We eval'ed one of the Quantum Guardian/SnapServer boxes awhile back. While there was a command line, you had to do everything from the GUI, and even though it was Linux underneath, you couldn't use all the standard options in the export file through the GUI.
We ended up sending it back and continuing to buy NetApps. It was the old 'good, cheap, fast' pick at most two. NetApp is good and fast, but not cheap. The Quantum thing wasn't that cheap, and wasn't any good, and was too broken to test fast.
Flat text files are good. If NetApp wants to make everything into a database, at least have an option to populate the database from a text file. Having `exportfs -a` read /etc/exports and create /etc/exports.db is fine, but I want to be able to edit a text file.
We keep quotas, exports and a few other of the config files under RCS on all our filers, so any automatic 'helpful' changes will be lost at the next check-out.
John
-----Original Message----- From: Mike Sphar [mailto:mike.sphar@Remedy.COM] Sent: Wednesday, August 18, 2004 12:09 PM To: toasters@mathworks.com Subject: RE: Automatic NFS export on vol create
Speaking purely for myself, as a long-time Sysadmin, the fact that so much of Netapp's config is stored in text files was a *big* advantage to me. Databases always seem like a good idea until they get corrupted, or the front-end administration tools fail because of bad data. (Anyone else ever adminned AIX? Hell, just the other day I had to spend a fair amount of time trying to repair a corrupted registry on a Windows box.)
We would need such functionality to support upgrade and revert paths.
But I also agree that there has to be a long lived way to convert from a text file to the database file. In part, I would need it for unit testing. And on the flip side, I would want a means to convert from the DB to a text file.
The problem for me is that I only want to do parsing error checking once, when the export is added to the DB. After that, I don't have to worry about issues like:
- Is this a netgroup which starts with a '.' or a DNS subdomain? - Is this a hostname or a netgroup? - Is this a hostname with an ':'?
There is a new class of problems, e.g., has the DB been corrupted, but if I can make better determination about entries in host lists, then I can make more intelligent procedures to resolve whether a request from a host is allowed access.
We eval'ed one of the Quantum Guardian/SnapServer boxes awhile back. While there was a command line, you had to do everything from the GUI, and even though it was Linux underneath, you couldn't use all the standard options in the export file through the GUI.
We ended up sending it back and continuing to buy NetApps. It was the old 'good, cheap, fast' pick at most two. NetApp is good and fast, but not cheap. The Quantum thing wasn't that cheap, and wasn't any good, and was too broken to test fast.
Flat text files are good. If NetApp wants to make everything into a database, at least have an option to populate the database from a text file. Having `exportfs -a` read /etc/exports and create /etc/exports.db is fine, but I want to be able to edit a text file.
We keep quotas, exports and a few other of the config files under RCS on all our filers, so any automatic 'helpful' changes will be lost at the next check-out.
John
-----Original Message----- From: Mike Sphar [mailto:mike.sphar@Remedy.COM] Sent: Wednesday, August 18, 2004 12:09 PM To: toasters@mathworks.com Subject: RE: Automatic NFS export on vol create
Speaking purely for myself, as a long-time Sysadmin, the fact that so much of Netapp's config is stored in text files was a *big* advantage to me. Databases always seem like a good idea until they get corrupted, or the front-end administration tools fail because of bad data. (Anyone else ever adminned AIX? Hell, just the other day I had to spend a fair amount of time trying to repair a corrupted registry on a Windows box.)
On Thu, Aug 19, 2004 at 08:55:23AM -0700, Haynes, Tom wrote:
The problem for me is that I only want to do parsing error checking once, when the export is added to the DB. [...] There is a new class of problems, e.g., has the DB been corrupted, but if I can make better determination about entries in host lists, then I can make more intelligent procedures to resolve whether a request from a host is allowed access.
XML format seems to comfort both parties: you can have errors checking once, DB corruption should not be a problem (and if happens, it gets easy to fix), admins can use revision control systems to guard changes and also edit files manually (provided XML format is described, but even if not, one can make an educated guesses).
p.
Let me just second this in case someone is keeping score... we do ALL of our admin stuff from ssh sessions. We even bailed on using snmp to monitor the filer and use ssh connections to get the information we need. We also have many Windows and Unix processes that automate the creation of directories/shares/exports that demand full functionality from command line utilities. If any of these features are to use a database on the back end... sufficient command line utilities like what is described below must be included. (and be sure to keep the ssh key authentication option!)
matt
On Aug 18, 2004, at 3:27 PM, John Clear wrote:
We eval'ed one of the Quantum Guardian/SnapServer boxes awhile back. While there was a command line, you had to do everything from the GUI, and even though it was Linux underneath, you couldn't use all the standard options in the export file through the GUI.
We ended up sending it back and continuing to buy NetApps. It was the old 'good, cheap, fast' pick at most two. NetApp is good and fast, but not cheap. The Quantum thing wasn't that cheap, and wasn't any good, and was too broken to test fast.
Flat text files are good. If NetApp wants to make everything into a database, at least have an option to populate the database from a text file. Having `exportfs -a` read /etc/exports and create /etc/exports.db is fine, but I want to be able to edit a text file.
We keep quotas, exports and a few other of the config files under RCS on all our filers, so any automatic 'helpful' changes will be lost at the next check-out.
John
-----Original Message----- From: Mike Sphar [mailto:mike.sphar@Remedy.COM] Sent: Wednesday, August 18, 2004 12:09 PM To: toasters@mathworks.com Subject: RE: Automatic NFS export on vol create
Speaking purely for myself, as a long-time Sysadmin, the fact that so much of Netapp's config is stored in text files was a *big* advantage to me. Databases always seem like a good idea until they get corrupted, or the front-end administration tools fail because of bad data. (Anyone else ever adminned AIX? Hell, just the other day I had to spend a fair amount of time trying to repair a corrupted registry on a Windows box.)
Matt Miller IT Infrastructure Duke - Fuqua School of Business