Homeautomation mit der Fritz!Box

Die Idee dazu gibt’s bei mir schon länger. Bereits Anfang 2015 gab es die Überlegung DECT Heizkörperventile für Bieberehren zu beschaffen. Für das Haus wäre aber gleich das volle Dutzend nötig geworden. Bei einem Stückpreis von seinerzeit noch rund 60 € durchaus ein kräftiges Investment. Die seinerzeit eingesetzte FritzBox 7490 hätte die 12 Ventile aber in der Tat unterstützt.

Stand Januar 2018 sind die Preise bei deutlich unter 40 €/Stück angekommen und für meine kleine Bude standen lediglich 5 der EUROtronic Comet DECT Thermostatventile auf dem Bestellzettel. Die nahezu baugleichen Fritz!DECT 301 liegen immer noch bei etwas mehr als 50 €/Stk.

Warum Homeautomation?

Zur Motivation der Beschaffung in meinem Fall: Zum einen liegt meine Wohnung im Souterrain und ist damit durchaus etwas anfällig für Feuchtigkeit. Bewusstes Heizen und regelmässiges Stoßlüften hält das Risiko allerdings im Zaum. Stoßlüften heisst natürlich auch: zu dem Zeitpunkt sollte die Heizung runtergeregelt werden, um nicht die Wärme zum Fenster raus zu blasen. Zum zweiten bin ich oft genug unter der Woche bei Kunden unterwegs und fast regelmässig auch an den Wochenenden außer Haus. Da braucht es nicht die volle Heizleistung. Beide Szenarien lassen sich mit genügender Disziplin auch manuell durchführen, aber einfacher ist die Automation. Andererseits ist es natürlich auch sehr schön in eine gemütlich warme Wohnung heimzukehren. Hier kann nur die Automation helfen. Als Nebeneffekt nehme ich eine Einsparung an Energiekosten oder auch die Zeitersparnis für die Beseitigung von Schimmel – s.o. unter Feuchtigkeit – gerne mit.

Installation

Die Thermostatventile selbst sind relativ schnell eingebunden. Der erste Schritt kann komplett am Schreibtisch erfolgen: DECT-Ventil aus der Verpackung nehmen, die mitgelieferten Batterien griffbereit daneben legen, FritzBox Weboberfläche aufrufen, Abteilung Heimnetz/SmartHome aufrufen und die Kopplung eines neuen Geräts starten. Als nächstes die Batterien einlegen. Im Display des Thermostatventils erscheint erst PREP dann INST und nach ein bisschen blinkern der DECT Anzeige kam bei mir auf allen fünfen sofort eine Verbindung zustande. In der Weboberfläche wird das Gerät dann noch passend benannt und der erste Schritt ist abgeschlossen.

Die physische Inbetriebnahme war in meinem Fall ebenso einfach: einmal die vorhandenen „statischen“ Thermostatventile einmal mit der Wasserpumpenzange links gedreht, die neuen draufmontiert und die Adaption kann losgehen. Für den Fall, dass ein anderes Gewinde vorliegt, sind Adapterringe mitgeliefert. Auch wenn ich durch den Sanitär- und Heizungsbaubetrieb meines Vaters, in dem ich als Jugendlicher mithelfen durfe, etwas erblich vorbelastet bin: das ist keine Raketenwissenschaft und mit durchschnittlichem handwerklichem Geschick zu leisten. Die Anzeige liefert bei der Montage INST, 3 Sekunden auf OK und schon beginnt eine kurze Anlernphase in der einmal der komplette Ventilweg durchgesteuert wird.

Konfiguration

Auch wenn manuelle Stellmöglichkeiten am Ventil selbst nach wie vor vorhanden sind – ab jetzt passiert erstmal alles in der Weboberfläche der FritzBox. Erster Schritt: die Definition von Komfort- und SparTemperatur. Nur was ist komfortabel in Grad Celsius? Unsere üblichen Heizkörperventile kennen Striche von 0 bis 5, aber keine Gradangaben. Auch hier half mir die Quasi-Ausbildung durch meinen Vater. Als gängige Faustregeln für die RaumTemperaturen gelten:

  • Wohnräume und Büro: 21 °C – je nach Empfinden auch gerne ein Grad mehr oder weniger. Gerade im Büro bei sitzender Tätigkeit – also wenn unsere Muskeln kaum bewegt werden und damit keine körpereigene Wärme produzieren, kann ein Grad mehr den Unterschied machen.
  • Kinderzimmer: 23 °C – insbesondere bei kleineren Kindern, je älter die Kinder werden, desto näher kann die Temperatur an die Wohnräume angepasst werden.
  • Schlafzimmer: 18 °C – mehr braucht es zum Schlafen tatsächlich nicht, je nach Empfinden sogar noch bis zu drei Grad weniger.
  • Bad: 23 °C – hier darf’s etwas behaglicher sein, insbesondere nach dem Baden oder Duschen.
  • Küche: 19°C – schon alleine weil dort Herd und Backofen zur rechten Zeit zuheizen.

Wie gesagt: alles erstmal nur Faustregeln, die man auf das persönliche Wohlbefinden anpassen muss. Aber als Ausgangsdaten für unsere Grundsteuerung taugen sie schon mal. Die Werkseinstellung mit 21 °C Komfort- und 16 °C Spartemperatur lassen sich so schon mal je Raum anpassen.

Als nächstes kommen wir zum Zeitplan, nach dem zwischen Komfort und Sparmodus umgeschaltet wird. Hier sind die persönlichen Lebensumstände natürlich maßgebend. Wer – wie ich – alleine lebt, hat’s einfach, ansonsten ist hier der Familienrat gefragt. Wann sind Aufsteh- und Zubettgeh-Zeiten? Wer hält sich wann in welchem Raum auf und braucht dann die Komforteinstellung, bzw. umgekehrt: wann kann ein Raum auf Sparflamme gesetzt werden? Wie verhält sich das an normalen Wochentagen und wie am Wochenende? Dazu sollte eingerechnet werden, dass es auch noch eine gewisse Vorlaufzeit braucht, bis ein Raum von kühl auf komfortabel eingeheizt ist – also auch die Raumgröße beachten! Wie weit will ich tatsächlich runterregeln, um einen guten Kompromiss zwischen Energieeinsparung und Eiskeller zu finden?

Hier greift eine weitere Faustregel: Maximal sollte die Temperaturdifferenz zwischen Komfort und Spareinstellung 4 bis 5 °C betragen. Zu starke Differenzen in Spar- und Komforttemperatur schaffen keinen Energieeinspareffekt mehr. Es ist weniger Energieaufwand geringe Differenzen wieder auszugleichen, als einen bereits ausgekühlten Raum wieder auf Komforttemperatur zu bringen! Aus das hatte ich rudimentär schon bei meinem Vater gehört, war aber dankbar das von meinem Bürokollegen Architekt nochmal en detail erläutert zu bekommen.

Am Ende hilft nur etwas experimentieren und die Aufzeichnungen der Temperaturen, die die Ventile an die FritzBox senden, auszuwerten. Zusammen mit den Einstellungen für die Heizperiode als Ganzes (Abschaltung der Heizkörper in einem vorgegebenen Zeitraum) sowie der Möglichkeit Urlaubszeiten einzutragen in denen nur eine Grundtemperatur gehalten und der Zeitplan ignoriert wird ist ein Großteil der Anforderungen bezüglich volle Pulle vs. Sparflamme aufgrund von An- und Abwesenheiten damit schon weitestgehend erledigt.

Ebenfalls sehr hilfreich ist ein externes Raumthermometer um die tatsächliche Temperatur im Raum mit der vom Ventil gemessenen abzugleichen. Konkret: wie ist die Temperatur an Stellen im Raum an denen ich mich regelmässig aufhalte: über Tag am Schreibtisch, abends auf der Couch, nachts im Bett, zum Essen am Küchentisch, …?

Hierfür gibt es einen sog. Offset in den Einstellungen mit der Differenzen in der Messung im Raum vs. der Temperatur am Ventil ausgeglichen werden können. Es ist durchaus sinnvoll jeden Raum mal über ein, zwei Tage daraufhin zu überwachen und nachzujustieren.

Das Anwendungsszenario Stoßlüften ist sozusagen ab Werk schon gelöst. Wird ein Fenster geöffnet – sprich: fällt die Temperatur im Raum schlagartig ab – regelt das Thermostatventil sofort komplett ab. Die Erkennung dafür und die Zeit der Abschaltung lassen sich einstellen, scheinen mir auf den ersten Blick aber ab Werk gut gewählt. Aber auch da habe ich im Laufe der Zeit etwas nachkorrigiert. So habe ich es mir zur Angewohnheit gemacht während des morgendlichen Badaufenthalts das Schlafzimmer durchzulüfen. Die dafür voreingestellten 10 Minuten waren etwas zu knapp bemessen, so dass ich den Wert auf 15 Minuten angehoben habe um ganz in Ruhe mich Duschen zu können, ohne das im Schlafzimmer schon wieder die Heizung anläuft und zum Fenster rausbläst.

Zugriff von Außen

Ein weiteres Komfortmerkmal ergibt sich aus der Zugänglichkeit der FritzBox aus dem Internet. Sofern man das will und sofern man die notwendigen Sicherheitsvorkehrungen dafür treffen kann und getroffen hat! Erlaubt man den Zugriff von außen – wahlweise direkt auf das Webinterface der FritzBox via https oder per VPN und dann über die interne IP auf die FritzBox können die Einstellungen für die SmartHome Geräte auch von unterwegs getroffen werden. Wie gesagt: hier wäre es mehr als wünschenswert, alles dafür zu tun, dass nur berechtigte Personen solche Einstellungen vornehmen können.

Nicht nur die Weboberfläche selbst wird so erreichbar auch verschiedene Drittanbieter Tools können über diesen Zugang angebunden werden. Im iOS AppStore finden sich gleich mehrere Anwendungen dafür:

  • MyFritz!App – die von FritzBox Hersteller AVM selbst entwickelte App, die unter anderem auch den Zugriff auf die Homeautomation ermöglicht (aber eben auch noch auf NAS Inhalte, Einstellungen, Anruflisten und Nachrichten auf dem Anrufbeantworter). Anders als der Name vermuten lässt bedarf es nicht zwingend eines MyFritz Kontos. Auch über eine fixe IP, einen DynDNS Eintrag und einfachen Benutzer-Credentials lässt sich die App mit der FritzBox verbinden. Die Einstellmöglichkeiten sind rudimentär: WunschTemperatur hoch oder runter. Die aktuell gemessene RaumTemperatur wird erst angezeigt, wenn man sich die Details des jeweiligen Geräts aufruft. Dafür ist die App kostenlos.
  • smart!DECT – für das Schalten von (AVM) Steckdosen prima geeignet. Beim Abfragen der Thermostatventile fing die Anzeige aber regelmässig das Flackern an. Dafür ist (mir) kostenlos noch zu teuer.
  • Smart!Home – von HOsy. Eigentlich eine gute Adresse, wenn es um Anbindungen von macOS oder iOS an die FritzBox geht. In dem Fall aber leider ungeeignet, weil nur auf schaltbare Steckdosen fokussiert. Vielleicht liefert ein kommendes Update ja noch die Steuerung für die Thermostatventile. Dann wären 2,29 € sicher nicht zu viel Geld dafür. So erstmal keine Kaufempfehlung.
  • fritch – kostet ebenfalls 2,29 €. Allerdings finde ich schon das Interface nicht sonderlich attraktiv. Zumal sich mit den gewählten Farben Festlegungen von Temperaturbereichen verbinden, die nichts mit meinen Einstellungen in der FritzBox zu tun haben, sondern in der App willkürlich festgelegt sind. Ungetestet.
  • smartFranz – Kann erstmal kostenlos getestet werden und dann über einen In-App Kauf zu 9,99 € komplett freigeschaltet werden. Absolute Killerfeatures: die Verkettung von mehreren Geräten für eine Aktion sowie die Geo-Fence Funktion. Verlasse ich das Haus in einem bestimmten (einstellbaren) Umkreis, werden festgelegte Aktionen ausgeführt. In meinem Fall eben die Temperatur runtergedreht oder auch bestimmte schaltbare Steckdosen ein- oder ausgeschaltet.

Wichtig hierbei: nicht zu enge Radien wählen, weil ansonsten schon beim Gang zum Briefkasten oder beim Einkauf um die Ecke die Heizung runtergefahren wird. Bei mir haben sich 2 km als guter Wert erwiesen. Wichtig auch: exakte Adresse eingeben. Wenn man ansonsten später von außerhalb mal die Einstellungen nachjustiert, kann die Geo-Fence Funktion „2 km von aktuellem Standort“ anders als gewollt interpretieren.

Umgekehrt natürlich genauso: nähere ich mich meinem Zuhause wieder an, dreht die Heizung auf. Letzteres nutze ich zwischenzeitlich schon nicht mehr. Die 2 km für’s Abschalten reichen umgekehrt bei der Annäherung nicht aus, um die Räume wieder auf angenehme Temperatur zu bringen. Und ein zweiter Schaltpunkt – sagen wir bei Annäherung auf 10 km – würde zu einer Fehlinterpretation nach dem Abschalten führen, da 2 km auch näher als 10 km sind und damit unmittelbar nach dem Abschalten sofort wieder ein Einschaltbefehl gesendet würde. Stattdessen nutze ich für die Annäherung einfach die Verkettung: Abhängig von der Tageszeit habe ich zwei verschiedene Temperaturszenarien hinterlegt, die ich wahlweise bei Heimkehr unter Tags oder in den Abendstunden ca. 30 – 45 Minuten vor geplanter Ankunft unterwegs abrufe.

Priorisierung

Sehr wesentlich zu wissen: was passiert wann, wenn von unterschiedlichen Stellen auf die Einstellungen der Thermostatventile zu gegriffen wird. Welche Einstellung überfährt welche?

  • Das erste Setting erfolgt durch die Angabe der (Nicht-)Heizperiode. Innerhalb des eingestellten Zeitraums werden keinerlei andere Regelungen – egal ob Zeitplan, App, manuell, … – zugelassen
  • Die zweite Priorität liegt im Urlaubsplan. Auch während dort hinterlegten Zeiträume werden keine Zeitpläne ausgeführt, bzw. der Zugriff via App und am Ventil selbst deaktiviert.
  • Als drittes greifen die Zeitpläne. Manuelle Eingriffe am Ventil oder via App werden von den Zeitplänen überfahren. Sprich: ändere ich unterwegs die Temperatur, wird beim nächsten Schaltvorgang im Zeitplan die dort hinterlegte Einstellung gezogen. Ebenso, wenn manuell am Thermostat selbst eine Temperatur eingestellt wird.
  • Alle manuellen Eingriffe – gleich ob über die Weboberfläche, verbundene Apps oder manuell am Thermostatventil selbst haben die niedrigste Priorität und werden von allen vorgenannten Stellmöglichkeiten wieder überfahren. Hier gilt einfach nur: wer zuletzt lacht, lacht am besten. Temperatur in der App runtergedreht und anschliessend am Ventil wieder nach oben, behält die letzte Einstellung, also in dem Fall die manuelle Veränderung.

Wünsche an AVM

Gerade was die Eintragung von Urlaubszeiten und Heizperiode angeht, darf der Komfort gerne noch etwas größer werden. Zwar ist es Möglich mehrere Ventile zu einer Gruppe zusammen zu fassen und gemeinsam zu konfigurieren. Aber bei der Gruppenkonfiguration gilt: alles oder nichts. So werden nicht nur die Urlaubszeiten an alle Ventile einheitlich übertragen, sondern auch die Zeitpläne werden komplett angeglichen. Just da will ich aber soviel individuelle Einstellung wie möglich haben. Nur weil ich den ganzen Tag im Büro bin und die Komforttemperatur von 22 °C haben möchte, müssen andere Räume wie das Schlafzimmer nicht ebenfalls auf dem (dort eh viel zu hohen) Niveau gehalten werden. Umgekehrt: in dem Moment wo ich die Ventile einzeln anspreche, muss ich einen Urlaubstermin auch jeweils einzeln pro Ventil hinterlegen. Da wäre eine Vorauswahl was global und was individuell eingestellt werden soll sehr hilfreich.

Sicherheit

Ein bisschen was dazu klang ja bereits weiter oben an: Der Zugriff von außen sollte natürlich so restriktiv wie möglich gehandhabt werden. Starke Kennwörter, Verschlüsselung der Verbindung sind das absolute Minimum. Und auch die Verwendung des MyFritz Zugangs ist trotz der der Einbindung eines Let’s-Encrypt Zertifikats nicht ganz problemlos.

Aber auch ohne die FritzBox ins Internet zu exponieren ergibt sich in der Kommunikation zwischen Ventil und FritzBox durch die Verwendung von DECT ein potentieller Angriffsvektor. Unklar ist ob die DECT Ventile bei der Kommunikation mit der FritzBox sich einer Verschlüsselung bedienen und ob diese auch Reverse Engineering Angriffen standhält. Aber zumindest sollte man das Szenario nicht aus den Augen verlieren!

[Update] Heiter bis wolkig

Nein, es geht nicht um’s Wetter, sondern um den allgegenwärtigen Hype »Clouds«. I.d.R. sprechen wir dabei über mehr oder minder Speicherplatz auf irgendwelchen Servern (die zumeist in Amerika stehen und deren Sicherheit und Privatheit man nun glauben kann oder nicht).

Egal wie: allen gemeinsam ist, das sie ein einfaches und bequemes Mittel darstellen um Daten immer und überall griffbereit auf allen Devices zu haben. Neben dem »Altvater« DropBox für den es ab Werk 2 GB Speicherplatz kostenlos gibt plus weiteres für neugewonnene Mitglieder (ACHTUNG: Aktion bis 31.10.2011: 2 x 50 GB extra zu gewinnen !) kommt nun Apple mit iCloud daher. Zunächst einmal ist sehr erfreulich, dass nach dem nicht immer runden und recht teuren MobileMe nun eine kostenlose Alternative bereitsteht, die immerhin 5 GB mitbringt. Richtig nett wird iCloud bei uns aber wohl erst werden, wenn iTunes dort verfügbar wird. Das Angebot ist derzeit nur in den USA verfügbar – dort kann man offenbar mit Musiklabels zu vernünftigen Einigungen kommen :-/. Auch wenn iTunes in der Cloud ein kostenpflichtiges Extra wird – für 25 $ (€?) pro Jahr die komplette Library (die bei mir rund 22.000 Titel umfasst) von Apple tip-top aufbereitet zu bekommen, ohne eine Nachfrage ob die MP3-Dateien selbst gerippt wurden oder als (erlaubte!) Privatkopie den Weg auf den Rechner fanden, finde ich sehr attraktiv.

5 GB sind nicht die Welt und so kommt aktuell box.net mit einem Top-Angebot daher: 50 GB Speicherplatz, wenn die Cloud über iPhone oder iPad eingerichtet wird. Die Aktion läuft bis zum 30.11.2011 (50 Tage). box.net-App downloaden, anmelden und (fast) fröhlich sein. Wieso fast? Weil iPhone und iPad unterstützt sind, eine Mac und Win-Applikation ähnlich wie Dropbox sie bietet aber noch in der Pipeline stecken. Schlimm? Nein!

Zum ersten ist die Weboberfläche nicht die allerschlechteste – inklusive Drag’n Drop Upload per Browserfenster. Zum zweiten gibt es schon eine kleine Mac-App namens Box Simple Share die zumindest ein paar rudimentäre Funktionen wie einen Upload, insbesondere von Screenshots auf der Pfanne hat. Und zum dritten – und besten – kann man box.net auch per WebDAV direkt aus dem Finder heraus ansprechen. Michael Preidel beschreibts auf seiner Page:

Interessant dabei ist, dass sich der Speicherplatz bequem über WebDAV ins Filesystem einbinden lässt: Unter Mac OS X im Finder Befehl-K drücken (oder im Menü Gehe zu > Mit Server verbinden … auswählen), bei Serveradresse „http://box.net/dav“ eintragen und anschließend Benutzer und Kennwort des Box.net-Accounts eintragen.

[Update 07.02.2012]Schade: box.net hat mir nichts dir nichts die (bis dahin inoffizielle) WebDAV-Unterstützung komplett rausgenommen. Damit ist box.net auf dem Mac komplett unbrauchbar geworden :-/

owncloud-square-logo-150x150Aktuell bin ich dabei owncloud.org zu testen. Schaut auf den ersten Blick auf jeden Fall um Welten besser aus, als das, was man gemeinhin aus der Linux/Opensource-Ecke gewöhnt ist und soll auch CalDAV und CardDAV unterstützen, was u.U. sowohl iCloud, wie auch einen OS X Server für den Hausgebrauch obsolet machen könnte!

 

Kann ich SL schon einsetzen?

Eine Frage, die mir häufiger von meinen Kunden gestellt wird. Neben der Lust auf »Neues«, der Neugier auf den jeweils letzten Release aus dem Hause Apple und z.T. der Notwendigkeit (oder soll ich es »Nötigung« durch Apple nennen :-o) durch die Auslieferung neuer Rechner mit dem aktuellen System gibt es aber gerade im Business-Einsatz ein paar Dinge mehr zu beachten.

Da wäre zum Ersten die Unterscheidung zwischen Server-Betriebssystem und Client-Rechnern. Was für den Client i.d.R. schon recht ordentlich funktioniert, muss für den OS X Server noch lange nicht gelten. Nachzuschlagen bei 10.5., wo ich Serverinstallationen guten Gewissens erst mit 10.5.6 angefangen habe. Im Prinzip verhält es sich mit SL recht ähnlich. Gerade wenn es darum geht neue Features der Serverversion einzusetzen kann man nur warnen. Bei 10.5. entpuppte sich der als Killerfeature hochgelobte iCal-Server als absolut anfällig. Unter 10.6 stellt zunehmend der Adressbuchserver als (im Moment, Stand 10.6.1) unbrauchbar heraus. Hier gilt es entspannt abzuwarten oder Drittprodukte einzusetzen. Bei bereits erprobten und seit vielen Versionen implementierten Funktionen kann darüberhinaus auch der alte Grundsatz gelten: never change a running system. Warum aus 10.4 oder 10.5. nun mit Gewalt 10.6. machen, wenn die eingesetzten Dienste absolut ident bleiben?!

Zum Zweiten das Zusammenspiel in Netzwerken. Was auf dem Einzelplatzrechner noch prima funktionieren mag, muß für eine Netzwerkinstallation noch lange nicht gelten. Die Liste von Unverträglichkeiten die Apple im Rahmen von Updates in Sachen Netzwerk produziert hat ist lang: hier mal ein DNS nicht mehr tat was er sollte, dort mal ein »verbessertes« AFP-Protokoll, das halbe Netzwerke lahmlegte und Server Amok laufen liess, … Die Aussage: »Bei mir läuft alles bestens, keine Probleme mit SnowLeopard!« bekomme ich denn i.d.R. auch von Leuten, die einsam und alleine mit ihrem MacBook auf weiter Flur unterwegs sind.

Zum Dritten die Konsistenz von Betriebssystemen innerhalb eines Netzes und damit ggf. verbunden die Notwendigkeit von Investitionen in neue Hardware. Was wie gerade beschrieben für ein Netzwerk im Allgemeinen gilt, gilt umso mehr für ein Netzwerk aus gemischten OS Versionen. Dabei muss man nicht mal in die Ferne zu Windows und Linux schweifen; schon der gemischte Einsatz von 10.4., 10.5. und 10.6. – von noch älteren Sachen, sehen wir wirklich mal ab – kann unerwünschte Verhalten im Netzwerk produzieren. So wurden beispielsweise die Formate von iCal und Mail zwischen den Versionen immer wieder mal geändert – was auch für den Laien recht leicht erkennbar ist an den Dialogen der ersten Installation: »Mail muß ihre Postfächer importieren« oder so ähnlich schlägt es einem nach erfolgtem Systemwechsel entgegen. Ein hin- und herwechseln zwischen verschiedenen OS-Versionen z.B. im Zusammenhang mit serverbasierten Homeverzeichnissen ist dann zum scheitern verurteilt! Scheidet dann noch ein Upgrade von Rechnern aus – bei SnowLeopard betrifft dies z.B. sämtliche PPC-Rechner – so entsteht aus dem Wunsch nach einer neuen OS-Version schnell ein größerer Bedarf an Ersatzinvestitionen!

Und zum Vierten wäre da noch die Verträglichkeit der vorhandenen Software mit SnowLeopard zu prüfen. Neben einigem an kunden- oder branchenspezifischen Programmen (die i.d.R. aufgrund ihres begrenzten Marktes und den dadurch schmalen Ressourcen in der Entwicklung und im Support zumeist mit Freigaben für aktuelle Betriebssysteme etwas hinterher hinken) sind auch die üblichen Verdächtigen wie Office Pakete, Mal- und Zeichenprogramme oder das eine oder andere liebgewonnene Tool auf SL-Tauglichkeit zu untersuchen. Hierbei hilft erfreulicherweise recht unkompliziert die Software »SnowChecker«.

Unterm Strich bleibt daher zu sagen: Ja, cleintseitig kann SnowLeopard bereits eine Option sein, wenn es sich in die vorhandene Installationsbasis einfügt. Wer dringend neue Rechner braucht, sollte darauf achten, das ggf. ein Downgrade auf 10.5. noch möglich ist!

 

Mac-Anbindung an Windows 2008 Server

Eigentlich bevorzuge ich immer noch den OS X Server, aber da Kunde bekanntermaßen König ist darf ich mich mit dem Thema »Wie binde ich einen Mac Client an einen Windows 2008 Server?« beschäftigen.

Die Antwort auf diese Frage klingt trivial: Dienstprogramm Verzeichnisdienste öffnen, das Active Directory PlugIn mit der AD-Domain des Servers ausstatten, AD-Verwalter und -kennwort eintragen, fertig.

AD-Einbindung von Leopard an Windows 2008 Server

Wären da nicht noch ein paar »aaabers«, die es dazu zu beachten gibt.

  1. Voraussetzung ist natürlich ein ordentlich konfigurierter Server. D.h. LDAP und DNS müssen laufen und idealerweise übernimmt der Server auch noch den DHCP Broadcast um die Informationen korrekt an die Clients zu übermitteln. Eigentlich nicht sehr viel anders, als beim OS X Server (wenn gleich ich beim Blick in die Adminoberfläche des Windows-Rechners den oftmals verfluchten OS X Server im Inneren still lobpries!)
  2. eingebunden bekommt man auf diese Weise sowohl 10.5 wie auch 10.4. Clients. Allerdings verweigern die Tiger danach den Verbindungsaufbau via SMB, sprich: die übermittelten Credentials prallen ab. Lediglich bei Leopard ist damit macseitig wirklich schon alles getan.
  3. um die Tiger-Clients mit SMB auszustatten bleibt der Griff zur 3rd-Party Software. ADmitMac von Thursby landete dabei gleich im ersten Versuch einen Treffer. Aufgrund des Preises von rund 150 EUR ist sollte allerdings auch eine Prüfung dazugehören, ob die Clients nicht doch zu einem Upgrade auf Leopard taugen (oftmals fehlt es ja nur an etwas RAM, welches gerade günstig zu bekommen ist) oder ob nicht besser gleich in einen aktuellen Rechner investiert wird.

Snow Leopard ante portas

wie immer, wenn Apple neue Mac OS X Versionen vorstellt fristet der Server ein Schattendasein. Kein Wort davon, dass mit der Veröffentlichung von Snow Leopard 10.6. im Herbst auch die entsprechende Server-Version bereitgestellt werden wird.
Der Weg über die Apple Seite fördert dann aber doch noch ein paar Infos zu Tage: http://www.apple.com/de/server/macosx/ Die dort beschriebenen Features klingen – auch einmal mehr – vielversprechend. So sehr, dass sie auf den Prüfstand gehören:

Simple Administration

»Allein mir fehlt der Glaube« ist man geneigt zu sagen, wenn man die Screenshots betrachtet und sich vor Augen hält, das diese GUI bereits aus Leopard 10.5. bekannt ist. Ebenso ist bekannt, das diese simple Administrationsoberfläche auch mit der »simplen« Konfigurationsmethode des Servers einhergeht, also der Methode bei der man eigentlich gar keinen Server braucht, sondern ebenso gut seinen Client aufbohrt. Für diese Karoeinfach-Kram braucht man wirklich kein IT-Abteilung. Für einen vollständigen Server, auch wenn OS X draufsteht, aber schon, oder mindestens einen externen Dienstleister.

iCal Server 2

Das wichtigste zuerst: die dämlichen Bubbles als Infofenster zu den Terminen verschwinden offenbar. iCal hatte sich u.a. damit gegenüber Tiger bis zur Unbenutzbarkeit verschlimmbessert. Der Server selbst basiert weiterhin auf CalDAV. So sehr beim Client also auf Exchange-Kompatibilität geachtet wurde – dem Server fehlt sie offenbar. In einem gemischten Netzwerk könnte also weiterhin ein Kerio Mailserver von Nöten sein.

Address Book Server

Na endlich! Konnte Leopard bisher nur mit einer halben Groupware aufwarten, bekommt der Schneeleopard nun endlich auch noch die andere Hälfte dazu. Aber wie schon unter iCal: kein Wort von der Anbindung anderer Clients als die Apple-eigenen. Auch hier gilt: im Zweifel lieber noch ein bisschen Etat für einen Kerio einplanen.

Podcast Producer 2

Ehrlich gesagt: ich hab ihn unter Leopard noch nie gebraucht und mir fällt auch für die neue Version herzlich wenig an Verwendung dazu ein. »… distributing university lectures …« mag ich ja noch glauben, aber »… training a sales force …« ist für mich ein für ein kommerzielles Umfeld an den Haaren herbeigezogenes Beispiel. Der fehlende Rückkanal mag dem Dozenten an der Uni noch einigermassen piepenhagen sein – die nächste Klausur wird schon darüber befinden obs angekommen ist. Als Verkaufsleiter/-trainer hätte ich schon gerne eine Einschätzung ob mein Sermon auf fruchtbaren Boden fällt, hängt doch nicht viel weniger als der Erfolg meines Produktes oder gar meines ganzen Unternehmens davon ab.

Wiki Server 2

Auch den habe ich bisher noch nicht eingesetzt, sehe aber durchaus mehr Sinnhaftigkeit für dieses Feature. Im Prinzip kann damit ein komplettes Intranet mit Stellenbeschreibungen, Organisationsprinzipien, Ablaufplänen, Arbeitsanweisungen, Dokumentationen, etc. etc. erschlagen werden. Ein bisschen mehr an vorgefertigter Struktur á la Pages-Vorlage zu o.g. Themen und gerne auch darüberhinaus würden den Einsatz erheblich beflügeln.

Mobile Access Server

VPN ohne VPN?! Ich weiß noch nicht was ich davon halten soll. Wie immer wo Bequemlichkeit einkehrt, geht IMHO Sicherheit zurück. Zumal die Einrichtung von VPN sowohl server- wie auch clientseitig auf OS X nicht wirklich Raketentechnik ist.

iChat Server

Den letzten iChat Server habe ich vor Jahren unter Tiger aufgesetzt. Genutzt wurde er nie. Ist meine Kundschaft zu wenig hip oder ist auch das etwas, das die (Business)Welt nicht wirklich braucht?

Mail Services

Leider verraten die Darstellungen auf der Seite rein gar nichts zum Server selbst. Bisher – sowohl unter Panther, Tiger und Leopard – galt aber: die GUI bildet nur einen sehr schmalen Teil der Konfigurationsmöglichkeiten ab. Vernünftige Kenntnisse in postfix, squirrelmail und Konsorten sowie ein geübter Umgang mit der Konsole waren (und dürften auch weiterhin) unabdingbar (sein). Schon wieder (immer noch) eines raufgezählt für die Kerio-Anschaffung.

Web Hosting

Ebenfalls wird ein Bild aus der Abteilung »Schmalspur« herangezogen um die Einfachheit zu zeigen. Einen Haken setzen, fertig, online. Die Wahrheit im Serveradmin-Tool dahinter schaut anders aus und wenn nur der nervige Bug mit immer notwendigen Zertifikaten (auch wenn sie nicht zum Einsatz kommen) gefixt wäre, wäre schon was gekonnt.

File Sharing, Spotlight Server, Client Management, Networking und VPN

Eigentlich alles nichts wirklich Neues, die Verbesserungen liegen fast überall ausschliesslich im Performance-Bereich. Business as usual. Vielleicht schneller, vielleicht schlanker im Code, aber keinesfalls neu. Macht nix, funkioniert ja auch schon seit Leopard, teilweise sogar schon seit Tiger prima.

Was bleibt unterm Strich?

Snow Leopard (Server) ist Leopard (Server) wie er immer hätte sein sollen – so wurde es uns schon bei der ersten Präsentation eingebläut. Bei aller Neuentwicklung, die dort aufgrund von 64-Bit-Technologie, Grand Central, OpenCL und so weiter und so fort sicherlich eingeflossen sein mag, vordergründig bleibt es ein Minor-Release, ein weiterer Bugfix des längst als Bettvorleger gelandeten Leoparden, das auch noch Geld kosten wird. Wieviel das für den Server sein wird, ist noch nicht klar. Meiner Vermutung nach, reden wir aber über sicher rund 200 EUR für die »unlimited« Lizenz und etwa 100 EUR für die 10er-Lizenz.

Mit dem Release-Datum September + einer Karenzzeit für Tests und Bugfixes könnte also für den Großteil meiner Kunden ein Upgrade auf SnowLeopard zum Jahreswechsel 2009/2010 in Frage kommen. Der Rest wird – schon mangels Investitionsbereitschaft in einen Intel-Rechner als Server, der Voraussetzung ist, auch weiterhin mit Tiger (!) arbeiten. Und auch meine Kerio-Installationsbasis wird unter SnowLeopard nicht zusammenschmelzen.

Ein Grund mehr sein WLAN zu schützen

Was ich in meinem Artikel »Sicherheit im WLAN« schon beschrieb, hat nun das Landgericht Hamburg in einem Urteil vom 26. Juli bestätigt: Wer sein drahtloses Netz jedermann offen hält, wird für die Folgen haftbar. Im konkreten Fall konnte sich die Musikindustrie mit einem Unterlassungsbegehren gegen einen WLAN-Betreiber durchsetzen, der sein Netz ohne Schutzmechanismen betrieb. Nachdem über den offenen Accesspoint Musikstücke illegal über ein Gnutella-Netz bereitgestellt wurden, hatte nicht der (unerkannte) Filesharer das Problem, sondern der Betreiber des WLANs!

Wörtlich heißt es in dem von Rechtsanwalt Lampmann veröffentlichten Urteil:

Zwar konnte weder festgestellt werden, dass sie selbst die Rechtsverletzung begangen haben, noch konnte es durch die Vorlage der eidesstattlichen Versicherung ausgeschlossen werden. Denn die eidesstattliche Versicherung sagt nichts dazu aus, ob die Antragsgegner persönlich zum streitgegenständlichen Zeitpunkt die Rechtsverletzung begangen haben, dass sie sich auf eine erst am 20.03.2006 erfolgte Überprüfung bezieht. Auch kann letztendlich nur vermuten, wie seine Eltern, die Antragsgegner, den Internetanschluss genutzt haben. Es ist aber nicht auszuschließen, dass die Rechtsverletzung durch andere nicht bekannte Nutzer des Anschlusses erfolgt sind die die ungeschützte WLan-Internetverbindung der Antragsgegner genutzt haben.

Ob die Antragsgegner die Rechtsverletzungen selbst begangen haben oder ob die Rechtsverletzungen aufgrund einer Nutzung der ungeschützten WLan-Internetverbindung durch Dritte erfolgten, kann aber dahinstehen. Denn die Antragsgegner haben für diese Rechtsverletzung jedenfalls nach den Grundsätzen der Störerhaftung einzustehen.

Wie üblich schützt auch Unwissenheit hier nicht vor Strafe! Auch wer nicht selbst über die notwendigen technischen Kenntnisse zur Einleitung von Absicherungsmassnahmen verfügt, muss für Abschottung sorgen. Die Kosten für professionelle Hilfe hält das Gericht – aus meiner Sicht zu recht – für zumutbar. Auch die widerspenstigsten WLAN-Router und -Accesspoints sollten nach längstens einer halben Stunde dichtgemacht sein.

Neben den vitalen Interessen, die jeder haben sollte, seine eigenen Dateien und Netzressourcen vom dem Zugriff Dritter zu schützen, tritt damit auch der Schutz vor zivilrechtlichen Ansprüchen und – mal die gerade gerne genommenen Szenarien von Terror, Kinderporno oder Rechtsextremismus rangezogen – sogar vor strafrechtlicher Verfolgung.

Es muß nicht immer Kaviar sein, …

Edel, kostspielig und gut. Das trifft nicht nur auf Kaviar sondern auch auf den OS X Server zu. Wer nur eine kleine Arbeitsgruppe mit wenigen Diensten zu versorgen hat, wird selbst vor den – mit rund 480 EUR an sich moderaten – Kosten einer 10er Lizenz für OS X Server zurückschrecken. Daher hier ein paar kleine Tipps wie man mit wenig Aufwand und kleinem Shareware-Geld ein auf jedem Mac installiertes OS X Client System aufbohrt und zum Server macht.

Filesharing

 

Elementare Funktionen um Dateien zwischen Windows- und Macintosh-Clients auszutauschen, bzw. gemeinsam zu nutzen bringt jedes OS X ab Werk mit. Ein einfacher Haken bei »Personal FileSharing«, bzw. »Windows FileSharing« in der Systemeinstellung »Sharing« und los geht’s. Leider sind die Funktionen sehr rudimentär und insbesondere die Verwaltung von Benutzer- und Gruppenrechten alles andere als komfortabel. Da war selbst OS 9 besser aufgestellt. Abhilfe schafft das Programm SharePoints, welches neben der selektiven Freigabe von Ordnern auch gleich die zugehörigen Benutzerrechte mitverwaltet. SharePoints läuft als Universal Binary auch auf Intel Macs und ist Donationware – sprich der Autor freut sich über jede beliebig hohe Spende.

NFS-Shares

Wer neben Windows- und Mac-Rechnern auch noch Linuxrechner optimal mit gemeinsam genutzten Verzeichnissen versorgen will, kann dazu auf das NFS-Protokoll zurückgreifen. Da OS X über einen Unix-Kern verfügt ist auch das NFS-Protokoll als solches bereits enthalten und kann mit entsprechenden Kenntnissen auch über die Kommandozeile eingerichtet werden. Eine sehr viel komfortable Konfigurationsmöglichkeit bietet der NFS-Manager von Marcel Bresink. Das Tool ist als Shareware für $15 sowohl für PPC als auch Intel Macs erhältlich.

Gemeinsame Nutzung von Druckern und Faxmodem

 

Lokal per USB am Server angeschlossene Drucker sind ebenfalls über einen Haken unter »Sharing« freizugeben. Über den Reiter »Sharing« in den Systemeinstellungen »Drucken und Faxen« werden dann noch die einzelnen Drucker die im Netzwerk erscheinen sollen festgelegt. Hier wird ebenfalls die Freigabe des Faxmodems eingerichtet. Kosten für Software: keine.

Webserver

 

Insbesondere als lokale Entwicklungsumgebung ist der eingebaute Webserver von OS X sehr gut zu gebrauchen. Als Basis verwendet OS X den Apache-Webserver, so fast schon so etwas wie der Quasistandard als Webserver geworden ist. Sofern eine genügend schnelle Leitung (wichtig: die Upstreamleistung ist hier entscheidend!) zur Verfügung steht, spricht auch nichts dagegen den Webserver im Internet öffentlich zu betreiben. Wer lediglich statische HTML-Seiten erstellt und vorhält ist mit dem schon mehrfach angesprochenene Haken unter »Sharing« fertig. Wer es etwas komfortabler mag, nimmt in der Datei /etc/httpd/httpd.conf die Kommentarzeichen für die PHP-Einbindung raus und bekommt damit die Möglichkeit auch dynamische Seiten unter PHP zu erstellen. Zusammen mit einer Datenbank Installation, z.B. gibt es fertige Binaries von MySQL für OS X, entsteht so mit wenigen Klicks ein sehr leistungsfähiger Webserver. Auch die Möglichkeit zum WebDAV-Zugriff ist mit wenigen Einträgen in der Konfigurationsdatei zu ermöglichen, so daß der WebServer als Basis für den Austausch von iCal-Terminen genutzt werden kann.

Ein Wort zu den immer gerne gepriesenen „Instant-Webservern“ wie XAMPP oder MAMP oder den recht komfortablen Installationen von Serverlogistics. Grundsätzlich vereinfachen sie jemandem ,der zuvor noch nie einen Webserver aufgesetzt hat, das Geschäft. Allerdings stehen einem diese fertigkonfektionierten Installationen mit etwas mehr Kenntnissen sehr schnell im Weg, weil doch einiges „verbogen“ wird, um z.B. dem bereits vorhandenen Apachen nicht ins Gehege zu kommen. Ein kleiner Lernaufwand an Anfang, um die Einträge der httpd.conf kennen zu lernen ist langfristig wesentlich ergiebiger als der schnelle Erfolg der Instant-Webserver Installationen. Apache, PHP, WebDAV sind an Bord, MySQL ist Freeware.

FTP-Server

Auch hier böte OS X einen einfachen Klick und fertig wäre der FTP-Server. Aber: die Implementation des eh etwas anfälligen FTP-Protokolls ist so unsicher gelöst, das man dringend von den OS X eigenen Ressourcen abraten muß. Besser gelöst ist diese Aufgabe mit dem PureFTPd Manager. Auch der PureFTPd Manager läuft bereits nativ auf den Intel Macs und ist ebenfalls Donationware.

Mailserver

Für etwa $20 bekommt man mit MailServe »a totally-functional buzzword-compliant mail server in less than a minute, the Mac Way«, also einen fix und fertigen Mailserver, der sowohl POP, IMAP und SMTP mit wenigen Klicks auf einem beliebigen PPC oder Intel Mac unter OS X zur Verfügung stellt. Wer lediglich einen SMTP-Server für den Versand von eMails betreiben will, kann für’s halbe Geld auch auf den PostfixEnabler zurückgreifen.

DomainName-Server (DNS)

Insbesondere wenn das Netz etwas wächst wird man es zu schätzen wissen, die Rechner beim Namen nennen zu können und sich nicht kryptische IP-Nummern merken zu müssen. Aus gleichem Haus wie der PostfixEnabler und MailServe kommt daher für weitere $9,99 der DNSEnabler an Bord.

DHCP-Server

Als Grundlage für den DNS empfiehlt es sich auch einen DHCP-Server zu betreiben. Leider gibt es keinen fertigen DHCP-Server für den OS X Client, sondern lediglich den Source Code des Internet Systems Consortiums, der dann noch zu komplieren wäre. Wer diese Aufgabe scheut, sollte auf die DHCP-Server Funktionen zurückgreifen, die heute so ziemlich jeder DSL- oder ISDN-Router enthält.

VPN-Server

Auch hier bietet sich leider nur die Wahl zwischen selbst kompilierten Lösungen oder dem Rückgriff auf einen – meist schon etwas leistungsfähigeren – Router, der eine VPN-Anbindung mitbringt.

NTP-Server

Um innerhalb des Netzes eine gemeinsame Uhrzeit zu haben verfügen bietet OS X die Möglichkeit in der Systemeinstellung »Datum und Uhrzeit« einen Timeserver anzugeben. Neben den Apple-Timeservern bietet sich der Rückgriff auf die Pysikalisch-Technische Bundesanstalt – dem Betreiber der deutschen Atomuhr – unter ptbtime1.ptb.de oder ptbtime2.ptb.de an. Auch hier verfügen die meisten Router über eine entsprechende Funktion, so dass diese einmalig einen Netzverkehr nach aussen produzieren und die Clientrechner wiederum auf den Router als Timeserver zurückgreifen können.

Firewall und NAT

Einen elementaren Angriffsschutz bietet OS X – wiederum in der Systemeinstellung »Sharing« – mit seiner eingebauten Firewall. Zu beachten ist: wer neben den Standarddiensten die unter »Sharing« verwaltet werden, weitere in sein System implementiert, muß notwendige Ausnahmen für die Firewall manuell einpflegen. Ggf. ist es überlegenswert in einem überschaubaren und vertrauenswürdigen internen Netz die OS X Firewall ganz abzuschalten, wenn dafür nach aussen über den DSL-Router eine entsprechende Firewallfunktionalität zur Verfügung steht. Auch bei der Weitergabe der DSL-Verbindung an andere Rechner und dem dafür notwendigen NAT (Network Address Translation – kurz: die externe IP im internen Netz nutzbar machen) ist ein expliziter Router ungleich leistungsfähiger als die Möglichkeit die OS X unter »Sharing« »Internet« dafür bietet. Insbesondere können in einem Router dafür weitreichende Regeln hinterlegt werden, welcher Rechner, welche Dienste zu welchen Zeiten nutzen oder eben auch nicht nutzen darf.

iChat-Server

Um den Funktionen eines OS X Servers nahe zukommen, gehen wir einfach mal alle Dienste durch, die dieser ansonsten noch so bietet. Dazu gehört auch die Möglichkeit einen eigenen iChat-Server aufzusetzen. Dieser basiert unter OS X Server auf Jabber. Neben zwei Java-Lösungen (Wildfire und Open-IM), die „out-of-the-box“ eingesetzt werden können, gibt es nur noch von ejabberd ein fertiges Binary (allerdings derzeit ausschliesslich für PPC-Macs) um einen entsprechenden Server zu betreiben.

Anwendungsserver

Unter OS X gehören dazu neben Tomcat und JBoss auch noch das appleeigene WebObjects. Letzteres ist seit der Version 5.3 kostenloser Bestandteil der Developer Tools, die zu jeder Tiger-Version mitgeliefert werden. Kostenlos sind auch die Java-Applikationsserver Tomcat und JBoss die kostenlos heruntergeladen werden können.

Quicktime Streaming Server

Die Grundlage für diesen Dienst unter OS X Server bildet der Darwin Streaming Server der von Apple selbst als kostenloses OpenSource Programm zur Verfügung gestellt wird.

NetBoot-Server

Neben der Möglichkeit Clients ohne eigene Festplatte über das Netzwerk zu booten, wird dieser Dienst sehr häufig genutzt um von zentraler Stelle aus, eine (möglichst) einheitliche Installation auf allen Clients zu erstellen. Als kostenlose Alternative bietet sich dazu NetRestore von Mike Bombich an.

Softwareaktualisierungs-Server (SUS)

Der OS X Server bietet die Möglichkeit einmal zentral alle verfügbaren Updates für Apples Software Produkte zu holen und innerhalb des lokalen Netzes den Clientrechnern zur Verfügung zu stellen. Faktisch veringert sich dadurch lediglich der verbrauchte Traffic, verglichen mit dem Standardverhalten, das jeder einzelne Client auf das Internet zugreift um die verfügbaren Softwareupdates vom Apple-Server zu laden. Eine einfache und elegante Möglichkeit den SUS auf OS X Clientsystemen nachzubilden ist mir leider nicht bekannt. Nach meiner Einschätzung wäre es aber mit etwas Shell-Scripting zu lösen.

Update 04.05.2007 : Heise hat ein nettes Tool namens »OliU – c’t Offline Updater für Mac OS X 10.4.« auf der Basis des Kommandozeilentools »wget« veröffentlicht, mit dem man sich die Updates vom AppleServer auf ein lokales Volume ziehen kann. Einstellbar ist, für welche Architektur – PPC und/oder Intel – die Pakete geladen werden sollen und wo und wie sie gespeichert werden. Für unseren Zweck als Server wäre sicherlich das Verzeichnis „Web-Sites“ und die Freigabe via Webserver im lokalen Netz sicherlich das Mittel der Wahl.

OpenDirectory

Last but not least – der zentrale Dienst des OS X Servers überhaupt. Fast alle o.g. Dienste kennen unterschiedliche Rechte für einzelne Benutzer. Und sei es, das ein Benutzer den betreffenden Dienst überhaupt nutzen darf. Aus diesem Grund bauen unter OS X Server fast alle Dienste auf einer zentralen Benutzerverwaltung – dem OpenDirectory – auf. Grundlage für OpenDirectory ist ein LDAP-Server. Auch hierzu gibt es mit OpenLDAP einen kostenlose OpenSource Ersatz, der allerdings nur Source-Code zur Verfügung steht, also selbst kompiliert werden muß. Grundsätzlich kann man aber festhalten: alle o.g. Dienste, die eine Konfiguration von Benutzerrechten erfordern bringen – jeder für sich – die notwendigen Einstellmöglichkeiten mit. Die zentrale Verwaltung ist damit vorallem ein Komfortgewinn und minimiert potentielle Fehlermöglichkeiten. Wer wirklich so viele Dienste auf seinem Server anbietet, das eine solche zentrale Benutzerverwaltung Sinn macht, sollte ernsthaft über die Anschaffung des OS X Servers nachdenken! Der Rest kann wie oben gezeigt mit wenigen Dollar für Shareware und etwas Fleiss bei der Einrichtung schon recht weit kommen.

Vorteil aller hier gezeigten Lösungen: sie unterliegen keiner Lizenzbeschränkung, wären daher vom Gegenwert her eher mit der unbegrenzten Lizenz des OS X Servers (ca. 970 EUR) zu vergleichen. Die meisten Programme liegen zudem schon als Universal Binary vor und können damit auf den aktuellen Intel Macs eingesetzt werden, während OS X Server noch auf PPC-Macs ausschliesslich läuft. Grundsätzlich sollte für eine kleine Arbeitsgruppe mit bis zu 5 Clients und einer handvoll Dienste aber jeder OS X fähige Rechner ausreichen. Selbst ältere G3- und G4-PowerMacs sind mit genügend RAM und einer schnellen Festplatte dieser Aufgabe locker gewachsen.

ebay-Auktionen bequem verfolgen

In Zeiten des Kostendrucks ist auch für Firmen ebay zunehmend eine ernstzunehmende Einkaufsquelle. Leider ist ebay kein großer Freund von Macintosh und Safari Usern und schon gar kein ausgewiesener Experte bei der Programmierung von standardkonformen Seiten. So sind einige nette Dinge, die Windowsuser kennen für den Mac schlicht nicht verfügbar.

Zum Beispiel die Möglichkeit mit einem schlichten Klick auf einen Link unter dem Auktionsende-Datum sich dieses Datum in seinen (Outlook) Kalender eintragen zu lassen. Um diese Funktion auch am Mac zu erhalten gibt es jedoch ein kleines AppleScript namens »eBaytoical«. eBaytoiCal ist ein Parser der die komplette Angebotsseite ausliest und nach bestimmten Informationen – hier dem Endedatum der Auktion – durchsucht. Entsprechend muß die Seite für die eine Erinnerung eingetragen werden soll das gerade aktive Fenster sein. Da der grundsätzliche Aufbau einer ebay-Angebotsseite immer gleich ist, kann das so lange zuverlässig erfolgen, wie die Struktur der Seite durch ebay nicht verändert wird. Ist das Auktionsende-Datum identifiziert, wird es in einem speziellen Kalender unter iCal abgelegt. Auch eine Erinnerung und der Link zur betreffenden Seite wird gleich mit angelegt, so daß man unmittelbar vor Auktionsende in die Versteigerung eingreifen kann.

Im Gegensatz zu sogenannten Snipern – also automatischen Bietagenten, die kurz vor Auktionsende ihr Gebot abgeben – ist eine solche Erinnerung in Übereinstimmung mit den ebay-Nutzungsbedingungen.

Den Aufruf des Scripts habe ich mir via Butler zusätzlich auf eine Tastenkombination gelegt, so dass dieser Hotkey im aktiven Fenster ausreicht um die Eintragung auszulösen.

Auf der Seite des Autors Ulrich Kortenkamp ist zu dem ein Modifikation des Scripts aufgeführt mit dem der Eintrag statt an iCal an Entourage übergeben werden kann. eBaytoiCal ist Donationware, sprich kostenlos nutzbar, der Autor freut sich jedoch über eine kleine Spende.

Briefkasten unter OS X

Eine sehr einfach Form des Dateiaustauschs zwischen mehreren Benutzern und mehreren Rechnern in einem Netzwerk bringt OS X ab Werk mit. So ist in jedem Benutzerverzeichnis ein Ordner »Öffentlich« (Public) und darin ein Ordner »Briefkasten« (Drop Box) zu finden. Arbeiten mehrere Benutzer auf ein und demselben Rechner kann man einem anderen Benutzer über den Briefkasten eine Datei zu kommen lassen. Oder umgekehrt Dateien aus dem Ordner »Öffentlich« des anderen Benutzers einsehen.

 

oeffentlich-briefkasten-ordner  systemeinstellung-sharing

Sind mehrere Rechner in einem Netz genügt ein Griff zu den Systemeinstellungen »Sharing« um dort »Personal File Sharing« zu aktivieren. Als Standardfreigabe für Gäste erscheint fort an der o.g. »Öffentlich«-Ordner für den Down- und der »Briefkasten« für den Upload von Dateien. Die Rechte des Briefkastens sind dabei so gesetzt, das jedermann dort Dateien einstellen kann, der Ordner selbst jedoch nicht zu öffnen ist.

Fatal dabei ist, das Dateien, die von Dritten in meinem Briefkasten gelegt werden noch die Benutzerrechte des Dritten behalten. Ich habe damit zwar Verfügungsgewalt über den Briefkasten-Ordner selbst, nicht jedoch über die darin befindlichen Dateien.

Um diesen Umstand zu korrieren kann man nun zum Terminal oder zum Infofenster der Datei greifen. Eleganter ist jedoch dies das System selbsttätig erledigen zu lassen. Dazu nutzen wir eine kleine Ordneraktion. So bald eine neue Datei in den Briefkasten gelegt wird läuft die Aktion an. Sie ermittelt den aktuell anmeldeten Benutzer des Systems und macht ihn zum Eigentümer der neueingestellten Datei. Dazu sind Administratorrechte erforderlich; eine entsprechende Abfrage zur Identifizierung erscheint ggf.

Wie üblich gibt es hier auch dieses kleine Ordneraktions-Script kostenlos zum Download.

Sicherheit im WLAN

Drahtloses Surfen erfreut sich steigender Beliebtheit. Auch ich gönne mir jeden Sommer diesen Spaß gegönnt und warte schon wieder sehnsüchtig auf die ersten Sonnenstrahlen, die es mir ermöglichen mein Büro in den Garten zu verlegen. Ein echtes Stück Lebens- und Arbeitsqualität das ich nicht mehr missen möchte. Aber deshalb muß man es ja nicht gleich jedem gönnen.

Das Plug-and-Play-Vergnügen das einem die Hersteller der diversen WLAN-Basisstationen liefern ist unter Sicherheitsaspekten als kritisch einzustufen! Das gilt nebenbei bemerkt für fast alle Hersteller solcher AccessPoints. So unterschiedlich die mitgelieferten Konfigurationstools, Firmwares etc. sein mögen, die Werkseinstellungen bezüglich der Sicherheit sind i.d.R. offen wie ein Scheunentor. Rühmliche Ausnahme scheinen die Fritz!Boxen zu sein, die dafür an anderer Stelle so ihre Tücken haben.

In dem Moment wo ein WLAN-AccessPoint eingeschaltet wird, ist er für jeden Rechner, der mit einer entsprechenden Gegenstelle ausgestattet ist, sicht- und ansprechbar. Alle dahinterliegenden Dienste sind sofort verfüg- und nutzbar, sofern diese nicht eigene Sicherheitsvorkehrungen mitbringen. Verfügbare Dienste heißt nicht automatisch (nur) Internetzugang, auch wenn dies der mit Abstand meistgebotene Dienst ist. Auch freigegebene Laufwerke von Servern oder Arbeitsplatzrechnern, Intranet-Webserver, freigegebene Drucker, FaxModems, Mailserver, etc. etc. sind dann für jeden, der über diesen Accesspoint zum eigenen Netz Zutritt erhält verfügbar. Obwohl räumlich »Von aussen« kommend ist ein solcher »Gast« netzlogisch ein interner Benutzer. Daher sind z.B. auch alle Vorkehrungen die zur Abschottung des internen Netzes gegenüber dem Internet in Form von Firewalls, Paketfiltern, Proxies etc. getroffen werden an dieser Stelle erst einmal wirkungslos.

Die Folgen der Freiheit

Wie schon gesagt stehen diverse Dienste, die für die berechtigten Nutzer eines Netzwerks gedacht sind, auch allen anderen »Besuchern« offen. Da oft auch andere Sicherheitseinstellungen, z.B. für den Zugriff auf gemeinsame Dateien lax gehandhabt werden, könnte ein unberechtigter Dritter Einblick in Dateien nehmen, diese verändern oder sogar löschen. Oder auf freigegebenen Druckern den Papier- und Tonervorrat mit reichlich Müll verbraten. Oder über ein FaxModem noch einen Kumpel anrufen und auch ihm das Netz via Modem zugänglich machen. Der häufigste Fall des Mißbrauchs wird jedoch das Surfen auf anderer Leute Kosten und in anderer Leute Verantwortung sein.

Eine mögliche Kostenfalle läßt sich am einfachsten mit einer Flatrate umgehen. Einige WLAN-Accesspoint-Betreiber machen dies sogar bewußt um im Sinne eines »OpenSource«-Gedankens anderen an ihrer schnellen Internetverbindung teilhaben zu lassen. Auch erste Geschäftsmodelle, die diesen Gedanken um eine Bezahlvariante anreichern sind in der Entstehung, wenn auch nicht immer ganz ausgegoren oder wirtschaftlich. Egal unter welchen Bedigungen ein WLAN-Accesspoint offen steht – freiwillig oder unfreiwillig, kostenlos oder gegen Obulus – zum Internetzugangsprovider für DSL, ISDN oder Analog-Verbindung tritt das interne Netz immer nur unter einer IP-Nummer auf. Und diese ist rückverfolgbar bis zum Netz des WLAN-Betreibers. Und auf den fällt die Beweislast, wer wann in Netz mit welcher internen IP denn bestimmte (illegale) Dinge getan hat. Ein schwierig zu führender Beweis, da die WLAN-Accesspoints über gar keine oder keine ausreichenden Log-Funktionen verfügen! Spätestens hier wird ersichtlich das es bestimmte Hürden braucht um seine Ressourcen nur den jenigen zu überlassen, denen man vertraut.

Fünf Sicherheitstipps für den Betrieb eines WLAN

  1. WLAN abschalten
    Auch wenn das zunächst paradox klingt: wenn WLAN nicht wirklich gebraucht wird (weil man sowieso gerade neben der Ethernet-Steckdose sitzt), einfach mal den AccessPoint abschalten. Voreinstellungen sind in einem nichtflüchtigen Speicher geschützt, so das es überhaupt nichts schadet diesen Teil des Netzwerks bedarfsweise vollkommen lahm zulegen. Der sicherste Schutz überhaupt!
  2. ESSID-Kennung ändern und verstecken
    Ab Werk sind WLAN-Accesspoints mit so sinnigen Namen für den ESSID (Extended Service Set Identifier) wie „default“ oder dem Namen des Herstellers ausgestattet. Anhand dieser einfachen Benenung sind WLAN-Netze leicht aufzustöbern und auf Verfügbarkeit zu prüfen. Ein eigener, eindeutiger Name ist also ein erster Schritt. Durch das Verstecken dieser Kennung, können sich weiterhin nur die Rechner am WLAN anmelden, die den korrekten Namen kennen und übermitteln. Die Grenzen des ESSID-Versteckens sind allerdings auch schon ausführlich beleuchtet.
    Schutzmechanismen am Beispiel der Airport Basisstation
  3. WEP/WPA-Verschlüsselung aktivieren
    Wie schon am Titel zu erahnen sind für die Verschlüsselung gleich mehrere Methoden unterwegs. Die Auswahlreihenfolge ist einfach: WPA (Wi-Fi Protected Access) geht vor WEP (Wired Equivalent Privacy). Je größer die bit-Zahl des Verschlüsselungsalgorithmus ist, desto sicherer. Hex geht vor ASCII. Ausgewählt wird letztlich das, worauf alle Rechner eines Netzes sich verstehen (kleinster gemeinsamer Nenner aus Kompatibilitätsgründen). Größter Nachteil dieser Verschlüssung – bei WPA zwar etwas besser als bei WEP – ist, das der Schlüssel statisch ist und ein ausreichend langes Belauschen der drahtlosen Übermittlung von eingebuchten Rechnern ausreicht um den Schlüssel rückrechnen zu können. Tools zum Aufspüren und Entschlüsseln von WLANs sind im Internet frei verfügbar. Entsprechend kann und sollte der Schlüssel von Zeit zu Zeit ausgetauscht werden.
    Dialogfenster zur Einstellung der WEP/WPA-Schutzfunktionen Die Angabe der entsprechenden WEP/WPA-Einstellungen auf dem einwählenden Rechner
  4. Positivliste von MAC-Adressen
    Jede Netzwerkkarte – eine WLAN-Karte ist nichts anderes – ist mit einem eindeutigen Media Access Code (MAC-Adresse) versehen. Durch eine Liste von zulässigen Netzwerk(WLAN)Karten in der Konfigurationsdatei des Accesspoints wird sichergestellt, das sich nur Geräte einwählen können, deren MAC-Adresse in der Positivliste auf der Basisstation enthalten ist. Umgekehrt können auch identifizierte Angreifer in eine Negativliste aufgenommen werden. Auch für dieses Verfahren gibt es Grenzen; eine MAC-Adresse kann mit entsprechenden Tools gefälscht werden.
    Hinterlegung von zugelassenen MAC-Adressen Einstellungen auf der Clientseite für den Zugang zu einem geschützten WLAN
  5. VPN-Verschlüsselung
    Einige neuere WLAN-Router verfügen über die Möglichkeit den WLAN-Netzverkehr in einem verschlüsselten Tunnel – einem Virtual Private Network (VPN) zu übertragen. Auch auf älteren Accesspoints ist dies machbar, sofern dahinter ein entsprechender Router/Server betrieben wird, der als VPN-Gegenstelle fungiert. Im Prinzip werden zwei Netze – eines vor (der Rechner, der sich per WLAN einwählt) und eines hinter dem WLAN-Accesspoint (das eigentliche Firmennetz) zu einem gemeinsamen Netz gekoppelt. Sofern ein solches WLAN abgehört wird, ist für einen Angreifer nur ein verschlüsselter Tunnel sichtbar. Dieser Schlüssel ist durch die gewählten Verfahren (zumeist IPSec) sehr sicher. Der eigentliche Datenverkehr läuft dann im Inneren dieses Tunnels ab und kann über weitere Mechanismen zusätzlich abgesichert werden.

Fazit

Für ein normales Maß an Sicherheit sollte eine Kombination aus den Verfahren 2), 3) und 4) verwendet werden. Damit werden einem potentiellen Angreifer gleich mehrere Hürden aufgestellt. Zunächst muß ihm die ESSID bekannt sein. Als nächstes muß er den stattfindenden Netzverkehr solange belauschen, bis der WEP/WPA-Schlüssel geknackt ist und zu guter letzt muß er dem Accesspoint eine gültige MAC-Adresse vorgaukeln. Wie schon gesagt: machbar ist das alles, wenn auch mit hohem Zeitaufwand für den Angreifer verbunden. Genau hierin liegt der Schutz: Aufwand und zu erwartender Erfolg stehen in keinem vernünftigen Maß zueinander. Wer kann und wer sich besonders gut schützen möchte, sollte eine VPN-Lösung erwägen, da sich hierbei der Zeitaufwand für einen Angreifer auf nahezu unendlich verschiebt. Die größtmögliche Sicherheit bietet ein bei Nichtbenutzung ausgeschalteter AccessPoint.