HDP 2.5 Hortonworks ambari-admin-password-reset manquant

J’ai téléchargé le sandbox depuis hortonworks (Centos OS), puis j’ai essayé de suivre le tutoriel . Il semble que la commande ambari-admin-password-reset soit absente et manquante. J’ai aussi essayé de me connecter avec du mastic, la console m’a demandé de changer le mot de passe alors je l’ai fait. maintenant, il semble que la commande est là , mais j’ai des mots de passe différents pour la console et un pour le mastic pour le même utilisateur.

J’ai essayé de trouver la raison pour laquelle, pour le même utilisateur, «root», j’ai deux mots de passe différents (un pour la console de boîte virtuelle et un pour le mastic) auxquels je peux me connecter. Je vois différentes commandes sur chaque boîte. plus que cela quand je partage le dossier je ne peux le voir que sur la console de la boîte virtuelle mais pas sur la console de mastic) ce qui est vraiment frustrant.

Comment puis-je affirmer que ce que je verrais du mastic serait le même que ce que je vois de la console de la boîte virtuelle?

Je pense que ça a un rapport avec TTY mais je ne suis pas sûr.

EDIT: exécuter des commandes à partir de la sortie de la machine virtuelle:

grep "^passwd" /etc/nsswitch.conf 

OUT : passwd: fichiers sss

 grep root /etc/passwd 

OUT : rppt “x” 0 “0” racine: / root: opérateur / bin / bash: x: 11: 0: opérateur: / root: / sbin / nologin

 getent passwd root 

OUT : root: x: 0: 0: root: / root: / bin / bash

EDIT: Je pense que tout cela concerne les conteneurs Docker. Il semble que le port machine 2222 soit le port ssh du conteneur hdp 2.5 et non de la machine hôte. Maintenant, j’ai un autre problème. en cours d’exécution

 docker exec sandbox ls 

ça se coince. de l’aide ?

Merci pour les aides

Alors maintenant, j’ai eu le temps d’parsingr la vm sandbox et de l’écrire pour les autres utilisateurs. Comme vous l’avez indiqué correctement dans votre édition de la question, il s’agit de la configuration du conteneur Docker du sandbox, qui confond avec deux utilisateurs root distincts:

  • via ssh [email protected] -p 2222 vous entrez dans le conteneur de docker appelé “sandbox”. Ceci est une version 6.8 de CentOS (Final), contenant tous les services HDP, en particulier le service ambari. La configuration impose un changement de mot de passe lors de la première connexion pour l’utilisateur root. A l’intérieur de cette VM, vous pouvez également exécuter l’ ambari-admin-password-reset et définir un mot de passe pour l’administrateur d’ambari.

  • via l’access à la console, vous accédez à l’hôte docker exécutant un Centos 7.2, ici vous pouvez vous connecter avec le mot de passe root par défaut pour la machine virtuelle tel que trouvé dans les documents HDP.

Venir à votre sous-question avec l’exécutable docker suspendu, cela semble être un bogue dans cette version spécifique du docker. Si vous google cela, vous trouverez des problèmes concernant ce problème ou d’autres problèmes similaires avec docker. J’ai donc pensé que ce serait une bonne idée de simplement mettre à jour l’hôte via la yum update . Cependant, cela s’est avéré être un chemin difficile.

yum a essayé de mettre à jour le kernel, mais s’est plaint qu’il n’y a pas assez d’espace sur le partion de démarrage.

J’ai donc déplacé le partion de démarrage vers la partition racine:

  1. éditez / etc / fsab et commentez l’entrée de démarrage
  2. démonter / démarrer
  3. mv / boot
  4. cp -a /boot.org / boot
  5. grub2-mkconfig -o /boot/grub2/grub.cfg
  6. grub2-install / dev / sda
  7. redémarrer

Après cela, j’ai découvert que la configuration du docker est cassée et que le docker ne démarre plus. Dans les journaux se sont plaints de

“Erreur lors du démarrage du démon: erreur lors de l’initialisation de graphdriver: \” / var / lib / docker \ “contient d’autres graphdrivers: devicemapper; veuillez nettoyer ou choisir explicitement le pilote de stockage (-s)”

J’ai donc modifié /etc/systemd/system/multi-user.target.wants/docker.service et modifié le paramètre ExecStart sur:

 ExecStart=/usr/bin/dockerd --storage-driver=overlay 

Après un service docker start et un docker start sandbox . Le conteneur a fonctionné à nouveau et je pouvais me connecter au conteneur et après un redémarrage du serveur ambari, tout fonctionnait à nouveau.

Et maintenant – avec la nouvelle version de docker 1.12.2, docker exec sandbox ls fonctionne à nouveau.

Donc, pour résumer, la commande docker exec a un bogue dans cette version spécifique du sandbox, mais vous devriez réfléchir à deux fois si vous voulez mettre à jour votre sandbox.

J’ai rencontré le même problème. Le sandbox HDP 2.5 exécute tous ses composants dans un conteneur Docker, mais les commandes telles que docker exec -it sandbox /bin/bash ou docker attach sandbox été bloquées.

Lorsque j’ai exécuté un ps aux , j’ai trouvé plusieurs commandes /usr/bin/docker-proxy qui ressemblaient à: /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 60000 -container-ip 172.17.0.2 -container-port 60000

Ils transmettent probablement les ports HTTP des différentes interfaces utilisateur des composants HDP.

Je pourrais ssh dans le conteneur ip (ici 172.17.0.2) en utilisant root / hadoop pour s’authentifier. De là, je pourrais utiliser toutes les commandes “manquantes” comme ambari-admin-password-reset.

$ ssh [email protected] ... # change password $ ambari-admin-password-reset

NB: Je suis nouveau sur Docker, donc il y a probablement une meilleure façon de gérer cela.