[9fans] Canonical way to configure permanent remote cpu access

[9fans] Canonical way to configure permanent remote cpu access

[Luke Evans]

After many years of knowing about Plan 9 but apparently being too lazy to go find out about it, we now have it available on the Raspberry Pi (hurrah!).  The ease with which I can now install and learn about Plan 9 is now such that I have no excuse but to dive in :-)

Having got Plan 9 running on the Pi with the networking functioning and having also compiled the version of drawterm for Mac OS X cocoa, I'm now wishing to configure Plan 9 so that it permanently allows access from remote terminals for authenticated users.

I've found a way to achieve this temporarily from the console:
echo 'key proto=p9sk1 dom=plan9 user=glenda !password=MYPASS' >/mnt/factotum/ctl
aux/listen1 -t tcp!*!ncpu /bin/cpu -R &

This works great, but obviously does not survive a reboot of the system.  I'd like to know:
- Where's the right place to configure a permanent listener in the config/startup files?
- How should authentication be also permanently configured for any user that should be able to connect with drawterm?

Thanks in advance.

-- Luke

P.S. Apologies if this ends up being the second posting to the group on this subject, I used the Google Groups web front end to post and it announced that it may not have managed to post my original submission after quite a wait.  Trying again after several hours and no sign of my post.

Re: [9fans] Canonical way to configure permanent remote cpu access

[lucio]

> Having got Plan 9 running on the Pi with the networking functioning
> and having also compiled the version of drawterm for Mac OS X cocoa,
> I'm now wishing to configure Plan 9 so that it permanently allows
> access from remote terminals for authenticated users.

I'm going to shoot a bit from the hip here, but others will no doubt
correct my mistakes.

My immediate concern with the PI is that it's going to get into
trouble, eventually, with CF memory.  I would consider using rotating
rust if users are going to need it for storage, even add an external
file server if it's worthwhile.  I'm not convinced that one could set
up a CPU server with practically read-only storage, but that's not out
of the question if drawterm is the dominant access.

But you will need an auth server which you can piggyback on the CPU
server.  You need to read the relevant documents in /sys/doc.  The
secstore is optional, but very convenient; it is orthogonal to the
auth server, but only a CPU server will support it properly.

I rue the lack of support for 9p2000 in the conventional operating
systems, I would delegate all permanent storage to Plan 9 if I had a
choice.  Linux is an exception, but like windows it likes lots of disk
storage on the workstation, which is precisely what I would like to
eliminate (going back to my previous theme - drawterm gives you access
to local storage across many platforms, but I don't find that at all
appealing, which is why I use 9vx in preference to drawterm).

++L

Re: [9fans] Canonical way to configure permanent remote cpu access

[Richard Miller]

> My immediate concern with the PI is that it's going to get into
> trouble, eventually, with CF memory.

The pi has no built-in flash at all; its normal non-volatile storage
is a plug-in SD card.  I think the wear-levelling on these is sufficient
that you can run a normal fossil file system for quite a while before
it wears out.  And if it does wear out, you just plug in a new one.

Re: [9fans] Canonical way to configure permanent remote cpu access

[Charles Forsyth]

Does SD support the Trim request for wear-levelling?

Re: [9fans] Canonical way to configure permanent remote cpu access

[Richard Miller]

> Does SD support the Trim request for wear-levelling?

Not as far as I know.

It's tempting to think about erasing freed blocks in order to
aid the wear-levelling and speed up writing.  But it's not easy
to find the actual erase block architecture on a given card.

Re: [9fans] Canonical way to configure permanent remote cpu access

[lucio]

>> My immediate concern with the PI is that it's going to get into
>> trouble, eventually, with CF memory.
>
> The pi has no built-in flash at all; its normal non-volatile storage
> is a plug-in SD card.  I think the wear-levelling on these is sufficient
> that you can run a normal fossil file system for quite a while before
> it wears out.  And if it does wear out, you just plug in a new one.

That's good to know.  Back here in the sticks such information arrives
slowly in horse-drawn carriages like 9fans :-)

I don't remember how I managed to keep up to date, or when the
slipping back started.  Probably when my friends started leaving South
Africa back in the 1990s.

++L

Re: [9fans] Canonical way to configure permanent remote cpu access

[Anthony Sorace]

> I think the wear-levelling on these is sufficient that you can run a
> normal fossil file system for quite a while before it wears out.

Or, of course, just don't run a local file system at all. This is Plan 9,
after all. Using the fs in the basement has worked great for me
throughout. You then free up the RAM that would otherwise be
devoted to the fs (and that's fixed size on the pi). Maybe not
something you can do today if this is your first Plan 9 system,
but worth keeping in mind.

Last night, as part of a few experiments, I connected a 15GB
external spinning HD over USB (with kfs on it). It's funny to see
the actual computer dwarfed by the physical size of the disk.

Re: [9fans] Canonical way to configure permanent remote cpu access

[Bakul Shah]

On Mon, 10 Dec 2012 10:41:56 EST Anthony Sorace <a@9srv.net>  wrote:
> > I think the wear-levelling on these is sufficient that you can run a
> > normal fossil file system for quite a while before it wears out.
>
> Or, of course, just don't run a local file system at all. This is Plan 9,
> after all. Using the fs in the basement has worked great for me
> throughout. You then free up the RAM that would otherwise be
> devoted to the fs (and that's fixed size on the pi). Maybe not
> something you can do today if this is your first Plan 9 system,
> but worth keeping in mind.

The combination of plan9 + the low cost Pi opens up new
possibilities where other configurations can make sense.  For
instance, sensor data collection with periodic syncing.  plan9
can make a nice embedded os. Another example: I can use a
pi-dock (pi + atrix lapdock) for hours on an airplane given
atrix's (supposed) 36 Wh battery.  There is no one true way.

Re: [9fans] Canonical way to configure permanent remote cpu access

[hiro]

is that allowed to tinker with terrorist arms on flight in america?

On 12/10/12, Bakul Shah <bakul@bitblocks.com> wrote:
> On Mon, 10 Dec 2012 10:41:56 EST Anthony Sorace <a@9srv.net>  wrote:
>> > I think the wear-levelling on these is sufficient that you can run a
>> > normal fossil file system for quite a while before it wears out.
>>
>> Or, of course, just don't run a local file system at all. This is Plan 9,
>> after all. Using the fs in the basement has worked great for me
>> throughout. You then free up the RAM that would otherwise be
>> devoted to the fs (and that's fixed size on the pi). Maybe not
>> something you can do today if this is your first Plan 9 system,
>> but worth keeping in mind.
>
> The combination of plan9 + the low cost Pi opens up new
> possibilities where other configurations can make sense.  For
> instance, sensor data collection with periodic syncing.  plan9
> can make a nice embedded os. Another example: I can use a
> pi-dock (pi + atrix lapdock) for hours on an airplane given
> atrix's (supposed) 36 Wh battery.  There is no one true way.
>
>

Re: [9fans] Canonical way to configure permanent remote cpu access

[Richard Miller]

The canonical way to make your Plan 9 machine accessible to multiple users
is to make it into a cpu server.

The Plan 9 wiki has instructions for doing this:

See hget http://www.plan9.bell-labs.com/wiki/plan9/Configuring_a_Standalone_CPU_Server/index.html

On the raspberry pi, you'll find an already-built cpu kernel in 9picpu
on the boot partition, and a cmdline-cpu.txt file with essential boot
parameters.

The wiki has lots of other useful information.  For the full Plan 9
experience, you can access the wiki directly instead of via the
web interface.  In acme, open the file /acme/wiki/guide, and use
the middle mouse button to execute first 'Local 9fs wiki' and
then 'Wiki /mnt/wiki'.

Re: [9fans] Canonical way to configure permanent remote

[Luke Evans]

Thanks for the pointers Richard.  Let me also take the opportunity to thank you for your efforts on getting Plan 9 onto the Pi.  

I had come across that linked doc, but wasn't sure that was what I was looking for.  I'll do a more thorough reading.

One of the challenges I'm finding with my early foray into Plan 9 is that there's quite a lot of reference material, a fair number of summaries and overviews (especially the various papers), a number of introductory videos, but it's difficult to navigate everything as a neophyte from an orientation and set-up task point of view.  The approach I'm taking is to 'swim about' in the materials, gradually learning the nomenclature and purposes of various bits and pieces, in the hope that the overall map of things will gradually piece itself together in my head.

Fantastic that you've already provided a 'cpu' kernel setup.  I saw this very early on when browsing the image, but had absolutely no idea what purpose it served.  It had looked like the basic system had everything it needed for this compared to my early reading of online docs, but I guess it is a sufficiently different thing.

Now that my interest is kindled, I had considered installing Plan 9 on my old G5 Mac, but it looks like the Mac/PowerPC version was never completed... unless somebody knows different.


On Monday, December 10, 2012 3:23:18 AM UTC-8, Richard Miller wrote:
> The canonical way to make your Plan 9 machine accessible to multiple users
> 
> is to make it into a cpu server.
> 
> 
> 
> The Plan 9 wiki has instructions for doing this:
> 
> 
> 
> See hget http://www.plan9.bell-labs.com/wiki/plan9/Configuring_a_Standalone_CPU_Server/index.html
> 
> 
> 
> On the raspberry pi, you'll find an already-built cpu kernel in 9picpu
> 
> on the boot partition, and a cmdline-cpu.txt file with essential boot
> 
> parameters.
> 
> 
> 
> The wiki has lots of other useful information.  For the full Plan 9
> 
> experience, you can access the wiki directly instead of via the
> 
> web interface.  In acme, open the file /acme/wiki/guide, and use
> 
> the middle mouse button to execute first 'Local 9fs wiki' and
> 
> then 'Wiki /mnt/wiki'.

Re: [9fans] Canonical way to configure permanent remote

[Richard Miller]

> Fantastic that you've already provided a 'cpu' kernel setup.

In fact the 9pi distribution image is set up so that you can use it
"headless" just by copying cmdline-cpu.txt to cmdline.txt and editing
config.txt to change 'kernel=9pi' to 'kernel=9picpu'.  You can then
connect into it with the cpu command from another Plan 9 system (or
9vx/p9p/inferno), or with drawterm.  Initially, the cpu authid and
password are pi and raspberry; you'll want to change those with
aux/wrkey.