Работа с доменом - почему CIFS?

Собственно, вопрос в названии темы - почему для работы с ресурасми домена выбрана CIFS? Для Windows-систем другого варианта нет - это понятно - но почему Linux-клиенты тоже его используют?
Вопрос возник потому, что такая схема создает некоторые проблемы:

  • при недоступном контроллера домена - долгая задержка загрузки (попытки монтирования);
  • при перезагрузке контроллера домена - пользовательский профиль не сохраняется, также неопределенная ситуация с подмонтированным с домена при загрузке каталогом;
    По моему мнению идеальным вариантом был бы вообще уход от CIFS для Linux-клиентов, и переход на что-то более устойчивое к сбоям сети, хотя бы тот же NFS (который при сбоях может восстанавливать связь без участия пользователя) для ресурсов домена и rsync (через rsyncd) для профилей.

Насколько я понимаю - увы, но только из-за желания разработчиков одним скриптом убить двух зайцев - потому-как в условиях работы в более-менее защищенном домене связка клиент-сервер на *nix по nfs проиграла-бы существующему решению только с точки зрения классической защищенности, существенно выиграв по всем остальным параметрам …

То есть объективных причин нет. Жаль, если так…

  • при недоступном контроллера домена - долгая задержка загрузки (попытки монтирования);

Задержка ставится для того, чтобы по dhcp успела подняться сетка. Т.к. после запуска демона wicd загрузка продолжается, параллельно поднимается сеть.

  • при перезагрузке контроллера домена - пользовательский профиль не сохраняется, также неопределенная ситуация с подмонтированным с домена при загрузке каталогом;

Я перезагружал samba, перезагружал сервер. Все пользователи после нескольких минут перекура продолжали работать, нормально выходя из сеанса при завершении сессии.

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

Зачем плодить сущности.

То есть объективных причин нет. Жаль, если так…

Помимо защищенности, Samba не дает поменять пользователю права файлов ресурса /Disks. Это удобно, т.к. предотвращает ситуации, когда по шалости одного пользователя, теряются права на файл у остальных.

  • при перезагрузке контроллера домена - пользовательский профиль не сохраняется, также неопределенная ситуация с подмонтированным с домена при загрузке каталогом;

Я перезагружал samba, перезагружал сервер. Все пользователи после нескольких минут перекура продолжали работать, нормально выходя из сеанса при завершении сессии.

В процессе переезда на CDS перегружал сервер не раз и не два - могу сказать, что не все так однозначно - чаще всего синхронизация проходит, но НЕ гарантированно - можно перегрузить CDS, дать пользователю отработать в системе часа три - и пронаблюдать как его профиль при выходе НЕ сохранился …

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

Зачем плодить сущности.

Затем, что под *nix NFS более “родная” с меньшим количеством глюков и более оптималной производительностью-быстродействием. Задайтесь вопросом - по какой причине подавляющее больнишство линуксовых админов предпочитают монтировать удаленный ресурс (в связке линукс-линукс) по NFS, а отнюдь не по SAMBA протоколам… NFS вылизанна задолго до того, как я или Вы начали заниматься линуксовыми системами, а SAMBA лижется и перелизывается по сей день. Очередной релиз на ней равнозначен очередному треску граблей по многочисленным лбам пользующих (правда с примечанием - пользующих развернутые, а не минимальные конфиги).

То есть объективных причин нет. Жаль, если так…

Помимо защищенности, Samba не дает поменять пользователю права файлов ресурса /Disks. Это удобно, т.к. предотвращает ситуации, когда по шалости одного пользователя, теряются права на файл у остальных.

Не очень понял данную мысль - с одной стороны применяемый в CDS подход “съел” большую часть вкусностей SAMBA - невозможность назначить четко определенные samba-параметры на определенную шару, применить “сетевую корзину” только для нужного ресурса и т.д., а с другой- Вы же сами утверждаете - ACL ! А ACL как-то безразлично. каким методом Вы к нему подключились - nfs, samba, ftp… он рулит правами на уровне ФС, все остальное ему “побоку” …

Samba не дает поменять пользователю права файлов ресурса /Disks

Специально в понедельник на работе проверю - но по “логике и классике” построения AD на SAMBA владелец как раз и должен иметь право выставить права доступа “как он желает”. Если есть желание “побороть” подобных пользователей - то в smb.conf есть параметры - force group и force user, НО! данное построение samba-шар опять! не дает возможности использовать их “по максимому” …

Чем-то напоминает спор Gnome/KDE. Сторонники Gnome полагают что пользователь не должен изменять до неузнаваемости рабочий стол и поведения программ. Разработчики KDE дают максимальную свободу.

Когда Вы говорите что пользовтаель должен иметь возможность закрывать определенные ресурсы на сетевой шаре, это хорошо. Только кого Вы этому будете учить и как Вы будете справляться с такими файлами, случайно заблокированными пользователями. В CL это разруливается сетевыми ресурсами (в пределах Disks). Один ресурс для логистов, другой для менеджеров, третий их общий и т.д. Кому-то можно только смотреть дизайны, кому-то с ними работать.

По поводу NFS и Samba. Я полностью согласен в том, что NFS работает быстрее. Правда cifs в этом плане значительно преуспел перед smb. С NFS многие любят работать, я даже знаю случай монтирования /home пользователей по NFS3 на все машины, и это в банке(!). Использование NFS не исключает применение Samba, а значит попросту дублирует. Плюс поведение работы с NFS ресурсом нужно сделать совместимым с Samba. Ну и не забывайте о безопасности.

Проблема появляется при работе в одной сети клиентов под Linux и Windows.
Самая распространенная - открываем файл в опеноффисе через NFS и вворде через сабма - начинаются глюки с правами, одновременным открытием ( например ворд или врайтер не орут что файл уже открыт на запись и начинают в него писать одновременно)
Да еще куча всего - щас не помню - надо записи смотреть.