LINUX.ORG.RU

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


0

2

Почему-то всегда игнорировал NFS, считая ее устаревшей недо-сетью, и пользовался SMB.
А недавно, когда попробовал ее в деле, понял, что ошибался - какая все-таки это замечательная штука, ведь это же Сетевая ОС!

Но один вопрос оставил в недоумении - почему один (кажется) из используемых портов не статический, а пляшет как попало? Ведь это крайне неудобно при настройке файера.

Хотя и есть хавту, как сделать его статическим, но почему создатели NFS не сделали его таким сразу?

Ведь SMB, SSH, FTP и т.д. используют фиксированные порты, и это удобно в настройке.

★★★★★

Ответ на: комментарий от TERRANZ

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

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

chukcha ★★★★★
() автор топика

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 может ещё получить версии, то есть ему не надо будет выяснять, какие версии протокола поддерживаются.

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

mky ★★★★★
()

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

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

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

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

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

Rost ★★★★★
()
Ответ на: комментарий от Rost

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

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

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

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

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от sin_a

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

chukcha ★★★★★
() автор топика

Если позволите, еще вопрос по 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

и т.д.

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

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

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

sin_a ★★★★★
()
Ответ на: комментарий от chukcha

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

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

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

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

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

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

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

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

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

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

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

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

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

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

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

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от sin_a

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Это?

        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

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от sin_a

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от YAR

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

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

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

YAR ★★★★★
()
Ответ на: комментарий от YAR

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

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

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

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

YAR ★★★★★
()
Ответ на: комментарий от chukcha

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

/etc/init.d/nfs
/etc/init.d/netfs
/etc/init.d/nfs.client
...или как-нибудь еще.
У тебя видимо при загрузке ОС просто не запускается этот скрипт, вот и все.

bigbit ★★★★★
()
Ответ на: комментарий от chukcha

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

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

sdio ★★★★★
()
Ответ на: комментарий от chukcha

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

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

mukoh
()
Ответ на: комментарий от chukcha

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

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

man Kerberized NFS

mukoh
()
Ответ на: комментарий от bigbit

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

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Ага, кое-что таки удалось отыскать в 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 :(

chukcha ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.