Eigentlich hatte ich ja schon Anfang des Jahres vor, mir KDE 4 anzusehen.

Nur irgendwie motiviert es nicht wirklich, ein halbfertiges System zu installieren.

Jetzt ist jedoch die erste Beta von KDE 4.1 veröffentlicht. Schon vollständiger als die Vorversion.

Ich sitze die Beta-Phase jetzt noch die zwei Monate aus, im Juli soll die finale Version dann erscheinen. Und dann bekommt KDE evtl. noch einmal eine Chance, als Gnome-Alternative auf meinem Desktop Platz zu finden.

So langsam wird es grotesk.

Energiekonzerne, Krankenkassen oder Banken (um nur ein paar der großen Absahner zu nennen) verdienen sich dumm und dusselig und Vater Staat schraubt sich mehr Steuern rein, als die Volksvertreter selbst erwartet hätten.

Zeitgleich kämpfen verschiedenste Gewerkschaften mit ausufernden Streiks darum, dass die arbeitende Bevölkerung zumindest mit einer an die Teuerungsrate des Landes angepasste Beteiligung am aktuell spürbaren Wirtschaftsaufschwung teilhaben darf.

Familien werden finanziell immer härter drangsaliert, dabei wird offen, auch aus Reihen der Politik davor gewarnt, dass immer mehr Bürger (auch aus der Mittelschicht) an den Rand der Armutsgrenze abrutschen.

Steuererleichterungen oder Zuwendungen aus dem Staatssäckel an die Bürger werden durch Minister Steinbrück kategorisch abgelehnt, die Sanierung des Staatshaushaltes habe Vorrang.

Zumindest wird werbewirksam, wir sind ja in Zeiten des Wahlkampfes, über eine Erhöhung der Renten diskutiert.

Und da wollen sich die Abgeordneten in Berlin mal eben klammheimlich eine 15-prozentige Diätenerhöhung bis 2010 zuschanzen.

In Politikerkreisen werden Diäten “Abgeordneten-Entschädigung” genannt, ich frage mich, wofür wollen die denn entschädigt werden.

Und nachdem nun vorerst hektisch zurückgerudert wurde, was soll das Thema auch im Wahlkampf, werden direkt Kommentare von Seiten der CDU laut, frei formuliert hört sich das dann so an:

“Die Leute meinen noch, wir wären gierig, wenn wir unsere Diäten erst um 15% erhöhen wollen, diese Entscheidung dann aber zurücknehmen können.”

Also wird das Thema auf später verschoben, wenn auch für den Bürger unangenehme Entscheidungen durchgedrückt werden können, nämlich kurz nach den Wahlen.

Und dabei sollte man nicht davon ausgehen, dass keine Anpassung der Abgeordnetenbezüge vorgenommen würden. 2008 waren das 4,7%, Anfang 2009 kommen noch einmal knapp 4,5% obendrauf. Das macht weit über 7000 Euro monatlich im Portemonnaie eines jeden Abgeordneten.

Dazu passend auch die Reaktionen von Politikern zu einer Umfrage der Zeitschrift “Capital”. Die wollten sowohl von Wirtschaftsbossen, als auch von den Spitzenpolitikern in Deutschland wissen, was diese denn so an Steuern abdrücken.

Aus der Wirtschaft kamen, trotz der z.Zt. sowieso schon schwierigen Fahrwasser zur Frage der Gehaltsklassen in den Chefetagen, auch Antworten.

Die Manger von Konzernen wie Adidas gaben bereitwillig Auskunft und nannten Zahlen, bei denen Ottonormalverbraucher schwindelig wird.

Volksvertreter wie Frau Merkel jedoch, oder auch Herr Schäuble verweigerten die Aussage. Das macht nachdenklich. Sehr nachdenklich. Die Begründung von Herrn Schäuble hierzu möchte ich garnicht erst nennen, denn das würde wieder einen dunklen Schatten über die ansonsten so offen zur Schau gestellte Datensammelleidenschaft des Ministers werfen.

Da bewahrheitet sich auf jeden Fall wieder:
Diäten, bei denen man selbst bestimmen darf, wieviel es zu essen gibt, funktionieren einfach nicht.

(gesehen auf aptgetupdate.de)

Gerade auf [pimp my shell] gefunden:

sprunge.us ermöglicht es, direkt aus der Shell einen Beitrag auf dem “nopaste-Service” zu posten, sprunge.us liefert die URL zurück auf die Shell.

Auf sprunge.us steht, wie es geht.

Ich habe mir das ganze noch ein wenig vereinfacht und ~/bin/nopaste mit folgendem Inhalt angelegt:
#!/bin/bash
curl -F 'sprunge=< -' http://sprunge.us

Jetzt kann ich simpel mit
$ echo foobar | nopaste
“nicht einfügen”.

Sehr praktisch.

Mittlerweile habe ich endlich alle Debian-Systeme patchen können, das Beheben der openssh-Sicherheitslücke war mit
# aptitude update && aptitude dist-upgrade
und dem Erzeugen ein paar neuer Schlüssel und Zertifikate wirklich kein Hexenwerk.

Aber beinahe hätte ich mir trotzdem ein Eigentor geschossen. Denn neben den aktuellen openssh-Paketen rutschte auf einem Webserver auch ein Kernel-Update mit auf die Platte, das einen Neustart erforderte. Ich war schon fast beim “init 6″, als mir einfiel, dass ich doch besser nochmal versuchen sollte, eine ssh-Verbindung zum Server aufzubauen.

Und flups, da hieß es direkt:

Permission denied (publickey).

und im auth.log des Servers tauchte die Meldung:

May 17 10:37:43 localhost sshd[21441]: Public key b1:5f:68:94:45:0e:fb:4a:9e:1e:19:b3:cb:6f:2a:b3 blacklisted (see ssh-vulnkey(1))

Mir war zwar bekannt, dass das Upgrade das Paket openssh-blacklist mit auf das System gebracht hatte, dass aber eine Verbindung mit dem eigenen, noch verwundbaren Schlüssel direkt unterbunden wurde, hat mich dann doch überrascht.

ssh-keygen hat’s gerichtet, der Server bootet gerade neu.

Und die Moral von der Geschicht’: vergiss den eig’nen Client nicht

Heute morgen per Mail:

Wiedereinmal macht eine Sicherheitslücke Schlagzeilen (hier oder hier oder natürlich hier).

Diesmal ist OpenSSL in Debian betroffen, die mit den bisher ausgelieferten Versionen des Paketes seit 0.9.8c-1 generierten Schlüssel sind vorhersagbar.

Es ist dringend empfohlen, alle Systeme mit dem nun zur Verfügung stehenden Sicherheits-Update auszustatten, sowie alle betroffenen Schlüssel (SSH, OpenSSL, …) und x509-Zertifikate zu erneuern.

Hurra.

Zu lesen auch auf:

oder

unixODBC macht mich echt fertig.

Nachdem ich die ODBC-Verbindung zu meiner Oracle-Datenbank scheinbar erfolgreich eingerichtet hatte, funktionierten die meisten DB-Funktionen mit dem danach installieren SquirreL SQL Client nicht.

Dauernd flog die Verbindung zum DBMS mit der Fehlermeldung: “[unixODBC][Driver Manager]Driver does not support this function” ab.

Ich schob den Fehler dem JDBC-Teil der Java-Anwendung zu (v.a. wg. der Meldung “Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.” und dem Umstand, dass der Fehler in einer testweise angelegten OOO-Base-Datenbank nicht auftrat), und richtete für das Programm dann die Verbindung über den “Oracle OCI Driver” ein. Das funktionierte auch einwandfrei.

Als ich jedoch gerade anfing, eine QT-Anwendung zu erstellen, die auch über ODBC an meine Oracle-Instanz andocken sollte, rieselte es wieder die “Driver does not support..”-Fehler.

Der Connect funktionierte, die Abfragen blieben allesamt hängen.

Und weil in der OSS-Version von QT keinen OCI-Treiber gibt, musste ich mich nun zwangsläufig mit dem Fehler auseinandersetzen.

Ein Trace der unixODBC-Verbindung ergab folgende Log-Einträge:

[ODBC][25990][SQLSetStmtAttr.c][243]
Entry:
Statement = 0×811f6d0
Attribute = SQL_ATTR_CURSOR_TYPE
Value = 0×3
StrLen = -5
[ODBC][25990][SQLSetStmtAttr.c][356]Error: IM001
[ODBC][25990][SQLGetDiagRec.c][710]
Entry:
Statement = 0×811f6d0
Rec Number = 1
SQLState = 0xbf916856
Native = 0xbf916860
Message Text = 0xbf916867
Buffer Length = 512
Text Len Ptr = 0xbf916864
[ODBC][25990][SQLGetDiagRec.c][747]
Exit:[SQL_SUCCESS]
SQLState = IM001
Native = 0xbf916860 -> 0
Message Text = [[unixODBC][Driver Manager]Driver does not support this function]

Endlich hatte ich Futter fuer meinen Freund Scroogle. Gleich im ersten Link des Suchergebnisses fand ich eine vermeintliche Lösung: die “aktuelle” Version 2.2.12 von unixODBC – immerhin auch schon fast zwei Jahre veröffentlicht – sollte meine Verbindungsprobleme lösen.

Ein Debian-Paket dafür war nirgendwo in Sicht, also musste ich wohl selber den Compiler anschmeißen.

Blöd dabei wieder:

Vom noch installierten unixodbc ist das immer noch für die Eclipse-Umgebungen für Aptana und QT benötigte Java-Runtime-Environment abhängig. Ich entschied mich vorerst gegen die Deinstallation und für eine Parallelinstallation der Version 2.2.12 nach /opt.

Nach dem Übersetzen und der Installation der Software trug ich, schnell und schmutzig /opt/unixodbc/lib als erste Zeile in die ld.so.conf ein und erneuerte den Cache.

Und siehe da: meine QT-Anbindung schmeißt keine Fehler mehr.

Dann werde ich das JRE wohl auch händisch installieren und die Ubuntu-Pakete von unixodbc und JRE vom System verbannen.

Marc hatte unter meinem letzten Blogeintrag (Oracle-ODBC-Zugriff für Debian und Ubuntu) das Datenbanktool “SQuirreL SQL” empfohlen.

Die Featurebeschreibung liest sich gut, also ging’s gerade direkt in die Testphase.

Das Programm ist in Java programmiert, ist somit weitestgehend Betriebssystem-unabhängig einsetzbar, und dank JDBC-Schnittstelle sind auch alle Datenbanken ansprechbar, für die ein entsprechender Treiber existiert.

Bei mir kommt naturgemäß nur ein Debian-Derivat als Basis in Frage, in diesem Fall musste Ubuntu 8.04 (Hardy Heron) dran glauben.

Die Installation ist schnell über

$ java -jar squirrel-sql-2.6.5a-install.jar

erledigt, beim anschließenden Aufruf von squirrel-sql.sh startet der Client auch schon.

Da ich auf meinem System bereits ein ODBC-DSN zu meiner Oracle-Datenbank eingerichtet hatte, und der entsprechende Treiber als einziger in SQuirreL SQL schon zur Verfügung stand, versuchte ich zunächst, die “JDBC-ODBC-Bridge” als Verbindungselement zu benutzen.

Als URL für den Datenbank-Alias TEST trug ich “jdbc:odbc:test” ein, der mit dieser Einstellung durchgeführte Verbindungsversuch zur Oracle-Testinstanz wurde positiv beschieden.

Ich konnte auch eine Sitzung mit dieser Konfiguration aufrufen. SQuirreL lud alle Schemes, Tables und weiteren Bestandteile der DB-Instanz und öffnete das Sitzungsfenster. Doch alle weiteren Versuche, auf der Datenbank zu arbeiten, wurden mit Fehlern, wie:

Error: [unixODBC][Driver Manager]Driver does not support this function

TEST: [unixODBC][Driver Manager]Connnection does not exist

oder

Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.
Das Eigenschaftenregister konnte nicht geladen werden.

quittiert.

Und weil ich nicht wirklich ein Faible für Java habe, und mich mit den Exceptions nicht weiter auseinandersetzen wollte, entschied ich mich für die sowieso sinnvollere Alternative, den “Oracle OCI-Treiber” einzurichten.

Und so funktioniert’s:

Download der Dateien

von oracle.com.

Die entpackten Dateien habe ich nach nach “~/SQuirreL SQL Client/lib/oracle/” geschoben.

Das Startscript squirrel-sql.sh benötigt eine kleine Erweiterung:

# Squirrel home
SQUIRREL_SQL_HOME=’/home/stefan/SQuirreL SQL Client’

# stpe – Patch starts here
LD_LIBRARY_PATH=$SQUIRREL_SQL_HOME/lib/oracle:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

Die Bibliotheken aus der existierenden Oracle-XE-Client-Installation funktionierten mit den eben heruntergeladenen Jar-Dateien übrigens nicht, da diese in Version 10.2.0.3 vorliegen, das Debian-Paket des XE-Clients aber nur in 10.2.0.1 zu haben ist. Benutzt man die “alten” Libraries, stürzt Squirrel SQL reproduzierbar mit Fehlermeldungen, wie:

# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0×9e875776, pid=8838, tid=2677013392
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b22 mixed mode linux-x86)
# Problematic frame:
# C [libclntsh.so.10.1+0x327776]

ab.

In der Treiberkonfiguration des Datenbank-Tools trug ich die heruntergeladenen Jar-Dateien als alternativen “Class Path” ein:

Jetzt war der Treiber benutzbar, die damit angelegte Verbindung “jdbc:oracle:oci8:@ora_tst:1529/test” funktionierte fehlerfrei:


Vielen Dank von dieser Stelle aus nochmal an Marc, ich werde das Tool bei den nächsten Arbeiten am DBMS auf jeden Fall intensiver unter die Lupe nehmen.

An meinem Lenny-Arbeitsplatz benutze ich sqlplus aus dem “Oracle Database 10g Express Client“, um Abfragen auf unseren Oracle-Datenbanken (9i) durchzuführen.

Bei der Einrichtung hatte ich seinerzeit viel zu basteln, deswegen freute ich mich nicht richtig auf die Aufgabe, auf einem Ubuntu-Client den Zugriff auf die Oracle-DB via UnixODBC einzurichten, um dort ein kleines Auswertungs-Tool programmieren zu können.

Aber es war garnicht so schlimm

Grundlage für die Installation war ein aktuelles Ubuntu 8.04 (Hardy Heron). Nach der Installation des o.g. Express Client von Oracle aus dem auf der dortigen Webseite angebotenen Debian-Paket, tauchte im Anwendungsmenü sofort ein Link zu SQL*Plus auf.

Nach dem Aufruf des Programms war über:
connect user/passwort@server:port/sid
die Verbindung sofort aufgebaut.

Herrlich

Jetzt zur Zitterpartie ODBC – die sich im Übrigen als nicht wirklich kompliziert herausstellte, wenn man denn fertige Ini-Dateien als Muster hat …

Als Grundlage werden eigentlich nur die Pakete unixodbc und unixodbc-bin benötigt.

Das zugehörige Tool ODBCConfig stellte sich dann jedoch quer, als es um die Anlage von Treiber und DSN ging und stellte wiederholt mit der Meldung:

ODBCConfig: ltdl.c:3104: try_dlopen: Assertion `filename && *filename’ failed.
Aborted

seinen Dienst ein.

Aber zum Glück lassen sich die Konfigurationsdateien auch händisch pflegen.

Dabei sollte die /etc/odbcinst.ini so aussehen:
[Oracle10g]
Description = Oracle 10g ODBC Driver
Driver = /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libsqora.so.10.1
Driver64 =
Setup =
Setup64 =
UsageCount = 1
CPTimeout =
CPReuse =

Auf diese Weise ist der Oracle-Treiber schon einmal verfügbar.

Jetzt zur DSN, die sich entweder als System-DSN unter /etc/odbc.ini befindet, oder unter selbigem Namen als User-DSN im eigenen Homeverzeichnis Platz findet:
[TEST]
Application Attributes = T
Attributes = W
BatchAutocommitMode = IfAllSuccessful
BindAsFLOAT = F
CloseCursor = F
DisableDPM = F
DisableMTS = T
Driver = Oracle10g
DSN = TEST
EXECSchemaOpt =
EXECSyntax = T
Failover = T
FailoverDelay = 10
FailoverRetryCount = 10
FetchBufferSize = 64000
ForceWCHAR = F
Lobs = T
Longs = T
MetadataIdDefault = F
QueryTimeout = T
ResultSets = T
ServerName = ora_tst:1529/test
SQLGetData extensions = F
Translation DLL =
Translation Option = 0
DisableRULEHint = T
UserID = testuser
StatementCache=F
CacheBufferSize=20

Und nachdem man “/usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/” in seine ld.so.conf aufgenommen, und den Cache mit ldconfig erneuert hat, steht einer Oracle-Verbindung über ODBC (beispielsweise mit dem DataManagerII) nichts mehr im Wege:

Bleibt mir nun “nur” noch die Programmiererei.