да ты просто гомофоб, если не любишь systemd! !!!

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

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

2020 год, Linux+systemd+Wayland+KDE победоносно шагают по планете, из-под картонных коробок на помойках доносятся последние хныки Unix-вытиранов...

Линукс был интересен, пока оставался реализацией UNIXway

детуля, ты сам себя поняшками обманул, Линукс никогда не был реализацией unixway, он всегда был злобным инженерным мутантом, плюющим на всякие фейлософские идеологии

Бомбит?

Я что-то неправильно понял или по ссылке видео трехмесячной давности?

дурачок что ли совсем?

Текстовые логи же

на что только не идут дети, лишь бы не использовать текстовые логи

А разве systemd нельзя заставить писать журналы плоских текстом, а не в бинарном виде?

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

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

journald можно заставить форвардить всё сислог-демону (в сокет /run/systemd/journal/syslog) и не писать ничего самостоятельно.

/etc/systemd/journald.conf:

Storage=none
ForwardToSyslog=true

Также можно просто отрубить journald, но тогда stdout/stderr демонов улетит в трубу.

Сижу на OpenRC+eudev и не парюсь. ^_^

Вот Вы сами подумайте:

Ключ для подписывания где? В том месте где лог генерится или принимается

Соответственно если враг имеет возможность изменить логи (то есть рутовые права по сути ибо логи пишутся обычно под другими бзерами нежели аккаунты пользователей в шелл) то вот что ему помешает исправить и переподписать?

Учи русский, неуч.

One key is the «sealing key» which is kept on the system, and the other is the «verification key» which should be securely stored elsewhere. Using the FSPRG mechanism, a new sealing key is generated periodically using a non-reversible process. The old key is then securely deleted from the system after the change.

The verification key can be used to calculate the sealing key for any given time range. That means that the attacker can only access the current sealing key (which will presumably be used for the next sealing operation), while the administrator can reliably generate any sealing key to verify previous log file seals. Changing log file entries prior to the last seal will result in a verification failure.

Перевожу: verification key — это закрытый ключ. Sealing key — это открытый ключ (точнее, последовательность открытых ключей). Логи «подписываются» открытым ключом.

Текущий sealing key хранится на машине и позволяет сгенерировать только следующий sealing key. Verification key хранится у администратора и позволяет сгенерировать любой sealing key. Дальше продолжать или сам поймёшь?

Молодец, держи нас в курсе.Здравствуйте, это OpenRC-прайд-парад?

Как вам будет угодно, сэр.

Отлично. Нет раздражающих детских болезней

7. Вот жду 10 с рабочими столами из кед.

Удачи комментатору отведать системды. Так как он не хочет разбираться в сути системды - придется ему переустанавливать линукс (как винду) при любых поломках системде :)

2020 год, Systemd Software Compilation победоносно шагает по планете, из-под картонных коробок на помойках доносятся последние хныки Linux-вытирана Alyssa...

Поправил. Не благодари.

Не поверишь - текстовые.

Никто не поверит, потому что бинарные.

% head System.evtx|hexdump -C
00000000  45 6c 66 46 69 6c 65 00  00 00 00 00 00 00 00 00  |ElfFile.........|
00000010  dd 00 00 00 00 00 00 00  2c 6c 00 00 00 00 00 00  |........,l......|
00000020  80 00 00 00 01 00 03 00  00 10 de 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000070  00 00 00 00 00 00 00 00  01 00 00 00 51 63 6a 03  |............Qcj.|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  45 6c 66 43 68 6e 6b 00  01 00 00 00 00 00 00 00  |ElfChnk.........|
00001010  77 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |w...............|
00001020  77 00 00 00 00 00 00 00  80 00 00 00 a0 fb 00 00  |w...............|
00001030  50 ff 00 00 cd 68 1e 14  00 00 00 00 00 00 00 00  |P....h..........|
00001040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001070  00 00 00 00 00 00 00 00  01 00 00 00 e5 a9 dd a7  |................|
00001080  00 00 00 00 00 00 00 00  00 00 00 00 c2 04 00 00  |................|
00001090  37 06 00 00 b1 0b 00 00  3b 47 00 00 00 00 00 00  |7.......;G......|
000010a0  00 00 00 00 00 00 00 00  8c 0b 00 00 3d 03 00 00  |............=...|
000010b0  50 49 00 00 00 00 00 00  00 00 00 00 7d 45 00 00  |PI..........}E..|
000010c0  34 4a 00 00 00 00 00 00  13 4b 00 00 05 4a 00 00  |4J.......K...J..|
000010d0  ae 4b 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.K..............|
000010e0  2e 0a 00 00 00 00 00 00  00 00 00 00 b1 4a 00 00  |.............J..|
000010f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001100  2c 46 00 00 82 06 00 00  db 0a 00 00 00 00 00 00  |,F..............|
00001110  c3 03 00 00 48 4b 00 00  63 05 00 00 00 00 00 00  |....HK..c.......|
00001120  00 00 00 00 ee 09 00 00  0b 04 00 00 00 00 00 00  |................|
00001130  00 00 00 00 79 4b 00 00  79 0a                    |....yK..y.|
0000113a

Нет раздражающих детских болезней

Правильно, у взрослых все по-взрослому, в том числе и болезни. Кстати, systemd In Action, part 4 (комментарий).

journald можно заставить форвардить всё сислог-демону

Это костыль. Должно быть простое apt-get remove journald.

Спасибо за публикацию 4-й части. А можно вопрос по первым? Вот мне нужно запускать при старте noip, если я создам такой юнит, работать будет?

[Unit]
Description= NO-IP Update Client
Requires=multi-user.target
After=network.service

[Service]
Type=forking
ExecStart=/usr/sbin/noip -U 15 -c /etc/noip.conf

Уже встал в очередь на 29 июля, нигер?

Нет, не должно. Подучи матчасть и разберись в том, для чего нужен journald.

и, если тот запущен не будет - то и мой юнит не запустится

Нет.

параметр After определяет не только очерёдность, но и зависимость

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

After/Before и Wants/Requires — совершенно разные вещи и друг друга не подразумевают.

Кстати, systemd In Action, part 4 (комментарий).

Самые обычные. Виндовые :)

Правильно, у взрослых все по-взрослому, в том числе и болезни.

К счастью, на десктопе я их очень редко вижу. Остальное неинтересно.

Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?

Зависит от значения директивы StandardOutput=. Варианты:

• в journald;
• в низкоуровневую консоль (путь к которой указан директивой TTYPath=);
• в сокет (если это сокет-активируемый юнит);
• в никуда.

такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?

Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».

systemd-networkd

По умолчанию не включен.

systemd-vconsole-setup

Отключается путём маскирования.

А возможно ли отключить journald

Отключается путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).

сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»

А это уже зависит от тебя и от демонов. Сообщения тех демонов, которые умеют самостоятельно писать в сислог — попадут в сислог. А чей-либо stdout/stderr не попадёт никуда, потому что внезапно journald именно тем (в частности) и занимается, что перенаправляет одно в другое.

А вообще я скоро допишу статью, в которой про всё это написано. Она должна была войти в SIA #3, но я не успел.

SIA #3

Бугагашеньки)))

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

[qoute]Нет, не должно. Подучи матчасть и разберись в том, для чего нужен journald

2^100500 раз не нужно. Что ты будешь делать со своей мат. частью, когда это все это рухнет. Фигней не занимайся, «memento mori».

Кстати,

[Unit]
Requires=multi-user.target

Скорее всего, это неправильно. Чего ты хотел добиться этой директивой?

Чего ты хотел добиться этой директивой?

Включить загрузку юнита в многопользовательском (умолчальном) режиме.

хороший план! тут у меня (в Сибири) как раз есть одиночное помещение!;)

В любом случае в винде меня не будут парить кривые драйвера и убогий системДэ

зачем же так радикально... вон FreeBSD уже подросла... там недавно классический пакетный менеджер с репозиториями появился.

Вроде бы, это делается обычно следующим образом:

[Install]
WantedBy=multi-user.target

не знакомы с задачами, которые возникают, когда надо не только читать /var/log/messages, но и осмысливать прочитанное.

т.е. ты за бинарные логи? тогда вопрос: как в systemd разграничен доступ к логам разного типа? а? другой вопрос: если ты не админ локалхоста, то скорее всего знаешь про девелоперскую среду. Это такой сервер с кучей отладки, где гигобайты логов могут наматываться быстрее чем за час. Очень бы хотелось _чистить_ эти никому не нужные кучи. Как это сделать при сохранении полезных логов, если мы не можем сделать просто

echo "" > /var/log/service/name.log

Помню, ты считаешь, что «systemd вполне облегчает работу админа и вполне удобен в обращении. А всё остальное — уже демагогия.». Вот интересно, как бы ты ответил на «демагогию» выше.

там недавно классический пакетный менеджер с репозиториями появился.

Оно там такое, что лучше б ему не появляться.

Это делается не так.

[Install]
WantedBy=multi-user.target

...и затем systemctl enable <твой-юнит>

Прошу не перевирать. Я никогда не утверждал и не утверждаю, что journald (да и весь systemd) решает все возможные юзкейсы. Вышеописанный — один из таких, которые journald не решаются. Т. е. journald не умеет раскидывать логи из разных источников по разным файлам.

К сожалению, решение только определенных юзкейсов - это виндовс подход. UNIX всегда славился гибкой комбинацией утилит. ИМХО, утверждение «systemd вполне облегчает работу админа и вполне удобен в обращении» можно употреблять только с большим ИМХО.)

К сожалению,

К сожалению, ты живёшь в выдуманном тобой же мире, который имеет с действительностью мало общего. Любая, вообще любая программа решает строго определённый конечный круг юзкейсов. И systemd-journald (а точнее, его встроенный механизм записи логов на диск — прошу не отождествлять одно с другим!) исключением не является.

Чем там славился юникс, я не знаю, да и оффтопик это абсолютный: форум-то у нас о линуксе. Что касается последнего — нет, это утверждение вполне объективно. systemd облегчает работу админа, т. к. решает ненулевое количество проблем лучше, чем они решались до этого.

хранится на машине ключ, которым что-то подписывается то что хранится на этой машине.

далее все уже - софистика из разряда DRM

Знаешь... ты напоминаешь младшешкольника, которому в первый раз показали, скажем, введение в высшую алгебру. Тот тоже ответил бы: «не морочьте мне голову, я твёрдо знаю — умножать и складывать можно только числа!»

...и затем systemctl enable <твой-юнит>

Что добавит симплинк в /etc/systemd/system/multi-user.target.wants, что равносильно добавлению в директиву wants юнита multi-user.target, так?

Зависит от значения директивы StandardOutput=

Я её описание не нашёл ни в man systemd.unit, ни в man systemd.service. Где нужно смотреть?

А это уже зависит от тебя и от демонов. Сообщения тех демонов, которые умеют самостоятельно писать в сислог — попадут в сислог. А чей-либо stdout/stderr не попадёт никуда, потому что внезапно journald именно тем (в частности) и занимается, что перенаправляет одно в другое.

Ты как говоришь, будто бы journald - единственное ПО, умеющее перенаправлять stdout/stderr в логи. Впрочим, тут интересно было бы узнать мнение опонентов.

Системд и туда запилят вроде.

Итак У тебя рут Поток логов Ключ для подписи Возможность сгенерить новый ключ

Ман ин миддл подделка логов уже возможна

А если поразглядывать эту систему то инмидл можно и в постфактум превратить Ибо ахииектура крива изначально

Не заморачивайся, по делу ему ответить нечего, это проверено. Юный студень думает, что сисодмин системд начинает рабочий день с обхода датацентра с флешкой и верифицированием логов.