På det här ögonblicket du måste ha en fungerande TCP/IP-anslutning till ditt nätverk. Du bör kunna pinga andra datorer i nätverket, och om du har konfigurerat gatewayen därefter, bör du också kunna pinga datorer på Internet. Som ni vet är huvudsyftet med att ansluta en dator till ett nätverk att få tillgång till information. Medan vissa människor kan ansluta en dator till ett nätverk precis så, skulle de flesta vilja dela och komma åt filer och skrivare. De skulle vilja komma åt dokument på Internet eller spela onlinespel. Med TCP/IP-stöd och programvara installerad på ditt nya Slackware-system får du allt; Men genom att endast installera TCP/IP-stöd kommer funktionaliteten att vara mycket begränsad. För att dela och dela filer måste vi överföra dem fram och tillbaka med FTP eller SCP. Vi kan inte titta på vår ny dator med Slackware-filträd via My Network Places eller Hela nätverksikoner från Windows-datorer. Vi skulle vilja kunna ha konstant tillgång till filer på andra Unix-maskiner.

Helst skulle vi vilja använda nätverksfilsystem så att vi kan ha transparent åtkomst till filer på datorer. De program vi använder för att arbeta med information lagrad på datorer behöver egentligen inte ens veta vilken dator filen är lagrad på. De behöver bara veta att filen finns och hur man skaffar den. Resten är redan operativsystemets uppgift, att ge åtkomst till den här filen med tillgängliga lokala filsystem och nätverksfilsystem. De två vanligaste nätverksfilsystemen är SMB (implementerat över Samba) och NFS.

5.6.1. SMB / Samba / CIFS

Server Message Block (SMB) är en ättling till det äldre NetBIOS-protokollet som ursprungligen utvecklades av IBM för deras LAN Manager-produkt. Microsoft har i sin tur alltid varit intresserad av NetBIOS och dess arvtagare (NetBEUI, SMB och CIFS). Samba-projektet började 1991 när det skrevs för att tillhandahålla kommunikation mellan en IBM PC och en Unix-server. Idag tillhandahåller allmän tillgång till filer och utskriftstjänster över SMB-nätverket är den föredragna metoden för nästan hela den civiliserade världen, eftersom Windows också stöder det.

Samba-konfigurationsfilen /etc/samba/smb.conf är en av de mest väldokumenterade konfigurationsfilerna du kan hitta. Det finns förbyggda exempel med inställningar för delade resurser, så att du kan se och ändra dem efter dina behov. Om du behöver mer mer kontroll, smb.conf man-sidan står till din tjänst. Eftersom Samba har så bra dokumentation kommer vi inte att skriva om den här. Men låt oss snabbt uppehålla oss vid huvudpunkterna.

smb.conf är uppdelad i flera sektioner: en sektion per aktie, plus en global sektion för att ställa in parametrar som används överallt. Vissa parametrar är endast giltiga i den globala sektionen, och vissa är endast giltiga utanför den. Kom ihåg att den globala sektionen kan åsidosättas av vilken annan sektion som helst. Per ytterligare information se man-sidorna.

Du kommer troligen att vilja redigera din smb.conf-fil för att återspegla dina inställningar. lokalt nätverk... Vi rekommenderar att du ändrar artiklarna nedan:

Detta kommer att vara beskrivningen av din Slackware-dator, som visas i mappen Mina nätverksplatser (eller Alla nätverk).

Du kommer nästan säkert att vilja använda användarsäkerhetsnivån på ditt Slackware-system.

Om lösenordskryptering inte är aktiverat kommer du inte att kunna använda Samba med NT4.0-, Win2k-, WinXP- och Win2003-system. Tidigare versioner av Windows-operativsystem krävde inte kryptering för att ge tillgång till delade resurser.

SMB är ett autentiserat protokoll, d.v.s. du kan ange ett användarnamn och lösenord för att dra nytta av denna tjänst. Vi berättar för sambaservern att användarnamnen och lösenorden är korrekta genom kommandot smbpasswd. smbpasswd tillåter att delade nycklar används för att lägga till både vanliga användare och maskinanvändare (för SMB måste du lägga till NETBIOS-maskinnamn som maskinanvändare, vilket begränsar antalet maskiner från vilka autentisering kan ske).

Det är viktigt att överväga det förnamn användarnamn eller värdnamn måste redan finnas i filen / etc / passwd. Du kan uppnå detta med kommandot adduser. Observera att när du använder kommandot adduser måste du lägga till ett dollartecken (“$”) till datornamnet för att lägga till det. Dock detta inte måste göras när man arbetar med smbpasswd. Verktyget smbpasswd lägger till ett dollartecken på egen hand. Brott mot denna regel av adduser kommer att resultera i ett fel när värdnamnet läggs till samba.

5.6.2. Nätverksfilsystem (NFS)

NFS (Network File System) skrevs ursprungligen av Sun för Solaris - deras implementeringar Unix-system... Även om det är mycket lättare att ställa in och konfigurera än SMB, är NFS mycket mindre säkert. Den största säkerhetsbristen är att det är enkelt att ersätta användar- och grupp-ID från en maskin med ID från en annan. Autentisering är inte implementerad i NFS-protokollet. Det har angetts att i framtida versioner NFS-protokoll säkerheten kommer att förbättras, men när detta skrivs är detta ännu inte gjort.

NFS konfigureras genom exportfilen / etc /. När du laddar standard / etc / exportfilen till en editor, kommer du att se tom fil med en kommentar på de två översta raderna. Vi kommer att behöva lägga till en rad i exportfilen för var och en av de kataloger som vi vill exportera, som listar klientarbetsstationerna som kommer att tillåtas åtkomst till den katalogen. Om vi ​​till exempel vill exportera katalogen / home / foo för Bar-arbetsstationen, skulle vi behöva lägga till den här raden i vår / etc / exports-fil:

Som du kan se finns det flera olika alternativ, men de flesta borde vara tydliga från detta exempel.

NFS antar att en given användare på en av datorerna i nätverket har samma identitet på alla andra maskiner. När en NFS-klient försöker läsa eller skriva till en NFS-server skickas UID som en del av läs-/skrivbegäran. Detta UID anses vara detsamma som om begäran gjordes från den lokala maskinen. Som du kan se, om någon godtyckligt kan specificera ett givet UID vid åtkomst till resurser på en fjärrdator, kan och händer problem. En del av sättet att undvika detta är att montera alla kataloger med parametern root_squash. Detta åsidosätter UID för alla användare som påstår sig vara root till ett annat UID, vilket förhindrar root från att få ny åtkomst till filer och kataloger i den exporterade katalogen. Det ser ut som att root_squash är aktiverat som standard av säkerhetsskäl, men författarna rekommenderar fortfarande att du anger det uttryckligen i din / etc / exportfil.

Du kan också exportera en katalog på servern direkt från kommandorad med kommandot exportfs som visas nedan:

Detta kommando kommer att exportera katalogen / home / foo för datorn "Bar" och ge den läs-/skrivåtkomst. Dessutom är parametern root_squash inte aktiverad på NFS-servern, vilket betyder att alla användare på Bar med UID "0" (UID root "a) kommer att ha samma privilegier på servern som root. Syntaxen ser ganska konstig ut (vanligtvis när du anger katalog som dator: / katalog / fil, hänvisar du till en fil i en katalog på en given dator).

Du kan hitta mer information om exportfilen på man-sidan.

Filsystemet NFS (Network File System) skapades av Sun Microsystems. Det är för närvarande standardnätverksfilsystemet för operativsystemet. UNIX-familjen dessutom är NFS-klienter och -servrar implementerade för många andra operativsystem. Principerna för dess organisation är för närvarande standardiserade av Internetgemenskapen, den senaste versionen av NFS v.4 beskrivs av RFC-specifikationen ZOJ, som släpptes i december 2000.

NFS är ett system som stödjer schemat Fjärranslutning till filer. Användarens arbete med fjärrfiler efter monteringsoperationen blir helt transparent - underträdet i filsystemet på NFS-servern blir ett underträd till det lokala filsystemet.

Ett av målen för NFS-utvecklarna var att stödja heterogena system med klienter och servrar som kör olika operativsystem på olika hårdvaruplattformar. Detta mål stöds av Suns RFC-baserade implementering av NFS, som stöder standard XDR-funktionen för enhetlig representation av fjärrprocedurargument.

För att säkerställa klientens motståndskraft mot serverfel har NFS antagit ett tillståndslöst tillvägagångssätt, det vill säga när man arbetar med filer lagrar servrar inte data om filer som öppnas av klienter.

Grundidén bakom NFS är att tillåta en godtycklig grupp användare att dela ett gemensamt filsystem. Oftast tillhör alla användare samma lokala nätverk, men inte nödvändigtvis. Du kan också köra NFS på WAN. Varje NFS-server tillhandahåller en eller flera av sina kataloger för fjärråtkomst till klienter. Katalogen förklaras tillgänglig med alla dess underkataloger. Listan över kataloger som skickas av servern finns i exportfilen / etc /, så dessa kataloger exporteras automatiskt så fort servern startar. Klienter kommer åt de exporterade katalogerna genom att montera. Många Sun-arbetsstationer är diskfria, men även då är det möjligt att montera ett fjärrfilsystem till rotkatalogen med hela filsystemet på servern. Exekveringen av program är nästan oberoende av var filen finns: lokalt eller på en fjärrdisk. Om två eller flera klienter har monterat samma katalog samtidigt, kan de kommunicera genom att dela upp filen.

NFS-filsystemet använder två protokoll i sitt arbete.

Det första NFS-protokollet styr monteringen. Klienten skickar det fullständigt kvalificerade katalognamnet till servern och begär tillstånd att montera den katalogen någonstans i sitt eget katalogträd. I det här fallet anges inte servern där serverkatalogen kommer att monteras. Efter att ha tagit emot namnet validerar servern begäran och returnerar en filbeskrivning till klienten som är fjärrmonteringspunkten. Deskriptorn inkluderar en filsystemstypbeskrivning, disknummer, inodnummer för katalogen som är fjärrmonteringspunkten och säkerhetsinformation. Läsa och skriva filer från monterade filsystem använder filbeskrivningar istället för ett symboliskt namn.

Montering kan göras automatiskt med hjälp av batchfiler vid uppstart. Det finns ett annat alternativ för automatisk montering: när operativsystemet startar på en arbetsstation monteras inte fjärrfilsystemet, men när fjärrfilen öppnas för första gången skickar operativsystemet förfrågningar till varje server och efter att den här filen har upptäckts, monterar katalogen för servern där den hittade filen finns.

Det andra NFS-protokollet används för att komma åt fjärrfiler och kataloger. Klienter kan skicka en begäran till servern om att utföra någon åtgärd på katalogen eller läsa eller skriva en fil. Dessutom kan de fråga efter filattribut som typ, storlek, skapande och ändringstider. NFS stöds av de flesta UNIX-systemanrop, med undantag för öppna och stänga. De öppna och stängda undantagen är inte oavsiktliga. Istället för att öppna en fjärrfil skickar klienten ett meddelande till servern som innehåller filnamnet, begär en uppslagning och returnerar en filbeskrivning. Till skillnad från det öppna anropet kopierar inte uppslagsanropet någon information till de interna systemtabellerna. Läsanropet innehåller filbeskrivningen som ska läsas, förskjutningen i filen som läses och antalet byte som ska läsas. Fördelen med detta schema är att servern inte kommer ihåg något om öppna filer. På detta sätt, om servern kraschar och sedan återställs, kommer information om öppna filer inte att gå förlorad, eftersom det inte stöds.

Om servern misslyckas, fortsätter klienten helt enkelt att skicka kommandon för att läsa eller skriva till filer, men utan att få ett svar och ha förbrukat timeouten, upprepar klienten sina förfrågningar. Efter omstart tar servern emot ytterligare en upprepad begäran från klienten och svarar på den. En serverkrasch orsakar alltså bara en viss paus i kundtjänsten, men nej ytterligare åtgärder klienter behöver inte återställa anslutningar och öppna filer igen.

Tyvärr gör NFS det svårt att låsa filer. På många operativsystem kan en fil öppnas och låsas så att andra processer inte kan komma åt den. När filen stängs frigörs låset. På tillståndslösa system som NFS kan blockering inte relateras till att en fil öppnas, eftersom servern inte vet vilken fil som är öppen. Därför kräver NFS speciella ytterligare medel blockerande kontroll.

NFS använder cachelagring på klientsidan, data överförs till cachen block för block och read-ahead används, där läsning av ett block till cachen på begäran av applikationen alltid följs av läsning av nästa block på initiativ av systemet. NFS-cachemetoden bevarar inte UNIX-semantik för fildelning. Istället används den kritiskt kritiserade semantiken, där ändringar av data i en fil som cachelagras av en klient är synliga för en annan klient, beroende på tidpunkten. Vid nästa öppning av en fil i dess cache, kontrollerar klienten med servern när filen senast ändrades. Om detta händer efter att filen har placerats i cachen tas filen bort från cachen och en ny kopia av filen tas emot från servern. Klienter distribuerar ändringar som gjorts i cachen var 30:e sekund, så att servern kan ta emot uppdateringar med en lång fördröjning. Som ett resultat av mekanismerna för att rensa data från cachen och distribuera ändringar, är data som tas emot av en klient inte alltid den senaste.

NFS-replikering stöds inte.

Katalogtjänst

Syfte och principer för organisation

Liksom en stor organisation behöver ett stort datornätverk centralt lagra så mycket referensinformation om sig själv som möjligt. Lösningen av många problem i nätverket är beroende av information om nätverksanvändare - deras namn används för logisk inloggning, lösenord, åtkomsträttigheter till nätverksresurser, såväl som resurser och nätverkskomponenter: servrar, klientdatorer, routrar, gateways, filvolymer system, skrivare etc.

Här är exempel på de viktigaste uppgifterna som kräver en centraliserad databas med referensinformation på nätverket:

• En av de mest frekvent utförda uppgifterna i systemet, baserat på referensinformation om användare, är deras autentisering, på basis av vilken åtkomstbehörighet sedan utförs. Nätverket måste på något sätt lagras centralt Konton användare som innehåller namn och lösenord.
• Att ha någon form av centraliserad databas kräver stöd för transparens för åtkomst till många nätverksresurser. En sådan databas bör lagra namnen på dessa resurser och mappningen av namn till numeriska identifierare (till exempel IP-adresser), så att du kan hitta denna resurs i nätverket. Transparens kan tillhandahållas för åtkomst till servrar, filsystemvolymer, RPC-procedurgränssnitt, distribuerade applikationsprogramobjekt och många andra nätverksresurser.
• E-post är ett annat populärt exempel på en tjänst som vill ha en webbaserad helpdesk som lagrar användarnamnsdata.
• V senare tid I nätverk används allt oftare hanteringsverktyg för tjänstekvalitet (QoS), som också kräver information om alla användare och applikationer av systemet, deras krav på trafikkvalitetsparametrar för tjänsten, samt om alla nätverksenheter med vilka du kan hantera trafik (routrar, switchar, gateways, etc.).
• Organiseringen av distribuerade applikationer kan avsevärt förenklas om nätverket har en databas som lagrar information om tillgängliga programmoduler-objekt och deras placering på nätverksservrarna. En applikation som behöver utföra någon standardåtgärd gör en begäran till en sådan databas och får adressen till ett programobjekt som kan utföra den nödvändiga åtgärden.
• Nätverkshanteringssystemet måste ha en bas för att lagra information om nätverkstopologin och allas egenskaper nätverkselement såsom routrar, switchar, servrar och klientdatorer. Närvaron av fullständig information om nätverkets sammansättning och dess anslutningar tillåter systemet automatiserad kontroll nätverk för att korrekt identifiera meddelanden om nödsituationer och hitta deras rotorsak. Information sorterad efter avdelningar av företaget om tillgängliga nätverksutrustning och etablerade programvara användbart i och för sig, eftersom det hjälper administratörer att få en tillförlitlig bild av nätverkets tillstånd och utveckla planer för dess utveckling.

Sådana exempel kan fortsätta, men det är inte svårt att citera ett motargument som ställer tvivel om behovet av att använda en centraliserad databas med referensinformation i nätverket - länge sedan nätverk fungerade utan en enda referensdatabas, och många nätverk fungerar fortfarande utan en. Det finns faktiskt många privata lösningar som gör det möjligt att effektivt organisera driften av ett nätverk baserat på privata referensdatabaser, som kan representeras av vanliga textfiler eller tabeller lagrade i applikationens kropp. Till exempel använder UNIX traditionellt en passwd-fil för att lagra användarnamn och lösenord, som bara täcker användare på en dator. Du kan också lagra namnen på e-postmottagare i en lokal fil på klientdatorn. Och så privat hjälpsystem fungerar bra - övning bekräftar detta.

Denna invändning gäller dock endast för små och medelstora nätverk, i stora nätverk förlorar enskilda lokala referensdatabaser sin effektivitet. DNS på Internet är ett bra exempel som visar sig inte tillämpas på lokala lösningar för stora nätverk. När storleken på Internet överskred en viss gräns blev det ineffektivt att lagra information om överensstämmelsen mellan namn och IP-adresser för datorer i nätverket i lokala textfiler. Det var nödvändigt att skapa en distribuerad databas som stöddes av hierarkiskt länkade namnservrar och en centraliserad tjänst ovanpå den databasen för att symbolisk namnupplösning på Internet skulle fungera snabbt och effektivt.

För ett stort nätverk är det också ineffektivt att använda ett stort antal snäva hjälptjänster: en för autentisering, en annan för nätverkshantering, tredje för att lösa datornamn, etc. Även om var och en av dessa tjänster är välorganiserade och kombinerar en centraliserat gränssnitt med en distribuerad basdata, stort antal helpdesk-tjänster duplicerar stora mängder information och komplicerar nätverksadministration och hantering. Till exempel har Windows NT minst fem olika typer referensdatabaser. Domänens huvudkatalog (NT Domain Directory Service) lagrar information om användare, som krävs för att organisera deras logiska inloggning till nätverket. Data om samma användare kan finnas i en annan katalog som används av elektroniskt via Microsoft mail Post. Ytterligare tre databaser stöder adressupplösning: WINS mappar Netbios-namn till IP-adresser, DNS-katalogen (Domain Name Server) är användbar när du ansluter ett NT-nätverk till Internet, och slutligen används DHCP-katalogen för att automatiskt tilldela IP-adresser till datorer i nätverket .... Uppenbarligen komplicerar en sådan mängd olika helpdesktjänster administratörens liv och leder till ytterligare fel när samma användares autentiseringsuppgifter måste anges i flera databaser. Därför i det nya Windows-versioner 2000 det mesta av systemets hjälpinformation kan lagras tjänsten aktiv Directory är en enda, centraliserad katalogtjänst som använder en distribuerad databas och är integrerad med DNS.

Resultatet av utvecklingen av lagringssystem för referensinformation var uppkomsten i nätverksoperativsystem av en speciell tjänst - de så kallade Directory Services, även kallade en referenstjänst (katalog). Katalogtjänsten lagrar information om alla användare och nätverksresurser i form av enhetliga objekt med vissa attribut, och låter dig även spegla relationerna mellan lagrade objekt, såsom användares tillhörighet till en viss grupp, användarrättigheter till datorer, ingång av flera noder i ett subnät, kommunikationslänkar mellan subnät, serverproduktion etc. Katalogtjänsten låter dig utföra vissa grundläggande operationer på lagrade objekt, såsom att lägga till och ta bort ett objekt, inklusive ett objekt i ett annat objekt, ändra värdena för ett objektattribut, läsa av attribut, och några andra. Vanligtvis byggs olika specifika nätverksapplikationer ovanpå katalogtjänsten, som använder informationen från tjänsten för att lösa specifika uppgifter: nätverkshantering, användarautentisering, servicetransparens och annat som anges ovan. En katalogtjänst är vanligtvis byggd på en klient-server-modell: servrar lagrar en databas med referensinformation som klienter använder genom att skicka förfrågningar till servrar över nätverket. Det verkar vara samma sak för katalogklienten. centraliserat systemäven om de flesta bra katalogtjänster har en distribuerad struktur som inkluderar ett stort antal servrar, är strukturen transparent för klienterna.

En viktig frågaär organisationen av referensdatabasen. En enda databas som lagrar en stor mängd referensinformation skapar samma problem som vilken annan stor databas som helst. Implementering av helpdesk som en lokal databas lagrad som en enda kopia på en av nätverksservrarna lämpar sig inte för ett stort system av flera skäl, främst på grund av låg prestanda och låg tillförlitlighet hos en sådan lösning. Prestandan kommer att vara låg på grund av det faktum att förfrågningar till databasen från alla användare och applikationer på nätverket kommer att gå till en enda server, som med ett stort antal förfrågningar säkerligen kommer att sluta hantera deras behandling. Det vill säga, en sådan lösning skalar inte bra när det gäller antalet betjänade användare och delade resurser. Tillförlitligheten kan inte heller vara hög i ett system med en enda kopia av data. Förutom att ta bort begränsningar för prestanda och tillförlitlighet är det önskvärt att strukturen i databasen tillåter logisk gruppering av resurser och användare efter strukturella divisioner av företaget och tilldela en administratör för varje sådan grupp.

Utmaningarna med att upprätthålla prestanda och tillförlitlighet när nätverket växer hanteras vanligtvis genom distribuerade referensdatabaser. Att dela data över flera servrar minskar belastningen på varje server, samtidigt som tillförlitligheten bibehålls genom att ha flera repliker av varje del av databasen. För varje del av databasen kan du tilldela sin egen administratör, som endast har åtkomsträttigheter till objekten i sin del av information om hela systemet. För användaren (och för nätverksapplikationer) verkar en sådan distribuerad databas vara en enda databas som ger tillgång till alla nätverksresurser, oavsett vilken arbetsstation begäran kom från.

Det finns två populära standarder för katalogtjänster. För det första är det X.500-standarden utvecklad av ITU-T (vid tidpunkten för utvecklingen av standarden kallades denna organisation CCITT). Denna standard definierar funktionerna, organisationen av helpdesk och protokollet för åtkomst till den. X.500-standarden är i första hand utformad för användning med posttjänsten X.400 och tillåter dig att effektivt organisera lagringen av all referensinformation och fungerar som en bra grund för en universell katalogtjänst på nätverket.

En annan standard är LDAP-standarden (Light-weight Directory Access Protocol) som utvecklats av Internetgemenskapen. Den här standarden definierar ett förenklat åtkomstprotokoll för katalogtjänster eftersom tjänster byggda på X.500-standarden har visat sig vara för besvärliga. LDAP har blivit utbredd och har blivit de facto-standarden som ett klientåtkomstprotokoll för helpdeskresurser.

Det finns också flera praktiska implementeringar katalogtjänster för nätverksoperativsystem. Den mest utbredda är tjänsten Novell NDS, utvecklad 1993 för nätverksoperativsystemet NetWare 4.0, och idag är den även implementerad för Windows NT/2000. Katalogtjänst är av stort intresse Active Directory utvecklat av Microsoft för Windows 2000. Båda dessa tjänster stöder åtkomstprotokollet LDAP och kan fungera i mycket stora nätverk på grund av deras distribution.

NDS katalogtjänst

NetWare Directory Services (NDS) är en global referenstjänst baserad på en distribuerad objektorienterad databas med nätverksresurser. NDS-databasen innehåller information om alla nätverksresurser, inklusive information om användare, användargrupper, skrivare, volymer och datorer. NetWare OS (och andra NDS-klienter som körs på andra plattformar) använder NDS-information för att ge åtkomst till dessa resurser.

NDS ersatte bindery-katalogen för tidigare versioner av NetWare. Bindery-katalogen är en "platt" eller single-tier databas utformad för att stödja en enda server. Den använde också begreppet "objekt" för en nätverksresurs, men tolkningen av denna term skilde sig från den allmänt accepterade. Bindeföremålen identifierades som enkla numeriska värden och hade vissa egenskaper. Men för dessa objekt fanns det inget uttryckligt arvsförhållande för objektklasser, så förhållandet mellan bindery-objekt fastställdes godtyckligt av administratören, vilket ofta ledde till dataintegritetsintrång.

NDS-databasen är en nivåbaserad databas som upprätthåller resursinformation för alla servrar i ett nätverk. För bakåtkompatibilitet med NetWare tillhandahåller NDS en bindery-emuleringsmekanism.

NDS är en betydande förbättring jämfört med tidigare versioner genom att:

• distribution;
• replikerbarhet;
• genomskinlighet;
• globalitet.

Distribution innebär att information inte lagras på en enda server, utan delas upp i delar som kallas partitioner. NetWare lagrar dessa partitioner på flera servrar i nätverket (Figur 10.8). Den här egenskapen förenklar administrationen och hanteringen av ett stort nätverk avsevärt, eftersom det framstår som ett enda system för administratören. Det ger också snabbare åtkomst till nätverksresursdatabasen genom att komma åt närmaste server.

Ris. 10.8. NDS databaspartitioner

En replik är en kopia av NDS-partitionsinformationen. Du kan skapa ett obegränsat antal repliker av varje partition och lagra dem på olika servrar... Om en server stannar kan kopior av denna information hämtas från en annan server. Detta ökar systemets motståndskraft eftersom ingen server är ansvarig för all information i NDS-databasen.

Transparens är att NDS automatiskt skapar länkar mellan mjukvara och hårdvarukomponenter som ger en användare tillgång till nätverksresurser. NDS kräver inte att användaren känner till den fysiska platsen för dessa resurser. Frågar nätverksresurs med namn kommer du att få korrekt åtkomst till den även om dess nätverksadress eller plats ändras.

Globaliteten för NDS är att efter att ha loggat in får du tillgång till resurserna i hela nätverket, och inte bara en server, som det var i tidigare versioner... Detta görs genom den globala inloggningsproceduren. Istället för att logga in på en separat server, loggar NDS-användaren in på nätverket och får sedan tillgång till de nätverksresurser som är tillåtna för honom. Informationen som ges vid logisk inloggning används för att identifiera användaren. Senare, när användaren försöker komma åt resurser som servrar, volymer eller skrivare, bakgrundsprocessen identifiering kontrollerar om en användare har rätt till en given resurs.

God tid, läsare och gäster. Det var ett väldigt långt uppehåll mellan inläggen, men jag är tillbaka i strid). I dagens artikel kommer jag att överväga NFS-protokolldrift, och konfigurera en NFS-server och NFS-klient på Linux.

En introduktion till NFS

NFS (Nätverksfilsystem - nätverksfilsystem) enligt min mening - en idealisk lösning i ett lokalt nätverk där snabbt (snabbare än SAMBA och mindre resurskrävande jämfört med fjärrfilsystem med kryptering - sshfs, SFTP, etc ...) behövs datautbyte och inte ligger i framkant säkerhet för överförd information. NFS-protokoll tillåter montera fjärrfilsystem över ett nätverk till ett lokalt katalogträd som om det vore ett monterat diskfilsystem. Således kan lokala applikationer fungera med fjärrfilsystemet som med det lokala. Men du måste vara försiktig (!) Med ställa in NFS, eftersom det med en viss konfiguration är möjligt att stänga av klientens operativsystem och vänta på oändlig I/O. NFS-protokoll baserat på arbete RPC-protokoll, vilket inte lämpar sig för min förståelse ännu)) så materialet i artikeln blir lite vagt ... Innan du kan använda NFS, vare sig det är en server eller en klient, måste du se till att din kärna har stöd för NFS-filsystemet. Du kan kontrollera om kärnan stöder NFS-filsystemet genom att leta efter närvaron av motsvarande rader i filen / proc / filsystem:

ARCHIV ~ # grep nfs / proc / filsystem nodev nfs nodev nfs4 nodev nfsd

Om de angivna raderna i filen / proc / filsystem misslyckas måste du installera paketen som beskrivs nedan. Detta kommer med största sannolikhet att installera beroende kärnmoduler för att stödja de önskade filsystemen. Om efter installation av paket visas inte NFS-stöd i den angivna filen, kommer det att vara nödvändigt, med inkluderandet av denna funktion.

Historia Nätverksfilsystem

NFS-protokoll utvecklad av Sun Microsystems och har 4 versioner i sin historia. NFSv1 utvecklades 1989 och var experimentell och körde på UDP-protokollet. Version 1 beskrivs i. NFSv2 släpptes samma 1989, beskrevs av samma RFC1094 och var också baserat på UDP-protokollet, samtidigt som du inte kunde läsa mer än 2 GB från en fil. NFSv3 reviderad 1995 och beskriven i. De viktigaste innovationerna i den tredje versionen var filstöd stor storlek, lagt till stöd för TCP-protokollet och stora TCP-paket, vilket avsevärt påskyndade teknikens drift. NFSv4 slutfördes 2000 och beskrivs i RFC 3010, reviderades 2003 och beskrivs i. Den fjärde versionen inkluderade prestandaförbättringar, stöd för olika autentiseringsverktyg (i synnerhet Kerberos och LIPKEY som använder RPCSEC GSS-protokollet) och åtkomstkontrollistor (både POSIX- och Windows-typer). NFS-versioner v4.1 godkändes av IESG 2010 och fick numret. En viktig innovation av version 4.1 är specifikationen pNFS - Parallel NFS, en mekanism för parallell åtkomst av en NFS-klient till data från många distribuerade NFS-servrar. Närvaron av en sådan mekanism i nätverkets filsystemstandard kommer att hjälpa till att bygga distribuerade "moln"-lagringar och informationssystem.

NFS-server

Sedan vi har NFS- detta är nätverk filsystem är nödvändigt. (Du kan också läsa artikeln). Vidare är det nödvändigt. På Debian är detta paketet nfs-kärnserver och nfs-vanligt, i RedHat är detta paketet nfs-utils... Och det är också nödvändigt att aktivera lanseringen av demonen på de nödvändiga OS-körnivåerna (kommandot i RedHat är / sbin / chkconfig nfs på, i Debian - /usr/sbin/update-rc.d nfs-kernel-server standardvärden).

Installerade paket i Debian körs i följande ordning:

ARKIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 rotrot 20 okt 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 rotrot 27 okt 22 01:23 S16nfs-server -.kerne./it-server -.kerne. / nfs-kärnserver

Det vill säga, det börjar först nfs-vanligt sedan själva servern nfs-kärnserver... I RedHat är situationen liknande, med det enda undantaget att det första manuset kallas nfslock och servern kallas helt enkelt nfs... Handla om nfs-vanligt debiansajten berättar bokstavligen följande för oss: vanliga filer för en NFS-klient och -server måste detta paket installeras på en maskin som fungerar som en NFS-klient eller -server. Paketet innehåller program: lockd, statd, showmount, nfsstat, gssd och idmapd... Genom att visa innehållet i startskriptet /etc/init.d/nfs-common du kan spåra följande arbetssekvens: skriptet kontrollerar förekomsten av en körbar binär fil /sbin/rpc.statd, kontrollerar förekomsten i filer / etc / default / nfs-common, / etc / fstab och / etc / exporter parametrar som kräver att demoner startas idmapd och gssd , startar demonen /sbin/rpc.statd , sedan innan du börjar /usr/sbin/rpc.idmapd och /usr/sbin/rpc.gssd kontrollerar förekomsten av dessa körbara filer binära filer, sedan för daemon /usr/sbin/rpc.idmapd kontrollerar för sunrpc, nfs och nfsd, samt stöd för filsystemet rpc_pipefs i kärnan (det vill säga dess närvaro i filen / proc / filsystem), om allt är framgångsrikt körs det /usr/sbin/rpc.idmapd ... Dessutom för demonen /usr/sbin/rpc.gssd kontroller kärnmodul rpcsec_gss_krb5 och startar demonen.

Om du tittar på innehållet NFS-serverns startskript på Debian ( /etc/init.d/nfs-kärnserver), sedan kan du följa följande sekvens: vid uppstart kontrollerar skriptet filens existens / etc / exporter, Tillgänglighet nfsd, tillgång till support NFS filsystem i (det vill säga i filen / proc / filsystem), om allt är på plats startas demonen /usr/sbin/rpc.nfsd , kontrollerar sedan om parametern är inställd NEED_SVCGSSD(ställ in i serverinställningsfilen / etc / default / nfs-kernel-server) och, om det ges, startar demonen /usr/sbin/rpc.svcgssd , den sista att starta demonen /usr/sbin/rpc.mountd ... Från det här skriptet kan du se det NFS serverdrift består av daemoner rpc.nfsd, rpc.mountd och om Kerberos-autentisering används, då demonen rcp.svcgssd. Demonen rpc.rquotad och nfslogd körs fortfarande i den röda hatten (Av någon anledning hittade jag inte information om denna demon i Debian och orsakerna till dess frånvaro, uppenbarligen raderade ...).

Av detta blir det tydligt att Network File System-servern består av följande processer (läs - demoner) finns i katalogerna / sbin och / usr / sbin:

I NFSv4, när du använder Kerberos, startas demoner dessutom:

• rpc.gssd- NFSv4-demonen tillhandahåller autentiseringsmetoder genom GSS-API (Kerberos Authentication). Fungerar på klient och server.
• rpc.svcgssd- NFSv4-serverdemon som tillhandahåller klientautentisering på serversidan.

portmap och RPC-protokoll (Sun RPC)

Utöver ovanstående paket kräver NFSv2 och v3 extra paket portmap(i nyare distributioner, ersatt av bytt namn i rpcbind). Detta paket installeras vanligtvis automatiskt med NFS som beroende och implementerar driften av RPC-servern, det vill säga det ansvarar för den dynamiska tilldelningen av portar för vissa tjänster som är registrerade i RPC-servern. Bokstavligen, enligt dokumentationen, är detta en server som konverterar programnummer för Remote Procedure Call (RPC) till TCP/UDP-portnummer. portmap fungerar på flera enheter: RPC-samtal eller förfrågningar, TCP/UDP-portar,protokollversion(tcp eller udp), programnummer och mjukvaruversioner. Portmap-demonen startas av skriptet /etc/init.d/portmap innan NFS-tjänsterna startas.

Kort sagt, jobbet för en RPC-server (Remote Procedure Call) är att behandla RPC-anrop (alias RPC-procedurer) från lokala och avlägsna processer. Genom att använda RPC-anrop registrerar eller tar tjänsterna bort sig själva till/från portmappern (alias portmapper, aka portmap, aka portmapper, aka rpcbind, i nyare versioner), och klienter som använder RPC-anrop som riktar förfrågningar till portmapper får den information de behöver. Användarvänliga programtjänstnamn och deras motsvarande nummer definieras i / etc / rpc. Så snart en tjänst har skickat en motsvarande begäran och registrerat sig hos RPC-servern i portmapparen, tilldelar RPC-servern TCP- och UDP-portarna till tjänsten som tjänsten startades på och lagrar i kärnan motsvarande information om kör tjänst (namn), en unik nummertjänst (i enlighet med / etc / rpc), om protokollet och porten som tjänsten körs på och om versionen av tjänsten, och tillhandahåller den specificerade informationen till klienter på begäran. Portomvandlaren själv har ett programnummer (100000), versionsnummer - 2, TCP-port 111 och UDP-port 111. Ovan, när jag specificerade sammansättningen av NFS-serverdemonerna, angav jag de viktigaste RPC-programnumren. Jag har förmodligen förvirrat dig lite med det här stycket, så jag säger huvudfrasen, som borde förtydliga: portmapparens huvudfunktion är att återvända till honom (klienten) porten som det begärda programmet körs på. Följaktligen, om en klient behöver åtkomst till RPC med ett specifikt programnummer, måste den först kontakta portmapprocessen på servermaskinen och fastställa portnumret för att kommunicera med den RPC-tjänst den behöver.

Driften av en RPC-server kan representeras av följande steg:

1. Portomvandlaren måste startas först, vanligtvis vid systemstart. Detta skapar en TCP-ändpunkt och öppnar TCP-port 111. Det skapar också en UDP-slutpunkt som väntar på att ett UDP-datagram ska anlända till UDP-port 111.
2. Vid start skapar ett program som körs genom en RPC-server en TCP-slutpunkt och en UDP-slutpunkt för varje version av programmet som stöds. (En RPC-server kan stödja flera versioner. Klienten anger vilken version som krävs vid ett RPC-anrop.) Ett dynamiskt tilldelat portnummer tilldelas varje version av tjänsten. Servern registrerar varje program, version, protokoll och portnummer genom att göra rätt RPC-anrop.
3. När RPC-klientprogrammet behöver den information det behöver anropar det en portmappningsrutin för att erhålla ett dynamiskt tilldelat portnummer för ett givet program, version och protokoll.
4. Som svar på denna begäran returnerar norr portnumret.
5. Klienten skickar ett RPC-begäranmeddelande till portnumret som erhölls i steg 4. Om UDP används skickar klienten helt enkelt ett UDP-datagram som innehåller RPC-anropsmeddelandet till UDP-portnumret på vilket den begärda tjänsten körs. Som svar skickar tjänsten ett UDP-datagram som innehåller ett RPC-svarsmeddelande. Om TCP används gör klienten en aktiv öppning till TCP-portnumret för den begärda tjänsten och skickar sedan ett RPC-anropsmeddelande på upprättad anslutning... Servern svarar med ett RPC-svarsmeddelande över anslutningen.

För att få information från RPC-servern, använd verktyget rpcinfo... När du anger parametrar -p värd programmet listar alla registrerade RPC-program på värden. Utan att ange värden kommer programmet att visa tjänster på localhost. Exempel:

ARCHIV ~ # rpcinfo -p prog-ma version proto sporten 100 tusen två tcp 111 portmappern 100 tusen två udp 111 portmappern 100.024 1 udp 59451 status 100.024 ett tcp 60.872 status 100021 1 udp 44310 nlockmgr 100021 3 udp 44310 nlockmgr 100021 4 udp 44310 nlock 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 UD5 tcp 2049 nfs 1000030 1 mount 41405 mountd 100005 2 udp 51306 monterad 100005 2 tcp 41405 monterad 100005 3 utp 51306 monterad 100005 3 tcp 41405 monterad

Som du kan se visar rpcinfo (i kolumner från vänster till höger) det registrerade programnumret, versionen, protokollet, porten och namnet. Med hjälp av rpcinfo kan du ta bort registreringen av ett program eller få information om en separat tjänst RPC (fler alternativ i man rpcinfo). Som du kan se, är portmapper version 2-demoner registrerade på udp- och tcp-portar, rpc.statd version 1 på udp- och tcp-portar, NFS lock manager version 1,3,4, nfs server daemon 2,3,4, samt mount daemon versioner 1,2,3.

NFS-servern (närmare bestämt rpc.nfsd-demonen) tar emot förfrågningar från klienten i form av UDP-datagram på port 2049. Även om NFS arbetar med en portmappare, som tillåter servern att använda dynamiskt tilldelade portar, är UDP-port 2049 hårdkodad till NFS i de flesta implementeringar ...

Network File System Protocol Operation

Montera fjärrstyrd NFS

Processen att montera ett fjärranslutet NFS-filsystem kan representeras av följande diagram:

Beskrivning av NFS-protokollet vid montering av en fjärrkatalog:

1. En RPC-server startas på servern och klienten (vanligtvis vid uppstart), betjänas av portmapper-processen och registreras på tcp / 111- och udp / 111-portarna.
2. Tjänster startas (rpc.nfsd, rpc.statd, etc.), som registreras på RPC-servern och registreras på godtycklig nätverksportar(om en statisk port inte anges i tjänstinställningarna).
3. monteringskommandot på klientdatorn skickar en begäran till kärnan att montera en nätverkskatalog med en indikation på filsystemstyp, värd och katalog själv, kärnan skickar en RPC-begäran till portmap-processen på NFS-servern på udp / 111-port (om klienten inte har möjlighet att arbeta via tcp)
4. NFS-serverkärnan kontrollerar RPC:n för närvaron av demonen rpc.mountd och returnerar den till klientkärnan nätverksport att demonen körs på.
5. mount skickar en RPC-begäran till porten som rpc.mountd körs på. Nu kan NFS-servern validera klienten baserat på dess IP-adress och portnummer för att se om klienten kan montera det angivna filsystemet.
6. Mount-demonen returnerar en beskrivning av det begärda filsystemet.
7. Klientmonteringskommandot utfärdar monteringssystemanropet för att binda filbeskrivningen som erhölls i steg 5 till den lokala monteringspunkten på klientvärden. Filbeskrivningen lagras i NFS-klientkoden, och från och med denna tidpunkt kommer all åtkomst av användarprocesser till filer på serverns filsystem att använda filbeskrivningen som utgångspunkt.

Kommunikation mellan klient och NFS-server

Typisk åtkomst till ett fjärrfilsystem kan beskrivas på följande sätt:

Beskrivning av processen för att komma åt en fil som finns på NFS-servern:

1. Klienten (användarprocessen) bryr sig inte om den får tillgång till en lokal fil eller en NFS-fil. Kärnan hanterar interaktionen med hårdvaran genom kärnmoduler eller inbyggda systemanrop.
2. Kärnmodul kärna / fs / nfs / nfs.ko, som fungerar som en NFS-klient och skickar RPC-förfrågningar till NFS-servern via TCP/IP-modulen. NFS använder vanligtvis UDP, men nyare implementeringar kan använda TCP.
3. NFS-servern tar emot förfrågningar från klienten som UDP-datagram på port 2049. Även om NFS kan arbeta med en portmappare, som tillåter servern att använda dynamiskt tilldelade portar, är UDP-port 2049 hårdkodad till NFS i de flesta implementeringar.
4. När NFS-servern tar emot en begäran från en klient skickas den till den lokala filåtkomstrutinen, som ger åtkomst till den lokala disken på servern.
5. Resultatet av diskåtkomsten returneras till klienten.

Konfigurera en NFS-server

Serverjustering består i allmänhet av att specificera de lokala kataloger som tillåts monteras av fjärrsystem i en fil / etc / exporter... Denna åtgärd kallas exportkataloghierarki... De huvudsakliga informationskällorna om exporterade kataloger är följande filer:

• / etc / exporter- huvudkonfigurationsfilen som lagrar konfigurationen av de exporterade katalogerna. Används när du startar NFS och exportfs-verktyget.
• / var / lib / nfs / xtab- innehåller en lista över kataloger monterade av fjärrklienter. Används av rpc.mountd-demonen när en klient försöker montera en hierarki (en monteringspost skapas).
• / var / lib / nfs / etab- en lista över kataloger som kan monteras av fjärrsystem, som anger alla parametrar för de exporterade katalogerna.
• / var / lib / nfs / rmtab- en lista över kataloger som inte exporteras för tillfället.
• / proc / fs / nfsd- ett speciellt filsystem (kärna 2.6) för hantering av NFS-servern.
  • export- en lista över aktiva exporterade hierarkier och klienter som de exporterades till, samt parametrar. Kärnan får denna information från / var / lib / nfs / xtab.
  • trådar- innehåller antalet trådar (kan även ändras)
  • med filehandle kan du få en filpekare
  • och så vidare...
• / proc / net / rpc- innehåller råstatistik som kan erhållas med hjälp av nfsstat, samt olika cacher.
• / var / run / portmap_mapping- information om registrerade i RPC-tjänster

Notera: i allmänhet finns det många tolkningar och formuleringar av syftet med xtab, etab, rmtab-filerna på Internet, jag vet inte vem jag ska tro. Även på http://nfs.sourceforge.net/, tolkningen är inte entydig.

Konfigurera filen / etc / exports

I det enklaste fallet är filen / etc / exports den enda filen som behöver redigeras för att konfigurera NFS-servern. Den här filen hanterar följande aspekter:

• Vilka kunder kan komma åt filer på servern
• Vilka hierarkier kataloger på servern kan nås av varje klient
• Hur anpassade kundnamn blir visas till lokala användarnamn

Varje rad i exportfilen har följande format:

export_point klient1 (alternativ) [klient2 (alternativ) ...]

Var export_point den absoluta sökvägen till den exporterade kataloghierarkin, klient1 - n namnet på en eller flera klienter eller IP-adresser, separerade med mellanslag, som får monteras export_point . alternativ beskriv monteringsreglerna för klient specificerat tidigare alternativ .

Här är en typisk exempel på exportfilkonfiguration:

ARCHIV ~ # cat / etc / exports / archiv1 files (rw, sync) 10.0.0.1 (ro, sync) 10.0.230.1/24(ro,sync)

V detta exempel filer och 10.0.0.1-datorer tillåts åtkomst till exportpunkten/arkiv1, medan filvärden läser/skrivs, och 10.0.0.1-värden och 10.0.230.1/24-undernätet är skrivskyddade.

Värdbeskrivningar i / etc / exporter är tillåtna i följande format:

• Namnen på enskilda noder beskrivs som filer eller files.DOMAIN.local.
• Domänmasker beskrivs i följande format: * DOMAIN.local inkluderar alla noder i DOMAIN.local-domänen.
• Subnät anges som IP-adress/maskpar. Till exempel: 10.0.0.0/255.255.255.0 inkluderar alla noder vars adresser börjar med 10.0.0.
• Ställa in namnet på nätverksgruppen @myclients som har åtkomst till resursen (när du använder en NIS-server)

Allmänna exportalternativ för kataloghierarkier

Exportfilen använder följande allmänna alternativ(alternativ som används som standard i de flesta system anges först, inom parentes - inte som standard):

• auth_nlm (no_auth_nlm) eller säkra_lås (osäkert_lås)- anger att servern ska kräva autentisering av låsförfrågningar (med NFS Lock Manager-protokoll).
• nohide (gömma)- om servern exporterar två kataloghierarkier, med en kapslad (monterad) i den andra. Klienten måste explicit montera den andra (underordna) hierarkin, annars kommer monteringspunkten för den underordnade hierarkin att visas som en tom katalog. Alternativet nohide resulterar i en andra kataloghierarki utan en explicit montering. ( notera: Jag kunde inte få det här alternativet att fungera ...)
• ro (rw)- Tillåter endast läs (skriv) förfrågningar. (I slutändan bestäms huruvida det är möjligt att läsa/skriva eller inte baserat på filsystemets behörigheter, medan servern inte kan skilja en filläsbegäran från en exekveringsbegäran, så den tillåter läsning om användaren har läs- eller exekveringsbehörigheter .)
• säker (osäker)- kräver att NFS-förfrågningar kommer från säkra portar (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (ingen_subtree_check)- Om en underkatalog till filsystemet exporteras, men inte hela filsystemet, kontrollerar servern om den begärda filen finns i den exporterade underkatalogen. Att inaktivera verifiering minskar säkerheten, men ökar dataöverföringshastigheten.
• synkronisera (asynkron)- indikerar att servern endast ska svara på förfrågningar efter att ändringarna som gjorts av dessa förfrågningar har skrivits till disken. Asynkroniseringsalternativet säger åt servern att inte vänta på att information skrivs till disken, vilket förbättrar prestandan, men minskar tillförlitligheten, eftersom förlust av information är möjlig i händelse av en frånkopplad anslutning eller utrustningsfel.
• wdelay (ingen_wdelay)- Sätter åt servern att fördröja exekvering av skrivbegäranden om en efterföljande skrivbegäran väntar, vilket skriver data i större block. Detta förbättrar prestandan när du skickar stora skrivköer. no_wdelay indikerar att inte skjuta upp exekveringen av kommandot för skrivning, vilket kan vara användbart om servern tar emot ett stort antal kommandon som inte är relaterade till varandra.

Export av symboliska länkar och enhetsfiler. När du exporterar en kataloghierarki som innehåller symboliska länkar måste länkobjektet vara tillgängligt för klientsystemet (fjärrsystemet), det vill säga en av följande regler måste uppfyllas:

Enhetsfilen hänvisar till gränssnittet. När du exporterar en enhetsfil exporteras detta gränssnitt. Om klientsystemet inte har en enhet av samma typ kommer den exporterade enheten inte att fungera. På klientsystemet, när du monterar NFS-objekt, kan du använda alternativet nodev så att enhetsfiler i de monterade katalogerna inte används.

Standardalternativen kan variera från system till system, de kan ses i filen / var / lib / nfs / etab. Efter att ha beskrivit den exporterade katalogen i / etc / exports och startat om NFS-servern, kommer alla saknade alternativ (läs: standardalternativ) att återspeglas i filen / var / lib / nfs / etab.

Alternativ för visning av användar-ID (matchning).

För en bättre förståelse av följande, skulle jag råda dig att läsa artikeln. Varje Linux-användare har sitt eget UID och huvud-GID, som beskrivs i filerna / etc / passwd och / etc / grupp... NFS-servern antar att fjärrvärdens operativsystem har autentiserat användarna och tilldelat dem rätt UID och GID. Att exportera filerna ger användare på klientsystemet samma tillgång till dessa filer som om de loggar in direkt på servern. Följaktligen, när en NFS-klient skickar en begäran till en server, använder servern UID och GID för att identifiera användaren på det lokala systemet, vilket kan leda till vissa problem:

• användaren kanske inte har samma identifierare i båda systemen och kan följaktligen komma åt en annan användares filer.
• eftersom rotanvändaren har en identifierare på alltid 0, sedan mappas denna användare till lokal användare beroende på de angivna alternativen.

Följande alternativ definierar reglerna för att mappa fjärranvändare till lokala:

• root_squash (ingen_root_squash)- Med det givna alternativet root_squash, förfrågningar från rotanvändaren mappas till den anonyma uid / gid, eller till användaren som anges i parametern anonuid / anongid.
• no_all_squash (alla_squash)- Ändrar inte UID / GID för den anslutande användaren. Alternativ all_squash ställer in ALLA användare (inte bara root) för att visas som anonyma eller specificerade i parametern anonuid / anongid.
• anonuid = UID och anongid = GID - Anger uttryckligen UID / GID för den anonyma användaren.
• map_static = / etc / file_maps_users - Anger en fil där du kan ställa in mappning av fjärr-UID / GID - lokal UID / GID.

Ett exempel på hur man använder en användarmappningsfil:

ARCHIV ~ # cat / etc / file_maps_users # Mappning av användare # lokal fjärrkommentar uid 0-50 1002 # mappar användare till fjärr-UID 0-50 till lokal UID 1002 gid 0-50 1002 # mappar användare till / spänner över fjärr-GID 0-50 k lokal GID 1002

NFS-serverhantering

NFS-servern hanteras med hjälp av följande verktyg:

• nfsstat
• showmsecure (osäker) ount

nfsstat: NFS- och RPC-statistik

Verktyget nfsstat låter dig se statistik för RPC- och NFS-servrar. Kommandoalternativ kan ses i man nfsstat.

showmount: visa NFS-statusinformation

Showmount verktyg frågar rpc.mountd-demonen för fjärrvärd om monterade filsystem. Som standard returneras en sorterad lista med klienter. Nycklar:

• --Allt- en lista över klienter och monteringspunkter visas, som anger var klienten monterade katalogen. Denna information kanske inte är tillförlitlig.
• --kataloger- en lista över monteringspunkter ges
• --export- ger en lista över exporterade filsystem från nfsd-synpunkt

Om du kör showmount utan argument kommer konsolen att visa information om de system som är tillåtna att montera lokal kataloger. Till exempel ger ARCHIV-värden oss en lista över exporterade kataloger med IP-adresserna för de värdar som får montera de angivna katalogerna:

FILER ~ # showmount --exports archiv Exportlista för arkiv: / archiv-big 10.0.0.2 / archiv-small 10.0.0.2

Om du anger värdnamn / IP i argumentet kommer information om denna värd att visas:

ARCHIV ~ # showmount-filer clnt_create: RPC: Program inte registrerat # detta meddelande talar om för oss att NFSd-demonen inte körs på FILES-värden

exportfs: hantera exporterade kataloger

Detta kommando tjänar de exporterade katalogerna som anges i filen / etc / exporter, blir det mer exakt att skriva tjänar inte, men synkroniserar med filen / var / lib / nfs / xtab och tar bort obefintliga från xtab. exportfs exekveras när nfsd-demonen startas med argumentet -r. Verktyget exportfs i 2.6 kärnläge kommunicerar med rpc.mountd-demonen genom filerna i katalogen / var / lib / nfs / och kommunicerar inte direkt med kärnan. Utan parametrar, listar de för närvarande exporterade filsystemen.

Exportfs alternativ:

• [klient: katalognamn] - lägg till eller ta bort det angivna filsystemet för den angivna klienten)
• -v - visa mer information
• -r - återexportera alla kataloger (synk / etc / exports och / var / lib / nfs / xtab)
• -u - ta bort från listan över exporterade
• -a - lägg till eller ta bort alla filsystem
• -o - alternativ separerade med kommatecken (liknande alternativen som används i / etc / exporter; så att du kan ändra alternativ för redan monterade filsystem)
• -i - använd inte / etc / exporter när du lägger till, bara parametrar för den aktuella kommandoraden
• -f - återställ listan över exporterade system i 2.6-kärnan;

NFS-klient

Innan du kommer åt en fil på fjärrfilsystemet måste klienten (klient-OS). montera den och hämta från servern pekare till det. Montering av NFS kan göras med eller med hjälp av någon av de produktiva automatiska montörerna (amd, autofs, automount, supermount, superpupermount). Monteringsprocessen är väl demonstrerad i illustrationen ovan.

På NFS-klienter inga demoner behöver startas, klientfunktioner kör kärnmodulen kärna / fs / nfs / nfs.ko som används vid montering av ett fjärrfilsystem. Exporterade kataloger från servern kan monteras på klienten på följande sätt:

• manuellt med monteringskommandot
• automatiskt vid uppstart, vid montering av filsystem som beskrivs i / etc / fstab
• automatiskt med autofs-demonen

Jag kommer inte att överväga den tredje metoden med autofs i den här artikeln, på grund av dess omfattande information. Kanske kommer det att finnas en separat beskrivning i följande artiklar.

Montera nätverksfilsystemet med kommandot mount

Ett exempel på hur man använder mount-kommandot presenteras i inlägget. Här är ett exempel på ett monteringskommando för att montera ett NFS-filsystem:

FILER ~ # mount -t nfs archiv: / archiv-small / archivs / archiv-small FILES ~ # mount -t nfs -o ro archiv: / archiv-big / archivs / archiv-big FILES ~ # mount ..... .. archiv: / archiv-small on / archivs / archiv-small type nfs (rw, addr = 10.0.0.6) archiv: / archiv-big on / archivs / archiv-big type nfs (ro, addr = 10.0.0.6)

Det första kommandot monterar den exporterade katalogen / arkiv-liten på servern arkiv till lokal monteringspunkt / arkiv / arkiv-liten med standardalternativ (dvs läs och skriv). Fastän mount kommando i de senaste distributionerna vet den hur man förstår vilken typ av filsystem som används utan att ange typen, ange fortfarande parametern -t nfsönskvärd. Det andra kommandot monterar den exporterade katalogen / arkiv-stor på servern arkiv till den lokala katalogen / arkiv / arkiv-big med skrivskyddat alternativ ( ro). Montera kommando utan parametrar visar den tydligt monteringsresultatet för oss. Förutom alternativet skrivskyddat (ro) är det möjligt att ange andra grundläggande alternativ vid montering av NFS:

• nosuid- Det här alternativet förbjuder körning av program från den monterade katalogen.
• nodev(ingen enhet - inte en enhet) - Det här alternativet förbjuder användning av tecken och blockerar specialfiler som enheter.
• lås (nolock)- Tillåter NFS-låsning (standard). nolock inaktiverar NFS-låsning (startar inte lockd-demonen) och är användbart för äldre servrar som inte stöder NFS-låsning.
• mounthost = namn- Värdnamnet som NFS-monteringsdemonen körs på - mountd.
• monteringsport = n - Porten som används av mountd-demonen.
• port = n- port som används för att ansluta till NFS-servern (som standard 2049 om rpc.nfsd-demonen inte är registrerad på RPC-servern). Om n = 0 (standard) kommer NFS att fråga efter portkartan på servern för att fastställa porten.
• rsize = n(läs blockstorlek) - Antalet byte som läses på en gång från NFS-servern. Standard - 4096.
• wsize = n(skrivblockstorlek) - Antalet byte som skrivits på en gång till NFS-servern. Standard - 4096.
• tcp eller utp- För att montera NFS använd TCP-protokoll eller UDP, respektive.
• bg- Om du förlorar åtkomsten till servern, försök igen i bakgrunden för att inte blockera systemstartprocessen.
• fg- Om du förlorar åtkomst till servern, försök igen i prioritetsläge. Denna parameter kan blockera uppstartsprocessen genom att upprepa monteringsförsök. Av denna anledning används parametern fg främst för felsökningsändamål.

Alternativ som påverkar attributcaching när NFS monteras

Filattribut lagras i (inoder), såsom ändringstid, storlek, hårda länkar, ägare, ändras vanligtvis sällan för vanliga filer och ännu mer sällan för kataloger. Många program, som ls, har åtkomst till filer skrivskyddade och ändrar inte filattribut eller innehåll, utan slösar bort systemresurser på dyra nätverksoperationer. För att undvika onödigt slöseri med resurser kan du cache givna attribut... Kärnan använder ändringstiden för en fil för att avgöra om cachen är inaktuell genom att jämföra ändringstiden i cachen med ändringstiden för själva filen. Attributcachen uppdateras regelbundet enligt de angivna parametrarna:

• ac (noac) (attributcache- attributcaching) - Aktiverar attributcaching (standard). Även om noac-alternativet saktar ner servern, undviker det att attributet löper ut när flera klienter aktivt skriver information till den delade hierarkin.
• acdirmax = n (attribut cache katalogfil maximum- maximal attributcache för en katalogfil) - Det maximala antalet sekunder som NFS väntar innan katalogattribut uppdateras (standard 60 sekunder)
• acdirmin = n (attribut cache katalogfil minimum- attributcache åtminstone för en katalogfil) - Det minsta antal sekunder som NFS väntar innan katalogattribut uppdateras (som standard 30 sekunder)
• acregmax = n (attribut cache normal fil maximum- attributcache som mest för vanlig fil) - Det maximala antalet sekunder som NFS kommer att vänta innan attributen för en vanlig fil uppdateras (standard 60 sekunder)
• acregmin = n (attribut cache normal fil minimum- attributcache åtminstone för en vanlig fil) - Det minsta antalet sekunder som NFS väntar innan attributen för en vanlig fil uppdateras (3 sekunder som standard)
• acttimeo = n (attribut cache timeout- tidsgräns för attributcaching) - Åsidosätter värdena för alla ovanstående alternativ. Om acttimeo inte är specificerat, är ovanstående värden satta till sina standardvärden.

NFS-felhanteringsalternativ

Följande alternativ styr hur NFS beter sig när det inte finns något svar från servern eller när I/O-fel uppstår:

• fg (bg) (förgrund - förgrund, bakgrund- bakgrund) - Försök att montera en misslyckad NFS i förgrunden/bakgrunden.
• hård mjuk)- visar meddelandet "servern svarar inte" för konsolen när timeout nås och fortsätter monteringsförsöken. Med det givna alternativet mjuk- om timeout inträffar, informerar programmet som anropade operationen om ett I/O-fel. (det mjuka alternativet rekommenderas att inte använda)
• nointr (intr) (inget avbrott- avbryt inte) - Förhindrar signaler från att avbryta filoperationer i den hårdmonterade kataloghierarkin när en lång timeout nås. intr- möjliggör avbrott.
• retrans = n (återsändningsvärde- återsändningsvärde) - Efter n små timeout genererar NFS en stor timeout (3 som standard). En lång timeout stoppar driften eller visar meddelandet "servern svarar inte" till konsolen, beroende på det hårda/mjuka alternativet som anges.
• försök igen = n (försök igen värde- Försök igen värde) - Antalet minuter som NFS-tjänsten försöker montera på nytt innan du ger upp (10 000 som standard).
• timeo = n (timeoutvärde- timeout-värde) - Antalet tiondelar av en sekund som NFS-tjänsten väntar innan återsändning i händelse av RPC eller låg timeout (standard 7). Detta värde ökar med varje timeout, upp till maximalt 60 sekunder, eller tills en lång timeout inträffar. På ett upptaget nätverk, en långsam server, eller när en begäran passerar genom flera routrar eller gateways, kan en ökning av detta värde förbättra prestandan.

Automatisk NFS-montering vid uppstart (beskrivning av filsystem i / etc / fstab)

Hitta den optimala tiden för ett visst värde det överförda paketet (rsize / wsize-värden), med hjälp av ping-kommandot:

FILER ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768 (32796) databyte. 32776 byte från archiv.domain.local (10.0.0.6): icmp_req = 1 ttl = 64 tid = 0,931 ms 32776 byte från archiv.domain.local (10.0.0.6): icmp_req = 69 ttl = 2 5 ttl = 2 5 ttl 7 x 7 ms . från archiv.domain.local (10.0.0.6): icmp_req = 3 ttl = 64 tid = 1,03 ms 32776 byte från archiv.domain.local (10.0.0.6): icmp_req = 4 ttl = 64 ms med 1,070 ms = 3270 ms = 1,070 ms .domain.local (10.0.0.6): icmp_req = 5 ttl = 64 tid = 1,08 ms ^ C --- archiv.DOMAIN.local ping-statistik --- 5 paket överförda, 5 mottagna, 0% paketförlust, tid 4006ms rtt min / avg / max / mdev = 0,931 / 1,002 / 1,083 / 0,061 ms

Som du kan se, när du skickar ett paket med storleken 32768 (32Kb) flyter dess restid från klienten till servern och tillbaka i området 1 millisekund. Om den givna tiden kommer att gå ur skalan om 200 ms, då bör du tänka på att öka timeo-värdet så att det överstiger utbytesvärdet med tre till fyra gånger. Följaktligen är det tillrådligt att göra detta test under en stark nätverksbelastning.

Starta NFS och konfigurera brandväggen

Anteckningen är kopierad från bloggen http://bog.pp.ru/work/NFS.html, för vilket stort tack till honom !!!

Starta NFS-server, montera, lås, kvot och status med "rätt" portar (för brandvägg)

• det är tillrådligt att först avmontera alla resurser på klienter
• stoppa och tillåt inte rpcidmapd att starta om du inte planerar att använda NFSv4: chkconfig --nivå 345 rpcidmapd av tjänsten rpcidmapd stop
• vid behov, aktivera starten av portmap-, nfs- och nfslock-tjänsterna: chkconfig --levels 345 portmap / rpcbind på chkconfig --levels 345 nfs på chkconfig --levels 345 nfslock på
• vid behov, stoppa nfslock och nfs tjänster, starta portmap / rpcbind, ladda ur moduler tjänst nfslock stopp tjänst nfs stopp tjänst portmap start # tjänst rpcbind starta umount / proc / fs / nfsd tjänst rpcidmapd stopp rmmod nfsd tjänst autofs måste stoppa # någonstans senare kör rmmod nfs rmmod nfs_acl rmmod lockd
• öppna portar i
  • för RPC: UDP / 111, TCP / 111
  • för NFS: UDP / 2049, TCP / 2049
  • för rpc.statd: UDP / 4000, TCP / 4000
  • för låst: UDP / 4001, TCP / 4001
  • för monterad: UDP / 4002, TCP / 4002
  • för rpc.rquota: UDP / 4003, TCP / 4003
• för rpc.nfsd-servern lägg till raden RPCNFSDARGS = "- port 2049" till / etc / sysconfig / nfs
• för monteringsservern lägg till raden MOUNTD_PORT = 4002 till / etc / sysconfig / nfs
• för att konfigurera rpc.rquota för nya versioner, lägg till raden RQUOTAD_PORT = 4003 till / etc / sysconfig / nfs
• för att konfigurera rpc.rquota är det nödvändigt för äldre versioner (likväl måste du ha paketet quota 3.08 eller nyare) lägg till rquotad 4003 / tcp rquotad 4003 / udp till / etc / services
• kommer att kontrollera lämpligheten av / etc / exporter
• starta tjänsterna rpc.nfsd, mountd och rpc.rquota (samtidigt som rpcsvcgssd och rpc.idmapd startas, om du inte har glömt att ta bort dem) service nfsd start eller i nya versioner service nfs start
• för låsservern för nya system lägg till raderna LOCKD_TCPPORT = 4001 LOCKD_UDPPORT = 4001 till / etc / sysconfig / nfs
• för en låsserver för äldre system lägg till direkt i /etc/modprobe [.conf]: options lockd nlm_udpport = 4001 nlm_tcpport = 4001
• binda statusservern rpc.statd till port 4000 (för gamla system i /etc/init.d/nfslock kör rpc.statd med -p 4000-växeln) STATD_PORT = 4000
• start tjänster lockd och rpc.statd service nfslock start
• se till att alla portar är ordentligt bundna med "lsof -i -n -P" och "netstat -a -n" (några av portarna används av kärnmoduler som lsof inte ser)
• om servern användes av klienter innan du "ombyggde" och de inte kunde avmonteras, måste du starta om de automatiska monteringstjänsterna på klienterna (am-utils, autofs)

Exempel på NFS-server- och klientkonfiguration

Serverkonfiguration

Om du vill göra din NFS-partitionerade katalog öppen och skrivbar kan du använda alternativet all_squash i kombination med tillval anonuid och anongid... Till exempel, för att ställa in rättigheterna för användaren "ingen" i gruppen "ingen", kan du göra följande:

ARCHIV ~ # cat / etc / exports # Läs-/skrivåtkomst för klient på 192.168.0.100, med rw-åtkomst för användare 99 med gid 99 / filer 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid = 99) ) # Läs-/skrivåtkomst för klient på 192.168.0.100, med rw-åtkomst för användare 99 med gid 99 / filer 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid = 99))

Detta betyder också att om du vill tillåta åtkomst till den angivna katalogen, måste nobody.nobody vara ägare till den delade katalogen:

man montera
man exporterar
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - NFS-prestanda från IBM.

Hälsningar, Mc.Sim!

Nätverksfilsystem

En av de mest användbara funktioner som kan implementeras med ett nätverk är delning av filer genom ett nätverksfilsystem. Vanligtvis används ett system som kallas Network File System eller NFS, som är utvecklat av Sun Corporation.

När du arbetar med ett nätverksfilsystem överförs alla operationer på filer som utförs på den lokala datorn över nätverket till fjärrmaskin... När nätverksfilsystemet körs antar programmet att alla filer på fjärrdatorn finns på datorn där det körs. Separeringen av information genom ett sådant system kräver alltså inga ändringar av programmet.

post

E-post är det viktigaste kommunikationsmedlet mellan datorer. E-postmeddelanden lagras i en enda fil i ett speciellt format. Specialprogram används för att läsa och skicka brev.

Varje användare har en separat brevlåda, en fil där information lagras i ett speciellt format där inkommande post lagras. Om ett brev kommer till datorn, hittar postbearbetningsprogrammet postlådefilen för motsvarande användare och lägger till det mottagna brevet där. Om användarens brevlåda finns på en annan dator, omdirigeras brevet till denna dator, där det behandlas vidare.

Postsystem består av många olika program... Postleverans till lokala eller fjärranslutna brevlådor görs av ett program (till exempel sendmail eller smail), medan ett stort antal olika program (till exempel Pine eller alm) används för att skicka eller visa post normalt. Maillådefiler lagras vanligtvis i katalogen /. var / spool / mail.

Frågor

1. Vad är NOS och vad är dess syfte?

2. Vilka funktioner i nätverket utför nätverksoperativsystemet?

3. Vilka är delarna av NOS-strukturen?

4. Vad är en omdirigering?

5. Hur är nätverksoperativsystem indelade efter åtkomsträttigheter till resurser?

6. Hur är nätverksoperativsystem indelade efter nätverksskala?

7. Hur beror egenskaperna hos ett nätverksoperativsystem på nätverkens skala?

8. Beskriv nätverksoperativsystemet NetWare från Novell.

9. Vilka är delarna av strukturen för NetWare-nätverksoperativsystemet?

10. Beskriv filsystemet för nätverksoperativsystemet NetWare.

11. Vilka protokollnivåer stöder NetWare-nätverksoperativsystemet?

12. Lista funktionerna för IPX, SPX-protokollen.

13. Beskriv nätverksoperationsrummet Windows-system NT.

14. Lista uppgifterna för nätverksoperativsystemet Windows NT.

15. Vilka är delarna av strukturen för nätverksoperativsystemet Windows NT?

16. Ange egenskaperna för filsystemet för nätverksoperativsystemet Windows NT.

17. Vilka säkerhetsprinciper används i nätverksoperativsystemet Windows NT?

18. Lista funktionerna i nätverksoperativsystemet Windows NT med tanke på genomförandet av nätverksfaciliteter.

19. Namnge egenskaperna för nätverksoperativsystemet Windows NT.

20. Vilka områden finns använder windows NT?

21. Ange egenskaperna hos nätverksoperativsystemet UNIX.

22. Lista funktionerna i UNIX-nätverksoperativsystemet.

23. Ange egenskaperna för filsystemet för nätverks OS UNIX.

24. Vilka säkerhetsprinciper används av UNIX?

25. Ge en översikt över Linux-nätverksoperativsystemet.

Nätverkstjänster

Föreläsning 10

En uppsättning server- och klientdelar av operativsystemet som ger åtkomst till specifik typ en datorresurs över ett nätverk kallas nätverkstjänst . Kunddel hanterar nätverksförfrågningar till serversidan på en annan dator. Server del tillfredsställer förfrågningar till lokala serverresurser. Klientsidan är aktiv, serversidan är passiv.

Under nätverksinteraktion upptas en betydande plats av åtkomst till filsystemet via nätverket. I det här fallet bildas klient- och serverdelarna tillsammans med nätverkets filsystem filtjänst

En nyckelkomponent i ett distribuerat operativsystem är nätverkets filsystem. Nätverksfilsystem stöds av en eller flera datorer som lagrar filer (filservrar)

Klient datorer ansluter eller monterar dessa filsystem till sina lokala filsystem

Filtjänst inkluderar serverprogram och klientprogram som kommunicerar över nätverket med hjälp av ett protokoll.

Filtjänster inkluderar den faktiska filtjänsten (filoperationer) och katalogtjänsten (kataloghantering)

Nätverksfiltjänstmodellen innehåller följande element:

Lokalt filsystem (FAT, NTFS)

Lokalt filsystemsgränssnitt (systemanrop)

Nätverksfilsystemserver

Nätverksfilsystemklient (Windows Explorer, UNIX-skal, etc.)

Nätverksfilsystemgränssnitt (upprepar systemanrop till det lokala filsystemet)

Network File System Client-Server Protocol (SMB-Server Message Block för Windows, NFS (Network File System) och FTP ( Filöverföring protokoll) för UNIX)

Nätverksfilsystemgränssnitt

Det finns flera typer av gränssnitt, som kännetecknas av:

Filstruktur... De flesta nätverksfilsystem stöder platta filer

Filens modifierbarhet... De flesta nätverksanslutna filsystem har möjlighet att modifiera filen. Vissa distribuerade filsystem förbjuder modifieringsoperationer. Endast skapa och läsa är möjliga. För sådana filer är det lättare att organisera cachelagring och replikering.

Fildelningssemantik:

Semantik UNIX (centraliserat). Om läsningen följer flera skrivoperationer läses den senaste uppdateringen. Denna princip är också möjlig i ett distribuerat filsystem, förutsatt ett sådant fil server och bristen på filcachelagring på klienten.

Sessionssemantik.Ändringar börjar när filen öppnas och slutförs när filen stängs. Med andra ord, för andra processer är ändringarna synliga först efter att filen stängts. I det här fallet finns det ett problem med fildelning. Semantik för oföränderliga filer. Filen kan bara skapas och läsas. Du kan också återskapa filen med ett annat namn. Därför kan filen inte ändras, utan kan ersättas med en ny fil. Det finns inga delningsproblem.

Transaktionsmekanism. Det är ett sätt att arbeta med delade filer med hjälp av transaktionsmekanismen (odelbara operationer)

Åtkomstkontroll... Till exempel, för Windows NT / 2000 finns det två mekanismer: på katalognivå (för FAT) och på filnivå (NTFS)

Åtkomstenhet. Full filuppladdning/nedladdningsmodell (FTP). Den andra modellen är användningen av filoperationer.