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
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
podsec: 1) changelog пакета немного не соответствует рекомендациям по написанию changelog'ов, принятых в ALT Linux Team (точка в конце предложения) 2) Не понял смысл этого задания: https://packages.altlinux.org/ru/tasks/350829/ 3) changelog в https://packages.altlinux.org/ru/tasks/357651/ вообще жестокий, непонятно куда смотрел ментор. Ну и надо бы ошибки на podsec разгрести. Я хотел бы посмотреть на работу над патчами. Аппрув должен буду делать в этот раз я.
Что ещё посмотреть я не понял, но podsec меня ввёл в печаль.
(Ответ для Anton Farygin на комментарий #43) > Что ещё посмотреть я не понял, но podsec меня ввёл в печаль. Доброго времени суток Вообще-то podsec не самая моя лучшая работа в плане соответствия стандартам портировния пакетов, но лучшая, по моему мнению, в плане функционала. На момент версии 1.0 в июне прошлого года это была первая в мире реализация поддержки rootless kubernetes с развертыванием через kubeadm. На тот момент надо было обеспечивать необходимый функционал для соответствия требований по сертификации rootless kubernetes для платформы c10f1. Обеспечивать соответствию требованиям портирования пакетов не была первоочередной задачей. Если есть конкретные замечания (кроме необходимости удалений точек в конце предложений), готов их устранять. По поводу "что еще посмотреть" - в заявке был указан таск #355139 https://packages.altlinux.org/en/tasks/355139/ podsec (таск https://packages.altlinux.org/ru/tasks/357651/) в заявку не входил. Поэтому я не совсем понимаю, почему рецензент все внимание уделил НЕ ВХОДЯЩЕМУ В ЗАЯВКУ пакету podsec и ни слове не сказал о ВХОДЯЩЕМУ В ЗАЯВКУ набором из 8-ми пакетов для поддержки flux2? При их реализации летом этого года я не был скован временными требованиями и пытался придерживаться стандартов портирования пакетов (хотя за точки в конце не поручусь). Прошу предоставить замечания именно по заявленному таску https://packages.altlinux.org/en/tasks/355139/
(Ответ для Anton Farygin на комментарий #42) > podsec: > Аппрув должен буду делать в этот раз я. Хотелось бы оперативно получить список замечений (наряду с отсутсвием точек в конце). Пакет является одним из центральных, обсуждаемым в ходе еженедельных встреч по теме "Обсуждение ИК-01 Альт СП релиз 10". При наличии новых замечаний по функционалу я буду вынужден реализовывать новые релизы и версии пакета podsec В случае долгих блокировок я буду не способен проводить их на платформу c10f2. Что может привести к задержке формирования окончательного ISO-образа для платформы c10f2. Я готов оперативно устранять замечания рецензента, но не хотелось бы получать полную блокировку выхода очередных релизов и версия для платформы c10f2.
(Ответ для Anton Farygin на комментарий #43) > Что ещё посмотреть я не понял, но podsec меня ввёл в печаль. По основному заявленному таску https://packages.altlinux.org/en/tasks/355139/ была собраны образы, проведено тестирование и подготовлена документация по разворачиванию: https://packages.altlinux.org/en/tasks/355139/ Если есть замечания по wiki-статье готов проводить изменения По podsec была подготовлена документация как в рамках самого пакета (в форматах markdown и man): - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec/md;h=aa2272d0ff37b4844e6c9938480884a1c3e47243;hb=HEAD - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-k8s/md;h=fdc9ef45a27578948e1347003f2ddbbfceb7c813;hb=HEAD - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-inotify/md;h=4042f78534e7a4040f85566419b624308ed51d5d;hb=HEAD - https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=podsec-k8s-rbac/md;h=8bfb277ed82e0b4f3a7c3acf34e017cfb194ecd3;hb=HEAD так и по разворачиванию решения: - https://github.com/alt-cloud/podsec/blob/master/usernetes/README.md - https://www.altlinux.org/Rootless_kubernetes вошедшая в состав документов для сертификации платформ c10f1, c10f2 Если есть замечания к оформлению готов в фоновом режиме дорабатывать документацию
Рецензент сам решает какую работу смотреть у кандидата. Т.к. podsec собственная разработка, то предлагаю начать с неё. первым делом предлагаю переписать весь changelog пакета, приведя его в порядок. Все места, где в changelog указаны не изменения а version-release - раскрыть и написать в changelog сделанные изменения. Как только будет готово - присылайте номер сборочного задания.
(Ответ для Anton Farygin на комментарий #47) > Рецензент сам решает какую работу смотреть у кандидата. > > Т.к. podsec собственная разработка, то предлагаю начать с неё. > > первым делом предлагаю переписать весь changelog пакета, приведя его в > порядок. > Все места, где в changelog указаны не изменения а version-release - раскрыть > и написать в changelog сделанные изменения. > > Как только будет готово - присылайте номер сборочного задания. OK Задача понятна
(Ответ для Anton Farygin на комментарий #42) > podsec: > 1) changelog пакета немного не соответствует рекомендациям по написанию > changelog'ов, принятых в ALT Linux Team (точка в конце предложения) Прошу уточнить - точки в конце предложения ОБЯЗАТЕЛЬНЫ ии НЕОБЯЗАТЕЛЬНЫ В документе https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog указано "Единообразно оформляйте предложения changelog’а: либо начинайте, либо не начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их точкой." речь идет об единообразии, а не об обязательности точек В моем случае точки отсутствуют, что не нарушает указанное требование Правда часть строк начинается с маленько буквы - исправлю на большие Необходимо ли в этом случае ставить точки в конце? По поводу требования оформления на английском языке В самом начале развития проекта было принято решение (так как проект внутренний) писать логи на русском языке У меня в итоге смешанный формат оформления - часть логов на англмйском языка. Основная часть на русском Допустимо ли оставить как есть?
(Ответ для ALexey Kostarev на комментарий #49) > (Ответ для Anton Farygin на комментарий #42) > > podsec: > > 1) changelog пакета немного не соответствует рекомендациям по написанию > > changelog'ов, принятых в ALT Linux Team (точка в конце предложения) > > Прошу уточнить - точки в конце предложения ОБЯЗАТЕЛЬНЫ ии НЕОБЯЗАТЕЛЬНЫ > В документе > https://www.altlinux.org/ > %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0% > BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog указано > "Единообразно оформляйте предложения changelog’а: либо начинайте, либо не > начинайте их все с большой буквы; либо заканчивайте, либо не заканчивайте их > точкой." > речь идет об единообразии, а не об обязательности точек Предложение, которое начинается с большой буквы - должно заканчиваться точкой. перечисление с маленькой - нет. > > В моем случае точки отсутствуют, что не нарушает указанное требование > Правда часть строк начинается с маленько буквы - исправлю на большие > Необходимо ли в этом случае ставить точки в конце? Да > > По поводу требования оформления на английском языке > В самом начале развития проекта было принято решение (так как проект > внутренний) писать логи на русском языке > У меня в итоге смешанный формат оформления - часть логов на англмйском > языка. Основная часть на русском > Допустимо ли оставить как есть? У нас уже достаточно давно есть правило оформлять всю разработку на одном английском языке. Т.к. мы не знаем что дальше будет с каким проектом и какие разработчики к нему подключатся в дальнейшем, а английский понятен всем. Поэтому язык changelog'ов должен быть английский.
(Ответ для ALexey Kostarev на комментарий #49) > (Ответ для Anton Farygin на комментарий #42) > > podsec: равда часть строк начинается с маленько буквы - исправлю на большие > По поводу требования оформления на английском языке > В самом начале развития проекта было принято решение (так как проект > внутренний) писать логи на русском языке > У меня в итоге смешанный формат оформления - часть логов на англмйском > языка. Основная часть на русском > Допустимо ли оставить как есть? Вопрос снимаю Перевожу логи на английский
(Ответ для Anton Farygin на комментарий #50) > > В моем случае точки отсутствуют, что не нарушает указанное требование > > Правда часть строк начинается с маленько буквы - исправлю на большие > > Необходимо ли в этом случае ставить точки в конце? > > Да Сделано > > > > > По поводу требования оформления на английском языке > > В самом начале развития проекта было принято решение (так как проект > > внутренний) писать логи на русском языке > > У меня в итоге смешанный формат оформления - часть логов на англмйском > > языка. Основная часть на русском > > Допустимо ли оставить как есть? > > У нас уже достаточно давно есть правило оформлять всю разработку на одном > английском языке. Т.к. мы не знаем что дальше будет с каким проектом и какие > разработчики к нему подключатся в дальнейшем, а английский понятен всем. > Поэтому язык changelog'ов должен быть английский. Да подзапамятовал При наличии кирилических букв мой локальный hasher бинарные пакеты не собирает Перевел на английский добавив к тексту точки Локальный hasher бинарные пакеты собрал корректно Поместил podsec c последней версией podsec-1.1.6-alt6 на https://git.altlinux.org/people/kaf/packages/?p=podsec.git Но в текущий момент к сожалению сервер https://git.altlinux.org/ не отвечает :-( (504 Gateway Time-out nginx) и и gyle (194.107.17.31) хоть и пингуется, но обращение на порт 222 сваливаетcя по Timeout? Коллеги говорят, что в выходные была аналогичная ситуация Так что запустить задачу на сборку пока не могу :-( Буду ждать оживления сервисов
> Буду ждать оживления сервисов Сервисы заработали Старый task к сожалению уже удален Создал новый task https://git.altlinux.org/tasks/358357/
241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6 242 - Changelog of podsec.spec has been adjusted to comply with recommendations 243 - Support for loading additional images into the archive Точек нет.
Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: принято если изменение идёт только в спек-файле, то делать новый release. если изменение в коде, меняющее функционал - то выпускать новую версию (увеличивая version).
(Ответ для Anton Farygin на комментарий #54) > 241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6 > 242 - Changelog of podsec.spec has been adjusted to comply with > recommendations > 243 - Support for loading additional images into the archive > > Точек нет. Как это нет - они стоят ровно в том месте, которое описано в https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog В конце каждого пункта (- ...) и подпункта (+ ...) Или что то другое имеется в виду
(Ответ для ALexey Kostarev на комментарий #56) > (Ответ для Anton Farygin на комментарий #54) > > 241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6 > > 242 - Changelog of podsec.spec has been adjusted to comply with > > recommendations > > 243 - Support for loading additional images into the archive > > > > Точек нет. > > Как это нет - они стоят ровно в том месте, которое описано в > https://www.altlinux.org/ > %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0% > BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog > В конце каждого пункта (- ...) и подпункта (+ ...) > Или что то другое имеется в виду Н-да В нескольких сотнях логов точки поставил А во вновь добавленных 2-ч - нет :-) Меня извиняет только то, что последние комментарии добавлял в конце рабочего дня Переработаю
(Ответ для Anton Farygin на комментарий #55) > Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: > принято если изменение идёт только в спек-файле, то делать новый release. > если изменение в коде, меняющее функционал - то выпускать новую версию > (увеличивая version). Да - этот пункт я для мне объяснили, только несколько месяцев назад Хотя в другой редакции Если меняется функционал - увеличивается версия, если все остальное, то release То есть правки ошибок, создание и добавление документов и т.п. вроде как не меняют функционал. Поэтому я в этом случае увеличивал release Это правильно? По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии? Тут хоть правила и есть, то границы довольно расплывчаты В любом случае я не представляю как сейчас переработать структуру истории тегов Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь их уже чревато Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом замечаний по вопросу выше (входит ли исправление ошибок и доьавление документации в правило увеличения Release или Version)
(Ответ для Anton Farygin на комментарий #54) > 241 * Wed Sep 25 2024 Alexey Kostarev <kaf@altlinux.org> 1.1.6-alt6 > 242 - Changelog of podsec.spec has been adjusted to comply with > recommendations > 243 - Support for loading additional images into the archive > > Точек нет. Уф... Добавил точки https://git.altlinux.org/tasks/358357/gears/400/git?p=git;a=blob;f=podsec.spec;h=ba9646a3996127a5e7cbc07212271949b1b37741;hb=HEAD#l241
Я позволю себе влезть в процесс и напомнить Вам и рецензенту, что тексты изменений, будь то в ченджлоге, будь то в коммитах хорошо бы оформлять в единой временной форме. https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog#%D0%9B%D1%83%D1%87%D1%88%D0%B8%D0%B5_%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B8_%D0%BE%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_changelog Пункт 2 382 * Tue Nov 07 2023 Alexey Kostarev <kaf@altlinux.org> 1.0.10-alt1 ... 399 - Improvements to the correct definition of the list and version of kuber images. 400 - Adding U7S_KUBEADFLAGS variable containing all additional kubeadm flags. 401 - Added analysis and processing of flags. 402 - Adding support for flags via getopt. 403 - Documenting kubeadm flags in /docs/kubead/README.md. 404 - Request for deletion of the /var/lib/podsec/u7s/etcd directory if it exists during init and join. 405 - Clarification of platform detection for sisyphus. 406 - More accurate automatic detection of environment variables U7S_PLATFORM, U7S_KUBEVERSION. 407 - Document kubeadm flags in /docs/kubeadm/README.md. 408 - Move tuneAudit after CNI startup, restart services after tuneAudit. 409 - Remove u7s.target and its dependencies. 410 - Replace u7s.target with /usr/libexec/podsec/u7s/bin/. Здесь перечислены 4 формы отражения изменения: Improvements - существительное Adding - present continious Added - Past simple Move - Present simple Читать такой ченджлог как минимум неприятно, а быстро найти глазами интересующий момент ещё и сложно. Править это всё или нет решайте с рецензентом, но как минимум в будущем неплохо было бы определить единый стиль.
Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот момент. Традиционно, для коммитов (изменений в коде) у нас используется present simple, для записей changelog past simple.
(Ответ для Anton Farygin на комментарий #61) > Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот > момент. > > Традиционно, для коммитов (изменений в коде) у нас используется present > simple, для записей changelog past simple. Спасибо Займусь
(Ответ для ALexey Kostarev на комментарий #58) > (Ответ для Anton Farygin на комментарий #55) > > Ещё правило хорошего тона, которое постоянно нарушается в этом пакете: > > принято если изменение идёт только в спек-файле, то делать новый release. > > если изменение в коде, меняющее функционал - то выпускать новую версию > > (увеличивая version). > > Да - этот пункт я для мне объяснили, только несколько месяцев назад > Хотя в другой редакции > > Если меняется функционал - увеличивается версия, если все остальное, то > release > > То есть правки ошибок, создание и добавление документов и т.п. вроде как не > меняют функционал. Поэтому я в этом случае увеличивал release > Это правильно? > > По увеличению версии тоже вопросы - когда менять патч, минор и мажор версии? > Тут хоть правила и есть, то границы довольно расплывчаты > > В любом случае я не представляю как сейчас переработать структуру истории > тегов > Часть тегов уже попала в ссылки сторонних документов и перемещать и менятьь > их уже чревато > > Хотя в дальнейшем развитии постараюсь придерживаться этого правила с учетом > замечаний по вопросу выше (входит ли исправление ошибок и доьавление > документации в правило увеличения Release или Version) Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте версию.
прошу прощения, корректировка: Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того или иного поведения при изменении пакета, я предлагаю использовать простой факт - меняется содержимое source tarball - меняем версию, меняется содержимое только spec и сопутствующих файлов без изменения source tarball - увеличивайте _release_.
(Ответ для Anton Farygin на комментарий #64) > прошу прощения, корректировка: > Изменять старые версии пакета не нужно. Что бы не мучаться с выбором того > или иного поведения при изменении пакета, я предлагаю использовать простой > факт - меняется содержимое source tarball - меняем версию, меняется > содержимое только spec и сопутствующих файлов без изменения source tarball - > увеличивайте _release_. Спасибо Принцип довольно строгий, но для полной ясности у меня остается вопрос. Если на текущий момент необходимо сделать изменения как в source tarball, так и в spec и сопутствующих файлов создавать ли промежуточные release-теги, по которым не собираются бинарники ? Например у меня текущий тег 1.2.3-alt2 Я добавил в source tarball файл и соответственно меняю spec Создавать ли мне теги: 1.2.4-alt1 - добавление файла 1.2.4-alt2 - изменения spec Ясно, что бинарные пакеты будут собираться только для 1.2.4-alt2, так как 1.2.4-alt1 нефункционален Или достаточно создать 1.2.4-alt1 - добавление файла, изменения spec ?
1.2.4-alt1 - добавление файла, изменения spec
(Ответ для ALexey Kostarev на комментарий #62) > (Ответ для Anton Farygin на комментарий #61) > > Григорий, спасибо. Согласен с замечаний. Алексей, просьба исправить и этот > > момент. > > > > Традиционно, для коммитов (изменений в коде) у нас используется present > > simple, для записей changelog past simple. > > Спасибо > Займусь Добрый день https://git.altlinux.org/tasks/358357/gears/500/git?p=git;a=blob;f=podsec.spec;h=b0c959b4a8793a5b38580923288889b4063c5b95;hb=HEAD#l240
Спасибо. По спеку: очень сложно сделан выбор файлов для упаковки, тяжело читается. Вместо использования конструкций: %_bindir/podsec* %exclude %_bindir/podsec-save-oci %exclude %_bindir/podsec-u7s-* %exclude %_bindir/podsec-k8s-* %exclude %_bindir/podsec-inotify-* %_mandir/man?/podsec* %exclude %_mandir/man?/podsec-k8s-* %exclude %_mandir/man?/podsec-u7s-* %exclude %_mandir/man?/podsec-save-oci* %exclude %_mandir/man?/podsec-inotify-* проще и правильнее (лучше читается) перечислить файлы, которые будут входить в подпакет. Список там не очень большой и будет почти таким же по размерам как конструкции с exclude.
Идея упакетить домашний каталог с подкаталогами выглядит странно: %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s/etcd %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bashrc %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bash_profile %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.bash_logout и очень похоже на ошибку упаковки. По идее такие служебные домашние каталоги не должны предоставлять возможность пользователю в них работать.
(Ответ для Anton Farygin на комментарий #69) > Идея упакетить домашний каталог с подкаталогами выглядит странно: > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) > %_localstatedir/podsec/u7s/etcd > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bashrc > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bash_profile > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bash_logout > > и очень похоже на ошибку упаковки. > По идее такие служебные домашние каталоги не должны предоставлять > возможность пользователю в них работать. В смысле речь идет о правах 0750 в каталогах (это права по умолчанию) 0750 в каталогах означает возможность перейти в каталог, а не право на выполнение Если в них поставить 640, то пользователь не сможет не перейти в них, ни записывать в них файлы Зачем они тогда нужны? Пример: kaf@host-87:~/tmp $ mkdir a kaf@host-87:~/tmp$ ls -ld a drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a kaf@host-87:~/tmp $ chmod 644 a kaf@host-87:~/tmp $ ls -ld a drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a kaf@host-87:~/tmp $ cd a bash: cd: a: Отказано в доступе kaf@host-87:~/tmp $ >a/vvv bash: a/vvv: Отказано в доступе Или речь о другом?
(Ответ для Anton Farygin на комментарий #68) > Спасибо. > По спеку: > очень сложно сделан выбор файлов для упаковки, тяжело читается. > Вместо использования конструкций: > %_bindir/podsec* > %exclude %_bindir/podsec-save-oci > %exclude %_bindir/podsec-u7s-* > %exclude %_bindir/podsec-k8s-* > %exclude %_bindir/podsec-inotify-* > %_mandir/man?/podsec* > %exclude %_mandir/man?/podsec-k8s-* > %exclude %_mandir/man?/podsec-u7s-* > %exclude %_mandir/man?/podsec-save-oci* > %exclude %_mandir/man?/podsec-inotify-* > > проще и правильнее (лучше читается) перечислить файлы, которые будут входить > в подпакет. > > Список там не очень большой и будет почти таким же по размерам как > конструкции с exclude. Ну он будет поболее и труднее в сопровождении - надо будет корректировать spec при каждом добавлении/удалении файлов Но раз резензент просит, то это закон :-) Политику exclude сменю, но это потребует тестирования пакетов + сейчас разбираемся с коллегами с образом node-colector для trivy Возможно это потребует добавление функционала в podsec с увеличение patch-версии Так что новую версию podsec с исправлениями могу предоставить не ранее завтра :-(
речь о другом. попросите своего ментора разъяснить голосом.
(Ответ для ALexey Kostarev на комментарий #70) > (Ответ для Anton Farygin на комментарий #69) > > Идея упакетить домашний каталог с подкаталогами выглядит странно: > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) > > %_localstatedir/podsec/u7s/etcd > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > %u7s_admin_homedir/.bashrc > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > %u7s_admin_homedir/.bash_profile > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > %u7s_admin_homedir/.bash_logout > > > > и очень похоже на ошибку упаковки. > > По идее такие служебные домашние каталоги не должны предоставлять > > возможность пользователю в них работать. > В смысле речь идет о правах 0750 в каталогах (это права по умолчанию) > 0750 в каталогах означает возможность перейти в каталог, а не право на > выполнение > Если в них поставить 640, то пользователь не сможет не перейти в них, ни > записывать в них файлы > Зачем они тогда нужны? > > Пример: > kaf@host-87:~/tmp $ mkdir a > > kaf@host-87:~/tmp$ ls -ld a > drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a > > kaf@host-87:~/tmp $ chmod 644 a > kaf@host-87:~/tmp $ ls -ld a > drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a > > kaf@host-87:~/tmp $ cd a > bash: cd: a: Отказано в доступе > kaf@host-87:~/tmp $ >a/vvv > bash: a/vvv: Отказано в доступе > > Или речь о другом? Про речь о другом - ответ на это сообщение.
(Ответ для ALexey Kostarev на комментарий #71) > (Ответ для Anton Farygin на комментарий #68) > > Спасибо. > > По спеку: > > очень сложно сделан выбор файлов для упаковки, тяжело читается. > > Вместо использования конструкций: > > %_bindir/podsec* > > %exclude %_bindir/podsec-save-oci > > %exclude %_bindir/podsec-u7s-* > > %exclude %_bindir/podsec-k8s-* > > %exclude %_bindir/podsec-inotify-* > > %_mandir/man?/podsec* > > %exclude %_mandir/man?/podsec-k8s-* > > %exclude %_mandir/man?/podsec-u7s-* > > %exclude %_mandir/man?/podsec-save-oci* > > %exclude %_mandir/man?/podsec-inotify-* > > > > проще и правильнее (лучше читается) перечислить файлы, которые будут входить > > в подпакет. > > > > Список там не очень большой и будет почти таким же по размерам как > > конструкции с exclude. > > Ну он будет поболее и труднее в сопровождении - надо будет корректировать > spec при каждом добавлении/удалении файлов > > Но раз резензент просит, то это закон :-) > > Политику exclude сменю, но это потребует тестирования пакетов > > + сейчас разбираемся с коллегами с образом node-colector для trivy > Возможно это потребует добавление функционала в podsec с увеличение > patch-версии > > Так что новую версию podsec с исправлениями могу предоставить не ранее > завтра :-( Ок. Присылайте все изменения на review
(Ответ для Anton Farygin на комментарий #73) > (Ответ для ALexey Kostarev на комментарий #70) > > (Ответ для Anton Farygin на комментарий #69) > > > Идея упакетить домашний каталог с подкаталогами выглядит странно: > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s > > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) > > > %_localstatedir/podsec/u7s/etcd > > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > > %u7s_admin_homedir/.bashrc > > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > > %u7s_admin_homedir/.bash_profile > > > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > > > %u7s_admin_homedir/.bash_logout > > > > > > и очень похоже на ошибку упаковки. > > > По идее такие служебные домашние каталоги не должны предоставлять > > > возможность пользователю в них работать. > > В смысле речь идет о правах 0750 в каталогах (это права по умолчанию) > > 0750 в каталогах означает возможность перейти в каталог, а не право на > > выполнение > > Если в них поставить 640, то пользователь не сможет не перейти в них, ни > > записывать в них файлы > > Зачем они тогда нужны? > > > > Пример: > > kaf@host-87:~/tmp $ mkdir a > > > > kaf@host-87:~/tmp$ ls -ld a > > drwxr-xr-x 2 kaf kaf 4096 сен 26 14:04 a > > > > kaf@host-87:~/tmp $ chmod 644 a > > kaf@host-87:~/tmp $ ls -ld a > > drw-r--r-- 2 kaf kaf 4096 сен 26 14:04 a > > > > kaf@host-87:~/tmp $ cd a > > bash: cd: a: Отказано в доступе > > kaf@host-87:~/tmp $ >a/vvv > > bash: a/vvv: Отказано в доступе > > > > Или речь о другом? > > Про речь о другом - ответ на это сообщение. Речь о том, что данные каталоги должны создаваться при создании пользователя в секцмм %pre https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec.spec;h=b0c959b4a8793a5b38580923288889b4063c5b95;hb=HEAD#l146 ? Возможно Вы правы - эти изменения вносились на определенном этапе для корректной работы podsec rootless Возможно сейчас уже не требуется... Просмотрю функционал и %_localstatedir/podsec/u7s (/usr/libexec/ который по умолчанию не создается перенесу в секцию %pre
(Ответ для Anton Farygin на комментарий #69) > Идея упакетить домашний каталог с подкаталогами выглядит странно: > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.local > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.cache > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.config > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir/.ssh > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) > %_localstatedir/podsec/u7s/etcd > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bashrc > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bash_profile > %config(noreplace) %attr(0640,%u7s_admin_usr,%u7s_admin_grp) > %u7s_admin_homedir/.bash_logout > > и очень похоже на ошибку упаковки. > По идее такие служебные домашние каталоги не должны предоставлять > возможность пользователю в них работать. Добрый день Замечания исправил https://git.altlinux.org/tasks/358357/
https://git.altlinux.org/tasks/358357/logs/events.6.1.log В логах очень много unowned files
(Ответ для Anton Farygin на комментарий #77) > https://git.altlinux.org/tasks/358357/logs/events.6.1.log > > В логах очень много unowned files Добавил описание каталогов https://git.altlinux.org/tasks/358357/logs/events.11.1.log Каталоги /usr/libexec/podsec/u7s /var/lib/u7s-admin /var/lib/u7s-admin/.bashrc /var/lib/u7s-admin/.cache /var/lib/u7s-admin/.local /var/lib/u7s-admin/.local/share /var/lib/u7s-admin/.local/share/usernetes /var/lib/u7s-admin/.local/share/usernetes/containers так как это подкаталоги домашнего каталога системного пользователя u7s-admin и они создаются на этапе %pre k8s Если добавлю, то снова получу от Вас замечание описанное выше
Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? И ещё - в логе про unowned files есть фа https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/3120979963681020020
Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету.
(Ответ для Anton Farygin на комментарий #79) > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > 3120979963681020020 При добавлении системного пользователя (в отличии от обычного) не используется skel, а мне нужны файлы - .bash_profile - .bashrc Если точнее мне нужно доопределить переменную PATH: export PATH=/usr/libexec/podsec/u7s/bin/:$PATH Обычно это делается в .bashrc А для его вызова требуется .bash_profile Я конечно могу их скопировать в пакет Это было сделано до этого и что Вам не понравилось: > и очень похоже на ошибку упаковки. > По идее такие служебные домашние каталоги не должны предоставлять > возможность пользователю в них работать. Так что единственным выходом в условиях в которые меян поставили было использование /etc/skel
(Ответ для Anton Farygin на комментарий #80) > Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету. Он принадлежал пакету podsec-k8s, но попал в список каталогов, https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c69 > Идея упакетить домашний каталог с подкаталогами выглядит странно: > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > ... Можно как то более точно определить замечание #c69 Иначе я вижу противоречие между двумя замечаниями
(Ответ для ALexey Kostarev на комментарий #81) > (Ответ для Anton Farygin на комментарий #79) > > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > 3120979963681020020 > > При добавлении системного пользователя (в отличии от обычного) не > используется skel, а мне нужны файлы > - .bash_profile > - .bashrc > > Если точнее мне нужно доопределить переменную PATH: > export PATH=/usr/libexec/podsec/u7s/bin/:$PATH > > Обычно это делается в .bashrc > А для его вызова требуется > .bash_profile > > Я конечно могу их скопировать в пакет > Это было сделано до этого и что Вам не понравилось: > > и очень похоже на ошибку упаковки. > > По идее такие служебные домашние каталоги не должны предоставлять > > возможность пользователю в них работать. > > Так что единственным выходом в условиях в которые меян поставили было > использование /etc/skel Ну зачем же так сложно. путь к скриптам можно переопределить в самих скриптах, а не в домашнем каталоге. сделать что-то вроде functions, в котором будет переопределяться путь и этот functions инклюдить в каждом скрипте.
(Ответ для ALexey Kostarev на комментарий #82) > (Ответ для Anton Farygin на комментарий #80) > > Каталог /var/lib/u7s-admin должен принадлежать какому-то пакету. > > Он принадлежал пакету podsec-k8s, но попал в список каталогов, > https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c69 > > Идея упакетить домашний каталог с подкаталогами выглядит странно: > > %dir %attr(0750,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir > > ... > Можно как то более точно определить замечание #c69 > Иначе я вижу противоречие между двумя замечаниями Сам домашний каталог должен быть упакечен с нужными правами, но пустой. Не надо его создавать вместе с пользователем.
(Ответ для Anton Farygin на комментарий #79) > И ещё - в логе про unowned files есть фа > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > 3120979963681020020 Можно уточнить о каком именно файле идет речь (в тексте не закрнчено)? В логах https://git.altlinux.org/tasks/358357/logs/events.11.1.log я не вижу имени файла из пакета nagwad-service И вроде это как не мой пакет Мои из области протоколирования логов: - podsec-nagios - podsec-icings
(Ответ для ALexey Kostarev на комментарий #85) > (Ответ для Anton Farygin на комментарий #79) > > И ещё - в логе про unowned files есть фа > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > 3120979963681020020 > > Можно уточнить о каком именно файле идет речь (в тексте не закрнчено)? > В логах https://git.altlinux.org/tasks/358357/logs/events.11.1.log > я не вижу имени файла из пакета nagwad-service > И вроде это как не мой пакет > > Мои из области протоколирования логов: > - podsec-nagios > - podsec-icings x86_64: podsec=1.1.8-alt2 post-install unowned files: /etc/nagwad возможно просто не хватает какой-то зависимости
(Ответ для Anton Farygin на комментарий #83) > (Ответ для ALexey Kostarev на комментарий #81) > > (Ответ для Anton Farygin на комментарий #79) > > > Не должно быть файлов из skel для пользователя сервиса. Зачем они нужны ? > > > https://packages.altlinux.org/ru/sisyphus/binary/nagwad-service/noarch/files/ > > > 3120979963681020020 > > > > При добавлении системного пользователя (в отличии от обычного) не > > используется skel, а мне нужны файлы > > - .bash_profile > > - .bashrc > > > > Если точнее мне нужно доопределить переменную PATH: > > export PATH=/usr/libexec/podsec/u7s/bin/:$PATH > > > > Обычно это делается в .bashrc > > А для его вызова требуется > > .bash_profile > > > > Я конечно могу их скопировать в пакет > > Это было сделано до этого и что Вам не понравилось: > > > и очень похоже на ошибку упаковки. > > > По идее такие служебные домашние каталоги не должны предоставлять > > > возможность пользователю в них работать. > > > > Так что единственным выходом в условиях в которые меян поставили было > > использование /etc/skel > > Ну зачем же так сложно. путь к скриптам можно переопределить в самих > скриптах, а не в домашнем каталоге. > > сделать что-то вроде functions, в котором будет переопределяться путь и этот > functions инклюдить в каждом скрипте. И это Вы называете просто? Вместо того, чтобы определить переменную PATH при запуске любого скрипта из под пользователя u7s-admin определять эту переменную в десятке скриптов https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=tree;f=usernetes/bin;h=7621bc56acfab9c3fa6606a8ad9d44a82ea8d1c0;hb=HEAD ? + отлаживать ситуации когда переменная PATH корректно не определяется У нас с Вами разные представления о сложности :-) > По идее такие служебные домашние каталоги не должны предоставлять возможность пользователю в них работать. Обычному пользователю да - не должны Но администратору kubernetes (ну и разработчику и тестеру) вроде как сильно не помещают Часто возникает при отладке и эксплуатации необходимость выполнить команду в namespace окружении пользователя u7s-admin: # machinectl shell u7s-admin@ $ nsenter_u7s # <команды в namespace-окружении>: iptables ..., ip ..., crictl, ... # less <файл> # просмотр файлов логов и т.пю которые видны ТОЛЬКО в namespace-окружении Я как бывший (и текущий) администратор считаю некорректным каждый раз еще добавлять в этот сложный процесс еще и переопределение переменной PATH перед запуском команды nsenter_u7s
из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc и сразу в двух пакетах это ошибка. да, архитектура приложения не должна полагаться на PATH в окружении, а системный пользователь не предназначен для рядовой работы под ним.
(Ответ для Anton Farygin на комментарий #88) > из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: > https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc > > и сразу в двух пакетах это ошибка. > > > > да, архитектура приложения не должна полагаться на PATH в окружении, а > системный пользователь не предназначен для рядовой работы под ним. Я про рядовую работу не говорю Я говорю про работу администратора kubernetes в нестандартных ситуациях Это как я понимаю из неписанных правил. Ждал от Вас замечания, что в /etc/password должен быть /bin/false в качестве интепретатора Ожидать в дальнейшем или указание /bin/bash в системных пользователя допустимо? Данные предложения приведут к: - серъезной переработке кода - отладке на моей стадии - поиск регрессий на стадии тестирования - обсуждения и добавления механизма для администратора kubernetes заходить в namespace пользователя u7s-admin - доработке документации для администратора kubernetes - смене минорной версии пакета на podsec 1.2 Я не против этих изменений, но сейчас коллеги по сертификации платформы c10f2 ждут от меня изменений по обнаруженным в рамках тестирования недоработкам для podsec этой платформы. Так как при описанных доработках срок реализации этих изменений и прохождения полного тестирования на регресии составит 1-2 недели я буду вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт СП релиз 10" обрисовать эту ситуацию. Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join после реализации podsec-1.2.x Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, ... А делать то что?
(Ответ для ALexey Kostarev на комментарий #89) > (Ответ для Anton Farygin на комментарий #88) > > из 20 тысяч пакетов bashrc присутствует в совсем небольшом количестве: > > https://packages.altlinux.org/ru/sisyphus/files/?q=.bashrc > > > > и сразу в двух пакетах это ошибка. > > > > > > > > да, архитектура приложения не должна полагаться на PATH в окружении, а > > системный пользователь не предназначен для рядовой работы под ним. > > Я про рядовую работу не говорю > > Я говорю про работу администратора kubernetes в нестандартных ситуациях > > Это как я понимаю из неписанных правил. > Ждал от Вас замечания, что в /etc/password должен быть /bin/false в качестве > интепретатора > Ожидать в дальнейшем или указание /bin/bash в системных пользователя > допустимо? > > Данные предложения приведут к: > - серъезной переработке кода > - отладке на моей стадии > - поиск регрессий на стадии тестирования > - обсуждения и добавления механизма для администратора kubernetes заходить в > namespace пользователя u7s-admin > - доработке документации для администратора kubernetes > - смене минорной версии пакета на podsec 1.2 > > Я не против этих изменений, но сейчас коллеги по сертификации платформы > c10f2 ждут от меня изменений по обнаруженным в рамках тестирования > недоработкам для podsec этой платформы. > > Так как при описанных доработках срок реализации этих изменений и > прохождения полного тестирования на регресии составит 1-2 недели я буду > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > СП релиз 10" обрисовать эту ситуацию. > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > после реализации podsec-1.2.x > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > ... > > > > А делать то что? Последняя фраза вне контекста Игнорируйте :-)
> x86_64: podsec=1.1.8-alt2 post-install unowned files: > /etc/nagwad > > > возможно просто не хватает какой-то зависимости Я почему то не могу найти этой строки в log'ах Но описания каталога действительно нет в spec Добавил В логах (снова :-)) не вижу https://git.altlinux.org/tasks/358357/logs/events.12.1.log
(Ответ для ALexey Kostarev на комментарий #91) > > x86_64: podsec=1.1.8-alt2 post-install unowned files: > > /etc/nagwad > > > > > > возможно просто не хватает какой-то зависимости > > Я почему то не могу найти этой строки в log'ах > > Но описания каталога действительно нет в spec > > Добавил Это не правильно. На мой взгляд должна была быть зависимость на пакет, в котором живёт этот каталог.
(Ответ для Anton Farygin на комментарий #92) > (Ответ для ALexey Kostarev на комментарий #91) > > > x86_64: podsec=1.1.8-alt2 post-install unowned files: > > > /etc/nagwad > > > > > > > > > возможно просто не хватает какой-то зависимости > > > > Я почему то не могу найти этой строки в log'ах > > > > Но описания каталога действительно нет в spec > > > > Добавил > > Это не правильно. > > На мой взгляд должна была быть зависимость на пакет, в котором живёт этот > каталог. OK Возможно Обсужу в @manowar Он занимался этой частью пакета
(Ответ для ALexey Kostarev на комментарий #89) > Так как при описанных доработках срок реализации этих изменений и > прохождения полного тестирования на регресии составит 1-2 недели я буду > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > СП релиз 10" обрисовать эту ситуацию. > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > после реализации podsec-1.2.x > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, Алексей, мы здесь про JOIN в ALT Linux Team. JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и остальных коллег. для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно отправлять задания не дожидаясь их прохождения в Sisyphus. Но это не убирает необходимости в рамках JOIN поднять качество пакету.
(Ответ для Anton Farygin на комментарий #94) > (Ответ для ALexey Kostarev на комментарий #89) > > > Так как при описанных доработках срок реализации этих изменений и > > прохождения полного тестирования на регресии составит 1-2 недели я буду > > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > > СП релиз 10" обрисовать эту ситуацию. > > > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > > после реализации podsec-1.2.x > > > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > > Алексей, мы здесь про JOIN в ALT Linux Team. > JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и > остальных коллег. > > для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я > удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно > отправлять задания не дожидаясь их прохождения в Sisyphus. > > Но это не убирает необходимости в рамках JOIN поднять качество пакету. Да конечно Спасибо, за вышеприведенные замечания и то, что вошли в текущую ситуацию... Я, как Вы рекомендовали, проконсультируюсь по оставшимся разногласиями у своего менторы Алексей Шабалина Думаю по итогам обсуждения продолжим движение дальше в рамках этой задачи
(Ответ для Anton Farygin на комментарий #94) > (Ответ для ALexey Kostarev на комментарий #89) > > > Так как при описанных доработках срок реализации этих изменений и > > прохождения полного тестирования на регресии составит 1-2 недели я буду > > вынужден сегодня в 16:00 MSK на обсуждении в рамках "Обсуждение ИК-01 Альт > > СП релиз 10" обрисовать эту ситуацию. > > > > Как альтернативу предлагаю все таки пропустить текущий релиз (в доработками > > unowners files) в sisyphus, а "пропускать" меня на дальнейшую стадию join > > после реализации podsec-1.2.x > > > > Обсудить можно с Игорем Корчагиным, Владимиром Черным, Денисом Медведевым, > > Алексей, мы здесь про JOIN в ALT Linux Team. > JOIN ничего не знает про ваши сложности с СП релиз 10, Чёрного, Корчагина и > остальных коллег. > > для того, что бы задание в Sisyphus не держало ваши задачи по c10f2, я > удаляю пакет podsec из Sisyphus и теперь в репозиторий c10f2 можно > отправлять задания не дожидаясь их прохождения в Sisyphus. > > Но это не убирает необходимости в рамках JOIN поднять качество пакету. Доброго времени суток podsec-пакеты прошли тестирование в c10f2. Спасибо Сформировал 1.1.8-alt4: - переопределение переменной PATH перенесено из .bashrc в функцию podsec-u7s-function - флаг -m (создать домашний каталог) в useradd заменен на -M (не создавать) - кроме домашнего каталога ~u7s-admin в пакет podsec-k8s включены подкаталоги .local, .local/share, .local/share/usernetes. .local/share/usernetes/containers. Это связано с необходимостью объединения каталогов контейнеров и образов обычного и namespaced окружения пользователя u7s-admin. Это обеспечивает корректную работу команды trivy для анализа уязвимостей в контейнерах и образах в пакете podsec-inotify Логи сборки образа https://git.altlinux.org/tasks/358357/logs/events.18.1.log
Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при изменении исходного кода проекта. Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите)
Права 0755 для домашнего каталога выглядят несекьюрно: %dir %attr(0755,%u7s_admin_usr,%u7s_admin_grp) %_localstatedir/podsec/u7s %dir %attr(0755,%u7s_admin_usr,%u7s_admin_grp) %u7s_admin_homedir
(Ответ для Anton Farygin на комментарий #97) > Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при > изменении исходного кода проекта. > > Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите) Инерция привычки :-( Пока бросает в крайности Я и точки в комитах то пока с трудом ставлю со второго раза :-) Исправлюсь
(Ответ для ALexey Kostarev на комментарий #99) > (Ответ для Anton Farygin на комментарий #97) > > Алексей, я настоятельно рекомендую придерживаться выпуска новой версии при > > изменении исходного кода проекта. > > > > Т.е. - здесь явно напрашивается 1.1.9-alt1 (в последнем коммите) > > Инерция привычки :-( > Пока бросает в крайности > Я и точки в комитах то пока с трудом ставлю со второго раза :-) > Исправлюсь Добрый день! https://git.altlinux.org/tasks/358357/: - изменил историю на версию 1.1.9-alt1 - изменил права доступа ~u7s-admin/.local/ с 0755 на 0700 - для скриптов, запускаемых под пользователем u7s-admin сменил владельца на u7s-admin и права доступа на 0700 - проверил разворачивание - версия рабочая
В specfile осталось ещё много, очень много каталогов с правами 0755 Вероятно этот список надо посмотреть весь и там, где не нужны такие права - сделать их более ограниченными по умолчанию.
(Ответ для Anton Farygin на комментарий #101) > В specfile осталось ещё много, очень много каталогов с правами 0755 > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > сделать их более ограниченными по умолчанию. OK Посмотрю Возможно для части каталогов и файлов стоит поменять и владельца с root на u7s-admin У меня на очереди в sisyphus еще висят 8 пакетов flux2 https://packages.altlinux.org/en/tasks/355139/ Для 6-ти из них надо создавать docker-образы. Но пока они не попадут в sisyphus собрать образы нет возможности Какова дальнейшая судьба этих пакетов?
(Ответ для ALexey Kostarev на комментарий #102) > (Ответ для Anton Farygin на комментарий #101) > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > сделать их более ограниченными по умолчанию. > > OK > Посмотрю > Возможно для части каталогов и файлов стоит поменять и владельца с root на > u7s-admin > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > https://packages.altlinux.org/en/tasks/355139/ > > Для 6-ти из них надо создавать docker-образы. > Но пока они не попадут в sisyphus собрать образы нет возможности > > Какова дальнейшая судьба этих пакетов? Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения однй задачу. Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, вносить исправления - это всё можно закончить за день.
(Ответ для Anton Farygin на комментарий #103) > (Ответ для ALexey Kostarev на комментарий #102) > > (Ответ для Anton Farygin на комментарий #101) > > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > > сделать их более ограниченными по умолчанию. > > > > OK > > Посмотрю > > Возможно для части каталогов и файлов стоит поменять и владельца с root на > > u7s-admin > > > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > > https://packages.altlinux.org/en/tasks/355139/ > > > > Для 6-ти из них надо создавать docker-образы. > > Но пока они не попадут в sisyphus собрать образы нет возможности > > > > Какова дальнейшая судьба этих пакетов? > > Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения > однй задачу. > > Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, > вносить исправления - это всё можно закончить за день. OK Я просто пока мгновенно реагировать не могу - отвлекают работы по c10f2 Но постараюсь оперативно реагировать на замечания.
(Ответ для Anton Farygin на комментарий #103) > (Ответ для ALexey Kostarev на комментарий #102) > > (Ответ для Anton Farygin на комментарий #101) > > > В specfile осталось ещё много, очень много каталогов с правами 0755 > > > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > > > сделать их более ограниченными по умолчанию. > > > > OK > > Посмотрю > > Возможно для части каталогов и файлов стоит поменять и владельца с root на > > u7s-admin > > > > У меня на очереди в sisyphus еще висят 8 пакетов flux2 > > https://packages.altlinux.org/en/tasks/355139/ > > > > Для 6-ти из них надо создавать docker-образы. > > Но пока они не попадут в sisyphus собрать образы нет возможности > > > > Какова дальнейшая судьба этих пакетов? > > Я не хотел бы в bugzilla смешивать и предлагаю сначала довести до завершения > однй задачу. > > Я отвечаю быстро. И если оперативно и качественно, не делая новых ошибок, > вносить исправления - это всё можно закончить за день. Уточнил владельцев и права доступа для скриптов выполняемых при разворачивании rootless kubernetes узла, располагаемых в каталоге /usr/libexec/podsec/u7s/bin/ В свое время выбрал этот каталог, как рекомендуемый. Но не вчитался в детали. Его необходимо добавлять в тропу PATH Сейчас обратил внимание но то, что для выполняемых файлов пользователя есть каталог $HOME/bin. ПРичем он автоматически добавляется в /etc/profiles при выполнении скриптов под пользователей u7s-admin Может стоит перенести выполняемые скрипты из /usr/libexec/podsec/u7s/bin/ в ~u7s-admin/bin ? В этом случае и необходимость модификации PATH отпадает при разворачивании rootless kuber (podsec-k8s).
точно не стоит. FHS придумали как раз для того, что бы таких идей не возникало.
(Ответ для Anton Farygin на комментарий #106) > точно не стоит. FHS придумали как раз для того, что бы таких идей не > возникало. Меня как раз и смутило 1. Внимаетельное прочтение FHS-документа: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html /usr/libexec includes internal binaries that are not intended to be EXECUTED DIRECTLY by users or shell scripts. В нашем случае часть скриптов из /usr/libexec/podsec/bin вызываются непосредственно из окружения пользователя при разворачивании rootless-kubernetes по схемам в скобках пользователи: /usr/libexec/podsec/bin/kubeadm (root) -> /usr/libexec/podsec/bin/kubeadm.sh (u7s-admin) -> системная_команда_или_podsec-скрипт /usr/libexec/podsec/bin/kubeadm (root) -> /usr/libexec/podsec/bin/kubeadm.sh (u7s-admin) -> nsenter (переход в namespace u7s-admin с правами превдо-root) -> системная_команда_или_podsec-скрипт (превдо-root пользователя u7s-admin) shell (u7s-admin) -> системная_команда_или_podsec-скрипт (u7s-admin) shell (u7s-admin) -> nsenter (переход в namespace u7s-admin с правами превдо-root) -> системная_команда_или_podsec-скрипт (превдо-root пользователя u7s-admin) То есть часть скриптов вызывается НЕПОСРЕДСТВЕННО ПОЛЬЗОВАТЕДЕМ u7s-admin 2. $HOME/bin хоть и не сходит в FHS, но в RPM-дистрибутивах (в которым вроде как принажлежит дистрибутив ALTLinux) является практически стандартом де-факто и автоматически добавляется в тропе HOME в начало в /etc/profile: https://unix.stackexchange.com/questions/507829/what-binaries-are-stored-in-home-username-bin However, having /home/username/bin/ is something you can encounter on RPM-based distributions, such as Fedora, Red Hat Entreprise Linux or Suse. Именно эти соображения и сподвигли меня оформить это предложение PS Может для оперативного решения части вопросов и дискуссии использовать telegram?
Лучше обсудить этот вопрос с ментором (Алексеем Шабалиным).
(Ответ для ALexey Kostarev на комментарий #107) > Может для оперативного решения части вопросов и дискуссии использовать > telegram? По-моему, оперативнее, чем отвечает rider@ уже некуда. Мне вот интересно понаблюдать за вашим джойном. Мне интересно и как ментору некоторых кандидатов и как уже состоявшемуся мейнтейнеру. Возможно кто-то ещё наблюдает:)
(Ответ для Anton Farygin на комментарий #101) > В specfile осталось ещё много, очень много каталогов с правами 0755 > Вероятно этот список надо посмотреть весь и там, где не нужны такие права - > сделать их более ограниченными по умолчанию. Добрый вечер Поправил и доьавил права и владельцев файлов и каталогов https://git.altlinux.org/tasks/358357/logs/events.19.1.log Большинству файлов и каталогов установил владельца и группу u7s-admin, с правами 0700 для каталогов и 0600 для файлов, так как они используются при запуске rootless-kubernetes при работа в среде пользователя u7s-admin. Часть скриптов запускаются при работа непосредственно в пользователе u7s-admin. Часть в его namespace от имени предво-root, который в HOST_системе имеет права пользователя u7s-admin Для файлов и каталогов пользователя u7s-admin права выставил 0700 для каталогов и скриптов, 0600 для обычных файлов и файлов конфигураций Сторонний пользователеь в этом случае их не прочтет, не изменит и не выполнит А пользователь root в любом случае имеет права аналогичные пользователю u7s-admin Для скриптов, запускаемых только под root (/usr/bin/podsec-u7s-kubeadm) выставил права 0700 с владельцем root Для скриптов, запускаемых как от root, так и от любого пользователя (это в основном скрипты для работы с кластером и RBAC) указывать права доступа и владельца root не стал Как я понимаю по умолчанию установится то что надо: %attr(0755,root,root) Защищенность данного решения от доступа к скриптам и файлам сторонним пользователем значительно возросла Что очень полезно для защищенного решения в рамках платформ c10f Спасибо за совет!
+- Removed unuser script podsec-k8s-create-master. выглядит как опечатка. Всё остальное (я детально права не проверял) стало заметно лучше. спасибо.
Ещё вот тут: https://git.altlinux.org/tasks/358357/build/2300/x86_64/srpm.log заметил: warning: Macro %min_kube_minor_version not found warning: Macro %min_kube_minor_version not found в changelog нужно писать как %%min_kube_minor_version (экранировать макрос). Иначе он раскроется в полноценный макрос, который будет написан прямо в changelog
(Ответ для Anton Farygin на комментарий #112) > Ещё вот тут: > https://git.altlinux.org/tasks/358357/build/2300/x86_64/srpm.log > заметил: > warning: Macro %min_kube_minor_version not found > warning: Macro %min_kube_minor_version not found > > в changelog нужно писать как %%min_kube_minor_version (экранировать макрос). > Иначе он раскроется в полноценный макрос, который будет написан прямо в > changelog https://git.altlinux.org/tasks/358357/ Опечатку испрвил Спасибо за %min_kube_minor - не мог найти место Для единообразия не стал экранировать %, а удалил
(In reply to ALexey Kostarev from comment #113) > Спасибо за %min_kube_minor - не мог найти место > > Для единообразия не стал экранировать %, а удалил Только об этом не надо делать записи в changelog пакета. Просто коммит с фиксом и всё. И не надо увеличивать релиз лишний раз, если пакет ещё не был собран в репозиторий.
(Ответ для Anton Farygin на комментарий #114) > (In reply to ALexey Kostarev from comment #113) > > Спасибо за %min_kube_minor - не мог найти место > > > > Для единообразия не стал экранировать %, а удалил > > > Только об этом не надо делать записи в changelog пакета. Просто коммит с > фиксом и всё. > > И не надо увеличивать релиз лишний раз, если пакет ещё не был собран в > репозиторий. DONE
я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный git commit без изменения specfile и версии. Т.е. - просто commit, в котором поправить кривую запись changelog. Ещё что заинтересовало в specfile, коль мы уж решили дальше работать над его качеством - зачем-то фильтруются зависимости. Когда так делают, то обычно это или ошибка, или непонимание работы алгоритмов поиска зависимостей. Предлагаю прокомментировать каждый из фильтров.
(Ответ для Anton Farygin на комментарий #116) > я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный > git commit без изменения specfile и версии. > > Т.е. - просто commit, в котором поправить кривую запись changelog. https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary Постарался обеспечить в последних комитах между 1.1.9-alt1, 1.1.10-alt1
(Ответ для Anton Farygin на комментарий #116) > > Ещё что заинтересовало в specfile, коль мы уж решили дальше работать над его > качеством - зачем-то фильтруются зависимости. Когда так делают, то обычно > это или ошибка, или непонимание работы алгоритмов поиска зависимостей. > Предлагаю прокомментировать каждый из фильтров. https://git.altlinux.org/tasks/358357/ Добавил комментарии https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec.spec;h=87d9d05c5dd51bbc6948c55d769a6ab0dd93fc68;hb=HEAD#l59 Дело в том, что kubernetes достаточно активно развивается За последние 1.5 года что существует podsec уже вышло 6 минорных версий kubernetes: 1.26, 1.27, 1.28, 1.29, 1.30, 1.31 В рамках каждой минорной версии 3-10 патчевых Мы для каждой минорной версии создаем отдельный версионный набор kubernetes-пакетов kubernetes-1.22, kubernetes1.23, .., kubernetes-1.33 См. https://packages.altlinux.org/ru/search/?branch=sisyphus&q=kubernetesВ рамках каждой минорной версии собирается несколько патчевых версий образов Поэтому нет особого смысла в RPM-пакет добавлять зависимости на последнюю минорную версию kubernetes. Во время установки пакета она может быть намного старше Поэтому сейчас поддерживается режим, когда последняя версия kubernetes определяется и устанавливается в момент разворачивания кластера podsec-скриптом kubeadm init ... в функции installKubeadm https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec-k8s/bin/podsec-u7s-functions;h=5ec158f92068bbca51e89b2a0b15edb399fea7bd;hb=HEAD#l354 Кроме этого эта функция позволяет устновить версию kubeadm, указанную в переменной U7S_KUBEVERSION См. https://www.altlinux.org/Rootless_kubernetes#%D0%92%D1%8B%D0%B1%D0%BE%D1%80_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8_kubernetes,_%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0_%D0%B8_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D1%8B Поэтому нет смысла в пакет podsec-k8s добавлять при сборке пакета зависимость от последней минорной версии kubernetes В момент разворачивания кластера она может быть другой
> В момент разворачивания кластера она может быть другой Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который предоставится одним из: https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не произойдёт.
И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 Заметил что весь вывод текста идёт на русском языке. Это ошибка, весь вывод нужно делать по умолчанию на английском и в зависимости от локали переводить на русский через gettext На мой взгляд ментор должен был рассказать про это при ревью кода.
(In reply to ALexey Kostarev from comment #117) > (Ответ для Anton Farygin на комментарий #116) > > я бы, конечно, рекомендовал для этих мелких изменений использовать отдельный > > git commit без изменения specfile и версии. > > > > Т.е. - просто commit, в котором поправить кривую запись changelog. > https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=summary > > Постарался обеспечить в последних комитах между > 1.1.9-alt1, 1.1.10-alt1 Спасибо, с этим я уже проблем не вижу.
(Ответ для Anton Farygin на комментарий #119) > > В момент разворачивания кластера она может быть другой > > Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который > предоставится одним из: > https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm > > Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий > пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не > произойдёт. По моему уже пошла вкусовщина :-) При разворачивании kuber часто необходимо бывает установить не последнюю минорную версию Это необходимо как при тестировании, так и при разворачивании у клиента Дело в том, что kuber разрешает только последовательные обновления То есть, если у клиента стоял kuber-1.26, то он должен последовательно обновиться 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 Это решается путем установки переменной среды U7S_KUBEVERSION В этой ситуации произойдет двойная загрузка kuber-пакетов - последней при apt-get install - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше на каждом из многочисленных узлов кластера (десятки, сотни) kuber-пакеты не маленькие Время на загрузку-перезагрузку уходит приличное Зачем при apt-get install podsec-k8s ставить последнюю версию kuber, если далее (при обновлении со старых версий) ее придется заменять на другую на многочисленных узлах кластера? Это только вызовет раздражение у клиента и ничего более... Я смысла не вижу...
(Ответ для ALexey Kostarev на комментарий #122) > (Ответ для Anton Farygin на комментарий #119) > > > В момент разворачивания кластера она может быть другой > > > > Ну так отлично, можно не удалять зависимость на /usr/bin/kubeadm, который > > предоставится одним из: > > https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fusr%2Fbin%2Fkubeadm > > > > Т.е. - она универсальная и при установке podsec-k8s вытянется самый свежий > > пакет с /usr/bin/kubeadm, а если он уже установлен в системе, то ничего не > > произойдёт. > > По моему уже пошла вкусовщина :-) > При разворачивании kuber часто необходимо бывает установить > не последнюю минорную версию > Это необходимо как при тестировании, так и при разворачивании у клиента > Дело в том, что kuber разрешает только последовательные обновления > То есть, если у клиента стоял kuber-1.26, то он должен последовательно > обновиться > 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 > > Это решается путем установки переменной среды U7S_KUBEVERSION > > В этой ситуации произойдет двойная загрузка kuber-пакетов > - последней при apt-get install > - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше > на каждом из многочисленных узлов кластера (десятки, сотни) > > kuber-пакеты не маленькие > Время на загрузку-перезагрузку уходит приличное > > Зачем при > apt-get install podsec-k8s > ставить последнюю версию kuber, если далее (при обновлении со старых версий) > ее придется заменять на другую на многочисленных узлах кластера? > Это только вызовет раздражение у клиента и ничего более... > > Я смысла не вижу... Тем более при установке последней версии при apt-get install podsec-k8s могут установиться файлы конфигурации которые не нужны в предыдущих версиях При установке предыдущих может возникнуть какие-то конфликты с ними Зачем себе и администратору создавать эти проблемы, которых могло бы не быть при последовательном обновлении с установленной у клиента версии, когда и других проблем достаточно? Чтобы мучались? :-)
(Ответ для Anton Farygin на комментарий #120) > И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в > коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 > > Заметил что весь вывод текста идёт на русском языке. > Это ошибка, весь вывод нужно делать по умолчанию на английском и в > зависимости от локали переводить на русский через gettext > > На мой взгляд ментор должен был рассказать про это при ревью кода. Причину я уже объяснял выше Если бы не успели к указанному сроку этого пакеты не было вообще - за ненадобностью Замечание принимаю Но исправление займет немало времени Сейчас вроде проблем с версии 1.1.8-alt3 для сертификации нет Надеюсь не будет и на дало будет удалять временно таск из сизифа
(In reply to ALexey Kostarev from comment #122) > По моему уже пошла вкусовщина :-) > При разворачивании kuber часто необходимо бывает установить > не последнюю минорную версию > Это необходимо как при тестировании, так и при разворачивании у клиента > Дело в том, что kuber разрешает только последовательные обновления > То есть, если у клиента стоял kuber-1.26, то он должен последовательно > обновиться > 1.26 -> 1.27 -> 1.28 -> 1.29 -> 1.30 -> 1.31 > > Это решается путем установки переменной среды U7S_KUBEVERSION > > В этой ситуации произойдет двойная загрузка kuber-пакетов > - последней при apt-get install > - указанной при kubeadm init/join на каждом из 6-ти шагов перечесленных выше > на каждом из многочисленных узлов кластера (десятки, сотни) > > kuber-пакеты не маленькие > Время на загрузку-перезагрузку уходит приличное > > Зачем при > apt-get install podsec-k8s > ставить последнюю версию kuber, если далее (при обновлении со старых версий) > ее придется заменять на другую на многочисленных узлах кластера? > Это только вызовет раздражение у клиента и ничего более... > > Я смысла не вижу... Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и не надо будет чистить зависимости.
> Тем более при установке последней версии при > apt-get install podsec-k8s > могут установиться файлы конфигурации которые не нужны в предыдущих версиях > При установке предыдущих может возникнуть какие-то конфликты с ними > Зачем себе и администратору создавать эти проблемы, которых могло бы не быть > при последовательном обновлении с установленной у клиента версии, когда и > других проблем достаточно? > > Чтобы мучались? :-) Да и последний как мне кажется неоспоримый аргумент Если у клиента стоит kuber 1.26 - 1.29, а он при обновлении автоматически по зависимостям поставит 1.31 (перескок как минимум через 1.30), то данный узел кластера гарантированно ляжет и вряд ли его можно будет после этого вернуть в кластер Только путем полной переустановки системы И то же факт
(In reply to ALexey Kostarev from comment #126) > > Тем более при установке последней версии при > > apt-get install podsec-k8s > > могут установиться файлы конфигурации которые не нужны в предыдущих версиях > > При установке предыдущих может возникнуть какие-то конфликты с ними > > Зачем себе и администратору создавать эти проблемы, которых могло бы не быть > > при последовательном обновлении с установленной у клиента версии, когда и > > других проблем достаточно? > > > > Чтобы мучались? :-) > Да и последний как мне кажется неоспоримый аргумент > > Если у клиента стоит kuber 1.26 - 1.29, а он при обновлении автоматически по > зависимостям поставит 1.31 (перескок как минимум через 1.30), то данный > узел кластера гарантированно ляжет и вряд ли его можно будет после этого > вернуть в кластер > > Только путем полной переустановки системы > И то же факт Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm притащит самый свежий kubernetes при наличии одинаковых provides ?
(Ответ для Anton Farygin на комментарий #125) > > > > Я смысла не вижу... > > Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и > не надо будет чистить зависимости. Нет конечно вариант для того, чтобы майнтейнер на заметил :-) Но не совсем понятно зачем запрещать использовать какие то rpm-spec-операторы которые вроде как предназначены для решения возникающих проблем Подумаю...
(Ответ для Anton Farygin на комментарий #127) > Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm > притащит самый свежий kubernetes при наличии одинаковых provides ? Ну пока притаскивал самый свежий Но проблеме не в том, чтобы притащить свежий Проблема в том, чтобы вообще не притаскивал
Ну наверное потому что эти макросы бьют из пушки и прячут все зависимости на данные бинарники
(In reply to ALexey Kostarev from comment #129) > (Ответ для Anton Farygin на комментарий #127) > > > Откуда информация о том, что наличие зависимости на /usr/bin/kubeadm > > притащит самый свежий kubernetes при наличии одинаковых provides ? > > Ну пока притаскивал самый свежий > Но проблеме не в том, чтобы притащить свежий > Проблема в том, чтобы вообще не притаскивал Самый свежий притаскивает только тогда, когда ничего другого не установлено.
(Ответ для ALexey Kostarev на комментарий #128) > (Ответ для Anton Farygin на комментарий #125) > > > > > > > Я смысла не вижу... > > > > Да вообще без проблем. В коде замаскируйте вызов утилит через переменную и > > не надо будет чистить зависимости. > Нет конечно вариант для того, чтобы майнтейнер на заметил :-) > > Но не совсем понятно зачем запрещать использовать какие то > rpm-spec-операторы которые вроде как предназначены для решения возникающих > проблем > > Подумаю... В замене переменной есть думаю ньюанс Алгоритм по которому hasher добавляет зависимости по контексу исходного кода мне неизвестен и нет никакой гарантии, что hasher вытащит зависимость из значениея переменной В общем на эти эксперементы может уйти куча времени и в итоге напороться на замечания другого майнтейнера нафига такие выкрутасы реализованы. Как то у меня ослабленная мотивация на реализацию этого подхода...
Нет нюансов. Посоветуйтесь с вашим ментором.
(Ответ для Anton Farygin на комментарий #133) > Нет нюансов. Посоветуйтесь с вашим ментором. Если мне не изменят память именно Алексей Шабалин предложил этот ( %filter_from_requires) выход из возникшей ситуации OK Внимательно еще раз продумаю Тем более пока мы еще не отлаживали и не документировали механизм upgrade с версии на версию По итогам примем решение...
(Ответ для Anton Farygin на комментарий #120) > И ещё я очень не хочу заглядывать внутрь скриптов, но просто мимо проходя в > коммите dbeb9ca9b8cfb4fcd20005fbf7dff9d0048e6d74 > > Заметил что весь вывод текста идёт на русском языке. > Это ошибка, весь вывод нужно делать по умолчанию на английском и в > зависимости от локали переводить на русский через gettext > Доброе утро https://git.altlinux.org/tasks/358357/ Локализовал скрипты Добавил зависимости от kubernetes-пакетов
В последнем коммите Makefile случайно попал, его надо в отдельный (или в предыдущие) перенести.
(Ответ для Anton Farygin на комментарий #136) > В последнем коммите Makefile случайно попал, его надо в отдельный (или в > предыдущие) перенести. https://git.altlinux.org/tasks/358357/ DONE
Ещё заметил (раньше на это не посмотрел) - локализованные man страницы должны лежать в другом каталоге. А у вас все страницы на русском языке. Надо: 1) добавить man на английском 2) переложить страницы на русском в другой каталог Если сложно писать страницы на английском, то можно просто переложить существующие в другой каталог.
(Ответ для Anton Farygin на комментарий #138) > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > должны лежать в другом каталоге. > > А у вас все страницы на русском языке. Надо: > 1) добавить man на английском > 2) переложить страницы на русском в другой каталог > > Если сложно писать страницы на английском, то можно просто переложить > существующие в другой каталог. Постараюсь первести Доводить до ума, так доводить Вопрос Я формирую man'ы из MD-файлов Напр https://git.altlinux.org/people/kaf/packages/?p=podsec.git;a=blob;f=podsec/md/podsec-create-imagemakeruser.md;h=6708c8a47fa651aaecb19cedb07a7094c129c00c;hb=HEAD конвертируя с помощью ronn в man'ы Перевод я тоже буду делать в в MD-фйалах Есть ли смысл включить MD-файлы в rpm-пакеты и если да где их размещать в файловой системе?
если MD файлы исходники, то зачем ? Но лучше с ментором обсудить.
Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь использование тэгов Requires ещё обсудите. Что рецензент может не заметить, так это использование команды rm в спеке. Не знаю записано у нас это где-то или нет, но лучше вместо флага -f использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления из спеков. К тому же с флагом -v и лог сборки становится более информативным.
(Ответ для Anton Farygin на комментарий #138) > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > должны лежать в другом каталоге. > Доброе утро > Если сложно писать страницы на английском, то можно просто переложить > существующие в другой каталог. После вытаскивая текста комитов за полтора года из git, перевода их на английский и приведения к стандартному виду перевод man'ов на английский существенно более простая задача :-) > А у вас все страницы на русском языке. Надо: > 1) добавить man на английском > 2) переложить страницы на русском в другой каталог > Сделано https://git.altlinux.org/tasks/358357/ Так как podsec прошел довольно глубокую локализацию, изменения прав доступа к файлам и потребует довольно глубокого тестирования на предмет наличия регрессий, то решил перейти на новую минорную версию 1.2
(Ответ для Grigory Ustinov на комментарий #141) > Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь > использование тэгов Requires ещё обсудите. > > Что рецензент может не заметить, так это использование команды rm в спеке. > Не знаю записано у нас это где-то или нет, но лучше вместо флага -f > использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления > из спеков. К тому же с флагом -v и лог сборки становится более информативным. Доброе утро Спасибо Флаг добавил...
(In reply to ALexey Kostarev from comment #142) > (Ответ для Anton Farygin на комментарий #138) > > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > > должны лежать в другом каталоге. > > > > Доброе утро > > Если сложно писать страницы на английском, то можно просто переложить > > существующие в другой каталог. > После вытаскивая текста комитов за полтора года из git, > перевода их на английский и приведения к стандартному виду > перевод man'ов на английский существенно более простая задача :-) > > > А у вас все страницы на русском языке. Надо: > > 1) добавить man на английском > > 2) переложить страницы на русском в другой каталог > > > Сделано > https://git.altlinux.org/tasks/358357/ > > Так как podsec прошел довольно глубокую локализацию, изменения прав доступа > к файлам и потребует довольно глубокого тестирования на предмет наличия > регрессий, то решил перейти на новую минорную версию 1.2 Спасибо. Выглядит неплохо.
(In reply to Grigory Ustinov from comment #141) > Я мельком глянул, что тут происходит, рецензент рецензирует хорошо, надеюсь > использование тэгов Requires ещё обсудите. > > Что рецензент может не заметить, так это использование команды rm в спеке. > Не знаю записано у нас это где-то или нет, но лучше вместо флага -f > использовать флаг -v. Я в своей практике утомился вычищать мусорные удаления > из спеков. К тому же с флагом -v и лог сборки становится более информативным. Да, у нас нет нигде правил написания удаления. Это просто совет от более опытного ментейнера. Наверное его стоит где-то зафиксировать на www.altlinux.org Что касается зависимостей - я сразу заметил перегруженность по requires, но пока не задавался вопросом - зачем. Предлагаю начать с полного удаления всех зависимостей из requires, за исключением проверенных и межпакетных. Например, Requires: sh - явно не нужен, у нас автопоиск зависимостей отлично находит sh. И т.д. - в спекфайле нужно оставить только те зависимости, которые автоматический поиск не нашёл. Привязка к версиям тоже выглядит довольно странно - например nginx указан Requires: nginx >= 1.22.1 но я уверен что с более младшими версиями nginx проблем не будет.
(In reply to Anton Farygin from comment #144) > (In reply to ALexey Kostarev from comment #142) > > (Ответ для Anton Farygin на комментарий #138) > > > Ещё заметил (раньше на это не посмотрел) - локализованные man страницы > > > должны лежать в другом каталоге. > > > > > > > Доброе утро > > > Если сложно писать страницы на английском, то можно просто переложить > > > существующие в другой каталог. > > После вытаскивая текста комитов за полтора года из git, > > перевода их на английский и приведения к стандартному виду > > перевод man'ов на английский существенно более простая задача :-) > > > > > А у вас все страницы на русском языке. Надо: > > > 1) добавить man на английском > > > 2) переложить страницы на русском в другой каталог > > > > > Сделано > > https://git.altlinux.org/tasks/358357/ > > > > Так как podsec прошел довольно глубокую локализацию, изменения прав доступа > > к файлам и потребует довольно глубокого тестирования на предмет наличия > > регрессий, то решил перейти на новую минорную версию 1.2 > > Спасибо. Выглядит неплохо. Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во время сборки пакета (в Makefile, например), а из дерева сгенерённые man убрать.
> > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > убрать. https://git.altlinux.org/tasks/358357/ Удалили из дерева man-файлы Перенес генерацию из md-файлов в Makefile Так как нового функционала не добавилось, то решил не увеличивать Release увеличив Version до alt2
(In reply to ALexey Kostarev from comment #147) > > > > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > > убрать. > https://git.altlinux.org/tasks/358357/ > Удалили из дерева man-файлы > Перенес генерацию из md-файлов в Makefile > > Так как нового функционала не добавилось, то решил не увеличивать > Release > увеличив > Version > до alt2 Только наоборот. Надо было увеличить Version до 1.2.1 а release оставить alt1
Ещё раз повторю правило версионирования и рекомендую прямо записать его в README проекта: при изменении исходного кода - увеличиваем version при изменении только specfile - увеличиваем release Поменялся код и спек - увеличиваем version и сбрасываем release на alt1 поменялся только спек - увеличиваем release на 1
(Ответ для Anton Farygin на комментарий #148) > (In reply to ALexey Kostarev from comment #147) > > > > > > Но если уж делать совсем хорошо, то генерацию man страниц стоит сделать во > > > время сборки пакета (в Makefile, например), а из дерева сгенерённые man > > > убрать. > > https://git.altlinux.org/tasks/358357/ > > Удалили из дерева man-файлы > > Перенес генерацию из md-файлов в Makefile > > > > Так как нового функционала не добавилось, то решил не увеличивать > > Release > > увеличив > > Version > > до alt2 > > Только наоборот. Надо было увеличить Version до 1.2.1 а release оставить alt1 https://git.altlinux.org/tasks/358357/ Сейчас снова необходимо внести изменения в ветку платформы c10f2 (обнаружены баги) Я попросил у Дениса Медведева инструкцию как это сделать в текущей ситуации (ветки к сожалению расходятся), но пока пока ответа не получил Как потом сливать ветки (через git rebase?) тоже вопрос Так что немного "подвешен" в текущей ситуации
Не вижу изменений с Requires.
(Ответ для Anton Farygin на комментарий #151) > Не вижу изменений с Requires. Как это? https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec.spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 Requires: kubernetes-kubeadm Requires: kubernetes-client Requires: kubernetes-kubelet
(In reply to ALexey Kostarev from comment #152) > (Ответ для Anton Farygin на комментарий #151) > > Не вижу изменений с Requires. > > Как это? > https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec. > spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 > Requires: kubernetes-kubeadm > Requires: kubernetes-client > Requires: kubernetes-kubelet из 145 комментария в этом issue
(Ответ для Anton Farygin на комментарий #153) > (In reply to ALexey Kostarev from comment #152) > > (Ответ для Anton Farygin на комментарий #151) > > > Не вижу изменений с Requires. > > > > Как это? > > https://git.altlinux.org/tasks/358357/gears/4100/git?p=git;a=blob;f=podsec. > > spec;h=b7eeb12c72a7a481a56107ea21406f3b38201746;hb=HEAD#l60 > > Requires: kubernetes-kubeadm > > Requires: kubernetes-client > > Requires: kubernetes-kubelet > > из 145 комментария в этом issue OK Тут есть вопрос При автоматическом поиске вставляется зависимость от последний версий пакетов что по мне не есть хорошо Я бы оставил зависимости с ограниченими версий package>=version и >= %EVR
при автоматичкеском поиске версии вообще никакие не проставляются. обсудите это, пожалуйста, со своим ментором.
(Ответ для Anton Farygin на комментарий #155) > при автоматичкеском поиске версии вообще никакие не проставляются. > обсудите это, пожалуйста, со своим ментором. https://git.altlinux.org/tasks/358357/ Убрал Requires без указания версий Алексей Шабалин сейчас на встрече - оперативно ответить не может Договорились, что в выходные примет окончательное решение Но чтобы процесс не простаивал выложу пока этот вариант
https://git.altlinux.org/tasks/358357/gears/4200/git?p=git;a=commitdiff;h=b217cba37bf65a7713cce41f7de5bd27388fed17 тут ошибка в содержимом коммита
там вообще в коммитах ошибки. Как приведёте в порядок - напишите.
(Ответ для Anton Farygin на комментарий #155) > при автоматичкеском поиске версии вообще никакие не проставляются. > обсудите это, пожалуйста, со своим ментором. Обсудили вчера с Алексеем Шабалиным 1. За счет добавления defattr упорядочил каталоги и файлы с разными правами доступа 2. Оставил только те Requires, которые не добавляются при автоматическом сканировании зависимостей https://git.altlinux.org/tasks/358357/
(In reply to ALexey Kostarev from comment #159) > (Ответ для Anton Farygin на комментарий #155) > > при автоматичкеском поиске версии вообще никакие не проставляются. > > обсудите это, пожалуйста, со своим ментором. > > Обсудили вчера с Алексеем Шабалиным > > 1. За счет добавления > defattr > упорядочил каталоги и файлы с разными правами доступа > > 2. Оставил только те Requires, которые не добавляются при автоматическом > сканировании зависимостей > > https://git.altlinux.org/tasks/358357/ Всё очень неплохо, надо только убрать лишнюю пустую строчку в changelog в последнем коммите (переписав сам коммит) и можно будет коммитить в репозиторий.
(Ответ для ALexey Kostarev на комментарий #159) > (Ответ для Anton Farygin на комментарий #155) > > при автоматичкеском поиске версии вообще никакие не проставляются. > > обсудите это, пожалуйста, со своим ментором. > > Обсудили вчера с Алексеем Шабалиным > > 1. За счет добавления > defattr > упорядочил каталоги и файлы с разными правами доступа > > 2. Оставил только те Requires, которые не добавляются при автоматическом > сканировании зависимостей > > https://git.altlinux.org/tasks/358357/ Добрый день Поправил
Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки.
(Ответ для Anton Farygin на комментарий #162) > Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки. Спасибо Отличный подарок на мой день рождения!
(Ответ для ALexey Kostarev на комментарий #163) > (Ответ для Anton Farygin на комментарий #162) > > Заапрувил, спасибо. Можно коммитить и отправлять в стабильные ветки. > > Спасибо > Отличный подарок на мой день рождения! Добрый день коллеги podsec 1.2.2-alt1 дошел до sisyphus https://packages.altlinux.org/ru/sisyphus/srpms/podsec/ Теперь у меня вопрос по Чернышевскому "Что делать?" (дальще) Какой мой текущий статус? Какие еще телодвижения с моей стороны требуются для завершения JOIN? Мне бы довести до sisyphus пакеты - flux2 - https://git.altlinux.org/people/kaf/packages/?p=flux2.git;a=summary https://git.altlinux.org/tasks/355139/logs/events.2.1.log - podman-compose-to-kube - https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=summary По последнему буквально вчера появился запрос со стороны Чернобривченко Елена Васильевна (chernobrivchenkoev@basealt.ru) Также судя по всему согласно последним разговорам появится необходимость портировать в ALT kompose - https://github.com/kubernetes/kompose
Все хотел написать раньше, но что-то останавливало :) Алексей, не надо из багзилы устаивать чатик. Не надо тут писать что кто-то недоступен, в командировке, на встрече, и т.п. Никому это не интересно. Не надо указывать какие-то другие производственные причины и требование. Не важно где Вы работаете. Join про другое. Давайте тут описывать и рассматривать исключительно технические вопросы. По делу. В каком виде отправлять в стабильные бранчи пакет podsec, решать исключительно Вам. Будете ли вы сопровождать несколько веток в git или нет, тоже решать Вам. Если текущую версию из сизифа можно один-в-один отправить в стабильные бранчи, то сделайте такое задание. Обойти наследование истории я подскажу как.
И еще, отправка пакетов в стабильные бранчи, никак не касается процедуры Join.
Что касается завершения JOIN - мы исправили (с большим трудом, на мой взгляд) один пакет. Я вижу колоссальную недоработку со стороны ментора и это надо исправлять. https://git.altlinux.org/people/kaf/packages/?p=flux2.git;a=blob;f=flux2.spec;h=8423dd64e86eecc3dec00670afa8f94e9e9b5289;hb=ec48bb36e33f1a935c09bb30bbe647ec63a6c6fd Вот тут: 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем переезжать на другую апстримную ветку 2) первая запись в changelog рекомендуется другая 3) не включены тесты
https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=commitdiff;h=3e7fce88c4699be46ea1a4bed14de70411420b42 - тут опять содержимое изменений не полностью соответствует тексту в message
https://git.altlinux.org/people/kaf/packages/?p=podman-compose-to-kube.git;a=commitdiff;h=4c918dc8fb28c5d9ae62aac22ab48344547022f7 тут тоже самое, плюс тарболл лучше делать из апстримного тэга и прикладывать альтовый патч, что бы было явно видно ваши изменения.
(In reply to Anton Farygin from comment #167) > Вот тут: > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > переезжать на другую апстримную ветку Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. Это абсолютно не важно при сборке этого пакета. > 2) первая запись в changelog рекомендуется другая Согласен. И тоже устал на это указывать. > 3) не включены тесты И не должны. Они для работы требуют выхода в Интернет.
Доброе утро! (Ответ для Alexey Shabalin на комментарий #170) > (In reply to Anton Farygin from comment #167) > > > Вот тут: > > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > > переезжать на другую апстримную ветку > > Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. > Это абсолютно не важно при сборке этого пакета. Я к этому моменту уже перенес Так что в этом пакете оставлю его в .gear/flux2.spec Конфликт, насколько я помню, у меня был тогда, когда я работал с пакетом patroni и в нем уже был в корне файл patroni.spec, принадлежащий самому проекту patroni В состав flux2 входят еще 6-ть пакетов-контроллеров - см https://git.altlinux.org/tasks/355139/ Тут как скажете Но, думаю, после Approve пакета flux2, чтобы удовлетворить самые строгие требования перенесу в них файлы *.spec в .gear > > > 2) первая запись в changelog рекомендуется другая > > Согласен. И тоже устал на это указывать. Этот chanhelog был сделан еще ДО подробной работа с пакетами podsec Посмотрите https://git.altlinux.org/tasks/361134/ Все ли я учел
(In reply to ALexey Kostarev from comment #171) > Доброе утро! > > (Ответ для Alexey Shabalin на комментарий #170) > > (In reply to Anton Farygin from comment #167) > > > > > Вот тут: > > > 1) spec файл лучше перенести в .gear - так будет проще в дальнейшем > > > переезжать на другую апстримную ветку > > > > Нет, не лучше. Пусть остается в корне. Но давай об этом не будем спорить. > > Это абсолютно не важно при сборке этого пакета. > Я к этому моменту уже перенес > Так что в этом пакете оставлю его в .gear/flux2.spec > Конфликт, насколько я помню, у меня был тогда, когда я работал с пакетом > patroni > и в нем уже был в корне файл patroni.spec, принадлежащий самому проекту > patroni Спасибо. В дальнейшем тоже лучше размещать в .gear, это облегчает переезд с ветки на ветку - достаточно перетащить содержимое .gear что бы перетащить всё, имеющее отношение к altlinux > > В состав flux2 входят еще 6-ть пакетов-контроллеров - см > https://git.altlinux.org/tasks/355139/ > > Тут как скажете > Но, думаю, после Approve пакета flux2, > чтобы удовлетворить самые строгие требования перенесу в них файлы *.spec в > .gear Да, лучше сразу сделать. Необходимость размещения всего, что имеет отношение к альту в .gear выработалась годами. > > > > > > 2) первая запись в changelog рекомендуется другая > > > > Согласен. И тоже устал на это указывать. > Этот chanhelog был сделан еще ДО подробной работа с пакетами podsec > Посмотрите > https://git.altlinux.org/tasks/361134/ > Все ли я учел Точки в %changelog пакета указаны не во всех записях. Остальное всё нормально.
(Ответ для Anton Farygin на комментарий #172) ... > Точки в %changelog пакета указаны не во всех записях. > Остальное всё нормально. Исправил https://git.altlinux.org/tasks/361134/
(In reply to ALexey Kostarev from comment #173) > (Ответ для Anton Farygin на комментарий #172) > ... > > Точки в %changelog пакета указаны не во всех записях. > > Остальное всё нормально. > Исправил > https://git.altlinux.org/tasks/361134/ task not found
(Ответ для Anton Farygin на комментарий #174) > (In reply to ALexey Kostarev from comment #173) > > (Ответ для Anton Farygin на комментарий #172) > > ... > > > Точки в %changelog пакета указаны не во всех записях. > > > Остальное всё нормально. > > Исправил > > https://git.altlinux.org/tasks/361134/ > > task not found Добрый день Я сейчас пересобираю все 8 пакетов входящих в flux2 https://git.altlinux.org/tasks/361226/ Есть еще недоработки - пустые строки в конце changelog Сегодня как только исправлю - сообщу
(Ответ для Anton Farygin на комментарий #174) > (In reply to ALexey Kostarev from comment #173) > > (Ответ для Anton Farygin на комментарий #172) > > ... > > > Точки в %changelog пакета указаны не во всех записях. > > > Остальное всё нормально. > > Исправил > > https://git.altlinux.org/tasks/361134/ > > task not found Собрал до уровня EPERM набор пакетов для flux2 https://git.altlinux.org/tasks/361256/ flux2, kustomize - команды HOST-системы остальные используются для сборки соответствующих docker-образов См. мою документацию на Вики https://www.altlinux.org/Flux2
+%changelog +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 +- Initial build. +- Added vendor modules. А Added vendor modules зачем в changelog ? разве без них можно собрать ?
(Ответ для Anton Farygin на комментарий #177) > +%changelog > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > +- Initial build. > +- Added vendor modules. > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? Как я понял мы вроде как в changelog включаем текст основных промежуточных комитов Я исходил из этого принципа Если для 1-го changlog это не работает, то удалю
(Ответ для ALexey Kostarev на комментарий #178) > Как я понял > мы вроде как в changelog включаем текст основных промежуточных комитов > Я исходил из этого принципа Коммиты для разработчиков, ченджлог больше для людей. Это то куда смотрит "пользователь" в первую очередь. То есть в первую очередь в ченджлоге пишется что-то значимое для пользователя. Обновили, убрали сервис, добавили десктоп-файл и прочее. Если ничего значимого не произошло, например отрефакторили спек, то приходится писать это, чтобы пользователь обновив пакет не ломал голову над тем, почему пакет обновился, а функционал нет. Общая логика такая.
(Ответ для Anton Farygin на комментарий #177) > +%changelog > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > +- Initial build. > +- Added vendor modules. > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? Исправлено https://git.altlinux.org/tasks/361320/
Пустая строка вставлена не в том месте (две в одном, ноль в другом) +BuildRequires: /proc + + +%description +This controller automates updates to YAML +when new container images are available. +%prep +%setup
(In reply to ALexey Kostarev from comment #180) > (Ответ для Anton Farygin на комментарий #177) > > +%changelog > > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > > +- Initial build. > > +- Added vendor modules. > > > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? > Исправлено > https://git.altlinux.org/tasks/361320/ А почему задание сборочное изменилось ? я про номер.
(Ответ для Anton Farygin на комментарий #182) > (In reply to ALexey Kostarev from comment #180) > > (Ответ для Anton Farygin на комментарий #177) > > > +%changelog > > > +* Thu Oct 31 2024 Alexey Kostarev <kaf@altlinux.org> 1.0.1-alt1 > > > +- Initial build. > > > +- Added vendor modules. > > > > > > А Added vendor modules зачем в changelog ? разве без них можно собрать ? > > Исправлено > > https://git.altlinux.org/tasks/361320/ > > А почему задание сборочное изменилось ? я про номер. Надо было удалять все 8-м subtask'ов в текущем, добавлять новые Я посчитал что проще удалить текущую и создать новую задачу Вот если бы дело касалось исправление отдельного subtask'а, тогда имеет смысл оставлять остальные Или это принципиально - оставлять task?
(Ответ для Anton Farygin на комментарий #181) > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > +BuildRequires: /proc > + > + > +%description > +This controller automates updates to YAML > +when new container images are available. > +%prep > +%setup Исправлено https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4;hb=HEAD#l18 Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) А есть ли у нас linter для проверки корректности spec-файла? Или каждый сам кузнец своего счастья? Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует Похоже надо писать шаблон на этот случай. Никто у нас этим не занимался? Номер задачи не сменил - удалил текущую подзадачу и добавил новые. Правда так как в ssh gyle task run ... нет возможности указать подзадачу, выигрыша нет Приходиться собирать все и тратить все то же свое и процессорное время :-(
(In reply to ALexey Kostarev from comment #184) > (Ответ для Anton Farygin на комментарий #181) > > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > > > +BuildRequires: /proc > > + > > + > > +%description > > +This controller automates updates to YAML > > +when new container images are available. > > +%prep > > +%setup > > Исправлено > https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/ > image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4; > hb=HEAD#l18 > > Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) > > А есть ли у нас linter для проверки корректности spec-файла? > Или каждый сам кузнец своего счастья? > Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует > Похоже надо писать шаблон на этот случай. > Никто у нас этим не занимался? > > Номер задачи не сменил - удалил текущую подзадачу и добавил новые. > Правда так как в > ssh gyle task run ... > нет возможности указать подзадачу, выигрыша нет > Приходиться собирать все и тратить все то же свое и процессорное время :-( А не надо удалять все подзадания. Можно же удалить одно и добавить тоже одно в нужное место task'а.
20 %description 21 This controller automates updates to YAML 22 when new container images are available. 23 %prep 24 %setup Всё равно сливается.
(Ответ для Anton Farygin на комментарий #185) > (In reply to ALexey Kostarev from comment #184) > > (Ответ для Anton Farygin на комментарий #181) > > > Пустая строка вставлена не в том месте (две в одном, ноль в другом) > > > > > > +BuildRequires: /proc > > > + > > > + > > > +%description > > > +This controller automates updates to YAML > > > +when new container images are available. > > > +%prep > > > +%setup > > > > Исправлено > > https://git.altlinux.org/tasks/361320/gears/1100/git?p=git;a=blob;f=.gear/ > > image-automation-controller.spec;h=6b8d65e627dab8d032ad1f759f24bb049c1e15c4; > > hb=HEAD#l18 > > > > Рискую нарваться на замечания Алексея Шабалина, но все же спрошу :-) > > > > А есть ли у нас linter для проверки корректности spec-файла? > > Или каждый сам кузнец своего счастья? > > Нашел rpmlint, но он на наличие нескольких пустых строк не реагирует > > Похоже надо писать шаблон на этот случай. > > Никто у нас этим не занимался? > > > > Номер задачи не сменил - удалил текущую подзадачу и добавил новые. > > Правда так как в > > ssh gyle task run ... > > нет возможности указать подзадачу, выигрыша нет > > Приходиться собирать все и тратить все то же свое и процессорное время :-( > > А не надо удалять все подзадания. Можно же удалить одно и добавить тоже одно > в нужное место task'а. Так я в этом случае я и не удалял все, а удалил второе и добавил в конец В следующий раз добавлю по месту, но сдается мне, что gyle run все одно будет все пакеты пересобирать Проверю
конечно будет все пересобирать, но отслеживать состояние таких заданий гораздо удобнее. К тому же я аппрувлю и дизаппрувлю подзадания, которые прошли или не прошли проверку.
(Ответ для Anton Farygin на комментарий #188) > конечно будет все пересобирать, но отслеживать состояние таких заданий > гораздо удобнее. > > К тому же я аппрувлю и дизаппрувлю подзадания, которые прошли или не прошли > проверку. Исправлено https://git.altlinux.org/tasks/361320/ subtask'и оставил на месте Для уже прошедших до этого сборку вижу, что взяты из кэшей 2024-Nov-02 09:35:05 :: [x86_64] #300 image-reflector-controller.git 0.32.0-alt1: build OK (cached) ... https://git.altlinux.org/tasks/361320/logs/events.4.1.log Так что да - стоит придерживаться этой схемы Спасибо
в пакете flux https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/3136990227885862690 не включены тесты.
https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/3136994127366774890 Замена %RELEASE% на %release выглядит как ошибка.
https://git.altlinux.org/tasks/361320/gears/1200/git?p=git;a=tree;f=.gear;h=e73556b8d33fcdda1389d1a3bebfcb2c7df32838;hb=7557b7d8b21c10d7633cbaf93d00b7e7f6b8aa3d В этом пакете specfile лучше назвать одноимённо с именем пакета, так просто чуть чуть удобнее.
(Ответ для Anton Farygin на комментарий #190) > в пакете flux > https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/ > 3136990227885862690 > > не включены тесты. Добрый день Алексей Шабалин выше прокомментировал же это замечание https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c170 > > 3) не включены тесты > И не должны. Они для работы требуют выхода в Интернет.
(In reply to ALexey Kostarev from comment #193) > (Ответ для Anton Farygin на комментарий #190) > > в пакете flux > > https://packages.altlinux.org/ru/sisyphus/srpms/flux2/specfiles/ > > 3136990227885862690 > > > > не включены тесты. > > Добрый день > > Алексей Шабалин выше прокомментировал же это замечание > https://bugzilla.altlinux.org/show_bug.cgi?id=39627#c170 > > > > 3) не включены тесты > > > И не должны. Они для работы требуют выхода в Интернет. ok.
(Ответ для Anton Farygin на комментарий #191) > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > 3136994127366774890 > > Замена %RELEASE% на %release выглядит как ошибка. Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go;h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 GitCommit: "unknown", Из за этого в бинарном коде возвращает при вызове kustomize version возвращает unknown Я в add-alt-release-to-GitConfig.patch https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt-release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD заменяю на GitCommit: "%RELEASE%", А затем в SPEC на текущую версию kustomize
(Ответ для ALexey Kostarev на комментарий #195) > (Ответ для Anton Farygin на комментарий #191) > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > 3136994127366774890 > > > > Замена %RELEASE% на %release выглядит как ошибка. > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > GitCommit: "unknown", > > Из за этого в бинарном коде возвращает при вызове > kustomize version > возвращает > unknown > > Я в add-alt-release-to-GitConfig.patch > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > заменяю на > GitCommit: "%RELEASE%", > > А затем в SPEC на текущую версию kustomize Сейчас уже точно не припомню (было почти полгода назад), на замена unknown сразу на %release создавало проблемы
(In reply to ALexey Kostarev from comment #195) > (Ответ для Anton Farygin на комментарий #191) > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > 3136994127366774890 > > > > Замена %RELEASE% на %release выглядит как ошибка. > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > GitCommit: "unknown", > > Из за этого в бинарном коде возвращает при вызове > kustomize version > возвращает > unknown > > Я в add-alt-release-to-GitConfig.patch > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > заменяю на > GitCommit: "%RELEASE%", > > А затем в SPEC на текущую версию kustomize В этом месте должен быть sha1 git commit'а.
(Ответ для Anton Farygin на комментарий #197) > (In reply to ALexey Kostarev from comment #195) > > (Ответ для Anton Farygin на комментарий #191) > > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > > 3136994127366774890 > > > > > > Замена %RELEASE% на %release выглядит как ошибка. > > > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > > > GitCommit: "unknown", > > > > Из за этого в бинарном коде возвращает при вызове > > kustomize version > > возвращает > > unknown > > > > Я в add-alt-release-to-GitConfig.patch > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > > заменяю на > > GitCommit: "%RELEASE%", > > > > А затем в SPEC на текущую версию kustomize > > В этом месте должен быть sha1 git commit'а. Можно поподробнее в каком месте и какого комита?
подробности если не понятны то лучше уточнить в апстриме.
(Ответ для Anton Farygin на комментарий #192) > https://git.altlinux.org/tasks/361320/gears/1200/git?p=git;a=tree;f=.gear; > h=e73556b8d33fcdda1389d1a3bebfcb2c7df32838; > hb=7557b7d8b21c10d7633cbaf93d00b7e7f6b8aa3d > > В этом пакете specfile лучше назвать одноимённо с именем пакета, так просто > чуть чуть удобнее. Да я могу и потерпеть Менять придется во всех -controller пакетах В имени этих пакетов добавлен префикс flux2- , чтобы они случайно не пересеклись с названиями других пакетов Например пакет notification-controller может быть в составе и других систем По договоренности с Алексеем Шабалиным был добавлен этот префикс А имя speс-файла не является глобальным Оно должно быть уникальным только в рамках каталога .gear Пакеты flux2*-controller не применяется вне пакета flux2 Все они собираются в отдельные docker-образы и используются только в составе docker-образов Так что я не вижу смысла менять имя спек-файла
(Ответ для Anton Farygin на комментарий #197) > (In reply to ALexey Kostarev from comment #195) > > (Ответ для Anton Farygin на комментарий #191) > > > https://packages.altlinux.org/ru/sisyphus/srpms/kustomize/specfiles/ > > > 3136994127366774890 > > > > > > Замена %RELEASE% на %release выглядит как ошибка. > > > > Эта ошибка в модуле vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob; > > f=kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go; > > h=c637ac2e1ac09baa3915905c2196c52e649757f5;hb=HEAD#l50 > > > > GitCommit: "unknown", > > > > Из за этого в бинарном коде возвращает при вызове > > kustomize version > > возвращает > > unknown > > > > Я в add-alt-release-to-GitConfig.patch > > https://git.altlinux.org/tasks/361320/gears/1000/git?p=git;a=blob;f=add-alt- > > release-to-GitConfig.patch;h=e9af1c5ae24a3b7df76726cca0ee4d0d8c231c60;hb=HEAD > > заменяю на > > GitCommit: "%RELEASE%", > > > > А затем в SPEC на текущую версию kustomize > > В этом месте должен быть sha1 git commit'а. Доброе утро https://git.altlinux.org/tasks/361320/ 1170 kustomize.git 5.4.2-alt1 Прошу прощения затупил Долго не мог понять о каком месте идет речь :-) + пытался избежать patch'а файла kustomize/vendor/sigs.k8s.io/kustomize/api/provenance/provenance.go пытаюсь передать значение комита (vcs.revision=%commit) в переменную info, возвращаемую методом ReadBuildInfo() Сколько не копал Инет метод передачи найти не удалось :-( Так что остановился на добавление в provenance.go переменной gitCommit, передачей ей значения %commit при сборке и присвоение этого значения в Provenance.GitCommit Это будет работать как при сборке вне среды git, так и (как запрограммировано в исходном варианте) при сборке в среде git(github) при наличии элемента vcs.revision в возвращаемом значении функцией ReadBuildInfo()
ну и совсем по мелочи - опять потерялась точка в changelog. просьба быть внимательнее и смотреть свой спекфайл перед отправкой
(Ответ для Anton Farygin на комментарий #202) > ну и совсем по мелочи - опять потерялась точка в changelog. > > просьба быть внимательнее и смотреть свой спекфайл перед отправкой Речь про kustomize? https://git.altlinux.org/tasks/361320/gears/1170/git?p=git;a=blob;f=.gear/kustomize.spec;h=97306e7cb22c0f584a0a929b7527c4af83b43110;hb=HEAD %changelog * Sun Nov 10 2024 Alexey Kostarev <kaf@altlinux.org> 5.4.2-alt1 - Initial build. Специально смотрел, чтобы не пропустить точку при сборке Или речь о другом SPEC?
Всё хорошо, возможно я куда-то не туда посмотрел. Заапрувил задание. Патч с gitCommit напрашивается на отправку в upstream
