Tag Archives: HowTo

eisfair-HowTo: richtig krasse Spam-Mails automatisch löschen

Spam, Spam, Spam, Spam und das jeden Tag. Mein Setup sieht derzeit so aus, dass auf meinem eisfair-Server das Paket mail installiert ist. Dies sammelt via fetchmail die Mails von meinen Mailkonten ein, jagt die durch ClamAV und durch SpamAssassin und verteilt die dann wahlweise auf mein IMAP-Konto oder zum User spam. Das funktioniert sehr gut, auch die false positive Rate des Spam-Filters ist traumhaft, ich kann mich an keinen einzigen in den letzten drei Jahren erinnern.

Nichtsdestotrotz kommen immernoch zu viele Spam-Mails durch. Peter vom Fli4l-Team wurde das bei derselben Software zu viel und kam im IRC mit folgender Lösung um die Ecke: alle Spam-Mails, die von SpamAssassin einen Score größer als 10 bekommen, werden direkt nach /dev/null verschoben, also unwiderruflich gelöscht. Als ich gestern die aktuelle Welle in meinem Spam-Ordner anrollen sah, hab ich beschlossen, das auch umzusetzen.

Mit eisfair ist das zum Glück spielend leicht. Man erstellt als root einfach eine Datei namens custom-systemfilter.rm_spam_mail im Ordner /var/spool/exim und übergibt die dann mit

chown exim:trusted /var/spool/exim/custom-systemfilter.rm_spam_mail

dem passenden Systemnutzer. Der Inhalt muss wie folgt aussehen:

# Exim custom filter
#------------------------------------------------------------------------------
if $h_X-Spam-Score: contains "++++++++++++"
then
    logfile /tmp/exim_filter_rm_spam.log
    logwrite "$tod_log To=$h_to Subject=$h_subject From=$h_from Id=$message_id"
    save /dev/null
endif

(Bei neueren Versionen des Pakets mail kann man die Datei direkt aus /usr/local/exim/examples kopieren.)

Dann geht man ins Setup-Menü, dort in die Konfiguration vom Paket mail und lässt die einmal neu durchlaufen. Das Paket erkennt die zuvor erstellte Datei und meldet folgendes:

adding custom system filter /var/spool/exim/custom-systemfilter.rm_spam_mail ...

Fertig, naja fast. Wer den Filter aufmerksam angesehen hat, erkennt, dass das Log erstmal provisorisch in /tmp/exim_filter_rm_spam.log landet. Eleganter ist es, das Logfile dahin schreiben zu lassen, wo die anderen Logfiles von exim landen, nämlich nach /var/spool/exim/log. Dazu ändert man den Pfad im obigen Beispiel entsprechend ab. Jetzt fehlt noch das logrotate dafür. Dazu kopiert man am besten /etc/logrotate.d/mail in eine neue Datei, beispielsweise /etc/logrotate.de/exim_filter_rm_spam. Diese Datei passt man nun an seine Bedürfnisse an, d.h. man schmeißt den Abschnitt für fetchmail raus, ändert die Pfadangabe für das Logfile und spielt dann noch bisschen mit den eigentlichen Einstellungen. Bei mir sieht das Ergebnis so aus:

#------------------------------------------------------------------
# Creation: 2009-07-07 alex
#------------------------------------------------------------------
/var/spool/exim/log/exim_filter_rm_spam.log {
    rotate 53
    weekly
#    compress
    missingok
    notifempty
    sharedscripts
    create 640 exim trusted
    postrotate
        /etc/init.d/mail -quiet reload exim
    endscript
}

Ich lasse in dem Fall recht viele wöchentliche Logfiles übrig und lasse die nicht komprimieren. Das ermöglicht eine einfache statistische Auswertung, wieviel Spam tatsächlich gelöscht wurde (auch wenn ich das noch nicht umgesetzt habe).

Mehr Infos über das eisfair-Paket gibt’s in der eisfair-Dokumentation im Abschnitt Mail-Package. Die Filter vom Mailserver Exim sind detailliert auf exim.org beschrieben.

Ach und wer erkannt hat, dass ich in meinem Filter die Mails erst ab einen Score von 12 wegwerfe und nicht wie Peter schon bei 10, bekommt ein Bienchen!

HTML-Entities mit WP-Syntax 0.9.2

Für die Darstellung von Code-Schnipseln, speziell das Syntax-Highlighting setzen wir das Plugin WP-Syntax ein. Probleme gab es bisher immer mit Code, der die speziellen HTML-Entities enthielt, also hauptsächlich die öffnenden und schließenden spitzen Klammern, die in der einen oder anderen Sprache irgendwie als Vergleichsoperatoren eingesetzt werden: < und >.

Bisher bin ich Problemen damit so aus dem Weg gegangen, dass ich entsprechende Zeichen im Beitragseditor durch &lt; und &gt; ersetzt hatte. Damit das Plugin damit umgehen konnte, war bei jedem Update eine kleine Änderung notwendig, für Version 0.9.1 sah der Patch beispielsweise so aus:

--- wp-syntax.php  2008-08-24 19:22:12.000000000 +0200
+++ wp-syntax.php  2008-08-25 15:26:48.000000000 +0200
@@ -97,7 +97,8 @@
     $line = trim($match[2]);
     $code = wp_syntax_code_trim($match[3]);

-    $geshi = new GeSHi($code, $language);
+    $geshi = new GeSHi(htmlspecialchars_decode($code), $language);
     $geshi->enable_keyword_links(false);
     do_action_ref_array('wp_syntax_init_geshi', array(&$geshi));

Ab WP-Syntax 0.9.2 ist das nicht mehr notwendig. Die Release Notes sagen ganz lapidar:

**0.9.2** : Updated to use GeSHi v1.0.8.2; Added optional `escaped=”true”` support in case code snippets are already escaped with html entities.

In der Praxis sieht das dann so aus:

    <pre lang="xml" escaped="true">
    &lt;xml&gt;Hello&lt;/xml&gt;
    </pre>

Das vereinfacht zukünftige Upgrades von dem Plugin, ist also eine feine Sache. Für vergangene Beiträge musste ich jetzt allerdings nochmal von Hand diesen Parameter setzen. Wenn mir da irgendwo was durch die Lappen gegangen sein sollte, einfach mal kurz anpiepsen, dann behebe ich das.

HowTo: Migration von Subversion Repositories mit eisfair

eisfair-2 steht vor der Tür, ich erwähnte es bereits im letzten Jahr und auch dieses Jahr anlässlich des LinuxTag. Da es kein Upgrade von eisfair-1 auf eisfair-2 geben wird, muss man die Kiste mehr oder weniger von Hand migrieren. Wie man seine Subversion-Repositories umzieht, beschreibe ich in diesem Artikel.

Falls aktiv und häufig mit den Repositorys gearbeitet wird, sollte der erste Schritt darin bestehen, die Schreibrechte auf dem alten Server zu entziehen. Das einfachste ist, in der Subversion-Konfiguration die Variablen SVN_REPOS_?_ANON_ACCESS und SVN_REPOS_?_AUTH_ACCESS für das umzuziehende Repository auf ‘read’ oder auf ‘none’ zu setzen.

Dann folgt das Backup des alten Repositorys. Dies sollte man an dieser Stelle manuell anstoßen, weil man nicht sicher sein kann, dass nicht noch jemand nach dem letzten automatischen Backup was eingecheckt hat. Dazu wählt man im Setup-Menü den entsprechenden Punkt für das Backup und im folgenden Dialog aus einer Liste das entsprechende Repository. Danach läuft der Dump vom Repository durch. Wenn das abgeschlossen ist, wird beim Subversion Paket ab 0.5.0 dann der Pfad und Name vom soeben erstellten Backup angezeigt, den man sich merken sollte, um zu wissen, welche Datei man gleich auf den Zielrechner zu kopieren hat. Bei älteren Paketversionen muss man im Setup-Menü nochmal den Menüpunkt ‘List backup files’ auswählen. Das grad erstellte Backup steht wahrscheinlich ganz oben, im Zweifelsfall schaut man auf Datum und Uhrzeit, die im Dateinamen mit drin stehen.

Der nächste Schritt besteht darin, die Backupdatei auf den Zielrechner zu kopieren, auf dem man bereits das Subversion-Paket installiert hat. Um das Backup über das Setup-Menü wieder einspielen zu können, muss der Zielpfad für die Kopieraktion der in SVN_BACKUP_TARGET angegebene sein. Außerdem sollte man ein neues leeres Repository einrichten, in das gleich das Backup eingespielt wird.

Aus dem Setup-Menü des Subversion-Pakets wählt man dann den Punkt ‘Restore repository’. Aus der Liste wählt man das soeben neu erstellte leere Repository. Das war es schon. Jetzt nur noch den Nutzern die neue Adresse mitteilen und fröhlich mit dem umgezogenen Repository weiter arbeiten. Das ganze nochmal in Kürze:

  • altes Repo auf dem Quellrechner deaktivieren oder wenigstens die Schreibrechte entziehen, nicht löschen natürlich!
  • setup -> Administration of services -> subversion administration -> Subversion Administration Tools -> Subversion backup and restore -> Backup repository
  • gewünschtes Repo auswählen
  • bei Paket vor 0.5.x: List backup files, entsprechende Datei steht wahrscheinlich ganz oben, auf die Zeit achten, um von cron-generierten zu unterscheiden, hier: /mnt/data2/backup/svn/repos1-2008-09-24-095600.backup.bz2
  • ansonsten angezeigten Dateinamen des Backup kopieren
  • auf den Zielrechner kopieren in das Verzeichnis was dort bei SVN_BACKUP_TARGET angegeben ist
  • neues Repo anlegen auf Zielrechner
  • Restore repository: richtiges Backup-File aus der Liste wählen
  • das neu erstellte Repo aus der Liste wählen

Schicke Grafiken in LaTeX mit pgfplots (2)

Ich hatte im Beitrag »Schicke Grafiken in LaTeX mit pgfplots (1)« noch ein zweites Beispiel angekündigt. Diesmal zeige ich wie man mit pgfplots eine Grafik mit horizontalen Balken baut. Als Grundlage dient die Grafik aus einem Paper mit dem Titel »Concrete-based constrained layer damping«. Das Original sieht bereits im Original verpixelt aus:

Mit PGF bzw. besser gesagt mit TikZ lässt sich das nachbauen. Box, Anstriche, Beschriftungen und Balken müssen aber alle komplett von Hand erstellt werden.

begin{tikzpicture}[xcomb,thick]
    % die balken
    draw[color=gray,line width=10pt]
        plot coordinates{(0.75,0.5) (1.125,1) (7.5,1.5) (5.4,2)
        (6,2.5) (0.3,3) (0.05,3.5)};
    % box (rechteck) außen rum
    draw (0,0) rectangle (9,4);
    % die achsenbeschriftung links
    foreach y/ytext in {0.5/mild steel, 1/cast iron, 1.5/granite,
        2/polymer concrete, 2.5/lead, 3/6063 aluminium, 3.5/alumina}
        draw (-2pt,y cm) node[anchor=east] {footnotesizeytext};
    % anstriche für die achse unten
    draw (0,0) -- (-2pt,0);
    foreach x in {0,0.75,...,9}
        draw (x cm,0) -- (x cm,-2pt);
    % achsenbeschriftung unten
    foreach x/xtext in {0/0.000, 1.5/0.001, 3/0.002, 4.5/0.003,
        6/0.004, 7.5/0.005, 9/0.006}
        draw (x cm,-2pt) node[below] {footnotesizextext};
end{tikzpicture}

Das Ergebnis ist schon recht ansprechend, es werden die LaTeX-Schriften verwendet und es ist eine saubere Vektorgrafik:

Mit pgfplots muss man nicht alle Einzelheiten selbst nachbauen sondern definiert im Grunde nur noch Labels und Werte.

begin{tikzpicture}
    begin{axis}[
        xbar,
        width=10cm,
        height=6cm,
        ytick={1,...,7},
        yticklabels={%
            mild steel,
            cast iron,
            granite,
            polymer concrete,
            lead,
            6063 aluminium,
            alumina},
        xmin=0,
        xmax=0.006
    ]
    addplot[draw=darkblue,fill=blue!50!white,semithick] coordinates {
        (4.5e-4,    1)
        (7.5e-4,    2)
        (5e-3,      3)
        (3.6e-3,    4)
        (4e-3,      5)
        (2e-4,      6)
        (3e-5,      7)
    };
    end{axis}
end{tikzpicture}

Da ist erstens der Quelltext übersichtlich und verständlich und das Ergebnis überzeugt ebenso:

Mehr Text gibt’s dann ein ander Mal wieder, ich denke die Code-Beispiele und Bildchen sprechen für sich. ;-)

Kommentare in der .htpasswd

Ich bin gerade ein wenig unsicher, ob ich mal wieder Google-blind bin oder ob es wirklich nicht vorhanden ist – jedenfalls war ich nicht in der Lage, eine vernünftige Dokumentation des Dateiformats für die Passwortdateien des Apache zu finden.

Die meisten Einträge befassen sich damit, wie man das htpasswd-Tool benutzt, mit dem sich solche Dateien über die Kommandozeile bearbeiten lassen. Ich möchte aber wissen, ob und wie ich dort Kommentare einfügen kann.

Letztendlich habe ich einfach mal probiert und war damit erfolgreich, vor die betroffene Zeile eine Raute zu setzen (#), also so zu kommentieren, wie in shell-Scripten.

Aber eine fundierte Lösung wäre mir natürlich lieber. Falls jemand etwas hat: Ab in die Kommentare damit!

Tiefenanordnung von Linien in Matlab-Plots

Heute geht es mal um ein sehr spezielles Problem mit einer Lösung auf die ich gestern durch Probieren gekommen bin und sehr erstaunt war, dass das so funktioniert und offenbar sogar so vorgesehen ist. Zunächst ein paar Worte zum ursprünglichen Problem.

Ich arbeite im Institut mit Matlab 6.1, zwar schon etwas in die Jahre gekommen aber brauchbar. Für die Auswertung meiner Messdaten habe ich ein GUI programmiert wo ich zwei verschiedene Sachen gleichzeitig in einem axes-Objekt darstellen will. Normalerweise kann man hier mit den Funktionen hold und plot arbeiten, aber mir war das zu unflexibel und ich habe daher gleich die LowLevel-Funktionen benutzt. Ich habe in dem GUI das gewünschte axes-Objekt. Direkt darunter in der Objekthierarchie kommen bereits die line-Objekte, die auch plot erzeugt. Von Hand kann man sich die mit dem Befehl line erzeugen, die landen dann in dem aktuellen axes-Objekt, das man zuvor mit axes(axeshandle) festlegen sollte. Bei der Erzeugung der line-Objekte speichere ich das line-Handle um später direkt wieder drauf zugreifen und beispielsweise die zugrundeliegenden Daten ändern zu können.

Soweit so gut, nun ist es so, dass ich nicht bestimmen kann, wann der Benutzer die eine Sache zum Plotten anklickt und wann die andere. Oben erscheint aber immer die zuletzt gewählte. Genauso verhält sich der Befehl plot. Was zuerst geplottet wird, landet hinten, die nachfolgenden Sachen darüber. Das ist bei vielen Darstellungen egal, bei einigen aber nicht.

Der Trick um die Darstellungsreihenfolge – oder englisch z-Order – zu ändern klingt ein wenig wie »von hinten durch die Brust ins Auge«, funktioniert aber wunderbar. Um zu verstehen, was dort gemacht werden muss, schaut man sich am besten nochmal die Objekthierarchie an. Ein axes-Objekt beherbergt beliebig viele line-Objekte. Die Handles dieser Objekte kann man sich ausgeben lassen:

linehandles = get(gca, 'Children')

Die einzelnen Elemente des Vektors linehandles haben genau die Reihenfolge der Anordnung in z-Richtung wobei das erste Element das zu oberst angezeigte ist. Es spricht nichts dagegen, die Elemente umzuordnen und dem axes-Objekt wieder zuzuweisen, z.B. in umgekehrter Reihenfolge:

set(gca, 'Children', flipud(get(gca, 'Children')))

Ich war einigermaßen überrascht, dass das tatsächlich so funktioniert, da ich in der ausführlichen Matlab-Hilfe nie darüber gestolpert bin. Dass das wirklich so vorgesehen ist, sagt einem Matlab selbst, wenn man versucht der Eigenschaft Children etwas anderes als ein umgeordnetes selbst zuzuweisen:

??? Error using ==> set
Children may only be set to a permutation of itself.

Damit das ganze noch ein wenig anschaulicher wird, habe ich noch ein kleines Skript geschrieben, dass die Sache nochmal illustriert:

% test data
a = rand(5,1)
b = rand(5,1)
c = rand(5,1)
% line handles
hp = plot([a b c])                  % hp in order we plotted
ha = get(gca, 'Children')           % reverse order
% vectors of line handles equal?
all(hp==ha)                         % not equal
all(hp==flipud(ha))                 % should be equal, see above
all(sort(hp)==sort(ha))             % also equal
% thick lines
set(ha, 'LineWidth', 10)
title('original order')
legend('a','b','c')                 % order as in plot call
print(gcf, '-dpng', 'z-order-original.png')
% color of the most front line, should be c
get(ha(1), 'Color')                 % should be red aka [1 0 0]
% now flip lines, put c in the back
set(gca, 'Children', [ha(2) ha(3) ha(1)])
title('flipped order')
print(gcf, '-dpng', 'z-order-flipped.png')
% color of the most front line, should be b
ha = get(gca, 'Children')
get(ha(1), 'Color')                 % should be green aka [0 0.5 0]

Schaut man sich hier die erzeugten PNG-Bilder an, erkennt man, dass die Linie für die Datenreihe c zunächst ganz vorn und dann ganz hinten dargestellt wird:

Alte Revisionen wiederherstellen mit Subversion

Im täglichen Umgang mit Subversion passiert es, dass man Dateien eincheckt, die man dann doch eigentlich nicht commiten wollte. Zum Glück kann man alte Revisionen wiederherstellen, dafür hat man ja das Versionsverwaltungssystem, man muss nur wissen wie.

Die erste Idee: revert – das funktioniert nicht, weil revert nur Änderungen an der lokalen Working Copy rückgängig macht, nach dem Commit kann revert nichts mehr ausrichten.

Die zweite Idee: update auf die ursprüngliche Version. Dann hat man in der Working Copy zwar zunächst mal die alte Version liegen. Man kann sie aber nich direkt commiten, weil Subversion sie für aktuell hält. Das ist sie im Grunde auch, nur halt in einer vorherigen Revision. Lokale Änderungen gibt es in dem Sinne nicht an der Datei. Bei Binärdateien kommt man an dieser Stelle nicht weiter, wenn man nicht jedesmal wieder ein update auf die alte Revision machen will.

Die dritte Idee: ins Handbuch schauen. Das exzellente Subversion-Buch hat natürlich auch zu dieser Problematik die passenden Tipps parat: Undoing Changes. (Wir arbeiten hier noch mit Subversion 1.4, daher der Link ins »alte« Buch.) Was auf den ersten Blick überraschend klingt: merge ist die Lösung für das Problem. Der Trick ist, dass wir dieses Mal rückwärts mergen. Dadurch gelangt die ältere Revision wieder in die Working Copy und nachdem man kontrolliert hat, ob damit alles stimmt, kann man die erneut commiten.

Genug der Vorrede, ich zeige den Vorgang mit dem Kommandozeilen-Client und mit TortoiseSVN am Beispiel. Ich habe hier eine Binärdatei driftcompgui.fig, die ich zuletzt in Revision 297 korrekt eingecheckt habe. In Revision 300 habe ich versehentlich eine falsche Version der Datei eingecheckt und möchte jetzt wieder die Version aus Revision 297 haben. Auf der Kommandozeile sieht das recht einfach aus (mit anschließendem Screenshot der Ausgaben):

svn merge -c -300 driftcompgui.fig

Wie man sieht liegt die Datei nun geändert in der Working Copy und zwar in der gleichen Version wie in Revision 297. Jetzt kann man die so einchecken oder noch weiter damit arbeiten. Bei TortoiseSVN erschließt sich diese Funktion aus dem GUI eher überhaupt nicht. Ich zeige zunächst mal den entscheidenden Screenshot und erkläre dann nochmal:

Hier wählt man zunächst im Feld »From:« die gewünschte Datei aus und klickt »HEAD Revision« an. Das ist sozusagen der Startpunkt des Rückwärts mergens. Bei »To:« natürlich »Use “From:” URL« auswählen, da es um die selbe eine Datei geht. Als Ziel Revision gibt man hier die an, die man wiederherstellen will, in meinem Fall 297. Jetzt kann man ohne weiteres auf »Merge« klicken und dann die Datei in der Working Copy untersuchen. Sollte irgendetwas nicht stimmen, kommt man mit revert wieder zur HEAD Revision, da wie bei jedem anderen Merge kein automatischer Commit passiert sondern die Änderungen des merge nur in der Working Copy landen. Wenn alles ok ist, kann man commiten und hat danach wieder die alte Version der Datei im HEAD des Repository.

Homepage mit trac 0.10.x

Wir arbeiten ab und zu an IMPULS. Anfang des Jahres sind wir mit dem Subversion-Repo hier nach antiblau gezogen und benutzen jetzt Trac anstelle des Bugtracking-Systems von Sourceforge. Trac bietet neben Repository Browser, Bug Tracker und Milestone-Verwaltung auch ein Wiki. Andere Projekte wie z.B. Licq oder lcd4linux haben ihre ganze Homepage mit Trac realisiert. Da sich ein Wiki ganz gut eignet um unabhängig von HTML-Editor, PHP-Kenntnissen etc. so eine Seite aktuell zu halten, beschloss ich die Homepage für Impuls auch mit dem sowieso schon genutzten Trac zu verwirklichen.

Die größte Hürde für eine sinnvolle Nutzung von Trac als Homepage stellt die Navigation dar. Im Wiki selbst sind mehr oder weniger nur Sprünge von Seite zu Seite möglich, eine einheitliche Navigation, beispielsweise über eine Sidebar ist so zunächst nicht vorgesehen. Dass das irgendwie möglich ist, sieht man bei Licq, also hab ich mir angeschaut, wie man das mit den Paketen von Debian Etch sinnvoll umsetzen kann, dort wird Trac in Version 0.10.x verwendet also noch vor der Umstellung der Template-Engine mit der 0.11.x.

Das Prinzip ist eigentlich ganz einfach: Trac an geeigneter Stelle in irgendeinem HTML-Template einen neuen div-Container unterschieben mit beliebiger Id und anhand dieser Id dann ein passendes CSS Stylesheet bauen. In diesem Fall haben wir in /usr/share/trac/templates/header.cs eine Zeile eingefügt:

<div id="mainnav" class="nav"><?cs call:nav(chrome.nav.mainnav) ?></div>
<?cs include "site_navi.cs" ?>
<div id="main">

Das hat den Vorteil, dass jede neue Trac-Installation von der Änderung erstmal nichts mitbekommt. Die Datei site_navi.cs muss im jeweiligen Trac-Projekt-Ordner angelegt werden, um in den Genuss der Navi-Sidebar zu kommen. Konkret geschieht dies im Unterordner templates des Trac-Projektordners, da wo z.B. auch die Dateien site_header.cs und site_footer.cs liegen. Die Datei site_navi.cs enthält dann den Inhalt der Sidebar, im Fall der IMPULS-Homepage sieht das so aus:

<?cs
####################################################################
# Site header - Contents are automatically inserted above Trac HTML
?>
<div id="left">
    <div id="navi1">
        <ul>
            <li><a href="http://www.impuls-toolset.org/trac/wiki">Start</a></li>
            <li><a href="http://www.impuls-toolset.org/trac/roadmap">Roadmap</a></li>
            <li><a href="http://www.impuls-toolset.org/trac/wiki/Toolset">Toolset</a></li>
            <li><a href="http://www.impuls-toolset.org/trac/wiki/MailingLists">Mailing lists</a></li
            <li><a href="http://www.impuls-toolset.org/trac/wiki/FrequentlyAskedQuestions">F.A.Q.</a
            <li><a href="http://www.impuls-toolset.org/trac/wiki/Download">Download</a></li>
            <li><a href="http://www.impuls-toolset.org/trac/wiki/Development">Development</a></li>
            <ul>
                <li><a href="http://www.impuls-toolset.org/trac/wiki/ProjectConventions">Project con
                <li><a href="http://www.impuls-toolset.org/trac/wiki/ProtocolSpecification">Protocol
            </ul>
        </ul>
    </div>
</div>

Fehlt noch das passende Stylesheet, dazu sind noch folgende Änderungen nötig. Zunächst eine Anpassung der Datei site_css.cs, die im gleichen Projektordner liegt:

<?cs
##################################################################
# Site CSS - Place custom CSS, including overriding styles here.
?>

@import url(<?cs var:chrome.href ?>/site/style.css);

Wie man sieht wird hier eine Stylesheetdatei eingebunden. In dieser wird dann das angepasste Stylesheet definiert. Die Datei style.css liegt ebenfalls im Trac-Projektordner und zwar im Unterordner htdocs. Im Falle der Impuls-Homepage hat sie folgenden Inhalt:

#left {
	float: left;
	width: 13em;
	margin-bottom: 1em;
	margin-top: 1em;
}

#navi1 {
	color: #000000;
	background-color: #EEE5E6;
	padding: 0em 0.5em 0em 0.8em;
	margin: 0em 0em 1em 0em;
	border: 1px solid #A8071C;
}

#navi1 ul {
	margin-left: 1em;
	padding: 0;
}

#main {
	margin-left: 14em;
}

#altlinks {
	clear: right;
}

table.listing {
	clear: right;
}

#preview {
	clear: right;
}

#help {
	clear: right;
}

#info {
	clear: none;
}

@media print {
    #left { display: none; }
    #main { margin-left: 0em; }
}

Damit sich die Sidebar harmonisch einfügt sind auch einige kleine Hacks an den bereits vorhandenen Elementen der Seite nötig, speziell die clear:right, damit der eigentliche Inhalt sauber neben und nicht unter die Sidebar gesetzt wird.

Was man in der Sidebar dann letztendlich verlinkt, bleibt jedem selbst überlassen. Im Falle von Impuls wollte ich eigentlich eine sehr flache Hierarchie haben, ist mir nicht ganz gelungen. Ansonsten genügt es für weitere Änderungen die beiden Dateien style.css und site_navi.cs zu bearbeiten. Mit einem möglichen Update auf Trac 0.11.x wird das ganze dann aber sehr wahrscheinlich nicht mehr funktionieren, weil dort keine Clearsilver-Templates mehr benutzt werden. Wenn es soweit ist, müssen wir mal schauen, wie wir das dann umsetzen.

HowTo: Standard-Dateiberechtigungen im Apache

Die Aufgabe: Dateien, die vom Apache HTTP-Server erzeugt werden, sollen bestimmte Zugriffsrechte erhalten.

Seit wir das Antiblau-Blog mit einem Cache versehen haben, bekomme ich regelmäßig E-Mails von dem Script, das sich normalerweise um die Korrektur der Berechtigungen in den WWW-Verzeichnissen kümmert (die Struktur lässt sich mit den Standardmechanismen der Unix-Dateiberechtigungen nicht mehr abbilden und ACLs habe ich nicht). Der Grund ist, dass die Cache-Dateien mit der Gruppe des Apache, statt mit der Gruppe des Webspaces, und mit den falschen Zugriffsrechten erzeugt wurden.

Die Gruppenberechtigung lässt sich leicht korrigieren, indem das Gruppen-Stickybit des übergeordneten Verzeichnisses gesetzt wird:

chmod g+s cache

Schwieriger ist die Anpassung der Zugriffsrechte von 640 auf 660. Hierfür muss der Apache so konfiguriert werden, dass auch Gruppen Schreibrechte erhalten. Das geschieht über die umask-Variable (umasks legen fest, welche Berechtigungen bei einem chmod wieder gelöscht werden), die in der envvars-Konfiguration angegeben werden.

Dazu habe ich in die Datei

/etc/apache2/envvars

den Eintrag

umask 002

eingefügt, den Apache neu gestartet und schon war das Problem behoben.

Hierarchische Package-Darstellung in Eclipse

Nachdem mir heute wieder ein “Wie machst Du das eigentlich?” begegnet ist, bringe ich als Abwechslung zu ewig langen Text-Einträgen mal ein kurzes Bunte-Bildchen-Howto:

Viele Eclipse-Nutzer sehen in der Java-Perspektive ihre Package-Struktur so:

Package-Explorer - flache Darstellung

Der Nachteil dieser Darstellung ist, dass sich die Baumstruktur der Packages nur schwer nachvollziehen lässt. Die Darstellung ist flach und genauso heisst sie auch: Flat Package Presentation.

Viel günstiger ist aber meist die Hierarchical Package Presentation, bei der Packets wieder in einer Baumstruktur dargestellt werden:

Package Explorer - hierarchische Darstellung

Erreicht wird dies, indem man in der rechten oberen Ecke des Package Explorers das Menü öffnet und die Option Package Presentation von Flat auf Hierarchical umstellt:

Package Explorer - Menü

Dort befinden sich auch einige andere nützliche – oder vielleicht auch nervige – Optionen der Package-Darstellung, die sich je nach Belieben aktivieren oder deaktivieren lassen.