Dienstag, 29. Juli 2014

Nagios crashing while using scheduled downtimes, log rotation and MK-Livestatus

So, this is my first post in English so please don't expect too much ;-)


There is a problem in nagios 3.4.x - 3.5.x while using NEB mk_livestatus (https://mathias-kettner.de/checkmk_livestatus.html), setting log_rotation_method and using scheduled downtimes.

This bug leads to a crashing nagios process at the time where a logrotate should be done.

I noticed this after updating nagios core from 3.3.x to 3.4.4 and also in 3.5.1.

There is a patch available at http://tracker.nagios.org/view.php?id=455 (Bug ID 455)

--- nagios-3.5.0/include/downtime.h     2013-02-10 00:55:47.000000000 +0100
+++ /tmp/downtime.h     2013-04-04 17:05:14.000000000 +0200
@@ -39,24 +39,26 @@
        char *service_description;
        time_t entry_time;
        time_t start_time;
-       time_t flex_downtime_start;             /* Time the flexible downtime started */
        time_t end_time;
        int fixed;
        unsigned long triggered_by;
        unsigned long duration;
        unsigned long downtime_id;
-       int is_in_effect;
-       int     start_notification_sent;
        char *author;
        char *comment;
 #ifdef NSCORE
        unsigned long comment_id;
+#endif
+       int is_in_effect;
+#ifdef NSCORE
        int start_flex_downtime;
        int incremented_pending_downtime;
 //     int start_event;
 //     int stop_event;
 #endif
        struct scheduled_downtime_struct *next;
+       time_t flex_downtime_start;             /* Time the flexible downtime started */
+       int     start_notification_sent;
        } scheduled_downtime;

This patch also works with 3.5.1 and should be applicable to 3.4.x.

On my next post i'll talk about creating rpms for nagios (which is very easy if you know how to)


Freitag, 18. Juli 2014

Linux: Active-Directory User-Login für Ubuntu/Debian Servern

Warum muss eigentlich für jedes Linux-System immer ein Passwort aus einem Passwort-Manager geholt werden, nur um eben einen Dienst neuzustarten oder die Logs zu durchforsten, wenn wir doch ein funktionierendes Active Directory im Einsatz haben?

Was muss also her: AD-Login für die Linux-Maschinen (Ubuntu/Debian)!
Da wir aber, wie auf den Windows Servern, nicht jedem den Zugriff und sudo (Kommandos als root ausführen!) erlauben wollen, müssen wir die Zugriffe einschränken, welches ich in diesem kurzen Tutorial ebenfalls tun werde.

Im Wesentlichen brauchen wir dafür die folgenden Pakete:
apt-get install winbind samba krb5-user libpam-krb5

Winbind übernimmt hier als Komponente von Samba im Zusammenspiel mit PAM & Kerberos die Hauptarbeit.

Kerberos

Als erstes werden die Kerberos Konfigurationen erledigt, dazu erstellen wir die /etc/krb5.conf in folgender Weise:

[libdefaults]
  default_realm = DOMAIN.TLD
  allow_weak_crypto = yes
  # passend zum AD:
  default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
  default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

[domain_realm]
  .domain.tld = DOMAIN.TLD

# wir nutzen nicht den PRÄ-2000 Namen!
[realms]
  DOMAIN.TLD = {
   kdc = dc1.fqdn
   kdc = dc2.fqdn
   admin_server = dc1.fqdn
  }
 
# wir nutzen nicht den PRÄ-2000 Namen, daher umschreiben, falls nötig
[appdefaults]
  pam = {
   mappings = DOMAIN_2000\\(.*) $1@DOMAIN.TLD
   forwardable = true
   validate = true
  }

  # Vorbereitung für Apache Kerberos Authentifizierung!
  httpd = {
   mappings = DOMAIN_2000\\(.*) $1@DOMAIN.TLD
   reverse_mappings = (.*)@DOMAIN\.TLD DOMAIN_2000\$1
  }

Zu ändern sind hier nur die Domänen-Namen, also der 2000er Name und die "moderne" Variante, sowie die Domänen-Controller, idealerweise als fqdn.

Jetzt testen wir den ersten Login mit einem AD-Admin und erzeugen ein Kerberos-Ticket mit
 kinit AD-Admin@DOMAIN.TLD

Und lassen uns das erzeugte Ticket anzeigen:
klist

Der Kerberos Part ist damit abgeschlossen.

Samba

Auch hier müssen wir die Konfiguration in /etc/samba/smb.conf ändern:
[global]
    security = ads
    realm = domain.tld
    workgroup = DOMAIN
    idmap uid = 70000-100000
    idmap gid = 70000-100000
    winbind enum users = yes
    winbind enum groups = yes
    winbind use default domain = yes
    winbind refresh tickets = yes
    template homedir = /home/%U
    template shell = /bin/bash
    client use spnego = yes
    client ntlmv2 auth = yes
    encrypt passwords = true
    restrict anonymous = 2
    domain master = no
    local master = no
    preferred master = no
    os level = 0
    socket address = 127.0.0.1
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes

[domain-share]
 path = /foo/bar
 comment = Foo-Bar
 browseable = no
 read only = no
 force user = root
 force group = "DOMAIN+ad-group"
 force create mode = 0666
 force directory mode = 2777
 force directory security mode = 0777
 valid users = @"DOMAIN+ad-group"

Der "domain-share" ist nur ein Beispiel, wie man Samba-Freigaben mit AD Berechtigungen anlegen kann.
Wenn dieser genutzt werden soll, sollte die socket address auf die entsprechende IP-Adresse gesetzt werden oder einfach auskommentiert werden.
Um den Overhead zu reduzieren habe ich dem Samba hier verboten Master zu werden, sowie Druckfunktionen anzubieten.

Die Konfiguration des Samba ist abgeschlossen, wir müssen nun die smb und winbind (Wichtig!) Dienste neustarten
/etc/init.d/smbd restart && /etc/init.d/winbind restart

Fehlt nun noch der AD-Join:
net ads join -U AD-Admin

Ob der AD-Join wirklich erfolgreich war, können wir mit dem Tool wbinfo gut ermitteln:
wbinfo -u | wc -l

wbinfo -u liefert alle User aus dem AD zurück und mit wc -l zählen wir das Ergebnis.
Alternativ geht auch wbinfo -g (Gruppen).
Achtung: es kann eine gewisse Zeit dauern bis wbinfo korrekte Ergebnisse anzeigt!

Damit wir die gefundenen User auch als User im System und damit auch für die Anmeldung nutzen können, müssen wir am "internen" DNS ebenfalls etwas ändern und zwar in der /etc/nsswitch.conf:
Im Wesentlichen ergänzen wir die Zeilen user und group, so dass diese dann folgendermaßen aussehen:
passwd:         compat winbind
group:          compat winbind

Anschließend können wir noch einmal die Dienste neustarten:
/etc/init.d/smbd restart && /etc/init.d/winbind restart

Und einen erneuten Test durchführen, dieses Mal rufen wir die virtuelle passwd inkl. Domänen-User ab:
getent passwd

Hier sollten nun alle Domänen-User im normalen Passwd Format auftauchen:
username:*:71776:70000:Surname, givenName:/home/username:/bin/bash

Die Domänen-User können wir gut an den IDs über 70000 erkennen.

Damit haben wir die Samba Konfiguration abgeschlossen.

PAM

Dem Plugable Authentication Mechanism, kurz PAM, muss nun noch die Nutzung von Winbind beigebracht werden, dazu wird die Datei /etc/pam.d/common-account um folgende Zeile erweitert:
account [success=1 new_authtok_reqd=done default=ignore] pam_winbind.so 

Weiterhin müssen wir Datei /etc/pam.d/common-auth erweitern, so dass sie wie folgt aussieht:
## restricted access
auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed

auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
# here's the fallback if no module succeeds
auth requisite   pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required   pam_permit.so

Wir erinnern uns, wir wollen den Zugriff für bestimmte Nutzer Gruppen einschränken, dazu nutzen wir das PAM-Modul pam_listfile.so und tragen dort zeilen-basiert unsere erlaubten Gruppen (ohne Prefix!) ein.

Damit wir auf jedem System auch ein entsprechendes Home Verzeichnis bekommen, benötigen wir das Modul pam_mkhomedir.so, welches wir in die Datei /etc/pam.d/common-session einfügen:
session required   pam_mkhomedir.so umask=0022 skel=/etc/skel

Abschluss

Damit wir die Änderungen testen können, machen wir einen SSH auf uns selbst:
ssh ad-user@hostname

Wenn das erfolgreich ist, fügen wir noch Samba und Winbind zum Autostart hinzu:
update-rc.d smb defaults && update-rc.d winbind defaults

Das wars!

Nachtrag: RHEL/CentOS/Oracle Linux

Das ganze funktioniert natürlich auch unter RHEL basierten Systen, dafür nutzt man die Pakete:
nscd pam_krb5 samba-common samba

Und ergänzt die Datei /etc/pam.d/system-auth-ac um folgende Zeilen:
auth        sufficient    pam_winbind.so use_first_pass
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
session     optional      pam_winbind.so mkhomedir

Ansonsten variieren natürlich die Befehle etwas.


Bei Fragen bitte einfach melden.



Donnerstag, 17. Juli 2014

ORA-15303: Probleme beim Erstellen der Voting files für ein Oracle RAC auf RHEL-basierten Linuxen mit iSCSI Luns und ASM

Es gibt leider einen nervigen Bug(?) bei der Verwendung von Oracle ASM (http://docs.oracle.com/cd/B28359_01/server.111/b31107/asmcon.htm) im Zusammenspiel mit iSCSI LUNs, der Bug äußert sich bei der Installation einer Grid Infrastructure für Oracle RAC (http://docs.oracle.com/cd/B28359_01/rac.111/b28254/admcon.htm).

Man wird nach der X-basierten Installation der Grid Infrastructure gebeten das root.sh Script auszuführen ($ORACLE_HOME/root.sh), dabei kommt es zu einem Fehler, welcher in folgendem Log gefunden werden kann: (eigentlich könnte die Variable imho auch $GRID_HOME genannt werden, aber seis drum):

$ORACLE_HOME/cfgtoollogs/crsconfig/rootcrs_oraracqs1.log

2013-10-15 15:29:12: Creating voting files
2013-10-15 15:29:12: Creating voting files in ASM diskgroup OCR_VOTING
2013-10-15 15:29:12: Executing crsctl replace votedisk '+OCR_VOTING'
2013-10-15 15:29:12: Executing /u01/app/11.2.0.3/grid/bin/crsctl replace votedisk '+OCR_VOTING'
2013-10-15 15:29:12: Executing cmd: /u01/app/11.2.0.3/grid/bin/crsctl replace votedisk '+OCR_VOTING'
2013-10-15 15:29:13: Command output:
>  Failed to create voting files on disk group OCR_VOTING.
>  Change to configuration failed, but was successfully rolled back.
>  CRS-4000: Command Replace failed, or completed with errors.
>End Command output

Diese Ausgabe hilft erstmal nicht wirklich weiter, also schauen wir im ASM Log nach:

Auf dem 1. Knoten:
/u01/app/grid/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log

Dort können wir folgende Ausgabe sehen:
NOTE: Voting File refresh pending for group 1/0x4b5bc0ec (OCR_VOTING)
NOTE: Attempting voting file creation in diskgroup OCR_VOTING
ERROR: Could not create voting files. It spans across 161 AUs (max supported is 64 AUs)
ERROR: Voting file allocation failed for group OCR_VOTING
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_1511.trc:
ORA-15303: Voting files could not be created in diskgroup OCR_VOTING due to small Allocation Unit size
NOTE: Attempting voting file refresh on diskgroup OCR_VOTING

Das hilft uns schon mal etwas weiter, also überprüfen wir die Disks auf ihre Blocksize (hier sdc)

[root@orarac1 queue]# pwd
/sys/block/sdc/queue
[root@orarac1 queue]# grep "" *block_size
logical_block_size:512
physical_block_size:4096

Was sehen wir hier? Das SAN präsentiert uns unterschiedliche Werte für die Block Size, um dieses Problem zu beheben müssen wir in der Konfiguration der ASM (/etc/sysconfig/oracleasm) den folgenden Wert von false auf true setzen

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=true

Alternativ kann das auch mittels Konfigurations-Tool gesetzt werden:
/usr/sbin/oracleasm configure -b

Anschließend muss die Konfiguration aktiviert werden:
service oracleasm restart

Wenn wir nun das root.sh Skript erneut ausführen, funktioniert die Erstellung der Voting Files auf unserer ASM Diskgroup.


Für weitere Informationen empfiehlt sich das Studium des Oracle MetaLinks DOC-ID: 1526096.1


Dienstag, 1. Juli 2014

Wie funktioniert eigentlich der Linux IO-Stack oder wie kommen wir Performance Problemen auf die Schliche

Bei Performance Problemen ist es immer nett zu wissen, an welchen Stellen man suchen sollte.


Dazu bin ich im Thomas-Krenn Wiki auf eine nette Grafik zum Thema IO-Stack unter Linux gestoßen:

Linux I/O Stack Diagram

Schön und gut, wir wissen nun wie der IO-Stack arbeitet, aber wie kommen wir nun tatsächlich unserem Performance-Problem auf die Schliche? Dazu gucken wir uns das Diagramm von Brendan Gregg - Linux Performance Analysis & Tools an.

Dieses Diagramm zeigt recht anschaulich mit welchen Tools man welchen Problem auf den Grund gehen kann:



Links: