WE ARE ROOT

Das wollte ich mir nur mal wieder für später merken…

Ein Howto zum Schreiben von WordPress-Plugins, sowohl für “in the loop” als auch außerhalb des Loops.

Tutorial, wir schreiben ein simples WordPress-Plugin

Viel Spaß…

PS: Ich arbeite derzeit an mehreren Plugins… also: Stay tuned!

Eric Range hat in seinem Blog eine ziemlich einfache Lösung vorgestellt, mit der man mit einer WordPressinstanz mehrere Domains bewirten kann, die aber unter jeder Domain als eigenständiger Blog (User, Theme, aktivierte Plugins, Settings usw.) agiert.

Multi-(Sub)Domain-WordPress @ Open Sourced Brain.

Eigentlich will ich mir hier das nur merken, weil ich das bei Gelegenheit mal testen will… Falls es doch noch jemand anderen interessiert: Umso besser!

In einem früheren Artikel versprach ich, eine Postfix-Konfiguration zu posten, die nach (meinen) neuen Erkentnissen eingerichet ist.

So sah meine Konfiguration nach der Einrichtung von sqlgrey aus:

[...]
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit
[...]

Mehrere Hinweise aus der Postfix-Mailgruppe brachten mich jedoch auf folgende Konfiguration, die weiter unten noch genauer erläutere:

#
# restrictions
#
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes

#
# Recipient Restrictions
#

smtpd_recipient_restrictions =
    reject_unlisted_sender
    reject_unlisted_recipient
    reject_unknown_sender_domain
    reject_unknown_recipient_domain
    permit_sasl_authenticated
    permit_mynetworks
    reject_invalid_hostname
    reject_non_fqdn_sender
    reject_non_fqdn_recipient
    reject_unauth_destination
    #policyd-weight
    check_policy_service inet:127.0.0.1:60001
    #sqlgrey
    check_policy_service inet:127.0.0.1:60000
    reject_unknown_client
    reject_unknown_hostname
    permit

Es handelt sich hier natürlich nur um einen Ausschnitt aus der main.cf, diese Parameter sind sehr wichtig, wenn es darum geht, welche Mails von Postfix zur Zustellung angenommen werden.

weiterlesen…

Es ist immer wieder das gleiche: Sobald man denkt, dass man das System perfekt eingerichtet hat, bekommt/ findet man gleich mehrere Hinweise, die einen daran zweifeln lässt.

Ausgangslage

Bei vielen, die sich halbwegs um einen spamgeschützten Postfix-Mailserver kümmern, wird die Konfiguration ungefähr so aussehen:

[...]
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit
[...]

Anmerkung: Diese Konfiguration hatte ich bereits hier gepostet, wurde von mir nun aber mehrfach verfeinert (siehe weiter unten).

Wie man sehen kann, sind mehrere RBL-Checks (Realtime-Blackhole-List) in der Konfiguration, welche bei jedem SMTP-Connect von anderen Mailservern überprüft werden und bei einem positiven Treffer sofort zum REJECT führen. Dies hat zwar funktioniert, birgt aber die Gefahr, dass man einen legitimen Mailserver ablehnt, weil er durch einen Fehler in einer der RBL landete.

Besser wäre es also doch, wenn man nachschauen könnte, ob der Mailserver in mehr als einer dieser RBLs steht. Mit Boardmitteln von Postfix ist dies vorerst nicht möglich.

Einführung in policyd-weight

Hier kommt policyd-weight als policy-Server ins Spiel und bietet folgende Zusatzfunktionen in der Standardkonfiguration an (Auszug von der Website):

• Score-basierte Auswertung von RBL/RHSBL
• Score-basierte Auswertung der Beziehung und Korrektheit von DNS-Einträgen, HELO und MAIL-FROM
• Caching von a) DNS-Request und b) Score-Ergebnissen (= Beschleunigung und weniger Traffic)
• eigene, schnelle DNS-Lookup.Routine
• frei konfigurierbare Scores und RBLs (sinnvolle Standardwerte bereits enthalten)
• keine Datenbank-Abhängigkeit
• Einrichtung auch nur für eine Teilmenge von Mails/Mailservern nutzbar (via postfix restriction classes)

Policyd-weight arbeitet als Policy-Server mit Postfix zusammen und entgegen z.B. AMAViS noch auf der Ebene des SMTP-Connects und ist daher in der Lage, Postfix einen REJECT der Verbindung zu empfehlen und die Mail erst gar nicht anzunehmen zu lassen. (Dies ist auch im Hinblick auf die Rechtslage ein wichtiger Unterschied.)

Diese Vorteile sprechen ja deutlich für den Einsatz von policyd-weight und daher nahm ich mir auch gleich die Installation vor, welche im Folgenden beschreiben werde.

weiterlesen…

Die Sicherung von Datenbanken ist immer wieder eine Aufgabe, die man schnell vergisst und, wenn man sich dann damit befasst, für Kopfschmerzen sorgen kann.

Die Gründe:

• Während des Betriebs des Datenbankservers ist es meist nicht möglich einen konsistenten Abzug der Datendateien zu erhalten.
• Ein Anhalten des Datenbank-Server hat aber Auswirkungen auf das gesamte System.
• Selbst wenn man die Dateien kopieren kann, ist es nicht 100%ig sicher, dass man nach einem Absturz die Daten in einen neuen DB-Server mit vielleicht veränderter Versionsnummer einspielen/ einkopieren kann.

Es bietet sich daher an, statt der Datenbankdateien nur die gespeicherten Daten zu sichern. Dies ist mittels eines sog. dumps (eng. “Halde”) möglich, bei dem die Daten im Klartextformat ausgegeben und optimalerweise gleich in die Befehle eingeschlossen werden, die die Daten automatisiert wieder in einen neuen Datenbankserver einspielen können.

Auch wenn MySQL bereits von Hause aus Tools mitbringt, die diese Sicherungsmethode ermöglichen und auch Hilfstools wie phpMyAdmin eine Option zum Erzeugen von DB-dumps bieten, suchte ich eine noch simplere Methode, die ggf. noch Mehrwert bietet.

automysqlbackup

Das Projekt automysqlbackup ist unter sourceforge gelistet und derzeit in der Version 2.5 aktuell. Das Projekt scheint nicht mehr weiterentwickelt zu werden, denn der letzte Release ist vom 14.02.2006. Dies ist aber nicht weiter problematisch, da es sich im Prinzip nur um einen Wrapper für das mysql-tool mysqldump handelt und damit nicht sonderlich wartungs- oder weiterentwicklungsbedürftig ist.

Die Vorteile der Nutzung von automysqlbackup sind (von der Homepage):

• Backup aller oder ausgewählter Datenbanken
• gesamtes Backup in eine Datei oder einzelne Dateien pro Datenbank
• Platzsparend durch wahlweise Komprimierung mit gzip oder bzip2
• Sicherung auch von entfernten Servern
• Manueller Start oder cron-job-Steuerung möglich
• Ermöglicht die Zusendung des Logs oder der DB-Sicherung an eine bestimmte Mailadresse

Nach Befolgung der Installationsanweisungen auf der Homepage erzeugt das Tool regelmäßige Backups in dem gewählten Ordner und ermöglicht durch verschiedene Ordner ein versioniertes Backup, durch das man auch Zugriff auf ältere Versionen einer Datenbank hat.

Alles in allem ein sehr sinnvolles Tool und ich möchte es nicht mehr missen.

Fragen? Probleme? –> Schreib mir!

Spam nervt und stiehlt jedem Nutzer täglich Zeit. Um zu vermeiden, dass wir eines Tages nur noch mit dem Löschung von dubiosen Angeboten beschäftigt sind, müssen wir uns immer wieder mit Gegenmaßnahmen befassen. Eine dieser Gegenmaßnahmen ist Greylisting.

Was ist Greylisting?

Das Wort Greylisting entstand aus den Wörtern Blacklisting (in diesem Kontext: permanentes Verbot einer E-Mailadresse) und Whitelisting (permanente Erlaubnis für eine E-Mailadresse) und bezieht sich auf die Mischung dieser beiden Verfahren. Das Verfahren funktioniert vereinfacht wie folgt:

1. Ein dem Mailserver unbekannter Absender (freund@absender.tld) möchte gern ein Mail an person1@mailserver.tld senden.
2. Der Mailserver (mit installiertem Greylisting) aber lehnt die Übermittlung nach Erhalt der Absender und Zieladresse unter Angabe eines temporären Fehlers ab (meist mit einer Greylisting-Erklärung für das Logfile).
3. Der Mailserver trägt die IP des Absendermailserver ( absender.tld, 123.123.123.123 ) zusammen mit dem Absender (freund@absender.tld) und der Zieladresse (person1@mailserver.tld) in seine Datenbank ein.
4. Ein vernüftig konfigurierter Mailserver wird innerhalb der nächsten 10 bis 60 Minuten eine erneute Zustellung versuchen. So ist es auch und so versucht der Mailserver von freund@absender.tld erneut, die Mail an person1@mailserver.tld zu übergeben.
5. Der Zielmailserver schaut nun wiederum in seine Datenbank, ob ihm diese Kombination aus Quell-IP (wahlweise auch Quell-Subnetz), Absender und Adressat bereits bekannt ist. Da dem in diesem Fall so ist, nimmt er die Mail an und bestätigt die Annahme.

Die Idee hinter dieser “Verkomplizierung” der Mailzustellung ist, dass die Spammaschinen entweder das Handling von temporären Fehlern ausgeschaltet oder dieses in Ihren Mailprogrammen/ -servern gar nicht implementiert haben, um den Durchsatz zu erhöhen.

Wie kann ich Greylisting einsetzen?

Da Greylisting wie oben erläutert noch vor der Annahme der Mail geschehen muss, kann man dieses entweder direkt im Mailserver integrieren (z.B. Plugin) oder alternativ dem Mailserver als Proxy vorschalten.
weiterlesen…

Es ist ein Befehl, den ich sehr zu schätzen gelernt habe und fast täglich beim Debuggen brauche…

tail -f filename.log

Es erzeugt einen ständig aktualisierten Output für die betreffende Datei – perfekt, um das syslog nach einer Config-Änderung im Blick zu behalten.

Oder eben als rootTV: Den ganzen Tag einfach

tail -f /var/log/syslog

laufen haben und spannende Dinge sehen… zumindestens spannender als im deutschen Fernsehen.

Und mit

echo "tail -f /var/log/syslog" > ~/syslog.sh
chmod u+x ~/syslog.sh
~/syslog.sh

hat man einen noch schnelleren Weg, das syslog aufzurufen.

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

• Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.
  

  Lösung: kleine Dateien übertragen durch Erstellung von Volumes

• Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.
  

  Lösung: Verschlüsselung der Daten mittels GPG

• Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).
  

  Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

• Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.
  

  Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

• Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.
  

  Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

• Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.
  

  Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. weiterlesen…

Auch wenn es vielleicht nur mich interessiert:

Das Problem: Ein Programm soll im Hintergrund laufen, also unabhängig von der aktuellen (Putty-)Sitzung, damit es auch noch dem Logout weiterläuft.

Die Lösung: Es gibt diverse Methoden für diese Problemstellung, das Programm screen ist für mich aber die schönste:
screen -dmS SITZUNGSNAME Programm.sh

Es startet das Programm in einer separaten Sitzung. Die offenen Sitzungen kann man sich mit
screen -ls
anzeigen lassen und (sofern nur eine läuft) sich mit
screen -r
mit der Sitzung verbinden um die Programmausgaben zu sehen.

Wichtig ist, sich dann mittels “Ctrl+A” danach “D” von der Sitzung zu trennen, damit man das Programm nicht aus Versehen beendet.

Die noch viel weitreichenderen Möglichkeiten findet man wie immer mit
screen --help
oder
man screen

Ich hoffe, das kann so manchen helfen, der nach einer schnellen, sauberen Lösung sucht.

PS: Es macht natürlich nur für Programme Sinn, die auch von selbst im Loop laufen (z.B. Server).