Exchange ActiveSync durch OpenBSD Proxy

Kein Problem, wenn man sein MobilePhone mit einem Exchange-Server synchronisieren und MS nicht direkt mit dem Internet verbinden will:

# cd /var/www
# mkdir etc cert
# cd cert
# openssl req -new > cert.csr
# openssl rsa -in privkey.pem -out cert.key
# openssl x509 -in cert.csr -out cert.cert -req -signkey cert.key -days 1095
# cd ..
# vi conf/httpd.conf

LoadModule proxy_module /usr/lib/apache/modules/libproxy.so

VirtualHost *:443
ServerName host.extern.dom
SSLEngine on
SSLCertificateFile /var/www/cert/cert.cert
SSLCertificateKeyFile /var/www/cert/cert.key
ProxyRequests Off
ProxyPass /Microsoft-Server-ActiveSync https://host.extern.dom/Microsoft-Server-ActiveSync
ProxyPassReverse /Microsoft-Server-ActiveSync https://host.extern.dom/Microsoft-Server-ActiveSync
NoCache *
/virtualhost

Listen 443
Listen 80

# vi etc/hosts

InterneIpExchangeServer host.extern.dom

# mkdir -p usr/lib/apache/modules/
# cp /usr/lib/apache/modules/libproxy.so usr/lib/apache/modules/
# vi /etc/pf.conf

pass in on $ext_if proto tcp to ($ext_if) port https keep state

# pfctl -f /etc/pf.conf

Nun das Zertifikat via IE in eine x.509 codierte Datei speichern, auf das MobilePhone kopieren und dort durch Ausführen in den lokalen Zertifikatspeicher importieren. Jetzt kann das Teil sich mit dem Exchange Server durch das öffentliche Netz synchen.

Apache als Reverse Proxy für Exchange 6.5

Soll das Webinterface des Exchange Servers auch aus dem Internet verfügbar sein ist es möglicherweise keine so gute Idee das direkt erreichbar zu machen sondern eher den Indianer mit einer weiteren Authentifizierung vorzuschalten.Und das geht unter OpenBSD 3.8 mit dem chrooted Apache so:
Die Konfiguration für den virtuellen Host schaut so aus:

VirtualHost *:443
ServerName host.extern.dom
DocumentRoot “/var/www/htdocs”
SSLEngine on
SSLCertificateFile /var/www/certs/cert.cert
SSLCertificateKeyFile /var/www/certs/cert.key
ProxyRequests Off
Directory proxy:*
Order deny,allow
Deny from all
AuthName “WebMail”
AuthType Basic
AuthUserFile /var/www/etc/user
require valid-user
Satisfy any
/Directory
ProxyPass /exchange https://host.extern.dom/exchange/
ProxyPassReverse /exchange https://host.extern.dom/exchange/
ProxyPass /exchweb/ https://host.extern.dom/exchweb/
ProxyPassReverse /exchweb/ https://host.extern.dom/exchweb/
ProxyPass /public https://host.extern.dom/public/
ProxyPassReverse /public https://host.extern.dom/public/
ProxyPass /iisadmpwd https://host.extern.dom/iisadmpwd/
ProxyPassReverse /iisadmpwd https://host.extern.dom/iisadmpwd/
NoCache *
/VirtualHost
Zu beachten sind jedoch folgende Punkte:

– es muss im www-root/etc eine hosts Datei existieren, welche die interne ip auf den externen Namen auflöst:

xxx.xxx.xxx.xxx host.extern.dom

– in der Apacheconfig muss das modul libproxy.so aktiviert sein und dieses ist nach /var/www/usr/lib/apache/modules/libproxy.so kopiert werden.

Der Indianer muss wissen, dass er auch auf den https port lauscht, am Ende der Config einfach folgendes einfügen:

Listen 443
Listen 80

und der Parameter für KeepAlive sollte auf Off stehen.

TFTP-Server

Benötigt man unter OpenBSD einen TFTP-Server entferne man aus der /etc/inetd.conf das # vor

tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot

ein beherztes

kill -HUP `cat /var/run/inetd.pid `

startet diesen dann. Die Files gehören in /tftpboot.

Pakete mit Hilfe des pkg_add updaten

Sollte es nötig sein, installierte Pakete auf einen neuen Stand zu bringen, geht das fast automatisiert so:

# export PKG_PATH=ftp://ftp.de.openbsd.org/3.9/packages/i386
# pkg_add -iu

Installation von xbase

Benötigt man Pakete aus den Ports, welche ein installiertes xbase voraussetzen kann man das so nachinstallieren:

# wget /Pfad/zum/xbase39.tgz
# cd /
# tar -xvpzf /Pfad/zum/xbase39.tgz

Nun muss man dem System noch die Bibliotheken bekannt geben:

# ldconfig -m /usr/X11R6/lib

udma modi im openbsd kernel einstellen

Moderne ATA Festplatten können mittlerweile bis UDMA7 betrieben werden, aber nur wenn auch ein 80 Adriges IDE Kabel angeschlossen ist.
Wird aber nur ein 40 adriges Kabel verwendet, so liest der OpenBSD Kernel die SMART Tabelle der hdd aus und nimmt die Geschwindigkeit welche die Tabelle angibt und PENG -> mit 40 Adern geht es nun mal nicht schneller als UDMA2.

Lösung:
den Kernel ohne neukompilieren anpassen.
Man gebe bei laufendem System folgenden Befehl an:
config -e -o bsd.new /bsd
und landet auf dem
ukc> prompt
Hier nun ein
ukc> change wd

und es wird gefragt,
36 wd* at wdc0|wdc1|wdc*|wdc*|pciide* channel -1 flags 0×0
change [n]
wir geben y ein,
es erscheint,
channel [-1] ?
mit enter bestätigen,
es erscheint,
flags [0] ?
hier geben wir nun 0×0a00 ein, was UDMA2 ergibt. Mit enter bestätigen und danach quit eingeben und das ganze wird in das vorhin angegebene bsd.new file geschrieben. Dieses file noch schnell nach / kopiert und beim booten ein:
boot bsd.new
abgeschickt und schon kann der Kernel nur noch UDMA2