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@.
Пользователь добавлен в группу мантейнеров.

Желаю удачного мантейнерства!

Всем спасибо, в т.ч. за пожелания!