Monitoring VSphere with Zabbix and vCLI

First of all, the items that can be fetched with zabbix from vsphere servers are very limited.

https://www.zabbix.com/documentation/2.4/manual/config/items/itemtypes/simple_checks/vmware_keys

If you want to fetch additional items from ESX-Servers, you can use the vSphere CLI – a perl toolkit with several handy tools.

https://my.vmware.com/web/vmware/details?downloadGroup=VCLI_PERL50U1_OSS&productId=242

One of the tools i can recommend from the toolkit is performance.pl

You can fetch almost all available items from virtual machines and feed it to zabbix. We are fetching the cpu readystates to monitor the machines and decided whether they are overcommitted.

DNS-Server mit RDNSS verteilen

Neben den üblichen Dingen wie Netz und Router kann per NDP auch der DNS-Server an die Clients verteilt werden.

Es reicht ein Eintrag in radvd.conf auf dem Router/Gateway in der Form:

RDNSS 2620:0:ccc::2 2620:0:ccd::2
{
AdvRDNSSLifetime 300;
};

Ab jetzt erhalten die Clients auch die nötigen Informationen.
Das jedoch auf Clientseite zu verwerten ist äußerst traurig implementiert unter Windows, wie folgende Übersicht zeigt:
(sechste Spalte)

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Unter Linux reichte mir das Paket rdnssd, was mir nach der Installation automatisch die resolv.conf ergänzt hat. Geht sicherlich auch mit anderen Tools.
Unter Windows scheint es rdnssd-win32 zu geben – beim Test hatte ich jedoch keinen Erfolg.

IPv6: Privacy Extensions einschalten

Jetzt hat man mit v6 Millionen von Adressen verfügbar, aber nur eine handvoll Clients. Zusätzlich wird standardmäßig ein Teil der Rechner MAC-Adresse des physikalischen Interfaces in die v6-Adresse integriert, wenn man die Stateless Address Autoconfiguration (SLAAC) nutzt.

Dies lässt sich deaktivieren mit net.ipv6.conf.all.use_tempaddr=2 in der /etc/sysctl.conf

Nach einem stop/start des Interfaces beinhaltet das IF nicht mehr einen Teil der Mac.

Link-Lokal-Adressen pingen – connect: Invalid argument

sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c
connect: Invalid argument

Hierzu ist die offizielle Meinung, es kann mehr Interfaces geben, die das Link-Lokal-Netz fe80 anliegen haben. Man muss das Interface/Zone beim Pingen definieren.

Weg1

sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c%br0
PING fe80::cacb:b8ff:fece:6e8c%br0(fe80::cacb:b8ff:fece:6e8c) 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.701 ms

Weg2:

PING fe80::cacb:b8ff:fece:6e8c(fe80::cacb:b8ff:fece:6e8c) from fe80::221a:6ff:fe5d:6989 br0: 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.468 ms

Weg3:

sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c%4
PING fe80::cacb:b8ff:fece:6e8c%4(fe80::cacb:b8ff:fece:6e8c) 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.476 ms

Leider sehe ich keinen Grund für die Definition des Source-Interfaces. Bei ipv4 entscheidet der Routing-Prozess das zu verwendende Interface:

sb@s1:~$ ip ro get 8.8.8.8
8.8.8.8 via 192.168.0.1 dev br0 src 192.168.0.101

Bei v6 sieht die Ausgabe auch korrekt aus – es interessiert den Prozess jedoch nicht:

sb@s1:~$ ip ro get fe80::cacb:b8ff:fece:6e8c
fe80::cacb:b8ff:fece:6e8c from :: dev br0 src fe80::221a:6ff:fe5d:6989 metric 0

sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c
connect: Invalid argument

Warum ist das so?

IPv6 für den Alltag – Ein Erfahrungsbericht

Jeder kennt ja längst die Vorteile von ipv6 – hier mal einige Infos aus der Sicht eines Anwenders/Admins:

Die Telekom verteilt zusätzlich zur öffentlichen v4-Adresse im Dual-Stack auch v6-Adressen für die pppoe-Verbindung des Routers aus dem Netz 2003::/19.

Die Clients im lokalen Netz erhalten automatisch vom Router eine zusätzliche v6-Adresse.

Bei v6 gibt es kein NAT mehr, v6-Geräten sind somit direkt und erstmal ungeschützt aus dem Internet erreichbar.

Ein Router nutzt das Neighbor Discovery Protocol (NDP)¹ um Geräten im Netz die nötigen Infos bezüglich Netz und Größe sowie Router zukommen zu lassen. Ganz ähnlich wie DHCP.

Ein ähnliches Tool unter Linux/Unix, das die Infos ankündigt heißt radvd².

Für die Kommunikation im lokalen Netz und ausschließlich dort, besitzt jeder Client eine Link-Local-Adresse, die auch nicht geroutet ist.
Über diese Adressen fährt auch das NDP.

Hat sich der Client per NDP informieren lassen, trägt er auch den Default-GW ein – dieser ist bei einem Speedport die erste Nutzbare Adresse im Netz und somit fe80::1

Thema Firewall:

Ich nutze lokal auf allen Clients folgende FW-Schnipsel für ipv6:

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -s fe80::/10 -j ACCEPT

Das erlaubt ausschließlich Verkehr von innen nach draussen mit folgenden Ausnahmen:
Ich akzeptiere eingehenden Verkehr aus dem Link-Local-Netz (mein Lan) und erlaube Antwortpakete zu bestehenden Verbindungen.

Da mein Provider noch kein v6 anbietet, nutze ich den kostenlosen Tunnel-Service von SIXXS³.

¹ http://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol
² http://www.litech.org/radvd/
³ https://www.sixxs.net/

KMS Server – Uhrzeit!

Die KMS Clientaktivierung klappt nur, wenn die Uhrzeit auf dem Client stimmt.

Auf Abweichungen reagiert er äußerst zickig…

Den Status kann man prüfen mit slmgr /dli

Die Aktivierung und somit eigene ID zurücksetzen mit slmgr /rearm

Die Aktivierung manuell anstoßen mit slmgr /ato

C:\Dokumente und Einstellungen und C:\Benutzer

Seit Vista/Win7 finden sich die Benutzerordner in C:\Benutzer\

Aus Kompatibilität legt Windows jetzt einen Link an von C:\Dokumente und Einstellungen zu C:\Benutzer an.

C:\Dokumente und Einstellungen selbst ist jedoch nicht betrachtbar, da es lediglich ein Link auf C:\Benutzer darstellt.

Durch div. unglückliche Umstände kann es passieren, dass Anwendungen wegen der Links erneut die Ordnerstruktur erstellen. Dadurch entstehen kaskadierte Ordner wie

C:\Documents and Settings\All Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\AVG2013

Bei meinen Tests, war der Ordner C:\Users\All Users\Anwendungsdaten nur wieder ein Link.

Nach dem Löschen des Links mit rmdir Anwendungsdaten hat sich das Problem erledigt.

Windows Backupstatus per E-Mail

Über Windows-Backup passenden Job anlegen täglich/wöchentlich usw.
Über Aufgabenplanung neuen Task anlegen

Häckchen setzen bei Unabhängig von Anmeldung ausführen

Bei Trigger auf NEU
Aufgabe starten bei neuem Ereignis
Umschalten auf Benutzerdefiniert
Neuer Ereignisfilter
Auf XML umschalten und manuell bearbeiten aktivieren und bestätigen die Warnung

Jetzt für fehlgeschlagenes Backup das einfügen:
<QueryList>
<Query Id=”0″ Path=”Application”>
<Select Path=”Microsoft-Windows-Backup”>*[System[Provider[@Name='Microsoft-Windows-Backup'] and (Level=4 or Level=0) and (EventID=14)]] and *[EventData/Data[@Name='HRESULT']!=’0′]</Select>
</Query>
</QueryList>

Bei Aktionen Programm starten auswhählen und powershell eintragen
Bei Paramter folgendes – für Versand von Mail über vorhandenen Mailserver:

Send-MailMessage -SmtpServer 192.168.2.1 -Port 27 -to anfragen@bla.blup -from Administrator@bla.blup -subject ‘Backup nicht erfolgreich’

Bei erfolgreichem Backup muss man nur den Trigger so anpassen:

<QueryList>
<Query Id=”0″ Path=”Application”>
<Select Path=”Microsoft-Windows-Backup”>*[System[Provider[@Name='Microsoft-Windows-Backup'] and (Level=4 or Level=0) and (EventID=14)]] and *[EventData/Data[@Name='HRESULT']=’0′]</Select>
</Query>
</QueryList>

Quellen:

http://www.administrator.de/forum/mailversand-nach-erfolgreicher-windows-serversicherung-192460.html

http://technet.microsoft.com/en-us/library/hh849925.aspx

http://www.bluecompute.co.uk/blogposts/configure-email-notification-for-windows-server-backup/

Cups Drucker an Win7 freigeben – Der Druckprozessor ist nicht vorhanden

Wie flanscht man einen Drucker, der in CUPS integriert ist, automatisch an Windows an:

Man installiert den Drucker in CUPS über die gewohnte Oberfläche Port 631 usw.

Man achtet darauf, dass Samba eine Freigabe mit dem Namen [$print] hat.
In dieser sucht ein Windowsclient automatisch nach Treibern – dieses Feature nennt sich Point & Click.
Man lege in das passende Share vorab die nötigen Treiber in der nötigen Struktur.
/var/lib/samba/drivers/x64/

Dorthin legt man die Windows-Cups-Treiber mit dem Namen cups-windows-6.0-source-tar.gz ausgepackt.
Google hilft zur weiteren Suche.

Beim Doppelklick auf den Druckernamen in der Netzwerkfreigabe werden automatisch die Treiber installiert.
Leider bricht dies mit der Fehlermeldung – Der Druckprozessor ist nicht vorhanden ab.

Lösung ist, in der Übersicht der Drucker einen Klick auf Remotedrucker anzeigen – bejahen – jedoch dann mit Abbrechen die Installation abbrechen. Es erscheinen die Details und div. Reiter des Drucker. Dort unter dem Punkt Anschlüsse ein Häckchen setzen bei dem einzigen Eintrag/Prozessor und speichern.

Jetzt werden mit einem Doppelklick die Drucker korrekt installiert.

Falls normale Benutzer auch Point&Click nutzen dürfen sollen, sei dies erwähnt:

http://wiki.itsm.de/index.php/Druckerverbindung_kann_nicht_hergestellt_werden_-_Zugriff_verweigert

NFS und FS ACLS – eine erste Beobachtung

Die Kernel-Entwickler haben im Jahr 2012 entschieden¹, dass die Mountoption acl jetzt standardmäßig aktiv ist und somit rausgeflogen ist. Es gibt natürlich weiterhin noacl zum Deaktivieren.
ACLS auf einer lokalen Partition für eine Datei zu setzen, erfolgt mit:

setfacl -m u:root:r bla

Bindet man jetzt ein NFS4-Share von einem entfernten Rechner ein mit

mount.nfs4 -o acl 192.168.0.254:/ /bla

und versucht obigen Befehl erneut, gibt es folgendes Problem:

setfacl: /bla/: Operation not supported

Mein letzter Stand ist, dass man acls auf nfs share setzen kann – benötigt hierfür aber ein gesondertes Tool nfs4acl (Debianpaket nfs4acl).
Für meine Backupzwecke jedoch wertlos – ich möchte die Rechte des lokalen Dateisystems beim Kopieren erhalten und nicht mit nfs4acl Rechte setzen auf dem NFS-Share.
Zeit für eine Anfrage an die Entwickler.

Update 29.09:

http://www.spinics.net/lists/linux-nfs/msg47081.html

¹ http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea6633369458992241599c9d9ebadffaeddec164