При переезде на новый сервер с операционкой версии 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.
Задаче переноса серверной части школьной базы данных на 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.
Иногда у меня создается впечатление что все вокруг умные, а я один тут в белом хожу как дурак. Я не нашел почему в моем экземпляре 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 портированного под SLES вместе с OES2 выяснилось несколько любопытных особенностей.
- Изначально включена опция кросспротокольной блокировки файлов. Кроме полезных вещей, она не позволяет записывать удалять некоторые типы файлов (проблема появлялась при копировании любых файлов которые на самом деле папки, таких как .pkg или .app из под MacOS 10.5, копирование останавливалось на файле с названием Icon, удалить его после этого не выходило). Отключение опции устраняет проблему.
- Изначально включена опция передачи всей информации о правах. Ее применение в моем случае порождало много-много сообщений об ошибке в лог (после того как я включил логирование ошибок, разумеется). Переключение в режим передачи только основной информации о правах существенно (в 2 раза) снизило количество ошибок.
- В некоторых случая вскоре после перезапуска (/etc/init.d/novell-afptcpd restart) сервиса сервер зависает наглухо. Зависают X-ы, зависает ssh, зависает веб-сервер... Все, в общем то, зависает. Только пинги тихо идут.
Неисключено что последняя проблема вызвана тем что вопреки рекомендациям NSS том и системный том с помощью evms установлены на один физический диск. Неисключено что нам придется переделать рейд и вынести из него один диск под систему. Но объяснять оставшуюся проблему с копированием и удалением файлов этим я как то не решаюсь(ошибка -50 на клиенте, все том же MacOS 10.5, при копировании, точные симптомы которой выяснить пока не удалось - все зависло после одного из перезапусков afptcpd).
В королевстве туманно.
Не всегда хотят дружить программки от novell для SLES и для NetWare, ой не всегда.
Например, при установке OES2 в существующее дерево где master-репликой является NetWare сервер, не захотели настраиваться AFP и CIFS. Дело в том что настроечные скрипты на Shell, которые Yast запускает при настройке этих сервисов (из /opt/novell/afptcpd/bin/*.sh) не хотят дружить с LDAP-сервером NetWare, и говорят что соединиться с ним не могут. Yast же выдает ошибку "here are no password policies currently defined in eDirectory. To associate policies to users, plase re-configure AFP later using YaST after adding password policies and users to eDirectory.
AFP configuration will continue."
Проблема решается выносом из настройки LDAP адресов NetWare сервера (чтобы скрипты соединялись на SLESовский eDirecroty), либо переписыванием скриптов так чтобы вне зависимости от парметров командной строки подставлялся нужный сервер, либо запуском скриптов руками. Я сделал первое, пока не жалею.
На питоне. Дампит базы в отдельные файлы, состоит из библиотеки и собственно запускаемых скриптов. К имени файла дописывает время, жмет дампы в bzip2, ну или еще чемто. Хорошо работает по крону. Делает ротацию логов. Может дампить все базы с сервера, может дампить все кроме каких то, может выборочно, может таблицы отдельные исключать.
http://enmirneli.ms45.edu.ru/sqlbackup.tar.gz
Файлы:
- backup.py - библиотека, должна работать так
- sample.py - собственно сценарий архивации. Скопировать под другое имя и переписать так как нужно.
Можно через ARD или через SSH, можно без переводов строк
systemsetup -setusingnetworktime off;
ntpdate -d ntp.example.com;
systemsetup -setnetworktimeserver ntp.example.com;
systemsetup -setusingnetworktime on
Посылая почту с вложениями на русском языке в формате html с помощью скриптов, экспериментально выяснено как определяют кодировку вложений веб-интерфейсы mail и yandex.
Для того чтобы Yandex воспринимал кодировку адекватно, использовались тег <meta http-equiv='Content-type' content='text/html; charset=utf-8' /> и xml-декларация <?xml version="1.0" encoding="utf-8"?>
Для того чтобы Mail воспринимал кодировку адекватно, использовался заголовок с указанием кодировки в начале вложения: Content-Type: text/html; name=file.html; charset=UTF-8
В экспресс-тестировании приняли участие замечательные люди Витя и Ната, спасибо им.
Установка WebObjects на различные платформы довольно хорошо задокументирована в Сети, правда, на Английском языке, и, обычно, не последней версии. Поэтому, смею предложить еще одно такое описание.
Выполнялась установка WebObjects на Apache 1.3 на FreeBSD.
Предполагается что Apache уже установлен. Особой сложности установка этого сервера из портов не представляет. Если ставить на Apache 2.2, изменится часть 5 по настройке апача на адаптер.
Обновим коллекцию портов. Сначала, если cvsup не установлен (в ответ на команду csup говорят "чего?"), установим его командой pkg_add -r cvsup-without-gui. Возьмем файлик /usr/share/examples/ports-supfile и закопируем куда-нибудь, например в /root. Отредактируем его: найдем строчку *default host=CHANGE_THIS.FreeBSD.org и вместо CHANGE_THIS напишем какой-либо из реальных серверов. Список сервером здесь, http://www.freebsd.org/doc/handbook/cvsup.html#CVSUP-MIRRORS.
Завершив редактирование, включим обновление командой csup /куда закопировали файл/ports-supfile.
Очень важно обновить порты. Кроме очевидных проблем (старые дырявые версии программ), если не обновить порты, ставить яву очень тяжко, потому что ява будет просить вас скачать всякие файлы которые sun уже не дает скачивать напрямую. Если не хотите заниматься шаманизмом и изменением строки запроса в браузере с смутной надеждой выбить таки вожделенный файл, обновите.
Ставим яву. Идем в каталог /usr/ports/java/jdk16 (или не 16 а сколько там будет, ищите с самой большой цифрой). Пишем make. От консоли не открепляем, нам еще придется соглашаться с лицензией. С первого раза make не пойдет. Он будет долго просить вас скачать разные файлы с разных сайтов, ссылаясь на проблемы личензирования. Вам потребуется зарегестрироваться на сайте sun.com. После того как вы вознинавидите используемую солнечной компанией схему лицензирования, а make наконец запсутиться, можно дожидаться лицензионного сообщения, писать yes и идти пить кофе (если после того как вы написали yes make делает вид что завис, не пугайтесь, он работает, просто тихо). По завершении сборки пишем make install.
Ставим WebObjects. Идем в каталог /usr/ports/www/webobjects. Пишем make. Как и в случае явы читаем чего нам откуда скачать и почему, послушно качаем. В моем случае было написано что нужен файл pax.gz. Или я что то сделал нетак, или это наглая ложь, если положить этот файл, извлеченный из архива извлеченного из образа диска в /usr/ports/distfiles ничего не будет. Класть нужно сам образ диска, с помощью dd и perl make сам вытащит оттудова нужный файл. Нам же проще, не нужен mac. После того как скачали файлик снова делаем make. После него make install.
Ставим mod_webobjects. Идем в каталог /usr/ports/www/mod_webobjects. Пишем make, потом make install. На этот раз, слава богам, не придется ничего качать руками. Смотрим как модуль радостно прописывается в апач с помощью apxs. Коварно смеемся, потому что apxs делает это неправильно.
Правим настройку апача. Идем в конфиги апача, /usr/local/etc/apache/httpd.conf. Находим строчку AddModule mod_WebObjects.c. Вырезаем/удаляем ее. Находим чуть выше строчку AddModule mod_rewrite.c. Непосредственно после нее вставляем AddModule mod_WebObjects.c. Птом идем в конец конфига апача и дописываем там строчку Include /usr/local/etc/apache/webobjects.conf. В интернетах пишут что стандартная настройка WebObjects на /cgi-bin/WebObjects сводит апач с ума и надо это дело в файле /usr/local/etc/apache/webobjects.conf править на /Apps/WebObjects по всему файлу. Не знаю, у меня все и так работет.
Разрешаем грузить WebObjects при загрузке. В /etc/rc.conf пишем строчки wotaskd_enable="YES" (чтоб работали программки на webobject) и JavaMonitor_enable="YES" (если хотим монитор на этом компьютере).
Стартуем wotaskd и monitor вручную. Для этого /usr/local/rc.d/wotaskd start и /usr/local/rc.d/JavaMonitor start
Проверяем по http://server:1085/cgi-bin/WebObjects/wotaskd.woa должно выдвавть что то нечленораздельное полужирным шрифтом. По http://server:56789, если включен монитор, выдается монитор. Там надо сразу задать пароль во вкладке 'Preferences'
Дальше нужно найти знакомого программиста на WebObjects и стребовать с него Hello World. Как только у меня будет такая программа, я ее здесь выложу. Если вы сами знаете как писать под webobjects - тем лучше.
Для того чтобы ACL правильно передавался на Mac было сделано следующее.
1. Система с папками учеников расшарена по NFS для сервера на базе XServe
2. На XServe она подмонтирована из меню NFS Share в окне Sharing в Server Admin. Если монтировать из других мест в т.ч. консоли, не работает. При этом том занесся в локальную директорию сервера. Еще не выяснено, сохраняется ли это при перезагрузке, но есть надежда что да.
3. На XServe подмонтированная шара расшарена вновь по AFP.
Авторизация маков в дерево работает. Невероятно, но факт. Уже целый месяц.
Выявлены проблемы.
Проблема за нумером 1: Firefox не желает слушать нас. Мы говорим Firefox-у: друг! Сохраняй на рабочий стол который лежит на /Network/Servers/server/share/class/user/Desktop. Firefox говорит "Да да конечно". И пытается сохранять на стол /Users/Guest/Desktop. Но увы! Прав у него нет туда сохранять. И Firefox говорит "Аххаха жалкие людишки! Я не буду сохранять."
Проблема за нумером 2: ACL странно работают через стандартную сборку netatalk на Suse. Finder их не видит, и говорит, в чем-то созвучно Firefox-у: "Аххахаха жалкие людишки! Я не буду показывать вам эту папку - у вас нету прав!!!" Что любопытно и показательно, bash на том же компьютере не умничает, и по командам ls и cat спокойно читает содержимое недоступных для умного Finder-а директорий.
Что странно и страшно, проблема повторяется для SMB, на маке (на Windows все ОК), что пугает к осознанию того что, может быть, Netatalk понимает ACL, а не понимает их Finder.
Неприятно, но директивы perm:0777 и options:upriv не делают того что кажется должны делать. Применен ли патч на perm на версию netatalk собранную для Suse - неизвестно. В списке опций в комментариях AppleVolumes.default она есть, в мане - нету.
Намереваюсь пересобрать netatalk, для этого нужно будет доставить пару библиотек на Suse.
В королевстве туманно.
Ну разьве можно не любить технологии с такими звучными аббривеатурами...
Суть содеянного здесь.
От себя добавлю что
- Не работает замечательная, призванная уменьшить нагрузку на сеть штука под названием nscd. Это лечится прописью в файлик /etc/nscd.conf слов no напротив каждой записи enable-cache. (Нерабочесть заключается в сообщениях nscd: nds_nss_GetPwdbyName: init sock returned -1. Буду потом разбираться что за сокет такой, и чего это он не работает. Может нужно из под другог юзера запускать ее, а не из-под nobody.)
- Мешает отладке наличие директивы enable-persistent-cache=no в конфиге /etc/nam.conf
- К глубочайшему сожалению, NAM почему то не вытаскивает из директории юзеров с именами по 4 и менее буков. Учитывая, что SUSE вполне нормально с такими юзерами работает... Непонятно, в общем.
TRUSTBAR.NLM - Хоть что то работает как надо, и выдает результаты в приличный формат.
Ура! На нашем xServe сгорела PCIX сетевуха, теперь он не в локальной сети и проблема связи его с деревом временно отпадает... Попутно выясняется, что не каждая сетевуха подходит к xServe. Будем искать совместимую.
У меня одного ощущение что пароли в eDirectory хранятся несколько неочевидно? Есть пароль который simple. Он хранится в атрибутах sASLogin чего то там, числом два атрибута. Если вручную копировать значения обоих этих атрибутов, пароль копируется. Но: только в пределах одного сервера. Скопировать простой пароль таким способом не удалось. Еще есть пароль который universal. Он покрыт тайной и мраком. Есть политики паролей. В них можно сказать чтобы при установке universal пароля все остальные с ним синхронизировались. Это хорошо. При импорте юзеров из LDIF файла где было прописано поле userPassword установился пароль который simple. Universal и остальные пароли не поменялись. Это плохо. При запуске перлового скрипта, который заменяет тот же параметр userPassword пароль установился, как simple, так, похоже, и universal. Это странно. Мак при коннекте по afp может поменять simple пароль, не меняя universal. Это было бы весело, если бы не было так грустно. Необходимо больше думать.
Имеем: сервер Xserve (PowerPC G4, MacOS X 10.5), и сервер NetWare (OES2) и деревом. Задача: подружить второй с первым. По этой теме по нитям Повсеместрно Протянутой Паутины можно многое прочитать, но у меня получилось не с первого раза (если честно, до конца пока вообще не получилось, но свет виден). Хотелось бы заострить внимание на нескольких неочевидных вещах: - Если мы используем SSL, имеет смысл показать OpenLDAP на маке сертификат дерева (SYS:Public/RootCert.der, подробности тут)
- Опять же, если мы используем SSL, в настройках в DirectoryUtility на маке нужно в качестве hostname/ip писать то что писалось при установки OES как основной hostname. Мне для того чтобы это работало пришлось прописывать hostname и ip сервера в /etc/hosts.
- Мак это UNIX-подобная система, глубоко в душе. Чтобы добавить юзерам gidNumber И uidNumber (для номера юзера и группы соответственно), которые нужны маку, можно приделать к объекту пользователя расширяющий класс (например, posixAccount или специально созданный и внедренный в схему). Не реуомендую модифицировать определение класса юзер напрямую - печально получается, проверено.
Кроме всего этого, нужно еще настроить mapping атрибутов и объектов. Но об этом позже и с прикрепленным файлом.
Как показывает практика, откопировать кусок Дерева в какой-либо формат можно тьмой способов. Это и экспорт в LDIF (напрямую с помощью утилиты ice или через iManager или еще как нибудь), и такой же экспорт в текстовый файлик, и копирование с помощью embox, и оно же с помощью dsbk (единственный удачный), и, наконец, еще один бакап с помощью nwconfig и опции "prepare for какой-то там upgrape" подменю "Directory Maintaince". Последний метод позиционировался знающими людьми как безотказный и безопасный, но судьба распорядилась иначе... С него и начнем эту поучительную историю. Вообще говоря, как видно из названия этого пункта в меню nwconfig, эта опция предназначена для использования перед апгрейдом. Она блокирует базу данных (Дерево, то есть, что для сервера который все хранит в этом самом Дереве несколько печально). Хорошо блокирует, очень качественно. До последующего восстановления, с помощью соседнего пункта меню. Трюк состоит в том, что восстанавление можно будет запустить сразу после архивации, а потом, когда все умрет, запустить его еще раз. Весьма вероятно, что этот трюк работает, но мне повезло больше - при выполнении архивации nwconfig сглючил в момент выбора пути сохранения архива, сказал что все плохо и ничего архивировать он не будет, но дерево заблокировал. Поиски средства разблокировать грешную деревяшку обратно не принесли успехов (сейчас у меня есть предположение что его можно произвести поигрався с ключами команды dsbk, но тогда я об этом не подумал, а теперь уже поздно). В общем, заклинаю вас не использовать nwconfig для резервного копирования - он слишком таинственный. Команда dsbk действует, на мой взгляд, несколько проще, понятней и безопасней. Написав в консоли netware сервера dsbk help, вы сможете прочитать о возможных с помощью этой команды действиях. Общий принцип состоит в том что метод backup сохраняет все дерево в один файлик, а restore - считывает его из этого файлика. У каждого дейтсвия есть несколько опций: например я, как человек суеверный, при восстановлении указал что надо восстановить все что только можно (кроме юзерских файлов которые в архив не включались) и потом все что можно разблокировать. Формат файлов, создаваемых dsbk, весьма интересный. Сверху идет располагающий к себе xml-заголовок, который содержит имя сервера и дерева и предвещает легкий просмотр архива. За ним и до конца файла следует убийственный кусок двоичных данных. Восстановление такого архива прошло успешно, на том же сервере на котором он был выполнен. Восстановление его же на другом сервере, даже с редактированием xml-заголовка, свернуло серверу мозги и заставило его считать себя другим сервером. Не делайте так как сделал я в этом случае. Копирование в текстовый файл мной не применялось - как то не верится что этот файлик можно потом будет обратно в Дерево запихать, а именно такая задача ставилась и ставится. LDIF оказался форматом хорошим, до определенной степени. Он позволяет экспортировать кусок дерева в человекочитаемый, человекопонимаемый и человекоизменяемый формат (Ну хорошо, почти.. Какая-то штука для кодирования/раскодирования base64 все таки нужна, но она есть где то в комплекте поставки ConsoleOne, а я сам пользовался perl и соответствующим модулем MIME::base64). Экспорт осуществляется с помощью яМэнеджер-а, КонсолиОдин (просто и не работает, я вам еще напишу об этих чудесных программах) и консольного средства ice (скудная документация здесь, первый способ по сути является графической оболочкой над ice). В итоге, в моих условиях полуживого дерева (после nwconfig, см. выше), наиболее эффективным оказался вариант использования ice в консоли, а iManager-а в качестве справочного руководства по подготовке командной строки. Файлы в формате LDIF относительно легко вставляются обратно в Дерево (или в другое Дерево) с помощью того же ice. Два маленьких ньюанса: во первых, с помощью LDIF можно создать пользователю пароль (по крайней мере так пишут Мудрые, сам еще не пробовал), но вот вытащить в него пароль или хотябы его хеш (в целях миграции) нельзя. Во вторых, LDIF можно использовать для модификации схемы (экспортируйте b cn=schema и все увидите), но обойти с использованием этого метода ограничения типа "нельзя удалить объект с флагом неудаляемый" не получается. Синтаксис LDIF рассмотрен тут.
|
