On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote:
Hi,
To be clear, a read-only root would not be the only possible config, it's a specific deployment methodology.
On Thu, 2004-04-01 at 05:54, Dave Jones wrote:
On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote:
A possibly related discussion; we've been wondering if we can make the OS image read-only (mounting it that way, or via selinux).
If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again.
The whole point is to never run apt/yum/up2date/rpm on individual machines, only on a central image ;-)
Ah.. the problem for us has come that we need a ton of diskless systems, but that many have to run different configurations that are out of step from a central image. I had hoped this would be the exception rather than the rule, but it has become more of the rule than anyone expected (and seems to be the rule at other similar organizations.)
The issue comes down to that we need to have 1-2 central servers per network for auditing purposes. The diskless clients may need to run different versions/packages of RHL/Fed/etc off of that diskless server. The current hacks look to be about 5-20 different ways of solving the same problem :).
Avoid per-system state that can be configured incorrectly, haX0rd, gotten out of sync.
One of the things, we have found is that the only way to maintain this when the central box is updated is to kill all the diskless clients, remove their per-system areas (/etc,/dev,/lib,/initrd) and then have them all rebuild themselves a new set of images on reboot. The problem is that 200+ systems doing UDP NFSv2 at nearly the same time kills the linux NFS server.
Then have /tmp and probably /var in RAM (or wiped on boot)
Errr, if /var/log disappeared, I'd be very annoyed.
Log to a server for example.
I am guessing for this configuration that would be the best way. You would need to make sure that for some systems that they could log to multiple log servers at the same time so that they can be independantly audited.
Ditto /var/spool.
IMAP and remote smtp server, or something along those lines. Print servers.
You could have "writable /var" as a possible configuration, too.
You can get away with most of that except when the CxO box dies while an email was being sent and its gone. Murphy seems to strike on this one more than statistically should be possible...
This allows you to maintain the OS image in a central location and the homedirs and server/app data in central locations, and have a single network-wide master copy of all important state.
This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it.
If we can't handle laptops this is still useful for server and thin-client-desktop type setups
The way to do laptops though is that the RW master image of homedir is on the laptop, and the laptop keeps a local RO cache of the OS image.
On connection to network, you sync the homedir from laptop to network, and sync the OS image from network to laptop.
The best way to get this to scale I have seen of doing this is either using 'other filesystems' than NFS or scripts like rsync. The reason is that a couple of the solutions I have seen work with 1-4 laptops but dont scale beyond that. The 'cool' version I saw was a hacked version of rsync that did something like asyncrynous updates. [Whats newer on each system, and according to config rules overwrite usually to the newer version.] The other version was one that would partition the laptop disk into 'mirrors' of itself.
/boot -- 1 I think /1 /2 /home -- 1 I think
boot is set up to boot into say /1 the first time, and then the asyncd updates /2 to whatever the network says it should be. Grub is changed appropriately, and a root message is sent to an applet on the desktop saying updates have been done, please reboot to get to the new configuration. Reboot then starts up by default into /2 and if the user is ok with it via the applet, then /1 can be updated to mirror /2. If not then the user can reboot back into /1 and contact their sysadmin about the problems. [Audits can also be set up to let the central administration which boxes are running old copies in case the user doesnt tell the sysadmins].
/home is backed up in the background to a central server in a similar method.
Or something, this isn't a mature idea, just a discussion that's come up.
Let me know if I can help any..
Havoc