XTC Shops für PHP 5.4 fit machen

Posted on by

Die Umstellung von PHP 5.3 auf PHP 5.4 kann nicht aktuelle Software sehr überraschend treffen. Am Beispiel XTC möchte ich heute eine kurze Hilfe zu einem bekannten Problem zeigen:

Function session_is_registered() is deprecated in /home/XTCSHOP/
public_html/shop/includes/functions/sessions.php on line 96

in Zeile 96 finden wir dies :

function xtc_session_is_registered($variable) {
      return session_is_registered($variable);
}

Eine einfache Änderung durch diese Anweisungen:

function xtc_session_is_registered($variable) {
      return true;
}

behebt die ersten Probleme. So können Sie wenigsten wieder in den Adminbereich einloggen und Updates einspielen.

Javaprogramme könnten schneller laufen

Posted on by

Mal wieder fiel sofort auf, als ich einmal mehr strace bemühen mußte um festzustellen,
was genau das von Java aus gestartete Bashscript so treibt.

Dabei weckten wieder diese Zeilen meine Aufmerksamkeit:

[pid  3488] gettimeofday({1371633845, 44988}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45163}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45283}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45401}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45648}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45776}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 45917}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46044}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46156}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46286}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46509}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46629}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46746}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46857}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 46967}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47120}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47231}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47343}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47465}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47612}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47750}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 47870}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 48008}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 48121}, NULL) = 0
[pid  3488] gettimeofday({1371633845, 48232}, NULL) = 0

Wie man leicht erkennen kann, finden diese Zugriffe im Milli- bis Microsekundentakt statt.

Wenn man sich das strace log vornimmt, kommt das dabei raus:

[root]# wc --lines  /tmp/log
38896 /tmp/log
[root]# grep -c gettimeofday /tmp/log
25366

Also rund 2/3 aller Logzeilen entfallen nur auf gettimeofday() . Auch wenn der Aufruf an sich nur wenige Takte der CPU benötigen sollte, die Masse der Aufrüfe an sich stellt ein nicht zu verachtendes Problem dar. Vermutlich ist das völlig unnötig. Mal sehen, ob sich Oracle der Meinung anschliesst.

Im Einsatz war Java 6 latest.

Vodafone und Deutsche Post passen nicht zusammen.

Posted on by

Vor ein paar Wochen hatten wir die fast perfekte Phisingmail im Postfach und da dachte ich schon, daß ab jetzt nur noch solche „gut“ gemachten Fälschungen kommen, aber die Hoffnung war verfrüht.

Heute schlug eine Virenemail bei uns auf, die noch schlechter als die gestrige Freenet Nachricht ist:

Return-path: <embellishmentkold@vodafone.com>
Envelope-to: XXXXXXXXXXXXXXXXXX
Delivery-date: Wed, 12 Jun 2013 10:01:54 +0200
Received: from office.sultrade.cz ([77.78.83.250])
    by XXXXXXXXXXXXXXXXXX with esmtp (Exim 4.76)
    (envelope-from <embellishmentkold@vodafone.com>)
    id 13ghtF-0330Wf-Lx
    for XXXXXXXXXXXXXXXXXX; Wed, 12 Jun 2013 10:01:54 +0200
Received: from [14.162.112.153] (helo=bpolztbxhdhvnj.repsbzunnmche.com)
    by office.sultrade.cz with esmtpa (Exim 4.69)
    (envelope-from )
    id 1MMXUA-4636xu-17
    for XXXXXXXXXXXXXXXXXX; Wed, 12 Jun 2013 09:01:53 +0100
From: "Deutsche Post" <supportpakete@deutschepost.de>
To: <XXXXXXXXXXXXXXXXXX>
Date: Wed, 12 Jun 2013 09:02:53 +0100
X-Mailer: aclovp 47
Message-ID: <23423423405.7ELTMN4234443dd9@yegcbtbuivgls.pjeyyh.tv>
Subject:  Wo ist meine Sendung 021604452

Wenn einen die Nachricht selbst nicht schon abschreckt, denn die ist im Mailprogramm eigentlich nur formloser Matschinhalt, sollten einem die Domainnamen im Header eigentlich alles sagen.

Vodafon.com und als Absender deutschepost.de, sowas kann nur ein ausländisches Scriptkid zusammenbasteln, das dem der Text egal ist.

Die Mail wird über einen gehackten oder offenen tschischen Mailserver gesendet, der seine Spams aus Vietnam bekommt.

Natürlich haben wir wieder eine ZIP Datei mit einem Virus drin. Das übliche halt.