Issue with hosts based authentication and https

[richard_payne]

Hello,

I wrote a script using the SDK a few months ago. It's using 'HOSTS' as the auth style, with the transport_style of HTTPS. The intent was to load the snapmirror data from all of our file servers and for most of them it works just fine. I just setup two new filers and am receiving this error:

Warning: Error were encountered on this run!

Warning:User  does not have capability to invoke API snapmirror-get-status. for file server deadpool

and on the console:

Thu Aug 21 11:44:31 EDT [deadpool:useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-snapmirror-get-status' 

Now the script is run from a host that has root access via rsh (and ssh FWIW) to the file server, and is run as root. Sure enough this is failing on both of the new hosts (these are running 8.2.1P2 if it matters). I did a diff on the options between this filer and a working filer and didn't see anything related to httpd or auth.

Now I also have 3 or 4 file server running 8.1 that return a similar message:

Warning:User XXX  does not have capability to invoke API snapmirror-get-status. for file server bucket

Now in this case the user XXX is the account we use the the RSA from the service processor. Again this is run as root from a root host, no where in the code am I using the XXX account (I even added a set_admin_user('root') as a test but no difference).

What am I missing?

thx,

--rdp

[richard_payne]

Bump....am I the only person using hosts based authentication with the SDK?

thx,

--rdp

[Richard_S]

Hi Richard - no you're not the only one. And "you're not alone" in hitting this error also. We're hitting it on ONTAP 8.1.3P1D6. Same application works perfect against 7.3.2. Seems 8.1+ may be where this started. We've not tested any versions in between these though. Have found someone else experiencing it as early as March 2013 at this thread: http://community.netapp.com/t5/Software-Development-Kit-SDK-and-API-Discussions/ontapi-HOSTS-style-connection-problem/td-p/60100 but no word on whether that one was resolved. Very keen to know if you've progressed from your situation above?

RS

[richard_payne]

Hello,

Thanks for the response...good to know I'm not the only one! I have not found a way to fix this. I've done some testing but so far have had no luck in solving the problem. I actually have a 7-mode cluster runing 8.1.4P1 where one head works all the time and the other fails. I've gone through the 'options' and configs on both machines but can find no differences. I will say i have not had any problem with 8.0 OnTap, only a few 8.1 machines. I've also noticed it failes on most of our 8.2 machines as well. I was thinking about opening a support case in regards to this. If I can't get the SDK working on all the machines then I'm afraid we'll have to go back to using rsh/ssh to gather the information we need.

thx,

--rdp

[Richard_S]

Hey thanks for the update. In our case we cannot go lower than 8.1.x as part of what we're doing with the API is SnapLock calls (file-set-retention & file-get-retention) and SL is supported from 8.1 only, after the 7.3.x series.

RS

[Richard_S]

Hey, BTW: can I check what version of the NetApp SDK you're using? We've had a hint that this may be part of the issue (a mismatch between SDK version and ONTAP version).

[richard_payne]

We are currently using 5.2.1.

thx,

--rdp

[richard_payne]

I know it's bad form to reply to my own post, but I just downloaded and tested SDK 5.2.2 with the same results. The filers that failed before still fail.

--rdp

[Richard_S]

OK, so you strike the error even when using completely up-to-date SDK. Our application is built with SDK 3.5p1, but apart from that we can generate the error using apitest from SDK 5.1. So I'm still leaning towards the problem being in the ONTAP-side.

[richard_payne]

Just thought I'd update the thread that this is still going on, though I see much less of it than I used to. I have still have two NetApps (running 8.1.4P5 7Mode) that routinely have a problem with this. What's most frustrating is that one API call will work and the next will fail (and sometimes subsequent calls will work). I tried opening a case on this but was basically told 'we don't support your code'. Which is fine, I get that but it fails with NetApp code as well. Oh well.

--rdp

[Richard_S · Accepted solution]

Hi, this is in fact an ONTAP bug that has been previously identified and there is a bugfix release that can be obtained (at least it's available for 8.1.4 - it's version 8.1.4P1D7). Note that the bug is specific to the hosts.equiv auth method. The bug ID is 269652 - the description of which might be only available internally. If you can get hold of that version (8.1.4P1D7) I'd be interested to hear if it fixes your issue.

RS

[richard_payne]

Richard - Thank you! I looked up the bug and it's public. Looks like it's fixed in lots of later OnTap revisions (include 8.1.4P7) so no need for the 'd' patch release. I don't know if I'll be able to upgrade my two problem children anytime soon, but I have seen intermittent failures on other hosts that will be easier to upgrade.

thx,

--rdp

[Richard_S]

Yeah see how you go - but if it's still failing then do try the D-path version I mention. IIRC, even though it's marked as being fixed in other versions, it actually got missed from a lot of those versions - hence the D7 patch version was made specially for our customer who was hitting it too many times to bear.

RS

[Richard_S]

Sorry, forgot to mention that the 8.1.4P1D7 version was only released in November 2014 (or early December), so any version 8.1.x or 8.2.x released earlier (even with later version numbers) will likely *not* be fixed from this bug...

RS

[richard_payne]

I asked our SAM to look into this and evidently 865594 is the follow on but that's fixed in the D patch release, as well as 8.2.3 and 8.3RC.

thx,

--rdp

[chithanh]

Useful article, I learned a lesson, thanks agian

-------------------------------

FilteringDataGrid for WPF