Сервер OSX 10.7 Lion и eDirectory - тонкости настройки

При переезде на новый сервер с операционкой версии 10.7 (а была 10.5) стали переносить на него настройки входа в дерево eDirectory. К дереву он подключался, однако авторизовываться в него не давал, при том что пользователей показывал исправно.

Решение нашлось, как известно, в интернете
Нужно открыть файлик /etc/openldap/ldap.conf вашим любимым текстовым редактором (желательно это делать из консоли от root)
Найти там строчку TLS_REQCERT demand
Исправить слово demand на never
В итоге у вас получается TLS_REQCERT never

После этого можно следовать пути, аналогичному для 10.5 - но в настройках DirectoryUtility обязательно нужно указывать галку "Использовать SSL", ибо в 10.7 небезопасная проверка пароля не прокатывает, а для работы безопасной как раз нужна правка файла настроек LDAP.

АИАС Директор 4.5.5 и Linux

Задаче переноса серверной части школьной базы данных на Linux оказалась одновременно тривиальной и не очень. Сделать это все же удалось — следующим образом:

Система АИАС Директор состоит из двух серверных компонентов: сервер базы данных и файловый сервер для приказов. Первое реализованно на firebird 1.5, второе — с помощью протокола FTP с несколькими оговорками.

Перенос firebird на linux не составляет труда: достаточно установить старую версию firebird с официального сайта (1.5.х, это важно, так как с более новыми версиями клиент будет работать нестабильно, в половине функций выпадая с ошибкой SQL запроса), настроить inetd (в моем случае — xinetd), скопировать файл базы данных из директории DataBase АИАС Директора. Я также прописал alias в базе alias-ов, чтобы иметь возможность в клиенте указывать короткий путь.

FTP часть оказалась сложнее. АИАС Директор передает FTP запросы по порту 5530, используя для имен файлов кодировку windows-1251 и символы backslash («\») для разделения элементов пути. Он авторизуется под именем пользователя 3CF43AD99B5944AF8C317BDAD23DC6A7 и аналогичным по виду паролем, которые возможно являются md5 или какими то еще хешами от какого то значения.

Практика показала, что для эмуляции можно использовать proftpd (версия 1.3.3g). Мне не удалось завести в систему пользователя с таким длинным именем, поэтому для авторизации я использую механизм AuthUserFile. Отдельно следует остановиться на замене backslash которые посылает клиент на обычные слеши.

Предложенный на сайте proftpd механизм не работает в случае восьмибитных символов — что то ломается в mod_rewrite при попытки сопоставления шаблона (.*) кириллическим символам, и в шаблон совпадает только с началом строки из некириллических символов (это один бэкслеш, который успешно заменяется на слеш). Попытка вместо шаблона (.*) применять сложные шаблоны с перечислением диапазонов по кодам символов также не увенчалась успехом.

Тем не менее, удалось заставить mod_rewrite все же делать то что нужно следующими директивами:

RewriteEngine on

RewriteMap replace int:replaceall

RewriteRule \\+ "${replace:!%f!\\!/}"

Здесь делается следующее:любая строка в которой содержится бэкслеш или несколько бэкслешей (\\+) заменяется на продукт замены бэкслешей на слеши служебной переменной proftpd %f, которая содержит имя файла уже пропарсенное движком демона. В результате, происходит корректное преобразование путей.

Для правильного сопоставления кодировок и указания правильного порта я также добавил в конфигурационный файл proftpd.conf следующие строки:

LangEngine on

UseEncoding utf8 cp1251

Port 5530

В остальном, конфигруационный файл остался без изменений.