Managing /etc files on a non-CIFS filer (Question/Complaint)

[markjcecil]

We have a 6000-class cluster here dedicated to servicing X86 virtualization platforms, and as such, it's not licensed for CIFS.  This poses a problem in that I need to add the "root" tree under /etc/sshd, so I can put my authentication keys under there to allow some management scripting from one of my UNIX boxen.  However, even though I can start unlicensed CIFS and browse to ETC$, I am unable to write the files I need, and the filer reports as write failed due to lack of CIFS license.

Am I relegated to mounting this sucker up on a box via NFS to manage these files (Not that this is any sort of technical issue, mind you...  It's merely inconsistent with the other filer clusters)?  Is there not a standard method for dealing with these situations that works with ALL filers, regardless of license posture?

Any thoughts?

Thanks,

Mark

[aborzenkov]

It was discussed just a couple of days ago and someone posted link to blog which describes how to setup SFTP. Then you can use any GUI/Norton Commander browser to manage files.

Let me check … yes, I saved it ☺

http://cosonok.blogspot.com/2012/01/netapp-data-ontap-81-enabling-sftp.html

all credits to blog author.

[markjcecil]

aborzenkov:

I do appreciate that.  My only issue is that our filers are all at 8.0.2Px.  SFTP is an option only for 8.1 and later.  All due respect, I thought it prudent to let the rest of the community Guinea-pig the 8.1 releases before I make the jump this year.

And, to the community in general...  Does this need to put things in via SFTP, which also seems to require some password acrobatics, seem just a little on the kludgy side?  Since virtually every filer will, at some point or another, require some file modification in the /etc tree, does it not seem reasonable to have a default method for doing so that does not require so much gyration?

[aborzenkov]

Well ... usually filer has either NAS license (NFS/CIFS), in which case access to /etc is obviously not an issue; or SAN (iSCSI/FCP) in which case it enables CIFS to the extent sufficient to access /etc and edit files there. Which license do you have?

[markjcecil]

We have, on these filers, both FCP and NFS.

And CIFS is definitely enabled, as I can browse the tree, but I can't

create the root dir in /etc/sshd. In fact, the error from the console of

the filer is:

filername> Wed Feb 1 15:11:42 EST [filername:

cifs.access.license.unlicensed:ALERT]: CIFS: LICENSE VIOLATION - attempt to

create a file for a CIFS client on a filer licensed for FCP.

Mark J. Cecil

Global IT Services

Information Services

Navy Federal Credit Union

Office: 703-206.3253

BB:703-853-3814

[aborzenkov]

It is possible that "limited CIFS" allows editing/creation of files but not directories. I think I had the same issue recently with creation of /etc/software. But I believe I was able to copy files into existing /etc/software.

As you have NFS license - do not you have system from which you can manage /etc?

[markjcecil]

Of course...  many hundreds of them, in fact.  And as a 20-year UNIX engineer, this is far from a problematic maneuver.  But the difiiculty or lack thereof in setting up a CIFS share or an NFS export is not the issue.  Any low-rent administrator can do these things.  I just want some non-license dependent consistency.  As an administrator, there should be standard methods to accomplish all of your configuration and administration tasks that are not specifically related to a licensed function (get this...)  *without needing a licensed function*

I suppose the point is this, and please forgive me for being snide...  I find it lacking in NetApp's attention to ease of administration that such a simple operation as enabling key-exchange authentication has to be written up as:

"Step 1 - Make /etc/sshd/root/.ssh/authorized-keys:

IF this filer is licensed for CIFS ( use the "license" command or "cifs stat" to determine this, or you know, whatever...), then do blah blah blah

OR

IF this filer is licensed for NFS (use the "license" command or "exportfs" to determine this, or, again,  whatever...), then do the other blah blah blah

OR

IF you are only licensed for FCP, then, well, I can't help you... "

NetApp has spent a LOT of time and development effort trying to shake the workgroup-level or small-business-level appliance status and present themselves as a provider of enterprise-class storage software and platforms.  Making simple tasks inconsistent and confusing is a great way to discredit that assertion.  If only the attention to ease of administration matched the level of customer support that I have had the pleasure of receiving, then they would be much more believable as a legit Enterprise player.

[aborzenkov]

I wholeheartedly agree that managing non-NAS NetApp version is needlessly complicated by inability to access /etc for various tasks.

As for NFS/CIFS case ... I think you have to draw the line somewhere. If you are managing file server, you are supposed to know how to make directory available and access it later. So any reference to /etc on filer is pretty unambiguous.

[markjcecil]

And here we have the heart of the matter.  In essence...  No, it is not possible to manage your /etc/ tree in a multiple-configuration environment with ONE method.  You will ALWAYS have to tweak your methods based upon what your chosen licenses are for the filer, even if your OnTAP versions are identical throughout your enterprise.  This sort of lack of attention to detail is what we refer to as "Amateur Hour."

I've managed a LOT of gear in my time, and never...  and I do mean NEVER...  have I had such ambiguous management techniques as on this platform.  I will freely admit to being new to the NetApp platform, with a mere eighteen months under my belt there, and I was hoping this was just another example of something I haven't learned yet.  Sadly, it just seems to be an oversight.

Does *anyone* besides me think that maybe an implementation of "vi" would not be too much to ask?

If the knee-jerk response is "admins could foul things up royally with an onboard editor," I will preemptively answer that by pointing out that we do not restrict "priv set diag," and that doesn't seem to bother anyone.