Посылая почту с вложениями на русском языке в формате 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 рассмотрен тут.
и имя ему было 45. Выполненное на eDirectory, две реплики, платформа NetWare 6.с хвостиком (ниже 6.5). Вообще говоря так бы ему и стоять, дереву. Но ничто не вечно: мусор накопился на ветках, всякие ненужные trustee, модификации схемы, Древние Юзеры (не к ночи будут помянуты) - и было принято Высокое Решение Миграции. Но Решение - Решением, а делать то надо. Как показала практика, Мудрые Романтики (Novell-щики) держат при себе свои сокровенные знания, и постичь тайну Миграции читая нити Повсеместно Протянутой Паутины тяжело. Поэтому здесь, под тенью дерева eDirectory, я намерен записать свои скромные потуги в этом направлении - в помощь и назедание.
|
