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.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

This site uses Akismet to reduce spam. Learn how your comment data is processed.