If I remember correctly, the harvest docs walk through setting it up
mark
------ Original message------
From: Brian Parent
Date: Mon, Feb 29, 2016 5:46 PM
To: Payne, Richard;
Cc: toasters@teaparty.net;
Subject:Re: NetApp API authentication
Is there a handy cook book on how to set up certificate based authentication on CDOT 8.x, specifically for use with the SDK APIs?
I'm looking at the help doc for Session Managemet APIs for Perl, (in netapp-manageability-sdk-5.4P1/doc/WebHelp/index.htm), but it doesn't explain the steps sufficiently for me.
Re:
From: "Payne, Richard" richard.payne@amd.com Date: Wed, 18 Mar 2015 15:40:47 +0000 Subject: RE: NetApp API authentication To: Edward Rolison ed.rolison@gmail.com, "toasters@teaparty.net" toasters@teaparty.net
7mode or Cmode?
For 7Mode I’ve used, hosts_equiv authentication (which arguably could be better/worse than username/password).
For Cmode I’ve setup certificate based authentication.
I make use of the Perl APIs, but started with them and never looked at just using LWP & XML Parser so I can’t comment on that part.
--rdp
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Edward Rolison Sent: Wednesday, March 18, 2015 11:34 AM To: toasters@teaparty.net Subject: NetApp API authentication
Having started to review some of our filer automation scripts, I'm starting to look in a bit more detail at the API.
My first conclusion is - the perl SDK doesn't actually seem to do anything much - it seems to be a reimplementation of LWP and and XML Parser.
Given I have LWP and XML::Twig installed, and am making API calls just fine, is there anything I'm missing here?
Aside from that though - authentication types.
I currently use ssh public-private key pairs, in a trusted account on a management station to enable 'doing stuff' with filers. It _looks_ like my only option with the API is to create a designated service account, and assign permissions... and then embed a username and password in a script somewhere. That just doesn't sit well with me - I like what ssh-agent will do in 'unlocking' key files, and I don't like embedding (potentially privileged) usernames and passwords ... anywhere.
Does anyone have a better solution than a couple of designated API users (privileged and read only) with a file somewhere embedding their username and password?
Does anyone have a better approach?
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Brian Parent Information Technology Services Department IT Infrastructure Operations Group Computing Infrastructure Team UC San Diego (858) 534-6090 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters