Variáveis do fantoche nem sempre funcionando

Question

Eu quero aplicar o princípio "SECA" (não se repita) nos nós.pp agrupando máquinas, por exemplo. Máquinas RH5 e RH6 em vez de adicionar várias linhas de inclusões para todos os servidores RH5 e RH6.

O fantoche no tst-01 funciona bem ao usar:

node "tst-01" inherits basenode {

Mas ele quebra quando tento organizar servidores em grupos com essa configuração:

node "tst-01" inherits redhat6server {

O erro "herda o redhat6server" é:

err: Could not retrieve catalog; skipping run
[root@tst-01 ~]# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template ldap/access.conf: Could not find value for 'netgroup' at 124:/etc/puppet/modules/ldap/templates/access.conf at /etc/puppet/modules/ldap/manifests/init.pp:82 on node tst-01.tst.it.test.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Este é o arquivo access.conf, que funciona bem se as heranças estiverem definidas como "inherits basenode".

[root@puppet]# grep -v "#" /etc/puppet/modules/ldap/templates/access.conf 
+ : root : LOCAL
+ : @<%= netgroup %> : ALL
- : ALL : ALL
[root@puppet]# 

Esta é a configuração em /etc/puppet/manifests/nodes.pp.

# Basenode configuration
node "basenode" {
        include resolv_conf
        include sshd
        include ntpd
        include motd
}

# Groups
node "redhat6server" inherits basenode {
        include ldap_auth
}

# Testservers
node "tst-01" inherits redhat6server {
        $netgroup = tst-01
}

    

Answer 1

Ele provavelmente falha porque a herança ocorre antes que a variável $netgroup seja avaliada e, portanto, a compilação do catálogo falhe. No entanto, usar esse método para separar o código dos dados tem limitações e deve ser evitado .

Eu refatorei meu código de marionete para usar dados hierárquicos para vinculações de dados e para obter o mesmo efeito de agrupar nós semelhantes. Um exemplo simplificado, supondo que você só precisa agrupar servidores RHEL, seria:

• Os dados hierárquicos serão recuperados usando a seguinte definição:

  hiera.yaml
  ---
  :backends: 
    - yaml
  :hierarchy:
    - %{::operatingsystem}
    - %{::hostname}
    - common
  :yaml:
    :datadir: /etc/puppet/hieradata/
  

  Tanto operatingsystem como hostname são facts . A Hiera tentará resolução de dados nesta ordem para um sistema Red Hat cujo nome de host é some-rhel-hostname :

  • RedHat.yaml
  • some-rhel-hostname.yaml
  • common.yaml

• Isso espera a seguinte estrutura de diretórios e arquivos:

  /etc/puppet/hieradata/
  ├── common.yaml
  ├── RedHat.yaml
  ├── some-rhel-hostname.yaml
  └── tst-01.yaml
  

• O conteúdo dos arquivos yaml de exemplo:

  common.yaml
  ---
  classes:
    - resolv_conf
    - sshd
    - ntpd
    - motp
  
  RedHat.yaml
  ---
  classes:
    - ladp_auth
  
  some-rhel6-hostname.yaml
  ---
  classes:
    - this_host_only
  ldap_auth::netgroup: foo-bar
  
  tst-01.yaml
  ---
  ldap_auth::netgroup: tst-01
  
  nodes.pp
  default {
      hiera_include(classes)
  }
  

  Observe o uso da função hiera_include , que retornará uma matriz de todos os valores para cada nó (aqueles de common.yaml e aqueles provenientes da resolução de hierarquia, ou seja, some-rhel-hostname incluirão todas as classes de common.yaml plus ldap_auth de RedHat.yaml e this_host_only de seu próprio arquivo yaml).

  A utilização de ligações de dados nos seus módulos é feita de forma diferente, dependendo de qual versão de puppet você está usando. Verifique aqui para os ponteiros.