Hello!

while setting up my experimental Plan9 network I found myself drawn to
implement a system wide 'profile' for the rc(1) shell.

This allows to simplify both: rcmain and the personal 'lib/profile'
for each user and seems easier to maintain to me.

And .. it is so trivial that I must apologize for annoying the list
with it, however maybe it is worth adopting it for the default
installation.

To make this mail small find it explained with details and ready to
use sources at:

  http://www.magma.com.ni/moin/Plan9Tutorial/RcProfile

Regards,


    Jorge-Le=F3n

Hello,

I'm not quite sure what you want to achieve there (well, maybe I'm just
slow). The net gain I see is two extra lines in rcmain and one additional
file (actually two files) doing more or less the same as before. The two
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. 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).
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.

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

* Russ Cox (rsc@swtch.com) wrote:
> One could also simply
> 
> . /rc/lib/profile
> 
> at the top of the user's lib/profile if conformance was desired.
> 
> Russ

I also thought about that after posting. Has the additional advantage of not
forcing the view of the site admin on you.

Martin

Martin Neubauer <m.ne@gmx.net> 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 tho=
se
> who want it. Speaking for myself, it would certainly make me sad to see t=
he
> 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=F3n

PS.1:=20

~/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=3D/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 perso=
ns).

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=3D11
~/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=20
- 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.

Martin Neubauer <m.ne@gmx.net> writes:

> * Russ Cox (rsc@swtch.com) wrote:
>> One could also simply
>>=20
>> . /rc/lib/profile
>>=20
>> at the top of the user's lib/profile if conformance was desired.
>>=20
>> Russ
>
> I also thought about that after posting. Has the additional advantage of =
not
> forcing the view of the site admin on you.
>
> Martin
>

If I am my own site admin, I can omit /rc/lib/profile and do
everything in ~/lib/profile.

If I am the site admin for other people I want to be able to force
things.  Users will apreciate my view if it is the right one.



geoff@plan9.bell-labs.com writes:

> Maybe I'm missing something, but why not just modify /rc/bin/termrc or
> termrc.local?
>

termrc (and cpurc) are only run during the boot process

/rc/lib/rcmain and ~/lib/profile are read everytime rc -l is run.

Regards,

        Jorge-Le=F3n

--=20
    Jorge-Le=F3n