[9fans] Hack font for plan9

[Chris McGee]

Hi All,

I have converted the open source font called Hack to plan 9 font format. It's 
designed to render source code and is working well for me.

https://github.com/sirnewton01/plan9-font-hack/releases

I used the this tool to convert it.

https://github.com/sirnewton01/ttf2plan9

I hope that they are useful.

Chris

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[James A. Robinson]

That sounds *very* useful.  Thank you!  I had 9atom installed, but was
planning to try out 9front next (probably this weekend).

Jim


On Tue, Nov 15, 2016 at 4:23 PM  wrote:

> you might take a look at 9front devtls and libsec. it does support
> tls1.1 and tls1.2. including ecdsa, ecdhe, both variants of
> chacha20-poly1305 and aes-gcm aead ciphers suits...
>
> i updated drawterm with the code and try to keep it in sync and
> should not be too difficult to port back to labs plan9.
>

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[cinap_lenrek]

you might take a look at 9front devtls and libsec. it does support
tls1.1 and tls1.2. including ecdsa, ecdhe, both variants of
chacha20-poly1305 and aes-gcm aead ciphers suits...

i updated drawterm with the code and try to keep it in sync and
should not be too difficult to port back to labs plan9.

--
cinap

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[cinap_lenrek]

> Is this the reason that it is actually possible to boot a combined
> auth/cpu/file server at all?

no. the reason this works is that the fileserver and authserver share
the same key (authid and password) so factotum can make up auth tickets
using the key it already knows, skipping the authentication server.

this is expecially true if everything runs on a combined cpu/fs/auth,
then factotum basically talks to itself thru the 9p auth file thru the
fileserver :-)

note this also happens when you boot off a cpu server from its own
local fileserver. for a stand alone terminal with a local disk you
wont neccesarily have a key so you have to disable authentication
on your local disk fileserver in that case.

this mechanism is also usefull when your authentication server is
unreachable or offline. then you can still logon as the hostowner
of the affected machine.

the fact that the key comes from nvram is irrelevant. if it where not
there factotum will prompt for the information on boot (cpu/file
servers only).

--
cinap

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[Stanley Lieber]

Ole-Hjalmar Kristensen  wrote:

>On Tue, Nov 15, 2016 at 8:05 PM, Stanley Lieber  wrote:
>
>> "James A. Robinson"  wrote:
>>
>> >So in a canonical installation the auth server mounts its root from
>the
>> >file server?
>> >
>> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber 
>wrote:
>> >
>> >> The idea is that there is one file system shared by all the
>> >neighboring
>> >> systems. The canonical Plan 9 installation comprises one disk file
>> >server
>> >> and many diskless computing machines (auth servers, cpu servers,
>> >terminals).
>> >>
>>
>> Yes. You can arrange for hands-free booting by storing  the same
>> authid/authdom/password in the nvram of both the file server and the
>auth
>> server. I usually boot the auth server from a 9fat partition or a USB
>key,
>> then tcp (actually, tls) mount the root file system from the file
>server.
>>
>> sl
>>
>>
>Is this the reason that it is actually possible to boot a combined
>auth/cpu/file server at all? I mean, the auth server stores /adm/keys
>on
>the file server, right? And normally you would need to authenticate
>yourself to attach to the file server, which would be kind of
>difficult,
>since it is the auth server that is trying to access the key file...
>
>Ole-Hj.

Yes. File server boots and loads it's key from nvram into factotum. Auth server 
does the same. If both credentials match, the two machines will agree to talk 
to each other. The ticket is "forged" and factotum realizes it has enough 
information to perform the authentication without needing to consult the actual 
auth server.

sl

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[Ole-Hjalmar Kristensen]

On Tue, Nov 15, 2016 at 8:05 PM, Stanley Lieber  wrote:

> "James A. Robinson"  wrote:
>
> >So in a canonical installation the auth server mounts its root from the
> >file server?
> >
> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber  wrote:
> >
> >> The idea is that there is one file system shared by all the
> >neighboring
> >> systems. The canonical Plan 9 installation comprises one disk file
> >server
> >> and many diskless computing machines (auth servers, cpu servers,
> >terminals).
> >>
>
> Yes. You can arrange for hands-free booting by storing  the same
> authid/authdom/password in the nvram of both the file server and the auth
> server. I usually boot the auth server from a 9fat partition or a USB key,
> then tcp (actually, tls) mount the root file system from the file server.
>
> sl
>
>
Is this the reason that it is actually possible to boot a combined
auth/cpu/file server at all? I mean, the auth server stores /adm/keys on
the file server, right? And normally you would need to authenticate
yourself to attach to the file server, which would be kind of difficult,
since it is the auth server that is trying to access the key file...

Ole-Hj.

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[James A. Robinson]

Ah, ok.  I'll try that.  Thank you!


On Tue, Nov 15, 2016 at 11:05 AM Stanley Lieber  wrote:

> "James A. Robinson"  wrote:
>
> >So in a canonical installation the auth server mounts its root from the
> >file server?
> >
> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber  wrote:
> >
> >> The idea is that there is one file system shared by all the
> >neighboring
> >> systems. The canonical Plan 9 installation comprises one disk file
> >server
> >> and many diskless computing machines (auth servers, cpu servers,
> >terminals).
> >>
>
> Yes. You can arrange for hands-free booting by storing  the same
> authid/authdom/password in the nvram of both the file server and the auth
> server. I usually boot the auth server from a 9fat partition or a USB key,
> then tcp (actually, tls) mount the root file system from the file server.
>
> sl
>
>

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[Stanley Lieber]

"James A. Robinson"  wrote:

>So in a canonical installation the auth server mounts its root from the
>file server?
>
>On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber  wrote:
>
>> The idea is that there is one file system shared by all the
>neighboring
>> systems. The canonical Plan 9 installation comprises one disk file
>server
>> and many diskless computing machines (auth servers, cpu servers,
>terminals).
>>

Yes. You can arrange for hands-free booting by storing  the same 
authid/authdom/password in the nvram of both the file server and the auth 
server. I usually boot the auth server from a 9fat partition or a USB key, then 
tcp (actually, tls) mount the root file system from the file server.

sl

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[James A. Robinson]

So in a canonical installation the auth server mounts its root from the
file server?

On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber  wrote:

> The idea is that there is one file system shared by all the neighboring
> systems. The canonical Plan 9 installation comprises one disk file server
> and many diskless computing machines (auth servers, cpu servers, terminals).
>

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[Stanley Lieber]

"James A. Robinson"  wrote:

>Folks,
>
>For a multi-machine network of Plan 9 services, would it be
>normal to have an authsrv machine that only runs that service,
>and uses a standalone local filesystem, and then have a separate
>server running dns+dhcp+tftp to PXE boot client machines.  The
>latter would be backed by a 3rd machine that is the fileserver.
>
>I'm trying to figure out the optimal way to maintain the systems
>without duplicating work, and run now an auth+dns+dhcp+tftp
>server appears to require maintenance of two separate filesystems
>to manage the /lib/ndb/* and kernel files.
>
>
>Jim

The idea is that there is one file system shared by all the neighboring 
systems. The canonical Plan 9 installation comprises one disk file server and 
many diskless computing machines (auth servers, cpu servers, terminals).

sl

Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[Steve Simon]

I have a single cpu/auth/dns/dhcp/tftp/file server.
and a raspberry pi terminal.

The obvious change would be to add a seperate raspberry pi as an
auth server, booting off its own sdcard (if memory serves,
the auth server needs to be up first).

If I were to do this I would probably make it backup its flash card
to an external flash card in a usb adapter every night or so
(if there are changes) to give it some protection.

This would mean there is really only one system to maintain, the auth server's,
and this static except for /sys/log and /adm on password changes.

-Steve

[9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server

[James A. Robinson]

Folks,

For a multi-machine network of Plan 9 services, would it be
normal to have an authsrv machine that only runs that service,
and uses a standalone local filesystem, and then have a separate
server running dns+dhcp+tftp to PXE boot client machines.  The
latter would be backed by a 3rd machine that is the fileserver.

I'm trying to figure out the optimal way to maintain the systems
without duplicating work, and run now an auth+dns+dhcp+tftp
server appears to require maintenance of two separate filesystems
to manage the /lib/ndb/* and kernel files.


Jim

Re: [9fans] tls 1.2

[Steve Simon]

Sorry, I don't have a 9front so I don't know.

-Steve

Re: [9fans] tls 1.2

[Steve Simon]

> The libsec-chacha.diff patch is not useful, since it's not used yet.

I suspected as much but thought it wouldn't hurt.

> Does it works when you connect to https://9p.io/?
> This machine have the same patches applied.

yes, this works fine.

I am trying to connect to davmail - an exchange / imap+smtp gateway, hosted on 
windows
so I am talking to a windows tls implementation which may well be the cause of 
my frustration.

There is a very suspicious block of code:

if((tr->handin == 0) && (header[0] & 0x80)){
if(tr->debug)pprint("weird MS header\n");
/* Cope with an SSL3 ClientHello expressed in SSL2 record 
format.
This is sent by some clients that we must interoperate
with, such as Java's JSSE and Microsoft's Internet 
Explorer. */
len = (get16(header) & ~0x8000) - 3;
type = header[2];
ver = get16(header + 3);
if(type != SSL2ClientHello || len < 22)
rcvError(tr, EProtocolVersion, "invalid initial 
SSL2-like message");
}else{  /* normal SSL3 record format */
if(tr->debug)pprint("normal SSL3 header\n");
type = header[0];
ver = get16(header+1);
len = get16(header+3);
}

Though I have tried looking at the contents of this buffer in case it has 
subtly changed and
it bears no relation to this case so maybe thats a red herring (false lead to 
non British people).

-Steve

Re: [9fans] tls 1.2

[Steve Simon]

> Just to be sure. Have you rebuilt libsec as well?

yep.

Wireshark sees TLS 1.2 packets from plan9 so I have that much right...

-Steve

Re: [9fans] tls 1.2

[David du Colombier]

> and rebuild my kernel and upas (where I need TLS1.2).

Just to be sure. Have you rebuilt libsec as well?

-- 
David du Colombier

Re: [9fans] tls 1.2

[David du Colombier]

> I am trying to get tls 1.2 working on a labs build of plan9.
>
> What is most infuriating is I am sure I did this a few years ago but I cannot 
> remember
> how (or even if) I got it working.
>
> what I have done is to install the following patches from 9legacy:
>
> libsec-chacha.diff  tls-devtls12.diff
> libsec-tlshand12-norc4.diff tls-tlshand12.diff
> libsec-tlshand12-nossl3.diff
>
> and rebuild my kernel and upas (where I need TLS1.2).
>
> When I try to connect to a windows machine I get an error
> from devtls in the kernel  of the length of the message is incorrect.
>
> I have hacked around inside port/devtls.c but not found anything obvious,
> I have also played with wireshark which didn't see anything very wrong.
>
> I am sure I have missed an obvious step but I cannot see what it is.

The libsec-chacha.diff patch is not useful, since it's not used yet.

Does it works when you connect to https://9p.io/?
This machine have the same patches applied.

-- 
David du Colombier

Re: [9fans] tls 1.2

[hiro]

does it happen on 9front?

[9fans] tls 1.2

[Steve Simon]

Hi,

I am trying to get tls 1.2 working on a labs build of plan9.

What is most infuriating is I am sure I did this a few years ago but I cannot 
remember
how (or even if) I got it working.

what I have done is to install the following patches from 9legacy:

libsec-chacha.diff  tls-devtls12.diff
libsec-tlshand12-norc4.diff tls-tlshand12.diff
libsec-tlshand12-nossl3.diff

and rebuild my kernel and upas (where I need TLS1.2).

When I try to connect to a windows machine I get an error
from devtls in the kernel  of the length of the message is incorrect.

I have hacked around inside port/devtls.c but not found anything obvious,
I have also played with wireshark which didn't see anything very wrong.

I am sure I have missed an obvious step but I cannot see what it is.

Anyone help?

Thanks,

-Steve