Bei der Gelegenheit: Ich hätte noch eine Lizenz für VMware Workstation 6 “über” – wer will?

Derartige Queries lassen sich wie folgt beschleunigen:
- UNION ALL anstelle von UNION, das Aussortieren der ggf. doppelten Datensätzen über ein WHERE geht schneller, als das per default genutzte UNION DISTINCT … nicht wundern, ist so.

Damit sinkt die Laufzeit der Query von ca. 5 auf ca. 1,5 Sekunden, aber da geht noch mehr (der eigentlich logische Teil *hust*):
- wenn möglich sollte man die abzufragenden Datenmengen Inner-Queries entsprechend klein halten, wenn man z.B. eh nur 50 Datensätze aus 2 Tabellen kombinieren will, dann ist es sinnvoll auch nur diese in die Gesamtmenge einzubringen.

Laufzeit der Query nun wieder im Millisekundenbereich. Fertig ;)

Direkt beim ersten Verdächtigen, dem “besten” FTP-Server vsftpd, wird man auch fündig – benötigt wird jedoch eine einigermaßen aktuelle Version, d.h. Debian Stable ist wie immer zu alt ;) vsftpd bringt nicht nur die Direktive cmds_allowed mit, sondern in aktuellen Versionen auch das gewünschte cmds_denied. Um nun das Löschen von Dateien wirksam zu unterbinden genügt folgender Schnipsel in der vsftpd.conf (bei der Gelegenheit wird das Löschen von Verzeichnissen ebenfalls unterbunden):

cmds_denied=DELE,RMD

Brauchte man bisher entweder einen Hamster, der regelmäßig genau diese Funktionalität prüfte oder zumindest grundlegende Perl-Kenntnisse und etwas Zeit um ein eigenes Check-Plugin zu programmieren, gibt es mit cucumber-nagios eine echte Alternative. Exemplarisch wollen wir die Suchfunktion auf der O’Reilly Webseite prüfen und sicherstellen, dass das Praxisbuch Nagios im Online-Katalog gefunden werden kann. Lassen Sie uns den Hamster wieder in den Käfig bringen ;)

cucumber-nagios ist in der Programmiersprache Ruby entwickelt und wird als “RubyGem” verteilt, vergleichbar mit dem CPAN von Perl. Die Installation inklusive aller benötigten Abhängigkeiten geht folglich recht einfach vonstatten, solange Sie ruby und rubygems bereits installiert haben – die Pakete hierzu sind jedoch in aktuellen Linux-Distributionen bereits vorhanden.

$ gem install cucumber-nagios

Dies installiert nun das Programm mitsamt weiterer benötigter Ruby-Erweiterungen – wenn Sie den Befehl als normaler, nicht-privilegierter Nutzer ausführen, werden die Pakete im ~/.gem Verzeichnis des aktuellen Benutzers installiert. Hier ist dann noch die Anpassung der $PATH-Variable erforderlich, etwa wie folgt:

$ export PATH="$PATH:/home/tobias/.gem/ruby/1.8/bin"

Nun können wir auch schon starten und ein erstes Projekt erzeugen – jede Prüfung, die Sie später als eigenständigen Service in Nagios überwachen wollen entspricht einem Projekt.

$ cucumber-nagios-gen project oreilly
Generating with project generator:
     [ADDED]  lib/generators/feature/%feature_name%_steps.rb
     [ADDED]  README
     [ADDED]  features/steps/result_steps.rb
     [ADDED]  features/steps/benchmark_steps.rb
     [ADDED]  features/steps/webrat_steps.rb
     [ADDED]  features/steps/ssh_steps.rb
     [ADDED]  features/support/nagios.rb
     [ADDED]  features/support/env.rb
     [ADDED]  .gitignore
     [ADDED]  .bzrignore
     [ADDED]  Gemfile
     [ADDED]  bin/cucumber-nagios-gen
     [ADDED]  bin/cucumber-nagios
     [ADDED]  lib/generators/feature/%feature_name%.feature
Your new cucumber-nagios project is set up.

Im nächsten Schritt sind nun die benötigten RubyGems in das Projekt zu integrieren. Dies ermöglicht das Projekt später auf dem Nagios-Server einfach zu deployen.

$ cd oreilly
oreilly $ gem bundle

Zu guter letzt nun der wichtigste Part – wir legen fest, was wir wo prüfen wollen. Zunächst fügen wir dem zuvor angelegten Projekt ein Feature hinzu. Wichtig hierbei ist, den cucumber-nagios Generator des Projekts zu nutzen. Dieser benötigt zwei Argumente: Eine URL und einen Namen des Features.

oreilly $ bin/cucumber-nagios-gen feature www.oreilly.de search
Generating with feature generator:
     [ADDED]  features/www.oreilly.de/search.feature
     [ADDED]  features/www.oreilly.de/steps/search_steps.rb

In der Datei features/www.oreilly.de/search.feature beschreiben wir nun unser Prüfszenario. In das tfq benannte Suchfeld geben wir nagios ein, drücken den Los-Knopf und die darauf folgende Katalogseite soll den Text Praxisbuch Nagios enthalten.

Feature: www.oreilly.de
  It should be up

  Scenario: Visiting home page
    When I go to http://www.oreilly.de
    And I fill in "tfq" with "nagios"
    And I press "Los"
    Then I should see "Praxisbuch Nagios"

… und fertig. Nun können wir unser Prüfszenario direkt ausprobieren:

oreilly $ bin/cucumber-nagios features/www.oreilly.de/search.feature 
Critical: 0, Warning: 0, 4 okay | passed=4, failed=0, nosteps=0, total=4

cucumber-nagios wertet jeden einzelnen der 4 Schritte als einzelne Prüfung, sowohl die Ereichbarkeit der Webseite, das Vorhandensein des Suchfeldes sowie des Los-Buttons und des Suchergebnisses Praxisbuch Nagios.

Um nun diese Prüfung in Nagios integrieren zu können, kopieren Sie das gesamte Projekt-Verzeichnis in das Nagios-System und rufen dort innerhalb des Projektpfades einmalig den Befehlen gem bundle auf – schon ist die Prüfung einsatzbereit und kann in Ihr Nagios-System integriert werden.

Dieses kurze Beispiel vermittelt die Idee und Funktion hinter cucumber-nagios, mehr verrät die Webseite des Projekts.

Nachdem ich erst in den letzten Tagen ein Debian Advisory zu einer vorherigen Lücke in Typo3 gelesen hatte, dachte ich bei der ersten heute von Hetzner eintrudelnden Warnmail erst an eine verspätete Nachricht, bei der zweiten Mail von DomainFactory hab ich dann doch nochmal genauer nachgeschaut …

Ich habe mit arg viel “Russenspam” zu kämpfen gehabt. Die hat der SpamAssassin nicht entsprechend getagged, tageweise kamen dann halt gleich mehrere kyrillische Buchstabenkombos ungeschoren davon. Mein erster Ansatz war eine entsprechende Regel um den kyrillischen Krams händisch im SpamAssassin ordentlich zu bepunkten – noch einmal drüber nach gedacht, ein wenig gegoogelt, ein weiteres Bier getrunken und den Parameter ok_locales gefunden.

ok_locales                      en ja ko th zh de

Damit hat sich das Problem mit dem für mich eh unlesbaren Russenspam erledigt. Da ein Großteil meines privaten Spam-Aufkommens über die @gentoo.org Mailadresse eingeliefert wird (die wiederum in mein Mailsetup geforwardet wird, entsprechende RBLs hier also nix tun), unternahm ich also den Versuch das Greylisting zu deaktivieren.

Nun gut zwei Tage später ist Zeit für ein erstes, kurzes Fazit: Trotz deaktivertem Greylisting wird deutlich weniger Spam nicht erkannt – im Schnitt bleiben mir 2-3 unerkannte Spam-Mails am Tag. Zum Vergleich: Als Spam erkannt werden täglich gute 2.000 Mails – wovon ein Großteil wie bereits erwähnt über die @gentoo.org  Adresse eingeliefert wird. Eine Erkennungszuverlässigkeit von 99,9%, da kann ich gut mit Leben.

Zum Vergleich im Übrigen, dieses Blog hat bisher auch einigen Pingback/Trackback- und Kommentarspam angezogen …

114,456 spams caught, 756 legitimate comments, and an overall accuracy rate of 99.971%.

Akismet nutze ich allerdings erst ungefähr ein Jahr …

Nicht das es Vorschläge gegeben hätte, aber selbst ist der Mann ;)

Im Prinzip lässt es sich mit wenigen Worten beschreiben, Passenger (aka mod_rails) installieren und aktivieren, einen stinknormalen VirtualHost auf das public/ Verzeichnis der RoR-Anwendung konfigurieren – fertig. “Gefühlt” ist das neue Setup mit Passenger ein wenig (gut, unwesentlich) langsamer als die vorherige Kombination aus Mongrel und Apache – dafür verbrauchen nicht gleichzeitig 3 Mongrel-Prozesse jeweils 40MB RAM.

Ich bin mir durchaus bewusst, dass selbstverständlich gilt “you get what you pay for” (und in Sachen Preis/Leistung kann man sich über Hetzner nun wahrlich nicht beschweren!) – dennoch ist es doch zumindest merkwürdig, dass gefühlt mindestens einmal pro Jahr in mindestens einem der Hetzner Rechenzentren der Stromfluss versagt und das Einspringen (vorhandener!) USV-Anlagen nicht funktioniert.

Wenn laut eigenen Auskünften “bei geplanten Wartungsarbeiten in unseren Rechenzentren heute um 11.00 Uhr Störungen aufgetreten” seien, dann erstaunt es doch sehr, dass eine Benachrichtigung der Kunden über die bevorstehenden Wartungsarbeiten nicht stattgefunden hat. Das funktioniert sogar bei Strato und DomainFactory darf man sicherlich in Sachen Informationspolitik gesondert positiv hervorheben – ein mit Ausfällen verbundener Umzug eines ganzen Rechenzentrums wird dem Kunden gegenüber mehr als ausführlich kommuniziert. Bei Manitu ist der Leser des “Hostbloggers” ebenfalls über anstehende Erweiterungs- und/oder Wartungsarbeiten im Bilde – inwieweit Kunden über diese Maßnahmen vorab gesondert informiert werden kann ich jedoch nicht beurteilen, da (noch?) kein Kunde des Hostbloggers.

Um es klar zu formulieren: Hetzner leistet lt. AGB eine durchaus branchenübliche (zumindest in der Preisklasse – mehr Verfügbarkeit kostet logischerweise auch mehr) “Erreichbarkeit unserer Server von 99% im Jahresmittel” – und erreicht diese auch problemlos (zur Verdeutlichung: Eine Verfügbarkeit von 99% im Jahresmittel kann mehr als 3,5 Tagen Ausfall entsprechen). Was dennoch merkwürdig aufstößt, ist die wiederholte Problematik “Stromversorgung” – bei künftigen Wartungsarbeiten würde ich mir zumindest eine vorherige Information der Kunden wünschen, die ihrerseits dann entscheiden können, ob Vorarbeiten zur eventuellen Schadensminimierung notwendig und für sie sinnvoll sind.

Für Mitte des Jahres steht für mich privat eine Entscheidung an, wo ein neuer dedizierter Server gemietet werden soll – bis heute schwankte ich zwischen Hetzner und Manitu …

Die folgenden Schritte beschreiben die Installation von Redmine unter Gentoo Linux, “serviert” wird das Redmine von Apache via Mongrel, die Daten landen in einer MySQL-Datenbank.

1. Herunterladen eines aktuellen Tarballs oder Checkout aus dem SVN Repository.

# svn co http://redmine.rubyforge.org/svn/branches/0.8-stable redmine-0.8

2. Erstellen einer MySQL-Datenbank und Berechtigen eines Benutzers auf die Datenbank
3. Erstellen und Anpassen der Datenbankkonfiguration in der Datei config/database.yml:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: <strong>user</strong>
  password: <strong>password</strong>
  encoding: utf8

4. Initialisieren der Datenbank

# rake db:migrate RAILS_ENV="production"

5. Importieren der Default-Konfiguration

# rake redmine:load_default_data RAILS_ENV="production"

6. Benutzer und Gruppe “redmine” (oder anderweitig benamst, je nach Belieben) anlegen und wie folgt berechtigen:

# mkdir tmp
# chown -R redmine:redmine files log tmp
# chmod -R 755 files log tmp

7. Bearbeiten der Email-Konfiugration in der Datei config/email.yml.
8. Mongrel konfigurieren:

# mongrel config: mongrel_rails cluster::configure -e production -p 8000 -N 3 -c /var/www/redmine-0.8 --user redmine --group redmine

9. Berechtigungen im Verzeichnis tmp/pids prüfen, sollten die nicht passen zeigt sich Mongrel bockig.
10. Mongrel starten, wenn sich Mongrel wider Erwarten doch bockig zeigt in log/production.log nachschauen wo es hapert.

# mongrel_rails cluster::start

11. Dem Apache beibringen, dass er gefälligst auf Mongrel zugreifen soll, wenn jemand was vom redmine-VirtualHost möchte. Das kann z.B. so ausschauen:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName redmine.localdomain
 
        RewriteEngine On
        # Redirect all non-static requests to cluster
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
        RewriteRule ^/(.*)$ balancer://redminecluster%{REQUEST_URI} [P,QSA,L]
</VirtualHost>
 
<Proxy balancer://redminecluster>
        BalancerMember http://127.0.0.1:8000
        BalancerMember http://127.0.0.1:8001
        BalancerMember http://127.0.0.1:8002
</Proxy>

(Das ganze gehört in einen VirtualHost, die BalancerMember noch in eine “Proxy balancer://redminecluster” Direktive – WordPress schluckt die Tags – kann wer ein schickes Plugin empfehlen, dass sich für die Anzeige von Konfigurations- und Code-Schnipseln gut eignet?)
12. Um den Apache zum mitspielen zu bewegen, prüfen ob die Proxy-Module mit kompiliert wurden (USE=”proxy proxy_balancer proxy_connect proxy_http”) sowie das Laden der Proxy-Module konfigurieren. In /etc/conf.d/apache2 dazu APACHE2_OPTS=”-D SSL -D NAGIOS -D PHP5 -D PROXY” aktivieren. Apache starten, aufs Redmine zugreifen – fertig.

Wenn man mag, dann gilt es noch die Schritte 13 und 14 zu beachten:
13. Sicherstellen, dass die Datenbank sowie die Konfigurationsdateien wie auch der Attachments-Ordner (files/) gesichert werden.
14. Über ein Init-Skript sicherstellen, dass Mongrel auch nach einem Reboot gestartet wird und das Redmine zur Verfügung steht. Sieht zugegeben “komisch” aus, aber funktioniert :P Wer als Ruby on Rails-Experte Verbesserungsvorschläge hat – Ihr seid eingeladen ;)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

-- /etc/init.d/redmine --
#!/sbin/runscript
 
start()
{
        ebegin "Starting mongrel_cluster [redmine]"
 
        cd /var/www/redmine && mongrel_rails cluster::start
 
        eend $? $"Failed to start redmine"
}
 
stop()
{
        ebegin "Stopping mongrel_cluster [redmine]"
 
        cd /var/www/redmine && mongrel_rails cluster::stop
 
        eend $? $"Failed to stop redmine"
}

… und schon fertig ;)

PS: Wer Redmine über eine HTTPS-Verbindung anbieten will, der sucht noch Folgende Ergänzung zur Apache-Konfiguration:

RewriteEngine On
# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RequestHeader set X_FORWARDED_PROTO 'https'
RewriteRule ^/(.*)$ balancer://redminecluster%{REQUEST_URI} [P,QSA,L]

Fertig ;)