Estou tentando configurar alguns serviços de usuário usando Ansible e systemd.
No Ubuntu e RHEL 7 estou recebendo
# systemctl --user status
Failed to get D-Bus connection: Connection refused
Para Ubuntu esclareci o erro, é por causa disso:
https://docs.ansible.com/ansible/latest/modules/systemd_module.html
execute systemctl dentro de um determinado escopo do gerenciador de serviços, seja como o escopo padrão do sistema (sistema), o escopo do usuário atual (usuário) ou o escopo de todos os usuários (global). Para que o systemd funcione com 'usuário', o usuário em execução deve ter sua própria instância do dbus iniciada (requisito do systemd). O processo dbus do usuário normalmente é iniciado durante o login normal, mas não durante a execução de tarefas Ansible. Caso contrário, você provavelmente receberá um erro 'Falha ao conectar ao barramento: arquivo ou diretório inexistente'.
Basicamente, o DBus precisa ser iniciado antes de systemd --userpoder funcionar. Também não tenho certeza de como fazer isso, mas acho que posso contornar isso de outras maneiras.
Porém, o principal bloqueador neste momento é: como verifico, genericamente, a disponibilidade da funcionalidade?
Eu tentei systemctl showe não há nenhum recurso explícito de "usuário". O sinalizador é o "+PAM" da Featureslinha? Eu sei que o systemd usa PAM pelo menos parcialmente para implementá-lo, não sei se é necessário para outros recursos.
Como posso verificar se "meu" systemd suporta --userde maneira confiável? Existe algum arquivo que eu possa verificar? Um comando? Algo mais? DBus vodu?
Responder1
Infelizmente não consigo mais reproduzir esse comportamento com o Ansible 2.12 no Debian 11 e não tenho outras caixas no momento, mas minha primeira solução suja seria ignorar qualquer erro e registrar o estado da resposta e descobrir o que acontece.
- name: "Check, if user can handle user property"
ansible.builtin.systemd:
state: "started"
name: "crond"
scope: "user"
ignore_errors: true
changed_when: false
register: systemd_status
- name: "Output status for debugging"
ansible.builtin.debug:
msg: "{{ systemd_status }}"
when:
- "systemd_status.failed | bool"
Quando você executa command: systemd --user status, isso lhe daria uma resposta concreta. Mas não posso testar isso por causa de um estado de falha ausente no Debian. Além disso, a documentação mostra um exemplo. Mas, no final, acho que a implementação do módulo systemd perde alguns detalhes de implementação e documentação aqui.
Também há um problema aberto no Ansible, consultehttps://github.com/ansible/ansible/issues/72674Ele oferece algumas soluções alternativas possíveis, forçando uma sessão prolongada.
Eu acho que o commit acima erra o alvo. Se o usuário não estiver logado, não há XDG_RUNTIME_DIR para apontar (o diretório não existe), portanto, esclarecer que deve estar acessível não ajuda. Conforme mencionado por @ikke-t, uma sessão prolongada pode ser forçada no systemd (por exemplo, loginctl enable-linger ), mas o ansible deve lidar com isso, habilitando-o automaticamente para esses casos ou permitindo-o no módulo systemd (habilitar/desabilitar usuário permanecer).
Com trabalho manual ansible antes de chamar o systemd:
- name: Ensure lingering enabled
ansible.builtin.command: "loginctl enable-linger {{ user }}"
creates: /var/lib/systemd/linger/{{ user }}