Re: [9front] another CPU

Re: [9front] another CPU

[Romano]

> So I have it working. But maybe i'm missing something. Much
> of the documentation talks about
> 
> cd /cfg; mkdir $sysname; dircp example $sysname
> 
> This seems old and deprecated. I'm not really sure what we
> are supposed to have in /cfg/$sysname
> 
> I tried copying cpurc and termrc and booting with each of them
> the results were strange and buggy. However I made not changes
> to those files as well. 
> ...
> 
> Any thoughts?

I don't think you want to copy cpurc(8) to /cfg/$sysname/ : see the
man pages for init(8) and cpurc(8): cpurc is started by init, and then
/cfg/$sysname/cpurc runs.  So what you're effectively doing, if I am
reading you correctly, is running cpurc(8) twice. This is all I have in my config:

cpu% cat /cfg/$sysname/cpurc
auth/secstored
cpu%

Re: [9front] another CPU

[thinktankworkspaces]

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

Okay so the clarification is as follows: 

/rc/bin/cpurc.local only pertains to the intial system that
booted such as the first system which is CPU/Auth. 
However you don't really need that file. Its' just a diff of
/rc/bin/cpurc. So really its also optional

The /cfg/$sysname/cpurc is also optional and no cpurc.local
should exist in that directory. It only pertains to machines
that will boot off the initial server (CPU/Auth). And the
file should be a minimum file of things needed such as
auth/secstore or maybe auth/httpd if you wanted to dedicated
the new cpu to just service httpd as a service right?

As far as a mount point to copy data back and forth. No mount
point exists you still have to mout it directly using commands such as having a listener on the server

server% aux/listen1 -tv tcp!*!9999 /bin/exportfs -R -r /

client% srv tcp!192.168.1.172!9999 servrer /n/server

something like that right?

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

From: "Ethan Gardener" <eekee57@fastmail.fm>
To: 9front@9front.org
Subject: Re: [9front] another CPU
Date: Sat, 08 Aug 2020 09:48:51 +0100
Message-ID: <209c852d-7353-4c6d-b91a-81603faea9d0@www.fastmail.com>

On Sat, Aug 8, 2020, at 6:44 AM, thinktankworkspaces@gmail.com wrote:
> So I have it working. But maybe i'm missing something. Much
> of the documentation talks about
> 
> cd /cfg; mkdir $sysname; dircp example $sysname
> 
> This seems old and deprecated. I'm not really sure what we
> are supposed to have in /cfg/$sysname

It's optional. (The documentation should say so.) If you read /rc/bin/^(term cpu)^rc you'll see files in /cfg/$sysname are sourced only if they exist.

Re: [9front] another CPU

[thinktankworkspaces]

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

What about changing the extension from cpurc to cpurc.local. I was curious about that as well. 

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

From: "Ethan Gardener" <eekee57@fastmail.fm>
To: 9front@9front.org
Subject: Re: [9front] another CPU
Date: Sat, 08 Aug 2020 09:48:51 +0100
Message-ID: <209c852d-7353-4c6d-b91a-81603faea9d0@www.fastmail.com>

On Sat, Aug 8, 2020, at 6:44 AM, thinktankworkspaces@gmail.com wrote:
> So I have it working. But maybe i'm missing something. Much
> of the documentation talks about
> 
> cd /cfg; mkdir $sysname; dircp example $sysname
> 
> This seems old and deprecated. I'm not really sure what we
> are supposed to have in /cfg/$sysname

It's optional. (The documentation should say so.) If you read /rc/bin/^(term cpu)^rc you'll see files in /cfg/$sysname are sourced only if they exist.

Re: [9front] another CPU

[Ethan Gardener]

On Sat, Aug 8, 2020, at 6:44 AM, thinktankworkspaces@gmail.com wrote:
> So I have it working. But maybe i'm missing something. Much
> of the documentation talks about
> 
> cd /cfg; mkdir $sysname; dircp example $sysname
> 
> This seems old and deprecated. I'm not really sure what we
> are supposed to have in /cfg/$sysname

It's optional. (The documentation should say so.) If you read /rc/bin/^(term cpu)^rc you'll see files in /cfg/$sysname are sourced only if they exist.

Re: [9front] another CPU

[thinktankworkspaces]

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

So I have it working. But maybe i'm missing something. Much
of the documentation talks about

cd /cfg; mkdir $sysname; dircp example $sysname

This seems old and deprecated. I'm not really sure what we
are supposed to have in /cfg/$sysname

I tried copying cpurc and termrc and booting with each of them
the results were strange and buggy. However I made not changes
to those files as well. 

The booting part was the tricky part. I did have two dhcp server
running. One for my internet and one for the CPU/Auth.

ipnet=yoda ip=192.168.1.0 ipmask=255.255.255.0
	ipgw=192.168.1.1
	dns=8.8.8.8
	auth=192.168.1.172
	dnsdom=yoda
	authdom=yoda
	fs=192.168.1.1
	cpu=foo
	smtp=foo

sys=localhost dom=localhost ip=127.0.0.1
sys=foo dom=foo.yoda ether=525400123336 ip=192.168.1.172
sys=cirno dom=cirno.thinktank ether=080027f9ec98 ip=172.27.0.67
#sys=cpubar dom=foo.yoda ether=525400124242 ip=192.168.1.42 bootf=/386/bootx64.efi
sys=cpubar dom=foo.yoda ether=525400124242 ip=192.168.1.42

I did have to make a change to cpubar below. evidently bootx64.efi does not work. 

When I do manage to boot cpubar it takes the name of foo. However
the file system is different as expected. 

netaudit
checking this host's tuple:
	ip=192.168.1.42 looks ok
	dom=foo.yoda looks ok
	no ether entry
checking the network tuple:
	we are not in an ipnet, so looking for entries in host tuple only
	ipgw=192.168.1.1 looks ok
	dns=8.8.8.8 looks ok
	auth=192.168.1.172 looks ok
	fs=192.168.1.1 looks ok
checking auth server configuration:
	we are not the auth server 192.168.1.172
	if this is a mistake, set auth=foo or auth=foo.yoda
	run auth/debug to test the auth server

But i don't see a default mount for the cpu to copy data over 
/n/other/ is the same for both 

When I look back the only thing I did or the only change I made is one
line to /lib/ndb/local and an install on another system. It seems the less
I do the more results as opposed to following a lot of the old 
documentation. But I still seem to be missing a few things. 

Any thoughts?

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

From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] another CPU
Date: Mon, 3 Aug 2020 08:47:45 +0200
Message-ID: <CAFSF3XPoMzizmFY7Uss=mYWHFMkmxSqjri3MjqHyF5iK3U90JQ@mail.gmail.com>

make sure you're not running 2 dhcp servers.
you need to setup 9front as cpu server, fileserver and dhcp server.
plan9 dhcp server will give above ip=192.168.1.100 to any PC that
requests an IP if they have 123456789 ethernet address.
i don't see any ip subnet, network info above, so perhaps the local
routes are missing, too.

Re: [9front] another CPU

[hiro]

make sure you're not running 2 dhcp servers.
you need to setup 9front as cpu server, fileserver and dhcp server.
plan9 dhcp server will give above ip=192.168.1.100 to any PC that
requests an IP if they have 123456789 ethernet address.
i don't see any ip subnet, network info above, so perhaps the local
routes are missing, too.