Faca SSH não encontra meus nós

12

knife sshnão está encontrando meus nós. Eu sei que deveria poder, porque quando eu posso procurá-los, eu os encontro

# knife search node name:*
2 items found

Node Name:   web_01
...

Node Name:   admin
...

No entanto, quando eu corro knife ssh(mostrarei com o sinalizador 'debug'), recebo

# knife ssh "node:*" "uptime" -VV
DEBUG: Using configuration from /root/.chef/knife.rb
DEBUG: Signing the request as dev
DEBUG: Sending HTTP Request via GET to ec2-xx-xx-xx-xx.compute-1.amazonaws.com:4000/search/node
FATAL: No nodes returned from search!

(sim, o host está correto, eu apenas o censurei no post).

Tentei modificar o parâmetro QUERY e sempre obtive os mesmos resultados. Eu tentei:

nó:*
Função:*
*
*: *

Alguma ideia?

chef knife

— Máx.
fonte

16

Eu descobri. meus nós não tinham um fqdn. Eu tive que especificar -a ipaddress. a mensagem de erro não foi útil. Eu descobri isso depurando o código ssh da faca. também há um erro que não lê o atributo no arquivo de configuração da faca. Vou abrir um chamado sobre o problema e talvez enviar um patch.

O que fiz para superar isso foi colocar o nome do host do nó do chef no meu arquivo / etc / hosts com um ponteiro para o endereço IP. Por exemplo:

10.3.3.100 chef-client.int

Você também pode, é claro, sempre colocá-lo em um servidor DNS, junto com o restante dos nós. Isso resolveria completamente o problema.

— Máx.
fonte

7

Para esclarecer para outros leitores, " -a ipaddress" é literal. Aparentemente, diz knife sshpara conectar por IP e não FQDN. Esse comportamento é idiota - ele deve fazer o fallback dessa maneira por padrão.

— 21712 Steve Bennett

@SteveBennett Concordo que deveria ser um comportamento padrão. Vejo como minha postagem pode ser confusa. Obrigado por esclarecer.

— Max

4

Além disso, se -a ipaddressnão funcionar, tente-a cloud.public_ipv4

Foi-me mostrada essa solução depois de descobrir que knife sshestava tentando usar endereços IP internos para meus nós e demorou algumas perguntas no canal IRC do chef (#chef em irc.freenode.net) antes que alguém chamado retr0h me mostrasse isso .

— jLi
fonte

incrível, obrigado! @all se você estiver executando EC2, e suas instâncias foram criados com IP público, mas hostname é apontado a um local, use o seguinte:knife ssh 'name:mydc1*' interactive -a node.node_name

— Ilja

0

Tente knife ssh "id:*" "uptime".

Lembre-se de que knife sshessencialmente faz a knife search node, portanto sua consulta deve ser aquela que funciona knife search node(ou seja, knife search node "node:*"não funciona). knife ssh "role:*"também deve funcionar, mas somente se seus nós tiverem funções atribuídas a eles. Nesse caso, o original knife search node "name:*"também deve funcionar assim que você redirecionar a consulta knife ssh. Então knife ssh "name:*" "uptime",.

— cjc
fonte

1

Obrigado pela resposta, mas eu aposto "Nenhum nós" tanto para id: * e name: *

— Max

OK, isso é bizarro (ou seja, funciona para mim). Ocasionalmente, tive que chutar chef-solr para que novos objetos aparecessem na pesquisa, mas, se você estiver obtendo resultados do "nó de pesquisa de facas", deverá obter a mesma lista de nós usada pelo "faca ssh" . Não sei para onde procurar a seguir se a lista de resultados for diferente.

— CJC

0

Você já tentou alguma vez knife ssh "name:*" "uptime" ?

Estou usando o chef 10.xe funciona para mim.

Na minha opinião, ao usar knife search [INDEX] [QUERY], o primeiro parâmetro INDEXé usado para especificar o tipo do item a ser consultado. Ao usar o knife sshcomando, ele sabe que você está tentando procurar nós; portanto, tudo o que você precisa fazer é especificar a [QUERY]peça, que é o name:*seu caso.

— ley
fonte

Acho que a resposta do @cjc significa o mesmo.

— ley

0

Eu resolvi isso usando ssh / config e conectando pelo fqdn.

— h4ck3rm1k3
fonte