Sette opp standard Linux-filsystemer og konfigurere NFSv4 Server - Del 2

En Linux Foundation Certified Engineer (LFCE) er opplært til å sette opp, konfigurere, administrere og feilsøke nettverkstjenester i Linux-systemer, og er ansvarlig for design og implementering av systemarkitektur og løsning av hverdagsrelaterte problemer.

Vi introduserer Linux Foundation Certification Program (LFCE).

I del 1 av denne serien forklarte vi hvordan du installerer en NFS-server (Network File System) og stiller inn tjenesten til å starte automatisk ved oppstart. Hvis du ikke allerede har gjort det, vennligst se den artikkelen og følg de skisserte trinnene før du fortsetter.

  1. Installere nettverkstjenester og konfigurere automatisk oppstart ved oppstart – Del 1

Jeg vil nå vise deg hvordan du konfigurerer NFSv4-serveren på riktig måte (uten autentiseringssikkerhet) slik at du kan sette opp nettverksdelinger som skal brukes i Linux-klienter som om disse filsystemene var installert lokalt. Merk at du kan bruke LDAP eller NIS for autentiseringsformål, men begge alternativene er utenfor LFCE-sertifiseringens omfang.

Konfigurere en NFSv4-server

Når NFS-serveren er oppe og går, vil vi fokusere vår oppmerksomhet på:

  1. spesifisere og konfigurere de lokale katalogene som vi ønsker å dele over nettverket, og
  2. montere disse nettverksaksjene i klienter automatisk, enten gjennom /etc/fstab-filen eller det automount kjernebaserte verktøyet (autofs).

Vi vil forklare senere når du skal velge den ene eller den andre metoden.

Før vi blir, må vi sørge for at idmapd-demonen kjører og er konfigurert. Denne tjenesten utfører tilordning av NFSv4-navn (bruker@mittdomene) til bruker- og gruppe-IDer, og er nødvendig for å implementere en NFSv4-server.

Rediger /etc/default/nfs-common for å aktivere idmapd.

NEED_IDMAPD=YES

Og rediger /etc/idmapd.conf med ditt lokale domenenavn (standard er FQDN til verten).

Domain = yourdomain.com

Start deretter idmapd.

service nfs-common start 	[sysvinit / upstart based systems]
systemctl start nfs-common 	[systemd based systems]

Eksportere nettverksandeler

/etc/exports-filen inneholder hovedkonfigurasjonsdirektivene for vår NFS-server, definerer filsystemene som skal eksporteres til eksterne verter og spesifiserer tilgjengelige alternativer. I denne filen er hver nettverksandel angitt ved hjelp av en egen linje, som har følgende struktur som standard:

/filesystem/to/export client1([options]) clientN([options])

Hvor /filsystem/til/eksport er den absolutte banen til det eksporterte filsystemet, mens klient1 (opp til klientN) representerer den spesifikke klienten (vertsnavn eller IP-adresse) eller nettverket (jokertegn er tillatt) som andelen eksporteres til. Til slutt er opsjoner en liste over kommaseparerte verdier (opsjoner) som tas i betraktning ved henholdsvis eksport av andelen. Vær oppmerksom på at det ikke er mellomrom mellom hvert vertsnavn og parentesene det står foran.

Her er en liste over de mest hyppige alternativene og deres respektive beskrivelse:

  1. ro (forkortelse for skrivebeskyttet): Eksterne klienter kan montere de eksporterte filsystemene kun med leserettigheter.
  2. rw (forkortelse for read-write): Lar eksterne verter gjøre skriveendringer i de eksporterte filsystemene.
  3. wdelay (forkortelse for skriveforsinkelse): NFS-serveren forsinker å foreta endringer til disk hvis den mistenker at en annen relatert skriveforespørsel er nært forestående. Men hvis NFS-serveren mottar flere små urelaterte forespørsler, vil dette alternativet redusere ytelsen, slik at no_wdelay-alternativet kan brukes til å slå det av.
  4. synkronisering: NFS-serveren svarer på forespørsler bare etter at endringer er forpliktet til permanent lagring (dvs. harddisken). Det motsatte, async-alternativet, kan øke ytelsen, men på bekostning av tap av data eller korrupsjon etter en urent server omstart.
  5. root_squash: Hindrer eksterne rotbrukere fra å ha superbrukerprivilegier på serveren og tildeler dem bruker-IDen for bruker ingen. Hvis du vil «squash» alle brukere (og ikke bare root), kan du bruke alternativet all_squash.
  6. anonuid/anongid: Angir eksplisitt UID og GID for den anonyme kontoen (ingen).
  7. subtree_check: Hvis bare en underkatalog til et filsystem eksporteres, bekrefter dette alternativet at en forespurt fil er plassert i den eksporterte underkatalogen. På den annen side, hvis hele filsystemet eksporteres, vil deaktivering av dette alternativet med no_subtree_check øke hastigheten på overføringene. Standardalternativet i dag er no_subtree_check ettersom undertresjekking har en tendens til å forårsake flere problemer enn det er verdt, ifølge man 5-eksport.
  8. fsid=0 | rot (null eller rot): Spesifiserer at det angitte filsystemet er roten til flere eksporterte kataloger (gjelder kun i NFSv4).

I denne artikkelen vil vi bruke katalogene /NFS-SHARE og /NFS-SHARE/mydir på 192.168.0.10 (NFS-server) som vår test filsystemer.

Vi kan alltid liste de tilgjengelige nettverksaksjene på en NFS-server ved å bruke følgende kommando:

showmount -e [IP or hostname]

I utdataene ovenfor kan vi se at /NFS-SHARE- og /NFS-SHARE/mydir-aksjene på 192.168.0.10 har blitt eksportert til klient med IP-adresse 192.168.0.17.

Vår første konfigurasjon (se katalogen /etc/exports på NFS-serveren) for den eksporterte katalogen er som følger:

/NFS-SHARE  	192.168.0.17(fsid=0,no_subtree_check,rw,root_squash,sync,anonuid=1000,anongid=1000)
/NFS-SHARE/mydir    	192.168.0.17(ro,sync,no_subtree_check)

Etter å ha redigert konfigurasjonsfilen, må vi starte NFS-tjenesten på nytt:

service nfs-kernel-server restart 		[sysvinit / upstart based system]
systemctl restart nfs-server			[systemd based systems]
Montering av eksporterte nettverksandeler ved hjelp av autofs

Det kan være lurt å se Del 5 av LFCS-serien ("Hvordan montere/avmontere lokale og nettverk (Samba & NFS) filsystemer i Linux ") for detaljer om montering av eksterne NFS-ressurser på forespørsel ved å bruke kommandoen mount eller permanent gjennom /etc/fstab-filen.

Ulempen med å montere et nettverksfilsystem ved hjelp av disse metodene er at systemet må tildele de nødvendige ressursene for å holde delingen montert til enhver tid, eller i det minste til vi bestemmer oss for å avmontere dem manuelt. Et alternativ er å montere det ønskede filsystemet på forespørsel automatisk (uten å bruke mount-kommandoen) gjennom autofs, som kan montere filsystemer når de brukes og avmontere dem etter en periode med inaktivitet.

Autofs leser /etc/auto.master, som har følgende format:

[mount point]	[map file]

Hvor [kartfil] brukes til å indikere flere monteringspunkter innenfor [monteringspunkt].

Denne masterkartfilen (/etc/auto.master) brukes deretter til å bestemme hvilke monteringspunkter som er definert, og starter deretter en automonteringsprosess med de spesifiserte parameterne for hvert monteringspunkt.

Montering av eksporterte NFS-aksjer ved hjelp av autofs

Rediger din /etc/auto.master som følger:

/media/nfs	/etc/auto.nfs-share	--timeout=60

og lag en kartfil med navnet /etc/auto.nfs-share med følgende innhold:

writeable_share  -fstype=nfs4 192.168.0.10:/
non_writeable_share  -fstype=nfs4 192.168.0.10:/mydir

Merk at det første feltet i /etc/auto.nfs-share er navnet på en underkatalog i /media/nfs. Hver underkatalog lages dynamisk av autofs.

Start nå autofs-tjenesten på nytt:

service autofs restart 			[sysvinit / upstart based systems]
systemctl restart autofs 			[systemd based systems]

og til slutt, for å aktivere autofs for å starte ved oppstart, kjør følgende kommando:

chkconfig --level 345 autofs on
systemctl enable autofs 			[systemd based systems]
Undersøker monterte filsystemer etter å ha startet autofs-demonen

Når vi starter autofs på nytt, viser kommandoen mount oss at kartfilen (/etc/auto.nfs-share) er montert på den spesifiserte katalog i /etc/auto.master:

Vær oppmerksom på at ingen kataloger faktisk har blitt montert ennå, men vil bli automatisk når vi prøver å få tilgang til delingene som er spesifisert i /etc/auto.nfs-share:

Som vi kan se, «monterer» autofs-tjenesten kartfilen så å si, men venter til filsystemene får en forespørsel om å faktisk montere dem.

Utføre skrivetester i eksporterte filsystemer

Alternativene anonuid og anongid, sammen med root_squash som er angitt i den første delingen, lar oss kartlegge forespørsler utført av root-brukeren i klient til en lokal konto på serveren.

Med andre ord, når root i klienten oppretter en fil i den eksporterte katalogen, vil dens eierskap automatisk tilordnes brukerkontoen med UID og GID=1000, forutsatt at en slik konto finnes på serveren:

Konklusjon

Jeg håper du klarte å konfigurere og konfigurere en NFS-server som passer for miljøet ditt ved å bruke denne artikkelen som en veiledning. Det kan også være lurt å referere til de relevante man-sidene for ytterligere hjelp (for eksempel man exports og man idmapd.conf).

Føl deg fri til å eksperimentere med andre alternativer og testtilfeller som skissert tidligere, og ikke nøl med å bruke skjemaet nedenfor for å sende kommentarer, forslag eller spørsmål. Vi vil gjerne høre fra deg.