CBlog

Same procedere as every year?

Nein, ganz bestimmt nicht - auch wenn uns das Fernsehen wie in jedem Jahr dutzendfach das Gegenteil beweisen will.

Warum es diesmal anders sein soll? Insheim feiert 2007 mit einer Reihe von Veranstaltungen sein 1225-jähriges Bestehen.

Zum Start ins Jubiläumsjahr feierte die Landjugend eine Silvesterparty. Eingeladen waren alle Insheimer und solche, die es zumindest für eine Nacht sein wollten ;-) Trotz Regen kamen schätzungsweise 500 Leute, die sich von der Partystimmung mitreißen ließen, das Höhenfeuerwerk bewunderten und teilweise noch bis heute Morgen um 5:30 Uhr durchfeierten.

Mehr Spaß mit und bei der Landjugend gibt es im Juli:

• beim 24-Stunden-Grillen darf rund um die Uhr gegrillt werden
• beim Seifenkistenrennen mitsamt Boxenluder-Party ist das Motto "Heiße Kisten, scharfe Kurven" gleich doppelt Programm

Bis dahin sorgen viele andere Vereine für einen prall gefüllten Terminkalender, den man sich beim Kulturverein Insheim ansehen kann. (Sobald der Downloadlink dort repariert ist ;-)

War noch was? Ach ja:

Prosit Neujahr!

Ob heute schon Weihnachten ist?

Eigentlich nicht, aber ich habe trotzdem ein vorgezogenes Geschenk: Die AppArmor-Profile dieses Servers. Im Einzelnen sind das Profile für:

• Postfix (Mailuser in MySQL)
• maildrop (Maildirs in /home/mailbox/)
• Mailman
• Amavisd
• ClamAV
• SQLgrey
• Courier (Mailuser in MySQL)
  
• vsftpd
• diverser "Kleinkram"

Der Vorteil meiner Profile gegenüber den in SUSE Linux 10.1 mitgelieferten ist schlicht, dass meine Profile durchgetestet sind und (zumindest bei meiner Konfiguration) auch alle nötigen Aktionen erlauben. Das nervige Nacharbeiten der Profile und "warum blockt er das jetzt?" fällt also weg ;-)

Außerdem habe ich für einige Programme (Mailman, Courier, maildrop, vsftpd, SQLgrey, ClamAV) die Profile komplett selbst erstellt. (Bei vsftpd können Anpassungen der Pfade je nach Struktur der Homedirs nötig sein, außerdem ist /home/mailbox/ als Mail-Verzeichnis fest in den maildrop- und Courier-Profilen verdrahtet.)

Einige Profile sind nach /etc/apparmor/profiles/extra/ verlinkt - diese Profile funktionieren entweder im Originalzustand oder ich habe das entsprechende Programm noch nie gebraucht ;-)

Download: apparmor-profiles-20061220.tgz

Installation: nach /etc/apparmor.d/ entpacken, rcapparmor reload aufrufen und schon ist das System ein gutes Stück sicherer.

Die Weitergabe und Verwendung der AppArmor-Profile ist unter den Bedingungen der GPL erlaubt.

Und ich wünsche an dieser Stelle schon mal Sichere ;-) und Frohe Weihnachten!

Eingabedaten validieren sollte die erste Lektion für alle sein, die sich mit ihren Scripten ins "WeltWeite Warten" (www) trauen.

Leider gibt es immer wieder traurige Gegenbeispiele. fefe hat jetzt entdeckt, dass packages.debian.org die URL-Parameter ungeprüft übernimmt, inclusive der auf der Seite angezeigten MD5SUM des Pakets. Sowas ist ziemlich blauäugig ;-)

Vor ein paar Stunden konnte man noch beliebigen HTML-Code einschleußen (siehe Screenshot - ja, soviel Spaß muss sein), inzwischen wird "immerhin" die MD5SUM auf Länge und erlaubte Zeichen überprüft. Eine falsche MD5SUM ausgeben geht immer noch, solange die Länge stimmt.

Eine falsche MD5sum in Verbindung mit einem manipulierten FTP-Server heißt de facto, dass jemand ein gefaktes Paket mit beliebig bösem Inhalt anbieten kann und das nichtmal auffällt. Auf debian-www hält man sowas aber für "low risk". Es geht ja auch nur um potenziell gefakte Pakete mit bösen suid-root Programmen...

Was fefe übersehen hat: auch die anderen Parameter sind beliebig manipulierbar. Ich bin mal gespannt, wie lange Debian den Internet Explorer zum Download anbietet *eg*

Wie man sowas manipulationssicher programmiert? Eigentlich recht einfach - man packt die Nutzdaten (Paketnamen, MD5SUM usw.) in eine Datenbank und übergibt dem Script nur die ID als Parameter.

UPDATE: Inzwischen wurde die RegEx etwas verschärft und erlaubt nur noch [0-9a-f]. Ich habe die obigen Links etwas angepasst, damit sie weiterhin funktionieren. Falsche MD5SUMs kann man immer noch einschleußen...

Das ist die Mailstatistik dieses Servers der letzten Woche. Die großen Ausschäge in der "Rejected"-Kurve stammen im Wesentlichen aus "Relay access denied" von einer einzigen IP.

Falls jemand gern Rätsel löst, hätte ich ein paar Fragen:

• Wann ist ein neuer Kunde dazugekommen?
• Ist es ein Privat- oder ein Geschäftskunde?
• Wann hat er endlich geglaubt, dass er SMTP Auth aktivieren muss? ;-)

Anhand der Grafik sollte die Lösung recht leicht zu finden sein. *g*

UPDATE (11.12.2006): Wie sich inzwischen herausgestellt hat, hat die Firewall die SMTP-Authentifizierung rausgefiltert...

So, seit ein paar Tagen läuft openSUSE 10.2 beta2 auf meinem Laptop. Wie es bisher aussieht, gibt es wenig Grund zum Klagen.

Die schlimmsten Bugs, die ich entdeckt habe, sind zwei Probleme im Paketmanager. Der eine sorgt für einen Hänger, wenn eine (Online-)Installationsquelle nicht verfügbar ist (#221071), der andere für einen riesigen Stapel Fehlermeldungen, wenn eine Installationsquelle eine Apache-Fehlermeldung statt der Metadaten liefert (#218552). Als Workaround hilft es, nur funktionierende Installationsquellen zu verwenden ;-)

Falls sich jemand Sorgen um den Status des Paketmanagers macht: diesmal funktioniert er wirklich ;-) out of the box und muss nicht erst wie bei 10.1 zurechtgepatcht werden. Ach ja, und man kann zmd und zen-updater durch opensuse-watcher ersetzen, der direkt auf libzypp aufsetzt. Bleiben nur noch die kaputten Berechtigungen bei permissions.secure (#216485).

Der einzige Bug, der in der täglichen Arbeit nervt, ist ein hyperaktiver artsd, der den Prozessor unnötig beschäftigt (#178930) - naja, dafür gibt es killall -9...

Dazu kommen die üblichen Kleinigkeiten - ein paar verwirrende Schaltflächen (#218677), eine komische Übersetzung (#220668) oder auch ein fehlendes Leerzeichen (#220875).

Ach ja, das Syntax-Highlighting for AppArmor-Profile in vi funktioniert dank meiner Mithilfe wieder (#190084).

Am schönsten fand ich aber die Tipps beim KDE-Start (Screenshot rechts oben). Dort wird u. a. erklärt, dass KDE in viele Sprachen übersetzt ist - und genau dieser Text ist nicht übersetzt *g* (#221177 - hmmm, sollte ich den wegen Peinlichkeit zum Blocker machen?)

"404 not found" hat wohl jeder schon mal gesehen.

Zur Abwechslung biete ich "404 bugs found" ;-)

Ja, von SUSE Linux 9.2 beta bis heute hat sich einiges angesammelt. Darunter waren einige Dauerbrenner, z. B. der Dualhead-Betrieb auf meinem Laptop (#61858), der dem Blinker-Prinzip folgt (pro SUSE-Release: geht, geht nicht, geht, ...) und PHP open_basedir, das ich gern pro vHost setzen würde - dummerweise werden aber die Einstellungen der vHosts bunt durcheinandergemischt (#136651). Der letzte "Fix" vor einiger Zeit war leider wenig erfolgreich. Ich bin ja mal gespannt, ob der jetzt angekündigte Patch das Problem endlich behebt ;-)

Andere Bugs befassten sich mit Ausnahmesituationen (z. B. dass /var/lib ein Symlink ist ;-) - #181606) und wieder andere "nur" mit ungewohnten Tastenfolgen für Datei - Öffnen (#215576). Auch der Spaß kam nicht zu kurz, wie beispielsweise einige Kommentare in Bug #141107 oder Bug #180796 zeigen. Dazu kamen diverse Verbesserungsvorschläge, von denen manche sofort und manche nach deutlichem Nachhaken (#206414, #143648) umgesetzt wurden. Beim Betatest der 10.1 hatten insbesondere die Programmierer von YaST und der Paketverwaltung ihre Freude - in diesen Bereich fielen 64 meiner 152 Bugreports zur 10.1 (was mich nebenbei zum zweitaktivsten Bugreporter nach Andreas Jaeger (182 Bugreports) gemacht hat ;-)

Nicht nur die Programmierer, auch das Doku-Team hatte seinen Spaß mit mir (oder umgehehrt?), als ich im berühmt-berüchtigten Bug #65000 (#50000 zu Zeiten von bugs.suse.de; ich habe zwar trotz der runden Zahl nichts gewonnen, aber "lots of people here were annoyed by it - they wanted to file this magical number themselves ;))") diverse Fehler im Handbuch ("handbug?") der 9.2 berichtete. Jede Büroklammer im Handbuch markierte einen Fehler im Kapitel "Shell", das Foto ging vorab ans Doku-Team. Die erste Reaktion seitens Jana Jaeger auf meinen Bugreport war dann übrigens "@bugreporter: please do not ever touch a paperclip again ... :)"

Inzwischen helfe ich gelegentlich auch selbst bei der Fehlerbehebung, beispielsweise in pin und in apparmor.vim (vim Syntax-Highlighting für AppArmor-Profile).

Nur einen Bug konnte ich bis heute nicht beheben: der Tag hat leider nur 24 Stunden. Egal, nehme ich eben die Nacht dazu ;-)

Ach so: Die älteren Bugreports für SUSE <= 9.3 sind nur für alteingesessene Betatester zugänglich, daher sind nur rund 290 Bugs öffentlich sichtbar. Vermutlich erhöt sich die Zahl aber demnächst - ich will morgen openSUSE 10.2 beta1 installieren...

Im Gästebuch der Landjugend RheinhessenPfalz habe ich ein paar Zeilen PHP-Code verwendet, um Gästebuch-Spam abzufangen. Das Funktionsprinzip war recht einfach: wenn der Eintrag nach Spam aussieht, setze $_POST['firstname'] = "". Das Gästebuch hat dann den fehlenden Vornamen beklagt ;-) und den Eintrag zuverlässig abgewiesen.

Nach dem Update auf Typo3 4.0 funktioniert das so nicht mehr - scheinbar wird $_POST von Typo3 gecacht.

Der Einfachheit halber habe ich jetzt doch ve_guestbook gepatcht:

--- pi1/class.tx_veguestbook_pi1.php_ORIG   2006-10-22 03:07:02.000000000 +0200
+++ pi1/class.tx_veguestbook_pi1.php        2006-10-22 02:56:52.000000000 +0200
@@ -947,6 +947,11 @@  function checkForm() {
                        }
                }

+               if (!empty($this->postvars['entry'])) {
+                       if (preg_match ( "/\[url=.*\]|<a[^>]*href/i", $this->postvars['entry']))
+                           $error .= "<li>Bitte keinen Spam posten!</li>\n";
+               }
+
                if ($this->config['email_validation'] && !empty($this->postvars['email'])) {

                        if (t3lib_div::validEmail($this->postvars['email']) == false) {

Der Feature Request für eine offizielle "Eintrag Blacklist" Konfiguratonsoption in ve_guestbook, die ganz normal übers Typo3-Backend konfiguriert werden kann, ist übrigens auch schon beim Autor eingereicht ;-)

 

UPDATE (17.11.2006)

Der Fehler lag woanders - Typo3 4.0.2 cacht ve_guestbook zu aggressiv.

Das führte zum Einen dazu, dass mein Hack, $_POST zu verändern, nicht mehr funktioniert hat, und zum anderen dazu, dass keine neue Gästebucheinträge akzeptiert wurden - die Bestätigungsseite wurde gechacht und der Eintragen-Code im Gästebuch wurde deshalb nicht mehr ausgeführt :-(

Die Lösung: Die Seite komplett vom Cachen ausschließen (nicht wirklich empfehlenswert) oder im Typoscript plugin.tx_veguestbook_pi1 = USER_INT eintragen. (Quelle)

Und schon kann man wieder $_POST missbrauchen ;-)

In Single Sign-on in phpMyAdmin aus einer anderen PHP-Session habe ich erklärt, wie man mit einer bestehenden Session passwortlos zu phpMyAdmin kommt und einen entsprechden Hack für die config.inc.php gezeigt.

Inzwischen wurde phpMyAdmin 2.9.0-rc1 releast, in dem ein neues Authentifizierungsmoduls "signon", basierend auf meinem Hack, enthalten ist. Zu konfigurieren ist das Ganze über ein paar Variablen in der config.inc.php:

$cfg['Servers'][$i]['auth_type']     = 'signon';
$cfg['Servers'][$i]['SignonURL']     = '/login.php';
$cfg['Servers'][$i]['LogoutURL']     = '/logout.php';
$cfg['Servers'][$i]['SignonSession'] = 'PHPSESSID';

Die MySQL-Logindaten müssen natürlich in der Session hinterlegt werden. Gegenüber meinem ursprünglichen Code haben sich die Variablennamen leicht verändert. Die Session wird mit folgendem Code befüllt:

$_SESSION['PMA_single_signon_user'] = "username";
$_SESSION['PMA_single_signon_password'] = "password";
if (!isset($_SESSION['PMA_single_signon_token'])) {
    $_SESSION['PMA_single_signon_token'] = md5(uniqid(rand(), true));
}

Kleine Stolperfalle: PMA_single_signon_user und PMA_single_signon_password werden beim Logout aus phpMyAdmin gelöscht. /logout.php sollte also wirklich sofort den Logout machen. Wenn man eine Abfrage "wirklich ausloggen?" hat und der User "nein!" antwortet, wird man trotzdem von phpMyAdmin ausgesperrt (oder muss PMA_single_signon_* nochmal neu setzen). Ja, ich habe das reklamiert, der phpMyAdmin-Entwickler wollte das aber nicht ändern.

Übrigens: PMA_single_signon_token benötigt man immer dann, wenn man direkt auf eine Unterseite von phpMyAdmin verlinken will (z. B. um einen Datensatz direkt zu bearbeiten). Im Link zu phpMyAdmin muss der Wert dann im ?token= Parameter angegeben werden.

Seit gestern und noch bis zum Montag, 4.9. ist Weinfest in Insheim. Das heißt quasi Ausnahmezustand im ganzen Ort, tausende Besucher und eine ganze Menge Spaß.

Für mich heißt es aber auch, dass ich für die Vorbereitung seitens der Landjugend (Plakate, Schoppenglas-Design, Werbung usw.) diverse Nachtschichten einlege. Außerdem brauchen wir natürlich noch mehrere Abende (und kurz vor Beginn auch mal einen ganzen Tag, damit alles rechtzeitig fertig wird) zum Aufbau. Während des Weinfests wird es gern mal etwas später - die letzten Gäste gehen nach 2 Uhr, bis etwa 4 Uhr sind wir dann noch mit Aufräumen und Hof kehren beschäftigt.

Bei der Landjugend Insheim gibt es neben reichlich Musik (Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und Deafen Goblins) und einer Vielzahl an Getränken unterschiedlichen Alkoholgehalts auch einige Leckereien aus der Küche. Für zwischendurch bieten wir unter anderem für alle, die es etwas schärfer mögen, eine Chili-Bratwurst an. Sowas lasse ich mir natürlich nicht entgehen und kann sagen, dass diese Chili-Bratwurst ihren Namen wirklich verdient hat :-) und sie definitiv gut für den Getränke-Umsatz ist *g*

So, und jetzt gehe ich wieder aufs Weinfest. Eigentlich[tm] habe ich ja heute Abend frei, aber erfahrungsgemäß werden doch noch ein paar Helfer mehr gebraucht als geplant ;-)

Ich habe seit einiger Zeit versucht, Pakete für courier-authlib-mysql in SUSE Linux integriert zu bekommen, nachdem diese des öfteren nachgefragt werden. Obwohl nur eine Änderung im Specfile erforderlich ist, endeten entsprechende Feature Requests bisher immer mit "wontfix".

Aber: Es geschehen noch Zeichen und Wunder ;-)

Auf dem kleinen Dienstweg (Mail an AJ) habe ich jetzt erreicht, dass es ab SUSE 10.2 (das dann übrigens openSUSE 10.2 heißt) ein courier-authlib-mysql Paket gibt - und nebenbei auch -pgsql und -pipe Pakete :-)

Übrigens: courier-authlib-mysql-Pakete für SUSE Linux 10.1 habe ich unter software.opensuse.org/download/home:/cboltz/ im Angebot - einzige Änderung zum Originalpaket der 10.1 ist die Aktivierung des -mysql-Pakets im Specfile.

Ich habe eine Seite mit selbstgestricktem Login auf Basis von PHP-Sessions. Jetzt will ich phpMyAdmin einbinden, ohne dass man sich nochmal darin einloggen muss - schließlich sind die Leute ja schon auf meiner Seite eingeloggt.

Sowas schreit förmlich nach Single Sign-On. Schönes Buzzword, allerdings findet Google für phpMyAdmin recht wenig zu diesem Thema.

Nach einigem Trial&Error sowie einem Nachmittag in #phpmyadmin habe ich eine Lösung geschrieben, die nur eine Ergänzung der config.inc.php braucht, ansonsten nicht in phpMyAdmin eingreift und nichtmal das normale Login stört - ich kann also dieselbe phpMyAdmin-Instanz für Single Sign-On und Cookie-basiertes Login verwenden.

Als Tastaturliebhaber muss ich bei dieser Initiative natürlich auch mitmachen ;-)

Vor ein paar Tagen habe ich einen Spamfilter ins Gästebuch von Landjugend-Insheim.de eingebaut, nachdem eine Handvoll Spameinträge aufgeschlagen war.

Weil das Gästebuch nur Plain Text-Einträge erlaubt, ist das Funktionsprinzip einfach: ich kann auf <a href=...> und [url=...]filtern. Die Spammer sind immer so nett, diese Tags in reichlicher Anzahl in ihre Einträge zu packen ;-)

Technisch gesehen sieht das so aus:

<?php
if ( preg_match ( "/\[URL=.*\]|<a[^>]*href/i", $eintrag)) {
    echo "Verp*** dich, Spammer!";
    die;
}
?>

Naja, die echte Fehlermeldung ist etwas freundlicher - es könnte ja auch mal jemand einen "guten" Eintrag schreiben und auf aktiviertes HTML hoffen. Der bekommt dann natürlich nach Entfernen der Links eine zweite Chance.

Gestern und heute hat mir dieser Filter reichlich Arbeit gespart - innerhalb von 36 Stunden hat er mir 170 Spameinträge vom Hals gehalten...

Am 27. und 28. Mai feierte die Landjugend RheinhessenPfalz ihr 137-tägiges Bestehen mit der Aktion Wir rollen durchs Land. Im Rahmen dieser Aktion gab es Aktionen in mehreren Städten und einer Party auf der Neumühle.

Hier sind endlich die Bilder dazu:

Spendensammlung zugunsten der Herzenssache in Neustadt

Der Server, auf dem auch dieses Blog liegt, hatte in der Vergangenheit öfter Schluckauf mit der Zeit:

• die Voreinstellung von 1&1 war "lokale Zeit", also ohne automatische Sommerzeitumstellung und grundsätzlich eine Stunde daneben
• auch nach der Umstellung auf UTC wollte sich die Uhr nicht automatisch auf Sommerzeit umstellen
• komischerweise hat ein Aufruf von yast2 timezone ohne irgendeine Änderung die Zeit immer korrigiert
• xntpd hat sich wegen einer Stunde "Zeitverschiebung" gleich nach dem Start verabschiedet

Nach längerer Zeit der Verwunderung habe ich endlich das Problem gefunden:

# rpm -V timezone
S.5....T   /usr/share/zoneinfo/Europe/Berlin

Nach Neuinstallation des timezone-Pakets bin ich die Zeitverschiebung endlich los.

Wer oder was die Datei überschrieben hat? Keine Ahnung - ich wäre aber nicht überrascht, wenn Plesk mal wieder seine Finger im Spiel gehabt hat.

(Hatte ich eigentlich schon erwähnt, was ich von Plesk halte? ;-)

Update: Zur Sicherheit sollte man auch noch die Zeitzone in den PHP-Scripten angeben:

<?php putenv( "TZ=Europe/Berlin" ); ?>