Posts by RTFM

    Laut /boot/overlays/README für Deine RTC dtoverlay richtig eingetragen?


    Dann brauchst Du nur warten, bis ein Time Server die RTC automatisch einstellt.

    Wenn kein Time Server verfügbar ist, musst Du einen "Zeitstempel" der RTC übergeben.


    Servus !

    zur Mountoption: -o user=hans,pass=xvcgdgdzded

    Wenn Du die Optionen um "_netdev" ergänzt, wartet mount bis das Netzwerk steht.

    < man mount > - FILESYSTEM-INDEPENDENT MOUNT OPTIONS


    Wenn ich den Befehl manuell ausführe (ohne @reboot) wird das LW gemountet, alles gut.


    Auch diese funktioniert wenn ich sie manuell starte.

    Die Frage ist immer: Wer bin ich < whoami >


    Wenn der User root < cron -e > aufruft, wird die crontab des users root verwendet

    Wenn der user pi das macht, wird die crontab des users pi verwendet.

    Der user pi kann normalerweise keinen mount-Befehl erfolgreich durchführen, das kann nur root

    Wird in den Mountoptionen keine uid=,gid= gesetzt, wird uid= gid= des aufrufenden Users herangezogen.


    Das Zielverzeichnis //backup hat mMn einen Slash zuviel.



    Servus !

    chown www-data:www-data /home/pi/...../script.py


    Müsste auch funktionieren.

    Solange "www-data" nicht schreibend auf das Ausgabe-Device zugreifen kann, bleibt ihm die Ausführung des Schaltbefehles verwehrt.

    Schreibrechte auf Geräte (Devices) werden üblicherweise über die Gruppenverwaltung erteilt.

    < ls -al /dev > zeigt die schreibberechtigten Gruppen der dort aufgelisteten Geräten an.

    Auch wenn das Script auf

    rwxrwxrwx www-data:www-data /home/pi/...../script.py

    abgeändert wird, wird nur der User pi das erfolgreich ausführen können, solange nur er Gruppenmitglied für die Schreibrechte am Ausgabegerät ist.


    Dass das ACK ACL Paket bei sparsamen Distributionen, oder Spezialimages nicht vorinstalliert ist, ist schon möglich. Es wurde aber früher zumindest für das Automount, zur Verzeichniserstellung des Mountpoints, gebraucht.



    Servus !

    Wenn Du in Deinem Link "mehr lesen" aktivierst, kommen am Ende die Links für die gesuchte "Anleitung".


    Servus !

    Aus < man 5 hostname >::

    "....

    It should contain a single newline-terminated hostname string.

    ....

    it is recommended that it consists only of 7-bit ASCII lower-case characters ....

    ...."


    Ein Bindestrich ist kein lower-case character.



    Servus !



    ED: Un wie kommt der Hostname pi-test auf die sd Karte, wenn sie noch nie gestartet hat ?

    Alle User mit einer uid < 1000 sind System-User, aber die uid hast Du Dir ja elegant weggefiltert.


    Schreibrechte auf Geräte (= Device) werden meistens über die Gruppenverwaltung erteilt.

    Gruppen, mit einer gid < 1000 sind Systemgruppen. < cat /etc/group >. [Huch, so viele ?]



    Servus !

    Deine Aussage würde bedeuten, das er automatisch das EEPROM updated, wenn man auf das April-EEPROM ein 2020-08-20 booted?

    Im Bootprozess ja. Wenn er aber garnicht bootet findet der Bootprozess mit dem Austausch des EEPROM gar nicht statt.

    Im Juni 2020 hat sich beim EEPROM des Pi4 ziemlich viel geändert, sodass die Versionen nicht vertauschbar sind.


    Und dann wartet da noch wer (und ich auch) auf die Ausgabe von /etc/hostname der nicht bootenden Karte. Damit hat Dein Bootdilemma ja angeblich angefangen.


    Servus !

    Will ich außerhalb von /home/pi was machen nutze ich < sudo pcmanfm > um Dateien um zu benennen z.B.

    Ist das der Richtige Weg für den Anfang ?

    Nein, das ist imho nicht der richtige Weg, v.A. nicht für den Anfang.

    Du änderst damt sukzessive alle Fileigentümer auf den User root, soband Files editiert, verschoben, oder kopiert werden.

    Im worst case hat der User pi in seinem Homverzeichnis viele Files des Users root, die der User pi nicht mehr bearbeiten/löschen kann. Ein Webserver, der als (System)User www-data innerhalb des Webverzeichnisses (z.B. /var/web/) arbeitet, kann unbrauchbar werden.


    Das betrifft alle Dateien und Verzeichnisse innerhalb des Root-Filesystems.

    Wird in das root Filesystem eine Festplatte, oder ein Netzlaufwerk gemountet, bestimmen sich die Dateirechte nach den Optionen des Mountbefehls.


    Dass Du beim Systemstart ohne Login gleich als User pi im Grafiksystem ohne Login eingeloggt bist, hast Du selbst beim Einrichten des Pi so konfiguriert. In raspi-config kannst Du das bei einem Raspian/Pi-OS ändern.



    Servus !

    Die vielen "sudo"s gehören jedenfalls raus.

    Als User pi sollte das Script /home/pi/webdir/python/send.py auch ohne sudo funktionieren, wenn es ihm gehört.


    Mit < setfacl -m u:www-data:rx /home/pi/webdir/python/send.py >

    erlaubst Du dem User www-data das File send.py zu lesen und auszuführen, alsob er der Eigentümer (User pi) ist.


    Mit < setfacl -x u:www-data:rx /home/pi/webdir/python/send.py > wird www-data wieder aus der File Access Control List gelöscht, falls es nicht funktioniert.


    < man acl >, < man setfacl >


    Das setzt auch vorraus, dass im home-Verzeichnis des Users pi, oder im Webverzeichnis /var/www noch nicht mit Internethoaxes wie chmod777, oder Rootrechten herumgehackt wurde.


    Servus !

    Du hast dasselbe Problem mit jedem anderen Dateibrowser (aka Dateimanager) auch.

    < sudo pcmanfm > solltest Du keinesfalls verwenden, sondern die Schreibrechte (=Löschrechte) schon über die Gruppenverwaltung lösen.

    Auch musst Du bei einer Netzwerkverbindung von zwei Linux-Geräten nicht den Umweg über Windows (CIFS/SMB) gehen, dafür wäre NFS, bzw. NFS4 vorgesehen.

    Du musst erstmals die Eigentums- und Gruppenrechte der Datei/Verzeichnisse kennen, die Du an einem Netzlaufwerk ändern/löschen willst.


    Servus !

    Meiner Meinung passt die im EEPROM geflashte Version mit der Kartenversion nicht zusammen, da das EEPROM Update aktiviert ist.


    Wenn ein Pi4 mit dem -- 2020-08-20-raspios-buster-armhf-full.img gestartet wurde, hat er dessen EEPROM Version übernommen. Wird derselbe Pi mit dem 2020-05-27-raspios-buster-armhf.img gestartet, versucht er ein EEPROM update in die Vergangenheit, was nicht funktioniert, weil es ja ein downgrade wäre.


    Ich würde das 2020-05-27-raspios-buster-armhf.img gegen ein 2020-08-20-raspios-buster-armhf.img austauschen, um beide Images auf denselben EEPROM Stand zu bringen, und dann (wenn beide Pis mit beiden Karten starten), das EEPROM Update deaktivieren.


    https://www.raspberrypi.org/do…are/raspberrypi/README.md

    --> SPI Boot EEPROM (Pi4)

    --> Boot Diagnostics Display (Pi4)

    --> Boot Modes

    samt deren weiteren Links, insbesondere https://www.raspberrypi.org/do…2711_bootloader_config.md


    Servus !

    Die Dateirechte an einem Netzlaufwerk werden durch die Freigabe am Server und durch die Optionen des Mountbefehles am Client bestimmt.


    Es würde die Hacker weltweit extrem freuen, wenn ein User mit der UID=0 (root) weltweit auf alle Netzlaufwerke schreibend/löschend Zugriff bekommt.


    Welche Schreibrechte Du benötigs, siehst Du mit < ls -al Pfad/zu/Dateiname >, oder im Grafik-Pcmanfm in der Listenansicht, wenn Du die Anzeigespalten für User/Group/Permission erweiterst.



    Servus !

    Das $ in #7 ist der Eigabeprompt von Linux und das Zeichen, dass Du sofort loslegen kannst.

    Du kannst auch über SSH auf den Pi zugreifen.


    Es ist aber unbedingt erforderlich, dass Du das Auslieferungspasswort sofort änderst.



    Servus !

    Solange dem Admin mit < tune2fs -l /dev/sdxy >, oder < dumpe2fs -h /dev/sdxy > noch der Superblock angezeigt wird, ist die Karte noch nicht so defekt, dass sie nicht mit Bordmitteln gerettet werden kann.


    Sonst gilt: Kein Backup, kein Mitleid.



    Servus !