Сервер 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

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

Гибридные сокеты

Сквид открывает гибридные (IPv6 и IPv4) сокеты. Из за этого он печально отказался работать после отключения в ядре FreeBSD опции INET6. Неожиданно. Сижу пересобираю ядро обратно. На случай если кому то это поможет найти быстрее и все понять, ошибка в логах была

comm_open: socket failure: (43) Protocol not supported

Ошибка в бруазере была

Система вернула: (43) Protocol not supported

Автоконфигурация прокси

Задача:

Сделать так чтобы настройки прокси-сервера на переносимых за пределы корпоративной сети компьютерах автоматически выставлялись на использование прокси когда компьютер внутри сети, и прямое соединение с интернет когда компьютер вне ее.

Решение:

Исследование показывает что не все браузеры адекватно отрабатывают определение собственного ip-адреса при исполнении .pac файла. Написано серверное решение, cgi-скрипт на языке perl, который в зависимости от адреса узла определяет какую версию файла выдать. Файл автонастройки прописан в свойствах MacOS и в настройках Opera. В Firefox выставлена настройка "Автоматически определять настройки прокси для этой сети", в сети настроен wpad, как по dhcp, так и по dns. Поддержка в IE не проверялась, но теоретически должно работать.

Исходный код скрипта:

!/usr/bin/perl
print "Content-type: application/x-ns-proxy-autoconfig\n\n";

my $remote = $ENV{'REMOTE_ADDR'};

if ($remote =~ /^192\.168\./) {
print <<EOF;
function FindProxyForURL(url, host) {
if (shExpMatch(url, "*.mydomain.ru/*")) {return "DIRECT";}
if (shExpMatch(url, "*.mydomain.ru/*:*")) {return "DIRECT";}
return "PROXY 192.168.1.2:3128";
}
EOF
} else {
print <<EOF;
function FindProxyForURL(url, host) {
return "DIRECT";
}
EOF
}


Добавлено в настройка apache (не совсем верно с точки зрения MIME):

AddType proxy/pac .dat
AddType proxy/pac .da
...
Action proxy/pac /cgi-bin/pac.cgi


Созданы пустые файлы в корне http-сервера:

wpad.dat
wpad.da


Создана запись cname в DNS где wpad.ms45.edu.ru указывает на сервер отдающий wpad.dat.

MacOSX 10.5 server quotactl

Иногда у меня создается впечатление что все вокруг умные, а я один тут в белом хожу как дурак. Я не нашел почему в моем экземпляре MacOS для управлением квотами есть только edquota, а quotactl нету. И библиотеки quotactl кажется тоже нету, хотя в C я не силен. Но edquota не удобна тем что плохо поддается автоматизации через всякие скриптики которые переделывают квоты 9000 пользователям за раз.

В общем я написал на перле ересь которая принимает аргументы как quotactl, потом вызывает edquota и делает что надо. Ценность этого продукта можете оценить сами: тут.

Строили и наконец построили

Для работы связки SLES 10 + OES 2 + NSS + afptcpd <=> Mac OS 10.5 сделано следующее:

• Чтобы убрать мертвозависания сервера, обновлен OES2. (Неожиданное решение, правда? Что характерно, разбиение рейда и установка NSS на отдельный том не устраняло мертвозавискний.)
• Чтобы убрать ошибки при которых MacOS и afptcpd начинали не сходиться в принципах именования файлов и из за этого не работало копирование/удаление, в свойствах тома NSS установлен namespace=unix ( с помощью nssmu)

Я не знаю, может все это очевидные вещи... Которые написаны в Novell-ских мануалах? А может быть тайное знание старейшин, которое по крупицам нужно собирать по novell-ским форумам?

По прежнему туманно в королевстве.

Особенности afptcpd потерявшего суффикс .nlm

При отладке afptcpd портированного под SLES вместе с OES2 выяснилось несколько любопытных особенностей.

• Изначально включена опция кросспротокольной блокировки файлов. Кроме полезных вещей, она не позволяет записывать удалять некоторые типы файлов (проблема появлялась при копировании любых файлов которые на самом деле папки, таких как .pkg или .app из под MacOS 10.5, копирование останавливалось на файле с названием Icon, удалить его после этого не выходило). Отключение опции устраняет проблему.
• Изначально включена опция передачи всей информации о правах. Ее применение в моем случае порождало много-много сообщений об ошибке в лог (после того как я включил логирование ошибок, разумеется). Переключение в режим передачи только основной информации о правах существенно (в 2 раза) снизило количество ошибок.
• В некоторых случая вскоре после перезапуска (/etc/init.d/novell-afptcpd restart) сервиса сервер зависает наглухо. Зависают X-ы, зависает ssh, зависает веб-сервер... Все, в общем то, зависает. Только пинги тихо идут.

Неисключено что последняя проблема вызвана тем что вопреки рекомендациям NSS том и системный том с помощью evms установлены на один физический диск. Неисключено что нам придется переделать рейд и вынести из него один диск под систему. Но объяснять оставшуюся проблему с копированием и удалением файлов этим я как то не решаюсь(ошибка -50 на клиенте, все том же MacOS 10.5, при копировании, точные симптомы которой выяснить пока не удалось - все зависло после одного из перезапусков afptcpd).

В королевстве туманно.