Re: [9fans] Installed Plan 9, now what?

Re: [9fans] Installed Plan 9, now what?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

perhaps, but i think that's necessary anyway even with all the . this-and-that-local attempts,
and in some ways they make it less obvious that something has changed.
for instance, the main script might have changed the place the local part
is invoked, or its context (environment variables, name space etc),
thus changing the effect without giving you any warning.
if instead you simply change the original script, you can see what happens
in context, in one place, and applylog moans making it obvious that
you need to diff to consider the changes.

[-- Attachment #2: Type: message/rfc822, Size: 2338 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installed Plan 9, now what?
Date: Mon, 08 Dec 2003 23:10:58 -0500
Message-ID: <20031209041058.7427.qmail@g.galapagos.bx.psu.edu>

| With the
| availability of dumps (or RCS on Lunix), there's little reason to be
| afraid of editing files.

The need to put things back isn't the problem; it's the need to notice
that something got stomped and the study required to integrate local
edits with the new reality.

Re: [9fans] Installed Plan 9, now what?

[Charles Forsyth]

>>perhaps, but i think that's necessary anyway even with all the . this-and-that-local attempts,
>>and in some ways they make it less obvious that something has changed.

i probably ought to have added that i've had exactly that
trouble with /etc/rc.conf on FreeBSD, which overrides
/etc/default/rc.conf, which configures /etc/too-many-rc-files

# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system.  You should
# not edit this file!  Put any overrides into one of the ${rc_conf_files}

it has advantages i suppose, especially when each component
comes with its own contribution to /etc/* (except when it's
/usr/local/etc) but in practice i found i needed to
grep for all the instances of each variable that i thought i might
need to change in order to decide whether and how to change it.
	tcp_extensions="YES"
really i wanted "MAYBE" or "GOODQUESTION" or "YOUTELLME" or "YOU'RETHECOMPUTER!"
i believe Linux applies fuzzy logic to this sort of thing.

RE: [9fans] Installed Plan 9, now what?

[David Presotto]

I use the following:

fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600 /srv/replica; mount -c /srv/replica /n/kfs }

-AWP wasn't possible originally, it got added later.
The chmod is there just so you can let others login
once you've started this without giving them access to
everything.

RE: [9fans] Installed Plan 9, now what?

[andrey mirtchovski]

On Mon, 8 Dec 2003, David Presotto wrote:

> fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600 /srv/replica; mount -c /srv/replica /n/kfs }
>

why not just add that to the /dist/replica/network script on sources? with
appropriate checks whether the system is running kfs or fossil and whether
$user can write to /srv/fscons we won't need to worry about it too much.

i can send you a sample script for that.

can you explain the chmod 600? it appears that /srv/replica is 600 already
after the srv command is issued...

andrey

RE: [9fans] Installed Plan 9, now what?

[David Presotto]

I was being paranoid and hadn't checked.  Sure give me a
script.  If I write one, its sure to have a dozen errors like
fshalt.

Re: [9fans] Installed Plan 9, now what?

[Dan Cross]

andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> writes:
>
> On Mon, 8 Dec 2003, David Presotto wrote:
>
> > fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600 /srv/replica; mount -c /srv/replica /n/kfs }
> >
>
> why not just add that to the /dist/replica/network script on sources? with
> appropriate checks whether the system is running kfs or fossil and whether
> $user can write to /srv/fscons we won't need to worry about it too much.
>
> i can send you a sample script for that.
>
> can you explain the chmod 600? it appears that /srv/replica is 600 already
> after the srv command is issued...

I'll propose again that replica scripts attempt to dot a script called
/dist/replica/site which could override things like the clientmount
function for dfferent sites.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[david presotto]

Isn't that what /dist/replica/network is?  How many times indirects
shall we go before we get to the file we're allowed to change.

Andrey's script is fine by me.  It gets it right in more cases
than the old one.  If you dinna like, it, replace it with your own.
----- Original Message -----
From: "Dan Cross" <cross@math.psu.edu>
To: <9fans@cse.psu.edu>
Sent: Monday, December 08, 2003 2:30 PM
Subject: Re: [9fans] Installed Plan 9, now what?


> andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> writes:
> >
> > On Mon, 8 Dec 2003, David Presotto wrote:
> >
> > > fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600
/srv/replica; mount -c /srv/replica /n/kfs }
> > >
> >
> > why not just add that to the /dist/replica/network script on sources?
with
> > appropriate checks whether the system is running kfs or fossil and
whether
> > $user can write to /srv/fscons we won't need to worry about it too much.
> >
> > i can send you a sample script for that.
> >
> > can you explain the chmod 600? it appears that /srv/replica is 600
already
> > after the srv command is issued...
>
> I'll propose again that replica scripts attempt to dot a script called
> /dist/replica/site which could override things like the clientmount
> function for dfferent sites.
>
> - Dan C.
>
>

Re: [9fans] Installed Plan 9, now what?

[Dan Cross]

"david presotto" <presotto@closedmind.org> writes:
>
> Isn't that what /dist/replica/network is?  How many times indirects
> shall we go before we get to the file we're allowed to change.

No, it's not, it's just for updating from sources.  And even if it were,
it's not used by anything else.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

Oh, I understand now, guess I'm just thick (never use anything except the
network).

[-- Attachment #2: Type: message/rfc822, Size: 2453 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installed Plan 9, now what?
Date: Mon, 08 Dec 2003 17:20:11 -0500
Message-ID: <200312082220.hB8MKBl22870@augusta.math.psu.edu>

"david presotto" <presotto@closedmind.org> writes:
>
> Isn't that what /dist/replica/network is?  How many times indirects
> shall we go before we get to the file we're allowed to change.

No, it's not, it's just for updating from sources.  And even if it were,
it's not used by anything else.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[Russ Cox]

> No, it's not, it's just for updating from sources.  And even if it were,
> it's not used by anything else.

here's a better question.  if we fix things so that
the pull files always use 9fs boot instead of 9fs kfs,
is there any benefit to /dist/replica/site?

Re: [9fans] Installed Plan 9, now what?

[Dan Cross]

"Russ Cox" <rsc@swtch.com> writes:
>
> > No, it's not, it's just for updating from sources.  And even if it were,
> > it's not used by anything else.
>
> here's a better question.  if we fix things so that
> the pull files always use 9fs boot instead of 9fs kfs,
> is there any benefit to /dist/replica/site?

Bearing in mind that right now there's no benefit to site, since it
doesn't exist, the only thing I could thing of would be to override
applyopts (e.g., to strip out -u).  Other users might come along,
such as doing the `srv -AWP' trick, etc.  Other than that?  No, not
right now, anyway.  Since it's a zero-cost thing, plugging it in for
the future wouldn't hurt much, though.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[Russ Cox]

> "Russ Cox" <rsc@swtch.com> writes:
> >
> > > No, it's not, it's just for updating from sources.  And even if it were,
> > > it's not used by anything else.
> >
> > here's a better question.  if we fix things so that
> > the pull files always use 9fs boot instead of 9fs kfs,
> > is there any benefit to /dist/replica/site?
>
> Bearing in mind that right now there's no benefit to site, since it
> doesn't exist,

this isn't fair -- the question is what the benefit would be
if it were there.

> the only thing I could thing of would be to override
> applyopts (e.g., to strip out -u).  Other users might come along,
> such as doing the `srv -AWP' trick, etc.  Other than that?  No, not
> right now, anyway.  Since it's a zero-cost thing, plugging it in for
> the future wouldn't hurt much, though.

well, no.  it does add to the complexity of the system,
and as presotto said there are a lot of redirects already.
i intended from the very beginning for people to customize
/dist/replica/plan9 to suit their local systems.

if there are more sensible defaults, i'd rather get them
done right in the files to begin with than require everyone
to edit /dist/replica/site.

russ

Re: [9fans] Installed Plan 9, now what?

[Dan Cross]

"Russ Cox" <rsc@swtch.com> writes:
> > Bearing in mind that right now there's no benefit to site, since it
> > doesn't exist,
>
> this isn't fair -- the question is what the benefit would be
> if it were there.

Fair enough.

> > the only thing I could thing of would be to override
> > applyopts (e.g., to strip out -u).  Other users might come along,
> > such as doing the `srv -AWP' trick, etc.  Other than that?  No, not
> > right now, anyway.  Since it's a zero-cost thing, plugging it in for
> > the future wouldn't hurt much, though.
>
> well, no.  it does add to the complexity of the system,

What complexity?  An if and a `.'?  I understand the argument that if
you add an if and a . everywhere, pretty soon we end up with a bloated
system, but I don't think this is the straw that's going to break the
camel's back.

> and as presotto said there are a lot of redirects already.

I didn't understand that comment then, and I don't really understand it
now.  What's being redirected here?  The idea is just to provide a
mechanism to interject local policy.

> i intended from the very beginning for people to customize
> /dist/replica/plan9 to suit their local systems.
>
> if there are more sensible defaults, i'd rather get them
> done right in the files to begin with than require everyone
> to edit /dist/replica/site.

The point isn't to require anything, but to provide mechanism.

Of course, optimizing for the common case by providing sensible
defaults so the majority can ignore /dist/replica/site should remain
the primary goal, but I don't understand how adding
`site=/dist/replica/site; if ( test -r $site ) .  $site' is going to
hurt much.  Or, even better, have the scripts dot a defaults file,
which might look for a site override.  So much of the replica scripts
are boilerplate, it just seems like a mistake not to provide a
defaulting mechanism.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[mirtchov]

> With the
> availability of dumps (or RCS on Lunix), there's little reason to be
> afraid of editing files.

I've gotten used to making pulls every morning (still done by hand,
I'm not that important to have it in a cron job yet).  I examine the
output looking for stuff that is "locally modified", then I
carelessly^Wcarefully accept it with -s and run "yesterday -c" on
whatever I don't like...  That's still easier than running 'up2date'
on a RedHat machine or 'cvsup' on a *BSD box.

By the way, my argument against the multi-level indirection is that
it's in such important places (fossil, replica, ndb) that explaining
it becomes hard.  How many times has 'why is pull not working?' been
answered on this list?  How many of those answers involved something
completely non-obvious to a new Plan 9 user?

Plan 9, as recently reiterated, is supposed to be about simplifying
administration as much as it is about offering a unified distributed
environment.

my $0.02(CAD): andrey

Re: [9fans] Installed Plan 9, now what?

[Geoff Collyer]

I believe rsc and presotto mean to say `indirection', not
`redirection'.  To see the potential problem with just adding another
level of indirection everywhere, consider the evolution of Lunix's
filename space.

Originally people edited files, including in places like /etc,
directly.  Then people began to worry that if they changed those
files, their changes would get stomped on by the next OS upgrade from
their vendor.  In that world, checking changed files into RCS would
let one just check them out again after an upgrade; in our world, we
can just copy them out of the dump.  But instead, people created a
parallel file tree under /usr/local (or /local [a symlink] in places
where people got tired of typing "/usr/local" endlessly).  So
additions and changes in /usr/local were now thought to be safe
against upgrades.  But then some vendors caught on to /usr/local and
started shipping free-ish software pre-installed in /usr/local.  And
the gnu-ish folk decided that all non-vendors software should be
installed in /usr/local.  And some organisations wanted to share a
standard /usr/local across their machines, including suborganisations.
U of Toronto ended up with /csri/local, /cs/local, /ai/local and
probably others that I've forgotten; I think U of Waterloo took it
even farther (they've been much more ideological ☺).  So what's local,
and who owns it?  At various times, these owners have existed:

- AT&T's System V maintainers (actually I think they populated /usr/lbin)
- SGI, who shipped their own programs in /usr/local (it was local
  relative to System V), and probably other OEMs
- campus computer centers, adding locally-installed (often imported)
  software to vendor distributions
- departments
- maintainers of clusters of machines
- owners or users of individual machines

Aside from the issue of name conflicts (who gets to control
/usr/local?), more and more of the file system becomes fossilised
boilerplate that most people (including administrators) are terrified
(or forbidden) to touch.  If you're in a big enough organisation, you
can end up with

	/company/local/
	/company/division/local
	/company/division/dept/local
	/company/division/dept/group/local
	/company/division/dept/group/my-machine/local

I think we've made a very small step in this direction with
termrc.local, /sys/lib/sysconfig/termrc, namespace.local and
namespace.$sysname.  One litmus test for when fear is driving these
decisions is when people become afraid to edit files with `local' in
their names and want to add another level of indirection.  With the
availability of dumps (or RCS on Lunix), there's little reason to be
afraid of editing files.

Re: [9fans] Installed Plan 9, now what?

[Scott Schwartz]

| With the
| availability of dumps (or RCS on Lunix), there's little reason to be
| afraid of editing files.

The need to put things back isn't the problem; it's the need to notice
that something got stomped and the study required to integrate local
edits with the new reality.

Re: [9fans] Installed Plan 9, now what?

[Geoff Collyer]

At least with replica, you have to use `pull -s' to overwrite a
locally-changed file, so it's pretty clear what's been stomped,
particularly with -v.  After that,

	diff `{yesterday file} file

has been enough to let me quickly decide how to proceed.

The Lunix world is of course quite different.

Re: [9fans] Installed Plan 9, now what?

[Dan Cross]

What Scott said.  My concerns here stem from my days as a Lunix system
administrator, and the difficulty of keeping localized changes straight
in the face of vendor changes; RCS, though used, didn't do everything,
because vendors started making necessary changes that simply checking a
file out from RCS would overwrite.  All the diffing and patching became
tedious; multiplying that over hundreds of machines with different
functions in tens of different administrative domains quickly leads to
a lot of tedious work.  While Plan 9's architecture really attenuates
the problem, I'd like to try and eliminate it.

This isn't Unix; there's only one vendor.  As for division of
change-authority (for lack of a better term), it's really simple:
anything with the name local in it is off limits for any `vendors' (ie,
Bell Labs).  Everything else is `change at your own peril' for everyone
else.  Create /dist/replica/defaults, that tries to dot
/dist/replica/defaults.local.  Problem solved.

It could be argued that the proliferation of hacks Geoff mentions in
Lunix-land happened because no one ever had a decent convention that
allowed for a clear seperation of authority between vendors and sites.
We have an opportunity with Plan 9 to try and do it right, and we
should.  Rob's paper on the death of systems research lists system
administration as a problem area worthy of investigation; instead of
sticking our collective heads in the sand and pretending this is a
non-problem, let's tackle it head on and figure out a good way to
address it.  Is all the .local stuff perfect?  No, not really, and the
warnings are good, because they give us perspective.  But, what's a
better alternative?  I'm all eyes.

	- Dan C.

Re: [9fans] Installed Plan 9, now what?

[okamoto]

> better alternative?  I'm all eyes.

Sigh, I know only one usage of "I'm all ears".
Sorry, I couldn't regist how english is difficult to me.

Kenji

Re: [9fans] Installed Plan 9, now what?

[a]

i'm with dan on this point, i think. my concerns here, however, come
from being a plan 9 administrator. we ran our own file server, and did
overlays on top of 1127's files when we wanted something changed, just
doing binds where we wanted them. it worked great, for the most part; a
real testament to the strength of the architecture. 

the problems came when 1127 changed things. well, of *course* they did;
it's a research system! our system of binds helped us manage local
changes in a way that was easy to manage and track, but it required
duplicating whole files (not to mention a /lib/namespace that was
several hundred lines long!). it was frustrating when, once or twice a
year, i'd have to track down some config file that'd changed and port
the new changes in 1127's version into our version, when all we
typically wanted was setting some variable differently than 1127 had.

if "local" files exist (whatever they're called), they should all ship
empty, or simply not exist. if something's not working right after
some upgrade, it's easy to figure out if it's local site mods that're
causing the error, and easy to tell where the changes - both from the
"vendor" and the local user - are.

i have to professionally (that is, i'm paid for it; saying nothing
about the manner in which i do it) manage a hadfull of unix boxes,
with some collection of GNU or other third-party software, and the
mess around config and site localization there is horrid. i'd very
much like to avoid duplicating that. but the current situation - which
is, as dan said, essentially ignoring the issue - is far from ideal,
too. things now are an order of magnitude easier to follow than in the
linux/GNU world, but could be better still.
ア

Re: [9fans] Installed Plan 9, now what?

[boyd, rounin]

> i'm with dan on this point

so am i.  wobber's and prusker's work we [PRL] used to update ultrix boxes
nightly.
get that config wrong and you had one broken lab.

there was a global config and a local config (in this case one per machine).

every site/machine is different and this behooves a 'local' config which is
taken into account when updates are done.

Re: [9fans] Installed Plan 9, now what?

[splite]

On Mon, Dec 08, 2003 at 11:54:45PM -0500, Dan Cross wrote:
> But, what's a better alternative?  I'm all eyes.

The Windows registry? *ducks*

I have to agree with Charles and Geoff.  The only thing .local files buy
you is overwrite protection, which is already provided by pull.  You still
have to check that your overrides in .local are valid.  Is there a way
around that problem that doesn't involve Star Trek-type AI or mind reading?

Ultimately, it's the price one pays for the flexibility of expressing
configuration info as shell scripts instead of a database (or registry)
of predetermined, paramaterized, versioned configuration variables.

Re: [9fans] Installed Plan 9, now what?

[Brantley Coile]

On Tue, 9 Dec 2003 13:33:53 -0500, <splite@purdue.edu> wrote:

> On Mon, Dec 08, 2003 at 11:54:45PM -0500, Dan Cross wrote:
>> But, what's a better alternative?  I'm all eyes.
>
> The Windows registry? *ducks*
>
> I have to agree with Charles and Geoff.  The only thing .local files buy
> you is overwrite protection, which is already provided by pull.  You
> still
> have to check that your overrides in .local are valid.  Is there a way
> around that problem that doesn't involve Star Trek-type AI or mind
> reading?
>
> Ultimately, it's the price one pays for the flexibility of expressing
> configuration info as shell scripts instead of a database (or registry)
> of predetermined, paramaterized, versioned configuration variables.
>


No no no no no no no no NOOOOOOO!

(It had to be expressed in the most direct manner possible.)

It was good that MS went the way of a central registry.  We now
know for sure that it's a very bad idea.

 Brantley

RE: [9fans] Installed Plan 9, now what?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

If the mod wasn't 600 to begin with, you wouldn't run it while letting
others connect to your system until you'ld made it 600.

But, as has been pointed out, it already is 600...

[-- Attachment #2: Type: message/rfc822, Size: 2504 bytes --]

From: YAMANASHI Takeshi <uncover@beat.cc.titech.ac.jp>
To: 9fans@cse.psu.edu
Subject: RE: [9fans] Installed Plan 9, now what?
Date: Tue, 9 Dec 2003 16:55:04 +0900
Message-ID: <736a4e0c78466e06ed007d90655c73f8@orthanc.cc.titech.ac.jp>


> fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600 /srv/replica; mount -c /srv/replica /n/kfs }

There is a window in this script if the creation mode of
/srv/replica is not 600, is it?  Actually, the mode is 600
and the window is always closed.

My concern is what would be the solution if the mode has
not been 600?
--
YAMANASHI Takeshi

RE: [9fans] Installed Plan 9, now what?

[YAMANASHI Takeshi]

> fn clientmount { echo 'srv -AWP replica'>>/srv/fscons;chmod 600 /srv/replica; mount -c /srv/replica /n/kfs }

There is a window in this script if the creation mode of
/srv/replica is not 600, is it?  Actually, the mode is 600
and the window is always closed.

My concern is what would be the solution if the mode has
not been 600?
--
YAMANASHI Takeshi

Re: [9fans] Installed Plan 9, now what?

[Russ Cox]

> > I recently installed plan 9 on my dell dimension desktop using the
> > wiki notes. I used fossil as my filesystem. How do I stay upto date?
> > The notes on the webpage seems to be for kfs.
>
> OK, I don't get it. There seems to be some consensus that clientmount()
> shoud be 'mount -c /srv/boot /n/boot'. But in /sys/src/9/boot/local.c
> /srv/boot is created as 'srv -A fboot', which means only authentication
> is off; permission checking and arbitrary wstats are still standard. =
> This is clearly
> not enough for replica (confirmed by in vivo experiments).=20
> So, what's the deal?

the deal is that for the local file system, it's okay
not to do authentication.  kfs never did, for bootstrapping
reasons, and so i made the fossil boot process do the same.
otherwise you'd need to run an auth server just to boot
a standalone laptop.

it's only for booting, not for pulling.  i just put myself
in sys and remove the -u from the proto file, and then that's
enough for replica (and all the created files get owned by me,
which is no problem for me).  if you have a special system account
you could still do the same, as long as you're willing to give
up on things being owned by sys.

russ

RE: [9fans] Installed Plan 9, now what?

[ron minnich]

On Mon, 8 Dec 2003, Tiit Lankots wrote:

> So, what's the deal?

things are outta date on the replica front, and people have different
solutions so far, all local hacks to deal with the problem.

ron

Re: [9fans] Installed Plan 9, now what?

[mirtchov]

> Hi
> I recently installed plan 9 on my dell dimension desktop using the
> wiki notes. I used fossil as my filesystem. How do I stay upto date?
> The notes on the webpage seems to be for kfs.

I'll update the notes for fossil later today.

>
> The website also talks about venti. What is venti? Is it a seperate
> partition? How do I set it up?

venti is described in /sys/doc/venti/

setting up venti is described in:

	http://plan9.bell-labs.com/wiki/plan9/Setting_up_Venti/index.html


andrey

RE: [9fans] Installed Plan 9, now what?

[Tiit Lankots]

> I recently installed plan 9 on my dell dimension desktop using the
> wiki notes. I used fossil as my filesystem. How do I stay upto date?
> The notes on the webpage seems to be for kfs.

OK, I don't get it. There seems to be some consensus that clientmount()
shoud be 'mount -c /srv/boot /n/boot'. But in /sys/src/9/boot/local.c
/srv/boot is created as 'srv -A fboot', which means only authentication
is off; permission checking and arbitrary wstats are still standard. This is clearly
not enough for replica (confirmed by in vivo experiments). 
So, what's the deal?

Tiit

[9fans] Installed Plan 9, now what?

[Sujan Gautam]

Hi
I recently installed plan 9 on my dell dimension desktop using the
wiki notes. I used fossil as my filesystem. How do I stay upto date?
The notes on the webpage seems to be for kfs.

The website also talks about venti. What is venti? Is it a seperate
partition? How do I set it up?

I am a newbie so please bear with me.

-Sujan Gautam