Puppet

Puppet 3.x unter Debian

Da ich Stunden damit zugebracht habe, Puppet 3.x unter Debian zum Laufen zu bringen, notiere ich an dieser Stelle ein paar Zeilen aus dem Kopf und der Bash History. Eventuell wird ja später mal daraus eine richtige Anleitung ... Ich verwendete eine Anleitung die gleich damit begann das neuste stable Release von Puppet über Debian zu installieren, nichts ahnend, was für Probleme damit einhergehen könnten. Das größte Problem ist nämlich, dass ein nicht unerheblicher, wichtiger Teil der Syntax von den 2.x'er abweicht und man sich dusslig sucht. Da ich auch kein Fan von Ruby/Rails/Gem bin (für mich die Hölle, was Debug und Co angeht), macht die Einrichtung umsoweniger spaß.

Hier meine Notizen:

Hinweis

Ich setze voraus, dass DNS etc. funktioniert, also ein ping auf z.B. puppet.domain.local funktioniert, andernfalls muss man die /etc/hosts überall so anpassen, damit ein Ping auf den vollständigen Rechnernamen (FQDN) klappt. Die Ip Adressen und Namen vom LDAP etc. sind aus der Luft gegriffen und müssen keinen Sinn ergeben ;-)

Puppet

Was ich ja nicht komplett erwähnen muss, (sonst wärst du nicht hier), ist, dass Puppet an der Stelle weitermacht, wo Fai aufhört. Man kann zwei eine Menge mittels Fai ausrollen, doch soll es ja vorkommen, dass Konfigurationen sich ändern und an dieser Stelle setzt Puppet ein. Beliebtest Beispiel: SSHD und die Sudo Konfigurations- Dateien.

Ziel

Am Ende der Zeilen wird (hoffentlich) Puppet mittels des Apache Passenger Modul laufen, die Klassen aus dem LDAP beziehen und - als nettes Add-On - eine Übersicht mittels des Puppet-Dashboard bieten.

Installation

Als Basis dient ein Debian Squeeze, welches auch mein Fai beherbergt. Puppetlabs stellt ein Debian Paket bereit, welches den Schlüssel und die passende Apt Liste enthält:

# wget http://apt.puppetlabs.com/puppetlabs-release-squeeze.deb # aptitude update

Nun die Installation der Pakete selbst:

# aptitude install -y puppet puppet-common puppet-el puppet-testsuite puppetmaster puppetmaster-common vim-puppet vim-nox

Konfiguration

Das Konfigurationsverzeichnis ist /etc/puppet und die später wichtig werdenden SSL Zertifikate liegen unter /var/lib/puppet. Im Grunde gibt es für die Hauptarbeit drei Dateien:

• /etc/puppet/puppet.conf
  • Enthält die Basiskonfiguration
• /etc/puppet/auth.conf
  • Bestimmt, der mit dem Puppet Server kommunizieren darf
• /etc/puppet/fileserver.conf
  • Wer darf auf die Puppet Dateien zugreifen

Im Schnelldurchlauf:

• /etc/puppet/puppet.conf

[main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates # Noch auskommentiert. Dient später der automatischen Versionierung der Puppet Dateien/Manifeste ... # prerun_command=/etc/puppet/etckeeper-commit-pre # postrun_command=/etc/puppet/etckeeper-commit-post # wir arbeiten mit Modulen, da dies sich gut Strukturieren lässt modulepath = $confdir/environments/$environment/modules:$confdir/modules [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY # Wir wollen für jeden Puppet Client einen Report hochladen reports = store, http # auf diesen Server reporturl = http://puppet.domain.local:3000/reports/upload # Die Klassen sollen aus dem LDAP bezogen werden node_terminus = ldap ldapserver = ldap.domain.local ldapbase = dc=domain,dc=local # wir arbeiten mit Modulen, da dies sich gut Strukturieren lässt modulepath = $confdir/environments/$environment/modules:$confdir/modules # Damit Reports überhaupt erstellt werden, wichtig für jeden Puppet "Client" [agent] report=true

Man beachte den zu ändernden Teil!

• /etc/puppet/auth.conf

### Authenticated paths - these apply only when the client ### has a valid certificate and is thus authenticated # allow nodes to retrieve their own catalog path ~ ^/catalog/([^/]+)$ method find allow $1 # allow nodes to retrieve their own node definition path ~ ^/node/([^/]+)$ method find allow $1 # allow all nodes to access the certificates services path /certificate_revocation_list/ca method find allow * # allow all nodes to store their reports path /report method save allow * # unconditionally allow access to all file services # which means in practice that fileserver.conf will # still be used path /file allow * ################## Hier ändern !!!!! ####################### ##### siehe: https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/IV_Qn39jox4 path ~ ^/file_(metadata|content)/files/ auth yes allow /^(.+\.)?domain.local$/ allow_ip 192.168.1.0/24 ################## Hier ändern !!!!! ####################### ### Unauthenticated ACL, for clients for which the current master doesn't ### have a valid certificate; we allow authenticated users, too, because ### there isn't a great harm in letting that request through. # allow access to the master CA path /certificate/ca auth any method find allow * path /certificate/ auth any method find allow * path /certificate_request auth any method find, save allow * # this one is not stricly necessary, but it has the merit # of showing the default policy, which is deny everything else path / auth any

• /etc/puppet/fileserver.conf

[files] path /etc/puppet/files allow * [modules] allow * [plugins] allow *

Hier steht zwar, dass jeder zugreifen darf, aber zuvor wird die auth.conf abgefragt. Dies hier ist eine art Workaround für Puppet 3.0.1 und soll später gefixt werden, sodass auch hier Einschränkungen auf DNS bzw. IP Ebene funktionieren.

Als nächstes müssen wir dafür sorgen, dass der Puppetmaster Daemon nicht gestartet wird, da wir das über den Apachen erledigen:

# service puppetmaster stop # vi /etc/default/puppetmaster

START=no # Startup options DAEMON_OPTS="" # What port should the puppetmaster listen on (default: 8140). PORT=8140

Kurzer Test

Um mal eben zu schauen, ob soweit die Syntax der Dateien passt, kann man Puppet Master mal von Hand starten. Nebenbei werden auch die SSL Zertifikate erzeugt:

# puppet master --no-daemonize --verbose --debug [...] Debug: Finishing transaction 70248629156860 Starting Puppet master version 3.0.1

Es werden eine Menge Debug Ausgaben gezeigt, doch am Ende sollte die passende Startmeldung angezeigt werden. Ein STRG+c beendet den Test wieder. Diese Zeile sollte man sich merken, da sie goldwert sein kann.

Apache Passenger

Da der eingebaute Webrick WebDaemon nicht das gelbe vom Ei sein soll (nur eine Verbindung ... kein Threading ...), richten wir den Apachen ein:

# aptitude install -y puppetmaster-passenger

Die Abhängigkeiten sorgen dafür, dass auch ein Apache2 mit dabei ist.

Konfiguration

Die Konfiguration ist nicht weiter kompliziert, es bedarf nur einer passenden Modul Unterstützung, sowie der korrekten Vhost Datei:

# a2enmode passenger

• /etc/apache2/sites-available/puppetmaster

# you probably want to tune these settings PassengerHighPerformance on PassengerMaxPoolSize 12 PassengerPoolIdleTime 1500 # PassengerMaxRequests 1000 PassengerStatThrottleRate 120 RackAutoDetect On RailsAutoDetect Off Listen 8140 <VirtualHost *:8140> SSLEngine on SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP SSLCertificateFile /etc/puppet/ssl/certs/puppet.local.pem SSLCertificateKeyFile /etc/puppet/ssl/private_keys/puppet.local.pem SSLCertificateChainFile /etc/puppet/ssl/ca/ca_crt.pem SSLCACertificateFile /etc/puppet/ssl/ca/ca_crt.pem # If Apache complains about invalid signatures on the CRL, you can try disabling # CRL checking by commenting the next line, but this is not recommended. SSLCARevocationFile /etc/puppet/ssl/ca/ca_crl.pem SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +StdEnvVars # This header needs to be set if using a loadbalancer or proxy RequestHeader unset X-Forwarded-For RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/ ## RackBaseURI / <Directory /usr/share/puppet/rack/puppetmasterd/> Options None AllowOverride None Order allow,deny allow from all # We are told that this is required for correct operation Options -MultiViews </Directory> </VirtualHost>

Einzig aufpassen muss man bei den Pfaden der Zertifikate. Beim ersten Start des Puppet Master Daemons werden diese automatisch erzeugt, sodass man sie für den Apachen 1:1 verwenden kann. Der Name wird vom Rechnernamen abgeleitet, in diesem Beispiel also puppet.local.pem.

• Starten

# a2ensite puppetmaster # apache2ctl -t # service apache2 restart

• Testen

Ein kurzer Aufruf der URL https://puppet.local:8140 sollte eine Zeile bringen, wie:

The environment must be purely alphanumeric, not ''

Dann funktioniert es.

LDAP

Da wir eh einen LDAP Server am Laufen haben, bot es sich an, einen Teil der Verwaltung in den LDAP zu verlegen. Wir verwenden dafür den OpenLDAP in der cn=config Konfiguration. Damit die Puppetklassen verwenden werden können, muss das Schema puppet.schema in den LDAP. Das Schema selbst kann hier geholt werden. Damit es aber auch in die dynamische Verwaltung passt, muss es zuvor konvertiert werden. Ich habe das hier mal getan:

dn: cn=puppet,cn=schema,cn=config objectClass: olcSchemaConfig cn: puppet olcAttributeTypes: {0}( 1.3.6.1.4.1.34380.1.1.3.10 NAME 'puppetClass' DESC 'Pu ppet Node Class' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121. 1.26 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.34380.1.1.3.9 NAME 'parentNode' DESC 'Pupp et Parent Node' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1 .26 SINGLE-VALUE ) olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.1.1.3.11 NAME 'environment' DESC 'Pu ppet Node Environment' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.11 5.121.1.26 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.34380.1.1.3.12 NAME 'puppetVar' DESC 'A va riable setting for puppet' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.146 6.115.121.1.26 ) olcObjectClasses: {0}( 1.3.6.1.4.1.34380.1.1.1.2 NAME 'puppetClient' DESC 'Pup pet Client objectclass' SUP top AUXILIARY MAY ( puppetclass $ parentnode $ en vironment $ puppetvar ) )

Der Umbrüche sind im Ldif Format definiert, müssen also nicht herausgenommen werden. Nun kann man mittels ldapmodify / Ldap Browser das Schema hinzufügen. Siehe Google (ich verwende gern den Apache Directory Studio, da auch vorhandene Einträge aktualisiert werden können).

In meinem Fall musste ich einen der LDAP Server (die als n-way Master arbeiten) neustarten um dann die neuen Klassen und Attribute im LDAP Browser sehen zu können.

Hat das geklappt, erstellt man sich am Besten - sofern man das nicht eh schon hat - eine DN wie diese:

• cn=host,dc=domain,dc=local

Das hat den Charme, später diese Objekte für andere dinge im Unix Umfeld verwenden zu können.

• Hier im Detail:

dn: cn=testhost.domain.local,dc=domain,dc=local objectClass: device objectClass: top objectClass: puppetClient cn: testhosts.domain.local environment: production puppetClass: ssh dn: ou=hosts,dc=domain,dc=local objectClass: organizationalUnit objectClass: top ou: hosts

Der erste Puppet Client heißt "testhost.domain.local", was wichtig ist zu wissen, denn auf diesen Namen wird sich der Puppet Agent beziehen. Auch zu beachten sind die jeweiligen Objektklassen. Hier lässt sich auch definieren, in welcher Puppet Klassen dieser Host sein soll, nämlich in der Klasse ssh.

• Fehlt noch die entsprechende ACL:

olcAccess to dn.subtree="ou=hosts,dc=domain,dc=local" by * read

Natürlich kann man dies später passend eingrenzen, wenn alles funktioniert.

Man sollte auf jedenfall vom Puppetmaster Server testen, ob am Ende das passende herausfällt, z.B. via ldapsearch:

• ldapsearch:

# ldapsearch -x '(&(objectclass=puppetClient)(cn=testhost.domain.local))' -LLL dn: cn=testhost.domain.local,ou=hosts,dc=domain,dc=local objectClass: device objectClass: top objectClass: puppetClient puppetClass: ssh environment: production cn: testhost.domain.local

Damit auch Puppet LDAP sprechen kann, müssen die passenden Ruby Module installiert werden:

# aptitude install libldap-ruby1.8

• Dann gleich mal testen:

# ruby -rldap -e 'puts :installed' installed # ruby -rpuppet -e 'p Puppet.features.ldap?' true

passt.

Damit wäre der LDAP Teil durch.

Puppet Module

Bevor der erste Test erfolgt, brauchen wir etwas zum testen, ob denn der Workflow funktioniert. Da bietet sich der SSH Daemon an, da der zumeist angepasst wird. Des weiteren sehen wir auch gleich, ob das Kopieren der Dateien funktioniert.

Es gibt zig Organisationsstrukturen, wie das Puppet Layout aussehen kann. Ich habe mich für die Modulvariante entschieden, da wir sowohl Linux als auch (würg) Solaris einsetzen und nicht immer die Pfade gleich sind.

• Erzeugen wir uns also das passende Layout:

# mkdir -p /etc/puppet/modules/ssh/{files,manifests} # mkdir -p /etc/puppet/templates/ssh/

Wie verwenden aus Spaß an der Freude (und für das Beispiel) auch gleich noch die Template Funktion, die aber in diesem Fall noch nicht wirklich genutzt wird. Da mir noch nicht alles aus Puppet bekannt ist, muss man sich einen Teil zu denken, was die jeweilige Zeile bedeutet ;-)

• Die Dateien:

• /etc/puppet/modules/ssh/manifests/init.pp
  • Wichtig: Die Datei muss wohl wirklich init.pp heißen, da sie bei mir sonst nicht ausgeführt wird (class ssh not found)
  • Von hier kopiert und leicht modifiziert.

# # SSH CONFIGURATION # class ssh { package { 'openssh-server': ensure => installed } exec { 'mkdir /root/.ssh': path => '/usr/bin:/usr/sbin:/bin', onlyif => 'test ! -d /root/.ssh' } ## Die source Zeile enthält kein "files", da das Puppet selbst weiß ## ## das hat mich Stunden gekostet, das herauszufinden ## file { '/etc/ssh/sshd_config': name => '/etc/ssh/sshd_config', owner => root, group => root, mode => 644, source => "puppet:///modules/ssh/sshd_config", require => Package['openssh-server'] } ## Hier nutzen wir die Template Funktion ## file { 'authorized_keys': name => '/root/.ssh/authorized_keys', owner => 'root', group => 'root', mode => 600, content => template( 'ssh/root_key.erb' ), require => Package['openssh-server'] } ## Hier kommmt alles zusammen ## service { 'ssh': subscribe => File[ '/etc/ssh/sshd_config' ], require => [ Package['openssh-server'], File['/etc/ssh/sshd_config', 'authorized_keys'] ] } }

• /etc/puppet/modules/ssh/files/sshd_config
  • Enthält die SSHD Konfiguration

Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes PasswordAuthentication yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM no AllowTcpForwarding no Match Address 192.168.1.1 PasswordAuthentication yes

• /etc/puppet/templates/ssh/root_key.erb
  • Enthält den öffentichen SSH Schlüssel vom Benutzer Root

ssh-dss AAAAB3NzaC1kc3M[...] root@puppet.domain.local

• • Wichtig ist auch an dieser Stelle, dass der Webserver (Debian www-data) alle Dateien lesen kann!**

Damit ist sozusagen die Grundkonfiguration abgeschlossen und ein erster Test kann erfolgen.

Erster Test

Als Testkandidat kommt ein Debian Squeeze zum Einsatz, welches vorher mittels Fai installiert wurde und alle notwendigen Pakete enthält. Dazu zählen eben SSH und Puppet. Die Konfiguration des Agents sieht dabei so aus:

Konfiguration

Da mein Puppet server noch nicht unter puppet.domain.local zu finden ist (wonach sie automatisch suchen), sage ich dem Agent, wo er den Server findet:

• /etc/puppet/puppet.conf

[main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY server = puppet.domain.local [agent] server = puppet.domain.local classfile = $vardir/classes.txt localconfig = $vardir/localconfig listen = true runinterval = 30000 ignorecache = true report = true

Unter Squeeze muss zusützlich die Datei /etc/puppet/auth.conf erstellt werden, sonst startet der Agent nicht (Nur auf den Puppet Clients ausführen, nicht auf dem Master)

# touch /etc/puppet/auth.conf

Und auch, dass der Puppet Dienst beim Boot gestartet werden soll:

• /etc/default/puppet

# Start puppet on boot? START=yes # Startup options DAEMON_OPTS=""

Das würde allerdings noch nicht funktionieren, da die Zertifikate noch nicht ausgetauscht worden sind. Das holen wir nun nach.

Test

• Starten wir den Puppet Daemon von Hand:

testhost# puppetd --server puppet.domain.local --waitforcert 60 --test

Klappt nun alles mit der Kommunikation (Stichwort Apache, Firewall, LDAP) wird nun eine Zertifizierungs- Anfrage an den Puppermaster gesendet, die wir (zügig) unterschreiben müssen (sign)

puppetmaster # puppet ca sign testhost.domain.local

Hat das auch geklappt, kann man den Puppet Client starten:

testhost# service puppet start

Es sollte nun die /etc/ssh/sshd_config angepasst worden sein, der SSH Daemon neugestartet und auch die /root/.ssh/authorized_keys existiert, mit dem richtigen Inhalt. Damit steht einem generellem Verwenden nun nichts mehr im Wege (sofern ich nichts vergessen habe).

• Kleiner Tipp:

sollte es dennoch an einer Stelle nicht funktionieren, kann es helfen, den Apachen zu stoppen und den Puppetmaster von Hand aufzurufen (siehe irgendwo oben) und dann noch einmal den Testaufruf vom Client zu starten. Zumeist kommt man dann eher darauf, was nicht funktioniert.

Puppet Dashboard

Der nächste Punkt wäre die Überwachung, welche Puppet Agents durchgelaufen sind, wie viele noch ausstehen und wo es nicht geklappt hat. Statt sich die passenden Zeilen aus den Logs zu holen, bietet das Puppet-Dashboard eine nette Übersicht, basierend auf MySQL und Rack.

Auch hier sind Stunden draufgegangen, weil immer irgendwas nicht gepasst hat und die Anleitungen im Netz meist veraltet sind oder nicht für Debian passen. Bei diesem Teil muss ich noch mehr aus dem Kopf schreiben und hoffen, noch alles zusammen zu bekommen.

Installation

MariaDB

Da ich Oracle nicht ausstehen kann, installieren wir statt MySQL das zu 100% kompatible MariaDB. Da MariaDB noch nicht in den Squeeze Repositories enthalten ist, fügen wir diese hinzu:

# apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db # cat > /etc/apt/sources.list.d/mariadb.list << "EOF" ## MariaDB 5.5 repository list - created 2012-12-20 12:52 UTC ## http://downloads.mariadb.org/mariadb/repositories/ deb http://mirror2.hs-esslingen.de/mariadb/repo/5.5/debian squeeze main deb-src http://mirror2.hs-esslingen.de/mariadb/repo/5.5/debian squeeze main EOF # aptitude update # aptitude install -y mariadb-server

Der restliche Teil entspricht dem 1:1 von MySQL und auch die meisten Befehle nennen sich mysql*. Dazu gehört unter anderem das Root Kennwort der Datenbank etc. zu ändern.

Im produktiven Bereich sollte in jedem Fall ein spezieller Datenbankbenutzer für das Dashboard angelegt werden, der Schnelligkeit wegen, greifen wir auf Root zurück.

Dashboard

Nun können wir das Dashboard installieren und verhindern so, dass eine andere Datenbank vorab gewählt wird.

# aptitude -y install puppet-dashboard

Konfiguration

Nun benötigen wir nun die Konfiguration für die Datenbank. Die ist zu erstellen unter:

• /etc/puppet-dashboard/database.yml

production: database: dashboard_production username: root password: wirklichsehrgeheim!!!! encoding: utf8 adapter: mysql

Die Datenbank heißt also dashboard_production. Da wir mit Root arbeiten, müssen wir sie nicht vorab erstellen, sondern überlassen dies dem Rake Script. Dazu müssen wir folgendes ausführen:

# cd /usr/share/puppet-dashboard/ # rake RAILS_ENV=production db:create # rake RAILS_ENV=production db:migrate

Erster rake Befehl erstellt die Datenbank, zweiter befüllt sie.

Die Dashboard Konfiguration selbst ist die /etc/puppet-dashboard/settings.yml die ich allerdings bisher noch nicht angepasst habe.

Apache

Um die Webseite darzustellen, benutzen wir den bereits vorhandenen Apachen mit einer neuen Vhost Konfiguration. Zuvor muss aber sichergestellt werden, dass das Dashboard nicht selbst einen Webserver Daemon startet:

• /etc/default/puppet-dashboard

# Uncomment the line below to start Puppet Dashboard. START=no # Location where puppet-dashboard is installed: DASHBOARD_HOME=/usr/share/puppet-dashboard # User which runs the puppet-dashboard program: DASHBOARD_USER=www-data # Ruby version to run the puppet-dashboard as: DASHBOARD_RUBY=/usr/bin/ruby # Rails environment in which puppet-dashboard runs: DASHBOARD_ENVIRONMENT=production # Network interface which puppet-dashboard web server is running at: DASHBOARD_IFACE=0.0.0.0 # Port on which puppet-dashboard web server is running at, note that if the # puppet-dashboard user is not root, it has to be a > 1024: DASHBOARD_PORT=3000

Wichtig ist das START=no, sonst kommen wir uns mit dem Apachen ins Gehege.

• /etc/apache2/sites-available/puppet-dashboard

Listen *:3000 PassengerHighPerformance on PassengerMaxPoolSize 12 PassengerPoolIdleTime 1500 # PassengerMaxRequests 1000 PassengerStatThrottleRate 120 RailsAutoDetect On PassengerDefaultUser www-data ServerSignature On <VirtualHost *:3000> SetEnv RAILS_ENV production RackBaseURI / ServerName puppet.domain.local DocumentRoot /usr/share/puppet-dashboard/public/ <Directory /usr/share/puppet-dashboard/public/> Options None AllowOverride None Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/dashboard.test_error.log LogLevel warn CustomLog /var/log/apache2/dashboard.test_access.log combined ServerSignature On # <Location "/"> # AuthBasicProvider ldap # AuthType Basic # AuthName "Puppet Dashboard" # AuthLDAPUrl ldap://ldap.domain.local/cn=people,dc=domain,dc=local?uid # AuthLDAPGroupAttribute memberUid # AuthLDAPGroupAttributeIsDN off # Require ldap-user admin # </Location> </VirtualHost>

Die Webseite ist also auf dem Port 3000 zu finden (wenn anders, dann an die puppet.conf auf dem Master denken!) und Passenger läuft ebenfalls als User www-data da es sonst Probleme gibt. Wer die LDAP Authentifizierung nutzen will, muss vorher das authnz_ldap Modul aktivieren.

Des weiteren muss ein Link zu einer Rake Datei erstellt werden, ohne die das Ganze nicht funktioniert:

# cd /usr/share/puppet-dashboard # ln -s /usr/share/puppet-dashboard/vendor/rails/railties/dispatches/config.ru .

Nun kann man die Vhost Konfiguration aktivieren und Apache sowie und die Dashboard-workers durchstarten:

# a2ensite puppet-dashboard # service apache2 restart # service puppet-dashboard-workers restart

Als Test kann man nun http://puppet.domain.local:3000 aufrufen und den Puppet Agent auf testhost neustarten. Nach kurzer Zeit sollte dessen (Fehl)Erfolg auf der Webseite angezeigt werden.

Quellen

• http://uberhost.dyndns.org/dokuwiki/doku.php?id=puppet#puppet_in_chroot_von_fai
• https://kb.askmonty.org/en/installing-mariadb-deb-files/
• http://projects.puppetlabs.com/projects/1/wiki/Ldap_Nodes
• http://num.math.uni-goettingen.de/~schulz/publications/puppet.pdf
• http://foaa.de/old-blog/2010/07/playing-with-puppets-on-debian/trackback/index.html

---

--Denny 13:24, 20. Dez. 2012 (UTC)