DataStax OpsCenter 4.0; работает, но не может запускать агенты (может подключаться к узлам по ssh из командной строки, но OpsCenter не может

Я настраиваю новый кластер C* и использую apt-get для установки OpsCenter 4.0; который подошел нормально и увидел все мои узлы.

У меня настроен файл ~/.ssh/id_dsa, и я могу подключиться к своим узлам по ssh без пароля.

Я попытался настроить OpsCenter для установки агентов через «исправление»... предоставив закрытый ключ в диалоговом окне «Учетные данные узла SSH»… но я получаю сообщение «Не удалось подключиться по SSH к... Ошибка вывода: Отказано в доступе (открытый ключ).

Я озадачен, как я могу ssh из строки cmd, но OpsCenter не может.

Затем я попытался установить агенты вручную (снова используя apt-get и запуск службы opscenterd-agent), но я получаю это в файле /var/log/datastax-agent/startup.log:

 INFO [main] 2013-12-13 13:25:11,035 Loading conf files: /var/lib/datastax-agent/conf/address.yaml
Exception in thread "main" java.lang.ClassCastException: java.lang.Character cannot be cast to java.util.Map$Entry
        at opsagent.conf$load_conf_file$fn__1185$fn__1186.invoke(conf.clj:197)
        at clojure.core$map$fn__4207.invoke(core.clj:2487)
        at clojure.lang.LazySeq.sval(LazySeq.java:42)
        at clojure.lang.LazySeq.seq(LazySeq.java:60)
        at clojure.lang.RT.seq(RT.java:484)
        at clojure.core$seq.invoke(core.clj:133)
        at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30)
        at clojure.core.protocols$fn__6026.invoke(protocols.clj:54)
        at clojure.core.protocols$fn__5979$G__5974__5992.invoke(protocols.clj:13)
        at clojure.core$reduce.invoke(core.clj:6177)
        at clojure.core$into.invoke(core.clj:6229)
        at opsagent.conf$load_conf_file.invoke(conf.clj:195)
        at clojure.core$map$fn__4207.invoke(core.clj:2487)
        at clojure.lang.LazySeq.sval(LazySeq.java:42)
        at clojure.lang.LazySeq.seq(LazySeq.java:60)
        at clojure.lang.RT.seq(RT.java:484)
        at clojure.core$seq.invoke(core.clj:133)
        at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30)
        at clojure.core.protocols$fn__6026.invoke(protocols.clj:54)
        at clojure.core.protocols$fn__5979$G__5974__5992.invoke(protocols.clj:13)
        at clojure.core$reduce.invoke(core.clj:6177)
        at clojure.core$into.invoke(core.clj:6229)
        at opsagent.conf$load_conf.invoke(conf.clj:209)
        at opsagent.opsagent$_main.doInvoke(opsagent.clj:228)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at opsagent.opsagent.main(Unknown Source)

(мой файл address.yaml: stomp_interface=1.2.3.4 // с разными номерами, конечно

Я использовал предыдущие версии C* и OpsCenter в течение многих лет, но теперь я застрял, чтобы запустить эту версию.


ssh cassandra datastax opscenter
person Brian Tarbox    schedule 13.12.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Вы используете "=", где синтаксис yaml ожидает ":". Итак, как должна выглядеть ваша строка stomp_interface:

stomp_interface: 1.2.3.4

Вам нужно будет перезапустить агент datastax, чтобы это вступило в силу.

person mbulman    schedule 16.12.2013
comment
Это изменение не имеет значения. Я все еще получаю ClassCastException. Я видел, как другие приписывают эту ошибку дублированию файлов jar агента, но здесь это тоже не так. - person Brian Tarbox; 16.12.2013

arrow_upward
-2
arrow_downward

Я ввел свой закрытый ключ ssh в ~/.ssh/id_dsa (я работаю на EC2 как пользователь «ubuntu».

По прихоти я искал другие каталоги .ssh и нашел /root/.ssh.

Я скопировал файл id_dsa в этот каталог, и на этот раз OpsCenter смог связаться со всеми узлами в моем кластере и установить агент.

Хотя это «решает» проблему, это немного неудовлетворительно, поскольку в инструкциях OpsCenter ничего не говорится об этом, и я не уверен, откуда я должен был знать, что нужно искать этот другой каталог .ssh. С другой стороны, это работает :-).

person Brian Tarbox    schedule 16.12.2013
comment
Для чего это стоит, этот шаг не должен быть необходим. OpsCenter должен иметь возможность использовать тот же ключ и пользователя, которые вы используете из командной строки для входа в узлы. - person nickmbailey; 17.12.2013
comment
Я согласен, что это не должно быть необходимо, но это было. Не знаю, почему за ответ, который устраняет проблему, проголосовали, тем более что альтернатив не было предложено. - person Brian Tarbox; 17.12.2013
comment
Ну, на самом деле в вашем посте поставлены две проблемы. Опубликованная вами трассировка стека определенно была вызвана ошибкой форматирования yaml. Я до сих пор не уверен, что вызвало вашу ошибку ssh. Похоже, ваше решение состояло в том, чтобы сделать ваш закрытый ключ закрытым ключом по умолчанию для пользователя root (под которым работает opscenter). Вы вставляли фактическое содержимое закрытого ключа в OpsCenter? Включая начальный и конечный комментарии? - person nickmbailey; 17.12.2013
comment
Ну... Я получил точно такую ​​же трассировку стека после исправления ошибки форматирования yaml, так что это была не ошибка. Учитывая тот факт (о котором я не знал), что OpsCenter работает от имени пользователя root, то размещение id_dsa в файле .ssh пользователя root является прекрасным решением, на самом деле, по моему опыту, именно так обычно обрабатываются соединения ssh. - person Brian Tarbox; 17.12.2013
comment
Мое единственное предположение состоит в том, что были дополнительные ошибки форматирования yaml или что вы редактировали conf, содержащийся в архиве, используемом для ручной установки, а не /var/lib/datastax-agent/conf/address.yaml, возможно. Причина, по которой добавление ключа — не лучший обходной путь, заключается в том, что OpsCenter не будет работать от имени пользователя root при других типах установки (rpm, tarball), и хотя в этом случае он работает, не гарантируется работать в будущем. - person nickmbailey; 18.12.2013
comment
На самом деле я использовал сценарий, содержащийся в документации DataStax, для создания файла yaml и только случайно поменял местами :/= при создании вопроса StackOverFlow. - person Brian Tarbox; 19.12.2013