Konfigurationsmanagement (was: Infrastruktur - Konkrete Schritte + Adminsuche)

From: Marc Haber <mh+uugrn_at_zugschlus.de>
Date: Thu, 14 Nov 2019 14:20:26 +0100
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 handgeklöppelten 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 plötzlich 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_at_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_at_torres:~ $ 

|[6/4992]mh_at_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_at_torres:~ $ 


Lokale Änderungen, die durch $TOOL womöglich automatisiert regelmäßig
überschrieben werden hasse ich seit SuSEconfig 1998.

Auch bei handgeklöppelten Systemen kann ein Co-Admin von einem hirntoten
Kollegen überschrieben 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 Änderung in einem
ansibilisierten File war, wird die von Admin A definierte "Wahrheit"
beim nächsten Ansible run wieder hergestellt. Admin B ist somit gut
beratn, wenn er Admin A über die Änderung 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 bräuchten dann noch eine mehrheitsfähige Lösung, wie man
Notfallcredentials interlegt, falls der Admin des Systems unerwartet
ausfällt. Auf den VMs würde vermutlich "reboot to rescue und dann
einbrechen" ausreichend sein, aber schön ist anders.

> > Für Beschäftigungstherapie habe ich keine Zeit, wenn ich für den Verein
> > etwas tue muss es mit meiner Zeit rücksichtsvoll umgehen. Die Nutzung
> > bereits vorhandener Zeitsparmechanismen gehört 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 für 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 unabhängigen
VMs.

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

Grüße
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/
Received on 14.11.2019

This archive was generated by hypermail 2.3.0 : 14.11.2019 CET