Martin Neubauer <[EMAIL PROTECTED]> writes:
...
> main usage scenarios I can think of would be a system used mainly by a
> single person and a system (or network of systems) used by a potentially
> large and diverse group of users. For a singleuser system that separation
> is more or less useless.
Right!
> For a multiuser system it might look like a good
> idea at first, but I value the convenience of having all settings I might
> want to customise in one place (especially as I get it via newuser anyway).
As a system administrator I (may) have three requirements:
- set up several different networks of systems, each of which has its
own particularities
- change some particularities for all users within a certain network
of systems.
- Take care of users that are not (shell) programmers
for the first two requirements it is convenient to be able to change default
values for all users:
Default installation remains identical for all networks of systems, to
"brand" each network, only one /rc/lib/profile has to be changed, no
need to change ~/lib/profile foreach ~.
What is left in /sys/lib/rcmain is a bare minimum for running rc
non-interactively (I guess even the "switch($#prompt.." could be
omited.
Also ~/lib/profile should be a bare minimum. See PS.1 for more.
/sys/lib/profile gives a reasonable default working environment
available even with a broken ~/lib/profile.
(l)users do break things. I want:
1- a working namespace without ~/lib/profile
2- a minimal ~/lib/profile, so user is not easily confused
3- be able to overwrite a broken, or restore a deleted ~/lib/profile
from a known to work template
1- and 2- are covered by /rc/lib/profile
> The newuser script arguably is simpler, but the change really hasn't got
> anything to do with a system-wide profile and as a downside makes it no
> longer self-contained.
3- is covered by not self-containing ~/lib/profile in the newuser
script, but rather have it separate.
The same would apply to ~/lib/plumbing, however I have not
exercised it.
>
> All in all it's a little exercise in establishing a system policy for those
> who want it. Speaking for myself, it would certainly make me sad to see the
> rise of the POSIX-rc...
>
> Martin
>
I don't care about POSIX-rc or not, I need a simple yet scalable
system. This means (amongst others), that the general case must
include the special case.
In the given approach /sys/lib/profile can simply be omitted and
everything works as before.
The exercise tries to draw from the idea of separating concerns:
- rcmain sets up rc(1)
... only with rc -l:
- system wide profile sets up the default namespace
- user profile launches the programs each users wants to launch
The system wide profile should not do anything, the user profile
cannot undo or override later.
Regards,
Jorge-León
PS.1:
~/lib/profile could be stripped down to something like:
----
upas/fs
switch($service) {
case terminal
plumber
exec rio -i riostart
case cpu
news
if (! test -e /mnt/term/mnt/wsys) { # cpu call from drawterm
exec rio
}
case con
news
}
----
if /rc/lib/profile was extended with:
----
fn cd { builtin cd $* && awd } # for acme
switch($service){
case terminal
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
case cpu
if (test -e /mnt/term/mnt/wsys) { # rio already running
bind -a /mnt/term/mnt/wsys /dev
if(test -w /dev/label)
echo -n $sysname > /dev/label
}
bind /mnt/term/dev/cons /dev/cons
bind /mnt/term/dev/consctl /dev/consctl
bind -a /mnt/term/dev /dev
if (! test -e /mnt/term/mnt/wsys) { # cpu call from drawterm
font=/lib/font/bit/pelm/latin1.8.font
}
case con
news
}
----
PS.2: To illustrate the advantage for system administration of large
Networks consider the following ficticious scenario:
I have one fileserver with comercial software and shared storage for
the bookkeepers folks (3 persons).
For developers group one I have some special development software on a
second fileserver (7 persons).
For developers group two I have other software and their filespace (4 persons).
For testers group one I have a test-setup with application binaries
from developers group one fileserver (4 persons).
etc...
So I would change 9fs, mounts and binds (to /bin) in the
/rc/lib/profile of each group: i.e. four (4) files.
With the actual approach I would need to temper with 3+4+4=11
~/lib/profile files to get things right for the folks *and* I'd need
to have access rights to these: This I do not want at all!
Some three months later, the testers get bumped up to 7 persons and
need to test software from developers group two also:
Actual situation:
- create three new accounts, edit 4 old and 3 new ~/lib/profiles: 7 files
- alternative: edit ~/sys/lib/newuser and create the new accounts
afterwards: 4 files
System wide approach:
- edit the /rc/lib/profile at the testing group: 1 file
As an exercise to the reader: multiply number of departments by five
and number of employes by three... result: nightmare.
