[Update] Perl – Properties

Posted by shelltux on Februar 19, 2012

Das Perl Properties ist nun über CPAN in Version 1.4 beziehbar.

florent.lartet[--@--]univ-tlse2.fr hat mich auf einen Bug aufmerksam gemacht durch welchen das Modul nicht nur den Namen des Property anhand der Punkte [.] in eine Hashstruktur parsed sondern, sollte der Wert des Property auch Punkte beinhalten, auch den Wert in eine Hashstruktur parsed. Ein entsprechender Testfall wurde der Modul Distribution hinzugefügt.

 

http://search.cpan.org/~shelltux/Properties-1.4/lib/Properties.pm

Categories: Perl
19Feb

tdb-1.0.6 kompiliert nicht

Posted by shelltux on Dezember 27, 2010

Sollte der Versuch, die genannte Version der Trivial Database zu kompilieren, fehlschlagen weil schließende Kommentarzeichen (“) fehlen so kann folgender Patch eingespielt werden: tdbtool.patch

Nachdem ich den Patch erstellt hatte habe ich gesehen dass auf entsprechender Sourceforge Seite bereits ein Patch bereitgestellt wurde, allerdings sehe ich diesen erst wenn ich mich bei Sourceforge anmelde, deshalb hier die Veröffentlichung meines Patches.

Um den Patch einzuspielen sind folgende Schritte durchzuführen:

  • Archiv runterladen und irgendwo im Dateisystem entpacken: tar xzf tdbtool.patch.tar.gz
  • Dann in den tdb Ordner navigieren in welchem sich tdbtool.c befindet: cd PARENT_DIR/tdb-1.0.6
  • Dann den Patch anwenden: patch < OrtAndemDiePatchDateiLiegt

Viel Spaß mit einer funktionierenden Trivial Database.

Markus

Categories: C++,Linux
27Dez

Ralink RT2870 und Linux Kernel 2.6.36.2

Posted by shelltux on Dezember 17, 2010

Da ich ab und an den Drang versprüre im Linux-Kernel-Code rumzuprogrammieren und andauernd vergesse die lauffähige Version als Backup im Bootloader verfügbar zu machen zerstöre ich des öfteren schon mal mein Linux System.
So nun aktuell auch wieder geschehen und dies habe ich direkt zum Anlass genommen den momentan aktuellen Stable-Kernel (Version 2.6.36.2) auf mein System zu bringen.

Wie in einem anderen Artikel bereits geschrieben schließe ich meinen Linux-Server mittels Ralink USB WLAN Device ans weltweite Netz an.
Nun stellt sich beim kompilieren der Treiber-Sourcen mit der beschriebenen Kernelversion das Problem ein, dass Fehler mit den Funktionen usb_buffer_alloc und usb_buffer_free berichtet werden.
Angeblich wären diese beiden Methoden implizit deklariert, was bedeutet dass die Methode benutzt wird aber vorher nicht deklariert (Forward-Declaration) wurde.

Da meine Analyse ergeben hat, dass beide Methoden nicht durch die Ralink Treiber mitgebracht werden sondern im Kernel für die USB Unterstützung enthalten sind, habe ich einmal in /usr/include/usb.h nachgeforscht.
Dort waren diese beiden Methoden allerdings nicht enthalten.
Ein klein wenig recherche hat ergeben, dass sich das USB Interface ein klein wenig geändert hat und die beiden Methoden zwar früher so hießen, nun allerdings in usb_alloc_coherent und usb_free_coherent unbenannt wurden.

Somit was es daran als nächstes herauszufinden wo die Ralink Treiber in ihrem Code diese Funktionen (also die alten) denn nun nutzen.
So wie es sich gehört, wurde ein Ralink spezifisches Funktionsmakro benutzt welches die usb Methoden an zentraler Stelle “ersetzt”.
Diese #define Deklarationen befinden sich im Ralink Code in der Datei include/os/rt_linux.h und sehen so aus:


#define RTUSB_URB_ALLOC_BUFFER(pUsb_Dev, BufSize, pDma_addr) usb_buffer_alloc(pUsb_Dev, BufSize, GFP_ATOMIC, pDma_addr)
#define RTUSB_URB_FREE_BUFFER(pUsb_Dev, BufSize, pTransferBuf, Dma_addr) usb_buffer_free(pUsb_Dev, BufSize, pTransferBuf, Dma_addr)

Um nun den Ralink Code mit dem “neuen” Kernel-USB interface zum Zusammenspiel zu bringen, reicht es aus dort die beiden Methoden zu ersetzen.
Also muss aus oben beschriebenen folgendes gemacht werden:


#define RTUSB_URB_ALLOC_BUFFER(pUsb_Dev, BufSize, pDma_addr) usb_alloc_coherent(pUsb_Dev, BufSize, GFP_ATOMIC, pDma_addr)
#define RTUSB_URB_FREE_BUFFER(pUsb_Dev, BufSize, pTransferBuf, Dma_addr) usb_free_coherent(pUsb_Dev, BufSize, pTransferBuf, Dma_addr)

Nun können die Treiber auch kompiliert werden.

Problem erkannt, Problem gebannt.

Beste Grüße

Markus

Categories: Linux
17Dez

Linux Kernel 2.6.33 und der RT2870 Chipsatz

Posted by shelltux on Mai 25, 2010

In diesem Artikel versuche ich einmal zu erklären wie man ein Wireless Device mit einem Ralink RT2870 Chipsatz zum laufen bekommt.

Folgendes Systemsetup habe ich:

  • Slackware
  • D-LINK Wireless USB Stick mit rt2870 Chipsatz von Ralink
  • Linux Kernel 2.6.33
  • ndiswrapper 1.56

Der angesprochene Kernel bringt zwar einen experimentellen rt2870 Treiber im Source Baum mit, allerdings funktionierte dieser bei mir nicht da der enthaltene rt2870 Treiber keine ndiswrapper Unterstützung bietet und somit wpa_supplicant mit dem Treibertyp ralink nicht funktioniert, was gleichzeitig bedeutet das man sich am AP nur mittels WEP verbinden kann.

Gehen wir nun zum ersten Schritt über und besorgen uns erst einmal alle benötigten tools und die rt2870 Firmware in Version 22.

  • Download der Firmware: hier
  • Download der Treiber Sourcen: hier
  • ndiswrapper: hier

Beim Download der Firmware und der Treiber Sourcen muss man keine E-Mail Adresse angeben. Durch einen Klick auf Accept kann man sich die Pakete auch so runterladen.

Ein Ziel was ich immer versuche bei meinem Linux System zu verfolgen ist es, den Kernel so klein wie möglich zu halten was bedeutet das ich alle unnötigen Treiber und Module rauslasse. Im Kontext der rt2870 Treiber Installation bedeutet das also auf meinem System, dass ich keinen einzigen Wireless Device Treiber einkompiliert habe, weder fest noch als Modul. Und hier bin ich dann beim bauen der ndiswrapper und rt2870 Sourcen auch direkt auf ein Problem gestoßen:

Ein benötigtes Symbol, WEXT_PRIV, war nicht verfügbar somit schlug jedes make fehl.

Ein Umstand der mich ein wenig gewundert hat, da ich dennoch die generische WLAN Unterstützung eingebaut hatte. Nach ein bisschen rumtesterei habe ich dann rausgefunden das ein Workaround für dieses Problem das einbauen eines alten WLAN Treibers ist der dieses Symbol in seiner Kconfig definiert. Zum testen habe ich zum Beispiel den ipw2200 Treiber genommen. Da dies für mich aber nicht akzeptabel ist, habe ich mich dazu entscheiden direkt in die Kconfig in /usr/src/linux/net/wireless einzugreifen und die Symbole beim anwählen der 80211 API verfügbar gemacht.

Das bedeutet nichts anderes als dass ich dem Moment wo die CFG80211 Untersützung einkompiliert wird 3 Symbole verfügbar gemacht werden. Dazu fügt man folgendes in /usr/src/linux/net/wireless/Kconfig ein:

config CFG80211
tristate “cfg80211 – wireless configuration API”
depends on RFKILL || !RFKILL
select WIRELESS_EXT
select WEXT_SPY
select WEXT_PRIV

Die 3 Select Anweisungen sind diejenigen die hinzugefügt werden müssen. Setzt man nun in der Kernel config (.config) CONFIG_CFG80211_WEXT=y so werden die 3 definierten Symbole exportiert. Dann muss der Kernel noch neu gebaut werden und die Sourcen sollten sich kompilieren lassen. Das bauen des Kernels beschreibe ich hier nicht weiter, dazu sollten sich genug Informationen im Netz finden lassen.

Achtung: Durch diese Änderung an der Kconfig von net/wireless hat man keine “Standard”-Sourcen mehr. Dass heißt, will man einmal einen Patch auf den Kernel anwenden, so wird der Versuch schief gehen, da diese 3 Zeilen nicht nativer Bestandteil des Kernels sind.

Die nächsten Schritte sind nun den ndiswrapper sowie den rt2870 Treiber zu kompilieren, dazu bitte einfach die INSTALL oder README Anleitung im jeweiligen entpackten Verzeichnis lesen.

Hat alles geklappt hat man nun einen Kernel ohne unnötige Module, das Tool ndiswrapper sowie ein funktionierndes rt2870sta Modul. Da das gebaute Modul nicht vom Kernel geliefert wurde muss man das Laden des Moduls manuell nachtragen. Dazu erstellt man einfach unter /etc/modules.d eine Datei mit dem Namen rt2870.conf und schreibt einfach rt2870sta rein. Diese Datei mit dieser einen Zeile sorgt dafür dass der Kernel das Modul beim booten lädt.

Das Device sollte ra0 heißen und durch Eingabe von iwconfig sollte es als WLAN fähig angezeigt werden. Nun muss man die Firmware rt2870.bin noch nach /lib/firmware kopieren.

Nun muss man sich noch eine Konfigurationsdatei für den wpa_supplicant erstellen:

  • wpa_passphrase SSID PASSPHRASE > /etc/wpa_supplicant_home.conf

SSID ist Service Set Identifier des WLAN Netzwerkes und PASSPHRASE das Passwort. Dieser Befehl erstellt die Konfigurationsdatei unter/etc mit den Namen wpa_supplicant_home.conf. Man sollte diese Konfigurationsdatei lediglich für Root lesbar machen, da das Plaintext Passwort als Kommentar mit rein geschrieben wird.

Im nächsten Schritt sollte man seinen AP in die Datei /etc/resolv.conf als Nameserver eintragen. Nehmen wir an der AP hat die IP 192.168.100.1 dann muss in /etc/resolv.conf folgendes stehen:

  • nameserver 192.168.100.1

Dann muss das Interface ra0 konfiguriert werden:

  • ifconfig ra0 192.168.100.1 netmask 255.255.255.0

Der Befehl bewirkt dass ra0 aktiv geschaltet wird und die feste IP 192.168.100.1 zugewiesen bekommt. Als nächstes muss der wpa_supplicant gestartet werden:

  • wpa_supplicant -Dralink -c/etc/wpa_supplicant_home.conf -ira0

Der Befehl startet den Supplicant nicht als Daemon sodass Fehler direkt gesehen werden können. -D spezifiziert den Treibertyp, -c gibt die Konfigurationsdatei an und -i erwartet das Interface auf welchem wpa_supplicant angewendet werden soll. Nun muss noch die korrekte Route hinzugefügt werden und dann ist man fertig:

  • route add default gw 192.168.100.1

Um mein WLAN Device direkt beim Booten zu starten und zu konfigurieren habe ich mir ein rc-Skript geschrieben welches unter Slackware in den Ordner /etc/rc.d gespeichert werden muss. Bei mir heißt das Skript rc.startWLAN und hat folgenden Inhalt:

#!/bin/sh

LOGFILE=/var/log/wlan
IP=”192.168.2.2″
NETMASK=”255.255.255.0″
IFACE=”ra0″
GW=”192.168.2.1″
ROUTE=/sbin/route
ECHO=/usr/bin/echo
DATE=/usr/bin/date
IFCONFIG=/sbin/ifconfig
WPA=/usr/sbin/wpa_supplicant
DRIVER=”ralink”
CONF=”/etc/wpa_supplicant_home.conf”

function log() {
STRING=”$1″
LOGTIME=”[`$DATE '+%d.%m.%Y %H:%M:%S'`]”
echo -e “$LOGTIME $STRING” >> $LOGFILE
return 0
}

log “Bringing up interface: $IFACE”
log “    IP: $IP”
log “    Netmask: $NETMASK”
$IFCONFIG $IFACE inet $IP netmask $NETMASK up 2> /dev/null 1> /dev/null
if [ $? -eq 0 ]; then
log “… Success”
else
log “… Error”
exit 1
fi

log “Starting WPA Supplicant”
log “    Driver: $DRIVER”
log “    Config: $CONF”
log “    Interface: $IFACE”
$WPA -B -D $DRIVER -i $IFACE -c $CONF
if [ $? -eq 0 ]; then
log “… Success”
else
log “…Error”
exit 1
fi

sleep 5

log “Setting routing options”
log “    Gateway: $GW”
log “    Netmask: $NETMASK”
$ROUTE add default gw $GW 2> /dev/null 1> /dev/null
if [ $? -eq 0 ]; then
log “…Success”
else
log “…Error”
exit 1
fi
exit 0

Die am Anfang definierten Variablen sind entsprechend anzupassen und dann sollte die Ausführung des Skriptes noch in /etc/rc.d/rc.local eingetragen werden.

Bei Fragen und/oder Anregungen einfach ein Kommentar hinterlassen.

Categories: Linux
25Mai

Going to CPAN

Posted by shelltux on April 28, 2010

Um meine Perlmodule leichter zugänglich zu machen, habe ich mich entschieden von nun an all diese auf CPAN zur Verfügung zu stellen.

Somit gibt es dort nun immer die neusten Versionen, und die Installation gestaltet sich ebenfalls leichter. Den Dokumentationstyp habe ich von Doxygen auf POD umgestellt um der PAUSE Forderung nach zu kommen.

Die neuste Version des Merror Moduls gibt es nun hier.
Wegen eines bereits existenten Options Modules habe ich mein Options Modul nun etwas klarer in Properties umgewandelt und das ist hier erhältlich.

Categories: Linux,Perl
28Apr

ITIM 5.1 Workflowdesigner nicht mehr nutzbar

Posted by shelltux on April 11, 2010

Der Workflowdesigner des IBM Tivoli Identity Manager Version 5.1 ist nach dem Java Update 19 für Version 1.6 nicht mehr Nutzbar.
Versucht man ein Workflow Objekt ins Editorfenster zu ziehen kann man in der Java-Konsole das Auftreten vieler AWT-Exceptions bewundern.

Abhilfe schafft hier erst einmal nur die Deinstallierung des Updates und Nutzung des Updates 18 für Java 1.6.

Categories: IBM
11Apr

log4cxx kompiliert nicht

Posted by shelltux on März 22, 2010

Um eine Vernünftige Logging Umgebung in meinen C++ Programmen zu nutzen wollte ich das log4cxx Paket von Apache installieren. Die Kompilierung schlug jedoch aufgrund fehlender “string.h” includes fehl.

inputstreamreader.cpp:66: error: ‘memmove’ was not declared in this scope
socketoutputstream.cpp:52: error: ‘memcpy’ was not declared in this scope
console.cpp:63: error: ‘strcmp’ was not declared in this scope

Ich konnte 3 Dateien lokalisieren in denen ich dies nachgeholt habe wonach das Paket dann einwandfrei zu kompilieren und installieren war.

Deswegen habe ich auch direkt 2 Patches erstellt die angewandt die nötigen Änderungen durchführen.
Ich bitte zu beachten, dass die Patches nur für die log4cxx Version 0.10.0 anzuwenden sind.

Patchschritte:

  1. Download der Patches: log4cxx Patches_
  2. Im Parentverzeichnis von apache-log4cxx-0.10.0 das Archiv entpacken: tar -xzf log4cxx_patches.tar.gz
  3. Ersten Patch ausführen: patch -p1 -i cppFolder_stringInclude.patch
  4. Zweiten Patch ausführen: patch -p1 -i exampleFolder_stringInclude.patch

Zum besseren Verständis ein etwas ausführlicheres Beispiel:

  1. Im Ordner ‘src’ liegt das log4cxx Archiv
  2. Entpacken: tar xzf src/apache-log4cxx-0.10.0.tar.gz
  3. Im Ordner ‘src’ liegt ebenfalls das log4cxx_patches Archiv
  4. Entpacken: tar xzf src/log4cxx_patches.tar.gz
  5. Dann ins ‘src’ Verzeichnis wechseln: cd src
  6. Dann die patches einspielen: patch -p1 -i cppFolder_stringInclude.patch && patch -p1 -i exampleFolder_stringInclude.patch
  7. Nun sollte die Kompilierung durchlaufen

Für diesen Fehler habe ich im Apache Jira ein Ticket eröffnet: Apache Jira – Log4Cxx

Categories: C++,Sonstiges
22Mrz

Javascript Extension im Tivoli Identity Manager 5.1

Posted by shelltux on März 2, 2010

Um Account-Request/Access oder Operational Workflows im TIM zu erweitern bzw. zu scripten bietet der TIM eine Javascript Engine die bereits so allerhand mitbringt.
Die Javascript Referent ist z.B. hier einsehbar.

Nun stellte sich aber raus, dass möchte man ITIM Gruppen mittels Javascript abfragen, dies nicht so ohne weiteres Möglich ist.
Man kann im ‘account’ Objekt zwar mittels getProperty(“erroles”) sich alle für diese Accountanlage definierten Gruppen zurückgeben lassen, jedoch hat man dann nur den DN und keine weiteren Informationen zu der Gruppe, wie z.B. den Namen.

Da in der JS Engine zwar alles ein DirectoryObject ist, man aber kein tatsächlich DirectoryObject erstellen kann ist es nicht so ohne weiteres Möglich sich die zur Gruppe gehörenden Informationen zu beschaffen.

Abhilfe schafft hier eine Anpassung der Datei ITIM_HOME/data/scriptframework.properties.
Dort existiert ein Abschnitt:
#
# Direct Java Access Configuration
#

In diesem können Java Klassen und Packagenamen angegeben werden die dann gewrapped und der Javascript Engine zur Verfügung gestellt werden.

Die API Dokumentation findet man mitsamt einiger Beispiele übrigens unter ITIM_HOME/extensions/5.1.

Nachforschungen in den Javadocs haben ergeben dass es Klassen für die SystemRollen (ITIM Gruppen) Verarbeitung gibt.
Durch folgende Ergänzung kann man die SysRole Klassen verwenden:

ITIM.java.access.com.ibm.itim.dataservices.model.system=com.ibm.itim.dataservices.model.system.*

Categories: IBM
Tags: , ,
2Mrz

Automatische ITIM Account Provisionierung – ITIM 5.1

Posted by shelltux on Februar 22, 2010

Folgendes Problem stellte sich mir heute:
Ich hatte vor, via statischer Rolle, mittels Provisionierungs Policy automatisiert einen ITIM Account für die User der statischen Rolle anlegen zu lassen.

Zweck dieser Odysee ist es die User in eine bestimmte Gruppe zu kippen die erweiterte Rechte auf einige unserer OrganizationalUnits, was Accountvergaben angeht, hat.
Nun könnte man sich ja denken, dass man in den Entitlements einfach die Gruppe und das Passwort defaultmäßig konfigurieren kann.

Stimmt auch, aber nur halb ;) .

Nachdem man dem Benutzer die Rolle zugewiesen hat und der ITIM Account auch angelegt wurde und aktiv ist, funktioniert der Login mit diesem User am Tivoli Identity Manager nicht.
Etwas Suche und der tatkräftigen Unterstützung eines IBM Kollegen später zeigte sich uns dann auch die Lösung des Problems:

Das Passwort speichert der TIM im LDAP ab, dieser verwendet für Passwortfelder seinen eigenen Hashalgorithmus. Nun ist es aber so, dass der TIM im ebenfalls einen eigenen Hashalgo verwendet um besagtes ITIM Account Passwort zu “verschlüsseln”.
Dies führte nun unweigerlich dazu, dass wenn mein ein Passwort im Entitlement, sagen wir mal “test123″, defaultmäßig setzt, der TIM dafür einen Hash bildet und diesen dann weiter an den LDAP sendet, der nun erkennt, dass es sich hier um ein Passwortfeld handelt und dann einen Hash vom TIM gesendet Hash erstellt.

Bedeutet im Klartext: Meldet der neu angelegte User sich mit dem Hash des defaultmäßig vergebenen Passworts am TIM an funktioniert es ;) .

Die Lösung des ganzen steck im Add-Worklflow des ITIM Service. Hier kann nun ohne weiteres mittels “[Accountvariable (zu finden über Properties)].setAndEncryptPassword(“test123″)” das Passwort korrekt gesetzt werden.

Categories: IBM
Tags: , , ,
22Feb

Propertyfile parsing in Perl

Posted by shelltux on Februar 16, 2010

Options ist eine Perl Klasse welche das parsen hierarchischer Optionsdateien implementiert. Sie implementiert die Möglichkeit eine Properties Datei als ganzes in eine wohldefinierte Struktur zu parsen sowie einzelne Attributewerte zu extrahieren.

Die HTML Dokumentation ist hier ersichtlich.
Die PDF Doku kann hier runtergeladen werden.
Das TAR Paket: Options_1.1

Categories: Perl
Tags: , ,
16Feb