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
