Konfigurationsmanagement mit VAMOS, Subversion, SUE und Cfengine

Beschreibung von SUE/SVN

SUE Subversion Server

• es existiert ein SVN Repository, welches auf allen Hosts lokal ausgecheckt wird (wenn der Host für sue/svn konfiguriert ist)

• Features können nach und nach durch Erstellen eines Files $TFEAT/<feature>/svn umgestellt werden

  • es ist daran zu denken, dass das Repo, alle Utilities und Module auch im SVN verfügbar sein müssen
• der Subversion Server läuft auf znrepo (mit SL6)
• Repository findet man unter /var/svn/suecf
• Zugang zum Repo

  • entweder über User/Passwort https://znrepo.ifh.de/suecf/

    • read/only Access für Hosts (/usr/sue/etc/suecf-svn.cfg)
    • Konfiguration svn: /var/svn/accfile

  • oder mit Kerberos-Authentisierung https://znrepo.ifh.de/svn

    • read/write Access für Admins und für Installationsserver(pallas) mit registry-Ticket
    • Konfiguration svn: /var/svn/accfilekerb (enthält alle Pricipals, die Änderungen vornehmen dürfen)
• der Subversion Server wird durch das Feature svn konfiguriert

Konfiguration der Host Systeme

• einige Scripte unter /products/sue/etc/ können nach der Umstellung nicht mehr benutzt werden und rufen automatisch die neuen Scripte aus dem RPM DZ_sue
• die sue-svn Scripte befinden sich in /usr/sue/sbin, keine Links ins AFS mehr, (rpm DZ_sue)
• /usr/sue/sbin/sue.update

  • neue Option -e(env) <path> : es ist möglich, Variablen aus /usr/sue/var/env.pl zu überschreiben

  • es wird im noaction und verbose Modus informiert, welches Feature gerade abgearbeitet wird
• /usr/sue/sbin/sue.checkout [-h] wird zum Auschecken verwendet, Pfad: /var/cache/suecf/repo
• /usr/sue/sbin/sue.bootstrap
  • erzeugt alle Links unter /usr/sue/etc/ für die Konfiguration der Features und ruft /usr/sue/sbin/mkconf

/usr/sue/sbin/sue.bootstrap -h
usage:
        -d|-v     set debug mode
        -w        use web client, overriding "clever" autodetection
                  only allowed without option 'H' and 'P'
        -h        show usage
        -H <host> run sue.bootstrap for an other host (installation,no all checks),
                  not in combination with option 'w'
        -P <path> generating sue env for an other host in this working directory,
                  mandatory for option 'H'
        -f <dir>  to test a feature on a host (maybe before putting the code into svn),
                  i.e. -f /tmp/sudo; /tmp/sudo is the complete dir tree for this feature,
                                     /tmp/sudo/cf.sudo has to exist,
                                     the subdir name has to correspond with the feature name
        -F <feature>:<dir>  to test a feature on a host (maybe before putting the code into svn),
                  examples: -F sudo:/tmp/test; /tmp/test/feature/sudo and /tmp/test/archive/sudo have to exist
                            -F group:/afs/.ifh.de/common/installation/test 
                  -F overwrites -f 

• die Option -H und -P wird vom Installationsserver verwendet (ai)
• Option -w kann auch in der Initialisierungsphase verwendet werden (SL6 Installationsprozedur)

• /usr/sue/sbin/mkconf generiert /usr/sue/var/env.pl
• /usr/sue/sbin/check_status überprüft Netwerk und ob znrepo verfügbar ist
• /usr/sue/sbin/set_status ist ein Link auf check_status und wird verwendet, um nach fehlgeschlagenem Checkout oder Sue-Run den Zustand zu melden, aber weitere Mails zu verhindern
• es gibt jetzt nur noch ein Script, welches beim Booten, für den Full- oder Updates Modus gestartet wird: /usr/sue/sbin/sue.run

/usr/sue/sbin/sue.run -h 
  check network connection and the availability of the svn server,
  runs 'svn checkout; sue.bootstrap' and then sue.run with the given mode
  informs 'scout-linux' in case of problems
Usage:
        -d      set debug mode, no delay
        -v      set verbose mode (more cfengine output), no delay
        -n      set noaction mode, implied debug mode 
        -s      skip sue.bootstrap
        -m <mode>       set mode: full,boot,update or now(default)
                nightly run in 'full' mode with delay
                run in 'boot' mode without delay
                daily run in 'update' mode for requested features ( by vamos workflow )
                run in 'now' mode without delay for given features
                  in future: 
                  daily run can switch to full mode with
                  touchfeatures -F ALL ...
        -h      show usage

• sue.run
  • während des Bootens darf sue.run nur im "boot" Modus laufen
  • Statuscheck
  • Check, ob /etc/nosue existiert
  • Delay ermitteln
  • SVN Checkout

  • Ermittlung der Features, die abzuarbeiten sind (über Webservice von configsrv)

  • Abarbeitung der Features

Umstellung auf SUE/SVN Umgebung auf einem Linux Host

• alle SL5 und SL6 sind umgestellt

  • feature aaasue installiert /usr/sue/etc/suecf-svn.cfg (user/passwort für svs) vom cfengine server

    • (nur gebraucht bei vorhandenen Installationen, sonst über ai verteilt)
  • feature sue wird nicht mehr verwendet

  • rpm DZ_sue stattdessen

  • Bootscript /etc/init.d/sue_boot startet /usr/sue/sbin/sue.run -m boot

FAQ zu SUE/Cfengine

• Liste der konfigurierten Features

  • /usr/sue/sbin/sue.bootstrap generiert Liste/Verzeichnis

  • Anzeige mit /usr/sue/sbin/sue.update --list

Updates per Cron-Jobs

tagsüber nur per workflow angestoßene Features (6-23 Uhr alle 10 Minuten)

• cron job: /usr/sue/sbin/sue.run -m update

  • läuft nur, wenn service sue_boot status ein OK zurückmeldet

• das sind z.Z.: hosts,netgroups,passwd,klogin,ssh

• oder manuell aktivierte Features per activate [-h] auf SL5/SL6:

   /usr/sue/sbin/activate -F list_of_features [-H list_of_hosts] [-N list_of_netgroups]

• nach der Abfrage der ToDo-Liste wird diese auf dem configsrv gelöscht

• Beispiele:

   activate -F scout,sudo -N linux-server
   activate -F ANY -H mydesk              # alle Features, die standardmäßig laufen, der Test erfolgt erst auf dem Client
   activate -F nagios -H ANY

• auf SL4 und Solaris funktionieren die alten sue Scripten und das /products/sue/etc/touchfeatures kann verwendet werden

Vollständiger Lauf (ab 3 Uhr mit Verzögerung)

• cron job: /usr/sue/sbin/sue.run -m full

Nutzung von SVN

Erste Benutzung von SUE/SVN

• Zugangsberechtigung: ~TARCH/svn/ServerSUE/var/svn/accfilekerb

• auschecken: svn co https://znrepo.ifh.de/svn [ <meinrepository> ]

Einchecken neuer Features

• auschecken

• einchecken von ~TFEAT/<feature>, ~PFEAT/<feature>, ~TARCH/<feature>, ~PARCH/<feature>

  • Kopieren der neuen Verzeichnisse ins eigene Repo und notwendige Anpassungsarbeiten durchführen
    • bitte vorher nach Möglichkeit aufräumen

  • dann mit svn add <meinrepository>/... die Verzeichnisse hinzufügen

  • auch prüfen: cfengine Module, utils aktualisieren

  • svn commit <meinrepository> -m 'Kommentar'

• Testen und Umstellen auf SVN: mehrere Möglichkeiten:
  • 1) man kann das private ausgecheckte Repository zum Testen verwenden, Beispiel:

    • touch /etc/nosue

    • /usr/sue/sbin/sue.bootstrap -F passwd:/afs/ifh.de/user/z/znawn/computing/svn/repo/test -d

    • jetzt verwendet sue.update den angegebenen Baum : /usr/sue/sbin/sue.update -n [-v] passwd

    • nach Beenden der Tests /usr/sue/sbin/sue.bootstrap;rm /etc/nosue

    • touch ~TFEAT/<feature>/svn

    2)

    • das feature auf noautotest stellen

    • touch ~TFEAT/<feature>/svn

    • auf einem Host, der umgestellt wurde, prüfen:

          /usr/sue/sbin/sue.checkout
          /usr/sue/sbin/sue.bootstrap
          /usr/sue/sbin/sue.update -n [-v] <feature>

    3)
    • nach sue.checkout und sue.bootstrap kann man einzelne Variablen für Tests auf einem Host ändern
    • Beispiel: Repository für feature klogin auf SVN Repo umdefiniert

          # Syntax wie /usr/sue/var/env.pl
          cat /tmp/env.pl
          $ENV{"CF_PREFIX_KLOGIN"}='/var/cache/suecf/repo/test';
      
          # Option -e erlaubt Überschreiben/Setzen von Variablen aus /usr/sue/var/env.pl    
          /usr/sue/sbin/sue.update -n -e /tmp/env.pl [-v] <feature>

    • nach notwendigen Anpassungen touch ~TFEAT/<feature>/svn

• bei Features, deren Repo vom Vamos Workflow aktualisiert wird, muß auch dafür gesorgt werden, dass SVN Repo aktualisiert wird. Das Feature host wurde bereits umgestellt, siehe /afs/ifh.de/project/VAMOS/prod/conf/workflow-config. Das Script svn_commit checkt die Änderungen ein.

  • auf pallas als root kinit -k registry; cd /var/site/vamos; svn co https://znrepo.ifh.de/svn repo

  • unter dem Baum /var/site/vamos/repo Änderungen vom Workflow einpflegen lassen

Liste der Features und Status

Änderungen an Features, die schon im SVN verwaltet werden

• auschecken

• Änderungen mit svn commit <meinrepository> -m 'last modified ' einchecken

FAQ

• Warum kann ich keine Files ...@<datum> löschen mit svn del ...?

  • Weil in @<datum> das Datum als Revision gedeutet wird und da diese Revision nicht existiert, wird angenommen, man will die aktuelle löschen und gelöscht wird das aktuelle File .

  • Mit ' svn del ...@<datum>@ ' kann man solche Files löschen.

• Wie kann man vermeiden, dass .svn Verzeichnisse beachtet werden?

  • Folgendes ins feature einbauen:

    •        ignore:
                     any::
                       .svn

• Wie kann man das execution Bit von Files im SVN setzen?

  •        svn propset svn:executable ON somescript
           svn commit   -m 'comment'

• zurückgehen auf ältere Versionen:
  • Infos zu Änderungen

    •      svn log repo/test/archive/rlogsurf/RLoghost/etc/logsurfer/kern.conf

  • Änderungen aufzeigen

    •      svn diff -r 212:218 repo/test/archive/rlogsurf/RLoghost/etc/logsurfer/kern.conf

  • Auschecken älterer Revisions

    •      svn co -r 212 https://znrepo.ifh.de/svn/test/archive/rlogsurf/RLoghost/etc/logsurfer/