On Sat, Aug 28, 2004 at 02:47:48PM +0200, Michael Tautschnig wrote: > >The version (forked around 2.3; some things are backported from FAI HEAD, > >some others got merged into FAI) currently used in my faculty can be found > >at > >http://www.physik.fu-berlin.de/~glaweh/fai/ > > Is there any documentation describing the changes? What is needed to make
That's the weak point (meanwhile for a really long time). I started to document some of my patches in the FAI Manual Chapter "Advanced FAI", though I got not further than describing the cvs support... > changes using your scripts? reboot? Or can it be done while users are > logged in? I installed a kind of "backdoor" on every client: a second SSHD allowing only root logins using a key-based login. Something like "clusterssh" already existed in my department for a long time, and so I used this to connect to the client's backdoor-sshd and run the command fai-update-system, which is basically a modified version of rcS_fai accepting some command line options and running a action_task faiupdate. That in turn is a variant of then standard installation, skipping the basic system setup (like vt creation and starting of sshd etc.) and of cause the partitioning, fs creation and base unpacking steps. I moved most of my $FAI/scripts/* to $FAI/files/*/*/postinst and use a recursive fcopy prior to task_config to copy the conffiles only when needed (for this I patched fcopy with a rather ugly cvs-update-detection-mechanism already merged into FAI and _even_ documented in the fcopy manpage ;) ). It is really important to check what you are doing/have to do in your files/*/postinst or scripts/* scripts, because most daemons need to be signaled that their config has changed, and you _really_ don't want running daemons when first-time installing a client. In my scripts, deciding whether an update or a fresh installation is running is done by checking if the environment variable $target points to "/" or not: if it is, we are updating a currently running system. Updates are done at any time an administrator (such as me and my co-workers) wants, users dont have to log out for normal updates; only changes in the bootloader configuration and/or kernel updates need of cause a reboot. This is automatically done by a small background process automatically run in those cases: this process (fai-reboot-thread) waits to the end of the last non-system process and interactive login and reboots the machine. To avoid hanging processes blocking the system reboot, an independend little daemon kills any non-interactive processes (user not logged in, no tty allocated) based on a blacklist of famous-hangers (netscape4 ... yukk) Unsolved problems so far: - Documentation !! - Porting to FAI HEAD - using cvs as config server has its limitations: even for read-only checkouts the pserver uses locks, so when updating many machines at the same time they block each other in the first phase (when updating the local config space copy) - Bandwidth: when updating too many machines at the same time, the apt-get processes flood the network... (anyone seen 100 computers updating monster-packages like openoffice or mathematica at the same time ? ;) ) - conffile updating is not ideal due to my ugly cvs-update-detection mechanism... -- c u henning
