Created attachment 9166 [details] SSH-ключ Алексей Костарев E-mail: kaf@nevod.ru Ментор: Алексей Шабалин shaba@basealt.ru Направление разработок: Контейнерная виртуализация Начальные цели - приобрести опыт в сборке пакетов В частности как любитель базы ClickHouse было бы интересно собрать пакет для него До настоящего времени занимаюсь поддержкой docker-образа flexberry/clickhouse-official https://hub.docker.com/r/flexberry/clickhouse-official
Created attachment 9167 [details] GPG Key
Принял. Готовлю тестовое задание.
(Ответ для Alexey Shabalin на комментарий #2) > Принял. Готовлю тестовое задание. (Ответ для ALexey Kostarev на комментарий #0) > Создано вложение 9166 [details] [подробности] > SSH-ключ (Ответ для ALexey Kostarev на комментарий #1) > Создано вложение 9167 [details] [подробности] > GPG Key Ok.
Прошу создать учетную запись на git.altlinux.org и предоставить возможность тестовой сборки на сборочном сервере.
Предлагаю переделать gpg ключ. Если устраивает логин kaf, то в gpg ключе укажите email kaf@altlinux.org. В описании ключа упоминать сторонний email kaf@nevod.ru совсем лишнее. Оставьте только "Alexey Kostarev". Для ключа можно добавить дополнительные email. PS: ssh ключ можно не переделывать, там комментарий не существенный, при добавлении на сервер его все равно поправят, я так думаю.
Created attachment 9177 [details] Новый GPG-ключ для E-mall kaf@altlinux.org
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.4.
Created attachment 9191 [details] Новый ssh-ключ Коллеги к сожалению я запятовал свой пароль к ssh-ключу Есть ли возможность заменить открытый ключ на приложенный?
Created attachment 9198 [details] Подписанный новый ssh-ключ
(Ответ для ALexey Kostarev на комментарий #8) > Создано вложение 9191 [details] [подробности] > Новый ssh-ключ > > Коллеги к сожалению я запятовал свой пароль к ssh-ключу > Есть ли возможность заменить открытый ключ на приложенный? (Ответ для ALexey Kostarev на комментарий #9) > Создано вложение 9198 [details] [подробности] > Подписанный новый ssh-ключ Да, так можно предположить, что этот ssh-ключ и gpg-ключ чуть выше сделал один и тот же человек. :) Ключи на серверах обновил, проверяйте.
Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий.
(Ответ для ALexey Kostarev на комментарий #0) > как любитель базы ClickHouse было бы интересно собрать пакет для него Этот? :) http://packages.altlinux.org/clickhouse
Да спасибо - я его уже обнаружил и попытался собрать у себя Но сходу не получилось Версия там довольно старая - 20.3 Мне же сейчас нужна 20.12 или 21.2 - там есть поддержка Postgers Wire Protocol Я пока поступаю проще - собираю свежий docker-образ на основе стандартного, добавляя необходимые мне плюшечки - возможность описания при запуске списка импортируемых таблиц из БД postgres https://github.com/Flexberry/dockerfiles/tree/master/clickhouse/official При навешивании тега на hub.docker.com срабатывает пересборка образа https://hub.docker.com/r/flexberry/clickhouse-official
Да коллеги мой gpg-ключ еще не попал в gyle? Остались еще какие-либо проблемы? Хотелось бы получить подарок на 23 февраля. Ставлю в очередь task на gyle: $ ssh gyle task add repo haproxy 2.3.5-alt1 gpg: Signature made Fri Feb 19 13:28:46 2021 UTC gpg: using RSA key 0x0DD3B4F9127CA906 gpg: Can't check signature: public key not found task add: 2.3.5-alt1: tag signature verification failure
(In reply to Alexey Shabalin from comment #11) > Прошу добавить gpg ключ на сборочницу для сборки тестовых заданий. T/J/S -> 3.0.
Пакет alt-gpgkeys обновлён. T/J/S -> 3.4.
Кандидат уже успешно собрал пару простых заданий (обновление существующих пакетов с помощью srpm и gear). Я их пропустил в сизиф. Заключительное задание на сборку нового пакета. Приглашаю к review #269308. Из моих замечаний: - временные файлы patroni.spec~ в репо - patroni.init надо адаптировать на основе альтовых шаблонов - patroni.service в таком виде не нужен, он вызывает patroni.init В service файле лучше использовать что-то типа Type=simple User=postgres Group=postgres EnvironmentFile=/etc/sysconfig/patroni ExecStart=/usr/bin/patroni /etc/patroni/config.yml ExecReload=/bin/kill -s HUP $MAINPID KillMode=process - вместо %_sysconfdir/%{name}_env.conf надо использовать %_sysconfdir/sysconfig/%name - в config.yml log_filename: 'postgresql-2.0.1-ALT.log' Точно логи должны привязываться к версии? тоже самое про scope: "2.0.1-ALT" - отсутствуют настройки для log rotation К python3-module-pysyncobj и python3-module-ydiff у меня претензий нет.
(Ответ для Alexey Shabalin на комментарий #17) > - вместо %_sysconfdir/%{name}_env.conf надо использовать > %_sysconfdir/sysconfig/%name А почему не %_sysconfigdir/%name ?
(Ответ для Alexey Shabalin на комментарий #17) > - patroni.init надо адаптировать на основе альтовых шаблонов По этой части могу попробовать содействовать в качестве со-ментора.
(Ответ для Andrew Vasilyev на комментарий #18) > (Ответ для Alexey Shabalin на комментарий #17) > > - вместо %_sysconfdir/%{name}_env.conf надо использовать > > %_sysconfdir/sysconfig/%name > > А почему не %_sysconfigdir/%name ? Исходя из того, что $_sysconfdir = /etc Алексей Шабалин прав %_sysconfdir/sysconfig/%name
(Ответ для Alexey Shabalin на комментарий #17) > - patroni.init надо адаптировать на основе альтовых шаблонов Добрый день, коллеги У меня вопрос по зависимостям Во время запуска patroni должен существовать пользователь postgres и одна из доступных версий postgres-серверов postgresql9.5-server postgresql9.6-server postgresql10-server ... postgresql13-server Мне в зависимостях для patroni писать общее имя из Provides этих пакетов? Там два кандидата /usr/bin/postgres postgresql-server Какой предпочnительный? И да - в этом случае я могу рассчитывает на наличие пользователя postgres при запуске init-скриптов Кстати сейчас встал в тупик - а где в пакетах описываются и создаются пользователи в случае нербходимости?
> - вместо %_sysconfdir/%{name}_env.conf надо использовать > %_sysconfdir/sysconfig/%name Да и коллеги у меня вопрос по экспорту переменных В качестве ствртового скрипта у меня используется python3 модуль /usr/bin/patroni Ему надо передать переменные среды их файла %_sysconfdir/sysconfig/patroni Я его читаю в /etc/init.d/patroni через ENVFILE=/etc/sysconfig/patroni SourceIfNotEmpty $ENVFILE но далее привызове start-stop-daemon --start ... --name patroni --user postgres --startas /bin/su - ... Я эту среду теряю Что делать писать дополнительный shell_скрипт для импорта среды из /etc/sysconfig/patroni ? Зачем тогда функция SourceIfNotEmpty ?
(Ответ для Alexey Shabalin на комментарий #17) > Заключительное задание на сборку нового пакета. > Приглашаю к review #269308. > > Из моих замечаний: > - временные файлы patroni.spec~ в репо Удалил > - patroni.init надо адаптировать на основе альтовых шаблонов - Перевел на: start_daemon stop_daemon status - добавил поддержку softdog/watchdog > - patroni.service в таком виде не нужен, он вызывает patroni.init > В service файле лучше использовать что-то типа > Type=simple > User=postgres > Group=postgres > EnvironmentFile=/etc/sysconfig/patroni > ExecStart=/usr/bin/patroni /etc/patroni/config.yml > ExecReload=/bin/kill -s HUP $MAINPID > KillMode=process - Поменял - Добавил поддержку softdog/watchdog > - вместо %_sysconfdir/%{name}_env.conf надо использовать > %_sysconfdir/sysconfig/%name Изменил Так как environments через su - не передаются добавил дополнительный shell-скрипт /usr/bin/patroni.sh для инициализации переменных под пользователем postgres перед вызовом python-скрипта /usr/bin/patroni > - в config.yml > log_filename: 'postgresql-2.0.1-ALT.log' упростил до postgresql.log > Точно логи должны привязываться к версии? Это наследство от пакеа в ubuntu, еде в рамках одного сервера могут запускаться несколько версий postgres > тоже самое про scope: "2.0.1-ALT" Упростил до ALT > - отсутствуют настройки для log rotation Мне кажется не стоит использовать стандартный logrotation так как после ротации приходится перегруэать patroni и postgres что может привести к смене лидера HA-кластера Так что воспоьзовался встроенной ротацией patroni и postgres Правда в этом случае архивные логи не сжимаются что приводит к небольшому overhead по дисковому пространству patroni: В /etc/sysconfig/patroni добавлены настройки ротации логов: ## LogRotate tuning export PATRONI_LOG_DIR=/var/log/patroni export PATRONI_LOG_FILE_NUM=7 export PATRONI_LOG_FILE_SIZE=1200000 Логи, к сожалению, в patroni ротируются не по времени - только по объему Предельный размер 1.2Mb при стандартном режиме работы (логи статуса patromi -master/slave) лог достигает примерно за сутки Так что при обычном режиме работы логи будут храниться в недельном промежутке postgres: В /etc/patroni/config.yml добавлена неделная ротация ежедневных логов: logging_collector: 'on' log_directory: '/var/log/patroni' log_filename: 'postgresql_%a.log' log_truncate_on_rotation: 'on' log_rotation_age: 1440
(Ответ для Andrew Vasilyev на комментарий #18) > > %_sysconfdir/sysconfig/%name > А почему не %_sysconfigdir/%name ? Похоже, это достаточно свежий макрос -- я бы пока не закладывался. (Ответ для ALexey Kostarev на комментарий #21) > Мне в зависимостях для patroni писать общее имя из Provides этих пакетов? > Там два кандидата > /usr/bin/postgres > postgresql-server > Какой предпочnительный? Я бы определённо ставил зависимость на postgresql-server (полагаю, она и сама ясней, и более чётко коррелирует с именами именно серверных пакетов). > И да - в этом случае я могу рассчитывает на наличие пользователя postgres > при запуске init-скриптов Да; конкретно postgres:46 у нас вообще в пакете setup определён. > Кстати сейчас встал в тупик - а где в пакетах описываются и создаются > пользователи в случае нербходимости? См. http://altlinux.org/Pseudo_User_Policy (важно не _удалять_ пользователей). (Ответ для ALexey Kostarev на комментарий #22) > Я его читаю в /etc/init.d/patroni через > ENVFILE=/etc/sysconfig/patroni > SourceIfNotEmpty $ENVFILE Если $ENVFILE больше нигде не используется -- я бы упростил до SourceIfNotEmpty /etc/sysconfig/patroni > Зачем тогда функция > SourceIfNotEmpty > ? Чтобы проверить наличие и непустоту файлика, который предлагается зачитать: --- SourceIfNotEmpty() { local f f="$1" shift [ -s "$f" ] && . "$f" "$@" } --- /etc/init.d/functions (Ответ для ALexey Kostarev на комментарий #23) > Так как environments через su - не передаются добавил дополнительный > shell-скрипт > /usr/bin/patroni.sh > для инициализации переменных под пользователем postgres > перед вызовом python-скрипта /usr/bin/patroni "Передай patroni" ;-)
(Ответ для Michael Shigorin на комментарий #24) > (Ответ для Andrew Vasilyev на комментарий #18) > > > %_sysconfdir/sysconfig/%name > > А почему не %_sysconfigdir/%name ? > Похоже, это достаточно свежий макрос -- я бы пока не закладывался. Да - не сначала не заметил разницы в написании В настоящий момент %_sysconfigdir нет в https://www.altlinux.org/Spec/%D0%9F%D1%80%D0%B5%D0%B4%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D0%B0%D0%BA%D1%80%D0%BE%D1%81%D1%8B > > (Ответ для ALexey Kostarev на комментарий #21) > > Мне в зависимостях для patroni писать общее имя из Provides этих пакетов? > > Там два кандидата > > /usr/bin/postgres > > postgresql-server > > Какой предпочnительный? > > Я бы определённо ставил зависимость на postgresql-server (полагаю, она и > сама ясней, и более чётко коррелирует с именами именно серверных пакетов). > OK Добавил в http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=blob;f=.gear/patroni.spec;h=2bfecaaba9e61e7b6371efa7585ff87bd499f69a;hb=HEAD > > И да - в этом случае я могу рассчитывает на наличие пользователя postgres > > при запуске init-скриптов > > Да; конкретно postgres:46 у нас вообще в пакете setup определён. > > > Кстати сейчас встал в тупик - а где в пакетах описываются и создаются > > пользователи в случае нербходимости? > См. http://altlinux.org/Pseudo_User_Policy (важно не _удалять_ > пользователей). В моей ситуации так как patroni зависит от postgres-server пользователь postgres уже будет создан при установке postgres-server > > (Ответ для ALexey Kostarev на комментарий #22) > > Я его читаю в /etc/init.d/patroni через > > ENVFILE=/etc/sysconfig/patroni > > SourceIfNotEmpty $ENVFILE > Если $ENVFILE больше нигде не используется -- я бы упростил до > SourceIfNotEmpty /etc/sysconfig/patroni > > > Зачем тогда функция > > SourceIfNotEmpty > > ? > Чтобы проверить наличие и непустоту файлика, который предлагается зачитать: > > --- > SourceIfNotEmpty() > { > local f > f="$1" > shift > [ -s "$f" ] && . "$f" "$@" > } > --- /etc/init.d/functions Да этоя просиотрел, правда не знал что в операиях . <shell-scriop> можно передавать параметры ($@) > > (Ответ для ALexey Kostarev на комментарий #23) > > Так как environments через su - не передаются добавил дополнительный > > shell-скрипт > > /usr/bin/patroni.sh > > для инициализации переменных под пользователем postgres > > перед вызовом python-скрипта /usr/bin/patroni > "Передай patroni" ;-) Так и сделал Испрововал несколько вариаентов - использвоания python-модуля импортирующего shell ENV-файл в sys.environment python-скрипта - надо создавать этот модуль в Sisiyphus - смена типа скрипта /usr/bin/patrony с python3 на ырудд #!/bin/sh . /etc/sysconfog/patroni exec /usr/bin/python3 <<EOF ... EOF - patroni некорректно формируем имя стартового скрипта (добавляет <stdin> в имя) и сваливается - добавление shell-скрипта /usr/bin/patroni.sh в котором после инициализации вызывается python скрипт /usr/bin/patroni В итоге остановился на последнем варианте...
Коллеги - жду вердикта...
Прошу перевести на следующий уровень. Только я уже не пойму, какой это, 4.1? Мое решение - кандидат готов для вступления в team. Жду подтверждения от второго ментора.
Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
Предложения и рекомендации: 1) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758 Советую использовать конструкцию "%define _unpackaged_files_terminate_build 1". Будет полезно если после обновления будут устанавливаться новые файлы. В таком случае это станет ошибкой, а не предупреждением. Также, по совету ldv@, стоит по возможности использовать "%define _stripped_files_terminate_build 1" и "%set_verify_elf_method strict". 2) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758 Packager: Alexey Kostarev <kaf@altlinux.org> Я считаю, что явно это указывать не нужно, поскольку при сборке пакета это поле заполняется автоматически. 3) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139 License: Apache License 2.0 По возможности лучше указывать лицензию так, как они называются в /usr/share/license. Об этом даже есть предупреждение при сборке пакета. Для этой цели может быть полезна утилита nomossa из пакета fossology-nomos, которая должна быть доступна в Сизифе и p10. 4) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368 %python3_sitelibdir/%name/ %python3_sitelibdir/*egg-info Возможно лучше будет вынести эти файлы в отдельный пакет python3-module-%name: если у какого-то другого питоновского пакета появится зависимость на этот модуль питона, то он вытянет весь этот пакет. Или в таком случае нужно будет в том числе и всё что за пределами %python3_sitelibdir в данном пакете есть? 5) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368 Странная комбинация .gear/rules и .gear/tags. В .gear/rules: tar: . spec: .gear/patroni.spec copy: .gear/*.yml copy: .gear/*.init copy: .gear/*.service copy: .gear/*.sh copy: .gear/*.py copy: .gear/*.conf Почти все файлы в директории .gear копируются дважды - в общий архив tar, и ещё раз отдельно. А в одном из следующих коммитов http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=aa332fd9afda892e5f1c8315e27af44993c6de11 добавляется тэг 2.0.1-alt1, который при этом, что не удивительно, не соответствует тэгу, находящемуся в репозитории. И конечно же, он никак не используется при сборке, т.е. не нужен. Я считаю, что это стоит переделать: брать исходники из апстримного тэга вместо просто "tar: .", тогда не будет дублирования файлов, и заодно этот апстримный тэг сохранить в .gear/tags, и убрать оттуда находящийся там сейчас ненужный тэг. Вопросы: 1) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139 BuildArch: x86_64 В связи с чем указаны такие строгие ограничения по архитектуре? Насколько мне известно, для пакетов на golang обычно используется следующая конструкция: ExclusiveArch: %go_arches BuildRequires(pre): rpm-build-golang 2) http://git.altlinux.org/people/kaf/packages/?p=butane.git;a=summary Здесь сначала идёт коммит, в котором добавляется почти весь spec-файл, затем merge с апстримным репозиторием, и затем добавляется запись в changelog. Почему сделано так? Почему нельзя было сделать просто 1 коммит поверх соответствующего тэга из апстрима? В пакетах patroni, python3-module-pysyncobj и python3-module-ydiff обнаружил тоже самое. 3) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758 Чем не подходят макросы %rust_build / %rust_install / %rust_test из пакета rpm-macros-rust ? 4) http://git.altlinux.org/people/kaf/packages/?p=bootupd.git;a=commitdiff;h=d0453c70238fc8395cf5fc140e2ee4cd52503758 ExclusiveArch: x86_64 aarch64 А здесь почему выбрано такое ограничение на архитектуры? И в других пакетах на rust тоже такой вопрос. Насколько я знаю, rust доступен на большем количестве архитектур чем указано здесь. Для всех ли пакетов нужно такое строгое ограничение архитектур? 5) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368 Скрипты patroni.py, patroni_aws.py, patroni_wale_restore.py, patronictl.py Нельзя ли их при сборке генерировать? Выглядят они однообразно и сгенерированными. Если это генерируемые файлы, то лучше их генерировать при сборке пакета, если такая возможность есть. Замечания: 1) git.altlinux.org/people/kaf/packages/?p=butane.git;a=commitdiff;h=1436e45c9ac35b6b163b937a90cdbca00bf57139 %pre / %post / %preun Не стоит захламлять спек-файл пустыми секциями %pre / %post / %preun. Лучше их удалить. Если же они не должны быть пустыми, это надо поправить. 2) http://git.altlinux.org/people/kaf/packages/?p=coreos-installer.git;a=commitdiff;h=c5414e155e84508f88b1f7c08203d9cd3353fd17 Согласно https://www.altlinux.org/Spec#%description длина строк в поле %description не должна превышать 72 символа. 3) http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=commitdiff;h=b52bb4b4ae90a4433d00887d3e75ff870bfbe368 Пустая секция %pre. 4) http://git.altlinux.org/people/kaf/packages/?p=python3-module-prettytable.git;a=summary Пакет явно не закончен, смотреть не на что. 5) В следующих пакетах неправильно указана лицензия в spec-файле: http://git.altlinux.org/people/kaf/packages/?p=patroni.git;a=summary - в спеке указано GPLv2+, в репозитории - MIT http://git.altlinux.org/people/kaf/packages/?p=python3-module-ydiff.git;a=summary - в спеке указано MIT, в репозитории - BSD-3-Clause 6) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e В директории .gear находится много файлов, которые при сборке и упаковке, похоже, не используются. Если они не нужны, то стоит их удалить. 7) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e %define zincati_user zincati %define zincati_group zincati ... %pre if getent passwd zincati then userdel zincati fi if getent group zincati then groupdel zincati fi %_sbindir/useradd -c 'Zincati user for auto-updates' %name Согласно https://www.altlinux.org/Pseudo_User_Policy, имена псевдопользователей и групп следует начинать с символа "_". Также там указаны рекомендуемые конструкции для создания таких пользователей и групп. Хотя в пакете patroni пользователь и группа указаны без данного символа, там, насколько я понимаю, они должны быть указаны как в другом пакете, а для новых пользователей и групп лучше ей следовать. 8) http://git.altlinux.org/people/kaf/packages/?p=zincati.git;a=commitdiff;h=e755cc4a5a531e9363e1afbd39d339d9f0e4519e %define zincati_confdir3 /run/%name/config.d/ %define zincati_metrics_public_dir /run/zincati/public %define zincati_metrics_private_dir /run/zincati/private %define zincati_run_rpm_ostree /run/rpm-ostree/ %define zincati_run_ostree /run/ostree/ ... %files ... %zincati_confdir3 %attr(-,zincati,zincati) %zincati_metrics_public_dir %attr(-,zincati,zincati) %zincati_metrics_private_dir %attr(-,zincati,zincati) %zincati_run_rpm_ostree %attr(-,zincati,zincati) %zincati_run_ostree Обычно /run является примонтированным tmpfs, всё её содержимое после перезагрузки пропадает. А это значит, что ничего туда упаковывать в пакеты нельзя, а если там всё-таки что-то нужно, и приложение там это само не создаёт, для создания стоит использовать tmpfiles.d: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html Эту часть, похоже, поправили пока я смотрел. Но этот пункт всё равно оставлю. Есть замечания, над которыми, я считаю, стоит поработать. Плюс пакеты zincati и patroni выглядят так, словно вступающий недостаточно освоился с .gear/rules и .gear/tags, поскольку везде используется конструкция "tar: ." даже если рядом ещё какие-то файлы копируются отдельно ещё раз, а в .gear/tags зачем-то добавляется неиспользуемый тэг, с именем, которое конфликтует с находящимся в репозитории тэгом.
kaf@ исправлены ли недостатки?
2 года нет движения. Неужели RESOLVED/TIMEOUT?
Актуально ли ещё?
Переоткройте, если будет актуально.
Доброго времени суток коллеги Прошу прощения за остановку работ по моему JOIN В начале года я потерял доступ к почте kaf@nevod.ru по которой был зарегистрирован Кроме этого в начале года плотно занялся созданием набора пакетов podsec (podman security) для поддержки защиты policy в решениях podman, kubernetes и мониторинга нарушений защиты: https://git.altlinux.org/people/kaf/packages/?p=podsec.git на основе собственного git-проекта https://github.com/kafnevod/podsec https://github.com/alt-cloud/podsec Кроме этого реализовал в рамках этого пакета rootless kubernetes https://www.altlinux.org/Rootless_kubernetes Эти пакеты включены в дистрибутив c10f1 и планируется включение последней версии пакета 1.0.10 очередной релиз c10f2. Предыдущая версия 1.0.8 в октябре 2023 включена в релиз p10 https://packages.altlinux.org/ru/search/?branch=sisyphus&q=podsec В связи с тем, что данная заявка закрыта я потерял доступ к https://git.altlinux.org/people/kaf/packages/?p=podsec.git и возможность вести пакет podsec Актуальность предыдущих вопросов по пакетам zincatti, bootupd пропала, так как эти пакеты портировал Андрей Соколов - https://packages.altlinux.org/ru/sisyphus/srpms/zincati/ В связи с эти прошу: 1. Открыть мою заявки в связи с необходимостью ведения группы пакетов podsec https://packages.altlinux.org/ru/sisyphus/srpms/podsec/ 2. Рассмотреть в рамках данной заявки реализованные группы пакетов podsec 3. В случае необходимости назначить мне для получения прав майнтейнера дополнительных пакетов для портирования
В данный момент все доступы отозваны, есть только email alias. Постараюсь в ближайшие дни восстановить доступ к git.alt и gyle.alt.
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. Откатываю на стадию 3.6, мячик теперь на стороне ментора. :)
ping?
PONG Добрый день Я жду ответа на вопросы которые озвучил выше: 2. Рассмотреть в рамках данной заявки реализованные группы пакетов podsec 3. В случае необходимости назначить мне для получения прав майнтейнера дополнительных пакетов для портирования Дополню, что в этом месяце - взял на сопровождение пакет podman-compose - https://git.altlinux.org/people/kaf/packages/?p=podman-compose.git;a=summary - Оформил в рамках этого пакета pull request - https://github.com/containers/podman-compose/pull/820 и Issue - https://github.com/containers/podman-compose/issues/822 - так как приема pull request можно ждать довольно долго и не дождаться прорабатываю вариант добавления в наш пакет podman-compose скрипта конвертации podman-compose стека в kubernetes-маниесты: * https://www.altlinux.org/Podman-compose/kubernetes * https://github.com/alt-cloud/podman-compose/blob/pod-to-kubemanifests/bin/pod-to-kubemanifests * https://github.com/alt-cloud/podman-compose/blob/pod-to-kubemanifests/md/pod-to-kubemanifests.md Планирую на этой и ближаыйшей неделе закончить написание, отладку и документирование скрипта
(Ответ для Gleb F-Malinovskiy на комментарий #37) > ping? Да URL покета podsec - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary
Претендент готов посылать пакеты в сизиф. Прошу призвать рецензента. Для проверки кандидат подготовил сборочное задание #355139