|
Size: 9893
Comment:
|
Size: 10523
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 126: | Line 126: |
| * das feature auf ''noautotest'' stellen * touch ~TFEAT/<feature>/svn * auf einem Host, der umgestellt wurde, prüfen: {{{ |
* Testen und Umstellen auf SVN: 2 Möglichkeiten: 1) * das feature auf ''noautotest'' stellen * touch ~TFEAT/<feature>/svn * auf einem Host, der umgestellt wurde, prüfen: {{{ |
| Line 133: | Line 134: |
| }}} | }}} 2) * 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'' |
Konfigurationsmanagement mit VAMOS, Subversion, SUE und Cfengine
Contents
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'- 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
svn commit <meinrepository> -m 'Kommentar'
- Kopieren der neuen Verzeichnisse ins eigene Repo und notwendige Anpassungsarbeiten durchführen
- Testen und Umstellen auf SVN: 2 Möglichkeiten:
1) * 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>
- 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
feature |
SL |
Status |
Kommentare |
aaru |
5,6 |
todo |
|
afs_client |
5,6 |
done |
|
arcx |
5,6 |
todo |
|
atlas |
5 |
todo |
|
automount |
5,6 |
done |
|
cfengine |
5,6 |
done |
|
conmgr |
5 |
todo |
|
cups |
5,6 |
done |
|
ganglia |
5 |
todo |
|
gdm |
5 |
todo |
|
group |
5,6 |
done |
|
hosts |
5,6 |
done |
|
httpd |
5,6 |
done |
|
kerberos |
5,6 |
todo |
|
kernel |
5,6 |
todo |
|
klogin |
5,6 |
todo |
|
ldap |
5 |
todo |
|
linux |
5,6 |
todo |
|
motd |
5,6 |
todo |
|
nagios |
5,6 |
done |
|
name_srv |
5,6 |
done |
|
netgroup |
5,6 |
todo |
|
nsswitch |
5,6 |
todo |
|
pam |
5,6 |
todo |
|
passwd |
5,6 |
todo |
|
passwd_prog |
5,6 |
todo |
|
products |
5 |
todo |
|
reg_notebooks |
5,6 |
done |
radius server, ... |
scout |
5,6 |
done |
|
security |
5,6 |
todo |
|
ssh |
5,6 |
todo |
|
sudo |
5,6 |
todo |
|
syslog |
5,6 |
done |
|
tcp_wrapper |
5,6 |
todo |
|
tidy_up |
5,6 |
todo |
|
trusted |
5,6 |
todo |
|
vamos |
5,6 |
todo |
|
xntp |
5,6 |
todo |
|
zzz |
5,6 |
todo |
|
Ä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
- Folgendes ins feature einbauen:
- 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/
- Infos zu Änderungen