sshblack under macOS Sierra

When you run a computer that is SSH-enabled and open to access from the internet, you should use safe passwords (or even better: private key authentication) and a restrictive sshd.conf. But even with that, the barrage of malicious connection attempts can cause performance issues.

I have been using sshblack for many years on my Mac to battle that issue: when an IP address makes multiple failed attempts to login, it gets banned for a while. The popular fail2ban does that for Linux systems, but it doesn’t work on Mac OS X/macOS.

sshblack always needed some hand-holding with new OS releases, but with Sierra there was an entirely new challenge: there are no log files for sshd anymore! In previous versions, sshblack would look in /var/log/system.log for failed login attempts. The file still exists, but most logging in Sierra uses Apple’s new Unified Logging and Tracing System. That means the only way to access logging for sshd is either Console.app or the log CLI command. Using log with its stream parameter to get real-time logging data incurs a huge performance penalty, so the only way to go seems to be log show. So instead of tailing a log file, the script now has this definition:

my ($LOG) = ‚/usr/bin/log show –style syslog –last 1m |‘;

I added a sleep 60 statement to the loop and removed the code meant to deal with log rotation. Seems to work fine.

Update bezüglich Microsoft Excel für Mac und ODBC-Zugriff auf MySQL-Server

Das Folgende ist ein Update für diesen alten Artikel. Ich nutze mittlerweile Microsoft Excel 15 für Mac und El Capitán. Microsoft Query ist kein eigenes Programm mehr, sondern es öffnet sich ein Fenster innerhalb von Excel, das diesen Namen trägt. Dabei handelt es sich im Gegensatz zu früher um ein 32-Bit-x86-Programm. Deshalb muss man nicht mehr mühevoll ein fat binary erzeugen, dafür gibt es neue Probleme. Da ich nirgendwo einen Artikel zu diesem Thema finden konnte, dachte ich mir, dass ich so vielleicht mindestens einer weiteren Person auf dem Planeten helfen kann.

Neben Excel braucht man:

  • die 32-Bit-Version des freien MySQL-ODBC-Connectors (Plattform Mac OS X, Mac OS X 10.7 (x86, 32-bit), DMG Archive, aktuelle Version: 5.3.4)
    NB: man muss den Installer per Rechtsklick öffnen, weil er nicht signiert ist.
  • den ODBC-Manager

Nachdem man beide Pakete installiert hat, muss man zunächst den Connector verschieben oder kopieren. Der Installer installiert ihn nach /usr/local/lib. Wenn man den Connector dort lässt, kann Excel ihn nicht öffnen. Im Systemlog findet man diesen Hinweis:

sandboxd[160] ([45299]): Microsoft Excel(45299) deny file-read-data /usr/local/lib/libmyodbc5w.so

Excel hat über seine Sandbox also keine Leserechte auf das Verzeichnis. Security kann so lästig sein 😉

Dieses Problem kann man im Terminal wie folgt beheben:

$ sudo cp -p /usr/local/lib/libmyodbc* /Library/ODBC/

Wenn man danach den ODBC-Manager (im Ordner Dienstprogramme) startet, sollte man so etwas im Treiber-Tab anlegen:

ODBC-Treiber

Danach muss man für die gewünschte MySQL-Verbindung einen System-DSN anlegen:

DSN anlegen

DSN bearbeiten

Diese Verbindung kann man danach in Excel verwenden:

Datenbankabfrage einfügen

Microsoft Query

Microsoft Query

Streaming auf AppleTV über Subnetzgrenzen hinweg

airplay_appletvMit dem Update auf Softwareversion 6.1 bekam das AppleTV in Verbindung mit iOS 7.1 und höher ein neues Feature: AirPlay Discovery via Bluetooth. Dies ermöglicht nun viel einfacher die Verbindung zwischen AppleTV und AirPlay-Klienten, wenn sich diese nicht im selben IP-Subnetz befinden. Einrichtungen mit vielen IT-Anwendern sind gezwungen, einzelnen Abteilungen oder Arbeitsgruppen eigene getrennte IP-Subnetze zuzuordnen. Oft wird dem WLAN-Netz auch ein eigener IP-Bereich zugewiesen. Befindet sich das AppleTV dann netztechnisch im IP-Bereich einer Arbeitsgruppe, müssen die Klienten einige Barrieren überwinden.

Haben beide Geräte Bluetooth aktiviert und die aktuelle Softwareversion installiert, wird auf dem iPad/iPod/iPhone das AppleTV angezeigt. Unter Umständen ist jedoch keine Kommunikation zwischen den Klienten möglich. AirPlay erfordert, dass vom AppleTV eine neue TCP/UDP-Session zum Endgerät aufgebaut werden kann, obwohl die ursprüngliche Session vom Endgerät initiiert wurde.

Damit schließt AirPlay Umgebungen aus, die NAT mittels Port-Addresstranslation durchführen. Diese Hürde kann man jedoch durch Aufbau einer VPN-Verbindung überwinden. Verteilt das VPN-Gateway jedem Endgerät eine eigene IP, kann so doch AirPlay eingesetzt werden.

Nun müssen gegebenenfalls noch Freigaben eingerichtet werden, wenn die Subnetze durch eigene Firewalls abgesichert sind. Leider verwendet AirPlay dynamische Ports, so dass ganze Bereiche freigegeben werden müssen. Dabei verläuft die Kommunikation von hohen Ports (49152 – 65535) zu hohen Ports.

Folgende Freigaben sollten eingerichtet werden:Firewallregeln

Je nach Firewall-Typ müssen auch die Rückantworten zu den fünf Freigaben eingetragen werden, also Quellnetz/-port und Zielnetz/-port vertauscht.

Mit diesen Freigaben sollte AirPlay funktionieren. Wir konnten mit den gewählten Einstellungen Videos, Musik und den Bildschirminhalt erfolgreich auf das AppleTV streamen.

Cisco RTMT v8 on Mac OS X

This article expands on a topic others have written about before, i.e. running Cisco’s RTMT for the Cisco Call Manager on a Mac:

Both of these deal with earlier versions of RTMT. Please read at least Ciscomonkey’s article, because I’m not repeating the hints regarding the timezone issue here.

I found that it doesn’t work as easily using RTMT v8, specifically 8.92. Here’s what you have to do to get that version to run on your Mac:

  1. Install the Linux version in a Linux VM
  2. Copy the installation directory (usually that’s /opt/Cisco/Unified-Serviceability/JRtmt/) to your Mac (e.g. to /Applications/)
  3. Edit the file JRtmt/run.sh so that it uses /usr/bin/java instead of trying to start the bundled JRE (which is a Linux binary)

At this point you can launch RTMT by invoking run.sh from a terminal, but for additional convenience you can write yourself a GUI launcher. The basics are described in the article I linked to, but I added logging the output:

do shell script "cd /Applications/JRtmt; ./run.sh 2>&1|logger -t 'Jrtmt'"

Of course you’ll have to adapt the path to the location where you installed the directory. Now you can just double-click the AppleScript app, and RTMT’s output will be logged to Console.app.

AirPrint-Erfahrungen

Seit einiger Zeit (ab Version 4.2.1) können iOS-Geräte wie z.B. iPads und iPhones drucken. Der offizielle Weg funktioniert aber nur in Heimnetzwerken und mit wenigen Druckermodellen. Im Netz kursieren viele Anleitungen, wie man diese Beschränkung umgehen kann. Was ich hier darstelle, ist nicht neu, sondern nur ein Erfahrungsbericht über die Fallstricke, die einem begegnen können. Der beste Ausgangspunkt für eigene Versuche, den ich gefunden habe, ist dieser Blogeintrag. Insbesondere die dort aufgelisteten Links sind sehr hilfreich.

Auf die grundsätzlichen Dinge, wie die Konfiguration von CUPS und das Erstellen der Servicerecords im DNS, gehe ich hier nicht ein. Das ist an anderer Stelle (s.o.) schon zur Genüge getan. Folgende Probleme hatte ich zunächst:

  • Farbausdruck ging nicht
  • Druck aus Safari ging nicht

Das letztere Problem wurde, wie man im CUPS-Log (mit debug-Logging) sehen konnte, dadurch ausgelöst, dass das zu druckende Dokument als URF-Image geschickt wurde. URF ist ein „raster image format“, für das Apple den MIME-Typ image/urf verwendet, das aber leider nirgends dokumentiert ist. Eigentlich sollte URF in meinem Fall nicht verwendet werden, weil ich (gemäß den Anleitungen) urf=none deklariert hatte. Ich hielt das für ein möglicherweise neues Problem und habe deshalb nach Lösungen zum Drucken von URF gesucht. Es sei hier schon verraten: das war eine falsche Fährte. Dennoch folgt ein kurzer Exkurs zum Drucken von URF.

Frühere Versionen von Mac OS X hatten einen CUPS-Filter namens urf2pdf, mit dem das Drucken von URF möglich war. Mit dem Update auf 10.6.5 hat Apple diesen Filter gelöscht, man findet ihn aber noch im Netz. Wenn man den (mit den richtigen Permissions, also root:wheel als owner/group) installiert, und in den CUPS-Einstellungen den MIME-Type image/urf aktiviert, klappt das tatsächlich – aber nur unter Mac OS X. Ich habe keine Möglichkeit gefunden, CUPS unter Linux beizubringen, mit URF umzugehen.

Das zweite Problem war, dass alle Ausdrucke schwarzweiß waren, obwohl im Servicerecord für den Drucker Farbfähigkeit annonciert war. Wie ich jetzt weiß, war beider Rätsel Lösung offenbar identisch: Tippfehler im Servicerecord. Beim Studium der „Bonjour Printing Specification“ von Apple fiel mir auf, dass ich ein (ganz anderes) Attribut falsch geschrieben hatte. Nachdem ich alles entsprechend angepasst hatte, gingen auf einmal Farb- und Duplexdruck. Es sieht so aus, als ignoriere der Parser alle Attribute nach einem falsch geschriebenen. Deshalb wurde auch mein urf=none nicht ausgewertet. Mit der korrigierten Fassung geht jetzt auch ein CUPS-Server unter Linux, weil die iOS-Geräte jetzt alle Druckjpbs als PDF schicken.

Fazit: wie so oft in der IT können kleine Ursachen große Auswirkungen haben.

Not so S.M.A.R.T.?

Today I sent the following question to Alsoft’s (DiskWarrior) support:

„I noticed entries like this one in my system.log:

May 31 10:11:53 tyrion
/Applications/DiskWarrior.app/Contents/MacOS/DiskWarriorDaemon[932]: [Thu May 31
10:11:53 CEST 2012] : The spare blocks for ATA device 'ST31000528ASQ', serial
number '6VP319CR', appear to be exhausted. (Total Available: 36) (Use Attempts:
229)

I have researched the issue and was surprised that the DiskWarrior manual
doesn’t mention this at all. There is some anecdotal evidence on the web that a
message like that is an indicator for impending drive failure.

So I installed smartmontools, because I wanted to know more details about the
drive’s state. Here’s the relevant output I got:

sudo smartctl -A disk0
smartctl 5.42 2011-10-20 r3458 [i386-apple-darwin10.8.0] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate     0x000e   106   099   006    Old_age   Always       -       11960322
3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       33
5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       741
7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       246300939
9 Power_On_Hours          0x0032   078   078   000    Old_age   Always       -       19671
10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       44
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   046   042   045    Old_age   Always   In_the_past 54 (1 165 58 35 0)
194 Temperature_Celsius     0x0022   054   058   000    Old_age   Always       -       54 (0 9 0 0 0)
195 Hardware_ECC_Recovered  0x001a   034   021   000    Old_age   Always       -       11960322
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

From my understanding of the manpage, the actual count of reallocated blocks (as
given by attribute 5) is 741, and the „value“ of 82 is still well above the
critical threshold of 36. What’s more, the attribute 197 shows there are zero
„current pending sectors“, which I understand to mean that all reallocation
requests could be satisfied so far. This seems to run counter to the output of
DiskWarriorDaemon. Could you please explain the discrepancy? Should I replace
the drive after all?“

Their reply was short: „You should replace this hard drive.“

That’s fine (I should be able to replace the drive under AppleCare), but a little low on details. Can anyone explain to me why the output of smartctl seems to be so different? Where do DiskWarrior’s numbers come from?

Willkommen in der schönen neuen 64-Bit-Welt

Seit Montag habe ich einen neuen iMac mit Core i5-Prozessor. Meine bisherigen Systeme bei der Arbeit waren ein PowerMac G5 und ein MacBook der ersten Generation, also noch mit dem ersten Core-Prozessor, der nur 32-bittig war. Der PowerMac unterstützte zwar 64 Bit, aber damals war Apple mit Mac OS X noch nicht so weit. Nur für Intel-Prozessoren des Typs Core 2 Duo und höher gibt es seit Mac OS X 10.6 (Snow Leopard) GUI-Programme im 64-Bit-Modus.

Warum erzähle ich das? Ein von mir geschriebenes QuickLook-Plugin funktionierte auf dem iMac nicht mehr. Mein erster Verdacht ging natürlich dahin, dass es sich um ein 64-Bit-Problem handele. Das war zwar gar nicht so, aber ein solches gab es auch …

Mir war zuerst nicht aufgefallen, dass die Dokumente, auf die ich das Plugin anwenden wollte, noch auf dem PowerMac erstellt worden waren. Nach einiger Zeit habe ich begriffen, dass das Problem darin lag, dass das Dokument in „native byte order“ geschrieben war. Neu auf dem iMac erstellte Dokumente funktionierten eigentlich sofort, da das Plugin nur in einer 32 Bit-Version vorlag. Da ich dann aber der Vollständigkeit halber das Plugin neu kompiliert hatte, so dass es als „universal binary“ vorlag, hatte ich mir erfolgreich selbst eine Falle gestellt. Denn jetzt hatte ich wirklich ein 64-Bit-Problem.

Der Datentyp long hat auf 32-Bit-Systemen eine Länge von 4 Byte, auf 64-Bit-Systemen hingegen eine von 8 Byte. Weil ich das Plugin nicht mit Sicht auf 64 Bit entwickelt hatte, wurden falsche Werte gelesen.

Um sowohl den Umstieg von PPC auf Intel als auch den von 32 Bit auf 64 Bit zu unterstützen, musste ich:

– statt long den Datentyp int32_t verwenden
– die Bytereihenfolge vertauschen, wenn der gelesene Wert zu hoch war

Für Neugierige: mehr Informationen zu dem Plugin.

Debugging für Fortgeschrittene: Post-Mortem einer Java-Bugsuche

Damit hatten wir nicht gerechnet: nachdem Snow Leopard von Apple veröffentlicht wurde, zeigte sich, dass unsere UKLAN-Admin-Anwendung darunter nicht lief. Die Version von Java, die mit Snow Leopard auf Macs erstmalig der Standard ist, ist Java 6. Diese Version hatten Kollegen mit Windows- und Linux-Rechner schon längst ohne Probleme im Einsatz, so dass nicht zu erwarten gewesen war, dass das auf Macs anders sein könnte.
Das Problem lag bei der Authentifizierung. Beim Anmeldeversuch kam die Meldung, dass diese gescheitert sei. Im Log konnte man zu der Exception einen recht langen Stacktrace sehen. Die entscheidende Meldung lautete:

java.lang.IllegalArgumentException: EncryptionKey: Key bytes cannot be null!

Der Fehler trat in einer internen Javaklasse auf, die nie explizit verwendet werden soll: sun.security.krb5.EncryptionKey. Das allein machte für mich klar, dass es sich um keinen Fehler in unserem Programm handeln konnte, sondern entweder einen im Betriebssystem oder im mitgelieferten Java. Da abzusehen war, dass das Problem durch Apple nicht kurzfristig gelöst werden würde, habe ich mich auf die Suche nach der eigentlichen Ursache gemacht. Am Anfang der Suche standen Beobachtungen:

  • Wenn man ein falsches Passwort eingab, wurde das korrekt als falsch erkannt. Das Problem trat also nur auf, wenn die Authentifizierung eigentlich erfolgreich war.
  • Wenn man bereits ein Kerberos-Ticket hatte, konnte das (nach einer kleinen Programmänderung) verwendet werden, so dass das Passwort gar nicht geprüft werden musste.

Die zweite Erkenntnis hat uns zumindest einen ersten Workaround verschafft, wenngleich der für die Anwender etwas lästig war. Die eigentliche Ursache war hingegen immer noch unklar. Durch die tatkräftige Hilfe eines Forummitglieds auf forums.sun.com bin ich in mehreren Schritten zu weiteren Erkenntnissen gekommen:

  • Die Exception wurde nur durch manche Ciphers verursacht – wie sich später zeigte, sind es die AES-basierten.
  • Unmittelbare Ursache der Exception war ein leeres Salt – dass die AES-Ciphers das nicht mögen, war auf verschiedenen Plattformen reproduzierbar.
  • Nach einer ganzen Weile wurde mir klar, dass die Authentifizierung manchmal klappte.

Das letzte Indiz wies mir den Weg. Wir befragen im Programm zunächst das DNS, welche Server im Active Directory der Uni als KDCs zur Verfügung stehen. Derzeit sind das sechs Stück:

% host -t srv _kerberos._udp.ad.uni-koeln.de
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 ads5.ad.uni-koeln.de.
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 advdc1.ad.uni-koeln.de.
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 rzkvdc1.ad.uni-koeln.de.
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 rzkvdc2.ad.uni-koeln.de.
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 rzkvdc3.ad.uni-koeln.de.
_kerberos._udp.ad.uni-koeln.de has SRV record 0 100 88 ads4.ad.uni-koeln.de.

Da die Authentifizierung manchmal klappte, lag der Verdacht nahe, dass nur manche der Server das Problem provozieren. Also habe ich die Server der Reihe nach fest im Programm verdrahtet. Dabei zeigte sich, dass Authentifizierung nur bei einem der sechs Server möglich war – wohlgemerkt, nur unter Java 6 auf Macs! Auf allen anderen Systemen funktionierten alle sechs Server. Wie ich vom zuständigen Kollegen erfuhr, läuft der funktionierende Server unter Windows Server 2008, die anderen hingegen noch unter Windows Server 2003. Aber in was unterschied sich die Authentifizierung? Mit Wireshark ließ sich beobachten, dass die Antwort des W2K8-Servers einen Unterschied aufwies.

W2K3:
Encryption type: rc4-hmac (23)
Salt:
Encryption type: des-cbc-md5 (3)
Salt: ...

W2K8:
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-md5 (3)
Salt: ...

Hm, ein leeres Salt – war da nicht was? Richtig, das leere Salt produziert eine Exception. Aber wieso wird hier das leere Salt in der Antwort des Servers übernommen, auf anderen Plattformen aber nicht? Die Klasse mit dem relevanten Code gehört zum dem kleinen Teil, der nicht im Source verfügbar ist – mit Ausnahme von OpenJDK. Also habe ich dort nachgesehen. In Zeile 360 beginnt der Code, der das Salt auswertet, das der KDC in seiner Antwort übergibt:

360 // update salt in PrincipalName
361 byte[] newSalt = error.getSalt();
362 if (newSalt != null && newSalt.length > 0) {
363 princ.setSalt(new String(newSalt));
364 }

Im OpenJDK wird also explizit getestet, dass der String eine Länge > 0 hat. Hatte Apple diesen Test etwa entfernt? Ich hätte es bei der Spekulation belassen müssen, wenn ich nicht auf das javap-Kommando hingewiesen worden wäre. Damit kann man Javaklassen disassemblieren. Das funktioniert auch für die Systemklassen. Und da konnte man folgenden Unterschied erkennen:

javap -v sun.security.krb5.Credentials

JDK 5
85: invokevirtual #77 // Method sun/security/krb5/internal/KRBError.getSalt:()[B
88: astore 6
90: aload 6
92: ifnull 114
95: aload 6
97: arraylength
98: ifle 114
101: aload_0
102: new #44 // class java/lang/String
105: dup
106: aload 6
108: invokespecial #78 // Method java/lang/String."":([B)V
111: invokevirtual #79 // Method sun/security/krb5/PrincipalName.setSalt:(Ljava/lang/String;)V

In Zeile 98 wird die Länge getestet. Ist sie 0, springt das Programm zu Zeile 114, also hinter die setSalt()-Anweisung.

JDK 6
85: invokevirtual #81; //Method sun/security/krb5/internal/KRBError.getSalt:()[B
88: ifnull 107
91: aload_0
92: new #51; //class java/lang/String
95: dup
96: aload 5
98: invokevirtual #81; //Method sun/security/krb5/internal/KRBError.getSalt:()[B
101: invokespecial #82; //Method java/lang/String."":([B)V
104: invokevirtual #83; //Method sun/security/krb5/PrincipalName.setSalt:(Ljava/lang/String;)V
107: aload_2
108: ifnull 131
111: aload_2
112: aload_0
113: invokevirtual #84; //Method sun/security/krb5/PrincipalName.getSalt:()Ljava/lang/String;

Hier fehlt der Längentest! Der Vergleich mit einem Windowsrechner zeigte, dass das dortige Java 6 den Test enthielt. Es handelt sich also zweifelsfrei um einen Bug in Apples Javaversion. Nachdem ich all diese Rechercheergebnisse an Apple gemeldet hatte, wurde der Bug dort auch sofort anerkannt. Bis Apple einen Fix rausbringt, könnte allerdings erfahrungsgemäß noch einige Zeit vergehen. Da die Ursache jetzt aber erkannt war, konnte ich einen Workaround implementieren, der ohne Mitwirkung der Anwender funktioniert: wenn die besagte Exception auftritt, wird die Authentifizierung einfach nochmal durchgeführt, dann aber immer gegen den W2K8-Server. Der ist zwar jetzt ein „single point of failure“ für Macs mit Java 6, aber damit können wir leben.

Der Workaround ist nur in der Testversion von UKLAN-Admin enthalten.

Der geschilderte Fall zeigt, wie verzwickt die Fehlersuche sein kann. Der Fehler tritt schließlich nur auf, wenn man

  • einen Mac einsetzt, der Java 6 als präferiertes Java eingestellt hat (d.h. alle Macs mit 10.6, sehr wenige mit 10.5)
  • Kerberos 5 zur Authentifizierung nutzt
  • kein anderweitig bezogenes Kerberos-Ticket besitzt
  • keinen Windows 2008 Server hat (wie es mit anderen KDCs als W2K3 aussieht, weiß ich allerdings nicht)
  • man nicht die Cipherliste in /Library/Preferences/edu.mit.Kerberos durch einen Eintrag für default_tkt_enctypes auf nicht-AES-Ciphers eingeschränkt hat (der Trick klappt allerdings nicht für WebStart-Programme)


Flattr this

Snow Leopard enthält Cisco IPSec VPN

Obwohl Apple angekündigt hatte, dass Snow Leopard keine neuen Features aufweisen würde, hat sich doch so manches getan, allerdings zumeist unter der Oberfläche. Eine dieser etwas versteckten Neuerungen ist integrierte Unterstützung für Ciscos Variante eines IPSec VPNs. Da iPhone und iPod Touch das seit Firmwareversion 2.0 schon konnten, ist die Integration in Snow Leopard keine ganz große Überraschung. Es fällt aber auf, dass im Ggs. zum iPhone bei OS X keine Spur des offiziellen Cisco-Logos zu erkennen ist. Und die Implementierung erfolgt auf Basis von racoon, eines Open Source VPN-Clients aus FreeBSD.

Wir propagieren hier an der Uni zwar mittlerweile vornehmlich die Verwendung des Cisco AnyConnect-Clients, der anstelle von IPSec DTLS verwendet, aber durch die direkte OS-Integration ist Apples Variante mglw. noch einen Tick komfortabler und robuster.

Wer’s probieren möchte, muss entweder im alten „tsunami“-WLAN oder außerhalb des UKLAN sein. Dann öffnet man Systemeinstellungen, dort Netzwerk, klickt auf das + oberhalb des Schlosses, wählt dort als Anschluss VPN, wählt als VPN-Typ Cisco IPSec, und bestätigt die Eingabe. Nun trägt man als Serveradresse vpngate.uni-koeln.de ein, Accountname und Passwort, klickt auf „Identifizierungseinstellungen …“, trägt dort als Gruppenname uklan-full ein, als Schlüssel uklan und klickt auf OK. Dann noch Anwenden und Verbinden, und fertig. Eine ausführlichere Doku mit Screenshots folgt evtl. später.

Mit dem Excel aus Office 2008 mit einem Intel-Mac auf MySQL zugreifen

Heute kam mir zum ersten Mal eine sinnvolle Anwendung für eine ODBC-Anbindung einer MySQL-Datenbank an Microsoft Excel in den Sinn. Zum Glück war meine erste Aktion nach der Idee eine Google-Suche. Dadurch habe ich einen Foreneintrag gefunden, der mir eine Menge Arbeit erspart hat.
Der Hintergrund ist, dass es eine Reihe von Problemen gibt:

  • Obwohl Office 2008 Macs mit Intel-Prozessoren nativ unterstützt, ist das Hilfsprogramm Microsoft Query seit 2002 unverändert und hat nur PowerPC-Code.
  • Der freie ODBC-Connector von MySQL wird nicht als „fat binary“ angeboten, sondern nur wahlweise als ppc- oder x86-Code.
  • Excel 2008 hat eine hartkodierte Liste von unterstützten ODBC-Konnektoren, die nicht den MySQL-Connector enthält.

Wenn man eine schnelle und einfache Lösung für alle genannten Problem will, kann man einen der offiziell von Microsoft unterstützten Konnektoren kaufen. Getestet habe ich nur den von Actual Technologies (siehe unten).

Da es einen freien Konnektor gibt, sehe ich aber nicht ein, warum ich einen kaufen soll. Hier sind die Schritte, um den freien MySQL-Connector benutzen zu können:

  • bei MySQL die Konnektoren für PowerPC und x86 separat runterladen (im „package format“)
  • Achtung: in gemounteter Form heißen beide gleich, so dass man die Architektur nicht mehr erkennen kann. Deshalb sollten die Images jeweils manuell nach Bedarf gemountet werden.
  • Das Image für x86 mounten (Doppelklick) und den Installer für x86 ausführen
  • im Terminal wie folgt aus den Shared Libraries beider Architekturen sog. „fat binaries“ bauen:
  • mkdir ODBC_ppc ODBC_x86 ODBC_fat
  • cd ODBC_x86
  • pax -zrf /Volumes/MySQL Connector ODBC 5.1/MySQL Connector ODBC 5.1.pkg/Contents/Archive.pax.gz
  • x86-Image auswerfen, ppc-Image mounten
  • cd ../ODBC_ppc
  • pax -zrf /Volumes/MySQL Connector ODBC 5.1/MySQL Connector ODBC 5.1.pkg/Contents/Archive.pax.gz
  • cd ..
  • lipo ./ODBC_ppc/usr/local/lib/libmyodbc3S-5.1.5.so ./ODBC_x86/usr/local/lib/libmyodbc3S-5.1.5.so -output ODBC_fat/libmyodbc3S-5.1.5.so -create
  • lipo ./ODBC_ppc/usr/local/lib/libmyodbc3S.so ./ODBC_x86/usr/local/lib/libmyodbc3S.so -output ODBC_fat/libmyodbc3S.so -create
  • lipo ./ODBC_ppc/usr/local/lib/libmyodbc5.so ./ODBC_x86/usr/local/lib/libmyodbc5.so -output ODBC_fat/libmyodbc5.so -create
  • sudo cp ODBC_fat/* /usr/local/lib/
  • An dieser Stelle hat man einen „fetten“ MySQL-Connector, den man mit Dienstprogramme->ODBC-Administrator konfigurieren kann. Ich habe einen Benutzer-DSN hinzugefügt.
  • Da Excel sich noch weigert, wenn man Daten->Externe Daten->Neue Abfrage erstellen auswählt, muss man die Demo-Version von Actual Technologies installieren.
  • Jetzt startet Microsoft Query, wenn man es aus Excel aufruft, und man kann auch den MySQL-Connector benutzen


Flattr this