VirtualBox und NAT

VirtualBox ist eine sehr gelungene und plattformübergreifende Virtualisierungslösung. Das einzige, über das ich häufiger stolpere ist die tatsache, dass man in der Netzwerkeinstellung für NAT das dahinter verwendete Subnetz nicht ändern kann. Nicht? Doch! Aber nur mit der Kommandozeile. 🙂

Um ein Subnetz einzustellen, erzeugt man eine virtuelle Maschine wie immer, fährt sie dann herunter, und führt folgenden Befehl aus:

$ VBoxManage modifyvm "" --natnet1 "<Netzadresse/BitMaske>"

Genauer nachlesen kann man das hier:
http://www.virtualbox.org/manual/ch09.html#changenat

PostgreSQL auf dem Mac

Wer (wie ich) nach einer Weile eine gewisse Trägkeit entwickelt, eine aktuelle PostgreSQL immer wieder aus dem Source zu bauen (und man das nachweislich wirklich schon langsam kann), der neigt möglicherweise ebenfalls dazu, einen Installer zu benutzen.

Schöne 1-Click-Installer gibt es von EnterpriseDB, die PostgreSQL schon sehr lange und sehr gut unterstützen.

Wenn man das dann tut, und z.B. den mitgelieferten „pgAdmin“ oder den „Application Stack Builder“ startet, so kann man sich fragen, woher diese Tools noch immer wissen, dass man vor Ewigkeiten vielleicht auch mal ältere Versionen davon installiert hatte (bei mir war es nach der Installation der 9.1 soweit – wo zum Henker steht noch was von 9.0 und 8.4?)

Nach einer wirklich aufreibenden und völlig ergebnislosen Suche in allen üblicherweise verdächtigen Verzeichnissen (Library-Ordner, Cache-Ordnern, Application Support-Ordnern usw.) habe ich zum Schluss in einem Forum den entscheidenden Hinweis gefunden:

Es gibt auf dem Mac eine Datei „/etc/postgres-reg.ini“, in der der Installer jede Version einträgt, die er installiert. Das ist eine ewige Liste. Und alle Tools schauen hier nach, welche Installationen vorhanden sind – ganz unabhängig davon, ob sie überhaupt noch existieren oder schon seit Jahren gelöscht sind 🙂

Hier entfernt man dann einfach alles, was man für überflüssig hält, und die unlöschbaren Server-Verbindungen im pgAdmin gehören der Vergangenheit an.

Die Suche hat ein Ende – Kampf dem Datenmüll 🙂

OpenVAS unter CentOS 5.7

Mit dem Upgrade auf CentOS 5.7 ist die aus den Atomic-Repositories stammende OpenVAS-Umgebung inkompatibel zur installierten Version der glibc. Sie erfüllt zwar die Voraussetzung von OpenVAS (glibc ≥ 2.16), erzeugt aber beim Start von „openvas-administrator“ die Fehlermeldung:

$ Starting openvas-administrator:
openvasad: symbol lookup error: openvasad: undefined symbol:
g_assertion_message_expr

Das Problem findet sich zwar in etlichen Diskussionsforen, aber die einzig bislang erfolgreiche Abhilfe schafft ein Downgrade der Administratorkomponente von OpenVAS:

$ yum downgrade openvas-administrator

Danach kann die Administrator-Komponente wieder ganz normal gestartet werden.

Quelle: http://seclists.org/openvas/2011/q4/543

DMG und ISO – gar nicht so kompliziert

Wenn man zwischen der Linux- und der Mac-Welt pendelt, so kommt es häufiger vor, dass man die beiden Raw-Device-Formate ineinander konvertieren will.

Auf dem Mac funktioniert das soweit eigentlich ganz einfach und sogar mit Bordmitteln, wenn man ein unverkrampftes Verhältnis zur Shell hat. 🙂

Da der Mac beide lesen kann, ist eigentlich nur der eine Weg interessant. Und der funktioniert so:

DMG –> ISO:

$ hdiutil convert /path/to/filename.dmg -format UDTO -o /path/to/output.iso

ISO –> DMG:

$ hdiutil convert /path/to/filename.iso -format UDRW -o /path/to/output.dmg

Wem eine GUI lieber ist, der wählt im Festplattendienstprogramm beim Erstellen eines DMG’s einfach das Ausgabeformat „DVD/CD Master“.

ShrewSoft VPN Client und Ubuntu

Ein sehr verbreiteter Client für IPSec-VPN’s ist sicherlich der Shrew Soft VPN Client (momentan aktuell: 2.1.7). Wer (wie ich) jetzt längere Zeit daran verzweifelt ist, dieses Ding unter Ubuntu (ab 10.x) an’s Laufen zu bekommen, der sei getröstet – es gibt Hoffnung! 🙂

Problem ist, dass augenscheinlich die Errichtung der Tunnel und die Etablierung der SA’s funktioniert, aber trotz korrektem Routing einfach kein Paket durch den Tunnel geht. Wer dann noch ein wenig mit tcpdump spielt, der wird schnell feststellen, dass die Pakete zwar in den Tunnel hinein, aber aus dem darunterliegenden Default-Interface wieder herauskommen. Das kann dann also nicht funktionieren. „ShrewSoft VPN Client und Ubuntu“ weiterlesen

MySQLdb unter Mac OS X „Snow Leopard“

Wenn man unter Mac OS X MySQLdb bauen will, und einen Intel-Mac mit Snow Leopard zusammen mit XCode 4 betreibt, muss man einige Hürden umschiffen.

1.    Man muss darauf achten, dass Python und MySQL in der gleichen Architektur vorliegen (entweder i386 oder x86_64)
2.    MySQL-python herunterladen und auspacken (http://pypi.python.org/pypi/MySQL-python/)
3.    Im Default ist das Compile-Target von XCode 10.3. Das funktioniert nicht!
⁃    export ARCHFLAGS=‘-arch x86_64′
⁃    export MACOSX_DEPLOYMENT_TARGET=10.6
4.    Jetzt kann man, wie üblich, mit python setup.py build und python setup.py install das Paket MySQLdb bauen (siehe README).

Allerdings funktioniert es noch nicht, wenn man versucht, das Modul zu importieren, so wird man mit folgender Fehlermeldung belohnt:

„MySQLdb unter Mac OS X „Snow Leopard““ weiterlesen

Back to the roots…

Manchmal ist es schön, wenn man altes Wissen noch mal brauchen kann. In Zeiten, wo die meisten Leute ausser „Java“ und „C#“ nichts mehr kennen (und daher damit auch alles machen, sogar ein „Hello, World!“ 🙂 ), ist es doch schön, wenn man mit einem ausgefuchsten Shellcript (mit getopts, vielen eckigen Klammern, Inline-Evaluation usw.) in einem Bruchteil der Zeit das gleiche erledigen kann. Als netten Nebeneffekt erntet man noch verblüffte Gesichter 🙂

php entfesselt!

Beim Googeln bin ich eindeutig gut. Es gibt eine Alternative zum eAccelerator, die aber merkwürdigerweise kaum ins Auge springt – den Alternative PHP Cache APC. Im Gegensatz zu eAccelerator wird dieser noch aktiv entwickelt und wahrscheinlich in die Core-Distribution von PHP6 einfließen. Klingt besser als die Zukunft von eA. Erste Benchmarks, u.A. auf diese Seite, zeigen: Er ist sogar noch schneller als der eA.

PHP entfesselt?

Nachdem sich die erste Begeisterung ein wenig gelegt hat, stellt es sich heraus, dass es mit dem eAccelerator doch die ein oder andere Hakeligkeit gibt – wirklich stabil läuft er unter RHEL6 mit php5.3 nicht – er neigt dazu, den Apache zu unangenehmen child-SegVaults zu veranlassen. Scheint ein Problem mit dem Shm zu sein – Lösung steht noch aus.