Хочу отправить в сизиф и поддерживать уже готовый пакет: https://gitlab.com/mikhailnov/system-autoupdate/blob/master/system-autoupdate-ALT.spec Псевдоним: mikhailnov Желаемый псевдоним @altlinux.org: mikhailnov Адрес пересылки почты: mikhailnov@dumalogiya.ru
Created attachment 7722 [details] public SSH key
Created attachment 7723 [details] public GPG key mikhailnov@altlinux.org
C "control sudo public" вряд ли кто-то пропустит. Большие %post-ы проще упаковать скриптами и убрать "AutoReq: no". Тексты лучше не писать на экран, а упаковать в %doc.
Скрипты от других дистрибутивов лучше удалить. Если они кому-то понадобятся, в исходниках почитает.
> C "control sudo public" вряд ли кто-то пропустит. Ну если не пропустят, то значит пакета не будет. Я не буду заменять правила надежного и проверенного временем sudoers в несколько строк https://gitlab.com/mikhailnov/system-autoupdate/blob/master/etc/sudoers.d/system-autoupdate-polkit на огромные правила policykit на javascript, обрабатываемые через mozjs, только потому что в Альте такие права на /usr/bin/sudo. polkit'a вообще нет, например, на серверах, где я использую system-autoupdate. > убрать "AutoReq: no" Он поставлен специально. Например, чтобы не добавил в зависимости snapd, если он когда-нибудь будет опакечен. Это можно обойти, например, конструкцией типа SNAPD="$(which snap)"; "$snap", но это странное занятие, все зависимости, кроме системных типа /bin/sh, grep, gawk уже стоят. В целом я не знаю, нужен ли AutoReq. Раньше он был, потом убрал. > Тексты лучше не писать на экран, а упаковать в %doc. В Альте политика при установке пакета не активировать никакие сервисы, а здесь они активируются. В составе идут сервисы-заглушки https://access.redhat.com/solutions/1580343 , а активировать надо timer, а не service systemd, поэтому сам администратор системы, ставящий пакет, не справится. Поэтому выводим текст на экран, объясняющий, какие изменения внесены в систему. > Большие %post-ы проще упаковать скриптами Эти post-ы Альтоспецифичные, т.к. в иных дистрибутивах может быть иная политика автоактивирования сервисов и нет control. Директория /usr/lib/* не используется, а в имеющуюся /usr/share/system-autoupdate/ класть исполняемые скрипты не комильфо, сейчас в ней нет ничего исполняемого, все скрипты из нее сорсятся, а не выполняются. Можно вынести в отдельный скрипт и его сорсить из %post, но это лучше сделать в будущем, если буду опакечивать под другие RPM-дистрибутивы, т.к. тогда станет понятно, какие скрипты нужны для других дистрибутивов. > Скрипты от других дистрибутивов лучше удалить. Если они кому-то понадобятся, в исходниках почитает. Готово: https://gitlab.com/mikhailnov/system-autoupdate/commit/0f741e4d06ca84150035cd7372b2a3a5a1ec6af5
Но если кто придумает, как малой кровью переделать sudoers в polkit, то можно будет избавиться от control sudo public.
(In reply to comment #5) > потому что в Альте такие права на /usr/bin/sudo. polkit'a вообще нет, > например, на серверах, где я использую system-autoupdate. Пользователь с правами добавляется в группу wheel, и всё. Первый пользователь, добавляемый инсталлятором, в неё попадает автоматом кажется. Так что вполне пойдёт control sudo wheelonly, думаю.
(В ответ на комментарий №5) > Я не буду заменять Не заменяйте, но "control sudo public" делать не надо. > > убрать "AutoReq: no" > Он поставлен специально. Например, чтобы не добавил в зависимости snapd, если > он когда-нибудь будет опакечен. Это можно обойти, например, конструкцией типа > SNAPD="$(which snap)"; "$snap", но это странное занятие Нормальное. >, все зависимости, кроме > системных типа /bin/sh, grep, gawk уже стоят. Проект более не развивается? Лучше довериться автомату, подчищая лишнее. > В целом я не знаю, нужен ли AutoReq. Раньше он был, потом убрал. Нужен. > > Тексты лучше не писать на экран, а упаковать в %doc. > выводим текст на экран, объясняющий, какие изменения внесены > в систему. Тогда сделайте копию объяснений в документации, идущей с пакетом. > > Большие %post-ы проще упаковать скриптами > Эти post-ы Альтоспецифичные, > т.к. в иных дистрибутивах может быть иная политика Тут как раз Альт, а не "иной дистрибутив". > автоактивирования сервисов и нет control. Директория /usr/lib/* не > используется, а в имеющуюся /usr/share/system-autoupdate/ класть исполняемые > скрипты не комильфо Комильфо.
(В ответ на комментарий №7) > пойдёт control sudo wheelonly, думаю. Нет. Вообще дергать control не надо в %post . Как и сервисы так, как сделано. Вполне сгодиться %post %post_service name %preun %preun_service name и файл в /lib/systemd/system-preset/
(In reply to comment #9) > > пойдёт control sudo wheelonly, думаю. > Нет. Вообще дергать control не надо в %post . Я как-то коряво пояснил, да... Я имел ввиду, что пользователя в группу wheel добавлять, которому это разрешено. sudo wheelonly - это же по-умолчанию в ALT: https://packages.altlinux.org/en/Sisyphus/srpms/sudo/spec %post %post_control -s wheelonly sudo
(В ответ на комментарий №10) > добавлять, которому это разрешено. sudo wheelonly - это же по-умолчанию в ALT: Относительно. Лучше поискать способы не менять настройки системы. control все-таки больше для админа и за него менять настройки системы не очень корректно.
Представьте, что устанавливается дистрибутив или обновляется много пакетов, из которых 10 пакетов дергают `control sudo` в разные стороны.
> Пользователь с правами добавляется в группу wheel, и всё. Речь идет о запуске sudo от nologin-пользователя polkitd. Без дергания control он не может запустить /usr/bin/sudo. Я понимаю, что так делать не надо, но по-другому никак. > Не заменяйте, но "control sudo public" делать не надо Без этого после перезагрузки графически кнопки выключения/перезагрузки системы в XFCE/Mate/LXDE/... будут заблокированы навечно. > Тогда сделайте копию объяснений в документации, идущей с пакетом. А можно пример документации, как она оформляется? И есть ли кросс-дистрибутивные решения? > Проект более не развивается? Лучше довериться автомату, подчищая лишнее. Включил AutoReq. https://gitlab.com/mikhailnov/system-autoupdate/commit/c1b3f77c35681586316a5b826218028f71e7852c . Но это взрывоопасно. > Комильфо. Не очень :) > Тут как раз Альт, а не "иной дистрибутив". А чем мешают большие скрипты непосредственно в спеке, кроме невозможности их удобно проверить через shellcheck ? > %post_service name %postun_service надо или оно автоматом?
Предлагаете сделать %post_control -s public sudo ?
sudo от nologin-пользователя polkitd вызывается здесь: https://gitlab.com/mikhailnov/system-autoupdate/blob/master/usr/share/polkit-1/rules.d/90-system-autoupdate.rules
notify_all_shutdown_error - https://gitlab.com/mikhailnov/system-autoupdate/blob/master/usr/share/system-autoupdate/common-funcs.sh#L146 check_shutdown - https://gitlab.com/mikhailnov/system-autoupdate/blob/master/usr/share/system-autoupdate/common-funcs.sh#L187 check_shutdown нужно от root, чтобы снять блокировку выключения системы, если сервис обновления по какой-либо причине находится в состоянии failed
Наверняка кто-нибудь предложит написать демона, с которым нужно общаться без sudo, но это лишняя нагрузка на систему и все-таки потенциально бОльшая дыра в безопасности.
Еще положить все просто в %doc мало, никто же не будет читать, а хочется проинформировать пользователя, какие сервисы активированы и что происходит.
Anton Farygin <rider@altlinux.org> согласился стать ментором. Добавлен в CC.
(В ответ на комментарий №18) > Еще положить все просто в %doc мало, никто же не будет читать, а хочется > проинформировать пользователя, какие сервисы активированы и что происходит. Проинформируйте, что ему надо почитать /какие/сервисы/активированы.txt вместо вывода на экран портянки, которую еще надо не потерять, если ее вообще увидят.
(В ответ на комментарий №13) > > Пользователь с правами добавляется в группу wheel, и всё. > Речь идет о запуске sudo от nologin-пользователя polkitd. Без дергания control > он не может запустить /usr/bin/sudo. Я понимаю, что так делать не надо, но > по-другому никак. Т.к. все без этого живут, то способ точно есть. > > Тогда сделайте копию объяснений в документации, идущей с пакетом. > А можно пример документации, как она оформляется? И есть ли > кросс-дистрибутивные решения? Для начал хоть README.txt :-) > > Тут как раз Альт, а не "иной дистрибутив". > А чем мешают большие скрипты непосредственно в спеке, кроме невозможности их > удобно проверить через shellcheck ? Возможностью удобно прочитать всё по отдельности. > > %post_service name > %postun_service надо или оно автоматом? Раз такой отсутствует, то, как-минимум, в нем нет необходимости.
Хорошо, попробую сделать. > Т.к. все без этого живут, то способ точно есть. Никто просто не пробовал запускать sudo из правила polkit
Собственно, начиная с версии 0.106 у polkit новый формат правил, раньше он работал от root, а не polkitd.
(В ответ на комментарий №22) > > Т.к. все без этого живут, то способ точно есть. > Никто просто не пробовал запускать sudo из правила polkit Ответ вполне может быть тот же. Я не углублялся, поэтому по сути сказать не могу.
По результатам обсуждения с asy@ пришел к выводу, что нужно сделать так: * control sudo public убрать из %post * убрать автоматически включаемые сервисы systemd путем убирания макросов %systemd*/%service* * enabled и disabled в /lib/systemd/system-preset/*.preset оставить * внутри самого system-autoupdate сделать команду enable, которая будет: * * прописана в описании пакета * * информация о ней будет выводится кратко в %post при первой установке пакета * * делать systemctl enable system-autoupdate.timer system-autoupdate-sanity.service * * записывать состояние control sudo * * делать control sudo public * команда disable будет делать: * * systemctl disable system-autoupdate.timer system-autoupdate-sanity.service * * control sudo $прежнее_состояние Таким образом, администратору будет достаточно сделать `system-autoupdate-runner enavle` для включения автообновления и `system-autoupdate-runner disable для выключения`. В таком виде подойдет для сизифа? =============================== Также я хочу сделать более короткую команду, чем system-autoupdate-runner. Поэтому вопрос, как лучше сделать: * симлинк /usr/bin/saur --> /usr/sbin/system-autoupdate-runner * или alias saur="system-autoupdate-runner" в /etc/profile.d/* ?
(В ответ на комментарий №25) > * симлинк /usr/bin/saur --> /usr/sbin/system-autoupdate-runner Если без параметров, то смысла алиас делать никакого нет. К тому же он shell-озависим. Главное, чтоб имя было достаточно уникальное на всякий. P.S. sauron и sauroff ;-)
Готово: https://gitlab.com/mikhailnov/system-autoupdate/commit/689594be231b2405408c3ed1beacb44c5a49e727 Новый спек: https://gitlab.com/mikhailnov/system-autoupdate/blob/master/system-autoupdate-ALT.spec
поле Packager можно (и лучше) не заполнять - его заполнят автоматически. мне не нравится странная и не очень нужная логика определения локали в %post скрипте. Лучше вывести сообщение на английском. Тем более что оно просто попадёт в лог и его прочитают с вероятностью, стремящейся к нулю. в preun скрипте не обязательно обрабатывать остальные случаи, можно просто игнорировать. Посмотрите в других пакетах - там запись очень короткая и читаемая. И для чистоты спека лучше зачистить от ненужных комментариев: (я про комментарии макросов, например __requires_exclude_from ) Удаление файлов лучше из спека перенести в Makefile, добавив туда угадав дистрибутива с возможностью указания логики вручную. Пакет без email-а @altlinux.org в changelog не пройдёт нашу сборочницу. Для Секретаря: кандидат в ментейнеры готов к переходу на следующую стадию.
В %preun так специально: если и только если пакет удаляется полностью, а не обновляется, вызываем saur disable, который снимает блокировку выключения (а вдруг она не снята до ужаления?) и systemctl disable все сервисы, из-за чего нет смысла в %preun_service.
А если при обновлении изменится унит systemd, в текущем виде будет сделан systemctl daemon-reload?
Упс. cat /usr/sbinpreun_service: "$SYSTEMCTL" --no-reload -q disable "$1.service" А мне надо .timer, помимо .service Обойдемся без %preun_service и повесим багу: https://bugzilla.altlinux.org/show_bug.cgi?id=35388 Изначальный вариант с %systemd_preun таких проблем не имел, собственно, но он уже не имеет смысла. Небольшие правки в спек внес: https://gitlab.com/mikhailnov/system-autoupdate/compare/689594be...master
Пинг) Готов еще один пакет: https://gitlab.com/mikhailnov/pulsejoin
(In reply to comment #1) > Created an attachment (id=7722) [details] > public SSH key Согласно https://www.altlinux.org/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%BC%D0%B8_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0 рекомендуется использовать ключ большей длины (ED25519 либо RSA размером не менее 4K).
Created attachment 7758 [details] public SSH key 2
Новый ключ имеет длину 4096 и фразу-пароль.
Дима, кандидату сразу можно дать доступ в git и к сборочнице для тестовой сборки.
Еще собрал: btrfsmaintenance: https://gitlab.com/nixtux-packaging/btrfsmaintenance/blob/master/btrfsmaintenance-ALT.spec audacity (в процессе): https://gitlab.com/nixtux-packaging/audacity-altlinux libsbsms: https://gitlab.com/nixtux-packaging/libsbsms-rpm
2ldv: ментейнер готов к переходу на следующий шаг.
(In reply to comment #35) > Новый ключ имеет длину 4096 и фразу-пароль. $ ssh-keygen -l -f mikhailnov.ssh 4069 SHA256:iOnC8zdn1DMyUiinKzRRmFjqVXIGzMBffO0zBAndrYA user@alt-p8-edu (RSA) Изивините, но 4069 < 4096.
Адрес для пересылки создан, T/J/S -> 2.2.
Created attachment 7793 [details] public SSH key 3
ssh ключ на gitery.alt и gyle.alt зарегистрирован, T/J/S -> 3.0.
Не могу запустить сборку, т.к. публичный GPG-ключ не добавлен. $ gpg --list-keys /home/user/.gnupg/pubring.gpg ----------------------------- pub 4096R/55E84CE1 2016-11-01 uid Mikhail Novosyolov <mikhailnov@altlinux.org> uid Mikhail Novosyolov <mikhailnov@dumalogiya.ru> sub 4096R/0B6AFF61 2016-11-01 $ ssh girar build packages/system-autoupdate.git 1.13-alt1.1 new task #213793: owner=mikhailnov repo=sisyphus gpg: WARNING: unsafe ownership on homedir `/usr/lib/alt-gpgkeys' gpg: Signature made Sat Sep 29 14:23:08 2018 UTC gpg: using RSA key 0xC49BD06755E84CE1 gpg: Can't check signature: public key not found task add: 1.13-alt1.1: tag signature verification failure removing task #213793 ... done http://git.altlinux.org/people/mikhailnov/packages/?p=system-autoupdate.git;a=tag;h=refs/tags/1.13-alt1.1
кандидата можно перевести на следующую стадию.
Напоминаю про доступ к сборочнице.
Пакет alt-gpgkeys обновлён. T/J/S -> 4.0.
Кандидат освоил наши технологии сборки и готов к полноценному ментейнерству. Прошу завершить его приём в члены Team.
Адрес подписан на devel@. Пользователь добавлен в группу мантейнеров. Желаю удачного мантейнерства!
Всем спасибо, в т.ч. за пожелания!
