Состоялся (https://lists.nongnu.org/archive/html/sysvinit-devel/2019-06...) релиз классической системы инициализации sysvinit 2.95 (https://savannah.nongnu.org/projects/sysvinit), которая широко применялась в дистрибутивах Linux во времена до systemd и upstart, а теперь продолжает использоваться в дистрибутиве Devuan. Одновременно сформированы выпуски применяемых в связке с sysvinit утилит insserv 1.20.0 и
startpar 0.63. Утилита insserv (http://manpages.ubuntu.com/manpages/xenial/man8/insserv.8.html) предназначена для организации процесса загрузки с учётом зависимостей между init-скриптами, а startpar (http://manpages.ubuntu.com/manpages/trusty/en/man8/startpar....) применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы.
В новом выпуске:
- В утилите "pidof" прекращена поддержка настройки форматирования вывода и удалён флаг "-f", так как связанный с форматированием код вызывал проблемы с безопасностью и потенциальные ошибки при работе с памятью. При необходимости изменения формата вывода теперь предлагается использовать опцию "-d" для определения разделителя и преобразование утилитами, подобными "tr";- На стадии завершении работы теперь применяютя миллисекундные задержки вместо приостановок на целую секунду (вместо do_sleep() вызывается do_msleep()). Изменение позволило в среднем на полсекунды сократить время завершения работы и перезапуска;
- В документации более детально описано поведение утилиты halt и связанных с ней опций (-h, -H и -P);
- Прекращено связывание с библиотекой sepol, которая больше не используется;
- В insserv внесены изменения в сборочные файлы (Makefile). При установке insserv больше не перезаписывает файл с настройками insserv.conf, если он уже существует, а сохраняет рядом новый файл insserv.conf.sample. - Добавлена обработка файла /etc/insserv/file-filters, в котором можно указать список расширений (например, .git и .puppet)), которые будут игнорированы при обработке скриптов в /etc/init.d. - В insserv добавлена опция "-i" для указания альтернативного каталога с файлами определения зависимостей.
- В insserv в проведена чистка тестового набора, перенесённого из Debian, и обеспечен его запуск при помощи команды "make check". Сбой при выполнении тестов теперь останавливает дальнейшую проверку и сохраняет статистику на диске для анализа проблемы. В ходе работы над тестовым набором выявлены различные проблемные ситуации, которые insserv может корректно обработать или обойтись выводом предупреждения. Например, insserv теперь ограничивается предупреждением, при наличии неопределяемой зависимости "$service" или при указании одного и того же runlevel в полях Default-Start и Default-Stop.
- Компана startpar теперь устанавливается в каталог /bin, а не в /sbin, так как она может использоваться не только администратором, но и обычными пользовтелями. Отменён план переноса файлов учёта зависимостей из /etc в /var или /lib, так как могли возникнуть потенциальные проблемы при использовании сетевых ФС и нарушалась совместимость с некоторыми утилитами. В коде некоторые строки, проверяемые через sizeof(), заменены на константы.URL: https://lists.nongnu.org/archive/html/sysvinit-devel/2019-06...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50874
Ждём Devuan 2.1 :-)
> Ждём Devuan 2.1 :-)Жди 4.0. Чтоб по-настоящему! (10 заморожен, 11 будет 4.0. Если за три+ года мажорно не поменяют "систему нумерации".)
при этом дивановцы палец о палец не стукнули ;)https://savannah.nongnu.org/project/memberlist.php?group=sys...
люди, которые работают в ibm, debian/ubuntu, suse, citrix =)
И где же SysVinit в SUSE?
я тебе сказал, что кирпич - это "прямоугольный параллелепипед", ты же при этом спрашиваешь "и какого же он тогда цвета?"."диванные пользователи и майнтейнеры, не приложили усилий по выпуску новой версии их любимой программы" - так понятно ?
Ну класс. То есть... Люди занимаются строительством дистрибутива вокруг инита, представляющего из себя ~8k строчек кода на C, потому что эти строчки за многие годы отлажены вдоль и поперёк, и почти не меняются с годами. А тут выпрыгивает из кустов некий эксгибиционист, распахивает плащ, а под плащом у него -- "большой" аргумент. Аргумент о том, что эти мейнтейнеры, оказывается, должны были в эти отлаженные за десятилетия 8k строчек кода свой вклад сделать. Знать бы ещё, зачем.
> что эти мейнтейнеры, оказывается, должны были в эти отлаженные за десятилетия
> 8k строчек кода свой вклад сделать. Знать бы ещё, зачем.Ну, мало ли.
/* Sort the big list */
- qsort(fl->files.recs, fl->files.used,
- sizeof(*(fl->files.recs)), compareFileListRecs);
+ if (fl->files.recs) {
+ qsort(fl->files.recs, fl->files.used,
+ sizeof(*(fl->files.recs)), compareFileListRecs);
+ }https://github.com/rpm-software-management/rpm/commit/6f2118...
>отлажены вдоль и поперёкВ тексте новости первым же пунктом ченджлога:
>прекращена поддержка настройки форматирования вывода и удалён флаг "-f", так как связанный с форматированием код вызывал проблемы с безопасностью
Ох уж эта гениальная отлаженность по сивинитовски. Авторы видимо так устали от отлаженности что решили удалить слишком отлаженный код.
>~8k строчек кода на C
Опять же судя по первому пункту в ченджлоге с каждой версией строчек все меньше. Будем делать ставки когда строк станет ~0 ?
>>отлажены вдоль и поперёк
> В тексте новости первым же пунктом ченджлога:
>>прекращена поддержка настройки форматирования вывода и удалён флаг "-f", так как связанный с форматированием код вызывал проблемы с безопасностью
> Ох уж эта гениальная отлаженность по сивинитовски. Авторы видимо так устали от
> отлаженности что решили удалить слишком отлаженный код.То, что со временем происходит переосмысление безопасности программы -- это процесс вполне себе нормальный. Переосмыслили и удалили форматную строку. В целом -- правильное решение, т.к. уязвимостям форматных строк целые книги посвящены.
То, что со временем происходит переосмысление программы безопасности -- это процесс вполне себе нормальный. Переосмыслили и удалили sysvinit. В целом -- правильное решение.Поправил, не благодари.
> То, что со временем происходит переосмысление программы безопасности -- это процесс вполне
> себе нормальный. Переосмыслили и удалили sysvinit. В целом -- правильное решение.Только вот правильное для кого?
https://www.opennet.ru/keywords/systemd.html
[19.02.2019] Уязвимость в systemd, которую можно использовать для блокирования работы системы
[10.01.2019] В systemd-journald выявлены три уязвимости, позволяющие получить права root
[27.10.2018] Удалённая уязвимость в systemd-networkd
[03.07.2017] Спорная ошибка в systemd, позволяющая повысить привилегии, закрыта без исправления
[28.06.2017] Уязвимость в systemd-resolved
[24.01.2017] В systemd 228 обнаружена локальная root-уязвимость
[30.09.2016] Локальная DoS-уязвимость в systemd
[01.02.2016] Выполнение rm -rf / может привести к неработоспособности UEFI-прошивки ноутбука
А еще:
https://github.com/systemd/systemd/pull/10519
> pid1 serialization/deserialization fixes #10519
> Oct 25, 2018
> Poettering: No description provided.Скромненько так. Правда:
https://www.exploit-db.com/exploits/45714
> systemd - 'reexec' State Injection
Ой системд единственное приложение в линуксе в котором нашли дыры, бяда бяда. До системд конечно же в линуксе дыр в безопасности не было.
А были, в init?
Ты не понял. SUSE уже не использует SysVinit. А наличие большого количества коммитов от них - это диверсия, чтобы сделать SysVinit хуже
Наличие коммитов в SysVinit - это диверсия. Только такой подход должен использоваться в современном линуксе!
пока что источники диверсии гораздо ближе - убунта и ее подобия, пропихнувшие всякий мусор типа insserv и, конечно же ж, "update-rc.d" (и вот, героически победившие автоудалятель конфига этой ненужной ненужно в очередной версии)То есть даже sysv init умудрились забить мусорными поделками. С кукареками о "параллельной загрузке" и прочем хламе.
Ну а чего, действительно, не пропадать же ж шлаку.
> во времена до systemd и upstartЭх, были времена…
А что, упс-срат еще живой?
запусти в виртуалке lionuxmint 9 (upstart) и сравни скорость загрузки с последним
В Chrome OS используется.
>> во времена до systemd и upstart
> Эх, были времена…
> А что, упс-срат еще живой?А ччо ему будет-то?!
# ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 May21 ? 00:00:18 /sbin/init
# ll /sbin/init
-rwxr-xr-x 1 root root 150352 Фев 12 2018 /sbin/init*
# rpm -qf /sbin/init
upstart-0.6.5-17.el6.x86_64
# _
PS: Пожиратеть cpu с соседнего хоста:# ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Apr18 ? 00:05:27 /usr/lib/systemd/systemd --switched-root --system --deserialize 22...и ещё одного:
# ps -fp 1
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 мар19 ? 00:00:49 init [2]
# dpkg -f /sbin/init
dpkg-deb: ошибка: «/sbin/init» не является архивом в формате debian
root@novy:/etc/service# dpkg -S /sbin/init
sysvinit-core: /sbin/init
# dpkg -l sysvinit-core |tail -1
ii sysvinit-core 2.88dsf-59.9+devuan2 i386 System-V-like init utilities
> во времена до systemd и upstartДолжен сказать неплохие были времена. Перестройка, sysvinit, Кашпировский...
> В коде некоторые строки, проверяемые через sizeof(), заменены на константы.Звучит как дурь.
Насколько помню sizeof считается ещё на этапе комплирования. Если я помню правильно, то это не дурь а вообще саботаж.
А выглядит как культура кода на сях- char path[128];
- snprintf(path, sizeof(path), "%s/%s", initddir, p->name);
+ char path[PATH_MAX];
+ snprintf(path, PATH_MAX, "%s/%s", initddir, p->name);
Т.е., если однажды кому-то захочется/понадобится изменить размер буфера, то будет недостаточно подправить объявление переменной, придётся искать и менять все места записи в этот буфер. Данунафиг такую "культуру".
И чего тут менять, кроме циферки в #define MAX_PATH?
Речь шла не про изменение значения константы, задающей размер буфера, а про замену одной константы на другую. Т.е. если в строчке
char path[PATH_MAX];
PATH_MAX заменить на, например, упомянутый тобой MAX_PATH, то такую же замену придётся делать и в строчке
snprintf(path, PATH_MAX, "%s/%s", initddir, p->name);
и во всех остальных подобных местах. С sizeof(path) достаточно поменять только объявление массива.
man sed
man стрельба-в-ногу
Посмотри на строку
snprintf(path, sizeof(path), "%s/%s", initddir, p->name);
и скажи поместится ли в path помещаемое?
И как быстро ты выяснишь что поместится (или не поместится)?А потом ответы на те же вопросы, но уже со строкой в которой PATH_MAX.
Ещё б ты знал, что это глобальная системная константа (POSIX limits.h), не порол бы чуши.
И именно поэтому она ничем не лучше магического значения 128 или 42. А тут это магическое значение впихнули 2 раза.Ой, кто бы порол чушь, програмизд
Нда... Это студент дорвался до кода?Если что, адекватно было бы сделать:
- char path[128];
+ char path[PATH_MAX];
snprintf(path, sizeof(path), "%s/%s", initddir, p->name);
>Состоялся релиз классической системы инициализации sysvinit 2.95, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart, а теперь продолжает использоваться в дистрибутиве Devuan.Автор новостей ограничен. Слака и его поризводные без systemd. Пусть новости про Sys V Init пишет Саахрикту.
Комментатор ограничен. Sys V Init в Slackware никогда не было, там BSD init.
Вы оба не в теме там BSD-style file layout http://www.slackware.com/config/init.php
sysvinit-2.88dsf-i486-4.txt с вами не согласен.
С вами тоже:
https://mirrors.slackware.com/slackware/slackware64-current/...
С вами тоже:
slackware64-current ->
sysvinit-2.94-x86_64-1.txz
Тот случай, когда прочитал sysvinit 2.95 как systemd 295 и подумал что последний сменил стиль нумерации.
Богу инициализации нужно больше систем инициализации..
Их итак много, просто анонимус не в теме ;)
> продолжает использоваться в таких дистрибутивах, как Devuan и antiXА когда-то еще и в OpenSUSE.. эх, давно прошли те времена!
В каком году отказались?
Когда она еще реально была OpenSUSE, а не тем, чем стала сейчас. 13.1? Да не помню уже.
> Когда она еще реально была OpenSUSE, а не тем, чем стала сейчас.OpenFeDO?
В версии 12.3. Я сейчас пишу из 12.2 с SysVinit. Не работают 2 вещи:1. "/etc/init.d/xdm stop", поэтому приходится вместо этого делать "killall kdm".
2. Не работает загрузка с ядром kernel-xen - загрузка не завершается успешно. Работает только если в GRUB-е выбрать Systemd. // да, в openSUSE 12.1 и 12.2 система инициализации выбирается в GRUB-е, во всяком случае в GRUB1 точно, а в GRUB2 вроде нет.
В остальном, с Инитом жить можно. Ещё один маленький баг: Steam не хочет парсить имя релиза ОС, там какой-то символ Стиму не нравился, то ли скобочки, то ли не помню. В 12.3 исправили.
В openSUSE 12.1 обе этих вещи работали. Мне вообще кажется, что SLES 12 должен был быть основан на openSUSE 12.1 - настолько он стабилен и отлажен. Явно на нём должен был быть релиз.
P.S. Сам Xen в openSUSE 12.1, правда, не работает. Если установить ядро из обновлений, то работает, а в релизе - нет. Сломали это ещё в 11.4 в одном из обновлений, но быстро починили, а в 12.2 баг вошёл прямо в релиз.
И да, я пробовал устанавливать ядро из 12.2 в 12.1 - оно прекрасно загружается, несмотря на то что SysVinit.
в 12.0 (в которой это и было основное идеологическое отличие, заставившиее увеличить major)то что у вас там что-то где-то случайно то работает,то нет - это потому,что вы используете нестандартную конфигурацию, оставленную исключительно для совместимости на переходный период - вдруг понадобится 3d party софт, несовместимый с модным трэшачком. Для постоянной эксплуатации ни разу и не предназначенную.
И старательно доламывавшуюся на всем протяжении жизни 12й версии. Потому что именно ради этого ее и выпускали - у пупсиков же ж сервер (с временем рестарта 15 минут из-за особенностей инициализации памяти) недостаточнобыстрозагружается!Последней не systed-аунутой opensuse была 11.4 - ее даже и поддерживали максимально возможное время - evergreen тянулся аж до 18го года именно по этой причине.
это и была последняя более-менее цельная и работающая система linux, еще не превратившаяся в "новый стандарт". На сегодня, увы, уже имеющая исключительно раритетную ценность.
Зенитур, залогинься!
надо sysvinit переписать на rust и добавить поддержку unit-файлов из systemd
> надо sysvinit переписать на rust и добавить поддержку unit-файлов из systemdНу и, собственно, значем? Что это изменит? В экосистеме sysv всё как бы и так есть, в том числе и systemd-shim -- эта самая пресловутая поддержка unit-файлов systemd, реализованная в виде отдельной утилиты. А Rust? Ну нафига? Вот действительно, сотню строчек с C на Rust переписать -- и что-то такое невероятное случится?
> В экосистеме sysv всё как бы и так естьЛолшто? Значение слова не потрудитесь узнать для его уместного применения
>> В экосистеме sysv всё как бы и так есть
> Лолшто? Значение слова не потрудитесь узнать для его уместного примененияСтесняюсь спросить, какого же именно слова. )
"экосистема"? "sysv"? "есть"?
Переписывай и добавляй, кто мешает?
И это хорошо.Буквально вчера наступил на очередные грабли с системГ, причем, как всегда, нежданно и с размаху. Чудесная штука это системГ - никогда не знаешь в каком месте при очередной перезагрузке грабли зависимостей выползут. Вчера вот с openntpd.
Это ещё что! Вы в какой Жо (Дыре безопасности) находитесь ещё не знаете!
Ты это про что? Про Лёнин код что-ли?
Требую:
1 переписать на Go + nodejs, как белые люди
2 добавить прослойку для совместимость с systemd на уровне бинарных логов
3 выбить грант на импортозамещение (и пропить всем Опеннетом)
4 интерфейс настроек должен быть на electron+flash, и тянуть (в качестве зависимостей) половину KDE последней beta версии
1. Несовременно, надо на react native
2. Зачем прослойку, systemd нужно тянуть как зввисимость и сбрасывать в него логи
3. А смузи с водкой будут?
4. KDE слишком легкое, нужно собраный в webassembly Servo запускать в электроне, а на этом уже рисовать qml. И заменить этим всем Плимут, а то у него фатальный недостаток, комп загружается быстрее, чем он стартует
1. реакт натив уже несовременно, надо на флаттере, или как тру смузихлёбы, на свифтуи (и пофиг что не будет на линуксе работать)
sysv - unix stylesystemd - nodejs electron+flash KDE -style
Systemd это про GNOME, а не про KDE.
s/про/оили используйте существительное. А то у вас смузиланг.
GNOME по вашему прилагательное?
[quote]Команда startpar теперь устанавливается в каталог /bin, а не в /sbin, так как она может использоваться не только администратором, но и обычными пользователями[/quote]какое важное изменение!
Эти ретрограды все ещё пишут в /Бин, а не в /уср/Бин
http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSE...
После systemd воспринимать вот это серьезно никак не получается. Можно избавить задонативших сюда людей от подобного рода новостей?
Задонатить и купить - это не одно и то же. И отучайтесь расписываться за всех задонативших.
>>После systemd воспринимать вот это серьезно никак не получается.а системде воспринимать серьезно вообще не получается. ну вообще вот. ну не понимаю я зачем оно нужно? что оно дает? запихали виндовый менеджер в линукс и довольны. столько говнобагов уже в нем словил что не понимаю как это в продакшон пускать? ну как? оно тупо непредсказуемо.
> ну не понимаю я зачем оно нужно?Коньтейнеры же
А при чём systemd? В контейнерах его нет, а на хосте контейнеры это docker или lxc.
Заведите docker без systemd
После systemd как раз новости про systemd не получается серьезно читать.
> После systemd как раз новости про systemd не получается серьезно читать.Зачем их "серьёзно читать"-то?!
Под ними надо несерьёзно укатываться над его "серьёзными" протребл-телями.
>После systemd воспринимать вот это серьезно никак не получается.А после Electron?
>утилите "pidof"Срочно зовите SJW!
её уже впилили в инсталятор Debian GNU/Linux?
Мне и OpenRC хватает.
Он же вроде сабж юзает?
Сиду на runit. Есть заусенцы но вцелом - простая как АК.
Чего и всем желаю.
>Сиду на runitНеплохо, Ранит - это упрощённый sysVinit