LINUX.ORG.RU

Релиз systemd v38 c поддержкой Journal, замены системе syslog

 , , ,


0

2

Леннарт Поттеринг (Lennart Poettering) анонсировал новый экспериментальный релиз системного менеджера systemd v38, примечательный интеграцией наработок проекта Journal, в рамках которого развивается подсистема, призванная заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Подробный обзор особенностей Journal и отличий от syslog можно прочитать в первом анонсе проекта.

Сообщается, что работа над Journal уже близка к завершению, остаётся нереализованными лишь несколько значительных функций и недостаточно проработана документация. Наиболее заметно наличие Journal при выполнении для сервисов команды 'systemctl status', которая теперь выдаёт в том числе и последние сообщения лога для указанного сервиса. Для совместимости с классическим syslog в systemd интегрирована специальная прослойка, которая использует сокет /run/systemd/journal/syslog для приема сообщений, включая перенаправление сообщений из /dev/log.

Данные сохраняются в /var/log/journal, если такая директория создана, в противном случае лог сохраняется в /run/log/journal. Для просмотра журнала следует использовать утилиту systemd-journalctl, которая по умолчанию генерирует вывод, полностью аналогичный формату /var/log/messages. Используя опции "-o verbose", "-o short-monotonic" или "-o json" можно менять детализацию и формат вывода. Для эмуляции поведения «tail -f» предусмотрена опция "-f".

>>> Подробности

Ответ на: комментарий от ananas

чем тебе /etc/blah/blah-blah.conf не единое древовидное хранилише конфигов типа key=value, да и прочих тоже?

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

и чем open/read/write/close не единый механизм доступа?

Да какой же это вообще механизм доступа. Это ровно настолько же «механизм доступа к конфигурационным данным», насколько и «механизм проигрывания видеофайлов», например.

thesis ★★★★★
()
Ответ на: комментарий от imul

ну толсто же! журнал по этой причине следит за ресурсами системы..

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

ну и как обычно проходил мимо вот и иди мимо...

Thero ★★★★★
()
Ответ на: комментарий от anonymous

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

Thero ★★★★★
()
Ответ на: комментарий от Reset

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


это еще почему?

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от Reset

«принципиально не одобряющие» - это когда не ставят по дефолту. Поверьте, и это уже - зачет!

anonymous
()
Ответ на: комментарий от Reset

А теперь правильный вопрос: почему бы не организовать БД с хешами странз (для безопасности) и индексами поверх текстовых логов, а? В виде отдельной службы?

В общем подумайте, об этом, потому что люди ведь тоже правы: по требованиям к подсистеме логирования бинарный формат сообщений вовсе ни к чему. И однако его ташшшат. Причем в апстрим. Можно конечно все объяснить клоунадой Поттеринга, а можно ведь и придумать другие объяснения. Потому как менеджзверье оно везде одинаковое и RH в этом плане ничуть M$ не лохмаче. А от эксплуатации местами проблемной системы в выйгрыше только саппорт.

anonymous
()
Ответ на: комментарий от AVL2

Я занимаю ими примерно половину, а Леонарт вообще не комментирует ;-))

Повеселило. Особенное если учитывать «Отсутствие комментариев является не только свидетельством неквалифицированности программиста, но и достаточным основанием для его увольнения» (с) Питер Нортон

anonymous
()
Ответ на: комментарий от anonymous

rsyslog давно имеет бэкенды к БД. Насчет имплементации частично-вменяемой функциональности journald (хеши, trusted properties) - см. logstore http://blog.gerhards.net/ http://blog.gerhards.net/2011/12/announcing-logstore.html http://blog.gerhards.net/2011/11/trusted-properties-in-rsyslog.html

Все unix-way, text-based, прозрачно, не приколочено гвоздями.

anonymous
()

Это он? Линуксокапец?

Lavos ★★★★★
()
Ответ на: комментарий от anonymous

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

Повторное открытие архивации LZ77? Ну тогда он точно НАСТОЯЩИЙ NIH!

sergv
()

Стоит вспомнить что RedHat зарабатывает на поддержке. Чем более сложная для поддержки стороним человеком система выйдет - тем больше контрактов на поддержку им, тем больше бабла - тем больше прибыль RedHat. Вот и вся логика journald, вместе с systemd.

RedHat - шаг за шагом повышает порог вхождения в Linux, а вы ищите там благо для всего мира...

anonymous
()
Ответ на: комментарий от geekless

Ты забыл добавить, что в «стандартизированный бинарный формат» будет содержать те же самые слабо формализованые текстовые логи, которые придётся грепать тем же самым грепом. А так всё «хорошо», ага.

Достаточно формализованный формат позволит в одну строчку реализовать сценарий типа «Выбрать все критические события источника foo со статусом bar начиная со времени x:y до времени y:x» без километровых нагромождений не читаемых регулярок. И это без привлечения грепа. Даже винда это давненько умеет стандартными командлетами из ps.

А какие немалые плюсы дает невозможность подделать запись.

Я ничего не имею против KISS, но употреблять его стоит только по месту. Скажем перфокарты тоже имеют немало плюсов перед более развитыми носителями - им не страшно излучение, вся программа сразу на ладони (тем более старый машинный код был гораздо проще). Отпатчить код можно при помощи скотча и ножа. А вот текстовые данные уже не читаемы. Современную программу тоже можно уместить на грузовике перфокарт, но минусы такого подхода будут многократно превышать плюсы.

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

начиная со времени x:y до времени y:x

Пиши лог в БД, в чем проблема?

критические события источника foo со статусом bar

Ага, все дружно кинулись переписывать демоны на новый API, намертво прибитый гвоздями к конкретной системе. Делать больше нехрен?

geekless ★★
()
Ответ на: комментарий от geekless

Ага, все дружно кинулись переписывать демоны на новый API, намертво прибитый гвоздями к конкретной системе. Делать больше нехрен?

Заменить вызовы сислога на другие смогут и мейнтейнеры.

Пиши лог в БД, в чем проблема?

С каких пор демоны поголовно научились писать логи в бд? Какие демоны из тех кто это умеют пишут в человеческом формате позволяющем не использовать полнотекстовый поиск? Смешно уже - чем это будет отличатся от по Леннартовской системы кроме разве что меньшей защиты данных в бд?

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

С каких пор демоны поголовно научились писать логи в бд?

демоны

писать логи

Ты точно головой ни обо что не бился? Или это ты коллективно все реализации логгеров так скастовал?

полнотекстовый поиск

Ты ж по дате хочешь выбирать, дурик. Какой, нахрен, полнотекстовый поиск для этого тебе нужен?

geekless ★★
()
Ответ на: комментарий от Orlangoor

Заменить вызовы сислога на другие смогут и мейнтейнеры.

Бугага. А статусы критичности событий и прочие ключи, необходимые, для выборки без полнотекствого поиска тоже мейнтейнеры будут прикручивать к каждому демону? Ты бредишь.

geekless ★★
()
Ответ на: комментарий от geekless

Бугага. А статусы критичности событий и прочие ключи, необходимые, для выборки без полнотекствого поиска тоже мейнтейнеры будут прикручивать к каждому демону? Ты бредишь.

Малышка, EE WW и т.д. в том или ином виде умеют практически все. Дату-время - умеют все. Источник также. Чего тебе еще надо?

Ты ж по дате хочешь выбирать, дурик. Какой, нахрен, полнотекстовый поиск для этого тебе нужен?

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

Orlangoor ★★★★★
()
Ответ на: комментарий от Pakostnik

Чо, Джопсу донатил? Правда?!!

Джобс не нуждался.

jackill ★★★★★
()
Ответ на: комментарий от Orlangoor

Малышка
Ты совсем дурочка?

Бабы не дают? Галлюцинации на базе спермотоксикоза?

EE WW и т.д. в том или ином виде умеют практически все. Дату-время - умеют все. Источник также. Чего тебе еще надо?

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

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

Я щас тебе страшную вещь открою. Ты можешь индексировать записи по времени вызова syslog(), не меняя ни строчки кода ни в одном демоне. А еще ты можешь их индексировать по ident, facility и level. Только никому не говори, это секрет.

Правильно поставленный вопрос для твоей задачи звучит так: «какие реализации логгера могут писать в базу данных?» И в этом месте умный человек откроет гугл и напишет в строке поиска: rsyslog to db. И что он там увидит... О боже, что это?! Сходи, посмотри.

Поттерлог не нужен.

geekless ★★
()
Ответ на: комментарий от Reset

прочие ключи тоже будут в API

Ветку не читай @ сразу отвечай.

geekless ★★
()
Ответ на: комментарий от Orlangoor

Достаточно формализованный формат позволит в одну строчку реализовать сценарий типа «Выбрать все критические события источника foo со статусом bar начиная со времени x:y до времени y:x»

select shit from table fuck where time и т.п.?

Дык это sql.

Рассмотрим другую возможность - сейчас можно логи перенаправить в другие каталоги/изменить права на чтение и запись на уровне системы (и какого-нить selinux'а). Если я верно понимаю, то подобная гибкость теряется, если у нас тупо одна база/реестр.

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

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

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

jackill ★★★★★
()
Ответ на: комментарий от geekless

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

Принцессе так нужны производные? Тебе недостаточно уже имеющегося в syslog'е источника и критичности? Хорошо, пожалуй и я тебе открою секрет раз уж пошла такая пьянка - куча ПО умеет кастомные статусы, правда оно срет ими исключительно в текст сообщения. Куку!

месте умный человек откроет гугл и напишет в строке поиска: rsyslog to db. И что он там увидит... О боже, что это?! Сходи, посмотри.

И ктоже мне помешает скомпрометировать записи сислога в БД?

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

куча ПО умеет кастомные статусы, правда оно срет ими исключительно в текст сообщения

Вот я тебя и спрашиваю, дуралея, кто же возмётся переделывать все эти кустомные статусы на API поттерлога. Подсказываю ответ: да никто.

И ктоже мне помешает скомпрометировать записи сислога в БД?

Ну а поттерлог как обеспечивает гарантию того, что логгируемое сообщение пришло от настоящего httpd, а не от фейкового? Кинь ссылкой на описание механизма, что ль.

geekless ★★
()
Ответ на: комментарий от geekless

Ну а поттерлог как обеспечивает гарантию того, что логгируемое сообщение пришло от настоящего httpd, а не от фейкового? Кинь ссылкой на описание механизма, что ль.

systemd знает, кого запустил

AptGet ★★★
()
Ответ на: комментарий от jackill

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

Если сервис использует сислог, то искать ничего не надо, только заменить вызовы - остальное задачи логгера, если не использует - то совсем другой разговор.

Рассмотрим другую возможность - сейчас можно логи перенаправить в другие каталоги/изменить права на чтение и запись на уровне системы (и какого-нить selinux'а). Если я верно понимаю, то подобная гибкость теряется, если у нас тупо одна база/реестр.

Если я верно понимаю, то в любом случае лог будет разбит по разным файлам.

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

Такое возможно, хотя за много лет ничего подобного не встречал - обычно собирал логи на отдельном сервере с несколькими массивами, т.к. объемы были огромные что не позволяло их хранить на тех же серверах что и само ПО. И я пока ни разу не встречал чтобы контрольная сумма бэкапов отличалась отличалась от оригиналов. В принципе в фс тоже могут потеряться текстовые логи от этого застрахуют только бэкапы.

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

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

Отсюда вопрос: А нафуя тогда поттерлог нужен?

Может достаточно ^.*syslog*$ в песочницу поселить, плагин к BD и файлы журналов на шифрованую ФС?

sergv
()
Ответ на: комментарий от AptGet

systemd знает, кого запустил

Т.е. через cgoups. Всё ясно.

Ну и что мешает добавить поддержку получения cgroup-ы процесса в нормальный лог?

geekless ★★
()
Ответ на: комментарий от sergv

Ага, значит «/etc/rc.d/blablabla restart» больше уже не проканает?

Проканает только systemdctl blabla.

geekless ★★
()
Ответ на: комментарий от geekless

Ну а поттерлог как обеспечивает гарантию того, что логгируемое сообщение пришло от настоящего httpd, а не от фейкового? Кинь ссылкой на описание механизма, что ль.

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

Вот я тебя и спрашиваю, дуралея, кто же возмётся переделывать все эти кустомные статусы на API поттерлога. Подсказываю ответ: да никто.

Рэдхат ядро не обламывается не то что патчить, но и разрабатывать, каноникл пилить вэйлэнды. Заменить конкатенацию строк в итоговом сообщении отправляющемся в сислог на запись поля с префиксом «_» - что может быть проще?

И вообще - я понимаю - ЛОР и все такое, но в более нормальных тонах общаться гораздо приятнее.

Orlangoor ★★★★★
()
Ответ на: комментарий от sergv

Может достаточно ^.*syslog*$ в песочницу поселить, плагин к BD и файлы журналов на шифрованую ФС?

Файлы журналов на шифрованой ФС не выход. Это ничем не защитит от модификации. Почитай наконец реализацию Поттеринга если не в исходниках, то хотябы информацию из блога

Orlangoor ★★★★★
()

Вообще система тупо совместима с сислогом. И даже добавив поля убрав совместимость изменения потребуются минимальные

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

Файлы журналов на шифрованой ФС не выход. Это ничем не защитит от модификации.

??? 8-( ???

А типа когда исходники всех демонов в свободном доступе, перезапустить фейкнутый журнал-дэ и т.д., то от ЭТОГО поттералло защитит?

Почитай наконец реализацию Поттеринга если не в исходниках, то хотябы информацию из блога

Исходники посмотрел минуты две. Проблевался...

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

sergv
()
Ответ на: комментарий от Orlangoor

Например, как уже написали идентификацией процесса займется systemd,

Это таким гордым словосочетанием ты назвал запрос cgroup-ы у ядра?

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

Слушай, ну как ты умудряешься придумывать проблемы на пустом месте? Если мы пишем логи в базу, то как — КАК? — вражина может до неё добраться? Вынеси её на другую машину, и всё.

Да даже если и на одной машине, и пишем в файлы, а не в базу. Запускай демоны в контейнере.

geekless ★★
()
Ответ на: комментарий от sergv

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

Система совместима с сислогом. Никакими гвоздями ты ничего не прибьешь.

Не читал но осуждаю?

Orlangoor ★★★★★
()
Ответ на: комментарий от geekless

перезапустить фейкнутый журнал-дэ

Чиво? Как ты init перезапустишь?

(Ну, не init, а systemd...)

А! Че, все еще круче? Теперь если журнал-дэ наеб..лся, то система раком встанет? Или если журнал-дэ пакетом обновил, то «Пожалуйста, перезагрузите систему»???

AHTUNG! Микрософт атакует !!! ;-)

sergv
()
Ответ на: комментарий от geekless

Слушай, ну как ты умудряешься придумывать проблемы на пустом месте? Если мы пишем логи в базу, то как — КАК? — вражина может до неё добраться? Вынеси её на другую машину, и всё.

Другая машина также может быть скомпрометирована.

Да даже если и на одной машине, и пишем в файлы, а не в базу. Запускай демоны в контейнере.

Это скорее костыль чем решение. Решение на уровне логгера видится более корректным

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

Система совместима с сислогом. Никакими гвоздями ты ничего не прибьешь.

А журналы из бэкапа? Если они в поттерлоге?

sergv
()
Ответ на: комментарий от sergv

Ну у тебя и криокамера. Читай:

systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.

Т.е. это программа, которая заменяет init, всю скриптовую демоно-инициализирующую логику и чертову уйму демонов. Можешь представить, сколько в ней багов.

И теперь вот она еще заменяет и syslogd.

Я с интересом слежу, на какой демон положит глаз Поттеринг в следующий раз. pppd? dhcpcd? httpd? xdm? Интрига затягивается!

geekless ★★
()
Ответ на: комментарий от Orlangoor

Если у тебя злоумышленник получил достаточные привелегии для доступа к файлам журнала, то тебе уже ничего не поможет. Против echo «хрен вам» > /var/log/logname любая математика бессильна.

geekless ★★
()
Ответ на: комментарий от geekless

Если у тебя злоумышленник получил достаточные привелегии для доступа к файлам журнала, то тебе уже ничего не поможет. Против echo «хрен вам» > /var/log/logname любая математика бессильна.

Это не пройдет незамеченым

Orlangoor ★★★★★
()
Ответ на: комментарий от sergv

Не знаю, как в текущей реализации, но в первом анонсе вроде как обещали в одном процессе. Хотя в исходниках я вроде видел раздельный main() для journald. Мне лень ставить эту кучку отбросов, чтобы проверить.

geekless ★★
()
Ответ на: комментарий от Orlangoor

То смотришь их утилитой, либо дампишь в привычный формат

Судя по исходникам, ЭТО вряд-ли можно будет куда-то спортировать

sergv
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.