Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Chocolatey Community Feed State of the Union

tl;dr: Everything on https://chocolatey.org/notice is coming to fruition! We’ve automatically tested over 6,500 packages, a validator service is coming up now to check quality and the unreviewed backlog has been reduced by 1,000 packages! We sincerely hope that the current maintainers who have been waiting weeks and months to get something reviewed can be understanding that we’ve dug ourselves into a moderation mess and are currently finding our way out of this situation.

Notice on Chocolatey.org
We’ve added a few things to Chocolatey.org (the community feed) to help speed up review times for package maintainers. A little over a year ago we introduced moderation for all new package versions (besides trusted packages) and from the user perspective it has been a fantastic addition. The usage has went up by over 20 million packages installed in one year versus just 5 million the 3 years before it! It’s been an overwhelming response for the user community. Let me say that again for effect: Chocolatey’s usage of community packages has increased 400% in one year over the prior three years combined!

But let’s be honest, we’ve nearly failed in another area. Keeping the moderation backlog low. We introduced moderation as a security measure for Chocolatey’s community feed because it was necessary, but we introduced it too early. We didn’t have the infrastructure automation in place to handle the sheer load of packages that were suddenly thrown at us. And once we put moderation in place, more folks wanted to use Chocolatey so it suddenly became much more popular. And because we have automation surrounding updating and pushing packages (namely automatic packages), we had some folks who would submit 50+ packages at a time. With one particular maintainer submitting 200 packages automatically, and a review of each of them taking somewhere between 2-10 minutes, you don’t have to be a detective to understand how this is going to become a consternation. And from the backlog you can see it really hasn’t worked out well.

1597 submitted

The most important number to understand here is the number in the submitted (underlined). This is the number of packages where a moderator has not yet looked at a package. A goal is to keep this well under 100. We want that time from a high quality package getting submitted to approved within 1-2 days.

Moderation has up until recently been a very manual process. Sometimes depending on which moderator that looked at your package determined whether it was going to be held in review for various reasons. We’ve added moderators and we’ve added more guidance around moderation to help bring a more structured review process. But it’s not enough.

Some of you may not know this, but our moderators are volunteers and we currently lack full-time employees to help fix many of the underlying issues. Even considering that we’ve also needed to work towards Kickstarter delivery and the Chocolatey rewrite (making choco better for the long term), it’s still not the greatest news to know that it has taken a long time to fix moderation, but hopefully it brings some understanding. Our goal is to eventually bring on full-time employees but we are not there yet. The Kickstarter was a start, but it was just that. A kick start. A few members of the core team who are also moderators have focused on ensuring the Kickstarter turns into a model that can ensure the longevity of Chocolatey. It may have felt that we have been ignoring the needs of the community, but that has not been our intention at all. It’s just been really busy and we needed to address multiple areas surrounding Chocolatey with a small number of volunteers.

So What Have We Fixed?

All moderation review communication is done on the package page. Now all review is done on the website, which means that there is no email back and forth (the older process) and what looks like one-sided communication on the site. This is a significant improvement.

Package review logging. Now you can see right from the discussion when and who submits package, when statuses change and where the conversation is.

package review logging

More moderators. A question that comes up quite a bit surrounds the number of moderators that we have and adding more. We have added more moderators. We are up to 12 moderators for the site. Moderators are chosen based on building trust, usually through being extremely familiar with Chocolatey packaging and what is expected of approved packages. Learning what is expected usually comes through having your own packages approved and having a few packages. We’ve written most of this up at https://github.com/chocolatey/choco/wiki/Moderation.

Maintainers can self-reject packages that no longer apply. Say your package has a download url for the software that is always the same. You have some older package versions that could take advantage of being purged out of the queue since they are no longer applicable.

The package validation service (the validator). The validator checks the quality of a package based on requirements, guidelines and suggestions for creating packages for Chocolatey’s community feed. Many of the validation items will automatically roll back into choco and will be displayed when packaging a package. We like to think of the validator as unit testing. It is validating that everything is as it should be and meets the minimum requirements for a package on the community feed.

validation results

The package verifier service (the verifier). The verifier checks the correctness (that the package actually works), that it installs and uninstalls correctly, has the right dependencies to ensure it is installed properly and can be installed silently. The verifier runs against both submitted packages and existing packages (checking every two weeks that a package can still install and sending notice when it fails). We like to think of the verifier as integration testing. It’s testing all the parts and ensuring everything is good. On the site, you can see the current status of a package based on a little colored ball next to the title. If the ball is green or red, the ball is a link to the results (only on the package page, not in the list screen).

passed verification - green colored ball with link

  • Green means good. The ball is a link to the results
  • Orange if still pending verification (has not yet run).
  • Red means it failed verification for some reason. The ball is a link to the results.
  • Grey means unknown or excluded from verification (if excluded, a reason will be listed on the package page).

Coming Soon – Moderators will be automatically be assigned to backlog items. Once a package passes both validation and verification, a moderator is automatically assigned to review the package. Once the backlog is in a manageable state, this will be added.

What About Maintainer Drift?

Many maintainers come in to help out at different times in their lives and they do it nearly always as volunteers. Sometimes it is the tools they are using at the current time and sometimes it has to do with where they work. Over time folks’ preferences/workplaces change and so maintainers drift away from keeping packages up to date because they have no internal incentive to continue to maintain those packages. It’s a natural human response. I’ve been thinking about ways to reduce maintainer drift for the last three years and I keep coming back to the idea that consumers of those packages could come along and provide a one time or weekly tip to the maintainer(s) as a thank you for keeping package(s) updated. We are talking to Gratipay now – https://github.com/gratipay/inside.gratipay.com/issues/441 This, in addition to a reputation system, I feel will go a long way to help reduce maintainer drift.

Final Thoughts

Package moderation review time is down to mere seconds as opposed to minutes like before. This will allow a moderator to review and approve package versions much more quickly and will reduce our backlog and keep it lower.

It’s already working! The number in the unreviewed backlog are down by 1,000 from the month prior. This is because a moderator doesn’t have to wait until a proper time when they can have a machine up and ready for testing and in the right state. Now packages can be reviewed faster. This is only with the verifier in place, sheerly testing package installs. The validator expects to cut that down to near seconds of review time. The total number of packages in the moderation backlog have also been reduced, but honestly I only usually pay attention to the unreviewed backlog number as it is the most important metric for me.

The verifier has rolled through over 6,500 verifications to date! https://gist.github.com/choco-bot/

When chocobot hit 6500 packages verified

We sincerely hope that the current maintainers who have been waiting weeks and months to get something reviewed can be understanding that we’ve dug ourselves into a moderation mess and are currently finding our way out of this situation. We may have some required findings and will ask for those things to be fixed, but for anything that doesn’t have required findings, we will approve them as we get to them.

Posted in chocolatey | 1 Comment

How To Avoid Common Windows Gotchas with Puppet

Originally published at http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet, reposted with permission and adjustments.

I’ve touched on Puppet before – Making Windows Awesome Since 2011Getting Started with Puppet on Windows and Managing Permissions with Access Control Lists.

I’m going to touch on the common things you can do, then show you how to avoid the common gotchas. Throughout the post, I’ll direct you to resources where you can dive in more deeply. When it comes to managing Puppet on Windows, a great resource is our Windows Documentation.

Common Windows Tasks You Can Automate With Puppet

Using Puppet, you can manage:

  • users /groups
  • files and folders
  • scheduled tasks (cron for Windows)
  • installation/upgrade/removal of software
  • permissions
  • windows features
  • management of services
  • IIS
  • management of databases
  • etc

The built-in types are listed on Windows Core Resource Types, along with specific examples. Much of the Windows ecosystem comes from several high-quality modules on the Puppet Forge that you can add in to Puppet to enhance your experience on Windows. Here are just a few specific modules:

There are of course many other modules for Windows, and I encourage you to explore the Forge.

As you can see, you can use Puppet to manage practically anything on Windows.

Common Windows Gotchas

We are always adding common gotchas and their resolutions to the Windows Troubleshooting page. Be sure to check that out if you don’t find what you are looking for here.

Puppet May Run as a 32-bit Application

Before Puppet 3.7.0, there was no 64-bit version of Puppet. This means you would be subject to File System Redirection and Registry Redirection from Windows because Puppet would run under 32-bit Ruby. The next two sections only apply if you are using a 32-bit version of Puppet on an x64 System.

File System Redirection (only when not using Puppet x64 on x64 systems)

Windows reserves the C:\Windows\System32 directory for 64-bit applications. In its great knowledge, Windows will redirect calls to System32 with SysWOW64, which contains the 32-bit equivalents of what is in the native system32 directory. Most of the time with Puppet, users actually want the physical system32 directory — the native system directory. In cases like these, what is wanted is to use the SysNative alias to bypass file system redirection.

To better understand what I mean about redirection, let’s take a simple manifest and execute it:

exec { 'powershell_system32':
  command => 'c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -NoProfile -ExecutionPolicy Bypass -Command "get-process powershell* | %{ Write-Host $($_.Path)}"',
  logoutput => true,
} ->
exec { 'powershell_sysnative':
  command => 'c:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -NoProfile -ExecutionPolicy Bypass -Command "get-process powershell* | %{ Write-Host $($_.Path)}"',
  logoutput => true,
}  

The output?

Notice: /Stage[main]/Main/Exec[powershell_system32]/returns: c:\windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
Notice: /Stage[main]/Main/Exec[powershell_sysnative]/returns: c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe


In this example, we are executing PowerShell and then looking at the path of any running powershell.exe processes (the same process we are running). We told the first exec (named powershell_system32) we wanted c:\windows\system32, but we got c:\windows\SysWOW64. This is how file system redirection works. If we want c:\windows\system32, we need to ask for c:\windows\sysnative, like we did with the second exec (powershell_sysnative).

For more information, see File System Redirection in 64-bit Windows Versions. You should also take a look at the MSDN reference for the File System Redirector.

NOTE: In the unlikely case where you are running Windows Server 2003 x64 (ONLY non-R2), you must apply the KB942589 hotfix to be able bypass file system redirection. And there is no x64 version of Ruby available for Windows Server 2003, so there is no x64 version of Puppet available either.

Registry Redirection (only when not using Puppet x64 on x64 systems)

In most cases, you will want to use the registry module, as it will provide you with the correct calls. In cases where you cannot, like when writing custom facts for Facter, you will want to do something similar to the following:

Facter.add(:myfact) do
  confine :kernel => :windows
  setcode do
    require 'win32/registry'

    value = nil
    hive = Win32::Registry::HKEY_CLASSES_ROOT
    hive.open('SOFTWARE\Somewhere\SomeValue',  Win32::Registry::KEY_READ | 0x100) do |reg|
      value = reg['SomeValue']
    end
    value
  end
end    

 

The addition of | 0x100 ensures the registry is opened without redirection so you can access the proper keys that you expect to access. For more information, see the MSDN Reference.

UAC (User Account Control) aka Security Context

UAC can bring you into some interesting places with Puppet. The Puppet agent (service) by default runs under an elevated LocalSystem account, which requests a certificate for the machine. If you run Puppet later from the command line in a non-elevated security context, it will attempt to request a second SSL certificate, which usually causes errors. See our documentation on security context.

Case Is Important

Most items on Windows are case-insensitive. Puppet, however, is not, especially when it comes to establishing relationships between resources in the manifests. See our documentation about case insensitivity.

File Paths

The general rule of thumb is to always use forward slash (/) except when specific Windows programs, like msiexec.exe, require backslashes in file paths. In those cases you should use the backslash (\) or a double backslash (\\) when the string is double quoted. The following paths are valid:

file { 'c:/path/to/file.txt': }
file { 'c:\path\to\file.txt': }
file { "c:\\path\\to\\file.txt": }

This is not a valid path due to double quoted single backslashes, which are interpreted as escape sequences:

file { "c:\path\to\file.txt": }

You will find more information here: http://docs.puppetlabs.com/windows/writing.html#file-paths-on-windows and http://docs.puppetlabs.com/windows/troubleshooting.html#path-separator.

Reboots

Yes, that’s the thing you have to do sometimes on Windows….it’s crazy, but it works. When you need to reboot, there’s a supported module for that. See Rebooting Windows with Puppet Enterprise.

Parting Thoughts

Now you’ve seen a few common gotchas to avoid and you’ve been introduced to some some stellar modules for enhancing the functionality of Puppet on Windows. Armed with this information, it is my hope that you:

  • Have a better understanding of Puppet and Windows
  • Run into fewer issues when you work with Puppet on Windows
  • Know where to find more Windows resources
Posted in howto, puppet | Tagged , | Comments Off on How To Avoid Common Windows Gotchas with Puppet

Puppet–Managing Permissions on Windows with Access Control Lists

acl type
Originally published at http://puppetlabs.com/blog/managing-permissions-windows-access-control-lists, reposted with permission and with adjustments. I wrote the original post and am also the author of the ACL module.

While there is a simple interface for setting permissions on Windows, managing and maintaining permissions has never been simple. Puppet has a module to make working with permissions almost enjoyable! You can work directly with ACLs (Access Control Lists) and to a degree, security descriptors, through the puppetlabs-acl module. The ACL module serves to make that process easy for you while satisfying your needs for very advanced permissions.

Let’s talk about a couple of real-world scenarios the ACL module can solve:

  • You need to set permissions appropriately for something like IIS/Apache.
  • You have a directory or file that you need to lock down to just admins.

These are very possible with the ACL module and just a few short lines of Puppet code. I’ll show you that in the Examples section below, but first let’s talk about ACLs and ACEs for those who want a refresher.

ACLs and ACEs, Oh My!

ACLs (also called Discretionary Access Control Lists) typically contain a list of access control entries (ACEs). An ACE is a defined trustee (identity) with a set of rights, and information about how those rights are passed to (and inherited by) child objects — for example, files and folders. For each ACE, the ACL contains an allowed/denied status, as well as the ACE’s propagation strategy. You cannot specify inherited ACEs in a manifest; you can only specify whether to allow upstream inheritance to flow into the managed target location (the location where you are applying the ACL).

ACL Features

Here are some features of Puppet’s ACL you should know:

  • Puppet can manage the complete set of ACEs or ensure that some Puppet-specified entries are present, while leaving existing entries alone.
  • You can lock down a path to only the specified permissions.
  • Identities can be users and/or groups, domain users/groups, and/or SIDs.
  • You can point multiple ACL resources at the same target path. Let me say that again in case there was confusion: You can point multiple ACL resources at the same path.
  • Propagation and inheritance of ACEs is set to Windows defaults, but can be specified per ACE.

Here’s what sets Puppet’s ACL module apart from other configuration management tools:

  • ACE order. The order of your ACEs matters. If they are incorrectly ordered, it can cause issues. So we apply ACEs in the order you’ve specified in the manifest. And we insert them in the correct location when merging with unmanaged ACEs.
  • SID (Security ID) support. We support specifying identities as SIDs.
  • Very, very granular permissions. Do you need to apply read attributes (RA)? Yes, we can do that.

Getting Started

Let’s take a look at what a typical ACL resource looks like:

acl { 'c:/temp':
  permissions => [
   { identity => 'Administrator', rights => ['full'] },
   { identity => 'Users', rights => ['read','execute'] }
  ],
}

If you were to run the above on a system that had the module installed, you would be giving the Administrator account full access to the temp folder, and giving the Users group access to read and execute (and list for folders). All the other options are set to Windows defaults, but if we need to get to them, we can. Let’s look at that same ACL resource with all the options specified:

acl { 'c:/temp':
  target      => 'c:/temp',
  target_type => 'file',
  purge       => 'false',
  permissions => [
   { identity => 'Administrator', rights => ['full'], type=> 'allow', child_types => 'all', affects => 'all' },
   { identity => 'Users', rights => ['read','execute'], type=> 'allow', child_types => 'all', affects => 'all' }
  ],
  owner       => 'Administrators',
  group       => 'Users',
  inherit_parent_permissions => 'true',
}

We have just specified the resource with all parameters and properties specified; what you are seeing is how the defaults line up. The only exception here are owner and group, which by default are not managed unless specified. The defaults for these depend on the user that created the target (the folder) and could be different based on who the user has as their default group and owner.

With both of the above examples we have done the following:

  • We’ve given Administrator full access to c:\temp.
  • We’ve given Users read/execute access to c:\temp.
  • We are by default not removing explicit unspecified permissions (purge => ‘false’).
  • We are by default inheriting the permissions from the parent folder (inherit_parent_permissions => ‘true’).
  • For each ACE, we are allowing the permission by default (type => ‘allow’).
  • For each ACE, we apply the permission to all child types by default, both folders and files (child_types => ‘all’).
  • For each ACE, we propagate the permission to self, direct children and all those further down by default (affects => ‘all’). Note that all types below child types are called grandchildren, no matter what the level of depth.

By default, if a user is not granted access through an ACE (whether individually or as a member of a group), then Windows will deny access. So if a user is not the Administrator account and not a member of the Users group, they will not have access to c:\temp. With the ACL module, this also means that access could be granted outside of Puppet (when purge => ‘false’) and/or it is an inherited ACE (when inherit_parent_permissions => ‘true’).

ACL Type Structure

Now let’s take a look at the ACL type and all it has to offer.

Parameters

The parameters are (bold means the parameter is required):

  • name – The name of the ACL resource, used as target if target is not set explicitly (see the target parameter).
  • purge – Determines whether unmanaged explicit access control entries should be removed. Combine purge => ‘true’, inherit_parent_permissions => ‘false’ to really lock down a folder. Supports true, false and listed_permissions. Defaults to false.
  • target – The location; defaults to the same value as name.
  • target_type – Currently supports only file; defaults to file.

Properties

The properties are (bold means the property is required):

owner – User/Group/SID that owns the ACL. If not specified, the provider will not manage this value.
group – User/Group/SID that has some level of access. If not specified, the provider will not manage this value. Group is not commonly used on Windows.
inherit_parent_permissions – Whether we inherit permissions from parent ACLs or not. Default is true.
permissions – The list of ACEs as an array. This should be in the order you want them applied. We cover permissions in more detail below.

Permissions Property

The permissions property could be considered the most important part of the ACL resource, because it contains each ACE in the order specified for the ACL. The available elements for each ACE hash are identity, rights, type, child_types, affects, and mask.

The elements are (bold means the key is required):

  • identity – This is the user/group/SID.
  • rights – An array with the following values: full, modify, mask_specific, write, read, and execute. The full, modify, and mask_specific values are mutually exclusive, and when any of these values are used, they must be the only value specified in rights. The full value indicates all rights. The modify value is cumulative, implying write, read, execute and DELETE all in one. If you specify mask_specific, you must also specify the mask element in the permissions hash. The write, read, and execute values can be combined however you want.
  • type – Whether to allow or deny the access. Defaults to allow.
  • child_types – Which types of children are allowed to inherit this permission, whether objects, containers, all or none. Defaults to all.
  • affects – How inheritance is propagated. Valid values are all, self_only, children_only, self_and_direct_children_only, or direct_children_only. Defaults to all.
  • mask – An integer representing access mask, passed as a string. Mask should be used only when paired with rights => [‘mask_specific’]. For more information on mask, see the granular permissions example below.

For more specific details and up-to-date information on the ACL type, see the usage documentation.

Examples

In the following examples we are going to show you how to lock down a folder, set appropriate permissions for a website, and set very granular permissions.

Locking down a folder for sensitive data

Here’s what you need to do when you keep sensitive data in a specific folder, and need to limit access to administrators only.

acl { 'c:/sensitive_data':
  purge                       => true,
  inherit_parent_permissions  => false,
  permissions => [
   { identity => 'Administrators', rights => ['full'] }
  ],
}

We’ve done the following:

  • Since permissions are inherited from parent ACLs by default, we set inherit_parent_permissions => false so no permissions are inherited from the parent ACL.
  • ACLs will also allow unmanaged ACEs to coexist with Puppet-managed permissions, so we need to specify purge => true to ensure that all permissions other than those we have specified are removed.
  • We’ve given the Administrators group full permission to the directory.
  • If an ACE has not granted permission for a user, Windows will by default deny access. So in this case, only users that are part of the Administrators group will be able to access this folder.

That was pretty simple! And very self-documenting as well. It’s worth mentioning that one goal of Puppet is for anyone to be able to read and understand the intent of the code, and the ACL module does not disappoint. Now let’s try something a little more involved.

Website setup with ACLs

Let’s take a look at setting up an IIS site and locking down permissions.

$website_location = 'C:\sites\thestuff'
$website_name = 'the.stuff'
$website_port = '80'

# add windows features
windowsfeature { 'Web-WebServer':
  installmanagementtools => true,
} ->
windowsfeature { 'Web-Asp-Net45':
} ->

# remove default web site
iis::manage_site { 'Default Web Site':
  ensure        => absent,
  site_path     => 'any',
  app_pool      => 'DefaultAppPool',
} ->

# application in iis
iis::manage_app_pool { "${website_name}":
  enable_32_bit           => true,
  managed_runtime_version => 'v4.0',
} ->
iis::manage_site { "${website_name}":
  site_path     => $website_location,
  port          => "${website_port}",
  ip_address    => '*',
  app_pool      => "${website_name}",
} ->

# lock down web directory
acl { "${website_location}":
  purge                       => true,
  inherit_parent_permissions  => false,
  permissions => [
   { identity => 'Administrators', rights => ['full'] },
   { identity => 'IIS_IUSRS', rights => ['read'] },
   { identity => 'IUSR', rights => ['read'] },
   { identity => "IIS APPPOOL\\${website_name}", rights => ['read'] }
  ],
} ->
acl { "${website_location}/App_Data":
  permissions => [
   { identity => "IIS APPPOOL\\${website_name}", rights => ['modify'] },
   { identity => 'IIS_IUSRS', rights => ['modify'] }
  ],
}

The script above does the following:

  1. Ensures IIS is installed and ASP.NET is set up.
  2. Ensures the default web site is removed.
  3. Ensures our site is set up correctly.
  4. Uses ACL to ensure IIS users have read access.
  5. Uses ACL to ensure the processes that run the website can modify the App_Data directory.

All of that, done in just a few lines of code! You can add more for getting the files there in the first place, using Puppet, but I have left that as an exercise for the reader :)

Granular Permissions

In our last example, let’s get into very granular permissions.

acl { 'c:/granular_permissions':
  permissions => [
   { identity => 'Administrators', rights => ['full'] },
   { identity => 'Bob', rights => ['mask_specific'], mask => '1507839' }
  ],
}

We’ve done the following:

So you see 1507839 and it looks like a magic number. How does one arrive at this number? I wrote a blog post on this once that shows you how to add up the numbers. Now we have a much simpler way to add those permissions: We have created and made available a worksheet to add up the ACL rights mask! This will allow you to add up the rights and will give you a heads up if you should use named rights from the module (like read or execute or a combination of read, execute).

ACL Module: You’re gonna love my permissions!

ACLs on Windows give you a lot of control over permissions. The ACL module harnesses that ability and makes it easy — even fun — to control permissions on Windows. While the ACL module makes it easy to get started, it allows advanced users to manage permissions in granular detail. And did I mention it’s a supported module? That means you get the same support for this module that you get with a Puppet Enterprise license. Give the ACL module a look today — if you manage permissions on Windows, I’m pretty sure you are going to love it!

References

Posted in howto, puppet | Tagged | 1 Comment

How Passion Saved Windows

“Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.” – Howard H. Aiken

Look around today. There is so much that you can do on Windows with respect to automation that just wasn’t possible a few short years ago. It’s hard to see what has changed because our memories are sometimes so short about how it used to be, so let’s go back about 4 years ago to 2010. PowerShell was still young, there was no Chocolatey, and things like Puppet and Chef didn’t work on Windows yet.

Folks were leaving Windows left and right once they got a taste of how easy automation was in other OS platforms. Well versed folks. Loud folks. Folks that were at the top of their game heading out of Windows. Many others have considered it. You’ve all heard the “leaving .NET stories” from some of the best developers on the .NET platform. But what you may not have realized is that these folks were not just leaving .NET, they were leaving Windows entirely. Some of this was in part to limitations they were finding that just were not there in other OSes. What you are also missing are all the folks that were silently leaving. For every one person speaking out about it, there were many more of the silent losses. The system admins, fed up with GUIs and lack of automation, leaving for greener pastures. The developers who didn’t blog leaving the platform.

But a change has occurred more recently that has slowed that process. I believe it is better tools and automation of the Windows platform. Some people have shown such a passion that they’ve saved Windows as a platform for future generations.

So What Saved Windows?

PowerShellPowerShell – Arguably this could be seen as the catalyst that started it all. It came out in 2006 and while v1 was somewhat limited, v2 (Oct 2009) added huge improvements, including performance. PowerShell is prevalent now, but it had humble beginnings. When Jeffrey Snover saw a need for better automation in Windows, no one understood what he was trying to do. Most folks at Microsoft kept asking, why do you need that? But Jeffrey had such a passion for what was needed that he took a demotion to make it happen. And we are thankful for that because it shaped the face of Windows automation for all. Jeffrey’s passion brought us PowerShell, and it is continuing to bring us more things that have come out of his original Monad Manifesto from 2002.

ChocolateyChocolatey – In 2011 Chocolatey furthered the automation story of Windows with package management, something that other platforms have enjoyed for years. Rob Reynolds’ goals for Chocolatey in the beginning were simply to solve a need but it has since grown into so much more and is now making improvements to become a true package manager. It wasn’t the first approach to package management on Windows and it is certainly not the last. But it did many things right, it didn’t try to achieve lofty goals. It started working at the point of the native installers and official distribution points with a simple approach to packaging and very good helpers to achieve many abilities. When Rob first started working on it, most of his longtime technical friends questioned the relevance of it. Rob did not stop because he had a vision, a passion for making things happen. As his vision has been realized by many he is about to change the face of package management on Windows forever.

Puppet LabsPuppet (and other CM tools) – In 2011 Puppet started working on Windows thanks to Josh Cooper. He single-handedly brought Puppet’s excellent desired state configuration management to Windows (Chef also brought Windows support in 2011). Josh saw a need and convinced folks to try an experiment. That experiment has grown and has brought the last bits of what was needed to save Windows as a platform. His passion for bringing Puppet to Windows has grown into so much more than what it originally started out to do. While most CM tools are good, I’m biased and believe Puppet is arguably the best CM tool for any platform, as the Puppet Labs CEO stated at PuppetConf 2014, Puppet is becoming the lingua franca of infrastructure configuration.

The Effects of Passion

All of this passion for automation has really changed Microsoft. They have adopted automation as a strategy. They are moving to a model of openness, recently announcing that the entire .NET platform is going to be Open Source. They are getting behind Chocolatey with OneGet and getting it built into Windows. They announced PowerShell DSC last year and have made huge improvements in it since then. From where we are sitting, it appears Microsoft now gets it. The effects of passion have really turned the company around and has saved Windows. Windows is becoming the platform we all hoped it would be, it’s really bringing many folks to see it as a true platform for automation and that makes Windows a formidable platform for the foreseeable future.

Posted in chocolatey, puppet | Tagged , | 2 Comments

Herding Code On Chocolatey

Recently I talked to Herding Code about the kickstarter, package moderation, OneGet, and where we are going with Chocolatey.

Listen now – http://herdingcode.com/herding-code-199-rob-reynolds-on-the-chocolatey-kickstarter-chocolatey-growth-and-oneget/

Posted in chocolatey | Tagged , | Comments Off on Herding Code On Chocolatey