Hello,
For some time now, I have been working on diskless NFS
systems (on and off).
I started off with using NFS-root, but wasn't particularly
happy with it (it seemed to specific to the authors setup),
so I created my own package, diskless.
While this package fixes a number of issues that I was concerned
with at the time, I am still not really happy with my solution.
It seems way to complicated, and makes using mail-transport-agents,
like ssmtp nearly impossible, especially when /usr is shared
between the server and clients.
So - I plan to completely redesign the current structure. This
is my ideal structure. Some tasks may not be possible without
changing the structure of deb control files. This may be
difficult... This change will not be a high priority - ie nothing
urgent.
In short: master client is responsible for maintaining (installing and
removing) packages using dpkg. dpkg modifies class A and class D files
(only one set per entire group). {post,pre}{rm,inst} scripts operate on
class A and class D files like normal. Class D files are interpreted
using M4 and copied for each client, either on the NFS server (faster), or
when the client boots (more secure).
In long form, my proposed changes:
1. force /usr to not be shared with the server. This would require
more disk space, but would allow /usr to be different. I think
this is a requirement, for programs like ssmtp.
2. create 2 different categories of files:
A) shared by entire group - should be read-only. ie
/usr /etc /bin /boot /dev /lib /root /sbin and mount points.
B) specific to individual host - can be read-only, but read-write
copy may be created, if required, when host boots. ie
/etc /dev /tmp /var
note:
- that /etc and /dev are included in both lists.
- this is similar to what I already have, except
/usr[1] is in another category of its own, class C.
- need someway to start a nfsroot system. Possibly could use base.tgz
(if thats the name), from the boot disks section for this purpose.
3. master system, is no longer the NFS-server, but a client
with special privileges. (hopefully, this can also
run on the NFS server, if required, eg in chroot environment).
This should have read/write access to the group files.
4. system administrator installs software, using dpkg, on the master
system, which will "magically appear" on the other systems.
class A files just get copied straight to the group directory.
class B files, on the other hand have to somehow be copied
for every NFS-root client. Maybe someone can tell me how this
could be done efficiently. However, I dislike it. so...
my solution is #5.
5. Only *one* read-only copy of class B files to be kept on the server.
Call this class D[1]. These files are interpreted (using m4) and copied
(where?) to a class B area when the client boots. Or perhaps, a script
can be executed on the server that copies everything at once for every
host. The m4 script language will substitute IP address, host address,
etc, as required for the different hosts.
6. I would really like support for preinst, postinst, prerm, and
prerm scripts. This would mean the system administrator
doesn't have to do any configuration that wasn't required
before (in theory). However, to list the minor problems first:
- preinst (I believe) is run before the installation. It
would modify class A and class D files. Class D files
would eventually be copied to class B for each client (see 5).
- the other scripts would be similar.
- scripts would only run once for all clients. For
instance, this would affect ssh, as the private host
key would become the same for all diskless clients. I don't
consider this to be a problem.
Now the more serious problems. I think I can solve all the problems
above. It is the problems below that concern me the most.
- these scripts may make assumptions based on the IP address
and host-name of the current computer, and may not even allow
the administrator to enter to the M4 token that will be substituted
with the proper value for every host.
- where should I put class D files? I could have the class D files in
the same directory structure as the class A files. This would make
executing {post,pre}{inst,rm} files easy (no change). The class D
files would be copied to a separate class B mount point as required
(either by the server or the client).
However, this wont work. /dev and /etc are required on boot, and
separate copies must be obtained for class A and class D. Files in
class D are not accessible until after the computer boots.
If devfs was supported by the kernel, it would solve the /dev part
of the problem, but not /etc. Perhaps I could also eliminate the
need for /etc on boot. The only really important file I see there is
resolv.conf. This would raise a few other minor issues. The client
would see the class D files on boot. These are not meant to be seen
by the client (they are meant to be preprocessed by M4). Would this
upset anything?
- if class D files are not contained within the class A files,
then dpkg and {post,pre}{inst,rm} scripts may be confused. Perhaps
symlinks could somehow be used. Perhaps I could invoke
dpkg within a chroot environment that pointed to a directory
with symlinks to the class A and D directories. This would
be the most flexible method.
Any ideas, suggestions, anything else?
If anybody has any problems understanding any of this, I
will try to expand on what I have said.
there are probably more issues that I haven't thought of yet.
Footnote: [1] I skipped class C on purpose. If I want to
refer to the separate category currently set aside for /usr,
I will call it class C.
--
Brian May <bam@snoopy.apana.org.au>
Attachment:
pgpNOcVKwjZZw.pgp
Description: PGP signature