web-dev-qa-db-fra.com

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

Lors d'une puppet agent appel d'une nouvelle image, je reçois un err: Could not find class custommod Erreur. Le module lui-même est dans /etc/puppet/modules/custommod identique à 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.pp dans le répertoire custommod 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 ne parvient jamais au fichier des applications. Si je commente le include custommod, l'erreur ci-dessus est générée sur le class{ "custommod::apps": frontend => "false} ligne à la place.

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.

puppetpuppetmaster
31
sysadmin1138

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

Environnements.

Juste là dans mon /etc/puppet.conf le fichier est le suivant:

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

Après avoir lancé strace dessus pour comprendre où il cherchait des fichiers, j'ai remarqué quelque chose. Il cherchait un établissement sous /etc/puppet/environments/production/modules, et comme il y avait un répertoire (vide), il n'est pas ensuite 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.

32
sysadmin1138

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_module avec l'espace de nom foo. 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 => [email protected]:foo/example_module'

après:

mod 'example_module',
    :git => [email protected]:foo/example_module'
4
spuder

Un autre problème qui peut se produire est lorsque votre module a un fichier metadata.json Invalide.

Assurez-vous que le fichier metadata.json Possède tous les champs obligatoires (voir https://docs.puppet.com/puppet/latest/reference/modules_metadata.html#allowed-keys-in-metadatajson =)

2
Nico

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.

0
Geoff Crompton

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
Haibo Liu