[9fans] p9p factotum available for plan 9

[9fans] p9p factotum available for plan 9

[erik quanstrom]

	contrib/install quanstro/nfactotum

thanks to a bunch of work by brian stuart and Coraid
paying both of us to work on these things, we've gotten
together a plan 9 version of p9p's factotum. the main
purpose of doing this is to support dsa and rsa verify
and sign.  of course the huge side benefit is that it's much
easier to add protocols to factotum.

i am currently running nfactotum as the factotum in
my terminal kernel, and i've been testing (but not
depending on) a cpu kernel with nfactotum built in.
it's verified that cpu, ssh 1 (client), telnet (client) work.

imap/smtpd passwd and cram and are untested.
i'm unsure if i've tested ssh server.  p9cr is missing some bits
to make vnc work.

telnet (server) is known broken.  i don't think it's a hard fix.
however, the diagnostic is fortune-worthy:

!factotum protocol botch 0 ok bad authentication failed

- erik

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

On Wed Nov  3 17:15:36 EDT 2010, quanstro@quanstro.net wrote:
> 	contrib/install quanstro/nfactotum
>
> imap/smtpd passwd and cram and are untested.

imap4d with a password (which uses cram) now works.
imap4d with a cram challenge does not.

> telnet (server) is known broken.  i don't think it's a hard fix.

telnet now works.

- erik

Re: [9fans] p9p factotum available for plan 9

[David Leimbach]

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

On Mon, Nov 8, 2010 at 7:37 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Wed Nov  3 17:15:36 EDT 2010, quanstro@quanstro.net wrote:
> >       contrib/install quanstro/nfactotum
> >
> > imap/smtpd passwd and cram and are untested.
>
> imap4d with a password (which uses cram) now works.
> imap4d with a cram challenge does not.
>
> > telnet (server) is known broken.  i don't think it's a hard fix.
>
> telnet now works.
>
> - erik
>
>
This is tangential to the topic, but has anyone written up a "how I use p9p"
configuration style document?  I've not really tried to use factotum from
p9p, because I was not even sure if it worked.

Also the one time I tried to set up venti from p9p I basically failed
horribly, and wasn't really sure what I did wrong.  (I should read the
installation scripts for Plan 9 and the man pages but haven't had time to
get back to it).

I'm wondering things like "can I use p9p venti as a snapshot back end to a
VMWare Plan 9 Fossil?

I'd also like to host the blocks for my guruplug on my Mac OS X system
directly with p9p venti if I could.

I feel I'm missing out on a few really great opportunities to use this
stuff, and I doubt I'm the only one :-).

That said, I use p9p Acme all the time, and it's wonderful!

[-- Attachment #2: Type: text/html, Size: 1813 bytes --]

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

> This is tangential to the topic, but has anyone written up a "how I use p9p"
> configuration style document?  I've not really tried to use factotum from
> p9p, because I was not even sure if it worked.

"recently", that is within the past 2 years, p9p factotum has stopped
working with drawterm.  it might be that porting back some of the
fixes to p9p factotum in nfactotum would fix that.

- erik

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

On Tue Nov  9 13:01:17 EST 2010, quanstro@quanstro.net wrote:
> > This is tangential to the topic, but has anyone written up a "how I use p9p"
> > configuration style document?  I've not really tried to use factotum from
> > p9p, because I was not even sure if it worked.
>
> "recently", that is within the past 2 years, p9p factotum has stopped
> working with drawterm.  it might be that porting back some of the
> fixes to p9p factotum in nfactotum would fix that.

no dice.  still hangs on startup:

where
#0  0x00007fb507c8440d in read () from /lib/libpthread.so.0
#1  0x0000000000410c77 in lfdread (c=0x6e0b60, buf=0x6e4e60, n=8192, off=0) at devlfd.c:86
#2  0x000000000040be90 in devbread (c=0x6e0b60, n=8192, offset=0) at dev.c:414
#3  0x00000000004128c6 in doread (m=0x6e0850, len=7) at devmnt.c:852
#4  0x000000000041296a in mntrpcread (m=0x6e0850, r=0x6e0dc0) at devmnt.c:874
#5  0x000000000041282c in mountio (m=0x6e0850, r=0x6e0dc0) at devmnt.c:837
#6  0x00000000004124ce in mountrpc (m=0x6e0850, r=0x6e0dc0) at devmnt.c:764
#7  0x0000000000411702 in mntattach (muxattach=0x7fff8a3da990 "`\vn") at devmnt.c:349
#8  0x0000000000415b23 in bindmount (ismount=1, fd=3, afd=-1, arg0=0x0, arg1=0x45be6e "/mnt/factotum", flag=0,
    spec=0x45bdf0 "") at sysfile.c:682
#9  0x0000000000415cba in _sysmount (fd=3, afd=-1, new=0x45be6e "/mnt/factotum", flag=0, spec=0x45bdf0 "") at sysfile.c:727
#10 0x0000000000416380 in sysmount (fd=3, afd=-1, new=0x45be6e "/mnt/factotum", flag=0, spec=0x45bdf0 "") at sysfile.c:988
#11 0x00000000004037a1 in mountfactotum () at cpu.c:87
#12 0x0000000000403ef9 in cpumain (argc=0, argv=0x7fff8a3dae70) at cpu.c:165
#13 0x0000000000403313 in main (argc=3, argv=0x7fff8a3dae58) at main.c:68

- erik

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

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

Factotum doesn't answer that message.
You need to be looking at 9pserve.

[-- Attachment #2: Type: text/html, Size: 90 bytes --]

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

On Tue Nov  9 20:51:30 EST 2010, rsc@swtch.com wrote:

> Factotum doesn't answer that message.
> You need to be looking at 9pserve.

maybe i'm missing something, but 9pserve is also the
mechanism behind plumb, and it works.  why would
p9serve be broken, but only for factotum?  more likely
that drawterm itself is broken?

- erik

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

>> Factotum doesn't answer that message.
>> You need to be looking at 9pserve.
>
> maybe i'm missing something, but 9pserve is also the
> mechanism behind plumb, and it works.  why would
> p9serve be broken, but only for factotum?  more likely
> that drawterm itself is broken?

It's always hard to say which program is broken
when two programs can't talk to each other.
I was only trying to point out that the two programs
involved are drawterm and 9pserve, not drawterm
and factotum (you had made changes to factotum
in hopes that would fix it).

I suspect the problem has to do with the so-called
9P2000.u protocol negotiation that 9pserve supports.

Russ

Re: [9fans] p9p factotum available for plan 9

[Noah Evans]

You can keep srv() from eating Tattach's and Tauth's without numeric
userids with the following:

--- a/src/cmd/9pserve.c	Wed Nov 03 15:49:22 2010 -0400
+++ b/src/cmd/9pserve.c	Thu Nov 11 19:27:02 2010 -0800
@@ -440,6 +440,8 @@
 				m->tx.uname = getuser();	/* what srv.c used */
 				repack(&m->tx, &m->tpkt, c->dotu);
 			}
+			if(dotu && !c->dotu)
+				repack(&m->tx, &m->tpkt, dotu);
 			break;
 		case Twalk:
 			if((m->fid = gethash(c->fid, m->tx.fid)) == nil){
@@ -474,6 +476,8 @@
 				continue;
 			}
 			m->afid->ref++;
+			if(dotu && !c->dotu)
+				repack(&m->tx, &m->tpkt, dotu);
 			break;
 		case Tcreate:
 			if(dotu && !c->dotu &&
(m->tx.perm&(DMSYMLINK|DMDEVICE|DMNAMEDPIPE|DMSOCKET))){


knieriem also proposed a fix at:
http://code.swtch.com/plan9port/issue/38/9pserve-not-translating-9p2000-client-msgs

Russ does this approach blow up your ssh-agent?

Noah

On Wed, Nov 10, 2010 at 6:31 AM, Russ Cox <rsc@swtch.com> wrote:
>>> Factotum doesn't answer that message.
>>> You need to be looking at 9pserve.
>>
>> maybe i'm missing something, but 9pserve is also the
>> mechanism behind plumb, and it works.  why would
>> p9serve be broken, but only for factotum?  more likely
>> that drawterm itself is broken?
>
> It's always hard to say which program is broken
> when two programs can't talk to each other.
> I was only trying to point out that the two programs
> involved are drawterm and 9pserve, not drawterm
> and factotum (you had made changes to factotum
> in hopes that would fix it).
>
> I suspect the problem has to do with the so-called
> 9P2000.u protocol negotiation that 9pserve supports.
>
> Russ
>
>

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

> You can keep srv() from eating Tattach's and Tauth's without numeric
> userids with the following:

this patch + factotum + drawterm yields this for me
on starting drawterm:

console
	9pserve: convS2Mu and sizeS2Mu disagree
in drawterm
	<blah> mount rpc error

- erik

Re: [9fans] p9p factotum available for plan 9

[Noah Evans]

Are you using the tip of plan9ports?

Noah



On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> You can keep srv() from eating Tattach's and Tauth's without numeric
>> userids with the following:
>
> this patch + factotum + drawterm yields this for me
> on starting drawterm:
>
> console
>        9pserve: convS2Mu and sizeS2Mu disagree
> in drawterm
>        <blah> mount rpc error
>
> - erik
>
>

Re: [9fans] p9p factotum available for plan 9

[Noah Evans]

Nope, you're right. I got your behavior. There's a race.

Noah



On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> You can keep srv() from eating Tattach's and Tauth's without numeric
>> userids with the following:
>
> this patch + factotum + drawterm yields this for me
> on starting drawterm:
>
> console
>        9pserve: convS2Mu and sizeS2Mu disagree
> in drawterm
>        <blah> mount rpc error
>
> - erik
>
>

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

Does anyone use 9P2000.u anymore?
Can we just remove it from the p9p tree?

Russ

Re: [9fans] p9p factotum available for plan 9

[Noah Evans]

I don't. I say go for it.

Noah



On Thu, Nov 11, 2010 at 10:19 PM, Russ Cox <rsc@swtch.com> wrote:
> Does anyone use 9P2000.u anymore?
> Can we just remove it from the p9p tree?
>
> Russ
>
>

Re: [9fans] p9p factotum available for plan 9

[EBo]

> Does anyone use 9P2000.u anymore?
> Can we just remove it from the p9p tree?

 Last summer when I was banging my head against the bug in alloctree I
 got it all to work when I removed 9P2000.u and some other stuff from
 lib9p/srv.c.  At that time I got a comment back that the patches I
 proposed would likely not be accepted, in part because I removed the
 9P2000.u code...

 If there are no objections to removing 9P2000.u, I can tell you that
 migrating p9p's srv.c code back to Plan 9's version does in fact fix the
 bugs in Tree.  I was simply not sure how many of the changes had to be
 reverted to make alloctree work properly.


   EBo --

Re: [9fans] p9p factotum available for plan 9

[David Leimbach]

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

On Fri, Nov 12, 2010 at 1:07 AM, EBo <ebo@sandien.com> wrote:

> Does anyone use 9P2000.u anymore?
>> Can we just remove it from the p9p tree?
>>
>
> Last summer when I was banging my head against the bug in alloctree I got
> it all to work when I removed 9P2000.u and some other stuff from
> lib9p/srv.c.  At that time I got a comment back that the patches I proposed
> would likely not be accepted, in part because I removed the 9P2000.u code...
>
> If there are no objections to removing 9P2000.u, I can tell you that
> migrating p9p's srv.c code back to Plan 9's version does in fact fix the
> bugs in Tree.  I was simply not sure how many of the changes had to be
> reverted to make alloctree work properly.
>
>
>
It seems like a good idea to removing .u.  I think I can add .u back to some
other 9P implementations I have if I want it.

Dave


>  EBo --
>
>
>

[-- Attachment #2: Type: text/html, Size: 1505 bytes --]

Re: [9fans] p9p factotum available for plan 9

[Eric Van Hensbergen]

On Fri, Nov 12, 2010 at 12:19 AM, Russ Cox <rsc@swtch.com> wrote:
> Does anyone use 9P2000.u anymore?
> Can we just remove it from the p9p tree?
>

I don't use it from plan9ports.  Not sure if Lucho is still using it
(or variants).

But.... why does version negotiation muck things up?  It seems like if
the other side isn't responding with .u then there shouldn't be any
issues.

     -eric

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

> But.... why does version negotiation muck things up?  It seems like if
> the other side isn't responding with .u then there shouldn't be any
> issues.

i think that's exactly it.  the .u stuff leaks out of the version negotiation
phase and changes the behavior of other messages.

- erik

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

> I don't use it from plan9ports.  Not sure if Lucho is still using it
> (or variants).
>
> But.... why does version negotiation muck things up?  It seems like if
> the other side isn't responding with .u then there shouldn't be any
> issues.

It just complicates everything, especially in a
protocol multiplexer.  You have to keep track
of whether you're serving .u because it changes
the layout of various messages and also the dir
struct.  I was happy to support the experiment but
it sounds like the experiment has failed.

Russ

Re: [9fans] p9p factotum available for plan 9

[Eric Van Hensbergen]

On Fri, Nov 12, 2010 at 9:55 AM, Russ Cox <rsc@swtch.com> wrote:
>> I don't use it from plan9ports.  Not sure if Lucho is still using it
>> (or variants).
>>
>> But.... why does version negotiation muck things up?  It seems like if
>> the other side isn't responding with .u then there shouldn't be any
>> issues.
>
> It just complicates everything, especially in a
> protocol multiplexer.  You have to keep track
> of whether you're serving .u because it changes
> the layout of various messages and also the dir
> struct.  I was happy to support the experiment but
> it sounds like the experiment has failed.
>

The complications with overloading existing operations is why we
started going with a new approach (.L).  I just wanted to make sure I
understood the issues in the p9p version to make sure we aren't
repeating them.

        -eric

Re: [9fans] p9p factotum available for plan 9

[ron minnich]

I never much liked .u so I'm happy to see it go away :-)

But I wonder what the failure of .u says about the version mechanism.
In the 9p stuff I did in 1998 for linux I used the SunRPC way of
handling protocol variants: client asked to do an op (e.g. Treadlink)
and got back an ENOSUPPORT if server couldn't do that. Client would
then shortstop the operation on the client side from that point on, as
it knew what the server could and could not do. That worked well for
both me and SunRPC (i.e. NFS).

(I had no choice at the time; this was a little bit before Tversion existed).

That might work but Plan 9 servers currently silently discard T
messages they don't understand, so this way of determining server
capabilities can't be used.

My impression is that if you see .L, then extra operations are
supported and you assume they'll work; is that true?

There are other issues with the versioning mechanism however. What if
a server supports capabilities of two versions, e.g. .L and .op? Do we
reply
9p2000.L+9p2000.op

It seems we made the first real test of versioning with .u and things
did not go as we hoped ...

As for the uid/gid mess, the simplest way out it seemed to me was to
send the numbers as strings; done. People can just put the strings for
the numbers in /etc/passwd; that's what I did anyway.

And, finally, errno and errstr. Plan 9 speaks strings, Unix integers,
Windows strings IIRC. The solution for unix clients was reverse
mapping of errstr to errno, which has not worked well for me. I'd
still prefer the format I used before:
sprint(rmsg.error, "%d:%s", errno, errstr);
and let the client figure out which of these two things it wants.
Obviously useless for Plan 9 servers but very useful for *nix
clients/servers, which only want to talk errno. Even if the Plan 9
client sees an errstr in the number:message format, that could be
helpful to users.

So, sorry to disinter this old discussion, but my $.02 and the pinon
coffee just woke me up a little.

ron

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

> And, finally, errno and errstr. Plan 9 speaks strings, Unix integers,
> Windows strings IIRC. The solution for unix clients was reverse
> mapping of errstr to errno, which has not worked well for me. I'd
> still prefer the format I used before:
> sprint(rmsg.error, "%d:%s", errno, errstr);
> and let the client figure out which of these two things it wants.
> Obviously useless for Plan 9 servers but very useful for *nix
> clients/servers, which only want to talk errno. Even if the Plan 9
> client sees an errstr in the number:message format, that could be
> helpful to users.

since plan 9 assumes that strings are null-terminated but
9p has explicit rle, one could send uids/errorno after the 0,
but before the rle says the string is done.

sleezy, and hackish, but it should work.

also, one can always support many extensions by doing
the following
(a) extensions are [a-zA-Z]
(b) all extensions start with "."

then you can check for the existence of an extension
with
	if(strstr(version, ".myextension") != nil)
		extensions |= Myextension;

and
	P92000.l.op.xyz.pdq

will be legal.

- erik

Re: [9fans] p9p factotum available for plan 9

[Eric Van Hensbergen]

On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
<quanstro@labs.coraid.com> wrote:
>
> since plan 9 assumes that strings are null-terminated but
> 9p has explicit rle, one could send uids/errorno after the 0,
> but before the rle says the string is done.
>
> sleezy, and hackish, but it should work.
>

FWIW I think this is a horrible idea.

     -eric

Re: [9fans] p9p factotum available for plan 9

[ron minnich]

On Fri, Nov 12, 2010 at 12:31 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
> <quanstro@labs.coraid.com> wrote:
>>
>> since plan 9 assumes that strings are null-terminated but
>> 9p has explicit rle, one could send uids/errorno after the 0,
>> but before the rle says the string is done.
>>
>> sleezy, and hackish, but it should work.
>>
>
> FWIW I think this is a horrible idea.

I agree. This kind of trickery just comes back to bite you at some
point. We just learned this with .u, do we need to do it all over
again and regret it in 6 years?

ron

Re: [9fans] p9p factotum available for plan 9

[Eric Van Hensbergen]

On Fri, Nov 12, 2010 at 1:55 PM, ron minnich <rminnich@gmail.com> wrote:
>
> That might work but Plan 9 servers currently silently discard T
> messages they don't understand, so this way of determining server
> capabilities can't be used.
>

Silent discard is a bit unfriendly and likely to hang the client.
Returning Rerror for any T message you don't understand is a bit more
friendly (and is what is written in the .L proposal).

> My impression is that if you see .L, then extra operations are
> supported and you assume they'll work; is that true?

Not really, the intent was that servers could implement a subset of
the .L features, and return Rerror for any that they don't.  The
intent was so that a client could degrade gracefully or report lack of
features back to the application/user.  The current client and server
for .L (that I'm aware of) doesn't do this yet (it is still in
development), but that is the intent.

>
> There are other issues with the versioning mechanism however. What if
> a server supports capabilities of two versions, e.g. .L and .op? Do we
> reply
> 9p2000.L+9p2000.op
>

That isn't currently supported by anything (that I am aware of),
although I imagine the right response woul dbe 9p2000.L.op.  Of
course, the op guys specified their stuff as an entirely different
protocol, so not currently a problem.

> It seems we made the first real test of versioning with .u and things
> did not go as we hoped ...

Well, the .u was a "clumsy" design intended to have minimum
interference, but in fact changed the size of certain protocol
messages which really threw a monkey wrench into certain clients or
servers.  The first test of the version stuff was 9p versus 9p2000,
and that worked just fine, but I don't think much was done to test
outside of these two conditions.

>
> As for the uid/gid mess, the simplest way out it seemed to me was to
> send the numbers as strings; done. People can just put the strings for
> the numbers in /etc/passwd; that's what I did anyway.
>

Doesn't really work in multi-account environments where uid on one
system doesn't equal uid on the other system.  Also introduces
potential parse problems.

> And, finally, errno and errstr. Plan 9 speaks strings, Unix integers,
> Windows strings IIRC. The solution for unix clients was reverse
> mapping of errstr to errno, which has not worked well for me. I'd
> still prefer the format I used before:
> sprint(rmsg.error, "%d:%s", errno, errstr);
> and let the client figure out which of these two things it wants.
> Obviously useless for Plan 9 servers but very useful for *nix
> clients/servers, which only want to talk errno. Even if the Plan 9
> client sees an errstr in the number:message format, that could be
> helpful to users.

More or less what we did in .u (it had both, just not in the same string).

In any case, if you are talking to Plan 9, you talk 9P2000 and
everything is as it should be except errors are a little funny.
If you are talking to Linux from Plan 9, you talk 9P2000 and get by.
If you are talking Linux<->Linux then you really should use the Linux
native structures, ids, errcodes, etc.  This is the .L path.

Hey man, IIRC you were Lucho's boss when he did the .u implementation
-- so it's all your fault :P

         -eric

Re: [9fans] p9p factotum available for plan 9

[ron minnich]

On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:

> Not really, the intent was that servers could implement a subset of
> the .L features, and return Rerror for any that they don't.

Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-)



> That isn't currently supported by anything (that I am aware of),
> although I imagine the right response woul dbe 9p2000.L.op.  Of
> course, the op guys specified their stuff as an entirely different
> protocol, so not currently a problem.

It was just an example, I picked op out of the air, I well know that
it's not the right example ;-)

> Doesn't really work in multi-account environments where uid on one
> system doesn't equal uid on the other system.  Also introduces
> potential parse problems.

but names are not guaranteed to be the either, right? I don't see that
names solve this versus numbers.



> Hey man, IIRC you were Lucho's boss when he did the .u implementation
> -- so it's all your fault :P

I was the guy who never liked it, but I figured you smart guys would
work it all out :-)

ron

Re: [9fans] p9p factotum available for plan 9

[Eric Van Hensbergen]

On Fri, Nov 12, 2010 at 2:41 PM, ron minnich <rminnich@gmail.com> wrote:
>> Doesn't really work in multi-account environments where uid on one
>> system doesn't equal uid on the other system.  Also introduces
>> potential parse problems.
>
> but names are not guaranteed to be the either, right? I don't see that
> names solve this versus numbers.
>

No, that's true.  I think this is actually a huge open issue for
existing distributed file systems in general and I'm not sure of a
good way around.  Linux (Posix?) does make it much tougher by
insisting that remote files must have owners mappable to the local
numeric uid database.  The asteroid to kill that dinosaur is still in
orbit, let's hope it comes down soon.

>
>
>> Hey man, IIRC you were Lucho's boss when he did the .u implementation
>> -- so it's all your fault :P
>
> I was the guy who never liked it, but I figured you smart guys would
> work it all out :-)
>

What's worse is that it was put in to make you happy!  Your just
trying to dodge blame now.

     -eric

Re: [9fans] p9p factotum available for plan 9

[ron minnich]

On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:

> No, that's true.  I think this is actually a huge open issue for
> existing distributed file systems in general and I'm not sure of a
> good way around.

yeah, we had lots of discussion of this about 8 years ago with 9grid
and never worked it out. What's your global identify? How do you name
it? How do you map it to a local identity? I have no clue.

ron

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

Someone send me a patch to expunge .u and I will apply it.  :-)

Russ

Re: [9fans] p9p factotum available for plan 9

[tlaronde]

On Fri, Nov 12, 2010 at 02:20:35PM -0800, ron minnich wrote:
> On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> 
> > No, that's true.  I think this is actually a huge open issue for
> > existing distributed file systems in general and I'm not sure of a
> > good way around.
> 
> yeah, we had lots of discussion of this about 8 years ago with 9grid
> and never worked it out. What's your global identify? How do you name
> it? How do you map it to a local identity? I have no clue.

The problem with strings is that they are human oriented and human
dependent, on mood and/or trend. Numbers are agnostic.

Isn't a solution à la IP network numbers possible? I mean, a user,
whatever string is locally associated to it (and this may change), is
uniquely identified by a number that could encode a domain (with some
numbers being absolutely local), the conversion between string to number
being local (I'm called "god" on my personal systems, and may be called
"dummy" elsewhere; well, in fact "god" is "root" on Unices, and this 
"god" is only a local thing, with external systems don't believing in it
at all), and negociation being only with numbers.

And separate logical user from physical user: a physical user can be,
depending on the task, several distinct logical users; but the reverse
is true: several distinct physical users can be an uniq logical user.

This changes the way one thinks about the sharing of randomly writable
files: only "the" (logical) user of a file can randomly write 
(by randomly, I mean not append) a file; but there can be several 
concurrent instances of "the" user writing to the file (an instance
of a user is called a terminal; and a terminal is a temporary view
of the data).

And there are group writable files that are only append writable so long
as a new record doesn't invalidate the previous ones [partition]
(hence distinct logical users sharing a group writable file don't
care about other writes when reading; when writing, an identifier
is returned, and if the record already exists, added by another user,
the existing identifier is returned, else it is added and the new
identifier is returned).

The use of numbers mapping to a string that can change is the principle
I have adopted with my CVS: the "projects" are only numbers, and if the
mood (or the "marketing") change, only the string associated changes,
the hierarchy is left alone since the numbers are fixed from start.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] p9p factotum available for plan 9

[Dave Eckhardt]

> The problem with strings is that they are human oriented and human
> dependent, on mood and/or trend. Numbers are agnostic.
>
> Isn't a solution a la IP network numbers possible?  I mean, a user,
> whatever string is locally associated to it (and this may change),
> is uniquely identified by a number that could encode a domain (with
> some numbers being absolutely local) [...]

I think the Inferno guys have relevant art.  Principals are identified
by public keys (which are indeed numbers).  But I am not an expert on
how this plays out in practice, and I also have a sense that the current
Inferno implementation is an approximation of the design goals.

Dave Eckhardt

Re: [9fans] p9p factotum available for plan 9

[Nathaniel W Filardo]

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

On Fri, Nov 12, 2010 at 02:20:35PM -0800, ron minnich wrote:
> On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> 
> > No, that's true.  I think this is actually a huge open issue for
> > existing distributed file systems in general and I'm not sure of a
> > good way around.
> 
> yeah, we had lots of discussion of this about 8 years ago with 9grid
> and never worked it out.

One proposal would be...

> What's your global identify?

A public (SPKI) key or, more robustly, a halo of subkeys.

> How do you name it?

By the shortest path from the key currently used as root, which probably is
the same as your public identity, so it gets stringified as "" or "." or
"self" or somesuch.

> How do you map it to a local identity?

There's less need to, since most rights checks would be done using the key
directly, but eve's factotum also probably has a SPKI key, and your identity
can be stringified into a path of names if necessary.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] p9p factotum available for plan 9

[erik quanstrom]

> > How do you map it to a local identity?
>
> There's less need to, since most rights checks would be done using the key
> directly, but eve's factotum also probably has a SPKI key, and your identity
> can be stringified into a path of names if necessary.

in that case, what do you do with the username? do you have
to change username if you rekey?

- erik

Re: [9fans] p9p factotum available for plan 9

[Nathaniel W Filardo]

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

On Mon, Nov 15, 2010 at 11:22:52AM -0500, erik quanstrom wrote:
> > > How do you map it to a local identity?
> > 
> > There's less need to, since most rights checks would be done using the key
> > directly, but eve's factotum also probably has a SPKI key, and your identity
> > can be stringified into a path of names if necessary.
> 
> in that case, what do you do with the username? do you have
> to change username if you rekey?

Hm; I wasn't thinking about rekeying.

You're free to use the path from eve's factotum, which may go via a local
naming authority, if you like.  Then the authority simply changes its view
of names in response to your rekeying and everything stays the same.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] p9p factotum available for plan 9

[John Floren]

On Fri, Nov 12, 2010 at 3:41 PM, ron minnich <rminnich@gmail.com> wrote:
> On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
>> Not really, the intent was that servers could implement a subset of
>> the .L features, and return Rerror for any that they don't.
>
> Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-)
>

Actually, I just have my streaming clients/servers give their versions
as 9P2000.s; unrecognized T-messages still get silently dropped. I
decided this was a better option for my current work, since it allows
me to connect to any unmodified 9P file system, rather than go through
and modify every single 9P server out there.

That said, I definitely agree that unrecognized T-messages should get
an Rerror back; I was kind of grossed out when I discovered that they
were being dropped, I had figured that was part of the purpose of
Rerror. If 9P ever has to change again (adding new T-messages), you'll
find it a lot easier to interoperate old and new code if we get
Rerrors on bogus T-messages.

John

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

On Fri, Nov 12, 2010 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote:
> I never much liked .u so I'm happy to see it go away :-)
> But I wonder what the failure of .u says about the version mechanism.

I think it says you shouldn't use it to change the
encoding of existing messages.  Add messages
all you want (and use the negotiation to make sure
you agree on what they are) but don't change the
messages that are already there, and especially don't
change format of fundamental data structures like Dir.

> In the 9p stuff I did in 1998 for linux I used the SunRPC way of
> handling protocol variants: client asked to do an op (e.g. Treadlink)
> and got back an ENOSUPPORT if server couldn't do that.

Sun RPC can get away with that because there are
64+ bits describing a particular RPC request type.
9P has 8.  You shouldn't just send an 8-bit value
and hope the other side knows which one you mean.
You should use the protocol negotiation.

Russ

Re: [9fans] p9p factotum available for plan 9

[yy]

2010/11/9 David Leimbach <leimy2k@gmail.com>:
> I'm wondering things like "can I use p9p venti as a snapshot back end to a
> VMWare Plan 9 Fossil?

mycroftiv is doing it with qemu. He has writen about it and you can
download the whole thing from 9gridchan.org.

--
- yiyus || JGL . 4l77.com

Re: [9fans] p9p factotum available for plan 9

[Bakul Shah]

On Tue, 09 Nov 2010 09:41:26 PST David Leimbach <leimy2k@gmail.com>  wrote:
>
> Also the one time I tried to set up venti from p9p I basically failed
> horribly, and wasn't really sure what I did wrong.  (I should read the
> installation scripts for Plan 9 and the man pages but haven't had time to
> get back to it).

See $PLAN9/src/cmd/venti/srv/tester.

When I was first playing with venti about 5 years back, I
used a `newventi' script like the one below.  It creates all
the necessary data & conf files in $PWD.  Modify as per
taste. Once set up, start as

    $PLAN9/bin/venti/venti -c $conf

You have to be a bit careful when shutting things down
(flush dcache or something -- can't remember).

If you decide to back up ffs/ffs2/hfs/ext2fs/fat filesystems,
Russ's backup scripts are pretty handy.

---
#!/bin/sh
PATH=$PATH:$PLAN9/bin:$PLAN9/bin/venti
export PATH

d=$PWD
bs=8k
conf=venti.conf

echo index main > $conf

for i in 0 1 2 3
do
    rm -f arenas$i; touch arenas$i; truncate -s 32G arenas$i;
    fmtarenas -b $bs arenas$i. arenas$i
    echo arenas arenas$i >> $conf
done

isect=$d/isect0
rm -f $isect; touch $isect; truncate -s 8G $isect
fmtisect -b $bs isect0. $isect
echo isect $isect >> $conf

bloom=$d/bloom
rm -f $bloom; touch $bloom; truncate -s 64M $bloom;
fmtbloom $bloom
echo bloom $bloom >> $conf

cat >> $conf <<EOF
mem 128M
bcmem 64M
icmem 64M
queuewrites
webroot $d/www
httpaddr tcp!*!9091
EOF

fmtindex $conf

Re: [9fans] p9p factotum available for plan 9

[Russ Cox]

> This is tangential to the topic, but has anyone written up a "how I use p9p"
> configuration style document?  I've not really tried to use factotum from
> p9p, because I was not even sure if it worked.

http://9fans.net/archive/2007/11/120

Russ