Централизованная аутентификация с использованием NIS+, LDAP, ... - замечательная штука, товарищи, если реализована со следующими оговорками:
- Используется шифрование передаваемых данных;
- Используется репликация, предоставляющая возможность балансировки нагрузки на чтение и главное возможность получения failover(a).
Однако любое положительное начало в реальной жизни подпортит небольшая ложка дегтя - NFS. Рассмотрим ситуацию, когда LDAP используется для аутентификации shell-пользователей. В таком постановке задачи сразу назревает вопрос: "как обеспечить централизованное создание домашней директории пользователю, предположим, на десятке серверов? и как обеспечить централизованную синхронизацию информации в домашней директории между машинами?"
Наименее дешевым вариантом оказывается выбор NFS в качестве мастер хранилища и autofs в качестве средства автоматического монтирования. В этом случае пользователь заводится централизованно в каталоге LDAP и одновременно создается его домашняя директория с требуемыми правами. При подключении пользователя к машине по ssh или через getty она автоматически аутентифицирует его через LDAP и с помощью autofs монтирует соответствующую домашнюю директорию.
Все выглядит достаточно радужно, если выбросить из рассмотрения тот момент, что своими же руками мы ввели единую точку отказа - NFS. В случае сетевых проблем, проблем дисковой системы и недоступности NFS хранилища мы сразу обретаем массу незабываемых мгновений беготни с бубном вокруг ошибок возвращаемых системными вызовами при обращении к сетевому хранилищу или просто недоступностью раздела /home в случае монтирования с параметром hard.
Оглянувшись по сторонам на существующие решения можно заметить
NBD. Для полноценной эксплуатации потребуется задействование кластерной файловой системы OCFS2 или GFS. И на выходе получится решение аналогичное NFS только вид сбоку.
Подводя промежуточный итог, получаем, что нам необходимо хранение домашних директорий локальной на каждой машине. Только в этом раскладе удастся уйти от единой точки отказа в случае отказа мастер-узла.
Приходим к проверенному решению с использованием
rsync. Файлы по прежнему хранятся на мастер-ноде, но каждая машина с некоторым интервалом забирает их к себе в /home, обеспечивая единое пространство домашних директорий с необходимыми правами.
Из неудобств для пользователей выделяются:
- файлы, хранящиеся на мастер-узле всегда будут перезатирать локальные модификации. Например, если пользователь изменил файл локально и не изменил его на мастер-узле последующий запуск rsync благополучно затрет измения;
- файлы историй, вытекающие плавно из первого пункта. Например, если на мастер-узле по каким-либо причинам остался файл истории .bash_history вся локальная история вызовов будет уходить в пустоту;
- централизованные модификации синхронизируемых файлов необходимо производить на мастер-узле.
Оба неудобства решаются административно и в каждой конкретной ситуации существует компромиссное решение. Например, для файлов историй можно использовать скрипт, которые по заранее определенным шаблонам удаляет их на мастер ноде. В любом случае данный подход с технической стороны имеет больше прав на существование в сравнение с NFS решением.
