На този моменттрябва да имате работеща TCP / IP връзка към вашата мрежа. Трябва да можете да пингвате други компютри в мрежата и ако сте конфигурирали съответно шлюза, трябва да можете да пингвате и компютри в Интернет. Както знаете, основната цел на свързването на компютър към мрежа е да получите достъп до информация. Докато някои хора могат да свържат компютър към мрежа просто по този начин, повечето хора биха искали да споделят и имат достъп до файлове и принтери. Те биха искали да имат достъп до документи в интернет или да играят онлайн игри. С TCP/IP поддръжка и софтуер, инсталиран на новата ви система Slackware, вие получавате всичко; обаче, като инсталирате само поддръжка на TCP / IP, функционалността ще бъде много ограничена. За да споделяме и споделяме файлове, трябва да ги прехвърляме напред и назад чрез FTP или SCP. Не можем да гледаме нашите нов компютърс файлово дърво на Slackware през My Network Places или икони Цяла мрежа от компютри с Windows. Бихме искали да можем да имаме постоянен достъп до файлове на други Unix машини.

В идеалния случай бихме искали да използваме мрежова файлова системакоето ни позволява да имаме прозрачен достъп до файловете на компютрите. Програмите, които използваме за работа с информация, съхранявана на компютрите, всъщност дори не трябва да знаят на кой компютър се съхранява файлът. Те трябва само да знаят, че файлът съществува и как да го получат. Останалото вече е задача на операционната система, осигуряваща достъп до този файл с помощта на наличните локални и мрежови файлови системи. Двете най-често използвани мрежови файлови системи са SMB (реализирана през Samba) и NFS.

5.6.1. SMB / Samba / CIFS

Server Message Block (SMB) е потомък на по-стария NetBIOS протокол, първоначално разработен от IBM за техния продукт LAN Manager. Microsoft, от своя страна, винаги се е интересувала от NetBIOS и неговите наследници (NetBEUI, SMB и CIFS). Проектът Samba започва през 1991 г., когато е написан да осигурява комуникация между IBM PC и Unix сървър. Днес осигуряване общ достъпза файлове и услуги за печат през SMB мрежата е предпочитаният метод за почти целия цивилизован свят, тъй като Windows също го поддържа.

Конфигурационният файл на Samba /etc/samba/smb.conf е един от най-добре документираните конфигурационни файлове, които можете да намерите. Има предварително изградени примери с настройки за споделени ресурси, така че можете да ги преглеждате и променяте според вашите нужди. Ако имате нужда от повече повече контрол, ръководството на smb.conf е на ваше разположение. Тъй като Samba има толкова добра документация, няма да я пренаписваме тук. Въпреки това, нека бързо да се спрем на основните точки.

smb.conf е разделен на няколко секции: една секция за споделяне, плюс една глобална секция за настройка на параметри, които се използват навсякъде. Някои параметри са валидни само в глобалната секция, а някои са валидни само извън нея. Не забравяйте, че глобалната секция може да бъде отменена от всяка друга секция. Пер Допълнителна информациявижте страниците на man.

Най-вероятно ще искате да редактирате вашия smb.conf файл, за да отразява вашите настройки. локална мрежа... Съветваме ви да промените изброените по-долу елементи:

Това ще бъде описанието на вашия Slackware компютър, показано в папката Моите мрежови места (или Всички мрежи).

Почти сигурно ще искате да използвате нивото на защита на потребителите във вашата система Slackware.

Ако криптирането на парола не е активирано, няма да можете да използвате Samba със системи NT4.0, Win2k, WinXP и Win2003. Предишните версии на операционните системи Windows не изискваха криптиране за осигуряване на достъп до споделени ресурси.

SMB е удостоверен протокол, т.е. можете да предоставите потребителско име и парола, за да се възползвате от тази услуга. Ние казваме на сървъра samba, че потребителските имена и пароли са правилни чрез командата smbpasswd. smbpasswd позволява споделени ключове да се използват за добавяне както на обикновени потребители, така и на потребители на машини (за SMB, трябва да добавите имена на NETBIOS машини като потребителски машини, като по този начин ограничавате от кои машини могат да бъдат удостоверени).

Важно е да се има предвид това собствено имепотребителско име или име на хост трябва вече да съществува във файла / etc / passwd. Можете да постигнете това с командата adduser. Имайте предвид, че когато използвате командата adduser, трябва да добавите знак за долар (“$”) към името на компютъра, за да го добавите. Това обаче нетрябва да се направи при работа с smbpasswd. Помощната програма smbpasswd добавя знак за долар самостоятелно. Нарушаването на това правило от adduser ще доведе до грешка при добавяне на името на хоста към samba.

5.6.2. Мрежова файлова система (NFS)

NFS (Мрежова файлова система) първоначално е написана от Sun за Solaris - техните реализации Unix системи... Въпреки че е много по-лесно за настройване и конфигуриране от SMB, NFS е много по-малко сигурен. Основната слабост на сигурността е, че е лесно да се заменят потребителски и групови идентификатори от една машина с идентификатори от друга машина. Удостоверяването не е внедрено в NFS протокола. Беше заявено, че в бъдещите версии NFS протоколсигурността ще бъде подобрена, но към момента на писане това все още не е направено.

NFS се конфигурира чрез файла / etc / за експортиране. Когато заредите стандартния файл / etc / за експортиране в редактор, ще видите празен файлс коментар в горните два реда. Ще трябва да добавим ред към файла за експортиране за всяка от директориите, които искаме да експортираме, като изброим клиентските работни станции, на които ще бъде разрешен достъп до тази директория. Например, ако искаме да експортираме директорията / home / foo за работната станция Bar, ще трябва да добавим този ред към нашия / etc / експортен файл:

Както можете да видите, има няколко различни опции, но повечето от тях трябва да са ясни от този пример.

NFS приема, че даден потребител на една от машините в мрежата има същата идентичност на всички други машини. Когато NFS клиент се опитва да чете или пише към NFS сървър, UID се предава като част от заявката за четене/запис. Този UID се счита за същия, както ако заявката е направена от локалната машина. Както можете да видите, ако някой може произволно да посочи даден UID при достъп до ресурси на отдалечена машина, проблеми могат да се случат и се случват. Част от начина да избегнете това е да монтирате всички директории с параметъра root_squash. Това отменя UID на всеки потребител, който твърди, че е root към различен UID, като по този начин предотвратява root да получи нов достъп до файлове и директории в експортираната директория. Изглежда, че root_squash е активиран по подразбиране от съображения за сигурност, но авторите все пак препоръчват да го посочите изрично във вашия / etc / файл за експортиране.

Можете също да експортирате директория на сървъра директно от командна линияизползвайки командата exportfs, както е показано по-долу:

Тази команда ще експортира директорията / home / foo за компютъра „Bar“ и ще му даде достъп за четене / запис. Освен това параметърът root_squash не е активиран на NFS сървъра, което означава, че всеки потребител на Bar с UID „0“ (UID root „a) ще има същите привилегии на сървъра като root. Синтаксисът изглежда доста странен (обикновено когато посочите директория като компютър: / директория / файл, вие препращате към файл в директория на даден компютър).

Можете да намерите повече информация за файла за експортиране в man страницата.

Файловата система NFS (мрежова файлова система) е създадена от Sun Microsystems. В момента това е стандартната мрежова файлова система за ОС. UNIX семействов допълнение, NFS клиенти и сървъри са внедрени за много други операционни системи. Принципите на неговата организация в момента са стандартизирани от интернет общността, последната версия на NFS v.4 е описана от RFC спецификацията ZOJ, издадена през декември 2000 г.

NFS е система, поддържаща схемата отдалечен достъпкъм файлове. Работата на потребителя с отдалечени файлове след операцията по монтиране става напълно прозрачна - поддървото на файловата система на NFS сървъра става поддърво на локалната файлова система.

Една от целите на разработчиците на NFS беше да поддържат хетерогенни системи с клиенти и сървъри, работещи с различни операционни системи на различни хардуерни платформи. Тази цел се подпомага от RFC-базираната реализация на NFS на Sun, която поддържа XDR по подразбиране за унифицирано представяне на аргументите на отдалечените процедури.

За да гарантира устойчивостта на клиента към грешки в сървъра, NFS е възприел подход без състояние, тоест при работа с файлове сървърите не съхраняват данни за файлове, отворени от клиенти.

Основната идея зад NFS е да позволи на произволна група потребители да споделят обща файлова система. Най-често всички потребители принадлежат към една и съща локална мрежа, но не е задължително. Можете също да стартирате NFS в WAN. Всеки NFS сървър предоставя една или повече от своите директории за отдалечен клиентски достъп. Директорията е обявена за достъпна с всички нейни поддиректории. Списъкът с директории, предавани от сървъра, се съдържа във файла / etc / за експортиране, така че тези директории се експортират автоматично веднага щом сървърът се стартира. Клиентите имат достъп до експортираните директории чрез монтиране. Много работни станции на Sun са бездискови, но дори и тогава е възможно да се монтира отдалечена файлова система към главната директория с цялата файлова система на сървъра. Изпълнението на програмите е почти независимо от това къде се намира файлът: локално или на отдалечен диск. Ако два или повече клиенти са монтирали една и съща директория по едно и също време, тогава те могат да комуникират чрез разделяне на файла.

Файловата система NFS използва два протокола в своята работа.

Първият NFS протокол контролира монтирането. Клиентът изпраща на сървъра пълното име на директория и иска разрешение да монтира тази директория някъде в собственото си дърво на директории. В този случай сървърът не е посочен къде ще бъде монтирана директорията на сървъра. След като получи името, сървърът потвърждава заявката и връща файлов дескриптор на клиента, който е отдалечената точка за монтиране. Дескрипторът включва дескриптор на типа файлова система, номер на диска, номер на inode на директорията, която е отдалечената точка на монтиране, и информация за сигурност. Четенето и записването на файлове от монтирани файлови системи използват файлови дескриптори вместо символно име.

Монтирането може да се извърши автоматично с помощта на пакетни файлове при стартиране. Има и друга опция за автоматично монтиране: когато ОС се стартира на работна станция, отдалечената файлова система не се монтира, но когато отдалеченият файл се отвори за първи път, ОС изпраща заявки до всеки сървър и след като открие този файл, монтира директорията на сървъра, на който се намира намереният файл.

Вторият NFS протокол се използва за достъп до отдалечени файлове и директории. Клиентите могат да изпращат заявка до сървъра за извършване на някакво действие в директорията или за четене или запис на файл. В допълнение, те могат да търсят атрибути на файла като тип, размер, време за създаване и модификация. NFS се поддържа от повечето системни повиквания на UNIX, с изключение на отваряне и затваряне. Изключенията за отваряне и затваряне не са случайни. Вместо да отваря отдалечен файл, клиентът изпраща съобщение до сървъра, съдържащо името на файла, като изисква търсене и връща файлов дескриптор. За разлика от отвореното повикване, повикването за търсене не копира никаква информация във вътрешните системни таблици. Извикването за четене съдържа файловия дескриптор за четене, отместването във файла, който се чете, и броя на байтовете за четене. Предимството на тази схема е, че сървърът не помни нищо за отворени файлове. По този начин, ако сървърът се срине и след това бъде възстановен, информацията за отворени файлове няма да бъде загубена, защото не се поддържа.

Ако сървърът не успее, клиентът просто продължава да изпраща команди за четене или запис във файлове, но без да получи отговор и след изчерпване на времето за изчакване, клиентът повтаря своите заявки. След рестартиране сървърът получава друга повторна заявка от клиента и отговаря на нея. По този начин сривът на сървъра причинява само известна пауза в обслужването на клиенти, но не допълнителни действияот клиентите не се изисква да възстановяват връзките и да отварят отново файлове.

За съжаление, NFS затруднява заключването на файлове. На много операционни системи файл може да бъде отворен и заключен, така че други процеси да нямат достъп до него. Когато файлът се затвори, ключалката се освобождава. В системи без състояние като NFS, блокирането не може да бъде свързано с отварянето на файл, тъй като сървърът не знае кой файл е отворен. Следователно, NFS изисква специални допълнителни средстваблокиращ контрол.

NFS използва кеширане от страна на клиента, данните се прехвърлят в кеша блок по блок и се използва предварително четене, при което блок, прочетен в кеша при поискване от приложение, винаги е последван от четене на следващия блок, иницииран от система. Методът за кеширане на NFS не запазва UNIX семантиката за разделяне на файлове. Вместо това се използва критично критикуваната семантика, при която промените в данните във файл, кеширан от клиент, са видими за друг клиент, в зависимост от времето. При следващото отваряне на файл в неговия кеш, клиентът проверява със сървъра кога файлът е бил последно променен. Ако това се случи, след като файлът е бил поставен в кеша, файлът се премахва от кеша и се получава ново копие на файла от сървъра. Клиентите разпространяват модификации, направени в кеша на всеки 30 секунди, така че сървърът може да получава актуализации с голямо закъснение. В резултат на механизмите за изчистване на данни от кеша и разпространение на модификации, получените от всеки клиент данни не винаги са най-новите.

Репликацията на NFS не се поддържа.

Услуга за справочник

Цел и принципи на организация

Подобно на голяма организация, голямата компютърна мрежа трябва централно да съхранява възможно най-много референтна информация за себе си. Решението на много проблеми в мрежата разчита на информация за мрежовите потребители - техните имена, използвани за логическо влизане, пароли, права за достъп до мрежови ресурси, както и ресурси и мрежови компоненти: сървъри, клиентски компютри, рутери, шлюзове, обеми на файлове системи, принтери и др.

Ето примери за най-важните задачи, изискващи централизирана база данни с референтна информация в мрежата:

• Една от най-често изпълняваните задачи в системата, базирана на референтна информация за потребителите, е тяхната автентификация, въз основа на която след това се извършва оторизация за достъп. Мрежата трябва по някакъв начин да се съхранява централно сметкипотребители, съдържащи имена и пароли.
• Наличието на някакъв вид централизирана база данни изисква поддържане на прозрачност на достъпа до много мрежови ресурси. Такава база данни трябва да съхранява имената на тези ресурси и съпоставянето на имена с цифрови идентификатори (например IP-адреси), което ви позволява да намерите този ресурс в мрежата. Прозрачността може да бъде осигурена за достъп до сървъри, томове на файловата система, интерфейси на RPC процедури, разпределени програмни обекти на приложения и много други мрежови ресурси.
• Имейлът е друг популярен пример за услуга, която желае уеб-базирано бюро за помощ, което съхранява данни за името на потребителската поща.
• V последните временаВ мрежите все по-често се използват инструменти за управление на качеството на услугата (QoS), които също изискват информация за всички потребители и приложения на системата, техните изисквания за качество на трафика на параметрите на услугата, както и за всички мрежови устройства, с които можете да управлявате трафика (рутери, комутатори, шлюзове и др.).
• Организацията на разпределените приложения може да бъде значително опростена, ако мрежата има база данни, която съхранява информация за наличните програмни модули-обекти и тяхното местоположение на мрежовите сървъри. Приложение, което трябва да извърши някакво стандартно действие, отправя заявка към такава база данни и получава адреса на програмен обект, който може да извърши необходимото действие.
• Системата за управление на мрежата трябва да има база за съхранение на информация за мрежовата топология и характеристики на всички мрежови елементикато рутери, комутатори, сървъри и клиентски компютри. Наличието на пълна информация за състава на мрежата и нейните връзки позволява системата автоматизиран контролмрежа, за да идентифицира правилно съобщенията за извънредни събития и да открие тяхната първопричина. Информация, сортирана по подразделения на предприятието за наличните мрежово оборудванеи установено софтуерполезно само по себе си, тъй като помага на администраторите да получат надеждна картина за състоянието на мрежата и да разработят планове за нейното развитие.

Такива примери могат да бъдат продължени, но не е трудно да се цитира контрааргумент, който поставя под съмнение необходимостта от използване на централизирана база данни с референтна информация в мрежата - дълго времемрежите работеха без единна референтна база данни и много мрежи все още работят без такава. Всъщност има много частни решения, които позволяват ефективно да се организира работата на мрежа, базирана на частни референтни бази данни, които могат да бъдат представени от обикновени текстови файлове или таблици, съхранявани в тялото на приложението. Например, UNIX традиционно използва файл passwd за съхраняване на потребителски имена и пароли, което обхваща само потребителите на един компютър. Можете също да съхранявате имената на получателите на имейл в локален файл на клиентския компютър. И толкова лично помощни системиработят добре - практиката потвърждава това.

Това възражение обаче е валидно само за малки и средни мрежи; в големите мрежи отделните локални референтни бази данни губят своята ефективност. DNS в Интернет е добър пример, който се оказва неприложим за локални решения за големи мрежи. След като размерът на Интернет надхвърли определена граница, стана неефективно да се съхранява информация за съответствието на имената и IP адресите на компютрите в мрежата в локални текстови файлове. Беше необходимо да се създаде разпределена база данни, поддържана от йерархично свързани сървъри за имена и централизирана услуга върху тази база данни, за да може разделянето на символни имена в Интернет да работи бързо и ефективно.

За голяма мрежа също е неефективно използването на голям брой помощни услуги с тясна цел: една за удостоверяване, друга за управление на мрежата, трета за разрешаване на имена на компютър и т.н. Дори ако всяка от тези услуги е добре организирана и комбинира централизиран интерфейс с разпределена база данни, голям бройУслугите на бюрото за помощ дублират големи количества информация и усложняват администрирането и управлението на мрежата. Например Windows NT има поне пет различни видовереферентни бази данни. Основната директория на домейна (NT Domain Directory Service) съхранява информация за потребителите, която е необходима при организиране на тяхното логическо влизане в мрежата. Данните за същите потребители могат да се съдържат в друга директория, използвана от електроника чрез пощата на Microsoftпоща. Още три бази данни поддържат разделителна способност на адресите: WINS съпоставя Netbios имена в IP адреси, DNS (Domain Name Server) директория е полезна при свързване на NT мрежа към Интернет и накрая, DHCP Directory се използва за автоматично присвояване на IP адреси на компютри в мрежата .... Очевидно такова разнообразие от услуги на бюрото за помощ усложнява живота на администратора и води до допълнителни грешкикогато идентификационните данни на един и същ потребител трябва да бъдат въведени в множество бази данни. Следователно в новото Версии на Windows 2000 повечето от системната помощна информация може да се съхранява услуга Активна Directory е единична централизирана услуга за директории, която използва разпределена база данни и е интегрирана с DNS.

Резултатът от разработването на системи за съхранение на референтна информация беше появата в мрежовите операционни системи на специална услуга - така наречените Directory Services, наричани още справочна услуга (директория). Услугата за справочник съхранява информация за всички потребители и мрежови ресурси под формата на унифицирани обекти с определени атрибути, а също така ви позволява да отразявате връзките между съхранените обекти, като принадлежност на потребителите към определена група, права за достъп на потребителите до компютри, влизане на няколко възли в една подмрежа, комуникационни връзкимежду подмрежи, производство на сървър и т. н. Услугата на директория ви позволява да извършвате някои основни операции върху съхранени обекти, като добавяне и премахване на обект, включително обект в друг обект, промяна на стойностите на атрибут на обект, четене на атрибути , и някои други. Обикновено различни специфични мрежови приложения се изграждат върху услугата на директории, които използват информацията на услугата за решаване конкретни задачи: управление на мрежата, удостоверяване на потребителя, прозрачност на услугите и други, изброени по-горе. Услугата на директории обикновено е изградена върху модел клиент-сървър: сървърите съхраняват база данни с референтна информация, която клиентите използват, като изпращат заявки до сървъри през мрежата. Изглежда, че е същото и за клиента на директорията. централизирана системавъпреки че повечето добри директорийни услуги имат разпределена структура, която включва голям брой сървъри, структурата е прозрачна за клиентите.

Важен въпросе организацията на референтната база данни. Единна база данни, която съхранява голям обем референтна информация, създава същите проблеми като всяка друга голяма база данни. Внедряването на help desk като локална база данни, съхранявана като едно копие на един от мрежовите сървъри, не е подходяща за голяма система по няколко причини, главно поради ниската производителност и ниската надеждност на подобно решение. Производителността ще бъде ниска поради факта, че заявките към базата данни от всички потребители и приложения в мрежата ще отидат до един сървър, който при голям брой заявки със сигурност ще престане да се справя с тяхната обработка. Тоест, такова решение не се мащабира добре по отношение на броя на обслужваните потребители и споделените ресурси. Надеждността също не може да бъде висока в система с едно копие на данните. В допълнение към премахването на ограниченията за производителност и надеждност, желателно е структурата на базата данни да позволява логическо групиране на ресурси и потребители по структурни подразделения на предприятието и определяне на администратор за всяка такава група.

Предизвикателствата за поддържане на производителност и надеждност с разрастването на мрежата обикновено се решават чрез разпределени референтни бази данни. Споделянето на данни между множество сървъри намалява натоварването на всеки сървър, като същевременно поддържа надеждност, като има множество реплики на всяка част от базата данни. За всяка част от базата данни можете да зададете собствен администратор, който има права на достъп само до обектите от своята част от информация за цялата система. За потребителя (и за мрежовите приложения) такава разпределена база данни изглежда е единна база данни, която осигурява достъп до всички мрежови ресурси, независимо от коя работна станция е дошла заявката.

Има два популярни стандарта за справочни услуги. Първо, това е стандартът X.500, разработен от ITU-T (по време на разработването на стандарта тази организация се нарича CCITT). Този стандарт определя функциите, организацията на бюрото за помощ и протокола за достъп до него. Създаден основно за използване с пощенската услуга X.400, стандартът X.500 ви позволява ефективно да организирате съхранението на всяка референтна информация и служи като добра основа за универсална услуга за справочници в мрежата.

Друг стандарт е Light-weight Directory Access Protocol (LDAP), разработен от интернет общността. Този стандарт дефинира опростен протокол за достъп до услугата на директории, тъй като услугите, изградени по стандарта X.500, се оказаха твърде тромави. LDAP стана широко разпространен и се превърна в де факто стандарт като клиентски протокол за достъп до ресурси на бюрото за помощ.

Има и няколко практически изпълненияуслуги на директории за мрежови операционни системи. Най-разпространена е услугата Novell NDS, разработена през 1993 г. за мрежовата операционна система NetWare 4.0, а днес е внедрена и за Windows NT/2000. Услугата на справочника представлява голям интерес Active Directoryразработено от Microsoft за Windows 2000. И двете услуги поддържат LDAP протокола за достъп и могат да работят в много големи мрежи поради разпространението си.

NDS указателна услуга

NetWare Directory Services (NDS) е глобална референтна услуга, базирана на разпределена обектно-ориентирана база данни от мрежови ресурси. Базата данни на NDS съдържа информация за всички мрежови ресурси, включително информация за потребители, потребителски групи, принтери, томове и компютри. NetWare OS (и други NDS клиенти, работещи на други платформи) използва NDS информация, за да осигури достъп до тези ресурси.

NDS замени директорията за свързване на предишни версии на NetWare. Директорията на bindery е "плоска" или едностепенна база данни, предназначена да поддържа един сървър. Той също така използва понятието "обект" за мрежов ресурс, но тълкуването на този термин се различава от общоприетото. Подвързващите обекти бяха идентифицирани като прости числови стойностии имаше определени атрибути. Въпреки това, за тези обекти не бяха дефинирани изрични отношения на наследяване за класове на обекти, така че връзката между биндерните обекти беше произволно установена от администратора, което често води до нарушения на целостта на данните.

Базата данни NDS е многостепенна база данни, която поддържа информация за ресурсите за всички сървъри в мрежата. За обратна съвместимост с NetWare, NDS предоставя механизъм за емулация на bindery.

NDS е значително подобрение спрямо предишните версии чрез:

• разпространение;
• възпроизводимост;
• прозрачност;
• глобалност.

Разпространението означава, че информацията не се съхранява на един сървър, а е разделена на части, наречени дялове. NetWare съхранява тези дялове на множество сървъри в мрежата (Фигура 10.8). Това свойство значително опростява администрирането и управлението на голяма мрежа, тъй като тя изглежда на администратора като единна система. Той също така осигурява по-бърз достъп до базата данни с мрежови ресурси чрез достъп до най-близкия сървър.

Ориз. 10.8. NDS дялове на базата данни

Реплика е копие на информацията за NDS дяла. Можете да създадете неограничен брой реплики на всеки дял и да ги съхранявате различни сървъри... Ако един сървър спре, тогава копия на тази информация могат да бъдат извлечени от друг сървър. Това повишава устойчивостта на системата, тъй като нито един сървър не е отговорен за цялата информация в базата данни на NDS.

Прозрачността е, че NDS автоматично създава връзки между софтуерни и хардуерни компоненти, които осигуряват на потребителя достъп до мрежови ресурси. NDS не изисква от потребителя да знае физическото местоположение на тези ресурси. питам мрежов ресурспо име, ще получите правилен достъп до него, дори ако неговият мрежов адрес или местоположение се промени.

Глобалността на NDS е, че след като влезете, получавате достъп до ресурсите на цялата мрежа, а не само до един сървър, както беше в предишни версии... Това се постига чрез глобалната процедура за влизане. Вместо да влиза в отделен сървър, потребителят на NDS влиза в мрежата и след това получава достъп до мрежовите ресурси, които са му разрешени. Информацията, предоставена по време на логическото влизане, се използва за идентифициране на потребителя. По-късно, когато потребителят се опита да получи достъп до ресурси като сървъри, томове или принтери, фонов процесидентификация проверява дали потребителят има право на даден ресурс.

Добро време, читатели и гости. Имаше много дълга пауза между постовете, но се върнах в битка). В днешната статия ще разгледам Работа с NFS протокол, и конфигуриране на NFS сървър и NFS клиент на Linux.

Въведение в NFS

NFS (Мрежова файлова система - мрежова файлова система) според мен - идеално решение в локална мрежа, където е необходим бърз (по-бърз от SAMBA и по-малко ресурсоемък в сравнение с отдалечените файлови системи с криптиране - sshfs, SFTP и т.н...) обмен на данни и не е на на преден план сигурността на предаваната информация. NFS протоколпозволява монтиране на отдалечени файлови системи през мрежа в дърво на локални директориисякаш е монтирана дискова файлова система. Така локалните приложения могат да работят с отдалечената файлова система както с локалната. Но трябва да внимавате (!) С настройка на NFS, тъй като при определена конфигурация е възможно да спрете операционната система на клиента, в очакване на безкрайно I/O. NFS протоколвъз основа на работата RPC протокол, което все още не се поддава на моето разбиране)) така че материалът в статията ще бъде малко неясен... Преди да можете да използвате NFS, било то сървър или клиент, трябва да се уверите, че ядрото ви има поддръжка за файловата система NFS. Можете да проверите дали ядрото поддържа файловата система NFS, като потърсите наличието на съответните редове във файла /proc / файлови системи:

АРХИВ ~ # grep nfs / proc / файлови системи nodev nfs nodev nfs4 nodev nfsd

Ако посочените редове във файла /proc / файлови системине успее, тогава трябва да инсталирате пакетите, описани по-долу. Това най-вероятно ще инсталира зависими модули на ядрото за поддръжка на желаните файлови системи. Ако след инсталиране на пакети, поддръжката на NFS не се показва в посочения файл, ще е необходимо с включването на тази функция.

История Мрежова файлова система

NFS протоколразработено от Sun Microsystems и има 4 версии в своята история. NFSv1е разработен през 1989 г. и е експериментален, работещ по UDP протокол. Версия 1 е описана в. NFSv2беше пуснат през същата 1989 г., беше описан от същия RFC1094 и също беше базиран на UDP протокола, като същевременно ви позволява да четете не повече от 2GB от файл. NFSv3преработено през 1995 г. и описано в. Основните нововъведения на третата версия бяха поддръжката на файлове голям размер, добави поддръжка за TCP протокола и големи TCP пакети, което значително ускори работата на технологията. NFSv4финализиран през 2000 г. и описан в RFC 3010, преработен през 2003 г. и описан в. Четвъртата версия включва подобрения в производителността, поддръжка на различни инструменти за удостоверяване (по-специално, Kerberos и LIPKEY, използващи протокола RPCSEC GSS) и списъци за контрол на достъпа (както POSIX, така и тип Windows). NFS версии v4.1беше одобрен от IESG през 2010 г. и получи номера. Важна иновация на версия 4.1 е спецификацията pNFS - Parallel NFS, механизъм за паралелен достъп на NFS клиент до данните на много разпределени NFS сървъри. Наличието на такъв механизъм в стандарта на мрежовата файлова система ще помогне за изграждането на разпределени "облачни" хранилища и информационни системи.

NFS сървър

Тъй като имаме NFS- това е мрежае необходима файлова система. (Можете също да прочетете статията). По-нататък е необходимо. В Debian това е пакетът nfs-kernel-serverи nfs-общ, в RedHat това е пакетът nfs-полезни програми... Освен това е необходимо да активирате стартирането на демона на необходимите нива на изпълнение на ОС (командата в RedHat е / sbin / chkconfig nfs включен, в Debian - /usr/sbin/update-rc.d nfs-kernel-server по подразбиране).

Инсталираните пакети в Debian се изпълняват в следния ред:

АРХИВ ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 root root 20 октомври 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 27 октомври 01:23 S16nfs-common -> . / nfs-kernel-сървър

Тоест започва първо nfs-общслед това самия сървър nfs-kernel-server... В RedHat ситуацията е подобна, с единственото изключение, че се извиква първият скрипт nfslockи сървърът се извиква просто nfs... относно nfs-общ сайтът на debian буквално ни казва следното: Общи файловеза NFS клиент и сървър, този пакет трябва да бъде инсталиран на машина, която ще действа като NFS клиент или сървър. Пакетът включва програми: lockd, statd, showmount, nfsstat, gssd и idmapd... Чрез преглед на съдържанието на стартовия скрипт /etc/init.d/nfs-commonможете да проследите следната последователност на работа: скриптът проверява за наличието на изпълним двоичен файл /sbin/rpc.statd, проверява за присъствие във файлове / etc / default / nfs-common, / etc / fstabи / etc / износпараметри, които изискват стартиращи демони idmapd и gssd , стартира демона /sbin/rpc.statd , след това преди да започнете /usr/sbin/rpc.idmapdи /usr/sbin/rpc.gssdпроверява наличието на тези изпълними файлове двоични файлове, след това за демон /usr/sbin/rpc.idmapdпроверява за sunrpc, nfsи nfsd, както и поддръжка на файловата система rpc_pipefsв ядрото (тоест присъствието му във файла /proc / файлови системи), ако всичко е успешно, тогава работи /usr/sbin/rpc.idmapd ... Освен това за демона /usr/sbin/rpc.gssd чекове модул на ядрото rpcsec_gss_krb5и стартира демона.

Ако прегледате съдържанието Скрипт за стартиране на NFS сървърна Debian ( /etc/init.d/nfs-kernel-server), след което можете да следвате следната последователност: при стартиране скриптът проверява съществуването на файла / etc / износ, Наличност nfsd, наличие на поддръжка NFS файлова системав (тоест във файла /proc / файлови системи), ако всичко е на мястото си, тогава демонът се стартира /usr/sbin/rpc.nfsd , след което проверява дали параметърът е зададен NEED_SVCGSSD(зададете във файла с настройки на сървъра / etc / default / nfs-kernel-server) и, ако е дадено, стартира демона /usr/sbin/rpc.svcgssd , последният, който стартира демона /usr/sbin/rpc.mountd ... От този скрипт можете да видите това Работата на NFS сървъра се състои отдемони rpc.nfsd, rpc.mountd и ако се използва удостоверяване на Kerberos, тогава демонът rcp.svcgssd. Демонът rpc.rquotad и nfslogd все още работят в червената шапка (По някаква причина не намерих информация за този демон в Debian и причините за отсъствието му, очевидно изтрити...).

От това става ясно, че сървърът на мрежовата файлова система се състои от следните процеси (четене - демони)разположени в директориите / sbin и / usr / sbin:

В NFSv4, когато се използва Kerberos, демони се стартират допълнително:

• rpc.gssd- Демонът NFSv4 предоставя методи за удостоверяване чрез GSS-API (Kerberos Authentication). Работи на клиент и сървър.
• rpc.svcgssd- NFSv4 сървър демон, който осигурява удостоверяване на клиента от страна на сървъра.

portmap и RPC протокол (Sun RPC)

В допълнение към горните пакети, NFSv2 и v3 изискват допълнителен пакет portmap(в по-нови дистрибуции, заменени с преименувани в rpcbind). Този пакет обикновено се инсталира автоматично с NFS като зависим и реализира работата на RPC сървъра, тоест отговаря за динамичното присвояване на портове за някои услуги, регистрирани в RPC сървъра. Буквално, според документацията, това е сървър, който преобразува номерата на програмата за отдалечено извикване на процедури (RPC) в номера на TCP / UDP портове. portmap работи с няколко обекта: RPC повиквания или заявки, TCP/UDP портове,версия на протокола(tcp или udp), номера на програмитеи версии на софтуера. Демонът на portmap се стартира от скрипта /etc/init.d/portmap преди стартиране на NFS услуги.

Накратко, задачата на RPC (Remote Procedure Call) сървър е да обработва RPC повиквания (известни още като RPC процедури) от локални и отдалечени процеси. Използвайки RPC повиквания, услугите се регистрират или премахват към/от портовия мапер (известен още като portmapper, известен още като portmap, известен още като portmapper, известен още като rpcbind, в по-новите версии), а клиентите, използващи RPC повиквания, насочващи заявки към portmapper, получават необходимата информация. Удобните за потребителя имена на програмни услуги и съответните им номера са дефинирани в / etc / rpc. Веднага щом дадена услуга изпрати съответна заявка и се регистрира с RPC сървъра в портовото устройство, RPC сървърът присвоява TCP и UDP портовете на услугата, на която е стартирана услугата, и съхранява в ядрото съответната информация за работеща услуга (име), услуга с уникален номер (в съответствие с / etc / rpc), за протокола и порта, на който се изпълнява услугата и за версията на услугата, и предоставя посочената информация на клиентите при поискване. Самият преобразувател на портове има номер на програмата (100000), номер на версията - 2, TCP порт 111 и UDP порт 111. По-горе, когато уточнявам състава на NFS сървърните демони, посочих основните номера на RPC програми. Вероятно малко ви обърках с този параграф, така че ще кажа основната фраза, която трябва да изясни: основната функция на мапера на портовете е да върне на него (клиента) порта, на който се изпълнява исканата програма. Съответно, ако клиентът трябва да получи достъп до RPC с определен номер на програма, той първо трябва да се свърже с процеса на portmap на сървърната машина и да определи номера на порта за комуникация с RPC услугата, от която се нуждае.

Работата на RPC сървър може да бъде представена чрез следните стъпки:

1. Преобразувателят на порт трябва да се стартира първо, обикновено при стартиране на системата. Това създава TCP крайна точка и отваря TCP порт 111. Също така създава UDP крайна точка, която чака UDP дейтаграма да пристигне на UDP порт 111.
2. При стартиране, програма, работеща през RPC сървър, създава TCP крайна точка и UDP крайна точка за всяка поддържана версия на програмата. (Един RPC сървър може да поддържа множество версии. Клиентът посочва необходимата версия при извършване на RPC повикване.) На всяка версия на услугата се присвоява динамично присвоен номер на порт. Сървърът регистрира всяка програма, версия, протокол и номер на порт, като извършва съответното RPC повикване.
3. Когато клиентската програма RPC се нуждае от информацията, от която се нуждае, тя извиква рутинна програма за преобразуване на портове, за да получи динамично присвоен номер на порт за дадена програма, версия и протокол.
4. В отговор на това искане северът връща номера на порта.
5. Клиентът изпраща съобщение за RPC заявка до номера на порта, получен в стъпка 4. Ако се използва UDP, клиентът просто изпраща UDP дейтаграма, съдържаща съобщението за RPC повикване до номера на UDP порта, на който се изпълнява исканата услуга. В отговор услугата изпраща UDP дейтаграма, съдържаща съобщение за RPC отговор. Ако TCP се използва, клиентът прави активно отваряне на номера на TCP порта на заявената услуга и след това изпраща съобщение за RPC повикване на установена връзка... Сървърът отговаря със съобщение за RPC отговор през връзката.

За да получите информация от RPC сървъра, използвайте помощната програма rpcinfo... При посочване на параметри -p хостпрограмата изброява всички регистрирани RPC програми на хоста. Без да посочва хост, програмата ще показва услуги на localhost. пример:

Archiv ~ # rpcinfo -р прог-ма версия прото порт 100 000 2 111 TCP демон 100 000 2 111 UDP демон 100024 1 UDP 59451 състояние 100024 1 TCP 60872 състояние 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 монтиране 41405 mountd 100005 2 UDP 51306 монтиран 100005 2 tcp 41405 монтиран 100005 3 udp 51306 монтиран 100005 3 tcp 41405 монтиран

Както можете да видите, rpcinfo показва (в колони отляво надясно) регистрирания номер на програма, версия, протокол, порт и име. С помощта на rpcinfo можете да премахнете регистрацията на програма или да получите информация за отделна услуга RPC (повече опции в man rpcinfo). Както можете да видите, демони portmapper версия 2 са регистрирани на udp и tcp портове, rpc.statd версия 1 на udp и tcp портове, NFS lock manager версии 1,3,4, nfs сървър демон 2,3,4, както и монтиране на демон версии 1,2,3.

NFS сървърът (по-точно демонът rpc.nfsd) получава заявки от клиента под формата на UDP дейтаграми на порт 2049. Въпреки че NFS работи с преобразувател на портове, който позволява на сървъра да използва динамично присвоени портове, UDP порт 2049 е твърдо кодиран към NFS в повечето реализации ...

Операция на протокола за мрежова файлова система

Монтирайте отдалечен NFS

Процесът на монтиране на отдалечена файлова система NFS може да бъде представен със следната диаграма:

Описание на NFS протокола при монтиране на отдалечена директория:

1. RPC сървър се стартира на сървъра и клиента (обикновено при зареждане), обслужва се от процеса на portmapper и се регистрира на tcp / 111 и udp / 111 портовете.
2. Стартират се услуги (rpc.nfsd, rpc.statd и др.), които се регистрират на RPC сървъра и се регистрират на произволно мрежови портове(ако в настройките на услугата не е посочен статичен порт).
3. командата mount на клиентския компютър изпраща заявка до ядрото за монтиране на мрежова директория с индикация за типа на файловата система, хоста и самата директория, ядрото изпраща RPC заявка към процеса на portmap на NFS сървъра на udp / 111 порт (ако клиентът няма опция да работи чрез tcp)
4. Ядрото на NFS сървъра проучва RPC за наличието на демона rpc.mountd и го връща на клиентското ядро мрежов портче демонът работи.
5. mount изпраща RPC заявка към порта, на който се изпълнява rpc.mountd. Сега NFS сървърът може да валидира клиента въз основа на неговия IP адрес и номер на порт, за да види дали клиентът може да монтира определената файлова система.
6. Демонът за монтиране връща описание на исканата файлова система.
7. Командата за монтиране на клиента издава системното извикване за монтиране, за да обвърже файловия дескриптор, получен в стъпка 5, към локалната точка на монтиране на клиентския хост. Файловият дескриптор се съхранява в клиентския код на NFS и от този момент нататък всеки достъп от потребителски процеси до файлове във файловата система на сървъра ще използва файловия дескриптор като отправна точка.

Комуникация между клиент и NFS сървър

Типичният достъп до отдалечена файлова система може да бъде описан по следния начин:

Описание на процеса на достъп до файл, намиращ се на NFS сървъра:

1. Клиентът (потребителският процес) не се интересува дали получава достъп до локален файл или NFS файл. Ядрото се занимава с взаимодействието с хардуера чрез модули на ядрото или вградени системни извиквания.
2. Модул на ядрото ядро / fs / nfs / nfs.ko,който действа като NFS клиент и изпраща RPC заявки към NFS сървъра чрез TCP/IP модула. NFS обикновено използва UDP, но по-новите реализации могат да използват TCP.
3. NFS сървърът получава заявки от клиента като UDP дейтаграми на порт 2049. Въпреки че NFS може да работи с преобразувател на портове, което позволява на сървъра да използва динамично присвоени портове, UDP порт 2049 е твърдо кодиран за NFS в повечето реализации.
4. Когато NFS сървърът получи заявка от клиент, тя се предава на рутинната програма за достъп до локални файлове, която осигурява достъп до локалния диск на сървъра.
5. Резултатът от достъпа до диска се връща на клиента.

Настройка на NFS сървър

Настройка на сървъраобикновено се състои в посочване на локалните директории, разрешени за монтиране от отдалечени системи във файл / etc / износ... Това действие се нарича йерархия на директорията за експортиране... Основните източници на информация за експортираните директории са следните файлове:

• / etc / износ- основният конфигурационен файл, който съхранява конфигурацията на експортираните директории. Използва се при стартиране на NFS и помощната програма exportfs.
• / var / lib / nfs / xtab- съдържа списък с директории, монтирани от отдалечени клиенти. Използва се от демона rpc.mountd, когато клиент се опитва да монтира йерархия (създава се запис за монтиране).
• / var / lib / nfs / etab- списък с директории, които могат да се монтират от отдалечени системи, като се посочват всички параметри на експортираните директории.
• / var / lib / nfs / rmtab- списък с директории, които не се експортират в момента.
• / proc / fs / nfsd- специална файлова система (ядро 2.6) за управление на NFS сървъра.
  • износ- списък на активните експортирани йерархии и клиенти, към които са били експортирани, както и параметри. Ядрото получава тази информация от / var / lib / nfs / xtab.
  • нишки- съдържа броя на нишките (също може да бъде променен)
  • с помощта на filehandle можете да получите указател на файл
  • и т.н...
• / proc / net / rpc- съдържа необработени статистически данни, които могат да бъдат получени с помощта на nfsstat, както и различни кешове.
• / var / run / portmap_mapping- информация за регистрирани в RPC услуги

Забележка: общо взето в интернет има доста тълкувания и формулировки за предназначението на файловете xtab,etab,rmtab,не знам на кого да вярвам.Дори на http://nfs.sourceforge.net/ интерпретацията не е еднозначно.

Конфигуриране на файла / etc / за експортиране

В най-простия случай файлът / etc / exports е единственият файл, който се нуждае от редактиране, за да конфигурира NFS сървъра. Този файлуправлява следните аспекти:

• Какви клиентиима достъп до файлове на сървъра
• Кои йерархиидиректории на сървъра могат да бъдат достъпни от всеки клиент
• Как ще бъдат персонализираните имена на клиенти да бъдат показаникъм локални потребителски имена

Всеки ред във файла за експортиране има следния формат:

експортна_точка клиент1 (опции) [клиент2 (опции) ...]

Където експортна_точка абсолютният път на йерархията на експортираната директория, клиент1 - n името на един или повече клиенти или IP адреси, разделени с интервали, които са разрешени за монтиране експортна_точка . Настроики опишете правилата за монтиране за клиентпосочено преди настроики .

Ето един типичен примерна конфигурация на файла за експортиране:

ARCHIV ~ # cat / etc / exports / archiv1 файлове (rw, sync) 10.0.0.1 (ro, sync) 10.0.230.1/24(ro, sync)

V този примерфайлове и компютри 10.0.0.1 имат достъп до точката за експортиране / archiv1, докато хостът на файловете се чете/записва, а хостът 10.0.0.1 и подмрежата 10.0.230.1/24 са само за четене.

Описанията на хост в / etc / експортирането е разрешено в следния формат:

• Имената на отделните възли се описват като файлове или files.DOMAIN.local.
• Маските на домейни са описани в следния формат: * DOMAIN.local включва всички възли в домейна DOMAIN.local.
• Подмрежите са посочени като двойки IP адрес/маска. Например: 10.0.0.0/255.255.255.0 включва всички възли, чиито адреси започват с 10.0.0.
• Задаване на името на мрежовата група @myclients, която има достъп до ресурса (при използване на NIS сървър)

Общи опции за експортиране на йерархии на директории

Файлът за експортиране използва следните общи опции(опциите, използвани по подразбиране в повечето системи, са посочени първо, в скоби - не по подразбиране):

• auth_nlm (no_auth_nlm)или secure_locks (insecure_locks)- указва, че сървърът трябва да изисква удостоверяване на заявките за заключване (с помощта на протокола NFS Lock Manager).
• не се скривам (скривам)- ако сървърът експортира две йерархии на директории, като едната е вложена (монтирана) в другата. Клиентът трябва изрично да монтира втората (дъщерна) йерархия, в противен случай точката на монтиране на дъщерната йерархия ще се появи като празна директория. Опцията nohide води до втора йерархия на директории без изрично монтиране. ( Забележка:Не можах да накарам тази опция да работи...)
• ro (rw)- Позволява само заявки за четене (записване). (В крайна сметка, дали е възможно четене/запис или не се определя въз основа на разрешенията на файловата система, докато сървърът не е в състояние да различи заявка за четене на файл от заявка за изпълнение, така че позволява четене, ако потребителят има разрешения за четене или изпълнение .)
• сигурен (несигурен)- изисква NFS заявките да идват от защитени портове (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check)- Ако се експортира поддиректория на файловата система, но не и цялата файлова система, сървърът проверява дали исканият файл е в експортираната поддиректория. Деактивирането на проверката намалява сигурността, но увеличава скоростта на пренос на данни.
• синхронизиране (асинхронно)- показва, че сървърът трябва да отговаря на заявки само след като промените, направени от тези заявки, бъдат записани на диск. Опцията async казва на сървъра да не чака информацията да бъде записана на диск, което подобрява производителността, но намалява надеждността, т.к. загуба на информация е възможна в случай на прекъсване на връзката или повреда на оборудването.
• wdelay (no_wdelay)- Указва на сървъра да забави изпълнението на заявки за запис, ако следваща заявка за запис е в очакване, записвайки данни в по-големи блокове. Това подобрява производителността при изпращане на големи опашки за запис. no_wdelay показва да не се отлага изпълнението на командата за запис, което може да бъде полезно, ако сървърът получи голям брой команди, които не са свързани помежду си.

Експортиране на символни връзки и файлове на устройството.Когато експортирате йерархия от директории, съдържащи символни връзки, обектът на връзката трябва да бъде достъпен за клиентската (отдалечена) система, тоест трябва да се спазва едно от следните правила:

Файлът на устройството се отнася до интерфейса. Когато експортирате файл на устройство, този интерфейс се експортира. Ако клиентската система няма устройство от същия тип, тогава експортираното устройство няма да работи. В клиентската система, когато монтирате NFS обекти, можете да използвате опцията nodev, така че файловете на устройството в монтираните директории да не се използват.

Опциите по подразбиране могат да варират от система до система, те могат да се видят във файла / var / lib / nfs / etab. След описание на експортираната директория в / etc / exports и рестартиране на NFS сървъра, всички липсващи опции (прочетете: опции по подразбиране) ще бъдат отразени във файла / var / lib / nfs / etab.

Опции за показване (съвпадение) на потребителския идентификатор

За по-добро разбиране на следното, бих ви посъветвал да прочетете статията. Всеки потребител на Linux има свой собствен UID и основен GID, които са описани във файловете / etc / passwdи / и т.н. / група... NFS сървърът приема, че операционната система на отдалечения хост е удостоверила автентичността на потребителите и им е присвоила правилните UID и GID. Експортирането на файловете дава на потребителите в клиентската система същия достъп до тези файлове, както ако влизат директно в сървъра. Съответно, когато NFS клиент изпрати заявка до сървър, сървърът използва UID и GID, за да идентифицира потребителя в локалната система, което може да доведе до някои проблеми:

• потребителят може да няма еднакви идентификатори в двете системи и съответно да има достъп до файловете на друг потребител.
• от root потребителят има идентификатор винаги 0, тогава този потребител е съпоставен с локален потребителв зависимост от посочените опции.

Следните опции дефинират правилата за съпоставяне на отдалечени потребители с локални:

• root_squash (no_root_squash)- С дадения вариант root_squash, заявките от основния потребител се съпоставят с анонимния uid / gid или с потребителя, посочен в параметъра anonuid / anongid.
• no_all_squash (всички_squash)- Не променя UID / GID на свързващия се потребител. Вариант all_squashзадава ВСИЧКИ потребители (не само root) да се показват като анонимни или посочени в параметъра anonuid / anongid.
• анонуиден = UID и анонгид = GID - Изрично задава UID / GID за анонимния потребител.
• map_static = / etc / file_maps_users - Посочва файл, в който можете да зададете съпоставяне на отдалечен UID / GID - локален UID / GID.

Пример за използване на файл за картографиране на потребители:

ARCHIV ~ # cat / etc / file_maps_users # User mapping # отдалечен локален коментар uid 0-50 1002 # преобразуване на потребителите към отдалечен UID 0-50 към локален UID 1002 gid 0-50 1002 # съпоставяне на потребители към / span отдалечен GID 0-50 към местен GID 1002

Управление на NFS сървър

NFS сървърът се управлява с помощта на следните помощни програми:

• nfsstat
• showmsecure (несигурен) count

nfsstat: NFS и RPC статистика

Помощната програма nfsstat ви позволява да преглеждате статистиката на RPC и NFS сървърите. Опциите за команди могат да се видят в man nfsstat.

showmount: показва информация за състоянието на NFS

Помощна програма Showmountзапитва демона rpc.mountd за отдалечен хостотносно монтираните файлови системи. По подразбиране се връща сортиран списък с клиенти. ключове:

• --всичко- показва се списък с клиенти и точки за монтиране, показващ къде клиентът е монтирал директорията. Тази информация може да не е надеждна.
• -- директории- даден е списък с точки за монтиране
• --износ- дава списък на експортираните файлови системи от гледна точка на nfsd

Ако стартирате showmount без аргументи, конзолата ще покаже информация за системите, на които е разрешено да се монтират местендиректории. Например хостът ARCHIV ни предоставя списък с експортирани директории с IP адресите на хостовете, на които е разрешено да монтират посочените директории:

ФАЙЛОВЕ ~ # showmount --exports archiv Експортиране на списък за архив: / archiv-big 10.0.0.2 / archiv-small 10.0.0.2

Ако посочите името на хоста / IP в аргумента, ще се покаже информация за този хост:

ARCHIV ~ # showmount файлове clnt_create: RPC: Програмата не е регистрирана # това съобщение ни казва, че демонът NFSd не работи на хоста FILES

exportfs: управлява експортираните директории

Тази команда обслужва експортираните директории, посочени във файла / etc / износ, ще бъде по-точно да се пише не служи, а се синхронизира с файла / var / lib / nfs / xtabи премахва несъществуващите от xtab. exportfs се изпълнява, когато демонът nfsd се стартира с аргумента -r. Помощната програма exportfs в режим на ядрото 2.6 комуникира с демона rpc.mountd чрез файловете в директорията / var / lib / nfs / и не комуникира директно с ядрото. Без параметри, изброява текущо експортираните файлови системи.

Exportfs опции:

• [client: directory-name] - добавете или премахнете посочената файлова система за посочения клиент)
• -v - показва повече информация
• -r - повторно експортиране на всички директории (sync / etc / exports и / var / lib / nfs / xtab)
• -u - премахване от списъка на експортираните
• -a - добавяне или премахване на всички файлови системи
• -o - опции, разделени със запетаи (подобно на опциите, използвани в / etc / експортиране; така че можете да промените опциите за вече монтирани файлови системи)
• -i - не използвайте / etc / експортиране при добавяне, само параметри на текущия команден ред
• -f - нулиране на списъка с експортирани системи в ядрото 2.6;

NFS клиент

Преди достъп до файл в отдалечената файлова система, клиентът (клиентската ОС) трябва монтирайте гои вземете от сървъра указател към него. Монтиране на NFSможе да се направи с или с помощта на един от плодотворните автоматични асембли (amd, autofs, automount, supermount, superpupermount). Процесът на монтаж е добре демонстриран на илюстрацията по-горе.

На NFS клиенти няма нужда да се стартират демони, клиентски функцииизпълнява модула на ядрото ядро / fs / nfs / nfs.koкойто се използва при монтиране на отдалечена файлова система. Експортираните директории от сървъра могат да бъдат монтирани на клиента по следните начини:

• ръчно с помощта на командата монтиране
• автоматично при стартиране, когато монтирате файлови системи, описани в / etc / fstab
• автоматично с помощта на демона autofs

Няма да разглеждам третия метод с autofs в тази статия, поради неговата обемна информация. Може би в следващите статии ще има отделно описание.

Монтирайте мрежовата файлова система с командата mount

Пример за използване на командата за монтиране е представен в публикацията. Ето пример за команда за монтиране за монтиране на NFS файлова система:

ФАЙЛОВЕ ~ # mount -t nfs archiv: / archiv-small / archivs / archiv-small FILES ~ # mount -t nfs -o ro archiv: / archiv-big / archivs / archiv-big FILES ~ # монтиране ..... .. archiv: / archiv-small on / archivs / archiv-small тип nfs (rw, addr = 10.0.0.6) archiv: / archiv-big on / archivs / archiv-big тип nfs (ro, addr = 10.0.0.6)

Първата команда монтира експортираната директория / архив-малъкна сървъра архивдо локална точка на монтиране / archivs / archiv-smallс опции по подразбиране (т.е. четене и писане). все пак команда за монтиранев най-новите дистрибуции той знае как да разбере какъв тип файлова система се използва, без да посочва типа, все пак посочете параметъра -t nfsжелателно. Втората команда монтира експортираната директория / архив-голямна сървъра архивкъм локална директория / archivs / archiv-bigс опция само за четене ( ро). Команда за монтиранебез параметри, той ясно ни показва резултата от монтирането. В допълнение към опцията само за четене (ro), е възможно да се посочи и друга основни опции при монтиране на NFS:

• носуид- Тази опция забранява изпълнението на програми от монтираната директория.
• nodev(без устройство - не устройство) - Тази опция забранява използването на символни и блокиращи специални файлове като устройства.
• заключване (nolock)- Позволява NFS заключване (по подразбиране). nolock деактивира NFS заключването (не стартира демона lockd) и е полезен за по-стари сървъри, които не поддържат NFS заключване.
• mounthost = име- Името на хоста, на който работи демонът за монтиране на NFS - mountd.
• mountport = n -Портът, използван от демона mountd.
• порт = n- порт, използван за свързване към NFS сървъра (по подразбиране 2049, ако демонът rpc.nfsd не е регистриран на RPC сървъра). Ако n = 0 (по подразбиране), тогава NFS ще поиска картата на портовете на сървъра, за да определи порта.
• rsize = n(размер на блок за четене) - Броят байтове, прочетени наведнъж от NFS сървъра. Стандарт - 4096.
• размер = n(размер на блок за запис) - Броят байтове, записани наведнъж на NFS сървъра. Стандарт - 4096.
• tcpили udp- За монтиране използвайте NFS TCP протоколили UDP, съответно.
• bg- Ако загубите достъп до сървъра, опитайте отново във фонов режим, за да не блокирате процеса на зареждане на системата.
• fg- Ако загубите достъп до сървъра, опитайте отново в режим на приоритет. Този параметърможе да блокира процеса на зареждане чрез повтаряне на опитите за монтиране. Поради тази причина параметърът fg се използва основно за целите на отстраняване на грешки.

Опции, засягащи кеширането на атрибути при монтиране на NFS

Файлови атрибутисъхранявани в (иноди), като време на модификация, размер, твърди връзки, собственик, обикновено се променят рядко за обикновени файлове и още по-рядко за директории. Много програми, като ls, имат достъп до файлове само за четене и не променят файлови атрибути или съдържание, но губят системни ресурси за скъпи мрежови операции. За да избегнете ненужна загуба на ресурси, можете кеширане на дадени атрибути... Ядрото използва времето за модификация на файл, за да определи дали кешът е остарял, като сравнява времето за модификация в кеша с времето за модификация на самия файл. Кешът на атрибутите се актуализира периодично според посочените параметри:

• ac (noac) (кеш на атрибутите- кеширане на атрибути) - Активира кеширането на атрибути (по подразбиране). Въпреки че опцията noac забавя сървъра, тя избягва изтичането на атрибута, когато множество клиенти активно пишат информация в споделената йерархия.
• acdirmax = n (атрибут кеш директория файл максимум- максимум за кеширане на атрибути за файл на директория) - Максималният брой секунди, които NFS чака преди актуализиране на атрибутите на директорията (по подразбиране 60 секунди)
• acdirmin = n (Минимален файл на кеша на директорията- кеширане на атрибути поне за файл на директория) - Минималният брой секунди, които NFS чака, преди да актуализира атрибутите на директорията (по подразбиране 30 секунди)
• acregmax = n (атрибут кеш обикновен файл максимум- кеширане на атрибути най-много за обикновен файл) - Максималният брой секунди, които NFS ще изчака, преди да актуализира атрибутите на обикновен файл (по подразбиране 60 секунди)
• acregmin = n (атрибут кеш редовен файл минимум- кеширане на атрибути поне за обикновен файл) - Минималният брой секунди, които NFS чака, преди да актуализира атрибутите на обикновен файл (3 секунди по подразбиране)
• actimeo = n (изчакване на кеша на атрибути- изчакване за кеширане на атрибути) - Отменя стойностите за всички горепосочени опции. Ако acttimeo не е посочено, тогава горните стойности се задават на техните стойности по подразбиране.

Опции за обработка на грешки в NFS

Следните опции контролират как се държи NFS, когато няма отговор от сървъра или когато възникнат I/O грешки:

• fg (bg) (преден план - преден план, заден план- фон) - Опитайте се да монтирате неуспешен NFS на преден план / фон.
• твърд мек)- показва съобщението "сървърът не отговаря" на конзолата при достигане на времето за изчакване и продължава опитите за монтиране. С дадения вариант мека- ако настъпи изчакване, информира програмата, която е извикала операцията, за I/O грешка. (меката опция се препоръчва да не се използва)
• ноинтр (intr) (без прекъсване- не прекъсвай) - Предотвратява сигнали от прекъсване на файлови операции в твърдо монтираната йерархия на директории, когато се достигне дълго изчакване. intr- позволява прекъсване.
• ретранс = n (стойност на повторно предаване- стойност на повторно предаване) - След n малки изчаквания, NFS генерира голямо изчакване (3 по подразбиране). Продължителното изчакване спира операциите или показва съобщение „сървърът не отговаря“ на конзолата, в зависимост от посочената твърда/мека опция.
• повторен опит = n (повторен опит стойност- стойност за повторен опит) - Броят минути, през които услугата NFS се опитва да монтира повторно операции, преди да се откаже (10 000 по подразбиране).
• timeo = n (стойност на изчакване- стойност на изчакване) - Броят десети от секундата, които услугата NFS изчаква преди повторно предаване в случай на RPC или ниско изчакване (по подразбиране 7). Тази стойност се увеличава с всяко изчакване до максимум 60 секунди или докато настъпи дълго изчакване. В натоварена мрежа, бавен сървър или когато заявка преминава през множество рутери или шлюзове, увеличаването на тази стойност може да подобри производителността.

Автоматично монтиране на NFS при стартиране (описание на файловите системи в / etc / fstab)

Намерете оптималното време за определена стойностпредадения пакет (стойности rsize / wsize), използвайки командата ping:

ФАЙЛОВЕ ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768 (32796) байта данни. 32776 байта от archiv.domain.local (10.0.0.6): icmp_req = 1 ttl = 64 време = 0,931 ms 32 776 байта от archiv.domain.local (10.0.0.6): icmp_req = 2 ttl = 64 времена 8 7 ms. от archiv.domain.local (10.0.0.6): icmp_req = 3 ttl = 64 време = 1,03 мс 32776 байта от archiv.domain.local (10.0.0.6): icmp_req = 4 ttl = 60 времена = 64 arch ms от 1.07 .domain.local (10.0.0.6): icmp_req = 5 ttl = 64 време = 1,08 ms ^ C --- archiv.DOMAIN.local ping статистика --- 5 пакета предадени, 5 получени, 0% загуба на пакети, време 4006ms rtt min / avg / max / mdev = 0,931 / 1,002 / 1,083 / 0,061 ms

Както можете да видите, когато изпращате пакет с размер 32768 (32Kb), времето му за пътуване от клиента до сървъра и обратно плава в района на 1 милисекунда. Ако даденото времеще излезе извън мащаба за 200 ms, тогава трябва да помислите за увеличаване на timeo стойността, така че да надвишава стойността на обмен три до четири пъти. Съответно, препоръчително е да направите този тест при силно натоварване на мрежата.

Стартиране на NFS и конфигуриране на защитната стена

Бележката е копирана от блога http://bog.pp.ru/work/NFS.html, за което много му благодаря !!!

Стартирайте NFS сървър, монтирайте, заключете, квота и състояние с "правилни" портове (за защитна стена)

• препоръчително е първо да демонтирате всички ресурси на клиенти
• спрете и забранете стартирането на rpcidmapd, ако не планирате да използвате NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• ако е необходимо, активирайте стартирането на услугите portmap, nfs и nfslock: chkconfig --levels 345 portmap / rpcbind на chkconfig --levels 345 nfs на chkconfig --levels 345 nfslock на
• ако е необходимо, спрете услугите на nfslock и nfs, стартирайте portmap / rpcbind, разтоварете модулите service nfslock stop service nfs stop service portmap start # service rpcbind start umount / proc / fs / nfsd service rpcidmapd stop rmmod nfsd service autofs трябва да спре # стартирайте rmmod nfs rmmod nfs_acl rmmod lockd
• отворени портове в
  • за RPC: UDP / 111, TCP / 111
  • за NFS: UDP / 2049, TCP / 2049
  • за rpc.statd: UDP / 4000, TCP / 4000
  • за заключен: UDP / 4001, TCP / 4001
  • за монтиране: UDP / 4002, TCP / 4002
  • за rpc.rquota: UDP / 4003, TCP / 4003
• за сървъра rpc.nfsd добавете реда RPCNFSDARGS = "- порт 2049" към / etc / sysconfig / nfs
• за сървъра за монтиране добавете реда MOUNTD_PORT = 4002 към / etc / sysconfig / nfs
• за да конфигурирате rpc.rquota за нови версии, добавете реда RQUOTAD_PORT = 4003 към / etc / sysconfig / nfs
• за да конфигурирате rpc.rquota е необходимо за по-стари версии (все пак трябва да имате квота 3.08 или по-нов пакет) добавете rquotad 4003 / tcp rquotad 4003 / udp към / etc / услуги
• ще провери адекватността на / etc / експорта
• стартирайте услугите rpc.nfsd, mountd и rpc.rquota (в същото време се стартират rpcsvcgssd и rpc.idmapd, ако не сте забравили да ги премахнете) service nfsd start или в нови версии service nfs start
• за сървъра за заключване за нови системи добавете редовете LOCKD_TCPPORT = 4001 LOCKD_UDPPORT = 4001 към / etc / sysconfig / nfs
• за сървър за заключване за наследени системи добавете директно към /etc/modprobe [.conf]: опции lockd nlm_udpport = 4001 nlm_tcpport = 4001
• свържете сървъра на състоянието rpc.statd към порт 4000 (за стари системи в /etc/init.d/nfslock стартирайте rpc.statd с превключвателя -p 4000) STATD_PORT = 4000
• start services lockd и rpc.statd service nfslock start
• уверете се, че всички портове са свързани правилно с "lsof -i -n -P" и "netstat -a -n" (някои от портовете се използват от модули на ядрото, които lsof не вижда)
• ако преди "преизграждането" сървърът е бил използван от клиенти и те не могат да бъдат демонтирани, тогава ще трябва да рестартирате услугите за автоматично монтиране на клиентите (am-utils, autofs)

Примерна конфигурация на NFS сървър и клиент

Конфигурация на сървъра

Ако искате да направите вашата NFS разделена директория отворена и достъпна за запис, можете да използвате опцията all_squashв комбинация с опции анонуидени анонгиден... Например, за да зададете правата за потребителя "никой" в групата "никой", можете да направите следното:

ARCHIV ~ # cat / etc / exports # Достъп за четене / запис за клиент на 192.168.0.100, с rw достъп за потребител 99 с gid 99 / файлове 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid) = 99) # Достъп за четене/запис за клиент на 192.168.0.100, с rw достъп за потребител 99 с gid 99 / файлове 192.168.0.100 (rw, sync, all_squash, anonuid = 99, anongid = 99))

Това също означава, че ако искате да разрешите достъп до посочената директория, nobody.nobody трябва да е собственик на разделената директория:

човек планина
мъжки износ
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - производителност на NFS от IBM.

Поздрави, Mc.Sim!

Мрежови файлови системи

Един от най полезни функциикоето може да се реализира с мрежа е споделянето на файлове чрез мрежова файлова система. Често използвана е система, наречена мрежова файлова система или NFS, която е разработена от Sun Corporation.

Когато работите с мрежова файлова система, всички операции върху файлове, извършени на локалния компютър, се предават по мрежата до отдалечена машина... Когато мрежовата файлова система работи, програмата приема, че всички файлове на отдалечения компютър се намират на компютъра, на който се изпълнява. По този начин, разделянето на информация чрез такава система не изисква никакви промени в програмата.

поща

Електронната поща е най-важното средство за комуникация между компютрите. Имейлите се съхраняват в един файл в специален формат. За четене и изпращане на писма се използват специални програми.

Всеки потребител има отделна пощенска кутия, файл, където информацията се съхранява в специален формат, в който се съхранява входящата поща. Ако на компютъра дойде писмо, програмата за обработка на поща намира файла на пощенската кутия на съответния потребител и добавя полученото писмо там. Ако пощенската кутия на потребителя се намира на друг компютър, тогава писмото се пренасочва към този компютър, където се обработва допълнително.

Пощенска системасе състои от много различни програми... Доставката на поща до локални или отдалечени пощенски кутии се извършва от една програма (например sendmail или smail), докато голям брой различни програми (например Pine или elm) се използват за нормално изпращане или преглед на писма. Файловете на пощенските кутии обикновено се съхраняват в / var / spool / mail.

Въпроси

1. Какво е NOS и какво е предназначението му?

2. Какви функции на мрежата изпълнява мрежовата операционна система?

3. Кои са частите от структурата на NOS?

4. Какво е пренасочване?

5. Как се подразделят мрежовите операционни системи според правата за достъп до ресурси?

6. Как се подразделят мрежовите операционни системи по мрежов мащаб?

7. Как свойствата на мрежовата операционна система зависят от мащаба на мрежите?

8. Опишете мрежовата операционна система NetWare от Novell.

9. Кои са елементите от структурата на мрежовата операционна система NetWare?

10. Опишете файловата система на мрежовата операционна система NetWare.

11. Какви нива на протоколи поддържа мрежовата операционна система NetWare?

12. Избройте функциите на протоколите IPX, SPX.

13. Опишете мрежовата операционна зала Windows системи NT

14. Избройте задачите на мрежовата операционна система Windows NT.

15. Кои са елементите от структурата на мрежовата операционна система Windows NT?

16. Дайте характеристиките на файловата система на мрежовата операционна система Windows NT.

17. Какви принципи за сигурност се използват в мрежовата операционна система Windows NT?

18. Избройте характеристиките на мрежовата операционна система Windows NT от гледна точка на внедряването на мрежови съоръжения.

19. Назовете свойствата на мрежовата операционна система Windows NT.

20. Какви са областите с помощта на прозорци NT?

21. Дайте характеристиките на мрежовата операционна система UNIX.

22. Избройте функциите на мрежовата операционна система UNIX.

23. Дайте характеристиките на файловата система на мрежовата OS UNIX.

24. Какви принципи за сигурност се използват от UNIX?

25. Дайте общ преглед на мрежовата операционна система Linux.

Мрежови услуги

Лекция 10

Набор от сървърни и клиентски части на ОС, които осигуряват достъп до специфичен типсе нарича компютърен ресурс през мрежа мрежова услуга . Клиентска частобработва мрежови заявки към сървърната страна на друг компютър. Сървърна частудовлетворява заявки към ресурси на локалния сървър. Клиентската страна е активна, сървърната страна е пасивна.

По време на мрежово взаимодействие значително място заема достъпът през мрежата до файловата система. В този случай се формират клиентската и сървърната част, заедно с мрежовата файлова система файлова услуга

Ключов компонент на разпределената ОС е мрежовата файлова система. Мрежовата файлова система се поддържа от един или повече компютри, съхраняващи файлове (файлови сървъри)

Клиенткомпютрите прикачват или монтират тези файлови системи към техните локални файлови системи

Файлова услугавключва сървърни програми и клиентски програми, които комуникират през мрежата с помощта на протокол.

Файловите услуги включват действителната файлова услуга (файлови операции) и директорийната услуга (управление на директории)

Моделът на мрежовата файлова услуга включва следните елементи:

Локална файлова система (FAT, NTFS)

Интерфейс на локална файлова система (системни повиквания)

Сървър на мрежова файлова система

Клиент на мрежова файлова система (Windows Explorer, UNIX shell и др.)

Интерфейс на мрежовата файлова система (повтаря системни повиквания към локалната файлова система)

Мрежова файлова система Протокол клиент-сървър (блок за съобщения на SMB-сървър за Windows, NFS (мрежова файлова система) и FTP ( Прехвърляне на файлпротокол) за UNIX)

Интерфейс на мрежова файлова система

Има няколко типа интерфейси, които се характеризират с:

Файлова структура... Повечето мрежови файлови системи поддържат плоски файлове

Възможност за промяна на файла... Повечето мрежови файлови системи имат способността да променят файла. Някои разпределени файлови системи забраняват операции по модификация. Възможни са само създаване и четене. За такива файлове е по-лесно да се организира кеширане и репликация.

Семантика на разделяне на файлове:

Семантика UNIX (централизиран). Ако четенето следва множество операции за запис, тогава се чете последната актуализация. Този принцип е възможен и в разпределена файлова система, при условие че има такава файлов сървъри липсата на кеширане на файлове на клиента.

Семантика на сесията.Промените започват при отваряне на файла и завършват, когато файлът бъде затворен. С други думи, за други процеси промените са видими само след затваряне на файла. В този случай има проблем със споделянето на файлове. Семантика на неизменяеми файлове.Файлът може само да бъде създаден и прочетен. Можете също така да създадете отново файла с различно име. Следователно файлът не може да бъде променен, но може да бъде заменен с нов файл. Няма проблем със споделянето.

Транзакционен механизъм.Това е начин за работа със споделени файлове, използвайки механизма за транзакции (неделими операции)

Контрол на достъпа... Например, за Windows NT / 2000 има два механизма: на ниво директория (за FAT) и на ниво файл (NTFS)

Устройство за достъп.Пълен модел за качване / изтегляне на файлове (FTP). Вторият модел е използването на файлови операции.