vnStat: Wieviel Netzwerkverkehr hatte welches Interface

Aus verschiedenen Gründen wollt ich monitoren, wieviel MB Traffic ich bei meinem Notebook so täglich über das UMTS Modem habe.

Gestolpert bin ich da über das Programm-Paket “vnstat”. Es läuft ein kleiner Daemon im Hintergrund und addiert defaultmäßig alle 5 Minuten den Traffic, der über die konfigurierten Interfaces ging und zeichnet diesen in einer Datenbank auf.

Abgefragt ist die Sache einfach mit “vnstat”:

$ vnstat

 rx / tx / total / estimated
 eth0: Not enough data available yet.
 wlan0:
 Dec '14 2.28 MiB / 610 KiB / 2.88 MiB / 0 KiB
 yesterday 2.28 MiB / 610 KiB / 2.88 MiB
 today 0 KiB / 0 KiB / 0 KiB / -- 

 virbr0: Not enough data available yet.
 wwan0:
 Dec '14 142.02 MiB / 89.06 MiB / 231.08 MiB / 2.62 GiB
 yesterday 0 KiB / 0 KiB / 0 KiB
 today 142.02 MiB / 89.06 MiB / 231.08 MiB / 343 MiB

Hier sind also alle Interfaces meines Notebooks aufgeführt, wobei mich eigentlich “wwan0”, wohinter sich das UMTS Modem verbirgt interessiert.

Installation unter Ubuntu 14.04 war auch recht einfach:

sudo apt-get install vnstat

Linux /tmp read-only nachträglich für Arme – ohne getrenntes Dateisystem

Temporär-Verzeichnisse wie /tmp oder /var/tmp auf Linux Rechnern read-only zu haben, kann einen vor den Folgen des einen oder anderen -meist automatischen- “Skriptkiddie” Angriffs schützen.

Im Rahmen einiger dieser Angriffe werden in einem für jedermann beschreibbaren Verzeichnis -also meist /tmp- ein Skript abgelegt, dass von dort ausgeführt wird, um weiteren Schaden zu verursachen.

Wenn dieses Verzeichnis nun mit der Option “noexec” gemounted ist, ist das Ausführen von Dateien dirkt aus dem Verzeichnis immerhin schwieriger. Unmöglich ist es jedoch nicht: Man könnte immer noch den notwendigen Befehlsinterpreter starten und das Skript als Parameter übergeben. Aber es geht hier einfach nur um eine weiter Hürde, die es für wenig Aufwand gibt und um automatische Angriffe, die ohne viel manuellen Zutun von nicht höchst fachlich fähigen Leuten ausgeführt werden.

Gut, ein Dateisystem kann man mit dem Parameter “-o noexec” mounten. – Was aber, wenn nun kein getrenntes Dateisystem für /tmp (und /var/tmp) bereit steht?

Hier lässt sich die Option “mount –bind” nutzen, um ein Verzeichnis in ein anderes zu mounten.

Vorbereitung. Kopien der Verzeichnisse /tmp und /var/tmp anfertigen. z.B. so:

cp -a /tmp /tmp-real
cp -a /var/temp /var/tmp-real

Dann lassen sich die “tmp-real” Verzeichnisse auf die “tmp” Verzeichnisse mounten:

mount -v --bind /tmp-real /tmp
mount -v -o remount,noexec,nosuid /tmp

Probe aufs Exempel:

$ ls -l /tmp
total 4
-rwxrwxr-x 1 testuser user 28 May 7 22:14 test.sh
$ cat /tmp/test.sh 
#! /bin/sh

echo Jaaaaaaaa

$ /tmp/test.sh
bash: /tmp/test.sh: Permission denied

Auch als root läßt es sich nicht ausführen:

~ # id
uid=0(root) gid=0(root) groups=0(root)
~ # /tmp/test.sh
-su: /tmp/test.sh: Permission denied

Jetzt noch alles zusammen: Ein Skript, um die Verzeichnisse read-only zu mounten:

~/bin # cat mount_tmp_noexec.sh
#!/bin/sh

echo noexec  to /tmp
mount -v --bind /tmp-real /tmp && mount -v -o remount,noexec,nosuid /tmp

echo
echo noexec to /var/tmp
mount -v --bind /var/tmp-real /var/tmp && mount -v -o remount,noexec,nosuid /var/tmp

echo 
echo Now mounted:
mount

…und eines das Ganze wieder rückgängig zu machen:

~/bin # cat mount_tmp_exec.sh 
#!/bin/sh

echo Umounting /tmp from noexec
# mount --bind /tmp-real /tmp && mount -o remount,exec,suid /tmp
umount /tmp

echo
echo Umounting /var/tmp from noexec
# mount --bind /var/tmp-real /var/tmp && mount -o remount,exec,suid /var/tmp
umount /var/tmp

echo 
echo Now mounted:
mount

Für das Einspielen von Paketen ist es zu empfehlen /tmp wieder read-write zu haben, da auch die Pakete vielfach Skripte zur Pre- oder Post-Installation dort ablegen und ausführen.

Beim Umounten kann es zu Problemen kommen, wenn Prozesse noch Dateien in dem Verzeichniss geöffnet lassen. Hier mit “lsof” o.ä. nachforschen.

Lokale Kopie des imap-Postfachs mit ssh-Tunnel, offlineimap und dovecot

Auch “offline” eMail lesen

…und zwar unabhängig vom verwendeten MUA (Mail User Agent) oder zu neu-deutsch Mailprogramm.

Verschiedene Mailprogramme bieten zwar oft die Möglichkeit eine offline Kopie es imap-Postfachs anzulegen, doch machen sie dies exklusiv für sich selbst, so dass man, wenn man den MUA wechselt oder mit mehrere parallel verwendet (z.B. KMail, alpine und Thunderbird) n Kopien auf seinem Laptop/ Netbook hat…

Da wollte ich Abhilfe schaffen. Genügen Resourcen für einen imap-Server hat mittlerweile jedes aktuelle Netbook: 1GB RAM, 120Gb Platte sind ja schon Minimum und es geht auch mit weniger. imap “spricht” jedes ernst zu nehmende Mailprogramm, so dass das wohl das optimale “Shared Medium” für eMails ist.

dovecot als lokaler imap-Server

Ich habe mich mit dovecot für einen modernen imap-Server entschieden. Er ist leicht zu konfigurieren und in jeder halbwegs aktuellen Linux-Distribution als Paket verfügbar.

Also dovecot-Paket(e) für dovecot-imap mittels distributionsspezifischem Tool (apt, zypper, yum…) installieren. Dann für den lokalen Gebrauch wie folgt minimal konfigurieren, indem man

/etc/dovecot/dovecot.conf

wie folgt modifiziert bzw. ergänzt:

protocols = imap
# oder wer auch an localhost mit SSL arbeiten möchte:
#protocols = imap imaps

listen = localhost
# ..oder auskommentieren, wenn man die gleichen Probleme wie ich mit KMail hat
# s.a. hier mein Blog-Artikel...
# With listen = localhost KMail can't access the imap-server...
#listen = localhost

disable_plaintext_auth = no

# Ich traue den localhost-Verbindungen ohne SSL
ssl=no

mail_location = maildir:~/Maildir

mail_privileged_group = mail

protocol imap {
}
protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
}
protocol managesieve {
}
auth default {
  mechanisms = plain
 passdb pam {
  }
  userdb passwd {
  }
  user = root
  !include_try /etc/dovecot/auth.d/*.auth
}
dict {
}
plugin {
}
!include_try /etc/dovecot/conf.d/*.conf

offlineimap konfigurieren

offlineimap synchronisiert entweder ein imap-Postfach eines Servers mit einem lokalen Maildir Store oder zwei imap-Postfächer, was wir hier machen wollen.

Lokal haben wir unseren dovecot und den Remote imap-Server binden wir gleich per SSH-Tunnel an. Also die

~/.offlineimaprc

wie folgt sinngemäß mit eigenen Login-Namen etc. erstellen bzw. ergänzen/ modifizieren:

[general]
metadata = ~/.offlineimap.IMAP
accounts = MyImap
maxsyncaccounts = 1
ignore-readonly = no
ui = Blinkenlights

[Account MyImap]
localrepository = LocalMyImap
remoterepository = RemoteMyImap
autorefresh = 60

[Repository LocalMyImap]
type = IMAP
remotehost = localhost
remoteport = 143
maxconnections = 5
remoteuser = mylocallogin
remotepass = SuperGeheim
holdconnectionopen = yes
keepalive = 60

[Repository RemoteMyImap]
type = IMAP
remotehost = localhost
remoteport = 10143
remoteuser = myremotelogin
remotepass = NochGeheimer
maxconnections = 5
holdconnectionopen = yes
keepalive = 60

So wird offlineimap alle 60 Minuten mit fünf Threads parallel die imap-Postfächer LocalMyImap und RemoteMyImap synchronisieren und dies über das Blinkenlights Interface schön darstellen.

ssh-Tunnel für imap

Jetzt muss noch der Remote imap-Server an Port 10143 von localhost verfügbar gemacht werden, wo offlineimap ihn erreichen möchte. – Selbstverständlich ist hier Voraussetzung, dass man Shell-Zugriff per SSH auf seinen imap-Server hat. Sonst muss mal die offlineimp-Konfiguration als Remote-Server auf einen externen Server umstellen (und dann natürlich SSL nicht vergessen)…

Ein einfaches

sudo ssh -f -N -L 10143:localhost:143 remoteuser@imap.remoteserver.tld

macht dies, indem es als User “remoteuser” auf den Server imap.remoteserver.tld verbindet (hier natürlich passenden User und Server einsetzen).

Ich hole mir hier auch noch gleich meinen SMTP-Server durch den SSH-Tunnel auf Port 10025 und nutze autossh (schönes Tool). Also:

sudo autossh -f -N -L 10143:localhost:143 remoteuser@imap.remoteserver.tld -L 10025:localhost:25 remoteuser@smtp.remoteserver.tld

..zwei Fliegen mit einer Klappe.

Ideen für Änderungen…

Ohne Tunnel

Eine mögliche Änderung habe ich oben schon erwähnt: Mit offlimeimap läßt sich natürlich auch mit einem entfernten imap-Server synchronisieren (wenn man z.B. keinen SSH-Tunnel hat oder haben möchte). Dazu einfach in

[Repository RemoteMyImap]

remotehost etc. passend ändern:

remotehost = localhost

und mit

ssl = yes

für Sicherheit sorgen.

…oder mit automatischem SSH-Tunnel

Oder man möchte einen SSH-Tunnel, den offlineimap selber aufbaut, weil man dies nicht “per Pfote” machen möchte. Hier gibt es folgende Optionen in der .offlineimaprc in der :

[Repository RemoteMyImap]

preauthtunnel = ssh -q imap.server.tld

# With on server side ~/.ssh/authorized_keys:
command="/usr/bin/imapd ~/Maildir" ssh-rsa xxxxxxxx(key)

Für Details verweise ich auf die Ergebnisse einer Suche bei der Lieblingssuchmaschine…

KMail/ Kontact mag nicht mehr starten

KMail bzw. KMail als Komponente von Kontact friert schon beim Starten ein

KMail bzw. KMail als Komponente von Kontact friert schon beim Starten ein: Genau das ist einem Freund letztens widerfahren.

Zuvor war KMail schon beim Verfassen einer eMail eingefroren und hat sich beendet bzw. musste beendet werden.

Weitermachen… auch wenn’s weh tut!

Scheinbar schien KMail dann beim erneuten Öffnen die Bearbeitung der “unverdaulichen” eMail fortzusetzen bzw. fortsetzen zu wollen. Damit frohr KMail natürlich wieder ein und und musste wieder beendet werden. :0)

Und täglich grüßt das Murmeltier.

Die Sache würde sich sicherlich weiter so fortsetzen, wenn man nicht manuell etwas unternähme. – z.B. die “unverdauliche” eMail wegräumte.

Weg mit dem Störenfried

Im Unterverzeichnis

.kde/share/apps/kmail/autosave/cur

bzw.

.kde4/share/apps/kmail/autosave/cur

bei openSUSE in des Users Home-Verzeichnis befinden sich die noch nicht fertig gestellten eMails.

In meinem Falle habe ich die dort liegende Datei von dort weg verschoben und konnte dann KMail wieder erfolgreich starten.

 

KMail will nicht IMAP mit Dovecot bei “listen localhost” sprechen

Um auf meinem Netbook unabhängig vom Mail-Client zu sein, habe ich fix Dovecot lokal als Imap-Server installiert und konfiguriert, mit OfflineImap mein Imap-Postfach vom Server synchronisiert und wollte jetzt (auch) mit KMail lokal drauf zugreifen…

Aber im Gegensatz zu Alpine oder Evolution (und natürlich OfflineImap) erzählte KMail mir immer wieder, dass es keine Verbindung zum Imap-Server aufbauen könne!

Alles Mögliche in KMail probiert: Statt “localhost” mal “127.0.0.1” als Imap-Server eingetragen, mal einen weiteren hosts-Eintrag gemacht und diesen genutzt, aber nichts half…

Also Debug-Logging auf Dovecot und tcpdump angeschmissen und siehe da: KMail versuchte sich irgendwie gar nicht richtig an localhost Port 143 anzumelden. Hmm…

Da ich Dovecot nur lokal verwende wollte, sollte der Imap-Daemon dann auch nur lokal lauschen. – Ergo hatte ich:

listen = localhost

in der 

/etc/dovecot/dovecot.conf

gesetzt. Testweise habe ich dann mal

listen *

gesetzt. – Und schwups, KMail zeigte mir mein Postfach an…

Als Workaround habe ich das dann erst mal akzeptiert und noch eine IPChains Regel (mittels ufw) gebaut, dass von außen nicht zugegriffen werden kann…

Da werd’ ich wohl noch ein wenig nach dem wirklichen Grund graben müssen, was KMail hier anders macht als andere (Imap-Clients).

gdebi – Lokale deb Pakete mit ihren Abhängigkeiten installieren

Neulich stand ich mal wieder vor dem Problem, dass ich ein deb Paket heruntergeladen hatte und dieses dann auch gerne installiert hätte, und zwar mit seinen Abhängigkeiten.
Nun können die apt-Tools (apt-get, aptitude und Freunde) aus Repositories (“Repos”) Pakete installieren und dabei die Abhängigkeiten berücksichtigen. Aber für auf der lokalen Platte liegende Pakete ohne Meta-Informationen eines Repos geht’s nicht… – Auch ein lokales Repo kann man selber bauen, aber ich befand das als ein kleines bischen Overkill: Mit Kanonen auf Spatzen…
Dann gibt es natürlich dkpg -i. – Hier muss man aber nun mal per Pfote die für die Abhängigkeiten benötigen Pakete einspielen.

Doch ich fand dann das Tool, was die Nachteile der beiden für diesen Anwendungsfall nicht hat:

gdebi

“man gdebi” meint dazu:
gdebi lets you install local deb packages resolving and installing its dependencies. apt does the same, but only for remote (http, ftp) located packages.

Einziger Wermutstropfen ist, dass gdebi als Parameter nur EIN deb Paket akzeptiert. Wenn man mehrere lokale Pakete hat, dann muss man das ggf. in ihrer möglicherweise vorhandenen Abhängigkeitsreihenfolge machen. – Aber gut, bei zu vielen lokalen Paketen mit Abhängigkeiten untereinander, kann man ja auch ein Repo draus bauen…