IT-Blog von Sebastian van de Meer
Veraltet: Solaris und OpenIndiana werden kaum noch eingesetzt. Unter Linux: ip link show, unter FreeBSD: ifconfig.
Es ändert sich im Laufe der Zeit ja mal immer wieder etwas. So auch der Weg mit Netzwerkkarten umzugehen unter Solaris.
Wer also gerade versucht die MAC Adresse seiner lokalen Netzwerkkarte / NIC herauszufinden, dem wird folgender Command helfen:
$ pfexec dladm show-phys -m LINK SLOT ADDRESS INUSE CLIENT rge0 primary 80:ee:73:4a:38:c7 yes rge0
Benutzer wollen ihr E-Mail-Postfach einrichten. Sie geben E-Mail-Adresse und Passwort ein — den Rest soll der Client erledigen. Bei Exchange mit Active Directory funktioniert das seit Jahren automatisch. Aber was, wenn der Mailserver Postfix und Dovecot heißt und kein Exchange in Sicht ist?
Microsoft Outlook unterstützt auch für IMAP und SMTP die automatische Konfiguration per Autodiscover. Man muss nur wissen, wo Outlook nachschaut — und dort die richtigen Antworten bereithalten.
Outlook arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig. Schlägt ein Schritt fehl, geht es zum nächsten:
1. Active Directory (SCP) — Ist der Rechner Domänenmitglied, fragt Outlook per LDAP nach einem Service Connection Point. Dort steht normalerweise die URL des Exchange-Servers. Für reine IMAP-Setups irrelevant.
2. HTTPS auf der E-Mail-Domain — Outlook versucht https://example.org/autodiscover/autodiscover.xml. Funktioniert nur, wenn der Webserver der Domain den Pfad bedient.
3. HTTPS auf autodiscover.<domain> — Outlook versucht https://autodiscover.example.org/autodiscover/autodiscover.xml. Das ist der Weg, den wir nutzen. Ein Webserver unter diesem Hostnamen mit gültigem TLS-Zertifikat — mehr braucht es nicht.
4. HTTP-Redirect — Outlook versucht http://autodiscover.example.org/autodiscover/autodiscover.xml und folgt einem 301/302-Redirect. Weniger sicher, aber ein Fallback.
5. DNS SRV-Record — Outlook fragt _autodiscover._tcp.example.org und folgt dem SRV-Eintrag. Bei einem SRV-Verweis auf eine andere Domain zeigt Outlook eine Sicherheitsabfrage: „Konfiguration von dieser Webseite zulassen?“ Einmalig bestätigen, danach läuft es.
6. Lokale XML-Datei — Outlook sucht auf dem Rechner nach einer vorinstallierten Konfigurationsdatei. Für Firmenumgebungen mit Software-Verteilung relevant.
7. Manueller Assistent — Wenn nichts funktioniert hat, öffnet Outlook den Konfigurationsassistenten. Genau das wollen wir vermeiden.
Outlook macht einen HTTP-POST auf /autodiscover/autodiscover.xml und schickt im Body ein XML mit der E-Mail-Adresse des Benutzers:
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>benutzer@example.org</EMailAddress>
<AcceptableResponseSchema>
http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
</AcceptableResponseSchema>
</Request>
</Autodiscover>
Die Antwort enthält IMAP- und SMTP-Einstellungen. Der Clou: Weil Outlook die E-Mail-Adresse im POST mitschickt, kann ein PHP-Script sie auslesen und als <LoginName> in die Antwort einsetzen. Ohne diesen Trick würde Outlook nur den Teil vor dem @ als Benutzernamen verwenden — bei Mailservern, die die volle E-Mail-Adresse als Login erwarten, ein Problem.
Ein Autodiscover-Webserver reicht für beliebig viele Maildomains. Jede zusätzliche Domain braucht nur einen SRV-Record im DNS:
_autodiscover._tcp.example.org. IN SRV 0 0 443 autodiscover.kernel-error.de.
Outlook folgt dem SRV-Record, zeigt einmalig die Sicherheitsabfrage, und hat danach die komplette Konfiguration. Das PHP-Script auf dem Zielserver beantwortet Anfragen für alle Domains — die E-Mail-Adresse kommt ja im POST mit.
Die konkrete Einrichtung — nginx-Konfiguration, PHP-Script und DNS — beschreibe ich im Nachfolgebeitrag: Outlook Autodiscover für IMAP und SMTP konfigurieren. Dort steht auch das Update von 2026 mit den Korrekturen am PHP-Script (GET-Absicherung, XSS-Schutz) und der Zusammenlegung mit Thunderbird Autoconfig.
Wer seine Konfiguration testen will: Microsoft bietet unter testconnectivity.microsoft.com den „Microsoft Remote Connectivity Analyzer“ an. Dort den Autodiscover-Test auswählen und die eigene E-Mail-Adresse eingeben.
Fragen? Gerne per Kontaktformular.
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.
Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt. Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht. Zusammengefasst bedeutet es: – Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen. – Ich kann diesen Speicher aber nicht anlegen 🙁 Damit wäre also nur das Problem des Anlegens zu lösen! Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit. Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen. Festhalten, es geht los… – gparted öffnen – den >2TB Datenspeicher auswählen
– über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen
– unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden
– den neuen unallocated Speicher markieren
– über den Menüpunkt Partition den Unterpunkt New auswählen
– nun den File system Type auf lvm2 pv setzten und Hinzufügen
– Abschließend noch diese Änderungen anwenden über den Button Apply
Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen.
Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:
$ pvcreate /dev/sda1 $ xe sr-create type=lvm content-type=user device-config:device=/dev/sda1 name-label="4TB-SPEICHER"Ab jetzt ist der Store wie jeder andere nutzbar.
Ich bin inzwischen ja von ZFS schon sehr verwöhnt… Vor allem was so Dinge angeht sich Kombinationen aus Laufwerk, Partition, Mountpunkt und SATA-Port zu merken. Man denkt einfach nicht mehr darüber nach 🙁 Heute bin ich damit mal wieder auf die Nase gefallen. Ok ok…. Natürlich kann man zur Konfiguration auch einfach die UUID nutzen, diese ist dann eindeutig und man kann ähnlich wie bei ZFS die ganzen Zusammenhänge „vergessen“….. Ich finde die UUID-Geschichte aber anstrengend. Diese viel zu lange Nummer zu tippen geht überhaupt nicht, sich diese erst in Konfigurationsfiles zu schieben und dann…. bäääähhhh. Dann kann ich mir die Nummer auch nur wieder schlecht merken.
Wie auch immer. Der Ansatz ist gut und wenn es Konfiguriert ist, geht es ja auch. Um mir nicht noch ein Komando mehr merken zu müssen friemel ich die Zuordnung UUID ==> Devicename immer wie folgt heraus:
ls -Al /dev/disk/by-uuid/ insgesamt 0 lrwxrwxrwx 1 root root 10 17. Sep 11:26 0e6894c5-1dfd-4fcb-8cc4-12290c28c3dc -> ../../sdb3 lrwxrwxrwx 1 root root 10 17. Sep 11:26 11cc385c-7fcc-4b87-88b9-ebe05af67df8 -> ../../sda1 lrwxrwxrwx 1 root root 10 17. Sep 11:26 2fc86b49-ad36-4755-bd72-aba0ec54f2e4 -> ../../sdb2 lrwxrwxrwx 1 root root 10 17. Sep 11:26 ca266482-0623-43a1-8741-70f8de485023 -> ../../sdb1
Jemand eine bessere Idee? In diesem Sinne….
Fragen? Einfach melden.
Ein Scrub ist die Integritätsprüfung von ZFS — jeder Block im Pool wird gelesen und seine Checksumme verifiziert. Beschädigte Blöcke werden automatisch aus der Redundanz repariert (Mirror oder RAID-Z). Ohne Redundanz erkennt ZFS den Fehler immerhin, kann ihn aber nicht korrigieren.
Empfehlung: Einmal pro Woche oder mindestens einmal im Monat. Auf Produktivsystemen am besten per Cronjob.
zpool scrub backup
zpool status backup
pool: backup
state: ONLINE
scan: scrub in progress since Sun May 27 11:11:00 2012
4.20G scanned out of 74.5G at 102M/s, 0h11m to go
0 repaired, 5.64% done
Braucht man die I/O-Leistung gerade für etwas anderes:
zpool scrub -s backup
Im Status sieht man dann den Unterschied — stopped statt completed:
# Abgebrochen scan: scrub stopped after 0h7m with 0 errors on Sun May 27 11:18:52 2012 # Normal beendet scan: scrub completed after 0h7m with 0 errors on Sun May 26 10:52:13 2012
Ein abgebrochener Scrub setzt beim nächsten Start nicht dort fort, sondern beginnt von vorne.
# Jeden Sonntag um 02:00 alle Pools scrubben 0 2 * * 0 /sbin/zpool scrub backup
Unter FreeBSD läuft der Scrub standardmäßig über periodic daily — dort muss man nichts extra einrichten. Unter Linux gibt es je nach Distribution einen systemd-Timer (zfs-scrub-weekly.timer) oder man legt den Cronjob selbst an.
Mehr zu ZFS: ZFS RAID: Mirror und RAID-Z und ZFS Snapshots. Fragen? Einfach melden.
Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Unter Linux gibt es zahlreiche RSS-Reader (Thunderbird, Liferea, Newsboat).
Ich habe gerade meinen lieblings RSS-Feed Reader Liferea auf der Solariskiste kompiliert. Ich finde es gibt einfach keinen besseren! Spannenderweise konnte ich auch keinen „fertigen“ finden. Na bis auf Thunderbird…. Aber Thunderbird? So gefällt es mir besser *hüpf*.
Mein Creative ZEN Mozaic lässt sich nur per MTP mit Daten befüllen. Unter Windows kein Problem, unter Linux bringen die meisten Distributionen FUSE-Treiber mit. Solaris und OpenIndiana bringen von Haus aus nichts mit. Die Lösung: gMTP.
Das Paket gibt es direkt auf der gMTP-Downloadseite. Auspacken und installieren:
gunzip gmtp-1.3.1-i386.pkg.gz pkgadd -d gmtp-1.3.1-i386.pkg
Fehlende Abhängigkeiten aus dem SFE-Repository nachinstallieren:
pkg install medialib libid3tag id3lib
libmtp war zum Zeitpunkt dieses Beitrags nicht als Paket verfügbar und musste selbst gebaut werden. Quellcode gibt es auf SourceForge.
gunzip libmtp-1.1.1.tar.gz tar xvf libmtp-1.1.1.tar cd libmtp-1.1.1 ./configure --prefix=/usr gmake gmake install
Danach lässt sich gMTP über /usr/local/bin/gmtp starten. Der Creative ZEN Mozaic wird erkannt, Dateien lassen sich per Drag and Drop übertragen.
Fragen? Einfach melden.
Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. USB-Kameras und Scanner funktionieren unter Linux mit SANE/XSane problemlos.
Man man man… Jetzt habe ich mich doch tatsächlich 1 Stunde lang in etwas sehr sinnlosem verrannt. *kopfschüttel*
Da will ich mal eben ein Bild mittels xsane von einem USB-Scanner einlesen. Da findet xsane auf dem Solaris 11 System den Scanner nicht. Genau so verhält es sich mit einer USB Digitalkamera….. Ich habe ja überall nachgeschaut, nur wohl ohne Verstand!
Die Lösung war natürlich recht simpel. Einfach mal das Paket: libusbugen installieren. *Narf*
Fragen? Einfach melden.
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die hier beschriebene Nagios-Überwachung bezieht sich auf XenServer 6.x/7.x. Wer heute Virtualisierung überwachen will, sollte sich Proxmox VE oder XCP-ng anschauen.
Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können.
Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.
So dann wollen wir mal:
Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.
$ mkdir /001 $ cd /001
Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.
$ wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm $ rpm -hiv epel-release-5-4.noarch.rpm $ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo
So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:
$ yum install --enablerepo=epel nrpe $ chkconfig nrpe on
Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:
$ nano -w /etc/sysconfig/iptables ….. -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT ….
Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.
$ yum install --enablerepo=epel nagios-plugins hddtemp ….
Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:
$ modprobe ipmi_devintf $ modprobe ipmi_si
Konfigurieren lässt sich nrpe nun wie bekannt über:
$ nano -w /etc/nagios/nrpe.cfg
Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.
Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich. Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Lokale Paketquellen lassen sich unter FreeBSD mit poudriere und unter Linux mit apt-mirror oder createrepo einrichten.
Man kann zwar über das „klickbunit“ Interface XenCenter für seinen einzelnen XenServer neue ISO libarays anlegen, diese können dann leider nur auf einem Windows File Shareing (CIFDS) oder NFS ISO Share liegen. Klar, man könnte nun eine VM auf dem XenServer installieren und dort einen solchen Share anlegen. oder eine Kiste neben den Server stellen, welcher die ISOs vorhält. In größeren Umgebungen kein Problem… Im „Kleinen“ schon mal nervig.
Ich habe für mich eine einfache Lösung gefunden. Ich schraube einfach eine weitere kleine Platte in den Server, lege dort die für mich wichtigen ISOs ab und baue mir eine lokale ISO library. So habe ich die nötigen ISOs immer auf der Kiste, selbst wenn alles andere aus sein sollte.
Also lokalen Speicherplatz für die ISOs habe ich an eine 160GB SATA Platte von WD gedacht. Diese wird nicht gespiegelt oder ähnliches, da die ISO Files für mich erstmal keinen Wert haben. Brennt die Platte wirklich ab, kopiere ich die ISO Files halt auf eine neue.
Nach dem Einbau ist die WD Platte in meinem System als /dev/sde zu finden. Als erstes werde ich nun auf ihr eine primäre Patrion vom Type 83 (Linux) anlegen:
$ fdisk /dev/sde The number of cylinders for this disk is set to 19457. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help):
Die Hilfe zu fdisk kann sicher jeder selbst lesen… Ich schaue als erstes über p nach ob ich wirklich auf der richtigen Platte bin, denn p listet mir die Partitionen auf der Platte auf. Dann erstell ich mit n ==> p ==> 1 eine neue primäre Partition und schreibe am Ende alles mit w auf die Platte. q beendet als letztes fdisk.
Nun muss ich die neue Partition noch formatieren. Als Dateisystem finde ich ext3 ganz passend:
$ mkfs.ext3 -L ISO-Store /dev/sde1
mke2fs 1.39 (29-May-2006)
Filesystem label=ISO-Store
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19546112 inodes, 39072080 blocks
1953604 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Nun erstelle ich einen Mountpoint unter welchem ich die Platte einbinden möchte:
$ mkdir /ISOs
Schon kann ich die Platte mounten:
$ mount /dev/sde1 /ISOs
Noch schnell eine kontrolle ob alles dort ist wo es hin soll:
$ mount|grep ISO /dev/sde1 on /ISOs type ext3 (rw)
Mit einem Eintrag in die fstab (ich muss immer aufpassen nicht vfstab zu schreiben) sorge ich nun dafür dass die neue Platte bei jedem Start des Servers wieder eingebunden wird.
$ vi /etc/fstab
und dann folgende Zeile einfügen:
/dev/sde1 /ISOs ext3 defaults 0 0
Jetzt kommt das wirklich spannende. XEN die neue Platte als localen ISO Speicher schmackhaft zu machen:
$ xe sr-create name-label=ISOs type=iso device-config:legacy_mode=true device-config:location=/ISOs content-type=iso 00da02b3-8b46-bade-6d00-e109e262ede9
Schaut doch schon gut aus, oder? Dann lassen wir uns mal die neue ISO library anzeigen:
$ xe sr-list uuid=00da02b3-8b46-bade-6d00-e109e262ede9
uuid ( RO) : 00da02b3-8b46-bade-6d00-e109e262ede9
name-label ( RW): ISOs
name-description ( RW):
host ( RO): xenserver01-kernel-error.local
type ( RO): iso
content-type ( RO): iso
Warum auch immer, wird die Platte bei mir an diesem Punkt immer ausgehangen. Ich könnte es jetzt einfach wieder mounten und nutzen, würde denn noch vorschlagen hier den Server selbst einmal zu rebooten. So kann man gleich sehen ob die Platte wieder richtig eingebunden wird. Nach dem Reboot schaue ich also nach ob die Platte wieder richtig eingehangen wurde:
$ mount|grep ISO/dev/sde1 on /ISOs type ext3 (rw)
Jetzt kopiere ich das nötige ISO auf die Platte:
scp WindowsSvrStd2008R2.iso root@10.44.2.88:/ISOs WindowsSvrStd2008R2. 100% |******************************************************************************************************************************************************************************************| 3052 MB 01:28
Im XenCenter sollte man nun schon das neue SR mit dem Namen „ISOs“ sehen. Klicke man nun am Reiter Storage auf Rescan wird das hochgeladene ISO gefunden und kann verwendet werden. Ich muss nun also nur noch alle meine ISOs dort hochschieben und fertig ist!
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑