Стоит ли использовать NFS?

Очевидно же, что от клиентов и от целей зависит.

ещё как живо, если в клиентах преобладают линуксы-маки, то однозначно стоит

Стоит.

В клиентах пусто пока. Будет linux only.

Живо, стоит. Ещё загрузку рабочих станций по сети настрой раз уж такое дело.

Просто есть ещё выбор использовать Samba/FTP/WebDAV или что-то такое.

BOOTP?

NFS по сравнению с Samba и SFTP ресурсы маршрутизатора-сервера экономит, хотя если сервер → десктоп — уже не так актуально.

Судите сами: NFS обычно монтируется системой (с правами суперпользователя) и поддерживает все атрибуты POSIX-совместимых ФС (хотя полтора NFS-клиента в природе существует), а FTP и WebDAV предполагают наличие программы-клиента, хотя и могут быть смонтированы при помощи FUSE или какой-нибудь абстракции вроде KIO или GVFS.

WebDAV

для локалки - ни в коем разе

FTP

примитивно, для монтирования нужны костыли

Samba

тоже костыли, да и без виндов смысла нет

а так, nfs+autofs рулят

Ещё PXE сверху и самое то.

Однозначно стоит использовать NFS.

Вот под оффтопик, правда, родной клиент только в ынтырпрайз версиях почему то. (

под оффтопик

Не интересует.

По сути мне нужен только загрузчик и ядро, так? Как передавать параметры ядру?

А чем самба от NFS отличается принципиально?
Гуглил про, NFS ничего не понял... а самба вроде устраивает...

Живо, но несекурно. Если пропало соединение - клиент виснет.

Для связи дом - сервер(а) - рабочий комп использую fuse-sshfs

используй samba, тебе для этого ничего устанавливать не нужно.

Так винда тоже nfs понимает. Или я ошибаюсь?

Есть Services for UNIX, но с каждой новой версией они требуют более дорогой вариант windows. Последняя ставится на Enterprise и Ultimate, объявлена устаревшей.

Венда не нужна.

И правда:
Warning: Serious performance issues may occur (it randomly takes 30-60 seconds to display a folder, 2 MB/s file copy speed on gigabit LAN, ...) to which Microsoft does not have a solution yet.[1]

Производительность высокая. С правами будет путаница и локальный рут будет рутом и на удалённой ФС. Для уменьшения вероятности невозможности отмонтировать при отвалившейся сети можно использовать autofs. Если в сети есть виндос машины то для них может быть проще включить самбу.

И, да, когда я последний раз имел дело, были проблемы с офисом. С совместным использованием документа. То ли он не лочил открытый кем-то другим, то ли наоборот, лочил что то не так. Не помню.

С правами будет путаница

А если использовать авторизацию?

Надо мапить UIDы, или что-то в этом роде, иначе UID будет совпадать на локальной и на сервере. Но не помню, это уже сделали или нет. И если сделали то в четвёртой, а может и вообще нет.

Использовать то вроде стоит - ибо родное.

Другой вопрос что толкового best practics мануала по настройке nfs считай что нет. Особенно на фоне вот этого http://wiki.debian.org/SecuringNFS

When you set up a tight firewally, you go with the «deny all, allow some» paradigm. The SunRPC system was designed around the «trust the remote system» and the «make it simple for the admin, use dynamic ports» paradigm. Fortunatly, the services you use with NFS have port options to work better with your firewall.

Использовать то вроде стоит - ибо родное.

А если ничего не стоит и есть желание поставить NFS?

Просто сделай и попробуй. Его «поднимать» и особо не нужно. На сервере заполнил /etc/exports и стартовал nfs, или, если уже работает, просто сказал exportfs -r . На клиенте просто сказал mount 1.2.3.4:/path/to/share /mountpoint и готово, наслаждайся жизнью.

На сервере заполнил /etc/exports

Открыл холодильник, положил слона, закрыл холодильник. Легкотня чо

С правами будет путаница

Если только UID'ы и GID'ы пользователей различаются на разных машинах. Если обеспечить одинаковые UID'ы (например, средствами NIS, LDAP), то все будет отлично.

локальный рут будет рутом и на удалённой ФС

По умолчанию root мапится в nobody. Чтобы он был рутом и на удаленной ФС - это надо специально включать (no_root_squash в /etc/exports), и это очень не рекомендуется. Другое дело, что локальный root всегда может сделать su на любого пользователя и обращаться от его имени к его файлам на удаленной ФС.

NFSv4 вроде призвана решить обе эти проблемы, но не видел, чтобы где-то ее использовали. Похоже, NFSv4 повторяет судьбу NIS+.

NFS точно стоит использовать, когда клиентами выступают не пользовательские машины, а другие серверы:

• на серверах может быть зоопарк из разных коммерческих Unix'ов, а NFS работает везде;
• cервера обычно не выключаются - нет проблем с отмонтированием;
• рута тоже обычно пользователям не дают - решается проблема с безопасностью.
• автоматическое монтирование хомяков по NFS - очень удобная штука.

Открыл холодильник, положил слона, закрыл холодильник. Легкотня чо

Факт - кроме как /etc/exports ее реально особо настраивать не нужно.
NFSv3, по крайней мере.

Открыл холодильник, положил слона, закрыл холодильник.

$ cat /etc/exports
# see also /etc/sysconfig/portmap (control portmap)

/mnt/share/public/     *(rw)

Легкотня чо

Мне кажется, да.

Мне кажется, да.

Мой вариант содержит еще всяческие squach-и и no_wdelay.

Без последнего копирование на примонтированный nfs представляет из себя классическую синусоиду кеширования ... принимаем, принимаем, принимаем, ой клиент тормози, я сейчас тут всё на диск сброшу, ждем, ждем, ждем

NFSv3, по крайней мере.

Это тот который работает по ID пользователей ? Спасибо, нафиг не нужно.

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

да, конфиг можно и готовый найти, или самому составить.

Угу .. найти ... а хотелось бы нормальный толковый мануал с бест практикс и прочими объяснением магии, как я и писал выше.

Одно мапирование пользователей требует трех четырех вдумчивых страниц текста с описанием как это работает, за счет чего это работает и чем грозит.

Одно мапирование пользователей

Мне просто сказали: не парься, нереально.

NFSv3, по крайней мере.

Это тот который работает по ID пользователей ? Спасибо, нафиг не нужно.

Наоборот, используется в основном NFSv3. В ситуации «нафиг не нужно» оказалась как раз NFSv4 с его мапингами и секьюрностью. Упомянутое здесь отсутствие толковых мануалов с бест практикс это лишь подтверждает.
Секьюрность в NFSv3 была реализована SUN еще много лет назад (Secure RPC), и уже тогда это было не нужно. Все только плевались, потому что даже тривиальная смена Unix-пароля иногда вызывала проблемы.

NFSv3 небезопасен, NFSv4 монструозен. Если в ro, то однозначно стоит, если в rw - зависит от инфраструктуры

В ситуации «нафиг не нужно» оказалась как раз NFSv4 с его мапингами и секьюрностью

Использую только v4 - ибо синхронизировать ID или заводить по сути только для NFS какой либо LDAP нафиг не уперлось.

Секьюрность в NFSv3 была реализована SUN еще много лет назад (Secure RPC), и уже тогда это было не нужно.

Угу - я выше уже цитировал - «trust the remote system» офигенная секурность. Сказал, клиент что он ID=100, верим чо !

Все только плевались, потому что даже тривиальная смена Unix-пароля иногда вызывала проблемы.

Вы меня как то запутали, получается что секурность вообще нафиг не нужна что ли ? Тогда уж реально проще самбу юзать

NFSv4 вроде призвана решить обе эти проблемы, но не видел, чтобы где-то ее использовали.

RHEL 6.x

Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) supports safe asynchronous writes and a more robust error handling than NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2Gb of file data. NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an rpcbind service, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it. [/qoute]