Kurztipp: opendmarc und Probleme mit dem Mailversand via client

Im Zusammenhang mit spf, dkim, dmarc und opendmarc:

IgnoreAuthenticatedClients true

in der /etc/opendmarc.conf hat geholfen damit auch Thunderbird wieder mails verschicken durfte wenn man

RejectFailures true

eingetragen hat.

IgnoreAuthenticatedClients If set, causes mail from authenticated clients (i.e., those that used SMTP AUTH) to be ignored by the filter. The default is „false“.

Informationen zur opendmarc.conf findet man hier.

ok ein kleines Update.

IgnoreAuthenticatedClients true

funktioniert nicht so wie es soll. SMTP Auth wird trotzdem von dmarc ignoriert. Was ich getan habe ist nun den submission Port für Clients zu nutzen und dabei keinen DMARC check durchzuführen. Wäre auch unsinnig.

submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_milters=inet:localhost:12301

Hinter inet:localhost:12301 verbirgt sich DKIM

 

noch ein update:

damit opendmarc auch

IgnoreAuthenticatedClients true

berücksichtigt ist die 1.31er Version erforderlich, z.B. die aus Debian/stretch, bei jessie ist leider nur die 1.30er dabei.

https://packages.debian.org/stretch/amd64/opendmarc/download

https://packages.debian.org/stretch/amd64/libopendmarc2/download

Dadurch braucht man den Eintrag bei submission quasi nicht. Trotzdem ist der Weg über den submission sinnvoll, allein schon wegen der s2s und c2s Trennung.

Danke an Jan für den Hinweis mit der 1.31er Version.

Kurztipp: Debian von 7 zu 8 und roundcube will nicht mehr

PHP mag wohl keine selfsigned Zertifkate mehr ab 5.6. Jedenfalls lief mein roundcube nicht mehr nach dem Upgrade von wheezy zu jessie . Geholfen hat folgendes in die config.inc.php von roundcube einzutragen:

$config['imap_conn_options'] = array(
 'ssl'         => array(
     'verify_peer'       => false,
     'verfify_peer_name' => false,
  ),
);
$config['smtp_conn_options'] = array(
  'ssl'         => array(
      'verify_peer'      => false,
      'verify_peer_name' => false,
  ),
);

Kurztipp: MySQL auf eine andere Partition verschieben (Debian 7)

Montag im Büro und die Data Partition eines MySQL Servers ist fast voll gelaufen.

0. Neue (LVM) Partiton einbinden.

1. Rsync des Datadirs

rsync -avh --progress --stats /var/lib/mysql/ /mnt/mysql/data/

2. MySQL stoppen

3. nochmal rsync

rsync -avh --progress --stats /var/lib/mysql/ /mnt/mysql/data/

4. Verschieben des alten Datadirs und Symlink anlegen

mv /var/lib/mysql /var/lib/mysql_old
ln -s /mnt/mysql/data /var/lib/mysql

5. MySQL starten und fertig

6. Irgendwann mal das mysql_old löschen

Schöner ist natürlich man ändert die Pfade in der my.cnf, aber manchmal muss es einfach schnell gehen. Falls man Apparmor nutzt, anpassen der Pfade nicht vergessen.

Laconica…aehhh StatusNet…aehh nun GNU social geht weiter

Bei StatusNet ist schon lange nichts mehr geschehen. 2013 ist StatusNet quasi zu GNU social geworden. Darauf ist erst mal lange Zeit nichts passiert. Nun scheint aber die Entwicklung weiter zu gehen. Ich habe jedenfalls relativ problemlos von StatusNet 1.1.1 auf gnu social 1.1.3-alpha1 updaten können. Für den Jabberbot sollt man den Wert der Variable PING_INTERVAL in der Datei plugins/Xmpp/lib/xmppmanager.php etwas hoch setzen, bei mir steht er auf 86400. Bedeutet also jeden ‚Tag ein reconnect. Zudem ist startdaemons jetzt kein PHP Skript mehr sondern ein bash Skript. Bekommen kann man die Software unter http://gnu.io/social/resources/code/.

Das ist alles dufte, unglaublich dufte.

 

 

Neue Hardware: CuBox-i4Pro

Als Ablösung für den Raspberry habe ich mir vor einigen Tagen ein CuBox-i4Pro gekauft. Zur Zeit nutze ich noch Openelec als OS, die Images dafür findet man hier. Als nächstes (sobald Zeit) schaue ich mir mal Android an. Die Perfomance ist sehr gut und kein Vergleich zum Raspberry. Plugins wie Apple Trailer, Dokumonster, Mediathek usw. laufen deutlich besser. Auch das Spulen oder herunterladen von Untertiteln läuft spürbar schneller. Nicht besonders erstaunlich und eigentlich auch zu erwarten, denn das Teil kostet schließlich auch ca. 4x soviel wie ein Raspberry.  Der Stromverbrauch liegt bei ca. 3 W bei Last und 1 W im Idle. Wie der Raspberry ist auch der Cubox als always on Device gedacht, also ein richtiges Runterfahren gibt es eigentlich nicht.

CuBox-i-first-562x421

Das Teil hat natürlich auch ein paar Nachteile, jedenfalls mit Openelec als OS. So funktioniert Bluetooth noch nicht, CEC hängt manchmal und ab und an friert das Bild nach Schauen eines Videos ein, das passiert aber relativ selten und bisher noch nie während des Abspielens. Wäre schön wenn das noch behoben werden würde, aber auch kein Problem damit klar zukommen. Vielleicht tauchen manche Probleme auch nur bei mir auf.

Ich hoffe es gibt bald auch raspbmc bzw.  osmc  für den Cubox. Generell gibt es einige images für den cubox. Unter http://blog.ecservices.de/2014/11/03/project-ignition  findet man einen universal Installer. Dabei sind auch  images für Xbian, Suse, Geekbox, Debian, Archlinux usw. Man kann also einiges ohne großen Aufwand ausprobieren.

Als kleines zwischen Fazit nach 1-2 Wochen in Benutzung kann ich eigentlich nur sagen, dass ich recht zufrieden mit dem Teil bin. Ein Raspberry steht zwar daneben bereit um im Notfall einspringen zu können, wurde bisher aber nicht gebraucht.

Sollte meine Tochter mir etwas mehr Zeit gönnen schreibe ich etwas ausführlicher was zu dem Teil, bzw. muss ich auch  Zeit haben mir den Cubox genauer anzuschauen.

 

Update: Mittlerweile läuft mit der Openeelc 5.0er eigentlich alles bis auf CEC. CEC verliert ab und an die Verbindung.

Kurztipp: nagios check_nfssmount

Findet man ganz einfach im Paket nagios-plugins-contrib bei Ubuntu

apt-get install nagios-plugins-contrib

Damit kommen auch eine ganze Reihe anderer nützlicher Plugins mit auf das System z. B.

check_email_delivery, check_drbd, check_cups, check_haproxy, check_backuppc, check_multipath, check_mysql_health und und und

Lohnt auf  jeden Fall, da man sich das zusammensuchen spart.

 

 

Kurztipp: cron für einen bestimmten Benutzer deaktvieren

Eventuell will man einem bestimmten Benutzer das Recht nehmen einen cronjob zu nutzen. Dazu reicht es eine Datei /etc/cron.deny anzulegen und den jeweiligen Benutzer dort einzutragen. Beim nächsten Versuch einen cronjob zu editieren, sollte dann in etwa folgendes kommen:

$ crontab -e
You (www-data) are not allowed to use this program (crontab)

Exisitiert cron.allow wird cron.deny nicht ausgewertet.

genaueres findet man bei man crontab.

nfs cachen mit cachefilesd

Ein kleiner Test zum NFS cachen. Genutzt habe ich cachefilesd dafür.

apt-get install cachefilesd

Konfigurationsdateien sind

/etc/default/cachefilesd

dort

RUN=yes

auskommentieren

und /etc/cachefilesd.conf wo man z.B. den Ort des Caches einstellen und diverse Limits setzen kann.

dir /cache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

Informationen zu den Variablen findet man unter man cachefilesd.conf.
Als nächstes muss das Filesystem auf dem der Cache liegt die user_xattr Option bekommen, z.B.

UUID=4d6b8fab-95f1-49e1-9651-16cbcb611ae6 / ext4 errors=remount-ro, user_xattr   0 1

Ebenso muss der mount Eintrag des nfs shares um die Option fsc ergänzt werden

123.123.123.123://web nfs defaults,rsize=32768,wsize=32768,intr,hard,rw,vers=3,fsc 0 0

in der fstab.

Danach noch ein reboot und nach dem reboot prüfen ob der cachefilesd Daemon läuft

/etc/init.d/cachefilesd status

fertig.

————-
Ein kurzer Exkurs wie man eine Ramdisk als Device nutzt

Nun könnte man natürlich auch eine Ramdisk als cache Device nutzen.
Das bringt noch ein paar Prozent an Geschwindigkeit.
Das fasse ich mal in kurz zusammen:

In der fstab /etc/fstab

tmpfs /media/tmpfs default,tmpfs size=10%	0 0

Wir nutzen 10% des RAMs für unseren Cache.

Einmounten unserer Ramdisk

mount /media/tmpfs

Erstellen eines Files in der Größe der Ramdisk

dd if=/dev/zero of=/media/tmpfs/cache bs=1024

Wir legen uns ein Device an und mounten es auf unseren Cache Ordner, den wir in der /etc/cachefilesd.conf angegeben haben

losetup /dev/loop0 /media/tmpfs/cache
mkfs.ext4 /dev/loop0
tune2fs -m0 /dev/loop0]
mount -o user_xattr /dev/loop0 /cache/

und mit

/etc/init.d/cachefilesd start

starten wir den Daemon.

Das findet ihr alles noch etwas besser beschrieben unter http://bopinions.de/?p=127.
Dort steht auch noch wie man das ganze persistent macht.
Das geht bestimmt auch irgendwie ohne den containerfile. Werde ich mir nochmal anschauen.
————-

Mit

$ cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID FSC
v3 0a6c2008 801 0:21 58be8694:0 yes

kann man prüfen ob fsc auch genutzt wird.

$ cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=9 dat=3553 spc=0
Objects: alc=2610 nal=0 avl=2610 ded=51
ChkAux : non=0 ok=0 upd=0 obs=0
Pages : mrk=60574 unc=20
Acquire: n=3562 nul=0 noc=0 ok=3562 nbf=0 oom=0
Lookups: n=2610 neg=2610 pos=0 crt=2610 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=53 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=3027 ok=0 wt=1796 nod=2967 nbf=60 int=0 oom=0
Retrvls: ops=2967 owt=2389 abt=0
Stores : n=60571 ok=60571 agn=0 nbf=0 oom=0
Stores : ops=10392 run=70963 pgs=60571 rxd=60571 olm=0
VmScan : nos=0 gon=0 bsy=0 can=0 wt=0
Ops : pend=2389 run=13359 enq=70963 can=0 rej=0
Ops : dfr=61 rel=13359 gc=61
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

bringt Statistiken zum Vorschein.

Ob ich das weiter betreibe und wo die Probleme und Vorteile liegen kann ich noch nicht abschätzen. Das wird sich aber im Laufe der nächsten Tage/Wochen zeigen.
Ein wichtiger Punkt ist natürlich wie Änderungen an Dateien erkannt werden bzw. was sie kosten. Eine expire time wie beim nginx cache kann man nicht einstellen.

An Erfahrungen damit bin ich sehr interessiert.

Update 1: noatime und nodiratime sollte man eventuell aus den Mountoptionen nehmen, da diese für das culling genutzt werden.
Update 2: Nach ein paar Tagen hängen sich die Webserver mit cachefilesd aktiviert auf. Der Zusammenhang ist noch nicht klar.

Links:
http://bopinions.de/?p=127
http://blog.lastlog.de/posts/ubuntu_cachefs_experiments/
http://chase-seibert.github.io/blog/2014/03/09/vagrant-cachefilesd.html
http://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/caching/cachefiles.txt
http://www.cyberciti.biz/faq/centos-redhat-install-configure-cachefilesd-for-nfs/
https://blog.yrden.de/2013/10/13/setting-up-nfs-cache-on-debian.html
http://ispire.me/nginx-over-nfs/
http://blog.spekschoor.nl/2012/08/effective-caching-with-nginx-over-nfs.html

N54L als NAS

Die Überlegung war Qnap, Synology oder selbst was bauen. Das Ergebnis der Überlegung war ein HP ProLiant N54L. Für die Entscheidung habe ich relativ lange gebraucht. Qnap (219 und 469) setze ich schon seit Jahren beruflich als zweit Backupsystem ein und war eigentlich immer sehr zufrieden. Ich wollte auch aus diversen Gründen kein System in das ich viel Zeit investieren muss, um es zum Laufen zu bringen. Eigentlich suchte ich nur ein flexibles, wartungsarmes und unabhängiges System auf Linuxbasis und mehr nicht. Der N54L als NAS ist genau das was ich wollte, flexibel unabhängig und günstig.  Günstig bedeutet dabei 177 €. Dafür bekommt man einiges: 2,2 GHz dual Core, 4 GB Speicher, DVD Brenner (wozu auch immer), 4 Bay Gehäuse usw.

n54lEin wichtiger Entscheidungspunkt war auch der Stromverbrauch. Dabei liege ich zur Zeit mit 5 HDs (4 normale + 1 SSD für OS) bei ca. 20 Watt im Idle, 40-50 bei Last und 1 Watt im WOL Zustand. WOL funktioniert außerdem wunderbar, dabei lässt sich das NAS mit jedem Device problemlos aufwecken. Bei XBMC 13 ist WOL direkt integriert und man braucht „eigentlich“ kein Extra Addon. „Eigentlich“ deshalb weil es bisher nur beim ersten mal wecken funktioniert innerhalb einer „Session“. Als Kernel hab ich den  3.14er (http://alexanderduss.de/Share/Kernel/HP_Mircoserver/ danke nochmal) installiert. Als OS nutze ich bisher Openmediavault oder einfacher OMV.  OMV ist gut, es bietet eine überschaubare Weboberfläche und tut was es tun soll. Installation ist ein Kinderspiel und es gibt ein Pluginsystem wie bei anderen NAS Systemen auch. Dabei stehen Plugins für Autoshutdown, Plex, DLNA, rsnapshot, virtualbox, virtualhosts usw. zur Verfügung. Durch Einbinden zusätzlicher Repositories, kann man auf noch mehr  Plugins  zugreifen. Ein Vergleich zu FreeNas und Nas4free fehlt mir, aber ich wollte auch ein Debian basiertes System haben. Darin liegt auch der große Vorteil von OMV. Ein normales Debian (noch squeeze in der 0.5er Version) was man eigentlich nach belieben anpassen kann, aber nicht muss. Sollte das Anpassen überhand nehmen, kommt da einfach ein Debian Wheezy drauf und gut ist, die paar NFS, Samba, DLNA Dienste bekommt man auch via Konsole hin.  Bisher bin ich sehr zufrieden und denke ich werde eine Weile bei OMV bleiben. Ansonsten kann man sogar XPEnology (Synology DSM 5.0) auf dem Teil laufen lassen. Auch die Hardare lässt sich problemlos erweitern: Remote Access Karte, zusätzliche Grafikkarte mehr Speicher (max 16GB).

Nachteile gibt es natürlich auch. Das Teil ist ein bisschen lauter als ein Qnap oder Synology. Es fehlt, jedenfalls bei OMV, eine zeitgesteuerte Startfunktion und  z.B.

rtcwake -m no -t $(date -d 'tomorrow 8:15' +%s)

funktioniert nicht wie erwartet beim N54L (geht zwar an aber nicht wann er soll)  nun auch. Hat mich anfangs etwas gestört, aber eigentlich soll das Teil angehen wenn man es braucht und nicht zu einer bestimmten Uhrzeit und das funktioniert einwandfrei. Die Bootzeit beträgt bei mir ca. 45 Sekunden.
Es gibt keinen Audioausgang, aber das ist zu verkraften.
Der Stromverbauch bei z.B. Qnap (412) ist noch um ein paar Watt niedriger.

Das war es auch schon an Nachteilen aus meiner Sicht. Wer sich auch nur etwas mit Linux auskennt wird  mit dem N54L als NAS keine Probleme haben. Der Durchsatz ist mir relativ egal, aber schaffen tut er mit NFS  locker 100mb/s bei mir.

Ich werde mal versuchen im Laufe der nächsten Monate ein paar Erfahrungen mit dem N54L aufzuschreiben.

 

Die neue Wohnung mit Open Source planen

Da ich bald mit Frau K. in eine gemeinsame Wohnung ziehe, habe ich eine Open Source Lösung zur Planung gesucht. Genauer gesagt zur Innenraum Planung. Relativ schnell bin ich bei Sweet Home 3D gelandet und bin nun seit ein paar Tagen ein Fan dieser Anwendung. Bisher hatte ich nur vor einigen Jahren mal was mit SketchUp gemacht, fand ich ok mehr aber auch nicht.

SweetHome3DLinux

Das Bild ist von der Homepage und zeigt eine Übersicht über die Möglichkeiten des Programms. Sweet Home 3D ist bei Ubuntu 12.04 / 14.04 in den Repositories dabei.

apt-get install sweethome3d

In der 14.04 sind noch weitere Texturen und Modelle dabei. Es macht wirklich Spaß damit die neue Wohnung zu planen und eine Vorstellung über den verfügbaren Platz und Größenverhältnisse zu bekommen. Optimalerweise hat man einen eingescannten Grundriss der Wohnung, den man als Hintergrundbild verwenden kann. Einfach mal anschauen und versuchen die eigene Wohnung nach zubauen. Das Programm ist wirklich eins der Programme wo man ruhig mal donaten sollte.

Kurztipp: Greylisting unter Postfix aktivieren

Unter Debian/wheezy ist postgrey in einer Minute eingerichtet.

apt-get install postgrey

Die /etc/postfix/main.cf um „check_policy_service inet:127.0.0.1:10023“ ergänzen, sieht bei mir dann so aus:

smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023

Bei Debian Wheezy läuft postgrey default auf 10023.
Postfix neu starten

/etc/init.d/postfix restart

Prüfen ob postgrey läuft mit

$ps aux|grep postgr
postgrey 32421  0.0  0.1  67932 14804 ?        Ss   21:51   0:00 /usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023

Will man die Verzögerungszeit von default 300 Sekunden anpassen, kann man dies in der /etc/default/postgrey tun z.B.

POSTGREY_OPTS="--inet=10023 --delay=120"

Schaut man in /var/log/mail.info nach postgrey, sollte man bald Einträge in der Art

...postgrey[32421]: action=greylist, reason=new...

finden.

Will man wissen, wer alles so erfolgreich abgelehnt wurde, kann man z.B. einfach mal

cat /var/log/mail.info|postgreyreport

oder etwas übersichtlicher

cat /var/log/mail.log | postgreyreport --nosingle_line --check_sender=mx,a --show_tries --separate_by_subnet=":===============================================================================================\n"

ausführen.

Es gibt noch die Möglichkeit Ausnahmeregeln zu definieren (whitelist_clients, whitelist_recipients).

Links:
http://de.wikipedia.org/wiki/Greylisting

http://www.debuntu.org/postfix-and-postgrey-a-proactive-approach-to-spam-filtering-page-2/