Podczas wykonywania puppet agent
połączenia z nowego obrazu pojawia się err: Could not find class custommod
błąd. Sam moduł jest /etc/puppet/modules/custommod
taki sam jak wszystkie inne moduły, które wywołujemy, ale ten jest uparty.
[site.pp]
node /clunod-wk\d+\.sub\.example\.local/ {
include base
include curl
include custommod
class{ "custommod::apps": frontend => "false}
[...]
}
Gdy puppetmaster jest uruchamiany z wyjściem debugowania, wyraźnie znajduje informacje o bazie i 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
Linia 84 jest include custommod
Skrócona struktura katalogów i plików:
/etc/puppet
|- manifests
| |- site.pp
|
|- modules
|- base
| |- manifests
| |- init.pp
|
|- curl
| |- manifests
| |- init.pp
|
|- custommod
|- files
| |- apps
| |- [...]
|
|- manifests
|- init.pp
|- apps.pp
Sprawdziłem pisownię:}
Treść init.pp
w katalogu klienta jest całkowicie nieistotna:
class custommod {
}
Celem jest utworzenie pustej klasy dla pliku apps.pp, czyli tam, gdzie znajduje się mięso.
class custommod::apps {
[lots of stuff]
}
Tylko nigdy nie dostaje się do pliku aplikacji. Jeśli to skomentuję include custommod
, powyższy błąd zostanie wygenerowany w class{ "custommod::apps": frontend => "false}
wierszu.
Czego mi brakuje podczas polowania, aby dowiedzieć się, jak generowany jest ten błąd? Muszę zauważyć, że to repozytorium działa dobrze, jeśli jest uruchamiane lokalnie przez puppet apply
.
źródło
could not retrieve catalog from remote server:
błąd, prawdopodobnie dlatego.custommod
- może nawet spróbowaćinit.pp
całkowicie usunąć , ponieważ nie powinno to być potrzebne.strace
na nią okiem i spróbować dowiedzieć się, jakie pliki próbuje odczytać w ten sposób.Odpowiedzi:
Więc ... to trochę zawstydzające, ale ...
Środowiska.
W moim
/etc/puppet.conf
pliku jest to:Po rzuceniu
strace
go, aby dowiedzieć się, gdzie szuka plików, zauważyłem coś. Szukał pod sprytem/etc/puppet/environments/production/modules
, a ponieważ był tam katalog (pusty), nie sprawdził/etc/puppet/modules
. Najwyraźniej podczas importowania modułu sprawdza obecność katalogu, a nie obecność pliku (init.pp).Usuń ten pusty katalog, wszystko zacznie działać.
Uruchom agenta marionetek w innym środowisku, wszystko zacznie działać.
Morał historii:
źródło
puppet config print modulepath
.Natrafiłem na ten sam problem, ale miałem inną poprawkę
Jeśli wygenerujesz taki moduł lalek:
Stworzy moduł o nazwie
example_module
zfoo
przestrzenią nazw. Wszystkie manifesty będą znajdować się w katalogu o nazwiefoo-example_module
Nazwa klasy zdefiniowanej w pliku init.pp musi być taka sama jak nazwa folderu.
Prosta poprawka:
Jeśli uruchomisz marionetkę, pojawi się następujący komunikat:
Jeśli używasz pliku Puppetfile z r10k lub librarian-puppet, może być również konieczne usunięcie przestrzeni nazw, aby pliki były umieszczane bez prefiksu „foo” w katalogu modułów.
przed:
po:
źródło
Innym problemem, który może się zdarzyć, jest niepoprawny
metadata.json
plik modułu .Upewnij się, że
metadata.json
plik ma wszystkie wymagane pola (patrz https://docs.puppet.com/puppet/latest/reference/modules_metadata.html#allowed-keys-in-metadatajson )źródło
Wystąpił podobny problem z marionetką 3.7.1 dla Fedory: Nie można znaleźć marionetki klasowej dla mojego serwera
Rozwiązanie:
To działa.
źródło
Miałem podobny problem. W moim przypadku nazwa klasy to „onehost :: change_IoT_password_reminder”. Po użyciu strace odkryłem, że marionetka szukała pliku modułów / onehost / manifests / change_iot_password_reminder.pp. Wydaje się, że używanie wielkich liter w nazwach klas nie jest dobrym pomysłem, nawet jeśli nie jest to pierwsza litera klasy.
źródło