[9fans] U9FS

[9fans] U9FS

[Lucio De Re]

There have been a few minor changes to u9fs posted here, do I have
to search for them, or have they been published on sources?

Can someone please point me to the most up to date source?

++L

Re: [9fans] u9fs

[arisawa]

I wrote:
>
> When I access to my Mac/OSX PowerBook from Plan 9 terminal (in
> hosted VirtualPC),
> ls command of Plan 9 terminal does not respond in a special directory:
> 	a mounted directory of remote file server.
>

but "(in hosted VirtualPC)" is not essential.

Kenji Arisawa

[9fans] u9fs

[arisawa]

Hello,

I am annoyed by a curious phenomenon.
When I access to my Mac/OSX PowerBook from Plan 9 terminal (in hosted
VirtualPC),
ls command of Plan 9 terminal does not respond in a special directory:
	a mounted directory of remote file server.

Of cause my PowerBook responds the directory: /Volumes/kenji
	-bash$ ls -l /Volumes
	total 8
	lrwxr-xr-x    1 root     admin      1 Mar 27 11:35 Macintosh HD -> /
	drwxrwxrwx   26 arisawa  arisawa  840 Mar 30 14:30 kenji
	-bash$ ls -l /Volumes/kenji
	total 16
	drwxrwxrwx    2 arisawa  arisawa   264 Feb 26 16:56 Network Trash
Folder
	drwxrwxrwx   47 arisawa  arisawa  1554 Mar  5 17:28 Private
	...
	drwxrwxrwx    4 arisawa  arisawa   264 Feb 26 20:22 travel
	-bash$

I found u9fs falls into infinite loop in the directory.

I added
	fprint(2,"rread...\n");
and
	fprint(2,"dirread:%s\n", fid->dirent->d_name);

in u9fs.c


void
rread(Fcall *rx, Fcall *tx)
{
	char *e, *path;
	uchar *p, *ep;
	int n;
	Fid *fid;
	Dir d;
	struct stat st;

	fprint(2,"rread...\n");

	...

			if(strcmp(fid->dirent->d_name, ".") == 0
			|| strcmp(fid->dirent->d_name, "..") == 0){
				fid->dirent = nil;
				continue;
			}
			fprint(2,"dirread:%s\n", fid->dirent->d_name);
			path = estrpath(fid->path, fid->dirent->d_name, 0);
			memset(&st, 0, sizeof st);
			...
}

Then u9fs.log shows:

rread...
dirread:Network Trash Folder
dirread:Temporary Items
dirread:photo
dirread:doc
dirread:study
dirread:arch
dirread:edu
dirread:src
dirread:tmp
dirread:.DS_Store
dirread:dlb
dirread:travel
dirread:spam
dirread:english
dirread:news
dirread:adm
dirread:db
dirread:.TemporaryItems
dirread:Private
dirread:lib
dirread:plan9
dirread:todo.txt
dirread:log
dirread:trashbox
rread...
dirread:Network Trash Folder
dirread:Temporary Items
dirread:photo
dirread:doc
dirread:study
dirread:arch
dirread:edu
dirread:src
dirread:tmp
dirread:.DS_Store
dirread:dlb
dirread:travel
dirread:spam
dirread:english
dirread:news
dirread:adm
dirread:db
dirread:.TemporaryItems
dirread:Private
dirread:lib
dirread:plan9
dirread:todo.txt
dirread:log
dirread:trashbox
rread...

I don't know why this loop happens, and I don't know how to prevent
the loop.
Suggestion welcome.

Kenji Arisawa

Re: [9fans] u9fs

[Russ Cox]

> We actually make different use of the attach spec here. It lets you
> restrict the domain of the server by basically making a fid for the attach
> lower in the tree than '/'.

Right.  If you want NFS, ...  ;-)

Re: [9fans] u9fs

[Ronald G. Minnich]

On Tue, 18 Feb 2003, Russ Cox wrote:

> The only use of the attach spec in u9fs is that if you attach
> to the name "device" then you can access devices
> on the system.  Otherwise you're not allowed, so as
> to avoid blocking the (single-threaded) server.

ah, that is interesting. This is what happens when you re-do an
implementation from the man pages.

We actually make different use of the attach spec here. It lets you
restrict the domain of the server by basically making a fid for the attach
lower in the tree than '/'.

I guess I'll get the same effect by chroot'ing the server.

It's interesting seeing how much I did the same as Plan 9 from the man
pages, and how many little differences like this have crept in. I've been
using that attach spec for years (and truth to tell, I still like it, but
I'm going to stick with stock u9fs).

I ran into this just now for this reason: I am running v9fs2k (linux vfs
client for 9p2000) on the same laptop as u9fs. I am getting readdir
working.  The mount point for v9fs2k is /mnt. Things got messy when the
server walked over /mnt ... as in deadlock. I never had this type of thing
with my old 9p server that I wrote, since the attaches were always below
root.

Anyway, an easy workaround.

thanks

ron

Re: [9fans] u9fs

[nigel]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

The attach name specifies the filesystem to attach to, not a remote path.

E.g. Plan 9 fileservers typically have "main" and "dump".

[-- Attachment #2: Type: message/rfc822, Size: 2141 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] u9fs
Date: Tue, 18 Feb 2003 09:38:19 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302180936430.15301-100000@carotid.ccs.lanl.gov>


has anyone used u9fs to attach to anything but root (i.e. /).

Reason I am asking: from my 9p2000 client I attach to local name /mnt,
remote name /tmp. However, when I do walks or other ops, u9fs is always
starting the walks etc. at /, not /tmp.

This is a stock u9fs, so I am wondering if I am doing something nobody has
tried.

ron

Re: [9fans] u9fs

[Russ Cox]

That's not how attaches typically work in Plan 9.

The only use of the attach spec in u9fs is that if you attach
to the name "device" then you can access devices
on the system.  Otherwise you're not allowed, so as
to avoid blocking the (single-threaded) server.

Russ

[9fans] u9fs

[Ronald G. Minnich]

has anyone used u9fs to attach to anything but root (i.e. /).

Reason I am asking: from my 9p2000 client I attach to local name /mnt,
remote name /tmp. However, when I do walks or other ops, u9fs is always
starting the walks etc. at /, not /tmp.

This is a stock u9fs, so I am wondering if I am doing something nobody has
tried.

ron

Re: [9fans] u9fs

[Axel Belinfante]

> If I wanted to use a different key I could use, for example,
> 
> 	mount -k 'user=glenda' /srv/sources /n/sources
> 	cpu -k 'user=glenda' -h sources
Thanks, I was not aware of this -k feature.

> really little point.  If you're using .rhosts authentication,
> then there's nothing stopping me from making my own
> connection to the u9fs service (with aux/9pcon or more
> usefully with a 9P filter in front of the kernel) and sending
> whatever attach name I want.  There's no authentication
> here, and I don't want to start pretending there is.

I know, but this rhost auth case is not an issue,
for me, here, because I don't intend to use it any longer.
This all started because I wanted to move
from rhost auth to now available p9any auth.
So, the .u9fs was meant as 'sort of' equivalent
(wrt opt-in/opt-out) to .rhosts in the case of
p9any/p9sk1 authentication, for the -luser attach hack.
With p9any auth, the plan 9 user can not just be anyone,
but is authenticated, right?

> It is worth noting, though, that if your Plan 9 system is not listed
> in /etc/rhosts.equiv, then users can opt in or out by editing
> their .rhosts files already.  So you really don't need a .u9fs file.

Been there, used that - that is what I depended on so far.

However, I wanted to:
 - get rid of rhosts authentication
   (the u9fs source advices against it, I don't feel safe;
	main thing I dislike about it is that a user using
	it to opt-in for u9fs autonagically also opts-in
	for rsh etc., which is more than wanted/needed)
 - instead, use newly available p9any/p9sk1 authentication
   (by which I loose the opt-in/out feature of rhost
	with plan 9 system not in host.equiv)
 - have flexibility by -luser attach name
   (now I need opt-in/out for the users)

That's why I came up with .u9fs -- 
opt-in/out at the unix side to complement
p9any authentication, giving me something
functionally similar to rhosts with empty hosts.equiv,
but using Plan 9 authentication, resulting in something
stronger than rhosts auth, I hope, something no longer
also allowing rsh,rlogin, at least mot from the plan 9
systen.

Axel.

Re: [9fans] u9fs

[Russ Cox]

> ... because you have only one account at the machine,
> or, at least, only one that is `interesting enough'
> to have a key for in factotum.

Not exactly true.  Factotum uses the first one it finds.

If I wanted to use a different key I could use, for example,

	mount -k 'user=glenda' /srv/sources /n/sources
	cpu -k 'user=glenda' -h sources

to select a key.  Of course, the fact that I'm selecting
on the user attribute is not why this works.  I could select
on any attribute in the key, and then that key (with its
user name) will be used.

This works really well when there are keys.  When there
are not keys, it's harder because there are no Tauth messages
in which to pass remote user names.  We could invent
a `unix' protocol consisting of sending a uid, but there's
no authentication in that. 

The ssh user@host syntax is annoying but standard
in the SSH world.  It is also somewhat necessary given
how SSH chooses to run its authentication:
you declare user up front, and then try a whole bunch
of authentication methods.  You can't change your 
user name after one fails.

As for ~/.u9fs or uid mappings on the server, there's
really little point.  If you're using .rhosts authentication,
then there's nothing stopping me from making my own
connection to the u9fs service (with aux/9pcon or more
usefully with a 9P filter in front of the kernel) and sending
whatever attach name I want.  There's no authentication
here, and I don't want to start pretending there is.
It is worth noting, though, that if your Plan 9 system is not listed
in /etc/rhosts.equiv, then users can opt in or out by editing
their .rhosts files already.  So you really don't need a .u9fs file.

Russ

Re: [9fans] u9fs

[Axel Belinfante]

> The new u9fs doesn't have
> a -r flag because we don't use it,
> so I didn't implement it.  Same for
> chroot and some other things that
> have made their way back.

That's the reason I expected. Good.
 
> While I'd be happy to pick up a -r flag, I'm
> hesitant about having a per-directory .u9fs file.

(one per-user (in the user's unix home directory))

>  That seems too specific to your particular case.

Probably it is. One the one hand I like the idea
of giving the unix user a choice; on the other hand,
it's a bit (too?) much.

> I'm torn about the uid mappings.  I feel like
> there should be a more general solution.

That would be great.

> With real authentication, factotum just does
> the right thing.  (For example, I have an account
> called bozo on sources.  I run 9fs sources and it
> automatically uses that name because it's the only
> key I have for the machine.)

... because you have only one account at the machine,
or, at least, only one that is `interesting enough'
to have a key for in factotum.

The nice behaviour in your example immediately
illustrates the disadvantage of my overloading-of-
attach-name hack: you not only can, but also have
to specify the unix user name. If you want to
(be able to) choose, you need (a way) to `voice'
your choice. So, the problem seems to start with
the possibility of having a one-to-many mapping,
because then a choice has to be made, and voiced.

But isn't this problem similar to the problem of
having multiple remote accounts on a single machine,
and then having to choose/identify one of them,
when making a connection to that host (e.g.) via ssh?

In this respect, the idea of the (one-to-one) mapping
file (which, I think, was suggested by Forsyth in an
earlier discussion about u9fs) is better, because it
just specifies a fixed one-to-one (or maybe many-to-one
but not one-to-many) plan9->unix name mapping that is
just slightly different from the also fixed one-to-one
(identity function) plan9->unix name mapping in the
unmodified u9fs. You just have one name at the unix
system (either identical to your plan 9 name, or
different  from it, but then automated via the
mapping file so it is out of your hands anyway),
which allows the same automation as in your example.

W.r.t. ~/.u9fs files:
If you don't have the general flexible -lunixuser
attach name hack (and you trust the maintainer of
the mapping file if it's there), and you trust your
plan 9 administrator not to add plan 9 users just
to get at unix files, there probably is no need for
the ~/.u9fs files.

> When there's no authentication, it's a little harder.
> I'm having the same problem with an NFS client I'm
> writing.  I'm not sure what to do.

Axel. (who wonders when he will learn to write concisely)

RE: [9fans] u9fs

[Russ Cox]

> I would expect that if you make Twrite, Twstat, Tremove, and Tcreate
> fail, that would do just fine.
> Make sure that Twrites to auth fids are still allowed.

Also Topen ORCLOSE, OTRUNC.

The new u9fs doesn't have
a -r flag because we don't use it,
so I didn't implement it.  Same for
chroot and some other things that
have made their way back.

While I'd be happy to pick up a -r flag, I'm
hesitant about having a per-directory .u9fs
file.  That seems too specific to your particular case.

I'm torn about the uid mappings.  I feel like
there should be a more general solution.
With real authentication, factotum just does
the right thing.  (For example, I have an account
called bozo on sources.  I run 9fs sources and it
automatically uses that name because it's the only
key I have for the machine.)  When there's no authentication,
it's a little harder.  I'm having the same problem
with an NFS client I'm writing.  I'm not sure
what to do.

Russ

RE: [9fans] u9fs

[Nigel Roles]

> I have been toying with the idea of allowing even greater control at
the unix side, by allowing a ``readonly''
> keyword with a user name in the .u9fs file. Suppose I would like to
put readonly access back in, would it be
> sufficient to look at 3ed u9fs and ``copy'' from there? Or are there
cases that I would miss?

I would expect that if you make Twrite, Twstat, Tremove, and Tcreate
fail, that would do just fine.
Make sure that Twrites to auth fids are still allowed.

Re: [9fans] u9fs

[Axel Belinfante]

> There are changes to u9fs on sources that add support
> for p9any as an authentication protocol.  Thanks to Nigel.


Great! Thanks!



I reintegrated my u9fs modifications mentioned on the list
before (for previous u9fs versions); I (think I) need them
because my plan 9 user list differs from the unix user list,
and these lists are managed by different people.
They consist of a plan9-user to unix-user username mapping
via a mapping file, and a hack to recognize '-lunixuser' in
the attach name as a way to specify the unix-user name.
I think(*) I like this flexibility, as I only use one
plan 9 account but several unix ones.

(*) it is all a bit experimental -- finding out what I want/need;
 right now I even don't rule out the potential conclusion that
 what I'm doing is too much, such that it can be removed again.

My modifications worked nicely in combination with .rhosts
authentication, because then a unix user had to explictly allow
attach from plan 9 as his/her via an entry in .rhosts.

With p9any this `limitation' is no longer there, allowing
in principle to attach as any unix user (except root).
To counter this, I added yet another modification,
which kind of imitates the .rhosts file.
With this modification, attach from plan9 only succeeds
if the plan 9 user name is present in a .u9fs file in
the home dir of the unix user as whom we try to attach.
In particular, this means that to attach as unix user
``A'' it is no longer sufficient to just add a new
user ``A'' on plan 9; user ``A'' on unix must explictly
allow the attach via his .u9fs file.

The code I have just works and still needs cleaning up
(is still full of detailed debugging print statements);
if there is interest I can post or put on the web.



On a related note: I noticed that in the transition
from 3ed to 4ed u9fs lost its -r (readonly) flag;
are there particular reasons for that?

I have been toying with the idea of allowing even greater
control at the unix side, by allowing a ``readonly''
keyword with a user name in the .u9fs file.
Suppose I would like to put readonly access back in,
would it be sufficient to look at 3ed u9fs and ``copy''
from there? Or are there cases that I would miss?

Axel.

[9fans] u9fs

[Russ Cox]

There are changes to u9fs on sources that add support
for p9any as an authentication protocol.  Thanks to Nigel.

Russ

Re: [9fans] u9fs

[Russ Cox]

> What is srvssh?  How does it differ from `execnet and ssh'?
> I wasn't able to find srvssh on /n/sources.

Srvssh serves the same purpose as execnet and ssh.
Instead of using execnet, it uses the new -e flag to srv.
It also hides a lot of the grime involved.  You don't have
to set up the script on the other side.

It's a shell script -- /rc/bin/srvssh.

Russ

Re: [9fans] u9fs

[YAMANASHI Takeshi]

> Thanks for srvssh.

What is srvssh?  How does it differ from `execnet and ssh'?
I wasn't able to find srvssh on /n/sources.

Thank you.
--
YAMANASHI Takeshi

[9fans] u9fs

[David Swasey]

Thanks for srvssh.  Here are the changes I made to get u9fs running on
a SunOS 5.5.1 machine.  -dave

1. A comment:

diff /sys/src/cmd/unix/u9fs/makefile u9fs-new/makefile
5a6,10
> # SunOS
> #
> # SunOS 5.5.1 does not provide inttypes.h; add -Isunos to CFLAGS and change
> # CC and LD to gcc.  Add -lsocket, -lnsl to LDFLAGS.
> #

2. Magic to get timeval defined:

diff /sys/src/cmd/unix/u9fs/plan9.h u9fs-new/plan9.h
5a6,9
> #ifdef sun	/* sparc and __svr4__ are also defined on the offending machine */
> #define __EXTENSIONS__	1	/* for struct timeval */
> #endif
>

3. A version of inttypes.h:

cat u9fs-new/sunos/inttypes.h
/* inttypes.h for SunOS cuff.link.cs.cmu.edu 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-Enterprise */
#ifndef INTTYPES_H
#define INTTYPES_H

typedef char int8_t;
typedef short int16_t;
typedef int int32_t;
typedef long long int64_t;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef long int intptr_t;
typedef unsigned long int uintptr_t;

#endif

[9fans] u9fs

[arisawa]

Sorry I sent incorrect title, `Bug report'.
The correct one is 'u9fs'.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] u9fs

[Christopher Nielsen]

FYI, this worked for me. Thanks!

On Sat, Mar 23, 2002 at 06:12:59PM +0000, Russ Cox wrote:
> where by /etc/hosts, nigel means /etc/hosts.equiv
> (or you can edit your own .rhosts).  if you can rlogin
> to the machine then you can mount it.
> to whoever complains, i will point out
> that this is no worse than nfs.

> From: nigel@9fs.org
> To: 9fans@cse.psu.edu
> Date: Sat, 23 Mar 2002 10:43:09 0000
> Subject: Re: [9fans] u9fs
> 
> You need to be in /etc/hosts of the unix machine, or equivalent
> permissiony sort of thing.
> 

> From: Christopher Nielsen <cnielsen@pobox.com>
> To: 9fans@cse.psu.edu
> Date: Fri, 22 Mar 2002 16:40:52 -0800
> Subject: Re: [9fans] u9fs
> 
> On Thu, Mar 21, 2002 at 11:19:35AM -0500, Russ Cox wrote:
> > If you have u9fs listening on port 564, then
> > you can say
> > 
> > 	srv -m tcp!1.2.3.4 kremvax /n/kremvax
> > 
> > ls -l /n/kremvax
> 
> when i try this from one of my cpu servers, i get an error:
> 
> srv -m tcp!12.99.91.196 cassie /n/cassie
> srv: mount failed: permission denied
> 
> thoughts?

-- 
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] u9fs

[Russ Cox]

> Wouldn't it be "sort of nice" if u9fs(4) mentioned this? :-)

Indeed it would.  It will be so.  :-)

Re: [9fans] u9fs

[Martin C.Atkins]

Ahhhh.

This was my problem too...

On Sat, 23 Mar 2002 10:43:09 0000 nigel@9fs.org wrote:
> You need to be in /etc/hosts of the unix machine, or equivalent
> permissiony sort of thing.

and On Sat, 23 Mar 2002 18:12:59 0000 "Russ Cox" <rsc@plan9.bell-labs.com> wrote:
> where by /etc/hosts, nigel means /etc/hosts.equiv
> (or you can edit your own .rhosts).  if you can rlogin
> to the machine then you can mount it.
> to whoever complains, i will point out
> that this is no worse than nfs.
> 

Wouldn't it be "sort of nice" if u9fs(4) mentioned this? :-)

Martin
-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] u9fs

[nigel]

[-- Attachment #1: Type: text/plain, Size: 32 bytes --]

Yep. I'm bang to rights too.


[-- Attachment #2: Type: message/rfc822, Size: 5461 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 219 bytes --]

where by /etc/hosts, nigel means /etc/hosts.equiv
(or you can edit your own .rhosts).  if you can rlogin
to the machine then you can mount it.
to whoever complains, i will point out
that this is no worse than nfs.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 3677 bytes --]

[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 95 bytes --]

You need to be in /etc/hosts of the unix machine, or equivalent
permissiony sort of thing.


[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 2044 bytes --]

From: Christopher Nielsen <cnielsen@pobox.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Fri, 22 Mar 2002 16:40:52 -0800
Message-ID: <20020323004052.GE78245@cassie.foobarbaz.net>

On Thu, Mar 21, 2002 at 11:19:35AM -0500, Russ Cox wrote:
> If you have u9fs listening on port 564, then
> you can say
> 
> 	srv -m tcp!1.2.3.4 kremvax /n/kremvax
> 
> ls -l /n/kremvax

when i try this from one of my cpu servers, i get an error:

srv -m tcp!12.99.91.196 cassie /n/cassie
srv: mount failed: permission denied

thoughts?

-- 
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] u9fs

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

where by /etc/hosts, nigel means /etc/hosts.equiv
(or you can edit your own .rhosts).  if you can rlogin
to the machine then you can mount it.
to whoever complains, i will point out
that this is no worse than nfs.

[-- Attachment #2: Type: message/rfc822, Size: 3677 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 95 bytes --]

You need to be in /etc/hosts of the unix machine, or equivalent
permissiony sort of thing.


[-- Attachment #2.1.2: Type: message/rfc822, Size: 2044 bytes --]

From: Christopher Nielsen <cnielsen@pobox.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Fri, 22 Mar 2002 16:40:52 -0800
Message-ID: <20020323004052.GE78245@cassie.foobarbaz.net>

On Thu, Mar 21, 2002 at 11:19:35AM -0500, Russ Cox wrote:
> If you have u9fs listening on port 564, then
> you can say
> 
> 	srv -m tcp!1.2.3.4 kremvax /n/kremvax
> 
> ls -l /n/kremvax

when i try this from one of my cpu servers, i get an error:

srv -m tcp!12.99.91.196 cassie /n/cassie
srv: mount failed: permission denied

thoughts?

-- 
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] u9fs

[nigel]

[-- Attachment #1: Type: text/plain, Size: 95 bytes --]

You need to be in /etc/hosts of the unix machine, or equivalent
permissiony sort of thing.


[-- Attachment #2: Type: message/rfc822, Size: 2044 bytes --]

From: Christopher Nielsen <cnielsen@pobox.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Fri, 22 Mar 2002 16:40:52 -0800
Message-ID: <20020323004052.GE78245@cassie.foobarbaz.net>

On Thu, Mar 21, 2002 at 11:19:35AM -0500, Russ Cox wrote:
> If you have u9fs listening on port 564, then
> you can say
> 
> 	srv -m tcp!1.2.3.4 kremvax /n/kremvax
> 
> ls -l /n/kremvax

when i try this from one of my cpu servers, i get an error:

srv -m tcp!12.99.91.196 cassie /n/cassie
srv: mount failed: permission denied

thoughts?

-- 
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] u9fs

[Christopher Nielsen]

On Thu, Mar 21, 2002 at 11:19:35AM -0500, Russ Cox wrote:
> If you have u9fs listening on port 564, then
> you can say
> 
> 	srv -m tcp!1.2.3.4 kremvax /n/kremvax
> 
> ls -l /n/kremvax

when i try this from one of my cpu servers, i get an error:

srv -m tcp!12.99.91.196 cassie /n/cassie
srv: mount failed: permission denied

thoughts?

-- 
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] u9fs

[Jean Mehat]

> is use samba to mount them on a Linux box and then mount the

A student here made, as a project, a smb client (equivalent to samba) under
Plan 9. The result is functional but it lacks a serious review to be 
diffused.

If someone wants to capitalize on this work, the student can be contacted
at versace@mime.up8.edu.

Re: [9fans] u9fs

[Russ Cox]

If you have u9fs listening on port 564, then
you can say

	srv -m tcp!1.2.3.4 kremvax /n/kremvax

ls -l /n/kremvax

Re: [9fans] u9fs

[Peter Canning]

With a little bit of hacking (ifdef-ing out the calls to setgroups and
setreuid), I've managed to get u9fs to compile using cygwin on a W2K
machine.  I haven't had a chance to try it yet however (I'm still trying
to figure out how I access a fileserver from my standalone plan9
installation), so I don't know if it actually works.

	- Peter Canning

In <5d3a323951f664ac2fba702bad875659@plan9.bell-labs.com>, Russ Cox wrote:

> There are no good options for seeing Windows file systems across a
> network in Plan 9.  The only way I can think of is use samba to mount
> them on a Linux box and then mount the Linux box with u9fs.
> 
> Russ

Re: [9fans] u9fs

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

drawterm runs something similar to, but simpler than, the Nt fs interface
code in Inferno, and i suppose in 9pm--they are all
somewhat vaguely related.  drawterm's work overall is somewhat
simpler (which is why it can manage on only pthreads on
Linux and FreeBSD, whereas Inferno has more work to do).


[-- Attachment #2: Type: message/rfc822, Size: 2209 bytes --]

To: 9fans@cse.psu.edu, 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Wed, 20 Mar 2002 11:42:35 -0800
Message-ID: <5.1.0.14.2.20020320113936.01b4c688@mail.real.com>

I've not looked, but how does drawterm expose /mnt/term?
could that part of it be used as an NT service?

At 02:05 PM 3/20/2002 -0500, Russ Cox wrote:
>There are no good options for seeing Windows file systems
>across a network in Plan 9.  The only way I can think of
>is use samba to mount them on a Linux box and then mount the
>Linux box with u9fs.  
>
>Russ

Re: [9fans] u9fs

[skipt]

I've not looked, but how does drawterm expose /mnt/term?
could that part of it be used as an NT service?

At 02:05 PM 3/20/2002 -0500, Russ Cox wrote:
>There are no good options for seeing Windows file systems
>across a network in Plan 9.  The only way I can think of
>is use samba to mount them on a Linux box and then mount the
>Linux box with u9fs.  
>
>Russ

Re: [9fans] u9fs

[Russ Cox]

You could run an NT u9fs of sorts by
starting with the drawterm code, I suppose.
You might be better off starting with u9fs.

Ideally I'd rather see an SMB client.

Russ

Re: [9fans] u9fs

[markp]

| There are no good options for seeing Windows file systems
| across a network in Plan 9.  The only way I can think of
| is use samba to mount them on a Linux box and then mount the
| Linux box with u9fs.  
|
| Russ

hmmm. that may be an acceptable workaround, to have the headless box
mounting samba shares from the laptop for handing off to u9fs, and plan9
having to worry only about mounting filesystems from that box.

incidentally, this is a partition shared by windows and BSD on the
laptop. the idea is that plan9 would have access to the same files
regardless which OS was running on the other laptop at the time.

thanks much for the swift reply,
---mp

Re: [9fans] u9fs

[Russ Cox]

There are no good options for seeing Windows file systems
across a network in Plan 9.  The only way I can think of
is use samba to mount them on a Linux box and then mount the
Linux box with u9fs.  

Russ

Re: [9fans] u9fs

[markp]

| From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>

| "Dharani Vilwanathan" wrote:
| > Can I safely assume that if I run u9fs on a linux box, it is as good as a
| > plan 9 file server with which Plan 9 terminals can be connected?
|
| Although I don't use it for booting terminals,
| students here are using u9fs to use their home dirs
| serviced by a linux box. It's working like a charm.
| just to let you know.

this was a question I was about to ask. my thinkpad 600e should be
arriving in a day or two and I'm starting to think about useful ways
to get at my present machines from plan9. 

one is a laptop dualbooting netbsd and win98 with hosted inferno on both
sides (the linux emu works reasonably well in netbsd's linux emulation),
the other is a headless deskside box running only netbsd. alas, neither
have much hope of being well supported by p9 in the near future.

i also wonder, what are the options for seeing Windows filesystems
across a network in plan9? 

---mp

Re: [9fans] u9fs

[Fco.J.Ballesteros]

"Dharani Vilwanathan" wrote:
> Can I safely assume that if I run u9fs on a linux box, it is as good as a
> plan 9 file server with which Plan 9 terminals can be connected?

Although I don't use it for booting terminals,
students here are using u9fs to use their home dirs
serviced by a linux box. It's working like a charm.
just to let you know.

Re: [9fans] u9fs

[Dean Prichard]

We ported etherga620.c to the fileserver kernel a while back,
if there is interest it's at:

http://www.acl.lanl.gov/plan9/fs-acenic/

On Tue, 19 Mar 2002, Geoff Collyer wrote:

> Date: Tue, 19 Mar 2002 23:10:18 -0800
> From: Geoff Collyer <geoff@collyer.net>
> Reply-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] u9fs
>
> > I agree but support for drivers is a concern.
>
> I've just succeeded in porting a gigabit ethernet driver from the cpu
> kernel to the fs kernel using a bit of scaffolding and a very few
> changes to the original driver.  I believe that this can be extended
> to all the other ethernet drivers and maybe some non-ethernet drivers
> and I intend to take a whack at it.  (Thus my recent interest in
> ether8139.c.)  I also believe that similar scaffolding can ease
> porting of ethernet drivers into 9load, which you really need to make
> a given model of ethernet card useful.
>

Re: [9fans] u9fs

[Lucio De Re]

On Tue, Mar 19, 2002 at 11:10:18PM -0800, Geoff Collyer wrote:
> 
> > I agree but support for drivers is a concern.
> 
> [ ... ]
> ether8139.c.)  I also believe that similar scaffolding can ease
> porting of ethernet drivers into 9load, which you really need to make
> a given model of ethernet card useful.

I agree, mucking about with the PCNet driver led me to similar
conclusions.  I assume that the underlying Plan 9 design greatly
simplifies device driver implementation.

Pity about VGA, admittedly, but I'm sure we're not far from a
simplified VGA driver design.  It's worth waiting until the game
developers hit an unsurmountable performance wall and rediscover the
joys of standardisation.

As for 9load, it may grate to the Bell Labs purist, but sharing
drivers between /sys/src/9 and /sys/src/boot would be a definite win,
even if the odd #ifdef has to be brought into use :-)

++L

Re: [9fans] u9fs

[Geoff Collyer]

> I agree but support for drivers is a concern.

I've just succeeded in porting a gigabit ethernet driver from the cpu
kernel to the fs kernel using a bit of scaffolding and a very few
changes to the original driver.  I believe that this can be extended
to all the other ethernet drivers and maybe some non-ethernet drivers
and I intend to take a whack at it.  (Thus my recent interest in
ether8139.c.)  I also believe that similar scaffolding can ease
porting of ethernet drivers into 9load, which you really need to make
a given model of ethernet card useful.

Re: [9fans] u9fs

[forsyth]

Inferno's equivalent of fcall(2) has different return values
to distinguish an incomplete message, avoiding the need for
aux/fcall (at least in the common instance).   it isn't better
than a count (given the dearth of common Internet protocols
that can punctuate properly) because it needs to know the
structure of every message (thus for instance a filter can't
skip messages it doesn't understand or need to parse).

Re: [9fans] u9fs

[Russ Cox]

The last release (and perhaps ones before that) has
code in the kernel to boot from tcp -- it reinserts
the message boundaries like push fcall used to do.
I think I'm the only one who ever used it, and it was
in fact for booting over TCP to u9fs.  

For 9P2000, the mount driver does the right thing 
rather than depend on message boundaries, so no special
code is needed.

Russ

Re: [9fans] u9fs

[Steve Kotsopoulos]

"Dharani Vilwanathan" wrote:
> Can I safely assume that if I run u9fs on a linux box, it is as good as a
> plan 9 file server with which Plan 9 terminals can be connected?

performance issues aside, I thought you couldn't use u9fs as a boot fileserver
because tcp doesn't preserve the message boundaries (as needed by 9P).

The solution suggested ages ago was to change the kernel to use
something similar to aux/fcall to reconstruct the 9p message boundaries.
Has the kernel been changed to do this now??

	Steve

Re: [9fans] u9fs

[Russ Cox]

yes, you'd have to add some sort of chroot.
i think the typical addition (in u9fs.c:/^main) looks like:

	setreuid(0, 0);
	myuid = geteuid();
	if(onlyuser && myuid != onlyuid)
		error("invalid uid");

>>	if(argc > 0)
>>		if(chroot(argv[0]) == -1)
>>			error("chroot failed");

	io();

russ

Re: [9fans] u9fs

[Dharani Vilwanathan]

> Hi,
>
> > depends what you mean by "as good as". if functions much the same
> what I really meant is this: Can the plan 9 terminal boot off the u9fs? I
> dont need security (I assume it is easy to configure it that way). I hope
> there is no issue but I just wanted to confirm this.
Also, do I need to do chroot or something to serve from a particular place,
say, /usr/vdharani/plan9?

dharani

Re: [9fans] u9fs

[Russ Cox]

You might also try running a kfs server off of one of
your Plan 9 boxes.  It's probably similar in performance
to u9fs, but you get the precise Plan 9 semantics and it's
easy to set up assuming you've got a Plan 9 box
already.  

You need to boot a cpu server kernel (perhaps with vga) or at least
change devcons to let you read #c/key on your terminal.
Then run disk/kfscmd listen.

I used this setup during the summer I spent at Harvard.  I booted
my office Plan 9 terminal completely off my dorm room
Plan 9 terminal a few ethernets away.  I didn't notice
any performance problems, and it was really nice to have
identical environments whether I was in my room or
my office.  This is, by far, the feature of Plan 9 that I miss
most when I'm not at Bell Labs.  (#2 is the dump.)

Russ

Re: [9fans] u9fs

[Dharani Vilwanathan]

Hi,

> depends what you mean by "as good as". if functions much the same
what I really meant is this: Can the plan 9 terminal boot off the u9fs? I
dont need security (I assume it is easy to configure it that way). I hope
there is no issue but I just wanted to confirm this.

> way, and you can indeed point plan 9 terminals at a u9fs server as
> their file server, but in my experience (using it on various Solaris/SPARC
> systems) the performance is far inferior to that of a real plan9 file
server,
For now, performance is not my concern. I was trying to install Plan 9 on
several boxes and laptops and problems cropped up in many boxes (IDE drive
issues, etc). Then, I thought, if I have a file server on Linux, half my
problems are solved. I have good server boxes that run Linux.

> even on modest hardware. i'd also suggest that the "real" fs is likely to
> be substantially more stable, as well.
I agree but support for drivers is a concern.

Thanks
dharani

Re: [9fans] u9fs

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

it's quite likely slower than need be
because of the wretched TCP_NODELAY
(or whatever it is on your system) not being
set by default.
set it on so as not to delay and it's typically much faster.

term% diff /sys/src/cmd/unix/u9fs/u9fs.c .
33a34
> #	include	<netinet/tcp.h>
1247a1249
> #ifdef SO_KEEPALIVE
1248a1251,1254
> #endif
> #ifdef TCP_NODELAY
> 	setsockopt(0, IPPROTO_TCP, TCP_NODELAY, (char*)&on, sizeof(on));
> #endif

i also ifdef'd SO_KEEPALIVE because some systems haven't got it.

i changed the old (2nd edition) version of u9fs to
emulate file server permissions and permission checking
more precisely, which is to say that it must have been
missing something, but i haven't had the need for that
this time.  you might find you need to adjust it though.
i haven't got that source or i'd hand it on.


[-- Attachment #2: Type: message/rfc822, Size: 2126 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Tue, 19 Mar 2002 11:15:48 -0500
Message-ID: <20020319111548.A54414@honk.eecs.harvard.edu>

On Tue, Mar 19, 2002 at 11:07:44AM -0500, Dharani Vilwanathan wrote:

> Can I safely assume that if I run u9fs on a linux box, it is as good as a
> plan 9 file server with which Plan 9 terminals can be connected?

No, it is substantially slower in my experience.
It serves a different purpose, namely accessing
Unix boxes.  That said, I have used it as a
replacement in a pinch.

Re: [9fans] u9fs

[anothy]

depends what you mean by "as good as". if functions much the same
way, and you can indeed point plan 9 terminals at a u9fs server as
their file server, but in my experience (using it on various Solaris/SPARC
systems) the performance is far inferior to that of a real plan9 file server,
even on modest hardware. i'd also suggest that the "real" fs is likely to
be substantially more stable, as well.
ア

Re: [9fans] u9fs

[William Josephson]

On Tue, Mar 19, 2002 at 11:07:44AM -0500, Dharani Vilwanathan wrote:

> Can I safely assume that if I run u9fs on a linux box, it is as good as a
> plan 9 file server with which Plan 9 terminals can be connected?

No, it is substantially slower in my experience.
It serves a different purpose, namely accessing
Unix boxes.  That said, I have used it as a
replacement in a pinch.

[9fans] u9fs

[Dharani Vilwanathan]

Hi,

Can someone tell me whether u9fs code in the release is the latest or an
updated version is available elsewhere?

Can I safely assume that if I run u9fs on a linux box, it is as good as a
plan 9 file server with which Plan 9 terminals can be connected?

Thanks
dharani

Re: [9fans] u9fs

[rob pike]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

Right.

Hey, I finally found the origin of Boyd's personality.
It's Paul's grandfather in "A Hard Day's Night."

-rob


[-- Attachment #2: Type: message/rfc822, Size: 1955 bytes --]

From: Boyd Roberts <boyd@planete.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Sun, 07 Jan 2001 17:00:43 +1100
Message-ID: <005301c0786f$2c9d8e80$8692fea9@coma>


> Enough evidence has been found.  U9fs once lived in a directory
> without a license, ...

it was 'unixsrc' with sam 'n stuff, right?

Re: [9fans] u9fs

[Boyd Roberts]

> Enough evidence has been found.  U9fs once lived in a directory
> without a license, ...

it was 'unixsrc' with sam 'n stuff, right?

[9fans] u9fs

[rob pike]

Enough evidence has been found.  U9fs once lived in a directory
without a license, which confirms what I vaguely remembered.
I think it's fair and honest to consider that it's unfettered.  I suppose
someone around here should put a copy outside the licensed area.

-rob

Re: [9fans] u9fs

[ianb]

I have. It was straightforward, as from the manual page. Except that 
the authentication is not mentioned. It is all done
using .rhosts for each user.

Ian

On Fri, 7 Jul 2000 10:46:36 -0400 (EDT) owner-9fans@cse.psu.edu wrote:
>
>Has any one installed u9fs on a UNIX box? I am looking for
>instructions to do that.
>
>- ishwar

Re: [9fans] u9fs

[Steve Kotsopoulos]

Ish Rattan wrote:
> Has any one installed u9fs on a UNIX box? I am looking for
> instructions to do that.

Here are the config entries on my RedHat Linux system:

% grep u9fs /etc/services 
u9fs            564/tcp
% grep u9fs /etc/inetd.conf 
u9fs    stream  tcp     nowait  root    /usr/sbin/tcpd  /local/lib/u9fs
% cat /etc/hosts.equiv
10.1.1.3
10.1.1.8
10.1.1.9

If it doesn't work for you, the first thing to do is compile u9fs
with debugging enabled; in u9fs.c change line 11 to say:
#define DBG(f)  f

The debug messages will go to the file defined in the makefile

see the manpage at http://plan9.bell-labs.com/magic/man2html/4/u9fs
for more details

[9fans] u9fs

[Ish Rattan]

Has any one installed u9fs on a UNIX box? I am looking for
instructions to do that.

- ishwar

[9fans] U9FS

[@ 1999-04-23 11:05 UTC (permalink / raw)]

    Thanks Russ Cox, u9fs is working now.

    I�m using port 23 (telnet) to listen u9fs calls, because port 564
didn�t work. Now I�m trying to connect to two systems: SunOS on Sparc
and Linux, and I get:

PC (Plan 9 - mercurio.dcc.unicamp.br) to PC (Linux - 143.106.24.84)

term% srv!tcp!143.106.24.84!23
session...post...
term% mount /srv/tcp!143.106.24.84!23 /n/kremvax
mount: mount /srv/tcp!143.106.24.84!23 /n/kremvax: unknown user or group

In PC (Linux)
term% cat /tmp/u9fs.log
bsdhost mercurio.dcc.unicamp.br on 760


PC(Plan 9) to Sparc (SunOS)
term% srv!tcp!143.106.23.13!23
session...post...
term% mount /srv/tcp!143.106.23.13!23 /n/kremvax
mount: mount /srv/tcp!143.106.23.13!23 /n/kremvax: write to hungup
stream

In Sparc (SunOS)
term% cat /tmp/u9fs.log


    Thanks.

Franklin.

[9fans] U9FS

[Russ]

This works for me on both Linux and the BSDs.

[rsc@brandy u9fs]$ cat makefile
CC=gcc
CFLAGS=-I. -DSYSV -DLOG='"/tmp/u9fs.log"'


u9fs:	u9fs.o conv.o memmove.o mfmt.o
	gcc -o u9fs u9fs.o conv.o memmove.o mfmt.o

%.o:	%.c  u.h libc.h 9p.h
	gcc -c $(CFLAGS) $<
[rsc@brandy u9fs]$

I had to comment out memcmp, strcmp, strcpy,
strlen, and sys_errlist in libc.h, presumably because they
have slightly different prototypes being presented
by the system libraries..

Russ

[9fans] U9FS

[@ 1999-04-22 8:32 UTC (permalink / raw)]

    Did anyone compile  U9FS using gcc. What gcc options  I have to use?
Because I�m getting some error messages when I compile using: gcc
u9fs.c.

    Thanks.


Franklin.

[9fans] U9FS

[Jean]

>     Did anyone install U9FS on SunOS in a SPARCstation?

I did.
The only serious problem I remember was in not realizing immediately that
9p identification is done on the user *name*, not id. So do not give uid
0 to the user none, or u9fs won't allow him access.

[9fans] U9FS

[Ed]

We run u9fs on Solaris 2.6 and Ultrix.  It works fine,
authentication is via the user name only, so the account
names have to be consistent between the 2 environments.

[9fans] U9FS

[Markus]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 508 bytes --]

On Wed, Mar 17, 1999 at 03:07:48PM +0000, Franklin Robert Araujo França wrote:
>     Did anyone install U9FS on SunOS in a SPARCstation?

yes, i have been useing u9fs both on sunos4 and sunos5 without
any problems. however, in order to make chroot() work on sunos5
you have to copy some solaris files to the plan9-tree (truss(1) is
your friend)

-markus

PS:
info on how to setup a chroot-environment for solaris:
ftp://ftp.cs.tu-berlin.de/pub/net/mail/postfix/postfix-contrib-beta.tar.gz

[9fans] U9FS

[Scott]

Franklin Robert Araujo =?iso-8859-1?Q?Fran=E7a?= <973930@dcc.unicamp.br> writes:
> Did anyone install U9FS on SunOS in a SPARCstation?

Yes.

[9fans] U9FS

[@ 1999-03-17 16:26 UTC (permalink / raw)]

    I copied the u9fs directory from the CD for the Sparc. When I "make"  I get the
following messages:

"./libc.h", line 4: syntax error at or near type word "void"
"./libc.h", line 5: syntax error at or near type word "void"
"./libc.h", line 6: syntax error at or near type word "void"
"./libc.h", line 7: syntax error at or near type word "void"
"./libc.h", line 8: syntax error at or near type word "void"
"./libc.h", line 9: syntax error at or near type word "void"
"./libc.h", line 14: syntax error at or near type word "char"

[9fans] U9FS

[@ 1999-03-17 15:07 UTC (permalink / raw)]

    Did anyone install U9FS on SunOS in a SPARCstation?


Franklin.