On Fri, Oct 01, 1999 at 05:39:15PM +0200, [EMAIL PROTECTED] wrote: > > I have made most of the changed required for my redesign of diskless. > > Amazingly, it looks like no changed are required for dpkg. I haven't > > yet tested anything though, and implementing secure mode might be a bit > > awkward. Currently I am considering the following: > > > > 1 installation moves /var, /dev, and /tmp into /rw/ > > 2 symlinks are created: /var --> /rw/var, > > /dev --> /rw/dev, and > > /tmp --> /rw/tmp. > > > > On startup (non-secure mode) /var, /dev, and /tmp are mounted > > as usual, over the top of the directories under /rw/ > > > > (should I do the same thing for /etc too? I inclined not to > > - I think it should be read-only. Making /etc read-write > > might make adding extra hosts easier, as all host > > specific data can be copied and processed on startup) > > Do you support multiple clients? I would have a normal /etc that links > most files to /share/etc and some to /rw/etc (the host specific stuff > like hostname). /share would be on / and ro so its available on boot.
Yes. However, I don't use symlinks. Note: I think you may possibly have confused my two (current) modes of operation. You can either use diskless-image-secure*.deb or diskless-image-simple*.deb. diskless-image-simple*.deb: (for example - all directories on right have sample names) / is mounted from server:/var/sub/dir/root This directory is created with my diskless-newimage perl script. The computer boots. It checks that / is mounted readonly. If it is, then it assumes that it is not the master system, and continues: /etc is mounted from server:/var/sub/dir/$IP/etc where $IP is the IP address of the computer. This subdirectory must already exist, and is created with my diskless-newhost perl script. The /etc directory now contains the /etc/fstab file which is valid for the computer, and continues to boot as per normal. > > The result will be that /var, /dev, and /tmp are read-write, > > but completely refreshed every-time the computer boots. > > ??? What do you mean here? Why copy anything at all? How should the > filesystems be broken? Isnīt it the servers responsibility to keep > them working? Do I have to copy my 2 GB /rw partition to /copy and > then back over my 40KB/s plip link? Question: do you want to run NFS-Root over 40KB/s plip links? I am not being critical here, just curious. In this case, you would use the diskless-image-simple*.deb package. Files are only copied as the client requires them. However, while /etc can be exported read-only, /var, /dev, and /tmp have to be exported read/write. That would mean that somebody could break into the network/computer and wreck the image. Some people I have talked to would rather have all NFS exports read-only. Note: Currently, no files under /var are copied, only the directory structure. I am not yet sure if this will break anything (eg man-db) which requires index files under /var. I imagine copying the directory structure shouldn't take too long (not tested yet). The major problem is /dev which may contain lots of devices. > Try to install for an m68k/ppc/alpha diskless station on your i386. I > might test i386/m68k/alpha in any combination for server and client > if I find the diskspace for it. That would lead to difficulties. Mainly that I don't have a m68k/ppc/alpha ;-) So, while I could test "dpkg --root alpha_image alpha_file.deb", I don't think this is quite enough. PS: telnetd doesn't work on my NFS-root computer. After considering the matter, I realized the problem might be because devices on base2_1.tgz have group and other write permission disabled. This probably includes devices that manage /dev/pts. Could somebody tell my what devices (and other files) *must* have group and other write permission enabled? So far I have identified /dev/null /dev/zero and /tmp. Any reason why these are installed like this? Whats the best way to fix all the permissions (in one operation prefered)? -- Brian May <[EMAIL PROTECTED]>
