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 [EMAIL PROTECTED] die im Body "unsubscribe debian-user-de <deine emailadresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ------------------------------------------------ Anzahl der eingetragenen Mitglieder: 736