Viestit

1

Yleistä keskustelua / Vs: Mitenkä vakaita nämä VPS tarjoajat ovatkaan ?

« : 23.08.20 - klo:11.14 »

Ihan jokaisessa on mahdollisuus skaalata. Ei siihen muuta tarvita kuin rahaa. Mutta skaalaustarve, kun paikalle sattuu yhtä aikaa huimaavat 20 ihmistä, ei liity mitenkään skaalaamiseen. Se tarkoittaa sitä, että ollaan maksettu Raspberrystä kuukausihintaa.

Mutta nuo kahvikupin hinnat selittävät miksi mm. OVH on niin hemmetinmoinen ongelma muille sivustoille. Itseasiassa melkoinen osa omista asiakkaistani blokkaa mahdollisuuksien rajoissa OVH:n ja Contabon IP-avaruudet.

2

Oppaiden kehittäminen / Vs: OpenVPN -yhteyden asettaminen ja käyttöönotto peruskäyttäjän näkökulmasta

« : 16.08.20 - klo:14.25 »

Jep. Ja kuinka monella on sama hetu 

Mutta ei oman VPN-serverin pystyttäminen ole isokaan asia edes humanistille:

https://www.eksis.one/ohjeet/openvpn/kiintea-ip-lahes-ilmaiseksi-oma-vpn/

3

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Operaattorin ei-julkinen IP ei toimi [RATKAISTU: Ei toimikaan, osta julkinen]

« : 11.08.20 - klo:21.47 »

No just. Tuo selittää erilaiset kokemukset.

Meillähän tänne Vihdin perukoille ei saa kaapelilla kuin sähkön. Data liikkuu taivaan kautta.

4

Yleistä keskustelua / Vs: Google Analyticsille vaihtoehto

« : 10.08.20 - klo:12.13 »

VPS vai joku muu? Matomo ehkä.

5

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Operaattorin ei-julkinen IP ei toimi [RATKAISTU: Ei toimikaan, osta julkinen]

« : 09.08.20 - klo:11.52 »

OpenVPN:stä: Minä en pääse siltä serveriltä, jossa OpenVPN-serveri pyörii, oman kotiverkon koneelle. Toisinpäin toimii. Tietysti, koska pääsen sisäverkosta ulos. Eli minun pitäisi käyttää DO:n serverillä omaa tunnustasi VPN-clienttinä, jos oikein ymmärsin? Kokeilen, mutta silloin kysymys kuuluu, että miksi siinä vaiheessa osattaisiin mennä Elisan NAT:n läpi sisälle päin, kun se ei muuten toimi?

Tunnelista - se edellyttäisi, että tunneli on ensin tehty sisältä ulos ja sen täytyisi olla koko ajan auki? Juu, en todellakaan ole sisäistänyt koko tunneloinnin ideaa, koska en ole sitä ikinä eläessäni joutunut käyttämään. Mutta noin se täytyy mennä, koska en pääse Elisan julkisesti näkyvällä IP:llä omaan sisäverkkoon normisti SSH:lla, kun käytössä on ei-julkinen, ja minulle on vaikea ymmärtää miten asia voisi olla toinen ilman, että yhteys tehdään ensin sisäverkosta. Joka vaatii joko jatkuvasti auki olevaa tunnelia tai että itse on fyysisesti sisäverkon koneella.

Tiedän, että tämä on osaltaan tekemällä tehty ongelma, koska noin 99 prosenttisesti teen töitä omalta koneeltasi ja on periaatteessa ihan se ja sama vaikka hyppäisinkin välillä toiseen terminaaliin. Mutta se ei ole joustavaa työntekoa. Plus minulla on henkinen ongelma asioiden kanssa, jotka eivät toimi. Mutta aika ajoin minun täytyy päästä maailmalla ollessa iPadin shellistä omaan sisäverkkoon ja se on nyt rikki.

Ei minulla ole taloudellista ongelmaa maksaa Elisalle julkisesta IP:stä. En vaan halua maksaa sitä, jos ei ole pakko. Ja sitä pakollisuutta yritän nyt hahmottaa.

Kyllä. Olen tuskallisen tietoinen, että tämä(kin) on eräänlainen välipostaus, koska en ole vielä ehtinyt vilkaisemaan noita viimeisiä vinkkejä.

6

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Operaattorin ei-julkinen IP ei toimi [RATKAISTU: Ei toimikaan, osta julkinen]

« : 08.08.20 - klo:19.56 »

Yritän hahmottaa ketjun selityksiä. Äkkinäiseltään näyttäisi siltä, että pääosin puhutaan omasta sisäverkosta maailmalle pääsystä. Ei se ollut missään vaiheessa ongelma. Maailmalta pääsy sisäverkkoon sen sijaan oli isokin ongelma ei-julkisella IP:llä.

En tiedä millä kaikilla tavoilla tämän aloituksessa olleen voi ymmärtää:

Ei-julkisella en pääse enää virtuaaliservereiltä SSH:lla kotiverkon routerissa SSH-serverin tointa hoitavaan tietotekniseen saippukoteloon eli Raspberry Pi'hin. Ulos sisäverkosta kyllä pääsee.

Mutta se tarkoittaa ihan sitä, että pääsen sisäverkossa olevasta omasta koneestani ihan minne vaan. Myös VPN:ni kautta. Mutta en saa muualta, vieraasta koneesta, kuten virtuaaliserveriltä, yhteyttä omaan Elisan NAT:n ja viimeiseksi oman routerin takana olevaan koneeseen, kun käytössä on ei-julkinen IP. En VPN:llä (joka olisikin outoa), en ProxyJumpeilla, enkä millään muullakaan.

Komento ssh jakke@84.231.jotain - jolla pitäisi päästä edes routerin takana olevaan SSH-serveriin, ei näyttäisi etenevän Elisan NAT:n läpi. jossa IP muuttuu muotoon 100.90.jotain. Ainakaan mikään logi ei kerro minkäänlaisesta saapuvasta liikenteestä. Sen sijaan julkinen IP, joka pysyy samana läpi ELisan NAT:n aina routerille saakka, toimii.

Efariminpojan ensimmäinen vinkki hankkia virtuaaliselverin siivu Hetzneriltä jne. ei auta tässä ja sellainen on jo käytössä - DigitalOceanilla. Se vaikuttaa vain omasta sisäverkosta lähtevään liikenteeseen. Mutta ei kykene yhdistämään takaisin edes routeriin asti, jos yritän käyttää vaikka iPadiäni VPN:n kautta, kun olen vieraassa verkossa.

Jikun tunneliesimerkki törmää samaan ongelmaan. Tunneli romahtaa Elisan NAT:n kohdalla, kun yritän rakentaa sen vaikka virtuaaliserveriltä oman sisäverkon suuntaan. Eframininpojan kommentti pohjaa samaan - on pakko olla julkinen IP (joka on tietysti aivan eri asia kuin julkisesti näkyvä osoite, jonka puuttumattomuus tarkoittaisi, ettei olla poistuttu sisäverkosta. Tietenkin).

Nyt saa kaivaa ratakiskoa esille. Mitä olen ymmärtänyt väärin?

7

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Operaattorin ei-julkinen IP ei toimi [RATKAISTU: Ei toimikaan, osta julkinen]

« : 08.08.20 - klo:09.29 »

IP:n vaihtuvuus ei ole tässä ongelma. VPN on asennettuna, mutta ulkoiseen serveriin ns. normaalimpaa käyttöä varten.

Mutta jaksaisitteko selittää miten se muuttaa ongelmaa sisääntulevassa liikenteessä? Jos minulla on routerin korvaajana VPN, niin miten ulkoa tuleva liikenne saa ELisan NAT:sta yhtään paremmin toimivan osoitteen, koska VPN olisi silloin NAT:n takana?

8

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Operaattorin ei-julkinen IP ei toimi

« : 08.08.20 - klo:00.05 »

Yksinkertainen selitys. Lopetan ongelman etsimisen omasta järjestelmästä.

Nyt, useamman tunnin täysin turhan riitelyn jälkeen toivoisi, että joku olisi kirjoittanut tuon noinkin simppelisti. Vaikka siihen Elisan mainostekstiin.

9

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Operaattorin ei-julkinen IP ei toimi [RATKAISTU: Ei toimikaan, osta julkinen]

« : 07.08.20 - klo:23.35 »

Kysäisenpä täältäkin, kun osaajia löytyy. On tämä Ubuntu-asiaa, koska yritän saada Ubuntusta yhteyttä Ubuntuun... okei, ei ole distroriippuvainen asia.

Joku aika sitten kun ostin Raspberryn ja aloin rakentamaan siitä SSH-serveriä, niin sekoilin urakalla. Aiheesta löytyy pari säälittävää ketjua. Mutta ihan alussa, kun en saanut millään yhteyttä SSH:lla Raspiin, niin avasin Elisalta julkisen IP:n tietämättä edes mitä se tarkoittaa. Ei se auttanut, koska en ollut tajunnut aukaista routerin palomuurista aukkoa Raspirukalle.

Homma lähti aikanaan toimimaan ja opin jopa, että julkinen IP tarkoittaa sitä, että julkisesti näkyvä IP on sama routerille asti. Normaali ei-julkinen muuttaa operaattorin NAT:ssa sen sisäverkon IP:ksi.

Päivittelin aikani, että mihin moista tarvitaan, kun kyllä meillä konsolit ja riistakamerat toimivat. Tuomitsin sen rahastukseksi ja katkaisin sopparin. Palasin ei-julkiseen IP-maailmaan.

Hetu kun olin sanonut, että koskaan ei ole julkista IP:tä tarvittu ja lopetin sen, niin heilahti samantien vastapalloon. Ei-julkisella en pääse enää virtuaaliservereiltä SSH:lla kotiverkon routerissa SSH-serverin tointa hoitavaan tietotekniseen saippukoteloon eli Raspberry Pi'hin. Ulos sisäverkosta kyllä pääsee.

Hyviä arvauksia? Johtuuko tuo siitä, että ulosnäkyvä IP ei ole sama kuin minkä sisäverkon SSH-serveri näkee eli Elisan NAT:n antama 100.90.jotain, mutta yhteys virtuaaliserveriltä tehdään julkisesti näkyvään 84.jotain osoitteeseen? Tämä nimittäin hajotti myös dynaamisen DNS:n toimivuuden tietysti myös.

sshd_config ei sisällä mitään IP-osoitteeseen liittyviä rajoitteita, ei myöskään UFW/iptables ja Fail2ban on pois päältä. Samaten hosts.deny kumisee tyhjyyttään. Ideoita mikä muu saattaisi blokata sisääntulevan, jos se ei johdu Elisan julkisen IP:n puuttumisesta?

Tuntuu ihmeelliseltä, koska tiedän, että jengi käyttää vastaavaa setupia ilman ostettua julkista IP:tä.

10

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: ProxyJump ja ohjeet aloittelijoille

« : 05.08.20 - klo:18.23 »

Hyviä pointteja. Hion noita kohtia paremmiksi.

11

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / ProxyJump ja ohjeet aloittelijoille

« : 05.08.20 - klo:12.44 »

Palvelimet ja muu edistyneempi käyttö... minä lähdin, omakohtaisesti, liikkeelle siitä, että aloittelija ei tee edistynyttä käyttöä 

Sekoilin aiemmin urakalla ketjussa SSH-verkon useampi asiakas ja koska se ketju on sisällöltään sekava ja ehkä jopa turha. niin teen epäkohteliaasti uuden aloituksen. Eli sain valmiiksi kirjalliset ohjeet miten aloittelija toteuttaa kotinsa sisäverkkoon jumpbox-serverin - joka siis aidosti kylläkin tarkoittaa, että mitä sinne omaan koneeseen täytyy komentaa, että pääsee pysähtymättä kotiverkkonsa SSH-palvelimen läpi.

Suunnilleen jokainen täällä varmaan osaa nämä asiat ja näin perusasiasta ei pysty kirjoittamaan mitään sellaista, jota ei olisi muualla kirjoitettu sen kiljuuna kertaa. Mutta olisin kiitollinen - oikeammin, joskus googlella tuonne eksyvät - olisivat kiitollisia, jos nopeasti vilkaisisitte läpi onko ajatustasolla jotain, jonka olen (taas) ymmmärtänyt väärin tai joka olisi parempi toteuttaa jollain muulla tavalla.

https://www.eksis.one/ohjeet/ssh-shell/sisaverkkoon-ulkomaailmasta-ssh-proxyjump/

12

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Raspi-bastioni

« : 04.08.20 - klo:18.47 »

Totta, tekeminen tekemisen takia on usein jo arvo sinällään.

13

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Raspi-bastioni

« : 04.08.20 - klo:18.07 »

Tuossa kun tappelin Raspberryn ja proxyjumpin kanssa (tai ei siinä tappelemista ollut, Windows-koneeseen kirjautumisessa oli), niin löysin itsestäni uuden tietämättömyyden - miten läppärit pääsee routerin läpi vaikka ihan vaan selaimella. No, ilmeisesti router ottaa niiden liikenteen ja päästää sen läpi jostain portista, mitä se ei kerro minulle - kaipa senkin jollain porttiscannerilla löytäisi.

Siitä sitten pääsin bastioneihin. Kyllä, tämä on vain pohdintaa, joka toivottavasti opettaa jotain, mutta koska saan pariskunnan Raspberry/Ubuntu toimimaan melkoisen vähällä vaivalla jump boxina /SSH-serverinä, niin onko mahdollista pakottaa sisäverkon tietokoneet kulkemaan kaikessa liikenteessään moisen bastiontyyppisen Raspin kautta?

Plus tietysti käytännön tasolla - onko moista mitään järkeä edes rakentaa? En tiedä mikä olisi sellainen uhkakuva, jossa moinen viritys auttaisi.

14

Yleistä keskustelua / Vs: SSH avaimella Windowskoneeseen ei onnistu [RATKAISTU: authorized_keys oikeudet]

« : 04.08.20 - klo:17.55 »

Jospa laittaisi näkyviin mitä tein. Ehkä joskus jollakulla on samanlainen ongelma:

https://www.eksis.one/ohjeet/ssh-shell/windows-10-ja-ssh/

15

Yleistä keskustelua / Vs: SSH avaimella Windowskoneeseen ei onnistu

« : 03.08.20 - klo:20.42 »

Tiesin niin paljon, että koska on win-tunnukseni on ylläpitäjä, niin se käyttää C:\\ProgramData\ssh\administrators_authorized_keys tiedostoa. Taviskäyttäjällä se olisi kotihakemistossa .ssh/authorized_keys (adminin suhteen tuota voi muuttaa sshd_config tiedostossa).

Sekin selvisi matkan varrella, että kyse on nimenomaan tiedosto-oikeuksista. Se mikä ei sitten selvinnyt on että miten hemmetissä nuo muutetaan. Yksikään PowerShell ohje ei toiminut. Osa oli liian vanhaa, osassa oli muuten vaan virheitä ja kaikki neuvoibat yhden kohdan väärin - joka on toki voinut toimiakin joskus kympin alkuvuosina.

Oikeudet saa ja täytyy olla vain kahdella: oma tunnus ja SYSTEM. Jokainen PowerShell-ohje, johon törmäsin, liittivät mukaan esim. sshd-käyttäjän.

Resurssinhallinta auki, oikea hakemisto, tapauksesta riippuen jonkumpi keys-tiedosto ja ominaisuudet, suojaus ja sitten nuo kaksi käyttäjää oikeuksilla. Ei oikeuksien perimistä, ei muita käyttäjiä. Ja salasanan kysely loppui siihen.

Ihmettelen vaan kahta asiaa:
- miksi logit eivät kerro mikä mättää (ssh:n logienkin katsominen oli yksi hemmetin souvi, kun nekin on suljettu kaikilta)
. minkä helvetin takia mikkisoftan inssit ei ole varastaneet chmod-komentoa

Ja kolmas . miksi Microsoftin omissa ohjeissa, joissa neuvotaan SSH-serverin asennus, ei tuota kerrota; ei tietenkään, koska ideahan on mennä ulos joten miksi silloin kukaan asentaisi serveriä...

Kyllä. Olen huonolla tuulella ja päätä särkee. Minulla meni puolitoista päivää tällaiseen perunan eto-asiaan.

16

Yleistä keskustelua / Vs: SSH avaimella Windowskoneeseen ei onnistu

« : 03.08.20 - klo:19.55 »

Alkaa haiskahtamaan, että tiedosto-oikeudet on väärin.

Jos olen koskaan joskus sanonut pahan sanan pingiviinimaailman vaikeudesta ja ohjeiden keskeneräisyydestä, niin nehän ovat ihan esikoulutasoa verrattuna WIndowsin ohjeisiin ja mitä Microsoftin tukisivut tarjoavat. No, kaipa tämä tästä - minä saan sekunnissa ohjeet miten oikeudet laitetaan Ubuntussa kohdallee, mutta olen nyt googlaillut puoli päivää miten hemmetissä se onnistuu Winkympissä 

17

Yleistä keskustelua / SSH avaimella Windowskoneeseen ei onnistu [RATKAISTU: authorized_keys oikeudet]

« : 03.08.20 - klo:19.09 »

Koska toinen osapuoli on Ubuntu, niin kelpaako?

Julkiset avaimet ovat paikallaan eikä mitään suurempia säätöjä ole tehty Win 10 SSH-serverillä. Silti kysyy koko ajan salasanaa. Googlekierrosta on nyt tehty pari päivää, eikä mikään onnistu. Koko ajan, kun yritän päästä Raspberrystä sisäverko Windows-koneeseen, kysytään sitkeästi salasanaa.

ssh -v kertoo tällaista:

[19:03:12] jagster@ubuntu:~$ ssh -v jakke@192.168.100.40
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/jagster/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.100.40 [192.168.100.40] port 22.
debug1: Connection established.
debug1: identity file /home/jagster/.ssh/id_rsa type 0
debug1: identity file /home/jagster/.ssh/id_rsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_dsa type -1
debug1: identity file /home/jagster/.ssh/id_dsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/jagster/.ssh/id_ed25519 type -1
debug1: identity file /home/jagster/.ssh/id_ed25519-cert type -1
debug1: identity file /home/jagster/.ssh/id_ed25519_sk type -1
debug1: identity file /home/jagster/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/jagster/.ssh/id_xmss type -1
debug1: identity file /home/jagster/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_7.7
debug1: match: OpenSSH_for_Windows_7.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.100.40:22 as 'jakke'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fj3Ntlzh3xNDxyDKBp+7fWR7KDA7aEDV7uD6kaXttcw
debug1: Host '192.168.100.40' is known and matches the ECDSA host key.
debug1: Found key in /home/jagster/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/jagster/.ssh/id_rsa RSA SHA256:HieGsx5L1GozfvQlb5wwYfpKEDUiNRqAOAEHpqPFTGk
debug1: Will attempt key: /home/jagster/.ssh/id_dsa
debug1: Will attempt key: /home/jagster/.ssh/id_ecdsa
debug1: Will attempt key: /home/jagster/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/jagster/.ssh/id_ed25519
debug1: Will attempt key: /home/jagster/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/jagster/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jagster/.ssh/id_rsa RSA SHA256:HieGsx5L1GozfvQlb5wwYfpKEDUiNRqAOAEHpqPFTGk
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/jagster/.ssh/id_dsa
debug1: Trying private key: /home/jagster/.ssh/id_ecdsa
debug1: Trying private key: /home/jagster/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/jagster/.ssh/id_ed25519
debug1: Trying private key: /home/jagster/.ssh/id_ed25519_sk
debug1: Trying private key: /home/jagster/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
jakke@192.168.100.40's password:

Näkeekö joku tuossa mitään vinkkiä sille, että SSH-avain ei käy, vaan siirrytään salasanaan? Minusta tuon mukaan kaikki on ok, mutta silti avainta ei käytetä. Jos estän salasanalla kirjautumisen, niin sitten ei kirjauduta ollenkaan.

18

Yleistä keskustelua / Vs: Nopein alustus ntfs-levyksi?

« : 03.08.20 - klo:10.56 »

Ja kiitos!

19

Yleistä keskustelua / Vs: Nopein alustus ntfs-levyksi?

« : 03.08.20 - klo:10.56 »

 -f, --fast, -Q, --quick
              Perform quick (fast) format. This will skip both zeroing of  the
              volume and bad sector checking.

Jep. Ehkä tässä on pakko opella man-sivujen käyttö kuitenkin.

20

Yleistä keskustelua / Vs: Nopein alustus ntfs-levyksi?

« : 03.08.20 - klo:10.54 »

Winkussa formatointi on, jos mahdollista, vielä hitaampaa. Tai no, ns. pika-formatointihan on nopea. Se vissiin vaan kirjoittaa uusiksi kirjanpidon?

Voishan tuosta tehdä vertailun, mihinkäs tässä on kiire valmiissa maailmassa.

Oukkidoukki, en tiennyt q-vivusta (man-sivut voisi olla syytä lukea, mutta ne tuppaa olemaan hyödyttömiä loppukäyttäjälle eli täytyisi tietää jo valmiiksi....)- Eli pintatarkastus on sama kuin nollien kirjoittaminen, joka sen ajan vie? Vai ei?