9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox rsc@plan9.bell-labs.com
Subject: [9fans] nfsserver
Date: Sat, 25 Jul 1998 18:23:43 -0400	[thread overview]
Message-ID: <19980725222343.fvnBZJ65rjgzMXhZGlUUO-9mDjp9-UF6qdAlPqpMA3Y@z> (raw)

I use the following to export a file tree from kfs to
DOS via NFS (it would work for Unix too...).

rm -f /srv/usaco
srvfs usaco /usr/rsc/usaco
aux/nfsserver -f /srv/usaco -c /lib/ndb/nfs >/sys/log/nfschat >[2=1]
aux/portmapper >/sys/log/portmapchat >[2=1]
aux/pcnfsd -c /lib/ndb/nfs >/sys/log/pcnfsdchat >[2=1]

The srvfs stuff gets me the tree /usr/rsc/usaco served by /srv/usaco.
Then the -f option to nfsserver serves this tree via NFS.

You could try
	mount -c /srv/kfs /n/kfs
	srvfs kfsroot /
	aux/nfsserver -f /srv/kfsroot ...

Note that you can't do "aux/nfsserver -f /srv/kfs",
since nfsserver reads and writes messages to the file you give
it, instead of using mount(2).  Since your kernel is already using
/srv/kfs, the fids that nfsserver picks are likely to conflict 
with the fids that the kernel is using.  In fact, I think you might
not even be able to do any file i/o to /srv/kfs, for this very
reason.  Once /srv stuff gets mounted, the kernel prohibits you 
from doing read/write operations yourself, so you don't interfere
with the kernel.

There are two problems with using srvfs.  One is that it's slightly
buggy and nfsserver exercises those bugs.  I'll post an appropriate
fix soon if you're interested. 

The second, more serious problem is that srvfs turns off permission
checking: all access via /srv/kfsroot would be done as if it was 
being done by the user that ran srvfs.  So in my above example, all
access via the NFS client to the files in /usr/rsc/usaco is done acting
as rsc (who ran the srvfs command) no matter who NFS mounts the file
system.  In my case, I don't care since I'm exporting it to one DOS
machine that I control.  In a less friendly environment, you probably
care a lot more.

I think Richard Miller had some boddles that let you have kfs serve
files via the usual IL port, i.e. act as a file server.  If you apply
those, then you could do
	aux/nfsserver -a il!yourmachine 
and both of the problems I mentioned with srvfs are of no concern,
since you're not using it.  That might be the best solution, short of
setting up your own file server.

Russ




             reply	other threads:[~1998-07-25 22:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-25 22:23 Russ [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-09-07 16:08 Russ
1998-09-04  7:56 forsyth
1998-09-04  6:39 forsyth
1998-09-04  0:18 Russ
1998-07-27  7:28 Kenji
1998-07-25  0:30 Kenji
1998-04-23  4:31 Kenji
1998-04-23  4:31 Russ
1998-04-22  7:13 Kenji
1998-04-21 13:53 forsyth
1998-04-21 10:59 Lucio
1998-04-15 23:27 arisawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19980725222343.fvnBZJ65rjgzMXhZGlUUO-9mDjp9-UF6qdAlPqpMA3Y@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).