среда, 2 апреля 2008 г.

nfs4 и samba - дружим доменами

При мигрировании, грамотно не ломать что либо сразу, а произвести плавный переход. Сначало плавно учимся привыкать к толстому OOo, а потом некоторую часть пользователей переводим на linux. Но перевод на linux не должен прерывать обмен данными с оставшимися пользователями. А у нас большое количество данных проходит через сетевые папки (некую файлопомойку с элементами упорядоченной структуры). Как знают грамотные люди, электронный документооборот требует не только покупки софта, а потому наша фирма пока еще пользуется таким способом работы.
Но вернемся к теме - linux, с некоторых пор, имеет поддержку nfs4, поддержку cifs он имеет с времен незапамятных. В свою очередь, nfs4 имеет поддержку протокола kerberos, ну а современные windows сети без kerberos не живут. Протокол kerberos пятой версии характеризуется хорошим механизмом отношений, или иначе "дружбой" сфер kerberos.
Я решил сделать как раз по этой схеме - у linux машин своя сфера kerberos, у windows - AD.
В общем я придумал три варианта:
1. Файловый сервер на машине с windows. Тут как раз нужно настроить дружбу доменов (сфер), а потом создавать пользователей два раза. Почему? Потому что это самый простой путь для подобной схемы - вы просто настраиваете отображение пользователей сферы linux в пользователей домена windows.
2. Файловый сервер на Samba и nfs4. В этом случае вы вводите машину с samba в домен windows, что, однако никак не отражается на самой системе сервера, просто теперь машины из AD смогут получить доступ к вашему серверу аутентифицируясь в AD. В то же время пользователи из сферы linux смогут получить доступ к файлам по протоколу nfs4, аутентифицируясь в linux сфере kerberos. Ключевым моментом схемы является отображение пользователей windows при помощи winbind - uid'ы пользователей AD не должны пересекаться с linux пользователями.
3. А можно не делать отдельную сферу kerberos для linux пользователей, можно аутентификацию и получение kerberos билетов организовать через домен AD. Тогда и проблем нет - делайте хоть на samba, хоть на windows сервере. Но мне не нравится это тем, что тогда отказаться от AD в дальнейшем не выйдет, и ничего то мы не сэкономим на подобном переходе. В общем я этот вариант не реализовывал.

При использовании второго варианта, доступ через nfs4 для linux машин более удобен и прост, так как монтирование по протоколу cifs(так называется протокол, используемый в windows среде) сетевой папки имеет некоторые недостатки:
1. ядро не имеет поддержки монтирования cifs шар с kerberos;
2. основанный на smbclient, smbfs имеет наприятные особенности;
3. если пользоваться, например, kde, то программы из этой среды смогут работать с сетевой папкой через kio-slaves, а вот OOo нет;
Таким образом, просматривать и скачивать файлы можно при помощи различных slaves (kde, да и гном что то такое имел в своем составе), а вот нормально работать только при использовании smbfs.

А вот конкретные настройки будут в следущей серии...

4 комментария:

Николай комментирует...

А не будет проблемы с синхронизацией, если одновременно к одному и тому же файлу получают доступ несколько пользователей по разным протоколам?

Deepwalker комментирует...

Это сложная тема, но думаю ничего хорошего не выйдет, не будет никакой синхронизации. Вы про byte range locking? Linux ничего такого в своем составе не имеет.

mmarkk комментирует...

загугли advisory lock. однако ж блокировки в NFS - те еще пляски с бубном. Впрочем, в оффтопике с блокировками не лучше. Нормальный софт не использует блокировку на сетевых фс. Вместо этого используется журнал + sync и запись типа append как и в больших распределенных ФС.

mmarkk комментирует...

А, ещё. NFS4 - Глючит несусветно. RHEL6 падает на ура, причем почему-то чаще всего именно сервер, а не клиент. в одном клиенте делаем рекурсивный поиск в большом каталоге (типа чрута убунты) а в другом делаем rm -rf этот каталог. УХ! ядро так и срёт кирпичами в дмесг. а потом падает. у одного из компов...

на NFS3 ничего такого не замечено.