Linux запуск службы от имени пользователя

Managing services for non-root users with systemd

Systemd is mainly used to manage services on modern linux distributions, but it also allows non-root users to manage services running under their own account. This makes systemd a great alternative to services like supervisord as it is able to detect crashes and automatically restarts the service.

Configuring a user unit

The directory structure that holds unit files is similar to the systemwide configuration, but is located in a user’s home directory:

$ mkdir -p ~/.config/systemd/user 

In the user folder we can create service units with a .service extension. A unit is a ini-style file describing a service that has to be managed.

Let’s say we have a Laravel PHP queue worker that we want to be managed by systemd, called worker.service :

[Unit] Description=Laravel PHP queue worker [Service] ExecStart=/usr/bin/env php /path/to/my/project/artisan queue:work --sleep=3 --tries=3 [Install] WantedBy=default.target 

Run $ systemctl —user daemon-reload to make systemd recognize your changes.

We can now manage this service with systemd:

• $ systemctl —user start worker starts the service
• $ systemctl —user stop worker stops the service
• $ systemctl —user restart worker restarts the workers
• $ systemctl —user status worker shows us the service status

If we want this service to start automatically when our user logs in, we have to enable it:

Viewing logs

Everything our PHP script writes to stdout and stderr will be recorded by journald. We can view the logs for this specific service:

On older versions of systemd (like the one shipped with Debian Jessie), you might need to use a flag specific to user units:

$ journalctl --user-unit worker 

Automatically restarting on failure

Let’s be honest: things go wrong. When our worker crashes we want to make sure it’s started again. Fortunately, we can configure systemd to restart on failure:

Add the following to the [Service] section of the unit file:

RestartSec=10s Restart=on-failure 

This makes systemd restart the service 10 seconds after it has stopped with a non-zero exit code. If the process exited cleanly, systemd considers the work as done and won’t restart the service until you manually start it later.

Starting user services at boot

By default, systemd starts enabled user units when the user logs in, and stops them once the user has logged out. This is great for desktop pcs where a user wants to run things while he’s using the computer. On servers, however, we may want to run those units all the time.

# loginctl enable-linger USERNAME 

You can check the status for each user by:

# loginctl user-status USERNAME 

It should show that the user is lingering:

vic (1000) Since: Fri 2017-09-01 21:54:29 CEST; 3s ago State: lingering Unit: user-1000.slice 

When the user is not logged in and does not have lingering enabled, loginctl doesn’t know about any user sessions so it will return an error:

Failed to get user: No user 1000 known or logged in 

Источник

🐧 Как запустить сервисы Systemd без пользователя root / sudo

Мануал

Systemd – это современный инит и замена rc в стиле SysV для систем Linux, которая использует многие современные функции ядра Linux.

О н предоставляет диспетчер системы и услуг, который запускается как PID 1 и запускает остальную часть системы.

Systemd отвечает за управление тем, как службы запускаются, останавливаются, перезапускаются и каким-либо другим образом управляются в современных дистрибутивах Linux.

Стандартные файлы модулей Systemd , которые поставляются с системой Linux или устанавливаются сторонними приложениями, обычно запускаются от имени пользователя root или системного пользователя.

Это руководство покажет вам, как запустить службу Systemd без рута от обычного пользователя, вошедшего в систему.

Юнит службы Systemd

Файл модуля Systemd содержит директивы конфигурации, которые описывают модуль и определяют его поведение.

В этом руководстве мы напишем файл модуля systemd, которым может управлять зарегистрированный пользователь без sudo.

Запустим службу Systemd от стандартного пользователя

Пользовательский сервис Systemd должен быть помещен в каталог ~/.config/systemd/user , если вы хотите иметь полное право владения обычным пользователем.

Создайте его, если его не существует.

mkdir -p ~/.config/systemd/user/

Мы создадим тестовый сервис, который запускает приложение Syncthing.

curl -s https://api.github.com/repos/syncthing/syncthing/releases/latest | grep browser_download_url | grep linux-amd64 | cut -d '"' -f 4 | wget -qi - tar xvf syncthing-linux-amd64*.tar.gz sudo cp syncthing-linux-amd64-*/syncthing /usr/local/bin/

$ syncthing --version syncthing v1.4.0 "Fermium Flea" (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-03-06 19:52:22 UTC

$ vim ~/.config/systemd/user/syncthing.service [Unit] Description=Syncthing - Open Source Continuous File Synchronization Documentation=man:syncthing(1) [Service] ExecStart=/usr/local/bin/syncthing -no-browser -no-restart -logflags=0 Restart=on-failure SuccessExitStatus=3 4 RestartForceExitStatus=3 4 # Hardening SystemCallArchitectures=native MemoryDenyWriteExecute=true NoNewPrivileges=true [Install] WantedBy=default.target

$ systemctl --user daemon-reload

Подтвердите, что служба доступна.

$ systemctl --user list-unit-files syncthing.service UNIT FILE STATE syncthing.service disabled 1 unit files listed.

$ systemctl --user enable --now syncthing.service Created symlink /home/vagrant/.config/systemd/user/default.target.wants/syncthing.service → /home/vagrant/.config/systemd/user/syncthing.service.

Давайте проверим состояние нашего сервиса.

$ systemctl --user status syncthing.service ● syncthing.service - Syncthing - Open Source Continuous File Synchronization Loaded: loaded (/home/vagrant/.config/systemd/user/syncthing.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2020-04-03 17:18:54 UTC; 5s ago Docs: man:syncthing(1) Main PID: 22628 (syncthing) CGroup: /user.slice/user-1000.slice/user@1000.service/syncthing.service ├─22628 /usr/local/bin/syncthing -no-browser -no-restart -logflags=0 └─22632 /usr/local/bin/syncthing -no-browser -no-restart -logflags=0

Это тот же процесс, который вы можете использовать для создания любой другой службы Systemd, которой хотите управлять без повышения привилегий или создания другого системного пользователя для запуска службы.

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!

Получается что установленные сервисы через –user настроить на автозапуск нельзя ?Получается нужно установить сервис в раздел /etc/system/systemd, для возможности автозапуска, дать права в /etc/sudoers USER ALL = NOPASSWD: /usr/sbin/service что бы не просил пароль?

Вообще можно. Можно сделать системный юнит, где указать пользователя и сделать скрипт запуска от пользователя. Но это больше трудозатрат

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (105)
• Книги (27)
• Мануал (2 305)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (820)
• Обход запретов (34)
• Опросы (3)
• Скрипты (114)
• Статьи (352)
• Философия (114)
• Юмор (18)

Anything in here will be replaced on browsers that support the canvas element

Что такое 404 Frame? Большинство инструментов для взлома веб-сайта находятся в 404 Frame. Итак, что же представляют собой команды? Вы можете отдавать команды, используя повседневный разговорный язык, поскольку разработчики не хотели выбирать очень сложную систему команд. Команды Команды “help” / “commands” показывают все команды и их назначение. Команда “set target” – это команда, которая должна […]

В этой заметке вы узнаете о блокировке IP-адресов в Nginx. Это позволяет контролировать доступ к серверу. Nginx является одним из лучших веб-сервисов на сегодняшний день. Скорость обработки запросов делает его очень популярным среди системных администраторов. Кроме того, он обладает завидной гибкостью, что позволяет использовать его во многих ситуациях. Наступает момент, когда необходимо ограничить доступ к […]

Знаете ли вы, что выполняется в ваших контейнерах? Проведите аудит своих образов, чтобы исключить пакеты, которые делают вас уязвимыми для эксплуатации Насколько хорошо вы знаете базовые образы контейнеров, в которых работают ваши службы и инструменты? Этот вопрос часто игнорируется, поскольку мы очень доверяем им. Однако для обеспечения безопасности рабочих нагрузок и базовой инфраструктуры необходимо ответить […]

Одной из важнейших задач администратора является обеспечение обновления системы и всех доступных пакетов до последних версий. Даже после добавления нод в кластер Kubernetes нам все равно необходимо управлять обновлениями. В большинстве случаев после получения обновлений (например, обновлений ядра, системного обслуживания или аппаратных изменений) необходимо перезагрузить хост, чтобы изменения были применены. Для Kubernetes это может быть […]

Является ли запуск сервера NFS в кластере Kubernetes хорошей идеей или это ворота для хакеров Одним из многочисленных преимуществ сетевой файловой системы является ее способность выполнять многократное чтение-запись. И как и все в наши дни, NFS – это просто еще одна служба, которую можно запустить в своем кластере Kubernetes. Однако является ли сервер NFS подходящей […]

Источник