GG
Мы юзаем journalbeat, раскатал один раз демонсетом и все логи полились, причём как системные так и логи контейнеров
Ну, вариант. Да. Только ты не обеспечил гарантии доставки логов )
Size: a a a
2020 September 20
GG
Выше я уже пояснил почему
GG
И все таки кажется, что логам аудита нужно давать больше приоритета, чем логам приложений
LB
А обновлять тупо целиком. Вся эта шляпа с rpm-ostree пахнет трупным ядом
ostree шагает по планете, даже flatpak оказывается через него работает, правда без перезагрузок
k
просто убунту не вывозит )
А как в rhel заведено? Будто там внешних реп нету
AS
да он лет 15 шагает никак не зашагает
AS
в рхел есть епель и все, остальное докером завозишь. в федоре есть коджи
GG
да он лет 15 шагает никак не зашагает
+
k
в рхел есть епель и все, остальное докером завозишь. в федоре есть коджи
А если ты уже в докере?
AS
но ппа, это же верный путь расъепсти все раз и навсегда, там нет контроля никакого. привезешь бинарь, его каким-то паченым гцц собрали, под неведомую глибц и все, пока,
LB
да он лет 15 шагает никак не зашагает
Мне кажется точно где то варится новый формат образов на базе ostree
k
но ппа, это же верный путь расъепсти все раз и навсегда, там нет контроля никакого. привезешь бинарь, его каким-то паченым гцц собрали, под неведомую глибц и все, пока,
Там автоматическая сборка же
GG
Мне кажется точно где то варится новый формат образов на базе ostree
Свари, покажи пример
GG
Там автоматическая сборка же
Это не гарантия работоспособности
AS
да есть такой формат, назывется nixOS
k
Это не гарантия работоспособности
Это гарантия отсутствия патченного gcc
GG
Я лично за подход CoreOS (старой)
AS
там сборка то автоматическая, но она никак не бьется с твоей убунтой
GG
Это гарантия отсутствия патченного gcc
Нет
GG
Гарантией является прозрачность процесса сборки и используемых в нем компонентов, но это имеет ортогональное отношение к автоматике