Autor: Joerg

  • Umzug die zweite

    Soooo…..

    lange nichts mehr geschrieben. Es wird mal wieder Zeit fuer einen neuen Post. Was gibt es neues ? (In Kurzform)

    • Selbsstaendigkeit an den Nagel gehaengt
    • Ein neuer, sehr interessanter, Job in der Bundesstadt Bonn am grossen Fluss 🙂
    • Umgezogen nach Koenigswinter (weg aus dem Schauerland)
    • Neuer Focus auf Security und Oracle (Es wird mehr zum Thema demnaechst hier geben)
    • Einmalige Fotomotive (Landschaftstechnisch) entdeckt – Ja! Futter fuer meinen fast verwaisten Flickr-Account

    So, stay Tuned – verspreche mich zukuenftig wieder mehr ums Bloggen zu kuemmern

  • Suspekte Referrers

    Wer soetwas in seinen Access Logs als Refrerrer sieht kann sich wundern, muss er aber nicht 🙂


    http://127.0.0.1:4664/preview?event...

    Der Referrer kommt naemlich von der Google-Desktop Suche. Also: Wieder schlauer geworden 🙂

  • Mails aus der Postfix Queue entfernen

    Man kennt das. Gerade frisch einen Postfix aufgesetzt, eine Testmail losgelassen und Zaaack! – das Ding will nicht rausgehen. Jetzt dümpelt die Mail bis zum Timeout in der Queue herum. Abhilfe habe ich früher geschaffen in dem ich mir via mailq die Mail-ID herausgekramt habe und dann mühsam durch die spool Directories gegangen bin um ein File nach dem anderen zu löschen. Es geht eleganter:

    mailq aufrufen um die Mail-ID zu bekommen

    und anschliessend nur noch „postsuper -d <mail-id>“ aufrufen um die Mail zu töten. Fertig….

    Ja, die meisten werden es kennen. Nur so vergesse ICH das garantiert nicht mehr 🙂

  • UTF8 Ausgabe aus Perl heraus erzwingen

    Probleme bei der Ausgabe von Texten in UTF8 unter Perl ? So für Schnittstellen, und ähnliches ?

    Kein Problem:

    Nach öffnen des Ausgabestreams (File, oder ähnliches) einfach ein simples binmode FILEHANDLE,":utf8"; implementieren, und schon klappt es mit dem Charset. Wieso das auf einigen Systemen (z.B. Solaris) auch ohne Binmode geht (das setzen der Environment-Variable „LANG“ auf de_DE.UTF half hier), weiss ich nicht. Aber so funktioniert es in jedem Falle !

  • Mobile.Me und die Sync Problem(chen)

    Mobile.Me ist ja irgendwie fein. Allerdings haben sich meine Macs strikt geweigert, auch nur im Ansatz die korrekten Inhalte des Kalenders zu synchronisieren. Nun woran lag es ?

    Kurz und bündig: Die „SyncData“ ist quasi „out of Sync“. Soll heissen: Der Mac weiss nicht (mehr) was er synchronisieren soll, und was nicht.

    Auf einschlägigen Seiten (z.B. der KB von Apple) wird ein hierzu Reset der Sync Data empfohlen. Allerdings ist diese in den Systemeinstellungen für Mobile.Me nur halbherzig implementiert. Ein Blick ins /var/log/system.log bringt folgende Meldungen zu Tage:


    Sep 16 19:03:11 powermac iCalExternalSync[822]: SyncServices precondition failure in [ISyncConcreteSession clientAcceptedChangesForRecordWithIdentifier:formatted-
    Record:newRecordIdentifier:]: you can't change the record identifier from BLUBB-DIWUPP-HEXKEY-WIEBEI-WINDOOFS to com.apple.ical.calendars.RootNode: it is already associated with a different record.

    Dem Mac das abzugewöhnen war garnicht so einfach (Naja, der Weg dahin war steinig, der Rest ist leicht 🙂 Fangen wir also an:

    1. iCal, iTunes, Addressbook etc. schliessen
    2. Unter ~/Library/Calendars selbiges Directory löschen (Die vorsichtigen unter euch dürfen es gern Backuppen)
    3. iSync starten und unter Einstellungen die Synchronisierung DEAKTIVIEREN
    4. Mobile.Me Account komplett unter den Systemeinstellungen DEAKTIVIEREN (Also „Abmelden“ !!)
    5. Unter ~/Library/Application Support/Sync Services/ das Directory „clientdata“ löschen
    6. In iSync sicherheitshalber nochmal auf „iSync-Verlauf zurücksetzen“ clicken.
    7. Mobile.Me wieder aktivieren und syncen
    8. Fertig !

    War der einzigste Weg bei mir, der ganze 3 Rechner wiederbelebt hat. Alle anderen „Tricks“ aus irgendwelchen Apple-Foren haben garnichts gebracht. Die „Magic“ steckt einzig und allein in Punkt 5 und 6 oben. Ich nehme an dass „iSync-Verlauf zurücksetzen“ genau das tun sollte, was ich in Punkt 5 beschreibe. Macht es aber leider nicht. Naja, mit der Anleitung oben wird man dann auch glücklicher Mobile.Me Nutzer 😉

    Viel Spass

  • Update von DBD::Oracle und das disconnect Verhalten bei mod_perl

    Ein Update des DBD::Oracle Treibers von 1.16 auf 1.21 klingt zunaechst unspektakulaer. Aber wie so oft steckt der Teufel im Detail. Benutzt man nämlich persistente Verbindungen unter mod_perl mit dem Modul Apache::DBI, ändert sich das Verhalten beim disconnecten von der DB. In der Regel cached das mod_perl die Verbindungen ja, daran hat sich auch nichts geaendert.

    Bei der 1.16er Version jedoch impliziert das disconnect ein commit. Das hängt laut Modul-Doku von gutdünken des (Modul-)Entwicklers ab. Hat man seine Applikation jetzt darauf ausgerichtet, dann macht man nie ein Commit (sollte man nicht tun !). Dumm nur, dass dieses Verhalten bei der 1.21er geändert wurde. Nun impliziert das Modul beim disconnecten nämlich ein Rollback. Und das macht es selbst dann, wenn ein commit vorrausgeht.

    Im ersten Ansatz ist das verschmerzbar. Wenn die DB allerdings, selbst bei Skripten die nur SELECTen, jedesmal mit einem Rollback belaestigt wird, kommt da schon einiges zusammen. Das Verhalten lässt sich mit folgendem „Workaround“ aendern:

    Aus einem $dbh->disconnect() wird ab sofort ein

    $dbh->{AutoCommit}=1;
    $dbh->disconnect();

    Das AutoCommit wird also kurz vorm disconnecten gesetzt, und beeinflusst das sonstige Rollback/Commit-Verhalten im gesamten Skript ueberhaupt nicht. Sobald ein neues Connect (auch in einer persistenten mod_perl Umgebung) kommt, werden (auch bei gecachter DB-Verbindung) die Parameter AutoCommit, etc., eh neu gesetzt. Damit verhält sich alles wieder wie vorher.

  • Aggregationen mit anderen Zeitwerten als to_date

    Schon mal versucht einen Aggregations-SQL nach anderen Werten als den Format-Strings die mit to_date, to_char benutzt werden duerfen zu bauen ?

    Ist garnicht so simpel. Ein

    select count(*),attribut,to_char(creationdate,'DD.MM.YYYY')
     from tabelle
     group by attribut,trunc(creationdate,'DD.MM.YYYY')

    ist noch fuer jedermann verstaendlich. Auch wenn man nach Stunden gruppieren will, geht das noch schmerzfrei (‚HH‘). Was aber wenn man auf 15Minuten Ebene Aggregieren soll ? Ohne Kunstgriff geht es nicht. Hier der to_date String:

     to_date(to_char(sysdate,'DD.MM.YYYY') ||
             ' ' ||
             trunc(to_number(to_char(sysdate,'SSSSS'))/900)*900,
             'DD.MM.YYYY SSSSS')

    Was passiert hier ?

    Zunächst wird die aktuelle Zeit (im Select ist es natuerlich das zu gruppierende Feld) in Sekunden nach Mitternacht umgewandelt. Nun dividieren wir das Ergebniss durch 900 (15 Minuten = 900 Sekunden) und schnibbeln die Nachkommastellen ab. Anschliessend das ganze wieder mit 900 Multiplizieren, und wir haben jede Erdenkliche Uhrzeit auf die letzte Viertelstunde (ab-)gerundet. (Schlaue Menschen koennten jetzt sagen, Mensch Joerch, nimm doch DIV, MOD gibts unter Oracle schliesslich auch -> DIV gibts leider NICHT). So, jetzt packen wir noch das Datum wieder davor (ist ja durch die Umwandlung in Sek. nach Mitternacht verloren gegangen) und konvertieren das ganze wieder in ein Datum. Fertig ist der Viertelstundenaggregator 🙂 Bezogen auf das obige Beispiel lautet unserer (zugegebenermassen unlesbarerer Spruch) wie folgt:

    
    select count(*),attribut,
     to_date(to_char(creationdate,'DD.MM.YYYY') ||
             ' ' ||
             trunc(to_number(to_char(creationdate,'SSSSS'))/900)*900,
             'DD.MM.YYYY SSSSS')
     from tabelle
     group by attribut,
     to_date(to_char(creationdate,'DD.MM.YYYY') ||
             ' ' ||
             trunc(to_number(to_char(creationdate,'SSSSS'))/900)*900,
             'DD.MM.YYYY SSSSS')
    
  • Disablen von ipv6 unter Debian

    Folgendes Problem:
    Irgendein Daemon moechte einen Listener aufbauen und grabscht sich anstelle des IPv4 Sockets ein IPv6 Socket. Dummerweise kann man das dem Daemon nicht abgewoehnen, da dieser kein config-File oder Closed-Source ist. Abhilfe schafft das disablen des kompletten ipv6 Stacks. Wie das geht ?

    Einfach in der /etc/modprobe.d/aliases folgende Zeile abaendern (die obere Zeile ist das original):

    #alias net-pf-10 ipv6
    alias net-pf-10 off

    Danach rebooten (ohne geht leider beim 2.6er Kernel nicht) und gut ist.

  • Forgotten AT

    Oft gesehen, nie benutzt. Zu der Kategorie gehoert wohl das kleine aber feine Tool „at“. Quasi ein „Wegwerf“-CRON. Dabei ist das Ding totsimpel zu bedienen, und dazu noch extremst nützlich. Wie es funktioniert ? Folgendermassen:

    Angenommen ich muss dringend noch ein paar Files per scp kopieren, kann das aber erst machen, wenn kein Betrieb mehr auf dem Produktionssystem herrscht. Erschwerend kommt jetzt noch hinzu dass, sagen wir, der Betrieb erst gegen 23:00 beendet ist. Ein klassischer Fall für at:

    at 23:00 [CR] (danach befinden wir uns im Commandmode)
    scp Datei user@system:/directory [CR]
    [CTRL+D]

    Nun lediglich den Rechner auf dem das Kommando abgesetzt wurde anlassen (oder noch besser: Auf einem Remotesystem ausführen und anschliessend ausloggen) und ab gehts um 23:00 🙂

    Eine Besonderheit für Mac-User gibt es noch. Der Dienst der die at-jobs (Eine Liste derer gibts übrigens via „atq“) startet, ist defaultmässig nicht gestartet. Das kann man via:

    sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

    nachholen.

    Viel Spass beim „at“ten …

  • CGI::Ajax Versionsproblem(chen)

    Wer sich mit folgender Fehlermeldung bei der Benutzung von CGI::Ajax unter Perl herumquaelen muss, dem sei ein Downgrade auf die Version CGI-Ajax-0.697 ans Herz gelegt. Damit ist die Fehlermeldung naemlich dann Geschichte:

    Undefined subroutine CGI=HASH(0xBLABLABLA)::header_type at CGI::Ajax line xxxx

  • DNS mit dem Mac

    Mit bind geht das schon lange. Man hat 2 Netze, mit jeweils zwei unterschiedlichen Nameservern die die privaten Adressen im jeweiligen LAN auflösen. Will man jetzt, z.B. via VPN beide Nameserver aus den jeweiligen LANs nutzen, so konfiguriert man den bind für die jeweiligen Netze als forwarder (Jeweils für das Netz mit seinem Nameserver einen Eintrag). Ein Beispiel:

    Gegeben seien ein LAN mit der Domäne Intranet1.de und dem Nameserver 192.168.0.222, und das LAN mit der Domain intranet2.de welches seinen DNS auf 10.0.0.222 liegen hat. Natürlich gibts noch einen öffentlichen Nameserver, der hat in unserem Beispiel die 212.121.212.111 als IP.

    In der named.conf sieht das dann so aus:

    options {
    directory „/var/named“;
    forwarders { 212.121.212.111;};
    };

    zone „intranet1.de“ in {
    type forward;
    forwarders {192.168.0.222; };
    forward only;
    };

    zone „intranet2.de“ in {
    type forward;
    forwarders {10.0.0.222; };
    forward only;
    };

    Beim Mac ist das viel simpler. Man lege ein Directory /etc/resolver an und lege dort einfach pro Zone ein File ab. In diesem Beispiel wäre das dann /etc/resolver/intranet1.de mit dem Inhalt „nameserver 192.168.0.222“ und eine zweite Datei mit /etc/resolver/intranet2.de mit Inhalt „nameserver 10.0.0.222“. Fertig. Dumm nur das das ganze nicht persistent ist. Nach dem Neustart ist alles weg. Nicht so wenn man sich die Dateien per Shellscript aus der /etc/rc.common erstellen lässt. Funktioniert prima und ist simpel.

  • Setzen der Hardware Clock unter Linux

    Als merker (einer der klamotten, die man immer wieder nachschlagen muss).

    Will man die Hardware Clock unter Linux setzen, nehme man hwclock. Syntax:

    hwclock –set –date=“10/10/02 10:45:00″

    Wobei das Datumsformat = „MM/DD/YY HH24:MI:SS“ ist.

  • Katze vermisst

    Seit dem 25.04.2008 vermissen wir unsere Maja. Wer das Tier findet melde sich bitte entweder per Kommentar oder via www.tasso.net bei uns. Maja ist gechippt, hat weisse Pfoten, eine weisse Brust und weisses Fell am Bauch. Ansonsten ist Sie getigert (Siehe Bild)

  • Shrinken von Oracle LOBs

    LOBs unter Oracle sind, wie schon an einigen Stellen im Blog hier erwaehnt, wirklich eine suboptimale Storage-Loesung unter Oracle. Vor allem, wenn eine solche Tabelle auch noch alle x Monate bereinigt werden soll. Nach dem entsprechenden DELETE belegt das LOBSEGMENT naemlich immer noch gut Platz auf dem Tablespace. Was bei „normalen“ Tabellen ueber ein „ALTER TABLE ENABLE ROW MOVEMENT“ mit anschliessendem „ALTER TABLE SHRINK SPACE“ geht, ist bei LOBSEGMENTEN nicht ganz so simpel. Und weil ich die beiden Sprueche immer wieder verwechsele, schreibe ich Sie jetzt hier auf:

    Gegeben sei ein Table „DATASTORE“ mit einem LOB der „FILEDATA“ heisst.

    Nur Shrinken (Nicht Highwatermark zuruecksetzen, also auch nicht Table „locken“):

    SQL> alter table datastore modify lob (filedata) (shrink space compact);

    Im Anschluss Highwatermark zuruecksetzen / Bzw. direkt vollstaendig shrinken (VORSICHT: Table wird gelockt):

    SQL>alter table datastore modify lob (filedata) (shrink space);

    PS: Das ganze laesst sich noch mit einem CASCADE erweitern, was dann bedeutet dass auch unterliegende Objekte mit geshrinkt werden (Indizes, etc.)