Разборки с Open Directory и его закономерная переустановка
Как на Дерибасовской, угол Ришельевской В восемь часов вечера разнеслася весть: Как у нашей бабушки, у бабушки-старушки, Шестеро налётчиков отобрали честь.
Я уже делился восторгом по поводу OS X Server.
Как не одно, так другое. Только решил вопрос вопрос с Messages, как перестал нормально работать Open Directory.
Началось с того, что внезапно перестали запускаться программы, которые я использую ежедневно — Sublime Text и Tower. Ради интереса захотел взглянуты в Console.app, и он тоже не запустился. Благо был запущен iTerm и я смог посмотреть на логи. В них была интересная запись о том, что моего uid не существует.
«Семь бед — один ресет», — сказал я, и перезагрузил Mac mini. Система долго не выключалась, понадобилась кнопка выключения питания.
После рестарта я с восторгом увидел красный кружочек возле поля ввода имени «Network accounts unavailable», который красноречиво говорил о проблемах с Open Directory.
«Боже, как я люблю развлекаться с починкой OS X Server вместо того, чтобы делать свою основную работу!», — воскликнул я. «Особенно когда мне позарез нужно работать…»
Зашёл под локальным администратором, которого создал при установке системы.
Просмотр логов дал представление, почему сервис недоступен сейчас (из-за выключения сервера по питанию повредились данные). Но почему вдруг он перестал работать ни с того, ни с сего до перезагрузки я не смог понять. Я просто работал с кодом, не влезал никуда, никаких системных команд не выполнял.
$ sudo view /var/log/slapd.log slapd[65]: bdb_db_open: database «dc=ceiling-cat, dc=ctrld, dc=me»: unclean shutdown detected; attempting recovery. slapd[65]: bdb_db_open: database «cn=authdata»: unclean shutdown detected; attempting recovery. slapd[65]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) slapd[65]: conn=22169 op=8: attribute «entryCSN» index add failure
По идее данные должны были восстановиться, попытка была сделана («attempting recovery»). Reboot. Система поднялась быстро, но OD снова не заработал.
Снова вход, System Preferences / Users & Groups / Login Options / Network Account Server / Edit. В Directory Utility начал играться с параметрами, менял адрес и т.п. Ничего умнее не придумал, кроме как отключить SSL для OD. Перезагрузил сервер — всё заработало, сетевые учётные записи стали доступны.
Всё бы хорошо, но через пару дней мне очень срочно нужно было сделать учётные записи для доступа по WiFi (Time Capsule использует WPA2 Enterprise с Radius на OS X Server). Привычно зашёл в Server.app и понял, что всё плохо. Список пользователей есть, но ни добавить, ни поменять ничего невозможно.
Workgroup Manager. Разлочить LDAP не могу, прекрасно известный мне пароль пользователя diradmin не проходит (специально сверился с Keychain). Приплыли…
Срочно изобрёл другую схему подключения через другие WiFi AP, пользователи смогли работать. Но это же не дело.
Начал разбираться. Если я ввожу неправильный пароль, то выдаётся ошибка в /var/log/slapd.log:
slapd[3528]: SASL [conn=1005] Failure: GSSAPI Error: Miscellaneous failure (see text (Decrypt integrity check failed)
При правильном пароле:
slapd[3528]: SASL [conn=1009] Failure: GSSAPI Error: Miscellaneous failure (see text (Decrypt integrity check failed for checksum type hmac-sha1–96-aes256, key type aes256-cts-hmac-sha1–96)
Мда, ну не хочу я разбираться с Kerberos. Отложил временно этот вопрос, благо остальное работало.
Прошло ещё несколько дней. Снова наступает запарка, и снова перестают открываться программы. «Боже, храни Apple!». Reboot. Система рестартовала сама. Снова красная херь рядом с вводом username. «Аллилуйя!»
Я укрепился в мысли, что вероятность падения OS X Server экспоненциально зависит от того, насколько он нужен в рабочем состоянии. Никому не нужен — значит работает стабильно. А если нужен позарез — так падает.
Диск я сразу проверил — никаких замечаний.
Углубление в лог /var/log/slapd.log:
slapd[73]: bdb (cn=authdata): file entryCSN.bdb has LSN 22/5598715, past end of log at 22/5526526 slapd[73]: bdb (cn=authdata): Commonly caused by moving a database from one database environment slapd[73]: bdb (cn=authdata): to another without clearing the database LSNs, or by removing all of slapd[73]: bdb (cn=authdata): the log files from a database environment slapd[73]: => bdb_idl_insert_key: c_put id failed: Operation not permitted (1) slapd[73]: conn=-1 op=0: attribute «entryCSN» index add failure slapd[73]: Unable to modify failedlogins for user authGUID=a8d6153e-d3b8–11e0–826c-c82a1455c9eb, cn=users, cn=authdata: 80 (null) slapd[73]: int slap_sasl_bind (Operation *, SlapReply *): Error to increment failed login count for uid=diradmin, cn=users, dc=ceiling-cat, dc=ctrld, dc=me slapd[73]: bdb (cn=authdata): DB_ENV→log_flush: LSN of 22/5598715 past current end-of-log of 22/5526526 slapd[73]: bdb (cn=authdata): Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment slapd[73]: bdb (cn=authdata): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery slapd[73]: bdb (cn=authdata): entryCSN.bdb: unable to flush page: 1 slapd[73]: bdb (cn=authdata): txn_checkpoint: failed to flush the buffer cache: DB_RUNRECOVERY: Fatal error, run database recovery
Какие к чёрту «caused by moving a database»??? Восстанавливаю двумя командами параллельно — db_recover и dump/load:
$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist $ sudo -i $ cd /var/db/openldap/authdata/ $ db_recover -v -h /var/db/openldap/authdata $ db_dump entryCSN.bdb > entryCSN.bdb.dump $ rm entryCSN.bdb $ db_load entryCSN.bdb < entryCSN.bdb.dump $ exit $ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
slapd запустился. Рестарт, Network Accounts доступны.
Снова пытаюсь зайти в Workgroup Manager — снова
kdc[102]: Client supported enctypes: aes256-cts-hmac-sha1–96, aes128-cts-hmac-sha1–96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1–96/aes256-cts-hmac-sha1–96 slapd[33641]: SASL [conn=1072] Failure: GSSAPI Error: Miscellaneous failure (see text (Decrypt integrity check failed for checksum type hmac-sha1–96-aes256, key type aes256-cts-hmac-sha1–96)
Не хочу возиться с Kerberos (дубль два)! Документации ноль. Нашёл пару команд в discussions.apple.com, запустил без явного понимания, при выполнении выдались ошибки:
sudo sso_util configure -r CEILING-CAT.CTRLD.ME -a diradmin -p «password» all sudo kdcsetup -f /LDAPv3/127.0.0.1 -a diradmin -p «password» CEILING-CAT.CTRLD.ME
Посмотрел на /etc/krb5.keytab, почесал в затылке. Попробовал снова авторизоваться в Workgroup Manager. Результат был и так предсказуем.
НАДОЕЛО!
Workgroup Manager, выделил все учётные записи. Меню Server, Export. Записал их в файл.
Сделал клон системного раздела с помощью SuperDuper!.
Server.app. Остановил все сервисы. Удалил Open Directory с сервера. Создал новый Open Directory Master.
Workgroup Manager. Импорт учётных записей. Само собой все пароли ушли в Валхаллу. Как хорошо, что у меня немного пользователей и я сам выдавал им пароли. Достал пароли из криптованного архива, установил. Поставил административные права для себя. Проверил, разрешён ли для пользователей доступ к сервисам.
Поднял сервисы. Перезагрузил сервер. В Workgroup Manager diradmin входит, все сервисы работают, в логах всё красиво.
А если бы пользователей были сотни? И сервер использовался для бизнеса?
Задумался снова перенести почту, WebDAV, файловые сервисы и т.д. на Linux.
Оц-тоц первертоц, бабушка здорова, Оц-тоц первертоц, кушает компот, Оц-тоц первертоц, и мечтает снова Оц-тоц первертоц, пережить налёт.
Полный текст статьи читайте на TheAppleGeek
