Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)

2016-09-20 Пенетрантность yuri 


On Tuesday 13 September 2016 04:21:01 Dmitrii Kashin wrote:
> Victor Wagner  writes:
> > Можно предолжить эту систему проекту devuan или самому дистрибутив
> > форкнуть.
>
> Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве
> основной системы?
>
> У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную
> систему, но я довыпендривался с репами и, похоже, придётся впервые за 6
> лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли,
> на devuan полностью, или опять держать смешанную систему debian/devuan?
>
> Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего
> выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот
> потеря mpd лично мне не приятна очень. Привык я к нему.
>
> Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин
> под Devuan?

Здравствуйте!

 У меня большая часть поддерживаемых линуксовых машин под Devuan - штук десять 
серверов, десятка два десктопов с Devuan и Trinity, всякие роутеры, есть даже 
экзотика на PowerPC.
 Все работает без особых нареканий. Раньше ставил Debian и переключался на 
Devuan, с выходом беты ставлю сразу Devuan.

Так что однозначно советую.

С уважением, Соловьев Юрий

Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)

2016-09-12 Пенетрантность Stanislav Vlasov 
13 сентября 2016 г., 4:21 пользователь Dmitrii Kashin
 написал:
> Victor Wagner  writes:
>
>> Можно предолжить эту систему проекту devuan или самому дистрибутив
>> форкнуть.
>
> Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве
> основной системы?

На домашнем ноуте и на рабочем компе.
Работает нормально, но у меня и потребностей особых нет.

> Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего
> выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот
> потеря mpd лично мне не приятна очень. Привык я к нему.

Э...
$ apt-cache policy mpd
mpd:
  Установлен: (отсутствует)
  Кандидат:   1:0.19.9-dmo2
  Таблица версий:
 1:0.19.9-dmo2 0
500 http://www.deb-multimedia.org/ jessie/main amd64 Packages
 0.19.1-1.1 0
500 http://packages.devuan.org/merged/ jessie/main amd64 Packages
   -100 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

Вроде никто никуда не выкидывал.
При установке поставится libsystemd0, но для работы сам systemd не требуется.

> Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин
> под Devuan?

Стоит.

Правда, мне пришлось для того, чтобы работал apt-file search, делать следующее:

deb [targets=Translations] http://httpredir.debian.org/debian jessie
main contrib non-free

так как в merged репозитории не отдаются всякие Contents и т.п.
Ну и на всякий случай :

Package: *
Pin: origin "httpredir.debian.org"
Pin-Priority: -100

-- 
Stanislav

Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)

2016-09-12 Пенетрантность Дмитрий Фёдоров 
13 сентября 2016 г., 6:21 пользователь Dmitrii Kashin написал:
>
> Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве
> основной системы?

Да, на домашний ноут.
Ранее стоял debian/testing.
В devuan сломался переход в standby при закрытии крышки,
при запуске руками работает.
IMHO, это было завязано на systemd.

> Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин
> под Devuan?

Да.

Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)

2016-09-12 Пенетрантность Anton Kashcheev 
У меня стоит и на работе, и на ноутбуке (второй системой, первая Void), и
до недавнего времени стояла на настольнике. Перешёл сразу же, как только в
Дебиане по умолчанию начали поставлять systemd. Мне вполне сносно живётся,
хотя и стоит смесь ceres (sid), ascii (testing) и jessie. Выбешивает разве
то, что иногда траблы с обновлениями случаются (boost + mpi, например).

Тут уже как душа желает. Можете попробовать. :)

вторник, 13 сентября 2016 г. пользователь Dmitrii Kashin написал:
> Victor Wagner  writes:
>
>> Можно предолжить эту систему проекту devuan или самому дистрибутив
>> форкнуть.
>
> Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве
> основной системы?
>
> У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную
> систему, но я довыпендривался с репами и, похоже, придётся впервые за 6
> лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли,
> на devuan полностью, или опять держать смешанную систему debian/devuan?
>
> Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего
> выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот
> потеря mpd лично мне не приятна очень. Привык я к нему.
>
> Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин
> под Devuan?
>

Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)

2016-09-12 Пенетрантность Dmitrii Kashin 
Victor Wagner  writes:

> Можно предолжить эту систему проекту devuan или самому дистрибутив
> форкнуть.

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

У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную
систему, но я довыпендривался с репами и, похоже, придётся впервые за 6
лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли,
на devuan полностью, или опять держать смешанную систему debian/devuan?

Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего
выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот
потеря mpd лично мне не приятна очень. Привык я к нему.

Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин
под Devuan?


signature.asc
Description: PGP signature

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-31 Пенетрантность Victor Wagner 
On Wed, 31 Aug 2016 13:53:06 +0300
dimas  wrote:

> 2016-243 13:40 Victor Wagner  wrote:
>  [...]  
> да мне кажется, проще сделать тулзу/скрипт, которая будет вызываться
> один раз по хуку при установке (обновлении) пакета и генерить
> инит-скрипт, чем править sysvinit и каждый раз интерпретировать 

init править не надо. init все равно делает только то, что вызывает
внешний скрипт прописанный в inittab (интерпретатором которого
традицонно делается /bin/sh, но никто не мешает прописать в первой
строчке что-то другое).

А вот генерировать автоматически скрипты для /bin/sh нельзя. Ни в коем
случае. Каждого кто такое предлагает, следует заставить выучить
наизусть и продекламировать с выражением на площади скрипт configure от
какого-нибудь крупного проекта, например от postgresql, сгенерированный
именно таким способом с помощью autoconf. Скрипты для /bin/sh следует
писать только руками. И по этим рукам бить, если кто-то захочет сделать
этот скрипт чрезмерно многофункциональным или чрезмерно переносимым.

Тем более бесполезно пытаться генерировать автоматически шелловские
скрипты, предназначенные для последующей правки админом вручную. А
смысл init-скриптов именно таков, недаром они все помечены dpkg как
конфигурационные файлы (а service-файлы от systemd, кстати, нет).

Размер шелловского скрипта не должен превосходить где-то 80-100 строк.
Все что больше следует писать на более строгих языках, позволяющих
предотвратить больше ошибок. Шелловский скрипт должен быть обозримым и
понятным, с максимально простым control flow, иначе это чревато
ошибками, которые никакой компилятор не выловит.

А многие современные init-скрипты даже без /lib/init/functions вплотную
подошли к этому пределу безопасности. Поэтому исполлзовать вместо shell
другой язык, менее универсальный и более высокоуровневый было бы
осмысленно. 

Конечно, язык service-файлов плохой, страдает creaping
featurism и вообще сдизайнен как все у Поттеринга. Но зато на нем есть
готовая codebase.

> и то же. тем более, править инит не это надо чтоб майнтейнер захотел,

Можно предолжить эту систему проекту devuan или самому дистрибутив
форкнуть.


> принял правки и т.д., а приблуду-конвертер держи себе отдельным
> пакетом, и никому она мешать не будет
>

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-31 Пенетрантность dimas 
2016-243 13:40 Victor Wagner  wrote:
> Поэтому в первом же письме я предлагал воспольноваться тактикой embrace
> and extend - для нашего, правильного интерфейса сделать переходник
> (интерпретатор), который позволит ему использовать service-файлы от
> systemd.
> 
> Ну и соответсвенно каждая система инициализации должна будет внутри
> себя поддержать тем или иным образом этот интерфейс.
> 
> Для sysvinit это просто - нужно только insserv подправить что  при
> генерации зависимостей умел не только читать LSB-style комментарии, но
> и вызывать скрипт согласно протоколу.
да мне кажется, проще сделать тулзу/скрипт, которая будет вызываться один раз
по хуку при установке (обновлении) пакета и генерить инит-скрипт, чем править
sysvinit и каждый раз интерпретировать одно и то же. тем более, править инит не
это надо чтоб майнтейнер захотел, принял правки и т.д., а приблуду-конвертер
держи себе отдельным пакетом, и никому она мешать не будет

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность Victor Wagner 
On Tue, 30 Aug 2016 15:18:52 +0500
Stanislav Vlasov  wrote:

> 30 августа 2016 г., 13:26 пользователь Victor Wagner
>  написал:
> 
> >> > Для конкретного случая можно специфицировать некое подмножество
> >> > этого протокола.
> >> > Например, вызов с параметрами start/stop/restart.  
> >> Если этот вызов для админа, а не для загрузки - не вижу проблем.  
> >
> > Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа
> > или  
> 
> Судя по первому сообщению темы, мейнтейнер вообще хочет писать только
> под systemd, потому это дело либо админа, либо дополнений к системе
> инициализации.

Мейнтейнер сейчас вынужден оглядываться на существующую реальность.
Большая часть дистрибутивов использует systemd.

Поэтому в первом же письме я предлагал воспольноваться тактикой embrace
and extend - для нашего, правильного интерфейса сделать переходник
(интерпретатор), который позволит ему использовать service-файлы от
systemd.

Ну и соответсвенно каждая система инициализации должна будет внутри
себя поддержать тем или иным образом этот интерфейс.

Для sysvinit это просто - нужно только insserv подправить что  при
генерации зависимостей умел не только читать LSB-style комментарии, но
и вызывать скрипт согласно протоколу.  Вернее скорее всего в обратном
порядке - сначала позвать с параметром depends, если выругалось что
такого параметра не знает, попробовать почитать, вдруг там LSB-style
комментарии.

Во сколько обойдется поддержка этого интерфейса других системах
инициализации, сходу сказать не могу. Поскольку глубоко в них не
копался.

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность Victor Wagner 
On Tue, 30 Aug 2016 12:03:52 +0300
Dmitrii Kashin  wrote:

> Victor Wagner  writes:
> 
> > On Tue, 30 Aug 2016 10:29:53 +0500
> > Stanislav Vlasov  wrote:
> >  
> >>   

> > А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> > существующих декларативных конифгов и врапперы для прочих случаев,
> > поддерживающие этот протокол.  
> 
> Я тут хотел бы также вклиниться, ибо уже не раз встречал что-то
> подобное. Важно, чтобы этот интерфейс был на интерпретируемом языке. Я
> слышал, что раньше было можно вместо init-скрипта подставить просто
> бинарный файл, поддерживал бы он только необходимый набор аргументов
> типа start/stop/etc... Имхо это конечно возможность интересная, но для
> системного администратора совершенно негодно, ибо одно дело -
> переписать скрипт на живой системе, и совсем другое - пересобрать
> бинарь, выполняющий ту же функцию.

А вот не нужно пересобирать бинарь. Надо скриптовый враппер вокруг него
написать, если приспичило организовать нестандартное поведение.

Бинарь он пришел из пакета находится под управлением пакетного
менеджера и изменение его хэшсуммы - это security alert. Но 95% юзеров
не нужно от демона  ничего, чего не предоставляет бинарь.

Собственно, на самом деле sysvinit начал проигрывать тогда, когда
в среднем внутри оказалось аж три уровня врапперов - 
сначала start-stop-daemon запускает собственно бинарь,
потом start-stop-daemon мы оборачиваем в стандартные функции
из /lib/init/functions, а потом уже из этих функций собираем
стандартный скрипт.

Три уровня, это, конечно, слишком много. Но один иногда бывает нужен.

Проблема сущесвующих init-скриптов в том, что каждый уровень имеет
разный интерфейс и произвольно выкинуть один-два из них получается не
всегда.

А вот сделать обертку, которая вызывается с параметрами
start/stop/depends/reload и сама вызывает бинарник с теми же
параметрами, выполняя на каждый из них какие-то предварительные (или
наоборот) действия - это несложно.


> В этом плане я, по-видимому, являюсь сторонником LSB-заголовков в
> sysvinit, поскольку они принуждают мейнтейнера использовать
> скриптовые запускалки.

Принуждать - нехорошо. А симлинк в /etc/init.d на файлик из /usr/sbin -
хорошо. Для тех 95% админов, которым не нужно от демона странного, а
нужно стандартное поведение.

Принуждение к использованию определенного языка (любого) приводит к
тому, что вместо одного простого и понятного скрипта наворачивается
несколько оберток с  несовместимыми интерфейсам и неудобочиаемыми
исхдониками.

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность Stanislav Vlasov 
30 августа 2016 г., 13:26 пользователь Victor Wagner
 написал:

>> > Для конкретного случая можно специфицировать некое подмножество
>> > этого протокола.
>> > Например, вызов с параметрами start/stop/restart.
>> Если этот вызов для админа, а не для загрузки - не вижу проблем.
>
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или

Судя по первому сообщению темы, мейнтейнер вообще хочет писать только
под systemd, потому это дело либо админа, либо дополнений к системе
инициализации.

> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
>
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.

Для sysvinit я подобное ещё представляю. С другими init могут быть проблемы.

>> > И еще нужен протокол для работы с зависимостями. Нечто аналогичное
>> > LSB comments, но только встроенное в стандартный юниксовый
>> > протокол.
>> Как вариант - проверка наличия работающих зависимостей.
>> Возможно, автозапуск при старте, но это может быть спорно.

> Вот по-моему главное - это способ рассказать системе инициализации чего
> нам нужно. А в каком порядке что из этого запускать - пусть сама
> разбирается. На то есть startpar, хотя я и считаю его лишней сущностью,
> вместо которой надо make использовать.

Хм... Сложный вопрос, так как у системы инициализации может просто не
быть такого интерфейса в удобном виде.
Просто набор сервисов, которые требуется запустить в любом порядке +
внутри запускаемого конфига сервиса - команда на запуск зависимостей
из других сервисов.
При этом оно _не_ совместимо с тем, что обычно лежит в /etc/init.d и
может не предоставлять совместимый интерфейс в данном каталоге, а если
и предоставляет, то не использует это внутри себя.

-- 
Stanislav

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность Dmitrii Kashin 
Victor Wagner  writes:

> On Tue, 30 Aug 2016 10:29:53 +0500
> Stanislav Vlasov  wrote:
>
>> 
>> > Для конкретного случая можно специфицировать некое подмножество
>> > этого протокола.  
>> 
>> > Например, вызов с параметрами start/stop/restart.  
>> 
>> Если этот вызов для админа, а не для загрузки - не вижу проблем.
>
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
>
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.

Я тут хотел бы также вклиниться, ибо уже не раз встречал что-то
подобное. Важно, чтобы этот интерфейс был на интерпретируемом языке. Я
слышал, что раньше было можно вместо init-скрипта подставить просто
бинарный файл, поддерживал бы он только необходимый набор аргументов
типа start/stop/etc... Имхо это конечно возможность интересная, но для
системного администратора совершенно негодно, ибо одно дело - переписать
скрипт на живой системе, и совсем другое - пересобрать бинарь,
выполняющий ту же функцию.

В этом плане я, по-видимому, являюсь сторонником LSB-заголовков в sysvinit,
поскольку они принуждают мейнтейнера использовать скриптовые запускалки.




signature.asc
Description: PGP signature

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность dimas 
2016-243 11:26 Victor Wagner  wrote:
> Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
> системы инициализации. В смысле, если предоставишь исполняемый
> файл с вот таким интерфейсом - при вызове с параметром start делает то,
> stop се, depends это, то система инициализации этот файл подхватит и
> будет через него демоном управлять.
> 
> А уже потом, специфицировав этот протокол, делаем интерпретаторы для
> существующих декларативных конифгов и врапперы для прочих случаев,
> поддерживающие этот протокол.
это все хорошо, пока демон запускается/останавливается на уровне простейших
действий: запустить указанный бинарник, пид-файл покласть туда-то, уйти в фон и
не отсвечивать. такому можно и /etc/init.d/skeleton подсунуть, указав только,
кого и откуда запущать.
и как раз такие случаи приводили в пример свидетили шыштемдэ, когда кричали,
что вот, у нас все запускается через простые текстовые "юниты" без всяких там
шелл-скриптов. но как только появляются какие-то другие действия при загрузке -
создать какую-то помойку, убрать за собой при запуске, запустить еще какие-то
вспомогательные сервисы, etc - вернулись к тому же, что с такой помпой
"закапывали" - к шелл-скриптам))
а еще в /etc/init.d полно всякой фигни, которая не является демонами как
таковыми, но вполне себе Provides, Depends и прочия - всякие там mount*,
checkroot и иже с ними. там чистая шелл-лапша, куда без нее. или что с ними
делать? переписывать на сях, чтоб был непременно бинарник? запихивать все в
общую помойку системы инициализации? и если что-то там понадобится подправить,
то пересобирать-перекомпилять?
я не в курсе, как там в шыштемдэ реализованы все эти fsck и прочее - запихано в
и без того жЫрный pid 1? и как это унифицировать без "шелл-лапши" - тоже не
очень представляю...

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-30 Пенетрантность Victor Wagner 
On Tue, 30 Aug 2016 10:29:53 +0500
Stanislav Vlasov  wrote:

> 
> > Для конкретного случая можно специфицировать некое подмножество
> > этого протокола.  
> 
> > Например, вызов с параметрами start/stop/restart.  
> 
> Если этот вызов для админа, а не для загрузки - не вижу проблем.

Тут вопрос скорее в интерфейсе для мейнтейнера пакета, а не админа или
системы инициализации. В смысле, если предоставишь исполняемый
файл с вот таким интерфейсом - при вызове с параметром start делает то,
stop се, depends это, то система инициализации этот файл подхватит и
будет через него демоном управлять.

А уже потом, специфицировав этот протокол, делаем интерпретаторы для
существующих декларативных конифгов и врапперы для прочих случаев,
поддерживающие этот протокол.


> > И еще нужен протокол для работы с зависимостями. Нечто аналогичное
> > LSB comments, но только встроенное в стандартный юниксовый
> > протокол.  
> 
> Как вариант - проверка наличия работающих зависимостей.
> Возможно, автозапуск при старте, но это может быть спорно.

Вот по-моему главное - это способ рассказать системе инициализации чего
нам нужно. А в каком порядке что из этого запускать - пусть сама
разбирается. На то есть startpar, хотя я и считаю его лишней сущностью,
вместо которой надо make использовать.


> 
> > Вообще этот вопрос у меня в ЖЖ примерно два года назад уже
> > обсуждался.
> >
> > http://vitus-wagner.livejournal.com/1032172.html  
> 
> Видел, но там, помнится, до чего-то конкретного не дошло, только
> обсуждения преимуществ/недостатков разных подходов инитов.
> 

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

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-29 Пенетрантность Stanislav Vlasov 
29 августа 2016 г., 22:43 пользователь Victor Wagner
 написал:

>> > Может быть стоит пойти по другому пути - embrace and extend -
>> > написать интерпретатор service-файлов systemd, который бы не
>> > выпендривался а вел себя примерно как start-stop-daemon.
>>
>> Я бы сказал, в том числе как start-stop-daemon.
>> Скажем, иногда очень удобен runit, в котором демонов лучше запускать в
>> скрипте через exec.
>> То есть, следует отделить интерпретацию и собственно методы запуска,
>> чтобы данным скриптом можно было пользоваться не только для sysvinit.
>
> Именно это я и считаю unix way - когда основной способ разделения
> системы на компоненты  это вызов программы, которая общается с
> вызывавшей через командную строку и стандартные каналы ввода-вывода.

> Для конкретного случая можно специфицировать некое подмножество этого
> протокола.

> Например, вызов с параметрами start/stop/restart.

Если этот вызов для админа, а не для загрузки - не вижу проблем.
В том же runit достаточно сделать симлинк в /etc/init.d с нужным
именем на /usr/bin/sv при наличии конфиг-каталога с таким же именем  и
получаем почти такой же интерфейс.
Почти - потому что 1) другой формат вывода, 2) нет хелпа по параметрам
(вероятно, стоит отметить как баг), 3) поведение в некоторых случаях
немного отличается.

> И еще нужен протокол для работы с зависимостями. Нечто аналогичное LSB
> comments, но только встроенное в стандартный юниксовый протокол.

Как вариант - проверка наличия работающих зависимостей.
Возможно, автозапуск при старте, но это может быть спорно.

>> > Чтобы  можно было использовать service-файлы, которые будут
>> > поддерживаться и  фикситься мейнтейнерами в рамках системы sysvinit
>> > основным преимуществом которой является минимизация функциональности
>> > init и использование внешних программ для всего остального.
>>
>> В остальном - однозначно поддерживаю. Не скажу, что толку от меня
>> будет много, но, если на работе опять будет какой-нибудь проект с
>> новым софтом, который работает только под systemd - писать подобное
>> просто придётся (у нас стандарт - sysvinit + runit для части
>> сервисов).

> Возможно, если речь идет об одном или двух демонах, проще вручную
> перевести сервис-файл на какой-нибудь имеющийся в системе язык
> программирования.

Для одного двух демонов я ещё напишу скрипты. А вот для пары десятков
уже будет геморрой.

Как вариант - написать конвертор, что будет универсальней, хотя и хуже
выглядеть.
Какой-нибудь хук при установке пакета и при наличии данных для systemd
- натравливать конвертор на них.
Дальнейшие действия конвертора - зависят от того, какой инит указан текущим.

Другой вариант - всё же написать интерпретатор, в котором для запуска
будут использоваться разные методы в зависимости от init.
К сожалению, иногда - чересчур разные...

> Вообще этот вопрос у меня в ЖЖ примерно два года назад уже обсуждался.
>
> http://vitus-wagner.livejournal.com/1032172.html

Видел, но там, помнится, до чего-то конкретного не дошло, только
обсуждения преимуществ/недостатков разных подходов инитов.

-- 
Stanislav

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-29 Пенетрантность Victor Wagner 
On Mon, 29 Aug 2016 19:06:08 +0500
Stanislav Vlasov  wrote:

> 29 августа 2016 г., 18:25 пользователь Victor Wagner
>  написал:
> 
> > Может быть стоит пойти по другому пути - embrace and extend -
> > написать интерпретатор service-файлов systemd, который бы не
> > выпендривался а вел себя примерно как start-stop-daemon.  
> 
> Я бы сказал, в том числе как start-stop-daemon.
> Скажем, иногда очень удобен runit, в котором демонов лучше запускать в
> скрипте через exec.
> То есть, следует отделить интерпретацию и собственно методы запуска,
> чтобы данным скриптом можно было пользоваться не только для sysvinit.

Именно это я и считаю unix way - когда основной способ разделения
системы на компоненты  это вызов программы, которая общается с
вызывавшей через командную строку и стандартные каналы ввода-вывода.

Для конкретного случая можно специфицировать некое подмножество этого
протокола.

Например, вызов с параметрами start/stop/restart.
И еще нужен протокол для работы с зависимостями. Нечто аналогичное LSB
comments, но только встроенное в стандартный юниксовый протокол.

Вроде опции depends, которая выдает на stdout список того, от чего
данный init-скрипт зависит (что должно быть запущено до него в случае
dependency-based boot).

> > Чтобы  можно было использовать service-файлы, которые будут
> > поддерживаться и  фикситься мейнтейнерами в рамках системы sysvinit
> > основным преимуществом которой является минимизация функциональности
> > init и использование внешних программ для всего остального.  
> 
> В остальном - однозначно поддерживаю. Не скажу, что толку от меня
> будет много, но, если на работе опять будет какой-нибудь проект с
> новым софтом, который работает только под systemd - писать подобное
> просто придётся (у нас стандарт - sysvinit + runit для части
> сервисов).

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

Вообще этот вопрос у меня в ЖЖ примерно два года назад уже обсуждался.

http://vitus-wagner.livejournal.com/1032172.html



-- 
   Victor Wagner

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-29 Пенетрантность Stanislav Vlasov 
29 августа 2016 г., 18:25 пользователь Victor Wagner
 написал:

> Может быть стоит пойти по другому пути - embrace and extend - написать
> интерпретатор service-файлов systemd, который бы не выпендривался
> а вел себя примерно как start-stop-daemon.

Я бы сказал, в том числе как start-stop-daemon.
Скажем, иногда очень удобен runit, в котором демонов лучше запускать в
скрипте через exec.
То есть, следует отделить интерпретацию и собственно методы запуска,
чтобы данным скриптом можно было пользоваться не только для sysvinit.

> Чтобы  можно было использовать service-файлы, которые будут
> поддерживаться и  фикситься мейнтейнерами в рамках системы sysvinit
> основным преимуществом которой является минимизация функциональности
> init и использование внешних программ для всего остального.

В остальном - однозначно поддерживаю. Не скажу, что толку от меня
будет много, но, если на работе опять будет какой-нибудь проект с
новым софтом, который работает только под systemd - писать подобное
просто придётся (у нас стандарт - sysvinit + runit для части
сервисов).

-- 
Stanislav

Re: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-29 Пенетрантность Victor Wagner 
On Mon, 29 Aug 2016 16:03:48 +0300
Dmitrii Kashin  wrote:

> 
> Я хочу обратить внимание сообщества debian-russian на обсуждение[1] в
> рассылке debian-devel инициативы сопровождающего пакет conntrackd
> удалить скрипты инициализации sysvinit.
> 
> Это важный прецедент, поскольку дело зашло уже так далеко, что
> обсуждают чуть ли "а не внести ли нам правки в Policy, чтобы
> мейнтейнеры могли по желанию выкидывать старый хлам из своих пакетов".

Проблема в том, что уже сейчас в stretch в некоторых пакетах лежат
неработоспособные скрипты, положенные туда "на отвяжись"
Я тут недавно пытался сбэкпортить taskd, так его init-скрипт ухитрился
запустить его так, чтобы он не смог создать себе pid-файл и поэтому не
стартовал. Хотя фикс в общем тривиальный.

При всех полезных свойствах sysvinit система инит-скриптов, которые
пишутся на шелле с использованием объемистой внешний библиотеки

/lib/lsb/init-functions

сочетает все недостатки и традиционного подхода unix и новомодного
подхода больших монолитных программ и библиотек с развесистыми API.

Может быть стоит пойти по другому пути - embrace and extend - написать
интерпретатор service-файлов systemd, который бы не выпендривался
а вел себя примерно как start-stop-daemon.

Чтобы  можно было использовать service-файлы, которые будут
поддерживаться и  фикситься мейнтейнерами в рамках системы sysvinit
основным преимуществом которой является минимизация функциональности
init и использование внешних программ для всего остального.

[debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.

2016-08-29 Пенетрантность Dmitrii Kashin 

Я хочу обратить внимание сообщества debian-russian на обсуждение[1] в
рассылке debian-devel инициативы сопровождающего пакет conntrackd
удалить скрипты инициализации sysvinit.

Это важный прецедент, поскольку дело зашло уже так далеко, что обсуждают
чуть ли "а не внести ли нам правки в Policy, чтобы мейнтейнеры могли по
желанию выкидывать старый хлам из своих пакетов".



Вот небольшая информация для размышления:

Основной аргумент мейнтейнера был "настало время дать sysvinit
умереть"[4].

Расс Олбери, голосовавший в 2014м за Systemd как систему инициализации,
высказался против удаления скриптов инициализации sysvinit из пакетов.[5]

Ян Джексон в 2014м настаивал на том, что Systemd -- это система по
умолчанию только для Jessie [2], Гарби уверил его в том, что решение
ТехКоммитета отражает эту позицию тоже [3].

В этом сообщении[6] Роберт Эдмондс замечает, что удаление скрипта
инициализации нарушает политику[7] Debian по поддержке сторонних систем
инициализации.



Я пишу это сюда постольку, поскольку тут есть люди, которые также, как и
я, считают, что мы несколько продолбали в 2014м году возможность принять
участие в дискуссии, и тем самым допустили весьма неприятные нам
изменения в дистрибутиве.

Пожалуйста, если Вы заинтересованы в сохранении поддержки
sysvinit-скриптов в пакетах, примите участие в дискуссии.



[1] https://lists.debian.org/debian-devel/2016/08/threads.html#00448
[2] https://lists.debian.org/debian-ctte/2014/02/msg00353.html
[3] https://lists.debian.org/debian-ctte/2014/02/msg00361.html
[4] https://lists.debian.org/debian-devel/2016/08/msg00456.html
[5] https://lists.debian.org/debian-devel/2016/08/msg00451.html
[6] https://lists.debian.org/debian-devel/2016/08/msg00450.html
[7] https://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit


signature.asc
Description: PGP signature