Re: Diskless boot NFS server image
Andreas Jellinghaus wrote:
>> My packages only writes to files under /var/lib/diskless. It also creates
>> symlinks under /tftpboot.
>
>i hope /tftpboot isn't necessary unless the kernel is tftp booted.
>that directory doesn't look nice in a fsstnd/fhs system.
I think the best solution is to only create symlinks in /tftpboot,
if /tftpboot already exists. This will be fixed in the next version.
Also, I will fix the hardcoded reference to /ftpboot/home in the
/ftpboot/ftp sample fstab files (I might make this a config option,
I am not sure yet).
>> Everything I have done is done at the server, hence there is no need
>> to use ssh. A record is kept of all files copied, and if the file
>> already exists and hasn't changed since the last copy, it is
>> not copied again. (This excludes devices, currently devices are always
>> considered the same if they exist).
>> I am not sure if this addresses your concern...
>
>if you don't have a full copy (e.g. shared /usr), you can alway be trapped.
>for example the new version of program xyz has a different config file
>(incompatible with the old). so in the time gap between your server (/usr)
>update and your clients /etc update can cause misfunctions. of course it's
>easy to you to minimize this time gap, since everything is on the same machine
>.
This is a problem, but no matter what you do, I think there always will be
problems... Opinions anyone?
I think my program handles updating files correctly (ie it
moves the old file on top of the new one) to allow concurrent use, but
this doesn't solve the above problem.
Of course, you could keep a seperate /usr, maybe one for each group,
but this would use heaps of extra disk space, and might still break
during big updates. It would be easy for me to make this another
config option, however I don't think it is worth it...
>also, keep in mind that some packages "do magic" in the post/pre-rm/inst
>scripts, for example konvert old style config files to new style. this
>is not done on your client /etc. you can fix this with syncroniozing everythin
>g
>(with a logn exception list).
Some programs are still very awkward, eg
ssh - creates a private key for the host in /etc/ssh
fdutils - configures floppy disks devices depending on how many floppy
disks are installed, currently my program copies all devices
from the master system, so if the master only has one disk
drive, you want get the newer devices for other drives.
xcdroast - creates devices, too, but this is OK, as all changes
propagate to all hosts.
probably others too
Ideally, it should be possible to somehow support diskless systems
directly into dpkg, however this is beyond the scope of my efforts.
>as usual any situation with shareing filesystems via nfs is a security problem
>(nightmare filesystem...). It's possible to limit this (/usr partition, export
>ed
>readonly - /usr doesn't contain security sensitive data and read-only exportin
>g
>fixes this). But the whole nfs problem is too big for us. maybe some day someo
>ne
>will write something better...
Agreed!
>The key problem is that administrating several machines isn't easy, and every
>software increses the komplexity a bit. So you need either very good
>dokumentation or a very easy to understand mechanism. I have to admit that
>i don't understand much of diskless-0.0.1, and i don't have the time for
>reading source now.
If I haven't documented anything adequately, then please let me know.
>for now i will stik to my 3 script combination, as it fits my setup for now
>(one to run on the client after any update (to call lilo, kill some app,
>call init or whatever), one to update the client via rsync (and call the first
>script in the end), and one script as daemon to look for newly booted clients
>and update them)).
>
>please keep me up to date with your development.
Ok.
>note: i noticed that one of your scripts "exec /sbin/init". is this now
>possible ? some time ago it was not possible (init only worked, if it's
>pid was 0).
(Correction: I think you meant pid 1)
You gave me a fright for a moment then! That is something I hadn't
even considered...
However, on my system it seems that exec keeps the same PID, and
I suspect that this is standard behaviour. Please correct me if I am
wrong...
The PID of init on my master system == 1 == PID of init on my diskless client.
Brian May <bam@snoopy.apana.org.au>
Reply to: