2 votes

Le démarrage de Juju donne ""ERROR could not access file '*-provider-state' gomaasapi : got error back from server : 403 forbidden."

Nous essayons d'amorcer Juju sur une autre machine dans le nuage MAAS mais nous obtenons un "ERROR could not access file *-provider-state gomaasapi : le serveur a renvoyé une erreur : erreur "403 forbidden".

Quand nous courrons juju bootstrap un fichier .jenv est créé et cette erreur est retournée avec le * dans le '*-provider-state' remplacé par le nom de l'agent Juju du nœud MAAS. Lorsque nous supprimons l'environnement (en supprimant le fichier .jenv), la même erreur est renvoyée mais le nom de fichier est juste listé comme 'provider-state'. Le nœud ne passe pas à l'état Allocated même si le fichier .jenv est créé. Exécuter quoi que ce soit - juju bootstrap, juju status, juju destroy-environment, donne la même erreur.

Backstory : Il y avait auparavant un environnement Juju amorcé sur ce serveur MAAS. Nous avons dû modifier nos configurations réseau et nous n'avons pas réussi à supprimer le nœud alloué. Nous avons donc pensé que nous pouvions désinstaller Juju et recommencer. Manifestement, cela n'a pas fonctionné et il en reste quelques liens sur notre serveur. Comment s'en débarrasser ? Nous avons réussi à supprimer le nœud alloué en utilisant le maas Shell mais cette erreur persiste.

Nous utilisons MAAS 12.04 LTS, Juju 1.16.

2voto

dimitern Points 2015

Tout d'abord, supprimer le fichier .jenv. n'est pas détruire l'environnement, cela rend juste impossible de s'y connecter à partir de votre client juju. Le fichier .jenv contient toutes les informations nécessaires pour se connecter à l'environnement, y compris les adresses des serveurs API juju, les certificats SSL, etc.

Pour détruire un environnement juju, utilisez : $ juju destroy-environment my-maas-env-name -y

Cela désallouera correctement les nœuds MAAS, supprimera les entrées de stockage, y compris l'élément fournisseur-état fichier.

De même, la réinstallation de juju sur votre machine cliente ne peut pas résoudre votre problème, car l'environnement et ses nœuds alloués sont toujours là et pour MAAS, il apparaît que vous utilisez toujours l'environnement.

Pour résoudre votre problème spécifique, je ferais ce qui suit :

  • Votre environnement n'est plus accessible parce que le fichier .jenv a disparu, et comme il est généré automatiquement, vous ne pouvez pas retrouver l'accès à l'environnement en créant simplement un fichier .jenv vide.
  • Supprimez le fichier .jenv s'il est toujours présent.
  • Connectez-vous en tant qu'administrateur MAAS dans l'interface web MAAS, allez dans "Nodes" et pour chaque nœud alloué, cliquez sur le nœud et cliquez sur "Stop node" sur la page du nœud. Ceci désallouera le nœud et le ramènera à l'état d'origine. Prêt .
  • À l'aide de l'interface CLI de MAAS, vous pouvez dresser la liste de tous les fichiers du stockage de l'environnement : $ maas my-maas-session files list et supprimer le fichier provider-storage : $ maas my-maas-session file delete XXXX-provider-storage (le nom exact du fichier que vous obtenez à partir de la liste des fichiers, il ressemblera à c4ba50c2-268c-4cf4-8be1-c0903982c8a8-provider-state ; et my-maas-session correspond à votre session utilisateur CLI - il peut s'agir de n'importe quelle chaîne, créée avec, par exemple. $ maas login my-session-name http://192.168.50.2/MAAS/ <maas-api-key> - utiliser la même clé que celle spécifiée avec "maas-oauth" dans environments.yaml)
  • Bootstrap encore, une fois que c'est fait, ça devrait marcher.

J'espère que cela vous aidera,

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X