Slashdot Mirror


Microsoft Releases PowerShell DSC For Linux

jones_supa writes: Microsoft is announcing that PowerShell Desired State Configuration (DSC) for Linux is available for download in form of RPM and DEB packages. DSC is a new management platform that provides a set of PowerShell extensions that you can use to declaratively specify how you want your software environment to be configured. You can now use the DSC platform to manage the configuration of both Windows and Linux workloads with the PowerShell interface. Microsoft says that bringing DSC to Linux is another step in the company's "broader commitment to common management of heterogeneous assets in your datacenter or the public cloud." Adds reader benjymouse: DSC is in the same space as Chef and Puppet (and others); but unlike those, Microsofts attempts to build a platform/infrastructure based on industry standards like OMI to allow DSC to configure and control both Windows, Linux and other OSes as well as network equipment like switches, etc.

9 of 265 comments (clear)

  1. Re:I'll bite by LordLimecat · · Score: 4, Informative

    It sounds like you dont use it often, which is hardly a good reason to knock it. But I can offer a few tips:

    1) Remember that just about everything is an object, with one or more attributes and methods. Even strings are objects, and can use methods such as ".equals(System.obj)". Get-Member is your friend for determining what methods and attributes apply:
            "This is a string" | get-member

    2) All (properly made) commands take the form of [verb]-[noun]:
            get-member
            set-ADUser
            remove-item
            get-help

    3) When iterating over a group using "foreach" or "where-object", the special variable $_ is used as a placeholder for the current element:
            @("arrayIndex1", "arrayIndex2") | foreach { write-host $_ }
            @("RedFish", "BlueFish", "BlueBird") | where-object {$_ -like "blue*"}

    4) When in doubt, use one of the following:
            Get-Help [command]
            Get-Command
            $variable | get-member
            $variable | format-list *

    Im of the opinion that it takes all of about 8 hours to learn to do the majority of things you would want to do in powershell (partly because thats about how long it took me). You just have to take some time to sit down and learn it, and then make an effort to use it instead of GUI administration tools. It is far, far superior to old windows command prompt and vbs,

  2. Re:I'll bite by LordLimecat · · Score: 5, Informative

    The nix shells I have used are very powerful, but also very, very painful to learn. Learning sed / awk syntax could easily fill 4 of those 8 hours I mentioned; and thats not even getting into how each and every tool has its own unique idea of how to do syntax. What does a -z switch specify? I dont know, probably fire up that man page and dig through it. What about -h? Is that help, or human readable?

    it really just feels like a kludged attempt to bring CMD.exe to something closer to bash.

    Theyre not even remotely close. They both operate on the idea that data should be passable between consecutive commands via a pipeline, but bash makes no attempt to deal with different types of data nor any good way to determine what data is incoming. Powershell solves this by being object oriented, and letting you easily determine the type of data coming in, export it to XML, and reimport it at a later session if desired.

    As an example-- if you have an error in bash, whats the stack trace look like? Do you have a good way of capturing it? In powershell you can reference the $error[0] variable, and pull up any piece of info you might need to troubleshoot, or even just export the whole thing by "$error | export-cliXML -file C:\somefile.xml" if you're running a nightly job; any issues can later be imported into a new session to diagnose.

    Now the question becomes just because you can use it, does it mean you should?

    Yes. If you deal with IT infrastructure at all, you would be absolutely crazy not to learn it; its explicitly supported (with native commands) by:

      * ALL of the major virtual infrastructure providers (VMWare, HyperV, Xen
      * All versions of windows
      * A great many storage providers (EMC, NetApp, probably others)
      * A number of network infrastructure providers
      * IIS, and Exchange -- like it or not these are huge players
      * And anything else you want to add support for yourself-- I note that Hadoop for example has community support for powershell

    By support, I dont mean in the sense that you could use bash to launch SSH to manage these things. I mean in the sense that VMWare allows you to run the following native powershell commands:
          Connect-VIServer myVMCluster
          Get-VM | Where-object {$_.powerState -eq "PoweredOn"} | foreach { stop-VM $_}

    And all of your VMs will be shut off. Trying to do something like that in bash is doable, it just requires screwing around with scripted SSH access to the VMhosts which is painful, for anyone who has done it.

    I much prefer being able to see /etc/fstab than working with some nebulous class with functions that barely make sense.

    This is a criticism of object-oriented languages, not powershell. You might as well rail against .Net, or Java, or C++.

  3. Re:I'll bite by Anonymous Coward · · Score: 5, Informative

    I've used Powershell several times to write more complex scripts that I would normally have installed Perl on a Win64 system to handle but didn't want to in those particular cases. It worked pretty well once I got all the permission issues worked out, and got kind of familiar with the syntax.

    It was still extremely painful to use. The bloody verbosity of the platform (it really is a platform - not a language) was the worst part. It seems to have been engineered straight out of the com-sci-professor-that's-never-had-to-build-anything's handbook. There is no compromise for anything, few shortcuts. The functions were not sensible in my opinion, as some other posters have mentioned, they would use terms that simply had more syllables than obvious synonyms that are normally used for such things. An IDE was necessary so you could scroll through the list of available functions to find the one you were looking for as they were generally not that obvious. Once you get used to them, sure, it's not as bad, but it's still like having an ankle hobbled compared to both knees.

    I would say it's fantastic compared to your standard batch script. If that's all you've ever known, I seriously pity you.

    I would also say it needs to compromise a great deal to be reasonably useful to people building system scripts, especially coming from unix environments where we've had such tools for $AGES, and have always been asking why our Windows brethren would put up with such silly useless systems.

    I would say that the above you say would be a nightmare in bash - it would be much more trivial in perl, which is what I commonly use for such things. A quick for loop to rename files? Definitely bash. Holy cow is that a pain in Powershell.

    Lastly, I would say: man pages. Sure, MSDN, but not when you don't have network access, or were you cool with installing 1.7gb more files (seriously??) to support it? Space is cheap until you are running out, at which point it's immediately more expensive. It's just a no-brainer.

    Overall, I think Microsoft is incredibly late to this game, over-engineered something as is the norm, and is using marketing tactics to heighten its adoption rather than working on its usefulness. If they could drop in better in-line documentation especially at the command-line (GUIs are great when you have plenty of monitor space and are actually using a UI instead of the console, when you really need to be confident in what that switch is about to do to your last snapshot), make a lot of aliases for the functions (not just the objects) they've developed for the various classes available, and make many of the more commonly used functions statically available directly in the shell instead of buried deep down in some class infrastructure, I for one would be tossing all of my Windows Perl installs (sorry ActiveState, but they're really just band-aids!).

  4. Re:I'll bite by LordLimecat · · Score: 5, Informative

    The bloody verbosity of the platform (it really is a platform - not a language) was the worst part

    A few things-- the language has a large number of shortcuts, like "fl" instead of "format-list" or "?" instead of "where-object" or "%" instead of "foreach". But the verbosity of it is not really a bad thing, as it makes the resulting code at least somewhat self-documenting; its crystal clear what each command will do most of the time.

    An IDE was necessary so you could scroll through the list of available functions to find the one you were looking for as they were generally not that obvious

    This is what tab-completion or get-member or even "get-help [command] -examples" is for.

    A quick for loop to rename files? Definitely bash. Holy cow is that a pain in Powershell.

    $date = get-date -format yyyyMMdd
    get-childitem -filter *.txt | foreach {rename-item $_.fullname "$date_$($_.name)"}

    Really not that painful.

    You mention usefulness- the usefulness as you said is that its a platform supported by an incredible number of vendors. Just about every piece of infrastructure I've come across has vendor-provided powershell integration; the ability to take output from a get-VM command and pass it into a storage provisioning command makes a number of tasks incredibly easy.

    Lastly, I would say: man pages.

    get-help is your friend, and is far superior to man with the -detailed or -examples switches. Not sure where you're getting the "1.7GB", but this page indicates that the size is more like 9KB.

  5. Re:I'll bite by benjymouse · · Score: 1, Informative

    1. What is awkward with string parsing? Is this shell aimed at _incompetent_ people?

    No, PowerShell is aimed at admins who want *robust* scripts - both the ad-hoc ones they whip up as well as the ones they choose to save. String parsing is extremely brittle, and most bash shell scipters do it the insecure and brittle way because it is easier.

    String parsing is often thrown off if presented with unusual characters in file names, if executed in locales where dates and numbers are both generated and parsed different, etc.

    2. And that works how on Linux?

    OMI is available on Linux. Read the FTFA

    3. An IDE in a Shell? Is the syntax so bad that you need an IDE? Or is this another effect of being aimed at incompetents?

    You're the incompetent one. There's is no "IDE in a shell". The ISE *is* the shell - much like if you did bash scripting from emacs. The difference is that the ISE will provide you with intellisense (automatic suggestions), help, syntax highlighting, snippets, multiple script panels, integrated source-level debugging (complete with breakpoints, variable inspection etc) and even a command "builder".

    4. Aehm, know any mainstream modern shell that does _not_ have excellent documentation?

    Most *nix shells have good documentation. PowerShell has good documentation as well. All of the cmdlets have syntax descriptions (automatically generated from metadata), description and multiple examples. In PowerShell even user-defined functions, cmdlets and script files can have the same level of documentation. Comment based help (look it up) makes it super easy to document scripts and functions. And the auto-generated syntax diagrams and parameter descriptions also work for your own script files.

    5. Seriously? I found the command syntax exceptionally awkward and badly thought out. I am back to a cygwin console for most things.

    PowerShells command syntax is extremely consistent. Cmdlets are *always* of the verb-noun form, and there are only about 40 or so standard "approved" verbs. Parsing of the command parameters is the responsibility of the *shell* not of the commands like in *nix shells. Hence, all commands follow the same convention with no strange outliers like e.g. dd. Parameter names are always "long" - but can be abbreviated as long as the abbreviation is unambigous.

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  6. Re:Developers! Developers! Developers! by Gadget_Guy · · Score: 3, Informative

    Build a script library based on short mnemonic commands.

    That's easy to do with set-alias. It already has built-in aliases for mv, cp, ls, cat, diff, echo, lp, man, ps, pushd, rm, wget and many more. Use get-alias to see the list of them.

    For the other commands you listed, I use UnxUtils. It's a lot lighter than cygwin, although the versions are very old.

  7. Re:Developers! Developers! Developers! by Junta · · Score: 4, Informative

    can be run without a GUI at all

    Not true, or else you wouldn't be able to run 'notepad' on the console. Not that this is necessarily a big deal, but the Core editions are not GUI-free, they start cmd in a window. If you ignore the graphics console and use EMS only, the GUI is still running, just not visible to you.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  8. Re:Developers! Developers! Developers! by Anonymous Coward · · Score: 2, Informative

    Last time I tried Powershell, it had one major drawback that made me stop using it. Binary output (like PNG) from one program cannot be piped to another program without getting corrupted.

    Powershell has some really interesting innovations, so I hope people give it a shot and make constructive criticisms so it can be improved.

  9. Re:Developers! Developers! Developers! by wbo · · Score: 4, Informative

    Can't you have some sort of aliases in PS? A genuine question.

    You can configure alias's quite easily in poweshell and in fact there are numerous alias's built-in for common commands. Out of the box powershell includes a ton of short alias's including "gci" and "ls" as aliases for Get-ChildItem, % is an alias for ForEach-Object, cp is an alias for Copy-Item, etc.

    You can get a list of all alias's defined using Get-Alias (or gal). You can also create an alias using Set-Alias (or sal).

    Microsoft generally encourages people to use the full command names in scripts for readability and to make them easier to maintain but there is nothing to stop you from using aliases everywhere including in scripts.