Rudder

François ARMAND a écrit:

Pour 1/ encore, pourquoi pas, ca peut faire partie d'une configuration normale.
Mais pour 2 (et donc 3), c'est vraiment trop contraignant. Je pense comprendre la raison (les politiques d'autorisation dans cf-serverd.cf sont faites avec les hostnames, c'est une IP qui tente de se connecter, il faut bien faire le lien), mais cela implique qu'on ne peut pas tester facilement Rudder.

Si j'ai mal fait une partie de l'installation, je veux bien refaire en modifiant ma procédure.

S'il y a des contournement simples, il faudrait les donner dans la documentation utilisateur.

Non, et non. Tu as certainement bien fait, mais je n'ai jamais utilisé un environnement sans DNS complet (ce serait sale :p). En revanche, je constate le même problème dans un use case plus courant sur de la prod : mon noeud N1 se connecte via une IP VPN, dont l'IP != host(N1). Sa connexion est donc refusée.

Je propose d'ajouter un warning dans la doc utilisateur, recommandant d'avoir soit une bonne config DNS, soit un /etc/hosts contenant les IP/noms utilisés. Et hop, une idée de PT en plus !

A plus long terme, il faudrait réfléchir à une solution qui prendrait en compte à la fois les IP et les hostnames pour les autorisations de mise-à-jour (mais comme ca, je n'ai pas d'idées qui ne débouchent pas sur un trou de sécu).

En quoi considères-tu, par exemple, qu'autoriser la connexion par toutes les IP du noeud tel que repértoriées par l'inventaire est un trou de sécu ?

I feel that this has already been, at least, partly solved. Can you update the ticket François if you agree ? Thanks :)

This is solved by the key-based authorizations in 4.0, closing.