Re: ifupdown / systemd

[Max Dmitrichenko]

13 января 2016 г., 11:01 пользователь Andrey Melnikoff
 написал:
> Max Dmitrichenko  wrote:
>> Производитель софтины фиксит у себя апстрим. С хорошей вероятностью
>> патч, который фиксит проблему, подойдет к той версии пакета, которая в
>> stable или в oldstable. Но может быть и так, что:
>> 1) Патч не подходит (не накладывается)
> С чего бы это?

Так бывает. Контекст патча может отличаться между upstream и соотв.
местом в исходниках старой версии.

>> 2) Софтина давно не поддерживается разработчикам
> Выкинуть и собрать свежую, поддерживаемую.

Нихрена. Политика debian не разрешает обновлять версии пакетов в
stable. За исключением volatile, куда кладутся браузеры и ещё что-то
типа антивирусов, кажется. К этому пришли именно потому, что
затрахались портировать фиксы проблем безопасности, коих в браузерах
чуть больше чем до хрена, из апстрима в версию stable и oldstable.

>> > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо,
>> > апстрим не разродился патчем - поэтому и починим как разродиться.
>
>> И если не разродится, то так и забьют? )
> Таки да. Багов вида "не работает" в трекере - вагон, и на большенство -
> забито с прибором.

Ещё раз. Мы сейчас говорим о проблемах с security и только о них.
Багов вида "у меня не работает", "у меня глючит", "у меня падает",
действительно дохрена. Но вот security-баги устраняются всегда и
достаточно быстро, если речь про stable.

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

-- 
With best regards
  Max Dmitrichenko

Re: ifupdown / systemd

[Victor Wagner]

On Wed, 13 Jan 2016 10:44:49 +0300
sergio  wrote:

> On 13/01/16 07:14, Victor Wagner wrote:
> 
> > Самому openvpn глубоко пофиг, как называется то, что указали в опции
> > --config. Что указали, то и читает.  
> 
> Конечно.
> 
> 
> > Назвать его .conf - дебиановское решение.  
> 
> Нет.
> 
> openvpn-2.3.10 % grep conf contrib/multilevel-init.patch
>   # Start every .conf in $work and run .sh if exists
> - for c in `/bin/ls *.conf */*.conf 2>/dev/null`; do
> + for c in `find * -name "*.conf" 2>/dev/null`; do
>   bn=${c%%.conf}
> 

Это очень новый патч. Openvpn 2.3. В Debian эта инфраструктура,
насколько я помню, была уже во времена openvpn 2.1. То есть скторее,
этот патч был по мотивам дебиансовсокго законтрибучен в апстрим.

--  

Re: ifupdown / systemd

[Andrey Melnikoff]

Max Dmitrichenko  wrote:
> 12 января 2016 г., 17:56 пользователь Andrey Melnikoff
>  написал:
> > Max Dmitrichenko  wrote:

> > А кто спонсирует разработку этого очень-нужного софта в виде gnome, NM,
> > pulseaudio, systemd друг на друга завязанного? Добрый дядя Шаттлворт?

> А как, простите, systemd или NM завязан на gnome или pulseaudio? Вы
> ещё gstreamer забыли.
gnome без systemd уже не работает. NM в отрыве от gnome нах не нужен. Он то
и с ним не сильно нужен из-за тупости в подходе "всё надо конфигурить через
меня". Особенно доставляют нерабочие VPN-модули без сообщений в GUI. 

> А то, что, например, все они (на счёт pulseaudio не знаю точно)
> используют dbus - это даже хорошо. Много лучше, чем если бы каждая из
> этих систем исползовала свой уникальный способ, для управления ею.
Да нету в этом ничего хорошего. Появляется единая точка отказа, с хреновыми
возможностями отладки.
А в цвете sd_notify() & co - systemd plague меделенно и верно расползается
по всему софту который хоть как-то умеет работать демоном.

Re: ifupdown / systemd

[sergio]

On 13/01/16 11:25, Victor Wagner wrote:


> Это очень новый патч. Openvpn 2.3. В Debian эта инфраструктура,
> насколько я помню, была уже во времена openvpn 2.1. То есть скторее,
> этот патч был по мотивам дебиансовсокго законтрибучен в апстрим.


Да я не про этот конкретный патч, а про сорцы в целом. И впечатление
такое, что openvpn сам не может решить чего хочет.


openvpn-2.3.10 % ls sample/sample-windows
sample.ovpn*

openvpn-2.3.10 % ls sample/sample-config-files
client.conf  loopback-server   README  tls-home.conf
firewall.sh* office.up*server.conf tls-office.conf


-- 
sergio

Re: ifupdown / systemd

[sergio]

On 13/01/16 11:59, sergio wrote:

> Да я не про этот конкретный патч, а про сорцы в целом. И впечатление
> такое, что openvpn сам не может решить чего хочет.


openvpn-2.3.10 % grep conf distro/systemd/openvpn-client@.service
ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/client --config %i.conf
--daemon --writepid /var/run/openvpn/client_%i.pid


openvpn-2.3.10 % grep conf distro/rpm/openvpn.init.d.suse
...
for c in `/bin/ls *.conf 2>/dev/null`; do


-- 
sergio

Re: перемещение на другое Рабочее место в xfce

[Mikhail A Antonov]

12.01.2016 20:54, Sohin Vyacheslav пишет:
> 12.01.2016 17:35, Mikhail A Antonov пишет:
>> 12.01.2016 17:50, Sohin Vyacheslav пишет:
>> Настройки \ Диспетчер окон (дополнительно) \ Фокус \ Когда окно 
>> активизируется выбери "Ничего не делать".
>>
> Спасибо, Михаил, всё зашуршало... а то бесило это постоянно))
Рад что помогло.
И отвечать стоит в рассылку, а не мне.
Удачи.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: ifupdown / systemd

[sergio]

On 13/01/16 07:14, Victor Wagner wrote:

> Самому openvpn глубоко пофиг, как называется то, что указали в опции
> --config. Что указали, то и читает.

Конечно.


> Назвать его .conf - дебиановское решение.

Нет.

openvpn-2.3.10 % grep conf contrib/multilevel-init.patch
# Start every .conf in $work and run .sh if exists
-   for c in `/bin/ls *.conf */*.conf 2>/dev/null`; do
+   for c in `find * -name "*.conf" 2>/dev/null`; do
bn=${c%%.conf}


openvpn-2.3.10 % cat sample/Makefile.am
...
client.ovpn: sample-config-files/client.conf
-rm -f client.ovpn
cp "$(srcdir)/sample-config-files/client.conf" client.ovpn

...


-- 
sergio

Re: reboot & dbus

[Max Dmitrichenko]

Надо дергуть соотв. метод у сервиса logind (который нынче тоже часть
systemd). У интерфейса systemd он тоже есть, но только для рута.
http://www.freedesktop.org/wiki/Software/systemd/logind/

И, по-моему, logind разрешит тебе это сделать, если сочтет твою сессию
локальной.

13 января 2016 г., 1:29 пользователь sergio  написал:
> On 13/01/16 01:23, sergio wrote:
>
>
>> Жмёшь ты аппаратную кнопку ресет или пишешь reboot --- в данном случае
>> не важно.
>
>
> Кстати про dbus: а как с консоли нажать reset или power точно так же как
> из иксовой сессии? Можно, наверное, посмотреть как это сделано для
> выключения по acpi по дефолту, но вдруг кто уже в курсе?
>
>
> --
> sergio
>



-- 
With best regards
  Max Dmitrichenko

Re: ifupdown / systemd

[Andrey Melnikoff]

Max Dmitrichenko  wrote:
> 13 января 2016 г., 0:53 пользователь Andrey Melnikoff
>  написал:
> > Еще раз, читаем медленно - патчи беруться от производителя софтины, ибо CVE
> > - на софтину, репортиться производителю и ожидает его реакции в виде патчей,
> > новых версий, "а вы так не делайте".

> Производитель софтины фиксит у себя апстрим. С хорошей вероятностью
> патч, который фиксит проблему, подойдет к той версии пакета, которая в
> stable или в oldstable. Но может быть и так, что:
> 1) Патч не подходит (не накладывается)
С чего бы это? 

> 2) Софтина давно не поддерживается разработчикам
Выкинуть и собрать свежую, поддерживаемую.

> Что тогда?

> > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо,
> > апстрим не разродился патчем - поэтому и починим как разродиться.

> И если не разродится, то так и забьют? )
Таки да. Багов вида "не работает" в трекере - вагон, и на большенство -
забито с прибором.

Re: reboot & dbus

[sergio]

On 13/01/16 12:29, Max Dmitrichenko wrote:

> Надо дергуть соотв. метод у сервиса logind (который нынче тоже часть
> systemd).

У меня нет systemd.


-- 
sergio

Re: ifupdown / systemd

[Andrey Melnikoff]

Max Dmitrichenko  wrote:
> 13 января 2016 г., 11:01 пользователь Andrey Melnikoff
>  написал:
> > Max Dmitrichenko  wrote:
> >> Производитель софтины фиксит у себя апстрим. С хорошей вероятностью
> >> патч, который фиксит проблему, подойдет к той версии пакета, которая в
> >> stable или в oldstable. Но может быть и так, что:
> >> 1) Патч не подходит (не накладывается)
> > С чего бы это?

> Так бывает. Контекст патча может отличаться между upstream и соотв.
> местом в исходниках старой версии.

> >> 2) Софтина давно не поддерживается разработчикам
> > Выкинуть и собрать свежую, поддерживаемую.

> Нихрена. Политика debian не разрешает обновлять версии пакетов в
> stable. За исключением volatile, куда кладутся браузеры и ещё что-то
Пальцем покажи где она запрещает. Я только вижу, что она разрешает обновзять
пакажд если фиксить овер-дохрена надо.

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

> >> > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо,
> >> > апстрим не разродился патчем - поэтому и починим как разродиться.
> >
> >> И если не разродится, то так и забьют? )
> > Таки да. Багов вида "не работает" в трекере - вагон, и на большенство -
> > забито с прибором.

> Ещё раз. Мы сейчас говорим о проблемах с security и только о них.
> Багов вида "у меня не работает", "у меня глючит", "у меня падает",
> действительно дохрена. Но вот security-баги устраняются всегда и
> достаточно быстро, если речь про stable.
Ага-ага. Я во всем этом одного не понимаю - для чего это геройство тянуть
древнюю версию годами? Нет, есть две версии печали - билиотеки с ABI+soname,
и новые версии софта которые портированны на библиотеки которых нет в $stable.

Re: ifupdown / systemd

[Artem Chuprina]

Victor Wagner  writes:

>> > А когда конфиг собирается из
>> > кучи файлов, да еще указанные в них параметры оверрайдят друг друга
>> > в не совсем очевидной последовательности  
>> 
>> Можно пример такой неочевидности?  Больше похоже на страшилку - для
>> типичного пакета (напр. apache2 или nginx) - последовательность
>
> Ну точно сисадмин хостинга. Web-сервер - это нетипичный пакет. Как
> правило, на рабочей станции его нет.
>
> Уж скорее там dovecot будет. 
>
> А типичный пакет, это, например apt, bash, modutils, sudo.

Вот я не админ хостинга.  Мне удобнее донастраивать скриптами dnsmasq через .d. 
 Руками я в его конфиг хожу раз в полгода, а скриптами — трижды в день.

Re: ifupdown / systemd

[Max Dmitrichenko]

13 января 2016 г., 14:04 пользователь Andrey Melnikoff
 написал:
> Ага-ага. Я во всем этом одного не понимаю - для чего это геройство тянуть
> древнюю версию годами? Нет, есть две версии печали - билиотеки с ABI+soname,
> и новые версии софта которые портированны на библиотеки которых нет в $stable.

По-моему, вы подошли вплотную к той точке, когда надо сделать свой дистрибутив )

-- 
With best regards
  Max Dmitrichenko

Re: ifupdown / systemd

[Sergey B Kirpichev]

On Wed, Jan 13, 2016 at 02:51:54PM +0200, Oleksandr Gavenko wrote:
> On 2016-01-12, Sergey B Kirpichev wrote:
> > Что вы предлагали в качестве решения проблем sysvinit?
> 
> У sysvinit есть проблемы??

Да, конечно.  Я же уже приводил в качестве примера ужос
с управлением сервисами /etc/init.d/foo start/stop.

> Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем
> грузиться быстрей.

За этими обсуждениями я не следил достаточно, чтобы утверждать,
что вы врете, но склонен полагать что это именно так.  Как минимум,
в качестве причин для использования LSB-зависимостей - обычно
приводят совсем другие.  См. например wiki:
https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

Re: перемещение на другое Рабочее место в xfce

[Sohin Vyacheslav]

13.01.2016 00:33, sergio пишет:
> Вдруг
> browser.tabs.loadDivertedInBackground=true
> поможет?
> 

нет, это не помогло... помог совет от Михаила:
Настройки \ Диспетчер окон (дополнительно) \ Фокус \ Когда окно
активизируется
выбрал "Ничего не делать".

-- 
BW,
Сохин Вячеслав

Re: ifupdown / systemd

[Oleksandr Gavenko]

On 2016-01-12, Sergey B Kirpichev wrote:

> Что вы предлагали в качестве решения проблем sysvinit?

У sysvinit есть проблемы??

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

Это не сработало, startpar(8) и немного шаманства в заголовках решили проблему
долгой загрузки.

У меня десктоп стартует до xterm за 3-4 сек (с SSD). 

Выдумывать шину, через которую разрешать зависимости скриптов загрузки? Может
не актуально?

Кстати лагерь systemd терпит неудачи в ядре. И даже с навязываемым сторонним
модулем (раз в ядро не удалось пропихнуть):

  https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html
kdbus module being removed from Rawhide

И причиной почему выкинули - техническое несовершенство kdbus, признаное
самими инжинерами.

Зато в какой спешке и горячке впихивают!

Просто бизнес, ничего личного ))

-- 
http://defun.work/

Re: ifupdown / systemd

[Sergey B Kirpichev]

On Wed, Jan 13, 2016 at 04:01:16PM +0300, Artem Chuprina wrote:
> > А типичный пакет, это, например apt, bash, modutils, sudo.
> 
> Вот я не админ хостинга.  Мне удобнее донастраивать скриптами dnsmasq через 
> .d.  Руками я в его конфиг хожу раз в полгода, а скриптами — трижды в день.

Тут речь не о том, как удобнее, а о том - как оно на практике
в Debian устроено.  Похоже, человек элементарно не в теме, что
данная схема используется практически в каждом пакете Debian,
в т.ч. для конфигурации apt, bash и sudo.

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

[DONE] wml://{security/2016/dsa-3442.wml}

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3442.wml2016-01-14 00:06:35.0 
+0500
+++ russian/security/2016/dsa-3442.wml  2016-01-14 00:34:39.196422019 +0500
@@ -1,19 +1,20 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -It was discovered that a maliciously crafted packet can crash any of
- -the isc-dhcp applications.  This includes the DHCP client, relay, and
- -server application.  Only IPv4 setups are affected.
+Было обнаружено, что специально 
сформированный пакет может приводить к 
аварийному
+завершению работы любого приложения isc-dhcp, 
включая клиент DHCP, релейное и
+серверное приложения.  Уязвимость 
проявляется только при использовании IPv4.
 
- -For the oldstable distribution (wheezy), this problem has been fixed
- -in version 4.2.2.dfsg.1-5+deb70u8.
+В предыдущем стабильном выпуске (wheezy) эта 
проблема была исправлена
+в версии 4.2.2.dfsg.1-5+deb70u8.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 4.3.1-6+deb8u2.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 4.3.1-6+deb8u2.
 
- -For the testing (stretch) and unstable (sid) distributions, this
- -problem will be fixed soon.
+В тестируемом (stretch) и нестабильном (sid) 
выпусках эта
+проблема будет исправлена позже.
 
- -We recommend that you upgrade your isc-dhcp packages.
+Рекомендуется обновить пакеты isc-dhcp.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWlqbyAAoJEF7nbuICFtKlxLQP+gL+JwkAvWcokZOCPppoJhBT
XCj1EMIPCmA8+tKc1r3xJM5/hIfryJxjzSpNjODvlffL7HK+IaGJJb6y4A5yQifo
/cjYwOXZj7Hq9n2+Tu0uTMrM8vOGP8BJ70o6EPrGc6qczY0+RbmTwFy6BSch84LS
9oLLnapCstC35dcW2ALU7h/NW8yK7NIcJiFRoEsXmY5fCtP4FM3+Y2AiXszqVQKE
xLVVbHQNZYEryFN6NsdykgXf5MIG+v5+/cYY0Q9OAn18hFeTrD2W/AGoBJwcz1zp
A8IMxFavn+St1I9nYZrajOlZOKr5aCoN4KrPb3bYEAJt0hBtUF727A017pI6KnIz
LbRmuQg9M6sINhy4bbmR0tH4r2vktLQEZ9kOCKBk4L/fW7fbXc30TNF2Lc26aFz5
co+ygFbiG9sZDLUHzeSgZv9pCXh7HJ4lN0nKL9D0R0iM8JZVLrRDRhI4QijmvQsN
E0zqXbhoY+ag4K6w4iRWJy0iYDGYvkWyIewEiyFcXnCWKkkNY2MavKxJ3DNbJ13x
Aji69wNjrzly/MxM4TVgTL7LkRZa8/B7rZEmkrF8wqKVG8lUIMv/bJbyMxKQ6Ckc
5OqEVgRIdA6lXIkLou4QqTtKqu53DPrNIjTglaKA8ZU2NOkuLRmQdq1KgtgTCY7c
OcJcyimRu9zMi8K1ZDnU
=UQpE
-END PGP SIGNATURE-

Re: ifupdown / systemd

[Dmitrii Kashin]

Tim Sattarov  writes:

> On 12/01/16 01:23 PM, Max Dmitrichenko wrote:
>> Между тем, проблема не столько в systemd, сколько в пакете ifupdown,
>> который явственно декларирует конфликт с новой версией systemd, и в

fix: со *старой* версией systemd

>> суровой правде жизни о том, что заливаются в testing они не синхронно.
>> То есть пинять (а точнее пытаться пинять) нужно тогда уж целиком на
>> весь Debian, что они такие растакие держут в тестинге конфликтующие
>> версии, а бюрократия не даёт им сделать это синхроно. Уверен, что
>> такой ситуации не возникнет при апгрейде на strech, когда он станет
>> stable.

А в остальном всё верно.

> Что интересно, по моему никто так и не понял, в чем дело то с ifupdown
> vs. systemd

Разве?

> читаем:
>
> при апгрейде
> ifupdown : Breaks: systemd (< 228-3~) but 228-2+b1 is installed.
>
> то есть ему нужна версия *новее*

Правильно. Новая несовместимая версия ifupdown прилетела раньше, чем
нужная ей версия systemd.

> Нужно подождать пока в тестинг придет systemd версии 228-4 (текущая
> версия в сиде) или новее и все разрешится.

Не обязательно. Можно ещё: а) временно поставить на удержание старую
версию ifupdown, и б) поставить systemd из sid.


signature.asc
Description: PGP signature

Re: ifupdown / systemd

[Tim Sattarov]

On 12/01/16 01:23 PM, Max Dmitrichenko wrote:
> Между тем, проблема не столько в systemd, сколько в пакете ifupdown,
> который явственно декларирует конфликт с новой версией systemd, и в
> суровой правде жизни о том, что заливаются в testing они не синхронно.
> То есть пинять (а точнее пытаться пинять) нужно тогда уж целиком на
> весь Debian, что они такие растакие держут в тестинге конфликтующие
> версии, а бюрократия не даёт им сделать это синхроно. Уверен, что
> такой ситуации не возникнет при апгрейде на strech, когда он станет
> stable.

Что интересно, по моему никто так и не понял, в чем дело то с ifupdown
vs. systemd
читаем:

при апгрейде
ifupdown : Breaks: systemd (< 228-3~) but 228-2+b1 is installed.

то есть ему нужна версия *новее*


http://metadata.ftp-master.debian.org/changelogs/main/s/systemd/systemd_228-4_changelog

systemd (228-3) unstable; urgency=medium

* Eliminate "hotplug.functions" udev helper and put the logging
functions
directly into net.agent. This simplifies the migration of the latter to
ifupdown.
  * Drop net.agent, 80-networking.rules, and ifup@.service. These
moved to
ifupdown 0.8.5 now. Add Breaks: to earlier versions.
 * Drop networking.service.d/systemd.conf. The ifupdown package now
ships a
proper service file so this drop-in file is no longer necessary.


http://metadata.ftp-master.debian.org/changelogs/main/i/ifupdown/ifupdown_0.8.8_changelog

ifupdown (0.8.5) unstable; urgency=medium

  * Move ifupdown related files from the systemd and udev packages
to this
package. Closes: #809171


Нужно подождать пока в тестинг придет systemd версии 228-4 (текущая
версия в сиде) или новее и все разрешится.

Re: ifupdown / systemd

[Andrey Nikitin]

В Tue, 12 Jan 2016 17:43:39 +0300
Victor Wagner  пишет:

> Лично мне вообще не слишком понятно зачем ускорять время загрузки.
> Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при
> этом все равно через раз fsck запускается.

Не десктопом и сервером единым, однако.

Как по мне, почти любое решение должно иметь право на существование (в debian),
кроме тех, у которых нет или сильно осложнена возможность отладки
с целью локализации проблемы или поиска решений задачи.
И таким я считаю systemd.

Re: ifupdown / systemd

[Oleksandr Gavenko]

On 2016-01-13, Sergey B Kirpichev wrote:

> On Wed, Jan 13, 2016 at 02:51:54PM +0200, Oleksandr Gavenko wrote:
>> On 2016-01-12, Sergey B Kirpichev wrote:
>> > Что вы предлагали в качестве решения проблем sysvinit?
>> 
>> У sysvinit есть проблемы??
>
> Да, конечно.  Я же уже приводил в качестве примера ужос
> с управлением сервисами /etc/init.d/foo start/stop.
>
Раньше считалось что init скрипт плохо написан если не прибивал детишек на
stop.

Давайте посмотрим на 

  http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
Linux Daemon Writing HOWTO, 2004

  4. Basic Daemon Structure

Fork off the parent process
Change file mode mask (umask)
Open any logs for writing
Create a unique Session ID (SID)
Change the current working directory to a safe place
Close standard file descriptors
Enter actual daemon code

Парадигма сменилась - теперь systemd валит детишек через cgroup.

Т.е. отменяют шаг:

Create a unique Session ID (SID)

Спору нет - я за то что бы компьютер делал работу за меня.

Т.е. должны появиться новые требования к написанию демонов:

  http://www.freedesktop.org/software/systemd/man/daemon.html

Ранее init-скритп знал как остановить демон, теперь появились требования:

  If SIGTERM is received, shut down the daemon and exit cleanly.

  If SIGHUP is received, reload the configuration files, if this applies.

Звучит отлично и мне нравятся эти соглашения!

Есть ощущение что монструозние сервисы, типа Oracle Database не перейдут на
systemd approach, вот как происходит старт/остановка:

  $ sqlplus / as sysdba
  SQL> STARTUP
  SQL> SHUTDOWN IMMEDIATE

  https://docs.oracle.com/cd/E17781_01/server.112/e18804/startup.htm

Кстати подскажите кто нибудь - активация через сокет:

  If your daemon provides services to other local processes or remote clients
  via a socket, it should be made socket-activatable following the scheme
  pointed out below. Like D-Bus activation, this enables on-demand starting of
  services as well as it allows improved parallelization of service start-up.
  Also, for state-less protocols (such as syslog, DNS), a daemon implementing
  socket-based activation can be restarted without losing a single request.

Это не то же самое что и inetd?

Или в systemd есть возможность прописать статическую и другие зависимости для
сервиса с сокет-активацией? Например не отвечать через сокет пока сервис
времени не обновил локальное время? Такие завичимости мне кажутся прогресом
(если они работают).


>> Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем
>> грузиться быстрей.
>
> За этими обсуждениями я не следил достаточно, чтобы утверждать,
> что вы врете, но склонен полагать что это именно так.  Как минимум,

Действительно, не совсем так. Про скорость хвастался Потеринг в 2013:

  http://freedesktop.org/wiki/Software/systemd/Optimizations/

замечая что:

  http://0pointer.de/blog/projects/the-biggest-myths.html

  Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms,
  anyone?), but that's primarily just a side-effect of doing things **right**.

Свежее интервью (2015):

  https://www.linuxvoice.com/interview-lennart-poettering/

говорит интересные вещи:

 * The Upstart way is always, “if this is started, then start that”. If the
   network is up, you take that as a trigger to start NFS and things like
   that. It always has this effect that you start as much as possible instead
   of as little as possible.

   ...we came to the conclusion that Upstart is conceptually wrong...

Запускать что то только по необходимости - класно! Такое sysvinit не умеет.
Для этого inetd?

 * So we started writing Systemd, and Red Hat didn’t like it at all. Red Hat
   management said: no, we’re going for Upstart, don’t work on that. So I
   said, OK, I’ll work on it in my free time. Eventually Red Hat realised that
   the problems we solved with Systemd were relevant, and were problems that
   needed to be solved, and that you couldn’t ignore them.

А тут забыл сказать что менеджеры увидели svhost.exe и возможность диктовать
условия рынку. Изветная стратения Mictosoft - вываливать раз в пятилетку новое
API, пока конкуренты адаптируют продукты они продают. Только RH дополнительно
к этому еще сможет продавать услуги по портированию и консалтинг ))

 * Debian had its init scripts, and Fedora had its init scripts, and they all
   kind of did the same thing, and did it differently, and some are better,
   and some are worse. We thought OK: this is bullshit, let’s write this in C
   in a unified way, and try to pick the best features of all distributions
   and make a convincing argument that it’s the right way.

Классно!

Только снова ситуация как когда LSB описывал RPM и забыл про DEB ))

 * Why do you think some distributions managed to adopt Systemd without any
   major fights, and then others like Debian had very intense debates and
   resignations? 

   Arch Linux probably did it the quickest way. You know, distributions
   attract 

Re: ifupdown / systemd

[Victor Wagner]

On Wed, 13 Jan 2016 16:01:16 +0300
Artem Chuprina  wrote:

> > А типичный пакет, это, например apt, bash, modutils, sudo.  
> 
> Вот я не админ хостинга.  Мне удобнее донастраивать скриптами dnsmasq
> через .d.  Руками я в его конфиг хожу раз в полгода, а скриптами —
> трижды в день.

dnsmasq - это пример пакета который более-менее выдерживает такое
обращение. С ним редко возникает проблема "найти где лежит та
настройка, которая оверрайдит то, что я сейчас туда вписал".

Опять же, у него по умолчанию /etc/dnsmasq.d пустая. 

А у того же dovecot-а поди еще найди куда правильно положить настройку.
 

Re: ifupdown / systemd

[Tim Sattarov]

On 12/01/16 09:43 AM, Victor Wagner wrote:
> Лично мне вообще не слишком понятно зачем ускорять время загрузки.
> Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при
> этом все равно через раз fsck запускается.  Но если уж делать
> dependency-based порядок выполнения, зачем вместо того чтобы брать
> стандартный и все равно присутствующий в дистрибутиве инструмент,
> изобретать велосипед с квадратными колесами.
Я бы поспорил насчет этого.
есть много проектов, особенно связанных с облачными деплойментами, где
нужна быстрая загрузка.
в том же AWS, есть Scaling group, который реагирует на нагрузку на
сервис и запускает/останавливает дополнительные сервера.
пауза в 30 секунд (какая есть сейчас в стандартном ядре, на Xen железе)
уже существенна для своевременной реакции.

Re: ifupdown / systemd

[Sergey B Kirpichev]

On Wed, Jan 13, 2016 at 06:05:43PM +0200, Oleksandr Gavenko wrote:
>Arch Linux probably did it the quickest way. You know, distributions
>attract different kinds of people, of course. If you looked at Arch Linux,
>it attracted very progressive kinds of people – like power users.

А моя думал, школие...

>There are also developers from Debian – two or three of them.
> 
> Не они ли голосовали втихаря за Systemd ))

В Дебиан ~2к разработчиков с правом голоса.  Только два голоса
погоды б не сделали.

Re: ifupdown / systemd

[Oleksandr Gavenko]

On 2016-01-12, Victor Wagner wrote:

> Лично мне вообще не слишком понятно зачем ускорять время загрузки.
> Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при
> этом все равно через раз fsck запускается.  Но если уж делать
> dependency-based порядок выполнения, зачем вместо того чтобы брать
> стандартный и все равно присутствующий в дистрибутиве инструмент,
> изобретать велосипед с квадратными колесами.

Официальный ответ от месии:

  http://0pointer.de/blog/projects/the-biggest-myths.html

  3 Myth: systemd's fast boot-up is irrelevant for servers.

  That is just completely not true. Many administrators actually are keen on
  reduced downtimes during maintenance windows. In High Availability setups it's
  kinda nice if the failed machine comes back up really fast. In cloud setups
  with a large number of VMs or containers the price of slow boots multiplies
  with the number of instances. Spending minutes of CPU and IO on really slow
  boots of hundreds of VMs or containers reduces your system's density
  drastically, heck, it even costs you more energy. Slow boots can be quite
  financially expensive. Then, fast booting of containers allows you to
  implement a logic such as socket activated containers, allowing you to
  drastically increase the density of your cloud system.

  Of course, in many server setups boot-up is indeed irrelevant, but systemd is
  supposed to cover the whole range. And yes, I am aware that often it is the
  server firmware that costs the most time at boot-up, and the OS anyways fast
  compared to that, but well, systemd is still supposed to cover the whole range
  (see above...), and no, not all servers have such bad firmware, and certainly
  not VMs and containers, which are servers of a kind, too.

Что такое socket activated containers?

Еще мне не ясно что может тупить при загрузке в VDS / облаке?

Тенденция то какая - один контейнер - один сервис.

Значит убираем все нафик. Остается статический /etc/network/interfaces,
мониторилка, sshd и основной сервис (mysqld, httpd, ...).

Вот я хостю бложик:

  bash# sudo pstree
  init─┬─acpid
   ├─cron
   ├─6*[getty]
   ├─lighttpd
   ├─rsyslogd─┬─{in:imklog}
   │  ├─{in:imuxsock}
   │  └─{rs:main Q:Reg}
   ├─sshd───sshd───sshd───bash───sudo───pstree
   ├─udevd
   └─xinetd

Расскажите мне зачем устанавливать:

 * logind
 * dbus
 * systemd
 * consolekit

Кстати удалить udevd - нельзя, от него зависит ядро ))

Еще не ясно зачем держать в KVM госте acpid - безопасно ли его будет удалить?
Перезагрузку с удаленным acpid хост пережил...

И зачем getty для VDS?

При апгрейде с wheezy приползли dbus, systemd и irqbalance. Их удалил.

-- 
http://defun.work/