23 ноября 2011, 14:58

На замену syslog предложен новый демон journald

Плюшевый Такс
Иллюстрация с сайта Abclinuxu.Cz

Леннарт Поттеринг (Lennart Poettering) и Кэй Сиверс (Kay Sievers), разработчики из Red Hat, представили альтернативу классической системе журналирования различных событий в ОС syslog. Новый проект получил название journald (systemd Journal daemon).

Авторы отмечают, что пользу syslog, существующего уже около 30 лет, сложно переоценить для системных администраторов, однако у этого инструмента накопилось множество ограничений, которые «со временем превратились в серьезные проблемы». Среди них, например, выделяются: отсутствие аутентификации источников данных («любой локальный процесс может представиться веб-сервером Apache с PID 4711, и syslog ему поверит»), слишком свободная форма логируемых данных (это приводит к излишним сложностям в анализе данных журнала), отсутствие данных о часовом поясе во временных метках (впрочем, не всегда), отдельные логи своего формата для журналов различных системных компонентов (вызывает дополнительные сложности, а также «прячет» зависимости различных событий) и целый ряд других.

Новое решение — демон Journal — позиционируется как ответ на современные требования, который будет достаточно прост, надежен, портируем, производителен, удобен в интеграции, масштабируем и т.п. При этом journald должен стать «хранилищем событий общего назначения», т.е. использоваться для хранения «журнальных записей любого вида вне зависимости от его формата [т.е. от содержащихся в описании событий данных], метаданных или размера». При этом все сведения о произошедшем событии будут передаваться в определенном формате, все записи в журнале — содержать криптографический хеш предыдущей записи в файле (старший в такой цепочке хеш хранится в безопасном месте, открытом только на запись).

Планируется, что первая реализация journald войдет в следующий релиз Linux-дистрибутива Fedora — 17 «Beefy Miracle».

Новый проект вызвал разную реакцию в Linux-сообществе. Например, некоторые считают, что переход с syslog на систему вроде journald — это «прямая атака» на классическую UNIX-концепцию «всё является файлом».

P.S. Леннарт Поттеринг известен как автор PulseAudio и systemd — системных компонентов, которые пришли (или «приходят») во многие современные Linux-дистрибутивы.

Постоянная ссылка к новости: http://www.nixp.ru/news/11511.html. Дмитрий Шурупов по материалам Google Docs, h-online.com.

Fedora, journald, syslog, Кэй Сиверс, Леннарт Поттеринг, логи, тенденции

Комментировать (7)

Читайте также в новостях:

Fedora 17 — новая версия популярного Linux-дистрибутива 612 29 мая 2012 г.
В Fedora рассматривают предложение перенести все исполняемые файлы в /usr/bin 7-2 39 2 ноября 2011 г.

LStranger 15:50, 23 ноября 2011

Кошмар, они ещё одного глючного монстра родили! На всех системах, что я ставлю, я категорически сношу pulseaudio — если забываю, то спустя некоторое время мне начинают жаловаться на звук — либо на пропадания, либо на его неуправляемость, ага.

Ответить Цитировать

Владислав 16:58, 23 ноября 2011

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

Ответить Цитировать

fhunter 17:10, 23 ноября 2011

Я pulseaudio использовал только по его прямому назначению — удалённые колонки, при отстутствии звуковой карты на машине. Вот в таком варианте — работает. А так — после проблем со skype/flash и тд — был зверски выпилен из системы и больше пока не ставился.

Ответить Цитировать

yesint 19:54, 23 ноября 2011

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

Ответить Цитировать

Дмитрий Шурупов 20:09, 23 ноября 2011

Из документа по ссылке-источнику Google Docs:

— Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!

— Well, sometimes improving an existing solution is the way to go, but when the changes necessary are too major a reinvention is a good thing, if it is done for the right reasons, and provides good compatibility with previous solutions. We believe we are doing it for the right reasons, and we try hard to provide greatest possible compatibility.

Ответить Цитировать

yesint 21:52, 23 ноября 2011

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

Ответить Цитировать

rgo 19:06, 29 ноября 2011

> Новый проект вызвал разную реакцию в Linux-сообществе. Например, некоторые считают, что переход с syslog на систему вроде journald — это «прямая атака» на классическую UNIX-концепцию «всё является файлом».

В связи с этим, мне в голову пришла очередная теория заговора. =)

Суть в чём. Всяческие там journald и Wayland, отказываясь от идеи «всё есть файл» в пользу вендового «всё есть API» усложняют reverse engineering приложений*. И делается это при безусловном одобрении и содействии со стороны IT-компаний занятых линуксом — Red Hat, Canonical они в первых рядах хватаются за такие разработки и начинают их внедрять. И собственно теория гипотеза заговора заключается в том, что они сговорились и делают это для того, чтобы перетащить линь на идеологию «всё есть API» и дать таким образом возможность широкого распространения в линуксе пропиетарного ПО — с привязкой к CD, лицензионным ключам и прочей лабуде, которой пока (тьфу-тьфу-тьфу) в линуксе ещё нет. То есть Red Hat и Canonical предали свободу *nix в пользу банального зарабатывания денег.

*) Если кому непонятно, как идеология «всё есть API» усложняет «обратную разработку» я поясню на примере. Возьмём к примеру десктопное приложение с окошками и рассмотрим его реверс в двух случаях:

приложение работает на Xorg
приложение работает на Wayland.

Допустим, приложение, запрашивает лицензионный ключ при старте. Как поймать отладчиком обработку ключа приложением, если оно выводит графику через X11? Элементарно! Берём wireshark и перехватываем весь трафик между X-сервером и приложением. Запускаем приложение, доводим его до окошка со вводом ключа, вводим ключ и смотрим в wireshark. Мы увидим как по соединению бегают ивенты типа keypress/keyrelease. Мы можем при этом подключиться с отладкой к приложению и трассировать приём этих ивентов и отслеживать куда в результате данные складируются. Так же мы легко отследим нажатие на кнопку «Ok». Разработчики и в таком случае могут понаделать проблем ревёрсерам, но… Но теперь глянем на случай с Wayland.

В случае с Wayland у нас уже нет возможности так запросто отловить всё общение между приложением и графической подсистемой. Тут уже надо отлавливать API, и для этого создавать специальный инструментарий — тут будет мало плагина для wireshark, который разбирает протоколы X11. Но мало того, даже если мы перехватим все функции из библиотек Wayland, приложение ведь может как-нибудь исхитриться, получить адреса static-функций Wayland, которые предназначены для «внутреннего использования» и работать с Wayland через эти функции. Приложение при этом может сопротивляться перехвату функций, вплоть до того, что просто отказываться работать, если используется, скажем, LD_PRELOAD. То есть понять что происходит внутри приложения будет существенно сложнее. И ко всему этому ещё добавляются те способы понаделать проблем ревёрсерам, которые доступны при использовании Xorg.

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