Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?

[Frank D. Engel, Jr.]

I for one have received quite a bit of help from this and the related 
9front mailing list when I was getting started with 9front, but then I 
had more targeted questions as I had been doing what I could with 
reading man pages and other available documentation and mostly needed to 
fill in a few gaps where I was struggling to find something specific; in 
some cases the documentation I was looking at was out of date.


I concur that there is not a problem with the lists in that regard; 
there are people here who are generally willing to help fill in gaps in 
understanding when they can see that you are putting in the effort 
yourself first.  They are not here to teach you from the ground up, 
however - this is not a high school course where you are starting from 
zero and being walked through the material step by step.  Start by 
studying the materials (yourself) which are available and try to 
understand as much as you can from what is already out there.  Come back 
here when you get stuck with something you can't figure out on your own.



On 8/4/24 02:59, sirjofri wrote:

04.08.2024 03:18:37 kalona.ayeli...@fastmail.us:

I'm not a troll; frustrated, perhaps. I just don't understand this culture. I 
don't think the issue lies with LLMs, but rather with an unwillingness to 
cooperate unless there's payment involved. I've never encountered an 
open-source community quite like this. Creating a separate mailing list to 
avoid answering questions is, to say the least, unusual. I suppose it can be 
seen as a safe zone for those who prefer not to assist newcomers. To me, it 
feels elitist.

LLMs: others already answered a lot, and I think I made my point clear enough 
already.

Payment: I think you got this wrong. It's not about the money, it's about 
effort. Expecting effort from others is something different than showing effort 
from yourself. People will likely help you if you show effort in your questions 
and your work (see many examples on this mailing list). Copy-pasting LLM 
content without any rework and validation is not showing effort, it's just 
expecting others to invest their time reading and answering.

You can expect effort from others by paying money, that's how companies work. 
There is a reasonable amount of bounties in the plan 9 community, from smaller 
lower-priced projects to larger projects.

Elitist new mailing list: I understand this feeling. I heard of this thing the 
first time and it gives another Super Secret Society of Selected Plan 9 People 
vibes we got from p9f in the beginning. This vibe got lost when p9f started 
doing their thing and we built some trust. I just hope that (1) they don't 
destroy this trust, (2) they actively search the community for selected mailing 
list members to invite so it can grow somewhat naturally without keeping that 
SSSoSP9P feel, (3) the group will open at some point or at least become 
publicly readable. Since the member board of p9f is quite good (people from 
basically all relevant communities) I have some hope.


What I've learned is that there's a significant cultural gap for newcomers, 
with an unspoken social contract and various hidden challenges.

Yes, that could be true. Plan 9 is not a beginner friendly system and users are 
expected to learn a lot, by reading the papers, the manuals, sometimes reading 
the source. Ideally (and sometimes required) by using the software. Then you 
can ask real questions, discuss real problems, give real answers. I don't think 
this is an issue within the community, see many other threads.

It's also highly recommended that you follow along other threads and learn how 
people treat each other and how they talk to each other. It's very common in 
(online) communities to just lurk until you feel the moment.

I do think that we have some trolls, probably more than in other communities, 
at least based on their sizes. That's probably also because of how plan 9 works 
and what it reflects in this modern world (we don't follow modern trends).


I'm simply seeking a friendly Plan 9 group where people genuinely enjoy helping 
newcomers.

The friendliest that I know is the 9fans discord. There's rarely heavy 
discussion going on, only people taking about general topics and people sharing 
their experiences and work and others encouraging each other. You might want to 
give this a try.


I see some people get treated well and others are treated poorly.  If someone asks a 
simple question, you give the person a pass. If someone asks a hard question, then you 
treat the person badly. The lesson there is "Don't ask hard questions." That is 
how I view it. If there are better Plan 9 groups out there, then I'd like to join that 
group.

Hard questions require more work to ask. It's quite common to collect your 
thoughts, gather lots of information, build knowledge and test things out 
before asking the question. Depending on the topic that can take a day or a 
week, sometimes more. Oftentimes you have to ask some 

Re: [9fans] different users for different system roles

[Frank D. Engel, Jr.]

I'm not sure what the prevailing wisdom on this is at this time, but for 
whatever it may be worth[less], my own small cluster I have set up with 
a separate host owner per system role (one for the file server, one for 
the auth server, and one used by both of my CPU servers).  I'm not 
currently using venti.



On 2/10/23 3:15 AM, Marco Feichtinger wrote:

If you have a grid with multiple machines, each with a dedicated system role,
should each system role get his own user?
Like one user for file servers, one for auth, one for venti, and one for cpu 
servers.
Is there any point in doing that or is it better to only use one user (bootes)
on all these machines?

-marco



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T690e4304847a34e4-Ma64e1cb7fc9ae382404faba9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[Frank D. Engel, Jr.]

The compiler appears to be called 7c.

adr, looking at the original email on this thread, it is not very clear 
what you are trying to ask?



On 5/21/22 12:39 PM, o...@eigenstate.org wrote:

Quoth Aram Hăvărneanu :

Since Charles wrote the arm64 compiler, he can call it whatever he wants.


aaarch64



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M9469a817902ca1783560b9c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front, git and mercurial.

[Frank D. Engel, Jr.]

I didn't even notice until now that there was a dedicated 9front list - 
I will try to subscribe to that shortly and move the conversation there.


Not sure that I understand how to determine which revision I am on - 
more familiar with svn than either hg or git - if I run "hg log" within 
/sys/src the first two lines say:



changeset: 8493:c8bec6f5ee1e

tag: tip


Does that answer the question, or how do I go about obtaining that?



On 5/18/22 2:30 PM, Kurt H Maier via 9fans wrote:

On Wed, May 18, 2022 at 02:12:47PM -0400, Frank D. Engel, Jr. wrote:

Related question I can't seem to track down an answer to:

I have a 9front cluster which was set up back when Mercurial was used,
so that is what sysupdate is looking for.

I finally realized that I am no longer seeing updates because 9front
switched to git.

How does one go about upgrading an existing 9front install to pull
updates from git instead of hg?

sysupdate should have seamlessly moved you to git.  what mercurial
revision is your stuff currently running?

this will be a longish debugging session so for the rest of it we should
probably move to the 9front mailing list, since 9fans at large might not
appreciate the traffic.

khm


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7dfa66085e395bcb-Mb037360ea191ed4fde0a87aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front, git and mercurial.

[Frank D. Engel, Jr.]

Related question I can't seem to track down an answer to:

I have a 9front cluster which was set up back when Mercurial was used, 
so that is what sysupdate is looking for.


I finally realized that I am no longer seeing updates because 9front 
switched to git.


How does one go about upgrading an existing 9front install to pull 
updates from git instead of hg?


When I try running the manual commands to pull from git it (logically) 
complains that it is not a git repository, but I am not finding any 
clear instructions on how to go about making this switch on an existing 
install?



On 6/14/21 3:13 PM, o...@eigenstate.org wrote:

Quoth Tony Mendoza :

Quick question (or maybe not), but how are these being hosted?   Is this done 
on a cloud provider vm platform?   Or is this being done in a traditional DC 
using real hardware?

Just curious to know how this is being done because I would like to do 
something similar.

Currently, it's hosted on vultr, but there are
a number of hosts that you can use.

As far as how it's actually done:

Git goes over git/serve in /rc/bin/service:

 cpu% cat /rc/bin/service/tcp9418
 #!/bin/rc
 exec git/serve -r/usr/git

the '-r' path is implicitly prepended on to
any repositories that are cloned, so eg:

 git/clone git://host.com/repo/path

clones

 /usr/git/repo/path

The authenticated protocol, hjgit, is the same
as the unauthenticated git:// protocol, but with
'tlssrv -a' wrapping the connection to handle auth
and encryption. The '-w' flag on git/serve enables
writing to the repo.

 cpu% cat /rc/bin/service/tcp17021
 #!/bin/rc
 exec tlssrv -a /bin/git/serve -wr/usr/git

Our encrypted 'gits://' extension is the same,
but with a cert, and its key in factotum:

 cpu% cat /rc/bin/service/tcp9419
 #!/bin/rc
 exec tlssrv -c/sys/lib/tls/git/git.cert /bin/git/serve -r/usr/git

That gets you a fully functional git server,
that hosts its code in /usr/git.

The website is served using tcp80 and execfs:

 cpu% cat /bin/cpurc.local
 auth/none execfs -s git.execfs /sys/lib/tcp80/gitrules

 cpu% cat /rc/bin/service/tcp80
 #!/bin/rc
 # some ns trickery to allow serving static data,
 # we can probably clean this up.
bind /usr/web /mnt/static
mount /srv/git.execfs /usr/web
bind /mnt/static /usr/web/static
rfork n
exec /bin/tcp80

And the code for the web ui is more or less a modified
version of this code:

http://shithub.us/ori/shithub/HEAD/files.html

There's also a more minimal proof of concept that I
did before phil9 ran with it and improved it here:

http://shithub.us/ori/git9/HEAD/extra/gitls/f.html

It's less complete, but probably easier to read and
understand.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7dfa66085e395bcb-M7a7dc8eefad0d619ba65c04a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[Frank D. Engel, Jr.]

Students who rely on that will never really learn.

From my perspective, most supposedly modern systems have been a bigger 
waste of time than some of the older ones.


Windoze, Linux, etc. in some ways still have not caught up to features 
that Multics and Plan 9, among other systems, had to offer decades ago - 
and they are bolting things on that came naturally to the older systems, 
so they don't work very well in contrast.  They build complexity on 
complexity instead of leveraging a simple consistent approach that can 
actually be understood.


Multics was in some ways a conceptual precursor to today's "cloud 
computing" (in the sense that it was engineered to be a multi-tenant 
system with separate projects being billed for the resources they used), 
while also introducing the world to concepts such as access control 
lists (ACLs).


Plan 9 offers a level of network transparency and process 
interoperability that most of our "modern" systems don't seem to be able 
to get right, not to mention having been well-designed for working 
transparently across systems with differing architectures (SPARC, MIPS, 
etc.) out of a common file system.


If a student just wants to write business logic for some big company 
doing batch processing or wants to create web sites or some such then 
sure, let them stick with what is out there at the moment.  If they 
really want to understand computers and computer programming, they 
should try to learn from the ground up.  Being limited to "modern" 
systems won't get them nearly as far as being exposed to a range of 
ideas and different approaches that have been taken over time.



 “Those who don't know history are doomed to repeat it.”

―Edmund Burke


On 2/4/22 12:48 PM, Kurt H Maier via 9fans wrote:

On Fri, Feb 04, 2022 at 09:30:26AM -0600, Kent R. Spillner wrote:

In your experience do students appreciate being told what's best for them?  ;)


In my experience needing to be told what's best for them is the defining
characteristic of a student

khm


--
9fans: 9fans
Permalink:https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mebbbc70d0d122fd7d3ec1dfc
Delivery options:https://9fans.topicbox.com/groups/9fans/subscription


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M7f837fca51d6819b2c70e520
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Frank D. Engel, Jr.]

Ok, sorry for the triple-post, but since I can't seem to find that man 
page or usb/ether on my 9front install, I should probably provide my source:


http://man.cat-v.org/plan_9/4/usb


On 1/29/22 7:14 AM, Frank D. Engel, Jr. wrote:

Evidently there are two major standards:

CDC, an official USB standard - specifications here: 
https://www.usb.org/sites/default/files/CDC_EEM10.pdf


RNDIS, a proprietary Microsoft protocol that Linux also provides 
drivers for: https://en.wikipedia.org/wiki/RNDIS



The man page for usb/ether on plan9 indicates that CDC support is 
already there but has not been tested; it may be that a good starting 
point is in place and getting this tested would provide the required 
support on the host side of things?



On 1/29/22 6:56 AM, Frank D. Engel, Jr. wrote:
Apparently Linux includes drivers for tunneling IP over a USB 
connection (possibly to support mobile phones?  not sure...)


Making host drivers compatible with these (if not already available) 
to share an IP stack and creating the equivalent device-side support 
for the "blocks" would allow 9P to be tunneled not only from these 
devices but also from other existing solutions in a wider variety of 
ways, also making it easier to connect those devices to Linux as 
there are ways to talk 9P from there.


That may open up some additional flexibility?


On 1/29/22 4:16 AM, Skip Tavakkolian wrote:

I've been working on something along those lines for IoT management
and networking. Here's my laundry list of architectural and
implementation pieces:

1. authentication: (a) tie devices to owner/user (b) authenticate
users against third parties (via OIDC/SAML2, etc), (c) let the
authenticated user provide the credentials to authenticate and use
their devices via a namespace that follows an established convention
(e.g. /joe/iot/0/secret).
2. device and capability discovery is a bootstrapping process,
starting with a namespace that describes the availability of devices
and features (analogous to '#c/drivers')
3. namespace to discover how to present the data from a particular
source (e.g. a steam gauge widget would need to understand the
namespace exported by a pressure sensor)
4. 9p libraries including fan-in, fan-out capability (i.e. mount,
9pserve) for FreeRTOS, Mbed OS,  ThreadX, Zephyr
5. libraries to localize user↔device 9p traffic, while keeping
authentication centralized (e.g. how @tailscale works)

Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and
actuators, until standards and conventions are established.

For hardware, targeting things like SAMD21 boards seem more
appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic
nRF52840 boards are below $10 and include the hardware to establish
root-of-trust.


On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah  wrote:

The idea:
- make it very easy to create hardware gadgets by
   providing a firmware/hardware building block that
   talks 9p on the host interface side & interfaces
   with device specific hardware.

- use a "universal" 9p driver on the host side that
   allows access to any such 9p device even from a shell.

- provide a standard way to find out device capabilities.

- together they provide a plug-and-play setup.

Example: connect an LED and a current sensor to this
9p device, other necessary hardware, add a few config
bits and plug this device kn]]into a host. Now you should
be able to turn on/off the light or sense its state.

Similarly you should be able to control a stepper motor
servo, cameras, microphones, other actuators, sensors,
IO etc. Eventually you should be able to snap together
enough of these components to build larger assemblies
such as a 3D printer.

Another example: a "hub" to multiplex such downstream
devices and make them available to a host.

This will probably have to ride on USB first. A verilog
implementation would be useful in an FPGA!

Would this be a useful component? If such a thing were
available, what would you want to build with it?

Do you think 9p is the right protocol for this?

Ideally
- connect anything to anything
- authenticated connections
- drive the device through a shell script
- no new low level drivers
- self-identifying devices with help and command syntax
- signicantly eases the task of creating new h/w devices.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2

Delivery options: https://9fans.topicbox.com/groups/9fans/subscription



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M06b50380a603d3037a973a37
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Frank D. Engel, Jr.]

Evidently there are two major standards:

CDC, an official USB standard - specifications here: 
https://www.usb.org/sites/default/files/CDC_EEM10.pdf


RNDIS, a proprietary Microsoft protocol that Linux also provides drivers 
for: https://en.wikipedia.org/wiki/RNDIS



The man page for usb/ether on plan9 indicates that CDC support is 
already there but has not been tested; it may be that a good starting 
point is in place and getting this tested would provide the required 
support on the host side of things?



On 1/29/22 6:56 AM, Frank D. Engel, Jr. wrote:
Apparently Linux includes drivers for tunneling IP over a USB 
connection (possibly to support mobile phones?  not sure...)


Making host drivers compatible with these (if not already available) 
to share an IP stack and creating the equivalent device-side support 
for the "blocks" would allow 9P to be tunneled not only from these 
devices but also from other existing solutions in a wider variety of 
ways, also making it easier to connect those devices to Linux as there 
are ways to talk 9P from there.


That may open up some additional flexibility?


On 1/29/22 4:16 AM, Skip Tavakkolian wrote:

I've been working on something along those lines for IoT management
and networking. Here's my laundry list of architectural and
implementation pieces:

1. authentication: (a) tie devices to owner/user (b) authenticate
users against third parties (via OIDC/SAML2, etc), (c) let the
authenticated user provide the credentials to authenticate and use
their devices via a namespace that follows an established convention
(e.g. /joe/iot/0/secret).
2. device and capability discovery is a bootstrapping process,
starting with a namespace that describes the availability of devices
and features (analogous to '#c/drivers')
3. namespace to discover how to present the data from a particular
source (e.g. a steam gauge widget would need to understand the
namespace exported by a pressure sensor)
4. 9p libraries including fan-in, fan-out capability (i.e. mount,
9pserve) for FreeRTOS, Mbed OS,  ThreadX, Zephyr
5. libraries to localize user↔device 9p traffic, while keeping
authentication centralized (e.g. how @tailscale works)

Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and
actuators, until standards and conventions are established.

For hardware, targeting things like SAMD21 boards seem more
appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic
nRF52840 boards are below $10 and include the hardware to establish
root-of-trust.


On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah  wrote:

The idea:
- make it very easy to create hardware gadgets by
   providing a firmware/hardware building block that
   talks 9p on the host interface side & interfaces
   with device specific hardware.

- use a "universal" 9p driver on the host side that
   allows access to any such 9p device even from a shell.

- provide a standard way to find out device capabilities.

- together they provide a plug-and-play setup.

Example: connect an LED and a current sensor to this
9p device, other necessary hardware, add a few config
bits and plug this device kn]]into a host. Now you should
be able to turn on/off the light or sense its state.

Similarly you should be able to control a stepper motor
servo, cameras, microphones, other actuators, sensors,
IO etc. Eventually you should be able to snap together
enough of these components to build larger assemblies
such as a 3D printer.

Another example: a "hub" to multiplex such downstream
devices and make them available to a host.

This will probably have to ride on USB first. A verilog
implementation would be useful in an FPGA!

Would this be a useful component? If such a thing were
available, what would you want to build with it?

Do you think 9p is the right protocol for this?

Ideally
- connect anything to anything
- authenticated connections
- drive the device through a shell script
- no new low level drivers
- self-identifying devices with help and command syntax
- signicantly eases the task of creating new h/w devices.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2

Delivery options: https://9fans.topicbox.com/groups/9fans/subscription



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M2bfae57976b54c9111775826
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Frank D. Engel, Jr.]

Apparently Linux includes drivers for tunneling IP over a USB connection 
(possibly to support mobile phones?  not sure...)


Making host drivers compatible with these (if not already available) to 
share an IP stack and creating the equivalent device-side support for 
the "blocks" would allow 9P to be tunneled not only from these devices 
but also from other existing solutions in a wider variety of ways, also 
making it easier to connect those devices to Linux as there are ways to 
talk 9P from there.


That may open up some additional flexibility?


On 1/29/22 4:16 AM, Skip Tavakkolian wrote:

I've been working on something along those lines for IoT management
and networking. Here's my laundry list of architectural and
implementation pieces:

1. authentication: (a) tie devices to owner/user (b) authenticate
users against third parties (via OIDC/SAML2, etc), (c) let the
authenticated user provide the credentials to authenticate and use
their devices via a namespace that follows an established convention
(e.g. /joe/iot/0/secret).
2. device and capability discovery is a bootstrapping process,
starting with a namespace that describes the availability of devices
and features (analogous to '#c/drivers')
3. namespace to discover how to present the data from a particular
source (e.g. a steam gauge widget would need to understand the
namespace exported by a pressure sensor)
4. 9p libraries including fan-in, fan-out capability (i.e. mount,
9pserve) for FreeRTOS, Mbed OS,  ThreadX, Zephyr
5. libraries to localize user↔device 9p traffic, while keeping
authentication centralized (e.g. how @tailscale works)

Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and
actuators, until standards and conventions are established.

For hardware, targeting things like SAMD21 boards seem more
appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic
nRF52840 boards are below $10 and include the hardware to establish
root-of-trust.


On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah  wrote:

The idea:
- make it very easy to create hardware gadgets by
   providing a firmware/hardware building block that
   talks 9p on the host interface side & interfaces
   with device specific hardware.

- use a "universal" 9p driver on the host side that
   allows access to any such 9p device even from a shell.

- provide a standard way to find out device capabilities.

- together they provide a plug-and-play setup.

Example: connect an LED and a current sensor to this
9p device, other necessary hardware, add a few config
bits and plug this device kn]]into a host. Now you should
be able to turn on/off the light or sense its state.

Similarly you should be able to control a stepper motor
servo, cameras, microphones, other actuators, sensors,
IO etc. Eventually you should be able to snap together
enough of these components to build larger assemblies
such as a 3D printer.

Another example: a "hub" to multiplex such downstream
devices and make them available to a host.

This will probably have to ride on USB first. A verilog
implementation would be useful in an FPGA!

Would this be a useful component? If such a thing were
available, what would you want to build with it?

Do you think 9p is the right protocol for this?

Ideally
- connect anything to anything
- authenticated connections
- drive the device through a shell script
- no new low level drivers
- self-identifying devices with help and command syntax
- signicantly eases the task of creating new h/w devices.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mf859fd621824fda00d5f5c43
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[Frank D. Engel, Jr.]

I was actually thinking of a somewhat different approach to providing a 
more modernized user interface.


Consider that rio currently exports the required files for each window, 
which provide the same interface as the display driver underneath them.


Now consider adding a new "control manager" file server which exports a 
filesystem to manage individual controls arranged inside a window (or at 
the root level if not running rio or other window manager).  Create a 
directory inside the exported filesystem to add a new control.  Inside 
the directory would automatically appear those same files that are 
exported by rio or by vga, but specific to the control.  There would 
also be a file for controlling the scaling and placement of child 
controls of the control in some defined manner, allowing "layout 
managers" to be defined (such a file would also appear at the root).  
Add a new subdirectory within the directory of a control to create a 
child control.


Individual types of controls can then be implemented as separate 
programs or libraries which would interact with those basic elements to 
provide the specific functionality of a control or layout manager - 
standard controls to be provided would be the typical buttons, 
checkboxes, text fields, etc., while layout managers would arrange their 
children in specific patterns, such as vertically stacked, horizontally 
stacked, grids, etc.


This mechanism is an extensible way to cover the provision of "modern" 
controls within a window, even when still using rio, and is true to the 
"everything is a filesystem" nature of plan9.



A second step would be to create an alternative to rio which would do 
the same job, but with title bars and the like.



Some kind of file management / desktop environment application could 
then be built on top of these foundations.  Users could mix and match 
the use of applications based on the control manager within the existing 
rio environment, and the existing command line / rio applications such 
as acme would work unmodified with the new window manager but have 
"modern" title bars and some sort of "minimize" and possibly "full 
screen" functionality, maybe with a dock of some kind.



As far as I can tell this would require practically zero core changes to 
the system as it is built entirely on existing primitives already offered.



On 1/27/22 9:03 PM, ibrahim via 9fans wrote:
I developed a kiosk version of plan9 (based on 9front and legacy9) and 
am about to develop a single user desktop system. Those can coexist 
with the existing plan9 system.


I named the new service targets kiosk and desktop. Both work without rio.

Currently I used initdraw, initmouse, initkeyboard, loadimage, 
flushimage from devdraw to avoid breaking of compatibility with the 
existing plan9 systems while the whole rendering of the windows is 
framebuffer based. Instead of the usual plan9 fonts I used regular 
truetypefonts.


So my suggestions would be :

1) Define new service targets kiosk and desktop (Currently I do this 
in init or /user/.../lib/profile. This makes it possible for a user to 
start an alternative window manager or even a single applicaton (kiosk 
service) with a modern look and feel.


2) Define a layer between vga and devdraw perhaps vgafb which improves 
the performance for frame buffer rendered window managers.


3) Define events for mouse, keyboard, touchpad, windows which is based 
on notes managed by light threads inside the client app.


Those three steps would protect the existing plan9 from changes and 
make it possible to only use the kernel, libraries, tools from 
alternative user interfaces. Plan9 is one of the smallest operating 
systems accompanied with a compiler and an abstraction which would 
attract much more developers and users if it had a modern user 
interface. We don't have to throw away anything and rio would even be 
able to run inside a window of a modern desktop.


Plan9 has everything necessary to make it an attractive system not 
only for a handful of developers. The compilers, the portability, 9p, 
unicode, direct support for video hardware and its small size are 
fascinating.


The only reason why it isn't recognized by more people is its GUI. I 
don't get the reason why we wouldn't extent it so we can use other 
GUI's while keeping the existing in respect of the developers who 
created this system.


I will integrate this changes but I would prefer staying fully 
compatible to the existing projects legacy9 and 9front even more I 
would prefer not forking any of them but sharing my parts as 
contributions.


What I need and what those changes need is a separation level between 
devdraw and the graphics hardware and a new event mechanism which can 
be based on notes or equals.


I'm not a native English speaker so excuse the many mistakes.

*9fans * / 9fans / see discussions 
 + participants 

Re: [9fans] Boot CD chokes

[Frank D. Engel, Jr.]

Partially to answer an earlier question and partially to emphasize just 
how different Plan 9 is: you "log out" by rebooting.



On 12/28/21 12:35 PM, Duke Normandin wrote:

On Tue, 28 Dec 2021 09:28:52 -0800
Eli Cohen  wrote:


if you're not accustomed to plan 9

Worst than that! I don't know squat about it. Just manage to
install it 10 minutes ago. I know Unix though and that's where I'm
getting hung up.

--
Duke
** Text only please. Bottom post is best for me **


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5888591114a7cf34-Mec7ddd4494077c06dcc4cfaa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Frank D. Engel, Jr.]

Maybe /dev/gpgpu (general-purpose GPU) would be more to the point?


On 8/22/21 2:50 PM, sirjofri wrote:


22.08.2021 20:25:12 o...@eigenstate.org:


Quoth sirjofri :


22.08.2021 18:41:06 o...@eigenstate.org:
Basically do software rendering on the GPU?


Yes. Or software neural net evaluation on the GPU.
Or software video decoding on the GPU. Or software
image transforms on the GPU. Or software signal
processing on the GPU.

If there's an interface to be selected, it needs
to be tractable to implement, *and* general purpose
enough for everything that wants to use it.

Well, it's totally possible. Even Nanite (the new system in Unreal 
Engine

5) has its own rasterizer and I believe even its own base pass. Also
Lumen does software rendering for global illumination.

But for serious 3d AAA stuff we'd have to consider: Lumen is for 
next-gen

GPUs and Nanite for newer GPUs. We'll never reach their quality in
realtime if we don't use the GPU features (built-in rasterizer, ...) to
have enough free power for crazy software calculation.


By the time any code is written, next-gen GPUs will be
previous-gen GPUs.

General compute is what any hardware you buy a few years
from now will be doing -- and it's far more intersting
in terms of what capabilities it allows.


I like that /dev/compute approach, but may I suggest putting it below
another directory /dev/gpu/compute so we have the ability to add
/dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?


I think supporting those is a cost we should not pay. It's
fundamentally solving a less general problem, and adds a
lot of complexity for the potential of a small performance
boost.

We already have zero people sinking time into the slim
interface; sinking time into a fatter interface seems
like a bad idea.


Gotcha.

Maybe I'll find some time to implement some kind of gpufs or /dev/gpu
(if it's general purpose I'd suggest renaming compute to gpu since
"compute" could be anything. The computer does compute, wow.).

sirjofri


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mb1c40d6c9d3bca972decad36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] UTF-8 characters in acme

[Frank D. Engel, Jr.]

Seems rather unlikely considering that UTF-8 was originally invented for 
Plan 9?



Turns out it is the same as anywhere else in Plan 9 - tap ALT (not hold) 
then the letter x then the hex code for the rune you are trying to enter 
and a semicolon (if fewer than 6 hexadecimal nybbles).



Example:  ALT x 2 1 d 4 ;


There are shorter versions for some characters - see the man page 
keyboard (6) for details




On 9/7/21 10:24 AM, revcomni...@gmail.com wrote:

I was under the impression you could only use ASCII.
*9fans * / 9fans / see discussions 
 + participants 
 + delivery options 
 Permalink 
 



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0d54d4b593281935-M4479c3e7548c22fab86cfc0d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Frank D. Engel, Jr.]

While not necessarily unwelcome as a possibility, I don't think 
GPU-based drawing/gaming is as relevant to this discussion (or as 
important of a goal for Plan 9 / 9front) as is GPU compute (GPGPU).


The ability to leverage GPU resources across CPU servers for computation 
purposes would be of great benefit to the platform, and working out a 
driver interface by starting the process remotely via drawterm seems 
like a sensible step in that direction.


On 8/22/21 3:07 AM, sirjofri wrote:


22.08.2021 05:16:42 Eli Cohen :

deep learning is another interest of mine too. hardware support is a
big deal for that... some kind of support for GPUs would be nice.
people have discussed that for years... hardware drivers are difficult
and important to do correctly!

I always really liked the "XCPU" and drawterm type ideas of using
other OSes for their existing strengths along with Plan 9. maybe
drawterm could have a GPU device driver or something... that being
said I have sometimes found it ends up surprisingly easier doing it
all on Plan 9...


That's also something I thought about a few times already: drawterm
with GPU support. The only issue I see is, for realtime applications
like games the draw times would be network bound and thus pretty slow.
It would work for heavy GPU applications where almost no draw calls
will exist (no textures, very low poly meshes, ...), but for heavier
stuff we'd need to address that.

That's the benefit of a native driver: you could calculate the server
side (heavy CPU calculations) on a cpu server, the client/frontend
side (including draw calls) on a terminal and the pure graphics on the
GPU.

I'd still give the drawterm GPU a shot. Maybe I can set drawterm up
for compilation on my work PC (two GTX 1080Ti) and try figuring out
how to do all that stuff. However, I've never done graphics
applications on windows or somewhere else that uses OpenGL or DirectX
(I'd try OpenGL because portability), only written shaders so far.
I'll surely need some time (which is always rare as a game developer).

Btw I don't know the exact specifications for GPU usage for neural
networks. I assume it's all compute shaders? Maybe it's even a kinda
blackbox, put stuff in (draw call), read things out. I assume this can
work perfectly fine for draw times, depending on the data.

sirjofri


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-Ma12c6e769699f5c3b561fbf2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9f mention of 9front

[Frank D. Engel, Jr.]

I don't think the touchscreen technology has figured out how to 
distinguish between fingers yet.


The rio environment would need to identify if you were using finger 1, 2 
or 3 to tap on something so it would know if it was to move or resize 
the window, which context menu to open, etc...


Either that or you would need to replace rio with something more 
touchscreen-friendly, in the process losing much of what makes the Plan 
9 environment as unique as it is from a user interface perspective.


Most "modern" phones also lack a suitable keyboard to provide reasonable 
interaction with the command line (and it can be difficult to type 
efficiently on something that small anyway).



On 6/24/21 12:06 AM, Lucio De Re wrote:

The other oddity is the smart mobile computer we like to call a
"phone". Why is there no Plan 9 flavour running on at least some
flavour of it?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M84bef267275597c3ab44884a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front man page on ps doesn't seem to match up?

[Frank D. Engel, Jr.]

I see...

That certainly could have been made less clear :-)

Maybe it would have helped to have put "Syscall" in parenthesis or 
quotes or something; as it is it looks like the rest of the entries in 
the list and I took it to mean that "Syscall" (literally) could show up 
as a status.



Thank you!


On 9/16/20 11:15 PM, Alex Musolino wrote:

On my system (9front) ps(1) states:

Syscall   performing the named system call.

Which is what you're seeing.  For the complete list,
have a look here: /sys/src/9/port/systab.h:/sysctab/

--
Cheers,
Alex Musolino


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8abf4e1c9a4c42a7-Ma5cd5a47aa4f7f2b1f80480d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 9front man page on ps doesn't seem to match up?

[Frank D. Engel, Jr.]

I was looking at the list of possible process statuses in the man page 
for the ps command on 9front and there are several different statuses 
I'm seeing on my system that are not in the list.  I am seeing Pread, 
Await and Rendez on the majority of my processes and Pwrite and Open on 
a few and none of those are listed in the man page.


Any tips on where to find a more accurate/complete list?



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8abf4e1c9a4c42a7-M1b4c97fd912549b54cac5153
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pi cpu server

[Frank D. Engel, Jr.]

Thanks, auth/debug was indeed useful.

Somehow I missed the authdom= entry in /lib/ndb/local and it was 
complaining that it could not find an auth server for my authdom.


I added that and rebooted, and now all is well.


On 9/4/20 11:38 PM, o...@eigenstate.org wrote:

Thanks, that is what I was missing - I had them on separate lines.

Now I need to puzzle through this "tlsclient: auth_proxy: auth_proxy rpc
write: interrupted" error whenever I try to use rcpu to connect back to
the server as a different user (from a drawterm connection).  If I just
"rcpu" by itself it works, but "rcpu -u glenda" for example gives me
that error.

First, make sure that your auth server is actually set up and found
correctly -- auth/debug can help here. Note that you'll probably be
able to auth as hostowner even if your auth server is misconfigured.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc236964f02eb4e55-M0799e4fa5f6acc778d11f52e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] pi cpu server

[Frank D. Engel, Jr.]

Thanks, that is what I was missing - I had them on separate lines.

Now I need to puzzle through this "tlsclient: auth_proxy: auth_proxy rpc 
write: interrupted" error whenever I try to use rcpu to connect back to 
the server as a different user (from a drawterm connection).  If I just 
"rcpu" by itself it works, but "rcpu -u glenda" for example gives me 
that error.



On 9/4/20 6:38 PM, o...@eigenstate.org wrote:

I am trying to set up a standalone (sd card boot) 9front installation on
a Raspberry Pi 3 (using the pi3/4 image) to boot as a cpu server, but I
can't figure out where to put the service=cpu and bootargs=... options.

The pi uses /n/pidos instead of /n/9fat, and I tried placing these in
both config.txt and cmdline.txt within that mount, but they seem to be
ignored in both places, and I am not finding any documentation on this -
everything relevant seems to be written assuming the x64/amd64 situation...?


I don't currently have a pi that I can use, but I seem to remember that
cmdline.txt is the right place to put it, but you need to put all the
arguments on one line, instead of multiple lines.

Something like:

bootfile=9pi4 'nobootprompt=local!/dev/sdN0/fscache -a tcp!*!564' 
mouseport=none service=cpu ...



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc236964f02eb4e55-Mac55864bd50a6a8c7f05d619
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] pi cpu server

[Frank D. Engel, Jr.]

I am trying to set up a standalone (sd card boot) 9front installation on 
a Raspberry Pi 3 (using the pi3/4 image) to boot as a cpu server, but I 
can't figure out where to put the service=cpu and bootargs=... options.


The pi uses /n/pidos instead of /n/9fat, and I tried placing these in 
both config.txt and cmdline.txt within that mount, but they seem to be 
ignored in both places, and I am not finding any documentation on this - 
everything relevant seems to be written assuming the x64/amd64 situation...?




--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc236964f02eb4e55-M53c54fae0982454700e91b4a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with Interpretation

[Frank D. Engel, Jr.]

Thanks!

I built the file server using a 32-bit 386 kernel but I think 64-bit 
CWFS was used?  I will try to figure out somehow which block size was 
selected, and that gives me something to work with.


Looks like it is just under 1 GB used if I have the 4K block size, and 
just under 2 GB used if I have the 8K block size, of a 64.21 GB worm 
partition.



On 1/5/20 10:56 AM, Steven Stallion wrote:

I am trying to make sense of these numbers but having some difficulty
finding any documentation explaining them.

Your best bet is to read the source in /sys/src/cmd/cwfs; cwfs is a
ported version of the original file server, ie.  Ken's.


Can someone either point me to that documentation or walk me through how
to interpret this?

Ken's can be a little terse, but the out put is very meaningful; fsize
is what you care about in this context.  This is the number of blocks
used by the WORM.  Take this number and multiply it by RBUFSIZE to get
the number of bytes written to disk.  Assuming you're using a 64-bit
fileserver, this will be 8K by default (4K for 32-bit), but this
depends on the kernel you are using.

HTH,
Steve



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta16a4beaa5de93c0-M77210e62cd5d01afd0dd0b78
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Help with Interpretation

[Frank D. Engel, Jr.]

Hi, I am trying to learn how to work out the used/free space on the cwfs 
file systems on my 9front file server.



The plan 9 primary partition has the following sub-partitions:

9fat - 100MB

nvram - 512B

other - 12.84GB

fscache - 12.84GB

fsworm - 64.21GB


If I use con -C /srv/cwfs.cmd to run check I get the following output:

checking filsys: main
check free list
lo = 259217; hi = 260388
nfiles = 91523
fsize  = 261091
nused  = 224847
ndup   = 0
nfree  = 886
tfree  = 886
nfdup  = 0
nmiss  = 35356
nbad   = 0
nqbad  = 0
maxq   = 134348
base stack=3758091244
high stack=3758089744
deepest recursion=15


I am trying to make sense of these numbers but having some difficulty 
finding any documentation explaining them.



Can someone either point me to that documentation or walk me through how 
to interpret this?



Thank you!



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta16a4beaa5de93c0-M3099920baeb798d2451858fd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

I figured this one out...  I had missed adding the "-a tcp!*!564" option 
on the file server bootargs.


Now it is working!


On 12/18/19 6:57 PM, Frank D. Engel, Jr. wrote:

ok, I seem to have run into another one.

I now have the file server booting as a cpu server with authentication 
enabled, and am trying to net boot another host from there.


I have dhcpd and tftpd running on the file server; my /cfg/pxe/default 
looks like this:



bootfile=/386/9pc

bootargs=tls

auth=192.168.81.12

fs=192.168.81.10

mouseport=ps2intellimouse

monitor=vesa

vgasize=1440x900x32

*acpi=1


The entry in /lib/ndb/local is (with "..." being the actual MAC address):


sys=thinker ether=... ip=192.168.81.20

    dom=thinker.9cluster

    bootf=/386/9bootpxe



The "thinker" system is starting the plan9 kernel over the network (it 
has no local disk); I get prompted for a user account and for now am 
just using "glenda".  I enter the password I set for the auth server, 
for secstore, and for the filesystem on the file server (I used the 
same for each), and I am getting this on "thinker":



mount: mount /root: tls error

mount -c #s/boot /root: mount 145: mount


bootargs is (tcp, tls, il, local!device)[tls]


When this happens the file server console shows this:


/bin/aux/trampoline: dial net!$fs!9fs: connection rejected


I'm not sure if this means that the file server is rejecting the 
connection from the (currently) terminal, or what might be going 
on...  the "$fs" showing up on the file server console seems curious 
to me as I would have thought if that were coming from the terminal 
the "$fs" would have been translated from there?  Again not sure where 
to go from here...



I was originally having a problem with secstored not having a 
"factotum" file for the terminal to retrieve, but after having worked 
that one out it now stored a key in it (and is no longer asking me to 
set one) for my "dom=9cluster", so I did manage to get past that one.



I also noticed that if I retry from the bootargs prompt I get the 
additional message "ipconfig: dialicmp6: address in use", but I am 
guessing that is simply a leftover from the earlier attempt, and 
assuming I can safely ignore that...





On 12/16/19 4:40 PM, Frank D. Engel, Jr. wrote:

Thank you!


When I tried bringing it up as a cpu server with auth enabled it did 
indeed make it past the errors.


I'll see if I can work things out from there.


On 12/16/19 2:27 PM, cinap_len...@felloff.net wrote:

i believe that this is due to running a with service=terminal.
this causes factotum to be started as a client with no keys in it.

the p9any auth protocol starts by the server presenting a set of
keys, auth domains and protocols, which you wont have in this
case (no keys there). which is most likely the reason the whole
thing fails.

if you boot your fileserver with service=cpu, then when factotum starts
it will prompt you for authid and password which will be the 
credentials
of the hostowner (of the fileserver) which should have to match what 
you

have on the authentication server. this information can be stored in
nvram to avoid the prompt on boot.

even if it doesnt match the auth key for (that user) on the authserver,
the fileserver should be able to boot and mount its root filesystem
as factotum talks to itself in this scenario and having the same keys
on both sides.

its just about to fail when there are no keys at all.

i hope this makes sense.

--
cinap





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-M38b41bb53e4bc0dccad36a4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

ok, I seem to have run into another one.

I now have the file server booting as a cpu server with authentication 
enabled, and am trying to net boot another host from there.


I have dhcpd and tftpd running on the file server; my /cfg/pxe/default 
looks like this:



bootfile=/386/9pc

bootargs=tls

auth=192.168.81.12

fs=192.168.81.10

mouseport=ps2intellimouse

monitor=vesa

vgasize=1440x900x32

*acpi=1


The entry in /lib/ndb/local is (with "..." being the actual MAC address):


sys=thinker ether=... ip=192.168.81.20

    dom=thinker.9cluster

    bootf=/386/9bootpxe



The "thinker" system is starting the plan9 kernel over the network (it 
has no local disk); I get prompted for a user account and for now am 
just using "glenda".  I enter the password I set for the auth server, 
for secstore, and for the filesystem on the file server (I used the same 
for each), and I am getting this on "thinker":



mount: mount /root: tls error

mount -c #s/boot /root: mount 145: mount


bootargs is (tcp, tls, il, local!device)[tls]


When this happens the file server console shows this:


/bin/aux/trampoline: dial net!$fs!9fs: connection rejected


I'm not sure if this means that the file server is rejecting the 
connection from the (currently) terminal, or what might be going on...  
the "$fs" showing up on the file server console seems curious to me as I 
would have thought if that were coming from the terminal the "$fs" would 
have been translated from there?  Again not sure where to go from here...



I was originally having a problem with secstored not having a "factotum" 
file for the terminal to retrieve, but after having worked that one out 
it now stored a key in it (and is no longer asking me to set one) for my 
"dom=9cluster", so I did manage to get past that one.



I also noticed that if I retry from the bootargs prompt I get the 
additional message "ipconfig: dialicmp6: address in use", but I am 
guessing that is simply a leftover from the earlier attempt, and 
assuming I can safely ignore that...





On 12/16/19 4:40 PM, Frank D. Engel, Jr. wrote:

Thank you!


When I tried bringing it up as a cpu server with auth enabled it did 
indeed make it past the errors.


I'll see if I can work things out from there.


On 12/16/19 2:27 PM, cinap_len...@felloff.net wrote:

i believe that this is due to running a with service=terminal.
this causes factotum to be started as a client with no keys in it.

the p9any auth protocol starts by the server presenting a set of
keys, auth domains and protocols, which you wont have in this
case (no keys there). which is most likely the reason the whole
thing fails.

if you boot your fileserver with service=cpu, then when factotum starts
it will prompt you for authid and password which will be the credentials
of the hostowner (of the fileserver) which should have to match what you
have on the authentication server. this information can be stored in
nvram to avoid the prompt on boot.

even if it doesnt match the auth key for (that user) on the authserver,
the fileserver should be able to boot and mount its root filesystem
as factotum talks to itself in this scenario and having the same keys
on both sides.

its just about to fail when there are no keys at all.

i hope this makes sense.

--
cinap





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mb08127daf7703de537047e02
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

Thank you!


When I tried bringing it up as a cpu server with auth enabled it did 
indeed make it past the errors.


I'll see if I can work things out from there.


On 12/16/19 2:27 PM, cinap_len...@felloff.net wrote:

i believe that this is due to running a with service=terminal.
this causes factotum to be started as a client with no keys in it.

the p9any auth protocol starts by the server presenting a set of
keys, auth domains and protocols, which you wont have in this
case (no keys there). which is most likely the reason the whole
thing fails.

if you boot your fileserver with service=cpu, then when factotum starts
it will prompt you for authid and password which will be the credentials
of the hostowner (of the fileserver) which should have to match what you
have on the authentication server. this information can be stored in
nvram to avoid the prompt on boot.

even if it doesnt match the auth key for (that user) on the authserver,
the fileserver should be able to boot and mount its root filesystem
as factotum talks to itself in this scenario and having the same keys
on both sides.

its just about to fail when there are no keys at all.

i hope this makes sense.

--
cinap



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mde0a5711ad3df989fdb26cb6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Newbie Question

[Frank D. Engel, Jr.]

Hi,

I am hoping someone can help me with this.

I am trying as an experiment to set up a small plan9 cluster as a set of 
computers in a VMWare environment.


I am using the latest 9front distribution, and currently have two VMs 
booting plan9 with one network adapter each, on a private network (not 
connected to the internet or to the host computer), with no DHCP being 
provided by VMWare, and am attempting manual isolated configuration for now.



As far as I can tell, I was able to get an auth server running, booting 
off its own installation, with authentication enabled on its 
filesystem.  It comes up without the window system running (as a cpu 
server) and "keyfs" is among the processes which are listed when I run 
"ps"; I was able to use auth/changeuser to create user accounts for the 
hostowner users "glenda" (for my file server) and another account for my 
auth server, and was able to arrange for secstored to start with the 
system (from cpurc) and that seems to be working - I also created 
accounts in there to match the two I created with auth/changeuser, and 
both accounts are defined on the filesystem. If I do "ps | grep listen" 
I see five processes running: two owned by the host owner and three by 
"none".


I have a second system set up which I intend to be the file server (more 
storage space) and I can successfully use "rcpu" to access the auth 
server from that one.  The file server is still booting as a terminal 
rather than a cpu server, and I created matching user accounts (newuser) 
on the filesystem on the file server.



The last part of the /lib/ndb/local file on the file server looks like this:


auth=fingers authdom=9cluster


ipnet=9cluster ip=192.168.81.0 ipmask=255.255.255.0

    fs=cabinet

    tftpd=cabinet

    auth=fingers

    authdom=9cluster

    dnsdomain=9cluster


# file server

sys=cabinet ether=005056301268 ip=192.168.81.10

    dom=cabinet.9cluster


# auth server

sys=fingers ether=00505635c452 ip=192.168.81.12

    dom=fingers.9cluster



As I understand it, the next step would be to enable authentication on 
the file server.  I do this by rebooting, adding -c to the bootargs and 
at the "config:" prompt entering "noauth" twice, then "end".



When I try to do this, I am getting this set of messages:


mount: auth_proxy: auth_proxy read fd: authread: auth protocol not finished

mount: mount /root: authread: auth protocol not finished


followed by a list of partitions then a new prompt for bootargs


I am interpreting this to mean that I missed something in my 
authentication configuration, but after trying several things, I am a 
bit lost on how to proceed with this.



Can someone point me in the direction of what I might be missing?


Thank you!





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-M4b9db801378b29d235a061b7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription