Re: [Debian]:Mit rsync Installationen synchronisieren?
Jens Benecke wrote:
hast du lust eine webseite zu dem thema zu machen ?
hier inhalt, ich kann zu allen punkten noch beliebig ins detail gehen.
grob planung:
- ein server, nfs
- viele client, lokale festplatte
- /opt, /usr, /home via nfs
multi tier platform:
- tier 1: das / des servers
- tier 2: /root/image als beinahe abbild der server /
- tier 3: / der clients als beinahe abbild des /root/image
die gemeinsamkeiten sind nicht so das problem (kann man ja mit rsync effektiv
erschlagen), das problem besteht vielmehr in "was muß unterschiedlich sein ?"
ich habe zwei script für den abgleich: server / -> /root/image und
/root/image -> client /, und für die gegenrichtung nochmal 2 diff
scripte, die mir unterschiede berichten.
beim abgleich gilt minimal prinzip: nur abgleiche, was 100% identisch
sein darf, beim diff gilt maximal prinzip: alles melden, es sei denn
ich bin ganz sicher, das diese dateien unterschiedlich sein dürfen.
die kompletten scripte kann ich gerne per mail schicken, möchte hier die
liste damit nicht belasten. die kurzversion: problem machen /var und /etc.
- /home, /opt, /usr sind nfs mounted. da rsync mit "-x" läuft, also
keine anderen filesysteme anfasst, solange kann nichts passieren.
- /tmp, /var/tmp, /var/run werden beim booten regelmässig geputzt,
brauchen also keine wartun. in ruhe lassen.
- /dev wird beim booten synchronisiert, noch befor logins erlaubt sind.
sobald logins erlaubt sind muß /dev in ruhe gelassen werden: beim login
wird der owner des terminals verändert, daran darf man nicht rumspielen.
also vor dem login säubern, und gut ist.
- /dev wenn man pts/ptmx benutzt, also unix 98 pty/tty master/slave terminal
devices gibt es das problem eh nicht, da das virtuelle /dev/pts filesystem
in ruhe gelassen wird (rsync -x flag, siehe oben).
- /var/log: syslog redirected auf den server, ansonsten laufen keine server
programme, also putze ich /var/log mit, ohne daten zu verlieren.
- /var/cache darf per definition geputzt werden wie man will, zumindest kein
programm darauf zugreift. ich repliziere ein /var/cache in dem unter-
verzeichnisse, aber keine dateien liegen.
- /var/state/misc existiert. aber welches programm braucht /var/state ?
trial & error ist angesagt.
- /var/spool wird ebenfalls geputzt. auf den clients gibts eh nur ein spool
verzeichnis: für tex. so überleben die fonts eben den reboot nicht, und
müssen jedesmal neu gerendert werden. macht nicht so viel.
- /var/lock muß existieren, soll leer sein, und ich habe eh kein programm,
das darauf zugreift: das verzeichnis wird von uucp, mgetty, minicom und
anderen programmen benutzt, die auf ein modem/serielle schnittstelle
zugreifen.
- /var/lib : hier hilft nur verzeichnis für verzeichnis einzeln behandeln.
dpkg fliegt bei mir weg (braucht man nicht auf den clients), mysql darf
nicht auf die clients (was wollen die mit den datenbank dateien), gnome
muß repliziert werden (debian menu -> gnome panel abbildung der menu
struktur). bid auf das gnome/ verzeichnis sind alle verzeichnisse bei mir
leer.
- /etc: ausnahmen sind /etc/hostname /etc/init.d/network /etc/mtab
/etc/pam_ntdom /etc/samba/*mac /etc/ssh/ssh_random_seed
mindestens diese dateien/verzeichnisse sind pro client und dürfen
nicht leichtfertig überschrieben werden.
- /boot: bei lilo muß man auf *.b aufpassen. aber lilo ist IMo unkompfortabel
und häßlich, ich ziehe da grub vor. lilo muß nach jeder änderung am
kernel neu gestartet werden, wenn der benutzer grade zwischendrinn das
system abwürgt, dann bootet die kiste nicht mehr.
grub ist da stabiler, der liest den kernel vom filesystem und braucht nur
ein update, wenn das menu file geändert wurde. wird er dabei unterbrochen
hat er im schlimsten fall noch das alte menu file. da grub das filesystem
lesen kann, ist das nicht schlimm, an alte/neue kernel kommt man nach
eingabe des admin passworts leicht ran.
> Oder ist es sinnvoller, auf jeder Installation einen Cronjob aufzusetzen,
> der alle X Minuten/Stunden auf einer FTP-Adresse nach neuen RPMs guckt und
> die ggf. installiert?
das würde ich sein lassen: was ist mit konfiguration ?
wer weis, ob die neuen rpm´s nicht fehlerhaft sind, und dir den rechner
zerschiessen.
> Wie gesagt, mir gehts nicht (nur) um die Installation, sondern darum, daß
> ich später nur _ein_ System warten muß, und sich alle automatisch
> synchronisieren.
jep, das mache ich, mit 80 clients. bei jedem boot aktualisieren die sich,
lediglich kernel und bootmenu brauchen einen zweiten reboot um zu wirken.
fast alle programme liegen auf dem server, das spart viel arbeit, und dank
lokalen / ohne /usr gibts nur wenig traffik, lokaler swap sorgt für
ausreichend speicher.
ich habe nun in 2 jahren recht viel ausprobiert und bin mit der aktuellen
lösung ganz zufrieden. andere ansätze wie zentrales nfsroot,
gemeinsames root und seltsame tricks um /etc/datei#host=foo# zu lesen,
und so manch anderes, all das hat es nicht gebracht.
insbesondere hilft das pull prinzip (client saugt neue informationen
im gegensatz zum push vom server) und das konsequent bei jedem reboot
nach dem aufräumen und initialisieren des systems (/tmp, /var/tmp,
swap, netzwerk ...) und befor server (ssh) oder login (console, gdm)
gestartet wird, dadurch hat man eine schnelle aktualisierung und
diese kann auf einem eindeutig definierten zustand aufsetzen.
da meine kisten dual boot windows/linux rechner sind, werden die dauernd
neu gebootet, also kein problem mit veralteter konfiguration.
die idee mit automatischer installation ist nett. nur nicht machbar.
zum beispiel das bescheuerte, buggy debconf versaut es, aber auch
vorher meinten viele packete in ihren *inst scripten auf ein
ENTER warten zu müssen - total sinnlos. die defaults von debian
sind auch oft derart daneben, das man diesen nicht vertrauen darf.
auch diverse automatismen machen sowas zunichte: wenn zwei packete
in verschiedener reihenfolge eingespielt werden, und jedes legt
dynamisch einen benutzer an, dann haben bekommen diese user verschiedene
user id´s. bei nfs muß man dann höllisch aufmerksam sein, wenn user id´s
verschieden sind.
ach ja zum user/passwort aktualisieren: ich habe früher nis benutzt,
dann ldap angetestet, bin jetzt aber zu /etc/passwd zurückgekehrt.
da die kisten eh beim booten aktualisiert werden, da können sie auch
/etc/passwd mitkopieren. die benutzer passwörter kommen eh per SMB
vom windows NT server, so das dies nur die admin passwörter betrifft.
mehr ?
andreas
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 736
Reply to: