WFA 2.0 - How to add and verify connectivity of type "Other"?

[reide]

IHAC who wants to define a Linux host in WFA 2.0.  Their goal is to write some WFA command that issue commands to the Linux host via SSH.  We were able to add the linux host to the "Credentials" menu by specifying a type of "Other".  However, their doesn't seem to be any way to test the connectivity of "other" devices such as hosts, switches, etc...  

What is the recommended method for adding "other" devices and testing their connectivity?

Thanks.

Reid

[sinhaa]

For testing the connectivity using the given credentials, WFA needs to know what API to use which in turn depends on what Type of Host is selected. E.g. Different API is used for connecting to a Vmware Host than what is used for a DFM host. Hence the Type is important.

For Host type "Other" which can be any type of Host, WFA can't have any API sets defined to carry out a connectivity test because "Other" can include absolutely any host. Hence no test connectivity possible for the type "Other".

Courtesy: Sasha

[SeanLuce]

I am also looking for the best way to send commands via SSH to a Linux host.  The idea is to complete the loop for some of the common workflows.  For example it would be nice to be able to do the following:

Create a new Volume

Create a Qtree on that Volume

Export the Qtree to a specific host

Mount the NFS export to the host

What is the best way to interact with hosts via SSH from within WFA?

Thank you!

[goodrum]

Sean,

I have been working on a very similar idea.  I can tell you that this is totally doable and requires no extra toolkits.  The Data ONTAP PowerShell toolkit comes with a command called Invoke-NaSSH.  This cmdlet can be called in a custom WFA command and doesn't require any changes to the execution policy.  Now, the command is designed to send SSH calls to the Data ONTAP system but it also works pretty well when calling other remote systems via SSH.  I have used it to run commands for configuring mounts on Oracle Linux hosts after carving out the new storage.  This solution is part of a planned release in a new Pirate Pack for Oracle.

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[SeanLuce]

Jeremy,

Thank you for the quick response.  I just listened to you on the NetApp Communities Podcast!

I thought about Invoke-NaSSH, but assumed it was only for interacting with controllers.

I have been mucking around with quite a few different SSH implementations for Windows, including cygwin, plink/putty, and some PowerShell modules that add SSH functionality.  I can get them all to work directly from the command line, but as soon as I try to call them from within WFA, I run into problems.

Thanks again,

Sean Luce, Open Systems Technologies

@seanluce

[goodrum]

I hope you enjoyed the Podcast.  We had fun doing it.

Technically, the Invoke-NaSSH is suppose to be for connections to NetApp Array but it is a regular SSH client.  I have used it for several direct operations to switches and to hosts.  So far no issues.

Regarding the remote execution issue:  Remember that by default, WFA runs as a Local System account.  If you need to change the execution policy for the Powershell modules to execute then there are a couple of options.

1) There is a tool called PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) that would allow you to trigger an execution as the Local System account.  You could use this to test out the issues that you are having and possible change the execution policy.

2) The other option would be to 'change' the execution on the fly.  If you put into the WFA command the cmdlet to 'backup' the execution policy and then set it to unrestricted.  After the execution was finished then the policy would be set back to the original state.  I have used this little 'trick' many times when I need to run a script:

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

$curPolicy=Get-ExecutionPolicy

Set-ExecutionPolicy Unrestricted

.....

Set-ExecutionPolicy $curPolicy

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

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[SeanLuce]

Thanks for the tips, Jeremy.  I think I am very close to password-less ssh commands to a Linux host from within WFA.

It seems like the DataONTAP PoSH module that is included with WFA does not include the -PrivateKeyFile parameter as part of Invoke-NaSsh.  I downloaded the latest NetApp Powershell Toolkit and replaced the one in C:\Program Files\NetApp\WFA\PoSH\Modules\

The following command does work from within a PowerShell command window (192.168.24.131 is a CentOS host):

Invoke-NaSsh -Name root@192.168.24.131 -PrivateKeyFile C:\scripts\private.ppk -Command 'mkdir /mnt/new_dir'

However, when I try to run the same command from within WFA, I get the following error:

00:16:44.178 INFO  [MakeDir] ### Command 'MakeDir' ###

00:16:44.864 ERROR  [MakeDir] Failed executing command. Exception: The following error occurred while loading the extended type data file:

Microsoft.PowerShell, C:\Program Files\NetApp\WFA\PoSH\Modules\DataONTAP\DataONTAP.Type.ps1xml : File skipped because of the following validation exception: AuthorizationManager check failed..

Microsoft.PowerShell, C:\Program Files\NetApp\WFA\PoSH\Modules\DataONTAP\DataONTAP.C.Type.ps1xml : File skipped because of the following validation exception: AuthorizationManager check failed..

Is this happening because I "upgraded" the included DataONTAP PowerShell toolkit?

Thanks again for all of your help!

[goodrum]

Hmm..  This is a new one for me.  After you upgraded the toolkit, did you bounce the WFA Server service?  Part of the process to initialize the modules is to run the script found in the %WFA_Install%\PoSH\profile.ps1 file.  So, if you replaced the existing DLL, then you might need to restart the service.  I haven't tried to use passwordless authentication.  I have used the WFA credential type of Other and passed that down to the command.

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[SeanLuce]

I can't believe how easy this turned out to be...

It seems like any modification at all to the included PoSH toolkit causes issues even with the bundled workflows.  It must do some kind of validation to make sure they haven't been tampered with.

Passing down the WFA credential of 'Other' was what did the trick. 

This is now working without any prompting:

$credentials = Get-NaCredentials -Host 192.168.24.131

Invoke-NaSsh -Name 192.168.24.131 -Command 'mkdir /mnt/now' -Credential $credentials

Thank you!