Congrats

[Henning Glawe]

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