Rootless Docker получает writable HOME в runner-owned runtime каталоге; XDG_CONFIG_HOME/XDG_DATA_HOME настроены с учетом существующего дерева и systemd user manager.
Добавлена проверка прав записи до вызова setup tool; healthcheck использует те же XDG пути. Защищенный /var/lib/akyldash-runner остается root-owned 0711.
VPS не изменялся, установщик не запускался. Проверки CI и ревью ожидаются.
## Что изменено
- Rootless Docker получает writable HOME в runner-owned runtime каталоге; XDG_CONFIG_HOME/XDG_DATA_HOME настроены с учетом существующего дерева и systemd user manager.
- Добавлена проверка прав записи до вызова setup tool; healthcheck использует те же XDG пути. Защищенный /var/lib/akyldash-runner остается root-owned 0711.
- Обновлена документация; повторный запуск сохраняет существующий runner storage image.
## Проверки
- bash infra/runner/test-runner-config.sh
- bash infra/runner/test-install-runner-idempotency.sh
- bash infra/runner/test-install-runner-guard.sh
- bash -n для измененных shell файлов
VPS не изменялся, установщик не запускался. Проверки CI и ревью ожидаются.
P1 — Закрепить HOME и XDG пути в docker.service (install-runner.sh:217).
systemctl --user set-environment меняет окружение только запущенного user manager. После перезагрузки хоста linger запускает новый manager, а включённый docker.service уже не наследует эти значения. Его HOME снова будет /var/lib/akyldash-runner (root-owned, 0711), а XDG_CONFIG_HOME и XDG_DATA_HOME не будут совпадать с путями установщика и healthcheck. В результате rootless Docker после перезагрузки запускается в ином окружении; операции, которым нужна запись под HOME/XDG, могут завершиться ошибкой, а healthcheck с явно заданными переменными эту разницу не обнаружит.
Запишите три переменные в постоянный drop-in для ~/.config/systemd/user/docker.service ([Service] Environment=...) и проверьте эффективное окружение unit после старта нового user manager. Проверки из PR проходят, но не моделируют этот сценарий.
**P1 — Закрепить HOME и XDG пути в docker.service (install-runner.sh:217).**
`systemctl --user set-environment` меняет окружение только запущенного user manager. После перезагрузки хоста linger запускает новый manager, а включённый `docker.service` уже не наследует эти значения. Его `HOME` снова будет `/var/lib/akyldash-runner` (root-owned, 0711), а `XDG_CONFIG_HOME` и `XDG_DATA_HOME` не будут совпадать с путями установщика и healthcheck. В результате rootless Docker после перезагрузки запускается в ином окружении; операции, которым нужна запись под `HOME`/XDG, могут завершиться ошибкой, а healthcheck с явно заданными переменными эту разницу не обнаружит.
Запишите три переменные в постоянный drop-in для `~/.config/systemd/user/docker.service` (`[Service] Environment=...`) и проверьте эффективное окружение unit после старта нового user manager. Проверки из PR проходят, но не моделируют этот сценарий.
Предыдущее замечание о запуске после перезагрузки исправлено: HOME, XDG_CONFIG_HOME и XDG_DATA_HOME теперь заданы в постоянном drop-in для docker.service.
P2 — Применить новое окружение к уже работающему Docker при повторном запуске установщика (install-runner.sh:229–233). Если docker.service был запущен до появления environment.conf, daemon-reload обновит описание unit, но enable --now не перезапустит активный процесс. systemctl show ... --property=Environment вернёт новые значения из описания unit, поэтому проверка пройдёт, хотя работающий dockerd-rootless.sh продолжит использовать старый HOME/XDG до ручного перезапуска или reboot. Это существенный сценарий для установщика, который заявлен как безопасно повторяемый после частичной установки. Перезапускайте уже активный docker.service после изменения drop-in и проверяйте окружение фактического процесса (либо явно документируйте и обеспечьте остановку/запуск перед проверкой).
Локальные проверки test-runner-config.sh, test-install-runner-idempotency.sh, test-install-runner-guard.sh и bash -n проходят; сценарий с уже работающим Docker ими не покрыт.
Предыдущее замечание о запуске после перезагрузки исправлено: `HOME`, `XDG_CONFIG_HOME` и `XDG_DATA_HOME` теперь заданы в постоянном drop-in для `docker.service`.
**P2 — Применить новое окружение к уже работающему Docker при повторном запуске установщика (`install-runner.sh:229–233`).** Если `docker.service` был запущен до появления `environment.conf`, `daemon-reload` обновит описание unit, но `enable --now` не перезапустит активный процесс. `systemctl show ... --property=Environment` вернёт новые значения из описания unit, поэтому проверка пройдёт, хотя работающий `dockerd-rootless.sh` продолжит использовать старый `HOME`/XDG до ручного перезапуска или reboot. Это существенный сценарий для установщика, который заявлен как безопасно повторяемый после частичной установки. Перезапускайте уже активный `docker.service` после изменения drop-in и проверяйте окружение фактического процесса (либо явно документируйте и обеспечьте остановку/запуск перед проверкой).
Локальные проверки `test-runner-config.sh`, `test-install-runner-idempotency.sh`, `test-install-runner-guard.sh` и `bash -n` проходят; сценарий с уже работающим Docker ими не покрыт.
Предыдущие замечания исправлены. HOME/XDG пути сохранены в постоянном drop-in docker.service; при повторном запуске установщик перезапускает активный daemon и сверяет переменные окружения его процесса. Путь к user unit, окружение runner и healthcheck согласованы. Локально прошли три runner test-скрипта и bash -n изменённых shell-файлов. Запуск на VPS в рамках ревью не выполнялся.
Предыдущие замечания исправлены. HOME/XDG пути сохранены в постоянном drop-in `docker.service`; при повторном запуске установщик перезапускает активный daemon и сверяет переменные окружения его процесса. Путь к user unit, окружение runner и healthcheck согласованы. Локально прошли три runner test-скрипта и `bash -n` изменённых shell-файлов. Запуск на VPS в рамках ревью не выполнялся.
admin
merged commit ac611cc878 into main2026-10-14 14:45:57 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Что изменено
Проверки
VPS не изменялся, установщик не запускался. Проверки CI и ревью ожидаются.
P1 — Закрепить HOME и XDG пути в docker.service (install-runner.sh:217).
systemctl --user set-environmentменяет окружение только запущенного user manager. После перезагрузки хоста linger запускает новый manager, а включённыйdocker.serviceуже не наследует эти значения. ЕгоHOMEснова будет/var/lib/akyldash-runner(root-owned, 0711), аXDG_CONFIG_HOMEиXDG_DATA_HOMEне будут совпадать с путями установщика и healthcheck. В результате rootless Docker после перезагрузки запускается в ином окружении; операции, которым нужна запись подHOME/XDG, могут завершиться ошибкой, а healthcheck с явно заданными переменными эту разницу не обнаружит.Запишите три переменные в постоянный drop-in для
~/.config/systemd/user/docker.service([Service] Environment=...) и проверьте эффективное окружение unit после старта нового user manager. Проверки из PR проходят, но не моделируют этот сценарий.Предыдущее замечание о запуске после перезагрузки исправлено:
HOME,XDG_CONFIG_HOMEиXDG_DATA_HOMEтеперь заданы в постоянном drop-in дляdocker.service.P2 — Применить новое окружение к уже работающему Docker при повторном запуске установщика (
install-runner.sh:229–233). Еслиdocker.serviceбыл запущен до появленияenvironment.conf,daemon-reloadобновит описание unit, ноenable --nowне перезапустит активный процесс.systemctl show ... --property=Environmentвернёт новые значения из описания unit, поэтому проверка пройдёт, хотя работающийdockerd-rootless.shпродолжит использовать старыйHOME/XDG до ручного перезапуска или reboot. Это существенный сценарий для установщика, который заявлен как безопасно повторяемый после частичной установки. Перезапускайте уже активныйdocker.serviceпосле изменения drop-in и проверяйте окружение фактического процесса (либо явно документируйте и обеспечьте остановку/запуск перед проверкой).Локальные проверки
test-runner-config.sh,test-install-runner-idempotency.sh,test-install-runner-guard.shиbash -nпроходят; сценарий с уже работающим Docker ими не покрыт.Предыдущие замечания исправлены. HOME/XDG пути сохранены в постоянном drop-in
docker.service; при повторном запуске установщик перезапускает активный daemon и сверяет переменные окружения его процесса. Путь к user unit, окружение runner и healthcheck согласованы. Локально прошли три runner test-скрипта иbash -nизменённых shell-файлов. Запуск на VPS в рамках ревью не выполнялся.