topic "system-cli" privilege in cDOT? in Software Development Kit (SDK) and API Discussions

"system-cli" privilege in cDOT?

kevingraham — Thu, 05 Jun 2025 05:42:20 GMT

What roles does a user need to be endowed with for system-cli access in cDOT?

A user has role "admin" access to application "ontapi" on the admin server. I can verify this at a high-level with just "system-get-version":

<results status="passed"><build-timestamp>1369153754</build-timestamp><is-clustered>true</is-clustered><version>NetApp Release 8.2 Cluster-Mode: Tue May 21 09:29:14 PDT 2013</version><version-tuple><system-version-tuple><generation>8</generation><major>2</major><minor>0</minor></system-version-tuple></version-tuple></results></netapp>

<build-timestamp>1369153754</build-timestamp>

<is-clustered>true</is-clustered>

<version>NetApp Release 8.2 Cluster-Mode: Tue May 21 09:29:14 PDT 2013</version>

<version-tuple>

<system-version-tuple>

</system-version-tuple>

</version-tuple>

</results>

...but attempting to execute system-flu gets "account not configured to connect in this manner":

<system-cli>

<args>

<arg>volume</arg>

<arg>space</arg>

</args>

</system-cli>

<cli-output>Error: Account not configured to connect in this manner.</cli-output>

<cli-result-value>0</cli-result-value>

</results>

Any hints as to what I'm missing?

Re: "system-cli" privilege in cDOT?

rle — Mon, 24 Feb 2014 23:43:04 GMT

Hi Kevin,

The error looks like CLI error because it is in the cli-ouput element. Does 'version' work with system-cli? Also you can check your role with "security login roll show-user-capability" and see if admin is allowed to user system-cli.

Regards,

- Rick -

Re: "system-cli" privilege in cDOT?

kevingraham — Tue, 25 Feb 2014 02:20:00 GMT

Rick Ehrhart wrote:

The error looks like CLI error because it is in the cli-ouput element.

Gah, tunnel vision, thanks.

Does 'version' work with system-cli?

Interestingly, yes, though trying to figure out what other cluster-wide commands would. Though I know we're in undocumented territory, are there at least some examples to dig around?

Also you can check your role with "security login roll show-user-capability" and see if admin is allowed to user system-cli.

Not valid, but here's what I think you're getting at. The 'version' example would -seem- to imply security roles are proper, but 'system node run -node <foo> version.' and other "bare" (e.g. "df") examples fail with the same error.

admin.vserver::> security login role show-user-capability

Error: "show-user-capability" is not a recognized command

admin.vserver::> security login role show -user

Error: invalid argument "-user"

admin.vserver::> security login role show -capability

Error: invalid argument "-capability"

admin.vserver::> security login role show -role admin

Role Command/ Access

Vserver Name Directory Query Level

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

admin.vserver

admin DEFAULT all

admin.vserver::> security login show -username test user

Vserver: admin.vserver

Authentication Acct

UserName Application Method Role Name Locked

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

testuser ontapi password admin no

testuser ssh password admin no

2 entries were displayed.

admin.vserver::>

Any tips would be appreciated.

Re: "system-cli" privilege in cDOT?

rle — Tue, 25 Feb 2014 02:55:20 GMT

Hi Kevin,

Here is my input file:

[rle@pale]{/u/rle} more system-cli.in

<system-cli>

<args>

<arg>version</arg>

<arg>system</arg>

</args>

</system-cli>

Here is the command:

ontapi -I rtp-cse-cl01.eims.netapp.com admin myPass < system-cli.in

Here is the output:

<cli-output>

NetApp Release 8.1.2 Cluster-Mode: Tue Oct 30 23:53:39 PDT 2012

Filesystem kbytes used avail capacity Mounted on

/vol/vol0/ 346969896 16261228 330708668 5% /vol/vol0/

/vol/vol0/.snapshot 18261572 1113280 17148292 6% /vol/vol0/.snapshot

/vol/cse_03/ 1090519040 849979772 240539268 78% /vol/cse_03/

/vol/cse_03/.snapshot 272629760 626821780 0 230% /vol/cse_03/.snapshot

/vol/esxi_boot/ 398458880 99855804 298603076 25% /vol/esxi_boot/

/vol/esxi_boot/.snapshot 20971520 3486324 17485196 17% /vol/esxi_boot/.snapshot

/vol/Orange_total/ 9961472 824 9960648 0% /vol/Orange_total/

/vol/Orange_total/.snapshot 524288 3996 520292 1% /vol/Orange_total/.snapshot

/vol/vsfcs01_root/ 19456 120 19336 1% /vol/vsfcs01_root/

/vol/vsfcs01_root/.snapshot 1024 720 304 70% /vol/vsfcs01_root/.snapshot

/vol/vscifs01/ 19456 124 19332 1% /vol/vscifs01/

/vol/vscifs01/.snapshot 1024 720 304 70% /vol/vscifs01/.snapshot

/vol/cifs_vol01/ 996148 752 995396 0% /vol/cifs_vol01/

/vol/cifs_vol01/.snapshot 52428 972 51456 2% /vol/cifs_vol01/.snapshot

/vol/cifs_vol02/ 996148 732 995416 0% /vol/cifs_vol02/

/vol/cifs_vol02/.snapshot 52428 992 51436 2% /vol/cifs_vol02/.snapshot

/vol/sql_vcenter_db/ 59768832 4778616 54990216 8% /vol/sql_vcenter_db/

/vol/sql_vcenter_db/.snapshot 3145728 0 3145728 0% /vol/sql_vcenter_db/.snapshot

/vol/api_vol/ 194560 244 194316 0% /vol/api_vol/

/vol/api_vol/.snapshot 10240 868 9372 8% /vol/api_vol/.snapshot

/vol/vs_cse_01_vol0_m1/ 19456 124 19332 1% /vol/vs_cse_01_vol0_m1/

/vol/vs_cse_01_vol0_m1/.snapshot 1024 884 140 86% /vol/vs_cse_01_vol0_m1/.snapshot

/vol/tenantinfra/ 209715200 13540508 196174692 6% /vol/tenantinfra/

/vol/tenantinfra/.snapshot 0 0 0 ---% /vol/tenantinfra/.snapshot

/vol/lun_21082013_171200_vol/ 54050312 188 54050124 0% /vol/lun_21082013_171200_vol/

/vol/lun_21082013_171200_vol/.snapshot 0 0 0 ---% /vol/lun_21082013_171200_vol/.snapshot

/vol/vol_rick/	996148	712	995436	0% /vol/vol_rick/
/vol/vol_rick/.snapshot	52428	952	51476	2% /vol/vol_rick/.snapshot
/vol/rick8/	20970652	1792 20968860	0% /vol/rick8/
/vol/rick8/.snapshot	1103716	1112	1102604	0% /vol/rick8/.snapshot
/vol/rick10/	20970652	1876 20968776	0% /vol/rick10/
/vol/rick10/.snapshot	1103716	1316	1102400	0% /vol/rick10/.snapshot
/vol/rick11/	20970652	1908 20968744	0% /vol/rick11/
/vol/rick11/.snapshot	1103716	1328	1102388	0% /vol/rick11/.snapshot
/vol/tenant/	524288000	8624420 515663580	2% /vol/tenant/
/vol/tenant/.snapshot	0	0	0	---% /vol/tenant/.snapshot
/vol/tenavc/	498073600 52415280 445658320	11% /vol/tenavc/
/vol/tenavc/.snapshot 26214400	12284 26202116	0% /vol/tenavc/.snapshot
/vol/testfcp/	498073600 62661500 435412100	13% /vol/testfcp/
/vol/testfcp/.snapshot 26214400	8156 26206244	0% /vol/testfcp/.snapshot
/vol/dtmgmt/	298844160 64975812 233868348	22% /vol/dtmgmt/
/vol/dtmgmt/.snapshot 15728640 26099700	0	166% /vol/dtmgmt/.snapshot
/vol/cse_03_clone2/ 1090519040 509523736 580995304	47% /vol/cse_03_clone2/
/vol/cse_03_clone2/.snapshot 272629760	474576 272155184	0% /vol/cse_03_clone2/.snapshot

</cli-output>

<cli-result-value>1</cli-result-value>

</results>

The ontapi goes to the cluster admin. Have fun parsing df.

- Rick -

Re: "system-cli" privilege in cDOT?

kevingraham — Tue, 25 Feb 2014 05:09:22 GMT

Got to the bottom of this -- "system-cli" requires access to the "console" role. I would've hoped that showed up in audit logs, but might not have been looking at them properly.

Rick Ehrhart wrote:
<system-cli>
<args>
<arg>version</arg>
<arg>;</arg>
<arg>system</arg>
<arg>node</arg>
<arg>run</arg>
<arg>-node</arg>
<arg>rtp-cse-cl01-n02</arg>
<arg>df</arg>
</args>
</system-cli>

Thanks, just wanted to make sure I wasn't missing some unusual structuring (e.g. magic phrasing of "system node run".

The ontapi goes to the cluster admin. Have fun parsing df.

Don't worry -- it was just illustrative