some ideas

[Henning Glawe]

On Fri, May 10, 2002 at 11:06:25AM +0200, ranty-bulk at bigfoot.com wrote:
smae thoughts went to me, i've already done much work into this
direction which has been incorporated into FAI. Basic concept here is
the massive use of CVS; that way we can detect what has changed since
last time.
> - new task "polishing" runnable from a working system
> 	- all code run here should be idempotent.
most of stuff in 'subroutines' is already, but tested only with CVS...

> 		  Warnning: reconfiguring the network could be a problem in a
> 		  running system.
not really. if you take the -L and -P options for fcopy, connected with
postinst, then you can actually update a running system. the idea is to
transfer as much intelligence from 'scripts' to the fcopied config files
and their postinst scripts, so updates are done on much finer
granularity.
fcopy -l logs used classes for files to a logfile, which is used
together with the CVS output in option -P to detect changes in config
files to be copied. that way we minimalize the copying of files.

> - A task or class which updates the system via cfengine during the automatic
>   install, so the system gets just right and cfengine can be used from then
why use just another structure ? FAI is pretty much enough for keeping
all the config files. just use the follwing structure:
1) put _all_ your config files into a CVS repository, use this for
   installing the systems. fai copies the checked out version of the
   repository to /var/lib/config after installation for 'remebering' the
   'status' of an installed system.

2) update works _exactly_ like installing; fai copies /var/lib/config to
   /tmp, does a update via CVS there; log output is saved to
   /tmp/fai/cvs.log, which is used as input for fcopy -P later on.
   omitted is only the partitioniung and base.tgz install.

>   update and the server would keep track of the date of the last change of
>   each type. This way any client will know at any time which update it has to
no. clients themselves keep track of their status via CVS. if they are
switched off during push, an init script should check out the cvs for
tracking latest changes; if the update process is interrupted, the
following happens:
- logs are not saved
- the updated cvs is in /tmp/config, but _not_ copied to /lib/config

the system therefore assumes to have the status before the interrupted
update, i.e. complete update is done either at boottime (via init) or
via the next push request.

reinstall only should be needed, if the partition table is changed... i
suppopse this not to be done automtically ;)

> SECURITY:
> --------
> - when updating, the clients may poll for a push for increased security.
> 	- This way the server doesn't have to trust the client.
our update works via ssh:
on every client runs a second sshd, which accepts only root logins only
from our servers ip only with key authentication. as long as our server
isn't compromised, this should be pretty bullet proof, because the secret
key only lies there.

> - there could be some special service to get the logs to the server, instead
>   of full shell account.
i think this is not such a big problem, here our logsaver works via ssh
and the shell account is rather rightless...
btw: basically only scp is needed, perhaps if removing the 'rm' we 
could work with a 'lesser' account...

Though the concept is operational, there are quite a few things to do:
-modify install_packages so it keeps _exactly_ the needed tree
 installed, i.e. remove all other non-essential packages.
 
-I'm working on a small patch to fcopy, so it checks for the existence
 of the file to be copied prior to the -P change detector... so if
 purging a package removes the configuration files fcopy doesn't assume
 them to be there

-- 
c u
henning