Teardown: Was steckt hinter einer Software-as-a-Service Lösung?

Dieser Artikel behandelt das Konzeptions-Thema für eine Software-as-a-Service Lösung anhand eines konkreten Beispiels. Er zeigt, welche Überlegungen hierbei zu bedenken sind und wie sie im betrachteten Fall gelöst wurden.

Einleitung: Was ist SaaS?

Was ist Software-as-a-Service (kurz SaaS) eigentlich?

Der Begriff gehört zu der Gruppe XXX-as-a-Service wobei XXX üblicherweise für einen dieser 3 Begriffe steht: Infrastructure, Platform oder Software – man liest zuweilen noch beliebige andere Begriffe. Im Grunde genommen bedeutet es aber nichts anderes, als die Verwendung des jeweiligen XXX ohne sich mit Installation, Betrieb und Wartung herumschlagen zu müssen. Also sozusagen „Plug and Play“.

SaaS_Pyramide

Die 3 genannten Begriffe sind üblicherweise aufbauend zu sehen. Das bedeutet, die unterste Stufe ist die Infrastruktur, z.B. das Hosting eines Servers durch einen Provider. Darüber kommt die Plattform, z.B. Datenbanken oder Middlewares. Ganz oben in dieser Reihung steht dann eine fertig zu verwendende Software. Das sind dann typische Cloud-Applikationen, die jeder von uns kennt. Je weiter man hier nach oben steigt umso näher kommt man dem Anwender.

Aus gegebenem Anlass – dem Start unseres neuen SaaS Dienstes design2budget – möchte ich hier einige Grundkonzepte beschreiben, die beim Design so einer Lösung zu beachten sind.

Basisverständnis

design2budget_logo-writingUm die nachfolgend beschriebenen Überlegungen und die getroffenen Entscheidungen zu verstehen, möchte ich einen kurzen Einblick geben, was design2budget ist.

design2budget ist eine Cloud-Applikation mit der eine Firma ihre Kunden, Angebote und Aufträge verwalten bzw. in weiterer Folge natürlich auch Verrechnungs- und Mahnwesen automatisiert abbilden kann. Die Grundidee ist – Sie kennen es sicher auch aus eigener Erfahrung – wenn Sie ein bestimmtes Vorhaben planen, holen Sie sich Angebote ein. Oft dauert es mehrere Wochen, bis Sie das Angebot erhalten und dann sitzen Sie besser auf einem Stuhl, denn neben der Themenverfehlung entspricht der Preis nicht dem was Sie im Kopf hatten. Unsere Lösung schafft hier Abhilfe, denn wir setzen auf den Einsatz von modernen Endgeräten, wie z.B. Tablets, mit denen Ihnen der Vertriebsmitarbeiter bereits vor Ort einen Preis nennen kann und das Angebot entsprechend Ihren Wünsche gestalten kann.

Wichtig für die folgenden Konzeptbeschreibungen ist jedoch, dass es sich bei den Kunden um Firmen handelt, die durchaus auch mehrere Benutzer (Vertriebsmitarbeiter, Techniker, Backoffice Mitarbeiter, …) haben. Daher wird das Wort „Mandant“ als Synonym für die Firma eingesetzt und die Benutzer sind User Accounts die einem Mandanten zugeordnet sind.

Datenhaltung und Datentrennung

dbinstance_per_mandantDa die in design2budget abgelegten Daten sensibler Natur sind, war für uns eine Mandantentrennung eine fixe Voraussetzung. Jeder Mandant erhält in unserer Lösung tatsächlich eine eigene Datenbank. Um diese strikte Trennung noch zu verschärfen, werden hierbei pro Mandant zufallsgenerierte Zugangsdaten erstellt und verschlüsselt hinterlegt. So hat ein Angreifer keine Chancen, bei Kompromittierung eines Mandanten auf die Daten eines anderen Mandanten zuzugreifen.

Skalierung

Eine Cloud-Applikation ist vom Prinzip her so ausgelegt, dass möglichst viele Anwender diese Software verwenden können. Um diesen Anspruch gerecht zu werden, sind bereits in der Konzeptionsphase entsprechende Skalierungsmaßnahmen zu planen. Die bei diesen Konzepten oft getroffene Entscheidung „dann geben wir der Maschine darunter einfach mehr RAM oder CPU“ hilft hierbei leider nur begrenzt weiter. Selbst mit Virtualisierungstechnologie ist damit sehr schnell Schluss.

skalierungMit design2budget haben wir uns für eine 2-stufige Skalierungsvariante auf Applikationsebene entschieden. In der Stufe 1 wird einem Mandant ein primärer (von mehreren vorhandenen) Applikationsserver zugeteilt. Erreicht der Mandant eine bestimmte Größe (Anzahl an Benutzern) tritt Stufe 2 in Kraft. Die Applikation wird auf mehrere gleich berechtigte Applikationsserver aufgeteilt und mit einem vorgelagerten Load-Balancer wird die Belastung gleichmäßig verteilt.

Deployment

Um die beschriebene Datentrennungs- und Skalierungsmaßnahmen umzusetzen benötigt es natürlich einer Steuerung. Hierzu gibt es ein Management Service, welches mit einer zentralen Instanz – dem Management-System – die anfallenden Tasks koordiniert und durchführt. Dazu gehören:deployment

  • Aktivierung eines neuen Mandanten
  • Deaktivierung / Löschung eines Mandanten
  • Automatische Ressourcen Verteilung
  • Update der Applikation
  • Reporting (für Verrechnungszwecke)
  • Backup- und Notfall-Mechanismen

Beim Betrieb eines Cloud-Services sollte das Konzept also bereits vorsehen, möglichst viele Tätigkeiten zu automatisieren.

Reporting

Was ist mit Reporting gemeint? Natürlich bietet design2budget eine Reporting Engine mit der die Hit-Rate, Conversion-Rate, usw. ausgewertet werden kann. Doch hier in diesem Artikel ist damit das notwendige Reporting für eine Verrechnung aus unserer Sicht gemeint.

Unser Verrechnungs-Modell basiert auf einer monatlichen Basisgebühr, welche 3 Benutzer-Accounts beinhaltet. Optional können weitere Benutzer-Accounts direkt im Programm angelegt werden.

Daher benötigen wir für jeden Mandanten die Anzahl an aktiven Benutzern um diese entsprechend zu verrechnen. Wie bereits erwähnt, haben wir keinen direkten Zugriff auf die Datenbanken, denn die Zugangsdaten wurden zufällig erzeugt und verschlüsselt abgelegt. Daher übernimmt der im vorigen Absatz genannte Management-Service die Aufgabe, diese Daten pro Mandant zu sammeln und an unser zentrales Management-System zu übermitteln.

Wir als Betreiber haben daher nur die Daten zur Verfügung, die wir zur direkten Verrechnungen benötigen. Zu einem sauberen Konzept gehört für uns auch die Überlegung, welche Daten hat wer wann im Zugriff.

Partner-Konzept

Wie bereits angesprochen, handelt es sich um sensible Daten, die durch unsere Lösung generiert und verwaltet werden. In Zeiten in denen viele Unternehmen Ihre Mails und Kalender einem großen Suchmaschinenbetreiber anvertrauen, gibt es weiterhin Unternehmen, die Ihre Daten selbst verwalten – in der sogenannten Private-Cloud.

Unsere Lösung nimmt auf diesen Umstand Rücksicht und das vorher beschriebene Deployment- und Skalierungsmodell erlaubt es, eine Instanz von design2budget in der eigenen Firma oder im eigenen Rechenzentrum zu betreiben.

architektur_partner2Der Mandant erhält eine vollständige Umgebung inkl. vorher angesprochenem Management-System. Dieses System dient als Gateway um sich mit unserer zentralen Management-Instanz zu verbinden, um dort die konsolidierten Reporting Daten für unsere Verrechnung abzuliefern und sich Applikations-Updates zu holen.

Durch dieses Konzept ist es uns sogar möglich, das gesamte Cloud-Service – mit allen beschriebenen Mechanismen – schlüsselfertig einem Partner als OEM Produkt zur Verfügung zu stellen. Der Partner kann seine eigene Infrastruktur verwenden um mehrere Applikationsserver aufzusetzen, selbst wiederum mehrere Mandanten anzulegen, diese zentral zu verwalten und die Abrechnung zu übernehmen. Das zentrale Management-System des Partners nimmt die gleiche Gateway-Rolle wie bei der Private-Cloud Variante ein und übermittelt an unsere Management-Instanz die konsolidierten Informationen, wie die Gesamtanzahl an Mandanten und die Gesamtanzahl an Benutzern aller Mandanten zusammen.

Abschlussbemerkung

Wie man aus den hier angeführten Überlegungen sieht, ist es nicht einfach damit getan, eine Webanwendung zu schreiben und diese auf einem Webserver zu installieren.

Will man SaaS professionell betreiben, so sind eine Menge Überlegungen im Hintergrund anzustellen und entsprechend umzusetzen:

  • Datenhaltung: wo und wie lege ich die Nutzerdaten ab
  • Datensicherheit: wer darf wann auf welche Daten zugreifen, welche Daten brauche ich als Betreiber
  • Skalierung: wie gehe ich mit steigender Belastung um
  • Automatisierung: was kann ich automatisieren, wie übernehme ich das Deployment, Updates, …
  • Verrechnung: welche Daten benötige ich und wie komme ich zu den Daten, die ich zum Verrechnen benötige
  • Markterweiterung: wie kann ich meine Lösung wiederverwenden, wie kann ich neue Märkte erschließen (in unserem Fall durch das Partner Modell)

Ausblick

Wir haben uns nicht nur mit den Konzepten und der Technik beschäftigt. Auch gehen wir mit unserem Produkt neue Themen an. In einem kommenden Artikel werde ich den Trend Gamification etwas näher beleuchten.

Über den Autor

Ing. Leo Eibler ist im Bereich Beratung und IT Service Management tätig sowie Geschäftsführer von cubic zebra. Das in diesem Artikel als Beispiel herangezogene Projekt design2budget wurde durch cubic zebra entwickelt und wird als Cloud-Service vertrieben.

 

 

 

Ähnliche Artikel:

  • Noch keine vorhanden.

Mailserver SPF, DKIM, DMARC – Was wie und warum?

Domain-based Authentifizerung für Emails mit SPF, DKIM und DMARC

Vorwort:

Als Admininstrator von Servern stößt man immer wieder auf die Schlagwörter SPF, DKIM, DMARC. Da ich mich nun aufgrund eines aktuellen Projekts ebenfalls mit Email Versand und nicht-als-spam-markiert-werden beschäftigt habe möchte ich hier eine kleine Erklärung und Anleitung zu diesem Thema bereitstellen.

Die Beispielkonfiguration in diesem Artiel verwendet debian Linux mit postfix und opendkim und bind als DNS Server.

Was ist SPF, DKIM, DMARC

Zuerst einmal zur Begriffserklärung:

SPF = Sender Policy Framework – http://en.wikipedia.org/wiki/Sender_Policy_Framework

DKIM = Domain Key Identified Mail – http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

DMARC = Domain-based Message Authentication, Reporting and Conformance – http://en.wikipedia.org/wiki/DMARC

Wozu?

Alle 3 Methoden helfen, dass die Gegenstelle (Mailempfänger) überprüfen kann ob der Absender (Server) der Email authorisiert ist, Emails unter dieser Domain zu versenden.

Was braucht man dazu und wie funktionierts?

  • opendkim (=milter für Postfix)
  • dns TXT Records

Wird eine Email verschickt hängt der opendkim Dämon (ACHTUNG: nicht mehr dkim-filter verwenden, wird nicht mehr weiterentwickelt) an jede ausgehende Email einen Key an. D.h. er signiert jede Email einer Domain für die er authorisiert ist mit dem hinterlegten Schlüssel.

Dieser Key wird dann vom Empfänger überprüft indem er den entsprechenden DKIM TXT Record (mail._domainkey.domain.tld. IN TXT “v=DKIM1; …”) aus dem DNS abruft und die Signatur prüft.

Zusätzlich kann der Empfänger auch prüfen ob der Versenderserver vom Domaininhaber authorisiert wurde, Emails für diese Domain zu versenden. Dies geschieht indem er den SPF TXT Record (domain.tld. IN TXT “v=spf1 ….”) überprüft. Dort ist z.B. hinterlegt, welcher Mailserver mit welchen Hostnamen und welchen IP Adressen Mails verschicken darf.

Zuletzt kann der Empfänger über den DMARC TXT Record (_dmarc.domain.tld. IN TXT “v=DMARC1; …”) eine Regel einholen, wie er denn mit den Emails verfahren soll, die die Prüfung nicht bestanden haben (z.B. von einem Host geschickt, der im SPF Record nicht erlaubt ist oder die DKIM Signatur nicht überprüft werden konnte).

ran ans Eingemachte – die Konfiguration

Um die zusammengehörigen Konfigurationseinstellungen besser ersichtlich zu machen wurden einzelne zusammengehörige Teile farblich markiert. z.B. die Domain, der Selektor, usw. …

Konfiguration opendkim Daemon

Wie bereits beschrieben sind die Rahmenbedingungen eine funktionierende postfix Installation und voller Zugriff auf die DNS Einträge einer Domain (zum Anlegen von TXT Records).

Installation des opendkim Pakets (debian):

root@shmail:/etc# apt-get install opendkim

Nun muss für den opendkim Daemon und für Postfix noch die Schnittstelle konfiguriert werden, über die beide miteinander kommunizieren. Dies geschieht im /etc/default/opendkim Konfigurationsfile:

root@shmail:/etc/default# cat opendkim
# 20141108 leo.eibler add listener
SOCKET="inet:8891@localhost" # listen on loopback on port 8891

In diesem Beispiel hört der opendkim Daemon auf den localhost Socket Port 8891.

Dazu passend muss nun postfix im Konfigurationsfile /etc/postfix/main.cf konfiguriert werden:

root@shmail:/etc/postfix# cat main.cf
...
# 20141108 leo.eibler add DKIM support
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Die Konfigurationsdatei des opendkim Pakets selbst liegt in /etc/opendkim.conf . Hier sind nun einige Anpassungen durchzuführen:

root@shmail:/etc# cat opendkim.conf
# Log to syslog
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes
# Required to use local socket with MTAs that access the socket as a non-privileged user (e.g. Postfix)
UMask                   002

# 20141109 leo.eibler this is a multidomain setup (use different keys for different domains)
# run command for each domain to generate keys:
#   cd /etc/mail
#   opendkim-genkey -r -s mail -d otherdomain.com
#   mv mail.private otherdomain.com.dkim.private
#   mv mail.txt otherdomain.com.dkim.txt
#   chmod ugo+r otherdomain.com.dkim.*
#   /etc/init.d/opendkim restart
# add TXT record to dns from file otherdomain.com.dkim.txt
# append domain to these 2 files:
KeyTable                /etc/mail/DkimKeyTable
SigningTable            refile:/etc/mail/DkimSigningTable

Nach der Konfiguration des opendkim Pakets müssen die entsprechenden Signatur Einträge für die jeweilige Domain erzeugt werden. Hierzu gibt es das opendkim-genkey tool, welches im opendkim Paket mitinstalliert wird:

root@shmail:/etc/mail# opendkim-genkey -r -s mail -d domain.tld

Nach der Ausführung des Kommandos finden sich 2 neue Dateien im Verzeichnis /etc/mail:

  • mail.private = enthält den Schlüssel mit dem die versendete Email vom opendkim/postfix Gespann signiert wird
  • mail.txt = enthält den TXT DNS record mit der Signatur, die vom Empfänger geprüft werden kann

Nun muss opendkim noch mitgeteilt werden, wie es die Keys findet. Der erste Schritt dazu ist die SigningTable Datei. Sie enthält das Mapping von Versender Adresse (FROM: ….@domain.tld) zu Keyfile das für die Signatur verwendet wird:

root@shmail:/etc/mail# cat /etc/mail/DkimSigningTable
# format:
#   $pattern    $keyname
*@domain.tld             domain.tld
*@otherdomain.tld        otherdomain.tld

Der Einfachheit halber wird der keyname gleich wie der Domainname gewählt. Hier könnte man z.B. auch 2 Domains mit dem selben Key signieren, indem der gleiche keyname verwendet wird.

Die zweite Konfigurationsdatei KeyTable enthält mehrere Komponenten:

  • den Verweis auf die Datei mit der Signatur (die Datei mail.private mit opendkim-genkey erstellt wurde):
  • die Domain für die signiert wird
  • den Selektor der vom Empfänger in der DNS Abfrage verwendet wird um die Signatur zu überprüfen
root@shmail:/etc/mail# cat /etc/mail/DkimKeyTable
# format:
#   $keyname    $domain:$selector:$keypath
domain.tld               domain.tld:mail:/etc/mail/domain.tld.dkim.private
otherdomain.tld          otherdomain.tld:mail:/etc/mail/otherdomain.tld.dkim.private

Nach Abschluss der Konfiguration (oder hinzufügen einer Domain) muss der opendkim Daemon neu gestartet werden:

root@shmail:/etc# /etc/init.d/opendkim restart

Häufige Fehler:

  • Die Signaturdatei kann aufgrund der Dateirechte von opendkim nicht gelesen werden (chmod ugo+r … oder chown postfix …)
  • opendkim wurde nicht neugestartet: /etc/init.d/opendkim restart
  • postfix wurde nicht neugestartet: /etc/init.d/postfix restart

Konfiguration DNS Records

Nach der Konfiguration des opendkim Daemons wird nun jede Email von Postfix entsprechend um eine DKIM Signatur ergänzt. Nun fehlen die DNS Einträge, mit denen der Empfänger nun den Versender überprüfen kann.

DNS: Sender Policy Framework (SPF)

Hierzu ist im DNS Zone Record (in diesem Beispiel bind) ein entsprechender TXT Record für die Domain einzurichten:

; TXT records for SPF
domain.tld. IN TXT  (
	 "v=spf1 mx a ip4:10.1.1.40/29 ip4:192.168.0.64/29 "
	 "a:www.domain.tld a:subdomain.domain.tld "
	 "include:mail.hoster.tld"
	 )

Was bedeuten diese Angaben im SPF Record?

  • Der TXT record wird durch die Angabe v=spf1 als SPF Version 1 Record identifiziert
  • mx und a bedeuten, dass der in den MX Records eingetragene Mailserver und die Domain selbst berechtigt ist Emails zu versenden
  • Die beiden ip4:…. Einträge bedeuten, dass Server mit einer IP Adresse in den angegebenen Subnetzen berechtigt sind, Emails für diese Domain zu versenden. Es können durch Hinzufügen mehrerer ip4 Abschnitte mehrere IP Nutze angegeben werden (in diesem Beispiel 2). Hier müssen z.B. die IP Adressen der Mailrelays des Hosters eingetragen werden
  • Die a:<subdomain>.domain.tld Einträge erlauben das Versenden von Mails von den angegebenen Subdomains. Auch hier sind mehrere Einträge für mehrere Subdomains erlaubt
  • Die include:<andere Domain> Einträge fügen weitere Domains bzw. Hosts hinzu, denen es erlaubt ist, Emails zu versenden. Hier wird z.B. das Mailrelay des Hosters eingetragen. Auch hier sind mehrere Einträge für mehrere andere Domains erlaubt

Häufige Fehler:

  • Der Punkt nach dem Domainnamen fehlt: domain<PUNKT>tld<PUNKT> IN TXT ”….”
  • Der TXT Record ist zu lange. Hier in diesem Beispiel wurde der TXT Record auf mehrere Zeilen aufgetrennt. Die Syntax hierfür lautet: Klammer auf ( danach in Anführungszeichen “erster Teil<Leerzeichen>” danach nächste Zeile in Anführungszeichen “zweiter Teil” usw. und abschließend Klammer zu ). Wichtig hierbei: Die Leerzeichen innerhalb der einzelnen in Anführungszeichen eingeschlossenen Abschnitte nicht vergessen: “erster Teil” “zweiter Teil” wird sonst zu “erster Teilzweiter Teil” zusammengesetzt.
  • Die Serial Number des Zone Records wurde nicht erhöht
  • Die Ablaufzeit des Zone Records ist sehr hoch gesetzt und die anderen Server haben die Änderungen noch nicht mitbekommen

DNS: Domain Key Identified Mail (DKIM)

Für das DKIM Signatur Verfahren sind ebenfalls im DNS Zone Record (in diesem Beispiel bind) ein entsprechender TXT Record für die Domain einzurichten:

mail._domainkey.domain.tld. IN TXT  (
	 "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvkDET02OqKcvgkpSxRvGMVzqwj5fxNFcuLWhLCcMsdx7hxlquRppBjbirvEV0HgRHS/za+KKp45edd4qBeChASEbJJ2NpNGIyL+Jy0jmpCK1E5AZKopjSLnSMo78lkaZDj/t5XRqj0qhnldUgtOGj6M8PHvN7AH9UBpXxhXAe1QIDAQAB"
	 )

Nun ist der Selektormail” wichtig, der in der opendkim Konfiguration angegeben wurde:

  • siehe opendkim-genkey -r -s mail -d domain.tld Aufruf mit -s mail = Selektor “mail
  • siehe Konfigurationsdatei KeyTable mit domain.tld domain.tld:mail:/etc/mail/domain.tld.dkim.private = Selektor :mail:

Der TXT Record wird also mit mail._domainkey.domain.tld. angelegt.

Was bedeuten diese Angaben im DKIM Record?

  • Der TXT record wird durch die Angabe v=DKIM1 als DKIM Version 1 Record identifiziert
  • Das Verschlüsselungsverfahren RSA wird mit k=rsa festgelegt
  • Der Schlüssel zum Überprüfen wird mit p=<key> festgelegt. Dies ist der Schlüssel der durch opendkim-genkey in der mail.txt Datei erzeugt wurde

Häufige Fehler:

  • Der Punkt nach dem Domainnamen fehlt: mail<PUNKT>_domainkey<PUNKT>domain<PUNKT>tld<PUNKT> IN TXT ”….”
  • Der Selektor (hier im Beispiel mail) ist falsch bzw. stimmt nicht mit der opendkim Konfiguration überein
  • Serial Number oder Caching des Zone Records

DNS: Domain-based Message Authentication, Reporting and Conformance (DMARC) Richtlinie

Die DMARC Richtlinie sagt dem Empfänger, wie er denn mit einer Email die nicht die Prüfungen für SPF und/oder DKIM bestanden hat umzugehen hat.

Die DMARC Richtlinie wird ebenfalls im DNS Zone Record (in diesem Beispiel bind) über einen entsprechenden TXT Record für die Domain veröffentlicht:

_dmarc.domain.tld. IN TXT “v=DMARC1; p=quarantine; rua=mailto:postmaster@domain.tld”

Der TXT Record wird also mit _dmarc.domain.tld. angelegt.

Was bedeuten diese Angaben in der DMARC Richtlinie?

  • Der TXT record wird durch die Angabe v=DMARC1 als DMARC Version 1 Record identifiziert
  • Die Angabe p=quarantine bedeutet, dass eine Email die nicht die Prüfungen besteht entsprechend markiert (z.B. als Spam) werden soll. Weitere Alternativen hierzu wären p=none – dies wird als TEST Mode bezeichnet (der Empfänger prüft zwar ignoriert aber das Ergebnis und behandelt die Domain wie wenn keine SPF und DKIM Records existieren würden). Die härteste Variante ist mit p=reject anzugeben – Emails werden bei fehlerhafter Überprüfung abgewiesen
  • An die im optionalen Parameter rua=<Email-Adresse> angegebene Email Adresse wird täglich ein XML Report versendet mit einer Zusammenfassung über die fehlerhaften Emails die beim Empfänger eingelangt sind

Weitere Parameter und Angaben finden sich auf der DMARC Webseite: http://www.dmarc.org

Häufige Fehler:

  • Der Punkt nach dem Domainnamen fehlt: _dmarc<PUNKT>domain<PUNKT>tld<PUNKT> IN TXT ”….”
  • Es ist der Test Modus aktiv p=none
  • Serial Number oder Caching des Zone Records

Testen der Einrichtung

Testen der DNS Konfiguration

Zuerst kann die DNS Einrichtung der TXT Records z.B. mit dig oder nslookup überprüft werden (alle Ausgaben gekürzt).

Überprüfen des DNS Servers ns1.hoster.tld auf dem die TXT Records für die Domain angelegt wurden – SPF:

root@soyuz:~# dig @ns1.hoster.tld. TXT domain.tld
; <<>> DiG 9.7.3 <<>> @ns1.hoster.tld. TXT domain.tld
domain.tld. 21600 IN TXT  "v=spf1 mx a ip4:10.1.1.40/29 ip4:192.168.0.64/29 a:www.domain.tld a:subdomain.domain.tld include:mail.hoster.tld"

Man sieht hier schön, dass die einzelnen Teile in Anführungszeichen zusammengefügt wurden und als ein ganzer Block ausgegeben werden. Hier kann man nun kontrollieren ob man z.B. ein Leerzeichen in einem Block vergessen hat.

Überprüfen des DNS Servers ns1.hoster.tld auf dem die TXT Records für die Domain angelegt wurden – DKIM:

root@soyuz:~# dig @ns1.hoster.tld. TXT mail._domainkey.domain.tld
; <<>> DiG 9.7.3 <<>> @ns1.hoster.tld. TXT mail._domainkey.domain.tld
mail._domainkey.domain.tld. 21600 IN TXT  "v=DKIM1\; g=*\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvkDET02OqKcvgkpSxRvGMVzqwj5fxNFcuLWhLCcMsdx7hxlquRppBjbirvEV0HgRHS/za+KKp45edd4qBeChASEbJJ2NpNGIyL+Jy0jmpCK1E5AZKopjSLnSMo78lkaZDj/t5XRqj0qhnldUgtOGj6M8PHvN7AH9UBpXxhXAe1QIDAQAB"

Überprüfen des DNS Servers ns1.hoster.tld auf dem die TXT Records für die Domain angelegt wurden – DMARC:

root@soyuz:~# dig @ns1.hoster.tld. TXT _dmarc.domain.tld
; <<>> DiG 9.7.3 <<>> @ns1.hoster.tld. TXT _dmarc.domain.tld
_dmarc.domain.tld. 21600  IN      TXT     "v=DMARC1\; p=quarantine\; rua=mailto:postmaster@domain.tld"

Testen der Mail Konfiguration

Verschicken einer Email von der jeweiligen Domain an einen Test Service wie z.B. check-auth@verifier.port25.com

root@test:~# echo "Dies ist ein Test" | mail -s "test email" check-auth@verifier.port25.com -- -f postmaster@domain.tld

Nun sollte auf der Absender Email Adresse postmaster@domain.tld eine Antwort eintreffen die hoffentlich so aussieht:

...
==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham
...

Falls bei SPF, DKIM und Sender-ID jeweils pass steht funktioniert die Konfiguration.

Gratulation! gmail signiert durch domain.tld
Gratulation! gmail signiert durch domain.tld

Eine Prüfung ist auch einfach mittels gmail möglich.

Hat alles geklappt zeigt gmail Signiert durch: domain.tld

 

 

Gratulation!

Über den Autor

Ing. Leo Eibler ist hauptberuflich im Bereich Beratung und IT Service Management tätig. Neben seiner beruflichen Tätigkeit entwickelt er Webapplikationen und kümmert sich auf freiwilliger Basis um den Betrieb von diversen Servern.

http://www.eibler.at/

Ähnliche Artikel:

Mit Bash prüfen ob das eigene Script gerade läuft

Die Problemstellung

Ein Script soll alle x Minuten laufen und eine bestimmte Tätigkeit auf dem Server ausführen.

Nun kann es vorkommen, dass das Script aber länger braucht als die Zeitspanne bis zum nächsten Aufruf desselben Scripts (z.B. Kopier und Backup Jobs, Mails abholen, …)

Natürlich sollte so ein Script dann nicht ein 2tes Mal gestartet werden sondern die Ausführung übersprungen werden. Zu diesem Zweck möchte ich hier ein kleines Bash Script zeigen, das genau diesen Zweck erfüllt.

Die Lösung

#!/bin/bash
#
# testpid.sh - demo script to show how to check if a script
# with the same name is currently running
#
# by Leo Eibler
# resources:
#    http://www.eibler.at
#    http://leo.sprossenwanne.at
#    http://www.nullpointer.at
#

# PID - pid of the current script
PID=$$
# SCRIPTNAME - current name of the script without directory prefix
SCRIPTNAME=`basename $0`
# PIDFILE - where to write the current pid
PIDFILE=/tmp/$SCRIPTNAME.pid

# ENDEXECUTION - if 1 then stop script, if 0 everything is ok and continue
ENDEXECUTION=0

if [ -f "$PIDFILE" ]
then
    RUNNINGPID=`cat "$PIDFILE"`
    echo "got pid from $RUNNINGPID from pidfile '$PIDFILE'"
    PROGRAMPID=`ps -e | grep "$SCRIPTNAME" | grep -v grep | awk '{print $1;}'`
    for PIDEL in $PROGRAMPID
    do
        echo "testing pid of running scripts '$PIDEL' == '$RUNNINGPID' from pidfile"
        if [ "$PIDEL" == "$RUNNINGPID" ]
        then
            echo "found PID $RUNNINGPID current running - end execution"
            ENDEXECUTION=1
            break
        fi
    done
fi

if [ "$ENDEXECUTION" == "1" ]
then
    echo "Current script '$SCRIPTNAME' already running (pid $RUNNINGPID) - end execution"
    exit 1
fi
# writing PID to pidfile
echo $PID > $PIDFILE

#
# ---- START ----
#

echo "do your stuff here ..."
sleep 5
echo "... end script"

#
# ---- END ----
#

# delete pidfile
rm $PIDFILE
exit 0

Die Erklärung

Zuerst holt sich das Script den eigenen Namen mit basename $0 ($0 würde ebenfalls den Pfad des Scriptaufrufs enthalten aber hier würde der spätere Aufruf von ps bzw. das automatische Erstellen und Auslesen des passenden pid-Files scheitern).

Mit dem Namen des Scripts wird dann versucht ein pid-File (welches die Process-ID des aktuell laufenden Scripts enthält) auszulesen. Der Pfad des pid-Files kann beliebig gewählt werden, jedoch muss das Script natürlich Schreibrechte auf die Datei besitzen.

Falls kein pid-File existiert kann das Script davon ausgehen, dass es derzeit nicht bereits läuft und seine eigentliche Arbeit aufnehmen.

Falls jedoch ein pid-File vorhanden ist, wird dieses ausgelesen und mit allen derzeit laufenden Process-IDs von Prozessen mit dem gleichen Namen wie das Script verglichen.

Wird hierbei eine Übereinstimmung gefunden, dann läuft das Script bereits und durch Setzen der Variable $ENDEXECUTION auf 1 wird der Abbruch signalisiert.

Dieser Vergleich mit den Process-IDs von Prozessen die bereits laufen ist deswegen wichtig, da es ja sein könnte, dass das Script beim vorherigen Aufruf zwar ein pid-File angelegt hat, aber danach abgebrochen wurde (z.B. manuell durch den Benutzer) und das pid-File dadurch nicht gelöscht wurde.

Ist die Überprüfung auf eine laufende Instanz negativ, muss zuerst das pid-File angelegt werden (Die Variable $$ enthält die pid des aktuellen Prozesses).

Nach Beendigung der Arbeit sollte danach das pid-File wieder gelöscht werden um einen sauberen Abschluss zu bilden.

Das Script als Download gibts hier.

 

Ähnliche Artikel:

Mehrsprachigkeit WordPress Plugins

Aus aktuellem Anlass (Erstellung meines ersten WordPress Plugins GarageSale) habe ich mich auch mit dem Thema Multilingualität und Übersetzungen auseinandergesetzt (Jetzt weiß ich auch woher I18N kommt – 18 Buchstaben zwischen i und n im Wort internationalization ;-)

Grundsätzlich muss die zu übersetzende WordPress Komponente natürlich die Funktionen __(„text“,“domain“) oder _e(„text“,“domain“) verwenden. Siehe hierzu I18N for WordPress Developers.

WordPress stellt für die Übersetzung einige Werkzeuge auf dem Subversion Host bereit. Aber zunächst einmal ein Schritt nach dem Anderen.

Schritt 1 – Download der Tools für Windows

Da ich auf den Clients Windows einsetze habe ich mich dazu entschlossen auch die Entwicklungswerkzeuge für Windows (in meinem Fall noch das gute alte Windows XP aber es sollte keinen Unterschied machen) einzusetzen  und zu beschreiben.

Wir beginnen also mit dem Download von folgenden Komponenten:

Und danach installieren wird zunächst einmal alle 4 Programme mit dem Windows Installer.

Schritt 2 – gettext und php einrichten

Damit die Gettext Werkzeuge funktionieren sollten Sie noch zum Windows Pfad hinzugefügt werden. Dies kann man entwededer dauerhaft machen unter Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen oder aber direkt vor dem Aufruf des Übersetzungswerkzeugs in der Commandshell.

Ich habe gettext einfach in das Standardverzeichnis c:\Programme\GnuWin32 installiert. Da die Utilities im Unterverzeichnis bin liegen muss also der vollständige bin Pfad hinzugefügt werden:

c:\Programme\GnuWin32\bin

Wie gesagt die Alternative lautet, direkt vor dem Aufruf der Übersetzungstools den Pfad in der Commandline mittels set PATH=%PATH%;c:\Programme\GnuWin32\bin hinzufügen.

Analog zu gettext wird dies mit PHP gemacht. Also falls php in das Standard-Verzeichnis c:\Programme\php installiert wird, dann muss dieses ebenfalls zur Umgebungsvariable Path hinzugefügt werden.

Schritt 3 – Entwicklerwerkzeuge von WordPress aus SVN holen

Um mit der Übersetzung zu beginnen benötigt man jetzt die Entwicklerwerkzeuge von WordPress. Diese holt man sich mittels Subversion (in unserem Fall komfortabel mit dem Tool tortoiseSVN) von der Adresse http://i18n.svn.wordpress.org/tools/trunk

Hierzu erstellt man am Besten ein leeres Verzeichnis (z.B. c:\Work\wp-i18n\) und dort drückt man die rechte Maustaste und wählt SVN Checkout. Im darauffolgendem Tortoise Fenster gibt man unter URL of repository http://i18n.svn.wordpress.org/tools/trunk und drückt auf OK.

Schritt 4 – WP i18n tool starten

Nach dem Checkout befinden sich jetzt die WordPress i18n Übersetzungs Tools im Verzeichnis c:\Work\wp-i18n. Wir öffnen nun ein Commandline Fenster und wechseln in diesen Ordner (wichtig, falls oben in Schritt 2 die Methode mit der dauerhaften Pfad Anpassung gewählt wurde, darf ein jetzt bereits schon offenes Commandline Fenster nicht weiterverwendet werden, da sich die Umgebungsvariablen Änderung nicht auf bereits geöffnete Fenster auswirkt!

Eine Eingabe des Kommandos xgettext sollte nun eine Informationszeile auswerfen ebenso wie eine Eingabe des Befehlst php -v. Falls dies nicht funktioniert, nochmal zurück zu Schritt 2 und prüfen ob die Pfade auch wirklich korrekt gesetzt wurden.

Nun kann die Übersetzung eines Plugins gestartet werden. Zu diesem Zweck muss folgendes Kommando ausgeführt werden: php makepot.php wp-plugin <Pfad des WordPress Plugins>

wp-plugin steht hierfür für den Typ des zu übersetzenden Objekts (in diesem Fall ein WordPress Plugin).

In diesem Beispiel übersetze ich mein eigenes Plugin welches sich im Pfad y:\ktzv-fischamend.at\www\wp-content\plugins\garagesale befindet.

Nach dem Fehlerfreien Durchlauf des makepot.php Scripts (zu erkennen an keiner Ausgabe) befindet sich nun eine pot Datei mit dem Namen des Plugins im aktuellen Verzeichnis (in diesem Beispiel garagesale.pot).

Schritt 5 – Mit POEdit die POT Sprach Datei editieren

Nun starten wir das Programm POEdit und öffnen die pot Datei. Um sie zu öffnen muss der Dateityp Filter auf *.* gestellt werden.

Nach dem Laden der pot Datei kann sofort mit dem Übersetzen begonnen werden. In der linken Spalte sind immer die Original (englischen) Begriffe zu sehen und in der rechten Spalte die bereits übersetzten (deutschen) Begriffe. Man wählt einfach den zu übersetzenden Begriff aus und tippt die Übersetzung in das unterste der Eingabefelder.

Vor dem Speichern sollten jetzt noch die Katalog Optionen angepasst werden. Diese finden sich unter dem Menüpunkt Katalog -> Optionen. Wird auf Deutsch übersetzt sollte nicht nur bei Sprache „German“ sondern auch bei Land „GERMANY“ ausgewählt werden (der Ländercode für Deutsch lautet nämlich üblicherweise de_de und nicht de_at, weil man übersetzt üblicherweise nicht extra ins Österreichische – obwohl das sicher witzig wäre ;-)

Nach dem Speichern findet sich dann zusätzlich zur geänderten Quellsprachdatei garagesale.pot (die jetzt auch die deutschen Übersetzungen enthält) eine Datei namens garagesale.mo. Dies ist die Datei, die für WordPress notwendig ist um das Plugin dann in der korrekten Sprache anzuzeigen.

Wie in dem Screenshot zu sehen, muss diese .mo Datei mit dem richtigen Namen in das Plugin Verzeichnis kopiert werden: <PluginName>-<Länder-und-Sprach-Code>.mo (in diesem Beispiel garagesale-de_DE.mo).

Schritt 6 – Hinzugekommene Begriffe und erneute Übersetzung

Wie das so ist, kommt man nach der fertigen Übersetzung drauf, dass man doch noch eine Funktionalität vergessen hat. Zu diesem Zweck muss man natürlich nochmals das makepot.php Script aus Schritt 4 starten. ABER VORSICHT!

Vor dem erneuten Start muss unbedingt die bereits übersetzte .pot Datei umbenannt werden in z.B. garagesale-translated.pot – Das Extraktionsscript überschreibt kommentarlos eine eventuell bereits bestehende <pluginname>.pot Datei!

Nach erneuter Erstellung der garagesale.pot Datei (in der sich nun auch die zusätzlichen, noch nicht übersetzten Begriffe befinden, können nun mit dem gettext Tool msgmerge die beiden .pot Dateien gemerget werden:

msgmerge -N [bereits-übersetzte-pot-Datei.pot] [neu-generierte-pot-datei.pot] > neue-Pot-Datei.pot

Nun befindet sich im aktuellen Verzeichnis eine Datei namens garagesale_new.pot die wieder mit POEdit um die zusätzliche Begriffe ergänzt werden kann und anschließend muss wieder die .mo Datei entsprechend der oben genannten Namenskonvention in das Plugin Verzeichnis kopiert werden.

 

 

Ähnliche Artikel:

pfSense 2.0 virtuelle IP Adressen

In der neuesten pfSense Release (Version 2.0) gibt es endlich eine Unterstützung um virtuelle IP Adressen (VIPs) direkt in der GUI anzulegen.

Jedoch ist dies nicht ganz so einfach wie es auf den ersten Blick scheint.

Grundsätzlich ist einmal zu unterscheiden ob man eine zusätzliche WAN oder LAN IP Adresse anlegen will.

Zusätzliche WAN IP Adresse

Beispielsweise man besitzt den IP Adressbereich 203.0.113.88/29 – dann wäre die erste nutzbare IP Adresse 203.0.113.90 – nehmen wir an auf diese Adresse würde auch das WAN Interface eingestellt werden. Voraussetzung hierfür ist natürlich, dass bereits ein entsprechendes Gateway mit der IP Adresse 203.0.113.89 existiert (z.B. das Modem des Providers).

Um nun die nächste IP Adresse 203.0.113.91 für beispielsweise ein Portforwarding zu verwenden, ist es notwendig eine VIP anzulegen.

Um eine zusätzliche WAN IP Adresse anzulegen startet man im Menüpunkt Firewall-> Virtual IPs:


Hier fügt man im Reiter Virtual IPs mit dem + Symbol einen neuen Eintrag hinzu.

Wichtig hierbei ist natürlich die Auswahl des Typs IP Alias und die richtige Angabe der Subnetzmaske (/29).

Nun kann die zusätzliche IP Adresse unter Firwall -> NAT für ein Portforwarding verwendet werden:

Zusätzliche LAN IP Adresse (2tes LAN Subnetz)

Angenommen man hätte 2 LAN Subnetze:

192.168.0.0/24 = primäres Subnetz (pfSense LAN static IP=192.168.0.1)

10.1.1.0/24 = sekundäres Subnetz

Um aus dem 10er Subnetz ebenfalls Internetzugriff zu haben bzw. ein Portforwarding in das 10er Subnetz durchzuführen bedarf es nun ein wenig mehr Aufwand.

Zuerst beginnen wir wieder mit dem Zuweisen einer Virtuellen IP Adresse unter Firewall -> Virtual IPs:

Hierbei ist wieder zu beachten:

Typ: IP Alias

Interface: Natürlich LAN

Adresse: Hier wird die IP Adresse unter der die Firewall erreichbar sein soll angegeben – aber Achtung: Die Subnetzwmaske muss die Netzwerk Subnetzmaske sein (also in unserem Fall /24 = 255.255.255.0)

Mit dieser Konfiguration kommt aber pfSense bei der automatischen Erstellung der NAT Regeln nicht klar – diese müssen nun manuell unter Firewall -> NAT -> Reiter Outbound erstellt werden.

Hierbei ist der Punkt Manual Outbound NAT rule generation auszuwählen. Nach Bestätigung mit dem Button Save werden automatisch entsprechende Regeln erzeugt (unter Umständen finden sich hierbei Regeln für einzelne Hosts die dann zu löschen sind).

Damit die Regeln berücksichtigt werden, muss unter Outbound NAT die Option Manual Outbound NAT rule generation aktiviert werden!

Grundsätzlich jedoch sollte eine Regel für das primäre LAN Netz erstellt worden sein:

Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 192.168.0.0/24 * * * * * NO Auto created rule for LAN to WAN

Nun ist eine manuelle Regel auf Basis der bestehenden Auto created rule durch den + Button daneben zu erstellen:

Hierbei ist zu beachten, das Source Netzwerk wieder mit der korrekten Netzwerk Maske anzugeben und für das Interface natürlich WAN auszuwählen.

Nach Bestätigen mit dem Save Button sollten sich nun 2 Outbound NAT Regeln in der Liste finden:

Damit der Internet Zugriff aus dem 10er Subnetz auch klappt muss dieses noch in den Firewall Regeln unter Firewall -> Rules -> Reiter LAN erlaubt werden. Hierzu wird basierend auf der bestehenden Regel für das (primäre) LAN net mit dem + Button daneben eine neue Regel erstellt:

Ab nun sollte der Zugriff auf das Internet aus dem 10er Subnetz klappen.

Portforwarding auf eine Virtuelle LAN IP

Ebenso ist es möglich ein Portforwarding auf einen Server (z.B. 10.1.1.100) im 10er Subnetz einzurichten.

Hierzu wird einfach eine neue Regel unter Firewall -> NAT -> Reiter Port Forward erstellt:

In diesem Beispiel wird sogar von der virtuellen WAN IP ein Portforwarding auf einen Server der sich im virtuellen LAN Subnetz befindet erstellt.

 

 

Ähnliche Artikel:

  • Noch keine vorhanden.