Для чего нужен файл networks в windows. Что должно быть в файле networks

Доброго времени, уважаемые читатели. Публикую вторую часть . В текущей части основной упор сделан на реализацию сети в Linux (как настроить сеть в Linux, как продиагностировать сеть в Linux и поддерживать в рабочем состоянии сетевую подсистему в Linux ).

Настройка TCP/IP в Linux для работы в сети Ethernet

Для работы с сетевыми протоколами TCP/IP в Linux достаточно наличие только петлевого интерфейса , но если необходимо объединить хосты между собой, естественно, необходимо наличие сетевого интерфейса, каналов передачи данных (например витая пара), возможно, какого-либо сетевого оборудования. Так же, необходимо наличие установленных ( , и др.), обычно поставляемые в . Так же необходимо наличие для сети (например /etc/hosts) и поддержку сети .

Параметры сети

Начнем понимание сетевых механизмов Linux с ручного конфигурирования сети, то есть со случая, когда IP адрес сетевого интерфейса статичен . Итак, при настройке сети, необходимо учесть и настроить следующие параметры:

IP-адрес - как уже говорилось в первой части статьи - это уникальный адрес машины, в формате четырех десятичных чисел, разделенных точками. Обычно, при работе в локальной сети, выбирается из частных диапазонов, например: 192.168.0.1

Маска подсети - так же, 4 десятичных числа, определяющие, какая часть адреса относиться к адресу сети/подсети, а какая к адресу хоста. Маска подсети является числом, которое складывается (в двоичной форме) при помощи логического И, с IP-адресом и в результате чего выясняется, к какой подсети принадлежит адрес. Например адрес 192.168.0.2 с маской 255.255.255.0 принадлежит подсети 192.168.0.

Адрес подсети - определяется маской подсети. При этом, для петлевых интерфейсов не существует подсетей.

Широковещательный адрес - адрес, используемый для отправки широковещательных пакетов, которые получат все хосты подсети. Обычно, он равен адресу подсети со значением хоста 255, то есть для подсети 192.168.0 широковещательным будет 192.168.0.255, аналогично, для подсети 192.168 широковещательным будет 192.168.255.255. Для петлевых интерфейсов не существует широковещательного адреса.

IP адрес шлюза - это адрес машины, являющейся шлюзом по-умолчанию для связи с внешним миром. Шлюзов может быть несколько, если компьютер подключен к нескольким сетям одновременно. Адрес шлюза не используется в изолированных сетях (не подключенных к глобальной сети), потому что данным сетям некуда отправлять пакеты вне сети, то же самое относиться и к петлевым интерфейсам.

IP-адрес сервера имен (DNS - сервера) - адрес сервера преобразующего имена хостов в IP адреса. Обычно, предоставляется провайдером.

Файлы настроек сети в Linux (конфигурационные файлы)

Для понимания работы сети в Linux, я бы обязательно посоветовал ознакомиться со статьей " ". В целом, вся работа Linux основана на , который рождается при загрузке ОС и плодит своих потомков, которые в свою очередь и выполняют всю необходимую работу, будь то запуск bash или демона. Да, и вся загрузка Linux основана на , в которых прописана вся последовательность запуска мелких утилит с различными параметрами, которые последовательно запускаются/останавливаются при запуске/остановке системы. Аналогично запускается и сетевая подсистема Linux.

Каждый дистрибутив Linux имеет слегка отличающийся от других механизм инициализации сети, но общая картина, думаю, после прочтения будет ясна. Если просмотреть стартовые скрипты сетевой подсистемы какого-либо дистрибутива Linux, то, как настроить конфигурацию сети с помощью конфигурационных файлов, станет более-менее понятно, например у Debian (за основу возьмем этот дистрибутив) за инициализацию сети отвечает скрипт /etc/init.d/networking , просмотрев который:

Net-server:~#cat /etc/init.d/networking #!/bin/sh -e ### BEGIN INIT INFO # Provides: networking # Required-Start: mountkernfs $local_fs # Required-Stop: $local_fs # Should-Start: ifupdown # Should-Stop: ifupdown # Default-Start: S # Default-Stop: 0 6 # Short-Description: Raise network interfaces. ### END INIT INFO PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" [ -x /sbin/ifup ] || exit 0 . /lib/lsb/init-functions process_options() { [ -e /etc/network/options ] || return 0 log_warning_msg "/etc/network/options still exists and it will be IGNORED! Read README.Debian of netbase." } check_network_file_systems() { [ -e /proc/mounts ] || return 0 if [ -e /etc/iscsi/iscsi.initramfs ]; then log_warning_msg "not deconfiguring network interfaces: iSCSI root is mounted." exit 0 fi exec 9<&0 < /proc/mounts while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network devices still mounted." exit 0 ;; esac case $FSTYPE in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs) log_warning_msg "not deconfiguring network interfaces: network file systems still mounted." exit 0 ;; esac done exec 0<&9 9<&- } check_network_swap() { [ -e /proc/swaps ] || return 0 exec 9<&0 < /proc/swaps while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network swap still mounted." exit 0 ;; esac done exec 0<&9 9<&- } case "$1" in start) process_options log_action_begin_msg "Configuring network interfaces" if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi ;; stop) check_network_file_systems check_network_swap log_action_begin_msg "Deconfiguring network interfaces" if ifdown -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; force-reload|restart) process_options log_warning_msg "Running $0 $1 is deprecated because it may not enable again some interfaces" log_action_begin_msg "Reconfiguring network interfaces" ifdown -a --exclude=lo || true if ifup -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; *) echo "Usage: /etc/init.d/networking {start|stop}" exit 1 ;; esac exit 0

можно найти несколько функций, проверяющих наличие подключенных сетевых файловых систем (check_network_file_systems(), check_network_swap() ), а так же проверку существования какого-то пока непонятного конфига /etc/network/options (функция process_options() ), а в самом низу, конструкцией case "$1" in и в соответствии с введенным параметром (start/stop/force-reload|restart или любое дугое) производит определенные действия. Из этих самых "определенных действий ", на примере аргумента start видно, что сначала запускается функция process_options , далее отправляется в лог фраза Configuring network interfaces , и запускается команда ifup -a . Если посмотреть man ifup , то видно что данная команда читает конфиг из файла /etc/network/interfaces и согласно ключу -a запускает все интерфейсы имеющие параметр auto .

The ifup and ifdown commands may be used to configure (or, respectively, deconfigure) network interfaces based on interface definitions in the file /etc/network/interfaces.

-a, --all
If given to ifup, affect all interfaces marked auto. Interfaces are brought up in the order in which they are defined in /etc/network/interfaces. If given to ifdown, affect all defined interfaces. Interfaces are brought down in the order in which they are currently listed in the state file. Only interfaces defined in /etc/network/interfaces will be brought down.

ip-server:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp allow-hotplug eth2 iface eth2 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254 broadcast 192.168.1.255

В данном конфиге строки allow-hotplug и auto - это синонимы и интерфейсы будут подняты по команде ifup -a . Вот, собственно, и вся цепь работы сетевой подсистемы. Аналогично, в других дистрибутивах: в RedHat и SUSE сеть запускается скриптом /etc/init.d/network . Рассматрев его, аналогично можно найти, где лежит конфигурация сети.

/etc/hosts

Данный файл хранит перечень IP адресов и соответствующих им (адресам) имен хостов .Формат файла ничем не отличается от мастдайного:

Ip-server:~# cat /etc/hosts # ip host.in.domain host 127.0.0.1 localhost 127.0.1.1 ip-server.domain.local ip-server 192.168.1.1 ip-server.domain.local ip-server

Исторически, данный файл использовался вместо службы DNS. В настоящее время, файл так же может использоваться вместо службы DNS, но только при условии, что в вашей сети количество машин измеряется в единицах, а не в десятках или сотнях, потому что в таком случае, придется контролировать корректность данного файла на каждой машине.

/etc/hostname

Данный файл содержит NetBIOS-имя хоста:

Ip-server:~# cat /etc/hostname ip-server

Данный файл хранит имена и адреса локальной и других сетей. Пример:

Ip-server:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 home-network 192.168.1.0

При использовании данного файла, сетями можно управлять по имени. Например добавить маршрут не route add 192.168.1.12 , а route add .

/etc/nsswitch.conf

Файл определяет порядок поиска имени хоста /сети, за данную настройку отвечают строки:

Для хостов: hosts: files dns Для сетей: networks: files

Параметр files указывает использовать указанные файлы (/etc/hosts и /etc/networks соответственно), параметр dns указывает использовать службу dns .

/etc/host.conf

Файл задает параметры разрешения имен для резолвера

Ip-server:~# cat /etc/host.conf multi on

Данный файл указывает библиотеке resolv - возвращать все допустимые адреса узла, которые встретились в файле /etc/hosts, а не только первый из них.

/etc/resolv.conf

Данный фал определяет параметры механизма преобразования сетевых имен в IP адреса. Простым языком, определяет настройки DNS . Пример:

Ip-server:~# cat /etc/resolv.conf nameserver 10.0.0.4 nameserver 10.0.0.1 search domain.local

Первые 2 строчки указывают сервера DNS . Третья строка указывает домены поиска. Если при разрешении имени, имя не будет FQDN-именем, то данный домен подставиться в виде "окончания". Например при выполнении команды ping host, прингуемый адрес преобразуется в host.domain.local. Остальные параметры можно почитать в man resolv.conf . Очень часто, в Linux используется динамическая генерация данного файла, с помощью т.н. программы /sbin/resolvconf. Данная программа является посредником между службами, динамически предоставляющими сервера имен (например DHCP client ) и службами, использующими данные сервера имен. Для того чтобы использовать динамически генерируемый файл /etc/resolv.conf , необходимо сделать данный файл символической ссылкой на /etc/resolvconf/run/resolv.conf . В некоторых дистрибутивах путь может быть другой, об этом обязательно будет написано в man resolvconf .

Настройка сети

Ознакомившись с основными конфигурационными файлами, можно посмотреть на . Выше уже говорилось о команде ifup , ifdown , но данные средства не совсем универсальны, допустим в дистрибутивах RH данных команд по умолчанию нет. Кроме того, в новых дистрибутивах появилось новое высокоуровневое средство управления сетью - , которая принадлежит пакету iproute. Ему (пакету iproute) я посвящу . А в текущем посте я его рассматривать не буду. Команды, описываемые ниже принадлежат .

Итак, чтобы быть уверенным в работоспособности команды в любом дистрибутиве Linux, необходимо пользоваться двумя основными командами-старичками. Это , и arp. Первая команда ( отвечает за настройку сетевых интерфейсов (ip, маска, шлюз ), вторая () - настройка маршрутизации , третья (arp) - управление arp-таблицей . Хочется заметить, что выполнение данных команд без отключения стандартного скрипта запуска SystemV сетевой подсистемы внесет изменения только до первой перезагрузки/перезапуска сетевой службы, т.к. если пораскинуть мозгами, то можно понять, что скрипт /etc/init.d/networking при очередном запуске перечитает указанные выше конфиги и применит старые настройки. Соответственно, выход для постоянной установки настроек - либо команда ifconfig с соответствующими параметрами - вписать в , либо поправить руками соответствующие конфиги сетевых интерфейсов.

Так же, если выполняется команда ifconfig с недостающими параметрами (например только IP адрес), то остальные дополняются автоматически (например бродкаст адрес добавляется по умолчанию с хостовым адресом, оканчивающимся на 255 и маска подсети по умолчанию берется 255.255.255.0).

Маршрутизация для имеющихся интерфейсов в современных ядрах всегда поднимается автоматически силами ядра. Вернее сказать, прямые маршруты в сеть согласно настроек IP и подсети, в которую смотрит поднятый интерфейс формируются автоматически, силами ядра. Поле gateway (шлюз) для таких записей показывает адрес выходного интерфейса или *. В старых версиях ядра (номер ядра с которого маршруты стали подниматься автоматом - не подскажу ) необходимо было добавлять маршрут вручную .

Если есть необходимость организовать свои маршруты , то необходимо воспользоваться . Данной командой можно добавлять и удалять маршруты, но опять же, это поможет только до перезапуска /etc/init.d/networking (или другого скрипта, отвечающего за сеть в Вашем дистрибутиве). Чтобы маршруты добавлялись автоматом, необходимо так же, как и с командой ifconfig - добавить команды добавления маршрутов в rc.local, либо поправить руками соответствующие конфиги сетевых интерфейсов (например в Deb - /etc/network/options ).

По каким правилам формируются маршруты к сетям , я в

Диагностика сети Linux

Существует большое количество инструментов диагностики сети в Linux, зачастую, они очень похожи на утилиты от Microsoft. Я рассмотрю 3 основные утилиты диагностики сети, без которых выявить неполадки будет проблематично.

Думаю, что данная утилита знакома чуть ли не каждому. Работа этой утилиты заключается в отправке т.н. пакетов ICMP удаленному серверу, который будет указан в параметрах команды, сервер возвращает отправленные команды, а ping подсчитывает время требуемое отправленному пакету, чтобы дойти до сервера и вернуться. Например:

# ping ya.ru PING ya.ru (87.250.251.3) 56(84) bytes of data. 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1 ttl=57 time=42.7 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=2 ttl=57 time=43.2 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=3 ttl=57 time=42.5 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=4 ttl=57 time=42.5 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=5 ttl=57 time=41.9 ms ^C --- ya.ru ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/avg/max/mdev = 41.922/42.588/43.255/0.500 ms

Как видно, из приведенного примера, ping выводит нам кучу полезной информации. Прежде всего , мы выяснили, что можем установить соединение с хостом ya.ru (иногда говорят, что "хост ya.ru нам доступен"). Во-вторых , мы видим, что DNS работает корректно , потому что "пингуемое" имя было корректно преобразовано в IP адрес (PING ya.ru (87.250.251.3)). Далее , в поле icmp_seq= указана нумерация отправляемых пакетов . Каждому отправляемому пакету последовательно присваивается номер и если в данной нумерации будут "провалы", то это нам расскажет о том, что соединение с "пингуемым" неустойчиво, а так же может означать, что сервер, которому шлют пакеты перегружен. По значению time= мы видим, сколько времени пакет путешествовал до 87.250.251.3 и обратно. Остановить работу утилиты ping можно клавишами Ctrl+C.

Так же, утилита ping интересна тем, что может позволить увидеть, где именно возникли неполадки. Допустим, утилита ping выводит сообщение network not reachable (сеть недоступна) , либо другое аналогичное сообщение. Это, скорее всего, говорит о некорректной настройке вашей системы. В таком случае, можно послать пакеты по IP-адресу провайдера, чтобы понять, в каком месте возникает проблема (между локальным ПК или "дальше"). Если Вы подключены к интернету через маршрутизатор, то можно послать пакеты по его IP. Соответственно, если проблема проявиться уже на этом этапе, это говорит, о неправильном конфигурировании локальной системы, либо о повреждении кабеля, если маршрутизатор отзывается, а сервер провайдера нет, то проблема - в канале связи провайдера и т.д. Наконец, если неудачей завершилось преобразовании имени в IP, то можно проверить связь по IP, если ответы будут приходить корректно, то можно догадаться, что проблема в DNS.

Следует отметить, что данная утилита не всегда надежный инструмент для диагностики. Удаленный сервер может блокировать ответы на ICMP запросы.

traceroute

Простым языком, команда называется трассировка маршрута . Как можно понять из названия - данная утилита покажет по какому маршруту шли пакеты до хоста. Утилита traceroute несколько похожа на ping , но отображает больше интересной информации. Пример:

# traceroute ya.ru traceroute to ya.ru (213.180.204.3), 30 hops max, 60 byte packets 1 243-083-free.kubtelecom.ru (213.132.83.243) 6.408 ms 6.306 ms 6.193 ms 2 065-064-free.kubtelecom.ru (213.132.64.65) 2.761 ms 5.787 ms 5.777 ms 3 lgw.kubtelecom.ru (213.132.75.54) 5.713 ms 5.701 ms 5.636 ms 4 KubTelecom-lgw.Krasnodar.gldn.net (194.186.6.177) 81.430 ms 81.581 ms 81.687 ms 5 cat26.Moscow.gldn.net (194.186.10.118) 47.789 ms 47.888 ms 48.011 ms 6 213.33.201.230 (213.33.201.230) 43.322 ms 41.783 ms 41.106 ms 7 carmine-red-vlan602.yandex.net (87.250.242.206) 41.199 ms 42.578 ms 42.610 ms 8 www.yandex.ru (213.180.204.3) 43.185 ms 42.126 ms 42.679 ms

Как видно, можно проследить маршрут от маршрутизатора провайдера 243-083-free.kubtelecom.ru (213.132.83.243) (Юг россии) до конечного хоста в www.yandex.ru (213.180.204.3) в москве.

dig

Данная утилита посылает запросы серверам DNS и возвращает информацию о заданном домене. Пример:

# dig @ns.kuban.ru roboti.ru ; <<>> DiG 9.3.6-P1 <<>> @ns.kuban.ru roboti.ru ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64412 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;roboti.ru. IN A ;; ANSWER SECTION: roboti.ru. 448 IN A 72.52.4.90 ;; AUTHORITY SECTION: roboti.ru. 345448 IN NS ns1.sedoparking.com. roboti.ru. 345448 IN NS ns2.sedoparking.com. ;; Query time: 102 msec ;; SERVER: 62.183.1.244#53(62.183.1.244) ;; WHEN: Thu Feb 17 19:44:59 2011 ;; MSG SIZE rcvd: 94

Команда dig послала запрос серверу DNS - ns.kuban.ru (@ns.kuban.ru - данный параметр указывать не обязательно, в таком случае источником информации о DNS будет взят сервер из настройки вашей системы) о доменном имени roboti.ru . В результате чего, получила ответ, в котором мы можем увидеть в разделе ANSWER SECTION информацию об IP адресах домена, в разделе AUTHORITY SECTION информацию о т.н. авторитетных DNS серверах. Третья строка снизу говорит нам о том, какой сервер предоставил ответ.

Другие утилиты диагностики

ping, dig и другие утилиты диагностики с параметрами, можно найти в посте .

Подключение новой сетевой карты

Подключение и запуск новой сетевой карты сводится к выполнению нескольких шагов:

1. Физическое подключение карты

3. Просмотр вывода на обнаружение системой новой сетевой карты:

Посмотрим вывод ДО подключения новой карты :

Server:~# dmesg | grep eth [ 4.720550] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.130191] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 15.285527] e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 15.681056] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

в выводе видно, что в системе есть 2 сетевые карты eth1 и eth2. Подключаем третью и смотрим вывод:

Server:~# dmesg | grep eth [ 4.720513] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.132029] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.534684] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection [ 39.274875] udev: renamed network interface eth2 to eth3 [ 39.287661] udev: renamed network interface eth1_rename_ren to eth2 [ 45.670744] e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 46.237232] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 96.977468] e1000: eth3: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

В dmesg мы видим, что появилась новая сетевушка - eth3, которая на самом деле - eth2, но переименована менеджером устройств udev в eth3, а eth2 - это на самом деле переименованная eth1 (об udev мы поговорим в отдельном посте). Появление нашей новой сетевой в dmesg нам говорит, что сетевая карта поддерживается ядром и корректно определилась . Осталось дело за малым - настроить новый интерфейс в /etc/network/interfaces (Debian), потому что данная карта не была инициализирована стартовым скриптом /etc/init.d/network . ifconfig данную карту видит:

Server:~# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 08:00:27:5f:34:ad inet6 addr: fe80::a00:27ff:fe5f:34ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:311847 errors:0 dropped:0 overruns:0 frame:0 TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:104670651 (99.8 MiB) TX bytes:16184 (15.8 KiB)

но опять же - не конфигурирует. Как конфигурировать сетевую карту говорилось выше.

Резюме

Думаю, на сегодня это все. Когда начал писать данную статью, думал что впишусь в один пост, но он получился громаден. Посему было решено разбить статью на две. Итого, я постарался изложить, не пошаговое хауту по настройке сети, а изложить принцип и объяснить понимание того, как же запускается и работает сеть в Linux. Очень надеюсь, что мне это удалось. Буду рад вашим комментариями и дополнениям. Со временем, буду статью дополнять.

После того, как Вы разделили на подсети свою сеть, Вы должны подготовиться к простому поиску адреса по имени, использующего файл /etc/hosts . Если Вы не собираетесь использовать DNS или NIS для этого, Вы должны помещать все хосты в файл hosts .

Даже если Вы хотите использовать DNS или NIS, можно иметь некоторое подмножество имен и в /etc/hosts . Например, если Вы хотите иметь некоторый вид поиска по имени даже, когда сетевые интерфейсы не запущены, например, во время загрузки. Это не только вопрос удобства, но также позволяет Вам использовать символические имена хостов в скриптах rc . Таким образом, при изменении IP-адресов, Вы должны будете только копировать обновленный файл hosts на все машины вместо того, чтобы редактировать большое количество файлов rc . Обычно Вы будете помещать все локальные имена и адреса в hosts добавлением их на любой gateway и NIS-сервер, если они используются.

Также при проверке Вы должны удостовериться, что сервер имен использует информацию только из файла hosts . Программное обеспечение DNS или NIS может иметь файлы примеров, которые могут дать странные результаты при их использовании. Чтобы заставить все приложения использовать исключительно /etc/hosts при поиске IP-адреса хоста, Вы должны отредактировать файл /etc/host.conf . Закомментируйте все строки, начинающиеся с ключевого слова order и вставьте строку:

order hosts

Конфигурация библиотеки сервера имен будет подробно описана в главе 6 .

Файл hosts содержит по одной записи на строку, состоящую из IP-адреса, имени хоста и необязательного списка псевдонимов. Поля отделяются пробелами или табуляцией, поле адреса должно начинаться в первой колонке. Все, что следует после символа #, расценивается как комментарий и игнорируется.

Имя хоста может быть полностью квалифицированным или заданным относительно локального домена. Для vale Вы ввели бы в hosts полностью квалифицированное имя, vale.vbrew.com , а также vale само по себе так, чтобы было известно и официальное имя и более короткое локальное.

Пример файла hosts для Virtual Brewery дан ниже. Два специальных имени, vlager-if1 и vlager-if2 , задают адреса для обоих интерфейсов, используемых на vlager .

Каково практическое использование файла /etc/networks ? Насколько я понимаю, в этом файле можно указать имена сетей. Например:

Root@fw-test:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 google-dns 8.8.4.4 root@fw-test:~#

Однако, если я попытаюсь использовать это сетевое имя, например, в ip утилите, он не работает:

root@fw-test:~# ip route add google-dns via 104.236.63.1 dev eth0 Error: an inet prefix is expected rather than "google-dns". root@fw-test:~# ip route add 8.8.4.4 via 104.236.64.1 dev eth0 root@fw-test:~#

Каково практическое использование файла /etc/networks ?

2 Solutions collect form web for “практическое использование файла / etc / networks”

Как написано на странице руководства, файл /etc/networks должен описывать символические имена для сетей. С сетью это означает сетевой адрес с хвостом.0 в конце. Поддерживаются только простые сети класса A, B или C.

В вашем примере запись google-dns неверна. Это не сеть A, B или C. Это отношение ip-address-hostname, поэтому оно принадлежит /etc/hosts . Фактически запись по default также не соответствует.

Предположим, у вас есть IP-адрес 192.168.1.5 из вашей корпоративной сети. Запись в /etc/network могла бы быть следующей:

Corpname 192.168.1.0

При использовании таких утилит, как route или netstat , эти сети переводятся (если вы не подавляете разрешение с флагом -n). Таблица маршрутизации может выглядеть так:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 corpname * 255.255.255.0 U 0 0 0 eth0

Команда ip никогда не использует имя узла для ввода, поэтому ваш пример вряд ли имеет значение. Также вы поместили имя хоста в /etc/networks , а не в сетевое имя!

Записи из /etc/networks используются инструментами, которые пытаются преобразовать числа в имена, например команду (устаревший) route . Без подходящей записи он показывает:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.254.0 U 0 0 0 eth0

Если теперь добавить строку mylocalnet 192.168.0.0 в /etc/networks:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 mylocalnet * 255.255.254.0 U 0 0 0 eth0

На практике это никогда не используется.

Go!

Протокол сетевой файловой службы (Network File Server, NFS) - это открытый стандарт на предоставление пользователю удаленного доступа к файловым системам. Созданные на его основе централизованные файловые системы облегчают ежедневное выполнение таких задач, как резервное копирование или проверка на вирусы, а объединенные дисковые разделы проще обслуживать, чем множество небольших и распределенных.

Кроме того, что система NFS предоставляет возможность централизованного хранения, oна оказалась весьма полезной и для других приложений, включая работу с бездисковыми и тонкими клиентами, разбиение сети на кластеры, а также для совместно работающего межплатформенного ПО.

Лучшее понимание как самого протокола, так и деталей его реализации позволит легче справиться с практическими задачами. Данная статья посвящена NFS и состоит из двух логических частей: вначале описывается сам протокол и цели, поставленные при его разработке, а затем реализации NFS в Solaris и UNIX.

С ЧЕГО ВСЕ НАЧИНАЛОСЬ...

Протокол NFS разработан компанией Sun Microsystems и в 1989 г. появился в Internet в виде документа RFC 1094 под следующим названием: «Спецификация протокола сетевой файловой системы» (Network File System Protocol Specification, NFS). Интересно отметить, что и стратегия компании Novell в то время была направлена на дальнейшее усовершенствование файловых служб. До недавнего времени, пока движение за открытые коды еще не набрало силу, Sun не стремилась раскрывать секреты своих сетевых решений, однако даже тогда в компании понимали всю важность обеспечения взаимодействия с другими системами.

В документе RFC 1094 содержались две первоначальные спецификации. К моменту его публикации Sun разрабатывала уже следующую, третью версию спецификации, которая изложена в RFC 1813 «Спецификация протокола NFS, версия 3» (NFS Version 3 Protocol Specification). Версия 4 данного протокола определена в RFC 3010 «Спецификация протокола NFS, версия 4» (NFS Version 4 Protocol).

NFS широко используется на всех типах узлов UNIX, в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. Будучи неизвестной за пределами сетевого «королевства», NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система.

ПРАРОДИТЕЛЕМ БЫЛ UNIX

Хотя NFS - платформенно-независимая система, ее прародителем является UNIX. Другими словами, иерархичность архитектуры и методы доступа к файлам, включая структуру файловой системы, способы идентификации пользователей и групп и приемы работы с файлами - все это очень напоминает файловую систему UNIX. Например, файловая система NFS, будучи по структуре идентичной файловой системе UNIX, монтируется непосредственно в ней. При работе с NFS на других операционных системах идентификационные параметры пользователей и права доступа к файлам подвергаются преобразованию (mapping).

NFS

Система NFS предназначена для применения в клиент-серверной архитектуре. Клиент получает доступ к файловой системе, экспортируемой сервером NFS, посредством точки монтирования на клиенте. Такой доступ обычно прозрачен для клиентского приложения.

В отличие от многих клиент-серверных систем, NFS для обмена информацией использует вызовы удаленных процедур (Remote Procedure Calls, RPC). Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу. Подробное описание NFS будет представлено ниже.

В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:

/root/usr2/ -> remote:/root/usr/

Если клиентскому приложению необходимы ресурсы этого каталога, оно просто посылает запрос операционной системе на него и на имя файла, а та предоставляет доступ через клиента NFS. Для примера рассмотрим простую команду UNIX cd, которая «ничего не знает» о сетевых протоколах. Команда

Cd /root/usr2/

разместит рабочий каталог на удаленной файловой системе, «даже не догадываясь» (пользователю тоже нет в этом необходимости), что файловая система является удаленной.

Получив запрос, сервер NFS проверит наличие у данного пользователя права на выполнение запрашиваемого действия и в случае положительного ответа осуществит его.

ПОЗНАКОМИМСЯ ПОБЛИЖЕ

С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.

Вначале клиентская команда mount взаимодействует со службой преобразования портов сервера, ожидающей запросы через порт 111. Большинство реализаций клиентской команды mount поддерживает несколько версий NFS, что повышает вероятность нахождения общей для клиента и сервера версии протокола. Поиск ведется, начиная с самой старшей версии, поэтому, когда общая будет найдена, она автоматически станет и самой новой версией из поддерживаемых клиентом и сервером.

(Излагаемый материал ориентирован на третью версию NFS, поскольку она наиболее распространена на данный момент. Четвертая версия большинством реализаций пока не поддерживается.)

Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.

Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF) 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF)

NFS традиционно реализуется на основе UDP. Однако некоторые версии NFS поддерживают TCP (в спецификации протокола определена поддержка TCP). Главное преимущество TCP - более эффективный механизм повторной передачи в ненадежно работающих сетях. (В случае UDP, если произошла ошибка, то полное сообщение RPC, состоящее из нескольких пакетов UDP, пересылается заново. При наличии TCP заново пересылается лишь испорченный фрагмент.)

ДОСТУП В NFS

В реализациях NFS обычно поддерживаются четыре способа предоставления прав доступа: посредством атрибутов пользователя/файла, на уровне разделяемых ресурсов, на уровне главного узла, а также в виде комбинации других методов доступа.

Первый способ основывается на встроенной в UNIX системе прав доступа к файлам для индивидуального пользователя или группы. Для упрощения обслуживания идентификация пользователей и групп должна быть единообразной для всех клиентов и серверов NFS. Защиту следует тщательно продумать: в NFS можно по неосторожности предоставить такой доступ к файлам, который не планировался при их создании.

Доступ на уровне разделяемых ресурсов позволяет ограничивать права, разрешив только определенные действия, независимо от принадлежности файла или привилегий UNIX. Например, работу с файловой системой NFS можно ограничить только чтением. Большинство реализаций NFS позволяет дополнительно ограничить доступ на уровне разделяемых ресурсов конкретными пользователями и/или группами. Например, группе «Отдел кадров» разрешается просмотр информации и не более того.

Доступ на уровне главного узла позволяет монтировать файловую систему только на конкретных узлах, что, вообще говоря, хорошая идея, поскольку файловые системы могут легко создаваться на любых узлах, поддерживающих NFS.

Комбинированный доступ просто объединяет вышеописанные виды (например, доступ на уровне разделяемых ресурсов с доступом, предоставляемым конкретному пользователю) или разрешает пользователям работу с NFS только с определенного узла.

NFS В СТИЛЕ «ПИНГВИН»

Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: .

Пакет nfs-utils содержит следующие исполняемые файлы: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.

К сожалению, иногда поддержка NFS вызывает путаницу у администраторов Linux, поскольку наличие той или иной функциональной возможности напрямую зависит от номеров версий как ядра, так и пакета nfs-utils. К счастью, в настоящее время положение дел в этой области улучшается: последние дистрибутивные комплекты включают самые новые версии и того, и другого. Для предыдущих выпусков в разделе 2.4 документа NFS-HOWTO приводится полный список функциональных возможностей системы, имеющихся в наличии для каждой комбинации ядра и пакета nfs-utils. Разработчики поддерживают обратную совместимость пакета с более ранними версиями, уделяя много внимания обеспечению безопасности и устранению программных ошибок.

Поддержку NFS следует инициировать во время компиляции ядра. Если необходимо, в ядро нужно добавить и возможность работы с NFS версии 3.

Для дистрибутивов, поддерживающих linuxconf, легко сконфигурировать службы NFS как для клиентов, так и для серверов. Однако быстрый способ установки NFS с помощью linuxconf не дает информации о том, какие файлы были созданы или отредактированы, что очень важно знать администратору для понимания ситуации в случае сбоя системы. Архитектура NFS в Linux имеет слабую связь с версией BSD, поэтому необходимые файлы и программы поддержки легко найти администраторам, работающим с BSD, Sun OS 2.5 или более ранними версиями NFS.

Файл /etc/exports, как и в более ранних версиях BSD, определяет файловые системы, к которым разрешен доступ клиентам NFS. Кроме того, он содержит ряд дополнительных возможностей, относящихся к вопросам управления и безопасности, предоставляя администратору средство для тонкой настройки. Это текстовый файл, состоящий из записей, пустых или закомментированных строк (комментарии начинаются с символа #).

Предположим, что мы хотим предоставить клиентам доступ только для чтения к каталогу /home на узле Lefty. Этому в /etc/exports будет соответствовать следующая запись:

/home (ro)

Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:

# exportfs -r exportfs: В /home (ro) не указано имя узла, введите *(ro) чтобы избежать предупреждения #

При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_ squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

То же самое можно просмотреть и с помощью команды showmount с параметром -e:

# showmount -e Export list for lefty: /home (everyone) #

Забегая несколько вперед, скажу, что команду showmount можно также использовать для определения всех смонтированных файловых систем, или, другими словами, чтобы выяснить, какие узлы являются клиентами NFS для системы, на которой запущена команда showmount. Команда showmount -a выведет все клиентские точки монтирования:

# showmount -a All mount points on lefty: 192.168.1.252:/home #

Как указывалось выше, большинство реализаций NFS поддерживает различные версии этого протокола. Реализация в Linux позволяет ограничивать список запускаемых версий NFS путем указания ключа -N для демона монтирования. Например, для запуска NFS третьей версии, и только ее, введите следующую команду:

# rpc.mountd -N 1 -N 2

Привередливым пользователям может показаться неудобным, что в Linux демон NFS (rpc.nfsd) находится в режиме ожидания пакетов версий 1 и 2, хотя это и достигает желаемого эффекта отказа от поддержки соответствующего протокола. Будем надеяться, что разработчики следующих версий внесут необходимые исправления и сумеют добиться большей согласованности компонентов пакета в отношении различных версий протокола.

«ЗАПЛЫВ С ПИНГВИНАМИ»

Доступ к сконфигурированной выше Lefty, экспортируемой файловой системе NFS на базе Linux, зависит от клиентской операционной системы. Стиль установок для большинства операционных систем семейства UNIX совпадает со стилем либо исходных систем Sun OS и BSD, либо более новой Solaris. Так как данная статья посвящена обеим системам, Linux и Solaris, давайте рассмотрим клиентскую конфигурацию Solaris 2.6 с точки зрения установления соединения с Linux-версией NFS, описанной нами выше.

Благодаря свойствам, унаследованным Solaris 2.6, ее легко сконфигурировать для работы в качестве клиента NFS. Для этого требуется лишь одна команда:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Предположим, что предыдущая команда mount выполнена успешно, тогда команда mount без параметров выведет следующее:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001

Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:

# tcpdump host lefty and host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny.2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access fh Unknown/10001 (DF) 06:07:43.491463 lefty.mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1/16777984 1048 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)

Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.

Хотя последовательность команд для доступа к удаленным файловым системам очень проста, ряд обстоятельств может привести к некорректному монтированию системы. Перед монтированием каталога точка монтирования должна уже существовать, в противном случае ее необходимо создать с помощью команды mkdir. Обычно единственной причиной ошибок на клиентской стороне является отсутствие локального каталога для монтирования. Большинство же проблем, связанных с NFS, обязано своим происхождением несоответствию между клиентом и сервером или некорректной конфигурации сервера.

Проще всего устранить проблемы на сервере с узла, на котором работает сервер. Однако, когда администрированием сервера занимается вместо вас кто-то другой, это не всегда возможно. Быстрый способ убедиться, что соответствующие службы сервера правильно сконфигурированы, - использовать команду rpcinfo с параметром -p. С узла Solaris Sunny можно определить, какие процессы RPC зарегистрированы на узле Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Заметим, что здесь же приводится информация о версиях, что достаточно полезно, когда для работы системы требуется поддержка различных протоколов NFS. Если какая-либо служба не запущена на сервере, то такая ситуация должна быть исправлена. В случае неудачного монтирования приводимая ниже команда rpcinfo -p позволит выяснить, что служба mountd на сервере не работает:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Команда rpcinfo очень полезна для выяснения, активен ли тот или иной удаленный процесс. Параметр -p - самый важный из ключей. Для ознакомления со всеми возможностями rpcinfo обратитесь к справочной странице man.

Другое полезное средство - команда nfsstat. С ее помощью можно узнать, обращаются ли в действительности клиенты к экспортируемой файловой системе, а также вывести статистическую информацию в соответствии с версией протокола.

Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:

# tcpdump host lefty and host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120 create ERROR: Permission denied (DF)

Вышеприведенный листинг, полученный после выполнения инструкции touch test.c, отражает следующую последовательность действий: сначала команда touch пытается получить доступ к файлу по имени test.c, затем она ищет каталог с этим же именем, а после неудачных попыток пытается создать файл test.c, что также не приводит к успеху.

Если файловая система смонтирована, то большинство типичных ошибок связано с обычными правами доступа UNIX. Использование uid или NIS+ в Sun помогает избежать глобального установления прав доступа на все файловые системы. Некоторые администраторы практикуют «открытые» каталоги, когда права доступа на их чтение даются «всему миру». Однако этого следует избегать по причинам безопасности. Даже отбросив в сторону проблемы защиты, все равно придется признать такой подход порочной практикой, поскольку пользователи редко создают данные с намерением сделать их доступными для чтения всем подряд.

Обращения привилегированного пользователя (root) к смонтированным файловым системам NFS трактуются по-особому. Чтобы избежать предоставления привилегированному пользователю неограниченного доступа, запросы от него трактуются так, как будто бы они поступают от пользователя nobody («никто»). Этот действенный механизм ограничивает доступ привилегированного пользователя глобально доступными для чтения и разрешенными для записи файлами.

СЕРВЕР NFS, ВЕРСИЯ SOLARIS

Конфигурирование Solaris для работы в качестве сервера NFS так же просто, как и в случае с Linux. Однако команды и местоположение файлов несколько отличаются. При начальной загрузке Solaris по достижении уровня загрузки 3 (run level 3) автоматически запускаются службы NFS и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:

#/usr/lib/nfs/mountd

Для запуска демона монтирования и сервера NFS введите:

#/usr/lib/nfs/nfsd

Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:

Share -F nfs /export/home

Мероприятия по обеспечению безопасности

БЕЗОПАСНОСТЬ В LINUX

Некоторые системные службы NFS на основе Linux имеют дополнительный механизм ограничения доступа посредством управляющих списков или таблиц. На внутреннем уровне этот механизм реализован с помощью библиотеки tcp_wrapper, которая для формирования списков контроля доступа использует два файла: /etc/hosts.allow и /etc/hosts/deny. Исчерпывающий обзор правил работы с tcp_wrapper выходит за рамки данной статьи, основной же принцип состоит в следующем: сопоставление вначале производится с etc/hosts.allow, а затем с /etc/hosts. deny. Если правило не найдено, то запрашиваемая системная служба не представляется. Чтобы обойти последнее требование и обеспечить очень высокий уровень безопасности, в конец /etc/hosts.deny можно добавить следующую запись:

ALL: All

После этого можно использовать /etc/ hosts.allow, чтобы установить тот или иной режим работы. Например, файл /etc/hosts. allow, который я использовал при написании данной статьи, содержал следующие строки:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192.168.1.0/255.255.255.0

При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:

Экспортируемый каталог {пробел} узел|сеть(опции)

«Экспортируемый каталог» - это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» - это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, - доступ только для чтения или преобразование идентификатора пользователя (user id mapping).

В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Другие примеры можно найти на справочной странице exports man.

БЕЗОПАСНОСТЬ NFS В SOLARIS

В Solaris возможности по предоставлению доступа к NFS аналогичны Linux, однако в этом случае ограничения задаются с помощью определенных параметров в команде share с ключом -o. Следующий пример показывает, как разрешить монтирование в режиме только для чтения /export/mcwrite.net на любом узле домена mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.

Ресурсы Internet

В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника - Bugtraq и CERT:

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

Иногда ошибки networks и другие системные ошибки Windows могут быть связаны с проблемами в реестре Windows. Несколько программ может использовать файл networks, но когда эти программы удалены или изменены, иногда остаются "осиротевшие" (ошибочные) записи реестра Windows.

В принципе, это означает, что в то время как фактическая путь к файлу мог быть изменен, его неправильное бывшее расположение до сих пор записано в реестре Windows. Когда Windows пытается найти файл по этой некорректной ссылке (на расположение файлов на вашем компьютере), может возникнуть ошибка networks. Кроме того, заражение вредоносным ПО могло повредить записи реестра, связанные с Microsoft Windows. Таким образом, эти поврежденные записи реестра Windows необходимо исправить, чтобы устранить проблему в корне.

Редактирование реестра Windows вручную с целью удаления содержащих ошибки ключей networks не рекомендуется, если вы не являетесь специалистом по обслуживанию ПК. Ошибки, допущенные при редактировании реестра, могут привести к неработоспособности вашего ПК и нанести непоправимый ущерб вашей операционной системе. На самом деле, даже одна запятая, поставленная не в том месте, может воспрепятствовать загрузке компьютера!

В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как WinThruster (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с networks. Используя очистку реестра , вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку networks) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра может резко повысить скорость и производительность системы.

Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск.

Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с networks (например, Microsoft Windows):

Нажмите на кнопку Начать .
Введите "command " в строке поиска... ПОКА НЕ НАЖИМАЙТЕ ENTER !
Удерживая клавиши CTRL-Shift на клавиатуре, нажмите ENTER .
Будет выведено диалоговое окно для доступа.
Нажмите Да .
Черный ящик открывается мигающим курсором.
Введите "regedit " и нажмите ENTER .
В Редакторе реестра выберите ключ, связанный с networks (например, Microsoft Windows), для которого требуется создать резервную копию.
В меню Файл выберите Экспорт .
В списке Сохранить в выберите папку, в которую вы хотите сохранить резервную копию ключа Microsoft Windows.
В поле Имя файла введите название файла резервной копии, например "Microsoft Windows резервная копия".
Убедитесь, что в поле Диапазон экспорта выбрано значение Выбранная ветвь .
Нажмите Сохранить .
Файл будет сохранен с расширением.reg .
Теперь у вас есть резервная копия записи реестра, связанной с networks.

Следующие шаги при ручном редактировании реестра не будут описаны в данной статье, так как с большой вероятностью могут привести к повреждению вашей системы. Если вы хотите получить больше информации о редактировании реестра вручную, пожалуйста, ознакомьтесь со ссылками ниже.