* [9fans] v9fs question @ 2009-07-11 18:46 Tim Newsham 2009-07-11 18:50 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: Tim Newsham @ 2009-07-11 18:46 UTC (permalink / raw) To: 9fans The documentation in the linux kernel says you merely mount -t 9p ipaddress /mntpoint this fails on my system since /sbin/mount tries to execute /sbin/mount.9p and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which ubunutu package should have this? If not, where I might find sources? Ironic since Ubuntu came with the 9p kernel module) Or should I be using a different mount program for the purpose? The linux Documentation/filesystems/9p.txt should probably be updated with more details, either way. Tim Newsham http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 18:46 [9fans] v9fs question Tim Newsham @ 2009-07-11 18:50 ` Eric Van Hensbergen 2009-07-11 19:03 ` Tim Newsham 0 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-11 18:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hmmm, that's really new behavior-- never used to fail without mount helper. Can you give the exact error message? Patches to documentation and/or code gladly accepted. Sent from my iPhone On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: > The documentation in the linux kernel says you merely > > mount -t 9p ipaddress /mntpoint > > this fails on my system since /sbin/mount tries to execute /sbin/ > mount.9p and fails. Am I supposed to have an /sbin/mount.9p? > (Anyone know which ubunutu package should have this? If not, where > I might find sources? Ironic since Ubuntu came with the 9p kernel > module) Or should I be using a different mount program for the > purpose? > > The linux Documentation/filesystems/9p.txt should probably be > updated with more details, either way. > > Tim Newsham > http://www.thenewsh.com/~newsham/ > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 18:50 ` Eric Van Hensbergen @ 2009-07-11 19:03 ` Tim Newsham 2009-07-11 19:47 ` Eric Van Hensbergen ` (2 more replies) 0 siblings, 3 replies; 65+ messages in thread From: Tim Newsham @ 2009-07-11 19:03 UTC (permalink / raw) To: Eric Van Hensbergen; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: TEXT/PLAIN, Size: 1145 bytes --] 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. I've tried several variants, such as thenewsh.com:/path with similar results. > On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: > >> The documentation in the linux kernel says you merely >> >> mount -t 9p ipaddress /mntpoint >> >> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p >> and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which >> ubunutu package should have this? If not, where I might find sources? >> Ironic since Ubuntu came with the 9p kernel module) Or should I be using a >> different mount program for the purpose? >> >> The linux Documentation/filesystems/9p.txt should probably be updated with >> more details, either way. >> >> Tim Newsham >> http://www.thenewsh.com/~newsham/ >> > Tim Newsham http://www.thenewsh.com/~newsham/ [-- Attachment #2: Type: TEXT/plain, Size: 10506 bytes --] execve("/bin/mount", ["mount", "-t", "9p", "thenewsh.com", "/mnt"], [/* 39 vars */]) = 0 brk(0) = 0x805e000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7faf000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=53546, ...}) = 0 mmap2(NULL, 53546, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa1000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300@\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=95948, ...}) = 0 mmap2(NULL, 101180, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f88000 mmap2(0xb7f9f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0xb7f9f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0 mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e39000 mmap2(0xb7f82000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f82000 mmap2(0xb7f85000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f85000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e38000 mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e34000 mmap2(0xb7e36000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7e36000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e33000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e33720, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7f82000, 4096, PROT_READ) = 0 munmap(0xb7fa1000, 53546) = 0 brk(0) = 0x805e000 brk(0x807f000) = 0x807f000 open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) statfs64("/selinux", 84, 0xbfea3dfc) = -1 ENOENT (No such file or directory) open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fae000 read(3, "rootfs / rootfs rw 0 0\nnone /sys"..., 1024) = 1024 read(3, "p_id=1000 0 0\n", 1024) = 14 read(3, "", 1024) = 0 close(3) = 0 munmap(0xb7fae000, 4096) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fae000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2586 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7fae000, 4096) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=373, ...}) = 0 mmap2(NULL, 373, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fae000 close(3) = 0 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=25700, ...}) = 0 mmap2(NULL, 25700, PROT_READ, MAP_SHARED, 3, 0) = 0xb7fa7000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MEASUREMENT", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0 mmap2(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa6000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_TELEPHONE", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_TELEPHONE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa5000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_ADDRESS", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_ADDRESS", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0 mmap2(NULL, 155, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa4000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_NAME", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=77, ...}) = 0 mmap2(NULL, 77, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa3000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_PAPER", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_PAPER", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0 mmap2(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa2000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 close(3) = 0 open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=52, ...}) = 0 mmap2(NULL, 52, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa1000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MONETARY", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=286, ...}) = 0 mmap2(NULL, 286, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e32000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=921214, ...}) = 0 mmap2(NULL, 921214, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d51000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_TIME", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_TIME", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2451, ...}) = 0 mmap2(NULL, 2451, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d50000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0 mmap2(NULL, 54, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d4f000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=254076, ...}) = 0 mmap2(NULL, 254076, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d10000 close(3) = 0 umask(022) = 022 open("/dev/null", O_RDWR|O_LARGEFILE) = 3 close(3) = 0 getuid32() = 0 geteuid32() = 0 lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=650, ...}) = 0 getcwd("/usr/src/linux-source-2.6.24", 4095) = 29 readlink("/usr/src/linux-source-2.6.24/thenewsh.com", 0xbfea2c17, 4096) = -1 ENOENT (No such file or directory) stat64("/sbin/mount.9p", 0xbfea49c4) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 stat64("/sbin/mount.9p", 0xbfea4994) = -1 ENOENT (No such file or directory) mount("thenewsh.com", "/mnt", "9p", MS_MGC_VAL, NULL) = -1 EPROTONOSUPPORT (Protocol not supported) rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "mount: Protocol not supported", 29) = 29 write(2, "\n", 1) = 1 exit_group(32) = ? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 19:03 ` Tim Newsham @ 2009-07-11 19:47 ` Eric Van Hensbergen 2009-07-11 20:03 ` J.R. Mauro 2009-07-13 8:24 ` sqweek 2 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-11 19:47 UTC (permalink / raw) To: Tim Newsham; +Cc: Fans of the OS Plan 9 from Bell Labs 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 <newsham@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 > mount: Protocol not supported > > Trace.txt is attached with full details. > > I've tried several variants, such as thenewsh.com:/path > with similar results. > >> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: >> >>> The documentation in the linux kernel says you merely >>> >>> mount -t 9p ipaddress /mntpoint >>> this fails on my system since /sbin/mount tries to execute /sbin/ >>> mount.9p and fails. Am I supposed to have an /sbin/mount.9p? >>> (Anyone know which ubunutu package should have this? If not, >>> where I might find sources? Ironic since Ubuntu came with the 9p >>> kernel module) Or should I be using a different mount program for >>> the purpose? >>> The linux Documentation/filesystems/9p.txt should probably be >>> updated with more details, either way. >>> Tim Newsham >>> http://www.thenewsh.com/~newsham/ >> > > Tim Newsham > http://www.thenewsh.com/~newsham/ > <trace.txt> ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 19:03 ` Tim Newsham 2009-07-11 19:47 ` Eric Van Hensbergen @ 2009-07-11 20:03 ` J.R. Mauro 2009-07-12 3:19 ` Uriel 2009-07-13 8:24 ` sqweek 2 siblings, 1 reply; 65+ messages in thread From: J.R. Mauro @ 2009-07-11 20:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Jul 11, 2009 at 3:03 PM, Tim Newsham<newsham@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 doesn't do resolution for you, you have to give raw ip addresses. Maybe not the problem, but worth pointing out. > mount: Protocol not supported > > Trace.txt is attached with full details. > > I've tried several variants, such as thenewsh.com:/path > with similar results. > >> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: >> >>> The documentation in the linux kernel says you merely >>> >>> mount -t 9p ipaddress /mntpoint >>> >>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p >>> and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which >>> ubunutu package should have this? If not, where I might find sources? >>> Ironic since Ubuntu came with the 9p kernel module) Or should I be using a >>> different mount program for the purpose? >>> >>> The linux Documentation/filesystems/9p.txt should probably be updated >>> with more details, either way. >>> >>> Tim Newsham >>> http://www.thenewsh.com/~newsham/ >>> >> > > Tim Newsham > http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 20:03 ` J.R. Mauro @ 2009-07-12 3:19 ` Uriel 0 siblings, 0 replies; 65+ messages in thread From: Uriel @ 2009-07-12 3:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 flags under a more consistent and clear interface. The ability to mount and unmount 9p file servers without being root is just a great extra. http://sqweek.dnsdojo.org/code/9mount/ uriel P.S.: Oh, and I think debian even packages 9mount! On Sat, Jul 11, 2009 at 10:03 PM, J.R. Mauro<jrm8005@gmail.com> wrote: > On Sat, Jul 11, 2009 at 3:03 PM, Tim Newsham<newsham@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 doesn't do resolution for you, you have to give raw ip > addresses. Maybe not the problem, but worth pointing out. > >> mount: Protocol not supported >> >> Trace.txt is attached with full details. >> >> I've tried several variants, such as thenewsh.com:/path >> with similar results. >> >>> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: >>> >>>> The documentation in the linux kernel says you merely >>>> >>>> mount -t 9p ipaddress /mntpoint >>>> >>>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p >>>> and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which >>>> ubunutu package should have this? If not, where I might find sources? >>>> Ironic since Ubuntu came with the 9p kernel module) Or should I be using a >>>> different mount program for the purpose? >>>> >>>> The linux Documentation/filesystems/9p.txt should probably be updated >>>> with more details, either way. >>>> >>>> Tim Newsham >>>> http://www.thenewsh.com/~newsham/ >>>> >>> >> >> Tim Newsham >> http://www.thenewsh.com/~newsham/ > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-11 19:03 ` Tim Newsham 2009-07-11 19:47 ` Eric Van Hensbergen 2009-07-11 20:03 ` J.R. Mauro @ 2009-07-13 8:24 ` sqweek 2009-07-13 8:51 ` hiro ` (3 more replies) 2 siblings, 4 replies; 65+ messages in thread From: sqweek @ 2009-07-13 8:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 you an "Invalid argument" error instead of "Protocol not supported". However the only place I see EPROTONOSUPPORT looks like an impossible code path... unless you have CONFIG_9P_FS enabled in your kernel but not CONFIG_NET_9P... which also shouldn't be possible with a current kernel. What version are you running? 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. Oh, and to preempt the question why 9mount is not packaged as mount.9p - mount(8) requires that you are root or your mount target is in fstab with '-o user' before calling the helper, defeating the purpose of an SUID mount.9p. -sqweek 2009/7/12 Tim Newsham <newsham@lava.net>: > 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. > > I've tried several variants, such as thenewsh.com:/path > with similar results. > >> On Jul 11, 2009, at 1:46 PM, Tim Newsham <newsham@lava.net> wrote: >> >>> The documentation in the linux kernel says you merely >>> >>> mount -t 9p ipaddress /mntpoint >>> >>> this fails on my system since /sbin/mount tries to execute /sbin/mount.9p >>> and fails. Am I supposed to have an /sbin/mount.9p? (Anyone know which >>> ubunutu package should have this? If not, where I might find sources? >>> Ironic since Ubuntu came with the 9p kernel module) Or should I be using a >>> different mount program for the purpose? >>> >>> The linux Documentation/filesystems/9p.txt should probably be updated >>> with more details, either way. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 8:24 ` sqweek @ 2009-07-13 8:51 ` hiro 2009-07-13 14:20 ` Eric Van Hensbergen ` (2 subsequent siblings) 3 siblings, 0 replies; 65+ messages in thread From: hiro @ 2009-07-13 8:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > mount: Protocol not supported There was a time where you had to modprobe 9p2000 first. Should be worth a try. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 8:24 ` sqweek 2009-07-13 8:51 ` hiro @ 2009-07-13 14:20 ` Eric Van Hensbergen 2009-07-13 20:44 ` hiro 2009-07-14 19:05 ` sqweek 2009-07-13 14:59 ` lucio 2009-07-13 15:08 ` Latchesar Ionkov 3 siblings, 2 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 14:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 3:24 AM, sqweek<sqweek@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 already available in some p9p code that lucho wrote called amount. It would complicate build a bit because you need libraries from p9p, but perhaps it could be conditional compilation. > Oh, and to preempt the question why 9mount is not packaged as > mount.9p - mount(8) requires that you are root or your mount target is > in fstab with '-o user' before calling the helper, defeating the > purpose of an SUID mount.9p. 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 which mount has always done DNS for. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 14:20 ` Eric Van Hensbergen @ 2009-07-13 20:44 ` hiro 2009-07-13 21:45 ` hiro 2009-07-13 22:00 ` Eric Van Hensbergen 2009-07-14 19:05 ` sqweek 1 sibling, 2 replies; 65+ messages in thread From: hiro @ 2009-07-13 20:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 which mount has always done DNS for. If they invest their time to find out about the mount.9p command, won't they rather easily understand the DNS issue? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 20:44 ` hiro @ 2009-07-13 21:45 ` hiro 2009-07-13 22:05 ` Eric Van Hensbergen 2009-07-13 22:00 ` Eric Van Hensbergen 1 sibling, 1 reply; 65+ messages in thread From: hiro @ 2009-07-13 21:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 be used locally I don't think it would be good enough for our distributed operating system's main network protocol. >From a security (and perhaps simplicity) point of view userspace authentication sounds more reasonable to me, p9p together with something like fuse (even together with the new userspace hackery) or perhaps a single-user v9fs combined with inferno for doing the auth/crypt work seems a lot more reasonable to me than additional clever hackery from the plan9 side. Not sure if somebody has something like this working already... ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 21:45 ` hiro @ 2009-07-13 22:05 ` Eric Van Hensbergen 2009-07-13 22:18 ` J.R. Mauro 2009-07-14 4:26 ` lucio 0 siblings, 2 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 22:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 4:45 PM, hiro<23hiro@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 security relevant code prone to > bugs. > While I agree with that being the state of things today, it doesn't mean we shouldn't push for better. Maybe the Glendix folks will make things consistent (and bug free). > > From a security (and perhaps simplicity) point of view userspace > authentication sounds more reasonable to me, p9p together with > something like fuse (even together with the new userspace hackery) or > perhaps a single-user v9fs combined with inferno for doing the > auth/crypt work seems a lot more reasonable to me than additional > clever hackery from the plan9 side. Not sure if somebody has something > like this working already... > I have a variant using Inferno right now, mounting the file system directly from the stdin/stdout of the emu. Combined with private namespaces it provides a seemingly secure mechanism for accessing remote resources as well as providing local resources to remote cpu services. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 22:05 ` Eric Van Hensbergen @ 2009-07-13 22:18 ` J.R. Mauro 2009-07-13 23:16 ` ron minnich 2009-07-14 4:29 ` lucio 2009-07-14 4:26 ` lucio 1 sibling, 2 replies; 65+ messages in thread From: J.R. Mauro @ 2009-07-13 22:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote: > On Mon, Jul 13, 2009 at 4:45 PM, hiro<23hiro@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 security relevant code prone to >> bugs. >> > > While I agree with that being the state of things today, it doesn't mean > we shouldn't push for better. Maybe the Glendix folks will make things > consistent (and bug free). 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 something under /mnt/foo or whatnot. 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. > >> >> From a security (and perhaps simplicity) point of view userspace >> authentication sounds more reasonable to me, p9p together with >> something like fuse (even together with the new userspace hackery) or >> perhaps a single-user v9fs combined with inferno for doing the >> auth/crypt work seems a lot more reasonable to me than additional >> clever hackery from the plan9 side. Not sure if somebody has something >> like this working already... >> > > I have a variant using Inferno right now, mounting the file system directly > from the stdin/stdout of the emu. Combined with private namespaces it > provides a seemingly secure mechanism for accessing remote resources > as well as providing local resources to remote cpu services. > > -eric > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 22:18 ` J.R. Mauro @ 2009-07-13 23:16 ` ron minnich 2009-07-13 23:22 ` Eric Van Hensbergen ` (2 more replies) 2009-07-14 4:29 ` lucio 1 sibling, 3 replies; 65+ messages in thread From: ron minnich @ 2009-07-13 23:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@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 something under /mnt/foo or whatnot. Could we solve this by making private mounts the default (or only allowed) behavior? That's how I did it long ago: it took real effort to make a mount non-private. ron ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:16 ` ron minnich @ 2009-07-13 23:22 ` Eric Van Hensbergen 2009-07-13 23:37 ` ron minnich 2009-07-13 23:41 ` J.R. Mauro 2009-07-14 0:42 ` Tim Newsham 2 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 23:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 6:16 PM, ron minnich<rminnich@gmail.com> wrote: > On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@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 something under /mnt/foo or whatnot. > > Could we solve this by making private mounts the default (or only > allowed) behavior? > > That's how I did it long ago: it took real effort to make a mount non-private. > 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. Of course you could check to make sure you were not in the global namespace and error -- that should be easy enough. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:22 ` Eric Van Hensbergen @ 2009-07-13 23:37 ` ron minnich 2009-07-13 23:47 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: ron minnich @ 2009-07-13 23:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen<ericvh@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 mount command, it did a fork and set CLONE_NS. You were, at that point, in a private name space. Yes, ugly, but it certainly ensured a private mount. > Of course you could check to make > sure you were not in the global namespace and error -- that should be > easy enough. That's a nice idea. You require users of the command to have a clean name space, or at least a non-global one, before you mount. That seems like a nice solution to the problem. ron ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:37 ` ron minnich @ 2009-07-13 23:47 ` Eric Van Hensbergen 0 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 23:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 6:37 PM, ron minnich<rminnich@gmail.com> wrote: > On Mon, Jul 13, 2009 at 4:22 PM, Eric Van Hensbergen<ericvh@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 mount command, it did > a fork and set CLONE_NS. You were, at that point, in a private name > space. Yes, ugly, but it certainly ensured a private mount. > Sure, and 9mount could do the same thing, but it would be nice to enforce it from the kernel somehow. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:16 ` ron minnich 2009-07-13 23:22 ` Eric Van Hensbergen @ 2009-07-13 23:41 ` J.R. Mauro 2009-07-13 23:50 ` erik quanstrom 2009-07-14 0:01 ` Eric Van Hensbergen 2009-07-14 0:42 ` Tim Newsham 2 siblings, 2 replies; 65+ messages in thread From: J.R. Mauro @ 2009-07-13 23:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote: > On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@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 something under /mnt/foo or whatnot. > > Could we solve this by making private mounts the default (or only > allowed) behavior? 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 devs seem to care about plan 9, and that has a negative impact on how much stuff can happen. Hopefully we'll gradually wear them down, or keep a minifork/patchset. > > That's how I did it long ago: it took real effort to make a mount non-private. > > ron > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:41 ` J.R. Mauro @ 2009-07-13 23:50 ` erik quanstrom 2009-07-14 0:00 ` J.R. Mauro 2009-07-14 0:01 ` Eric Van Hensbergen 1 sibling, 1 reply; 65+ messages in thread From: erik quanstrom @ 2009-07-13 23:50 UTC (permalink / raw) To: 9fans > 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 devs seem to care about plan 9, and that has a negative > impact on how much stuff can happen. Hopefully we'll gradually wear > them down, or keep a minifork/patchset. i think if the linux folks really appreciated what one could do with namespaces, a number of the container bolt-on things could be implemented in terms of namespace. (then again, i have a feeling the same could be said of plan 9.) it's quite interesting to see how taking the seemingly- conservative approach at every turn can take you much further from v7 than even pretty radical breaks like plan 9. - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:50 ` erik quanstrom @ 2009-07-14 0:00 ` J.R. Mauro 2009-07-14 0:06 ` erik quanstrom 0 siblings, 1 reply; 65+ messages in thread From: J.R. Mauro @ 2009-07-14 0:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 7:50 PM, erik quanstrom<quanstro@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 chroots: a security feature no one but pros needs. Unfortunately >> not many linux devs seem to care about plan 9, and that has a negative >> impact on how much stuff can happen. Hopefully we'll gradually wear >> them down, or keep a minifork/patchset. > > i think if the linux folks really appreciated what one > could do with namespaces, a number of the > container bolt-on things could be implemented in terms > of namespace. So much cruft would go right out the window if only it were accessible. > > (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. > > it's quite interesting to see how taking the seemingly- > conservative approach at every turn can take you > much further from v7 than even pretty radical breaks > like plan 9. > > - erik > Agreed. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:00 ` J.R. Mauro @ 2009-07-14 0:06 ` erik quanstrom 0 siblings, 0 replies; 65+ messages in thread From: erik quanstrom @ 2009-07-14 0:06 UTC (permalink / raw) To: 9fans > > (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 brand of cruft, it's easy to do. unfortunately plan 9 does not make good ideas any easier to come by. - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:41 ` J.R. Mauro 2009-07-13 23:50 ` erik quanstrom @ 2009-07-14 0:01 ` Eric Van Hensbergen 2009-07-14 0:08 ` ron minnich 2009-07-14 0:42 ` J.R. Mauro 1 sibling, 2 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 0:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote: > On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote: >> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@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 something under /mnt/foo or whatnot. >> >> Could we solve this by making private mounts the default (or only >> allowed) behavior? > > 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 devs seem to care about plan 9, and that has a negative > impact on how much stuff can happen. Hopefully we'll gradually wear > them down, or keep a minifork/patchset. > When things get further along we can do a coordinated assault :) We've got bits of mindshare spread out over different places including a couple of the major distributions, if things can be made optional they'll make it into mainline and then we just need to focus on education by presenting demos at places like OLS, Plumbers, and LCA -- and maybe get some good video podcast tutorials up on YouTube to get people wanting and using the features. Of course the main thing is finding a niche that needs the features and selling them on it. The focus on cloud computing and other cluster type solutions in mainstream computing may be helpful there. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:01 ` Eric Van Hensbergen @ 2009-07-14 0:08 ` ron minnich 2009-07-14 0:46 ` J.R. Mauro 2009-07-14 0:42 ` J.R. Mauro 1 sibling, 1 reply; 65+ messages in thread From: ron minnich @ 2009-07-14 0:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. FUSE has done a great job in this area. ron ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:08 ` ron minnich @ 2009-07-14 0:46 ` J.R. Mauro 0 siblings, 0 replies; 65+ messages in thread From: J.R. Mauro @ 2009-07-14 0:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 8:08 PM, ron minnich<rminnich@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 to write servers and there's no clear answer on > which library to use. FUSE has done a great job in this area. > > ron > > Unfortunately, the only niches being filled are by other 9fans :P We've got some cool stuff by sqweek and Kris Maglione that are linux-specific, but the world at large is mostly ignorant of it. I'm sure adding things like /net will turn the tide. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:01 ` Eric Van Hensbergen 2009-07-14 0:08 ` ron minnich @ 2009-07-14 0:42 ` J.R. Mauro 2009-07-14 0:58 ` Eric Van Hensbergen 1 sibling, 1 reply; 65+ messages in thread From: J.R. Mauro @ 2009-07-14 0:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote: > On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote: >> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote: >>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@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 something under /mnt/foo or whatnot. >>> >>> Could we solve this by making private mounts the default (or only >>> allowed) behavior? >> >> 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 devs seem to care about plan 9, and that has a negative >> impact on how much stuff can happen. Hopefully we'll gradually wear >> them down, or keep a minifork/patchset. >> > > When things get further along we can do a coordinated assault :) Indeed :) > We've got bits of mindshare spread out over different places including > a couple of the major distributions, if things can be made optional We've got Greg KH and Christoph on our side. I'm sure viro would also be a voice in our favor, and he has some pull with Linus > they'll make it into mainline and then we just need to focus on > education by presenting demos at places like OLS, Plumbers, and LCA -- > and maybe get some good video podcast tutorials up on YouTube to get > people wanting and using the features. Of course the main thing is > finding a niche that needs the features and selling them on it. The > focus on cloud computing and other cluster type solutions in > mainstream computing may be helpful there. Yes, showing people the benefits of /net and how simple clustering is will be the path to victory. People will be amazed when they see how easy it is to make 5 computers pretend to be one. > > -eric > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:42 ` J.R. Mauro @ 2009-07-14 0:58 ` Eric Van Hensbergen 2009-07-14 1:28 ` Latchesar Ionkov 0 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 0:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 7:42 PM, J.R. Mauro<jrm8005@gmail.com> wrote: > On Mon, Jul 13, 2009 at 8:01 PM, Eric Van Hensbergen<ericvh@gmail.com> wrote: >> On Mon, Jul 13, 2009 at 6:41 PM, J.R. Mauro<jrm8005@gmail.com> wrote: >>> On Mon, Jul 13, 2009 at 7:16 PM, ron minnich<rminnich@gmail.com> wrote: >>>> On Mon, Jul 13, 2009 at 3:18 PM, J.R. Mauro<jrm8005@gmail.com> wrote: >> they'll make it into mainline and then we just need to focus on >> education by presenting demos at places like OLS, Plumbers, and LCA -- >> and maybe get some good video podcast tutorials up on YouTube to get >> people wanting and using the features. Of course the main thing is >> finding a niche that needs the features and selling them on it. The >> focus on cloud computing and other cluster type solutions in >> mainstream computing may be helpful there. > > Yes, showing people the benefits of /net and how simple clustering is > will be the path to victory. People will be amazed when they see how > easy it is to make 5 computers pretend to be one. > I can validate this to some extent. The ability to transitively mount /net was one of the most popular features of the Library OS environment I worked on a few years back. It was really easy for Linux and UNIX minded folks to grasp how powerful it was: http://portal.acm.org/citation.cfm?id=1254810.1254817 -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* [9fans] v9fs question 2009-07-14 0:58 ` Eric Van Hensbergen @ 2009-07-14 1:28 ` Latchesar Ionkov 2009-07-14 1:35 ` Devon H. O'Dell 2009-07-14 2:05 ` Tim Newsham 0 siblings, 2 replies; 65+ messages in thread From: Latchesar Ionkov @ 2009-07-14 1:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? Thanks, Lucho On Monday, July 13, 2009, Tim Newsham <newsham@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 /n. Initially > I have no remote mounts in there, but I have /n/ctl. > I echo "mount 1.2.3.4 foo" to /n/ctl and now I have > /n/foo which is served from 1.2.3.4 for my process, but > other processes dont see /n/foo. I fork a child and it > gets /n/foo, too. In the child I mount another directory > and the changes are seen in both the child and the parent. > I then echo "copyns" to /n/ctl and then perform another > mount and the new mount is visible in the child process but > not the parent process. > > This would of course require that the kernel filesystem > (probably vfs layer) could distinguish who made a filesystem > request. It might also require some hackery to get the > inheritance on fork working properly (although perhaps some > existing unix mechanism could be reused for this purpose, such > as session and process group stuff). > > Feasible at all in Linux? *BSD? Win32? > > Upsides: Kernel doesnt need to otherwise support any notion > of mount namespace. Removes security concerns of per-process > namespaces since you could never rebind over /etc/passwd or > other important files. > > Downsides: Perhaps not possible. Mount/bind namespaces not > universally present, only within certain mount points. > > > ron > > > Tim Newsham > http://www.thenewsh.com/~newsham/ > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 1:28 ` Latchesar Ionkov @ 2009-07-14 1:35 ` Devon H. O'Dell 2009-07-14 2:05 ` Tim Newsham 1 sibling, 0 replies; 65+ messages in thread From: Devon H. O'Dell @ 2009-07-14 1:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I believe Priyanka has some significant work on getting private per-process namespaces in Glendix for this year's GSoC. --dho ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 1:28 ` Latchesar Ionkov 2009-07-14 1:35 ` Devon H. O'Dell @ 2009-07-14 2:05 ` Tim Newsham 1 sibling, 0 replies; 65+ messages in thread From: Tim Newsham @ 2009-07-14 2:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: TEXT/PLAIN, Size: 462 bytes --] > 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 people who have used UNIX for a long time have a natural aversion to the latter. > Thanks, > Lucho Tim Newsham http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 23:16 ` ron minnich 2009-07-13 23:22 ` Eric Van Hensbergen 2009-07-13 23:41 ` J.R. Mauro @ 2009-07-14 0:42 ` Tim Newsham 2009-07-14 0:50 ` erik quanstrom ` (2 more replies) 2 siblings, 3 replies; 65+ messages in thread From: Tim Newsham @ 2009-07-14 0:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 /n/ctl. I echo "mount 1.2.3.4 foo" to /n/ctl and now I have /n/foo which is served from 1.2.3.4 for my process, but other processes dont see /n/foo. I fork a child and it gets /n/foo, too. In the child I mount another directory and the changes are seen in both the child and the parent. I then echo "copyns" to /n/ctl and then perform another mount and the new mount is visible in the child process but not the parent process. This would of course require that the kernel filesystem (probably vfs layer) could distinguish who made a filesystem request. It might also require some hackery to get the inheritance on fork working properly (although perhaps some existing unix mechanism could be reused for this purpose, such as session and process group stuff). Feasible at all in Linux? *BSD? Win32? Upsides: Kernel doesnt need to otherwise support any notion of mount namespace. Removes security concerns of per-process namespaces since you could never rebind over /etc/passwd or other important files. Downsides: Perhaps not possible. Mount/bind namespaces not universally present, only within certain mount points. > ron Tim Newsham http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:42 ` Tim Newsham @ 2009-07-14 0:50 ` erik quanstrom 2009-07-14 0:56 ` Eric Van Hensbergen 2009-07-14 4:51 ` lucio 2 siblings, 0 replies; 65+ messages in thread From: erik quanstrom @ 2009-07-14 0:50 UTC (permalink / raw) To: 9fans On Mon Jul 13 20:43:21 EDT 2009, newsham@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 /n. Initially > I have no remote mounts in there, but I have /n/ctl. > I echo "mount 1.2.3.4 foo" to /n/ctl and now I have > /n/foo which is served from 1.2.3.4 for my process, but > other processes dont see /n/foo. I fork a child and it > gets /n/foo, too. In the child I mount another directory > and the changes are seen in both the child and the parent. > I then echo "copyns" to /n/ctl and then perform another > mount and the new mount is visible in the child process but > not the parent process. i believe you've described the speaks-for relationship in plan 9. > > This would of course require that the [linux] kernel filesystem > (probably vfs layer) could distinguish who made a filesystem > request. It might also require some hackery to get the > inheritance on fork working properly (although perhaps some > existing unix mechanism could be reused for this purpose, such > as session and process group stuff). how could the fs record the creat without having the uid/gid? - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:42 ` Tim Newsham 2009-07-14 0:50 ` erik quanstrom @ 2009-07-14 0:56 ` Eric Van Hensbergen 2009-07-14 4:51 ` lucio 2 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 0:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 7:42 PM, Tim Newsham<newsham@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 mechanisms allow for per-user namespaces (sort-of) as they force a new-attach ever time a new user crosses the mount point. I think there's enough knowledge (in Linux anyways) to obtain the current process. The hard bit is, as you say, managing inheritance and other namespace process controls. This is why its probably best implemented in a more integrated fashion. I have been playing with using Inferno to construct dynamic namespaces for me in Linux and MacOSX. The idea is to setup the namespace and then back mount it (with v9fs and FUSE) in either a private namespace or a chroot. I'm using this to implement an xcpu2-like environment purely with Inferno (remote threads get their own private namespace sandboxes to run in with an Inferno crafted namespace). Not as powerful as the whole enchilada, but it provides a container environment with composable namespaces. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 0:42 ` Tim Newsham 2009-07-14 0:50 ` erik quanstrom 2009-07-14 0:56 ` Eric Van Hensbergen @ 2009-07-14 4:51 ` lucio 2 siblings, 0 replies; 65+ messages in thread From: lucio @ 2009-07-14 4:51 UTC (permalink / raw) To: 9fans > 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 point? I'd use /ns rather than /n as the root, but that's really a small thing. Unfortunately, I have no idea (yet) of the machinery provided by Linux to construct private namespaces. And I am not aware of any equivalent work in the NetBSD world. ++L ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 22:18 ` J.R. Mauro 2009-07-13 23:16 ` ron minnich @ 2009-07-14 4:29 ` lucio 1 sibling, 0 replies; 65+ messages in thread From: lucio @ 2009-07-14 4:29 UTC (permalink / raw) To: jrm8005, 9fans > 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 never knows. ++L ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 22:05 ` Eric Van Hensbergen 2009-07-13 22:18 ` J.R. Mauro @ 2009-07-14 4:26 ` lucio 1 sibling, 0 replies; 65+ messages in thread From: lucio @ 2009-07-14 4:26 UTC (permalink / raw) To: 9fans > 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 directions would be helpful. ++L ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 20:44 ` hiro 2009-07-13 21:45 ` hiro @ 2009-07-13 22:00 ` Eric Van Hensbergen 1 sibling, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 22:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 3:44 PM, hiro<23hiro@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 over the DNS resolution error because all >> they are used to is NFS which mount has always done DNS for. > > If they invest their time to find out about the mount.9p command, > won't they rather easily understand the DNS issue? > Well, if someone installs the mount.9p package, then it "just works" -- at least at the same level of "just works" as CIFS and the other second-class distributed file systems for Linux. Its easier to tell someone to install a package than step them through installing and using a different command for mount than mount. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 14:20 ` Eric Van Hensbergen 2009-07-13 20:44 ` hiro @ 2009-07-14 19:05 ` sqweek 2009-07-14 20:11 ` Eric Van Hensbergen 1 sibling, 1 reply; 65+ messages in thread From: sqweek @ 2009-07-14 19:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/7/13 Eric Van Hensbergen <ericvh@gmail.com>: > On Mon, Jul 13, 2009 at 3:24 AM, sqweek<sqweek@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 already available in some p9p code that lucho wrote called > amount. It would complicate build a bit because you need libraries from > p9p, but perhaps it could be conditional compilation. 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 on p9p doesn't help convince me either - the current arrangement seems to provide a decent seperation of responsibility. The mount.9p symlink sounds pretty reasonable though, I'll get around to that sometime. [1] actually back when I read over amount I even concluded that it used the same trick as srv -a just with a pipe instead of unix socket! failed to notice the Tversion/Tattach subtlety. is it really worth the coupling to go back to that approach? -sqweek ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 19:05 ` sqweek @ 2009-07-14 20:11 ` Eric Van Hensbergen 0 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 20:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 2:05 PM, sqweek<sqweek@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 on p9p doesn't help convince me either - the > current arrangement seems to provide a decent seperation of > responsibility. > The mount.9p symlink sounds pretty reasonable though, I'll get around > to that sometime. > > [1] actually back when I read over amount I even concluded that it > used the same trick as srv -a just with a pipe instead of unix socket! > failed to notice the Tversion/Tattach subtlety. is it really worth the > coupling to go back to that approach? > Its not exactly the same. amount didn't use a pipe, it started the connection with an fd, did the auth and then passes the fd to the kernel to use. The use of the pipe adds extra copies on all data after authentication. This is the overhead involved with the srv approach that I mentioned. IMHO it is worth it for the performance. There's also the security implications of the srv approach, but I was never really much concerned with that angle. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 8:24 ` sqweek 2009-07-13 8:51 ` hiro 2009-07-13 14:20 ` Eric Van Hensbergen @ 2009-07-13 14:59 ` lucio 2009-07-13 15:04 ` Eric Van Hensbergen 2009-07-13 15:08 ` Latchesar Ionkov 3 siblings, 1 reply; 65+ messages in thread From: lucio @ 2009-07-13 14:59 UTC (permalink / raw) To: 9fans > 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, but I can see that I have a merry documentation chase ahead of me :-) ++L ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 14:59 ` lucio @ 2009-07-13 15:04 ` Eric Van Hensbergen 0 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-13 15:04 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs 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, <lucio@proxima.alt.za> 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. > > 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, but I can see that I have a merry documentation chase ahead > of me :-) > > ++L > > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 8:24 ` sqweek ` (2 preceding siblings ...) 2009-07-13 14:59 ` lucio @ 2009-07-13 15:08 ` Latchesar Ionkov 2009-07-13 19:51 ` Tim Newsham 2009-07-14 7:34 ` sqweek 3 siblings, 2 replies; 65+ messages in thread From: Latchesar Ionkov @ 2009-07-13 15:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@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 accidentally with some of the changes, probably when access=user|any|<uid> was introduced. I.e. my fault. 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. Thanks, Lucho ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 15:08 ` Latchesar Ionkov @ 2009-07-13 19:51 ` Tim Newsham 2009-07-14 7:34 ` sqweek 1 sibling, 0 replies; 65+ messages in thread From: Tim Newsham @ 2009-07-13 19:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 see. I can think of several different ways to go about this: - nfs style: if you authenticate to the remote as root, you can speak for any of the uids you want to. This assumes a common mapping of users to uids across the machines. twist: root squash as an option, as per nfs. - single user: All files are presented as if owned by a single user. This need not be the user that was authenticated on the remote side. Any local user id would work. Perm checks are going to be done twice, anyway. Once locally (based on perms + the user id assigned to all files) and once remotely (on file server) based on the remote's idea of what user id you are (who you authenticated as). - multi-user authentication: A separate authenticated 9p channel is opened for each user that makes a request over the remote mount. This requires that some daemon have access to credentials to authenticate each user at least once. This daemon could be set up in advance or it could interactively request auth info as it goes. I think one obvious approach is to prime it with creds for a bunch of accounts and have it fall back to the "single user" case for all other accounts -- by mapping to some distinguished user such as "nobody" or "guest" or "unauth9p". by the way, I think auth method offers some room for thought here, too. When talking with plan9 or inferno then p9sk1 or the inferno auth (whose name I forget) is the obvious choice. However, when talking just between several non-plan9 machines (ie. linux-linux) then other auth choices might make sense. How many 9p servers actually use auth? Most "file servers" are only accessed remotely through "cpu" or locally without auth, right? > Lucho Tim Newsham http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-13 15:08 ` Latchesar Ionkov 2009-07-13 19:51 ` Tim Newsham @ 2009-07-14 7:34 ` sqweek 2009-07-14 11:08 ` roger peppe ` (3 more replies) 1 sibling, 4 replies; 65+ messages in thread From: sqweek @ 2009-07-14 7:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/7/13 Latchesar Ionkov <lucho@ionkov.net>: > On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@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 accidentally with some of the changes, probably when > access=user|any|<uid> was introduced. I.e. my fault. I didn't realise v9fs ever had auth support. Here is how I've been getting an authenticated mount for years: # create mountpoint $ n=$HOME/n $ mkdir -p $n/wren # need factotum running to do the dirty work $ factotum # srv -a posts a pre-authenticated socket in the p9p ns directory # wren is my fileserver $ srv -a wren !adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org user[sqweek]: password: $ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren (or) $ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id -u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren # I'm not sure if uname is strictly necessary $ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail # various other binds Jorden mentioned it's a bad idea to let anyone mount anything because everyone shares the same namespace. 9mount does have some sanity checks for that environment, it will only let you mount over a directory you have write access to (and isn't sticky) or is under your home dir. Never really been field tested though :) > 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. 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 7:34 ` sqweek @ 2009-07-14 11:08 ` roger peppe 2009-07-14 11:20 ` hiro ` (3 more replies) 2009-07-14 13:10 ` Eric Van Hensbergen ` (2 subsequent siblings) 3 siblings, 4 replies; 65+ messages in thread From: roger peppe @ 2009-07-14 11:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 command do the actual dial, authentication, etc? wouldn't that be simpler and just as versatile? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 11:08 ` roger peppe @ 2009-07-14 11:20 ` hiro 2009-07-14 12:48 ` Eric Van Hensbergen ` (2 subsequent siblings) 3 siblings, 0 replies; 65+ messages in thread From: hiro @ 2009-07-14 11:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 1:08 PM, roger peppe<rogpeppe@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 file descriptor > (like the plan 9 syscall) and have an auxiliary > command do the actual dial, authentication, etc? > > wouldn't that be simpler and just as versatile? > > I perfectly agree. And I used to think this was how FUSE is working, but this has been only an uneducated guess. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 11:08 ` roger peppe 2009-07-14 11:20 ` hiro @ 2009-07-14 12:48 ` Eric Van Hensbergen 2009-07-14 15:45 ` ron minnich 2009-07-14 16:31 ` Tim Newsham 3 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 12:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Jul 14, 2009, at 6:08 AM, roger peppe <rogpeppe@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 file descriptor > (like the plan 9 syscall) and have an auxiliary > command do the actual dial, authentication, etc? > This has always been an option. The tcp transport is there (and is default) because it is closest to the expected behavior for the naive Linux user. It is also there because at one time we used 9p as root (ala nfsroot direct option in the kernel). It's worth noting there are performance/efficency implications for using the fd transport (particularly for the non-socket fd case like sshsrv) as well as the unix named pipes transport -- but I don't have quantitative analysis of the differences as it's hard to get an apples to apples comparison. Anthony ligouri has shown some really promising numbers for a hybrid transport based on the Linux splice command. > wouldn't that be simpler The code in question is mostly common, maybe 20 lines of code for each tcp and unix, so I think it's worth having them as options so that user space mount tools arent required. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 11:08 ` roger peppe 2009-07-14 11:20 ` hiro 2009-07-14 12:48 ` Eric Van Hensbergen @ 2009-07-14 15:45 ` ron minnich 2009-07-14 16:31 ` Tim Newsham 3 siblings, 0 replies; 65+ messages in thread From: ron minnich @ 2009-07-14 15:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 4:08 AM, roger peppe<rogpeppe@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, authentication, etc? The fd stuff has been in there in one form or another for 10 years. Just FYI. ron ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 11:08 ` roger peppe ` (2 preceding siblings ...) 2009-07-14 15:45 ` ron minnich @ 2009-07-14 16:31 ` Tim Newsham 2009-07-14 20:21 ` roger peppe 3 siblings, 1 reply; 65+ messages in thread From: Tim Newsham @ 2009-07-14 16:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 > command do the actual dial, authentication, etc? > > wouldn't that be simpler and just as versatile? The v9fs driver lets you mount from a file descriptor. Is this what you're asking for? Tim Newsham http://www.thenewsh.com/~newsham/ ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 16:31 ` Tim Newsham @ 2009-07-14 20:21 ` roger peppe 0 siblings, 0 replies; 65+ messages in thread From: roger peppe @ 2009-07-14 20:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/7/14 Tim Newsham <newsham@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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 7:34 ` sqweek 2009-07-14 11:08 ` roger peppe @ 2009-07-14 13:10 ` Eric Van Hensbergen 2009-07-14 13:23 ` erik quanstrom 2009-07-14 14:33 ` Latchesar Ionkov 2009-07-14 14:37 ` Latchesar Ionkov 3 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 13:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Jul 14, 2009, at 2:34 AM, sqweek <sqweek@gmail.com> wrote: > 2009/7/13 Latchesar Ionkov <lucho@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 correct way. :( Any >> suggestions are welcome. > > Can't help you there - I'm not sure it makes sense to try and put > factotum's functionality in the linux kernel... Probably don't need factotum in kernel, Linux has a keyring facility that can be used to query userspace agents (like factotum). We'd just need the right hooks in v9fs and potentially a glue application to match the kernel keyring API. > Is there some problem > with the private namespace/individual user mount approach? > 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 additional overhead. -Eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 13:10 ` Eric Van Hensbergen @ 2009-07-14 13:23 ` erik quanstrom 2009-07-14 14:26 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: erik quanstrom @ 2009-07-14 13:23 UTC (permalink / raw) To: 9fans > 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 additional overhead. unless this is unmanagable slowness, wouldn't worring about performance at this stage only stand in the way of getting something working? - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 13:23 ` erik quanstrom @ 2009-07-14 14:26 ` Eric Van Hensbergen 2009-07-14 14:44 ` erik quanstrom 0 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 14:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 8:23 AM, erik quanstrom<quanstro@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 mentioned elsewhere in this thread, but then you incur >> some additional overhead. > > unless this is unmanagable slowness, wouldn't worring about > performance at this stage only stand in the way of getting > something working? > Is something not working? My understanding of the situation is that many folks have a workable solution with p9p. The issues are ones of security, convenience and potentially performance. I'm not really a security expert, so I'll refrain from commenting on the first issue outside of the fact that there are concerns with the use of setuid applications, public mount points, and user-space managed connections to file systems (the latter only being a concern if the file system in question is the root partition). Outside of security, the option of tighter auth integration (via the keyring mechanism and fixing 9p.auth in v9fs) with the kernel module is primarily a convenience issue with a side-dish of performance. All that being said, I have no issues with the private mount approach, and have advocated it both via a paper (http://citeseer.ist.psu.edu/746023.html) and in the LKML mailing list discussions on removing privilege restrictions from the Linux mount system call. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 14:26 ` Eric Van Hensbergen @ 2009-07-14 14:44 ` erik quanstrom 0 siblings, 0 replies; 65+ messages in thread From: erik quanstrom @ 2009-07-14 14:44 UTC (permalink / raw) To: ericvh, 9fans > Is something not working? authentication? or doesn't that count? - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 7:34 ` sqweek 2009-07-14 11:08 ` roger peppe 2009-07-14 13:10 ` Eric Van Hensbergen @ 2009-07-14 14:33 ` Latchesar Ionkov 2009-07-14 14:54 ` Eric Van Hensbergen 2009-07-14 14:37 ` Latchesar Ionkov 3 siblings, 1 reply; 65+ messages in thread From: Latchesar Ionkov @ 2009-07-14 14:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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, sqweek<sqweek@gmail.com> wrote: > 2009/7/13 Latchesar Ionkov <lucho@ionkov.net>: >> On Mon, Jul 13, 2009 at 2:24 AM, sqweek<sqweek@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 accidentally with some of the changes, probably when >> access=user|any|<uid> was introduced. I.e. my fault. > > I didn't realise v9fs ever had auth support. Here is how I've been > getting an authenticated mount for years: > > # create mountpoint > $ n=$HOME/n > $ mkdir -p $n/wren > > # need factotum running to do the dirty work > $ factotum > > # srv -a posts a pre-authenticated socket in the p9p ns directory > # wren is my fileserver > $ srv -a wren > !adding key: role=client proto=p9sk1 dom=sqweek.dnsdojo.org > user[sqweek]: > password: > > $ 9mount -i 'unix!/tmp/ns.sqweek.:0/wren' $n/wren > (or) > $ mount -t 9p -o uname=sqweek,trans=unix,noextend,dfltuid=$(id > -u),dfltgid=$(id -g) /tmp/ns.sqweek.:0/wren $n/wren > # I'm not sure if uname is strictly necessary > > $ 9bind $n/wren/home/sqweek/mail $HOME/sqweek/mail > # various other binds > > Jorden mentioned it's a bad idea to let anyone mount anything because > everyone shares the same namespace. 9mount does have some sanity > checks for that environment, it will only let you mount over a > directory you have write access to (and isn't sticky) or is under your > home dir. Never really been field tested though :) > >> 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. > > 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 > > ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 14:33 ` Latchesar Ionkov @ 2009-07-14 14:54 ` Eric Van Hensbergen 2009-07-14 15:01 ` erik quanstrom 2009-07-14 15:06 ` Latchesar Ionkov 0 siblings, 2 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 14:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 9:33 AM, Latchesar Ionkov<lucho@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 (unauthenticated) version of the mount via 9p. 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? -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 14:54 ` Eric Van Hensbergen @ 2009-07-14 15:01 ` erik quanstrom 2009-07-14 15:13 ` Eric Van Hensbergen 2009-07-14 15:06 ` Latchesar Ionkov 1 sibling, 1 reply; 65+ messages in thread From: erik quanstrom @ 2009-07-14 15:01 UTC (permalink / raw) To: 9fans > 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? - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:01 ` erik quanstrom @ 2009-07-14 15:13 ` Eric Van Hensbergen 2009-07-14 15:19 ` erik quanstrom 0 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 15:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 10:01 AM, erik quanstrom<quanstro@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. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:13 ` Eric Van Hensbergen @ 2009-07-14 15:19 ` erik quanstrom 2009-07-14 15:37 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: erik quanstrom @ 2009-07-14 15:19 UTC (permalink / raw) To: 9fans > > 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 it's possible to do the same thing from a linux host. - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:19 ` erik quanstrom @ 2009-07-14 15:37 ` Eric Van Hensbergen 2009-07-14 16:12 ` erik quanstrom 0 siblings, 1 reply; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 15:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 10:19 AM, erik quanstrom<quanstro@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 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 like that. I think for a while we were using aname in one of the early 9P servers to allow the mounting of a sub-hierarchy, but that's been gone for a while I think and still wouldn't do the exact same thing you are describing. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:37 ` Eric Van Hensbergen @ 2009-07-14 16:12 ` erik quanstrom 2009-07-14 16:19 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: erik quanstrom @ 2009-07-14 16:12 UTC (permalink / raw) To: 9fans > > 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 like that. I i would, if it existed. the current workarounds we have are quite horrendous. - erik ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 16:12 ` erik quanstrom @ 2009-07-14 16:19 ` Eric Van Hensbergen 0 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 16:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 11:12 AM, erik quanstrom<quanstro@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 linux host. >> > >> >> Yeah, I don't think anyone is currently doing anything like that. I > > i would, if it existed. the current workarounds we > have are quite horrendous. > patches gladly accepted :) This is likely more of a wrapper application and server issue as you point out of course rather than something which is implemented in the kernel. -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 14:54 ` Eric Van Hensbergen 2009-07-14 15:01 ` erik quanstrom @ 2009-07-14 15:06 ` Latchesar Ionkov 2009-07-14 15:48 ` ron minnich 1 sibling, 1 reply; 65+ messages in thread From: Latchesar Ionkov @ 2009-07-14 15:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 Hensbergen<ericvh@gmail.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? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:06 ` Latchesar Ionkov @ 2009-07-14 15:48 ` ron minnich 2009-07-14 15:59 ` Eric Van Hensbergen 0 siblings, 1 reply; 65+ messages in thread From: ron minnich @ 2009-07-14 15:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov<lucho@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 me, I would love to see it back. Was there a problem with it? ron ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 15:48 ` ron minnich @ 2009-07-14 15:59 ` Eric Van Hensbergen 0 siblings, 0 replies; 65+ messages in thread From: Eric Van Hensbergen @ 2009-07-14 15:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 10:48 AM, ron minnich<rminnich@gmail.com> wrote: > On Tue, Jul 14, 2009 at 8:06 AM, Latchesar Ionkov<lucho@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 me, I would love to see it back. Was there a > problem with it? > I don't think there was a problem, I think it just got accidentally squashed. patches gladly accepted :) -eric ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [9fans] v9fs question 2009-07-14 7:34 ` sqweek ` (2 preceding siblings ...) 2009-07-14 14:33 ` Latchesar Ionkov @ 2009-07-14 14:37 ` Latchesar Ionkov 3 siblings, 0 replies; 65+ messages in thread From: Latchesar Ionkov @ 2009-07-14 14:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jul 14, 2009 at 1:34 AM, sqweek<sqweek@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 authentication in the kernel, but somehow to allow user space programs to create and manipulate authentication fids. One option would be to expose the afids in /proc or /sys, but then it is hard to figure out what mount they belong to. Another option is for every mount, v9fs serves mntpt/.afids directory at the top of the mountpoint. Or, as Ron suggested, just forget about multiple users and make it work for a single one. Thanks, Lucho ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2009-07-14 20:21 UTC | newest] Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-11 18:46 [9fans] v9fs question Tim Newsham 2009-07-11 18:50 ` Eric Van Hensbergen 2009-07-11 19:03 ` Tim Newsham 2009-07-11 19:47 ` Eric Van Hensbergen 2009-07-11 20:03 ` J.R. Mauro 2009-07-12 3:19 ` Uriel 2009-07-13 8:24 ` sqweek 2009-07-13 8:51 ` hiro 2009-07-13 14:20 ` Eric Van Hensbergen 2009-07-13 20:44 ` hiro 2009-07-13 21:45 ` hiro 2009-07-13 22:05 ` Eric Van Hensbergen 2009-07-13 22:18 ` J.R. Mauro 2009-07-13 23:16 ` ron minnich 2009-07-13 23:22 ` Eric Van Hensbergen 2009-07-13 23:37 ` ron minnich 2009-07-13 23:47 ` Eric Van Hensbergen 2009-07-13 23:41 ` J.R. Mauro 2009-07-13 23:50 ` erik quanstrom 2009-07-14 0:00 ` J.R. Mauro 2009-07-14 0:06 ` erik quanstrom 2009-07-14 0:01 ` Eric Van Hensbergen 2009-07-14 0:08 ` ron minnich 2009-07-14 0:46 ` J.R. Mauro 2009-07-14 0:42 ` J.R. Mauro 2009-07-14 0:58 ` Eric Van Hensbergen 2009-07-14 1:28 ` Latchesar Ionkov 2009-07-14 1:35 ` Devon H. O'Dell 2009-07-14 2:05 ` Tim Newsham 2009-07-14 0:42 ` Tim Newsham 2009-07-14 0:50 ` erik quanstrom 2009-07-14 0:56 ` Eric Van Hensbergen 2009-07-14 4:51 ` lucio 2009-07-14 4:29 ` lucio 2009-07-14 4:26 ` lucio 2009-07-13 22:00 ` Eric Van Hensbergen 2009-07-14 19:05 ` sqweek 2009-07-14 20:11 ` Eric Van Hensbergen 2009-07-13 14:59 ` lucio 2009-07-13 15:04 ` Eric Van Hensbergen 2009-07-13 15:08 ` Latchesar Ionkov 2009-07-13 19:51 ` Tim Newsham 2009-07-14 7:34 ` sqweek 2009-07-14 11:08 ` roger peppe 2009-07-14 11:20 ` hiro 2009-07-14 12:48 ` Eric Van Hensbergen 2009-07-14 15:45 ` ron minnich 2009-07-14 16:31 ` Tim Newsham 2009-07-14 20:21 ` roger peppe 2009-07-14 13:10 ` Eric Van Hensbergen 2009-07-14 13:23 ` erik quanstrom 2009-07-14 14:26 ` Eric Van Hensbergen 2009-07-14 14:44 ` erik quanstrom 2009-07-14 14:33 ` Latchesar Ionkov 2009-07-14 14:54 ` Eric Van Hensbergen 2009-07-14 15:01 ` erik quanstrom 2009-07-14 15:13 ` Eric Van Hensbergen 2009-07-14 15:19 ` erik quanstrom 2009-07-14 15:37 ` Eric Van Hensbergen 2009-07-14 16:12 ` erik quanstrom 2009-07-14 16:19 ` Eric Van Hensbergen 2009-07-14 15:06 ` Latchesar Ionkov 2009-07-14 15:48 ` ron minnich 2009-07-14 15:59 ` Eric Van Hensbergen 2009-07-14 14:37 ` Latchesar Ionkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).