Erro bootstaping de timestamp do bootstraping de Juju

Question

Tenha uma configuração simples, consistindo em um servidor LTS 14.04 MAAS, responsável pelo dhcp e pelo dns, e um nó de destino do laptop. O nó de destino alcançou com sucesso o estado "Pronto"; no entanto, ao tentar fazer o bootstrap no ambiente maas, recebo o seguinte erro:

ERROR juju.cmd supercommand.go:305 gomaasapi: got error back from server: 401 OK (Expired timestamp: given 1400585768 and now 1400610974 has a greater difference than threshold 300)

Isso acontece no final do processo de bootstrap, ou seja, o nó de destino foi atualizado e o serviço relevante o iniciou:

juju -v --debug bootstrap -e maas --upload-tools

...
Setting up libsnappy1 (1.1.0-1ubuntu1) ...
Setting up juju-mongodb (2.4.9-0ubuntu3) ...
Processing triggers for libc-bin (2.19-0ubuntu6) ...
tools from http://MAAS_IP.hum.com/MAAS/api/1.0/files/?key=a5b32a4c-e04c-11e3-8e9d-3c970e523f90&op=get_by_key downloaded: HTTP 200; time 0.229s; size 7356324 bytes; speed 32134911.000 bytes/s 559550d004af5b4c7cee626c6be1b9fae2d2fcac15ce66fb41443eb0a0c8b3df  /var/lib/juju/tools/1.18.3.1-trusty-amd64/tools.tar.gz
tar: FORCE-VERSION: time stamp 2014-05-20 18:29:11 is 24782.564204358 s in the future
tar: jujud: time stamp 2014-05-20 18:29:11 is 24782.252135833 s in the future
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00266961 s, 393 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00269804 s, 389 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00339052 s, 309 MB/s
juju-db start/running, process 31297
2014-05-20 11:36:08 INFO juju.cmd supercommand.go:302 running juju-1.18.3.1-trusty-amd64 [gc]
2014-05-20 11:36:08 DEBUG juju.agent agent.go:384 read agent config, format "1.18"
2014-05-20 11:36:08 DEBUG juju.provider.maas environprovider.go:30 opening environment "maas".
2014-05-20 11:36:08 ERROR juju.cmd supercommand.go:305 gomaasapi: got error back from server: 401 OK (Expired timestamp: given 1400585768 and now 1400610974 has a greater difference than threshold 300)
2014-05-20 18:36:14 ERROR juju.provider.common bootstrap.go:123 bootstrap failed: rc: 1
Stopping instance...
2014-05-20 18:36:14 INFO juju.cmd cmd.go:113 Bootstrap failed, destroying environment
2014-05-20 18:36:14 INFO juju.provider.common destroy.go:14 destroying environment "maas"
2014-05-20 18:36:15 ERROR juju.cmd supercommand.go:305 rc: 1

Está pesquisando por palavra-chave timestamp sem sorte. A reinicialização e recomissionamento do nó de destino não parece ajudar. Qualquer ajuda seria apreciada. Felicidades

    

Answer 1

Possível causa para isso pode ser este link - ou seja, o relógio do servidor MAAS está fora de sincronia em comparação com a máquina do cliente.

Eu observei isso ao usar uma VM para o servidor MAAS, que tinha um instantâneo de alguns dias. Toda vez que eu tentei bootstrap após a restauração do instantâneo eu recebi o erro. A solução foi tão fácil quanto executar ntpdate ntp.ubuntu.com para atualizar o relógio do servidor antecipadamente.

    

Answer 2

Você pode configurar seu próprio ntp local (net tine server)

link

e atualize seu arquivo / etc / maas / preseed / preseed-master para apontar para o seu servidor ntp ao invés de ntp.ubuntu.com e você é ocal e não precisa manipular nada.

    

Answer 3

Basta definir o fuso horário como UTC e fazer o bootstrap novamente.

    

Answer 4

Eu tive esse problema e ele veio para o meu firewall. Eu não estava deixando o NTP através do meu firewall. Eu tive que permitir o UDP / 123 através do firewall para que o nó pudesse sincronizar seu tempo.