Systemadministration: Dokumentation

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Systemadministration: Dokumentation

Beitrag von heisenberg » 07.12.2017 15:44:47

Eine Frage, die immer mal wieder bei mir auftaucht ist die Dokumentation der Systemadministration.

Dabei geht es mir jetzt weniger um die Dokumente, die man sowieso manuell erstellen und auf dem aktuellen Stand halten muss(Z. B. Netzwerkplan, Ablaufpläne, Aufbaupläne und -skizzen) sondern um die Tagesadministration. Ein schlimmer Fall wäre da, wenn eine Änderung unbemerkt bleiben würde und widerrum Folgefehler aufgrund nichtbeachtung der Änderung verursacht.

Besonders, wenn man mit mehreren Leuten an einem Serverpool zu Gange und besonders auch dann wenn die Koppelung eher etwas lose ist, ist die Frage wie man so etwas elegant und effizient erledigt.

Für mein Hauptfeld habe ich mir ein kleine PHP-Anwendung umgemodelt, wo ich dann ab und an was eintrage.

Ich frage mich, ob es nicht praktisch wäre, etwas auf der Shell zu haben. Da kann man mal eben so einen Befehl abschicken, der dann automatisch mit Benutzernamen, Zeit, Servernamen in ein zentrales Log fliesst.

Wie macht Ihr das so?
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Systemadministration: Dokumentation

Beitrag von bluestar » 07.12.2017 16:31:50

Wir nutzen u.a. etckeeper und pushen damit Änderungen in ein zentrales Repo, daraus generieren wir wiederrum Info-Mails an die beteiligten Administratoren. Parallel dazu haben wir noch Scripte um automatisiert Media-Wiki Inhalte aktuell zu halten.

Ich würde jedoch gerne noch einen Schritt weitergehen und automatisiert sämtliche Änderungen durch Administratoren mitloggen, insbesondere um so auch ein Auditing zu ermöglichen um gegenüber Kunden nachweißlich belegen zu können, was getan/nicht getan wurde.

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

Re: Systemadministration: Dokumentation

Beitrag von heisenberg » 07.12.2017 16:45:30

etckeeper hab ich auch im Einsatz.

Meine Gedanken gehen aber in dem Fall weniger in Richtung Aufzeichnung der Änderungen, sondern mehr um die Kommentare der Admins, also nicht was wurde gemacht?, sondern warum wurde etwas gemacht?

Hintergründe wären:
  • Gründe für Änderungen erfahren
  • Fehler sehen, wenn jemand zwar richtige Gründe hatte, aber etwas falsch umgesetzt hat.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemadministration: Dokumentation

Beitrag von r4pt0r » 07.12.2017 21:56:59

Disclaimer: Ich bin eine 1-Mann-Show und für _alles_ zuständig - Dienste, Server, Clients, Router, FW, VPN, Switches, Kabel verlegen, Drucker...
Da ich ständig das "Fachgebiet" wechseln muss, ist ausführliche Dokumentation für mich essentiell - trotzdem habe ich absolut keine Ahnung ob mein System und Art der Dokumentation in großen Teams wirklich taugen würde...


Bei mir ist praktisch alles was manuell bearbeitet wird in git-repositories. Der Anteil an configdateien die ich selber anrühre wird dabei immer geringer, vieles ist gescriptet, das meiste davon per ansible.

Praktisch alle Dienste auf Servern werden per ansible ausgerollt und verwaltet - das zieht configs entweder aus dem jeweiligen git-repo oder bei boilerplate-Konfiguration werden die Dateien aus templates generiert. Sämtliche Ansible-Projekte sind natürlich ebenfalls in git-repositories verwaltet.
Jeder commit wird so kommentiert, dass ich i.d.r. auch monate später wieder weiß was ich mir dabei gedacht habe (oder wo der denkfehler war...). Jedes repo hat eine relativ ausführliche README.md, in der ich sowohl das grundlegende Layout erkläre (aber nicht das was aus den playbooks ohnehin hervorgeht; nur Überlegungen und "warum"), als auch Besonderheiten der Konfiguration (mit Begründung) und ggf Grenzfälle, stolpersteine/bugs ("caveats") und ggf workarounds oder Hinweise auf patches.
Am Ende jeder Readme habe ich i.d.r. auch einen Abschnitt mit "braindumps", in dem ich mal mehr, mal weniger strukturiert alles Dokumentiere, was beim Entwickeln einer Lösung angefallen ist: Alternativen, dead-ends, Quellenangaben und oft auch allgemeine Rants zu hirntoten implementierungen/software/bugs/etc mit denen man sich rumschlagen musste (betrifft vor allem Dienste/Projekte die Berührungspunkte mit Windows und/oder proprietärer Software haben :roll: ). Diese Rants dürften in größeren Teams problematisch werden (NSFW :wink:), haben sich bei mir aber zum Ärger abladen und dabei trotzdem noch hilfreiche Infos unterbringen bewährt. Bei manchen (speziell Windows-)Problemen weiß ich z.T. nur noch nach welchem Schimpfwort ge-grept werden muss - im selben Abschnitt steht dann die Lösung :lol:
Selbst geschriebene Tools/Scripte haben grundsätzlich auch eine manpage; Allgemeine Dokumentation dazu steht wie gehabt in der Readme.md des git repos, Änderungen sind in den commit-notes dokumentiert.

Bei größeren Projekten kann die readme relativ lang werden: z.B. für die komplett automatisierte Clientinstallation von TrueOS inkl Windows 7 VM ist diese aktuell 800 Zeilen lang - und es liegen noch etliche Schmierzettel auf dem Schreibtisch und einiges ist noch unstrukturiert oder muss noch eingepflegt werden...

Für allgemeine/kleine "Dokumentationen" die ggf für nicht-IT-Personal wichtig (oder relevant) sein könnten, habe ich noch einen kleinen Admin-bereich in unserer Horde-Wiki (wicked) angelegt. Hier finden sich allgemeine Dinge wie Netzwerkpläne, VLAN-/zonen-/subnet-layouts etc. Also alles was eher statisch mit wenigen/seltenen Änderungen ist und evtl einfach für nicht-IT-Personal zugänglich gemacht werden können muss.

Also kurz und knapp:
Praktisch alles liegt in git repositories und wird dort dokumentiert.

Zudem wird hier so viel wie möglich automatisiert per Ansible ausgerollt und konfiguriert, damit manuelle Änderungen direkt an den Servern minimiert werden bzw i.d.r. überflüssig (bzw nicht möglich) sind.
Hostinstallationen werden nur minimal verändert, damit z.B. auch bei Totalausfall schnell auf neuer Hardware ausgerollt werden kann. Am perfektesten ist das mit smartOS möglich, auf den FreeBSD Servern sind sämtliche dienste in Jails untergebracht.
Einige playbooks, vor allem für infrastrukturdienste (DHCP, DNS, NIS, NFS...), sind mittlerweile OS-agnostisch und können beliebig neu oder zusätzlich in Jails oder Zones ausgerollt werden. Dadurch sind Installationen reproduzierbar und die Fehlerquelle "manuelles Editieren" wird stark minimiert bzw zum großteil eliminiert.
Nebeneffekt davon ist natürlich, dass Dokumentation von Änderungen dann auch nur an zentraler Stelle im jeweiligen Ansible playbook/rolle/modul nötig ist bzw in der Configdatei/Template die von Ansible geladen wird. Direkt auf Hosts/jails/zones/VMs liegen keinerlei Dokumentationen.
Weiterer nebeneffekt: Ein (zusätzliches) Backup der Infrastruktur (ohne Userdaten) besteht aus vielen git-repositories die ziemlich kompakt sind - das lässt sich extrem schnell&einfach mehrmals täglich mit tarsnap sichern.

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Re: Systemadministration: Dokumentation

Beitrag von DynaBlaster » 09.12.2017 12:01:31

@ r4pt0r

Cool, wir machen das hier im Grunde genauso. Ansible übernimmt die Software-Installation und pusht im Nachgang die entsprechenden Konfigurationsdateien auf die Server. /etc/ansible vom "Ansible-Server" wird in einem Git-Repo gepflegt, um da Änderungen nachhalten zu können.

Angefangen haben wir mit dem Ausrollen von Nagios/Icinga. Es war einfach lästig, die ganzen Konfigurationen manuell auf dem Client und dann nochmal auf dem Server selbst zu konfigurieren und dann bei jeder Änderung an dem System wieder 2 Configs zu editieren. Gut, mittlerweile hat sich da Icinga-seitig ne ganze Menge getan und man kann die Konfigurationen bzw. Checks auch da jetzt verteilen lassen. Hab mich da aber nur ansatzweise mit beschäftigt und müsste mal schauen, wie es da mit FreeBSD-basierten Dingen wie pfSense/OPNSense und Freenas aussieht.

Der ELK-Stack inkl. Java wird auch via Ansible installiert und konfiguriert. Grundsätzliche Einstellungen wie die SSMTP- und SSHD-Konfiguration inkl. Verwaltung der SSH-Keys sind schon ne coole Sache.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemadministration: Dokumentation

Beitrag von r4pt0r » 11.12.2017 16:57:32

DynaBlaster hat geschrieben: ↑ zum Beitrag ↑
09.12.2017 12:01:31
Hab mich da aber nur ansatzweise mit beschäftigt und müsste mal schauen, wie es da mit FreeBSD-basierten Dingen wie pfSense/OPNSense und Freenas aussieht.
Viele Standardmodule in Ansible sind leider durch etliche "linux-ismen" auf UNIX-systemen (BSD und illumos) buggy oder schlicht kaputt. Da muss man eigene bzw modifizierte Module nutzen. Für die gängigen Dinge wie Paketverwaltung (pkg) oder Dienste (rc, OpenRC, SMF) gibts auch schon einiges in Ansible Galaxy was zumindest als Vorlage taugt. Mir steht auch noch das umbauen des OpenRC Moduls für unsere TrueOS clients bevor...
Da FreeBSD eine _wesentlich_ bessere Dateisystemhygiene betreibt als praktisch alle Linuxe (ausnahme evtl Alpine), ist das Arbeiten mit Configdateien deutlich vereinfacht. Hostkonfiguration ist mit /etc/rc.conf eigentlich komplett abgedeckt, ggf noch ein paar sysctl variablen in /boot/loader.conf, aber mehr auch nicht.
Konfigurationsdaten für Dienste in base liegen in /etc, alles andere in /usr/local/etc. Teilweise sind playbooks und/oder rollen mittlerweile nur noch halb so lang wie früher für die selben aufgaben auf debian/devuan systemen. Für secondary DNS server wird eigentlich nur ein git-repo nach /usr/local/etc gepullt und die Konfiguration ist fertig (weil nicht alles verstreut in /etc, /var/cache, /var/lib rumfliegt!).
Firewallkonfiguration (PF vs iptables) ist hier auch ein ziemlich extremer Fall - 80% der Firewallkonfiguration sind auf allen FWs in allen Standorten identisch. Zusammen mit der um Welten besseren lesbarkeit ist die FW-Verwaltung extrem erleichtert worden. pfSense würde ich mir aber nicht für automatisiert verwaltete systeme antun - das ist schon ziemlich weit entfernt von FreeBSD und die Konfigurationsschicht wurde komplett umgebaut. OPNsense ist hier wesentlich näher an vanilla-FreeBSD.

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

Re: Systemadministration: Dokumentation

Beitrag von heisenberg » 13.12.2017 17:48:39

@r4pt0r:

Vielen Dank für Deine interessanten Ausführungen.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

Re: Systemadministration: Dokumentation

Beitrag von ThorstenS » 13.12.2017 21:24:26

@bluestar:
Wie realisiert ihr das Pushen der etckeeper/git repos? Schiebt ihr alles in ein repo und jeder Server hat seinen eigenen branch¹, oder hat jeder Server ein eigenes remot-git repo²? An eurer config wäre ich interessiert.

Ich würde mir gerne die Änderungen der letzten X Tage von Server 1…n anschauen können. Das wäre sehr cool.

@r4pt0r:
Wir hatten das Thema ja schon vor einigen Monaten - echt klasse, wieviel Energie du da reinsteckst! :THX:

@heisenberg
Danke für den Thread! 8)
Ich benutze ebenfalls etckeeper/git (seit 73 Monaten und 5 Tagen, um exakt zu sein) und schaue gerne bei gemeinsam administrierten Servern in die git-Historie, aber auch in die unendlich lang eingestellte .bash_history, sowie die Loginhistorie (z.B. last -f /var/log/wtmp.5)
Das sind leider mehrere unterschiedliche Orte, an denen ich mir zusammensuchen muß, wer wann was gemacht hat. Aber besser so, als nix :mrgreen:

Ich schreibe mir auch ansible-Rollen für das ein oder andere und schicke mir hübsche farbige HTML-Mails z.B. mit dem Status der einzelnen Server zu (z.B. Servername, IP, OS, Releasestand). Die jinja2-Templates sind einfach unglaublich vielfältig nutzbar. ansible-cmd ist sehr geil und kostet keinen Aufwand.

Halt uns bitte auf dem Laufenden, was du wie umsetzt.
/thorsten

[1]
in etckeeper.conf PUSH_REMOTE="$SERVERNAME"

[2]
PUSH_REMOTE="origin"
git remote add origin git@HOSTNAME:SERVERNAME

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Systemadministration: Dokumentation

Beitrag von bluestar » 29.12.2017 10:44:34

ThorstenS hat geschrieben: ↑ zum Beitrag ↑
13.12.2017 21:24:26
@bluestar:
Wie realisiert ihr das Pushen der etckeeper/git repos? Schiebt ihr alles in ein repo und jeder Server hat seinen eigenen branch¹, oder hat jeder Server ein eigenes remot-git repo²? An eurer config wäre ich interessiert.
Bei uns hat jeder Server sein eigenes Remote-Git. Für die Übersicht/Historie nutzen wir Wiki-Seiten, die werden durch den post-receive Hook automatisch aktualisiert.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Systemadministration: Dokumentation

Beitrag von bluestar » 29.12.2017 10:48:49

heisenberg hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 16:45:30
... sondern warum wurde etwas gemacht?
Das lösen wir über ein Ticket System (Trac) mit Change-Requests-Tickets. Für die klassischen wiederkehrenden Arbeitsfälle gibt es Vorlagen für diese Tickets.
Die Verknüpfung erfolgt dahingehend, das wir in die Commit-Meldungen den jeweiligen Change-Request eintragen und darüber die Git-Historie mit den Requests verknüpfen.

Antworten