Archiv der Kategorie: Memo

Lokaler Mailserver mit Dovecot 2.4.x

Da ich auf jedem Endgerät (vulgo: Laptop, PC) einen dezidierten Mailserver laufen habe, um dort meine Mailmassen einfach zu speichern, brachte mich die Umstellung von Dovecot 2.3.x auf 2.4.x ein wenig in Not und dovecot23 wollte ich nicht installieren.

Hier nun die Doku für einen rein lokalen Mailserver – ausdrücklich ohne jede Verbindung ins Netz!

Neu benötigt wird ein Benutzer vmail:

useradd vmail
usermod -a -G vmail dovecot
usermod -a -G vmail dirk
chown -R dirk:vmail /home/dirk/Maildir/
chmod -R 775 /home/dirk/Maildir

Die Konfigurationsdateien für den lokalen Mailserver sehen nunmehr so aus:

# /etc/pam.d/dovecot
#%PAM-1.0
auth include system-auth
account include system-auth
session include system-auth
password include system-auth

# /etc/dovecot/dovecot.conf
# Dovecot config and storage versions
dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0
ssl = no
auth_mechanisms = plain login
auth_allow_cleartext = yes
auth_username_format = %{user | username }
userdb passwd {
use_worker = yes
}
passdb pam {
session = yes
service_name = dovecot
}
mail_driver = maildir
mail_path = /home/%{user | username}/Maildir
protocols = imap lmtp
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
mail_gid = vmail
mail_uid = vmail

# /etc/postfix/main.cf
# Postfix main.cf for dovecot 2.4.x
compatibility_level = 2
queue_directory = /var/spool/postfix
command_directory = /usr/bin
daemon_directory = /usr/lib/postfix/bin
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = localhost
mydomain =localdomain 
myorigin = $myhostname
inet_interfaces = loopback-only
mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
mynetworks_style = host
alias_maps = lmdb:/etc/postfix/aliases
alias_database = $alias_maps
home_mailbox = Maildir/
mailbox_transport = lmtp:unix:private/dovecot-lmtp
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/bin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /etc/postfix
readme_directory = /usr/share/doc/postfix
inet_protocols = ipv4
meta_directory = /etc/postfix
shlib_directory = /usr/lib/postfix

Dann noch eine /etc/postfix/aliases dazu und es sollte passen.

Mehrere Seiten im PDF auf ein Blatt

Mehrere Seiten in einem PDF auf ein einzelnes DIN A4 Blatt drucken geht teilweise auch mit Viewern / Editoren wie z.B. Master PDF Editor. Schneller geht es auf der Shell:

pdfjam --nup 2x1 --landscape --a4paper in.pdf --outfile out.pdf

Das Programm pdfjam ist Teil von texlive-binextra.

Seitenleistengedöhns

Nachdem ich gerade 10 Minuten brauchte, um eine aus Versehen in Libreoffice gelöste rechte Seitenleiste wieder anzudocken:

Wer den Desktop unter KDE über mehrere Monitore hinweg liegen hat, kann wohl so oft Strg Umschalten F10 drücken, wie er will – es passiert schlicht gar nix. Also darauf achten, dass

nur noch ein Libreoffice Fenster offen ist (also alle Dialogfenster geschlossen sind)
für den Andockvorgang das Hauptfenster von Libreoffce auf den Monitor legen, von dem aus es nicht „weiter nach rechts“ geht.

Und schwupp sitzt sie nach Strg Umschalten F10 wieder am rechten Rand, wo sie auch hingehört.

Shrink VM

Was tut man nicht alles? Ich hab hier eine VM mit W10Edu 20H2, die gelegentlich gestartet wird, um damit z.B. Wireshark zu testen, Updates zu installieren, eine einzelne Datei in MSO anzusehen oder mit W10 Privacy nachzusehen, was ich alles unter Arch nicht erdulden muss.

Trotzdem wuchert das Ding über die Zeit vor sich hin und will gelegentlich geschrumpft werden. Das geschieht hier so:

Erst einmal aus W10 heraus mit sdelete Platz schaffen:

sdelete -z "C:"

Dann die VM runterfahren und mit VBoxManage die VDI komprimieren:

vboxmanage list hdds
vboxmanage modifymedium disk /pfad/zur/vm/w10edu.vdi --compact

Am Schluss nach Geschmack wegsichern mit tar – oder auch nicht.

webm2mp3

Falls ich es erneut vergesse: Die Konvertierung von webm Dateien im aktuellen Verzeichnis nach mp3 mit ffmpeg:

for i in $(ls *.webm) ; do ffmpeg -i "$i" -vn -ab 192k -ar 44100 -y "${i%.*}.mp3"; done

Grubgefummel

Weil wireguard mit dem heute gekommenen Kernel für Ubuntu 18.04 nicht durch den Compiler ging

Unpacking wireguard-dkms (1.0.20200520-0ppa1~18.04) over (1.0.20200520-0ppa1~18.04) ...
Setting up wireguard-dkms (1.0.20200520-0ppa1~18.04) ...
Loading new wireguard-1.0.20200520 DKMS files...
Building for 4.15.0-106-generic
Building initial module for 4.15.0-106-generic
Error! Bad return status for module build on kernel: 4.15.0-106-generic (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200520/build/make.log for more information.
Setting up wireguard (1.0.20200513-1~18.04) ...

und dann in /var/lib/dkms/wireguard/1.0.20200520/build/make.log Derartiges hinterließ

DKMS make.log for wireguard-1.0.20200520 for kernel 4.15.0-106-generic (x86_64)
Wed Jun 10 07:49:21 CEST 2020
make: Entering directory '/usr/src/linux-headers-4.15.0-106-generic'
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/send.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/socket.o
In file included from <command-line>:0:0:
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c: In function ‘send6’:
/var/lib/dkms/wireguard/1.0.20200520/build/compat/compat.h:102:42: error: ‘const struct ipv6_stub’ has no member named ‘ipv6_dst_lookup’; did you mean ‘ipv6_dst_lookup_flow’?
 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, &dst, c) + (void *)0 ?: dst
                                          ^
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c:139:20: note: in expansion of macro ‘ipv6_dst_lookup_flow’
   dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sock), sock, &fl,
                    ^~~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:330: recipe for target '/var/lib/dkms/wireguard/1.0.20200520/build/socket.o' failed
make[1]: *** [/var/lib/dkms/wireguard/1.0.20200520/build/socket.o] Error 1
Makefile:1577: recipe for target '_module_/var/lib/dkms/wireguard/1.0.20200520/build' failed
make: *** [_module_/var/lib/dkms/wireguard/1.0.20200520/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.15.0-106-generic'

wollte ich prüfen, ob ich um den Bug herumkomme, wenn ich den Server mit dem alten Kernel starte.

Ich dachte, das geht so:

Ein

grub-mkconfig | grep -E 'submenu |menuentry '

liefert den Menüeintrag für den älteren Kernel

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
Found linux image: /boot/vmlinuz-4.15.0-101-generic
Found initrd image: /boot/initrd.img-4.15.0-101-generic
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {

der dann beim Boot via /etc/default/grub (vorher wegsichern!) ausgewählt wird

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-101-generic"

nachdem ein

update-grub

fehlerfrei durchläuft.

Doof gedacht: wireguard-dkms baut natürlich trotzdem für den neueren Kernel. Weil? Weil er da ist. So simpel.

Das Ergebnis ist also das gleiche wie oben: wireguard-dkms fällt beim Modulbau auf die Nase – obwohl der Server mit dem älteren Kernel läuft.

Eigentlich total klar – aber die Finger auf den Tasten sind manchmal schneller als das Hirn dazu.

Einfacher – und dazu noch fehlerfreier bei den Nacharbeiten mit DKMS zu handhaben – ist ein simpler apt-get purge auf den neueren Kernel.

apt-get purge linux-image-4.15.0-106-generic
apt-get clean ; apt-get autoremove

Dann evtl. noch die alten /etc/default/grub Inhalte wiederherstellen (falls mensch so blöd wie ich war), ein update-grub und nach einem Neustart ist wireguard wieder brav am Start.

Update

Was hier bezüglich Wireguard wunderbar funktioniert hat:

apt-get install --install-recommends linux-generic-hwe-18.04
apt-get install --reinstall wireguard-dkms wireguard-tools linux-headers-$(uname -r)

Ich hoffe, das hält nun eine Weile.

LiSCrypt

Irgendein Mensch auf dem Amt der in Weisheit klug Erschlauten kam auf die Idee, dass man doch weiterhin VeraCrypt ignorieren könnte – und beschloss, dass man nun in den Kommissionen LiSCrypt zu nutzen habe. Naja. Wenigstens ist es quelloffen zu haben, auch wenn die Idee, lauter Einzeldateien zu verschlüsseln, statt einen Container zu nutzen, davon zeugt, dass dieser Mensch mit der konkreten Arbeit in Kommissionen wenig zu tun hat.

Und was ein Audit ist, weiß er wohl auch nicht.

Aber es hilft ja alles nix. Also ran an das Ding.

Unter Kubuntu 18.04 kommt LiSCrypt wie folgt an Bord:

wget https://github.com/MaWe2019/LiSCrypt_public/archive/v0.9.7.zip
unzip v0.9.7.zip

Das oben geht natürlich auch händisch. Downloads hat es hier: https://github.com/MaWe2019/LiSCrypt_public/releases

Dann pip3 updaten

pip3 install --upgrade pip

Noch die Abhängigkeiten installieren

pip3 install psutil
pip3 install base91

Und dann geht es im entpackten Quelltextverzeichnis an die Arbeit mit

python3 -m Steuerung.LiSCrypt

Sieht dann so aus:

Wer kein KDE hat, muss evtl. noch die Qt Abhängigkeiten installieren. Aber wer die Ausgaben beim Start des Programms liest, findet die passenden Pakete, die man sich per pip an Bord holen kann. Vermutlich ist das dann sowas wie

pip3 install PyQt5

Hat man die defaults in der GUI gelassen, dann ist mit der Verschlüsselung des Originals dasselbe auch gleich weggelöscht. Hübsch, wenn man sich bei der Eingabe des Kennwortes zwei mal vertippt haben sollte. Dann sind die Dateien richtig sicher 😉

Ich tippe mal, das führt im Kommissionsalltag dann dazu, dass alle das Häkchen dort wegmachen und die unverschlüsselten Dateien im Dateisystem liegen lassen.

Notizen zum build von LOS für Flo / Mako

Damit ich es nicht vergesse, was hier Schritt für Schritt abzuarbeiten ist bei der Erstellung von neuen Images für Flo und Mako:

## Note for Mako and Flo LOS builds
## Flo
## See https://wiki.lineageos.org/devices/flo/build
## repo init -u https://github.com/LineageOS/android.git -b cm-14.1
## Mako 
## https://wiki.lineageos.org/devices/mako/build
## repo init -u https://github.com/LineageOS/android.git -b lineage-15.1
##
## Keep buildenv up to date
## in this case in two sub-dirs in ~/android:
## ~/android/flo and ~/android/mako
##

cd ~/android/flo ; repo sync
# or
cd ~/android/mako ; repo sync

# if we run into problems with repo sync this might help:
# repo sync --force-broken --force-sync

##
## Source and export what we need for build
##

source build/envsetup.sh  

export LC_ALL=C
export USE_CCACHE=1
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"

##
## Start build process
##

breakfast flo
# or
breakfast mako

# change dir to pull in proprietary blobs from device
cd ~/android/flo/device/asus/flo
# or
cd ~/android/mako/device/lge/mako

# Connect device via USB
# Check your path: 
# ~/android/flo/device/asus/flo
# ~/android/mako/device/lge/mako
# Check that USB debugging is ON on device
# Can we see the device?

adb devices

# pull the proprietary blobs in
./extract-files.sh 

# prepare compile
ccache -M 50G
croot

# compile
brunch flo
# or
brunch mako

## 
## Install the image
##

cd $OUT
adb reboot sideload
adb sideload lineage [TAB]
# return to sideload mode
adb sideload addonsu [TAB]

Mit je einem Image ist hier der Ordner für Flo ca. 85G und der Ordner für Mako rund 122G groß.

getmyfreetraffic redirect

Wer, wie ich, ein wenig zu lang (in meinem Fall: 2 Tage) wartete, um das Update für Easy WP SMTP einzuspielen, deswegen gehackt wurde und nun vor lauter Redirects sein Blog nicht mehr sieht: hier mein Weg zu einer wieder funktionierenden Multiblog-Installation inklusive der Schilderung meiner Stolpersteine:

Das Firefox Addon noscript verhinderte zuverlässig, dass ich bei der Begutachtung des eigenen Blogs dauernd von der eigenen Site weggeschubst wurde und im Orkus landete.
Die eigentliche Reparatur erfolgte nach dieser Anleitung auf Stackoverflow. Ich wählte für meine Reparatur Option 2 – also den Weg über die functions.php im Theme-Ordner.
Jedoch: Bei mir war ein Subblog gehackt worden, das das gleiche Theme verwendete wie das Hauptblog. Trägt man nun die geforderten Zeilen im Theme ein, muss man sich entscheiden, welches Blog man zuerst retten will, denn hieraus ergibt sich der einzutragende URL
```
update_option( 'siteurl', 'https://bdjl.de' );
update_option( 'home', 'https://bdjl.de' );
```
Wie oben zu sehen, war das in meinem Fall die Hauptdomain (und das konkrete Theme: twentytwelve).
Das beschriebenen Vorgehen über die functions.php von twentytwelve für das Hauptblog führte dazu, dass die Posts im Subblog mit dem gleichen Theme nicht mehr zu erreichen waren, weil für die nun die URLs des Hauptblogs galten … also lauter leere Seiten.
Immerhin funktionierte ab diesem Punkt das Backend des Hauptblogs wieder. Hier stellte ich dann die Themes aller meiner Blogs in der Multisite Installation um auf twentyten. Nur das gehackte Subblog behielt twentytwelve.
Jetzt wurde im Theme twentytwelve
```
update_option( 'siteurl', 'https://bdjl.de/subblog' );
update_option( 'home', 'https://bdjl.de/subblog' );
```
die Haupt-URL des Subblogs eingetragen, die Seite einmal aktualisiert und: die Posts waren alle wieder da.

Dringend angeraten ist eine Passwortänderung für a) den Mail-Account und b) die Datenbank (MariaDB, MySQL). Weiter würde ich dazu raten, die Datenbank von WordPress nach der Reparatur zu dumpen und dann im Dump nach allen möglichen Strings zu suchen, die im Kontext dieses Überfalls irgendwie Sinn machen könnten. Weitere Schritte sind auch hier beschrieben:

https://codex.wordpress.org/FAQ_My_site_was_hacked

https://wordpress.org/support/plugin/easy-wp-smtp/

TC und EDS-Lite

Als Notiz für die, die es brauchen: Für EDS-Lite können TrueCrypt-Container (ja – auch VeraCrypt geht, aber das Schutzniveau muss ja nicht in und für jeden Fall so gesetzt werden) mit den Einstellungen oben schneller auf dem Rechner, als auf dem Tablet angelegt werden:

Encryption Algorithm: Twofish
Hash-Algorithm: SHA-512

Die Standardvorgaben von TrueCrypt scheinen für EDS-Lite nicht zu funktionieren.

/localhost

127.0.0.1