Preciso de ajuda com bootstrap juju no ambiente maas. Eu instalei o maa no servidor do controlador do maa, comissionei um blade e tentei fazer o bootstrap com o juju.
O sistema se instala no novo blade, o juju entra com o usuário do ubuntu via ssh e fica preso neste ponto do processo de instalação dos serviços de juju:
Registrando em /var/log/cloud-init-output.log no host remoto
Executando o apt-get update
Executando o apt-get upgrade
Instalando o pacote: git
Instalando o pacote: curl
Instalando o pacote: cpu-checker
Instalando o pacote: bridge-utils
Instalando o pacote: rsyslog-gnutls
Fetching tools: curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s ' --retry 10 -o $bin/tools.tar.gz 'https://streams.canonical.com/juju/tools/releases/juju-1.20.11-trusty-amd64.tgz'
Qualquer ajuda seria apreciada, porque eu não posso avançar a partir deste ponto, exceto para finalizar o processo de bootstrapping.
Obrigado!
Problema resolvido. Se você ssh para um servidor e seu layout de teclado não for o mesmo que as configurações de idioma no servidor, o juju não conseguirá inicializar o sistema. Eu mudei meu layout para en_US e bootstrapping funcionou bem. É o mesmo problema quando você instala o postgresql onde ele não consegue instalar se você não tiver a mesma linguagem de layout de teclado que o idioma do sistema no servidor.
Eu tenho exatamente o mesmo problema, o boostrapping do juju está preso. Tentei alterar a configuração do local, mas nada ajudou.
aqui está o que eu fiz: verifique suas configurações
locale
correção temporária
export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
locale-gen en_US.UTF-8
torná-lo permanente
nano /etc/environment
copiar / colar
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
Eu também tive esse problema. A raiz do problema para mim era que eu não tinha acesso à Internet e precisava fazer algumas coisas. IIRC, este particular estava sendo causado pelo tempo em que o servidor e a máquina alvo estavam desligados por um período de tempo muito grande. Não foi realmente preso, mas o tempo foi enorme, talvez 30 minutos. Eu configurei meu servidor como um servidor ntp, então eu editei meu / etc / maas / preseeds / preseed-master
d-I clock-setup/ntp-server string ntp.ubuntu.com
Coloque o IP ou o nome do seu servidor em ntp.ubuntu.com. Além disso, quando você instala o juju, é necessário copiar os charms localmente. Eu fiz um diretório ~ /, juju para o ambiente e charms, então o processo, até a implementação do juju-gui, ficou assim:
mkdir ~./.juju/sync-tools
juju sync-tools –e maas –destination=”~/.juju/sync-tools”
juju bootstrap –e maas –-upload-tools=true –-metadata-source=”.juju/sync-tools” -–to jujuBS.local
mkdir –p ~/.juju/charms/trusty
juju charm get juju-gui .juju/charms/trusty
juju deploy –repository=”~/.juju/charms” local:juju-gui
Espero que isso ajude!
Para qualquer um que tenha esse problema depois de adicionar máquinas ao provedor local: Eu tive esse problema quando o add-machine tentou adicionar uma máquina com uma versão do Juju diferente do servidor de estado.
Isso foi causado por não executar apt-get update antes de instalar o cliente Juju.