> Я говорил только о первом компоненте - «API для логов»

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

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

> Если ты открываешь порт 514/UDP, то _любой_ может в него насрать. Кроме того, запись пида процесса в сислог опциональна, и любой процесс может написать что он apache2[1234]

Так ведь все об этом знают, кроме поттеринга, естественно. И используют соответственно. Вот уже несколько десятилетий. И вот, farafonoff, приходите Вы и кричите: «Караул! любой процесс может написать, что он apache2!!! Как это ужастно!!!!!!!111 Долой!»

Для использования прав доступа придется руками править конфиги -я не видел создания файла журнала на каждое приложение изкоробки ни в одном дистре.

А стоит такая задача? Хотите, я Вам кину скрипт, который будет для syslog-ng генерировать по имени «приложения» кусок конфигурации, чтобы складывать в отдельный файл? Или сами справитесь, своими силами?

Вы хоть понимаете, что это - не задача.

Есть реализации сислога с криптографической защитой от подделки логов, они решают весьма специфические задачи с весьма специфическими требованиями. Случай с поттерингом из другой области.

>В сраче где-то пробегало - анонимус говорил, что выпилил systemd, policykit, pulseaudio и т.п. вещи из сузи. Как? Я попытался через Yast, так он предложил полсистемы снести - т.к. всё прибито гвоздями к указанным т.н. «поделиям».

Я другой аноним, но могу предположить, что он выбрал «удалить пакеты XXX, но оставить (и повредить) пакеты YYY, ZZZ и т.д.». А вообще, лучшая OpenSuSE - это Slackware.

Я ж написал. Если никто не использует libbar.so.1.2.3, а используют so.1 — никакого. Его и не оставят. Это у вменяемых обычно значит, что libbar.so.1.2.3 совместима на уровне API/ABI с libbar.so.1.2.4. А вот если нет, то дальше идут варианты :]

И чего он сломал?

Проще было сломать альсу/oss, чем городить этот велосипед.

Obvious fix.

man pulseaudio. Впилить его идеи в альсу практически нереально.

> у вменяемых обычно значит, что libbar.so.1.2.3 совместима на уровне API/ABI с libbar.so.1.2.4

Есть еще понятие bug compatibility

+1000

Он ведь так весь линукс в гроб загонит.

Да успокойся ты, никто эту поделку в никсы не пустит, а если пустит - только опционально для избранных убунтоидов ССЗБ.

мануал по как это делать не могли бы Вы куда-нибудь написать?

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

Ну, такое уже автоматом не сделать, пожалуй. Такого нет, да

Ага, меня это страшное слово «повредить» и остановило. Не такой я спец в сусе, чтобы потом чинить случайно поломанное стремлением к минимализьму. Насчет Слаки - это где все зависимости надо разрешать вручную? нет уж, спасибо.

Спасибо! за перевод

Gentoo - это ещё более клёвая слака. Правда, в последнее время катится в УГ. Например, там вводят systemd, пока опционально. Но многие пакеты (типа dbus) сервисы systemd уже устанавливают строго обязательно. Так до обязательного systemd недалеко. В общем, пора форкать и спасать Gentoo.

>есть конструктивная критика?

Конструктивная критика только одна :) Не нужно лезть с таким подходом в системное программирование. Есть множество областей, где подход тяп-ляп-прототип невозбранно рулит. И не нужно кидать в меня помидоры, я сам адепт подобного подхода и при разработке спецификаций и при их практической реализации.

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

>есть конструктивная критика?

Ну по сути только одно замечание. Все так и сделано.

С той лишь разницей, что сислоговые файлы ведет rsyslog, а «дополнительные индексы» ведет журнал.

Кстати, пытался gentoo ставить по хэндбуку - но видать не осилил этап настройки fstab, система в итоге ругалась на неправильную ФС и не грузилась. Потому Suse, толерантная даже к таким криворуким, хех.
А что до форка - насколько понял, этим megabaks занимается. GTK3 вон уже выпиливает.

>Ну, развели панику, как будто вас кто-то заставляет пользоваться этим поделием.
Пульсаудио зафорсили? Да.
/run зафорсили? Да. (уже и в udev)
systemd форсится? Да. И через три года думаю уже сложно будет без него обойтись, так как поганый поттеринг везде успеет понавтыкать своих коммитов и понаставить
зависимостей.

ЗверьДиВиДи блин, дальше кед системы не видели.

Видели, собирали даже. Не кеды правда.

Плеер не тот? Реинсталл! Кеды старые? Реинсталл! Панелька сбилась? Реинсталл!

Поменьше толксов читайте с нытик-тредами.

Скажешь, что в Линуксе что-то глючит или работает не так как хочется и все как один отвечают - напиши сам. Он написал сам?! Вот урод! Давайте убьём его!!!

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

Меня поражает ваша логика.

> systemd форсится? Да. И через три года думаю уже сложно будет без него обойтись

А я не понимаю, что такого страшного в systemd, после того, как его отладили на пользователях Федоры. Наверное, он не стоил затраченных усилий, но, если он работает, а unit'ы с ним писать легче, чем init-скрипты - why not? Это принципиально другая ситуация по сравнению с поттерлогом - поттерлог предполагает достижение кривого результата кривыми средствами.

Тред не читал, хочу спросить

>Поскольку данная разработка Леннарта войдёт в Fedora 17

Инфа 100%?

Ну GTK3 меня не особо пугает. Притянул Audacious (хотя Мегабакс вроде писал, что это на самом деле опциональная зависимость). Всегда можно сменить плеер. А вот systemd (+journald) - совсем другое дело. Пропихнут даже в Debian Stable (уже в Unstable есть). И в Арч. И в Генту. Останется только Слака. Без зависимостей, зато без поделий поттера и с православным богом Патрегом.

Леннарт делает революцию в линуксе. Не успеем оглянуться, как линукс превратится в винду.

UPD: Легче в Слаку запилить зависимости, чем, например, из OpenSuSE 12.1 выпилить (полностью, а не частично) systemd.

Я бы не сказал, что всё это столь уж прекрасно:
1) Количество места, которое занимают логи на жёстком диске (файлы логов - один из самых злостных источников спама, и это далеко не факт, что они не нужны именно в таком виде)
2) Скорость анализа логов - если они по 4Гб размером, никакой Perl и уж тем более sed, awk и perl за разумное время разобрать логи не смогут, если только у вас не мейнфрейм
3) Принятая в FOSS практика писать логи «кто во что горазд». Если они будут в бинарном виде, то и писать их придётся в строгом формате
4) Ну и да, если Поттеринг приделает к бинарным логам хороший API, то они действительно будут разбираться в десятки раз быстрее
5) «Источники сообщений», отправляемых в Syslog - это, простите, полный маразм (localX, daemon, mail - это что ещё хр.нь такая, кто и в каком веке это придумал?!). Особенно доставляют localX - вообще ни о чём, лучше никак источник сообщения не указывать, чем так. Их бы ещё как регистры процессоры назвали: rax, rbx, rcx. А что? Ни чуть не менее (а)логично.
6) Неоправданный overhead на подсистему i/o опять же из-за размеров того, что в бинарном виде в десятки раз более компактно можно было бы записать

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

Кстати, я вообще не понимаю, чего здесь все так раскричались, если опять же в силу принятых в OpenSource «добрых традиций» больше половины приложений не знает о syslog, из них процентов 20 вообще считают ниже своего достоинства писать логи (в лучшем случае на консоль что-нибудь выс.ут).

>Скорость анализа логов

А это зависит от того, что ты анализируешь. Если тебе нужно выдернуть записи «с часу ночи и до четырех утра», тут индексирование подойдет. Или если надо выдергивать только критичные сообщения (хотя что тебе мешало писать critical отдельно от остального?), тоже индексы помогут. Но, как правило, в логах ищут «ойпи хакира» и прочие данные, собственно, из самого текста сообщения. И чем тут поттеринговский гений поможет?

> Это принципиально другая ситуация по сравнению с поттерлогом - поттерлог предполагает достижение кривого результата кривыми средствами.

Так ведь поттерлог в systemd и впилят.

>> Это принципиально другая ситуация по сравнению с поттерлогом - поттерлог предполагает достижение кривого результата кривыми средствами.

Так ведь поттерлог в systemd и впилят.

Но от этого systemd не потеряет способность пускать unit'ы. А поттерлог, я надеюсь, можно будет обойти, и использовать привычный syslog (я даже надеюсь, что у systemd будет опция configure --with-potterlog=no).

Млять! Пульсаудио до вменяемого состояния после этого пилили много лет. Теперь еще журналы испортить, чтобы после падения никто не прочитал что там...

>тяжелый случай, для БД( а тут речь идет о специализированной БД ) этого не нужно делать, и это и не делается

Нормальные БД крутятся на отдельном дорогом железе, с ИБП, не загруженном левыми задачами, а здесь предлагается устроить пародию на надёжную систему.

> Нормальные БД крутятся на отдельном дорогом железе

загляни внутрь своего браузера

>>Леонарт Поттеринг

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

kill it at the fire

>> Нормальные БД крутятся на отдельном дорогом железе

загляни внутрь своего браузера

Ой рассмешил, неужели Перосяна клонировали? В браузере система работает крайне ненадёжно, иногда требует чистки всей истории для нормального отображения страницы, вдруг протекает и падает и жаба этому помогает, хорошо хоть питона нет. А в играх пропадают некоторые сообщения и шмотки посланные другому игроку. Там конечно и сервер виноват, но у него аналогичная «сверхнадёжная» БД. Поэтому не нужно мне этого глюкалова в линуксе - то чему позволено глючить в приложениях, не должно являться частью системы.

> Ой рассмешил, неужели Перосяна клонировали?

рад, что рассмешил, хоть и не собирался

В браузере система работает крайне ненадёжно

к __методу хранения данных__ какие претензии?

>2) Скорость анализа логов - если они по 4Гб размером, никакой Perl и уж тем более sed, awk и perl за разумное время разобрать логи не смогут, если только у вас не мейнфрейм

man logrotate

3) Принятая в FOSS практика писать логи «кто во что горазд». Если они будут в бинарном виде, то и писать их придётся в строгом формате

Ща, разбежались... На фоне того, что бинарный формат поттерлога будут менять как это заблагорассудится Поттеру, то получаем кучу софта, которые не _смогут_ писать логи из-за _изменения формата_ лога. В результате имеем: комп не работает и почему не работает неизвестно.

4) Ну и да, если Поттеринг приделает к бинарным логам хороший API, то они действительно будут разбираться в десятки раз быстрее

С чего это ради быстрее? К тому же если вдруг этот бинарный лог будет поврежден, то вообще хрен что разберется.

5) «Источники сообщений», отправляемых в Syslog - это, простите, полный маразм (localX, daemon, mail - это что ещё хр.нь такая, кто и в каком веке это придумал?!). Особенно доставляют localX - вообще ни о чём, лучше никак источник сообщения не указывать, чем так. Их бы ещё как регистры процессоры назвали: rax, rbx, rcx. А что? Ни чуть не менее (а)логично.

Если вы что-то не понимаете, то это не значит, что это не нужно. Лучше бы матчасть подтянул, чем кричать «маразм»

> Конструктивная критика только одна :) Не нужно лезть с таким подходом в системное программирование. ... Здесь как раз, необходимо разрабатывать фундаментальную спецификацию, и потратить на ее разработку на несколько порядков больше времени, чем на ее реализацию

так вы не мне это говорите, а поттерингу или AVL2 :)
об этом и разговор, о том, что ломать - не строить. и прежде всего нужна спецификация протокола взаимодействия приложения и лога. проработка API, если уже говорить о программировании. чётко описать структуру. чтобы не получилось, как обычно.
«тщательнЕй надо, тщательнЕй!» (с)

>>есть конструктивная критика?

Ну по сути только одно замечание. Все так и сделано.

С той лишь разницей, что сислоговые файлы ведет rsyslog, а «дополнительные индексы» ведет журнал.

вы говорите, что все деревья - одной породы, потому что тоже листья и тоже ветки (в другом треде про это было). следуя вашей логике, все программы в мире одинаковы, ибо написаны на ЯП и служат одной цели - делают человеков счастливее :)

Опять же. Что вам мешает поставить минимальную систему с initd и без pulseaudio? Может я чего не знаю - может у Федоры systemd и pulseaudio в зависимостях ядра?

Блестящая фраза! Вы не против, если я её немного позаимствую?

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

>к __методу хранения данных__ какие претензии?

Низкая надёжность, которая позволительна для отдельных приложений но не системы в целом.

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

Это ты еще повисающую на этапе старта систему с systemd не пытался заставить работать. Как случится - начнешь как и я ненавидеть поттинга поттерингинг.

Наверно ойпи хакера будут искать среди сообщений apache2/ssh? А если еще будет индекс по полю «адрес клиента» - то вообще мгновенно.

>The Journal: существование linux после исчезновения остатков здравого смысла.

fxd.

> Вот забыла программа написать свой пид - как его узнать?

можешь хоть один пример привести, когда знание пида жизненно важно при анализе логов?

Ничто не мешает. Но если такой «прогресс» будет продолжаться и дальше, то я не удивлюсь и этому.

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

Кстати, я вообще не понимаю, чего здесь все так раскричались, если опять же в силу принятых в OpenSource «добрых традиций» больше половины приложений не знает о syslog, из них процентов 20 вообще считают ниже своего достоинства писать логи (в лучшем случае на консоль что-нибудь выс.ут).
---
Вот собрать бы всех пеньков и вместе с потерингом на галеры отправить. Труд на свежем воздухе должен дурь из башки вышибать. А потом заставить всем переписать прошивки - на железках работающих 24х7.

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

RedHat OS, не оно?

А если еще будет индекс по полю «адрес клиента»

Бугагашечка ты наш... Глупенький... «ойпи хакера» это «application-specific data, и никакие индексы на него поттерлог строить не будет. Так что вместо grep <что-там-надо> /var/log/httpd/acces.log.* ты будешь делать „pottertool --from date1 --to date2 --file /var/log/journal --daemon http | grep <опять_так_что_надо>“

>Наверно ойпи хакера будут искать среди сообщений apache2/ssh? А если еще будет индекс по полю «адрес клиента» - то вообще мгновенно.

При чем, адрес домашний, а еще паспортные данные. И скан справки в блобе, да.