WOL (WakeOnLan) unter Windows

Windows-N00bs finden mit

ipconfig /all

die MAC-Adresse des aufzuweckenden Rechners heraus und nutzen z.B. wake.exe
http://masterbootrecord.de/english/wakeup.php

Syntax: wake.exe MACADRESSE BROADCASTADRESSE
also z.B.

wake.exe AA-BB-CC-DD-EE-FF 192.168.1.255

und packen das ganze in eine CMD-Datei.

Wer’s lieber grafisch mag nutzt MagiWOL oder eins der vielen anderen Tools die eine entsprechende Google-Suche ausspuckt.

Auch nett:
Sofern vom Router unterstützt funktioniert das ganze auch via WAN:
http://stephan.mestrona.net/wol/

Besitzer einer Fritz!Box können übrigens im Menü HEIMNETZ > NETZWERK (oder ähnlich je nach Fritz!Box) ebenfalls einen WOL-Call auslösen.

Für Linux siehe: http://syslog.flocki.org/wol-wakeonlan-unter-linux/

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!

stuff that matters