Schlagwort: Debian

Puppet: Informationen des Nodes mit facter auslesen

prego Schreib einen Kommentar

In heterogenen Setups ist es wichtig das sich die Module und Klassen den nodespezifischen Eigenheiten anpassen. Dafuer koennen in Puppet Informationen aus facter verwendet werden.

Facter is an independent, cross-platform Ruby library designed to gather information on all the nodes you will be managing with Puppet. It is available on all platforms that Puppet is available.

Facter ist auch ein eigenstaendiges Tool. Nach dem Aufruf werden die zur Verfuegung stehenden Informationen ausgegeben.

Ein Anwendungsbeispiel ist mit einem Modul sicherzustellen, dass SSH installiert und der SSH Serverdienst auch laeuft. Auf Debian basierten Systemen heisst der Dienst ’ssh‘, waerend auf RedHat basierten Systemen der Dienst ’sshd‘ heisst. In einem Puppet Modul laesst sich das mit Informationen aus facter wie folgt abbilden:

class ssh_server {
  case $::osfamily {
    Debian: {
      $serviceName = 'ssh'
    }
    RedHat: {
      $serviceName = 'sshd'
    }
  }
 
  service { $serviceName:
    ensure => 'running',
  }

Aber nicht nur in den manifest Dateien kann man auf die Informationen aus facter zurueckgreifen, auch in den Templates stehen diese zur Verfuegung. Eine sinnvolle Modifikation des Templates jail.local.erb das ich in dem fail2ban Modul gezeigt habe ist, die Emails nicht an fail2ban@localhost sondern an fail2ban@FQDN zu verschicken. Dafuer muss die folgende Zeile geaendert werden:

  • alt: 
    destemail = fail2ban@localhost
  • neu: 
    destemail = fail2ban@<%= fqdn %>

Puppet: Aufsetzen der Infrastruktur

prego Schreib einen Kommentar

Durch die Arbeit inspiriert, habe ich nun auch fuer mich Privat einen puppet Server zur Verwaltung meiner virtuellen Maschinen aufgesetzt.

Wikipedia schreibt zu puppet:

Puppet ist ein Tool zum Konfigurationsmanagement von Computern mit Betriebssystemen 
wie Unix, Linux und FreeBSD. Ein IT-Administrator kann damit an zentraler Stelle 
die Konfiguration von Rechnern in seinem Netzwerk verwalten. Puppet eignet sich 
sowohl für einzelne Rechner als auch für große Rechnerverbünde

Als erstes wurde die generelle Infrastruktur aufsetzen. Das bedeutet fuer mich:

  1. Einen puppet master Server zu haben
  2. Auf den Clients einen puppet agent laufen zu haben der mit dem Master verbunden ist.

Alles hier beschriebene passiert auf der Basis von Debian wheezy. Auf dem Server der als puppet master dienen soll habe ich zuerst das entsprechende Paket mit seinen Abhaengigkeiten installiert:

sudo aptitude install puppetmaster

Anschliessend habe ich in der /etc/default/puppetmaster den Parameter START=yes gesetzt. Wichtig ist nun noch sicherzustellen, dass der Port 8140 von den Clients aus erreichbar ist.

Danach habe ich auf den Clients den puppet agent installiert:

sudo aptitude install puppet

Auch hier habe ich in der /etc/default/puppet wieder den Parameter START=yes gesetzt. Weiter habe ich in den DAEMON_OPTS den Parameter zu dem Server angegeben. Beispiel:

--server puppetmaster.example.org

Dann habe ich probiert mich mit dem puppet agent an den puppet master Server zu verbinden:

puppet agent --server puppetmaster.example.org --test

Auf dem puppet master konnte ich danach das unsignierte Zertifikat des Clients mit dem folgenden Befehl sehen:

puppet cert list

Danach musste es mit dem folgenden Befehl signiert werden, wobei puppetclient.example.org der FQHN des puppet clients ist:

puppet cert sign puppetclient.example.org

Alle signierten Zertifikate kann man sich uebrigens mit dem folgenden Befehl anzeigen lassen:

puppet cert list --all

Danach konnte ich den puppet agent auf dem Client erneut laufen lassen und die Verbindung war erfolgreich. Zum Ende das neu starten des puppet agents auf den Clients nicht vergessen, damit der Prozess mit den neuen DAEMON_OPTS laeuft.

Notizen:

  • Wenn es zu einer „Connection refused“ Fehlermeldung wie unten gezeigt kommt, sicherstellen, dass der Port erreichbar ist. Eventuell auch erst einmal ausprobieren mit der IP Adresse auf dem Port zu verbinden (telnet IP PORT) 
    root@host:~# puppet agent --test --server puppetmaster.example.org
err: Could not retrieve catalog from remote server: Connection refused - connect(2)
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: Connection refused - connect(2)
root@host:~#
  • Wenn es zu einer „Server hostname did not match server certificate“ Fehlermeldung kommt, dann kann es helfen fuer den Server einen entsprechenden Eintrag in die /etc/hosts zu packen 
    root@host:~# puppet agent --test --server 192.168.1.100
err: Could not retrieve catalog from remote server: Server hostname '192.168.1.100' did not match server certificate; expected one of puppetmaster.example.org, DNS:puppet, DNS:puppet.example.org, DNS:puppetmaster.example.org
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: Server hostname '192.168.1.100' did not match server certificate; expected one of puppetmaster.example.org, DNS:puppet, DNS:puppet.example.org, DNS:puppetmaster.example.org
root@host:~#

Apache2 mod_proxy und mod_rpaf

prego Ein Kommentar

Mein Webserver ist in einem internen Netz und davor sitzt ein Apache Webserver der die Anfragen mittels mod_proxy nach hinten weiterreicht. Damit in den Logfiles des internen Webservers dennoch die korrekten IP Adressen auftauchen muss dort das Apache Modul rpaf installiert und konfiguriert werden.

Vor der Installation und Konfiguration sehen bei mir die Logeintraege wie folgt aus:

[Sat Nov 09 18:32:14 2013] [error] [client 10.10.10.10] File does not exist: /var/www/foobar

Die Installation des Moduls erfolgt bei Debian aus den Paketquellen:

apt-get install libapache2-mod-rpaf

Anschliessend muss das Modul aktiviert werden:

a2enmod rpaf

Konfiguriert wird es in der Datei /etc/apache2/mods-enabled/rpaf.conf. Dort muss die IP des oder der Proxy-Server entsprechend hinzugefuegt werden. In dem Beispiel oben ist 10.10.10.10 der Proxy-Server und wird entsprechend unter RPAFproxy_ips hinzugefuegt:

<IfModule rpaf_module>
    RPAFenable On
 
    # When enabled, take the incoming X-Host header and
    # update the virtualhost settings accordingly:
    RPAFsethostname On
 
    # Define which IP's are your frontend proxies that sends
    # the correct X-Forwarded-For headers:
    RPAFproxy_ips 10.10.1.2
 
    # Change the header name to parse from the default
    # X-Forwarded-For to something of your choice:
#   RPAFheader X-Real-IP
</IfModule>

Nach dem Neustart des Apache Webservers steht dann die korrekte IP in der Logdatei:

[Sat Nov 09 18:46:32 2013] [error] [client 77.176.69.123] File does not exist: /var/www/foobar

HowTo: move running process to screen

prego Schreib einen Kommentar

Schonmal das Problem gehabt, dass man einen Prozess startet und sich danach denkt: Mist, haette ich den mal im screen ausgefuehrt? Passiert klassisch am Freitag Nachmittag wenn man SIGWOCHENENDE empfangen moechte. Fuer genau das Problem habe ich aber gerade eine Loesung gefunden: reptyr

Das Programm kann bei Debian oder Ubuntu einfach aus den Repositories installiert werden:

apt-get install reptyr

Anschliessend funktioniert das folgende Szenario:

  • Ein Terminal Fenster starten (T1) und folgenden Befehl eingeben: 
    T1 - root@foo:~# tail -f /var/log/syslog
  • Ein zweites Terminal Fenster starten (T2) und als root einen screen starten: 
    T2 - root@foo:~# screen
  • Im screen die PID fuer den Prozess raussuchen und anschliessend mit repryr holen: 
    T2 - root@foo:~# pidof tail
28802
root@foo:~# reptyr 28802
  • Im T1 sieht man nun etwas wie folgt 
    T1 - [1]+  Angehalten              tail -f /var/log/syslog
  • Im T1 nun mit dem folgenden Befehl sicher gehen dass alles sauber ist: 
    T1 - root@foo:~# bg; disown
  • Im T1 nun etwas in die Logdatei schreiben und im screen anschauen, wie es geloggt wird: 
    T1 - root@foo:~# logger foo

Man finde ich das praktisch! :-)