Elisan kaksi epäonnistumista

Jatko

Elisa on 8.6. julkaissut tietoja häiriön syihin liittyen. Käsittelen asiaa uudessa postauksessani.

Hädin tuskin puoli vuotta ehti kulua kaivuriepisodista, kun Elisan linjat tänään katkesivat valtaosalta asiakkaita jälleen. Tämänkertainen häiriö alkoi Elisan mukaan kello 10.30, ja yhteydet toimivat kaikilla jälleen kello 14.30. Pahimmillaan tämä tarkoitti siis neljän tunnin katkosta kesken perjantaita. Omalla kohdallani yhteys oli enemmän-vähemmän poikki noin kaksi ja puoli tuntia.

Elisa ei tätä kirjoittaessa ole kertonut mitään syytä tai selitystä verkkonsa ongelmiin, vaikkakin yrityksen palvelunhallintajohtaja Lasse Huttunen on Twitterissä kertonut asiaa selvitettävän ”pohjamutia myöten”. Syytä kaikenlaiseen muuhunkin itsetutkiskeluun Elisalla on. Jatka lukemista >>

NFS4 ja kadonneiden omistajanimien arvoitus

Kuvan KServer-Fuku­shima oik­kui­li verk­ko­kan­si­oi­den­sa kans­sa, kun idmapd käyt­ti vää­rää verk­ko­ni­meä. Lop­pu hy­vin, kaik­ki hy­vin: yli tun­nin ih­met­te­le­mi­sen ja yh­den kon­fi­gu­raa­tio­ri­vin muut­ta­mi­sen jäl­keen hom­ma toi­mii taas.

Kuva: Riku Eskelinen/ CC BY-SA 3.0

Kotonani työasemakoneet tuovat kotikansiot NFS4-tiedostopalvelimeltani, KServer-Mythbusterilta. Tänään kuitenkin kiinnitin huomiota KServer-Fukushima-ykköstyöasemakonettani (Debian squeeze) käyttäessäni, ettei kotikansioni ollut aivan kunnossa.

Pikaisella tarkistuksella (ls -ld ~) selvisi, että kotikansion omistajaksi oli merkitty nobody:nogroup oman käyttäjä- ja ryhmätunnukseni sijaan. Koska uudelleenkäynnistys yleensä auttaa kaikkeen, komensin1:

$ sudo service nfs-common restart
$ sudo mount -a -t nfs4 -o remount

Komennot suorittuivat ilman sen ihmeellisempiä virheilmoituksia, mutta ongelma pysyi samana: NFS-asiakas oli vahvasti sitä mieltä, että kotikansiot omistaa ei-kukaan. Siispä NFS-palvelimeni kimppuun.

NFS-jaoissa on oletuksena käytössä niin kutsuttu root_squash, jossa asiakkaan ilmoittamat root-käyttäjän oikeudet muunnetaan lennossa asetetun anonyymikäyttäjän ja -ryhmän (asetusoptiot anonuid ja anongid, oletuksena nobody:nogroup) oikeuksiksi. Tietoturvan kannalta asetus on hyvä pitää päällä, ja näin toki kaikilla jaoillani asia onkin. Musiikki- ja videojakojen osalta käytän vielä valintaa all_squash, jolloin kaikki käyttäjät voivat vapaasti kirjoitella ja lukea näitä kansioita.

Kun kerran kotikansiollekin omistajaksi näkyivät NFS-anonyymikäyttäjä ja -ryhmä, päätin tarkistaa, etten vahingossakaan ollut laittanut kotikansioille all_squash:ia päälle. NFS-verkkojaothan määritellään tiedostossa /etc/exports, ja siellä kotikansioiden osalta jako-optiot olivat kunnossa:

/export/homes   <koneet>(rw,sync,insecure,no_subtree_check)

OK, vika siis ei ollut palvelimessa, joten jatkoin selvittelyä Fukushiman osalta.

Käyttäjätunnusten koneidenvälinen mäppäily tapahtuu NFS4:ssa (ainakin Debianissa) rpc.idmapd:illa, joka kuuluu aiemmin uudelleenkäynnistettyyn nfs-common -pakettiin. Jotta idmapd:ia käytettäisiin, pitää asiakaskoneen /etc/default/nfs-common -tiedostossa se olla kytkettynä päälle. Kun kyseisen tiedoston avasin, ei NEED_IDMAPD=-kohdassa ollut määritelty mitään. Asetustiedoston mukaan tällöin käytetään automaattista tunnistusta, mutta ajattelin muuttaa tämän varmuuden vuoksi muotoon NEED_IDMAPD=yes.

Päätin tässä välissä rebootata Fukushiman, ja katsoa mitä tapahtuu. Noin minuutti myöhemmin2 päädyin raapimaan päätäni uudelleen, sillä asetusmuutos ei tuottanut toivottua tulosta. Tässä vaiheessa päätin vilkaista /var/log/syslog:ia, jota kahlaamalla löytyikin johtolanka:

May 17 14:55:11 kserver-fukushima rpc.idmapd[1161]: nss_getpwnam: name ’<käyttäjänimi>@kserver.dy.fi’ does not map into domain ’localdomain’

Kotiverkossani käytän verkkonimenä kserver.dy.fi:ä, ja kaikkien verkkoon tulevien koneiden pitäisi saada tietää tämä DHCP-vastauksen mukana. Olisiko sitten niin, että Fukushima jättäisi jostain syystä DHCP:n kertoman verkkonimen huomiotta, ja päätyisi jonkinlaisen oletusasetuksen kautta käyttämään localdomain:ia?

$ dnsdomainname
kserver.dy.fi

Ei, kyllä kone tietää olevansa kserver.dy.fi-verkossa. Tässä vaiheessa jouduin turvautumaan Googleen, jota kautta päädyin selaamaan RHEL:n postituslistan ketjua. Eräs viesti alkoi sanoin:


/etc/idmapd.conf is configured the same way on both the NFSv4 Server & Client correct?

/etc/idmapd.conf, vai? Katsotaanpa, mitä Fukushiman tiedosto tietää:

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Kas niin, löytyihän se syyllinen lopultakin. Domain-rivi muotoon Domain = kserver.dy.fi, reboottaus, ja kas:

$ ls -ldh ~
drwx—— 261 <käyttäjänimeni> <ryhmänimeni> 36K 17.5. 15:05 /home/<käyttäjänimeni>

Näin helposti ja mukavasti tämäkin asia saatiin kuntoon.


1) Tässä ensin käynnistetään NFS-jakojen oheispalvelut uudelleen, ja sen jälkeen liitetään kaikki fstab:in nfs4-muotoiset liitospisteet uudelleen.
2) Niin, Debian buuttaa huomattavasti Ubuntua nopeammin sekä ylös että alas, ainakin itselläni.

Vialliset verkkosovittimet viivästyttävät RPi:n toimituksia

Toinen on oikea, toinen väärä. Tehtaan
asentaman väärän verkkosovittimen ta-
kia Raspberry Pin toimitukset viivästy-
vät.
Kuva: Raspberry Pi Foundation

Olen kirjoittanut ultraedullisesta Raspberry Pi -tietokoneesta viime aikoina runsaasti, ja eräänlainen tilannepäivitys lienee taas paikallaan.

Raspberry Pi -säätiö ilmoitti eilen, että he huomasivat testeissään laitteen verkkosovittimen vaihtuneen tehtaalla toiseen, toimimattomaan, malliin:

— [W]here we’d specified jacks with integrated magnetics in the BOM and
schematics, the factory soldered in non-magnetic jacks. No magnetics
means no network connection.

Luonnollisesti tällainen vika aiheuttaa viivästyksiä, mutta samassa postauksessa kerrotaan, että valmistaja on saanut jo korjattua osan laitteista, ja että ensimmäisten tilaajien toimitukset voitaneen aloittaa suunnitellusti. Kuitenkin samalla ilmaistaan huoli siitä, että mahdollinen oikean komponentin saatavuusongelma voi aiheuttaa viivästyksiä:

There may now be a slight delay in later batches if there’s a problem
sourcing enough magnetic jacks –; all the stock of jacks we believed we had in place and ready
to turn into the ethernet ports on your Raspberry Pis turn out not to be
the correct part, so we’re having to start again and move through the
negotiating/ordering/delivery cycle as fast as we can.

Mutta on säätiöllä myös hyviä uutisia: Raspberry Pin ”virallinen” käyttöjärjestelmä, Raspberry Pi Fedora Remix, on julkaistu ja ladattavissa. Arch Linux -sovitus RPi:lle julkaistiin jo aiemmin, kuten myös Debian-versio. Vaikkei itse laitteita vielä käsiinsä saakaan, jakajia torrenteilla riittää: Fedoralla vajaa 500, Archilla n. 850 ja Debianilla n. 1850.

Odottavan aika on pitkä, ja vastoinkäymiset voivat alkaa masentaa. On kuitenkin hyvä muistaa, että säätiö on tehnyt – ja tehnee vastaisuudessakin – paljon töitä. Ja kaikkien odotus palkitaan – ennen pitkää.

Päivitetty klo 15:00: Näköjään myös IT-viikko uutisoi asiasta, tosin faktat ovat hieman hakusessa.

Elisalla epävarmuutta vähimmäisnopeudesta

Kuten lupasin eilisessa kirjoituksessani, soitin tänään Elisan asiakaspalveluun jälleen kerran.

Pääasiana oli hyvitykset häiriöajalta, ja varsin ystävällinen asiakaspalvelija tarjoutui hyvittämään kahden kuukauden kk-maksut. Täytyy myöntää, että olin positiivisesti yllättynyt Elisan asenteeseen tämän asian suhteen. Luonnollisesti hyväksyin tällaisen tarjouksen. Hieman joudun tilannetta asiakaspalvelijalle avaamaan, sillä Elisan laskutusongelmista johtuen on pari muutakin laskua jouduttu mitätöimään. Tämän suhteen kaikki on kunnossa.

Tiedustelin samalla hiukan lisätietoa siihen, millaista nopeutta Viihteestä pitäisi odottaa, sillä en oikein löytänyt katetta väitteelle, että kolmasosaan olisi tyytyminen. Asiakaspalvelija kertoi yllättäen, että vähintään noin puolet (eli 50Mbit/s) pitäisi tulla läpi. Kysäisipä vielä työkaveriltaan, jolla myös Viihde on, millaisia nopeuksia hän on saanut. Tämä työkaveri nauttii 70Mbit/s Viihteestä.

Täytyy nyt tarkastella, josko jotain optimoimisenvaraa vielä löytyisi omasta verkkokonfiguraatiosta, jotta nopeutta saisi edes tuohon 50Mbit/s:iin. Tämä on kuitenkin jokseenkin aikaavievä prosessi, mutta tullen siitäkin blogissani jossain vaiheessa raportoimaan. Tätä kirjoittaessa 24h keskiarvo on n. 32Mbit/s ja edellinen mittaus näyttää nopeudeksi noin 40Mbit/s.

Ei muuta kuin lisää konffia peliin ja savun hälvennyttyä tarkistamme kytkennät.

Lenten Reborn – miksi ei?

Olin tänään tutustumassa erääseen peruskoulu-lukion atk-luokkaan, jossa monen muun koulun tapaan on käytössä taiwanilaisen Lentenin Reborn-PCI-kortit, eli tietokone palautuu alkuperäiseen tilaansa uudelleenkäynnistyksen yhteydessä. Tuollaisen ratkaisun avulla esim. kioskikoneista ei tarvitse huolehtia, sillä niihin mahdollisesti tarttuneet haitakkeet poistuvat uudelleenkäynnistyksen yhteydessä.

Vaikkakin järjestelmän päivittäminen pysyvästi on mahdollista, valitettavan usein näin ei tehdä, eikä tässäkään tapauksessa. Tietokone oli asetettu olemaan valittamatta päivityksistä, ja niinpä koneesta löytyikin Windows XP SP 2 ja Firefoxista vanha 2-sarjan versio. En ryhtynyt tilanteen sopimattomuuden takia tarkemmin järjestelmää analysoimaan, mutta en lähtisi noin konfiguroidulla koneella tekemään mitään nettiselausta ihmeellisempää. Eli en kirjautuisi mihinkään, en kirjoittaisi esim. blogiani ja vielä vähemmän liittäisin järjestelmään omaa massamuistiani (=muistitikkua/ulkoista kiintolevyä…).

Kun vielä järjestelmässä kaikki käyttävät samoja tunnuksia, on tietoturva ja yksityisyys käytännössä olemattomia. Edes niin yksinkertaista toimenpidettä kuin Firefoxin yksityisyystietojen automaattista poistoa ei ollut kytketty päälle, ja näinpä vielä selaimen sulkemisen jälkeenkin seuraavalla käyttäjällä on melko vapaa pääsy edellisen käyttäjän tietoihin (keksit, välimuistit, sivuhistoria…).

Ottanen yhteyttä kyseisen kunnan IT-osastoon ensi tilassa ja tiedustelen hieman noista tietoturva-aukoista. Vähintä mitä he voivat tehdä on ilmoittaa järjestelmän käyttäjille (käytännössä siis oppilaat ja opettajat) ymmärrettävällä suomen kielellä että käytännössä kaikki syötetyt salasanat voidaan kaapata, ja näin on saattanut jo tapahtua.

Jos minun mielipidettäni korjaustoimenpiteiksi kysyttäisiin, suosittelisin maksimaalista siirtymistä Linux-verkkoon. Linux-verkossa jokaisella käyttäjällä voi olla oma käyttäjätunnus ja NFS-verkkojaossa oma kotikansio ja yhteiskansio. Muutenkin oikeuksien hallinta olisi helppoa ja worst case scenariossa käyttäjä voisi vaarantaa vain oman turvallisuutensa. Luonnollisestikin tällöinkin täytyy palvelimien ja työasemien päivityksistä huolehtia, mutta nuo voi asettaa päivittymään automaattisesti.

Jos (ja kun, näin uskon) oppilaitokset ovat myyneet sielunsa Microsoftille, hieman lievempi toimenpide olisi tehdä jokaiselle käyttäjälle oma tunnus ja verkkojakoihin oma kotikansio, kuten tiedän monien pienempienkin yhteisöjen (kuten työpaikkani, Oriveden seurakunnan) tehneen.

Mutta joo, kunhan ehdin joskus kotiinikin niin voisi laittaa sähköpostia tuosta asiasta, kirjoitan tänne sitten lisää kun heiltä kommenttia saan.