juju bootstrap usando maas incapaz de ssh em nós

Question

Fiel: 14,04

Tentando inicializar o JUJU usando o ambiente maas usando juju -v --debug bootstrap -e maas , mas o processo fica preso nas linhas mostradas abaixo e finalmente atinge o tempo limite.

Meus nós maas estão no estado pronto. Quando tentei executar o comando ssh no shell do sistema do host MAAS e consegui me conectar com sucesso.

Eu não entendo porque o juju não continua mesmo se o ssh for bem sucedido. Eu tentei isso com juju 1.18.x [stable] assim como 1.19.x [devel]

O seguinte é o rastreio de log.

Lote de registros ....

2014-06-30 13:29:44 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/dcadmin/.juju/ssh/juju_id_rsa -i /home/dcadmin/.ssh/id_rsa [email protected] /bin/bash
2014-06-30 13:29:46 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/dcadmin/.juju/ssh/juju_id_rsa -i /home/dcadmin/.ssh/id_rsa [email protected] /bin/bash

Alguém por favor pode ajudar.

Obrigado Prasanna

    

Answer 1

Este problema é corrigido se colocarmos um hack. Eu encontrei enquanto procurava por este problema e ele realmente funcionou.

Mas, seriamente, nunca aconselharia usar isso em produção.

Para contornar este problema, siga os seguintes passos:

1. Primeiro, verifique se você pode efetuar login em cada um dos nós filhos do MAAS usando a senha menos ssh.
2. Crie o diretório / var / lib / juju
3. Altere a propriedade do diretório para o ubuntu: ubuntu
4. Crie um arquivo de texto /var/lib/juju/nonce.txt com conteúdo - user-admin: bootstrap

Inicie o bootstrap novamente.

    

Answer 2

Encontrei este post porque, por acaso, tive os mesmos sintomas. Talvez você tenha, afinal, o mesmo problema.

Ao inicializar o Juju, recebi a mesma tentativa de login do ssh exibida como você. Então eu dei uma olhada no meu virt-manager e notei que a máquina não estava ligada. Eu então tentei iniciar a máquina usando o MAAS GUI. Embora, dentro da GUI do MAAS, ele afirmasse estar alocado para o usuário, na verdade ele não foi iniciado no KVM (verificando-o pelo virt-manager).

Isso me confirmou que há um problema de configuração com o MAAS, e não com o Juju. Eu verifiquei algumas coisas e, em seguida, notei que não criei um diretório de usuário e uma chave SSH para o usuário do MAAS, conforme descrito em link .

Depois de ter feito isso, o MAAS conseguiu iniciar e parar minhas máquinas KVM e Juju fez o mesmo.

Abaixo estão as linhas relevantes copiadas do link que resolveu o problema para mim.

Se você quiser usar ssh, precisará gerar um par de chaves ssh para o usuário maas. Por padrão, não há diretório inicial criado para o usuário maas:

sudo mkdir /home/maas
sudo chown maas:maas /home/maas

Adicione um shell de login para o usuário maas:

sudo chsh -s /bin/bash maas

Torne-se o usuário maas e gere um par de chaves SSH:

ssh-keygen

Em seguida, adicione a chave pública para /ubuntu/.ssh/authorized_keys no servidor vm, assim o virsh pode usar ssh sem uma senha:

ssh-copy-id -i ~/.ssh/id_rsa [email protected]

Como usuário do maas, teste os comandos do virsh no libvirt em 10.0.0.2:

virsh -c qemu+ssh://[email protected]/system list --all

    

Answer 3

Parece que o Juju não consegue resolver os nomes dos nós. Você precisa ter certeza de que o sistema onde você executa o Juju usa o servidor DNS do MAAS como seu resolvedor (verifique se ele funciona executando host <name of my MAAS node> no servidor onde você deseja executar o Juju).