Zockertown: Nerten News

Ich weiß nicht, ob an dem dahinter liegenden Script Interesse besteht...

Einfach melden.

Ich möchte hier kurz ein neues Script vorstellen, welches gleich mehrere Ziele hat.

blockedspam.sh

(1) bietet eine Kurzinfo. DiscardedInbound bedeutet soviel wie "eMail Eingang verworfen". Das heißt also diese eMail wurde nicht an ein eMail Konto geliefert, sondern ignoriert.

Bei (2) werden die definierten Richtlinien ausgegeben. Die definierten Richtlinien sind  in der Admin Oberfläche von ISPConfig eingerichtet. Bei uns werden die X-Spam-Score Zeilen der hereinkommenden eMails durch Amavis modifiert. Das machen etliche eMail Anbieter auch.  Ganz wichtig war nun für mich, leicht zu erkennen, ob auch der Kill Level korrekt funktioniert. Also, ob der score dazu führt, dass die eMail verworfen wird, wenn der Wert hoch genug ist.

Bei (3) sind alle Treffer aus dem mail.log der laufenden Woche aufgelistet. Der Screenshot ist vom Dienstag Nachmittag, hat also nur eine Zeitspanne von reichlich 2,5 Tagen.

In der rechten Spalte ist die für den entsprechenden eMail Konto die ausgewählte Richtlinie.

Im erweiterten Teil findet ihr den Source Code von blockedspam.sh

Ich habe das Skript roundcube-users.sh entwickelt, es  ermöglicht mir, die jüngsten erfolgreichen Anmeldungen im Roundcube-Webmail-Interface anzuzeigen. Dieses Tool dient dazu, die Erfolg oder Misserfolg von Anmeldeversuchen zu überprüfen.

#!/bin/bash
# roundcube-users.sh $Revision: 1.10 $
# Mit Zeilennummerierung
echo "SELECT (@row := @row + 1) as Nr, username,last_login,created,failed_login,failed_login_counter \
from roundcube.users r, (SELECT @row := 0) row \
where username like '%$1%' \
order by last_login DESC \
LIMIT 10;"|\
mysql -S /var/run/mysqld/mysqld.sock --table | egrep --color 'username|last_login|*'


if [ "$#" -ne "1" ]
then
    bold=$(tput bold)
    normal=$(tput sgr0)
    #gelb=$(tput setaf 3)
    gruen=$(tput setaf 2)
    black=$(tput setaf 0)

    echo "---------------------------------------------------------------"
    echo "$bold Tipp:$normal "
    echo "Die Anzeige zeigt nur die letzten 10 Logins."
    echo "Kann aber auch durch einen$gruen Teilstring$normal eingeschränkt werden. "
    echo "$bold Beispiel:$normal"
    echo "$0$gruen .eu$normal"
fi

Netdata bietet sogenannte Badges. Diese dynamischen Grafiken werden bei Notifications bzw. Alarmen verwendet.

Man kann sie aber recht einfach auch in anderen Seiten integrieren, wie z.B. hier.

(Wer diesen Beitrag per Planet liest, sieht den Badge nicht. Das ist Absicht, weil ich die Badges nun auf nur meine eigenen Site beschränkt habe)

Nur ist für unseren rootserver netdata passwort geschützt. Das hat zur Folge, dass die Badges bei Aufruf natürlich nach einem Login und Passwort fragen. Es gibt aber eine recht einfache Möglichkeit, die Beschränkung für die Badges aufzuheben.

Darum geht es hier.

<Location /netdata/>
        AuthType Basic
        AuthName "Protected site"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
        Order deny,allow
        Allow from all
</Location>

<Location /netdata/api/v1/badge.svg>
    Satisfy any
    Allow from all
    AllowOverride None
    Require all granted
</Location>

Die eigentliche Location /netdata/ ist password geschützt mit Authtype Basic.

Für /netdata/api/v1/badge.svg ist eine Ausnahme definiert.

Das funktioniert prima.

Ich möchte aber nicht verschweigen, dass der geneigte unautorierte User nun beliebige Badges anlegen kann, man sollte den Zugriff evtl auf bestimmte Sites begrenzen. --- Edit, das ist nun geschehen, die veränderte Config kommt im erweiterten teil

zum scannen neuer Files, die nicht über die Oberfläche hinzugefügt wurden.

Das hier ausführen

su -s /bin/bash www-data
php occ files:scan --all

Quelle: hostflash.de

Ich bin Fritzbox Nutzer, ich verwende den integrierten DNS Server, (genauer wohl ein resolver Cache)

Da ich auch einige Domain mit DNS Robot von Hetzner betreue, kommt es nach IP Änderungeen dort zu merkwürdigen Seiteneffekten.

Wenn es Unterschiede in der DNS Auflösung  zwischen dig, host und ping gibt, könnte es daran liegen, das in der FB ein Cache benutzt wird, den ping abfragt.

Die Lösung könnte sein, dass man einmal den DHCP-Server deaktivieren und gleich wieder aktivieren muß.

Eigentlich trivial.

Ich dokumentiere idas hier, weil ich eine Zeilennummerierung der Ausgabe sehr einfach realsiert habe und das mir merken möchte.

                                                                                        
#!/bin/bash
# roundcube-users.sh $Revision: 1.5 $
# changed wieder rausgenommen, fehlt der richtige dreh
# Mit Zeilennummerierung
echo "SELECT (@row := @row + 1) as Nr, username,created,last_login,failed_login,failed_login_counter \
from roundcube.users r, (SELECT @row := 0) row \
where username like '%$1%' \
order by last_login desc;"|\
mysql -S /var/run/mysqld/mysqld.sock --table


if [ "$#" -ne "1" ]
then
        bold=$(tput bold)
        normal=$(tput sgr0)
        #gelb=$(tput setaf 3)
        gruen=$(tput setaf 2)
        black=$(tput setaf 0)

        echo "---------------------------------------------------------------"
        echo "$bold Tipp:$normal"
        echo " Die Anzeige kann auch durch einen$gruen Teilstring$normal eingeschränkt werden. "
        echo "$bold Beispiel:$normal"
        echo "$0$gruen bik$normal"
fi

Gefunden bei 
https://www.askingbox.de/frage/mysql-reihen-im-ergebnis-nummerieren

Und ich benutze nun nicht mehr die Debian Spezialität  --defaults-extra-file=/etc/mysql/debian.cnf,

sondern den Socket /var/run/mysqld/mysqld.sock

Auf einer lokalen Umgebung macht das Sinn, da der Socket ohnehin rootrechte hat.

Das hier ist keine Anleitung, sondern dient mir als Stütze, was ich gemacht habe.

Gmail möchte verstärkt die absendenen Mailserveradmins dazu bewegen, SPF zu verwenden. Andere große eMail Provider übrigens auch. Es kommt vereinzelnt zu solchen Einträgen im mail.log

said: 421-4.7.0 This message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best protect our users from spam, the 421-4.7.0 message has been blocked. Please visit 421-4.7.0  https://support.google.com/mail/answer/81126#authentication for more 421 4.7.0 information. e15-20nmnmnmxmxmnmn.517 - gsmtp (in reply to end of DATA command))

Eine sehr gute Erklärung ist hier bei it-zeugs.de zu finden.  Hier auch: blog.k-webs.ch 

Deshalb erspare ich mir eine Wiederholung.

Es gibt auch Kritik an SPF. Schön auf den Punkt gebracht hat es meiner Meinung nach  tec-bite.ch/warum-mag-google-meine-mails-nicht/

Links:

Einen gesetzen SPF TXT Record kann man hier  testen.

appmaildev.com/en/spf 

spf-record.de/spf-lookup/

www.kitterman.com/spf/validate.html

https://www.mailhardener.com/tools/spf-validator

mxtoolbox.com/SuperTool.aspx?action=spf

Oder zu Fuß:

Eine email per roundcube oder imap Mailclient an eine eigene  gmail.com Adresse senden.

Die empfangene email unter "mehr", im Original anzeigen. Dort die SPF Einträge untersuchen.

Oder auch so: 

dig -t txt zockertown.de +short
"v=spf1 +a +mx +ip4:xx.yy.zz +ip4:xx.rr.ff.fe -all"

Hinweis:

Unterschied -all und ~all

~all ist die entschärfte Variante

Sollte man die Einträge nicht mit einem Webtool o.ä. machen, sondern auf der Console, bitte daran denken, dass die Serial hochgezählt wird, es gibt sonst evtl. unschöne Nebeneffekte, wie ich erleben durfte.

Wenn man Softraid verwendet, sollte einem klar sein, dass da eine monatliche Prüfung die Daten im Monitoring versaut.

Zum Unterschied von collectd und netdata hier ein Beispiel.

Ausgangssituation: In beide Tools wird auffallend hoher Load angezeigt, die Ursache liegt aber nicht an wild gewordenen Prozessen, eingeschleppte Schädlinge, sondern lediglich am 4 Wöchentlichen Rebuild des Raid1. Man muss halt nur wissen, welche Grafiken einem das verraten.

cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb2[1] sda2[2]
      2929609152 blocks super 1.2 [2/2] [UU]
      [==============>......]  check = 70.0% (2050771840/2929609152) finish=222.2min speed=65892K/sec
      bitmap: 5/22 pages [20KB], 65536KB chunk

md0 : active raid1 sdb1[1] sda1[2]
      523712 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Hier sieht man es auch sehr schön. Na klar, sda zeigt es genauso

Siehe auch https://zockertown.de/s9y/index.php?/archives/1630-Den-UEberblick-behalten-collectd-update.html

Hier noch das Ende. Leider kann man nicht minutengenau die Start und Ende Punkte erkennen. Aber das ist jammern auf hohem Niveau. Allerdings ist es bei netdata einfacher den Zeitpunkt zu erfassen.

Vor ein paar Wochen hatte ich einen langsam steigenden Load auf dem Server entdeckt.

Was auffiel, war ein schlechtes Antwortverhalten verschiedener CMS Systeme.

Scheinbar besonders betroffen waren Sites mit relativ vielen Redirects.

Es hat eine Weile gedauert, bis ich den Übeltäter fand.

Die inotify Log-Datei war riesige 27GB groß!

Da die Partition voll lief, hat mich mein Monitoring freundlich darauf hingewiesen und ein ncdu -x / hat mir den Übeltäter offenbart.

Sobald die Logdatei gelöscht war, lief alles wieder mit voller Geschwindigkeit.  Maldet und inotify war nicht in den Log-Rotationsprozess eingebunden, also habe ich dies getan, um die inotify Logdatei rotieren zu lassen.

Dazu habe ich den  Vorschlag verwendet. War zu faul mir selbst etwas auszudenken

Auch  Load ist wieder Prima.

Prolog

Durch Zufall bin ich auf restic gekommen, es ist ein Backup Programm, welches sehr ähnlich zu borg Backup funktioniert, aber von Grund auf neu geschrieben wurde und eine andere Syntax benutzt. Der Original Autor ist Alexander “fd0” Neumann, er hat das Programm in go geschrieben.

Für mich sind die herausragenden Eigenschaften:

• Verschlüsselung der Daten (auch die Struktur ist ohne Passphrase nicht einsehbar)
• Deduplizierung  (ist im Video von 2016³ endlich mal gut erklärt)
• immer Vollbackups
• man kann Snapshots auch per z.B.: SFTP Storage lokal mounten (Stichwort FUSE)
• sehr schnell
• Verifizierung der Daten mit Hashsummen 
• leicht zu konfigurieren
• integrierte Update Funktion

Hier soll es um das Backup Programm im praktischen Einsatz gehen.

Gesichert werden 2 Laptops und ein Server (später) auf meinem Storage bei Hetzner. Mein Artikel soll kein selber lesen der Dokumentation ersetzen oder ersparen, sondern ein Leitfaden für mich und Leute sein, die eine ähnliche Situation haben. Es ist also ein Notizblock, um schnell das setup zu verstehen und als Hilfe gedacht, wenn nach Monaten mal ein Problem auftritt und ich wissen möchte, wie hatte ich mir das gedacht.

Ich benutze derzeit restic nur als user zum sichern von Bildern und persönlichen Dokumenten. Natürlich würde es auch für die komplette Installation der Laptops gehen, das brauche ich aber momentan nicht.

Voraussetzungen

Hetzner hat die Besonderheit, dass der Storage über Port 22 und 23 erreichbar ist. Hinweis: Bei Hetzner ist user@name durch eure Kennung z.B. u0815@u0815 zu ersetzen, ich wollte hier nicht meinen realen Account offenbaren.

Hat man den Public_Key auf dem Storage unter .ssh/authorized_keys hinterlegt, ist der Zugriff über Port 23 für Backup Programme ohne Passwort möglich.

Einloggen per ssh ist unterbunden.

Bevor man sich einen Wolf sucht, bitte entweder mit

lftp -p 23 sftp://user@name.your-storagebox.de 
oder
sftp -P 23 user@name.your-storagebox.de

testen. Es sollte nun ohne Passwortabfrage eine Verbindung zum Storageserver hergestellt werden.

Warum lftp?

Nun es geht auch mit sftp, das ist ja standardmäßig bereits installiert, allerdings ist lftp der klare Sieger, wenn man rekursiv mal etwas löschen muss, was bei mir der Fall war, das beschreibe ich weiter unten. Ansonsten ist die Verwendung weitgehend identisch. Bei sftp gibt man den Port mit großem -P an und es versteht df -h, lftp dafür du -hs (Achtung u.U. langsam).

Eine Merkwürdigkeit ist bei lftp, dass man trotz ssh Key eine Passwort Aufforderung bekommt, wo man einfach nur <ENTER> drücken muß.

Ein Workaround um die Passwort Abfrage zu umgehen, ist der Trick, einen eigentlich unnötigen Platzhalter "platz" zu verwenden:

lftp -p 23 -u user,platz sftp://name.your-storagebox.de

Zum experimentieren mit restic verwende ich einen Alias. (Hetzner storagebox)

#                  -p password_file    -r repository pfad
alias back='restic -p ~/.ssh/restic_pw -r sftp://user@name.your-storagebox.de:23/privat/bernd/T500

Mit dem alias back erspare ich mir die Angabe des Repositories und des Passwords. Man könnte natürlich auch mit Environment Variablen arbeiten, das finde ich aber unsicherer, weil die für Angreifer leichter auslesbar wären. Ich denke z.B. aber auch an die .bash_history. Der Nachteil des Alias ist, dass man die Autocompletion von bash verliert, wenn man allerdings als alias restic verwendet, fällt dieser Nachteil weg, man handelt sich dann ggfs. andere Nachteile ein. Zum Beispiel, wenn man mit mehreren Repositories arbeiten will. 

#In restic_pw ist das lange Password des Repositories abgelegt, es darf nur für den User lesbar sein
~/.ssh/restic_pw 
chmod 600 ~/.ssh/restic_pw 

In den weiteren Beschreibungen verwende ich den Alias back und nicht restic, um Verwirrungen beim Leser zu vermeiden.

Anlegen des Repository

Vorher auf dem sftp Server nachschauen, welche Verzeichnisstruktur bereits vorhanden ist. Das Verzeichnis des Repositories wird angelegt, es muss nicht existieren! Bei mir z.B. /home/privat/bernd. wobei das /home nicht mit angegeben wird! Im obigen Beispiel ist dies bereits berücksichtigt und deshalt reicht ein einfaches

back init

created restic repository  e5f00e22 at sftp://user@name.your-storagebox.de:23/privat/bernd/T500

(...)

Damit ist in kurzer Zeit die notwendige Datenstruktur auf dem Storage angelegt und bereit für ein erstes Backup

Erstes Backup erstellen

Ich habe als erstes mal meine Dokumente gesichert.

Hier das Protokoll des dritten Aufrufes, das erst Backup lief ca. 40 Minuten

back backup Dokumente
repository e5f00e22 opened successfully, password is correct
using parent snapshot 3504f0f6

Files:           0 new,     0 changed,   139 unmodified
Dirs:            0 new,     0 changed,    12 unmodified
Added to the repo: 0 B  

processed 139 files, 2.634 GiB in 0:00
snapshot b982a7d0 saved

Backup auflisten

back snapshots 

repository e5f00e22 opened successfully, password is correct

ID        Time                 Host        Tags        Paths

--------------------------------------------------------------------------

99494f33  2021-02-18 19:01:31  T500                    /home/bed/Dokumente

3504f0f6  2021-02-19 19:42:50  T500                    /home/bed/Dokumente

b982a7d0  2021-02-19 21:10:30  T500                    /home/bed/Dokumente


--------------------------------------------------------------------------

3 snapshots

Backup Dateien auflisten

#back ls b982a7d0 # oder das aktuellste mit latest
back ls latest
(...)
/Dokumente/SchaubLorenz_Golf100.pdf
/Dokumente/Toshiba_TLG373.pdf
(...)

Das Ergebnis ist mit pipe weiter verarbeitbar. Zum Beipiel

back ls latest|grep -i toshiba
/Dokumente/Toshiba_TLG373.pdf

Backup Dateien suchen

restic bietet auch eine Suchfunktion

back find toshiba* --ignore-case 
repository e5f00e22 opened successfully, password is correct
Found matching entries in snapshot 3504f0f6 from 2021-02-19 09:42:50
/Dokumente/Toshiba_TLG373.pdf

Found matching entries in snapshot 99494f33 from 2021-02-18 09:01:31
/home/bed/Dokumente/Toshiba_TLG373.pdf

Found matching entries in snapshot b982a7d0 from 2021-02-19 13:10:30
/Dokumente/Toshiba_TLG373.pdf

Backup checken

Ein Hilite von restic ist die check Funktion, hier wird die Struktur auf Integrität geprüft.

Sie testet das Repository auf Fehler und meldet gefundene Fehler. Sie kann auch verwendet werden, um alle Daten zu lesen und somit eine Wiederherstellung zu simulieren.

Standardmäßig lädt der "check"-Befehl immer alle Daten direkt aus dem Repository und verwendet keinen lokalen Cache.

Die 2 Beispiele sind nicht vom T500, sondern vom Tuxedo, dort läuft durch den moderneren Prozessor auch die Hardware decryption, was natürlich dem Vorgang den Marsch bläst.

back check

time back check

using temporary cache in /tmp/restic-check-cache-775446915
repository cfa22dd6 opened successfully, password is correct
created new cache in /tmp/restic-check-cache-775446915
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs

[0:01] 100.00%  3 / 3 snapshots

no errors were found


real 0m31,592s

user 0m1,660s

sys  0m0,359s

Nicht schlecht, oder? nach gerade mal 32 Sekunden weiß ich, dass mein Backup in Ordnung ist. Doch was ist wirklich los, simulieren wir doch einen kompletten Restore... des 55GiB großen Repo (ok, Download Speed nicht mit einberechnet)

back check --read-data

time back check --read-data 

using temporary cache in /tmp/restic-check-cache-410215478
repository cfa22dd6 opened successfully, password is correct
created new cache in /tmp/restic-check-cache-410215478

create exclusive lock for repository

load indexes

check all packs

check snapshots, trees and blobs
read all data  2 / 3 snapshots

[0:01] 100.00%  3 / 3 snapshots

[1:12:32] 100.00%  9019 / 9019 packs

no errors were found



real   72m58,199s

user   12m50,579s

sys    4m16,768s

Repository Password ändern

Beim ausprobieren und einrichten ist mir ein Fehler unterlaufen. Ich wollte eigentlich ein password file benutzen, habe es aber ich der command line nicht angegeben. Damit wurde als Password File der Private Key genommen, wahrscheinlich keine gute Idee

Das merkte ich aber erst, als das erste Backup lief.

Da es hier aber ein größeres Backup war, wollte ich es nicht neu machen, sonder habe mich nach der sehr guten Dokumentation gerichtet und einfach einen neuen Key angelegt, dann meinen Aufruf korrigiert und den nun nicht mehr notwendigen Key gelöscht. Fertig.

Weil hier der Alias back benutzt wird, besonders darauf achten, dass das hinterlegte password auch händisch im 

~/.ssh/restic_pw 

angepasst wird, sonst könnte es böse Überraschungen geben

Also:

Auflisten aller Keys

​back key list

password ändern

​back key passwd

Key hinzufügen

​back key add

Key löschen

​back key delete

Restore

Ich komme nun zum eigentlichen Zweck eines Backup Programms, dem zurückholen von einzelnen Dateien oder des gesamten gesicherten Bestands.

Zuerst feststellen was alles, wann gesichert wurde:

back snapshots
repository cfa22dd6 opened successfully, password is correct
ID        Time                 Host        Tags        Paths
--------------------------------------------------------------------------
00fbbd64  2021-02-18 19:01:26  Bullseye                /home/bed/Bilder
84e0f2bc  2021-02-19 12:17:52  Bullseye                /home/bed/Dokumente
c3d0c516  2021-02-19 17:16:48  Bullseye                /home/bed/Dokumente
7d2d6547  2021-02-19 20:07:09  Bullseye                /home/bed/Bilder
--------------------------------------------------------------------------
4 snapshots

Ich möchte die Bilder im Ordner usb-warzen zurück sichern, Witzigerweise sind die nicht im gesicherten Ordner Bilder, sondern in Dokumente.

Siehe auch Datei suchen

Einzelne Dateien finden und zurück holen
Mehrere Möglichkeiten:

back ls c3d0c516|grep usb-warzen

/Dokumente/usb-warzen
/Dokumente/usb-warzen/1.png
/Dokumente/usb-warzen/1.png_max_200kb.jpg
/Dokumente/usb-warzen/10.png
/Dokumente/usb-warzen/10.png_max_200kb.jpg
/Dokumente/usb-warzen/11.png
/Dokumente/usb-warzen/11.png_max_200kb.jpg
/Dokumente/usb-warzen/2.png
/Dokumente/usb-warzen/2.png_max_200kb.jpg
/Dokumente/usb-warzen/3.png
/Dokumente/usb-warzen/3.png_max_200kb.jpg
/Dokumente/usb-warzen/4.png
/Dokumente/usb-warzen/4.png_max_200kb.jpg
/Dokumente/usb-warzen/5.png
/Dokumente/usb-warzen/5.png_max_200kb.jpg
/Dokumente/usb-warzen/6.png
/Dokumente/usb-warzen/6.png_max_200kb.jpg
/Dokumente/usb-warzen/7.png
/Dokumente/usb-warzen/7.png_max_200kb.jpg
/Dokumente/usb-warzen/8.png
/Dokumente/usb-warzen/8.png_max_200kb.jpg
/Dokumente/usb-warzen/9.png
/Dokumente/usb-warzen/9.png_max_200kb.jpg

back ls latest listet alle Dateien auf, die gesichert worden, kann prima mit pipe und den unix tools verarbeitet werden.

z.B.

back ls latest|grep usb-warzen

Kein Treffer

Aber Achtung! latest listet also nur den aktuellen snapshot, wenn man nach Bildern sucht passt das hier zufällig, wenn man Dokumente finden will, muss in diesem Fall die korrekte snapshotid verwendet werden.

Oder das Kommando find nutzen Achtung Case sensitiv! 

Vorteil gegenüber der ersten Methode, es sucht in allen snapshots...

back find  usb-warzen*

repository cfa22dd6 opened successfully, password is correct

Found matching entries in snapshot 84e0f2bc from 2021-02-19 12:17:52

/Dokumente/usb-warzen

/Dokumente/usb-warzen/1.png

/Dokumente/usb-warzen/1.png_max_200kb.jpg

/Dokumente/usb-warzen/10.png

/Dokumente/usb-warzen/10.png_max_200kb.jpg

/Dokumente/usb-warzen/11.png

/Dokumente/usb-warzen/11.png_max_200kb.jpg

/Dokumente/usb-warzen/2.png

/Dokumente/usb-warzen/2.png_max_200kb.jpg

/Dokumente/usb-warzen/3.png

/Dokumente/usb-warzen/3.png_max_200kb.jpg

/Dokumente/usb-warzen/4.png

/Dokumente/usb-warzen/4.png_max_200kb.jpg

/Dokumente/usb-warzen/5.png

/Dokumente/usb-warzen/5.png_max_200kb.jpg

/Dokumente/usb-warzen/6.png

/Dokumente/usb-warzen/6.png_max_200kb.jpg

/Dokumente/usb-warzen/7.png

/Dokumente/usb-warzen/7.png_max_200kb.jpg

/Dokumente/usb-warzen/8.png

/Dokumente/usb-warzen/8.png_max_200kb.jpg

/Dokumente/usb-warzen/9.png

/Dokumente/usb-warzen/9.png_max_200kb.jpg


Found matching entries in snapshot c3d0c516 from 2021-02-19 17:16:48

/Dokumente/usb-warzen/1.png

/Dokumente/usb-warzen/1.png_max_200kb.jpg

/Dokumente/usb-warzen/10.png

/Dokumente/usb-warzen/10.png_max_200kb.jpg

/Dokumente/usb-warzen/11.png

/Dokumente/usb-warzen/11.png_max_200kb.jpg

/Dokumente/usb-warzen/2.png

/Dokumente/usb-warzen/2.png_max_200kb.jpg

/Dokumente/usb-warzen/3.png

/Dokumente/usb-warzen/3.png_max_200kb.jpg

/Dokumente/usb-warzen/4.png

/Dokumente/usb-warzen/4.png_max_200kb.jpg

/Dokumente/usb-warzen/5.png

/Dokumente/usb-warzen/5.png_max_200kb.jpg

/Dokumente/usb-warzen/6.png

/Dokumente/usb-warzen/6.png_max_200kb.jpg

/Dokumente/usb-warzen/7.png

/Dokumente/usb-warzen/7.png_max_200kb.jpg

/Dokumente/usb-warzen/8.png

/Dokumente/usb-warzen/8.png_max_200kb.jpg

/Dokumente/usb-warzen/9.png

/Dokumente/usb-warzen/9.png_max_200kb.jpg

Angenommen, ich möchte das Verzeichnis /Dokumente/usb-warzen/  wieder herstellen, es aber, weil ich unsicher bin vorerst in /tmp speichern: 

time back restore c3d0c516 -i /Dokumente/usb-warzen/ --target /tmp
repository cfa22dd6 opened successfully, password is correct

restoring <Snapshot c3d0c516 of [/home/bed/Dokumente] at 2021-02-19 17:16:48.706292257 +0100 CET by bed@Bullseye> to /tmp


real    0m17,422s

user    0m1,095s

sys    0m0,399s

bed@Bullseye:~$ ls -ltr /tmp/Dokumente/usb-warzen/

insgesamt 24392
-rw-r--r-- 1 bed bed 1851594 11. Nov 19:28 7.png
-rw-r--r-- 1 bed bed 1484032 11. Nov 19:28 2.png
-rw-r--r-- 1 bed bed 1573462 11. Nov 19:28 1.png
-rw-r--r-- 1 bed bed 1877277 11. Nov 19:28 6.png
-rw-r--r-- 1 bed bed 1629634 11. Nov 19:28 5.png
-rw-r--r-- 1 bed bed  600155 11. Nov 19:28 4.png
-rw-r--r-- 1 bed bed 4588086 11. Nov 19:28 3.png
-rw-r--r-- 1 bed bed 1615798 11. Nov 19:28 9.png
-rw-r--r-- 1 bed bed 1986633 11. Nov 19:28 8.png
-rw-r--r-- 1 bed bed 2383447 11. Nov 19:28 10.png
-rw-r--r-- 1 bed bed  168904 11. Nov 19:28 9.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  187365 11. Nov 19:28 8.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  188381 11. Nov 19:28 7.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  191964 11. Nov 19:28 6.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  188648 11. Nov 19:28 5.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  166986 11. Nov 19:28 4.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  198799 11. Nov 19:28 3.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  198531 11. Nov 19:28 2.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  180148 11. Nov 19:28 1.png_max_200kb.jpg
-rw-r--r-- 1 bed bed  199263 11. Nov 19:28 11.png_max_200kb.jpg
-rw-r--r-- 1 bed bed 3276158 11. Nov 19:28 11.png
-rw-r--r-- 1 bed bed  197313 11. Nov 19:28 10.png_max_200kb.jpg

Wie lösche ich auf dem sftp Server rekursiv?

Das hat zwar direkt nichts mit restic zu tun, aber da ich es beim experimentieren brauchte ....

Weil ich mich beim Testen im Pfad geirrt hatte, war der Wunsch nach einem rekursiven Löschen vorhanden.

lftp bietet das und erspart damit u.U. eine Menge Tipparbeit (Bei Debian apt install lftp)

Bei lftp gibt man einfach rm -r Directory ein, dann rattert es im Karton und man kann derweil in einem anderen Tab weiterarbeiten.

Wenn ich überhaupt mäkeln wollte, dann ist es der name "restic" Wie bitte? Weiß jemand wie dieser Name zu Stande kam? Ich habe gefragt, ein Namengenerator war schuld Aber mittlerweile kann ich restic fehlerfrei tippen, alles gut.

Eine gute Idee ist immer back command --help. (oder eben restic command --help)

Damit komme ich gut zurecht.

Ps: Ich musste den Quellcode editieren, werde wohl auch noch etwas dran schrauben, also ab- und zu mal schauen, wen es denn interessiert ...

Linksammlung:

blog.datentraeger.li/?p=1733 

techgoat.net/index.php?id=5 

³ media.ccc.de/v/c4.openchaos.2016.01.restic

restic.readthedocs.io/en/stable/index.html

Seit Oktober 2018 habe ich auf meinem Server einen Dirty Hack am laufen.

Er sorgt dafür, dass die von den Usern als SPAM markierten emails als SPAM gelernt werden, um die Bayes Filter zu verbessern.

Meine Hoffnung war, dass dadurch die verbesserte Erkennung von Spam allen Usern zu Gute kommt.

Mittlerweile habe ich Buster und der hack funktioniert immer noch.

Deshalb hier meine Notizen:

Als root:
usermod -aG vmail amavis
chmod -R g+rx /var/vmail/

# Als amavis: su - amavis

# Voraussetzung: Debian Stretch, nach "der perfekte Server"

# Zustand VOR dem Lernen:
sa-learn -D --username=amavis --dump magic

# Anlernen HAM
find /var/vmail/*/* -type d -not -path "*.Spam*" -not -path "*.Junk*" -not -path "*.Trash*" -not -path "*new*" -not -path "*tmp*" -not -path "*.Sent*" -not -path "*.Archive*" -not -path "*Maildir/cur*" -not -path "*dovecot*" -not -path "*sieve*" -not -path "*quotausage*" -not -path "*courier*" -type d -exec /usr/bin/sa-learn --ham {} \;
# Anlernen SPAM
/usr/bin/find /var/vmail/*/*/Maildir/ -type d \( -iname "*Junk*" -o -iname "*spam*" \) -exec /usr/bin/sa-learn --spam {} \;

# Zustand NACH dem Lernen:
sa-learn -D --username=amavis --dump magic


#Als root: STRG-D
# Die Gruppe kann IMHO bleiben
chmod -R g-rx /var/vmail/

Das ganze habe ich in ein Script gepackt:

#!/bin/bash

#/usr/local/sbin/spamlern.sh 
# Einmal als Root 
#usermod -aG vmail amavis 
# in Root crontab 
#nice chmod -R g+rx /var/vmail/ 
# Anlernen HAM (funktioniert aber ohne, wie ich gemerkt habe) 
#find /var/vmail/*/* -type d -not -path "*.Spam*" -not -path "*.Junk*" -not -path "*.Trash*" -not -path "*new*" -not -path "*tmp*" -not -path "*.Sent*"$ 
# Anlernen SPAM 
nice /usr/bin/find /var/vmail/*/*/Maildir/ -type d \( -iname "*Junk*" -o -iname "*spam*" \) -exec /usr/bin/sa-learn --spam {} \; >/dev/null 
# Zustand NACH dem Lernen: #sa-learn --username=amavis --dump magic|grep 'n*am'|mailx -s 'sa-lern Status' root echo "$(date +'%Y-%m-%d')$(sa-learn --username=amavis --dump magic |grep nspam|cut -c18-30)" >>/var/log/spam-lern.log mailx -s 'sa-lern Status' root

#und als amavis User in die Crontab gepackt 6 5 * * 1,4  /usr/local/sbin/spamlern.sh

... und wo ist der "Dirty" Hack?

Hier

4 5 * * 1,4 nice chmod -R g+rx /var/vmail/ >/dev/null 2>&1
15 5 * * 1,4 nice chmod -R g-rx /var/vmail/ >/dev/null 2>&1

Ich erlaube damit meinem obigen Script für 11 Minuten, die Mailboxen nach Spam abzuklappern  

Update 27.02.2023:

Script ist nun im CVS und auch auf dem neuen rootserver aktiv, hatte ich vergessen.

Notiz für mich.

Let's encrypt stellt ja auch Wildcard Zertifikate aus. D.h. für rootgemeinschaft.de; www.rootgemeinschaft.de; smtp.rootgemeinschaft.de usw. gibt es nur ein Zertifikat, das vermeidet Meckern vom Browser und Mail Client.

Derzeit stelle ich die Domains Zug um Zug auf Wildcard Domains manuell um.

Nebenbei funktioniert die automatische Verlängerung nicht mehr, weil das ACME Protokoll V1 nicht mehr akzeptiert wird.

Meine Versuche, das zu lösen waren bisher nicht erfolgreich.

Update: Der Schlüssel zu einem neuen Script für das Renew ist wohl hier:

https://community.hetzner.com/tutorials/letsencrypt-dns

Wenn ich hier wieder auf Reihe bin, werde ich das umsetzen. 

Egal, hier die notwendigen Schritte zu Ersterstellung von Wildcard Zertifikaten und was zusätzlich nötig sein könnte.

certbot certonly --manual -d *.rootgemeinschaft.de -d rootgemeinschaft.de --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Man wird dann aufgefordert, einen TXT Eintrag in der DNS Zone einzutragen: _acme-challenge.rootgemeinschaft.de Value="FgHjU89_asdvFetrxBlaFasely"

Der Eintrag im DNS Robot bei Hetzner für die Domain rootgemeinschaft.de muss dann so lauten​​:

Also ohne .rootgemeinschaft.de, das wird automatisch ergänzt, da hatte ich ein Verständnisproblem.

Als TTL nehme ich 60s und warte, bis ich in einem zweiten Terminal Fenster den eingetragenen TXT Record auch finde.

root@rootgemeinschaft ~ # dig -t txt _acme-challenge.rootgemeinschaft.de +short
"FgHjU89_asdvFetrxBlaFasely"

Jetzt kann man Enter drücken und hoffen, das alles klappt.

Falls es sich wie hier um den Mailserver handelt muss auch der Dienst neugestartet werden, sonst wird das neue Zertifikat nicht angezogen.

service postfix restart
service dovecot restart

Oder eben der Webserver.

Danach muss certbot ohne parameter aufgerufem werden, Option 1

Experimentell habe ich heute (22.7.2020) auch mal die Hetzner API ausprobiert. Scheint gut zu laufen, ist aber sehr langsam, aber scheinbar habe ich jetzt den Kanackpunkt gefunden, warum bei mir das Auto Renew mit den Wildcard Domains nicht klappte.

Wenn ich sicher bin, dass es läuft, ergänze ich es hier.

Ergänzung: openssl x509 -dates -noout </etc/letsencrypt/live/rootgemeinschaft.de/fullchain.pem

Ergibt das Expiredate, ich muß noch ein Script machen, dass dovecot durchstartet, wenn ein neues Cert vorhanden ist

Eigentlich nimmt man heutzutage GIT.

Ich nicht, da ich auch nur meine eigenen Spielereien etwas sichern und den Überblick behalten möchte, verwende ich CVS.

Braucht keiner nachmachen, ich schreibs halt hier mal auf, damit ich es wiederfinde, wie ich es aufgesetzt habe.

Schönere Anleitungen gibt es im Netz, hier die Variante, die bei mir werkelt.

Mein Repository liegt auf dem Rootserver.

CVSROOT=/var/CVS

Zugriff kann lokal oder über ssh erfolgen.

Dafür habe ich

export CVSROOT=:extssh:IP-adresse:/var/CVS

in der .bashrc des Client.

Damit das Ganze funktioniert muss der lokale user auch auf dem Server existieren und den sshkey im authorized_key hinterlegt haben.

Jetzt kann auf dem Client z.B. ein Verzeichnis importiert werden.

cvs import Elektronik bed start

Elektronik ist der Ordner Name und bed ist der user.

Selbstredend sollte der Ordner Elektronik frei von unnötigem Zeug sein, sonst wird das auch versioninert. Einige wenige Dateien werden allerdings auch per default ignoriert.

Es öffnet sich nano und fragt nach einem Kommentar. Mit -m "bla fasel" könnte man das umgehen, mache ich gewöhnlich aber nicht.

Jetzt sollte eine Liste von "N Dateinamen" erscheinen, damit ist das importieren erfolgreich.

Danach kann man mit cvs co Elektronik das Verzeichnis ausschecken und so zum bearbeiten vorbereiten.

Ps: Nicht vergessen, 

 /var/CVS 

mit im Backup Script aufzunehmen.

Keywörter: "$Revision$", "$Date$" und "$Log$" 

Nützliche Seite, um die Erinnerung an die Syntax aufzufrischen:

https://gki.informatik.uni-freiburg.de/lehre/ss03/sopra/cvs.html#REVISIONSNUMMERN

Vor einiger Zeit habe ich den Verursacher von erhöhter Prozessorlast gesucht. Mangels detailierter Monitoring Graphen war ich da leider etwas behindert bei der Suche. Schliesslich hatte ich es dann doch gefunden, es war der 4 Wöchentliche Softraid Check, den ich gar nicht mehr auf dem Schirm hatte.

Das war der Anlaß das Monitoring etwas aufzubohren.

Collectd bietet das Plugin Processes.

Das lässt sich individuell für seine eigene Zwecke anpassen.

Ich habe folgende Konfiguration gemacht:

<Plugin "processes">
ProcessMatch pg_autovacuum "postgres:.*autovacuum"
# Ergänzung um typische Verdächtige, wenn Proccess Count zu hoch ist
ProcessMatch webuser "web???"
ProcessMatch webcgi "php.cgi"
ProcessMatch vmail "dovecot"
</Plugin>

Die Idee dabei ist, dass man diese Prozessgruppen detailiert beobachten kann und nicht nur die normale Gesamtprozess Graphen.

Heute habe ich in meinem Imap Postfach aufgeräumt und diverse Archiv Ordner verschoben und indiziert. (Innerhalb von Thunderbird)

So sah das in der Graphik, aus man erkennt deutlich, in welchem Zeitraum das indizieren stattfand.

Das macht Hoffnung, für spätere Ernstfälle

Update 13.03.2020:

Mit den Notifications bin ich nun ein Stück weitergekommen.

Hier ein Ausschnitt aus der threshold.conf:

<Plugin "processes-vmail">
    <Type "ps_count">
        Instance "processes"
        Percentage false
        Hits 4
        WarningMax 4
    </Type>
    <Type "ps_rss">
        Percentage false
        Hits 4
        WarningMax 550000000
    </Type>

#   ps_cputime. Ohne Angabe einer Instance gilt WarningMax für jeden
    <Type "ps_cputime">
        Percentage false
        Hits 4
        WarningMax 25000
    </Type>
</Plugin>

Ach, bevor ichs vergesse, während des experimentierens mit den Werten fand ich AutoRefresh auf den Detail Seiten ganz praktisch.

# In detail.php nach Header() ein Echo und gut.

header("Content-Type: text/html");
echo '<meta http-equiv="refresh" content="30"/>';