Impossible de trouver la classe, et pourtant elle est là


31

Lorsque puppet agentje fais un appel à partir d'une nouvelle image, je reçois une err: Could not find class custommoderreur. Le module lui-même est /etc/puppet/modules/custommodidentique à tous les autres modules que nous appelons, mais celui-ci est obstinante.

[site.pp]

node /clunod-wk\d+\.sub\.example\.local/ {
      include base
      include curl
      include custommod
      class{ "custommod::apps": frontend => "false}
      [...]
}

Lorsque le marionnettiste est exécuté avec une sortie de débogage, il trouve clairement les informations de base et de curl:

debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production
debug: Automatically imported base from base into production
debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production
debug: Automatically imported curl from curl into production
err: Could not find class custommod for clunod-wk0130.sub.example.local at /etc/puppet/manifests/site.pp:84 on node clunod-wk0130.sub.example.local

La ligne 84 est include custommod

Un répertoire abrégé et une structure de fichiers:

/etc/puppet
   |- manifests
   |     |- site.pp
   |
   |- modules
         |- base
         |    |- manifests
         |          |- init.pp
         |
         |- curl
         |    |- manifests
         |          |- init.pp
         |   
         |- custommod
              |- files 
              |     |- apps
              |         |- [...]
              |
              |- manifests
                    |- init.pp
                    |- apps.pp

J'ai vérifié l'orthographe:}

Le contenu de init.ppl'annuaire des clients est complètement banal:

class custommod {
}

L'objectif est de créer une classe vide pour le fichier apps.pp, où se trouve la viande.

class custommod::apps {

    [lots of stuff]
}

Seulement, il n'atteint jamais le fichier des applications. Si je commente le include custommod, l'erreur ci-dessus est générée à la class{ "custommod::apps": frontend => "false}place sur la ligne.

Que manque-t-il dans ma chasse pour savoir comment cette erreur est générée? Je dois noter que ce dépôt fonctionne très bien s'il est exécuté localement via puppet apply.


Avez-vous pris un pic dans le fichier client yaml pour voir si votre classe est présente?
Zoredache

@Zoredache Le répertoire / var / lib / puppet / client_yaml / est vide sur le client. Le client reçoit une could not retrieve catalog from remote server:erreur qui est probablement la raison.
sysadmin1138

Hrm .. a recréé votre mise en page de base et votre structure d'importation et n'a pas pu reproduire le problème (sur 2.7.1). Il devrait être sûr d'arrêter d'inclure le vide custommod- peut-être même essayer de supprimer init.ppcomplètement, car cela ne devrait pas être nécessaire.
Shane Madden

@ShaneMadden Après avoir essayé cela, ma prochaine étape est de jeter stracedessus et d'essayer de comprendre quels fichiers il essaie de lire de cette façon.
sysadmin1138

Réponses:


32

Donc ... c'est un peu gênant, mais ...

Environnements.

Là, dans mon /etc/puppet.confdossier, voici:

[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules

Après avoir jeté stracedessus pour comprendre où il cherchait des fichiers, j'ai remarqué quelque chose. Il cherchait un logement sous /etc/puppet/environments/production/modules, et comme il y avait un répertoire (vide), il n'est pas allé vérifier/etc/puppet/modules . Apparemment, lors de l'importation d'un module, il vérifie la présence du répertoire plutôt que la présence du fichier (init.pp).

Supprimez ce répertoire vide, les choses commencent à fonctionner.

Exécutez l'agent marionnette en utilisant un environnement différent, les choses commencent à fonctionner.

Morale de l'histoire:

Les chemins de l'environnement de marionnettes n'agissent pas comme bash $ PATH.


8
Et si quelqu'un n'a pas défini explicitement son modulepath dans puppet.conf, et qu'il souhaite découvrir le modulepath de puppet sans recourir à strace, il peut également s'exécuter puppet config print modulepath.
Alison R.

1
cela a-t-il été signalé aux puppetlabs?
Felipe Alvarez

3
Le modulepath déclenche désormais un avertissement de dépréciation.
Magellan

4

J'ai rencontré ce même problème, mais j'ai eu une solution différente

Si vous générez un module marionnette comme ceci:

puppet module generate foo-example_module

Il créera un module nommé example_moduleavec l' fooespace de nom. Tous les manifestes seront dans un répertoire appeléfoo-example_module

Le nom de la classe définie dans init.pp doit être le même que le nom du dossier.

Solution simple:

mv foo-example_module example_module

Si vous exécutez puppet-lint, il vous avertira avec le message suivant:

ERROR: example_module not in autoload module layout on line 42

Si vous utilisez un Puppetfile avec r10k ou librarian-puppet, vous devrez peut-être également supprimer l'espace de nom afin que les fichiers soient placés sans le préfixe 'foo' dans le répertoire de vos modules.

avant:

mod 'foo-example_module',
    :git => git@github.com:foo/example_module'

après:

mod 'example_module',
    :git => git@github.com:foo/example_module'


0

A rencontré un problème similaire avec la marionnette 3.7.1 pour Fedora: impossible de trouver la marionnette de classe pour my.server

Solution:

sudo ln -s /my/local/copy/puppet/modules /etc/puppet/

Alors ça marche.


0

J'avais un problème similaire. Dans mon cas, le nom de la classe était "onehost :: change_IoT_password_reminder". Après avoir utilisé strace, j'ai trouvé que la marionnette recherchait un fichier modules / onehost / manifests / change_iot_password_reminder.pp. Il semble que l'utilisation de majuscules dans les noms de classe ne soit pas une bonne idée, même si ce n'est pas la première lettre de la classe.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.