Posts by ThomasL

    lutz


    Ich habe den erwähnten Teil Deines Vorschlags nun übernommen... und es läuft:

    Was passiert da?


    - VirtUser übernimmt die Umgebungsvariable $USER... mit einem alltrim()

    - Dann wird in der alias_maps gesucht, ob es für den virtuellen einen Linux-User gibt

    - alias_maps enthält z.B. die beiden (Stresstest-)-Einträge:

    toml thomas

    tom thoma (=provozierte Fehlersituation)


    oder umgekehrt

    tom thoma

    toml thomas


    Als letztes wird geprüft, ob der in der alias_maps eingetragene Linuxuser auch wirklich eine UID hat.... also das er wirklich existiert.


    provozierte Fehlersituation = tom und toml sind virtuelle User, 'thomas' ist ein vorhandener Linuxuser, 'thoma' hingegen nicht, den gibts nicht in passwd.


    Mit dem Script oben passieren jetzt nicht diese erwarteten grep-Fehler, auch aus der Reihenfolge der virtuellen User in alias_maps resultiert kein Fehler, sondern nur die korrekte Fehlerbehandlung... also alles so wie es sein soll. Fällt Dir (oder gerne auch jedem anderen 'Prüfer') noch was auf, oder eine Idee, wie ich das Script noch mal "stressen" kann...?... oder ist das so ok? Ich denke, solche Namens-Werke/Kombinationen sind ja typische Fehlerquellen....

    Hi Lutz


    Ich freue mich ehrlich über jeden Tipp, der das Projekt besser macht... insofern ein aufrichtiges Danke für diese Überlegung... nur basiert dieser Update-Vorschlag leider auf der Vor-Weihnachtsversion, die bei Rudi zum Fehler geführt hat. Der Ablauf ist jetzt im Script ein anderer.... ich glaube, dass sowohl Abfragen als auch die Plausibilitätsprüfungen stabiler sind als zuvor.... und anscheinend war das bei Rudi jetzt auch erfolgreich.


    Unter anderen war diese Zeile fehlerhaft,

    LinuxUser_UID=$(grep $LinuxUser /etc/passwd | awk -F':' '{ printf "%6s", $3}')


    die nun durch diese ersetzt wurde:

    LinuxUser_UID=$(grep "$LinuxUser:" /etc/passwd | awk -F':' '{ printf "%s", $3}')


    Darüber hinaus -so denke ich- ist die Fehlerbehandlung jetzt besser.


    Wobei mir die letzte Änderung richtig gut gefällt... ich hatte auch schon dran gedacht, mir dann aber überlegt, dem geschenkten Gaul (die schon vorhandene Lösung ) nichts in Maul zu schauen... *fg* ... soll heissen, ich war einfach zu faul mich mit 'id' zu befassen... aber jetzt, wo's da so fertig steht... da sach ich ma danke... *fg*

    Ein Hinweis noch, statt apt install getmail habe ich apt install getmail14 installiert ("getmail" wurde nicht gefunden)

    Das war eine Falle, in die ich dieser Tage getappt bin.... richtig ist "getmail", nicht "getmail4". In einer früheren Version hatte ich damals "getmail4" eingetragen, das ist aber bei Debian heute nur noch ein Übergangspaket, das richtige Paket ist "getmail". Das bedeutet, die Zurücknahme der Änderung auf getmail wieder auf getmail4 war ein Fehler, den ich jetzt wieder geradegerückt habe. Ich konnte mich daran erinnern, dass ich da schon mal was gemacht habe, hatte das aber im Dezember durcheinander gebracht. Wenn die von Dir verwendete Distribution nur das Übergangspaket "getmail4" anbietet, so ist das eine Entscheidung dieser Distri.... das ist aber nicht weiter tragisch... letztlich ist es die gleiche Version... aber korrekt ist "getmail".

    Wenn ich dein Script manuel durchgehe, funktioniert der Grep-Befehl problemlos:

    Ja, das habe ich mir schon gedacht. Aber egal, ich habe die User-Erkennung im Script trotzdem noch mal überarbeitet ...notwendigerweise... denn mit mehr Sorgfalt und kritischerer Betrachtung bei der Prüfung sind mir da jetzt Dinge aufgefallen, die man besser machen kann. Lade Dir die aktuelle Version noch mal mit dem Tarfile runter. Aber daran denken, vorher die alte sichern und die neue mit den korrekten Rechten versehen:

    mv /usr/local/bin/getmail_eventhandler /usr/local/bin/getmail_eventhandler.sik


    Starte dann mal 2 Terminalfenster mit einer horizontalen Trennung, jeweils über die ganze Breite. Im unteren Terminal startest Du zuerst

    journalctl -f | grep eventhandler


    ... und anschließend im oberen Terminal (der User "rudi" ist ja sowohl virtueller Dovecot-User als auch Linux-User, sollte also klappen) die beiden Varianten:

    export USER='ruuuhdi';/usr/local/bin/getmail_eventhandler

    export USER='rudi';/usr/local/bin/getmail_eventhandler


    Der erste Befehl sollte eine passende Fehlermeldung im unten laufenden Journal anzeigen, ohne das das Script darüber ins stolpern gerät. Der zweite Befehl müsste die Postfächer korrekt abarbeiten. Wenn der genannte Fehler (und auch keine anderen) nicht auftritt, ist also das Script ok.

    findest du in deiner mail.err keine entsprechende Fehlermeldung?

    Damit weiß ich jetzt gar nicht, welches Log das ist. Wo steht diese Meldung, in welchem Logfile, in welchem Verzeichnis?


    Bitte berichte mal, wie sich das jetzt mit der Fehlernachricht entwickelt. Ich halte nämlich immer noch für möglich, dass das ein Socket-Problem ist.... ich warte aber erst auf Deine Meldung.

    grep rudi /etc/passwd

    rudi:x:1002:1002:Rudi Rodolfsen,,,:/home/rudi:/bin/bash

    Kannst Du mir kurz erklären, wie Du das geschafft hast, einen solchen Usernamen anzulegen?

    Code
    # adduser "donald duck"
    adduser: Um Probleme zu vermeiden, sollte der Benutzername nur aus Buchstaben,
    Ziffern, Unterstrichen, Punkten, Klammeraffen (@) und Bindestrichen bestehen
    und nicht mit einem Bindestrich anfangen (wie durch IEEE Std 1003.1-2001
    festgelegt). Zur Kompatibilität mit Konten auf Samba-Rechnern wird
    außerdem $ am Ende des Benutzernamens unterstützt

    Ganz offensichtlich verstoßen solche Namen gegen gewisse Regeln hinsichtlich Namenskonventionen. Ich habe das jetzt bei mir in einer Testversion korrigiert, nur scheitert das jetzt an anderer Stelle (s.o.).... und nun stell ich mir die Frage, ob die Korrektur nicht selber ein Fehler ist..... :conf:... oder sehen andere Distributionen das nicht so eng und ignorieren gewisse Regeln?


    Hat da vielleicht noch jemand anderes eine Meinung zu solchen geteilten Linux-User-Namen?

    Fortsetzung des Fehlers "falsche Rückschlüsse".

    grep rudi /etc/passwd

    rudi:x:1002:1002:Rudi Rodolfsen,,,:/home/rudi:/bin/bash

    Das ist tatsächlich die Quelle des Problems.... und zwar explizit hier:

    ....was anstatt (was korrekt wäre) "Rudi Rodolfson" fälschlicherweise nur Feld 2 ("Rudi") zurückgibt.


    An die Möglichkeit solcher Linux-User-Namen hab ich nicht gedacht.... das muss natürlich korrigiert werden.

    Wenn ich ehrlich bin, ich habe nicht den leisesten Schimmer... ich vermute, das Problem hängt mit stdout zusammen....möglicherweise bist Du da über einen Bug gestolpert, der vielleicht mit dem durch Blank geteilten Linux-User-Namen entstanden ist. Wenn solche Namen als übergebene Parameter nicht mit "" maskiert werden, ist das Verhalten vorhersagbar fehlerhaft.


    Ich versuche mal mit ein paar Tests dahinter zu kommen.....


    Völlig falsche Rückschlüsse nachträglich gelöscht:

    Oh... den ersten Fehler habe ich schon gesehen:

    /etc/dovecot/alias_maps

    Suitable Linux-User bedeutet, dass zum virtuellen Dovecot-User ein passender Linux-User zugewiesen wird. Laut /etc/passwd ist "Rudi Rodolfson" ein echter Linux-User. Insofern müssten den beiden virtuellen Dovecot-Usern "rudi" und "r.rudi" dieser Linus-User zugewiesen werden, so das das wie folgt aussieht.


    Hier stellt sich jetzt nur die Frage, ob das seitens Dovecot überhaupt richtig verarbeitet wird oder ob das trennende Blank möglicherweise eine permanente Problemquelle darstellt.

    Kannst du deine Anleitung noch dahingehend erweitern, dass der dovecot deamon alle x Minuten die POP3-Server abgrast?

    Das musste ich mir gerade selber mal kurz anschauen und das kannst Du relativ einfach selber über ein kleines Script einrichten, welches Regelmäßig via root-Crontab gestartet wird.


    Im Script werden die virtuellen Usernamen aufgerufen, also exakt die, die in der /etc/dovecot/alias_maps eingetragen sind. Aber Achtung: Ein echter Linux-User kann ja mehrere virtuelle User (resp. Postfächer) innehaben. Das bedeutet, es braucht NUR EINEN virtuellen User, um alle Postfächer des Linux-Users abzurufen. Der Aufruf für die beiden Linux-User Tom und Silvia dann so aus:


    Bash
    #!/bin/bash
    export USER='tom';/usr/local/bin/getmail_eventhandler
    export USER='sylvie';/usr/local/bin/getmail_eventhandler
    exit 0

    Wenn für Tom 5 Postfächer in der alias-maps eingetragen sind und für silvie 3, dann würden damit alle 8 Postfächer aktualisiert werden. Wenn man das ganz intelligent machen will, fragt man einfach in einem while-loop die Einträge der alias-maps ab und startet für jeden eingetraenen virtuellen User einmalig den Job. Man muss noch nicht mal zwingend darauf achten, wenn das für einen User mehrfach gestartet wird, getmail-eventhandler prüft das selber, ob für einen User schon ein Lauf gestartet ist und überspringt einfach alle weiteren.

    Danke für diesen Hinweis.... :thumbup:... und ich muss gestehen, dass ich das jetzt überhaupt nicht mehr verstehe :conf:ich bin total überfordert. Denn diesen Hinweis hatte ich bereits irgendwann im Frühjahr diesen Jahres bekommen und ich bin absolut sicher, dass ich das schon einmal korrigiert habe. Mir ist unerklärlich, was zum verschwinden dieser Änderung geführt haben konnte und ob ggf. auch noch was anderes davon betroffen ist. Ich habs jetzt sofort erneut geändert.

    Leider ging hier niemand auf die eigentliche Frage ein, schade.

    Auf welche Frage? Auf die merkwürdige Frage mit "Zeile 39"... aus einem Script, dessen Start-Modus via init.d seit dem Jahr 2015 nicht mehr direkt unterstützt wird, sondern mehr schlecht als recht nur noch in einem kompatiblitätsmode? Schau Dir später im Thread die systemd-Variante an, die kannst Du Dir nach Deinem erfordernissen anpassen. Die funktioniert auch heute noch.

    Sind die sowieso vorhandenen Bord-Mittel dafür nicht ausreichend?


    TV auf HDMI-1 ist an:

    Code
    $ xrandr | grep connect
    HDMI-1 connected (normal left inverted right x axis y axis)
    HDMI-2 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm

    TV auf HDMI-1 ist aus:

    Code
    $ xrandr | grep connect
    HDMI-1 disconnected (normal left inverted right x axis y axis)
    HDMI-2 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm

    Jemus


    Wie dreamshader schon erwähnt hat, der Thread ist uralt. Du solltest einen neuen eigenen Thread öffnen und kurz beschreiben, welche Rahmenbedingungen bestehen, was Du genau erreichen möchtest, also was am Ende rauskommen soll. Und alles so kurz wie möglich beschreiben, aber so umfassend und eindeutig wie nötig... dann kann man sehen, wie man am besten das Problem lösen kann.

    Hat jemand eine Idee woran es liegen kann, dass es auf 2 Rechnern funktioniert und bei den beiden anderen nicht?

    Vielleicht unterschiedliche Schreibweise des Usernamens auf Server und Client...?... versuch mal eine direkten Mount auf der Windows-Maschine, mit expliziter Angabe von user und password.... genau so, wie es auf der Linux-Maschine eingerichtet ist:

    net use x: \\1.1.1.2\ShareName Pwd /user:%USERDOMAIN%\Username /persistent:no


    IP-Adresse, ShareName, Pwd und Username natürlich entsprechend ersetzen.... case-sensitive !!!

    Was haltet ihr für sinnvoll?

    Deutsche Texte in einem deutschsprachigen Forum, englische Texte in einem englischen/internationalen Forum. Manche technischen Texte sind schon in deutsch hoch-anspruchsvoll, da brauch ich jedenfalls nicht noch zusätzliche Hürden durch eine Fremdsprache. Ich schließ mich Flyppo an... englisch *hier* klick ich vermutlich ein wenig verärgert weg... "vermutlich ein wenig verärgert" dann, wenn mich das Thema eigentlich interessiert.

    dbv: systemd mag in Summe komplexer sein. Deswegen muss es aber nicht zwangsläufig schwieriger bzw. unverständlicher zu konfigurieren sein.


    peuler: das mit dem "leichter verständlich" sehe ich in der Tat genau so ...

    Ich finde #metoo-Postings eigentlich total doof... aber diese beiden vorherigen Statements schließe ich mich voll und ganz an.

    Eine farbliche Unterscheidung wäre natürlich mein Favorit, gefolgt von einer Ausgabe in Textform

    Wie soll das gehen? "grep" kennt doch gar nicht die Farbcodes für journald. Soll heissen, Du hast die Journald-Ausgabe nach grep gepiped, siehst also nicht mehr die Ausgabe von Journald, sondern die von grep.


    Damit kommt die Anzeige auch farblich korrekt:

    Code
    journalctl -b -p err
    journalctl -b -p warning

    Aber es gibt ne bessere Alternative... öffne einfach ein weiteres Fenster und starte dort

    Code
    journalctl -f

    Damit siehst Du live alle Meldungen, die Dein Job in dem anderen Fenster produziert... und hier dann auch farblich markiert.


    BTW: Noch'n Tip... das Statement "systemctl enable" solltest Du tunlichst nicht vorher verwenden, bis Du 100% bestätigt hast, dass Service-Unit und Job zweifelsfrei fehlerfrei funktionieren. Sowas sofort in der Startphase zu machen erschwert es Dir nur, Probleme zu beheben. Der Job muss jederzeit OnTheFly mit

    Code
    systemctl start jobname
    systemctl restart jobname
    systemctl stop jobname

    kontrolliert werden können. Und im zweiten Terminalfenster siehst Du immer passend dazu alle Meldungen. Wenn ich im ersten Terminal den Daemon direkt starte:

    Code
    $ ./daemon start
    thomas@thomaspc:/testbin
    $ ./daemon stop
    thomas@thomaspc:/testbin

    sehe ich im zweiten Terminal bei vorherigem journalctl -f das hier:

    Code
    Apr 18 21:39:47 thomaspc thlu:daemon[6573]: starting
    Apr 18 21:39:47 thomaspc thlu:daemon[6577]: started
    Apr 18 21:39:47 thomaspc thlu:daemon[6580]: running 1: warte 10 Sekunden
    Apr 18 21:39:57 thomaspc thlu:daemon[6586]: running 2: warte 10 Sekunden
    Apr 18 21:40:07 thomaspc thlu:daemon[6592]: running 3: warte 10 Sekunden
    Apr 18 21:40:09 thomaspc thlu:daemon[6599]: stopping
    Apr 18 21:40:09 thomaspc thlu:daemon[6606]: stopped


    Mach ich das gleiche über die Service-Unit (bei mir Type forking) sieht das so aus.... im Terminal 1:

    Code
    # systemctl start daemon
    root@thomaspc:/testbin
    # systemctl stop daemon
    root@thomaspc:/testbin

    was dann im Terminal 2 zur folgenden Ausgabe führt:



    Also... wie ich schon sagte... das beste Vorgehen ist, es "direkt" zu testen... und erst wenns wirklich fehlerfrei läuft folgt ganz am Ende der

    Code
    systemctl enable servicename

    und ggf. ein Reboot für die Abschlußkontrolle.


    Das hier ist mein "Daemon"-Test-Script, welches bei der Entwicklung der Unit die Aufgabe des späteren Programms übernimmt:||


    Und das ist die Mini-Service-Unit, mit der man mit dem Unit-Type Forking rumbasteln kann....

    Code
    [Unit]
    Description=Test Daemon
    [Service]
    Type=forking
    ExecStart=/testbin/daemon start
    ExecStop=/testbin/daemon stop
    [Install]
    WantedBy=multi-user.target


    Also.. alles zusammen demonstriert nur, wie ich sowas angehe.... vielleicht findest Du davon etwas hilfreich....

    Das etwas fehlt kann durchaus sein, hab d

    Mittlerweile ist das Log größer, aber eine Unterscheidung welche Meldungsart es ist ist für mich auch noch nicht ersichtlich.

    Doch, das geht... und die Grösse des Journals habe ich begrenzt.... das regelt also journald für mich. Ich verwende

    err

    warning und

    info (siehe oben)


    zur Unterscheidung meiner Meldungstypen

    Die Reihenfolge ist eigentlich egal, ich entwickel und teste nur beides getrennt.


    Und was die Service-Unit angeht, verwende ich dazu eben ein völlig unverfängliches Script, was definitiv fehlerfrei funktioniert.... was ich dann auch mit Log-Einträgen kontrollieren kann. Wie sich die Unit in den Start einreiht, ob das kollisionsfrei ist, ob die sachlichen und zeitlichen Abhängigkeiten passen, kontrolliere ich mit systemd-analyze. Wenn ich sicher bin, dass es so ist, wie ich will, hänge ich das richtige Programm ein. Wenn es dann Probleme gibt, weiss ich, dass es nicht an systemd oder der Unit liegt. Mitterweile habe ich verschiedene dieser Testscripte, die ich in Abhängigkeit des Unit-Types wähle, bis hin zu einem kurzen Testscript, welches sich forken kann... für den Unit-Type "forking".


    Es ist definitiv anspruchsvoller, als früher unter sysvinit, aber auch definitiv weitaus effektiver, mit genialen Möglichkeiten zu absolut 'feinen' Einstellungen.

    Hofei


    Ich habe grundsätzlich ein geteiltes Vorgehen. Zuerst erstelle ich die Service-Unit mit einem Dummy-Programm, danach das eigentliche Programm, welches im root-Terminal mit dem gleichen Eintrag gestartet wird, wie er in der Service-Unit seht. Wenn beides einzeln funktioniert, funktioniert es auch zusammen. Und "sudo" ist bei allen Tests absolut tabu!


    Als Dummy-Programm verwende ich meistens ein Bash-Script, aber ähnliches sollte auch mit Python klappen... ich hoffe mal, dass auch Python direkt ins Journal schreibt.

    Bash
    #!/bin/bash
    echo "Programm gestartet: User=$USER Param.: 1=$1 2=$2 3=$3" | systemd-cat -t "hofei:$(basename $0)" -p info
    exit 0

    Wenn jetzt also auch das Journal aktiviert ist, könntest Du nachsehen, ob das Programm mit Parameter ordentlich aufgerufen wurde. Also, wichtig ist, das Journal zu aktivieren... und wenn man sich mal dran gewöhnt hat, kann man schließlich sogar die alte Leiche "rsyslog" purgen... das Journal ist viel "mächtiger".


    Code
    journalctl -b | grep hofei


    Nachtrag:

    Hier liegt noch ein Problem mit der Codedarstellung vor... der Shebang wird nicht angezeigt, obwohl er im Codeblock drin steht..., wie kann das sein?