Вопрос по истории NFS

NFS != Сетевая ОС!

и таки первая ссылка в гугле
http://guruadmin.ru/page/razreshaem-klientam-nfs-dostup-k-nfs-serveru-ispolzu...

откройте для себя 9p2000

> и таки первая ссылка в гугле

Вопрос не понят: я спрашиваю не КАК, а ПОЧЕМУ?
См. выше.

NFS «пилился» под portmap, так как его делали SUN. В RFC 1833, описывающем протокол portmap'а есть следующий абзац:

A client program needs to know the RPC program number, version number, and the transport address corresponding to a service in order to utilize the service. Of these, the RPC program number and version number are usually built into the client program, as part of the service definition. The network address component of the transport address is usually available in a name service, or is given as a parameter to the client program. The transport selector (ie., the TCP or UDP port) is usually determined dynamically, and varies with each invocation of the service. Server programs allocate a transport address, and register it with a well-known lookup service (well-known because it uses a fixed transport selector, and resides at the same network address as the server). Client programs consult the lookup service in order to obtain the server's transport address.

Such a lookup service is very desirable because the range of well- known transport selectors is very small for some transports and the number of services is potentially very large. By running only the lookup service on a well-known transport selector, the transport addresses of other remote programs can be ascertained by querying the lookup service.

Суть сводится к тому, что портов мало (2^16=65000), а различных программ может быть очень много, portmap'у отдадим фиксированный порт, а остальные программы пронумеруем 32-х разрядным числом.

Причём, клиент через portmap может ещё получить версии, то есть ему не надо будет выяснять, какие версии протокола поддерживаются.

А про фильтрации портов в то время, ИМХО, особо не думали.

Почему пляшут «порты» — уже объяснили: так работает RPC.

Остался вопрос — почему NFS использует RPC, а не сразу TCP/IP?
Разве RPC - это не лишнее звено в цепочке NFS->RPC->UDP/TCP->IP?

Ну, наверное потому, что в Sun хотели сделать протокол NFS независимым от всего, от чего только возможно, в том числе и от протокола транспортного уровня.
Ведь спецификация RPC не «прибита гвоздями» к TCP/IP. Теоретически RPC можно реализовать поверх любого, в том числе и ненадежного, протокола (проблему надежной передачи сообщений RPC решает сам). Как, например, NFSv2 работал поверх UDP.
Ну и к тому же RPC, как и NFS, тоже разработали в Sun — почему бы не использовать, чего два раза велосипед изобретать :)

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

s/проще/лучше/

> это убьет совместимость. если сделать как вы предлагаете

Разве я что-то предлагаю? Автор топика задал вопрос, почему это не было сделано изначально, в момент разработки NFS, когда речь ни о какой совместимости не шла (т.к. других реализаций NFS еще не существовало). На него я и попытался ответить.

Спасибо всем, более-менее понятно.

Любопытно, сейчас, когда стал понятен один из недостатков «плящущих портов», будут что-то в этом плане менять, или все так и останется на веки вечные как дань былой недальновидности?

NFS вообще рассчитана только на работу в доверенной сети.

Иными словами, безопасность в ней не самый сильный ее конек.
Ок, еще раз большое спасибо всем! :)

Если позволите, еще вопрос по NFS, но уже по использованию.
Пользуюсь NFS успешно, но пока монтировал вручную из комстроки, например, так:

mount.nfs 192.168.1.5:/home/chukcha /mnt/chukcha


И все бы хорошо, но когда попробовал загнать монтирование в fstab, то ровным счетом никакого автомонтирования не происходит:

192.168.1.5:/home/chukcha /mnt/chukcha nfs ro

или
192.168.1.5:/home/chukcha /mnt/chukcha nfs auto 0 0

и т.д.

В чем тут может быть ошибка?

С такой записью в fstab, что выдаёт команда: mount /mnt/chukcha ?

Вообще, я предпочитаю automount, что бы не так зависеть от наличия сервера.

Эта команда ничего не выдала, просто тихо примонтировала шару

И при старте оно не монтируется?

Возможно когда отрабатывает монтирование ещё нет сети? Может быть стоит всё же посмотреть на autofs? Это монтирование при попытке обращения. Или man nfs на предмет fstab, кажется я слышал про какие-то параметры на этот случай.

Насчет того есть сеть или нет ничего не могу сказать кроме того, что:
а) сервер всегда включен
б) на клиентском компе запись о nfs находится в последней в списке

Насчет autofs... понимаете, мне как раз не хочется им пользоваться как относительно новой фишкой в линуксе, ее там вначале не было.

А вот fstab - древний как мамонт и был всегда как основа монтирования фс, и хотелось бы воспользоваться именно им, так мне спокойнее.

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

Пытался по обычным системным логам найти что-нибудь о поведении nfs, ничего не нашел.
Где вообще ведутся логи по nfs в сервере и клиенте?

> б) на клиентском компе запись о nfs находится в последней в списке

А когда монтируются файловые системы сеть уже работает? У меня есть сомнение. Искать, наверно, имеет смысл в логе загрузки - /var/log/messages, но сомневаюсь что там что-то будет, логи начинают писаться на смонтированную ФС, то есть fstab уже отработал, а он отрабатывает очевидно одним проходом. Разве что загружаться без сплеш и на ходу читать что происходит.

Autofs, кстати, тоже существует довольно давно. Она сделана именно для сетевых файловых систем, хотя одно время использовалась для сменных носителей, как CD-ROM.

> А когда монтируются файловые системы сеть уже работает?

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

Насколько понял из штудирования многочисленных мануалов, монтирование NFS с помощью fstab настолько тривиальная и простая задача, что ее упоминают лишь вкратце и никто ею особо не заморачивается, например:

http://www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-nfs...

Кстати, слеш у меня всегда отключен. И по нему видно, что с NFS ровным счетом ничего не происходит :)
Т.е. никаких ошибок загрузки не наблюдается.

Это?

        bg / fg        Determines  how  the   mount(8)
                      command  behaves  if an attempt
                      to mount an export fails.   The
                      fg  option  causes  mount(8) to
                      exit with an  error  status  if
                      any  part  of the mount request
                      times out  or  fails  outright.
                      This  is  called a "foreground"
                      mount,  and  is   the   default
                      behavior  if neither the fg nor
                      bg mount option is specified.

                      If the bg option is  specified,
                      a timeout or failure causes the
                      mount(8)  command  to  fork   a
                      child    which   continues   to
                      attempt to  mount  the  export.
                      The  parent immediately returns
                      with a zero exit code.  This is
                      known as a "background" mount.

                      If the local mount point direc‐
                      tory is missing,  the  mount(8)
                      command  acts  as  if the mount
                      request timed out.   This  per‐
                      mits  nested  NFS mounts speci‐
                      fied in /etc/fstab  to  proceed
                      in any order during system ini‐
                      tialization, even if  some  NFS
                      servers  are not yet available.
                      Alternatively these issues  can
                      be  addressed  using  an  auto‐
                      mounter (refer to  automount(8)
                      for details).

man nfs

Даже с гуглом не могу одолеть столько хитроумный текст :)
Подскажешь, о чем тут манится?

попробуй в параметры монтирования добавить bg

Попробовал, к сожалению, безрезультатно

А просто mount -a? Если смонтирует - значит, вероятнее всего сеть.

Ну как же сеть, если вручную монтируется без проблем...

И что значит «mount -a», куда его - просто вписать в fstab или как?

Это выполнить вместо mount /mnt/chukcha. Иначе говоря, попытаться смонтировать все, что должно монтироваться - так, как оно делается при загрузке системы.

А, т.е. типа смонтировать «all», т.е. «все», что в fstab

Да, по «mount -a» получилось - nfs-шары смонтировались!
Что же получается - сеть при загрузке оси клиента не успевает активизироваться, что ли?

Тогда почему этот случай (я бы сказал баг) нигде в мануалах по NFS не описан?
Ведь вот же, злобная бага налицо, а все мануало- и хавту-писаки как в рот воды набрали, пересказывают друг друг другу примитивную жалкую маунт-строку для fstab, которые привел выше, и все :(

хз, в моем теплом ламповом Debian'e монтирование явно 2 раза дергается, ибо в консоли видна ругань на неизвестный хост <имя сервера>, но в итоге все смонтировано на свои места.

Сетевые ФС из /etc/fstab как правило монтируются отдельно от локальных.
И этим как правило занимается отдельный стартовый скрипт.
В зависимости от дистрибутива он может называться:

/etc/init.d/nfs
/etc/init.d/netfs
/etc/init.d/nfs.client
...или как-нибудь еще.

chukcha> Иными словами, безопасность в ней не самый сильный ее конек.

NFS.v4 должен был решить все проблемы NFS.v2 и v3

> Любопытно, сейчас, когда стал понятен один из недостатков «плящущих портов»

Это «трудность настройки файера» имеется ввиду? Дык путевые «файеры» умеют понимать RPC и пропускать NFS без особого гимора.

>> NFS вообще рассчитана только на работу в доверенной сети.

Иными словами, безопасность в ней не самый сильный ее конек.

man Kerberized NFS

Спасибо за полезную информацию, узнал много интересного, и конечно, покопаю дальше эти скрипты, но не перестает беспокоить вопрос:
- почему в классических мануалах/хавту описываются случаи монтирования через fstab без малейшего намека на то, что при этом могут возникать таким проблемы? Не может же быть, чтобы я первый на них наткнулся, это нонсенс :-O

Ага, кое-что таки удалось отыскать в boot.log!

===
Запускаются службы NFS: [ OK ]
Запускаются квоты NFS: [ OK ]
Запускается демон NFS: rpc.nfsd: unable to create inet6 TCP socket: errno 97 (Address family not supported by protocol)
[ OK ]
Запускается NFS mountd: rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
===

Видно, что при старте демона nfs возникают какие-то негаразды с TCP/IP v.6.
Но эта суперновая шестерка мне и даром не надо, пусть работает по обычной четверке!
Чего увы, не наблюдается.

Мля, знать бы, кто только в Федоре приложил руку к такой кривой реализации NFS :(