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

Для разнообразия, я ненавижу автоматический запуск сервисов после установки.

// упоротый дебианщик

> Я уже как-то создавал тему о том, что в debian'е почти все сервисы после установки стартуют с неким конфигом по умолчанию, и это как бы не очень хорошо

Обоснуй.

Но сегодня я узнал о другой интересной штуке: веб-приложения автоматом добавляют свои конфиги в /etc/apache2/conf.d и делают ему reload.

Да, наверно нехорошо

Для разнообразия, я ненавижу автоматический запуск сервисов после установки.

// упоротый дебианщик

Просто ты правильно упорот, правильными веществами =).

> Обоснуй.

Стой, в смысле, сразу стартуют?

Обоснуй.

Знаешь, когда *внезапно* запускается свежеустановленный dhcpd и начинает раздавать адреса в локалку, то это немного напрягает. Имеенно из-за dhcpd я и создал ту тему. Тогда меня спасло только то, что дефолтный dhcpd.conf оказался несовместим с конфигом локалки =)

Ага, не так тебя понял сначала. Собственно, в данный момент тоже дебиан, но проверять влом

Обоснуй.

HAL может инициализировать устройства, которые отключены по каким-либо причинам, smartd «разбудит» усыплённые диски, mpd как общесистемный сервис не нужен, то же относится к bitlbee и didiwiki. Список не энтерпрайзный, но этого хватает мне.

Стой, в смысле, сразу стартуют?

Да. Делаешь apt-get install dhcp3-server и он сразу после установки стартует =).

> и он сразу после установки стартует =)

идиотизм)

Специалист^W Хорошему человеку неважно как там все автоматизировали :) Я лично не вижу разницы как работать с Apache'ем ни для FreeBSD, Solaris, Gentoo, CentOS...

Gentoo рулит.

Меня, гентушника, тоже бесит запуск демонов сразу после установки. Считайте что набижал упоротый гентушник в моём лице и начал доказывать, что правильно только так как сделано в Gentoo.

Именно поэтому адекватный мейнтейнеры добавляют /etc/default/daemon_name, в котором есть оцпия daemon_enabled, значение которой по дефолту false. Пример - saned.

Меня, гентушника, тоже бесит запуск демонов сразу после установки. Считайте что набижал упоротый гентушник в моём лице и начал доказывать, что правильно только так как сделано в Gentoo.

+1 =)

Что-то не устраивает? Стань меинтейнером сам! Это же опенсорс etc.

Что-то не устраивает? Стань меинтейнером сам! Это же опенсорс etc.

Меня не возьмут в мейнтейнеры дебиана =).

эм... никогда не юзал уеб приложения из реп...

P.S. nginx+passenger

>Для разнообразия, я ненавижу автоматический запуск сервисов после установки.

А это иногда очень даже полезно. Например, sshd. Я два раза ставил Debian на устройства, которые в принципе не имеют средств отображения, поэтому автоматом стартующий openssh-server, да еще и с по умолчанию разрешенным логином root был очень кстати.

Кстати, мне пришла в голову мысль о том, как можно костылём победить такое поведение postinst-скриптов:

ln -s /dev/null /etc/apache2/conf.d/conf-file-that-isnt-needed.conf

Юзайте KISS-дистры, арч же. Ничего само не стартует и ни в какие conf.d не лезет.

KISS тут тоже не очень подходит.

Юзайте KISS-дистры, арч же

Там тоже у ментейнеров проблемы, в частности пакет с slapd собран без бекендов, точнее только с тем, которым пользуется сборщик.

Там тоже у ментейнеров проблемы, в частности пакет с slapd собран без бекендов, точнее только с тем, которым пользуется сборщик.

Хе-хе, из всех виденных мной дистрибутивов, OpenLDAP нормально* ставится только в RHEL/CentOS, Fedora и Gentoo. Вот они, настоящие Ънтерпрайз-дистры!

* Не представляю жизни без оверлея smbk5pwd.

А потом апач будет лопатить тонны нулей в надежде прочитать конфиг?

А потом апач будет лопатить тонны нулей в надежде прочитать конфиг?

Не путай /dev/null и /dev/zero. Нули - в zero, а null - вечно пустой файл =).

>Кстати, мне пришла в голову мысль о том, как можно костылём победить такое поведение postinst-скриптов:

Все уже украдено до вас. man invoke-rc.d на предмет policy-rc.d. Разумеется, если сопроводающий сделал запуск скрипта не через invoke-rc.d, то его его в багзилле надо за это побить палкой, ибо

The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly.

4.2 dhcp в деюиане стартует с пустым конфигом о чем тебе говорит сразу после установки...

Настраивается пакет isc-dhcp-common (4.1.1-P1-9) ...
Настраивается пакет isc-dhcp-server (4.1.1-P1-9) ...
Generating /etc/default/isc-dhcp-server...
 * Starting ISC DHCP server dhcpd                                                * check syslog for diagnostics.
                                                                         [fail]
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
Настраивается пакет dhcp3-server (4.1.1-P1-9) ...

те что-то ты делаешь не так.. с апачем аналогично хрень какая-то..

4.2 dhcp в деюиане стартует с пустым конфигом о чем тебе говорит сразу после установки...

Значит уже поправили. Когда я ставил - в конфиге по умолчанию был конфиг для подсети 192.168.0.0/16. И если хоть один интерфейс настроен на эту подсеть, то dhcpd взлетал нормально.

те что-то ты делаешь не так.. с апачем аналогично хрень какая-то..

Попробуй поставить drupal из репозиториев. Я в первом посте даже ссылку на соответствующий багрепорт запостил.

Можешь даже просто поставить apache2 на чистую систему - он сразу стартанёт с конфигом по умолчанию и начнёт слушать на 80-м порту.

Кстати, мне пришла в голову мысль о том, как можно костылём победить такое поведение postinst-скриптов:

Все уже украдено до вас. man invoke-rc.d на предмет policy-rc.d. Разумеется, если сопроводающий сделал запуск скрипта не через invoke-rc.d, то его его в багзилле надо за это побить палкой, ибо

The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly.

Кажестя ты не понял в чём проблема. А проблема в том, что postinst-скрипты в дебиановских пакетах изменяют конфиг апача.

Ладно, фиг с ним. Проблему можно считать решённой =).

>Да. Делаешь apt-get install dhcp3-server и он сразу после установки стартует =).

А у меня не стартует (Debian Lenny). Я его вот сейчас специально удалил aptitude remove dhcp3-server (оставив конфиг). Потом aptitude install dhcp3-server. Сервис не запускается.

>А у меня не стартует (Debian Lenny). Я его вот сейчас специально удалил aptitude remove dhcp3-server (оставив конфиг). Потом aptitude install dhcp3-server. Сервис не запускается.

Это, наверное, из-за этого policy-rc.d. У меня этот скрипт имеется в /usr/sbin/policy-rc.d. В нем:

#!/bin/sh exit 101

Чего-то моя плохой совсем. Когда я его успел создать и создавал ли, не помню. Факт в том, что этот скрипт не принадлежит никаком пакету. Четыре года назад создан. :)

Сейчас я посмотрел историю изменений дебиановского dhcp3-server'а - походу у меня шизофрения...

Но тем не менее апач стартует сам и сразу, я только что проверил. Аналогично с drupal.

>Это, наверное, из-за этого policy-rc.d.

Точно, сейчас скрипт переместил из /usr/sbin/, удалил dhcp3-server и снова его постаавил. Тепреь сервис автоматом запускается после установки. :)

policy-rc.d

А где про него можно почитать поподробнее? В манах как-то расплывчато написано. Я правильно понимаю, что с твоим вариантом (#!/bin/sh exit 101) invoke-rc.d будет всегда завершаться _до_ реального запуска/перезапуска сервиса?

>А где про него можно почитать поподробнее? В манах как-то расплывчато написано. Я правильно понимаю, что с твоим вариантом (#!/bin/sh exit 101) invoke-rc.d будет всегда завершаться _до_ реального запуска/перезапуска сервиса?

С документацией на это ой как плёхо. Все сумбурно. Я действительно не знаю, хороша ли политика запуска сервисов после установки или нет и какие обоснования у нее. По-моему, Debian с такой политикой не одинок. Надо флеймы по этому поводу поискать.

Можно глянуть скрипт /usr/sbin/invoke-rc.d. И в документации, и в скрипте видно, что если policy-rc.d вернул на конкретное действие конкретного сервиса 101, то действие не выполняется. Если скрипт всегда будет возвращать 101 (что в моему случае), то любые действия после вызова invoke-rc.d будут запрещены, кроме, наверное, каких-то нестандартных (лень разбираться).

>правильно понимаю, что с твоим вариантом (#!/bin/sh exit 101) invoke-rc.d будет всегда завершаться _до_ реального запуска/перезапуска сервиса?

invoke-rc.d запускается в postinst скрипте, который сразу после установки пакета. Сервисы после установки пытаются запуститься через invoke-rc.d, но если стоит политика их не запускать, то они не запускаются и не стопарятся. При обновлении, соотвественно, в таком топорном случае, как у меня, тебе придется сервис вручную передергивать. И это не очень-то хорошо, когда на серверах security updates накатываешь.

И это не очень-то хорошо, когда на серверах security updates накатываешь.

Спорно. А если сервис критический и с ним прямо сейчас работают юзеры? А тут хлопс! Обновление с перезапуском -> все юзеры отваливаются. В общем такой подход где-то оправдан, а где-то вреден...

Поясню. Вот если этот policy-rc.d стоит и возвращает на все действия 101, то сервис во всемя aptitude remove, где в prerm запускается invoke-rc.d с действием stop это действие проигнорирует и останется висеть, потом у тебя произойдет обновление и перезапуск уже в postinst, который тоже проигнорируется. В итоге новый сервис-то поставится, но не запустится.

>Я действительно не знаю, хороша ли политика запуска сервисов после установки

Ну прикинь: купил роутер , воткнул и он работает.
Это ожидаемо у нормального человека ? - да.
Не, понятно, что есть иные люди и с иными потребностями , вот только сколько их ?

=)

Ну прикинь: купил роутер , воткнул и он работает.

Ага, вот именно из-за такого «plug & play»/«just works» в местной подсети городской локалки иногда работает аж до трёх dhcp-серверов кроме провайдерского. Пока не приедут инженеры провайдера и не настучат по шапке неосиляторам инструкции к роутерам =).

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

>Не, понятно, что есть иные люди и с иными потребностями , вот только сколько их ?

Я полагаю, что неприятие у ТСа вызывает тот факт, что сервис стартует после установки, когда он еще совершенно не настроен, т. е. ставится впервые.

Ну например ))
в энергетике есть состояние устройства «работают люди» и инфа с него блокируется по заявке на текущие или аварийные работы.
Ведь не факт, что еще его упражнения на сервере буду успешными или не затронут что-то там еще.

Ну, положим, это говорит только о том, что у них либо плохое сетевое оборудование, либо эти «анженеры провайдера» не осилили его настроить. Таким инженерам, пардон, только по квартирам и ездить.

Ну, положим, это говорит только о том, что у них либо плохое сетевое оборудование, либо эти «анженеры провайдера» не осилили его настроить. Таким инженерам, пардон, только по квартирам и ездить.

Кривость провайдера - это уже совсем другой вопрос.