Future: fhs 2.3 compliance for fc3

[Stephen Smoogen]

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
-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --