Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 filesystem > > doing the right stuff". But as I pointed out in my original email > > this approach has a downside of never exporting these mounts > > into the namespace of the process that caused them. > > You'd have the program export its own name space, > a delicate but not impossible dance. Then its mounts > would be exported too. That's pretty much what I'm after. Now, the question I still have is this: was there a clear reason behind deciding not letting the kernel help with something like that? 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 wasn't implemented that way which makes me believe that I do (as usual) overlook something obvious here. Please give me a hint to what it might be that renders the idea as a bad one. Thanks, Roman. P.S. Thinking for a couple more minutes makes me believe that a writable '#p'//ns might even be used to implement mount/bind syscall. Which, on the surface, would make it even more appealing.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 that's all you want, though, I have to > confess I don't see how it would be too hard to implement. You could > just write a shim filesystem that would sit on top of /net and monitor > walk's and handle importing and mounting for you. If you followed a > simple convention of always referring to a filesystem as, say, > '/a/' then it wouldn't require any configuration at all. > Hell, you could probably even implement it as a shell script. > > What's not there, aside from the program itself, of course? 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 hidden from me inside the namespace of the shim fileserver itself. I'm not sure whether it is an artifact of me spending lots of time under Solaris inside a pretty well managed Sun's intranet, but I do appreciate the fact that every time I access something like: /set/tools/gcc/4.0/intel-S2 I actually have a total transparency of where this thing came from. All 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. Now, the only [meta]question I have lest for this list at this point is: am I unique in appreciating something like the above? Do you think I'd better off with a shim-like approach instead (where /set would be managed 100% by a single fileserver hiding all the details from me)? Thanks, Roman.
Re: [9fans] How to implement a moral equivalent of automounter in
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, I've asked the manipulation question in my reply to Russ, so if you're interested in pursuing this topic -- lets do it in that other part of the thread. Thanks, Roman. P.S. Don't get me wrong though: srvfs is a very useful tool, its just that I'm asking a bit broader question than what it was designed to answer.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 wasn't implemented that way which makes > me believe that I do (as usual) overlook something obvious here. > Please give me a hint to what it might be that renders the idea as a bad > one. Namespaces form a large part of the security component of the Plan 9 model, and (AFAICT) cross-namespace work is underinvestigated since it starts to look a lot like something that could compromise the system's security. At the moment, we can make claims like "once fork(NEWNS) succeeds, I and the kernel are the only agents that are able to manipulate my namespace." This is a nice statement to be able to make. Since /proc/$PID/ns is "mostly" an rc script, it's possible (sometimes) to "see into" another proc's namespace by following along... given that, what would be wrong with your /set server exporting a ns-like file that simply detailed its own manipulations to its namespace? You'd have to assume that /net (or /srv, if you prefer) was shared between /set and you, I suppose... which is probably OK. > Thanks, > Roman. > > P.S. Thinking for a couple more minutes makes me believe that a > writable '#p'//ns might even be used to implement > mount/bind syscall. Which, on the surface, would make it even > more appealing. Intriguing. I guess it wasn't done this way so that processes could be constructed without /proc mounted... (though you could always manipulate '#p/$PID/ns'... that might be considered a bug, tho') --nwf; pgpMmbsCYB9pQ.pgp Description: PGP signature
Re: [9fans] How to implement a moral equivalent of automounter
> 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 hidden from me inside the namespace of the shim fileserver > itself. that's the point. > 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 direct mounts with things that are accessable because you have mounted a server which has mounted something else. 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. if you don't, and you really need to know what's on the other end, you should mount it yourself. /lib/namespace is a big help in this. if you do, then you don't want to care what's over there. - erik
Re: [9fans] How to implement a moral equivalent of automounter
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 > 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" seems to be quite confusing. Here's how the above works (changing the names to protect the innocent): $ grep set /etc/auto_master +set.map $ ypcat -k set.map | grep /set/tools set.tools -rw,hard,intr,nosuid $ ypcat -k set.tools | grep gcc gcc -ro / gcc-stuff:/ /4.0 gcc-tools:/4.0 /4.1 gcc-tools:/4.1 /3.0 old-gcc-tools:/ The beauty of the last line is that it is a multi-mount and a lazy multi-mount at that. Which means that: $ cd /set/tools/gcc/4.0 will mount gcc-tools:/4.0, but will not mount anything else. Now, I actually omitted the replications part, which also distributes the load between different servers when everybody wants to use the latest gcc. And *then* knowing which server your gcc actually came from could be a lifesaver. > 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 explanation given above. > if you don't, and you really need to know what's on the other > end, you should mount it yourself. /lib/namespace is a big > help in this. Sure, I can mount it myself. But the whole point is to have a "lazy" mount that only gets mounted when I need it (and also gets unmounted when I don't need it) AND also has nice things like replications thrown in for a good measure. It is kind of empowering to always have *everything* at your fingertips, but only when you need it, so that it doesn't clutter your setup. AND also be able to dig deeper into things if they don't seem to work for some reason. If the server that a shim filesystem made appear under /n/server started to misbehave -- how would you know *what* is actually misbehaving so that you can, perhaps, mount an alternative server in its place? Thanks, Roman.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 compromise the > system's security. Somehow, it doesn't strike me as any more dangerous that the rest of files you have under #p//. But I'd love to be corrected. > the moment, we can make claims like "once fork(NEWNS) succeeds, I and the > kernel are the only agents that are able to manipulate my namespace." This > is a nice statement to be able to make. But isn't it a tad overprotective? Although, it seems that I know of at least one more thing that didn't make it into #p -- environment. #e is also only accessible to the kernel and the process itself. I have always thought that Linux got it right with /proc/self and /proc//environ. But may be, again, I'm missing some part of a bigger picture here. > Since /proc/$PID/ns is "mostly" an rc script, it's possible (sometimes) to > "see into" another proc's namespace by following along... given that, what > would be wrong with your /set server exporting a ns-like file that simply > detailed its own manipulations to its namespace? You'd have to assume that > /net (or /srv, if you prefer) was shared between /set and you, I suppose... > which is probably OK. 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.
Re: [9fans] How to implement a moral equivalent of automounter
>> 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" seems to be quite confusing. > Here's how the above works (changing the names to protect the innocent): > > $ grep set /etc/auto_master > +set.map > $ ypcat -k set.map | grep > /set/tools set.tools -rw,hard,intr,nosuid > $ ypcat -k set.tools | grep gcc > gcc -ro / gcc-stuff:/ /4.0 gcc-tools:/4.0 /4.1 gcc-tools:/4.1 /3.0 > old-gcc-tools:/ but the machine you're logged into does do the mount directly in your namespace. (the one and only namespace.) conversely, with srvfs, you are mounting a fs that inturn mounts other fs. fundamentally this is different. (hey, could you imagine a seperate nfs mount for ken's compiler? laughable, no?) >> 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 > explanation given above. 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. - erik
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
> 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. Could it be that you just want a naming convention for your mount places?
Re: [9fans] How to implement a moral equivalent of automounter
> (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.
[9fans] How do I set passwords for users?
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.
Re: [9fans] How do I set passwords for users?
> 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 have proper entries in /lib/ndb/local and will need to run auth/keysfs. - erik
Re: [9fans] How to implement a moral equivalent of automounter
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 > > explanation given above. > > 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 full well, that the client is *not* affected by that knowledge when everything works as expected(*), which would be in 99% of the cases (at lest here within Sun's intranet). And the fact that this knowledge can be easily obtained makes that 1% bearable. That said, thanks for the feedback anyway. I consider this thread closed expect for that one question I asked Russ. Thanks, Roman. P.S. I've seen this disbelief in the fact that automoter + NFS actually can be really convenient mostly come from Linux people. Which is not surprising given how crappy autofs and NFS are implemented there.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 back that claim up.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
> 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 back that claim up. 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 open file descriptors? seems like a big can of worms. - erik
Re: [9fans] How to implement a moral equivalent of automounter
> > 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 full well, that the client is *not* affected by that > knowledge when everything works as expected(*), which would > be in 99% of the cases (at lest here within Sun's intranet). > And the fact that this knowledge can be easily obtained makes > that 1% bearable. 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. - erik
Re: [9fans] How do I set passwords for users?
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 each prompt. still no password after the user[nhh]: prompt.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
> 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 open file descriptors? > > seems like a big can of worms. 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. A writable #p/pid/ns seems strange to me (not nearly as natural as Roman suggested), but maybe it would be fine. No one has cared enough to explore it. I don't think a writable #p/pid/ns would really help you write an automounter. You don't know the pid you are getting the 9P request from (maybe it is on another machine!). If I had to write an automounter like you describe and I was going to tweak the kernel to make it easier, I would change name spaces to be hierarchical, so that rfork(RFNAMEG) (or perhaps some new bit) insulates the parent from the child's modifications but not vice versa. Then the automounter can sit in some early name space and mount things, and all the name spaces that were forked off would see them. That is easier to reason about than writing #p/pid/ns. Russ
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
> 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 would not not be possible without yet another mechanism. - erik
[9fans] standalone netkey
i'm sorry for what should be an obvious question. does anyone know of a standalone netkey for unix, mac or windows? - erik
Re: [9fans] standalone netkey
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 > >
Re: [9fans] standalone netkey
/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
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 by creating a unique ns with rfork. > if /proc/$pid/ns were writable, one would not not > be possible without yet another mechanism. >From where I sit, the file permissions seem to be quite an adequate a measure to be used for restricting access to any of the files under #p/. I don't see how ns is different from, lets say, mem. Thanks, Roman.
Re: [9fans] How to implement a moral equivalent of automounter
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. > > > > I think you're deliberately exaggerating here. You must > > know full well, that the client is *not* affected by that > > knowledge when everything works as expected(*), which would > > be in 99% of the cases (at lest here within Sun's intranet). > > And the fact that this knowledge can be easily obtained makes > > that 1% bearable. > > 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 gets picked by the automounter, it is awfully convenient that you see the actual mount as part of the namespace. Thanks, Roman.
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 to, "How do you define external." If you mean another process owned by the same user, then it breaks down (hello trojan horse). There are many things that would be *possible* with /proc, some of them ill advised. For instance, why can't I 'mkdir /proc/n/' and have it create a new process? I can think of a number of potential reasons, one of the most obvious ones is 'how do I choose n'; something more reasonable would probable be a /proc/ctl or /proc/fork or /proc/new or something that, when read, gives me a file directory name corresponding to a new process in some 'new' state. Maybe copying a binary onto /proc/n/text would and writing 'go' would be the moral equivalent of a 'spawn'-like call. Who knows. I guess the point is, "what does that *mean*?" Ie, it would fundamentally change the process model from something fork-based to something radically different. Is that good? Is that bad? Beats me. I'm not sure it's worth exploring. I suspect opening up /proc/n/ns for tinkering would be similar. As Russ says, no one's felt motivated to do it. There's no good reason you can't explore it, but you may find it isn't as cool as you'd originally hoped. An aside: One of the nice things about Plan 9 is that a lot of the things you sort of have to work around in Unix just work in Plan 9. They applied a few fundamental principles aggressively and in so fixed a lot of warts that had begun to glare on Unix as it aged. I can see the utility of an autofs-like thing, but I wouldn't get too wrapped up in the semantics of making it look like Unix; that's not a profitable thing in this environment, since this environment *is* different. It's funny, the feeling you described when talking about the Sun intranet is exactly how I felt when first working with plan 9. That being said, one of the biggest challenges the Linux/Unix community faces these days is a mental entrenchment and clinging to bad technology because "that's the way it's always been." The Plan 9 community should work hard to make sure that doesn't happen to it. - Dan C.
Re: [9fans] How to implement a moral equivalent of automounter
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 talking at cross-purposes here; I think it's a semantics issue more than anything. In Plan 9, the automounter would be considered part of the client. In plan 9, the canonical way to implement an automounter would be with a filesystem that did it on your behalf; the smarts for all the replication and so on would be put there. The namespace would be visible by asking the automounter (which in this environment is probably a filesystem) what the namespace is. There's nothing in the environment that prevents it from being implemented other than time and inclination. - Dan C.
Re: [9fans] How to implement a moral equivalent of automounter
> > 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 gets picked by the automounter, it is awfully > convenient that you see the actual mount as part of the namespace. there is the rub. for the "actual mounts" to be meaningful on the client, they need to be interpreted on the client. in the case of srvfs, the namespace is interpreted on the server running srvfs. (srvfs is a proxy.) in fact, you might not be able to directly mount the stuff srvfs serves. i use it (actually exportfs) every day to export il-only fileservers via aan over tls over the internet. one part of the ns making up the namespace i import is #s/boot. if that were interpreted on the client, it would point to a different fs (in a different authentication domain) than it does on the server. - erik
Re: [9fans] standalone netkey
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
Re: [9fans] Grid computing architecture w/ 9P + Java ;-)
// 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 wrote some dummy apps for the thing and looked at the Java Styx implementations, but it all took longer than expected (because I don't really know Java, mainly) and then paying work picked up. I'd be interested in getting back to work on them if you get to a point where colaboration would be useful. Anthony
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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 race between changing the namespace and >> opening fds? >> >> and, what about open file descriptors? >> >> seems like a big can of worms. > > 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. > > A writable #p/pid/ns seems strange to me > (not nearly as natural as Roman suggested), > but maybe it would be fine. No one has cared > enough to explore it. > > I don't think a writable #p/pid/ns would really > help you write an automounter. You don't know > the pid you are getting the 9P request from > (maybe it is on another machine!). > > If I had to write an automounter like you describe > and I was going to tweak the kernel to make it > easier, I would change name spaces to be hierarchical, > so that rfork(RFNAMEG) (or perhaps some new bit) > insulates the parent from the child's modifications > but not vice versa. Then the automounter can sit > in some early name space and mount things, and all > the name spaces that were forked off would see them. > That is easier to reason about than writing #p/pid/ns. > > Russ Long ago I considered making the namespace not hierarchical but a set of spaces. The first level of complexity upwards would be to have two spaces: one that is per-process and one that is global or per-machine. It could of course be extended to more generality, hierarchy, etc. The reason I didn't was that the existing one-space system was almost good enough and any generalization seemed either too complex or too specific. There seemed no guiding principle to organize the design. So I left it alone even though in so doing I was leaving a problem on the table. -rob
