ldif_read_file: checksum error on „/etc/ldap/slapd.d/cn=config.ldif“

Problem:
cn=config.ldif wurde händisch modifiziert.
Beim Starten des LDAPs erwartet mich folgende Meldung im Syslog

ldif_read_file: checksum error on "/etc/ldap/slapd.d/cn=config.ldif"

Lösung:
Konfiguration backuppen, LDIF modifizieren und Konfiguration neu erstellen lassen.

mkdir /tmp/ldap-backup
service slapd stop
cd /etc/ldap/slapd.d
slapcat -n0 -F . > /tmp/ldap-config.ldif
mv * /tmp/ldap-backup
nano /tmp/ldap-config.ldif
slapadd -n0 -F . -l /tmp/ldap-config.ldif
service slapd start

Nun sollte der Fehler weg und die Changes an der LDIF in der Konfiguration aktiv sein.

str2entry: entry -1 has invalid DN sambaDomainName

Problem:
Der Import eines LDIF Dumps bricht immer wieder bei der DN sambaDomainName ab.

Lösung:
Zuerst muss man der LDAP Datenbank seine Schemen beibringen.

Ich installiere samba-doc und entpacke die Samba Dateien an ihren Platz

apt-get samba-doc
cd /etc/ldap/schema
zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > samba.schema
zcat /usr/share/doc/samba-doc/examples/LDAP/samba.ldif.gz > samba.ldif

Ich stoppe LDAP, und bereinige das Datenbankverzeichnis

service slapd stop
cd /var/lib/ldap
rm -rf *

Im Anschluss bekommt man den genannten Fehler beim Import eines LDIFs

str2entry: entry -1 has invalid DN sambaDomainName

Bei früheren Versionen von OpenLDAP hatte es genügt, die *.schema Dateien in das Verzeichnis zu kopieren. Nicht so bei den neueren Versionen!! Der Dienst kennt das Attribut „sambaDomainName“ noch nicht!

Ich wechsel also nach /etc/ldap/slapd.d, lösche alles und generiere den Inhalt neu

service slapd stop
cd /etc/ldap/slapd.d
rm -rf *
slaptest -f ../slapd.conf -F .
chown -R openldap.openldap ../slapd.d/

Nun klappt auch der Import 😉

cd /var/lib/ldap
rm -rf *
slapadd -l /tmp/migrate.domain.ldif
slapindex -v
chown -R openldap.openldap ../ldap
service slapd start

Tip: slapadd kann mit dem Schalter „-u“ den Vorgang simulieren. Damit testet man, ob der Import auch wirklich durchlaufen würde.

Weitere Infos kann man im Debian Wiki nachlesen

WOL (wakeonlan) unter Linux

Problem:
Ich möchte meinen Rechner via WakeOnLan starten. Er unterstützt WOL im Bios.

Lösung:
Ich muss mit „ethtool“ das entsprechende Flag auf der Netzwerkkarte setzen. Los geht’s!

Ich besorg mir auf dem aufzuweckenden Rechner zuerstmal „ethtool“

apt-get install ethtool

Dann schau ich mir mit „ethtool“ meine Netzwerkkarte etwas genauer an – in meinem Fall eth0.

ethtool eth0

Die Ausgabe kürze ich auf die entsprechend wichtige Passage

Supports Wake-on: g
Wake-on: d

Die Karte unterstützt als den WOL Modus „g“ und derzeit ist Wake-On deaktiviert „d“

Da ich die Werte bei jedem Bootvorgang gesetzt habe möchte, bediene ich mich der Datei /etc/network/interface und füge eine „post-up“ Anweisung hinzu.

Der Abschnitt der Karte eth0 schaut dann wie folgt aus

auto eth0
iface eth0 inet static
address 192.168.222.254
netmask 255.255.255.0
dns-nameserver 192.168.222.254
dns-search net.home
post-up ethtool -s eth0 wol g

Dann starte ich das Netzwerk neu und prüfe den Wert „Wake-On“

service networking restart
ethtool eth0


Supports Wake-on: g
Wake-on: g

Sitzt!

Nun notiert man sich am besten gleich mal die MAC Adresse der Netzwerkkarte und dann darf getestet werden. Man findet sie mit folgendem Befehl

ip addr show eth0

Unter Linux gibt es ein Kommandozeilenwerkzeug und ein Werkzeug für GNOME. Welches ihr nutzt, kommt wohl auf den Einsatzzweck an. Ich installiere beide

apt-get install wakeonlan gwakeonlan

Ich leg mir gleich n Alias in der .bashrc an

alias server-up="wakeonlan 11:22:33:44:55:66"

So kann ich mit dem Befehl server-up in der Konsole den Rechner wecken 😉

Auf gehts, Rechner runterfahren und wakeonlan testen =)

Die Windows Anleitung hat Kollege sennator für uns niedergeschrieben

LDAP – Passwort Self-Service

Wer seinen Nutzern ein einfaches Webinterface zum Zurücksetzen des eigenen Passwortes zur Verfügung stellen möchte, der ist beim LDAP ToolBox Projekt richtig aufgehoben.

http://ltb-project.org/wiki/documentation/self-service-password

Einfach das DEB Paket herunterladen, installieren und dann die Konfiguration am Webserver nach eigenem Ermessen vornehmen. Funktionierte bisher immer Bestens!

regex-markup – Einfärben von Befehlen

Regex Markup ist ein witziges Werkzeug, um auf der Konsole Ausgaben einzufärben.

De Projekthomepage findet sich hier http://www.nongnu.org/regex-markup/


cd /tmp
wget http://savannah.nongnu.org/download/regex-markup/regex-markup_0.10.0-1_amd64.deb
dpkg -i regex-mark*.deb

Erster Einsatz:
ping- und syslog-Ausgaben einfärben

Dazu modifiziert man die ~$user/.bashrc, folgende Zeilen einfach anhängen

ping() { /bin/ping $@ | remark /usr/share/regex-markup/ping; }
syslog () { /usr/bin/tail -n 100 -f /var/log/syslog | remark /usr/share/regex-markup/syslog; }

Nach einem erneuten Login kann man das Ergebnis überprüfen!

S.M.A.R.T. – Selfmonitoring von Festplatten unter Linux

Problem:
Ich möchte wissen, wie es um meine Festplatten steht.

Lösung:
Wir nutzen die S.M.A.R.T. Funktion der Festplatten. Bei älteren Rechnern (mit IDE) musste diese Option noch im BIOS aktiviert werden. Neuere Bioses und Festplatten unterstützen dieses Feature aber schon von Haus aus.

Ich installiere also die „smartmontools“

apt-get install smartmontools

Im Anschluss steht auch schon der Befehl „smartctl“ bereit.

Wichtig: 
Mit diesem Werkzeug sollte man die Blockdevices 
direkt ansprechen! Man bekommt keine Info wenn 
man den S.M.A.R.T Status eines Softwareraids abruft!

Im Beispiel nutze ich das Device /dev/sda und /dev/sdb, ich habe also 2 Festplatten die ich überwachen möchte.

Mit dem folgenden Befehl bekomme ich direkte Rückmeldung von den Platten

smartctl -H /dev/sda
smartctl -H /dev/sdb

Ergebnis bei Beiden:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Möchte man die Ausgabe aller verfügbarer Werte haben, dann muss man den Schalter „–all“ nutzen.

smartctl --all /dev/sdb

Weitere Infos findet man bei Wikipedia

Zum automatischen Monitoring wird auch hier ein Daemon mit geliefert.

Wir editieren die Datei /etc/default/smartmontools und kommentieren die beiden Optionen ein

# uncomment to start smartd on system startup
start_smartd=yes

# uncomment to pass additional options to smartd on startup
smartd_opts="--interval=3600"

Den oberen Teil der Datei lassen wir in Ruhe! 😉

Nun packen wir noch die zugehörige Konfiguration in /etc/smartd.conf an. Der Befehl

grep -v '#' /etc/smartd.conf | sort -u

zeigt die in meinem Fall ausreichenden Zeilen an

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
/dev/sda -a
/dev/sdb -a

Je nach Systemkonfiguration sollte man die Datei anpassen. In meinem Fall (2 SATA Platten) genügen die beiden zusätzlichen Zeilen allerdings.

Mit

/etc/init.d/smartmontools restart

aktiviert man die Einstellungen.

Im Fehlerfall gehen die Mails an „root“, leider kann man dafür keine alternative deklarieren.

Man kann allerdings die aliase des Systems modifizieren und die Mails an „root“ einfach weiterleiten lassen.

In /etc/aliases sollte eine Zeile mit root beginnen und wie folgt erweitert werden

root: me@gmail.com

Mit dem Befehl „newaliases“ aktiviert man die Modifikation!

Failed to allocate internet-domain X11 display socket.

Wer diese Message im Log /var/log/auth.log vorfindet, hat evtl versucht eine Anwendung über X11 zu forwarden.

In meinem konkreten Fall ist die Deaktivierung von IPv6 schuld.

Lösung: Man gewöhnt dem SSH-Daemon ebenfalls das ipv6 Protokoll ab.

Dazu modifiziere ich die Datei /etc/default/ssh und füge folgende Option ein

SSHD_OPTS=-4

Hintergrund: -4 weisst den SSH an, nur ipv4 zu nutzen. Weitere Optionen kann man via

man sshd

nachschlagen!

Im Anschluss startet man den SSH neu und versucht das Forwarding erneut.
Im besten Fall funktioniert es nun wie gewohnt!

Software RAIDs unter Linux mit mdadm

Problem:
Ich habe eine Software RAID auf einem Mietserver und möchte mich über den Zustand informieren lassen falls etwas gravierendes vorliegt.

Lösung:
Softwareraids werden in der Regel über das Paket „mdadm“ administriert

Description-de: Werkzeug zum Verwalten von Multi-Disk-Arrays unter Linux (Software RAID)
Mdadm ist ein Programm, das zum Erstellen, Verwalten und Beobachten von
MD-Geräten für Software-Raid oder Multipath-I/O benutzt werden kann.
.
Dieses Paket konfiguriert mdadm automatisch so, dass beim Systemstart die
Arrays zusammengefügt werden. Falls nicht benötigt, kann diese Funktion
deaktiviert werden.

Man kann also auf der Shellkonsole direkt mal prüfen, ob ein solcher Prozess läuft

ps uax | grep mdadm

Die Ausgabe sollte eine derartige Zeile zeigen:

/sbin/mdadm --monitor --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog

Bedeutet also, dass das RAID mit mdadm erstellt, genutzt und auch überwacht wird.

Die verfügbaren RAIDs kann man sich auch anschauen.

cat /proc/mdstat

Man hier zB auch den Fortschritt wenn ein RAID „created“ oder „rebuilded“ wird.

Prinzipiell sollte man sich unter Linux/Debian/Ubuntu mal die zugehörigen Konfigurationdateien anschauen.

more /etc/default/mdadm
more /etc/mdadm/mdadm.conf

Die 2. Konfigurationsdatei kann auch, je nach eingesetzter Distribution, direkt in /etc zu finden sein.

Die Datei /etc/default/mdadm sollte auf jeden Fall mit folgenden Optionen aktiviert sein

# INITRDSTART:
# list of arrays (or 'all') to start automatically when the initial ramdisk
# loads. This list *must* include the array holding your root filesystem. Use
# 'none' to prevent any array from being started from the initial ramdisk.
INITRDSTART='all'

# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=true

# AUTOCHECK:
# should mdadm run periodic redundancy checks over your arrays? See
# /etc/cron.d/mdadm.
AUTOCHECK=true

# START_DAEMON:
# should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

Diese Zeilen sorgen für den Monitorprozess, welcher zu Beginn mit „ps uax|grep mdadm“ gezeigt wurde.

Dann schauen wir uns die Datei /etc/mdadm/mdadm.conf näher an
Hier sollte die Zeile

MAILADDR root

zu finden sein. Wenn man sich nicht sicher ist, ob man die Mails an „root“ bekommt, dann kann man gerne seine eigene Emailadresse hier eintragen.

Dann sollten noch ARRAY Zeilen in der Datei zu finden sein. Das sind die im System definierten und verfügbaren Softwareraids.

Sollten keine ARRAYs zu finden sein, dann existieren keiner oder die Datei wurde nach Erstellung nur mangelhaft gepflegt. Solche Dinge können gelegentlich bei Rootservern auftreten. Diese werden ja idR automatisiert erstellt und deshalb fehlen diese Zeilen gerne. Kann, muss aber nicht! mdadm scannt ja beim Systemstart die verfügbaren Partitionen und regelt das selbst. Allerdings gibt es in dem Fall einen entsprechenden Eintrag im Syslog. Tonus: „No Arrays defined“

Man kann die ARRAY Zeilen aber selbst hinzufügen

mdadm --detail --scan | tee -a /etc/mdadm/mdadm.conf

zeigt dir die verfügbaren ARRAYS an UND hängt (-a = append) diese Zeilen an die angegebene Datei an.

Nun kann man sich noch eine Testmail schicken lassen

mdadm --monitor --scan --test

Der Prozess muss mit „Strg + C“ beendet werden. In der Zwischenzeit sollte man eine Email erhalten haben. Check das gleich mal!

Falls die Mail nicht ankommt, dann ist idR der Mailserver zu prüfen. Thema „mailq“ und „runq“

Künftig wird man vom System benachrichtigt, wenn dem Monitorprozess irgendwelche Ungereimtheiten (DEGRADED o.ä.) auffallen.