Eu entro no wish SSH como um usuário "Ubuntu" em um servidor. No entanto, quero gerenciar a execução de alguns serviços systemd como outro usuário "ABC".
Se eu tentar sudo -u abc bashcomo usuário ABC, todo systemd --usercomando dará o erro:
Failed to connect to bus: No medium found
Encontrei este tópico que sugeriu adicionar o seguinte a ~/.bashrc:
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
Isso altera o erro para:
Failed to connect to bus: No such file or directory
Outras fontes sugeriram que servidores headless normalmente não têm dbus instalado, então isso faz sentido (parece ser um componente do x11). Embora eu não saiba por que funciona sem problemas se eu o executo como ubuntu.
Encontrei esta solução alternativa sugerida
sudo systemctl -M abc@ --user restart foobar.service
Isso funciona para start, , básico stop, statusmas:
systemctl --user catnão funciona- Nenhuma variação
journalctlparece funcionar:
Failed to open root directory of machine 'abc@': The name org.freedesktop.machine 1 was not provided by any .service files
Failed to open journal: No route to host
- É muito longo para digitar e inconveniente.
Eu realmente só quero um shell para esse outro usuário, assim como quando eu entro ubuntu, e posso gerenciar todos os meus serviços de usuário sem problemas.
Menciono o Podman porque o Podman também fica realmente infeliz quando o executo como um usuário diferente. Ele funciona bem se eu o uso como, ubuntumas dá erros se eu o executo com sudo -u. Como o systemd, tenho algumas soluções alternativas parciais, mas nenhuma parece funcionar bem.
Um ponto importante para começar: D-Bus não é um singleton. O mesmo software exato é usado em várias configurações diferentes para fornecer vários "barramentos" distintos para diferentes propósitos: um barramento de 'sistema' global, um barramento de 'sessão' por usuário, outros conforme necessário. Qualquer coisa que você fizer com D-Bus precisa ser qualificada com qual barramento está envolvido, caso contrário você acabará com correções sem sentido.
Pelo que você descreveu em sua postagem, parece que uma configuração do Podman por usuário espera que um barramento de sessão esteja presente.
O barramento de sessão pode ser iniciado de várias maneiras, inclusive manualmente, mas por padrão um é iniciado pelo systemd quando o usuário efetua login.
Tecnicamente, um barramento de sessão "personalizado" também pode ser iniciado com 'dbus-run-session' ou 'dbus-launch' ou até mesmo com a invocação manual de 'dbus-daemon', embora eu suspeite que isso não seja suficiente para o podman; ele provavelmente também esperará que o systemd esteja disponível no barramento, caso em que você realmente precisa do "login", pois isso inicia um systemd por usuário e um D-Bus por usuário.
Segundo ponto: Não se trata do shell, mas do mecanismo de troca de usuário. Apenas mudar seu UID usando
suousudonão conta como um 'login' nesse sentido; mesmo que o novo shell esteja rodando sob o usuário B (e possa ter carregado o ~/.profile do usuário B e tal), tudo isso ainda está agrupado sob a sessão de login do usuário A.O mecanismo para isso é o módulo PAM
pam_systemd, que é executado como parte do procedimento de login CLI/SSH/GUI para registrar um "login" com o systemd – mas não é executado como parte do sudo/su e não tem permissão para registrar um "login" de dentro de um já existente; ele precisa ser feito do zero.Se você quiser imitar um login, use
machinectl shell foouser@.(A versão mais recente
run0 --user=foousertambém pode funcionar, embora eu me lembre de um tópico na lista de discussão sobre alguns bugs relacionados ao PAM.)Se tudo o que você quer é iniciar serviços em nível de usuário, essa
systemctl --user -M foouser@é uma maneira correta de fazer isso "de fora".Relacionado: Se você quiser iniciar coisas que não têm uma definição de serviço, use
systemd-run --user(que aceita o mesmo-Mse for necessário usar de fora).Se você quiser forçar o systemd a iniciar suas tarefas em nível de usuário para um usuário específico sem que haja nenhum login para esse usuário, execute
loginctl enable-linger foousercomo root.Fazer isso permitirá que você manualmente
export XDG_RUNTIME_DIR=e assim por diante, se quiser. (Isso não funcionou na sua tentativa original porque não era a falta de variáveis de ambiente que era o problema – era a falta de soquete D-Bus real para o qual as variáveis apontam.) Embora isso seja automatizado pela-M user@opção systemctl e systemd-run.(Não, o conceito de "shell de login"
su -não tem nada a ver com isso.)Sim, não há sessão de usuário (do usuário ABC), então não há barramento de sessão para conectar. Faz sentido para mim!
Não vou comentar sobre uma solução que você copiou que começa com "esta solução está obsoleta...". É verdade, essa solução não é uma solução.
Isso deve ter sido há 20 anos… geralmente, sistemas Linux modernos têm dbus instalado. Qualquer coisa com systemd definitivamente tem.
Uma das principais razões para a existência do Podman é que isso não é verdade. Você provavelmente deveria consertar esse problema, não encontrar soluções alternativas empilhadas sobre soluções alternativas.
Tenho vários servidores onde inicio pods podman com vários contêineres na inicialização como usuários não root separados usando scripts de serviço systemd, que podman tem até um comando para criar... então, isso é definitivamente corrigível. Você provavelmente deveria fazer uma nova pergunta! Provavelmente você está apenas esquecendo de algo que é muito mais fácil de consertar do que descobrir se, e se, onde, um processo sem login pode encontrar o barramento de sessão do usuário dbus se for iniciado.
por padrão, fornece um shell rodando como usuário root. Uma vez que você tenha permissões de root, você pode usar outras ferramentas para iniciar uma sessão interativa como o usuário ABC. Por exemplo, se o usuário ABC tiver sido atribuído a um shell interativo normal e tiver um diretório home normal:
lhe dará uma sessão (shell) como se você tivesse acabado de fazer login como o usuário ABC. Agora os comandos que você digitar terão as permissões do usuário ABC. Digitar 'exit' retornará ao shell rodando como o usuário root, e outro
exitcomando retornará ao shell rodando como sua conta.Os comandos devem
podmanser sensíveis a qual usuário os invoca? Em teoria não, mas frequentemente os aplicativos são configurados para rodar sob um usuário Linux em particular. Tentar iniciar/parar/gerenciar o aplicativo como um usuário diferente encontrará problemas. Normalmente, no entanto, a documentação será deixada para trás sobre como fazer login em sua própria conta (diferente) no servidor e então alternar para a conta do aplicativo antes de executar os comandos do aplicativo.