vitus_wagner (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
vitus_wagner) wrote2015-03-24 04:47 pm
vitus_wagner) wrote2015-03-24 04:47 pm
Entry tags:
Пропоттеринга
А все-таки жаль что Поттеринга не затравили до самоубийства.
А то вот у меня тут в lxc контейнере jessie. Вдруг после перезагрузки хоста взял и перестал пускать.
На консоли пишет Cannot make/remove an entry for the specified session, а при заходе по ssh просто "connection closed".
При этом найти идиотские бинарные логи этого идиотского systemd из хост-системы не получается. Делаю chroot в контейнер, пытаюсь запустить эту якобы "жутко удобную" специутилиут journalctl, а она мне говорит "мужик, у тебы /proc не смонтирован". Впрочем, смонтировал её /proc, все равно ничего не нашла. Пришлось в этом chroot-е поставить sysvinit-core и rsyslog и перезапустить контейнер.
После этого появились нормальные текстовые логи, и зловредный pam_loginuid.so был уличен и казнен.
Впрочем подозреваю, что этот самый pam_loginuid который ставит на процесс некий расширенный атрибут (что почему-то не позволено делать из контейнера) - это тоже поттеринговское извращение.
Типа чтобы можно было корректно проаудитить процессы, запущенные юзером через su или sudo или процессы с suid-битом, и записать их на счет юзера.
Но блин, ставить это с session required по умолчанию (хотя аудит процессов нужен в одной системе из миллиона, поскольку остальные single-user), зная что в контейнерах это не работает...
А то вот у меня тут в lxc контейнере jessie. Вдруг после перезагрузки хоста взял и перестал пускать.
На консоли пишет Cannot make/remove an entry for the specified session, а при заходе по ssh просто "connection closed".
При этом найти идиотские бинарные логи этого идиотского systemd из хост-системы не получается. Делаю chroot в контейнер, пытаюсь запустить эту якобы "жутко удобную" специутилиут journalctl, а она мне говорит "мужик, у тебы /proc не смонтирован". Впрочем, смонтировал её /proc, все равно ничего не нашла. Пришлось в этом chroot-е поставить sysvinit-core и rsyslog и перезапустить контейнер.
После этого появились нормальные текстовые логи, и зловредный pam_loginuid.so был уличен и казнен.
Впрочем подозреваю, что этот самый pam_loginuid который ставит на процесс некий расширенный атрибут (что почему-то не позволено делать из контейнера) - это тоже поттеринговское извращение.
Типа чтобы можно было корректно проаудитить процессы, запущенные юзером через su или sudo или процессы с suid-битом, и записать их на счет юзера.
Но блин, ставить это с session required по умолчанию (хотя аудит процессов нужен в одной системе из миллиона, поскольку остальные single-user), зная что в контейнерах это не работает...
no subject
А еще больше людей, которым попросту безразлично выживу я или нет в результате каких-то их действий.
И считаю идиотизмом полагать, что если я не буду желать никому смерти, то и мне никто не будет желать смерти.
Примерно таким же, если не большим, как придувать для логов такой формат, что его нельзя читать без использования специальных утилит.
no subject
no subject
Тут одни названия файлов-то чего стоят - сразу заставляют вспомнить "нет ничего более постоянного, чем временное".
no subject
no subject
no subject
зачем практически все СУБД хранят данные в бинарях вместо человекочитаемого текста
и т.п.
no subject
Помнится, когда мы обсуждали проблему визуализации больших графических файлов на maemo, один такой деятель пытался мне доказать, что невозможно на экране 800x480 показать с масштабированием tiff-файл 16000x12000 имея всего-то 256 мегабайт памяти. В то время как я в 93 году писал вьюер для подобных файлов (правда не tiff, но по смыслу то же самое) работавший в реальном режиме DOS.
no subject
no subject
no subject
no subject
Логгер с такой функциональнсотью делается из syslogd одной строчкой в конфиге
*.* /dev/null.
no subject
no subject
Хорошо у меня был воспроизводимый случай. А если бы это блин, была хакерская атака?
Поэтому если эта хрень этого не сделала при установке пакета, мейнтейнера пакета нужно повесить на одном дереве с Поттерингом.
Впрочем меня не удивляет что эту хрень не взялся мейнтейнить человек имеющий представление о том как надо работать в области информационной безопасности.
Потому что у всех таких людей реакция на systemd "уберите эту гадость из моего дистрибутива".
no subject
no subject
Я уже лет тридцать как вырос из того возраста, когда домашнее задание задают.
Если ты хочешь мне, а также множеству других людей привыкших к unix-way доказать, что systemd хорошая штука, напиши книгу.
Размером примерно с Oracle Concept Manual, а лучше - с SAH. В которой будут все полезные вещи которые делает systemd изложены последовательно и логично
(на мой взгляд, это невозможно. Нынешняя подсистема роутинга в линуксовом ядре куда концептуально чище, но и то когда Алекс Кузнецов собрался ее документировать, он вынужден был половину кода переписать.)
В лучшем случае получится что-то вроде рихтеровского Windows NT Internals, по прочтении которого данная категория людей скажет "да, спасибо, мы так и думали, что это страшная гадость, от которой нужно держаться подальше".
no subject
no subject
no subject
no subject
1) расширенная функциональность journald не имеет особой ценности, если к ней добавляется способность все логи вовсе потерять, особенно если это получается по дефолту.
2) проблемы, которые добавляют бинарные логи, более существенны, чем те, которые они решают.
(можете со мной не дискутировать по этим тезисам, я лишь указываю, что эти ответы есть в более-менее явном виде)
no subject
Однако вас это никак не оправдывает.
no subject