Hi, Russ!
Firs of all -- thank a lot for answering all of my question
in a very detailed manner. I really do appreciate it!
Now, if you don't mind, I still have just one question left:
On Mon, 2008-12-01 at 16:55 -0800, Russ Cox wrote:
> > That's very similar to what I referred to as a "synthetic
On Mon, 2008-12-01 at 16:18 -0500, Dan Cross wrote:
> On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> > In Plan9 land you don't need automounter to deal with
> > /media/floppy. But cd /net/ is not there.
> > At least not by default.
>
> I see what you're after. If
On Mon, 2008-12-01 at 18:11 -0500, [EMAIL PROTECTED] wrote:
> Won't srvfs (see exportfs(4)) do what you want (packaging up a
> namespace)?
It will. But in a read-only, black-box way. My problem is that
I don't see how I can even inspect the namespace that it exports,
let alone manipulate it.
Now
On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
> I would imagine that making '#p'//ns writable and receptive
> to messages of exact same format that is being output right now
> (plus an 'unmount X Y' message) would be a very natural thought in
> a Plan9 environment. Yet, it w
> I totally agree that a shim filesystem whould solve an immediate issues
> perfectly. The solution, however, will be a 'black box'. If I mount
> such a filesystem under /n/ all I would see in my name space is a single
> mount. Everything that goes on underneath /n//stuff... will be
> completely hi
On Tue, 2008-12-02 at 13:18 -0500, erik quanstrom wrote:
> > I need to do in order to find out is:
> > $ mount | fgrep /set/tools/gcc/4.0/intel-S2
> > and then I can manipulate my namespace even further to suit my needs.
>
> since nfs is always directly mounted, i think you are confusing
> dire
On Tue, 2008-12-02 at 13:31 -0500, Nathaniel W Filardo wrote:
> Namespaces form a large part of the security component of the Plan 9 model,
> and (AFAICT) cross-namespace work is underinvestigated
It would be, in fact, a fair answer.
> since it starts to look a lot like something that could compr
>> since nfs is always directly mounted, i think you are confusing
>> direct mounts with things that are accessable because you have
>> mounted a server which has mounted something else.
>
> I don't think I'm confusing anything here. In fact, your statement
> of "nfs is always directly mounted" se
> I *suspect* that this is, indeed, the dance Russ was referring to.
> Nothing wrong with dancing it. But it still leaves me curious
> as to why it was decided to *not* implement the support in the
> kernel.
>
> Thanks,
> Roman.
>
>
>
I still don't understand what kind of feature you are missing.
> (hey, could you imagine a seperate nfs mount for ken's compiler?
> laughable, no?)
It would make a lot more sense than an nfs mount for some gcc tools.
I created a user nhh, and would just like to know how to set a password for
it.
I tried "auth/changeuser nhh"
and entered in all of the answers for each prompt.
still no password after the
user[nhh]:
prompt.
> I created a user nhh, and would just like to know how to set a password for
> it.
> I tried "auth/changeuser nhh"
> and entered in all of the answers for each prompt.
> still no password after the
> user[nhh]:
> prompt.
what do you mean by "no password"? your authentication
server will need to
On Tue, 2008-12-02 at 14:29 -0500, erik quanstrom wrote:
> >> i would think that either you want encapsulation or you don't.
> >> see-through encapsulation would seem to me to be a contradiction
> >> in terms.
> >
> > Thanks for the feedback. Lets see if you change your mind after the
> > explanat
On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> I still don't understand what kind of feature you are missing. Could
> it be that you just want a naming convention for your mount places?
Writable '#p//ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the explanation
to
> On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> > I still don't understand what kind of feature you are missing. Could
> > it be that you just want a naming convention for your mount places?
>
> Writable '#p//ns'
>
> Thanks,
> Roman.
>
> P.S. Unless somebody tells me that it is a bad idea wit
> > nope. sorry. i would hate to see such a botch in plan 9.
> > if you want to distribute load by having multiple fs, then
> > it should be done so that the client wouldn't know or care
> > that any distribution is going on.
>
> I think you're deliberately exaggerating here. You must
> know ful
Nolan,
how are you trying to connect to the Plan9? drawterm?
Plan9 do not request for a password on console.
Saludos.
Nolan Hamilton escribió:
I created a user nhh, and would just like to know how to set a
password for it.
I tried "auth/changeuser nhh"
and entered in all of the answers for e
> a couple of questions come to mind. how does writing
> to a ns interact with shared namespaces? does it automaticly
> fork the namespace? seems iffy. which leads to the next
> obvious question
>
> how do you prevent a race between changing the namespace and
> opening fds?
>
> and, what about
> None of these questions are any different in this
> context than if there was simply some other process
> sharing the name space and doing the same manipulations.
>
currently one can prevent external changes to a
namespace by creating a unique ns with rfork.
if /proc/$pid/ns were writable, one
i'm sorry for what should be an obvious question.
does anyone know of a standalone netkey for unix,
mac or windows?
- erik
i have Charles's version here:
http://mirtchovski.com/p9/netkey.tgz
On Tue, Dec 2, 2008 at 5:09 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> i'm sorry for what should be an obvious question.
> does anyone know of a standalone netkey for unix,
> mac or windows?
>
> - erik
>
>
/sys/src/cmd/unix/netkey.c
On 12/2/08, erik quanstrom <[EMAIL PROTECTED]> wrote:
> i'm sorry for what should be an obvious question.
> does anyone know of a standalone netkey for unix,
> mac or windows?
>
> - erik
>
>
--
Federico G. Benavento
On Tue, 2008-12-02 at 19:07 -0500, erik quanstrom wrote:
> > None of these questions are any different in this
> > context than if there was simply some other process
> > sharing the name space and doing the same manipulations.
> >
>
> currently one can prevent external changes to a
> namespace b
On Tue, 2008-12-02 at 16:35 -0500, erik quanstrom wrote:
> > > nope. sorry. i would hate to see such a botch in plan 9.
> > > if you want to distribute load by having multiple fs, then
> > > it should be done so that the client wouldn't know or care
> > > that any distribution is going on.
> >
>
On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> currently one can prevent external changes to a
> namespace by creating a unique ns with rfork.
> if /proc/$pid/ns were writable, one would not not
> be possible without yet another mechanism.
chmod? I guess it comes back
On Tue, Dec 2, 2008 at 8:26 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> The client does not pick. It is part of the automounter's decision.
> And once the server gets picked by the automounter, it is awfully
> convenient that you see the actual mount as part of the namespace.
Folks are ta
> > are you saying that clients don't need information about the
> > variety of nfs servers serving the xyz tree? if they do not, then
> > could you explain how the client picks which server to mount.
>
> The client does not pick. It is part of the automounter's decision.
> And once the server ge
does anyone know of a standalone netkey for unix,
mac or windows?
I have a windows netkey binary, Not much used, but it runs:
http://labs.utopian.net/who/josh/plan9/netkey-win32.zip
I *think* its origins are here:
http://www.cs.york.ac.uk/ftpdir/plan9/
-Josh
// P.S. Speaking of Inferno -- I have always wanted to run it
// natively on these puppies:
// http://www.sunspotworld.com/
I got myself one of those kits for Christmas last year. My intent
wasn't native Inferno, but rather more like Styx on a Brick: export
the interesting hardware via 9p. I
On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <[EMAIL PROTECTED]> wrote:
>> a couple of questions come to mind. how does writing
>> to a ns interact with shared namespaces? does it automaticly
>> fork the namespace? seems iffy. which leads to the next
>> obvious question
>>
>> how do you prevent a r
30 matches
Mail list logo
