[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    [9fans] the import/exportfs protocol - fmt repost
From:       mycroftiv () sphericalharmony ! com
Date:       2013-02-27 8:32:40
Message-ID: 13243eba28cc62981669ec147e3ff067 () sphericalharmony ! com
[Download RAW message or body]

I apologize for the resend. I pasted text written in acme without |fmt first. I'm blushing.

Hello.  I am writing to 9fans to solicit discussion (and hopefully
consensus) about a proposed patch to import(4) to match the options
that currently exist in exportfs(4).  I have submitted a patch(1) to
sources to be found in sources/patch/importz.  The readme and manpages
for that patch also explain this issue but based on my discussions
with other users in IRC, I would like to submit the topic for
community analysis.  I am sorry for any inaccuracies, please correct
any mistakes.  I appreciate all the discussion I have had with others
already.

Summary: currently, the exportfs(4) options -a and -r or -S are
incompatible when exportfs is being used as a listener.  I propose a
simple patch to import to allow import to correctly mount exportfs(4)
services that are using these flags.  A new flag -z tells import to
skip the same part of the protocol (tree request) that exportfs skips
when using the -r or -S flags.

Example:

aux/listen1 tcp!*!9876 /bin/exportfs -a -r /usr/me/authedexport

Translated to english, this command says: "listen on port 9876,
authenticate clients, and then serve this directory." This is a
sensible usage of exportfs.  However, neither current import(4) or
srv(4) and mount is able to connect to an exportfs run with these
options.  It creates a protocol variant which is currently
unsupported.  The same issue exists if you substitute the -S flag
(exportfs of a service mount usually from /srv).

The proposed patch allows you to use this command to mount the above
export:

import -z tcp!server!9876 somefiles /n/authedimport

(because the string for the remote tree is not sent to the server
under this protocol variant, "somefiles" can be any random string.)

The implementation of the flag is completely trivial, simply wrapping
the tree request code in an if block.  It changes no existing behavior
of either exportfs or import.  No new bugs or incompatibilities in
existing scripts and configs are created.  The purpose is simply to
make import conform to the options which already exist in exportfs.  I
believe that making exportfs and import "symmetrical" in terms of
supported options and modes is fundamentally sound.  At the moment,
exportfs is happy to listen with -a -r but nothing can mount it.  I
see this patch as a bugfix for this poor interaction of flags.

In discussing this issue and patch with others, several potential
issues and objections have been raised.  I would like to discuss them
to try to clarify possible objections and misunderstandings.  A list
of objections and responses:

1.  "This creates additional complexity."

I do not believe so.  The complexity is created by the already
existing flags to exportfs and their interactions.  The -z flag to
import exists to match the existing behavior of exportfs and allow to
use the existing exportfs options to function in combination without
producing "non-mountable" exports,

2.  "There is no purpose to this, because a standard exportfs -a of
the full root allows the client to request whatever subroot it wants,
or mount and then mount any /srv it wants."

I understand this point, but I think there are several responses.  The
first is that fixing broken interactions of seemingly sensible flags
is a good thing to do no matter what.  You can cp a file by cat file
>newfile but that doesnt mean that a bug in cp isnt worth fixing, just
because you can perform the operation another way.  The second is that
you could make the same argument for an http server: "Why does an http
server need to be able to serve a specific subdirectory?  You can
always serve the whole root of the tree and the client can choose to
look in the www subdirectory." - in other words, choosing a specific
portion of namespace or a specific /srv is a sensible thing to do to
restrict access.  As a user, saying "I only want to export this much"
is desirable.

3.  "The -P patternfiles let you control that also." Yes, but the
patternfile mechanism is definitely more complex, and when you have a
simple flag like -r to select a given root, why impose the necessity
of creating a patternfile rather than using the -r flag which already
exists?  To some extent this argument and the previous are more
arguments about the design of exportfs.  My belief is that whatever
exportfs does, import needs to support.  There are many possible ways
to have the protocols work - but I am proposing a simple change to fix
a currently existing issue, the question of whether or not the -r or
-S flags to exportfs are superfluous is a design issue.  Those flags
exist, and I believe it makes sense for import(4) to support the same
behavior those flags create.

Also, my fundamental concern is making exportfs -a -S mountable by
something, somehow - the exact mechanism isnt the most important
thing.  I believe a tiny patch to import makes the most sense in terms
of minimalism and simplicity, but you could deal with this issue in
many ways - make exportfs and import smarter about tree negotiation,
let srv know how to talk the "-a -S/r" protocol, etc.  The issue of
the "unmountable protocol" is something that could be solved in many
ways, but I believe it definitely should be solved in some way.  The
proposed patch adding -z flag to import is trivial and i believe
trivially "verifiable' in the sense that it is guaranteed to allow you
to mount those exports and not introduce any new buggy behaviors.

4.  "The -r and -S options are really just for -B mode" I haven't
actually heard anyone say this, but I can imagine it as a potential
response.  To some extent the previouis answers respond to this also,
but another response is simply a user perspective: I find that doing
listeners with -a -r and -a -S is something that is useful to me.  It
seems like the most direct way to share a specific piece of namespace
or a specific service with auth, and that is a sensible thing to do.
Perhaps the -r and -S flags were added with -B mode in mind and that
has been the primary historical use, but when you translate the
meaning of the commands into english - "do an authenticated export of
this service or this part of namespace" - it seems to me like a simple
and sensible use of the commands and flags.

5.  "Exportfs isn't intended to be used in this way" I don't think
this is true.  Exportfs is intended as a general mechanism to share
namespace of any kind.  It is a core system utility.  The essence of
Plan 9 is network transparent namespaces.  The flexibility of being
able to share namespace across a network however you want is very
important to Plan 9, and so making exportfs and import work together
in all situations and with all options is a sensible goal.  I think
that exportfs -a -r and -a -S listeners are a useful tool for both
private and public plan 9 networks.

6.  "OK, but patching import isn't the right solution, the right
solution is..." maybe you are right.  I don't have strong opinions
about whether or not a new flag is better or worse than trying to
extend the import/export protocol to be smarter in its negotiation or
whether some other solution is preferable.  I do think that the
proposed patch is trivially "correct" in fixing the problem,
non-disruptive to all existing users, and based on a sensible
principle of symmetry between exportfs and import.  Even if you think
a better long term solution involves changing the export/import
protocol or even unifying srv and import as a single tool to handle
all kinds of 9p connections and authentications, perhaps you might
view import -z as a decent temporary solution.

7.  "Why is this important?  This has never affected me, can't it just
be ignored?" I agree that this is an issue which is only like to come
up if you are creating "on-demand" service listeners with aux/listen1
for various purposes, but that is basic functionality for some grids
of machines.  9p is the heart of plan 9, and the tools which work with
9p services should let you serve and mount using the options of your
choice.  Making exportfs and import match cleanly is just like making
the electrical plugs match electrical pluckets - square pegs, square
holes, round pegs, round holes.

8.  "You submitted the patch already, what is the purpose of this huge
9fans post?" The reason for soliciting community discussion is my
practical awareness that Plan 9 is now being distributed in several
forms, some consiered "forks" and some "not-fork variants".  I
mentioned that I think the tools for creating and importing 9p
services over the network are foundational, so to me the interaction
of import and exportfs and how the options work on each side is
something that all the plan 9 developers (and users) should have
consensus on.

I also hope that the intent of this post - constructive discussion and
consensus about how these tools should work - is clear.

I have had long discussions with many people who are more expert in
plan 9 use and development than I am, and I have not succeeded in
achieving consensus about my perspective and proposal.  I want to have
constructive discussion about an issue i think is important because it
affects how all Plan 9 systems which make use of exportfs/import
communicate.  I hope this post leads to constructive discussion of the
import/exportfs protocol.

Ben Kidwell -mycroftiv

[prev in list] [next in list] [prev in thread] [next in thread]