Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Еще не утихли срачи^W продуктивные обсуждения на Linux.org.ru инициативы небезызвестного Lennart Poettering по замене syslog на Journald, а ведущие разработчики решений на базе стандарта RFC 5424 (syslog) уже встретились, чтобы лицом к лицу ответить на суровую критику от Poettering'а.

На прошедшем недавно Fedora Developer's Conference в чешском городе Брно встретились Rainer Gerhards, основной разработчик rsyslog, Balazs Scheidler, основной разработчик syslog-ng, William Heinbockel, один из соавторов стандарта CEE со стороны Mitre, Lennart Poettering, Steve Grubb, нынешний мэйнтейнер auditd, работник Red Hat и участник проекта Fedora. Были и еще некоторые заинтересованные лица из числа участников Fedora Project.

По результатам встречи было признано очевидное (о чем и говорил Lennart Poettering) - система ведения журнала в Linux действительно в печальном наколеночном состоянии, негодном для серьезного использования в сложных системах без значительной доработки и написания кучи скриптов на shell, perl, sed/awk и python с php. Например, нет стандартов на хранение бинарного журнала (в базе данных, например), нет формата на структуру сообщений (почитайте man 3 syslog - там довольно исчерпывающая информация о его возможностях). Основной проблемой служит то, что подавляющее большинство разработчиков в своих программах просто задействуют старый интерфейс BSD syslog, который оперирует лишь с текстовыми строками, получаемыми от приложения (отдельный разговор, это то, как в эти строки вставить бинарные данные, и что будет потом). Т.е. основная проблема с журналированием в Linux, это ты, ленивый разработчик! С другой стороны, те разработчики, которые упираются в примитивность традиционного текстового BSD syslog, из-за слабой информированности о возможностях современных syslog-демонов, просто берут сторонние (или создают свои - Journald) нестандартные решения для ведения журналов - тысячи их!

В результате, даже в популярных Linux-дистрибутивах сразу работают несколько логгеров - один из популярных syslog-демонов, работающий хорошо если на 10% своих возможностей, и еще пара-тройка средней паршивости и отлаженности (а теперь еще будет работать и Journald). Например, отдельный логгер для auditd и сообщений selinux, отдельная подсистема для Java-приложений (Log4J, который может использовать syslog, а может и нет). Не стоит и говорить, что практически любое большое приложение (как принято говорить, Enterprise уровня) использует свою систему ведения журналов, т.к. его разработчики скорее всего уже имеют печальный опыт общения с примитивным void syslog(int priority, const char *format, ...);

С 2007 года существует проект CEE, от Mitre, в рамках которого добиваются синхронизации стандарта на формат сообщений журналирования, и проект уже привлек внимание внушительного количества заинтересованных компаний, однако большинство oткрытых программ, написанных энтузиастами, не использует наработок этого и других проектов, в результате чего журналирование в Linux дистрибутивах сильно отстает от журналов, ведущихся в проприетарных продуктах и операционных системах, разработчики которых внимательнее прислушиваются к своим пользователям. Опять-же, посмотри в зеркало, ленивый opensource девелопер!

Учитывая эти и другие факты, на встрече было решено создать совместный проект - Lumberjack, в рамках которого будет проводиться популяризация и внедрение в популярные Linux дистрибутивы стандартов CEE, RFC 5424 и наработок Lennart Poettering. В рамках проекта предложена трехуровневая система, в которой внизу будет находиться бэкенд для физического ведения журнала (традиционные текстовые файлы, база данных, сетевое хранилище и т.п.), в середине будет сам демон журналирования, а сверху будет одновременно доступно несколько вариантов API - традиционный, для примитивного журналирования, как было принято в простеньких системах в конце 1980х, и структурированные логи событий, как это требуется для сложных систем второй декады XXI века. У проекта уже есть подпроект - ELAPI, библиотека, упрощающая внедрение CEE-журналирования в приложения. Она развивается Red Hat и участниками Fedora.

Ждите скоро в Fedora, а затем и в других дистрибутивах!

Официально объявлено, что EPEL 4 более не поддерживается с 29 февраля. Мы предупреждали ранее, что это скоро произойдет, так-что, "кто не спрятался - я не виноват". Один из вариантов дальнейших действий владельцев систем, с развернутым RHEL4, это перейти на RHEL5 или RHEL 6 (или их производный дистрибутив, такой, как CentOS или Scientific Linux).

На прошлой неделе в одной из рассылок Fedora проскочил запрос на исключение пакета system-config-network из Fedora Rawhide и будущих версий Fedora.

При ближайшем рассмотрении выяснилось, что это происходит в рамках "System Configuration Tools Cleanup Project", т.е. проекта по приведению в приличный вид конфигурационных приложений. По всей видимости под проект попадут и некоторые другие приложения. В частности пакет system-config-network собираются исключить из-за схожести с NetworkManager'ом.

В репозиторий russianfedora выложен обновлённый клиент DC++ eiskaltdcpp 2.2.6. Помимо обновления версии, интерфейс eiskaltdcpp-gtk переведён на GTK3.