Beiträge von Igel1954

  • Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

    Zur Zeit experimentiere ich noch mit einigen Einstellungen. Ich habe mal die Parameter Nice=19, IOSchedulingClass=2 und IOSchedulingPriority=4 gesetzt, aber meine Werte haben dadurch wohl die Laufzeit der Sicherung verdoppelt, so dass ich die 3 Parameter wohl wieder lösche und damit wieder auf die Standardwerte zuücksetze.


    Ich hab bei meiner Suche nach Beschreibungen von Beispielen einen Artikel der LinuxUSer aus 07/2018 gefunden:


    Systemd-Units verstehen und selbst schreiben


    Der Artikel beschreibt den Aufbau einer Systemd-Unit für autofs.


    Der Artikel hat mir weiter geholfen, um meine selbst erstellten Systemd-Units zu verbessern. Ich glaube dabei auch den Grund gefunden zu haben, weshalb meine Timer-Units beim Neustart des OS nicht gestartet werden. Ich muss das bisher nach einem Neustart manuell auslösen.


    Wenn ich meine Systemd-Units soweit habe, dass auch der Start der Units nach einem Neustart des OS automatisch erfolgt, stelle ich eine als Beispiel hier ein.

  • Wie leicht ist Windows trojanisierbar? (samt Viren und Würmer)

    Zitat von Katzenfreund

    ich will auf der Frage nicht herumreiten ...

    Wenn Du meinen Text aufmerksam gelesen hast, müsstest Du auf die Anwort selber kommen. Jedes OS ist "trojanisierbar", wenn du Zugriff darauf hast und den Trojaner selber baust. Dazu braucht es unter Windows, glaube ich, nicht mal Admin-Rechte. Du brauchst nur Zugriff auf einen entsprechenden Compiler. Wenn du in dann in deinem User startest, kannst du damit die Fähigkeiten der Antivirensoftware testen. Du solltest vorher nur den Rechner vom Netzwerk trennen und musst ihn u. U. anschließend platt machen und Windows jungfräulich installieren. Du könnstest sogar den selber gebauten Trojaner im (Firmen)Netzwerk an deine Kollegen verteilen, um deren Rechner zu infizieren.


    Die Bauanleitung dazu gibt es sogar frei im Internet (Links liefert dir Tante Goggel reichlich).


    Die größte Gefahr für die Verseuchung eines Intranets geht immer von einem im Intranet tätigen Benutzers aus, ob aus Unvorsichtigkeit beim Öffnen von Dateien aus unbekannte Quellen oder aus Bosheit, um der Firma oder den Kollegen zu schaden.


    Wie Hidalgo oben schreibt, nichts und niemand ist vor irgendetwas sicher, ob positiv oder negativ.

  • Wie leicht ist Windows trojanisierbar? (samt Viren und Würmer)

    Angriffe auf die IT gab es schon, bevor Bill Gates seine OS (DOS, Win) und die dazugehörige Hardware existierten. Selbst zu der Zeit als es nur "dumme" Terminals gab, wurde versucht in Rechner einzudringen, weil Firmen mit mehreren Firmensitzen (Hauptstellem Filialen) ja auch schon über Datenleitungen (Tokenring, o.ä) verbunden waren.

    Da ich ja aus der Hardware- und Operatingsystem-Umgebung von Mama Blue komme, sind mir hier auch solche (vergeblichen) Versuche bekannt geworden. Hier sind die OS-Umgebungen aber so aufgebaut, dass man eigentlich erst einmal gar nichts darf. Alles was nicht explizit erlaubt ist, ergibt beim Versuch es tun, einen Sicherheitsverstoß.

    Das macht auch vor den eigenen IT-Mitarbeitern keinen Halt. Der Zugriff auf eine nicht freigegebene Datei erzeugt eine Meldung über eine unerlaubten Zugriff. Den darf man dann spätestens 2 Tage später mit einer mehrseitigen Erklärung begründen, selbst wenn es nur durch ein Versehen wegen Buchstaben-/Zahlendreher im Dateinamen war.


    Erfolgreiche Versuche kamen immer aus dem Kreis der eigenen Mitarbeiter (Z. B. Rundungsdifferenzen sammeln und sich auf seinem Konto gutschreiben, oder nach Kündigung die Selbstzerstörung eines Programms bzw. seiner Datenbestände in dem Programmcode zu verstecken).

  • Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

    Zitat von Sauerland

    Ich hab jetzt nicht alles nochmal nachgelesen, aber warum benutzt du nicht /etc/systemd/?

    /usr/local/ ist eine eigene Partition auf der Platte auf der auch meine Home-Partition liegt, und da gehen dann die Daten auch nicht verloren, wenn ich mal Linux komplett neu installieren müsste. Und /usr/local/lib/systemd/system ist ja auch im Suchpfad (systemd-analyze --system unit-paths ).


    Beim aktivieren der Timer wird ja auch ein Link nach /etc/systemd/system gesetzt:


    Code
    igel01:~ # systemctl reenable --now BackupFS.timer BorgBackup.timer Update_OS.timer 
Removed /etc/systemd/system/multi-user.target.wants/BackupFS.timer.
Removed /etc/systemd/system/multi-user.target.wants/BorgBackup.timer.
Removed /etc/systemd/system/multi-user.target.wants/Update_OS.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/BackupFS.timer → /usr/local/lib/systemd/system/BackupFS.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/BorgBackup.timer → /usr/local/lib/systemd/system/BorgBackup.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/Update_OS.timer → /usr/local/lib/systemd/system/Update_OS.timer.
igel01:~ #

  • Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

    Mir ist jetzt in den letzten Tag noch etwas negatives zu gestoßen. Nach einem, durch einen Patch erzwungenen, Neustart wurden meine 3 systemd-timer nicht sauber wieder aktiv gesetzt. Vermutlich ist hier systemd etwas zu früh, weil meine systemd-timer und -services ja in /usr/local/lib/systemd/system liegen.


    Ich musste sie manuell wieder aktivieren.


    Jetzt versuche ich durch Tests herauszufinden, weleche Angaben im Bereich [Init] zusätzlich notwendig sind, um das aktivieren der Timer zu verzögern.


    Ich hab bisher nur die folgenden targets iin [Init] angegeben:


    Code
    [Unit]
Wants=network-online.target local-fs.target

    Ich muss jetzt erstmal schauen, welche Targets ich an dieser Stelle noch als Sync-Point angeben muss/kann.

  • Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

    Ich hab meine 3 regelmäßigen Aufgaben jetzt ein paar Tage schon via systemd laufen.


    Da der vorhandene Inhalt der Dateien, in die ich meine Protokollausgaben schreibe, beim öffnen nicht gelöscht (truncated) sondern nur überschrieben wird, wollte ich variable Dateinamen verwenden. Das ist aber leider von systemd nicht vorgesehen. Man kann bei StandardOutput etc. keine Shellvariablen im Dateinamen verwenden. Die Fehlermeldung taucht aber erst bei der Ausführung der Service-Unit im Journal auf und die Unit wird nicht ausgeführt.


    Ich suche zur Zeit noch nach einer Möglichkeit, entweder meine Protokolldateien Dateien beim Start der Unit zu leeren bzw. zu löschen. Da experimentiere ich noch.


    Ich hab aber nach mehrmaligem Lesen der Man-page systemd.units meine selbsterstellten Unit-Files nicht mehr in /etc/systemd/system liegen, sondern in /usr/local/lib/systemd/system. Das hat bei mir sogar den Vorteil, dass ich /usr/local auf der 2. Platte in einer separaten Partition liegen habe und diese bei einem Upgrade meines Systems nicht angepackt wird.


    Da meine Scripte, die ich über systemd ausführen lasse, ja in /usr/local/bin liegen, ist jetzt alles was zusammengehört am gleichen Ort (Partition/Filesystem).


    Man kann sich die Pfade, die von systemd im --system Mode bzw im --user Mode durchsucht werden, anzeigen lassen:


    Pfade im --system Mode

    Pfade im --user mode:

  • Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

    Noch eine Besonderheit bei dem Service hab ich vergessen zu erwähnen.

    Man kann in einem Service mehrere ExecStart-Anweisungen einsetzen, die alle sequentiell abgearbeitet werden. Nur hat das einen kleinen Nachteil, wenn man die Ausgaben der einzelnen Programme/Scripte nach  StandardOutput=file:/pfad/datei schreiben lässt. Jede ExecStart-Anweisung überschreibt die vorherige Ausgabe. Will man alle Ausgaben der einelnen ExecStart-Anweisungen erhalten, muss man hier mit StandardOutput=append:/pfad/datei arbeiten und evtl. den erzeugten File später händisch bereinigen.


    Ich hatte bei meinem Sonntags-Service zuerst beide Backups in einem Service abhandeln wollen und dabei dann feststellen müssen, dass mein erzeugtes Log-File nur die Ausgaben der letzten ExecStart-Anweisung enthielt. Ich hab mir dann noch mal in den Man-Pages die OnCalender_Möglichkeiten angesehen und dabei dann auch gesehen, dass diese Angabe mehrfach in einem Timer auftreten darf.


    Wie man Status seiner Timer und Services überprüfen kann, beschreibe ich mit dem folgenden Beispiel.


    Mit systemctl status <name>.timer läßt sich prüfen, ober der Timer aktiv ist und auf die nächste Ausführung wartet. Er zeigt auch an, wie der getriggerte Service heißt.


    systemctl status <name>.service zeigt, ob der Service geladen ist, seit wann er inactive ist und von wem er getriggert wird und ob die letzte Ausführung fehlerfrei war.