Консоль Linux неприменима, когда сервер LDAP снижается
В дополнение к возможным предложенным проблемам файловой системы я видел это, когда файловая система SD-карты сжата. Копирование файла, который не сжимаем, может заставить копию перестать работать, несмотря на свободное пространство, о котором сообщают, являющееся больше, чем скопированный файл.
У Вас есть несколько вариантов.
Мы используем репликацию, чтобы иметь несколько серверов LDAP в сети, скрытой позади подсистемы балансировки нагрузки, поэтому если Вы идете вниз, мы все еще имеем тот в наличии. Мы используем keepalived для нашего выравнивания нагрузки. Можно также использовать keepalived в установке обработки отказа, где у Вас есть ведомое устройство горячего резервного копирования.
Во-вторых, у Вас может быть локальный сервер LDAP на каждой рабочей станции, но это приведет к высокой головной боли обслуживания, поскольку необходимо администрировать все их и контролировать их, чтобы удостовериться, что они не отстают от репликации. Вы не хотите, чтобы они упали из синхронизации.
Когда у Вас есть ведомый сервер, удостоверьтесь, что Вы устанавливаете свою updateref опцию так, чтобы любые предпринятые обновления были отправлены на главный сервер.
Существует несколько настроек в/etc/ldap.conf, который можно использовать для создания ситуации лучше. Самый важный:
bind_policy soft
Значение по умолчанию "твердо", который будет продолжать повторять для контакта с сервером с промежуточным ожиданием. При установке его на мягкий это сразу возвратится. Можно также использовать опции тайм-аута уменьшить количество времени, оно ожидает.
# Search timelimit
timelimit 30
# Bind/connect timelimit
bind_timelimit 30
-
1который укусил работавший? – David Pashley 19 August 2009 в 22:52
Я знаю, что у Вас есть принятый ответ от David, но я хотел бы предложить другой подход здесь и совместно использовать некоторые мои события.
Я нашел проблему с использованием bind_policy soft это, если Вы не получите ответ от сервера сразу же, скажете, например, что это занято, или у Вас есть высокая сетевая нагрузка, то Вы сразу получите отказ LDAP. Для nss_ldap это означает, что Ваш nss поиск перестанет работать и независимо от того, что процесс пытался использовать его, просто сообщит, что он не мог найти пользователя или группу, которую он искал и сбой. Это может быть проблемой во время нормального функционирования, когда Вы, на которых возрос Ваш сервер LDAP, какой IMO хуже, чем проблемы, когда Ваш сервер снижается.
Я нашел более приемлемое решение при помощи следующих настроек:
bind_policy hard
nss_reconnect_tries 3
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2
Таким образом, у Вас все еще будет трудная политика подключения, но nss_reconnect_* настройки решительно уменьшат количество времени, Ваш клиент LDAP потратит попытку получить результат LDAP. Это также означает, что во время нормального использования, если этому не удается получить результат LDAP на первой попытке, это попробует еще раз и обычно получать его во второй раз вокруг. Это означает меньше отказов во время нормальной эксплуатации.
До выполнения локального сервера LDAP на каждой рабочей станции я не рекомендую это. Что я могу указать, что Вы к вместо этого являетесь nsscache. Это было записано некоторыми инженерами в Google, и это решает эту проблему путем создания локального кэша базы данных LDAP и инкрементно обновления его через задание крона. Вы затем настраиваете свой nsswitch источник для пользований их библиотекой вместо nss_ldap, и все поиски локальны. Это имеет преимущество большого сокращения нагрузки на Ваш сервер LDAP и предоставления доступа ко всем поискам, если соединение с сервером снижается. Это не имеет самой замечательной документации прямо сейчас и не находится в широком употреблении, но это действительно работает хорошо, списки рассылки являются довольно быстро реагирующими.
У нас была эта проблема, и наше решение состояло в том, чтобы сказать LDAP не быть источником для групп, необходимых, чтобы серверы работали. Это сделано путем помещения следующего в конце нашего ldap.conf
# We need to ensure that various things can work without LDAP being available
# for example: booting, ssh in as root, apache ...
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,daemon,dhcp,dhcpd,games,gdm,gnats,haldaemon,hplip,irc,klog,libuuid,list,lp,mail,man,messagebus,munin,mysql,nbd,news,ntp,nut,polkituser,proxy,pulse,root,sshd,statd,sync,sys,syslog,uucp,www-data
Из nss_ldap страницы справочника
nss_initgroups_ignoreusers <user1,user2,...,userN>
This option directs the nss_ldap implementation of initgroups(3)
to return NSS_STATUS_NOTFOUND if called with a listed users as
its argument.
Таким образом, в основном LDAP притворяется, что не знает тех пользователей, даже не связываясь с главным сервером, таким образом, NSS возвращается к локальным пользователям, и система хорошо работает.
Мы также настроили копии LDAP в ряде серверов для подхода фигурных скобок и пояса.