Has anyone seen where exporting a filesystem after a reboot fails because exports has the name of a host that no longer exists?
My co-worker had this problem and support said this is by design. This proved to be problematic for us when we had a filer reboot and it failed to export some filesystems because some host had been removed a long time ago. Considering the reliability of the filer, it's reasonable that some hosts in the export list might disappear, I'd rather see this as a warning than something that breaks the filer's ability to serve volumes. After all, nothing a client does should break a server, general rule.
Jerry
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
What happens if someone reuses the host name after a month?
Say you have an export: /vol/payroll -access=george:harry:arnold:fred,rw=harry:arnold:george,root=arnold:george
And you retire arnold. You never change the export or there is a new admin who doesn't know to look at the export lists.
Several times since the old arnold was retired, "exportfs -a" was run. Warning messages were printed to the console about no arnold being available. We don't let arnold have rw or root permissions, but due to the nature of -access, we have to leave the string "arnold" in that list, meaning that the client arnold would still have read/only access.
Someone brings up a general purpose server on the network and being a huge fan of TV pigs, goes immediately for the available host name of arnold.
The new arnold is immediatley able to get read permissions on /vol/payroll and several salaries get shared.
A new volume gets created on the filer and someone reruns "exportfs -a". Now arnold is able to write as root to the payroll volume.
In retrospect, a warning would have been nicer, wild security example aside, but at the time we were trying to patch the exports code and not redesign it to a new specification.
We redesigned the exports code in 6.5 and as we no longer preload host IPs for -rw= and -root=, we do not detect that a host is no longer being resolved to IP. As a result, we do not throw away the entire export rule.
The flip side is that arnold can still run amuck through your payroll, so check your export lists when you retire a secure server name. ;>
Has anyone seen where exporting a filesystem after a reboot fails because exports has the name of a host that no longer exists?
My co-worker had this problem and support said this is by design. This proved to be problematic for us when we had a filer reboot and it failed to export some filesystems because some host had been removed a long time ago. Considering the reliability of the filer, it's reasonable that some hosts in the export list might disappear, I'd rather see this as a warning than something that breaks the filer's ability to serve volumes. After all, nothing a client does should break a server, general rule.
Jerry
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
I'd rather see this as a warning than something that breaks the filer's ability to serve volumes.
Agreed.
I had this problem when upgrading to 6.4.2
Had to refer to the manual to remember the option to ignore the exports file.
Atleast if there was a vi like editor on the box, i could use that to make the changes...
But not exporting the entire volume is not cool.
We experienced the same thing here. Luckily, the volume that had the problem wasn't being used by too many folks so the impact was minimal. However, with over 3000 machines in our shop it could have been a nightmare. C-
On Tue, Jan 06, 2004 at 11:49:13AM -0500, devnull@adc.idt.com wrote:
I'd rather see this as a warning than something that breaks the filer's ability to serve volumes.
Agreed.
I had this problem when upgrading to 6.4.2
Had to refer to the manual to remember the option to ignore the exports file.
Atleast if there was a vi like editor on the box, i could use that to make the changes...
But not exporting the entire volume is not cool.
-
Chris Blackmor -
devnull＠adc.idt.com -
Haynes, Tom -
Jerry