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