Konfigurationsmanagement (was: Infrastruktur - Konkrete Schritte + Adminsuche)

[Marc Haber <mh+uugrn@xxxxxxxxxxxx>]

On Thu, Nov 14, 2019 at 12:49:41PM +0000, Philipp Schafft wrote:
> On Thu, 2019-11-14 at 13:12 +0100, Marc Haber wrote:
> > Wenn Konfigurationsdateien aus einem Ansible erzeugt werden macht das
> > exakt keinen Unterschied zu einem handgekloeppelten System. Man macht
> > einfach den zgansible-Account zu und die Maschine ist sauber.
> 
> Solange das hinreichend gut Dokumentiert ist. Es geht mir einfach darum,
> dass wenn ein wechsle stattfindet nicht ploetzlich Aenderungen
> verschwinden, da diese von irgendwoher ueberschrieben werden.

Auf meinen Systemen steht (Fehler ausgenommen) in der ersten oder
zweiten Zeile eines Files explizit drin, dass es ansiblisiert ist:

|[5/4991]mh@torres:~ $ cat /etc/logrotate.d/rsyslog
|# this file is managed by ansible
|
|/var/log/syslog/syslog
|{
|        rotate 30
|        size 6M
|        missingok
|        notifempty
|        delaycompress
|        compress
|        nomail
|        postrotate
|                /usr/lib/rsyslog/rsyslog-rotate
|        endscript
|}
|
|/var/log/syslog/auth.log
|{
|        rotate 30
|        size 6M
|        missingok
|        notifempty
|        compress
|        nomail
|        delaycompress
|        sharedscripts
|        postrotate
|                /usr/lib/rsyslog/rsyslog-rotate
|        endscript
|}
|
|[6/4992]mh@torres:~ $ 

|[6/4992]mh@torres:~ $ /etc/update-motd.d/70-ansible 
|
|This host is managed with ansible. Last ansible run on 2019-11-01 20:39
|  by mh from drop.zugschlus.de
|  git repo ssh://git.zugschlus.de/~/git/zgdebansible commit 85b22ce
|[7/4993]mh@torres:~ $ 


Lokale Aenderungen, die durch $TOOL womoeglich automatisiert regelmaessig
ueberschrieben werden hasse ich seit SuSEconfig 1998.

Auch bei handgekloeppelten Systemen kann ein Co-Admin von einem hirntoten
Kollegen ueberschrieben werden.

> Die Frage an der stelle ist auch, wie es sich verhaellt mit Admin B
> uebernimmt mal kurz weil Admin A gerade nicht greifbar ist (man denke
> etwa an Urlaub). Das ist vielleicht generell eine interessante Frage.

Dann macht Admin B etwas und wenn es eine Aenderung in einem
ansibilisierten File war, wird die von Admin A definierte "Wahrheit"
beim naechsten Ansible run wieder hergestellt. Admin B ist somit gut
beratn, wenn er Admin A ueber die Aenderung informiert. Das kann durch ein
git add, git commit, git push geschehen oder in dem Fall, dass Admin B
nicht in das git schreiben darf, weil er z.B. kein "offizieller" Admin
des Systems ist.

sdk, wir braeuchten dann noch eine mehrheitsfaehige Loesung, wie man
Notfallcredentials interlegt, falls der Admin des Systems unerwartet
ausfaellt. Auf den VMs wuerde vermutlich "reboot to rescue und dann
einbrechen" ausreichend sein, aber schoen ist anders.

> > Fuer Beschaeftigungstherapie habe ich keine Zeit, wenn ich fuer den Verein
> > etwas tue muss es mit meiner Zeit ruecksichtsvoll umgehen. Die Nutzung
> > bereits vorhandener Zeitsparmechanismen gehoert dazu.
> 
> Natuerlich muss man effizient arbeiten. Dennoch sind hier zwei Dinge
> wichtig:
>       * Den Zielen dem diese ganze Aktion folgt auch folgen: Sprich
>         single-point-of-failures abbauen.
>       * Eine gewisse Transparenz halten. Nicht nur zu Administration
>         (s.o.) und Meta-Administration (Dinge die auf Vorstandsebene
>         oder MVebene passieren) Zwecken, sondern auch unter dem Gedanken
>         das auf diesen Systemen private Daten liegen.

Das hat mit der Art und Weise, wie Konfigurationsdaten bearbeitet
werden, kaum etwas zu tun. Bei zentraleren Systemen mit Agenten wie
puppet z.B. muss man sich da etwas mehr Gedanken machen, ja.

Das Angebot, die zwei Dienste zu administrieren gilt, wenn ich es so
machen darf wie ich es fuer richtig halte. Wenn da jemand was dagegen
hat, mach ich es halt nicht. Also im Sinne von "gar nicht".

> Ich bin hier gegen keine Loesung oder so. Sondern ich habe eine Frage
> gestellt zu Anfang. Und auch genau das ist meine Intention:
> Wissen was du dir darunter vorstellst und was das bedeutet.

Genau diese Rechtfertigungen sind aber m.E. im aktuellen Konzept nicht
(mehr) vorgesehen, deswegen auch der Ansatz mit voneinander unabhaengigen
VMs.

Natuerlich ist es sinnvoll, derartiges Konfigurationsmaagement irgendwann
mal fuer alle UUGRN-Maschinen anzubieten. ansible finde ich allerdings
u.a. wegen der unterirdischen Arbeitsgeschwindigkeit eigentlich nicht
fuer geeignet, das ist auch "bei mir" schon ein Auslaufmodell.

Gruesse
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/