Re: [9fans] a few more misc. questions if you don't mind

Re: [9fans] a few more misc. questions if you don't mind

[Corey]

On Saturday 25 July 2009 18:46:27 erik quanstrom wrote:
<snip>
> auth/keyfs provides the authentication database.
> this is run on the auth server.
>
> awuth/wrkey writes the host keys into nvram.  this needs
> to happen on every cpu server encluding the auth server.  this
> enables the hostowner to boot unattended.  otherwise
> someone would need to be at the console to type in
> the authdomain, hostowner, and password.
>

Perfect, thanks.


> on a pc nvram is typically not usuable, so a 512-file
> plan9.nvr in 9fat or a 512-byte prep partition named
> nvram serves this purpose.
>
> > Why is sysname= not documented in plan9.ini(8)? Just an oversight?
>
> because it's not set there.  ndb/cs sets sysname.
> see comments in /rc/bin/cpurc.
>

I got the notion that you can set sysname via plan9.ini from this doc:

http://www.9grid.fr/wiki/plan9/Configuring_a_Standalone_CPU_Server/

About half way down the page, under the 'NETWORK DATABASE' section:

"
If you're not setting up a whole network and just want drawterm access to
the combined cpu and auth server you're configuring, adding the single line:

authdom=some.domain auth=cycles

...to /lib/ndb/local will suffice, if you also add the line:

sysname=cycles

...to plan9.ini.
"

This appears to work. For example, I put:

sysname=howl

in my terminal's plan9.ini, and after I reboot, /dev/sysname and $sysname
end up being set accordingly... I guess because anything put into plan9.ini
ends up as an env variable?


> > There seems to be somewhat of an ambiguity regarding "workstation-class"
> > terminals, vs. the "dumb" terminals - it seems not totally unreasonable
> > for someone to have their "personal workstation" setup as a cpu/auth
> > terminal.
>
> i think you may be missing the distinction.  a terminal
> in plan 9 is simply a personal machine.  computing power
> or hardware capabilities have nothing to do with it.
> a cpu server is a shared resource.  there's also often
> an assumption that cpu servers that provide services
> like authentication are always available.
>

I understand that, but I didn't pose my question correctly. The gist behind
the question might have made more sense if I had phrased it differently:

Given the following ridiculously contrived hypothetical situation:

You only had a single computer in your house, and you could only run
Plan 9 on it...

Would you opt to install and configure it with a terminal kernel, or would
you decide to use a cpu kernel, with auth and fs services enabled? Or is
there simply no reason to prefer one over the other given such constrained
circumstances?

I realize it's totally "against the point" to have a _single_ plan 9 box; but
I doubt it's all that rare when you step outside the lab or the corporate
environment and peer into the domiciles of everyday people using plan 9
at home for personal experimentation and educational purposes.

Re: [9fans] a few more misc. questions if you don't mind

[John Floren]

On Sat, Jul 25, 2009 at 8:08 PM, Corey<corey@bitworthy.net> wrote:
>
> I understand that, but I didn't pose my question correctly. The gist behind
> the question might have made more sense if I had phrased it differently:
>
> Given the following ridiculously contrived hypothetical situation:
>
> You only had a single computer in your house, and you could only run
> Plan 9 on it...
>
> Would you opt to install and configure it with a terminal kernel, or would
> you decide to use a cpu kernel, with auth and fs services enabled? Or is
> there simply no reason to prefer one over the other given such constrained
> circumstances?
>
> I realize it's totally "against the point" to have a _single_ plan 9 box; but
> I doubt it's all that rare when you step outside the lab or the corporate
> environment and peer into the domiciles of everyday people using plan 9
> at home for personal experimentation and educational purposes.
>

To the contrary, I think it is highly likely that anyone interested in
Plan 9 has a spare computer to try it on, or in these days of fast
processors, big disks, and lotsa-RAM, they'd boot in a virtualized
environment. Don't bring in the tired old argument "but what about
average users who want to switch from Windows", because that's not
what happens. Everyday people do not use Plan 9, they don't even know
Plan 9 exists, they got Linux on a netbook a year ago and got upset
because it was weird. Strange adventurous people with an interest in
operating systems & software try Plan 9, and such people tend to have
spare computers around.

If you have only one computer in the entire house, you run Linux on
it, with Xen or Qemu or whatever to run Plan 9 at the same time and
set it up as a CPU/auth/file server. Then you connect via drawterm. If
that's not the answer you want, I'd install as a terminal and just
deal with it. Or find a PIII desktop on Craigslist for $30 and use
that. Desktop computers cost less than cell phones these days.

Of course, we could continue all day in the "but what if..." vein, in
some weird attempt to satisfy whatever particular solution you were
hoping for--if we restrict the options enough, then yes, we will get
the answer you want.



John
--
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] a few more misc. questions if you don't mind

[Corey]

On Saturday 25 July 2009 20:22:35 John Floren wrote:
> On Sat, Jul 25, 2009 at 8:08 PM, Corey<corey@bitworthy.net> wrote:
<snip>
> > Given the following ridiculously contrived hypothetical situation:
> >
> > You only had a single computer in your house, and you could only run
> > Plan 9 on it...
> >
> > Would you opt to install and configure it with a terminal kernel, or
> > would you decide to use a cpu kernel, with auth and fs services enabled?
> > Or is there simply no reason to prefer one over the other given such
> > constrained circumstances?
> >
> > I realize it's totally "against the point" to have a _single_ plan 9 box;
> > but I doubt it's all that rare when you step outside the lab or the
> > corporate environment and peer into the domiciles of everyday people
> > using plan 9 at home for personal experimentation and educational
> > purposes.
>
> To the contrary, I think it is highly likely that anyone interested in
> Plan 9 has a spare computer to try it on, or in these days of fast
> processors, big disks, and lotsa-RAM, they'd boot in a virtualized
> environment. Don't bring in the tired old argument "but what about
> average users who want to switch from Windows", because that's not
> what happens. Everyday people do not use Plan 9, they don't even know
> Plan 9 exists, they got Linux on a netbook a year ago and got upset
> because it was weird. Strange adventurous people with an interest in
> operating systems & software try Plan 9, and such people tend to have
> spare computers around.
>
> If you have only one computer in the entire house, you run Linux on
> it, with Xen or Qemu or whatever to run Plan 9 at the same time and
> set it up as a CPU/auth/file server. Then you connect via drawterm. If
> that's not the answer you want, I'd install as a terminal and just
> deal with it. Or find a PIII desktop on Craigslist for $30 and use
> that. Desktop computers cost less than cell phones these days.
>
> Of course, we could continue all day in the "but what if..." vein, in
> some weird attempt to satisfy whatever particular solution you were
> hoping for--if we restrict the options enough, then yes, we will get
> the answer you want.
>

I don't understand why you are assuming that I have some sort of
pre-biased angle. That I'm framing things in order to receive a
particular answer? It was just a question. From a curious user.
Who wants to increase his understanding of the system and the.

Anyhow:

"One computer, Plan 9 only, on bare hardware - which do you prefer:
terminal kernel or cpu kernel w/ auth and fs enabled? Or is there
technically no reason to have a preference under the circumstances?"

Your answer: "terminal and just deal with it."

But unfortunately you didn't say why you would choose terminal, and
you didn't explain what you meant by "just deal with it".

At any rate, sorry to ruffle your feathers.


Beers

Re: [9fans] a few more misc. questions if you don't mind

[John Floren]

On Sat, Jul 25, 2009 at 9:09 PM, Corey<corey@bitworthy.net> wrote:
>
> "One computer, Plan 9 only, on bare hardware - which do you prefer:
> terminal kernel or cpu kernel w/ auth and fs enabled? Or is there
> technically no reason to have a preference under the circumstances?"
>
> Your answer: "terminal and just deal with it."
>
> But unfortunately you didn't say why you would choose terminal, and
> you didn't explain what you meant by "just deal with it".
>

A standalone terminal is far from ideal. However, in my experience
I've found working on the console of a CPU/auth/file server (running
rio of course) even less ideal... it's just not meant to be used that
way, while a terminal is. To tell the truth I don't recall exact
problems, but I remember things like auth not working properly when
actually sitting at the console; this may have been due to a slight
misconfiguration, or maybe I just needed to start factotum--I don't
remember. On the other side of the coin, I have a standalone terminal
installation on my laptop, although I normally get root over tcp.
However, when I'm visiting my parents, it isn't feasible to boot from
a filesystem across the country over dialup, so I boot into the
standalone system, dial up, and work like that. It works without
trouble, I just mount the remote filesystem when I need my files and
otherwise work locally.

Assuming you have an account on a public system somewhere--there's
mordor, of course, and I believe there are now a few others, one or
two in Europe and I seem to recall one in New York--you can do just
fine like that. Actually, it was kind of fun to actually use Plan 9
with dialup, felt like the "good old days".

And regarding the "preconceived answers" stuff, I've just seen so many
people with an apparent axe to grind ("For reasons known only to
myself, I must prove that Plan 9 is not a viable Windows replacement
for Joe Sixpack!") that I was expecting one here. Appy-polly-logies
from your humble Narrator.


John
--
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] a few more misc. questions if you don't mind

[erik quanstrom]

On Sat Jul 25 23:09:49 EDT 2009, corey@bitworthy.net wrote:
> > > Why is sysname= not documented in plan9.ini(8)? Just an oversight?
> >
> > because it's not set there.  ndb/cs sets sysname.
> > see comments in /rc/bin/cpurc.
> >
>
> I got the notion that you can set sysname via plan9.ini from this doc:
>
> http://www.9grid.fr/wiki/plan9/Configuring_a_Standalone_CPU_Server/
>
> About half way down the page, under the 'NETWORK DATABASE' section:
>

however, doing it this way will cause ndb/cs to be confused.  this
can cause subtle problems.  it's best to follow the convention.

> in my terminal's plan9.ini, and after I reboot, /dev/sysname and $sysname
> end up being set accordingly... I guess because anything put into plan9.ini
> ends up as an env variable?

yes.  actually everything in plan9.ini will be in #ec.  #ec is a subset of #e.

> I realize it's totally "against the point" to have a _single_ plan 9 box; but
> I doubt it's all that rare when you step outside the lab or the corporate
> environment and peer into the domiciles of everyday people using plan 9
> at home for personal experimentation and educational purposes.

i hope this isn't condecending, but if faced with that constraint,
i would do as i suggested before. run a cpu/auth/fs and use drawterm
to access it.  when i really had one machine, i ran it as a terminal.
but that wasn't much fun.  i was pretty motivated to get a fs working.

my home network consists of a ken's fs, a cpu server and a terminal.
i also have a secondary fast cpu server and a secondary slow cpu server,
that's generally in various states of disrepair as i break^wwork on things.

a big system, can be a little more elaborate.  coraid has a stand-alone
auth server, and four other cpu servers and a stand alone fs.  there
are also a few dozen terminals.

- erik

Re: [9fans] a few more misc. questions if you don't mind

[Steve Simon]

For interest I have a single cpu/file/auth server at home which I connect
to with drawterm or a native terminal depending on which laptop I am on.

At work I have a cpu/file/auth server which is also my terminal.
This is definitely sub-optimal, combining the terminal with the others means
your host owner must be yourself rather than the usual bootes and I end
up support two different auth databases (home and work) but it can be done.

Running plan9 on current hardware was becomming hard as PC technology has
been changing quite a bit of late, but this situation has been improving
in recent months thats to the hard work of a few stallwart 9fans.

-Steve

Re: [9fans] a few more misc. questions if you don't mind

[erik quanstrom]

> Also, not so much from the perspective of a standalone terminal, just general
> questions:
>
> What's the inter-relationship/difference between the following two commands:
> 'auth/keyfs' and 'auth/wrkey'? I've read their respective man pages, but I'm
> still a bit hazy on what exactly are the roles of those two commands (assuming
> no arguments are supplied).

auth/keyfs provides the authentication database.
this is run on the auth server.

awuth/wrkey writes the host keys into nvram.  this needs
to happen on every cpu server encluding the auth server.  this
enables the hostowner to boot unattended.  otherwise
someone would need to be at the console to type in
the authdomain, hostowner, and password.

on a pc nvram is typically not usuable, so a 512-file
plan9.nvr in 9fat or a 512-byte prep partition named
nvram serves this purpose.

>
> Why is sysname= not documented in plan9.ini(8)? Just an oversight?

because it's not set there.  ndb/cs sets sysname.
see comments in /rc/bin/cpurc.

> There seems to be somewhat of an ambiguity regarding "workstation-class"
> terminals, vs. the "dumb" terminals - it seems not totally unreasonable for
> someone to have their "personal workstation" setup as a cpu/auth terminal.

i think you may be missing the distinction.  a terminal
in plan 9 is simply a personal machine.  computing power
or hardware capabilities have nothing to do with it.
a cpu server is a shared resource.  there's also often
an assumption that cpu servers that provide services
like authentication are always available.

> e.g. I _think_, that if one were simply wanting to get a _single_ plan 9 box
> running on a typical moderately powered pc, that one should just go for a cpu
> kernel running auth, vs. a term kernel? -- of course this is assuming one has
> no interest in setting up a "proper" plan 9 environment for whatever reasons.

option c.  i would (and have) set up a cpu server
running auth and the fs and use drawterm instead
of a terminal.  given two machines, i would still
use drawterm and use the second machine to run
either a stand-alone fileserver or only a fs on a
cpu kernel.

- erik

[9fans] a few more misc. questions if you don't mind

[Corey]

I'm still assembling a mental map of a typical Plan 9 environment, which I"m
primarily using various scattered papers, docs and tutorials from the web in
addition to the man pages and docs on the system as my resources.

I'm currently focusing on the most basic case of standalone terminal -
I'm sure that is a rare situation, but it's the most simple, with the least
number of moving parts and thus the easiest platform to begin my
initial understanding of the rest of the system from.

So, here are a few questions - they're probably naive and suffer from an
obvious lack of perspective - but I'm sure getting useful input from you
all will greatly clarify some current shady spots in my understanding of
things; and I appreciate your patience.


Is there any purpose in running auth/wrkey on a standalone terminal?

What are the use-cases, if any, for logging into a standalone terminal as
user 'none'?

How do you delete a filesystem user from a standalone terminal? i.e., how
would I properly remove glenda? (would hand-editing /adm/users be
sufficient?)

On a standalone terminal, is there any useful purpose in having a default user
with +adm and +sys groups, along with a "normal" user who only belongs to
+sys? In what circumstances, for what purposes, would you create users who
belong to either, both, or none of those two groups (sys and adm) - again,
assuming a standalone terminal?


Also, not so much from the perspective of a standalone terminal, just general
questions:

What's the inter-relationship/difference between the following two commands:
'auth/keyfs' and 'auth/wrkey'? I've read their respective man pages, but I'm
still a bit hazy on what exactly are the roles of those two commands (assuming
no arguments are supplied).

Why is sysname= not documented in plan9.ini(8)? Just an oversight?

There seems to be somewhat of an ambiguity regarding "workstation-class"
terminals, vs. the "dumb" terminals - it seems not totally unreasonable for
someone to have their "personal workstation" setup as a cpu/auth terminal.
e.g. I _think_, that if one were simply wanting to get a _single_ plan 9 box
running on a typical moderately powered pc, that one should just go for a cpu
kernel running auth, vs. a term kernel? -- of course this is assuming one has
no interest in setting up a "proper" plan 9 environment for whatever reasons.



Many thanks!