PowerShell: Import NetApp AutoSupport

The first step to any problem is getting said problem into PowerShell! We all know the usual players here WMI, ADSI, .NET, COM, etc… but what about good old text. I get the impression text has been ignored as legacy. When text does get a little attention it is almost always treated like the unix world.  Get-Content | Select-String used in place of cat|grep… I offer a different approach, in my opinion you haven’t really ingested something until it’s in the form of an object. Ala, Import-ASUP, a PowerShell script to ingest a NetApp autosupport. Give it a try and look around at the object it spit’s out. You may be surprised just how much information we all beam back to the mother ship every week!

Read more

PowerShell: Custom Types, and Formatting

So you’ve graduated to the PowerShell elite, you’ve mastered the pipeline, and one-liners seem well trivial.  What now?  For me, I started working on a module, and along the way I was forced to really learn PowerShell’s Type and Formatting subsystems.  As I see advanced functions start to propagate out into the world I wanted to share some of what I learned (As well as provide myself a useful reference guid!).

Why should you care? Well,  in order for your script/module to truly perform like a first class cmdlet.  You must have a custom type.  Having this custom type will cause several built-in automation gremlins to get confused…. I.e. PowerShell doesn’t know how to handle your new object!  With a combination of type, and format data we’ll teach PowerShell how to handle our object. 

First we need a custom object, I’ll use an example slightly above foo.bar..  First things first we need to construct our object, I won’t get too into this as I’m not qualified to speak on the matter.  All I will offer is this I’ve seen examples using c# interfaces as the object construct.  I prefer using a class as it allows me to define multiple Constructors, which become very useful later on in your code!

So far so good right?  Well, we already need a little tweaking.  Consider what happens next when we instantiate our Server object.. 

Notice how PowerShell just repeated the type name over and over again.  That’s because we haven’t told it what we care about and how to display the information in this situation. I know this is a rare case but it’s one I’ve found all to often!  Fortunately this is handled easily enough. Ultimately we will handle this with a format data file, but first we need to extend our types!  While it is possible to do all this work in the format file, I highly advise against it as it will lead to confusion by your users!

First we’ll create a GetAdmin.Types.ps1xml file and add the following, permanently adding a couple script properties to our objects.

As you can see we added a script property to our Net object that will return the the ip in a string.  Then we used that IP property in the IPAddress script property to create a comma separated list of IP’s.  Then we’ll use that list of IP’s as the default view for the network.  This is done with a simple format data file. A quick note with the format data file: it’s a good idea to format to 80chars wide, as this is the default for most 3rd party consoles.

Now when we run our command we’re displaying useful information right from the start, but we haven’t hampered anything.  Remember the full object is still available underneath.

That’s all for now, Next time type conversion!

~Glenn Sizemore

PowerShell: Custom Types, Type conversion and ETS

Before we get into the how, here is why you should care about this!  Consider the following oversimplified function.

First off we need to load our custom types:

Now let try and use this function:

While that’s not that bad, consider the following, it could look like this.

Now I really don’t want to get into which one you should be using.  I prefer instead to focus on how to enable either one!

First things first we’re going to have to get a little dirty with some C# (Again I’m not a developer so if anyone knows a better way to do this I’m all ears.) and create a type converter.

I told you we needed to get a little dirty!  Now that we’ve implemented a type converter that knows how to convert a string to a GetAdmin.Net object.  Now we need to inform PowerShell of our work.  This is accomplished via the a type formatting file.

Next import your new type definition file, and try it out!

Hope that was helpful, know a better way?

~Glenn

Homemade remote CLI for NetApp

Security is one of those things that everyone knows they need to do, but it rarely gets done to the level that it should be.  This, at least in my experience, is primarily because security makes general, day-to-day tasks more difficult.  Take, for instance, rsh.  Rsh by itself is a great time saver…admit it…it’s great to just be able to execute commands from your admin host and have the results returned back.  You can parse them however you like using standard operating system tools like grep, awk, and sed, and best of all (or perhaps worst…) you don’t have to type the password repeatedly.

However, all of the benefits of rsh can be realized using ssh, it just takes a little more setup.  But, I’m not going to get into that today.  What if you just want a way to securely execute commands against your NetApp without consuming the sole connection to your your filer via ssh (you have telnet and rsh disabled, right?).  What if you don’t want to enable ssh, telnet, or rsh but still want to have a pseudo command line?  Assuming you have SSL (https) access enabled, you can use the Perl SDK to access, and execute commands against, your filer almost like you were telnet/ssh’d into it.

The magic comes from the undocumented system-cli SDK command.  It allows you to execute almost any command just as though you were sitting at the console.

The great part is that with this, you can accomplish probably 99% or more of all tasks having only one access method enabled to your NetApp: the https/ssl option.  SSH, RSH, telnet and HTTP can all be disabled.

I say almost because there are two types of commands that do not work using the below Perl script.  The first type is non-terminating commands.  These, at least off the top of my head, are primarily the stats show commands with the –i option specified.  With the –i option, the stats command repeats every number of seconds specified.  Now, the caveat to this is that you can also specify a –c option that limits the number of occurrences to the number specified.  The downside to this is that if you issue a command like stats show –i 5 –c 5 volume:*:read_ops then the command will take 25 seconds, at which point the results, as a whole, will be returned.

This also applies to issuing man commands.  Man will not return (at least with the simulator) to STDOUT, so system-cli doesn’t capture the output.

So, without any more pontificating by me, here is some sample output and the script.  If you would like to see additional examples, let me know in the comments.

Read more

b8356caf813633f4b9d3e13de0f7a411{{{{{{{{{{