Там нет никакого рокет сайенса. Обычный C. Если отбросить страхи — можно спокойно заняться. Тем более, 1227 открытых тикетов — сколько можно пользы комьюнити принести и уважения получить.
Ну а может полчаса найдётся, чтобы нормальный тикет завести, с подробной диагностикой проблемы? Я на гитхабе поискал — нет тикета. Значит не такая она известная. А телепатов среди разработчиков нет.
разумно ведь в desktop системе все логи писать на HDD
У вас в 2020 году HDD на десктопе? Даже без bcache? А что-за диск, кстати, не какой-нибудь пыльный Seagate 15-летней давности или люто тормозной WD Green случайно?
но systemctl status использует journald и поэтому тоже дико тормозит
Это никому не нужно. Большинство на SSD живут. Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.
Или захочется использовать центрилизованный сбор логов
Ну опять же — если очень надо, то делайте PR на гитхаб. Очевидно, что этот функционал не особо востребован, поэтому тикет висит несколько лет, а решить его некому.
Для сбора логов есть другие, более подходящие средства.
Противоречит в том, что у journald логи всегда сжаты. Не будет там «x2», равно как и ситуации, когда безумный процесс нагенерил 5Гб логов и они в текстовом файле валяются, пока logrotate не запустится.
доку по сустемди могли сделать какой-то более человечной
У systemd отличная дока, всё подробно расписано. Что не нравится? Много чего запоминать надо? Так не надо — man systemd.directives
Разработчик поставляет докерфайл, т.к. ничего другого он не умеет
Почитайте, что такое podman и расскажите заказчику. В этой схеме явно многие слышали лишь «напевы Мойши» про docker.
podman — это docker без демона, работающего от рута. В крайнем случае его вообще можно самому скомпилить, положить в /home и использовать. Да, для сборки контейнера — берём buildah.
Наличие докерфайла упрощает жизнь, вот и надо его использовать. Зачем городить какие-то костыли и грабли?
rsyslog в убунту 18 берет и бережно эти логи перекладывает в /var/log/syslog
Он ничего не перекладывает. rsyslog вообще про journald не знает ничего и ему не нужно знать. Что ему в сокет пишут, то он пишет на диск. А пишет ему journald. Не нравится — systemctl disable --now rsyslog или apt purge rsyslog.
две не совсем очевидные настройки
Очень даже очевидные. Всё в документации подробно расписано.
[NETWORK] SECTION OPTIONS
…
Private=
Takes a boolean argument, which defaults to off. If enabled, the container will run in its own network namespace and not share network interfaces and
configuration with the host. This setting corresponds to the --private-network command line switch.
Загрузиться по сети, чрутнуться, запустить сервисы в незагружаюшейся системе
Это каждый день происходит? Сочувствую. А раз в полгода можно глазами .service посмотреть, он редко когда больше 1 экрана размером.
система не загружается до ssh намного чаще именно под systemd
Если вы работаете в серьёзной компании (или пользуетесь нормальным хостером), то коннектимся в iLO/IPMI/IP-KVM и просто с консоли разбираемся. А если так, поиграться — ну, опять же, можно посочувствовать и пожелать удачи в организации хороших условий работы.
чаще всего не отключаешь, а оставляешь
Для этого есть один раз написанный сценарий ansible, чтобы привести хост к нужному состоянию. Да, если он смотрит в интернет — первое, что делаем — закрываем доступ отовсюду.
все уязвимости в systemd пошли по второму кругу — dns/ntp amplification уже были
В systemd нет NTP сервера, только клиент, там не могло никакого amplification быть.
ждём shellshock over dhcp
Не дождётесь. Советую ознакомиться со списком ограниченных пермишнов:
Давайте кроме cron-а добавим Systemd Timer, чтобы сразу две программы выполняли одни и те же функции.
«Всё сказанное может быть использовано против вас»
Админы localhost'а, скорее всего, с таким и не сталкивались никогда, но в реальной жизни сплошь и рядом проблема — многократный запуск кроном одного и того же процесса. Потому что во времена, когда «UNIX way ещё не был потерян» такой сценарий просто не встречался.
systemd.timer нам даёт «из коробки» гарантию, что не более 1 копии сервиса будет запущено, ограничение по времени работы, jitter времени запуска (чтобы 1000+ серверов не ломились разом обновлять список пакетов) и плюс, все остальные плюшки, которые systemd даёт. Даже можно сделать так, чтобы до/после сервиса запускался другой автоматически по зависимостям (с другими пермишнами, например).
CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права
Он не для выдачи прав, а для ограничения возможностей. Например, указанная строка сделает так, что процесс и его дети не смогут делать, всё остальное (что через capabilities рулится), даже если от рута работают.
Для выдачи прав есть AmbientCapabilities=, например:
AmbientCapabilities=CAP_NET_BIND_SERVICE
Это не в systemd дело, просто подсистема capabilities так работает.
Есть очень-очень крупный проект (master) и есть свой личный форк (fork) проекта с личными изменениями, которые, по каким-то причинам, не могут быть приняты (либо не хочется отправлять) в апстрим. Проект большой (десятки-сотни тысяч коммитов), личные изменения — максимум 10-20 коммитов.
Пришло время подтянуть свежие обновления из крупного проекта. Есть два варианта:
1) можно замержить master → fork
2) можно сделать rebase
В случае «1» наши фиксы со временем перемешиваются с коммитами из апстрима и через пару лет уже будет трудно разобраться, что происходит.
В случае «2» у нас всегда в ветке fork сверху те 10-20 коммитов с нашими фиксами и ситуация всегда ясна, конфликты проще разрешить при значительных изменениях в апстриме.
Для облегчения ситуации можно при каждом обновлении из апстрима создавать новую ветку fork-YYYYMMDD, чтобы после rebase хэши коммитов не менялись.
что пишет? Где затуп?
что значит не прогружается? sshd не запускается? getty на консоли не запускается?
У меня 9-летней давности ноут с 500Гб SSD. Что я делаю не так?
Цены? Ну вроде как в IT индустрии на зарплаты люди не жалуются?
(сразу добавлю, что ноут — это ThinkPad x220 и он старый не потому, что денег нету на новый :)
Там нет никакого рокет сайенса. Обычный C. Если отбросить страхи — можно спокойно заняться. Тем более, 1227 открытых тикетов — сколько можно пользы комьюнити принести и уважения получить.
Ну а может полчаса найдётся, чтобы нормальный тикет завести, с подробной диагностикой проблемы? Я на гитхабе поискал — нет тикета. Значит не такая она известная. А телепатов среди разработчиков нет.
У вас в 2020 году HDD на десктопе? Даже без bcache? А что-за диск, кстати, не какой-нибудь пыльный Seagate 15-летней давности или люто тормозной WD Green случайно?
Это никому не нужно. Большинство на SSD живут. Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.
Ну опять же — если очень надо, то делайте PR на гитхаб. Очевидно, что этот функционал не особо востребован, поэтому тикет висит несколько лет, а решить его некому.
Для сбора логов есть другие, более подходящие средства.
А чем вы занимались 3 года? PR на гитхаб кто делать будет? Добрый дядя? Или может она всё же не такая известная?
Если что — относительно недавно мой PR в системд приняли без вопросов. Даже страшный Поттеринг не пришёл, хотя я уже готовился.
Противоречит в том, что у journald логи всегда сжаты. Не будет там «x2», равно как и ситуации, когда безумный процесс нагенерил 5Гб логов и они в текстовом файле валяются, пока logrotate не запустится.
У systemd отличная дока, всё подробно расписано. Что не нравится? Много чего запоминать надо? Так не надо —
man systemd.directivesПочитайте, что такое podman и расскажите заказчику. В этой схеме явно многие слышали лишь «напевы Мойши» про docker.
podman— это docker без демона, работающего от рута. В крайнем случае его вообще можно самому скомпилить, положить в /home и использовать. Да, для сборки контейнера — берёмbuildah.Наличие докерфайла упрощает жизнь, вот и надо его использовать. Зачем городить какие-то костыли и грабли?
Он ничего не перекладывает. rsyslog вообще про journald не знает ничего и ему не нужно знать. Что ему в сокет пишут, то он пишет на диск. А пишет ему journald. Не нравится —
systemctl disable --now rsyslogилиapt purge rsyslog.Очень даже очевидные. Всё в документации подробно расписано.
Читаем man systemd.nspawn:
Возьмите podman и не мучайтесь.
Это где она жрёт? По дефолту jourlnald пишет в /run/systemd/journal (который tmpfs). К тому же он логи ротейтит и сжимает.
Так кто мешает самому вписать, зачем 6 лет ждать?
Это каждый день происходит? Сочувствую. А раз в полгода можно глазами .service посмотреть, он редко когда больше 1 экрана размером.
Если вы работаете в серьёзной компании (или пользуетесь нормальным хостером), то коннектимся в iLO/IPMI/IP-KVM и просто с консоли разбираемся. А если так, поиграться — ну, опять же, можно посочувствовать и пожелать удачи в организации хороших условий работы.
Для этого есть один раз написанный сценарий ansible, чтобы привести хост к нужному состоянию. Да, если он смотрит в интернет — первое, что делаем — закрываем доступ отовсюду.
В systemd нет NTP сервера, только клиент, там не могло никакого amplification быть.
Не дождётесь. Советую ознакомиться со списком ограниченных пермишнов:
«Всё сказанное может быть использовано против вас»
Админы localhost'а, скорее всего, с таким и не сталкивались никогда, но в реальной жизни сплошь и рядом проблема — многократный запуск кроном одного и того же процесса. Потому что во времена, когда «UNIX way ещё не был потерян» такой сценарий просто не встречался.
systemd.timer нам даёт «из коробки» гарантию, что не более 1 копии сервиса будет запущено, ограничение по времени работы, jitter времени запуска (чтобы 1000+ серверов не ломились разом обновлять список пакетов) и плюс, все остальные плюшки, которые systemd даёт. Даже можно сделать так, чтобы до/после сервиса запускался другой автоматически по зависимостям (с другими пермишнами, например).
Никто там ничего не вешает.
Это отдельный процесс вообще-то.
Запустите
systemd-cgls— увидите много интересного.Он не для выдачи прав, а для ограничения возможностей. Например, указанная строка сделает так, что процесс и его дети не смогут делать, всё остальное (что через capabilities рулится), даже если от рута работают.
Для выдачи прав есть
AmbientCapabilities=, например:Это не в systemd дело, просто подсистема capabilities так работает.
ssh-add -c …1)
git pull --rebase2) проверить, что там подтянулось
3)
git pushЯ имел в виду, чтобы старую ветку не трогать (чтобы в ней хэши коммитов не менялись), а создать новую и очередной rebase уже там делать. Пример:
1) есть наш форк 2-недельной давности (
our-20200414) и новые изменения вmaster, поверх которых надо наши изменения положить2) делаем rebase
3) получили:
Один из примеров полезности rebase:
Есть очень-очень крупный проект (
master) и есть свой личный форк (fork) проекта с личными изменениями, которые, по каким-то причинам, не могут быть приняты (либо не хочется отправлять) в апстрим. Проект большой (десятки-сотни тысяч коммитов), личные изменения — максимум 10-20 коммитов.Пришло время подтянуть свежие обновления из крупного проекта. Есть два варианта:
1) можно замержить
master→fork2) можно сделать rebase
В случае «1» наши фиксы со временем перемешиваются с коммитами из апстрима и через пару лет уже будет трудно разобраться, что происходит.
В случае «2» у нас всегда в ветке
forkсверху те 10-20 коммитов с нашими фиксами и ситуация всегда ясна, конфликты проще разрешить при значительных изменениях в апстриме.Для облегчения ситуации можно при каждом обновлении из апстрима создавать новую ветку
fork-YYYYMMDD, чтобы после rebase хэши коммитов не менялись.