Re: [sisyphus] openldap vs fedora-ds

["Alexey Shabalin" <a.shabalin@gmail.com>]

13 сентября 2008 г. 7:20 пользователь Alexander Bokovoy написал:
> 2008/9/13 Alexey Shabalin <a.shabalin@gmail.com>:
>> 12 сентября 2008 г. 11:48 пользователь Guest007 написал:
>>> В сообщении от 10 сентября 2008 Guest007 написал(a):
>>> Кстати. Вот еще вопрос - гетерогенная (как сейчас принято говорить) сеть -
>>> клиентские машинки и виндовые и линуксовые. Как лучше организовать доступ к
>>> файлам? Если я правильно понимаю - общим будет только через самбу?
>> некоторые компании (думаю не будет рекламой, если назову в слух
>> Netapp), в своих продуктах предлагают доступ к одним и тем же данным
>> через разные протоколы: для *nix - nfs, для win - cifs. В своих
>> рекламках они расказывают, что "мапят" пользователей разных систем.
>> Я сам не пробовал, но думаю вполне можно такое же сдалать
>> самостоятельно на linux, для win - samba  с авторизацией в AD, для
>> *nix - nfs.v4 с авторизацией через kerberos, а на ФС использовать
>> расширенные acl, attr.
> Если пользователь авторизуется в AD, то на правильно настроенной Samba
> будет автоматически получен билет Керберос, которым смогут
> воспользоваться и другие приложения в системе, включая nfs.
>
> Если кто-то собирается использовать одновременно nfs и cifs
> применительно к одному и тому же ресурсу, то нужно озаботиться strict
> locking = yes в smb.conf, потому что иначе будут большие проблемы с
> когерентностью блокировок по nfs. К сожалению, nfs слабо приспособлен
> к передаче вменяемой информации о блокировках.
>
> В этом случае Samba будет делать дополнительные операции по
> принуждению к блокировкам после каждого запроса типа Read&X, а не
> только после Write&X. Это вызывает дополнительные накладные расходы,
> которые могут отражаться особенно серьезно на производительности
> распределенных файловых систем. Идеальным вариантом было бы
> реализовать ведение блокировок в nfs посредством ctdb, чтобы они были
> едины для samba и nfsd. Пока что это не сделано. Впрочем, с текущим
> состоянием cifsfs.ko в ядре можно вполне избавиться от NFS и
> поддерживать доступ из GNU/Linux клиентов полностью по cifs, особенно
> с включенной поддержкой CIFS Unix Extensions.

Согласен. Только вот есть один минус (для меня критический) - я так и
не смог подключить и использовать DFS-ресурс из altlinux.
Если не ошибаюсь эта экспериментальная фича в наших ядрах отключена.
DFS сервер на samba работает, а клиент нет.

>
> Что касается NFSv4 и всяческих расширенных атрибутов и POSIX ACL в
> файловой системе, здесь тоже много подводных камней и не в последнюю
> очередь из-за неэффективной реализации acl/attr в файловых системах.
> Как только они начинают использоваться для чего-то серьезного,
> оказывается, что их реализации не планировались для чего-то
> серьезного, а скорее делались "потому что остальные поддерживают этот
> функционал".



-- 
Alexey Shabalin