You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Мы используем у себя свой кастомный плагин для мониторинга на серверах бекапов pg_probackup.
После обновления до версии 3.5.2 плагин перестал корректно работать, не отдает данные об имеющихся бекапов. В логе обнаружил ошибки доступа к файлам:
Дело в том, что файлы в бекапе доступны только владельцу - postgres, и поменять это мы не имеем возможности (стоит еще учитывать что сам pg_probackup те же wal файлы всегда пишет из под postgres с правами 600) и ранее у нас mamonsu запускался от пользователя postgres и все работало.
Сейчас же, мы переделали в сервисе запуск mamonsu от пользователя mamonsu, т.к. в новой версии введена проверка на владельца и права файла agent.conf:
"Shut down because of incorrect config file {0} permissions. It must be r/w for mamonsu user only (600).".format(
cfg_file))
sys.stderr.write(
"Please, check your config file {0} permissions. It must be r/w for mamonsu user only (600).\n".format(
cfg_file))
sys.exit(1)
И получилось что у нас плагин потерял возможность ходить и мониторить бекапы.
Запустить же mamonsu как раньше, от пользователя postgres, не позволяет выше приведенная проверка, т.к. запуск от пользователя, отличного от mamonsu, требует поменять либо владельца agent.conf, либо права изменить, но это все приводит к завершению mamonsu при старте из-за выше приведенной проверки.
Можно ли на уровне кода установить, чтобы хотя бы были доступны вариации по правам и владельцу файла agent.conf? Например чтобы он мог иметь права не только 600, но и 644. И нам так же требуется чтобы можно было бы чтобы владельцем файла мог бы быть и пользователь postgres (помимо mamonsu), т.к. в контейнерах Docker agent.conf именно с владельцем postgres разворачивается.
В текущей ситуации, нам придется перед сборкой из исходников самим внедряться в код и изменять там этот момент.
The text was updated successfully, but these errors were encountered:
Мы в итоге (т.к. собираем mamonsu из исходников для своих нужд), вносим автоматически правки в эту часть кода, чтобы работало так как нам надо. Разрешили нужные нам права на конфигурационный файл (600, 644) и пользователей postgres и root добавили (помимо mamonsu) в условиях if.
Пока так пришлось сделать.
Добрый день! @xinferum@levinsv в последнем вышедшем патче эту проверку убрали. В планах сделать проверку более гибкой и не привязываться к конкретному юзеру mamonsu, а определять запускающего пользователя.
Добрый день.
Версия mamonsu: 3.5.2
Мы используем у себя свой кастомный плагин для мониторинга на серверах бекапов pg_probackup.
После обновления до версии 3.5.2 плагин перестал корректно работать, не отдает данные об имеющихся бекапов. В логе обнаружил ошибки доступа к файлам:
Дело в том, что файлы в бекапе доступны только владельцу - postgres, и поменять это мы не имеем возможности (стоит еще учитывать что сам pg_probackup те же wal файлы всегда пишет из под postgres с правами 600) и ранее у нас mamonsu запускался от пользователя postgres и все работало.
Сейчас же, мы переделали в сервисе запуск mamonsu от пользователя mamonsu, т.к. в новой версии введена проверка на владельца и права файла agent.conf:
mamonsu/mamonsu/lib/config.py
Lines 87 to 94 in 9bd4952
И получилось что у нас плагин потерял возможность ходить и мониторить бекапы.
Запустить же mamonsu как раньше, от пользователя postgres, не позволяет выше приведенная проверка, т.к. запуск от пользователя, отличного от mamonsu, требует поменять либо владельца agent.conf, либо права изменить, но это все приводит к завершению mamonsu при старте из-за выше приведенной проверки.
Можно ли на уровне кода установить, чтобы хотя бы были доступны вариации по правам и владельцу файла agent.conf? Например чтобы он мог иметь права не только 600, но и 644. И нам так же требуется чтобы можно было бы чтобы владельцем файла мог бы быть и пользователь postgres (помимо mamonsu), т.к. в контейнерах Docker agent.conf именно с владельцем postgres разворачивается.
В текущей ситуации, нам придется перед сборкой из исходников самим внедряться в код и изменять там этот момент.
The text was updated successfully, but these errors were encountered: