Como configuro o usuário para iniciar automaticamente e configurar corretamente os serviços do usuário do systemd?

Question

No meu servidor de arquivamento, eu estava configurando usuários restritos a seus diretórios pessoais. Eu corri:

useradd -m -s /bin/bash username e passwd username

Eu li este artigo wiki ...

Eu imaginei que deveria usar os serviços do usuário systemd para fazer com que cada usuário executasse um servidor do nó na inicialização. Então eu entrei em uma conta de usuário su username e criei um arquivo ~/.config/systemd/user/serve.service contendo:

[Unit]
Description=One of the servers

[Service]
ExecStart=/usr/bin/node /home/username/server.js

[Install]
WantedBy=default.target

eu executei systemctl --user enable serve.service , que respondeu com Failed to connect to bus: Permission denied

Tanto quanto eu entendo, devo executar o comando systemctl --user ... logado como usuário e não como root.

Então, o que eu perdi nessa configuração?

    

Answer 1

So I logged into one user account su username

Não, você não fez.

Você não está efetuando login. Você está aumentando os privilégios de sua sessão de login existente com su username .

systemctl com a opção --user localiza seu Desktop Bus por usuário, gerenciado pelo usuário do Desktop Bus por usuário, e através desse barramento se comunica com sua instância por usuário de systemd que gerencia sua conta user servics.

su não é um mecanismo de login . Ele funciona dentro de uma sessão de login interativa existente. Nessa sessão, seus processos possuem variáveis de ambiente que informam onde seu diretório de tempo de execução por usuário é ( XDG_RUNTIME_DIR ), onde o Desktop Bus por usuário é ( DBUS_SESSION_BUS_ADDRESS ) e outras coisas como onde seu servidor X está ( DISPLAY ).

Em particular, DBUS_SESSION_BUS_ADDRESS pode implicitamente referenciar XDG_RUNTIME_DIR ou pode nomear explicitamente o mesmo caminho. Esse caminho geralmente será algo como /run/user/1001/bus para o soquete de acesso do agente do Desktop Bus (presumindo que seu ID do usuário seja 1001, por exemplo).

Essas variáveis não são alteradas por su . Tem havido um longo caminho de ida e volta por muitos anos, incluindo os comportamentos de outros comandos similares, como pkexec .

A conseqüência disso é que se você su para um segundo usuário em sua sessão de login, executando systemctl como segundo usuário tenta se conectar a um soquete de acesso ao agente Desktop Bus localizado em um diretório privado para o primeiro usuário . O usuário 1002 (para escolher um ID de usuário para seu segundo usuário por exemplo) não pode acessar /run/user/1001 nem nada dentro dele, e mesmo se xe tivesse lido + executar acesso a esse diretório xe não pode acessar /run/user/1001/bus porque isso apenas concede acesso ao usuário 1001 também.

Naturalmente, isso não é o corretor direito do Desktop Bus para falar em primeiro lugar. Você deseja conversar com o corretor do Desktop Bus do usuário do segundo e por meio da instância por usuário do segundo usuário de systemd .

A solução simples é como parte do su para definir essas variáveis de ambiente para as apropriadas para a segunda conta de usuário, apontando para o Desktop Bus do segundo usuário:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus su username -c 'systemctl --user'

Claro que, em tais circunstâncias, uso uma ferramenta útil para definir isso, userenv , o que me permite não ter que digitar longhand esse endereço de barramento:

su username -c 'userenv --set-dbus systemctl --user'

Leitura adicional

• link
• link
• Jonathan de Boyne Pollard (2014). Não abuse do su para eliminar privilégios de usuário . Respostas frequentemente dadas.
• Jonathan de Boyne Pollard. userenv . páginas de manual do conjunto de ferramentas. Softwares.
• link