1und1 nutzt QUEMU für Tests ;)

Gerade habe ich bei meinem Server in der GRUB-Konfiguration einen Hinweis auf eine QUEMO-VHD gefunden. 1und1 scheint also quemu zum Testen der Systemabbilder ihrer rootserver zu verwenden?! Warum nicht, nur hätte man den sinnfreien resume-eintrag aus der GRUB-Konfiguration entfernen sollen.

kernel /boot/vmlinuz-2.6.34.7-0.7-default root=/dev/md1 resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00002-part1

Naja, immerhin besser als Virtual PC ;)

Wenn der Provider macht was er will ….

… bist du scheinbar bei All-inkl.com. Hier kann es tatsächlich passieren, dass ihr Account ohne Vorwarnung auf einen anderen Server verschoben wird. Nach dieser Änderung sind dann, je nach TTL im DNS, sämtliche Webseiten und EMail-Adressen nicht mehr erreichbar. Doch es kommt noch schlimmer, anstelle einer temporären SMTP (mailserver) Fehlermeldung wirft der Mailserver nach dem Umzug alle Mails mit “550 – not permitted” einfach weg. Der Absender bekommt eine Meldung als würde die Mailbox nicht existieren.

Sollte man dann auch noch wie ich das DNS bei einem anderem Anbieter hosten, bekommt man an der Hotline nicht mal die aktuelle IP des Webservers um seine Zonefiles anzupassen. Und nochwas, die physischen Server sind leider extrem unterdimensioniert und der Apache so konfiguriert, dass er sogar noch Verbindungen annimmt wenn absolut keine Systemressourcen mehr zur Verfügung stehen. Kurz, die MPM-Konfiguration passt nicht zur Leistung der Hardware.

Unterm Strich, für das Geld bekommt zwar ordentlich webspace und einige Features die es bei größeren providern nicht gibt, die Stabilität und die Wartungpraktiken machen das Angebot für Leistunghungrige Webseiten oder Seiten mit hohen Besucherzahlen uninteressant. Da hilft auch der SSL-Proxy nichts mehr.

Gigabyte GA-D525TUD – DualCore Atom Mini-ITX Mainboard

Seit einiger Zeit suche ich nach einem möglichst günstigem, stromsparendem, Linux-tauglichen und mit 4 SATA-Ports ausgestatteten Mainboard für meinen Heimserver. Nach einigem hin und her habe ich mich für das Gigabyte GA-D525TUD entschieden.

Zur Ausstattung:

Die ersten beiden SATA-II Anschlüsse werden über den Standard 82801GR/GH (ICH7 Family) SATA AHCI Controller bereitgestellt.  Der onboard “Realtek RTL8111/8168B” Gigabit Ethernet Chip ist intern genau wie der von Gigabyte “Gigabyte SATA-II Controller” getaufte “JMicron 20360/20363 Serial ATA Controller” über PCI Express angebungen. Leider wird der am 82801G (ICH7 Family) High Definition Audio Controller angebundene Realtek ALC887 noch nicht von ALSA unterstützt. Alsactl meldet “Unknown hardware: “HDA-Intel” “Realtek ALC887″ “HDA:10ec0887,1458a002,00100302″ “0×1458″ “0xa002″. Anwender, die dieses Board als Multimedia-System einsetzten wollen, sollten dies beachten. Leider kann im BIOS nicht sehr viel Speicher für den “Intel Pineview” Grafikchip” zugewiesen werden, was wieder gegen Multimedia-Einsatz spricht. Für Erweiterungskarten steht ein normaler PCI-Slot zur Verfügung.

Hardware-Monitoring

Das Board verfügt noch über einen it8720-isa-0290 Hardware-Monitoring Chip und den üblichen coretemp-Sensor bei Intel-Prozessoren. Beide werden vom LM-Sensors-Projekt unterstützt und auch richtig erkannt. Es können die üblichen Spannungen, Coretemp und Lüfterdrehzahl problemlos abgefragt und überwacht werden.

Leistung

Die beiden Kerne und die HT Unterstützung machen sich unter Linux bemerkbar. Im Vergleich zu meinem EPIA C7 1Ghz System ist der Atom um das 5-10 Fache schneller. Leider fehlt ihm eine Hardware-AES Engine zur Festplattenverschlüsselung, was den kleinen Prozessor beim Verschlüsseln von Software-Raids an seine Grenzen bringt. In den beiden DDR3 Speicherbänken können maximal 4GB PC3-800 Speicher installiert werden. Für einen Heimserver mehr als ausreichend.

Fazit

Das Mainboard ist in Preis/Leistung fast nicht mehr zu überbieten. Das fast perfekte Mainboard für einen Heimserver. In Verbindung mit einem IDE-Flash Modul für das Betriebssystem stehen 4 SATA-Ports zur Verfügung. Zusammen mit dem Chenbro ES34069 ergibt das einen sehr stromsparenden Heimserver.

Weitere Informationen zum Mainboard bei Gigabyte

Mit PHP im IIS unter Windows Server via sicheres LDAP auf ActiveDirectory zugreifen

Wer sollte nicht schon immer mal aus PHP auf ActiveDirectory zugreifen. Und das ganze am besten noch SSL-Geschützt über LDAPS (Port 636). Und das gnaze auch noch auf einem Windows Server 2003 mit IIS … wuah … aber in bestimmten Situationen geht es nicht anders.

Wie man PHP im IIS einbindet werde ich hier nicht beschreiben. Allerdings sollte man das LDAP-Modul auch laden. Dazu entfernt man einfach den Kommentar in der Zeile “;extension=php_ldap.dll”. Aber noch nicht genug. In der Standardeinstellung versucht das LDAP-Modul bei einer Verbindung über SSL das Zertifikat zu prüfen. Dies scheitert meistens und man erhält die Fehlermeldung ” ldap_bind(): Unable to bind to server: Can’t contact LDAP server”. Unschön. Um die Zertifikatsprüfung abzuschalten, erstellt man auf Laufwerk C: des Servers den Ordner  “C:\openldap\sysconf” und legt dort eine Datei namens “ldap.conf” ab. Hier können nun Einstellungen für das OpenLDAP-Modul gesetzt werden. Um die Zertifikatsprüfung abzuschalten, reicht es hier die Zeile “TLS_REQCERT never” einzutragen. Anschließend sollte man den IIS “WWW-Publishingdienst” neustarten.

Eine Verbindung zum LDAP-Server stellt man nun mit PHP wie folgt her:


$ldap->user="user@ad.firma.de"; // Benutzername in form LOGON@DOMÄNE
$ldap->password="12345"; // Passwort des Benutzers
$ldap->server="ad.firma.de"; // LDAP-Server, bei AD-Domänen kann einfach der Domänenname angegeben werden
/* Verbindung mit dem LDAP-Server herstellen */
$ldap->conn=ldap_connect("ldaps://".$ldap->server, 636); // Verbinde mit Server über LDAPS auf Port 636
ldap_set_option($ldap->conn, LDAP_OPT_PROTOCOL_VERSION, 3); // Verwende LDAP Protokoll version 3
ldap_set_option($ldap->conn, LDAP_OPT_REFERRALS, 0); // Referenzen nicht folgen
/* Nun melden wir uns am LDAP-Server an (LDAP-BIND)*/
$ldap->bind=ldap_bind($ldap->conn,$ldap->user,$ldap->password); // Verbindung herstellen

Nun könnte man im LDAP Suchanfragen oder andere Dinge unter den Rechten des Bind-Benutzers starten. Viel Spaß.

Einsatz eines IMAP-Proxys zur Beschleunigung und entlastung des IMAP Servers bei Webmail

Gerade neuere PHP basierende (IMAP) Webmailer haben das Problem, das jede Aktion in der Oberfläche einen erneuten Login am verursacht. Um dies zu verhindern, kann ein Cache auf dem Webserver eingerichtet werden. Dieser verbindet den jeweiligen Benutzer dem Server und hält die Verbindung noch einige Zeit offen. Löst der Benutzer anschließend im Webmailer eine erneute Verbindung aus, wird diese vom Cache abgefangen und die bereits offene zwischengespeicherte Verbindung weiterhin genutzt. Der IMAP-Server  muss so nicht bei jeder Aktion im Webmailer erneut die Zugangsdaten des Benutzers prüfen, was bei einem komplexeren Anmelde Backend zu einer massiven Leistungssteigerung führt.  Nach einigen Tests habe ich mich für http://www.imapproxy.org entschieden. Dieser überzeugt durch einfache Konfiguration und hohe Leistung. Leider fehlt ein passendes init-script für Gentoo-Linux. Dies lässt sich aber problemlos nachholen.

Installation unter Gentoo

Kopieren des Download-Links von http://www.imapproxy.org/download.html in die Zwischenablage

cd /usr/src
wget http://www.imapproxy.org/downloads/up-imapproxy-VERSION.tar.gz (vorher kopiert :- )
tar xfz up-imapproxy-1.2.6.tar.gz

Gentoo sollte als Meta-Distribution alle Abhängigkeiten zum Kompilieren erfüllen. Für andere Distributionen sollten die entsprechenden Pakete (GCC, MAKE, usw.) installiert werden.

Konfigurieren und Kompilieren:

./configure --prefix=/usr --sysconfdir=/etc/imapproxy  --localstatedir=/var
make

Installieren:
Ein Blick ins Makefile verrät das von „make install“ nur 2 Dateien nach /usr/sbin kopiert werden.  „make install-init“ sollte man unter Gentoo nicht ausführen, da die scripte unter /etc/init.d abgelegt werden.  Die Konfiguration kann auch per Hand kopiert werden.

make install
mkdir /etc/imapproxy
cp scripts/imapproxy.conf /etc/imapproxy

Nun schnell noch ein für gentoo passendes init-script schreiben und unter /etc/init.d ablegen …

#!/sbin/runscript
#Runscript for imap-proxy under Gentoo Linux
#
opts="checkconfig reload"
depend() {
need net hostname localmount
}
checkconfig() {
if [ ! -e /etc/imapproxy/imapproxy.conf ]; then
eerror "Please create /etc/imapproxy/imapproxy.conf first!"
return 1
fi
}
start() {
checkconfig || return 1
ebegin "Starting imap proxy"
start-stop-daemon --start --quiet --exec /usr/sbin/in.imapproxyd -- -p /var/run/imapproxy.pid -f /etc/imapproxy/imapproxy.conf
eend $? "Failed to start imap proxy"
}
stop() {
ebegin "Stopping imap proxy"
start-stop-daemon --stop --quiet --pidfile /var/run/imapproxy.pid
}
Die Konfiguration erfolgt in der Datei /etc/imapproxy/imapproxy.conf. Die Kommentare sind mehr als ausreichend. Ich empfehle aus sicherheitsgründen den Proxy ausschließlich an das  loopback Interface (127.0.0.1)  zu binden. Sollte sich der IMAP-Server im gleichem Netz (z.B. DMZ) oder gar auf dem gleichem Host befinden, kann auf SSL verzichtet werden.

Nun kann der Proxy gestartet werden.

/etc/init.d/imapproxy start

“tail /var/log/messages /var/log/mail.log” sollten nun folgende Zeilen zeigen:

in.imapproxyd: main(): Using pidfile '/var/run/imapproxy.pid'
in.imapproxyd: main(): Using configuration file '/etc/imapproxy/imapproxy.conf'
in.imapproxyd: Using syslog facility 'LOG_MAIL' for logging.
in.imapproxyd[1957]: Masking syslog priority up to LOG_INFO.
in.imapproxyd[1957]: main(): SELECT caching is disabled
in.imapproxyd[1957]: main(): Internal admin commands are disabled
in.imapproxyd[1957]: main(): Allocating 3072 IMAP connection structures.
in.imapproxyd[1957]: ServerInit(): Using '/var/log/imapproxy_protocol.log' for global protocol logging file.
in.imapproxyd[1957]: ServerInit(): proxying to IMAP server '**********'.
in.imapproxyd[1957]: ServerInit(): Proxying to IMAP port 143
in.imapproxyd[1957]: main(): Binding to tcp 127.0.0.1:1430
in.imapproxyd[1957]: main(): Using global statistics file '/var/run/pimpstats'
in.imapproxyd[1957]: Daemonize(): Configured to run in background mode.
in.imapproxyd[1959]: BecomeNonRoot(): Process will run as uid 65534 (nobody) and gid 65534 (nobody).
in.imapproxyd[1959]: main(): Launched ICC recycle thread with id -1381332080
in.imapproxyd[1959]: main(): imapproxy version 1.2.6 normal server startup.

INIT, “netstat -nlp” und “ps -Al” sollten bestätigen das der Proxy läuft.

netstat -nlp | grep -i imapproxy
tcp        0      0 127.0.0.1:1430           0.0.0.0:*               LISTEN     1959/in.imapproxyd
ps -AlF
5 S nobody 1959 1 0 78 0 - 5067 415801 1176 0 16:37 ? 00:00:00 /usr/sbin/in.imapproxyd -p /var/run/imapproxy.pid -f /etc/imapproxy/imapproxy.conf
/etc/init.d/imapproxy status
* status: started

Abschließend wird der Webmailer zur Verwendung des IMAP-Proxys konfiguriert und fertig.
z.B. Roundcube:

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['default_port'] = 1430;

Anfangs sollte man die “syslog_facility” mindestens auf “LOG_INFO”. Dies hilft bei der Fehlersuche.