Protokollierung von Systemveränderungen

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Benutzeravatar
Himopka
Beiträge: 39
Registriert: 31.10.2015 19:22:14
Wohnort: Pfälzerwald

Protokollierung von Systemveränderungen

Beitrag von Himopka » 31.12.2017 17:27:56

Wie macht ihr das?
Momentan ist die Sache bei mir recht unübersichtlich. Ich lege in einem Verzeichnis Textdateien ab in denen ich jeweils beschreibe was ich gemacht habe.
Wie macht das ein Profi? Sollte ich mir einen Kalender erstellen und dort die Einträge machen oder gibt es Tools die ich verwenden könnte?
Ich sollte mir auch Gedanken machen wie ich meine Logfiles und Journalfiles machen, also wie ich diese am besten organisiere. Leider fehlt mir hier aber ein Plan. Ein kleiner "Anschubser" eurerseits wäre klasse! :hail:
OS: Debian 9.2; KDE-Plasma 5.8.6
Kernel: x86_64 Linux 4.9.0-4-amd64
CPU: AMD FX-4300 Quad-Core @ 3.8GHz
GPU: Gallium 0.4 on AMD TURKS (DRM 2.49.0 / 4.9.0-4-amd64, LLVM 3.9.1)
RAM: 11,75GiB

Benutzeravatar
MarkusF
Beiträge: 361
Registriert: 04.06.2007 12:45:22

Re: Protokollierung von Systemveränderungen

Beitrag von MarkusF » 01.01.2018 01:34:06

evtl. https://packages.debian.org/de/stretch/git

Je nachdem was du vorhast. Aber um z.B. /etc im Blick zu halten...

Gutes Neues Jahr an alle! Mist, wenn man kränklich daheim bleiben muss wenn die anderen Party...

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Protokollierung von Systemveränderungen

Beitrag von breakthewall » 01.01.2018 03:00:46

Erstmal gutes neues Jahr.

An deiner Stelle würde ich die Problematik hinsichtlich möglicher Systemveränderungen, gänzlich präventiv lösen. Sprich, es wird nicht aufgezeichnet was sich ggf. verändert, sondern das ganze System wird so aufgesetzt, dass es nicht mehr verändert werden kann.

Eine sehr wirksame Möglichkeit wären hier read-only Volumes. Hierfür muss aber von Anfang an entsprechend partitioniert, und das System in mehrere Bereiche unterteilt werden. Dann lassen sich die Teilbereiche wahlweise über Dateisystemoptionen wie, ro, nodev, noexec oder nosuid schützen. Ersteres würde ein Volume wie z.B. / oder /boot, unverwundbar machen zur Laufzeit. Hier kann dann sozusagen nichts mehr gelöscht oder manipuliert werden, was es erst garnicht notwendig macht hier etwas zu überwachen. Und solange der read-only Status besteht, wurde logischerweise auch nichts verändert. Kann man nur empfehlen sich das zunutze zu machen, gerade als eine zusätzliche Schutzschicht. Nebenbei auch praktisch um eigener Fahrlässigkeit vorzubeugen, bevor man etwas unbeabsichtigt löscht.

Alternativ gäbe es auch das Immutable-Bit, was seitens des Dateisystems via "chattr +i Datei" beliebig gesetzt werden kann. Das sorgt auch unmittelbar für einen Schreibschutz, nur in gezielter Weise. Praktisch für gewisse Dateien die unveränderlich sein sollen, bspw. Konfigurationen.

Zur reinen Überwachung von Dateien oder ganzen Verzeichnissen, eignet sich auch auditd aus dem Repository. Hiermit wird auf das Audit-Framework des Linux-Kernels zugegriffen, um eine umfassende Analyse oder Systemüberwachung zu realisieren.

TomL

Re: Protokollierung von Systemveränderungen

Beitrag von TomL » 01.01.2018 12:05:10

Himopka hat geschrieben: ↑ zum Beitrag ↑
31.12.2017 17:27:56
Wie macht ihr das?
Prinzipiell nicht viel anders.... wobei ich das definitiv nicht in einen Kalender übernehmen würde. Das macht es nachher unmöglich Änderungen direkt hintereinander zu vergleichen.

Ich habe ebenfalls ein Verzeichnis mit Text-Files, wobei jedes Textfile den passenden Namen zum "Objekt" trägt. Mittlerweile habe ich mir angewöhnt, chronologische relevante Einträge auch wirklich mit Datum zu versehen, in der Form, dass ich die Chronologie auch wirklich zeilenweise auf einen Blick verfolgen kann. Sofern es sich nur um Syntaxerklärungen, HowTo's oder technische Erinnerungsvermerke handelt, gruppiere ich diese Vermerke in der gleichen Datei, mit hierarchischen Trennlinien abgetrennt. Hierarchisch bedeutet ===== oder ------ oder - - - - - mit Kapitelüberschriften unter der Trennline. Das macht es dann ziemlich übersichtlich.... aber auch viel Arbeit. Aber die Arbeit zahlt sich aus, wenn man drauf zurückgreifen muss.

Sofern es sich um Änderungen in Conf's handelt, handhabe ich Änderungen mit Versions-Bezeichnungen. Die Kopie des Originals bekommt immer die Extension ".V_0_0", dann gehts weiter mit ".V_1_0", ".V_1_1", ".V_2_0", usw. wenn ich Änderungen vorgenommen habe. Die aktive Conf hat keine Extension, aber es besteht schon eine Kopie mit passender Erweiterung. Und natürlich sind alle diese Confs Bestandteil des Backup-Konzeptes. Das heisst, die werden alle (aber nur die) regelmäßig automatisch mitgesichert.

Meine eigenen Scripte liegen in /usr/local/bin, welches Zusätzlich ein Verzeichnis "History" enthält. Und in History pflege ich nach gleichem Prinzip wie zuvor die Script-Versionen, um immer Änderungen zurückverfolgen zu können.... je Script ein eigenes Unterverzeichnis, in dem alle Versionen lagern. Auch dieses Verzeichnis ist komplett im Backup-Konzept berücksichtigt.

Und speziell für die Systemeinstellungen des Servers mit Scripte und Confs und Customizing-Support-Files legt mein Server zusätzlich noch automatisch versionierte Backups an, automatisch 1 mal im Monat. Und von denen behalte ich dauerhaft nur die Milestone-Backups.... das heisst, ein Milestone-Backup wäre z.B. das letzte Jessie-Backup vor der Migration nach Stretch, oder bei einem Rechnerwechsel. Ich bin, was Sicherung und Reproduzierbarkeit angeht, einigermaßen paranoid... *lol*.... ich habe Schiss, dass ich das ohne meine Hilfkrücken nie wieder so hinkriegen würde, wie es jetzt ist.... also bin ich da übertrieben gewissenhaft.

J.m.2.c.

Benutzeravatar
Himopka
Beiträge: 39
Registriert: 31.10.2015 19:22:14
Wohnort: Pfälzerwald

Re: Protokollierung von Systemveränderungen

Beitrag von Himopka » 02.01.2018 05:21:51

MarkusF hat geschrieben: ↑ zum Beitrag ↑
01.01.2018 01:34:06
evtl. https://packages.debian.org/de/stretch/git

Danke für die Anregung! Leider bin ich momentan (noch) nicht in der Lage das System einzusetzen, sprich, ich bin froh, daß ich mitlerweile überhaupt verstehe was git eigentlich ist... :roll:

breakthewall hat geschrieben: ↑ zum Beitrag ↑
01.01.2018 03:00:46
An deiner Stelle würde ich die Problematik hinsichtlich möglicher Systemveränderungen, gänzlich präventiv lösen. Sprich, es wird nicht aufgezeichnet was sich ggf. verändert, sondern das ganze System wird so aufgesetzt, dass es nicht mehr verändert werden kann.

Eine sehr wirksame Möglichkeit wären hier read-only Volumes. Hierfür muss aber von Anfang an entsprechend partitioniert, und das System in mehrere Bereiche unterteilt werden. Dann lassen sich die Teilbereiche wahlweise über Dateisystemoptionen wie, ro, nodev, noexec oder nosuid schützen. Ersteres würde ein Volume wie z.B. / oder /boot, unverwundbar machen zur Laufzeit. Hier kann dann sozusagen nichts mehr gelöscht oder manipuliert werden, was es erst garnicht notwendig macht hier etwas zu überwachen. Und solange der read-only Status besteht, wurde logischerweise auch nichts verändert. Kann man nur empfehlen sich das zunutze zu machen, gerade als eine zusätzliche Schutzschicht. Nebenbei auch praktisch um eigener Fahrlässigkeit vorzubeugen, bevor man etwas unbeabsichtigt löscht.

Alternativ gäbe es auch das Immutable-Bit, was seitens des Dateisystems via "chattr +i Datei" beliebig gesetzt werden kann. Das sorgt auch unmittelbar für einen Schreibschutz, nur in gezielter Weise. Praktisch für gewisse Dateien die unveränderlich sein sollen, bspw. Konfigurationen.

Zur reinen Überwachung von Dateien oder ganzen Verzeichnissen, eignet sich auch auditd aus dem Repository. Hiermit wird auf das Audit-Framework des Linux-Kernels zugegriffen, um eine umfassende Analyse oder Systemüberwachung zu realisieren.

Danke für deine Informationen!
Das read-onlyKonzept ist sehr interessant und ich habe es für meine boot Partition auch schon eingerichtet. Da ich aber mein System als Workstation nutze bin ich mir nicht sicher ob das bei meinen recht häufigen Neuinstallationen und Löschungen von Anwendungen und bei den damit einhergehenden häufigen Updates wirklich Sinn macht, Ich müsste dann doch jedes Mal die Berechtigungen ändern, oder? Ich habe mir das Tool "Timeshift" (http://www.teejeetech.in/p/timeshift.html) eingerichtet welches mir jetzt schon einige Male "den Arsch gerettet" hat. Was hältst du davon?


TomL hat geschrieben: ↑ zum Beitrag ↑
01.01.2018 12:05:10
Prinzipiell nicht viel anders.... wobei ich das definitiv nicht in einen Kalender übernehmen würde. Das macht es nachher unmöglich Änderungen direkt hintereinander zu vergleichen.

Ich habe ebenfalls ein Verzeichnis mit Text-Files, wobei jedes Textfile den passenden Namen zum "Objekt" trägt. Mittlerweile habe ich mir angewöhnt, chronologische relevante Einträge auch wirklich mit Datum zu versehen, in der Form, dass ich die Chronologie auch wirklich zeilenweise auf einen Blick verfolgen kann. Sofern es sich nur um Syntaxerklärungen, HowTo's oder technische Erinnerungsvermerke handelt, gruppiere ich diese Vermerke in der gleichen Datei, mit hierarchischen Trennlinien abgetrennt. Hierarchisch bedeutet ===== oder ------ oder - - - - - mit Kapitelüberschriften unter der Trennline. Das macht es dann ziemlich übersichtlich.... aber auch viel Arbeit. Aber die Arbeit zahlt sich aus, wenn man drauf zurückgreifen muss.

Sofern es sich um Änderungen in Conf's handelt, handhabe ich Änderungen mit Versions-Bezeichnungen. Die Kopie des Originals bekommt immer die Extension ".V_0_0", dann gehts weiter mit ".V_1_0", ".V_1_1", ".V_2_0", usw. wenn ich Änderungen vorgenommen habe. Die aktive Conf hat keine Extension, aber es besteht schon eine Kopie mit passender Erweiterung. Und natürlich sind alle diese Confs Bestandteil des Backup-Konzeptes. Das heisst, die werden alle (aber nur die) regelmäßig automatisch mitgesichert.

Meine eigenen Scripte liegen in /usr/local/bin, welches Zusätzlich ein Verzeichnis "History" enthält. Und in History pflege ich nach gleichem Prinzip wie zuvor die Script-Versionen, um immer Änderungen zurückverfolgen zu können.... je Script ein eigenes Unterverzeichnis, in dem alle Versionen lagern. Auch dieses Verzeichnis ist komplett im Backup-Konzept berücksichtigt.

Und speziell für die Systemeinstellungen des Servers mit Scripte und Confs und Customizing-Support-Files legt mein Server zusätzlich noch automatisch versionierte Backups an, automatisch 1 mal im Monat. Und von denen behalte ich dauerhaft nur die Milestone-Backups.... das heisst, ein Milestone-Backup wäre z.B. das letzte Jessie-Backup vor der Migration nach Stretch, oder bei einem Rechnerwechsel. Ich bin, was Sicherung und Reproduzierbarkeit angeht, einigermaßen paranoid... *lol*.... ich habe Schiss, dass ich das ohne meine Hilfkrücken nie wieder so hinkriegen würde, wie es jetzt ist.... also bin ich da übertrieben gewissenhaft.

J.m.2.c.

Danke!
Wenn Du erlaubst so werde ich mir direkt dein System zu eigen machen! :mrgreen:
OS: Debian 9.2; KDE-Plasma 5.8.6
Kernel: x86_64 Linux 4.9.0-4-amd64
CPU: AMD FX-4300 Quad-Core @ 3.8GHz
GPU: Gallium 0.4 on AMD TURKS (DRM 2.49.0 / 4.9.0-4-amd64, LLVM 3.9.1)
RAM: 11,75GiB

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Protokollierung von Systemveränderungen

Beitrag von breakthewall » 02.01.2018 06:40:31

Himopka hat geschrieben: ↑ zum Beitrag ↑
02.01.2018 05:21:51
Da ich aber mein System als Workstation nutze bin ich mir nicht sicher ob das bei meinen recht häufigen Neuinstallationen und Löschungen von Anwendungen und bei den damit einhergehenden häufigen Updates wirklich Sinn macht, Ich müsste dann doch jedes Mal die Berechtigungen ändern, oder? Ich habe mir das Tool "Timeshift" (http://www.teejeetech.in/p/timeshift.html) eingerichtet welches mir jetzt schon einige Male "den Arsch gerettet" hat. Was hältst du davon?
Dieses Programm ist mir bislang nicht bekannt gewesen, habe jedoch selbst keine Verwendung dafür. Und hinsichtlich potenzieller Systemveränderungen, stimmt das natürlich das die Restriktionen rückgängig gemacht werden müssen. Doch hierfür gibt es eine praktische Apt-Konfiguration, die mit Dpkg interagiert bei Installationen. Diese müsste nur minimal erweitert werden, um die Restriktionen bei jeder Installation, vom Paketmanager automatisch aufheben und wieder setzen zu lassen. Von daher nicht wirklich kompliziert.

Das einzige was evtl. ungünstig sein kann ist, dass ggf. für / bzw. das Wurzelverzeichnis, ein read-only Status nicht wiederhergestellt werden kann, sobald tiefgreifende Systemänderungen stattfanden, und entsprechend offene Dateien existieren. Das lässt sich nur mittels Neustart lösen, den man aber automatisch initialisieren könnte, wenn eine Installation sehr umfassend war. Würde zumindest Sinn machen.

Benutzeravatar
Himopka
Beiträge: 39
Registriert: 31.10.2015 19:22:14
Wohnort: Pfälzerwald

Re: Protokollierung von Systemveränderungen

Beitrag von Himopka » 02.01.2018 11:15:07

Diese Apt-Konfiguration, finde ich die wenn ich die Manpage von APT durchforste?
OS: Debian 9.2; KDE-Plasma 5.8.6
Kernel: x86_64 Linux 4.9.0-4-amd64
CPU: AMD FX-4300 Quad-Core @ 3.8GHz
GPU: Gallium 0.4 on AMD TURKS (DRM 2.49.0 / 4.9.0-4-amd64, LLVM 3.9.1)
RAM: 11,75GiB

Benutzeravatar
MarkusF
Beiträge: 361
Registriert: 04.06.2007 12:45:22

Re: Protokollierung von Systemveränderungen

Beitrag von MarkusF » 03.01.2018 12:58:56

das was du willst ist eigentlich gar nicht sonderlich kompliziert. Wenn du die Grundkonfiguration nach Neuinstallation als Basis nimmst,, diese sicherst und lokal speicherst kannst du, wenn es ganz einfach sein soll, den GAP, also deine Änderungen, mit z.B. https://packages.debian.org/stretch/meld oder https://packages.debian.org/de/wheezy/kdiff3 jederzeit einsehen, dann halt ohne Revisionskontrolle.

Wenn es dir auch noch um evtl. unberechtigte Änderungen von außen geht, - readonly Ansatz, kannst du z.B. auch autom. Prüfsummen vergleichen, wobei ntl das unterbinden von Änderungen immer vorzuziehen ist.

Der Ansatz z.B. mit GIT ist dann einfach nochmal ne Stufe drauf. Ich z.B. ziehe mir auf den Servern die /etc lokal, revisioniere die Änderungen und kann jeden beliebigen Zustand jederzeit wieder herstellen, auch auf anderen Servern. Die Doku und Verfolgbarkeit ist -jedenfalls für mich - absolut perfekt.

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Protokollierung von Systemveränderungen

Beitrag von heisenberg » 03.01.2018 13:25:05

Der Klassiker zum protokollieren ist der Debianetckeeper, der git, bzr, oder eine Reihe anderer Versionsverwaltungssysteme verwendet um eine History aufzuzeichnen. Damit kann man änderungen in /etc überwachen.

Für beliebige Verzeichnisse ist evtl. das ältere Debianchangetrack besser geeignet.

Der Thread hier im DF könnte auch interessant sein, das sind jetzt aber eher komplexere Ansätze:

viewtopic.php?f=32&t=167798

Ein Versionsverwaltungssystem ist vergleichsweise komplex. Aber für ein bisschen Config-Tracking braucht man im Alltag wahrscheinlich eh' nicht mehr als 5 verschiedene Befehle davon.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Protokollierung von Systemveränderungen

Beitrag von MSfree » 03.01.2018 14:43:39

heisenberg hat geschrieben: ↑ zum Beitrag ↑
03.01.2018 13:25:05
Der Klassiker zum protokollieren ist der Debianetckeeper, der git, bzr, oder eine Reihe anderer Versionsverwaltungssysteme verwendet um eine History aufzuzeichnen. Damit kann man änderungen in /etc überwachen.
Wobei ein Versionskontrollsystem die (zusätzliche) Dokumentation nicht eretzen kann. In vielen Fällen geht es ja nicht nur darum, die Änderungen irgendwie festzuhalten, sondern darum, daß wenn man ein neues bzw. ein Ersatzsystem aufsetzen will, eher auf die Dokumentation zurückgreift als auf die History eine CVS/SVN/GIT etc.

Oft setzt man so eine neues System dann mit einer neueren OS-Version auf, so daß die alten Konfigs nicht unbedingt direkt übernommen werden können und so nicht aus dem Versionkontrollsystem extrahierbar sind.

Mein persönlicher Ansatz ist eher, auf Versionkontrolle zu Verzichten, das hilft im Grunde nur in Serverfarmen, wo man hunderte Kisten weitgehend identisch konfiguriert. Ich habe mir die wesentlichsten Dinge in einem eigenen Mediawiki vermerkt. Das ist allemal besser als ASCII-Dateien und überall im LAN erreichbar. Wiki ist sicherlich auch nicht der Weisheit letzter Schluß, vor allem, wenn man viele unterschiedliche Installationen dokumentieren und protokollieren muß.

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Protokollierung von Systemveränderungen

Beitrag von heisenberg » 03.01.2018 15:16:25

Wobei ein Versionskontrollsystem die (zusätzliche) Dokumentation nicht eretzen kann.
Sicherlich nicht. Aber es ist eine Komponente, die quasi schon mit minimalen Aufwand einen echt brauchbaren Nutzen hat.

Use case #1: Problem mit Dienst X. --> Ich schaue mal in die History, was da in dem Verzeichnis so passiert ist.

Use case #2: Ich habe jetzt 100 Mal was geändert und ich weiss nicht mehr welcher von den 100 Ständen zwischendrin der war, der funktioniert hat.

Use case #3: Die Performance von Dienst X hat sich mehrfach geändert. Welche Konfigurationsänderungen haben welche Auswirkungen gehabt?

Das ist nur das, was mir so spontan dazu einfällt.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Antworten