2009/7/13 Latchesar Ionkov lu...@ionkov.net:
On Mon, Jul 13, 2009 at 2:24 AM, sqweeksqw...@gmail.com wrote:
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.
I don't think that auth is working
this is at a bit of a tangent from the previous discussion,
but something i've always wondered:
why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for mounting a file descriptor
(like the plan 9 syscall) and have an auxiliary
On Tue, Jul 14, 2009 at 1:08 PM, roger pepperogpe...@gmail.com wrote:
this is at a bit of a tangent from the previous discussion,
but something i've always wondered:
why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for
On Jul 14, 2009, at 6:08 AM, roger peppe rogpe...@gmail.com wrote:
this is at a bit of a tangent from the previous discussion,
but something i've always wondered:
why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for mounting a
On Jul 14, 2009, at 2:34 AM, sqweek sqw...@gmail.com wrote:
2009/7/13 Latchesar Ionkov lu...@ionkov.net:
Adding the support we had before the access= support is probably
easy,
but I would like to make it better and support authentication for
multiple users. Still no idea what is the
Main annoyance is the lack of a proper srv device in Linux to
facilitate sharing already open connections. This is t a problem for
per-user mounts --- but is a problem for private namespaces. You can
use p9p srv as mentioned elsewhere in this thread, but then you incur
some
On Tue, Jul 14, 2009 at 8:23 AM, erik quanstromquans...@quanstro.net wrote:
Main annoyance is the lack of a proper srv device in Linux to
facilitate sharing already open connections. This is t a problem for
per-user mounts --- but is a problem for private namespaces. You can
use p9p srv as
Hmm, I don't understand how this works. v9fs should issue its own
Tversion and Tattach and discard the previously authenticated session,
right? Or I am missing something?
Thanks,
Lucho
On Tue, Jul 14, 2009 at 1:34 AM, sqweeksqw...@gmail.com wrote:
2009/7/13 Latchesar Ionkov
On Tue, Jul 14, 2009 at 1:34 AM, sqweeksqw...@gmail.com wrote:
Can't help you there - I'm not sure it makes sense to try and put
factotum's functionality in the linux kernel... Is there some problem
with the private namespace/individual user mount approach?
-sqweek
I don't want to put the
Is something not working?
authentication? or doesn't that count?
- erik
On Tue, Jul 14, 2009 at 9:33 AM, Latchesar Ionkovlu...@ionkov.net wrote:
Hmm, I don't understand how this works. v9fs should issue its own
Tversion and Tattach and discard the previously authenticated session,
right? Or I am missing something?
It works because srv is serving its own
I thought at one point in time we had something in there that
bypassed tversion/tauth and that's how the amount stuff worked. But I
don't see that code anymore, is that what got squashed with the new
auth= stuff?
has anyone written anything to deal with an
exportfs connection on linux?
-
Yes, that's what was removed. When the code was still there, the
presence of the afid= option would prevent sending Tversion and would
use the specified afid on Tattach. It is not hard to put it back.
On Tue, Jul 14, 2009 at 8:54 AM, Eric Van Hensbergeneri...@gmail.com wrote:
I thought at one
On Tue, Jul 14, 2009 at 10:01 AM, erik quanstromquans...@coraid.com wrote:
I thought at one point in time we had something in there that
bypassed tversion/tauth and that's how the amount stuff worked. But I
don't see that code anymore, is that what got squashed with the new
auth= stuff?
has anyone written anything to deal with an
exportfs connection on linux?
I'm confused about what you are asking.
if i have two plan 9 machines, i can
import butts /mnt/consoles /n/consoles
however, since import and exportfs run a special
protocol in front of 9p, i don't think
On Tue, Jul 14, 2009 at 10:19 AM, erik quanstromquans...@coraid.com wrote:
has anyone written anything to deal with an
exportfs connection on linux?
I'm confused about what you are asking.
if i have two plan 9 machines, i can
import butts /mnt/consoles /n/consoles
however, since
On Tue, Jul 14, 2009 at 4:08 AM, roger pepperogpe...@gmail.com wrote:
why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for mounting a file descriptor
(like the plan 9 syscall) and have an auxiliary
command do the actual dial,
On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkovlu...@ionkov.net wrote:
Yes, that's what was removed. When the code was still there, the
presence of the afid= option would prevent sending Tversion and would
use the specified afid on Tattach. It is not hard to put it back.
That sounds nice to
On Tue, Jul 14, 2009 at 10:48 AM, ron minnichrminn...@gmail.com wrote:
On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkovlu...@ionkov.net wrote:
Yes, that's what was removed. When the code was still there, the
presence of the afid= option would prevent sending Tversion and would
use the
On Tue, Jul 14, 2009 at 11:12 AM, erik quanstromquans...@coraid.com wrote:
if i have two plan 9 machines, i can
import butts /mnt/consoles /n/consoles
however, since import and exportfs run a special
protocol in front of 9p, i don't think it's possible
to do the same thing from a
if i have two plan 9 machines, i can
import butts /mnt/consoles /n/consoles
however, since import and exportfs run a special
protocol in front of 9p, i don't think it's possible
to do the same thing from a linux host.
Yeah, I don't think anyone is currently doing anything
this is at a bit of a tangent from the previous discussion,
but something i've always wondered:
why does the linux 9p mount syscall bother
with IP addresses at all? isn't it sufficient
just to provide a facility for mounting a file descriptor
(like the plan 9 syscall) and have an auxiliary
2009/7/13 Eric Van Hensbergen eri...@gmail.com:
On Mon, Jul 13, 2009 at 3:24 AM, sqweeksqw...@gmail.com wrote:
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.
Any chance we can get fossil
On Tue, Jul 14, 2009 at 2:05 PM, sqweeksqw...@gmail.com wrote:
I'm not too fond of the idea... It's not as though amount adds any
new functionality over srv+mount[1], and I hate throwing more code at
a problem when equivalent code exists elsewhere. Having to introduce a
link time dependency
2009/7/14 Tim Newsham news...@lava.net:
The v9fs driver lets you mount from a file descriptor.
Is this what you're asking for?
i was aware it allowed a mount of a file descriptor.
in the interests of minimalism, i was wondering why
it did anything else.
You'll notice it still tries mount(2) after stat(2) reveals that
mount.9p doesn't exist. mount(8) always looks for a helper and will
call it if it exists, but it doesn't fail when no helper is present.
As others have said, mount(2) doesn't do name resolution, but by my
reading that should give
mount: Protocol not supported
There was a time where you had to modprobe 9p2000 first. Should be worth a try.
On Mon, Jul 13, 2009 at 3:24 AM, sqweeksqw...@gmail.com wrote:
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.
Any chance we can get fossil integration into 9mount directly? Most of
the code is
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.
Would you mind documenting this a little more explicitly and posting
it somewhere handy? I'm sure you've given enough hints here to make
it work,
On Mon, Jul 13, 2009 at 2:24 AM, sqweeksqw...@gmail.com wrote:
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv -a, in particular, then give v9fs a -o
trans=unix.
I don't think that auth is working with v9fs at all. The auth support
got dropped
If someone pulls together a verified HOWTO for the auth case, I'd be
happy to add it to the Documentation/filesystems/9p.txt
-eric
On Mon, Jul 13, 2009 at 9:59 AM, lu...@proxima.alt.za wrote:
Anyway, note that if you auth you'll need supporting software from
p9p also. Factotum and srv
Adding the support we had before the access= support is probably easy,
but I would like to make it better and support authentication for
multiple users. Still no idea what is the correct way. :( Any
suggestions are welcome.
I'm glad you brought this up because this is a conversation I wanted
to
Well, IMHO it would be nice to have it named (or symlinked as) mount.9p
folks who mount as root could get the helper automatically. This
would be nice for the standard Linux admin who is mounting crap as
root anyways and trips over the DNS resolution error because all
they are used to is NFS
When I need remote access I nowadays use v9fs+ssh.
Multi-user auth in kernel like you propose sounds nice and consistent,
but too complicated. It doesn't fit linux, and thus an additional
deamon would mean one more place of security relevant code prone to
bugs. And even if this is only intended to
On Mon, Jul 13, 2009 at 3:44 PM, hiro23h...@googlemail.com wrote:
Well, IMHO it would be nice to have it named (or symlinked as) mount.9p
folks who mount as root could get the helper automatically. This
would be nice for the standard Linux admin who is mounting crap as
root anyways and trips
On Mon, Jul 13, 2009 at 4:45 PM, hiro23h...@googlemail.com wrote:
When I need remote access I nowadays use v9fs+ssh.
Multi-user auth in kernel like you propose sounds nice and consistent,
but too complicated. It doesn't fit linux, and thus an additional
deamon would mean one more place of
On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergeneri...@gmail.com wrote:
On Mon, Jul 13, 2009 at 4:45 PM, hiro23h...@googlemail.com wrote:
When I need remote access I nowadays use v9fs+ssh.
Multi-user auth in kernel like you propose sounds nice and consistent,
but too complicated. It
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote:
We hope to. One of the reasons it would actually be unwise to let
anyone mount anything now is that no one uses per-process namespaces.
That's probably fine on your desktop, but not on a server where 20
people try to mount
On Mon, Jul 13, 2009 at 6:16 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote:
We hope to. One of the reasons it would actually be unwise to let
anyone mount anything now is that no one uses per-process namespaces.
That's probably
On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergeneri...@gmail.com wrote:
Not sure how easy or difficult this would be inside the kernel -- the
central problem last time I looked at it was it was difficult to
unshare namespace after the fork.
Well, my mount command cheated. When you ran the
On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote:
We hope to. One of the reasons it would actually be unwise to let
anyone mount anything now is that no one uses per-process namespaces.
That's probably
On Mon, Jul 13, 2009 at 6:37 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergeneri...@gmail.com wrote:
Not sure how easy or difficult this would be inside the kernel -- the
central problem last time I looked at it was it was difficult to
unshare
It would be nice to fix up mounts so that you didn't need to be root
and all that crap, and then make it the default, but I doubt Linus
would let it fly. I get the feeling that private namespaces are viewed
like chroots: a security feature no one but pros needs. Unfortunately
not many linux
On Mon, Jul 13, 2009 at 7:50 PM, erik quanstromquans...@quanstro.net wrote:
It would be nice to fix up mounts so that you didn't need to be root
and all that crap, and then make it the default, but I doubt Linus
would let it fly. I get the feeling that private namespaces are viewed
like
On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote:
On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote:
We hope to. One of the reasons it would actually be unwise to let
anyone mount anything
(then again, i have a feeling the same could be said of
plan 9.)
Of course, everything has cruft. But Plan 9 is decent to imitate since
it is less crufty.
not only is plan 9 cleaner, it's core ideas are all high quality,
and one can understand it. so when it comes time to add one's
own
you need to find the niche and provide programs, which people can just
use. Or you need to find the niche that lets other people write
programs, and we're not where we need to be on that score. It's still
too hard for people to write servers and there's no clear answer on
which library to use.
Could we solve this by making private mounts the default (or only
allowed) behavior?
I've wondered if there's enough context information
that the fs driver could fake per-process mount points
directly. For example, I mount v9fs on /n. Initially
I have no remote mounts in there, but I have
On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergeneri...@gmail.com wrote:
On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote:
On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul 13, 2009 at 3:18 PM, J.R. Maurojrm8...@gmail.com wrote:
We hope to.
On Mon, Jul 13, 2009 at 8:08 PM, ron minnichrminn...@gmail.com wrote:
you need to find the niche and provide programs, which people can just
use. Or you need to find the niche that lets other people write
programs, and we're not where we need to be on that score. It's still
too hard for people
On Mon Jul 13 20:43:21 EDT 2009, news...@lava.net wrote:
Could we solve this by making private mounts the default (or only
allowed) behavior?
I've wondered if there's enough context information
that the fs driver could fake per-process mount points
directly. For example, I mount v9fs on
On Mon, Jul 13, 2009 at 7:42 PM, Tim Newshamnews...@lava.net wrote:
Could we solve this by making private mounts the default (or only
allowed) behavior?
I've wondered if there's enough context information
that the fs driver could fake per-process mount points
directly.
Lucho's v9fs auth
On Mon, Jul 13, 2009 at 7:42 PM, J.R. Maurojrm8...@gmail.com wrote:
On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergeneri...@gmail.com wrote:
On Mon, Jul 13, 2009 at 6:41 PM, J.R. Maurojrm8...@gmail.com wrote:
On Mon, Jul 13, 2009 at 7:16 PM, ron minnichrminn...@gmail.com wrote:
On Mon, Jul
I believe Priyanka has some significant work on getting private
per-process namespaces in Glendix for this year's GSoC.
--dho
I don't see why should we do tricks like that. We have support for
private namespaces, why should we make the linux code even more
complicated?
Some of us use systems other than Linux. Also, it may be
easier to sell one idea (v9fs) than two ideas (v9fs +
private name spaces). It seems that
I have a variant using Inferno right now, mounting the file system directly
from the stdin/stdout of the emu.
This isn't very practical in my case, because I need to port emu
to the Yeeloong first. Hiro suggested using v9fs+ssh, I'd be
interested in that option as a stopgap, but again some
On the security side, I helped get the plan9-style authentication
device in the mainline kernel. It's in staging. I guess the PAM module
is 90% done, but they need some help if anyone is interested.
Where do I look for this? I don't know Linux or PAM well enough to
believe I can help, but one
I've wondered if there's enough context information
that the fs driver could fake per-process mount points
directly.
A totally uneducated shot in the dark: would having a userspace
mount command that creates a private namespace (vaguely what you
describe in your note) not be a good starting
On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
Hmmm, that's really new behavior-- never used to fail without mount helper.
Can you give the exact error message?
# strace -o trace.txt mount -t 9p thenewsh.com /mnt
mount: Protocol not supported
Trace.txt is attached with full details.
Try an ip address instead of the DNS name. For the DNS name you'll
need a helper like 9mount.
Sent from my iPhone
On Jul 11, 2009, at 2:03 PM, Tim Newsham news...@lava.net wrote:
On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
Hmmm, that's really new behavior-- never used to fail without
On Sat, Jul 11, 2009 at 3:03 PM, Tim Newshamnews...@lava.net wrote:
On Sat, 11 Jul 2009, Eric Van Hensbergen wrote:
Hmmm, that's really new behavior-- never used to fail without mount
helper. Can you give the exact error message?
# strace -o trace.txt mount -t 9p thenewsh.com /mnt
Linux
Using sqweek's 9mount is strongly recommended if you are using v9fs,
not only it deals with the silly and deficient linux mount command
(which somebody should submit a patch for some day I guess if we want
to be taken seriously as an nfs replacement), but it also hides the
ever changing v9fs mount
62 matches
Mail list logo
