Вопрос или проблема
Я подключаюсь по SSH как пользователь “Ubuntu” на сервере. Однако я хочу управлять некоторыми системными сервисами systemd как другой пользователь “ABC”.
Если я попытаюсь выполнить sudo bash от имени пользователя ABC, то каждая команда systemd --user выдаёт ошибку:
Не удалось подключиться к шине: Средство не найдено
Я нашел эту тему, в которой предлагалось добавить следующее в ~/.bashrc:
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
Это изменяет ошибку на:
Не удалось подключиться к шине: Нет такого файла или каталога
Другие источники указывают на то, что безголовные серверы, как правило, не имеют установленного dbus, поэтому это имеет смысл. Хотя я не понимаю, почему это работает без проблем, если я выполняю это от имени ubuntu.
Я нашел предложенное решение
sudo systemctl -M abc@ --user restart foobar.service
Это работает для базовых start, stop, status, но:
systemctl --user catне работает- Никакой вариант
journalctlне кажется работающим:
Не удалось открыть корневой каталог машины 'abc@': Имя org.freedesktop.machine 1 не было предоставлено ни одним .service файлом
Не удалось открыть журнал: Нет маршрута к хосту
- Просто очень долго печатать и неудобно.
Мне действительно нужен терминал для этого другого пользователя, точно так же, как когда я захожу в ubuntu и могу управлять всеми своими пользовательскими сервисами без каких-либо проблем.
Я упоминаю Podman, потому что Podman тоже крайне недоволен, когда я запускаю его от другого пользователя. Как и в случае с systemd, у меня есть некоторые частичные обходные пути, но ни один из них не работает хорошо.
Если я попытаюсь выполнить
sudo bashот имени пользователя ABC, то каждая командаsystemd --user выдаёт ошибку:Не удалось подключиться к шине: Средство не найдено
Да, нет пользовательской сессии (пользователя ABC), поэтому нет сессионной шины, к которой можно подключиться. Это имеет смысл!
Я не собираюсь комментировать решение, которое вы скопировали и которое начинается с “это решение устарело…”. Это верно, это решение не является решением.
Другие источники указывают на то, что безголовные серверы, как правило, не имеют установленного dbus, поэтому это имеет смысл.
Это должно было быть 20 лет назад… Обычно современные системы Linux имеют dbus установленным. Все, что на systemd, определенно, имеют его.
Я упоминаю Podman, потому что Podman тоже крайне недоволен, когда я запускаю его от другого пользователя. Как и в случае с systemd, у меня есть некоторые частичные обходные пути, но ни один из них не работает хорошо.
Одной из основных причин существования Podman является то, что это неправда. Вам, вероятно, стоит решить эту проблему, а не искать обходные пути, накладывая один на другой.
У меня есть несколько серверов, где я запускаю поды podman с несколькими контейнерами при загрузке как отдельные, не-root пользователи, используя скрипты сервисов systemd, которые podman даже предоставляет команду для создания… так что это определенно можно исправить. Вам, вероятно, следует задать новый вопрос! Вероятно, вам просто не хватает чего-то, что намного проще исправить, чем выяснить, может ли процесс без входа найти систему пользовательской сессии dbus, если он вообще запускается.
Ответ или решение
Чтобы получить «полную» оболочку для другого пользователя, которая позволит управлять службами systemd и Podman, нужно учитывать несколько ключевых моментов. Давайте разберем шаги, необходимые для достижения этой цели.
1. Понимание контекста
Когда вы заходите на сервер под пользователем Ubuntu и хотите запускать команды от имени другого пользователя ABC, нужно обратить внимание на то, что systemd использует пользовательские сеансы, которые требуют наличия активного сеанса D-Bus. Таким образом, простое использование sudo bash отправляет вас в новую сессию без контекста ABC, что и вызывает проблему с подключением к D-Bus.
2. Правильный способ переключения пользователя
Чтобы работать от имени пользователя ABC и иметь доступ к его сеансам, следует использовать команду su с параметром -l (или --login). Это позволит инициировать новую сессию с полным окружением для пользователя ABC.
su -l ABCЭтот способ создаст именно такую среду, которую имел бы пользователь ABC, если бы он вошёл в систему напрямую.
3. Настройка окружения
После того как вы вошли в систему под ABC, вам могут потребоваться другие настройки окружения, чтобы убедиться, что systemd --user и Podman работают правильно.
a. Установка D-Bus
Убедитесь, что на вашем сервере установлен D-Bus. Для проверки можно использовать:
systemctl status dbusЕсли он не установлен, выполните:
sudo apt install dbusb. Переменные окружения
В .bashrc или .profile пользователя ABC убедитесь, что следующие переменные установлены (если вы еще не сделали этого):
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"Эти переменные помогут системе находить необходимые «шины» для подключения к службам.
4. Использование systemd
Теперь, когда вы находитесь под пользователем ABC, команды systemctl --user должны работать корректно. Например, чтобы начать, остановить или проверить статус службы, используйте:
systemctl --user start myservice.service
systemctl --user stop myservice.service
systemctl --user status myservice.serviceЕсли у вас возникают проблемы, проверьте настройки и права на доступ к вашим юзер-юнитам в каталоге ~/.config/systemd/user.
5. Работа с Podman
Podman, как иллюстрирует практика, также может функционировать под другим пользователем, но может потребовать дополнительной настройки, чтобы иметь полный доступ к безопасным контейнерам. Убедитесь, что вы правильно настроили разрешения и контексты SELinux (если он включен).
Следует также убедиться, что для Podman используются те же параметры окружения, что и для systemd. После перехода под ABC, вы можете запускать Podman с командой:
podman run ...6. Заключение
Работа с системными сервисами и контейнерами под другим пользователем на Linux-сервере может представлять собой непростую задачу, но правильной настройкой окружения и сессий можно достичь желаемого результата. Настоятельно рекомендуется не пытаться обойти системные ограничения без надлежащего понимания их причин, чтобы избежать потенциальных проблем с безопасностью и управляемостью систем.
Следуя этим рекомендациям, вы сможете эффективно управлять сервисами под пользователем ABC без дополнительных неудобств.