Fri, 20 May 2016 00:44:30 +0200 Jasper Valentijn <jasper.valent...@gmail.com> > OK, diskless(8), Example 7 states: > > Populate myclient's root filesystem on the server. How this is done depends > on the client architecture and the version of the OpenBSD distribution. It > can be as simple as copying and modifying the server's root filesystem, or > perhaps the files can be taken from the standard binary distribution. > > > > > In fact, with the current scheme, this is really the only way you > > should mount NFS clients. I mean, even though it's done with an > > atomic mv, I wouldn't really want my NFS clients re-ordering shared > > /usr/lib on reboot. > > Shouldn't each diskless client have a unique re-ordering independent of the > server?
Yes, preferably and recommended. This makes each machine unique in this respect, increasing resilience as intended with the mitigation. > Must an OpenBSD diskless client depend on myserver to reorder even > if it's not able? Think not running OpenBSD. There are many other write desirable operations on systems running with no local disk. In fact network booting can be combined with local disk. Memory file systems, and optionally some flash memory storage locally may come to the rescue for one time shuffling. Persist between reboots for entropy seed can be write mount on the server etc, you get the idea. This is a good ping to revisit the diskless(8) thanks for mentioning it. diskless - booting a system over the network [http://man.openbsd.org/diskless] > I read diskless(8) as: myclient must be OpenBSD and my server could be > OpenBSD. One valid real example in a heterogeneous operating system environment. Note: the above are not authoritative opinions of mine, not power talk.
