Разработчики Debian не приняли правило о поддержке нескольких систем инициализации

И лапша из скриптов, не вынесенная в модули.

Некоторую минимальную часть всё же вынесли. Совсем минимальную, к сожалению. И даже спустя годы не все активно поддерживаемые пакеты используют эти стандартные функции в init-скриптах.

А пардон...

Сразу аватарке то твоей не придал значение...

То про хвост пишешь... Вот про коричневое вспомнил...

Лисы кстати любители поедать и коричневое и падаль всякую (системд)...

:)

От тебя ни одного комментария по теме... Озабоченный нетрадиоцеоналист ты наш :)

Просто ты криворукий. Мне одно интересно зачем ты о своих недостатках другим рассказываешь?

Перепись пионеров, кричащих, что все новое лучше.

У меня складывается впечатление, что скоро я уйду на что-нибудь из unix. Нечитабельные логи - это полный и законченный бред.

А в чём. собственно, проблема? Вместо cat будет другая команда, с поддержкой фильтрации по куче параметров. Это так ужасно? Я вот «бреда» не вижу; напротив, это сильно удобнее, чем было раньше. В конце концов, syslog никто не отменял — там есть перенаправление.

А в чём. собственно, проблема?

Не доводилось видеть на Винде ошибки типа «файл журнала событий поврежден»? И все, лога нет.

В конце концов, syslog никто не отменял — там есть перенаправление.

Только это и утешает.

И все, лога нет.

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

Почему текстовый файл не может повредиться?

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

FYI, повреждение файла журнала вызывает недоступность только тех записей, которые повреждены.

Это у Journal так? Хорошо, если так. Просто с виндологами это точно не так.

Хотел бы я знать, что вызывало виденные мной поврежения виндовых логов.

Мне тоже интересно. Может, они не append-only, и есть риск повреждения метаданных/заголовка при некорректном завершении чего-нибудь?

Это у Journal так?

Да, именно так. Журнал как раз-таки append-only, т. е. то, что уже на диске, оттуда не исчезнет (баги в ФС не рассматриваем).

Почему текстовый файл не может повредиться?

Если повредился текстовый файл, то в большинстве случаев его всё равно можно прочитать (не рассматриваем случай повреждения, при котором размер текстового файла равен 0). Если поврежден бинарный файл, то в большинстве случаев его невозможно прочитать. Интересно, когда эта простая истина дойдёт до ярых сторонников systemd с его бинарными логами?

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

В большинстве — возможно. Но не в этом случае, на что я уже указал.

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

4.2, иди учись в школе. примеров пруд пруди, чуть ли не все аудио- и видеоформаты.

4.2, иди учись в школе. примеров пруд пруди, чуть ли не все аудио- и видеоформаты.

Анонимус, прочитай-ка мне битый mp4, к примеру.

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

Как это типично на ЛОРе - после испражнений жидким стулом трусливо бросаться оскорблениями

Отлично, в чем тогда будет отличие такой системы от венды? Принципиально.

Ок, сильно удобнее. Сделайте мне выборку по ВСЕМ логам, которые сейчас в папке /var/log с рядом условий. На офлайн-системе. Да, вы подцепили погашенную виртуальную машину и хотите поработать с логами. Включать машину нельзя. Как будет выглядеть решение?

фанбои системд уже задолбали.

Отлично, в чем тогда будет отличие такой системы от венды? Принципиально.

А в чём оно должно заключаться? Здесь вот формат более продуманный — append-only. И journalctl мощнее, чем соответствующая оснастка виндовой консоли управления.

Как будет выглядеть решение?

Весьма просто.

journalctl -D /mnt/whatever/var/log/journal

journalctl --directory /%mnt_point%/var/log | grep «Neosiljator detected»

[user@comp ~]$ journalctl

bash: journalctl: команда не найдена

что-то не работает ;) Упс :)

Понятно. То есть, в работающей системе должен быть journalctl. Что делать если его там нет? Дистр такой.

Таки про венду - я не про реализаци, а про принцип. Чем принципиально будет отличаться этот черный ящик от венды? Вот unix, например, следует принципам, один из которых гласит «human readable». Венде этому принципу не следует. Часть linux теперь тоже не следует. Так в чем разница?

Кстати, там случайно еще не возникло идеи о бинарных конфигах? Если уж слать human readable, то слать совсем. Что это за полумеры такие? Давайте напилим единую утилиту для управления всеми конфигами в системе. Хм. Наверное, я камраду Леннарту самолично отпишу. Подарю идею. Пускай заводит базу данных под конфиги. Пусть заодно причешет формат всех конфигов под один шаблон. Бардак же.

Но это тоже полумеры. Дискриминация man-файлов же. Очевидно, что и под man файлы тоже надо базу данных. Сами man файлы, естественно, перевести в бинарный вид.

Что там еще осталось в читабельном виде? Всё нахер в бинарный вид и в БД перенести надо. А иначе это просто хаос какой-то. Часть системы читабельна и лежит просто файлами, часть - в бинарном виде. Ну бардак же.

Однозначно, пишу Леннарту. Сегодня же.

Кстати, там случайно еще не возникло

у лени чего только не возникло :)

не зря же упоростость программистов в «поттерингах» меряют :)

он сейчас свой пакетный менеджер пилит на базе ФС, так что пока он занят :)

Есть идея. Надо ему сказать чтобы не свой софт писал, а единый конвертор любого кода в софт Леннарта. С едиными базами бинарного всего. Работает такая штука очень просто. Берешь такую утилиту, скармливаешь ей источник (iso, например), жмёшь enter и на выходе получаешь готовую систему с бинарным всем, в базах данных. И одной единой утилитой управления. По-моему, это гениальная идея.

Сам спросил, сам ответил, сам посмеялся над своим «остроумием». Идеально. Мой ответ ещё требуется?

Конечно, ответ нужен. Что делать с логами, лежащими в образе погашенной системы? Их надо обработать. На хосте, куда подключили образ, такой утилиты нет. ОС переставлять на ту, в которой есть? Виртуалку отдельную завести?

А я не смеюсь. С чего ты решил, что я смеюсь? Мне совершенно не смешно.

И да, я на полном серьёзе буду писать Леннарту со всем вышеуказанными «идеями».

Хм, а у Леннарта, случаем, нет претензий к архиваторам? Может быть, стоит свой написать?

Вот unix, например, следует принципам, один из которых гласит «human readable»

Unix не следует никаким принципам. Принципам следуют фанатики.

«Всё есть текст» — это хорошая инженерная «идиома», но у неё (как и у любого другого решения) есть своя область применимости. Не всё выгодно хранить в виде текста. Если ты не согласен, предлагаю взглянуть на ELF. Или на mandb: внезапно, там тоже бинарная база данных.

Все дальнейшие слова про «следование принципам» я проигнорирую, потому что принцип не является техническим аргументом.

А насчёт винды — оно много чем отличается от винды. И наличие/отсутствие текстового формата хранения данных здесь совершенно не играет роли.

Что делать с логами, лежащими в образе погашенной системы?

Я привёл команду.

На хосте, куда подключили образ, такой утилиты нет.

Значит, её нужно установить. Если нет в дистрибутиве — значит, её нужно скомпилировать. И не нужно говорить, что это, мол, сложно: это несложно. Если что, journalctl не требует запущенного systemd.

И да, я на полном серьёзе буду писать Леннарту со всем вышеуказанными «идеями».

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

Хм, а у Леннарта, случаем, нет претензий к архиваторам?

Нет.

Установить, значит. Хорошо.

http://en.wikibooks.org/wiki/Linux_Guide/How_Linux_Works he Linux Way can be summarized as: Use programs that do only one task, but do it well. To accomplish complex tasks, use several programs linked together. Store information in human-readable plain text files whenever it is possible. There is no «one true way» to do anything. Prefer commandline tools over graphical tools.

Скажи мне, а зачем вообще вот этот сыр-бор с бинарными логами? Чего ради? Какие-то супер-выгоды?

Случайно не подскажешь адрес, куда писать?

http://en.wikibooks.org/wiki/Linux_Guide/How_Linux_Works

А с каких пор wikibooks стал истиной в последней инстанции? Я вот не склонен принимать на веру всё подряд, вне зависимости от того, где это написано.

Скажи мне, а зачем вообще вот этот сыр-бор с бинарными логами? Чего ради? Какие-то супер-выгоды?

Вроде того. Ради поиска и фильтрации по полям. Каждому сообщению сопоставляются некоторые метаданные, и journalctl может по ним фильтровать. Например:

journalctl --since=today --priority=err --unit smartd.service
journalctl --boot -1 # показать сообщения от предыдущего запуска системы

systemd-devel@lists.freedesktop.org

Скажи мне, а зачем вообще вот этот сыр-бор с бинарными логами? Чего ради? Какие-то супер-выгоды?

Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и вычистить из системных логов записи, выдающие их активность. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога.

Это был контрольный...

А что большинство кипятятся из-за бинарных логов?

Скажи мне, а зачем вообще вот этот сыр-бор с бинарными логами? Чего ради? Прицепиться больше не к чему?

Так лучше)

Вроде того. Ради поиска и фильтрации по полям. Каждому сообщению сопоставляются некоторые метаданные, и journalctl может по ним фильтровать.

Но ведь есть awk/grep/sed и прочие утилиты.

Вот оно что. Понятно. Это довод. Допустим, логи тупо удалят. После злонамеренных действий. Новая система справится с этим?

Это попросту менее эффективно, чем индексируемая БД, коей является журнал.

С этим ничто не справится, кроме реалиаймовой отправки логов на защищённую систему.

Но отсутствие логов (если их потёрли) — уже свидетельство злонамеренных действий. А от тихой подмены FSS защищает.

Нет.

Нет, но это решаемо) systemd использует сжатие где-нибудь?
Значит надо добавить systemd-compressd и прочие -xzd, gzipd и bzip2d.

https://s-media-cache-ak0.pinimg.com/736x/53/70/54/53705403f112dc99945d848d68...

Зачем *d? Хватит sd_compress() в libsystemd_internal. Но пока что хватает существующей библиотеки.

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

для этих действий нужно повышение привилегий?

В Journal для решения данной задачи

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

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

Это попросту менее эффективно

в каких попугаях измеряем эффективность?

никак их скрыть задним числом злоумышленник не сможет.

что ему может помешать?

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

Тебе известно, что такое криптографическая подпись? Это оно.

что ему может помешать?

надо думать, что хеши, как минимум.

Мда. Идея бинарных логов ясна, в общем. Пока у меня нет мнения на этот счет.

Под эффективностью понимается производительность.

производительность чего? говори конкретно, что я щипцами вытаскиваю?

Тебе известно, что такое криптографическая подпись? Это оно.

и как она поможет себя не изменить/удалить/итд?

надо думать, что хеши, как минимум.

защита от дурака.

говори конкретно, что я щипцами вытаскиваю?

Вытаскивай сколько хочешь. Я не обязан что-то тебе разжёвывать. Производительность фильтрации по запросу, естественно — речь шла о противопоставлении бинарной БД утилитам для работы с текстом (sed/grep/awk).

и как она поможет себя не изменить/удалить/итд?

Значит, тебе не известно, что такое криптографическая подпись, а точнее, forward secrecy. читай раз, читай два.

В данном случае лог-файлу сопоставляется некая инкрементально вычисляемая хэш-сумма. Если подменить одну или более записей в логе, сумма не сойдётся. Подобрать сумму невозможно за разумное время (NP-полная задача). Если удалить лог, это будет заметно.