[devel] [Fwd: Рассказ об установке ALTLinux]

Alexander Bokovoy =?iso-8859-1?q?a=2Ebokovoy_=CE=C1_sam-solutions=2Enet?=
Пт Янв 4 23:20:36 MSK 2002


On Fri, Jan 04, 2002 at 10:57:39PM +0300, Aleksey Novodvorsky wrote:
> -----------------------------------------------------------------------
> $Id: ОтчетОбУстановкеALT.txt,v 1.8 2001/12/21 02:03:06 cray Exp $'
> -----------------------------------------------------------------------
[skip]

>  -- MySQL потребовал установки PerlDB в обязательном порядка. Хотя обратная
>     ситуация была бы не лучше. Разумно ли существование такой зависимости:
>     MySQL не всегда используют вместе с Perl, может быть стоит ее подавить?
Perl-DBI требуют системные утилиты от MySQL-server:
/usr/bin/mysql_convert_table_format
/usr/bin/mysql_setpermission
/usr/bin/mysqlaccess
/usr/bin/mysqlhotcopy

Их можно было бы вынести в отдельный пакет (MySQL-server-utils), а
mysqlhotcopy вообще перенести в клиентскую часть, но там (на клиенте) возникнет
подобная же проблема. Есть предложения?


>  -- Никому в голову не придет ставить линух без пакета filesystem, но у нас
>     такое получилось: зависимости это допустили. Соотв., последующие пакеты,
>     используеющие каталог, например, /var/tmp, отказались ставится без
>     видимых причин: т.к. такой зависимости в них не было. Если нам не изменяет
>     память, это были все пакеты perl*;
Насколько я понимаю, речь не шла об установке последней версии, на которой
будет базироваться выходящий в январе ALT Linux Master? Ибо там filesystem
требуется для basesystem.

>  Ряд пакетов для перла нам пришлось добавить. Честно говоря, меня удивило,
>  что они не вошли в ваш дистрибутив, т.к. пакеты, вообще-то, весьма часто
>  используемые: нам приходилось по их поводу неоднократно вступать в, хм,
>  полемику с различными службами техподдержки провайдеров, и последние хотя и
>  не высказывали любви, но демонстрировали хорошее знакомство с ними.  Вот
>  список этих пакетов:
> 
>    perl-HTML-Template-2.4-iig1.src.rpm  - это знаменитый HTML::Template;
> 
>    perl-MIME-Base64-2.12-iig1.src.rpm - Кодировщик/декодировщик Base64;
> 
>    perl-MIME-Lite-2.117-iig1.src.rpm - Посылалка писем;     
> 
>    perl-MIME-Types-0.06-iig1.src.rpm - Определение MIME-типа по расширению;
> 
>  Мы собрали по вашим примерам для них rpm'ы, и, возможно это неплохо
>  получилось. Хотя мы вряд ли возьмемся их поддерживать, т.к. с перлом
>  работаем все меньше и меньше, но то что собрали можем передать вам:
>  выложить на ftp или закатать на болванку - как вам будет удобнее.
С этим проблем не будет, дополнительные модули для perl поддерживает
Григорий Милев (week на altlinux.ru), он без проблем возьмет их на себя.

>  Пришлось добавить группу пакетов для питона & Zope, про Zope 
>  подробно скажу ниже, про питон вот:
> 
>     MySQL-python-0.9.0-1.i686.rpm - сбсно, коннектор к MySQL. Питон для нас
> 	основной язык разработки, да и среда, с нашей точки зрения, должна
> 	быть целостной, навено разумно включить пакет в дистрибутив.  Наша
> 	поддержка возможна, если она актуальна. Кстати, коннектор к
> 	PostgreSQL, кажется у вас есть.
Включить в дистрибутив можно, проблемы не будет. 2LDV: как будет с
поддержкой?

>  Либо мы не нашли... Либо вы реально решили ничего такого не добавлять... 
>  Но ни одной хоть скольнить серьезной тулзы посвященной IP аудиту в
>  дистриутиве нет, за исключением каких-то малополезных функциональных
>  возможностей в одном из файерволов.
> 
>  Что забавно, такие утилиты существуют. Часть из них мы перетащили под 
>  Alt:
> 
>   ipaudit-0.92-0.src.rpm - счетчик & классификатор пролетающих мимо пакетов.
> 	Эксплуатация показала, что это весьиа качестенная реализация.
> 
>   ntop-1.3.2-5alt1.src.rpm - это из редхетовского дистрибъюшена. Красиво,
> 	реалтаймово, но бесполезно и глючно: подробных логов не ведет, часто
> 	падает, в общем, при разговорах с начальством штука бесполезная.
Скорее, руки просто не дошли.

>  У меня возник ряд вопросов относительно конфигурации пакетов по умолчанию:
> 
>  bind - удивил сконфигуренный по умолчанию сhaosnet. Чесгря, я думал, что это
> 	дела давно минувших дней, времен Lisp-машин и институтских сетей.
> 
>  чрутизация - не то, что бы я возражал.... Но были ли какие-то реальные
> 	эксплойты на mysql & bind, и стоит ли вообще-то овчинка, хм,
> 	выделки? Хотя удивило то, что чрутизация заняла столь мало места.
Благодаря минимизации затрат на реализацию более строгий вариант имеет
право на жизнь. От потенциальных эксплоитов мало кто защищен.


>  С Zope была чумовая история: несмотря на ваши заверения, у нас есть
>  серъезные опасения, что ситуация не изменилась, т.к. с Zope было два уровня
>  ошибок: скорее всего вы заметили первый, но если вы не эксплуатируете Z, то
>  вряд ли заметили второй.
С Zope серьезные проблемы именно по причине его неиспользуемости членами
команды. Если вы готовы проконсультировать или обозначить, что именно нужно, 
то никаких проблем с исправлением имеющихся ошибок не будет. Проблема
только с периодической поддержкой пакетов и обновлением.

>  =========
>  Apache
>  =========
> 
>  Я уже говорил что в апаче бага? В модуле mod_proxy. Честно говоря, у меня
>  так и не дошли руки поднять стенд и воссоздать тестовую ситуацию на вашем
>  русском апаче, но где-то дня через три его работы я увидел до боли знакомые
>  симптомы и Павел пересобрал апач с моим патчем, симптомы после этого прошли,
>  а к этому письму я прилагаю патч, описание баги, обоснование патча и
>  тестовый скрипт. Теперь к апачу претензий, вроде, нет. Хотя баги в этом
>  модуле, безусловно, еще есть - я не шучу, я вижу их проявления, просто это
>  не критично.
> 
>  Далее следуют подробности баги, взятые из нашей переписки с заказчиками,
>  если нужны дополнительные подробности, мы готовы их предоставить, также можем
>  предосавить ваш SRPMS вашего апача, в который патч уже добавлен :
Спасибо за обстоятельный отчет и исправление ошибки (каким бы простым оно
не было). Новая версия будет в Sisyphus на следующей неделе, там будут еще
исправления в httpd-perl.

>  Остальное - это уже скорее настройки под конкретное применение, и
>  представляют интерес скорее полемический, чем практический, а потому и
>  высказываются только в плане общей полемики:
>  
>  1. Представляется разумным, имея на борту дистрибутива две базы данных,
>  собирать все пакеты с их поддержкой, если таковая есть. Как пример приведем
>  ProFTPD... Зависимость в этом случае, видимо, лучше попробовать подавить.
Если приложение имеет поддержку модульности, то так и делать. Если нет --
придется делать виртуальный пакет, который будут предоставлять два
конфликтующих между собой пакета с поддержкой разных баз.

>  2. Представляется разумным, поставлять апач уже настроенный под виртуальный
>  хостинг и с несколько облагороженными ErrorMessage. Есть несколько
>  полуразумных вариантов такой настройки, есть и специальный модуль, и
>  настроить апач самим, конечно, не трудно, но зачем всем каждый раз
>  изобретать велосипед?  Не самый лучший вариант есть у нас, но, я думаю,
>  самостоятельной ценности он не представляет, а если такая работа будет
>  проводится - мы бы приняли участие, по крайней мере, в обсуждении.
Давайте вспомним об этом в феврале, раньше не будет времени.

>  3. Когда-то давным давно, лет, может быть, даже и 6ть назад, достаный
>  большим количеством файлов ~/.* , я попросил администратора того дуникса
>  дописать в /etc/passwd каталог .home после домашнего, а в .bashrc добавил
>  строчку
> 
> 	function cd () { if [ "$1" ]; then command cd "$1"; else command cd ~/..; fi 
> }
> 
>  и перестал все время видеть ~/.*.
> 
>  С тех пор это вошло в привычку. Позже, ситуацию сильно усугубило ~/.kde,
>  ~/public_html, gnome и ряд других аналогичных иерархий: похоже, мы
>  благополучно движемся к тому, что бы понятие "домашнего каталога"
>  разделить на два: каталог с профайлами и рабочий каталог по умолчанию. Свой
>  шаг в этом направлении я уже рассказал: он очень короткий, хотя многие
>  находят его удобным, а не известно ли вам каких-то более серъезных шагов в
>  этом направлении?  Правда, hier благополучно заминает вопрос планировки
>  домашних каталогов....
Имеет смысл подумать об этом в свете наших etcskel-*. Как и о добавлении,
скажем, bash-completion от Яна Макдональда (http://www.caliban.org/bash/).

>  4. Язык Ruby. Мы обратили внимание на этот пакет в дистрибъюшене, хотелось
>  бы узнать, кем и как он поддерживается. Мы им не пользуемся, но много
>  читали в прессе о проектах на его основе, часть из них представляет для нас
>  интерес, отсюда и вопрос.
Поддержка его сейчас перешла ко мне. Планирую поддерживать его и в
дальнейшем, поскольку он требуется для следующей версии нескольких
проектов, в которых я участвую. Пакет собирается в тесном сотрудничестве с
командой разработчиков Ruby.



-- 
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
  `Senior software developer and analyst for SaM-Solutions Ltd.`
---
Nov 21 20:58:58 alconost kernel: VFS: Busy inodes after unmount. 
		    Self-destruct in 5 seconds.  Have a nice day...




Подробная информация о списке рассылки Devel