Никак не против Павла Kilevatyh лично, но в иллюстрацию простоты и прозрачности слакварного подхода. Надо сказать, вовсе необязательно ставить Slackware, чтобы исповедовать эту идеологию, в моём случае это был сервер с FreeBSD.
Понадобился как-то моему знакомому хостинг с движком вики, собственно mediawiki, как наиболее привычным.
Вообще, надо сказать, что сам я админ как раз вебсерверов на FreeBSD, но, во избежание каких-либо недоразумений, ничего левого на серверах не размещаю, потому я ему сказал, мол, извини, настроить на хостинге помогу, но место ищи сам (вопрос непокупания хостинга был там, насколько я понял, принципиален). Ну вот нашёл он по знакомым, где можно разместить, попросил объяснить админу, что нужно на хостинге. Выяснилось, что на его сервере тоже FreeBSD. "О, отлично", говорю я ему, "mediawiki есть в портах". А он отвечает: "Нет, из портов ставить не буду, я не ставлю софт, код которого не изучил на предмет уязвимостей, а оно зависимости тянет само". Нет, ну в общем-то, позиция, без зубоскальства, ответственная, правда несколько утопичная -- установка чего-то нового может растянуться на месяцы. Ну да ладно, в чужой монастырь со своим уставом...
Вот, кстати, информация о зависимостях
Port: mediawiki-1.5.8
Path: /usr/ports/www/mediawiki15
Info: The wiki engine used by Wikipedia
Maint:
gerrit.beine@gmx.de
B-deps:
R-deps: GraphicsMagick-1.1.6_1 expat-2.0.0_1 fontconfig-2.3.2_5,1 freetype2-2.1.10_3 ghostscript-gnu-7.07_15 gsfonts-8.11_2 jasper-1.701.0_1 jbigkit-1.6 jpeg-6b_4 lcms-1.14_1,1 libdrm-2.0.1_1 libiconv-1.9.2_2 libwmf-0.2.8.4 libxml2-2.6.24_1 mysql-client-4.1.19 pecl-imagick-0.9.11_4 php4-4.4.2_2 php4-iconv-4.4.2_2 php4-mbstring-4.4.2_2 php4-mysql-4.4.2_2 php4-pcre-4.4.2_2 php4-readline-4.4.2_2 php4-session-4.4.2_2 php4-xml-4.4.2_2 php4-zlib-4.4.2_2 pkgconfig-0.20_2 png-1.2.8_3 tiff-3.8.2 xorg-libraries-6.9.0
WWW: http://www.mediawiki.org/
В общем, в данном случае всё прошло сравнительно легко, где-то через неделю mediawiki худо-бедно заработала. Правда, зависимости поставлены были по самому минимуму и, например, при попытке вывести, список всех размещённых изображений, выпадала страница с ошибкой. А надо сказать, это было существенно, т.к. там размещались карты и наброски, обсуждение которых составляло немалую часть активности на сайте. Ну я поспрашивал админа, чего он не доставит зависимости, оказалось, у него они не собираются (что меня, в общем-то, не очень удивило, дело было год назад, а FreeBSD у него была 4.3, обновлять которую он отказался несмотря на аргументы об уязвимостях, обнаруженных в базовом коде FreeBSD тех версий). В общем, промаялись с этим сайтом несколько месяцев, а потом сервер упал пару раз по неделе каждый, и хостинг приказал долго жить...
Мораль сей басни такова: некоторые, на первый взгляд, правильные по задумке идеи имеют слишком много негативных последствий, чтобы безоговорочно и слепо им следовать. Скомпилированный статически апач будет иметь на полпроцента большую производительность, но будет куда менее гибок в сопровождении. Ручная установка зависимостей и сборка из тарболлов, с одной стороны, вроде бы повышает контроль за происходящим в системе, но с другой стороны, при использовании пакетного менеджера всегда можно изучить список установленых пакетов, да и удалить/обновить их при этом куда проще. А портаудит ещё и за уязвимости отследить поможет. Просмотр и изучение исходного кода всего устанавливаемого на сервер ПО, вроде бы, ultimate мера повышения безопасности, при ИТ-штате в одного админа абсолютно утопична. Во-первых, ко времени завершения анализа ПО уже будет просто неатуально, сроки (не внедрения -- лишь установки софта!) будут исчисляться хорошо если месяцами, да и просмотр кода админом -- не гарантия отсутсвия в нём уязвимостей или даже закладок.
