Вышла версия 1.5 system-autoupdate (https://gitlab.com/mikhailnov/system-autoupdate) — набора скриптов, сервисов и таймеров systemd для автоматизации обновления Linux с трехуровневой блокировкой выключения ПК во время обновления. Наработки проекта распространяются (https://gitlab.com/mikhailnov/system-autoupdate) под лицензией GPLv3. Для установки подготовлены (https://gitlab.com/mikhailnov/system-autoupdate/tags/v1.5) Makefile с инструкциями install и uninstall, а также deb-пакет, который при помощи штатных средств deb-хелперов автоматически активирует все необходимые юниты systemd при установке. Для Ubuntu поддерживается PPA-репозиторий (https://launchpad.net/~mikhailnov/+archive/ubuntu/utils/).
Решаемые проектом задачи:
- Автоматическое обновление серверных и десктопных установок различных дистрибутивов Linux без участия пользователя и без наличия центрального командно-управляющего сервера (например, Ansible, Puppet, Zabbix), в том числе когда Linux установлен на не личную технику, а, например, на ноутбук знакомого или удаленного сотрудника, но хочется, чтобы операционная система и набор прикладного ПО автоматически поддерживались в актуальном состоянии. Система также применима в малых офисах и небольшом парке серверов, когда нецелесообразно развёртывать централизированную систему управления и отдельный репозиторий;
- Предотвращение случайного выключения ПК, когда процесс обновления еще не завершен.
В настоящий момент поддерживаются следующие дистрибутивы:
- Ubuntu, Mint, Debian, Astra
- ROSA Fresh
- ALT Linux
- Arch, Manjaro, Antergos (только pacman, не AUR)
- CentOS, RHEL
- Fedora
- openSUSE, SUSE
Для надежной блокировки выключения компьютера во время обновления используется трехуровневая блокировка:
- Через systemd-inhibit блокируются выполняемые от пользователя (не root) операции systemctl reboot/shutdown/halt; эта же блокировка в большинстве систем приводит к запросу пароля root при выключении/перезагрузке, а отказ от ввода пароля останавливает графическую сессию и возвращает на экран менеджера входа;- Блокируется выполнение целей systemd shutdown.target, reboot.target, halt.target, hibernate.target, poweroff.target, sleep.target, suspend.target, suspend-then-hibernate.target, предотвращая разные типы выключения даже от root;
- Блокируются графические кнопки выключения, перезагрузки, ухода в сон, гибернации в графической оболочке, а при попытке ими воспользоваться выводятся графические уведомления, сообщающие пользователю, что систему невозможно выключить, что показано на скриншоте ниже.Блокировка графических кнопок выключения и вывод уведомлений реализованы с помощью правила policykit-1 (https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...), для работы которого требуется Polkit >= 0.106, однако в современных версиях Debian и Ubuntu, в том числе Debian Sid, до сих пор используется Polkit 0.105, когда как его свежие версии поддерживаются в Debian Experimental, поэтому пакеты policykit-1 из Debian Experimental были пересобраны для Ubuntu 18.04 и 18.10 и доступны в одном с system-autoupdate репозитории PPA (https://launchpad.net/~mikhailnov/+archive/ubuntu/utils/).
Показ графических уведомлений о начале и завершении процесса автообновления по умолчанию отключен, но доступен для включения в файле конфигурации. Также предусмотрена возможность использования только функциональности блокировки выключения системы без автообновлений.В версии system-autoupdate 1.5 (https://gitlab.com/mikhailnov/system-autoupdate/tags/v1.5) штатными средствами systemd предотвращен запуск system-autoupdate одновременно с выполняемыми по расписанию операциями макетных менеджеров apt и dnf (apt-daily.service, apt-daily-upgrade.service, dnf-makecache.service). В сборку Debian-пакета от автора system-autoupdate включен конфликт с пакетом unattended-upgrades по причине бессмысмленности работы unattended-upgrades, когда включен system-auotupdate, а также потому что их одновременная работа теоретически может привести к конфликтам и взаимным блокировкам пакетной системы.
Разработчик проекта рекомендует сочетать system-autoupdate с функциональностью apt-btrfs-snapshot, которая автоматически делает снапшот (снимок состояния) корня файловой системы ОС при любой операции с пакетами, то есть при каждом автообновлении, а стандартное меню восстановления Ubuntu (пакет friendly-recovery) позволяет откатиться на один из снапшотов в псевдографическом интерфейсе (что не отменяет возможности сделать это вручную из системы вживую или из chroot).
Автор system-autoupdate создал форк apt-btrfs-snapshot (https://gitlab.com/nixtux-packaging/apt-btrfs-snapshot), заменив еженедельное задание очистки старых снапшотов cron на ежедневный таймер systemd с защитой от запуска при питании от батареи и изменив максимальный возраст снапшотов с 90 до 15 дней, как временное решение от переполнения диска. Изменения предложены (https://bugs.launchpad.net/bugs/1778256) апстриму. Готовый к использованию пакет собран в PPA (https://launchpad.net/~mikhailnov/+archive/ubuntu/utils/). Также установлена зависимость от подготовленного командой SUSE пакета btrfsmaintenance со скриптами (https://github.com/kdave/btrfsmaintenance) для автоматического обслуживания разделов Btrfs. За основу пакета взят одноименный пакет из Debian, в которые перенесены имеющиеся исправления (https://gitlab.com/nixtux-packaging/btrfsmaintenance/tree/ma...).
URL: https://gitlab.com/mikhailnov/system-autoupdate
Новость: https://www.opennet.ru/opennews/art.shtml?num=48835
настройка обновлений системдос
30%
не выключайте компьютер
Ага, и еще "Нам не удалось установить обновления бла-бла-бла"
до этого не дойдет, насколько я вижу, в случае неудачи будет сделан откат.
Мелкософт говорит то же самое.
И времени откат занимает гораздо больше2 часа ставим апдейт, потом 2 часа откатываем, потом незагружаемся и делаем восстановление системы еще минут на 40
Откат BTRFS - 1 сек.
та самая бтрфс, которую самые успешные бизнесмены назвали deprecated? Наверное чтобы ос успешных бизнесменов быстрее откатывалась к состоянию до устновки обновлений методом успешных бизнесменов.
В SUSE - это файловая система по умолчанию. У меня на домашних компах тоже.
Поздравляю, у тебя дома система работает намного медленнее чем могла бы с Ext4. Так ли часто бывает необходима система снапшотов на уровне ФС, оно того стоит? От навернувшегося диска оно не поможет, а восстановить систему при поломке пакетов на крайняк и через chroot можно.
Ext4 очень передовая ФС со статическими iнодами, ага.
> Ext4 очень передовая ФС со статическими iнодами, ага.А вам удавалось их исчерпать ?
все нормально, если бы он ее ставил на Ext4 - под ним бы оказался lvm, сведя весь (малозаметный, надо сказать, при стандартных настройках имени rh) выигрыш производительности к нулю.
Заодно были бы и снапшоты, только неработающие, потому что им нужно место ;-)> восстановить систему при поломке пакетов на крайняк и через install можно, вы ж хотели "как в виндах".
поправил, не благодари.
Так тебе и надо.
>та самая бтрфс, которую самые успешные бизнесмены назвали deprecated?Это кто: Михельсон, Мордашов, Лисин и ниже?
>> самые успешные бизнесмены назвалиСамые успешные анонимусы ))
ну да ну да, если места хватит :)
> Откат BTRFS - 1 сек.Конечно-конечно. Но мало у кого стоит btrfs.
Вы ССЗБ если пытаетесь на систему установленную из оригинального образа 7ки установить 200 обновлений за 1 раз и 1 перезагрузку, давно доступны образы с интегрироваными апдейтами, любой может его собрать при помощи dism и других вантузоидных утилит. В 10ке же мелкософт исправился и выпускает сам свежие релизы венды каждые 6 месяцев.
> до этого не дойдет, насколько я вижу, в случае неудачи будет сделан
> откат.На что и каким образом будет сделан откат в общем случае, если обновление происходит когда в репозитории версии пакетов обновлены (т.е. старых уже нет)?
Какие профиты то, исключая невозможность прерывания, в сравнении с просто обновлением файловым менеджером?
можно автоматизировать обновы на предприятии и для этого не надо писать свой башскрипт для обновления зоопарка.. это просто удобнее.
Стесняюсь спросить: много ли предприятий вы лично уже так автоматизировали на «обновы»?И что такое, кстати, «обновы»? На каком это языке?
Твои аргументы: ненужно и сленг -- это плохо.
Отличные аргументы, что сказать.
чё ты э? по вашемуж вродь написано.. ну для этих которые сами подумать не умеют..
> Какие профиты то, исключая невозможность прерывания, в сравнении с просто обновлением файловым менеджером?
> в сравнении с просто обновлением файловым менеджером?
> файловым менеджером?Месье знает толк в обновлениях...
> Какие профиты то, исключая невозможность прерывания, в сравнении с просто обновлением файловым
> менеджером?Читаем "Linux установлен на не личную технику, а, например, на ноутбук знакомого".
— Оно не выключалось, а мне надо было срочно уходить, потому я вытащил аккумулятор из ноутбука...
— Ты сам виноват! Выключил, теперь придётся переустанваливать систему.
— Сколько?
...Профит!
Я прошу прощения, поскольку являюсь админом локалхоста, но что мешает в cron поставить, например apt update && apt upgrade?
Мешает чтение документации и последующая установка и настройка unattended-upgrade.
У unattended-upgrades и apt-btrfs-snapshot один и тот же изначальный автор из компании Canonical, и оба написаны в районе 2011 года. Это для размышления.
Ну сабжевое решение универсально и наверняка будет по дефолту присутсвовать, может даже включаться при установке путем установки галочки.
А апт только в дебианоклонах присутсвует
чем это лучше запихнутого в cron "sudo apt-get -f install; sudo apt-get update; sudo apt-get dist-upgrade -y"?
не понятно
зато - сиськемд, йоу!
вангую, скоро системд будет выбирать репозитории, а при установке будет два варианта: "1. классичексая установка Убунту 2. запустить systemd-installd (рекомендуеться)"
> вангую, скоро системд будет выбирать репозиториирандомом, ага.
Ну или "согласно нашей телеметрии, все вокруг вас используют убунту последней версии - нате!"> а при установке будет два варианта
юзер модного-современного-systemd-enabled линукса "уже почти окончательно совсем готового для десктопа" не должен беспокоиться о каких-то вариантах.
Будет единственная кнопка "ok!" - автоматически самонажимающаяся через минуту неактивности пользователя. Первое время над ней еще будет показываться выбранный дистрибутив, но потом его заменят веселеньким логотипчиком.
тем что в таком случае ты не контролируешь установку обновлений и потенциально будучи в соре с здравым смыслом - можешь выключить компьютер. А это штука попросит тебя подождать пока они установятся. Но я сам я являюсь противником данной штуки, также как и обновлений в кроне. На десктопе автоматически только проверяется наличие обновлений и все ставится контролируемо вручную. На серверах unattended updates только для критических обновлений безопасности.
компьютер может выключаться вполне осмысленно - например, кончается электричество.
А "эта штука", раз запустившись, будет работать, пока не кончится. После чего попробует еще и откатиться - на fs с последствиями неудачного выключения в момент наиболее активной пилежки диска.ну ничего, ничего, еще лет пять - встроят проверку состояния батареи через system-batteryd, потом вспомнят про существование usp'ов, а потом, наконец, дойдет и до десктопов не подключенных к гарантированному питанию, если они еще будут такие на свете, и может даже милостиво позволят пользователю все же выключить питание, когда ему понадобилось, а установить обновления как-нибудь в другой раз. "как в винде".
> ну ничего, ничего, еще лет пять - встроят проверку состояния батареи через
> system-batteryd, потом вспомнят про существование usp'ов, а потом, наконец, дойдет и
> до десктопов не подключенных к гарантированному питаниюГотово, ConditionACPower=true: https://gitlab.com/mikhailnov/system-autoupdate/commit/b77a7...
Спасибо за напоминание.
> тем что в таком случае ты не контролируешь установку обновлений и потенциально будучи в соре с здравым смыслом - можешь выключить компьютер.Ты тоже думаешь, что в таком случае произойдёт что-то более страшное, чем обновление только части из запланированных пакетов? Поэкспериментируй на виртуалке, что ли. Сломать систему корректной остановкой в момент обновления невозможно.
> Ты тоже думаешь, что в таком случае произойдёт что-то более страшное, чем
> обновление только части из запланированных пакетов? Поэкспериментируй на виртуалке, что
> ли. Сломать систему корректной остановкой в момент обновления невозможно.что происходит, если прибить dpkg (не apt/еще какую высокоуровневую хрень, а dpkg!) в момент апдейта _базы_ пакетов?
Я честно не знаю, у меня мало убунт/дебианов под рукой.redhat с битыми базами rpm боролась несколько лет (там, правда, по-моему, был berkley db >1.83, doomed to die сам по себе, и вылечилось как у всех - апгрейдом на еще более новые версии). Автоматика регулярного бэкапа этих баз во многих rh-based осталась и по сей день, как память о тех мрачных временах. (по понятным причинам, проблему решала только частично)
Что, по SIGTERM база бьётся? Не верю!
> Что, по SIGTERM база бьётся? Не верю!Проверь, забей в поиск "если упала база RPM"
В убунте обычно весь набор пакетов сначала качается, потом распаковывается, затем только настраивается... самому интересно, что будет, если прервать один из последних двух этапов.На генте во время ночного обновления тихо отключали электричество. В результате пропал XDG_RUNTIME_DIR (сама директория, не переменная). Остаётся гадать, что ещё могло сломаться (без этого каталога много чего не работает, включая кеды, пульаудио и некоторые права на работу с network manager). Боюсь придётся делать переустановку.
Попросит выполнить dpkg --configure -a
> В убунте обычно весь набор пакетов сначала качается, потом распаковывается, затем только
> настраивается... самому интересно, что будет, если прервать один из последних двух
> этапов.Не просто в убунте, а вообще в любой debian-based-системе. Это общая логика для APT.
Если завалится на этапе конфигурирования, то пакет будет помечен, как несконфигурированный и потребуется дерево конфигурации снова создать и свернуть.
В любом случае apt-get -f обычно решает эту проблему. А вот c rpm-based -- там будут проблемы, потому что если пакет завалил конфигурацию (читай, post-install), то он всё равно считается установленным, и будь что будет.
>> В убунте обычно весь набор пакетов сначала качается, потом распаковывается, затем только
>> настраивается... самому интересно, что будет, если прервать один из последних двух
>> этапов.
> Не просто в убунте, а вообще в любой debian-based-системе. Это общая логика
> для APT.
> Если завалится на этапе конфигурирования, то пакет будет помечен, как несконфигурированный
> и потребуется дерево конфигурации снова создать и свернуть.Правды ради замечу что пакеты по дефолту являются несконфигурированными, и потом после конфигурации уже помечяются установленными корректно.
> Правды ради замечу что пакеты по дефолту являются несконфигурированными, и потом после
> конфигурации уже помечяются установленными корректно.Да, это корректнее. Мой вариант допускал неправильную трактовку, будто он помечается несконфигурированным явно, а не остаётся помечен несконфигурированным. Спасибо за поправку.
> На генте во время ночного обновления тихо отключали электричество. В результате пропал
> XDG_RUNTIME_DIR (сама директория, не переменная). Остаётся гадать, что ещё могло сломаться
> (без этого каталога много чего не работает, включая кеды, пульаудио и
> некоторые права на работу с network manager). Боюсь придётся делать переустановку.Ещё один нечитатель. Я вообще-то про корректное отключение говорил. А от ситуации "электричество кончилось" и сабж ничем не поможет.
> чем это лучше запихнутого в cron "sudo apt-get -f install; sudo apt-get
> update; sudo apt-get dist-upgrade -y"?
> не понятнокак видишь оно ещё и снапшоты фигачит и защита от выключения есть.. в общем то это просто дописанный до ума скрипт автообновления который каждый админ хотя раз костылил в систему с заранее решёнными детскими проблемами таких скриптов.
> это просто дописанный до ума скрипт автообновленияНет, это написанный без ума скрипт, потому что делает кучу ненужного, включая эти самые блокировки.
> который каждый админ хотя раз костылил в систему
Нормальный админ не изобретает велосипеды, а использует штатные средства дистрибутива.
Админы точно не пишут скриптов для этого - уже давно есть поддержка unattended updates на серверных дистрибутивах, для десктопных автоматически только проверка обновлений. А это чудо инженерной мысли сугубо для безруких вантузятников, которые не будут обновлять свою систему самостоятельно и которые захотят перейти на линукс.
> как видишь оно ещё и снапшоты фигачит и защита от выключения есть..отличный снапшот у него выйдет на ext4? (или ссыстемда теперь будет требовать новую-модную fs в обязательном порядке?)
Защита от выключения точно возьмет мне электричество из воздуха?> в общем то это просто дописанный до ума скрипт автообновления который
> каждый админ хотя раз костылил в систему с заранее решёнными детскими
> проблемами таких скриптов.по-моему наоборот - это кривонаписанный костыль для/от альтернативно-одаренных юзеров "хотим как в винде", болеющий всеми-всеми детскими болезнями времен windowsME. Сколько там прошло, лет пятнадцать? Вот и этот к 2030му выздоровеет. (к 33му начнутся "запланированные перезагрузки" на основе автоугадава когда именно этот пользователь спит и прочий бред)
Только вот в windows обновление начинается после выключения системы, и со 100% вероятностью помешает пользователю, а здесь оно начнется после включения компьютера и к моменту его выключения с большой вероятностью не будет идти. Кто что не умеет: я объяснять или анонимусы с опеннета читать?
Вот именно, что на В-нде по-человечески сделано, а тут хомяк сперва офигеет от того, что комп внизaпна вдруг начал тормозить, попытается перезагрузить, обломается, запаникует и рубанет питалово.
А может самый нормальный вариант, это как ChromeOS? Атомарное обновление клона
> А может самый нормальный вариант, это как ChromeOS? Атомарное обновление клонас конфигами/версиезависимыми данными юзера что делать будем? В хрень-осе понятно что - ни конфиги, ни данные юзеру не принадлежат, они у гугля.
> Только вот в windows обновление начинается после выключения системы, и со 100% вероятностью
> помешает пользователюпочему помешает? Я люблю ткнуть в эту галку, уходя с работы домой - и пусть себе трудится (да, чтобы завершить утром, нужен WoL, но зачем жить бедно и хреново). Шансов что мне нужен был именно чистый Shutdown, а не hybernate, и я не заметил подвоха - далеко не 100.
Теперь вот искусственный интеллект - галки никакой нет, а есть предупреждение - "ты работай, работай, раб, мы тут тебе перезагрузочку запланировали, когда тебя точно нет, так ты ничего хировыгребанного, типа этого своего линукса в виртуалочке, не оставляй, наш-то софт умеет правильно автосохраняться, а твой не факт".И хрен его знает, одна и та же ли программа запустится, если два раза подряд ее запускать - может, пока ты кофе пил, она обновилась. Это хорошо еще, в винде системных приложений хрен да нихрена, и их никому не жалко.
> чем это лучше запихнутого в cron "sudo apt-get -f install; sudo apt-get
> update; sudo apt-get dist-upgrade -y"?Это в любом случае плохая практика, даже по cron-у.
>Блокируются графические кнопки выключения, перезагрузки, ухода в сон, гибернации в графической оболочке, а при попытке ими воспользоваться выводятся графические уведомления, сообщающие пользователю, что систему невозможно выключить, что показано на скриншоте ниже.Так быть не должно. В винде комп разрешит нажать на кнопки, примет их к сведению, сделает дело и выключится.
Да что уж там. обновляли бы снапшотами, как во всяких модных атомарных системах любят. И как в ведроиде недавно гугл сделали.
Тогда хоть перезагружай, хоть провод ножницами режь все равно обновится рано или поздно.
> Да что уж там. обновляли бы снапшотами, как во всяких модных атомарных
> системах любят. И как в ведроиде недавно гугл сделали.
> Тогда хоть перезагружай, хоть провод ножницами режь все равно обновится рано или
> поздно.Пулл-реквест с реализациям обновления в чруте снапшота принимается. При этом нужно не потерять все, что будет записано в подраздел до перезагрузки.
Разбивка системы на кучу подтомов, как в сусе, вынося /var отдельно и делая прочие упражнения, чтобы такое обновление работало, не очень нравится, а без этого не получится.
> Так быть не должно. В винде комп разрешит нажать на кнопки, примет
> их к сведению, сделает дело и выключится.sudo system-autoupdate-runner unblock_shutdown для ручной разблокировки.
Т.к. по умолчанию обновления раз в 6 часов, пользователь вообще не должен сталкиваться с блокировкой.
Зачем понадобились эти многочисленные костыли-блокировки, чтобы юзер обозлился и рубанул питание? Автор что, не в курсе, что пакетный менеджер, прерванный SIGTERM, всё равно оставляет систему в консистентном состоянии?
100% гарантиии оставления в консистентном состоянии нет. Что касается рубания с кнопки, то если юзер совсем идиот, то значит совсем идиот.
> 100% гарантиии оставления в консистентном состоянии нет.Значит у Вас неправильный дистрибутив с неправильным пакетным менеджером. Не знаю даже, где Вы такой нашли, потому что во всех мейнстримных эта проблема решена давным-давно.
> Что касается рубания с кнопки, то если юзер совсем идиот, то значит совсем идиот.Что должен подумать пользователь-неидиот, если вдруг у него безо всяких объяснений пропала/стала неактивной кнопка выключения, и что он должен предпринять, если ему таки нужно срочно выключить комп?
Графические уведомления появляются в момент показа заблокированной кнопки и объясняют ему, почему.
Дарю идею: можно ещё блокировать управлениями беспроводными и проводными сетями на время скачивания свежих апдейтов. Да много ещё чего можно блокировать!
Вообще весь ввод блокировать, чтобы пользователь ни окно выключения/перезагрузки открыть не смог, ни терминал для "killall -9 <автообновлятор>", ни ещё чего такого-эдакого учудить. Все процессы блокировать, чтобы они своими I/O и сетевой активностью не мешали процессу обновления.
Админа локалхоста с 15летним стажем достаточно не идиот для примера? Однажды я куда-то там сунул окно терминала и запамятовал про апдейт и вырубил комп. Но, правда, он вполне себе продолжился после запуска. Повезло, что ничего важного.
Виндовенько.. :)
что же неймется этим горе-разработчикам всё пытаются высосать из пальца какую-то надуманную задачу (для себя) и припаять в ядро/ОС очередной костыль, чтобы усложнить людям жизнь.
Неймётся настолько сильно, что вон уже во всему треду агитатор этого поделия бегает. Потому что он понимает в зарабатывании денег, а ты — нет.
Наверное решил сменить работу и нарабатывает портфолио.
> Наверное решил сменить работу и нарабатывает портфолио.На больничный он себе так наработает, если живым людям свою агитацию начнёт втирать.
Ну а на форуме можно, интернет всё степит.
> что же неймется этим горе-разработчикам всё пытаются высосать из пальца какую-то надуманную
> задачу (для себя) и припаять в ядро/ОС очередной костыль, чтобы усложнить
> людям жизнь.П.Д.Р.Сы, сэр.
системд портит мозг даже переводчику интерфейса?
не получится выключить комп? а если держать кнопку выключения? Лучше бы рэп переводил вместо интерфейса ПО.
Надо писать:
Пожалуйста не выключайте компьютер
> системд портит мозг даже переводчику интерфейса?Не было никакого переводчика. Это русский разработчик. Он же и новость тут запостил.
systemd-autoupdated
Че все (комментаторы) так системд любят? Два цента за комментарий от рептилоидов, не?
потому что прямой хейт сабжа трется, не?
Ждем выпуск system-autorepair-after-autoupdate
Цитата автора "Да, можно вести занятия через Skype и наслаждаться отвратительным качеством групповой связи и привязкой к кривому проприетарному программному обеспечению"и тем не менее сильно увлечён написанием системы под это самое кривое проприетарное ПО.
>с трехуровневой блокировкой выключения ПК во время обновленияКак это показательно :) На всяких винфаках недавно жаловались, что в Win10 такая же обнова прилетела, фиг выключишь комп нормально. Даже если надо куда-то сорваться и бежать по делам.
Костыли однако
Ну вот зачем это издевательство над пользователями?
> Автоматическое обновление серверных и десктопных установок различных дистрибутивов Linux без участия пользователяВсё, остановитесь. Если это исходный посыл, то извините, но это уже неправильно. У пользователя надо как минимум запрашивать подтверждение на начало проведения обновления.
> Блокируются графические кнопки выключения, перезагрузки, ухода в сон, гибернации в графической оболочке, а при попытке ими воспользоваться выводятся графические уведомления, сообщающие пользователю, что систему невозможно выключить
Вообще класс. То есть пользователь закрывает крышку ноутбука, и будучи искренне убеждён, что тот отправится в сон, кладёт его в портфель между пледом и бутербродом. Через 10 минут ноут превратится в печку и автоматически вырубится, не завершив обновление и повредив систему, бутерброд станет противно есть, а вытекшее с него на плед масло/сыр оставят пятна.
> Разработчик проекта рекомендует сочетать system-autoupdate с функциональностью apt-btrfs-snapshot
Разработчику проекта рекомендую подумать о проблемах, которые он создаст людям, которым это вкатит.
upd:
Плюс весьма любопытно, каковы были мотивы написания этого... продукта. Вон в той же нелюбимой мной Ubuntu есть весьма годные штуки под названием емнип update-manager/update-notifier. Они вообще говоря на ubuntu не завязаны и могут работать где угодно.
И логика её работы update-manager выглядит правильной, и не приводит ни к каким эксцессам. Почемы бы было просто не использовать её?
>У пользователя надо как минимум запрашивать подтверждение на начало проведения обновленияТот, кто умеет обновлять, может не использовать system-autoupdate.
Убунта ставится на декстоп или ноутбук домохозяйки, домохозяина или просто хорошего человека, который сам не умеет и не должен уметь что-то обновлять, например, он наш удаленный сотрудник и использует Линукс на ноутбуке для проведения вебинаров (реальный юз-кейс, не придумано). Его компьютером занимаюсь только я, но при этом он находится в другом городе за сотни километров от меня, линукс туда ставился удаленно, и я ни разу в глаза не видел этот комп. Есть несколько таких людей, пока еще не успел у них внедрить system-autoupdate, но это будет скоро сделано, и делалось именно в том числе для такого использования.> Вон в той же нелюбимой мной Ubuntu есть весьма годные штуки под названием емнип update-manager/update-notifier
Думаю, из сказанного выше понятно, почему они не то, что нужно.
На счет закрывания крышки интересная мысль, надо бы проверить, не будет ли происходить повторного срабатывания датчиков, когда блокировка уже будет снята. В принципе не так сложно сделать так, чтобы вместо просто отказа в выключении/засыпании система автоматически выполняла указанное действие по завершению обновления, но тогда не совсем понятно, зачем блокировать компьютер, как виндоффс, когда как в это время на нем можно продолжать работать.
Обратите внимание, что обновление начинается сразу после ВКЛючения системы, и к ее ВЫКЛючению с большой вероятностью уже не будет блокировки. А частые обновления делают процесс обновления быстрым.
> Разработчику проекта рекомендую подумать о проблемах, которые он создаст людям, которым это вкатит.
Например? Только давайте без пересказов форумных историй о падениях BTRFS времен ядер 2.х и 3.х, скоро 5.х будет.
Т.е. юзер запускает систему чтоб в ней поработать, а тут бац и прилетели обновы, которые сразу же похерили внешний вид уже запущенного софта. И такая лотерея каждый день. Хорошенькая перспективка.
Похоже набирает обороты новое понятие junk soft, следом за bloatware.
Речь не об Арче, GTK не обновляется до новых мажорных версий, тема не слетит.
В описании сказано о поддержке арча, теперь начинаются отмазки? Лёня покусал?
В документации (https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...) сказано: "..., если доверяешь стабильности используемого дистрибутива Linux".
Арч поддерживается, дальше сам думаешь, будешь использовать или нет. Надо - используй, не надо - не используй. Я стабильности Арча не доверяю, а тебя никто не заставляет этим пользоваться.
Лучше рекламы и не придумаешь
> Убунта ставится на декстоп или ноутбук домохозяйки, домохозяина или просто хорошего человека, который сам не умеет и не должен уметь что-то обновлять, например, он наш удаленный сотрудник и использует Линукс на ноутбуке для проведения вебинаров (реальный юз-кейс, не придумано). Его компьютером занимаюсь только я, но при этом он находится в другом городе за сотни километров от меня, линукс туда ставился удаленно, и я ни разу в глаза не видел этот комп.Этот вопрос прекрасно решает unattended-upgrades, который настраивается куда более гибко и не блокирует ничего лишнего.
> Этот вопрос прекрасно решает unattended-upgrades, который настраивается куда более гибко
> и не блокирует ничего лишнего.Кстати спасибо. Не знал об этом инструменте.
>[оверквотинг удален]
> Тот, кто умеет обновлять, может не использовать system-autoupdate.
> Убунта ставится на декстоп или ноутбук домохозяйки, домохозяина или просто хорошего человека,
> который сам не умеет и не должен уметь что-то обновлять, например,
> он наш удаленный сотрудник и использует Линукс на ноутбуке для проведения
> вебинаров (реальный юз-кейс, не придумано). Его компьютером занимаюсь только я, но
> при этом он находится в другом городе за сотни километров от
> меня, линукс туда ставился удаленно, и я ни разу в глаза
> не видел этот комп. Есть несколько таких людей, пока еще не
> успел у них внедрить system-autoupdate, но это будет скоро сделано, и
> делалось именно в том числе для такого использования.Ну я о чём-то таком разумеется догадывался, но боюсь, что данная ситуация описывается простым тезисом: "ваши процессы не отлажены". Если ноутбук находится в личном пользовании у сотрудника, то и ответственность за него должен нести сотрудник.
Если он не умеет и не должен уметь обновляться -- то тут два варианта. Вариант первый: может ему и не нафиг не сдались обновления? Вариант второй: может быть написать должностную инструкцию, обязывающую его соглашаться на обновление системы, предложенное через штатные механизмы дистрибутива, и дожидаться их корректного завершения?
Вы же предлагаете продукт, который может навернуться в ряде весьма нетривиальных граничных случаев, и при этом перекладывает ответственность с пользователя на администратора. Я вот не понимаю, зачем и кому это нужно. Человек должен иметь минимальные представления о том, как работать с системой на своей машине, равно как любой человек за рулём должен иметь водительские права. Потому что автопилот -- штука конечно клёвая, но опасная, в том числе и для пользователя/водителя.
В общем, тут зарылся интересный нюанс, заключающийся в том, что иногда правильное решение технической проблемы -- не техническое.
> Обратите внимание, что обновление начинается сразу после ВКЛючения системы, и к ее
> ВЫКЛючению с большой вероятностью уже не будет блокировки. А частые обновления
> делают процесс обновления быстрым.Само собой. Однако если мы в качестве аргумента берём именно этот вариант, тогда и запиханный в anacron apt-get dist-upgrade будет ничуть не хуже. Но Вы же хотели своим инструментом именно что предусмотреть граничные случаи, не так ли?
>> Разработчику проекта рекомендую подумать о проблемах, которые он создаст людям, которым это вкатит.
> Например? Только давайте без пересказов форумных историй о падениях BTRFS времен ядер
> 2.х и 3.х, скоро 5.х будет.Я ничего не имею против btrfs. Вы написали в новости, что *рекомендуете* совместное использование с btrfs. Стало быть, Вы допускаете вариант работы продукта и без него. Если btrfs нету, экспириенс в случае сбоя будет не слишком приятным.
> может быть написать должностную инструкцию, обязывающую его соглашаться на обновление системы, предложенное через штатные механизмы дистрибутива, и дожидаться их корректного завершения?Может, его еще научить из tty обновляться и прописать это в "должностную инструкцию"?
> Вы же предлагаете продукт, который может навернуться в ряде весьма нетривиальных граничных случаев, и при этом перекладывает ответственность с пользователя на администратора.
Все верно, администратор берет на себя ответственность, устанавливая system-autoupdate.
> Человек должен иметь минимальные представления о том, как работать с системой на своей машине
В моем случае не должен, потому что это невозможно. Если предложите методику обучения, буду рад.
> Однако если мы в качестве аргумента берём именно этот вариант, тогда и запиханный в anacron apt-get dist-upgrade будет ничуть не хуже. Но Вы же хотели своим инструментом именно что предусмотреть граничные случаи, не так ли?
Предусмотрен подграничный случай - выключение во время обновления.
> Я ничего не имею против btrfs. Вы написали в новости, что *рекомендуете* совместное использование с btrfs. Стало быть, Вы допускаете вариант работы продукта и без него. Если btrfs нету, экспириенс в случае сбоя будет не слишком приятным.
Экспериенс в случае любого сбоя будет не слишком приятным, я исхожу из того, что тот, кто это устаналивает, прочитал и понял, что оно делает. Дальше сам решает, нужно ему это или нет, я никого не заставляю и не предлагаю включать это по умолчанию в публично распространяемые дистрибутивы.
>> Человек должен иметь минимальные представления о том, как работать с системой на своей машине
> В моем случае не должен, потому что это невозможно. Если предложите методику
> обучения, буду рад.Ну, я всё-таки не эникей, чтобы обучать сотрудников. :)
Однако в данном случае этого и не нужно. Составляешь инструкцию (можно даже с картинками), согласуешь с руководством и, возможно, кадровиками -- а дальше не твоя забота.
> Ну, я всё-таки не эникей, чтобы обучать сотрудников. :)
> Однако в данном случае этого и не нужно. Составляешь инструкцию (можно даже
> с картинками), согласуешь с руководством и, возможно, кадровиками -- а дальше
> не твоя забота.Давай я сам решу, что моя забота...
> Вариант первый: может ему и не нафиг не сдались обновления?Все верно, ему вообще нафиг не сдалось любое обслуживание системы. Оно сдалось мне. То естьм не надо, чтобы его система была обновленной.
> Оно сдалось мне. То естьм не надо, чтобы его система была обновленной.Сомневаюсь, что Вам это нужно. Но с удовольствием бы выслушал Ваши доводы.
А почему Вы думаете, что я пофигист и должен пытаться сохранить низкую температуру своей задницы любой ценой? Мне интересно, чтобы, как минимум, у человека была свежая версия браузера без CVE, сайты не ругались на старую версию, обновленное ядро с закрытыми CVE, обновленные мои пакеты из моего репозитория.Ставить линукс и забивать на безопасность - это ускорение нашествия массовых попыток обманом или взломами внедрить вирусы на линукс. Если это произойдет, то мы (сообщество) проиграли, т.к. начавшийся тренд будет не остановить.
Если говорить о личных серверах, то там, где использовпние автообновлений уместно, system-autoupdate позволяет быстро закрыть уязвимость. Наример, пару дней назад вышло обновление панели VestaCP с закрытием очередной уязвимости, а у меня оно установилось раньше, чем я о нем узнал. [панель висит на нестандартном порту, и вход в нее дополнительно прикрыт http-авторизацией nginx].
Для сервера действительно нет большой разницы с кроном, но интересно иметь универсальное и одинаковое решение везде, а не на каждом сервере городить свои костыли и потом забывать, что, где и как работает.
> Ставить линукс и забивать на безопасность - это ускорение нашествия массовых попыток
> обманом или взломами внедрить вирусы на линукс. Если это произойдет, то
> мы (сообщество) проиграли, т.к. начавшийся тренд будет не остановить.Ах, вирусы… Так вы заботитесь об избавлении линукса от вирусов?
А ведь каков пафос!
Любо-зелено читать. )
в вашем манямирке апдейты==НЕТВИРУСОВ? разочарую,прилетит новый пакет, там сломали обратнуб совместимость и кто-то поедет в магадан быстренько исправлять это и откатывать апдейты (в лучшем случае через тимвьювер матерясь полезет). И такого уровня школотрон рекламируется в главных новостях. Алё, шигорин сотоварищи, сами же свою экосистему топите в смузи.
> в вашем манямирке апдейты==НЕТВИРУСОВ? разочарую,прилетит новый пакет, там сломали обратнуб
> совместимость и кто-то поедет в магадан быстренько исправлять это и откатывать
> апдейты (в лучшем случае через тимвьювер матерясь полезет). И такого уровня
> школотрон рекламируется в главных новостях. Алё, шигорин сотоварищи, сами же свою
> экосистему топите в смузи.Я вот не пойму, почему от автора ПО требуют вместе с ПО поставлять мозг пользователя?
Не удалось выключить комп. комп. Вы что серьезно? Комп.?
Оставьте ПК включенным?И эти люди еще смеют гнобить microsoft за их систему обновления?
А на фразе:
> командно-управляющего сервера (например, Ansible, Puppet, `Zabbix`)Ни у кого глаз не дёргнулся?
InfluxDB, Grafana, Graphite, statsd, fluentd, telegraf, etc...
> А на фразе:
>> командно-управляющего сервера (например, Ansible, Puppet, `Zabbix`)
> Ни у кого глаз не дёргнулся?Ахахаха, и то правда... Два чаю господину Орлиному Глазу! :)
А вообще, сдаётся мне, что глаз-то у народа начал дёргаться почти сразу после прочтения заголовка... )
>> А на фразе:
>>> командно-управляющего сервера (например, Ansible, Puppet, `Zabbix`)
>> Ни у кого глаз не дёргнулся?
> Ахахаха, и то правда... Два чаю господину Орлиному Глазу! :)
> А вообще, сдаётся мне, что глаз-то у народа начал дёргаться почти сразу
> после прочтения заголовка... )Что не так?
https://www.zabbix.com/documentation/3.4/manual/config/notif...
> Что не так?То, что заббикс не для этого предназначен. ;)
Осталось увидеть такое для Slackware и Gentoo, а то системад корявый, а потом в нем что-то поменяют, что поломается автообновлятор и вообще не смешно станет. Это конечно очень сложно, но руками ядро обновлять не весело, особенно с ручными настройками без генкернела - вот только в таком месте нужна подобная автоматизация. А то влепят неясную лажу при обновлении, а настроить нафигпосылатель уже не получится - нужны были бы настройщики обновления ядра, которые изврат оттяпают из нововведений, ну или предложат с человеческими пояснениями что это за новая приблуда в ядре и чем она отличается от старой и самое главное - нафига мне о ней надо знать.
Автопересборщик мира?
а тут все комменты о ненужности и опасности внедрения сабжа трут ? разаработчик кривого никого не нужного велосипеда знакомый модератора ?
> а тут все комменты о ненужности и опасности внедрения сабжа трут ?
> разаработчик кривого никого не нужного велосипеда знакомый модератора ?Сомневаюсь, что трут именно по этому признаку, с учётом того, что сами модераторы пишут об опасности и ненужности сабжа. )
> "Не получится выключить комп."Чего уж там, не комп, а "пекарня" бы написали. Или "комплюхтер".
Хехехе, народ. Если кто считает, что автор до сих пор был недостаточно унижен, то вот код, о котором идёт речь. :)Перед чтением этих скриптов запаситесь попкорном.
https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...
https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...Вот как обновляется система.
https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...Вау, автор предусмотрел возможность руками задать список демонов для перезагрузки! :)
https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...
Кстати посмотрел по коду.. скрипты обновления на дебиан системах 100% не отработают на всех пакетах в автомате.. но автору в принципе похоже только попариться нужно.. и таки почему такое как главная новость опеннета идёт ?
> скрипты обновления на дебиан системах 100% не отработаютМожно пример ситуации, когда не отработают?
Например интерактивные вопросы при установке автору велосипеда не знакомы.. уж про политику работы со старыми конфигами можно и не упоминать.. в общем желающие ломать себе систему кривымии и не протестированными скриптами налетай
По умолчанию (в Ubuntu, как минимум) на вопрос, что делать с измененным конфигом, дается ответ "оставить старый". Это настраивается, можно изучить debconf(5) и debconf(7). Это не входит в задачу скрипта обновления, а настраивается администратором и может быть настроено по-разному.Вот export DEBIAN_FRONTEND=noninteractive можно сделать, чтобы не сыпало в лог ошибками выбора фронтенда.
Не стоит считать себя самым умным, а всех остальных дураками.
> Не стоит считать себя самым умным, а всех остальных дураками.Вы будто первый раз на опеннет зашли.
Я уже смотрел эти скрипты и должен сказать, что для нашего времени автор исключительно хорошо владеет шеллом. Если он вдруг заинтересован в работе в Питере, нам с ним определённо есть о чём поговорить.
Ну а что скрипты делают кучу бессмысленных вещей — так чего ждать от инструмента, изначально предназначенного для решения несуществующей проблемы.
> Если он вдруг заинтересован в работе в Питере, нам с ним определённо есть о чём поговорить.
> Ну а что скрипты делают кучу бессмысленных вещей — так чего ждать от инструмента, изначально предназначенного для решения несуществующей проблемы.Ах, забирайте. Поделом вам.
с трехуровневой блокировкой выключения ПК во время обновления.
А защиту от пропадания электричества в сети они предусмотрели ? ну или хотя бы с apcupsd эта "программа" дружит ?
А вообще все как в винде становится - systemd с его зависимостями прям как виндовые службы - один в один.
Теперь еще тут - "не выключайте питание компьютера, пока обновление не будет установлено".
Красота :)Arch
Огонь, просто огонь :))
Разработчик проекта рекомендует сочетать system-autoupdate с функциональностью apt-btrfs-snapshot, которая автоматически делает снапшот (снимок состояния) корня файловой системы ОС при любой операции с пакетамиНу а чо - в линуксах по другому никак - запустил обновление и молись, чтобы ничего не сломалось, ну или не стало хуже чем было.
Проще будет делать акронисом или dd корень куда-нить копировать, ну и всякие ~/.config тоже.
> А защиту от пропадания электричества в сети они предусмотрели ? ну или
> хотя бы с apcupsd эта "программа" дружит ?Да: https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...
Если питание от батареи, обновление НЕ запускается.> Проще будет делать акронисом или dd корень куда-нить копировать, ну и всякие ~/.config тоже.
dd, безусловно, прям проще снапшота BTRFS. Главное, насколько быстрее-то бекап и откат.
>> А защиту от пропадания электричества в сети они предусмотрели ? ну или
>> хотя бы с apcupsd эта "программа" дружит ?
> Да: https://gitlab.com/mikhailnov/system-autoupdate/blob/master/...
> Если питание от батареи, обновление НЕ запускается.
>> Проще будет делать акронисом или dd корень куда-нить копировать, ну и всякие ~/.config тоже.
> dd, безусловно, прям проще снапшота BTRFS. Главное, насколько быстрее-то бекап и откат.А если нет btrfs и нет желания, а главное возможности его поставить ? Я к тому, что, к сожалению, без бекапов в линуксах перед обновлениями - никак, увы. Хотя могло бы быть КАК, только лишь нужно отказаться от структуры каталогов и концепции разделяемых библиотек 80ых, зависимости, чтобы их !
А вы представьте, что может быть линукс, в котором не только не ломается после апдейта ничего, но и работает любая софтина, когда-либо под него написанная ?!!
Так он вроде бы выше тут писал, что тот, кто ставит это на машину -- сам себе злобный буратино. :)"я исхожу из того, что тот, кто это устаналивает, прочитал и понял, что оно делает. Дальше сам решает, нужно ему это или нет, я никого не заставляю и не предлагаю включать это по умолчанию в публично распространяемые дистрибутивы"
Отказ от FSH не решит ни одну проблему и создаст много новых. Проблема обратной совместимости сильно преувеличена, и часто возникает потому, что в debian переименовали пакет, содержащий номер so name в названии, или удалили его, пример - libtiff3 с кучей CVE.Linux не ломается после апдейта в большинстве случаев; то, что предусмотрена страховка, не означает, что ей приходится пользоваться часто.
> А если нет btrfs и нет желания, а главное возможности его поставить
> ? Я к тому, что, к сожалению, без бекапов в линуксах
> перед обновлениями - никак, увы. Хотя могло бы быть КАК, только
> лишь нужно отказаться от структуры каталогов и концепции разделяемых библиотек 80ых,
> зависимости, чтобы их !
> А вы представьте, что может быть линукс, в котором не только не
> ломается после апдейта ничего, но и работает любая софтина, когда-либо под
> него написанная ?!!О, просите, я поначалу прочитал по диагонали, и понял неправильно. Тонко. Лайк! :)