Beiträge von Life_of_Pi

    Ich kenne mich gar nicht mit dem HFS Filesystem aus, da ich kein MAC OS Gerät und daher keine Verwendung dafür habe.

    Ich könnte mir aber denken, dass der Kernel einerseits HFS unterstützen muss,
    was meiner anscheinend nicht out of the box tut

    Code
    [root@retropie:~]
    # grep -c hfs /proc/filesystems 
    0

    andererseits muss man sicher noch User Space Tools fürs Hantieren mit HFS Devices nachinstallieren.
    Da scheint es was zu geben.

    Code
    [root@retropie:~]
    # apt-cache search hfsplus
    dmg2img - Tool for converting compress dmg files to hfsplus images
    hfsplus - Tools to access HFS+ formatted volumes
    libhfsp-dev - Library to access HFS+ formatted volumes
    libhfsp0 - Shared library to access HFS+ formatted volumes

    Wie gesagt, habe noch nie mit HFS zu tun gehabt.
    Mal sehen, ob das was bringt...

    Hm, kein mkfs.hfs+ o.ä.
    Da fehlt noch was.

    Das sieht doch schon mal vielversprechend aus.

    Aha, verstehe jetzt, was Dein Problem ist.

    Das klappte immerhin.

    Versuch doch einfach mal das HFS mit der Option force zu mounten.

    Aber wie gesagt, ist mit Vorsicht zu geniessen, da ich keinerlei Ahnung von HFS(+) o.ä. für mich exotische Filesysteme habe.

    Hallo Tell,

    Deine Beobachtung ist schon richtig;
    aber die Interpretation des Inhalts der Variablen ALARMZEIT_AUS als Oktalzahl durch die Shell scheint mir doch den doppelten square brackets des test statements geschuldet,
    welche durch einfache square brackets zu ersetzen, dreamshader und meigrafd bereits zu Beginn hingewiesen haben.

    Denn innerhalb doppelter square brackets wertet die Shell arithmetische Ausdrücke auch dahingehend aus,
    dass Zahlen mit führender 0 als Oktalzahlen interpretiert werden, während innerhalb einfacher square brackets anscheinend im Kontext des Ganzzahlvergleichsoperators -lt führende Nullen einfach gestrippt bzw. ignoriert werden.

    Somit war der empfohlene Übergang von doppelten zu einfachen square brackets schon die naheliegendste Lösung des Problems.

    Der Test funktioniert allerdings auch mit doppelten square brackets, wenn man die Shell die Variableninhalte lexikographisch (entsprechend der durch die Umgebung vorherrschenden Lokalisierung) sortieren lässt.
    Das scheint zu funktionieren, weil die < und > Vergleichsoperatoren einen String Kontext statt eines Integer Kontext wie bei -gt und -lt vorgeben.

    z.B.

    Code
    if  [[ $timeNow > $ALARMZEIT_EIN && $timeNow < $ALARMZEIT_AUS ]]; then

    Die single square bracket Variante des Test ist dem aber eindeutig vorzuziehen.

    Zitat


    timeNow=0019
    x=$((timeNow+1))
    bash: 0019: Der Wert ist zu groß für die aktuelle Basis. (Fehlerverursachendes Zeichen ist \"0019\").

    $((...)) bildet ebenfalls arithmetischen Kontext für das, was in den doppelten parens steht.
    Deshalb werden auch hier offenbar führende Nullen als Oktalzahlkennzeichner interpretiert.


    Und jetzt soll mir bitte einer einen Link geben, wo das Verhalten von
    [ und [[ genau definiert ist.

    Ich lerne ja gerne was dazu :D

    man bash

    Wenn man die Variablen, mit denen man Shell Arithmetik betreiben will, explizit deklariert,
    wirft die Shell bereits einen Fehler bei deren Zuweisung und nicht er bei deren Referenzierung.

    Code
    $ declare -i n=018
    bash: declare: 018: value too great for base (error token is "018")

    Man kann aber, um sicherzugehen, die Basis vorgeben.

    Code
    $ (declare -i n=10#017;echo $((++n)))
    18



    Wenn man die Variablen, mit denen man Shell Arithmetik betreiben will, explizit deklariert,
    wirft die Shell bereits einen Fehler bei deren Zuweisung und nicht erst bei deren Referenzierung.

    Code
    $ declare -i n=018
    bash: declare: 018: value too great for base (error token is "018")

    Man kann aber, um sicherzugehen, die Basis vorgeben.

    Code
    $ (declare -i n=10#017;echo $((++n)))
    18



    deliberately left blank owe to inadvertent double post

    @mods: könnt Ihr bitte meinen letzten redundanten Beitrag entfernen.
    Da ist mir anscheinend beim Posten etwas durcheinander geraten.

    Wenn Du der Einzige bist, der den Webserver administriert,
    dann ist das Setzen von etwas anderem als AllowOverride None unsinnig.
    Sowas benötigt man nur, wenn man (z.B. anderen Admins ohne volle Webserverkontrolle auf dem System) dynamisch das Einstreuen von Direktiven via .htaccess Dateien ermöglich will
    (z.B. in einer Web Hoster Umgebung).
    Im Gegenteil gehen andere AllowOverrides zulasten der Performance,
    insbesondere, wenn sie vom DocumentRoot ausgehend in sämtliche Subdirs vererbt werden,
    weil der Webserver jedesmal checken muss, ob eine .htaccess Datei für einen Leaf Node vorhanden ist
    und falls ja, die Direktiven darin auswerten muss.

    Sämtliche Overrides kannst Du als alleiniger Admin des Webservers in dessen httpd.conf selbst im jeweiligen Kontext vornehmen und, da Du ja root bist,
    nach jeder Config Änderung selbst den Webserver über ein SIGUSR1 (i.e. Graceful Restart) an die PID von dessen Parent Proc/Thread davon in Kenntnis setzen.


    Zitat von &quot;Apache Performance Tuning&quot;



    Zitat von &quot;Apache Core Features&quot;




    AuthUserFile /.htpasswd

    Das erscheint mir unsinnig.

    Der Wert zur AuthUser Direktive muss einen String mit dem (am besten absoluten) Pfad zu einem Password File auf Deinem System enthalten,
    in dem die Password Hashes der zu diesem Realm zutrittsberechtigten User gespeichert werden.

    So ein Password File legt man üblicherweise als root mit dem Hilfskommando htpasswd an und verwaltet das damit.
    (wenn man crypt() kennt und einen Editor bedienen kann, geht das natürlich auch ohne dieses Tool zu Fuß)
    Erst wenn es sehr viele User werden, bietet es sich aus Performance-Gründen an, stattdessen ein DBM oder anderes DB Backend zu verwenden.

    Achtung, die Passwörter werden quasi im Klartext (d.h. base64 encoded, wenn AuthType Basic gewählt wurde) zwischen Web Clients (Browsern) und dem Webserver ausgetauscht.
    Deshalb sollte man solchen Realm-Zugang zusätzlich über eine SSL/TLS Verschlüsselung (also https) absichern.


    Ganze Atomkraftwerke laufen so :)

    Bitte zerstöre nicht meinen naiven Glauben an das Verantwortungsbewusstsein der Betreiber dieser Anlagen,
    und lass sie dort bitte kein Windows OS zur Steuerung ihrer Anlagen betreiben,
    sondern irgend ein eigens dafür entwickeltes oder gepatchtes Custom OS.

    Dass ein abgeschottetes Intranet kein Garant gegen Angriffe ist und schon mit einem präparierten
    und z.B. auf dem Mitarbeiterparkplatz "weggeworfenen" USB Stick überwunden werden kann,
    hat ja Stuxnet erschreckend gezeigt.

    Fasse die einzelnen Schritte zu einem Shell Script zusammen.
    Das ist der übliche erste Schritt zur Automatisierung und nebenbei auch gleich zu einer gewissen Dokumentierung (die einzelnen Befehle hat man das nächste Mal oft wieder vergessen).

    Wenn alles in 1-3 Zeilen passt, kann man dafür auch ein Shell Alias oder eine Shell Function definieren
    und diese Definition in z.B. seine $HOME/.bashrc packen (wenn Bash die eigene Login Shell ist).

    Wenn es aufwendiger wird, entweder mehr als etwa 50-100 Codezeilen oder sehr viele Schleifeniterationen,
    in deren Bodies viele oder CPU-zeitfressende externe Aufrufe erfolgen,
    sollte man darüber nachdenken, das in einer dynamischen Skriptsprache zu schreiben (z.B. Python, Perl, Ruby),
    dabei aber nach Möglichkeit "in dieser Sprache bleiben", also [i]system(), subprocess(), pipe()[i] u.ä. externe Aufrufe vermeiden.

    Wenn das immer noch zu inperformant ist (was aber auch sehr am Coding liegen kann),
    dann auf eine Compiler-Sprache (z.B. C) zurückgreifen.

    Vielen Dank denen, die mir geantwortet haben.

    Ich verstehe Eure Vorbehalte. Für einen engagierten HW-Schaltungsbastler ist das Zubehör in den Bundles sicherlich nicht ausreichend,
    und wenn man sowieso genau weiss, welches Projekt man mit dem RPi in Angriff nehmen will,
    dann ist es zweifellos sinnvoller, sich genau die Komponenten zu besorgen, die man dafür benötigt.

    Bei mir liegt der Fall etwas anders, weil ich ausser sehr rudimentären Elektronik-Grundkenntnissen,
    die ich mir vor fast 30 Jahren mal im Rahmen meiner Elektromechaniker-Lehre angeeignet habe,
    zunächst nicht viel Wissen und Ausstattung habe, auf denen ich aufbauen könnte.
    Allerdings könnte ich mir, im Gegensatz zu damals, inzwischen leichter tiefergehende Kenntnisse, auch unter Nutzung "anspruchsvoller" Fachliteratur, aneignen,
    weil mir jetzt die mathematischen Modelle und Methoden vertrauter sind,
    die ich zwar aus der technischen Mechanik und Strömungslehre hervorkramen würde,
    die aber von den Gleichungen und Prinzipien mir analog übertragbar zu sein scheinen, nur dass die Formelzeichen andere physikalische Grössen beschreiben.

    Dennoch fehlt mir natürlich die Elektronik- und schaltungstechnische Praxis,
    nicht nur, was das Handling mit dem Soldering Iron etc angeht.

    Abgesehen davon, muss ich mir zunächst darüber klar werden,
    was für ein Projekt ich überhaupt mit dem RPi umsetzen möchte und wozu ich in der Lage wäre.
    Mich würde z.B. sehr die Kombination RPi und Arduino reizen und am liebsten irgendwas in Richtung Modellbau.
    Mal sehen...


    Ob es auch direkt vom PC nach /var/www/ geht, weiss ich nicht, da ich das noch nie gemacht habe.

    Sofern der sshd in seiner sshd_config PermitRootLogin yes gesetzt hat,
    bzw. dieser Eintrag auskommentiert ist oder gar nicht vorkommt (root logins sind per default erlaubt),
    dann kann man dass gleich "an root" kopieren.
    z.B.

    Code
    me@myhost:~>$  scp somefile root@pihost:/var/www/html

    Ich würde auch stets scp oder ssh Befehle zum Übertragen verwenden.
    sftp ist m.E. der SSH nur aufgesetzt worden, um FTP Klientel zufriedenzustellen.

    Man könnte auch ein Sshfs via Fuse mounten.

    Hallo Panic0815,

    wenn Du den GUI Desktop nicht willst, brauchst Du nur als root einfach in den Runlevel 3 zu wechseln.
    Das ist bei Linux Systemen, die noch nach dem SysV init Konzept booten
    (alle Distros mit systemd tun das nicht mehr bzw. "emulieren" nur noch runlevel)
    ein Multi-User mit voller Netzwerkunterstützung, aber ohne X und GUI
    und üblicherweise der Runlevel, in dem Server betrieben werden (wo man meist erst gar kein X drauf installiert)

    Code
    # init 3


    oder

    Code
    # telinit 3


    versetzen Dein System in diesen GUI-losen Runlevel 3.

    Mit

    Code
    # who -r
             run-level 3  2014-04-07 21:39                   last=S


    kannst Du abfragen, in welchem Runlevel sich das System befindet und welches der zuletzt davor benutzte Runlevel war,
    von dem es in den aktuellen gewechselt ist.

    Wenn Du Dein System dauerhaft gleich in den Runlevel 3 booten möchtest,
    dann musst Du die Datei /etc/inittab als root editieren und den Default Runlevel darin eintragen,
    in etwa so wie hier

    Code
    # grep initdefault /etc/inittab 
    #   0 - halt (Do NOT set initdefault to this)
    #   6 - reboot (Do NOT set initdefault to this)
    id:3:initdefault:


    Beachte auch die sinnvollen Kommentare.

    (edit: sorry, mir ging beim copy and paste die wichtigste Zeile, die nicht auskommentierte, verloren)

    Hallo RPi-Gemeinde,

    ich möchte mir gern einen zweiten RPi zulegen und bin bei amazon auf dieses Bundle [Anzeige] gestossen.
    Ein ähnliches Bundle gibt es auch bei reichelt.

    An dem amazon Bundle gefällt mir allerdings besser, dass es auch ein Breadboard und etwas Kabelage dazu enthält.
    Da ich bisher kein Elektronikbastler bin, fehlt mir natürlich auch selbst so elementares Zubehör.
    Andererseits gibt's aber auch preiswert erscheinende Starter Kits wie dieses [Anzeige],
    das sogar, neben den obligatorischen Widerständen und LEDs, ein Mini Servo enthält.

    Was mich etwas verwirrt und weshalb ich Euch frage, sind die sehr durchwachsenen Kundenrezensionen zum amazon Ultimate Bundle,
    die von "totaler Mist", was alle Komponenten ausser dem RPi PCB selbst betrifft,
    bis zu euphorischen Lobpreisungen zu einem "Superpreis" reichen.

    Sicher, bei 66 € kann man eigentlich nicht so viel falsch machen,
    wenn denn der enthaltene RPi funktioniert und es sich tatsächlich um ein Revision 2 Model B handelt
    und einem nicht ein Model A untergejubelt wird,
    wie das bei einem anderen Reichelt Bundle der Fall zu sein scheint.


    und da muss ich noch dicke Dokus lesen, bis ich das mit Timestamp & Co umsetzen kann.

    Hallo RasPi-Azubi,

    da ich selbst auch kein SQL Hacker bin, hätte ich das mit dem MySQL timestamp auch nicht auf Anhieb gewusst,
    wäre aber vermutlich auch irgendwann darauf gestossen.

    Prinzipiell ist meigrafd nur zuzustimmen, und man sollte so eine Datenstruktur verwenden, die das RDBMS dafür vorgesehen hat und intern selbst verwendet.

    Ich glaube ich wäre als aller erstes auf die Unix Epoch Seconds als abzuspeichernde Timestamps verfallen,
    so wie sie z.B. die das date Kommando oder die time() Implementierungen diverser Sprachen einem ausgeben.

    Da braucht man sich am wenigsten Gedanken über irgendwelche Formate zu machen,
    da die jeweils benötigte Formatierung und ggf. TZ Konvertierung erst nach dem SQL Fetch ausserhalb der DB vorgenommen wird.

    Code
    $ date;date +%s;perl -le 'print time';python -c 'import time;print time.time()'
    Mon May 26 01:26:13 CEST 2014
    1401060373
    1401060373
    1401060373.7


    mein forgehen, ich habe startx ausgeführt und unter LXTerminal mit sudo ./launch...py
    zum laufen gebracht,

    Ich vermute mal, dass der Grund dafür, dass DISPLAY ungesetzt ist, genau darin liegt, dass das Skript via sudo gestartet wird.

    (Meine Güte, jetzt habe ich tatsächlich einen Satz fabriziert, in dem dreimal die Konjunktion dass vorkommt:X)

    Das Standardverhalten bei sudoers Regeln, bei denen das nicht explizit davon abweichend vorgegeben wurde, ist nämlich,
    dass die Umgebung des auszuführenden sudo Kommandos bis auf ganz wenige Umgebungsvariablen eingestampft wird
    (was meist im Sinne einer höheren Systemsicherheit ist);
    oder, um aus man sudoers zu zitieren

    Da es oben heisst, The DISPLAY, PATH and TERM variables remain unchanged,
    wäre eine Möglichkeit, dass Du Deinem sudo Kommando die Option für ein login shell behaviour,
    also "-i" mitgibst.

    Da man das aber auch nicht immer unbedingt will
    (schliesslich werden dann die .bash_profile sowie die .bashrc im HOME des users, unter dem das sudo Kommando ausgeführt wird - also meist die von root - gesourced),
    sehe ich die sauberere Lösung darin, in Deiner sudoers Datei in den Defaults Deines Users, der das sudo Kommando mit anderen (meist höheren) Rechten ausführt,
    die Umgebungsvariable DISPLAY in die env_keep Liste aufzunehmen.

    Dazu editierst Du die sudoers, indem Du in eine root Shell wechselst und dort das Kommando visudo eingibst.
    Das setzt ein Lock auf diese sensible sudoers Datei und lädt sie in den Editor,
    der auf Unix Systemen meist der vi ist.

    Ich weiss, dass mancher mit dem vi auf Kriegsfuss steht, und üblicherweise kann man durch Setzen der Umgebungsvariablen EDITOR bzw. VISUAL dafür sorgen,
    dass ein Editor seiner Wahl aufgerufen wird.
    Weil sudo aber so ein sicherheitskritisches Kommando ist, ist gemeinerweise nicht selten der vi während des Builds auch des Hilfskommandos visudo
    als Standardeditor fest einkompiliert worden.
    Deshalb kann es sein, dass visudo die Umgebungsvariablen EDITOR bzw. VISUAL schlicht ignoriert.
    Am besten einfach ausprobieren, also z.B.

    Code
    # EDITOR=nano visudo


    aufrufen. Evtl. klappt es auch mit einem anderen Editor.
    Ansonsten wäre jetzt erstmal ein Zehn-Minuten-Kurztutorial zum vi angesagt.

    Wenn die sudoers (in welchem Editor auch immer) geladen ist,
    such Zeilen, die mit Defaults beginnen, wovon es meist mehrere gibt.
    Evtl. existiert ja bereits eine Defaults Zeile für den User, der Dein sudo Kommando absetzen können soll.
    Ich nehme mal an, dass dieser User pi sei.
    Für den könntest Du z.B. folgende Defaults Zeile in die sudoers schreiben bzw. eine bereits vorhandene entsprechend ergänzen:

    Code
    Defaults:pi  env_keep+="DISPLAY"

    Wenn man nun aus dem Editor mit Abspeichern der Änderungen des Buffers aussteigt
    (im vi wäre das die Tastenfolge, Esc :wq<enter>)
    nimmt visudoer zuvor einen Syntaxcheck der sudoers vor, was sehr praktisch ist.
    Sollte irgendeine Editierung der sudoers Syntax zuwiderlaufen, weist visudo unter Angabe der Zeile darauf hin,
    wo es ein Problem vermutet und fragt, what now?.
    Wenn man hier nochmal ein e eingibt und mit <enter> bestätigt,
    springt der Editorprompt in die strittige Zeile und man hat Gelegenheit die Syntax zu korrigieren.

    Zum Schluss kann man mit z.B.

    Code
    # sudo -lU pi|grep env_keep.*DISPLAY


    gucken, ob dem User seine DISPLAY Variable für seine sudo Kommandos erhalten bleibt.

    Anschliessend (hoffe ich) sollte das sudo Kommando zumindest nicht mehr mit einem,
    unset DISPLAY error abbrechen.

    Hallo something001,

    auf Linux Systemen wird das Passwort als crypt Hash im zweiten Feld der /etc/shadow gespeichert.

    Ich habe root auf meinem System mal eben zu Demonstrationszwecken ein leicht knackbares Wörterbuch-Wort gegeben.
    Der Hash selbst ist nicht knackbar, da er nur in einer Einwegfunktion generiert werden kann.
    Aber man kann genauso vorgehen, wie es auch das entsprechende PAM Modul beim Login bzw. Password Cracker Programme machen,
    die Wörterbuchlisten und Listen mit gängigen Kombinationen sowie Leetspeak-Ersetzungen u.ä. abarbeiten
    und auf diese Weise schwache Passwörter (wie meins) herausfinden.
    Dabei werden diese Passwortkombinationen mit derselben crypt Einwegfunktionen nacheinander verschlüsselt und deren Hash Strings solange mit dem Eintrag in der shadow verglichen,
    bis ein Match der Strings vorliegt.

    Weil die shadow Datei nur für root lesbar sein darf, erfordert das Auslesen root Rechte.

    Hier nun der Demo Hash des Passworts meines root account:

    Code
    [root@dellinsp:~]
    # awk -F: '$1=="root"{print$2}' /etc/shadow
    $6$Edl1gHxqyY/Pvven$BhQoPVdt7ZrYS4neTqes9MBE/LDTgJCXjWU.H/Oo8q.8GkG6ZPrF.OGAgYv2J.sYrBZlsb6VpGA4Ql.UtAb5j.

    An der Zahl zwischen dem ersten Dollarzeichenpaar erkennt man, mit welchem Cipher der Hash generiert wurde.
    In meinem Fall steht die 6 für SHA512.

    Da ich ja mein eben vergebenes root Passwort kenne, brauche ich natürlich keine Wörterbuchliste abarbeiten zu lassen,
    sondern komme mit einem einzigen Aufruf des crypt syscall aus.

    Man könnte jetzt zwar ein kleines C Programm dafür schreiben,
    noch bequemer geht es aber mit einer der dynamischen Skriptsprachen wie Perl, Python, Ruby etc.,
    die alle die libc syscalls auch implementiert haben.

    Die crypt Funktion erwartet als erstes Argument das Passwort im Klartext und als zweites den sog. salt,
    der eine bis zu 16 Zeichen lange Zufallszahlenfolge ist, die Wörterbuchangriffe ein wenig "versalzen" soll.
    Da wir als root aber den salt auslesen können, der die Zeichenfolge umfasst, die zwischen dem nächsten Paar von Dollarzeichen steht,
    macht das für uns keinen Unterschied.
    Die übrigen Zeichen bilden dann den Hash, den wir vergleichen müssen.

    In Perl geht das z.B. mit so einem Einzeiler:

    Code
    [root@dellinsp:~]
    # perl -le 'print crypt("bugger",q{$6$}."Edl1gHxqyY/Pvven")'
    $6$Edl1gHxqyY/Pvven$BhQoPVdt7ZrYS4neTqes9MBE/LDTgJCXjWU.H/Oo8q.8GkG6ZPrF.OGAgYv2J.sYrBZlsb6VpGA4Ql.UtAb5j.

    und in Python könnte das so aussehen:

    Code
    [root@dellinsp:~]
    # python -c 'import crypt;print crypt.crypt("bugger","$6$"+"Edl1gHxqyY/Pvven")'
    $6$Edl1gHxqyY/Pvven$BhQoPVdt7ZrYS4neTqes9MBE/LDTgJCXjWU.H/Oo8q.8GkG6ZPrF.OGAgYv2J.sYrBZlsb6VpGA4Ql.UtAb5j.

    Wenn die Hashes Zeichen für Zeichen übereinstimmen, ist Dein Passwort korrekt.

    Du kannst also natürlich auch als root das zweite Feld der shadow editieren und den Hash dort reinkopieren,
    obwohl man sowas nur im Notfall machen sollte (z.B. nach Booten in den Single User Mode bzw. in eine rescue Shell),
    wenn man ausgesperrt bleibt, weil man das alte root Password vergessen hat.

    Ach ja, Du kannst die Konsistenz Deiner /etc/passwd und /etc/shadow mit dem pwck Kommando auf den meisten Linux Systemen checken.
    z.B.

    Code
    [root@dellinsp:~]
    # pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'gopher': directory '/var/gopher' does not exist
    user 'ftp': directory '/var/ftp' does not exist
    user 'saslauth': directory '/var/empty/saslauth' does not exist
    user 'pulse': directory '/var/run/pulse' does not exist
    pwck: no changes

    Eine "beliebte" Inkonsistenz der /etc/passwd, die zum vorübergehenden Verlust der Einlogbarkeit auf Unix Systemen führen kann
    und so irretierende Meldungen am Login wie,
    "You do not exist. Go away" zeitigen kann,
    liegt auch vor, wenn nicht jeder Eintrag in der passwd aus sieben Feldern besteht.
    Sowas ist mir mal bei einer Wartung auf einem HP-UX System passiert,
    wo ich mich nicht als root anmelden konnte, weil ein Kollege durch einen Bug in seinem Skript
    beim Synchronisieren der passwd Dateien zwischen Cluster Nodes irgendwelche Felder unterschlagen hatte.
    Betroffene Accounts kann man aber z.B. mit so einem Befehl schnell ausfindig machen:

    Code
    # awk -F: 'NF!=7' /etc/passwd

    Ich finde es auch nicht empfehlenswert, jemandem, der das Rechtesystem des Multi-User OS Linux noch nicht, wenigstens in den Grundzügen, verstanden hat,
    bzw. sich als nicht nur Gelegenheitsanwender damit auseinanderzusetzen weigert,
    ernsthaft zu vermitteln, dass der permanente Gebrauch des root account durchaus praktikabel sei.
    Vor allem, wenn der Adressat dieses "Ratschlags" vorhat, einen nicht nur "nicht-gehärteten",
    sondern womöglich vollkommen offenen und elementarer Unix-Schutzmechanismen beraubten Webserver ins Internet zu stellen.
    Ich rede hier nicht mal von z.B. SELinux Policies, die durchaus kompliziert zu erstellen sein können.

    Bei solcher Aversion dazuzulernen würde ich eher dazu raten, ein anderes OS zu wählen.

    Natürlich kann man völlig zu Recht auf dem Standpunkt stehen,
    dass auf seinem eigenen Rechner niemand einem vorschreiben kann, unter welcher Kennung und mit welchen Privilegien er sich darauf bewegt,
    und wenn derjenige sich dabei in den Fuss schiesst, dann ist das ganz allein sein Vergnügen.
    Etwas anders sieht die Sache jedoch aus, wenn man so ein offenes System im Internet betreibt
    und dadurch in Kauf nimmt, andere Teilnehmer zu schädigen, indem der eigene Server z.B. zum Host für Spam, CSRF, DoS und für ähnlichen Missbrauch durch Kriminelle mutiert.

    Klar, wenn man systemadministrierend zugange ist und in der Regel weiss, was man tut,
    ist es üblich, dass man in eine root shell wechselt statt des dauernden sudo.
    Aber schon das Entwickeln, wenn es nicht gerade Code-Teile betrifft, die root-Privilegien benötigen,
    sollte auf jeden Fall unter einem in seinem (unbeabsichtigten) Zerstörungspotential eingeschränkten Account stattfinden.
    Nicht umsonst findet man in jeder Anleitung zum SW-Paketbau den eindringlichen Hinweis,
    das auf gar keinen Fall als root zu machen
    (falls das bei deb Paketen anders sein sollte, ich kenne nur die rpm Konventionen, da die von mir verwendeten Distros rpm-basiert sind).

    Bevor sich jetzt evtl. ein Embedded Systems Entwickler widersprechend zu Wort meldet,
    meine Ansichten und Erfahrungen basieren ausschliesslich auf Multi-User-Systemen.


    Neue Erkenntnisse:

    mount -a sagt jetzt: [mntent]: line 6 in /etc/fstab is bad

    Hier der Eintrag in /etc/fstab:
    192.168.178.36:/volume1/Recordings/TV-Aufnahmen /root/myQNAP/TV-Aufnahmen nfs atime,auto,rw,dev,exec,suid user=xxx,password=xxx

    Ich gehe mal davon aus, dass das die strittige Zeile 6 ist.

    Die Mount Optionen stimmen nicht.
    Sämtliche Optionen müssen durch Kommata voneinander getrennt sein und dürfen keinen whitespace enthalten.
    Zwischen suid und user= taucht ein Leerzeichen auf.
    Abgesehen davon sind user= und password= bestimmt keine für den FS Typ NFS validen Mountoptionen, sondern solche für CIFS bzw smb Mounts.
    Auch bei Deinen übrigen Optionen glaube ich nicht, dass die für NFS Mounts gültig sind.
    Wenn Du mal man 5 nfs in der Shell aufrufst, bekommst Du eine Liste mit Erklrärungen zu den gültigen NFS Mount Optionen angezeigt.

    Es ist nicht ganz einfach aus der Ferne, Empfehlungen für NFS Mountoptionen zu geben, die hier einen vernünftigen Kompromiss bilden,
    weil das sehr von den Gegebenheiten in Deinem LAN abhängt.

    Du könntest es aber zunächst mal mit diesen versuchen:

    Code
    192.168.178.36:/volume1/Recordings/TV-Aufnahmen /root/myQNAP/TV-Aufnahmen nfs _netdev,rw,bg,hard,intr,timeo=60,retry=5 0 0


    Ich habe ausserdem noch die letzten beiden fstab Felder für Dump und fsck Sequence der Vollständigkeit halber angegeben, die für NFS Mounts beide 0 sein sollten,
    auch wenn sie laut fstab Manpage weggelassen werden können und dann automatisch zu 0 angenommen werden.
    Ich finde es nur persönlich blöd, wenn nicht jeder FS Eintrag dieselbe Anzahl von Feldern in der fstab aufweist.
    Der mount Befehl andere Unices als Linux würden z.B. meckern, wenn nicht alle fstab Felder besetzt sind.

    Mounten solltest Du das mit

    Code
    $ sudo mount /root/myQNAP/TV-Aufnahmen


    können,
    sobald der Eintrag in der fstab korrekt, das NFS Share vom NFS Server an Die IP Deines RasPi exportiert ist und der eingetragene Mountpoint existiert.

    Ich kann mich auch nur der Signatur von Lunepi anschliessen.
    Lest einfach die Manpages; in dem Fall die von sftp-server.

    Über die Option "-f" eine noch nicht benutzte syslog facility wählen und über "-l" den gewünschten Loglevel einstellen.
    Einfach mal mit verschiedenen Logleveln solange probieren, bis das passende Maß gefunden ist.

    Diese beiden Optionen müssen in der /etc/ssh/sshd_config eingetragen werden.

    Anschliessend in die /etc/syslog.conf einen Eintrag für das gewählte log facility mit Verweis auf die Datei, in die geloggt werden soll, eintragen.

    Ein Beispiel findet man hier.

    Zum Schluss müssen beide daemons (sshd und syslogd) noch dazu gebracht werden, sich neu zu initalisieren,
    was man bei Unix Daemons üblicherweise über ein SIGHUP deren PIDs signalisiert.

    Code
    $ sudo pkill -1 -P1 -u0 sshd
    $ sudo pkill -1 -P1 -u0 syslogd

    Alles - das Editieren der Dateien und das Senden von Signalen an die daemons - erfordert natürlich root Rechte (deshalb oben sudo).

    Man kann die daemons natürlich auch über die jeweilige init Methode zum Reinitialisieren veranlassen.
    z.B.

    Code
    $ sudo /sbin/service sshd reload


    oder alternativ

    Code
    $ sudo /etc/init.d/syslog reload


    Aber das ist von System zu System verschieden
    (was Debian benutzt weiss ich nicht, systemd Distros wiederum sehen systemctl Kommandos dafür vor)

    Hallo Kostfastnix,

    ich denke auch, dass FFmpeg als eierlegende Wollmilchsau für Konvertierungen von Audio und Video Streams das auf jeden Fall beherrschen sollte.

    Leider sind Audio/Video und die ganzen Codecs nicht gerade mein Beritt, weswegen ich selbst wenig Hilfe dazu geben kann.

    Weil ich so perplex über die Ausgabe

    Zitat von &quot;excerpt from posted ffmpeg output&quot;


    *** THIS PROGRAM IS DEPRECATED ***
    This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

    in Deinem Beitrag war und diese Unverfrorenheit zunächst nicht glauben wollte
    (nämlich, die Bahauptung, dass FFmpeg tot sei, nachdem ich Leute des Projekts erst vor einer Woche an deren Stand auf dem Berliner LinuxTag gesehen und kurz gesprochen habe),
    musste ich mich erstmal selbst schlau machen, was dahinter steckt und habe eine Antwort darauf in diesem Post auf stackoverflow gelesen.

    Anscheinend hast Du so eine, nicht ganz taufrische, Übergangsversion von ffmpeg eines Builds aus der Zeit des oben beschriebenen Fork War.

    Vermutlich klappt das nur mit dieser ffmpeg Version nicht.
    Hier in diesem Blog wird so etwas auch angedeutet:

    Zitat von &quot;How to stream a webcam from the RPi&quot;


    The version that comes with the current version of Raspbian and Debian have issues streaming.

    Vielleicht baust Du Dir zuerst ein funktionieredes ffmpeg, wie in dem Blog beschrieben?

    Habe es selber noch nicht ausprobiert,
    wäre aber daran interessiert, Deine Erfahrungen damit zu lesen.

    Hallo Knuckel,

    zum Editieren Deiner langen Schlüssel kannst Du das Hilfskommando wpa_passphrase verwenden,
    dem Du lediglich die SSID Deines Access Points sowie die Zeichenkette Deines Schlüssels mitgeben musst.
    Es schreibt dann einen network Hash bzw. Dictionary nach stdout.

    Code
    $ wpa_passphrase MySSID $(tr -dc 'A-Za-z0-9+/' < /dev/urandom |head -c 63)
    network={
    	ssid="MySSID"
    	#psk="43xnTr3sTJjmY/POwWFylDYEW/VvJzuWIHyR0TbiqLnpfVzyMhi08HNq7U5Nt4f"
    	psk=a3f0d8f202b2b440ec4e54ef18e6814754a8662c5caaa638f1678c6b85fa67d8
    }

    Du brauchst diese Ausgabe lediglich als root an Deine wpa_supplicant.conf anzuhängen.

    Z.B. so

    Code
    $ sudo wpa_passphrase "MySSID" "meineSehrGeheimeUndSehrLangePassphrase" >> /etc/wpa_supplicant/wpa_supplicant.conf