>Сформулируйте плиз требования (простым списком)

Требования там простым списком и идут. Какая разница, где не читать, там или здесь?

Во первых, это изменение все равно сломает протокол.

Эта «поломка» несмертельная. Мы сохраняем главный принцип - «получаем больший функционал при сохранении всех плюсов».

получишь то, что Леннарт обещает сделать чуть позже.

Он не собирается этого делать. Ты хоть сам почитай что он предлагает в качестве «сетевой прозрачности» - использование LE в бинарниках и scp. Это курам насмех, как в Windows - «откройте общий доступ к папке 'мои документы' и получите возможность совместной работы с документами».

Во вторых, надо бы еще добавить защиту от потери части записей журнала при передаче

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

https://bugs.launchpad.net/ubuntu/ source/pulseaudio/ bug/590049

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

Краткая суть - ноутбук; не работает встроенный микрофон (ни в скайпе, ни в звукозаписи), при подключении наушников звук пропадает на колонках и не появляется в наушниках; при увеличении громкости через «горячую клавишу» на ноуте включаются колонки И наушники.

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

На чистой alsa в тех же debian, ubuntu, arch, gentoo всё ок. Так что баг исключительно в PA.

Да, для моего ноута советуют прописывать snd-hda-intel=auto в alsa-base.conf, но не помогает ни капли.

Резюмируя всё выше сказанное, Кэп сообщает: «жизнь после syslog» будет не сильно радостной...

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

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

> это надо делать.

:)

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

я не нашел, как она обеспечивается сейчас?

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

Пора нанимать киллера этому господину. Или если все гуманисты, срочно допиливать GNU/Hurd и сваливать на него.

Хм, логично

> И все еще хочу узнать как к требованиям к службе логирования соотносится это круто-эх-поперло поделие?

Очевидно-же - systemd с НОРМАЛЬНЫМ syslog-ом работать не умеет!

Как и с кучей бинарников в массе каталогов на массе разделов.

А все остальное - за уши притянуто.

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

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

проще было внести логгер в systemd, чем реализовывать надежный клей между ним и логгером?

Сокеты. Unix domain sockets. И systemd ничем не отличается от други процессов, кроме PID, он также естественно будет общаться с ним через сокет.

>Ты не понял. Предположим, сейчас я «включу дурака» и перейду на его Journal, и как этот «мастер костыля и подпорки» и предлагает, начну по scp складывать файлы на сервер логов. Ага. И вдруг в следующей версии он меняет формат журнала, и пишет новую версию бибилиотеки. Которая оказывает НЕСОВМЕСТИМА со старым форматом бинарного журнала. И что теперь делать?

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

Насколько реальные достижения будут соответствовать этим целям?

«Ну ты понел»...

Я-то вот как раз прочитал. И даже уже «проиграл» раз несколько в уме. А вот вы... вы так красиво прибавляли в длину простынку в защиту Леннарта, что мне как раз хочется узнать какие проблемы логирования видите лично вы, и какие из них по-вашему решает эта система?

Но судя по пустому списку и отсылок «на простыню» в никуда - ваше видение тоже пустое.

Жаль что звезды на ЛОРе не прибавляют ума. Искренне жаль.

> Друзья, это же просто жесть какая-то. Чувствую, вакханалия Поттеринга кончится распадом сообщества Linux на два лагеря, во главе с Red Hat с одной стороны, и с Debian - с другой.

Поттеринг работает на редхат?

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

> исключить незаметные (необнаружимые) манипуляции с ними [прим. логами]

вообще имхо странно, что это не решается раздачей прав в фс.

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

То есть способность просмотреть любые обрывки любой версии файла журнала на любом компе с любой архтектурой.

Какие есть варианты, кроме текстового представления?

binary

> надо бы еще добавить защиту
всё равно непонятно как этому поможет двоичный сислог?

я ломаю сервак

мимо. ты в этом случае можешь всёравно сделать что угодно.

добавив сюда передачу дополнительных полей

1) добавить их почти ничего не стоит
2) это никого ни к чему не обязывает - совместимость в обе стороны

> Ждём бинарных рее^Wконфигов.

Ждём бинарный реестр и гуёвый regedit.

Ладно еще pulseaudio и кое-как systemd, но эта поделка уже ни в какие ворота не лезет. Бинарный лог - no way

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

Поможет, но этого нет в классическом сислоге.

Об том и спич, что не надо тупо портировать сетевую составляющую сислога в журнал. Надо или смириться с ограничениями сислога и использовать его, или ждать пока новый журнал допилят до _нормальной_ работы в сети или копировать файлы журнала костылями по сети и мириться с лагом. Или все сразу.

[жирнота]Делаем ставки, заменит ли Леннарт /etc на реестр :))

Вейдер

> Поттеринг работает на редхат?
ты знал =D
Леннарт Вейдер уже дышит в свою маску
и да, тащемта Пётерин'. GN

Насколько реальные достижения будут соответствовать этим целям?

Чтобы «реальные достижения» соответствовали целям, надо формализовать как минимум частично формат журнала, указав «это будет меняться, это нет». Работодателю леннарта на это наплевать - у них штат мантейнеров, который будут делать compat-journalclient, а остальным?

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

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

logrotate решает проблему доступного места; zless, bzless отлично читают лог, который можно распаковать, погрепать. Каждый может выбрать удобный инструмент для работы с csv/txt-файлом. Поди-поищи нормальный logrotate для regedit-way ос...

>всё равно непонятно как этому поможет двоичный сислог?

двоичный лог помогает ьраузингу, фильтрации по полям и сжатию данных. Здесь он не при чем.

мимо. ты в этом случае можешь всёравно сделать что угодно.

нет. В админской должна гореть красная лампа - " у сервера XXX пропуск сообщения в логе". «Или сервер давно ничего не сообщает», если вообще никаких известий от него нет.

2) это никого ни к чему не обязывает - совместимость в обе стороны

это как сделать. Очевидно, что было бы неплохо сохранить совместимость.

Linux не плацдарм для тестов. Пусть использует Windows эта ОС для этого и рассчитана.

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

не совсем. головной хеш лежит не в файле лога, а в отдельном месте. И помимо прав, охраняется selinux.

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

Хомячки и так от века ели что дают, а профи будут вынужденны смирится, ибо выбора не будет((((

двоичный

> двоичный лог помогает
ничему он не помогает
proof: оффтопик - очень наглядно
а вот с индексацией текстовых файлов был опыт - проблема решаема и очень простыми инструментами

админской должна гореть красная лампа

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

>Он не про API говорит, но про абсолютно конкретное видение реализации хранилища и работу с ним.

Это вопросы не про API.

Про АПИ у него ответ - линукуйте мою либу в свою программу и используйте API.

Он не про API говорит, но про абсолютно конкретное видение реализации хранилища и работу с ним.

статья большая. Про реализацию он тоже много говорит, хотя бы потому, что она уже есть.

> двоичный лог помогает браузингу,

Неправда. Его НЕЛЬЗЯ читать ЛЮБЫМ редактором/программой для просмотра текста.

фильтрации по полям

Опять неправда. grep сработает ничуть не хуже.

и сжатию данных.

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

> этого нет в классическом сислоге.

«это надо делать»? :)

смириться с ограничениями сислога и использовать его

ограничениями?

>ничему он не помогает

ну файрфоксу помог, когда он перетащил все закладки, журнал в бинарный формат. А там ведь смешные объемы по сравнению с журналом.

всё равно я не вижу никаких преимуществ перед простым MARK как сейчас

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

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

rsyslog+tls

А то я ломаю сервак и блокирую поток сообщений об этом на твой сетевой сборщик логов. Ты только видишь у себя сообщения от крона (нейтральная часть лога). Полная иллюзия спокойной обстановки.

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

>«это надо делать»? :)

да. и Леннарт пишет, что это будет делаться посзднее.

ограничениями?

да. Сислог практически можно заменить cat | nc -h mylogserver

Делать такое еще раз нет смысла.

>Если ты «ломаешь сервак» так, что бы манипулировать потоком логов - ты уже выиграл, вне зависимости от того, будет ли там поделие поцтеринга или *syslog.

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

Если ты про передачу данных между узлами, а не коммитом сообщений в лог _на_ узле, то я уже написал про rsyslog+tls

>Опять неправда. grep сработает ничуть не хуже.

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

Можно подумать, я не грепаю каждый день самбу, freeswitch и messages...

Современные алгоритмы сжатия

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

> двоичный лог помогает ьраузингу

интересно как?

фильтрации

тут уже 100500 раз заметили, что скорострельность логов при чтении никому никуда не вперлась, grep решает.

сжатию данных

logrotate?

у сервера XXX пропуск сообщения в логе

к примеру апач. что за пропуск у него может быть?

«Или сервер давно ничего не сообщает», если вообще никаких известий от него нет.

это не проблема сислога.

Ты не пробовал _сразу_ фильтровать лог по регексам и рассовывать в разные места в зависимости от содержимого? ))

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

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

то я уже написал про rsyslog+tls

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

>к примеру апач. что за пропуск у него может быть?

на локалхосте

9:00 «работаю, все нормуль»

9:01 «пользователь хакер вошел»  — потеряно

9:02 «демон апаче рестартовал»  — потеряно

9:03 «работаю, все нормуль»

в пульте дежурного

9:00 «работаю, все нормуль»

9:03 «работаю, все нормуль»

Кодовое слово перехватят, и засрут тебе весь лог.

> Сислог практически можно заменить cat | nc -h mylogserver

ну так и отлично.

Делать такое еще раз нет смысла.

действительно. вот тебе и решение :)

>Ты не пробовал _сразу_ фильтровать лог по регексам и рассовывать в разные места в зависимости от содержимого? ))

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

Одно дело статистика, а другое дело, когда речь про ошибки и инциденты.

Кодовое слово перехватят, и засрут тебе весь лог.

А оно не передается. Никогда.

Я говорю о home media desktop

home media desktop - уже имеет свои решения. И Linux туда уже не впишется. Не рационально внедрять решения, которые поставят под вопрос целесообразность функционирования линуха там, где он неплохо закрепился.

обычный греп по гигам лога работает очень долго

cast r

Используя словари можно уменьшить объем журнала без сжатия текста.

но зачем? чем не нравится решение cat | gzip ?

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

> на локалхосте

9:00 «работаю, все нормуль»

9:01 «пользователь хакер вошел» — потеряно

9:02 «демон апаче рестартовал» — потеряно

9:03 «работаю, все нормуль»

в пульте дежурного

9:00 «работаю, все нормуль»

9:03 «работаю, все нормуль»

я повторюсь: туннель. простое решение, которое решит еще с десяток проблем просто потому что он есть.