Амулет, загружающийся gomaasapi, добавляет метку времени к ошибке
Имейте простую установку, состоящую из одного сервера LTS 14.04 МААСА, ответственного за dhcp и DNS и целевой узел ноутбука. Целевой узел успешно достиг "Готового" состояния; однако, при попытке загрузиться в среду Мааса, я получаю следующую ошибку:
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)
Это происходит к концу процесса начальной загрузки, т.е. целевой узел был обновлением, и соответствующий сервис запустили его:
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
Поиск ключевого слова метки времени без удачи. Перезагрузка и переввод в действие целевого узла, кажется, не помогают. Любая справка ценилась бы.Удачи
4 ответа
Возможная причина для этого могла бы быть этим , http://maas.ubuntu.com/docs/troubleshooting.html#possible-cause-timing-issues - т.е. часы сервера Мааса является выходом из синхронизации по сравнению с клиентской машиной.
я наблюдал это при использовании VM для сервера МААСА, который имел снимок несколько дней. Каждый раз, когда я пытался загрузиться после восстановления от снимка, я получил ошибку. Решение было так же легко как выполнение ntpdate ntp.ubuntu.com для обновления часов сервера заранее.
Можно настроить собственные локальные ntp (сетевой сервер зубца)
http://ubuntuforums.org/showthread.php?t=862620
и обновить Ваш/etc/maas/preseed/preseed-master, файл для указания на сервер ntp вместо ntp.ubuntu.com и Вашего является и ocal и ничего не должен вручать заводной рукоятке.
Просто установите Часовой пояс на UTC и загрузите его снова, это работает.
У меня была эта проблема, и она свелась к моему брандмауэру. Я не позволял NTP через свой брандмауэр. Я должен был позволить UDP/123 через брандмауэр, таким образом, узел мог синхронизировать свое время.