 | | | Diskless cluster and up2date | Diskless cluster and up2date 2004-02-27 - By Stephen Smoogen
Back
On Fri, 2004-02-27 at 09:31, David J. Bianco wrote:
> I hope not. This sounds like a royal pain. You 'd have to somehow figure
> out which files in each update RPM were changed and then move them to the
> diskless area.
>
> I 've recently started planning the migration of our diskless machines
> from 7.3 to RHEL3, and although I haven 't done this yet, I think the idea
> is that all the directories with binaries that might be patched should be
> shared with the server, and the only client-writable directories should be
> things like /tmp and parts of /var that wouldn 't normally have patchable
> things in them anyway.
>
> Also, I think that for diskless booting, you won 't need a /boot
> partition, so this part is moot. The kernels will be downloaded at boot time
> rather than being accessed from the /boot partition.
>
I know that people at my organization are looking at doing this also.
The most widespread diskless solution here does something pretty painful
to update with /boot,/etc,/lib,/bin and a couple other directories to be
unique per machine, and /usr etc shared from the master diskless server.
Doing updates means updating the master server and then having ALL the
diskless clients rebuild themselves so that they get new /bin,/lib, etc.
Our big problem is that some people need to run older code like 6.x
still and so we have to have multiple diskless servers using this
method.
Our other drawback has been that the linux NFS server implementation is
not as solid as we would like and so all these boxes go into ugly NFS
storms where UDP congestion comes up.
My current pipe-dream which I dont know if it would work or not would be
to have the master server have the needed kernel and /boot items, and
the rest of the data being served from a NFS NetApp appliance (or
possibly a Linux box that can do NFSv3 TCP for diskless clients). Then
when I do an update, the clients can have their own up2date running and
not worry about shared data. Wasteful of disk ... yes ... easier
administration hopefully (especially when I have clients that have
'different ' needs for glibc/X)
Anyway.. back to work for me.
--
Stephen John Smoogen smoogen@(protected)
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
--
Taroon-list mailing list
Taroon-list@(protected)
http://www.redhat.com/mailman/listinfo/taroon-list
|
|
|