fdell Falls jetzt der Hinweis kommt, nicht mit 7zip zu sichern weil userrechte und Pfadangben nicht einbezogen werden, da kann ich beruhigen. Der Schalter -spf sichert diese zumindest für /home, das habe ich mehrfach getestet.

Das ist leider nicht der Fall.

Schau dir mal:
man 7za -> Backup and limitations
an. Ebenfalls für -spf gilt das nicht:
7za --help
schreibt für -spf: use fully qualified file paths

Eigentümer der zu sichernden Datei im Archiv ist immer der User/Gruppe, welcher das Archiv erstellt. Hast du ja bei root schon gemerkt. Auch werden nicht die Zugriffsrechte(?), zumindest nicht die ggf. vorhandenen erweiterten und ACLs gesichert. Wahrscheinlich ebensowenig wie Sym-/Hard-Links und spezielle Dateien(Pipes, Devices,etc). Kurz: 7z ist für richtiges Backup unter Linux nicht geeignet, allenfalls für den Inhalt einer Datei.

Wenn du (wie bisher) als dein USER einfach nur Dateien deines USERS unbedingt in ein 7z-Archiv packen willst, dann geht das mit den o.a. Einschränkungen. Du kannst halt als USER wieder Texte, Bilder etc. aus dem Archiv holen. Es werden aber nur Inhalte gesichert.
Wenn es allerdings darum geht auch andere als DEINE Dateien "wie das Original" (aus Sicht des Dateisystems) zu sichern, dann führt kein Weg über die in der manpage angemerkte Kombination von tar und 7z. Wenn es denn unbedingt ein 7z-Archiv sein muß.

(Oder überhaupt ein Archiv. Ich habe böses Lehrgeld bezahlt, ein BACKUP (also die einzige KOPIE) in ein Archiv-Format abzulegen. Nie wieder! Archive sind nur dazu nutze, eine Ansammlung von Daten ressourcenschonend zu transportieren. My 2 ¢).

Überlegung zu deinem Backup-Skript:

  • Lass das ganze Skript als root-Skript laufen
    Das spart dir u.a. wieder die sudo-Orgien.
  • Ändere zu tar (und ggf. 7z Komprimierung)
    Mittels der Kombi tar/7z(a) bleiben alle UNIX-Eigentümer/Rechte/Flags an zu sichernden Inhalten erhalten. Du kannst also z.B. sowohl Dateien aus /etc als auch /home/USER (und/oder /home/FRAU_DES_USERS) wirklich "original" in das tar-Archiv(plus ggf. 7z komprimiert) packen lassen.
    tar kann alles was du in deinem Skript mit 7z machst, z.B. in-/exclude-Listen. Die Syntax ist halt anders.
  • fdell hat auf diesen Beitrag geantwortet.

      GerBra Danke für deine Hinweise, du hast sicher Recht, für ein komplettes Sys-backup ist 7zip nicht geeignet. Da ich nur meine Texte und Tabellen aus /home sichern will, sind die Nachteile mit 7zip nicht so relevant.

      Es kommen noch die Skripte aus /usr/local/bin und wenn ich schonmal dabei bin, auch ein paar (config) Dateien aus /etc dazu. Die werden auch korrekt mit Unterordnern gespeichert, allerdings werden Eigentümer und Nutzerrechte nicht gespeichert, da hast du recht. Das ist ein Nachteil mit dem ich für diesen Einsatzzweck leben kann. Das Skript läuft als root und liegt in /usr/local/bin. Diese Systemdateien kann ich, muss ich aber nicht bei jedem Lauf sichern, da ich mehrfache Backups davon habe.

      Ich mache ohnehin schon seit Jahren keine vollständigen Systembackups mehr, nur meine "daily workfiles" mit wenigen 100MB werden gesichert. Ein neues Arch Linux ist schnell installiert und mit den Paketlisten die nach jedem Sysupdate erstellt werden, kann ich schnell mein komplettes System replizieren. Selbst die genialen (Partitions-) Backups mit Clonezilla (ich bin ein echter Fan davon) nutze ich nicht mehr, weil ein fresh-install ziemlich zügig möglich ist.

      Bei tar gibt es ein paar Probleme:

      1. meckert es wenn ein File aus der Auswahlliste nicht gefunden wird (wenn es gelöscht oder deinstalliert wurde)
      2. hat es Probleme mit Ordnern & Dateien die mit den selben Zeichen (Namen) beginnen

      Anderes Thema:
      Wäre es möglich zu Beginn des Skripts den xfce-terminal starten zu lassen damit ich eventuelle Meldungen sehe?

      Habe ein /usr/bin/xfce4-terminal an den Anfang des Skripts gesetzt, das Terminal wird auch als root gestartet, aber der Ablauf und eventuelle Meldungen des Skripts werden nicht darin angezeigt.
      Oder muss ich die /usr/share/applications/xfce4-terminal.desktop Datei dazu nehmen?

          fdell Anderes Thema:
          Wäre es möglich zu Beginn des Skripts den xfce-terminal starten zu lassen damit ich eventuelle Meldungen sehe?

          Habe ein /usr/bin/xfce4-terminal an den Anfang des Skripts gesetzt, das Terminal wird auch als root gestartet, aber der Ablauf und eventuelle Meldungen des Skripts werden nicht darin angezeigt.

          Wenn du aus dem Skript raus ein Terminal startest dann bekommt das ja eine "neue" Shell, ist quasi ein abgekoppelter Prozeß vom aufrufenden Skript.
          Gehe es anders an: starte in einem neuen Terminal-Window das Skript.

          Ich habe kein xfce4-Terminal, schau dir die entsprechende man-Page oder --help zum Terminal an. Den meisten(allen?) X-Terminals kann man Befehle mitgeben - also dein Skript.
          Für xterm wäre das z.B. die Option -e :

          xterm -e "/pfad/zum/Skript ; read"
(wenn das Skript ausführbar ist, oder)
xterm -e "bash /pfad/zum/Skript ; read"

          Das zusätzliche read bewirkt, daß das Terminal sich nach dem Ende des Skripts nicht gleich wieder schließt, es wartet auf einen beliebigen Tastendruck.

          Das X-Terminal mußt du halt entweder schon aus root starten (daß scheint bei dir ja zu funktionieren, normalerweise kann root nicht auf dein USER-X-$DISPLAY zugreifen ("Desktop"). Andere Möglichkeiten wären via Erlaubnis über die .Xauthority bzw. xauth oder per pkexec (was u.U. wieder eine Paßwortabfrage erfordert).

          Zweiter Weg wäre, das Terminal als USER zu starten und das auszuführende Skript darin per sudo.

            Ich würde alle Ausgaben des Skripts in eine "Logdatei" umleiten. Die "Logdatei" kannst du dann in dein $HOME verschieben und mit chown anpassen.

            Oder du schickst dir die "Logdatei" per Email.

            Oder du logst alle Meldungen unter /var/log. Du kannst dir auch eine systemd-Unit basteln und das Skript dann mit systemctl start skript.service starten.

            Es gibt auch die Möglichkeit, zuerst eine tmux-Sitzung zu öffnen und das Skript darin aufzurufen. Dann sollten die Ausgaben erhalten bleiben, solange die tmux-Sitzung erhalten bleibt.

            Es gibt viele Möglichkeiten, das "professionell" anzupacken. Nur ein paar Ideen für die kommenden Festtage.

            fdell damit ich eventuelle Meldungen sehe?

            su
<passwort>
echo "Meldung"

            Meldung

            Auch eingeloggt als root zeigt das terminal die Befehlsausgaben an.

              ich überlege ob es grundsätzlich eine gute Idee ist, soviel Aufwand zu betreiben um den normalen USER mit extra Privilegien auszustatten, stattdessen ein "su -l" in der Konsole eingeben und ich bin da wo ich hin will.

              Die Frage ist jetzt, kann ich meine gewohnten aliases der "~/.bash_aliases" weiter verwenden?
              Ich habe zwar die Syntax der grundlegenden Programme (pacman, systemctl usw.) basal gespeichert, jedoch bin ich auch bequem und möchte nicht jedes mal den ganzen Aufruf/Befehl eintippen müssen...

              Kann ich für root eine bash_aliases schreiben und diese in "/etc/bash.bashrc" verlinken?

              if [ -f /root/.bash_aliases ]; then
    . /root/.bashrc
fi

              Oder ist das sicherheitstechnisch weniger sinnvoll?

              Ich persönlich habe keinen einzigen alias und rede mich selbst immer noch mit eigenem Namen an. 😉
              Die drei Befehle sind schneller in die Konsole getippt, als darüber nachzudenken welche Abkürzung man für was, wann eingerichtet hat. Meine 1,5 Cent.

              Ich verzichte auf sudo und nutze su -l.
              Im root Ordner habe ich nun eine .profile und eine .bash_aliases erstellt und alles funktioniert soweit.
              Die NOPASSWD Zeile in /etc/sudoers ist leer und eigentlich könnte ich sudo jetzt deinstallieren.

              Ich lasse das Thema offen, da mir (und anderen) bestimmt noch ein paar Anfängerfragen zu bashskripten einfallen werden. Ich finde es z.B. immernoch eine gute Idee, Start und Ausgaben eines root-skripts per notify-send an den normalen USER zu senden bzw. einzublenden. Da muss ich noch einiges lesen...

              Das war eine Menge input zu bashskripten in den letzten Tagen und ich bin immer noch am nachlesen was @GerBra und @Gerry_Ghetto mir vermitteln wollten. Danke an alle, die so nett unterstützt haben :-)

              4 Tage später

              Hallo zusammen,
              ich nutze ein etc-hosts file um Werbung heraus zu filtern.
              Die Datei lade ich von dieser URL https://hosts.ubuntu101.co.za/hosts
              Ein systemd *.timer startet einen *.service mit dem skript zum herunterladen der hosts-datei.

              Das Problem ist, das Skript bricht ab, wenn dieser Verbindungsfehler kommt:

              --2024-01-04 10:56:13--  https://hosts.ubuntu101.co.za/hosts
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… 2a01:4f8:140:5021::5, 2a01:4f8:140:5021::39, 88.198.70.39
Verbindungsaufbau zu hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)|2a01:4f8:140:5021::5|:443 … fehlgeschlagen: Keine Route zum Zielrechner.
Verbindungsaufbau zu hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)|2a01:4f8:140:5021::39|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 19505850 (19M) [application/octet-stream]
Wird in »hosts.2« gespeichert.

              Hat jemand eine Idee, wie ich das Skript anpassen kann,
              damit es nicht nach diesem Verbindungsfehler abbricht?

              Das download skript:

              #!/bin/sh

# Make sure we're running as root
if 
(( `id -u` != 0 )); then { echo "Sie haben keine Root Rechte, beende..."; exit; } 
fi

cd /tmp
wget https://hosts.ubuntu101.co.za/hosts

head -400 hosts | grep --quiet ^127.0.0.1
if (( $? != 0 )); then
   echo "Error: Falsche hosts Download-Liste"
   exit 1
else
   cp hosts /etc/hosts
fi
              • Martin-MS hat auf diesen Beitrag geantwortet.

                fdell Das Problem ist, das Skript bricht ab, wenn dieser Verbindungsfehler kommt:

                Ich sehe da noch keinen Verbindungsfehler. Die Anfrage wird in zwei IPv6- und einer IPv4-Adresse(n) aufgelöst. Die Verbindung nach ::5 schägt zwar fehl, aber nach ::39 ist erfolgreich, es wird "verbunden" mit Status 200 gemeldet und der Download findet statt.

                An welcher Stelle bricht das Skript denn ab?

                fdell Hat jemand eine Idee, wie ich das Skript anpassen kann,
                damit es nicht nach diesem Verbindungsfehler abbricht?

                Du könntest den resultcode von wget mit $? abfragen; wenn der <> 0 ist, war die Verarbeitung nicht erfolgreich und du könntest darauf entsprechend reagieren.

                Außerdem würde ich wget noch die Downloadoption -O hostsübergeben, damit sowas

                Wird in »hosts.2« gespeichert.

                nicht passiert.

                • fdell hat auf diesen Beitrag geantwortet.

                      Martin-MS Der Fehler tritt nicht immer auf, aktuell tritt er nicht auf.
                      Aber zur vorgesehenen Uhrzeit (06:00Uhr) tritt dieser Fehler auf
                      wenn das Skript per *.service oder *.timer getriggert wird:

                      [root@arch1 ~]# ctlstat upd_hosts.service
× upd_hosts.service - update etc-hosts file daily at 06:00 CET
     Loaded: loaded (/etc/systemd/system/upd_hosts.service; static)
     Active: failed (Result: exit-code) since Tue 2024-01-02 09:33:02 CET; 28min ago
   Duration: 153ms
TriggeredBy: ● upd_hosts.timer
    Process: 517 ExecStart=/usr/local/bin/upd_hosts.sh (code=exited, status=1/FAILURE)
   Main PID: 517 (code=exited, status=1/FAILURE)
        CPU: 90ms

Jan 02 09:33:02 arch1 systemd[1]: Started update etc-hosts file daily at 06:00 CET.
Jan 02 09:33:02 arch1 upd_hosts.sh[522]: --2024-01-02 09:33:02--  https://hosts.ubuntu101.co.za/hosts
Jan 02 09:33:02 arch1 upd_hosts.sh[522]: CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Jan 02 09:33:02 arch1 upd_hosts.sh[522]: Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… fehlgeschlagen: Temporärer Fehler bei der Namensauflösung.
Jan 02 09:33:02 arch1 upd_hosts.sh[522]: wget: Host-Adresse »hosts.ubuntu101.co.za« kann nicht aufgelöst werden
Jan 02 09:33:02 arch1 upd_hosts.sh[534]: head: 'hosts' kann nicht zum Lesen geöffnet werden: Datei oder Verzeichnis nicht gefunden
Jan 02 09:33:02 arch1 upd_hosts.sh[517]: Error: Falsche hosts Download-Liste
Jan 02 09:33:02 arch1 systemd[1]: upd_hosts.service: Main process exited, code=exited, status=1/FAILURE
Jan 02 09:33:02 arch1 systemd[1]: upd_hosts.service: Failed with result 'exit-code'.

                        Aha, also wenn das Skript manuell aufgerufen wird tritt der Fehler nicht auf, aber wenn er als systemd.service gestartet wird.

                        Ich habe beides, Skript und Unit mal in einer VM installiert und ausgeführt, da lief es auch als systemd.service problemlos.

                        wget soll allerdings Probleme mit rekursiven Namensauflösungen haben. Das erklärt aber noch nicht, warum es beim manuellen Aufruf funktioniert und aus einem systemd.service nicht; eigentlich müsste es immer laufen oder nie.

                        Du kannst es mal statt wget mit curl versuchen, das läuft ähnlich, da musst du aber explizit die -o-Option setzen, damit der Output in eine Datei und nicht im Terminal ausgegeben wird. Möglicherweise kommt systemd damit besser zurecht.

                        da der Fehler

                        Jan 02 09:33:02 arch1 upd_hosts.sh[522]: Auflösen des Hostnamens hosts.ubuntu101.co.za (hosts.ubuntu101.co.za)… fehlgeschlagen: Temporärer Fehler bei der Namensauflösung.
Jan 02 09:33:02 arch1 upd_hosts.sh[522]: wget: Host-Adresse »hosts.ubuntu101.co.za« kann nicht aufgelöst werden
Jan 02 09:33:02 arch1 upd_hosts.sh[534]: head: 'hosts' kann nicht zum Lesen geöffnet werden: Datei oder Verzeichnis nicht gefunden

                        Morgens um 6 Uhr bzw. gehäuft vormittags auftritt, könnte es doch auch am Server liegen der nicht antwortet oder? Der Server ist ziemlich langsam, Downloadspeed ist unter 500kb/s. Vielleicht kommen vormittags zuviele Anfragen an der ipv4 Adresse an?

                        Gegen Mittag hin funktioniert es häufiger ohne Verbindungsfehler. Die Option -O hosts habe ich eingefügt (wget). Es wurde aber auch ohne diese immer in die /etc/hosts geschrieben, egal was im Terminal angezeigt wurde. Eine "hosts.2" o.ä. wurde nie angelegt.

                        • Martin-MS hat auf diesen Beitrag geantwortet.

                          fdell Morgens um 6 Uhr bzw. gehäuft vormittags auftritt, könnte es doch auch am Server liegen der nicht antwortet oder?

                          Die Verbindung zum Server kommt wegen der fehlgeschlagenen Namensauflösung gar nicht erst zustande. Wenn er nicht erreichbar wäre, sähe der Fehler je nach Ursache anders aus.

                          fdell Eine "hosts.2" o.ä. wurde nie angelegt.

                          In deinem Beispiel weiter oben aber schon. Die Dateien werden von wget mit Zahlen erweitert, wenn mehr als eine Datei im Zielverzeichnis existiert. Wenn also aus irgendeinem Grund die Verarbeitung abbricht oder wiederholt wird, steht die letzte gültige Datei wie in diesem Fall in hosts.2. Nach einem Abbruch und Wiederholung würde eine unvollständige Datei nach /etc/hosts geschrieben, deswegen ist es sicherer, die Ausgabedatei ausdrücklich als Option dem Aufruf zu übergeben.

                          • fdell hat auf diesen Beitrag geantwortet.

                                Martin-MS Sorry, ich muss das immer erst nachlesen...
                                Das hatte ich garnicht verstanden, weil ich nur die /etc/hosts monitored hatte. Da das Skript zuerst nach /tmp und dann nach /etc/hosts kopiert ist mir nicht aufgefallen, das wohl tatsächlich eine "hosts2" angelegt wurde. Die Option -O hosts habe ich eingefügt (wget) und das Skript abgeändert:

                                #!/bin/sh

# Make sure we're running as root
if 
(( `id -u` != 0 )); then { echo "Sie haben keine Root Rechte, beende..."; exit; } 
fi

cd /tmp
wget -O hosts https://hosts.ubuntu101.co.za/hosts
head -400 hosts | grep --quiet ^127.0.0.1
if (( $? != 0 )); then
   echo "Error: Falsche hosts Download-Liste"
   exit 1
else
   mv hosts /etc/hosts
fi

                                Das Problem liegt leider am DNS Server. Ich habe in meiner Fritzbox den DNS-Server von "Cloudflare" und "DNS over TLS (DoT)" eingerichtet. Dies führt dazu, dass die Namensauflösung temporär nicht funktioniert.

                                Wenn ich das Skript oder den *.service manuell starte, funktioniert es komischerweise fehlerfrei bei der Namensauflösung. Wenn ich in der Fritzbox-config den DNS-Server auf "Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)" ändere, funktioniert das ganze per *.timer oder *.service ebenfalls problemlos.

                                Ich lasse den *.timer & *.service jetzt weg und starte das Skript manuell, da ich nicht auf den DNS-Server und "DNS over TLS (DoT)" verzichten möchte.

                                • GerBra hat auf diesen Beitrag geantwortet.

                                    Hast du es denn auch mal mit curl versucht? Da die vorhandenen Inhalte von /etc/hosts sowieso überschrieben werden, könnte man die Aufgabe auch mit einem Einzeiler erledigen:

                                    curl https://hosts.ubuntu101.co.za/hosts | grep '^127.0.0.1\|^255.255.255.255\|^::1\|^fe80\|^0.0.0.0' >/etc/hosts

                                    Die Überprüfung auf den root-Benutzer ist bei Ausführung als system unit entbehrlich, und auf die Plausibilitätsprüfung kann wegen des grep-Filters eigentlich auch verzichtet werden.

                                    Was mir bei meinen Tests allerdings auffiel war, dass systemd-resolved Hostnamen mit Unterstrich als ungültig zurück weist und für jeden dieser Hostnamen (wovon es aktuell 856 gibt) zwei Zeilen im journal ablegt. Das passiert bei jeder DNS-Anfrage und dürfte so das Journal ziemlich zumüllen. Wenn du einen anderen Resolver verwendest, ist das vielleicht egal, aber ein Blick dazu ins journal wäre trotzdem angezeigt.

                                    Außerdem dürfte ein solcher Eintrag dann auch nicht auf 0.0.0.0umgeleitet werden, was dann den eigentlichen Nutzen der Liste zweifelhaft erscheinen lässt, denn für diese Einträge wird der Hostname dann doch in seine eigentlich Adresse aufgelöst und die Verbindung hergestellt.

                                    • GerBra hat auf diesen Beitrag geantwortet.

                                      fdell Das Problem liegt leider am DNS Server. Ich habe in meiner Fritzbox den DNS-Server von "Cloudflare" und "DNS over TLS (DoT)" eingerichtet. Dies führt dazu, dass die Namensauflösung temporär nicht funktioniert.

                                      Wenn ich das Skript oder den *.service manuell starte, funktioniert es komischerweise fehlerfrei bei der Namensauflösung. Wenn ich in der Fritzbox-config den DNS-Server auf "Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)" ändere, funktioniert das ganze per *.timer oder *.service ebenfalls problemlos.

                                      Es könnte einfach sein, daß die TLS-Session zu deinem Nameserver abgelaufen wäre zu diesem Zeitpunkt. Und wget/curl versuchen dann nur einmal, eine IP-Adresse für den Download zu erhalten.
                                      Möglichkeiten:
                                      a) Den wget-Aufruf mehrmals zu starten, z.B. in einer for-Schleife dreimal mit 1 Sekunde Pause. Die Schleife kann abgebrochen werden wenn der Return-Wert von wget 0/erfolgreich ist.
                                      b) Evtl. reicht schon ein vorheriger DNS-Request um die Session zum DNS-Server zu initiieren. Z.B. durch ein vorangehendes:

                                      ping -c 3 hosts.ubuntu101.co.za
sleep 1

                                      (Die ping-Ausgabe kann - wenn es so klappt - komplett nach /dev/null umgeleitet werden.)

                                      Fakt ist auf jedenfall: Da das Downloaden der Liste ja der zentrale Vorgang des Skripts ist, bedarf dieser eine eigene "Fehler"-Behandlung und sollte nur dann abbrechen(nichts tun), wenn der User bestimmte Kriterien als nicht möglich ersieht.

                                      Leider (aber in punkto Sicherheit zum Glück) erlauben weder wget noch curl andere DNS-Server für die Aktion zu verwenden, beide Tools sind ohne die entsprechende Option kompiliert. Dann könnte z.B. für diesen Aufruf dein Provider DNS verwendet werden anstatt des System-DNS. Es wäre allerdings möglich sich bei Bedarf ein eigenes (ggf. statisch gelinktes) wget/curl zu bauen und z.B. nach /usr/local abzulegen. Das wäre aber IMHO mit "Kanonen auf Spatzen" gefeuert und bedarf auch einiger Sicherheitsvor-/nachkehrungen.

                                      Martin-MS Außerdem dürfte ein solcher Eintrag dann auch nicht auf 0.0.0.0umgeleitet werden, was dann den eigentlichen Nutzen der Liste zweifelhaft erscheinen lässt, denn für diese Einträge wird der Hostname dann doch in seine eigentlich Adresse aufgelöst und die Verbindung hergestellt.

                                      Das stimmt nicht. Solange die hosts-Datei primär für DNS-Resolv genutzt wird werden diese Adressen zu 127.0.0.1/localhost umgesetzt.
                                      Kannst du testen mit z.B.

                                      [root@ws01 ~]# dig zzzzzz.petrodollar.org && ping -c 2 zzzzzz.petrodollar.org
...
;; ANSWER SECTION:
zzzzzz.petrodollar.org.	3213	IN	A	103.224.182.253
...
PING zzzzzz.petrodollar.org (103.224.182.253) 56(84) Bytes an Daten.
64 Bytes von lb-182-253.above.com (103.224.182.253): icmp_seq=1 ttl=55 Zeit=165 ms
64 Bytes von lb-182-253.above.com (103.224.182.253): icmp_seq=2 ttl=55 Zeit=165 ms

[root@ws01 ~]# echo "0.0.0.0 zzzzzz.petrodollar.org" >> /etc/hosts

[root@ws01 ~]# dig zzzzzz.petrodollar.org && ping -c 2 zzzzzz.petrodollar.org
...
;; ANSWER SECTION:
zzzzzz.petrodollar.org.	3111	IN	A	103.224.182.253
...
PING zzzzzz.petrodollar.org (127.0.0.1) 56(84) Bytes an Daten.
64 Bytes von localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 Zeit=0.012 ms
64 Bytes von localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 Zeit=0.023 ms

[ich@ws01 ~]$ wget zzzzzz.petrodollar.org
--2024-01-07 09:38:39--  http://zzzzzz.petrodollar.org/
Auflösen des Hostnamens zzzzzz.petrodollar.org (zzzzzz.petrodollar.org)… 0.0.0.0
Verbindungsaufbau zu zzzzzz.petrodollar.org (zzzzzz.petrodollar.org)|0.0.0.0|:80 … fehlgeschlagen: Verbindungsaufbau abgelehnt.

                                      Besser wäre so eine hosts-(Block)-Liste natürlich auf dem lokalen Router/DNS-Server aufgehoben.

                                      • Martin-MS hat auf diesen Beitrag geantwortet.

                                            GerBra Das stimmt nicht. Solange die hosts-Datei primär für DNS-Resolv genutzt wird werden diese Adressen zu 127.0.0.1/localhost umgesetzt.

                                            …solange der Hostname keine Unterstriche enthält und nicht systemd als Resolver verwendet wird. Wenn hosts z. B. so aussieht

                                            [root@archlinux ~]# cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.

0.0.0.0 1.03rid7_easycoops.filter.clickbank.net
0.0.0.0 google.de

                                            dann gehen sowohl ping als auch wget für das erst Ziel durch und für das zweite Ziel nicht:

                                            [root@archlinux ~]# ping -c1 google.de
ping: google.de: Zu diesem Hostnamen gehört keine Adresse
[root@archlinux ~]# ping -c1 1.03rid7_easycoops.filter.clickbank.net
PING clickbank-apache-54377296.us-west-2.elb.amazonaws.com (35.167.122.11) 56(84) Bytes an Daten.
^C
--- clickbank-apache-54377296.us-west-2.elb.amazonaws.com ping-Statistik ---
1 Pakete übertragen, 0 empfangen, 100% packet loss, time 0ms

[root@archlinux ~]# wget google.de
--2024-01-07 10:59:02--  http://google.de/
Auflösen des Hostnamens google.de (google.de)… fehlgeschlagen: Zu diesem Hostnamen gehört keine Adresse.
wget: Host-Adresse »google.de« kann nicht aufgelöst werden
[root@archlinux ~]# wget 1.03rid7_easycoops.filter.clickbank.net
--2024-01-07 10:59:15--  http://1.03rid7_easycoops.filter.clickbank.net/
Auflösen des Hostnamens 1.03rid7_easycoops.filter.clickbank.net (1.03rid7_easycoops.filter.clickbank.net)… 35.167.122.11, 54.191.88.1
Verbindungsaufbau zu 1.03rid7_easycoops.filter.clickbank.net (1.03rid7_easycoops.filter.clickbank.net)|35.167.122.11|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 400 400
2024-01-07 10:59:16 FEHLER 400: 400.

                                            und das journal meldet (abweichender Zeitstempel wegen früherem Versuch)

                                            Jan 07 10:46:47 archlinux systemd-resolved[269]: /etc/hosts:4: hostname "1.03rid7_easycoops.filter.clickbank.net" is not valid, ignoring.
Jan 07 10:46:47 archlinux systemd-resolved[269]: /etc/hosts:4: line is missing any valid hostnames

                                            GerBra Besser wäre so eine hosts-(Block)-Liste natürlich auf dem lokalen Router/DNS-Server aufgehoben.

                                            Fände ich auch, weil man damit das gesamte Netzwerk und nicht nur ein Gerät schützen würde. Mir ist aber aus dem SoHo-Bereich kein Router bekannt, der >600.000 Ziele in einer Sperrliste verwalten könnte. Die Liste ließe sich aber auch deutlich ausdünnen, wenn man die Sperren z.B. auf die ganze Domain clickbank.net beschränken und nicht jeden einzelnen Host aufführen würde.

                                            • GerBra hat auf diesen Beitrag geantwortet.

                                                  Martin-MS …solange der Hostname keine Unterstriche enthält und nicht systemd als Resolver verwendet wird.

                                                  Ups. Da hält sich der systemd-resolved wohl strikt an RFC 952, obwohl die "reale" Welt anders aussieht. Mit dem glibc-resolver gibt es das Problem nicht.
                                                  Ich habe auf die Schnelle auch nichts in den manpages gesehen daß man systemd-resolver entsprechend konfigurieren könnte.

                                                  Martin-MS Mir ist aber aus dem SoHo-Bereich kein Router bekannt, der >600.000 Ziele in einer Sperrliste verwalten könnte.

                                                  dnsmasq kann es wohl, ist halt kein Hardware-Blob:

                                                  It is possible to use dnsmasq to block Web advertising  by  using  a  list  of  known  banner-ad servers,
all  resolving to 127.0.0.1 or 0.0.0.0, in /etc/hosts or an additional hosts file. The list can be very long,
dnsmasq has been tested successfully with one million  names.  That  size file needs a 1GHz processor and
about 60Mb of RAM.

                                                  Martin-MS Die Liste ließe sich aber auch deutlich ausdünnen

                                                  OnTopic: Wäre ja eine kleine "Hausaufgabe" so ein Parser-Skript zu schreiben... <g>

                                                          GerBra OnTopic: Wäre ja eine kleine "Hausaufgabe" so ein Parser-Skript zu schreiben... <g>

                                                          Ähm... also ich würde da lieber etwas anderes schreiben wollen.

                                                          Habe herausgefunden, dass "ublock Origin" (eine Firefox Erweiterung) deutlich mehr Werbeinhalte blockiert als eine "/etc/hosts" (habe mittlerweile diverse getestet). Ich nutze diese Seite für Wettervorhersagen: https://kachelmannwetter.com/de/wetter/2950159-berlin

                                                          Hier werden die Werbeinhalte nicht von der "/etc/hosts" blockiert, weil die url's der Werbebanner auf dem Server von https://kachelmannwetter.com liegen, also wird die Werbung angezeigt. Die FF Erweiterung filtert das alles raus, auch bei anderen Seiten wie Stern oder Spiegel usw. Der Erste Aufruf einer Webseite dauert zwar etwas länger, aber dafür ist man zuverlässig die Werbung los. Weitere Aufrufe der Seite sind dann deutlich schneller.

                                                          OnTopic:
                                                          Ich überlege ein "Ausgabe-Skript" zu schreiben, dass es mir ermöglicht, jede Ausgabe eines Befehl- /Skriptaufrufs in der Konsole zu zeigen und parallel in eine *.log Datei zu schreiben. Man bräuchte dann nur das "Ausgabe-Skript" an einen Befehl oder Skriptaufruf anhängen.

                                                          Bisher habe ich dafür jedes mal ein >> ${out} oder ein &>> $out geschrieben. Das funktioniert auch, aber wenn die Ausgabe umgeleitet ist, wird leider in der Konsole nichts angezeigt. Schöner wäre es, die Ausgabe in der Konsole zu sehen und bei Bedarf, eine *.log zu haben, in der man später in Ruhe etwas nachlesen kann.

                                                          Da es die "log Funktion" und vor allem "Journald" bereits gibt, werde ich erstmal die manpages dazu lesen und versuchen zu verstehen.

                                                          • Martin-MS hat auf diesen Beitrag geantwortet.