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
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
On Fri, Nov 12, 2010 at 3:41 PM, ron minnich rminn...@gmail.com wrote:
On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen eri...@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!
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 eri...@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.
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
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
On Fri, Nov 12, 2010 at 1:07 AM, EBo e...@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.
On Fri, Nov 12, 2010 at 12:19 AM, Russ Cox r...@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
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
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
On Fri, Nov 12, 2010 at 9:55 AM, Russ Cox r...@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
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
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
On Fri, Nov 12, 2010 at 1:55 PM, ron minnich rminn...@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
On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
quans...@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
On Fri, Nov 12, 2010 at 12:31 PM, Eric Van Hensbergen eri...@gmail.com wrote:
On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
quans...@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
On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen eri...@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
On Fri, Nov 12, 2010 at 2:55 PM, ron minnich rminn...@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
On Fri, Nov 12, 2010 at 2:41 PM, ron minnich rminn...@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
On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen eri...@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
Someone send me a patch to expunge .u and I will apply it. :-)
Russ
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
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
Are you using the tip of plan9ports?
Noah
On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom quans...@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:
Nope, you're right. I got your behavior. There's a race.
Noah
On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom quans...@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
Does anyone use 9P2000.u anymore?
Can we just remove it from the p9p tree?
Russ
I don't. I say go for it.
Noah
On Thu, Nov 11, 2010 at 10:19 PM, Russ Cox r...@swtch.com wrote:
Does anyone use 9P2000.u anymore?
Can we just remove it from the p9p tree?
Russ
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
On Mon, Nov 8, 2010 at 7:37 PM, erik quanstrom quans...@quanstro.netwrote:
On Wed Nov 3 17:15:36 EDT 2010, quans...@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
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
2010/11/9 David Leimbach leim...@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
On Tue, 09 Nov 2010 09:41:26 PST David Leimbach leim...@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
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
On Tue Nov 9 13:01:17 EST 2010, quans...@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
Factotum doesn't answer that message.
You need to be looking at 9pserve.
On Tue Nov 9 20:51:30 EST 2010, r...@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
On Wed Nov 3 17:15:36 EDT 2010, quans...@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
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
38 matches
Mail list logo
