Ceci est la sortie de juju à partir d'une installation propre avec 2 nœuds exécutant tous le bootstrap juju 12.04 - se termine sans erreur et alloue la machine à l'utilisateur mais toujours pas de joie après la destruction et la reconstruction de l'environnement juju avec différents utilisateurs et différents nœuds.
[email protected]:/storage# juju -v status
2012-06-07 11:19:47,602 DEBUG Initializing juju status runtime
2012-06-07 11:19:47,621 INFO Connecting to environment...
2012-06-07 11:19:47,905 DEBUG Connecting to environment using node-386077143930...
2012-06-07 11:19:47,906 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="node-386077143930" remote_port="2181" local_port="57004".
The authenticity of host 'node-386077143930 (10.5.5.113)' can't be established.
ECDSA key fingerprint is 31:94:89:62:69:83:24:23:5f:02:70:53:93:54:b1:c5.
Are you sure you want to continue connecting (yes/no)? yes
2012-06-07 11:19:52,102 ERROR Invalid SSH key
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:host.name=cloudcontrol
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.name=Linux
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.arch=3.2.0-23-generic
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.name=sysadmin
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.home=/root
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.dir=/storage
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Initiating client connection, host=localhost:57004 sessionTimeout=10000 watcher=0x7feb11afc6b0 sessionId=0 sessionPasswd=<null> context=0x2dc7d20 flags=0
2012-06-07 11:19:52,429:18541(0x7feb0e856700):[email protected][email protected]: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
2012-06-07 11:19:55,765:18541(0x7feb0e856700):[email protected][email protected]: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
- J'ai essayé de nombreuses façons de créer les clés avec ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen, et j'ai essayé de les ajouter à la page de configuration Web MAAS, mais toujours obtenir le même résultat.
- J'ai ensuite ajouté la clé publique appropriée au
~/.ssh/authorized_keys - Je peux également me connecter en ssh au nœud, mais comme on ne m'a pas demandé de lui donner un nom d'utilisateur ou un mot de passe ou de créer un compte, je ne peux pas me connecter manuellement en ssh au nœud. La configuration du nœud est entièrement gérée par le serveur maas. Cela ressemble à une simple erreur de regarder la mauvaise clé ou de regarder aux mauvais endroits, seules les autres suggestions que je peux trouver sont de détruire l'environnement et de reconstruire (mais cela n'a pas fonctionné une multitude de fois maintenant) ou de le laisser construire l'instance une fois le nœud sous tension, mais je suis parti pendant quelques heures, et laissé toute la nuit pour construire sans succès.
Réponse acceptée :
La solution que j'ai trouvée consiste à définir un mot de passe pour les nœuds nouvellement démarrés, puis à insérer manuellement des clés SSH dans chacun d'eux. Pour définir un mot de passe de démarrage pour l'utilisateur Ubuntu, assurez-vous que les lignes suivantes dans /var/lib/cobbler/kickstarts/maas.preseed :
d-i passwd/make-user boolean true
d-i passwd/user-fullname ubuntu
d-i passwd/username string ubuntu
d-i passwd/user-password-crypted password <CRYPTED PASSWORD>
Une fois cela fait, vous pouvez ssh [email protected] et utiliser le mot de passe spécifié dans la chaîne de mot de passe cryptée (le moyen le plus simple est d'en utiliser un à partir d'un fichier /etc/shadow que vous connaissez déjà) pour vous connecter. Vous pouvez ensuite insérer votre SSH clés publiques sous ~ubuntu/.ssh/authorized_keys et ~root/.ssh/authorized keys.
Connexes :Problème avec le GPU Nvidia et Ubuntu 16.04 ?Notez qu'il s'agit d'une solution de contournement - une fois que vous avez ssh-keygen, MaaS doit soit extraire l'id_rsa.pub de votre répertoire .ssh, soit de l'interface Web MaaS, où l'utilisateur peut spécifier une clé publique dans son profil. Peu importe ce que j'ai essayé, ces clés ne sont pas propagées, j'ai donc trouvé la solution de contournement.
Une autre triche consiste simplement à ajouter la clé .pub aux .ssh/authorized_keys de votre nœud MaaS, puis à la scp sur chacun des nœuds du MaaS :
for i in `cobbler system list |grep -v default`;
do j=`cobbler system dumpvars --name "${i}" | grep hostname |grep -v duplicate |cut -f 2 -d \:`;
scp ~/.ssh/authorized_keys [email protected]${j}:.ssh/authorized_keys;
done
Cela vous permet d'accepter à plusieurs reprises les erreurs de certificat SSH et de saisir le mot de passe dans la chaîne cryptée pour remplir l'ensemble de votre MaaS avec la clé publique SSH.