LINUX.ORG.RU

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

 , , ,


0

4

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

Референдум был инициирован членом технического комитета Яном Джексоном, который является сторонником системы инициализации upstart. Ян считает, что необходимо предотвратить зависимость пакетов от какой-либо конкретной системы инициализации, в частности - рост числа пакетов, зависимых от systemd.

Наибольшее число голосов набрал вариант, гласящий, что необходимость в изменении правил отсутствует.

>>> Подробности

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от quantum-troll

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

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

Gotf ★★★ ()
Ответ на: комментарий от scalist

А пардон...

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

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

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

:)

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

anonymous ()
Ответ на: комментарий от unt1tled

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

partyzan ★★★ ()
Ответ на: комментарий от intelfx

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

dexpl ★★★★★ ()
Ответ на: комментарий от dexpl

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

dexpl ★★★★★ ()
Ответ на: комментарий от dexpl

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

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

Это у Journal так?

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

alex-w ★★★★★ ()
Ответ на: комментарий от alex-w

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от alex-w

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

alex-w ★★★★★ ()
Ответ на: комментарий от anonymous

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

alex-w ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

targitaj ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от targitaj

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от anonymous

[user@comp ~]$ journalctl

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

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

anonymous ()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

targitaj ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

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

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

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

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

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

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

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

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

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

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

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

Нет.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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.

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

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

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от targitaj

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

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

Polugnom ★★★★★ ()
Ответ на: комментарий от Polugnom

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

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

chrisred ()
Ответ на: комментарий от targitaj

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

Так лучше)

chrisred ()
Ответ на: комментарий от intelfx

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

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

targitaj ★★★★★ ()
Ответ на: комментарий от Polugnom

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от Polugnom

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

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

Polugnom ★★★★★ ()
Ответ на: комментарий от Deleted

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

intelfx ★★★★★ ()
Ответ на: комментарий от Deleted

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

intelfx ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

targitaj ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

Deleted ()
Ответ на: комментарий от targitaj

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.