[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Redesign of diskless NFS-root package


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

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

   - 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

Reply to: