Parametri superiori nella Risorsa Puppet precedentemente dichiarata

Sto tentando di ribuild il module snap puppet di nwaller per essere interamente basato su LDAP e per essere un po 'più pulito. In esso abbiamo una risorsa definita per each dominio di authentication del module

define sssd::domain ( $domain = $name, $domain_description = '', $domain_type, $ldap_uri = 'ldap://example.com', $ldap_search_base = 'dc=example,dc=com', $simple_allow_groups, .... ) 

Questa definizione viene quindi passata come concat::fragment che compila un model per la costruzione del sssd.conf finale.

Questo tutto funziona bene se definisco il server LDAP in each nodo, come in:

nodes.pp

 node "node1.systems.private" { include "puppet::client" class { 'sssd': domains => [ 'LDAP' ], make_home_dir => true; } sssd::domain { 'LDAP': domain_type => 'ldap', ldap_uri => 'ldaps://ldap.site.com:636', ldap_search_base => 'DC=site,DC=com', ldap_user_search_base => 'OU=People,DC=site,DC=com', ldap_group_search_base => 'OU=Groups,DC=site,DC=com', ldap_default_bind_dn => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com', ldap_default_authtok => 'soopersekretbindpw', simple_allow_groups => ['SysAdmins','AppAdmins'], } } 

Quello che preferirei è una configuration molto più gerarchica. Conserva la definizione del sssd::domain come il generico ansible, pertanto posso mantenerlo come un module indipendente dalle nostre configurazioni di organizzazione. Definire il server LDAP in una configuration globale e quindi all'interno di ciascun nodo definire quali gruppi specifici richiedono l'accesso. Quindi qualcosa di più simile:

Moduli / org / manifesti / default.pp

 class org::default { include "puppet::client" class { 'sssd': domains => [ 'LDAP' ], make_home_dir => true; } sssd::domain { 'LDAP': domain_type => 'ldap', ldap_uri => 'ldaps://ldap.site.com:636', ldap_search_base => 'DC=site,DC=com', ldap_user_search_base => 'OU=People,DC=site,DC=com', ldap_group_search_base => 'OU=Groups,DC=site,DC=com', ldap_default_bind_dn => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com', ldap_default_authtok => 'soopersekretbindpw', } } 

nodes.pp

 node "node1.systems.private" { include "org::default" sssd::domain { 'LDAP': simple_allow_groups => ['SysAdmins','AppAdmins'], } } 

Come previsto, ciò provoca un errore di dichiarazione duplicato quando si tenta di applicare la definizione. C'è un modo per fare questo, sovrascrivere selettivamente i parametri o sono bloccato con la definizione del dominio di authentication all'interno della definizione originale e quindi l'overriding dei parametri di authorization all'interno di each nodo?

  • I server Linux che utilizzano AD / Kerberos per l'authentication / authorization necessitano di conti di computer?
  • Elenco dei pacchetti per RH 5.x
  • SSSD ignorando ldap_access_filter
  • Problemi con sssd e integrazione di Active Directory
  • Aggiorna la configuration del client ldap Centos
  • Imansible unirsi a un dominio utilizzando la networking di strumenti di samba o realm / sssd
  • Autenticazione SSSD al dominio di Windows senza @ domain.com ovunque
  • Impedire a sssd di utilizzare ldap per autenticare o identificare utenti specifici per lo chef
  • 2 Solutions collect form web for “Parametri superiori nella Risorsa Puppet precedentemente dichiarata”

    Vorrei usare Hiera: http://docs.puppetlabs.com/hiera/latest/

    Hiera consente di separare i dati variables dai tuoi manifesti Puppet.

    Hiera, come suggerisce il nome, è gerarchico, permettendo alcuni modi interessanti per ignorare, oltre a combinare dati variables.

    Innanzitutto, modifica la tua dichiarazione di dominio sssd :: per eseguire le ricerche Hiera per i parametri:

     sssd::domain { 'LDAP': domain_type => 'ldap', ldap_uri => hiera('ldap_uri', 'ldaps://ldap.site.com:636'), ldap_search_base => hiera('ldap_search_base', 'DC=site,DC=com'), ldap_user_search_base => hiera('ldap_user_search_base', 'OU=People,DC=site,DC=com'), ldap_group_search_base => hiera('ldap_group_search_base', 'OU=Groups,DC=site,DC=com'), ldap_default_bind_dn => hiera('ldap_default_bind', 'CN=bindaccount,OU=ServiceAccounts,OU=People,DC=site,DC=com'), ldap_default_authtok => hiera('ldap_default_authtok', 'soopersekretbindpw'), simple_allow_groups => hiera_arrays('ldap_simple_allow_groups', ['SysAdmins','AppAdmins']), } 

    Nel codice qui sopra, ho definito i valori predefiniti per ciascuna delle ricerche. Potresti escludere quelli, se ti piace, attaccando i valori predefiniti nel file di dati Hiera più generico (in genere "common.yaml" o "common.json"):

    common.yaml:

     --- ldap_uri: ldaps://ldap.site.com:636 ldap_search_base: DC=site,DC=com ldap_simple_allow_groups: - SysAdmins - AppAdmins 

    Per i bit che si desidera personalizzare su base host, creare un file YAML o JSON denominato dopo il FQDN dell'host in questione e inserire i valori necessari.

    node1.systems.private.yaml:

     --- ldap_simple_allow_groups: - SomeOtherGroup 

    In questo esempio, si noti che ldap_simple_allow_groups utilizza la function di ricerca hiera_arrays . Questo concatenerà TUTTI i fondamenti validi nella gerarchia. Come tale, il nodo1 otterrà i valori definiti in common.yaml così come il "SomeOtherGroup" definito nel proprio file YAML.

    Leggere la documentazione dei tipi di ricerca Hiera per ulteriori dettagli: http://docs.puppetlabs.com/hiera/latest/lookup_types.html

    Mentre Hiera è il modo migliore e deve essere accettato, vorrei aggiungere per completezza: c'è una syntax per fare proprio questo override che avevi in ​​mente:

     node "node1.systems.private" { include "org::default" Sssd::Domain<| title == 'LDAP' |> { simple_allow_groups => ['SysAdmins','AppAdmins'], } } 

    Si noti che questa syntax serve anche a raccogliere risorse virtuali , ma può essere utilizzata per ignorare i parametri delle risorse.

    Ovviamente, questa tecnica porterà al caos se usata di conseguenza, quindi ancora una volta – Hiera è superiore nella maggior parte dei casi.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.