Мне нужно некоторое управление пользователями для серверной фермы из +/- 30 серверов Linux. Обычно я думаю о чем-то вроде LDAP, но мы не хотим полагаться на глобальный сервер, на котором нам нужно пройти аутентификацию, в случае простоя или разрыва соединения.
Поэтому я подумывал написать несколько сценариев, которые синхронизируют / etc / passwd и / etc / shadow и проверяют, существуют ли домашние каталоги. Включая возможность исключить некоторых пользователей на некоторых серверах.
Но ... я не мог представить, что я единственный человек в мире, которому может понадобиться что-то подобное. Так кто-нибудь знает проект с открытым исходным кодом, который делает такие вещи?
Я все еще говорю о LDAP, даже с учетом ваших предостережений. Централизованная аутентификация с единой точкой отказа - это проблема, известная уже несколько лет, поэтому Windows отказалась от модели PDC / BDC WinNT и перешла на распределенную модель с несколькими главными серверами, как и в Active Directory. Novell eDirectory (среди прочего, очень хороший сервер LDAP) уже более 15 лет поддерживает работу с несколькими мастерами. Оба могут временно функционировать отдельно от остальной сети аутентификации, по медленным каналам глобальной сети и функционировать, несмотря на обычный процесс зависания / перезагрузки / восстановления, которым отмечены все ИТ. За исключением продолжительных простоев (день и более), эта проблема в значительной степени решена.
Просто не так много в пространстве с открытым исходным кодом, которое я видел. OpenLDAP имеет репликацию между несколькими серверами LDAP, что обеспечивает отказоустойчивость.
Немного разветвляясь, если у вас есть среда Active Directory для работы с Samba, вам будут предложены способы работы с AD, которые будут выполнять обработку идентификационных данных с несколькими мастерами. Если один DC не работает, он будет разговаривать с другими. Если вы не боитесь Samba 4, все еще находящегося в разработке, вы даже можете настроить полностью основанную на Linux среду AD и использовать winbind на своих клиентских серверах для обработки распределенной аутентификации.
Я не видел решения с открытым исходным кодом, но мы уже накатывали собственное. Относительно просто иметь root бегать rsync и синхронизировать /etc/passwd, /etc/shadow и домашние каталоги, содержащие авторизованные ключи SSH.
Однако следует иметь в виду одну вещь - "главную" копию /etc/passwd и /etc/shadow необходимо иметь подробную информацию обо всех пользователях во всех системах. Это означает, что если у вас есть одна машина с MySQL и другая с Apache, файл passwd / shadow должен содержать как mysql пользователь и www-data пользователь. Это приводит к тому, что на некоторых машинах в passwd / shadow больше записей, чем должно быть.
Еще одно замечание: лучше сделать это как можно раньше при развертывании / настройке, так как вы можете столкнуться с конфликтом UID при создании «мастера». Если вы реализуете это в системах, которые уже работают, вам нужно будет выяснить, какой пользователь имеет какой UID, и соответственно изменить права доступа к каталогам / файлам в каждой системе.
Самым простым решением было бы иметь главную систему и задание cron, которое запускается на отдельных узлах для регулярной синхронизации файлов passwd, shadow и group. Тем не менее, это похоже на мерзкий и грязный хакер.
В более широком смысле вы можете использовать кукольный как всеобъемлющий инструмент управления конфигурацией. Сюда входят учетные записи пользователей. Фактически вы определяете все атрибуты пользователя и членство в группах глобально. Затем для группы машин или для каждой машины вы определяете группы или отдельных пользователей, которые имеют доступ к системе. Поскольку аутентификация и авторизация выполняются локально, даже если ваш кукловод не работает, пользователи все равно могут войти в систему. Вы только потеряете распространение изменений.
Поскольку марионетка управляет только теми файлами и службами, которые вы явно определяете, она упрощает централизованное управление одними аспектами и локальное управление другими.
Вот почему Active Directory требует (ну, почти во всяком случае) несколько серверов. Так что, когда один из них умрет, вам не облажаться.
Если у вас есть база пользователей любого размера, вы не хотите полагаться на децентрализованное управление, даже если оно осуществляется через что-то вроде марионетки. Изменения и добавления ходов (MAC) не принесут удовольствия. Вообще. Кроме того, без централизованной аутентификации вам нужно будет управлять локальными учетными записями, учетными записями samba, учетными записями htaccess ... где вы / можете / централизованно аутентифицировать всех сразу.
Пожалуйста, пересмотрите централизованную аутентификацию для вашего собственного здравомыслия.
Хотел бы что-нибудь этот работай? Очевидно, они используют MySQL для масштабирования установки OpenLDAP и ее репликации.
Я думаю, что Kerberos также можно настроить для распространения. Это более старая статья это немного обсуждает об этом.
Я не знаю, есть ли в вашей сети какие-либо системы Windows AD, но если да, то можете настроить модули для аутентификации против этого.
Я по-прежнему считаю, что LDAP - это самый простой / лучший выбор. Безумно надежный, очень простой в обслуживании. Я безупречно использую пары LDAP ведущий / ведомый в производстве уже несколько лет. На моей предыдущей работе они обеспечивали аутентификацию для 20-30 серверов и сотен рабочих станций. Насколько мне известно, они никогда не выходили из строя в результате ошибки. Когда я намеренно переключался (перезагрузка / обновление / и т. Д.), Никто не замечал.
При этом существует решение, которое делает почти то же самое, что вы описываете, но с преимуществом централизованного управления: Шекелей. Он распределяет passwd, hosts, group и т. Д. По протоколу клиент-сервер, но, насколько я понимаю, полностью способен продолжать работать, если сервер уходит. Это немного сложно, но поддерживается всеми * nix-подобными ОС, которые я могу придумать.
LDAP - это замечательно, но он добавляет сложности, с которыми вы, возможно, не сможете справиться. Кроме того, вам нужно будет создать инструменты и средства управления конфигурацией на серверах для работы с LDAP. Хотя модули PAM (подключаемые модули аутентификации) в Linux имеют большое значение для поддержки некоторых из ваших потребностей, они могут не удовлетворить их все.
Я также мог бы предложить использовать что-то вроде кукольный (http://reductivelabs.com/products/puppet/). Хотя я нечасто его использовал, он может быть хорош в качестве комплексного решения для вас вместо LDAP или как средство для добавления инструментов и решения тех случаев, когда LDAP не поддерживает.
хотя это не очень хорошо, вы можете реплицировать базу данных ldap (или ее часть) на клиентах ldap (фактически, на серверах)
слабость этого заключается в том, что база данных повреждается при повреждении клиентов ldap, преимуществом является то, что у вас будет много реплик, что сделает ваши данные невероятно безопасными, и если соединение между главной и подчиненной базами данных разорвется, вы можете продолжить использование реплики. вместо
Я присоединюсь к остальным и предложу LDAP. Однако, если вам действительно нужны локальные файлы passwd, рассмотрите возможность создания их из LDAP. Вы можете либо сгенерировать их где-то централизованно, а затем распространить (puppet, rsync и т. Д.), Либо вы можете попросить каждого клиента создать свой собственный. Если сервер LDAP недоступен, локальный файл passwd все еще существует, чтобы вернуться к нему. Наличие там LDAP-сервера и поддержка информации позволяет вам продолжать и использовать или создавать инструменты, необходимые для обеспечения и управления пользователями, поэтому, если вы когда-нибудь решите доверять своей сети / настроить резервные серверы, у вас будет очень простая миграция. дорожка.