As already said with this setup the clients share basicly the entire root-fs
with the server. But the clients ofcourse only get read access to it. This
is basicly how things work.
Unfortunatly things aren't that simple, there are a couple of problems
the overcome with this simple setup.
Each ws needs its own writable copy of a number of dirs
A normal linux setup needs to have write access to the following dirs:
There are 3 solutions for this, of which one will only work for /dev:
- mount a ramdisk and populate it by untarring a tarball, or by copying a
- It's cleaned up every reboot, which removes tmp files and logs. Thus it
needs no maintaince unlike server sided dirs.
- It doesn't take up any space on the server, and that it doesn't generate
any network traffic. A ramdisk takes less server and network resources, and
- It takes memory.
- The logs aren't kept after a reboot, if you really want logging of all
your clients tell syslog to redirect the logging to your server.
- create a dir for each ws on the server and mount it rw over nfs.
- Advantages & disadvantages:
- The above arguments work in reverse for serversided dirs.
- With kernel 2.2 devfs can be used for /dev, this is a virtual filesystem
ala /proc for /dev.
- Devfs takes very little memory when compared to a ramdisk / no diskspace
on the server and is very fast. A normal /dev takes at least 1.5 mb since the
minimal size for a file (and thus for a device) is 1k, and there are somewhere
around 1200 devices. You can offcourse use a template of a stripped /dev with
only the entries you need to save some space. 1.5 Mb is a lott for a ramdisk
and also isn't nice on a server.
- Devfs automagicly creates entries for newly added & detected devices,
so no maintainance is needed.
- Any changes to /dev like creating symlinks for the mouse and cdrom are
lost. Devfs comes with a script called rc.devfs to save these chances. The
script's provided in this howto will automagicly restore these symlinks settings
by calling rc.devfs If you make any changes to /dev you need to call the rc.devfs
yourself to save them by typing:
/etc/rc.d/rc.devfs save /etc/sysconfig
As you can see, there are a number of ways to solve this problem. For the
rest of this Howto the following choices are assumed:
- For /dev we'll use Devfs
- For /var and /tmp we'll use a shared ramdisk of 1mb. It's shared to use
the space as effeciently as possible. /tmp is replaced by a symlink to /var/tmp
to make the sharing possible.
- Populating the ramdisk with tarballs or template dirs, works equally well.
But with template dirs it's much easier to make changes, thus we'll use template
Write access to /home might be needed
Not really a problem in every unix client/server setup /home is mounted
rw from the server so we'll just do that ;)
How does a ws find out it's ip so that it can communicate with the server?
Luckily for us, this problem has already been solved and the linux kernel
has support for 2 ways of autoconfiguration of the ip-address:
Rarp is the easiest to setup, bootp is the most flexible. Since most bootroms
only support bootp that's what we'll use.
What about ws sepecific configuration
On redhat most system dependent config files are already in /etc/sysconfig
We'll just move those which aren't there and add symlinks. Then we mount a
seperate /etc/sysconfig on a per ws basis. This is really the only distribution
dependent part on other distributions you can just create a sysconfig dir,
move all config files which can't be shared there and create symlinks. Also
/etc/rc.d/rc3.d, or symilar on other dists, might need to be different for
the server resp the workstations. Assuming that all ws run the same services
in runlevel 3, we'll just create a seperate 3th runlevel for the workstations
and the server:
- Create both a /etc/rc.d/rc3.ws and a /etc/rc.d/rc3.server
- make /etc/rc.d/rc3.d a symlink to /etc/sysconfig/rc3.d
- make /etc/sysconfig/rc3.d a symlink to the apropiate /etc/rc.d/rc3.xxx
- replace S99local in rc3.ws by a link to /etc/sysconfig/rc.local so that
each ws can have it's own rc.local
There are a few problems left:
- /etc/rc.d/rc.sysinit needs /var, so /var needs to be mounted or created
before /etc/rc.d/rc.sysinit is run. It would also be nice if the ws-specific
/etc/sysconfig is mounted before any initscripts are run.
- We'll just source a bootup script for the ws in the very top of /etc/rc.d/rc.sysinit.
Note this script will then ofcourse also be sourced by the server itself on
boot, so the script has to detect this and do nothing on the server.
- /etc/mtab needs to be writable:
- This is a tricky one, just create a link to /proc/mounts and create an
empty file mounts in /proc so that fsck and mount don't complain during the
initscripts when /proc isn't mounted yet. One note smb(u)mount doesn't respect
mtab being a link and overwrites it. Thus if you want to use smb(u)mount create
wrapper scripts that restore the symlink.