I am with Matt on this one. If you want it to default as "on" that is fine. Then those of us who want to do everything ourselves are happy and those that want a little more help are happy too.
I appreciate NA trying to help but really... this goes a little too far. C-
On Tue, Aug 17, 2004 at 01:39:43PM -0400, Matt Phelps wrote:
Haynes, Tom wrote:
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
One thing to be remembered in all of this discussion is that the export changes were driven by customer requests. So, what one customer may not like, some other customer *had* to have in the code.
So why not an "option auto_update_exports off" ???
Then, we can *all* have it "our way".
We were automatically creating default exports for the root volume. This allowed an admin to start editing files as soon as a NFS license was given to the filer.
We expanded this capability to include all volumes. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch fill up the payroll volume with critical data vol offline scratch vol destroy scratch vol rename payroll scratchWithout automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
- The automatic export creation:
If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
- If you want a command line export to be persistent, use the new,
as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
I don't like it either. In addition, when you do a volume name change, the OS will quietly change the exports file to what it thinks you'd like to have there. I feel it's rude to make those changes to MY export file without letting me know. NetApp says they are making it easier for system administration for less experienced owners.
At 10:06 AM -0500 8/17/04, Chris Blackmor wrote:
I agree with you Chris. I don't think automatic exports of any kind are a good idea. I would rather err on the side of not giving access than opening it up to the world without my knowledge. I know soon enough if I have forgotten to export something but I *WON'T* know soon enough if the system has *helped* me out.
What say ye NA-Folks? C-
On Tue, Aug 17, 2004 at 03:47:15PM +0100, Chris Thompson wrote:
I have been caught out by one aspect of the changed NFS export implementation in ONTAP 6.5.x (specifically, 6.5.1R1P6), that might have had serious security implications.
When a volume is created, say /vol/test, it is now autmatically NFS exported with a rule
/vol/test -rw,nosuid
i.e. read-write to the world. As a volume starts off with just a root-owned top-level directory, and there's no "root=" clause, this isn't _exactly_ a security exposure staight away, but of course it becomes one as soon as more interesting data is installed there.
Having noticed that at the time, I did
exportfs -io rw=[a-testing-host],root=[a-testing-host] /vol/test
and continued with my tests (which involved restoring bits of other filing systems into /vol/test).
What I hadn't realised was that the original "vol create test" had not only exported the volume, it had added a line to /etc/exports. So the next time the filer was rebooted, the unrestricted export came back... which, of course, I didn't notice for some time.
Has anyone else been caught out like this? Does anyone else think that these automatic NFS exports shouldn't be happening at all?
-- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
--
- Chris Blackmor _______ | If I keep doing what I
am *
- Advanced Micro Devices ____ | | doing
- Phone: (512) 602-1608 /| | | | I'll keep getting what I
am *
- Fax: (512) 602-5155 | |___| | | getting
- Email: chris.blackmor@amd.com |____/ | | Author
Unknown*
My comments are mine, and mine alone.
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://cfa-www.harvard.edu