В системном менеджере systemd выявлена (http://www.openwall.com/lists/oss-security/2016/09/28/9) локальная уязвимость. При поступлении сообщения нулевой длины в сокет уведомлений systemd, PID 1 зависает на системном вызове pause, после чего невозможно запустить/остановить демоны или выполнить "чистую" перезагрузку, а systemd-сервисы в стиле inetd перестают принимать соединения.
Так как сокет уведомлений /run/systemd/notify доступен всем на запись, то любые локальные пользователи могут вызвать отказ в обслуживании на системах с systemd.
Уязвимость проявляется во всех версиях systemd, начиная по крайней мере с версии 209. Атака сводится к выполнению команды
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
URL: http://www.openwall.com/lists/oss-security/2016/09/28/9
Новость: http://www.opennet.me/opennews/art.shtml?num=45244
нечему удивляться, хочешь миришься с этим, либо сидишь на дистре без сабжа. Или вон бсд подтянется 5го октября, правда там тоже не лучше и launchd притащат начнется тоже самое.
> launchdесть надежда, что оно будет академично по-бздешному продуманней, чем сабж. Например, pkg-ng, довольно хорош у них получился
pkg-ng научился в человеческое разруливание циклических зависимостей? Может он хотя бы умеет различать release/version/serial? Поддерживает provides/requires/conflicts? Умеет в {pre,post}{{un,}install,update} скрипты?
Без всех этих способновлей он пакетным менеджером называться не имеет права.
pkg info xcb-util
xcb-util-0.4.0_1,1
Name : xcb-util
Version : 0.4.0_1,1
...
Shared Libs required:
libxcb.so.1
Shared Libs provided:
libxcb-util.so.1
https://github.com/freebsd/pkg#pkgfmt
Valid scripts are:pre-install
post-install
install
pre-deinstall
post-deinstall
deinstall
pre-upgrade
post-upgrade
upgrade
> Version : 0.4.0_1,1Версию и билд вижу. Serial (aka семейство) - нет
> Shared Libs required:
> Shared Libs provided:Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А метапакеты? А надо.
> Valid scripts are:
Эт да. Проглядел.
Ну и я не увидел секции provides/requires/conflicts. Попакетно. С мета-пакетами.
Что-то вроде:
Name : apache
Version : 2.2
Requires : meta/www-filesystem-base
Provides : meta/www-server
Confclicts : www/nginx
>Версию и билд вижу. Serial (aka семейство) - нетРасскажите, пожалуйста, что такое "семейство" ? а то может в более других (отличных от привычных) утилитах оно наз-ся по другому как-то... чтобы 2 раза не вставать: а что такое "билд" в строке 0.4.0_1,1 ?
> Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А метапакеты? А надо.
какие, простите, бинарники? какие, простите, [мета]пакеты? содержимое "потрохов" пакета (список бинарников, или чего там Вам нужно) можно было получить еще в pkg_tools (в pkg, естественно, тоже).
> Что-то вроде:
> Name :
> apache
> Version : 2.2...
> Confclicts : www/nginxа это где такой интересный мейнтейнер апача есть? и что за кривой пакетный менеджер, в котором даже слово conflicts не смогли правильно написать?
или я отвечаю Денису Попову с его уникальным менеджером пакетов сейчас ?
Плакали с такими конфликтами фронты на nginx перед апачем, на одной и той же машине. (Я конечно считаю, что апач не нужен, но не так радикально же)
> Версию и билд вижу. Serial (aka семейство) - нетСемейство чего? Гуглить насчет "serial" несколько напряжно.
> Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А
> метапакеты? А надо.А посмотреть по ссылке?
> Ну и я не увидел секции provides/requires/conflicts. Попакетно. С мета-пакетами.
deps: {
libiconv: {origin: converters/libiconv, version: 1.13.1_2};
perl: {origin: lang/perl5.12, version: 5.12.4 };
}> Confclicts : www/nginx
А это еще зачем? Что бы независимо от опций сборки и реальной ситуации пакет все равно не ставился?
>> Версию и билд вижу. Serial (aka семейство) - нет
> Семейство чего? Гуглить насчет "serial" несколько напряжно.Скорее часть полной версии, перекрывающая собственно версию исходника.
Например, для понижения версии в случае необходимости.
> Скорее часть полной версии, перекрывающая собственно версию исходника.
> Например, для понижения версии в случае необходимости.В следующей строчке:
Version : 0.4.0_1,1предпоследняя 1 (после _) инкрементируется при перевыпуске той-же версии, последняя 1 (после ,) - при понижении. Фактически, эквивалентно серийнику.
это он так эпоху в терминах RPM обозвал ?
> это он так эпоху в терминах RPM обозвал ?Угу, это синонимы. Рекомендуется s/^Serial:/Epoch:/g (со слов нашего майнтейнера rpm).
Если пакетному менеджеру нужно большое количество pre/post и т.д. скриптов, то он просто имеет недостаточный функционал.
> Если пакетному менеджеру нужно большое количество pre/post и т.д. скриптов, то он
> просто имеет недостаточный функционал.как правило - это нужно не пактеному менеджеру,
а пакету для выполнения тех или иных служебных работ - добавить/удалить рабочий аккаунт, подготовить/удалить служебное дерево каталогов и т.д.
Интересно, зачем могут понадобиться циклические зависимости пакетов?
По факту, такой набор с циклическими зависимостями - это один пакет, поскольку весь этот набор может быть установлен только сразу весь полностью.
> довольно хорош у них получилсяНо пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов. Хидеры и либы вперемешку. А уж дебагинфо в отдельный пакет отпилить - наверное по меркам BSD это космические технологии.
> Но пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов.Великий знаток опеннета не в курсе разницы между ракетным менеджером и собственно пакетом?
>Хидеры и либы вперемешку.
Пакетный менеджер тут то причём?
> А уж дебагинфо в отдельный
> пакет отпилить - наверное по меркам BSD это космические технологии.А уж знать, о чем с умным видом вещаешь - наверное по меркам опеннетного знатока это что-то запредельное.
> Великий знаток опеннета не в курсе разницы между ракетным менеджером и собственно пакетом?Хорошая опечатка.
> Пакетный менеджер тут то причём?
При том что теоретически он есть. Практически толку с этого нет. Наверняка и с launchd будет так же. В bsd все так делают. На бумаге крутейшая системаю. А на серверах - геморроя кусок.
> А уж знать, о чем с умным видом вещаешь - наверное по
> меркам опеннетного знатока это что-то запредельное.Это слишком хилая попытка троллить. Попробуй еще раз, менее жирно.
> Хорошая опечатка.Бывает. А по теме что-то будет?
>> Пакетный менеджер тут то причём?
> При том что теоретически он есть. Практически толку с этого нет. Наверняка
> и с launchd будет так же. В bsd все так делают.
> На бумаге крутейшая системаю. А на серверах - геморроя кусок.Учитывая предыдущие "вумности", смахивает на очередные размышлизмы анонимого аналитика )
>> А уж знать, о чем с умным видом вещаешь - наверное по
>> меркам опеннетного знатока это что-то запредельное.
> Это слишком хилая попытка троллить. Попробуй еще раз, менее жирно.Троллить? Отнюдь. Это просто констатация факта, не более. Смотрим внимательно:
>> Но пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов.
pkg query %sh xcb-util
55.3KiB
% pkg query %sh FreeBSD-ssh
1.58MiB
https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64
Installed Size 159,681.0 kB>> Хидеры и либы вперемешку.
% pkg query "%n %c" FreeBSD-ssh
FreeBSD-ssh Secure Shell Utilities
% pkg rquery "%n %c" FreeBSD-ssh-development
FreeBSD-ssh-development Secure Shell Utilities (Development Files)
% pkg query "%n %c" FreeBSD-libz
FreeBSD-libz libz package
pkg rquery "%n %c" FreeBSD-libz-development
FreeBSD-libz-development libz package (Development Files)% pkg search FreeBSD-ssh
FreeBSD-ssh-11.0 Secure Shell Utilities
FreeBSD-ssh-debug-11.0 Secure Shell Utilities (Debugging Symbols)
FreeBSD-ssh-development-11.0 Secure Shell Utilities (Development Files)
% pkg search FreeBSD-ssh
FreeBSD-ssh-11.0 Secure Shell Utilities
FreeBSD-ssh-debug-11.0 Secure Shell Utilities (Debugging Symbols)
FreeBSD-ssh-development-11.0 Secure Shell Utilities (Development Files)>> А уж дебагинфо в отдельный пакет отпилить - наверное по меркам BSD это космические технологии.
% pkg rquery "%n %c" FreeBSD-libz-debug
FreeBSD-libz-debug libz package (Debugging Symbols)
% pkg rquery "%n %c" FreeBSD-ssh-debug
FreeBSD-ssh-debug Secure Shell Utilities (Debugging Symbols)
Но вам, с высоты мягкой мебели, наверняка виднее )
А в дистре без сабжа, типа, уязвимостей не бывает?
> А в дистре без сабжа, типа, уязвимостей не бывает?В /bin/init-е-то? Серьёзно?!
>> А в дистре без сабжа, типа, уязвимостей не бывает?
> В /bin/init-е-то? Серьёзно?!Кгм, у меня и бинаря-то такого нет -- следовательно, неуязвим.
$ rpm -qf --changelog /sbin/init | grep CVE
$ _
> Кгм, у меня и бинаря-то такого нет -- следовательно, неуязвим.?) Лучше так:
# ps -p 1
PID TTY TIME CMD
# _
Говорили им - нечего лезть в иерархии, обязательно что-нибудь пойдет не так, так и случилось.
волков бояться - в лес не ходить
Тут не про поход в лес, про нырок в канализацию.
А, так вот о чём ldv@ вслух размышлял...
#32545 - исправлено?
> #32545 - исправлено?Не-а. Вообще говоря, поддержка ветки p7 уже завершена и всё, что в этом плане делается -- сверх обещанного: http://altlinux.org/branches/p7
Но всяко спасибо, что повесили.
> Не-а. Вообще говоря, поддержка ветки p7 уже завершена и всё, что в этом плане делается > -- сверх обещанного: http://altlinux.org/branches/p7Поэтому я и не выделял ветки, а закинул в общую секцию.
> Но всяко спасибо, что повесили.
Чем могу.
> А, так вот о чём ldv@ вслух размышлял...Я надеюсь не при дамах размышлял? Вообще, Михаил, спасибо вам за sysV сборки. Периодически просматривая dev и sisyphus списки рассылки радуюсь, что у меня не systemd.
> Я надеюсь не при дамах размышлял? Вообще, Михаил, спасибо вам за sysV
> сборки. Периодически просматривая dev и sisyphus списки рассылки радуюсь, что у
> меня не systemd.Все познается в сравнении. Если так попробовать почитать баги в инит-скриптах - они тоже на все вкусы. Не говоря о том что в sysv вообще нет нотификаций и система просто забьет на сервис повисший при старте. Это вообще никем и никак не обрабатывается.
Вот тут и познаётся разница между нормальной компонентной системой и кубик-рубик-монолитом. Те инит скрипты, которые я не запускаю, мне не мешают.
> Вот тут и познаётся разница между нормальной компонентной системойПри том большинство компонентов - из бамбука и лиан. И работает характерно, забив на ошибки, продолбав логи и проигнорировав таймауты. Если на таймауты забивать - то и багов в механизме нотификаций не будет. Кто бы сомневался.
> и кубик-рубик-монолитом.
Из кубик-рубика можно и скрипт позвать, если нужно. С другой стороны кубик-рубик может мне выставить планировщик времени проца и IO и приоритеты, порубить SECCOMP-ом лишние сисколы, выставить лимиты, рестартануть процесс при зависоне и проч. И все это несколькими простыми директивами. Самому это горожить что на скриптах что сишным кодом довольно утомительно, а использовать системы как будто на дворе XX век нравится не всем.
> Те инит скрипты, которые я не запускаю, мне не мешают.
Те сервисы которые я не запускаю в системд мне тоже не мешают. Более того - сперва я не понимал в чем прикол с 2 levels of disable. А после того как въехал нахожу это удобным и логичным.
> горожитьНу вот примерно в таком стиле systemd и написан.
> Из кубик-рубика можно и скрипт позвать, если нужно. С другой стороны кубик-рубик
> может мне выставить планировщик времени проца и IO и приоритеты, порубить
> SECCOMP-ом лишние сисколы, выставить лимиты, рестартануть процесс при зависоне и проч.
> И все это несколькими простыми директивами.В нормальных системах покрутить лимиты-приоритеты может и старый добрый sysvinit, я уже давал Вам ссылку на limited(8): http://git.altlinux.org/gears/s/service.git?p=service.git;a=...
> Самому это горожить что на скриптах что сишным кодом довольно утомительно,
Да уж, надорваться можно. Если быть пользователем, а не улучшать используемую ОС.
> а использовать системы как будто на дворе XX век нравится не всем.
Давайте конкретнее -- "как будто 1995 год": то ли загрузится, то ли зависнет на останове...
> Не говоря о том что в sysv вообще нет нотификаций и система просто забьет на сервис
> повисший при старте. Это вообще никем и никак не обрабатывается.Если надо, берёте monit и получаете _вменяемый_ мониторинг состояния сервисов.
> берёте monit и получаете _вменяемый_ мониторинг состояния сервисов.Это чем он более вменяемый реализации в systemd? Тем, что сделан через костыли с опросом списка процессов?
Поддержание работоспособности процессов и их перезапуск при падении — задача init'а, причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от ядра и перезапускает их.
Почему вместо развития этой схемы от неё вообще отошли и прикрутили демоны уродливыми костылями через простыни скриптов с утерей возможности наблюдения и перезапуска — непонятно. Systemd с unit'ами — как раз таки исправление этого упущения, возвращение к архитектуре UNIX, а не уход от неё.
> Поддержание работоспособности процессов и их перезапуск при падении — задача init'а,
> причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab
> с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от
> ядра и перезапускает их.Ваши познания уних-вея ввергают нас в ступор благоговения. У не сам ли Леннарт посетил борду!
> Почему вместо развития этой схемы от неё вообще отошли и прикрутили демоны
> уродливыми костылями через простыни скриптов с утерей возможности наблюдения и перезапуска
> — непонятно. Systemd с unit'ами — как раз таки исправление этого
> упущения, возвращение к архитектуре UNIX, а не уход от неё.Браво, бис, Леннарт Полиграфович!! Расскажите нам больше, сорвите покровы -- что будет новенького прогрессивненького в RHEL-9 и s-d v300? Вы ж не просто так после драчки кулочками, и удобные факты под нужный ответ подгоняете -- у Вас же ж вИдение!? Жгите, просим!
>> берёте monit и получаете _вменяемый_ мониторинг состояния сервисов.
> Это чем он более вменяемый реализации в systemd?Функциональными тестами.
> Поддержание работоспособности процессов и их перезапуск при падении — задача init'а,
> причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab
> с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от
> ядра и перезапускает их.Если бы Вы ещё сами этой функциональностью пользовались и понимали особенности... я, если что, пользовался -- для N малого особо важных сервисов.
Очень вкратце -- да, обычному init не помешала бы возможность прилетевшие сыновнии копытца передать менеджеру вроде того же monit (возможно, поменьше и попроще). Вот _это_ было бы возвращение и в затронутом Вами аспекте, но никак не неразборный комбайн с невменяемым "незаменимым" апстримом и типично штатовскими методами "продвижения демократии".
> Функциональными тестами.Это уже интересно. И как выглядит функциональное тестирование сервиса, допустим, слушающего UART, в терминах monit? Да, он не работает с сетью. Но может быть вполне себе mission critical для моей задачи т.к. должен что-то сделать когда другая железка что-то прислала. И без него система полная тыква и утрачивает смысл существования.
В системд - прописываем в конфиг желаемый таймаут и дергаем его апи, он знает что мой сервис живой. А в monit - это как будет выглядеть? Не говоря что проверяющего проверяет ядро и аппаратный вачдог и если и эти проверяющие дадут маху - железный вачдок тикает в железе и когда он дотикает до часа Ч - ну в крайнем случае системе приедет "железный" ресет от вачдога, он безусловный и неоспариваемый. И тут в хитрозадой системной механике вроде все схвачено. А как это делаете вы? Чтобы full coverage всей цепочки? Ну вот например - как проверяется что сам monit не повис? И как взвис обрабатывается? Подперто ли что-то из этого сначала ядерным а потом и аппаратными вачдогами, на случай если софту плохо или даже совсем плохо?
> И как выглядит функциональное тестирование сервиса, допустим, слушающего
> UART, в терминах monit? Да, он не работает с сетью.Зависит от того, какие средства внешнего контроля предусматривает сервис. Например, он может заранее известным образом отзываться на какие USR1/USR2.
> В системд - прописываем в конфиг желаемый таймаут и дергаем его апи,
> он знает что мой сервис живой.API сервиса?
> А в monit - это как будет выглядеть?
Если да, то так же.
> Ну вот например - как проверяется что сам monit не повис?
Там два процесса стартуют -- не помню уже роли и взаимоотношения, но не удивлюсь, если есть и некоторый самоконтроль, чтоб не доводить до hw watchdog, о котором Вы уже и упомянули.
> И как взвис обрабатывается? Подперто ли что-то из этого сначала ядерным
> а потом и аппаратными вачдогами, на случай если софту плохо или даже совсем плохо?Аппаратным вообще-то подпирается вне зависимости от, на то он и аппаратный.
А так у меня monit за всё время эксплуатации -- это где-то с 2003 года, в т.ч. на системах, где почти каждое моргание eth0 звякало в копилку -- не вис ни разу. В отличие от systemd, который однажды позволил себе упасть в корку в ситуации, когда приличный init продолжил бы работать.
Это только начало, хехе.
Естественно. Надо ведь не фичи релизить, а отлаживать существующий функционал.
Забавный баг:)Походу нашли случайно.
Но для пользователей ничего хорошего, хоть его и исправили,
он еще долго может давать о себе знать.
> он еще долго может давать о себе знать.Как?
Как бамблби наверное, со своим "rm -rf /usr /share...", в айтишных байках.
1) Ну в апстриме исправили, а в старых версиях надо еще патч адаптировать.
2) Если на грабли наступили в одном месте и их от туда убрали, то это не значит, что на них нельзя будет через некоторое время наступить в другом.
>Ну в апстриме исправили, а в старых версиях надо еще патч адаптироватьв убунте уже исправили. Вчера вечером команда работала, сегодня утром - уже нет
> 2) Если на грабли наступили в одном месте и их от туда
> убрали, то это не значит, что на них нельзя будет через
> некоторое время наступить в другом.Даже так: Если они входные данные не проверили в одном месте, то такого будет много. Скоро разно-не-цветные шляпы подтянутся, потрясут деревце -- ужо-то будет звездопад.
> Скоро разно-не-цветные шляпы подтянутся, потрясут деревце -- ужо-то
> будет звездопад.Он давно уже идёт - я подписан на ALTовские рассылки, там периодически появляются темы systemD завис/не работает/сломался.
> Он давно уже идёт - я подписан на ALTовские рассылки, там периодически
> появляются темы systemD завис/не работает/сломался.Достаточно посмотреть на опеннете на представителей альтлинукса, чтобы понять как у них системд будет работать. У них и баш-скрипты так же работают, достатчно посмотреть как они баш 3.х таскают. Сметь пофигизма и нежелания разбираться в предмете вообще штука злая.
> как у них системд будет работать.Без чудес, да. Падает, как у всех остальных.
>> Он давно уже идёт - я подписан на ALTовские рассылки, там периодически
>> появляются темы systemD завис/не работает/сломался.
> Достаточно посмотреть на опеннете на представителей альтлинукса,
> чтобы понять как у них системд будет работать.Ничего, что здесь обычно отмечаются mike@, cas@, vkni@ -- а вот shaba@, который как раз и является нашим героическим майнтейнером systemd, так сходу не припомню?
А от https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&... Ваша обобщалка не распухнет?
> У них и баш-скрипты так же работают, достатчно посмотреть как они баш 3.х таскают.
http://www.opennet.me/openforum/vsluhforumID3/74697.html#66
> Сметь пофигизма и нежелания разбираться в предмете вообще штука злая.
Вы охарактеризовали лишь себя самого, увы.
> он еще долго может давать о себе знать.Думаю что во всех мало-мальски ориентированных на продакшн дистрах майнтайнеры бэкпортнут фикс и он прилетит ближайшим апдейтом. А кто системы не апдейтит - там и более интересные баги есть, критичный cve в openssl например.
Говорили же, чем больше всего намешано в PID 1, тем больше пространства для атак и сбоев.
Не ошибается тот, кто ничего не делает.
> Не ошибается тот, кто ничего не делает.Признаёте s-d ошибкой?
лол, пилить болгаркой стремянку, на которой стоишь, тоже можно... а потом после ампутации половины конечностей повторять твою фразу...если изначально делаешь глупость, то не ошибиться невозможно.
Ну да, править кастомно 100500 скриптов от 100500 криворуких мейнтейнеров потому, что они делают что-то не так, как положено - куда лучше.
> лол, пилить болгаркой стремянку, на которой стоишь, тоже можно...Поэтому фанаты sysv init утверждают что болгарки и стремянки не требуются. Максимум ручная дрель.
> Поэтому фанаты sysv init утверждают что болгарки и стремянки не требуются. Максимум
> ручная дрель.Язык Цэ, на котором написана система systemD - это и есть ручная дрель по сравнению с sysVinit'овским sh'ем.
> Язык Цэ, на котором написана система systemD - это и есть ручная
> дрель по сравнению с sysVinit'овским sh'ем.Пока не попробуешь им namespace переключить, попутно расставляя лимиты и переключая планировщики, попутно прописывая лимиты SECCOMP. Вот тут берешь ты sh и ощущаешь себя с ручной дрелью около бетонной стены. А системд - обычный перфоратор среднего пошиба. Да, чинить его сложнее чем ручную дрель. Но и может он намного больше.
У вас функциональная неграмотность: я писал про языки Цэ и sh, а вы возражаете, рассказывая про системы инициализации.
Ну и нахрена вам всё это?> namespace переключить
Ну и что вам такого дали эти ваши namespace-ы? Улучшенная статистика? О, это да. Статистика - это ведь круто. "Типа контейнеризация, типа безопасность"? Да нет вроде. "Возможность управлять всеми процессами разом"? Блин, ну так для того всегда были pgid и sid у каждого процесса. Вы о них хотя бы слышали, оналитеги хреновы?
> расставляя лимиты
О да, ulimit-а вам почему-то не хватило.
> ... переключая планировщики ...
Планировщики по 10 раз на дню переключать. Ага. Зачем?! Кому такое в голову взбрело, что за больное воображение? Кроме вас, системдэ-шников, так *никто* не делает.
> ... лимиты SECCOMP ...
"Запихнём всё в контейнеры во имя добра"?
Как же блин раньше-то люди жили без этих песочниц-то? Пихали процесс в chroot и горя не знали. И то - при крайней необходимости, и только.
>> расставляя лимиты
> О да, ulimit-а вам почему-то не хватило.Он скорее о том, что ulimit из инитскриптов в "обычных дистрибутивах" штатно не дёргается, т.е. придавить получится лишь с точностью до псевдопользователя в тех случаях, когда на них вообще переключаются. Дистрибутивно решается крайне компактной шелльной библиотекой (ссылка в #93) и точечными добавлениями в собственно пакетах с сервисами.
>>> расставляя лимиты
>> О да, ulimit-а вам почему-то не хватило.
> Он скорее о том, что ulimit из инитскриптов в "обычных дистрибутивах" штатно
> не дёргаетсяДа я, Миш, собственно о том и говорю, что они ставят в заслугу своей любимой поделочке такие вещи, потому что они там есть "из коробки". Но при этом как-то закрываются глаза на то, что:
1) такие штуки можно при желании и к sysvinit приделать,
2) это не делается в "обычных дистрибутивах", потому что в 99% случаев это нафиг не нужно.> т.е. придавить получится лишь с точностью до псевдопользователя в
> тех случаях, когда на них вообще переключаются.Ага. И обычно в оставшемся 1% случаев именно так и делается.
> Дистрибутивно решается крайне компактной шелльной библиотекой (ссылка в #93) и точечными добавлениями в собственно пакетах с сервисами.
Даже не сомневался, что сущесвует. Вообще, у вас там в Альте со скриптами всё хорошо. У вас там Левин есть. Я с ним не знаком, но читал его скрипты, когда gears изучал на досуге. Они клёвые.
> Даже не сомневался, что сущесвует. Вообще, у вас там в Альте со
> скриптами всё хорошо. У вас там Левин есть. Я с ним
> не знаком, но читал его скрипты, когда gears изучал на досуге.
> Они клёвые.Реально, если есть проблемы со скриптами, то нужно просто переходить на какой-нибудь более-менее типизированный язык с sh'а. Т.е. вполне можно взять и переписать sysVinit скрипты с sh на тот же Ocaml. Они, конечно, распухнут, но ошибок будет меньше. Хотя, конечно, это явно не идеальный выбор языка - желательно всё-таки написать лёгкую типизированную замену sh.
Но архитектура-то всё равно будет не systemDшная (кубик-рубик-монолит), а sysVinit'овская - лёгкое ядро + скриптовая обвязка.
> Реально, если есть проблемы со скриптами, то нужно просто переходить на какой-нибудь
> более-менее типизированный язык с sh'а. Т.е. вполне можно взять и переписать
> sysVinit скрипты с sh на тот же Ocaml. Они, конечно, распухнут,
> но ошибок будет меньше. Хотя, конечно, это явно не идеальный выбор
> языка - желательно всё-таки написать лёгкую типизированную замену sh.Кстати, очень интересная мысль. Предлагаю обсудить в почте. vkni@altlinux.org, не ошибаюсь?
У меня есть некоторый опыт разработки DSL на Ocaml. Давайте обсудим и скооперируемся. Я бы поигрался с подобным проектом. Сейчас болею, но завтра-послезавтра буду в адеквате.Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы sysvinit решены в других инитах. Я лично с проблемами в скриптах не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно не хватает.
> Но архитектура-то всё равно будет не systemDшная (кубик-рубик-монолит), а sysVinit'овская
> - лёгкое ядро + скриптовая обвязка.И это хорошо.
> У меня есть некоторый опыт разработки DSL на Ocaml.У меня тоже есть, но толку-то? Основная проблема с заменой sh - это то, что нужно хорошо поставить задачу, описать этот самый язык. А интерпретатор много кто может написать.
Я много раз это обсуждал - решительно непонятно, что конкретно нужно делать с типами. Т.е. с одной стороны, скриптовый движок должен быть типизирован (т.к. bash уже есть), с другой стороны, нужна поддержка grep/sed - т.е. операций над строковыми данными. Нужно, чтобы скрипт мог без выпадения обрабатывать потоки данных с ошибками.
Вот что в bash'е круто:
1) Работа со файловыми именами без кавычек. Ну и вообще минимум кавычек.
2) Ленивость конвееров как Хаскелле, позволяет обрабатывать не влезающие в ОЗУ объёмы данных потоковым образом.
3) Распараллеливаемость всего и всея - программы, входящие в конвеер работают параллельно.> Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы
> sysvinit решены в других инитах. Я лично с проблемами в скриптах
> не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно
> не хватает.Инит скрипты уже более-менее вылизаны. Ну, а что плохо - if'ы, передача параметров скриптам, передача кодов ошибок и т.д.
>> У меня есть некоторый опыт разработки DSL на Ocaml.
> У меня тоже есть, но толку-то? Основная проблема с заменой sh -
> это то, что нужно хорошо поставить задачу, описать этот самый язык.
> А интерпретатор много кто может написать.
> Я много раз это обсуждал - решительно непонятно, что конкретно нужно делать
> с типами. Т.е. с одной стороны, скриптовый движок должен быть типизирован
> (т.к. bash уже есть), с другой стороны, нужна поддержка grep/sed -
> т.е. операций над строковыми данными. Нужно, чтобы скрипт мог без выпадения
> обрабатывать потоки данных с ошибками.Вот мне тоже не понятно, куда там типизацию втыкать. Основное применение shell - это вызов внешних команд. А их коды возврата - это обычно int. И где мы там типизацию втыкать собрались...
Нужна ли поддержка grep/sed в самом языке - это конечно вопрос интересный. Чтобы как в perl не ставить лишнюю экранировку - может быть, было бы удобно. Но возможно легче было бы в bash привнести что-то вроде двойных-тройных кавычек для этого дела?
Но вот если Вы предлагаете регэкспы компилировать языком, то я считаю это однозначно плохой вещью. Пусть уж лучше sed разбирает строку, которую мы ему передали и сигналит об ошибке кодом возврата, как и раньше.
Потом, начнём мы типы вводить. Какие мы сможем ввести-то? И для чего? Я смекаю, что только для определяемых функций. У нас будет тип exit_code, который будет либо Ok, когда программа вернула нуль, и Error of int, когда программа вернула не нуль. У нас будут преобразования exit_code в bool и в int. Надо поработать со строками обязательно. Где мы сможем использовать типизацию? Пожалуй, только в функциях, которые мы определяем в самом языке. Повсеместно будут требоваться преобразования кода возврата во что-нибудь. Для каждого действия со внешними командами придётся писать типизированную обёртку. Скрипты довольно-таки разрастутся.
Если на то пошло, у меня похоже получается один-в-один Ocaml, который дёргает внешние команды. Но сам Ocaml использовать нельзя, потому что у него слишком большой рантайм. Нам нужно что-нибудь легковесное, что уместится килобайт в 20 против 170кб для hello_world для Ocaml.
> Вот что в bash'е круто:
> 1) Работа со файловыми именами без кавычек. Ну и вообще минимум кавычек.В большинстве случаев всё равно оборачиваю в кавычки всё, с чем работаю, чтобы в случае наличия пробелов трактовалось как один параметр.
> 2) Ленивость конвееров как Хаскелле, позволяет обрабатывать не влезающие в ОЗУ объёмы
> данных потоковым образом.Ленивость конвееров - это собственно не фишка самого shell, а фишка unix-системы в целом. Он же создаёт детей и связывает их каналами, так что распараллеливание, оно на уровне ядра, а не shell-а.
> 3) Распараллеливаемость всего и всея - программы, входящие в конвеер работают параллельно.
Аналогично п.2
>> Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы
>> sysvinit решены в других инитах. Я лично с проблемами в скриптах
>> не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно
>> не хватает.
> Инит скрипты уже более-менее вылизаны. Ну, а что плохо - if'ы, передача
> параметров скриптам, передача кодов ошибок и т.д.А что там с if-ами? Не соображу никак. Если есть желание cond, так elsif в принципе та же фигня. Да и case в наличии.
Передача параметров - возможно. В принципе аналоги labeled & optional parameters для скриптов можно было бы обязательным предварительным getopt-разбором. Хотя если честно, мне понравилось, как параметры разбираются в zsh. Получается примерно так:
zparseopts -a opts \
v+ -version \
d -debug \
h -help -usage \
s:=server -server:=server \
-src:=source -source:=source \
-dst:=destination -destination:=destination \
p:=project -project=project \
a:=action -action:=action \
u:=user -user:=user
> У вас там Левин есть. Я с ним не знакомВообще это несложно поправить -- на конторе всё так же вечерами водится чай, а завтра до обеда мы вообще в Калуге на #ossdevconf (ещё можно в Переславль где-нить к концу января готовиться с докладом по образовательной тематике или просто так). Ну, на всякий :)
PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где неподалёку живёт -- в лицо друг дружку знать?..
>> У вас там Левин есть. Я с ним не знаком
> Вообще это несложно поправить -- на конторе всё так же вечерами водится чай,А контора-то где?
> ещё можно в Переславль где-нить к концу января готовиться с докладом
> по образовательной тематике или просто так.Посмотрел. Мне 4 часа ходу до Переславля. Можно попробовать. Хотя Москва была бы удобнее. Я не очень хороший водитель пока - 4 часа за рулём мне пока тяжело. :)
> PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где
> неподалёку живёт -- в лицо друг дружку знать?..Очень за. Заодно может ключи друг другу подпишем (если кто пользуется gpg)?
>>> У вас там Левин есть. Я с ним не знаком
>> Вообще это несложно поправить -- на конторе всё так же вечерами водится чай,
> А контора-то где?На Дмитровской, см. basealt.ru.
> Посмотрел. Мне 4 часа ходу до Переславля. Можно попробовать. Хотя Москва была
> бы удобнее. Я не очень хороший водитель пока - 4 часа за рулём мне пока тяжело. :)Да, зимой по горкам с эпизодическими лесовозами бывает сложно -- но туда арендуют автобус.
>> PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где
>> неподалёку живёт -- в лицо друг дружку знать?..
> Очень за. Заодно может ключи друг другу подпишем (если кто пользуется gpg)?Тоже вариант, если кому надо.
Я все жду когда Торвальдс хороший гемор от этой поделки получит
> Я все жду когда Торвальдс хороший гемор от этой поделки получитLF РедХейту гешефт не выклюет!
> При поступлении сообщения нулевой длины в сокет уведомлений systemd,
> PID 1 зависает на системном вызове pauseНемного напомнило давний баг
https://bugs.freedesktop.org/show_bug.cgi?id=74589
> systemd segfaults if no cgroups are availableВернее, ответ анонимного тезки Леннарту )
(Lennart)
>> To make this work we'd need a patch, as nobody of us tests this.(Тезка)
> Yes, it's clear you don't test for NULL pointers before deferencing.
> Nobody else should need to provide a patch to fix the bug you created.
> If you can't figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY!
> You should never EVER be deferencing any pointer without first sanity checking its value.
>NO EXCEPTIONS!
> P.S. Please go diе in a fire.
>Вообще, проверок и аccертов в том коде системд, который я просматривал, немало. Но как-то немного беccистемно. Т.е. иногда как минимум двойные-тройные, когда параметры проверяются вызывающей функцией, а потом еще и в вызванной. Ну и поведение кода в "случае чего" как-то ... не всегда очевидно (вернее, так далеко я в код не закaпывался, так что воздержусь от опрометчивых суждений).
Я тоже глубоко не закапывался, но на поверхностный взгляд "бессистемность" - это очень хорошая характеристика стиля кода systemd.Код upstart-а, по крайней мере, читать намного проще.
upstart в целом был бы куда более интересен, если бы не имел такой полномасштабной жопы с отслеживанием разного рода зависимостей.В системды конфиги в целом логичны. А код - дело вылизываемое.
> А код - дело вылизываемое.Можете приступать. Но что-то тот код с магическими константами как появился в 2010м году, так до сих пор торчит.
> А код - дело вылизываемое....архитектура -- дело поправимое, задумка -- не беда...
PS: привет с калужской конференции #ossdevconf :)
Теперь-то да, деваться уже некуда. Пару лет назад еще имело смысл пробовать допилить upstart.
> Код upstart-а, по крайней мере, читать намного проще.А радости с этого? Ну вот надо мне чтобы моя программа взлетела перед какой-то еще программой. С апстартом - болт. Он это нормально не умеет by design. Для этого надо прописываться в конфиг той программы, а это уже разборки с тем как тот пакет обновляется и не перетрет ли он изменения. Системд этим не страдает.
