Beiträge von Ubuntiner

    Ich kann Dir bei "RadarBox" selbst nicht helfen, weil es sehr speziell ist, aber in den Logfiles werden alle wichtigen Ereignisse protokolliert. Und aus den Logfiles lässt sich auch erkennen, ob die Datenverbindung vom Pi zum Flugverkehrsanbieter, oder Dein ADS B Empfänger fehlerhaft ist.

    Die Logfiles befinden sich in /var/log/* für die letzten 7 Tage und werden täglich um einen Tag nach hinten rotiert.

    /var/log/sys*, kern*, auth* wären meine ersten Durchsichtskandidaten.

    Servus !

    Herzlichen Dank! Die Logfiles werde ich noch sichten müssen, da kam ich noch nicht zu. Es zeichnet sich ein merkwürdiges Muster ab, wo "keine Daten" vorliegen.

    Benutzt Radarbox denn einen anderen Unterbau als die anderen Feeder ?

    Ich nehme dump1090 und alle Feeder greifen darauf zu.

    Ich habe einen separaten Feeder für FR24. Auf diesem mit dem merkwürdigen Verhalten ist als Unterbau für Radarbox PiAware installiert. Händisch, nicht über das Image. Entgegen meiner Angewohnheit, nahm ich hier die 32-Bit-Version, weil die 64er wohl nicht so rund läuft damit.

    Dann Radarbox nach Anleitung installiert inklusive MLAT-Client.

    Viele Grüße und herzlichen Dank für die Antworten!

    Flug-Ubu

    Moin!

    Zunächst, es scheint eher ein Problem mit dem Programm zu sein, nicht mit dem Pi. Sofern es hier dann keine Hilfe dafür gibt, bitte ich um Löschung bzw. Nachricht. Wird mir hier dennoch geholfen, bin ich natürlich dankbar.

    Ich mag es, Flugzeuge mittels ADS-B zu verfolgen. Diverse Systeme laufen hier ohne Probleme, Flightradar24, PiAware usw.

    Radarbox ist auch so ein "Flug-Feeder", man empfängt Flugzeuge, die ihre Datenpakete ausstrahlen und bietet die dann dem jeweiligen Anbieter an. So entsteht eine möglichst flächendeckende Karte.

    Der Datenstrom bricht immer wieder mal ab. Der Feeder ist online, aber es werden keine Daten übertragen. Andere Programme melden sehr wohl Flugverkehr. Was muss ich noch in der *.ini von RadarBox um- oder einstellen, dass die Daten konstant und kontinuierlich übertragen werden? Oder ist das sozusagen üblich bei RadarBox, dass es immer wieder Aussetzer gibt? Alle anderen Programme mit ADS-B-Empfang empfangen kontinuierlich.

    Viele Grüße und ich liefere bereitwillig alle Logs, Ini-Dateien und Informationen, wenn nötig bzw. gewünscht

    Harald

    OK, nicht als root. D. h. root-Rechte werden schon mal nicht benötigt. D. h. (wenn man das schon so machen will) sollte man "pihole -up" nicht in einer root-crontab benutzen.

    *Seufz* Ich sehe schon, dass selbst zusammen Gepuzzelte ist scheinbar nicht gut. Ich war schonmal stolz, dass ich überhaupt einen Cronjob zum laufen brachte.

    Danke für alle Hilfen und Denkanstösse, ich schaue mir das mal mit dem Skript an, aber erstmal nehme ich hier das "pihole -up" raus und mache das ggf. händisch.

    Dann warte mal auf den nächsten Lauf deines Cronjobs. Im ersten Logauszug könnte auch apt mit !=0 terminiert haben.

    Wenn du schon auf diese Weise Updates machen willst, schreibe die Befehle nacheinander in ein Script und rufe das im cronjob auf. Am besten noch mit Logging. Dann weisst du, was schief lief.

    Ansonsten, was rpi444 sagt. diese Art der Updates sind ... subobtimal. Gucke dir mal z.B. unattended-upgrades an.

    Ja gut, wird gemacht. Ich sehe schon, das werde ich alles gesamt umstellen müssen. Wie ich das dann in Skriptform bringe und via Cronjob aufrufen kann, muss ich mir dann noch aneignen.

    Wo, in der Kommandozeile? Die Umgebung der Kommandozeile kann aber eine andere sein als die in der root-crontab. Was wird für ein "pihole -up" alles benötigt?

    Äh ... ich schaute via SSH auf dem Pi nach und gab folgendes ein, mit nachfolgender Ausgabe:

    Das kann schon mal nicht stimmen.

    Danke sehr, jetzt ist mir der Groschen auch gefallen. Nur "crontab -e" setzt einen User-Cronjob, der mit sudo vorweg automatisch einen Root-Cronjob.

    Ich nehme alles zurück und behaupte das Gegenteil: Ich richtete auf allen Geräten einen Root-Cronjob ein. Dann werde ich überall mal editieren und das sudo rausnehmen.

    Du siehst doch, dass der Job ausgeführt wird.

    Wahrscheinlich weil pihole -up nicht mit Exitcode 0 terminiert und das && reboot damit nicht ausgeführt wird.

    Lasse deine 3 Commands händisch nacheinander laufen und schaue dir den jeweiligen Exitcode $? an.

    Ja eben, dass irritierte mich ja so. Danke für den Gedankenanstoss. Der erste Teil scheint in der Tat gelaufen zu sein, dafür ist die Ausgabe etwas zu kurz. Verzeih die dumme Frage, aber wo und wie erhalte ich einen Exitcode?

    Code
    harald@pi64pihole:~ $ sudo apt update
    Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
    Hit:2 http://deb.debian.org/debian bullseye InRelease                          
    Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]        
    Hit:4 http://archive.raspberrypi.org/debian bullseye InRelease                 
    Fetched 44.1 kB in 1s (42.2 kB/s)
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    All packages are up to date.

    Zuviel root tut niemals gut.

    Entweder konfigurierst Du einen cronjob als User root in der root crontab (ohne sudo), oder in der user-crontab (zB. pi) als user pi.

    Wenn sich der Pfad zu pihole nicht im Envireoment PATH befindet, dann denn absoluten Pfad verwenden.


    Servus !

    Danke für die Antwort. Erstellt habe ich sie auf allen Geräten identisch mit "sudo crontab -e", auf 4 von 5 Geräten laufen sie prima. Scheinbar wird der Cronjob erst gar nicht angefasst, es sind keine Updates gemacht und die Uptime verrät mir, dass auch der Reboot fehlt.

    Evtl. ist die Umgebung der crontab nicht ausreichend für pihole.

    Weil Du sudo für apt benutzt, ist das keine root-crontab.

    Versuch ml mit absolutem Pfad für pihole. Für "pihole -up" wird sudo (root-Rechte) nicht benötigt?

    Statt sudo in einer user-crontab, wäre m. E. besser eine root-crontab zu benutzen. Aber von apt /update/upgrade via cronjob halte ich nicht viel.

    Wessen Crontab wird benutzt?

    Wenn root, dann ist das sudo überflüssig. Wenn $user, dann dürfte auch das pihole -up sudo benötigen.

    Allgemein ist roots crontab angeraten, sudo in crontabs ist blöd.

    // zu spät

    Danke für Eure raschen Antworten. Es ist der User-Crontab in Benutzung. Das mit dem "pihole -up" ist nicht mein eigentliches Problem, der ganze Cronjob wird scheinbar nicht gestartet. Sonst wäre er bei der Uptime nicht bei 14 Tagen.

    Im Syslog eines anderen Gerätes, bei dem dieser ausgeführt wird, sieht es auch ganz anders aus:

    Moin!

    Auf meinen Kleinen läuft wöchentlich ein Cronjob, der sie aktuell hält. Auf allen richtete ich es identisch ein, bei 4 von 5 Geräten wird er auch ausgeführt.

    Einzig beim Rechner mit Pihole fügte ich noch den Befehl "pihole -up" ein. Der Cronjob lautet:

    0 3 * * 6 sudo apt update && sudo apt full-upgrade -y && pihole -up && sudo reboot

    Laut Uptime ist der Rechner seit 14 Tagen an, ich bekomme den Cronjob hier nicht ausgeführt. Was mache ich falsch?

    Beigefügt das Syslog.

    Viele Grüße!

    Eckdaten:
    Pi 4b 8 GB, Bullseye 64 Bit headless

    "Headless" bzw. "light" ist ja da nur gemeint, dass es keine graphische Oberfläche gibt. Aber natürlich habe ich die auch mal am Monitor, wenn es sein muss. Das ist das kleinste Problem, nutze ich immer wieder mal genau so.

    Das ist wahrscheinlich die Frage die du dir beantworten musst.

    Danach richtet sich deine Block Liste.

    Es gibt ja gefühlt eine Milljausend Listen.

    Vielen Dank für Deine Antwort. Da musste ich meine Denkweise noch anpassen. Mehr Listen bieten nicht direkt mehr Schutz. Ich holte mir mal vom "Blocklistproject" die, die mir am wichtigsten erscheinen. Mal sehen.

    Viele Grüße!

    Moin!

    So lange habe ich mich nicht getraut, da ich in Puncto Netzwerk in keiner Weise bewandert bin. Die neue c't brachte dann den Ausschlag, ich installierte Pi-Hole in der aktuellen Version.

    Es läuft alles auf Anhieb bestens, auch die Einträge in der FB waren schaffbar. Aber eine Frage blieb dennoch übrig.

    Aktuell werkelt eine Adlist mit ca. 140.000 Einträgen. Gibt es da Listen, die ein "must have" darstellen? Oder kommt das drauf an, wogegen ich mich schützen möchte? Bietet diese Standard-Liste schon ausreichendes, oder sollte man noch weitere dazu laden?

    Vielen Dank für die Info und viele Grüße!

    Ubuntiner

    Das liegt daran, dass es DEN Standarduser nicht mehr gibt. Der user "pi" ist weiterhin mit Bullseye schon möglich, denn es gibt z. B. (warum auch immer) "proprietäre" Software für den Raspi, die ohne den user "pi" nicht funktionieren würde.

    Herzlichen Dank für die Richtigstellung. Ich kam mit dem Standard-User "pi" nicht sehr weit beim headless einrichten. Also gewöhnte ich mir gleich einen anderen Usernamen an. Bei mir läuft allerdings auch keine Software, die "pi" verlangt.

    Hallo,

    mindestens seit Bullseye (vielleicht auch schon seit Buster) ist es nicht mehr möglich ein Raspbian headless komplett ohne Monitor und Tastatur einzurichten. Früher war es ausreichend eine leere Datei 'ssh' in die Boot-Partition zu schreiben um SSH zu aktivieren. Das geht weiterhin, aber jetzt muss erst ein User angelegt werden - der war früher schon da. Also muss ich zunächst ganz Oldshool Monitor und Tastatur an den Pi anschließen. Ich hab keine zweite Tastatur, ich musste also immer erst hinten den Rechner kriechen, USB-Dongle abziehen usw.

    Geht das eleganter? Gibt es irgendeine Möglichkeit gleich den User 'pi' mit einem Initialpasswort "anzulegen" bevor man Raspbian das erste mal startet? Vielleicht analog zum Vorgehen mit dem SSH-Server? Ich hab hier https://forums.raspberrypi.com/viewtopic.php?t=282203 was dazu gefunden, ich versteh das mit dem "cloud-init" nicht. Es gibt keinen Ordner /etc/cloud. Ist das weil der User scheinbar nicht das Raspbian-Image sondern das Ubuntu-Server-Image verwendet?

    Also ich nutze den Raspi Imager und lege dort direkt die SSH-Nutzung sowie User und PW fest. "pi" als Standarduser mag er ja seit Bullseye nicht mehr wirklich. Nachdem ich das Image auf die Karte schrieb, mache ich alles weitere komplett headless auf dem einzurichtenden Pi. Es bedarf auch keiner leeren Datei "ssh" mehr, alles lässt sich bequem im Imager festlegen.