2 votes

Comment s'abonner au paquet provenant du tableau de Hiera ?

J'ai les éléments suivants dans les définitions de ma hiérarchie :

# common.json
{
  "classes": [
    "sysbase",
  ],
  "sysbase::packages": [
    "less", "build-essential", "bash"
  ]
}

# dev.local.json
{
  "sysbase::packages": [
    "xmltv"
  ]
}

Et la classe suivante :

# modules/sysbase/manifests/init.pp
class sysbase($packages){
  package{ $packages :
    ensure => latest,
  }

  exec{'select-pager':
    command     => '/usr/sbin/update-alternatives --set pager /bin/less',
    user        => 'root',
    refreshonly => true,
    subscribe   => Package['less'],
  }
}

Quand je lance l'agent sur ce noeud :

$ facter hostname fqdn domain
domain => dev.local
fqdn => francois.dev.local
hostname => francois

Je reçois cette erreur :

Error: Could not retrieve catalog from remote server:
  Error 400 on SERVER:
    Invalid relationship:
      Exec[select-pager] { subscribe => Package[less] },
      because Package[less] doesn't seem to be in the catalog

(reformaté pour plus de lisibilité)

Pour moi, il est évident que le moins de paquet est inclus. Quand je demande à Hiera, elle me le dit même :

# hiera --array sysbase::packages ::hostname=francois ::domain=dev.local ::fqdn=francois.dev.local
[...
 "less",
 "build-essential",
 "bash"]

Les paquets Puppet installés sur le master sont :

# dpkg -l | grep -i puppet
ii  facter                           2.3.0-1puppetlabs1                  Ruby module for collecting simple facts about a host operating system
ii  hiera                            1.3.4-1puppetlabs1                  A simple pluggable Hierarchical Database.
ii  puppet                           3.7.3-1puppetlabs1                  Centralized configuration management - agent startup and compatibility scripts
ii  puppet-common                    3.7.3-1puppetlabs1                  Centralized configuration management
ii  puppetdb                         2.2.2-1puppetlabs1                  PuppetDB Centralized Storage.
ii  puppetdb-terminus                2.2.2-1puppetlabs1                  Connect Puppet to PuppetDB by setting up a terminus for PuppetDB.
ii  puppetlabs-release               1.0-11                              "Package to install Puppet Labs gpg key and apt repo"
ii  puppetmaster-common              3.7.3-1puppetlabs1                  Puppet master common scripts
ii  puppetmaster-passenger           3.7.3-1puppetlabs1                  Centralised configuration management - master setup to run under mod passenger
ii  ruby-rgen                        0.6.5-1puppetlabs1                  A framework supporting Model Driven Software Development (MDSD)

# puppet --version
3.7.3

Le pire, c'est que tous mes agents Puppet ne signalent pas la même erreur !

Pourquoi le paquet moins n'est-il pas reconnu ? Est-ce parce qu'il est dans un tableau ?

2voto

Felix Frank Points 3033

Étant donné que vous voulez que Hiera fusionne les tableaux de la hiérarchie ( hiera --array ), vous ne pouvez pas compter sur la liaison automatique des paramètres de Puppet. Vous devrez appeler explicitement la fonction hiera_array à la place.

class sysbase($packages = hiera_array('sysbase::packages'))
{
    ...
}

Comme décrit dans la réponse précédente, je pense que votre kilométrage serait meilleur avec une conception comme la suivante :

class sysbase(
    $with_xmltv,
    $with_builddev,
    ...
) {
    package { [ 'less', ... ]: }
    if $with_builddec { package { ... } }
}

Il est ainsi beaucoup plus facile de contrôler l'ensemble des paquets dans votre hiérarchie. D'un autre côté, il sera très difficile de mettre en place un nœud sans build-essential avec un hiera_array par exemple.

0 votes

Voir le Limites de la section Utiliser Hiera avec Puppet la documentation. Nous vous remercions de votre attention.

1voto

Felix Frank Points 3033

Pour déboguer ce problème, vous pouvez faire en sorte que le compilateur échoue avant d'effectuer cette vérification particulière :

fail("Packages: $packages")

Il devrait être évident de savoir si Puppet voit les less entrée.

L'approche consistant à transmettre les titres des paquets via Hiera n'est pas particulièrement élégante, de toute façon, car l'utilisateur peut faire en sorte que la classe gère tout le paquet qu'ils veulent, ce qui est une mauvaise sémantique.

Si vous voulez vraiment hacer vous voulez énumérer vos paquets dans Hiera, vous pouvez le faire sous une clé générique et générer les ressources dans site.pp ou n'importe où ailleurs.

Pour établir la relation de manière sûre, vous pouvez utiliser une requête :

if 'less' in $packages {
    Package['less'] ~> Exec['select-pager']
}

0 votes

Dans mon cas, il s'agit d'une classe de base, que tous les nœuds appliqueront. J'applique des choses basiques, comme vous l'avez vu plus haut. Je veux curl et wget, less, bash et zsh, et une tonne d'autres choses que j'aimerais garder à jour. Qu'est-ce que vous me recommandez de faire à la place ? Une classe par paquet ? Cela semble excessif.

0 votes

Ah, et bien si cette classe est dédiée à ces ressources, alors oui, je pense que vous pouvez les utiliser. sont en faisant ce que j'ai préconisé ci-dessus. Néanmoins, l'interface serait meilleure si l'ensemble des paquets était codé dans le manifeste et si des paramètres significatifs permettaient à chaque nœud de (dé)sélectionner un sous-ensemble spécifique de classes à gérer.

0 votes

J'ai ajouté un peu plus d'informations, telles que le numéro de téléphone de la personne à contacter. dev.local définition du domaine. Je veux unir les paquets, et non les remplacer, à un niveau moins générique.

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