OpenNMS und dynamische IPs

Meinen alten Banknachbarn zur Schulzeit habe ich auch schon mit OpenNMS angesteckt. Hat er auch gleich dokumentiert. *grins*. Beim Chatten heute haben wir überlegt, wie man Kundenrechner mit dynamischen IPs überwacht. Die Antwort ist einfach: OpenVPN! Das ganze hat viele Vorteile:

  • Die Daten – selbst mit SNMP – werden automatisch verschlüsselt.
  • IP-Adressen extern/intern spielen keine Rolle.
  • Firwalls spielen nahezu keine Rolle. Das Tunnel kann vom Kunden aufgebaut werden.

So habe ich die Infrastruktur bei meinem Bruder im Laden schon lange im Blick (allerdings immer noch mit Nagios).

vlogger – Apache logfiles aufräumen

Nachdem ich die Konfiguration meiner VHosts auf meinem Notebook aufgeräumt habe, war jetzt mein Server dran. Dort habe ich mich um die Logfiles gekümmert und sie sauber getrennt. Dazu kommt jetzt vlogger zum Einsatz. Folgende 3 Zeilen in der apache2.conf machen die Arbeit:

ErrorLog "|/usr/sbin/vlogger -e -s error.log /var/log/apache2/"
LogFormat "%{Host}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vlogger
CustomLog "|/usr/sbin/vlogger -s access.log /var/log/apache2/" vlogger

Sämtliche CustomLog Einträge bei den jeweiligen VHosts sind dann überflüssig. Vlogger erstellt pro virtuellen Host ein Verzeichnis unter /var/log/apache2 mit dem Namen des Hosts.

OpenNMS: alles ist (auch) relativ!

Das muss ich mir aufschreiben, damit ich es nicht vergessen zu konfigurieren. OpenNMS überwacht die Thresholds anders wie Nagios nicht direkt über das Plugin, sondern speichert die Werte einem RRD File ab. Diese prüft dann der threshd Daemon regelmässig auf die Grenzwerte ab. Hört sich Anfangs umständlich an, ist aber durchaus sinnvoll. Damit kann nämlich jeder erfasste Wert nicht nur auf überschreiten der Grenzwerte überprüft werden, nein es kann auch die relative Veränderung überwacht werden! Das ganze funktioniert mit jedem Wert, egal ob die entsprechende Quelle das könnte oder nicht. Sehr geil. Dokumentiert ist das ganze hier.

Als erster Anwendungsfall fällt mir da die Temperaturüberwachung bei mir im Arbeitszimmer ein. Egal wie genau der Sensor ist, ändert sich relativ viel gibt es einen Alarm. Das gleiche baue ich mir auch für die Auslastung meiner Internetanbindung ein.

FirewallBuilder – my home is my castle

Linux-Firewalls sind mächtig kompliziert. Das liegt primär an dem nicht einfachen IPTables. Die Parameter, Parameterreihenfolge und die damit verbundenen Möglichkeiten sind einfach unbegrenzt. Das macht es schwer für Menschen, die nicht ständig damit arbeiten. Die Konfigurationshilfen (z.B. Shorewall) die es für Linux gibt gehen zwar in die richtige Richtung, für mich aber nicht weit genug. Man muss sich dennoch per ssh verbinden, Textfiles mit vi editieren, … wie leicht geschehen da Vertipper, die die Firewall lahmlegen, und als Folge ist man dann ausgesperrt. Deswegen suche ich schon lange nach Abhilfe.

Gestern bin ich per Zufall auf FirewallBuilder gestoßen. Das scheint der richtige Ansatz zu sein. Damit können auch die Windows Admins die Firewall administrieren ohne dass eine Schulung in vi notwendig ist. Ich werde das Teil mal probieren müssen.

Apache vhost_alias

Ich hab ja schon mal hier geschrieben, dass ich für meinen localhost zig Hostnames angelegt habe. Darüber kann ich die Entwicklung der einzelnen Projekte super trennen. Jedes Projekt hat darüber seine eigene URL (z.B. http://intranet.localhost/). Bisher habe ich für jede URL einen virtuellen lokalen Webserver konfiguriert. Schöner Aufwand. Heute habe ich das endlich umgestellt und nutze jetzt mod_vhost_alias. Damit passiert das alles automatisch. Sehr geil. Hier mein neuer VHost:


        ServerName localhost
        VirtualDocumentRoot /var/www/%1
        
                Options FollowSymLinks
                AllowOverride None
        

Damit lege ich pro Projekt jetzt nur noch den Hostnamen an (projektname.localhost) und dann noch den Symlink auf das entsprechende Projektverzeichnis:

ln -s [Projekverzeichnis] /var/www/projektname

Fertig.

Postfix: SMTPs Auth (ausgehend)

Ich bin nicht nur die EDV-Abteilung im Laden meines Bruders, nein auch meine Kisten sind die Internet-Server für Ihn. D.h. auch Mails werden über mich geschleußt. Zum Versenden sollen Sie sich mit meinem Server sicher verbinden. Das setzt 2 Sachen voraus: 1. SMTPs und 2. Authentifizierung. Das erst geht mit Postfix problemlos. Fürs zweite mißbrauchen ich stunne. Ich schreib mir hier mal die Anleitung auf:

  1. SMTP Auth
    etc/postfix/main.cf

    relayhost = localhost:1025
    smtp_sasl_auth_enable = yes
    smtp_sasl_security_options = noanonymous
    smtp_use_tls = no
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    

    /etc/postfix/sasl_passwd

    localhost ACCOUNT:PASSWORD
    

    Wichtig hierbei ist, dass der Relayhost localhost und der Port 1025 ist. Darüber wird im Schritt 2 die SMTPs Verbindung zu meinem Server hergestellt.

  2. SMTPs
    client = yes
    foreground = no
    [smtps]
    accept = 1025
    connect = mail.it4sport.de:smtps
    

    stunnel muss über ein einsprechendes Startskript gestartet werden.

Ziemlich einfach und sicher.

OpenNMS HttpPlugin – Lessons learned

Nachdem ich die Überwachung von Typo3 wie hier beschrieben eingerichtet hatten, waren plötzlich alle Server Typo3 Server :-). Ich hatte übersehen, dass der capsd Daemon von OpenNMS HttpPlugin einen Scann als erfolgreich annimmt, wenn die aufgerufene URL einen positiven Return Code liefert. D.h. auch Webserver, die beim nicht vorhanden sein von /typo3/index.php auf eine Standardseite umleiten waren plötzlich Typo3 Server. Nicht schön!

Also habe ich die Doku zum Plugin gesucht. Obwohl es in der OpenNMS Doku Beispiele gibt, sind die doch zu wenig. Daher habe ich mir die JavaDoc zur entsprechenden Klasse angesehen und Repsonse-String als Porperty entdeckt. Mit dem Parameter funktioniert der Scan erfolgreich nur da wo wirklich Typo3 installiert ist. Hier die verbesserte Version:

   
       
       
       
       
       
       
     

Das ist schon richtig cool. Einmal richtig konfiguriert wird jeder Typo3 Server automatisch erkannt und sofort vernünftig überwacht. Typo3 liefert nämlich diese Seite nur dann richtig aus, wenn auch die Datenbank-Verbindung besteht.

Top 10

Toms Kommentar hat mich mal motiviert meine aktuellen Top 10 aus der [[FOSS]] hier auf zu schreiben.

  1. KVM
    Virtualisierung ist das Thema Nummer eins zur Zeit. Damit sind erst viele andere Sachen möglich. Aktuell lasse ich Dank KVM ein Centos 4.7 auf einer Centos 5.2 als VM laufen. Xen ist raus gefallen aus meiner Top 10 Liste. Es mag zwar sicherer sein aber wer es nicht schafft aktuell zu bleiben fliegt raus.
  2. OpenNMS
    OpenNMS ist wirklich super. Dank Autodiscover hat man super schnell sein Netzwerk integriert und überwacht. Die integrierten Collectoren und Monitore erlauben es auch ganz einfach eigene Test zu integrieren ohne dass man was programmieren muss. Nagios hat es leider nicht mir in die Liste geschafft. Die Nagios Entwicklung ist leider viel zu langsam und Nagios selbst fehlen viel zu viele Selbstverständlichkeiten. Der Zug ist abgefahren.
  3. HAProxy
    HAProxy ist endlich ein wirklicher HTTP(s) Loadbalancer mit allen Features die man braucht. In Minuten eingerichtet und performant ohne Ende. LVS mag zwar ganz nett sein für andere TCP Geschichten aber ehrlich gesagt hatte ich noch nie für etwas anderes wie HTTP(s) Bedarf.
  4. Heartbeat
    Heartbeat ist meine HA-Lösung und dass obwohl ich hier immer noch auf die Version 1! setze. Bei meinen Cluster laufen normalerweise die Resourcen sowieso auf beiden Nodes, so dass ich nur die IP schwenken muss. Trotzdem muss ich mir mal Pacemaker genauer ansehen um beim Ausfall einer Resource auch zu schwenken.
  5. Quagga
    Nichts ist schlimmer als den Überblick zu verlieren. Quagga ist der Routing Daemon unter Linux für mich. Dank der „Cisco“-like Konfiguration kommt man sofort damit zu recht. Perfekt!
  6. WordPress
    Dank WordPress dokumentieren ich endlich meine privaten IT Krempel und finde ihn auch wieder. Durch die Öffentlichkeit meines Blogs bekomme ich auch sehr viel Tipps und Anregungen.
  7. OpenVPN
    Bei OpenVPN fehlt mir nur noch der Client fürs Handy. Zusammen mit Quagga ist OpenVPN wirklich super.
  8. Apache Http Server
    Obwohl es zig andere leichtere Server gibt ist der Apache immer noch mein Arbeitspferd. Richtig konfiguriert ist er richtig schnell.
  9. Postfix
    Kein MTA Daemon ist für mich schneller und einfacher eingerichtet. Neben der Performance von Postfix schätze ich auch die leichte Erweiterbarkeit.
  10. Bacula
    Backups sind super wichtig. Bacula hat mir schon oft den Hintern gerettet. Danke!

Mal sehen wie sich die Statistik so weiter entwickelt. Vor einem halben Jahr oder früher hätte sie noch ganz anders ausgesehen (Xen, Nagios, Exim, dokuwiki, LVS, …)

CentOS Netzwerk Konfiguration

Will man 2 Netzwerkkarten zu einem Bond vereinen, darauf VLans packen und dass dann einer virtuellen Maschine (z.B. KVM) per Bridgen zur Verfügung stellen muss man einiges am Netzwerk konfigurieren. Obwohl es bei CentOS / RHEL ist so einfach ist schreibe ich mir hier doch mal die Parameter als Beispiel auf, damit ich neue Server per Drag & Paste konfigurieren kann :). Alle Files befinden sich unter /etc/sysconfig/network-scripts.
ifcfg-eth0

DEVICE=eth0
BOOTPROTO=none
HWADDR=00:30:48:...
USERCTL=no
MASTER=bond0
SLAVE=yes

ifcfg-eth1

DEVICE=eth1
BOOTPROTO=none
HWADDR=00:30:48:...
USERCTL=no
MASTER=bond0
SLAVE=yes

ifcfg-bond0

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet

ifcfg-bond0.1

DEVICE=bond0.1
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
VLAN=yes
BRIDGE=br0

ifcfg-br0

DEVICE=br0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=static
NETMASK=255.255.255.0
NETWORK=172.16.1.0
IPADDR=172.16.1.2

Fürs Bonding ist noch die Ergänzung in /etc/modprobe.conf notwendig

alias bond0 bonding
options bond0 miimon=100 mode=active-backup primary=eth0

CentOS / RHEL macht es einen wirklich leicht. Wenn ich da an Debian denke und da nur ans Bonding und den ganzen ifenslave-Krampf… Ich mutiere langsam aber sicher zum Red Hat Fan.