{"id":13906119,"url":"https://github.com/chef/knife-windows","last_synced_at":"2025-06-25T22:32:44.721Z","repository":{"id":422251,"uuid":"1440272","full_name":"chef/knife-windows","owner":"chef","description":"Plugin for Chef's knife tool for working with Windows nodes","archived":false,"fork":false,"pushed_at":"2024-08-12T15:33:50.000Z","size":1272,"stargazers_count":152,"open_issues_count":13,"forks_count":110,"subscribers_count":93,"default_branch":"main","last_synced_at":"2024-11-17T14:55:03.907Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/chef.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2011-03-04T17:30:51.000Z","updated_at":"2024-08-12T15:33:54.000Z","dependencies_parsed_at":"2024-07-22T11:58:12.032Z","dependency_job_id":"5b00993a-e936-43d3-9568-4ee5d33ae668","html_url":"https://github.com/chef/knife-windows","commit_stats":{"total_commits":838,"total_committers":83,"mean_commits":"10.096385542168674","dds":0.9128878281622912,"last_synced_commit":"9a33610e89b29ca04ebf2fa88c718c5f67d92675"},"previous_names":["opscode/knife-windows"],"tags_count":96,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chef%2Fknife-windows","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chef%2Fknife-windows/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chef%2Fknife-windows/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chef%2Fknife-windows/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/chef","download_url":"https://codeload.github.com/chef/knife-windows/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":226344525,"owners_count":17610154,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-06T23:01:29.750Z","updated_at":"2024-11-25T14:30:53.934Z","avatar_url":"https://github.com/chef.png","language":"Ruby","funding_links":[],"categories":["Ruby"],"sub_categories":[],"readme":"Knife Windows Plugin\n====================\n[![Build status](https://badge.buildkite.com/2e8cc60e947d9ce9e846ec6ef644717cce3ae7a40d6903c3b0.svg?branch=master)](https://buildkite.com/chef-oss/chef-knife-windows-master-verify)\n[![Gem Version](https://badge.fury.io/rb/knife-windows.svg)](https://badge.fury.io/rb/knife-windows)\n\n**Umbrella Project**: [Knife](https://github.com/chef/chef-oss-practices/blob/master/projects/knife.md)\n\n**Project State**: [Active](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md#active)\n\n**Issues [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md)**: 14 days\n\n**Pull Request [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md)**: 14 days\n\nThis plugin adds additional functionality to the Chef Knife CLI tool for\nconfiguring / interacting with nodes running Microsoft Windows:\n\n* Remote command execution using the WinRM protocol\n* Utilities to configure WinRM SSL endpoints on managed nodes\n\n## **Knife bootstrap windows ssh/winrm**\n\nCore Chef now supports bootstrapping Windows systems without a knife plugin\n\n|  knife-windows plugin | Chef Infra Client 15+ | Notes |\n|-----:|:-----------|:-----------|\n| knife windows bootstrap ssh | knife bootstrap -o ssh or knife bootstrap | Default is 'ssh'|\n| knife windows bootstrap winrm | knife bootstrap -o winrm|\n\nFor more detail https://github.com/chef/chef/blob/master/RELEASE_NOTES.md#knife-bootstrap\n\n## Subcommands\n\nThis plugin provides the following Knife subcommands. Specific command options can be found by invoking the subcommand with a `--help` flag\n\n### knife winrm\n\nThe `winrm` subcommand allows you to invoke commands in parallel on a subset of the nodes in your infrastructure. The `winrm` subcommand uses the same syntax as the [search subcommand](https://docs.chef.io/knife_search.html); you could find the uptime of all your web servers using the command:\n\n    knife winrm \"role:web\" \"net stats srv\" -x Administrator -P 'super_secret_password'\n\n_Please note that to run a single command against multiple nodes, each node must share the same username and password._\n\nOr force a chef run:\n\n    knife winrm \"myserver.myorganization.net\" \"chef-client -c c:/chef/client.rb\" -m -x Administrator -P \"super_secret_password\"\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:49 +0000] INFO: Starting Chef Run (Version 0.9.12)\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:50 +0000] WARN: Node ip-0A502FFB has an empty run list.\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:53 +0000] INFO: Chef Run complete in 4.383966 seconds\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:53 +0000] INFO: cleaning the checksum cache\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:53 +0000] INFO: Running report handlers\n    myserver.myorganization.net [Fri, 04 Mar 2011 22:00:53 +0000] INFO: Report handlers complete\n\nThis subcommand operates in a manner similar to [knife ssh](https://docs.chef.io/knife_ssh.html)...just leveraging the WinRM protocol for communication. It also includes `knife ssh`'s \"[interactive session mode](https://docs.chef.io/knife_ssh.html#options)\"\n\n#### winrm-shell\n\nBy default, `knife winrm` runs in a `cmd.exe` shell. You can use the `--winrm-shell` argument to change the shell to `powershell` or `elevated`. An elevated shell is similar to the `powershell` shell but the powershell command is executed from a scheduled task using a local identity. This may be desirable for some operations such as running `chef-client` to converge recipes that work with windows updates, install sql server, etc.\n\n#### Tip: Use SSL for WinRM communication\n\nBy default, the `knife winrm` subcommands use a plaintext transport,\nbut they support an option `--winrm-transport` (or `-t`) with the argument\n`ssl` that allows the SSL to secure the WinRM payload. Here's an example:\n\n    knife winrm -t ssl \"role:web\" \"net stats srv\" -x Administrator -P \"super_secret_password\" -f ~/server_public_cert.crt\n\nUse of SSL is strongly recommended, particularly when invoking `knife-windows` on non-Windows platforms, since\nwithout SSL there are limited options for ensuring the privacy of the\nplaintext transport. See the section on [Platform authentication\nsupport](#platform-winrm-authentication-support).\n\nSSL will become the default transport in future revisions of\n`knife-windows`.\n\n### knife wsman test\n\nConnects to the remote WSMan/WinRM endpoint and verifies the remote node is listening.  This is the equivalent of running Test-Wsman from PowerShell.  Endpoints to test can be specified manually, or be driven by search and use many of the same connection options as knife winrm.\nTo test a single node using the default WinRM port (5985)\n\n    knife wsman test 192.168.1.10 -m\n\nor to test a single node with SSL enabled on the default port (5986)\n\n    knife wsman test 192.168.1.10 -m --winrm-transport ssl\n\nor to test all windows nodes registered with your Chef Server organization\n\n    knife wsman test platform:windows\n\n### knife windows cert generate\n\nGenerates a certificate(x509) containing a public / private key pair for WinRM 'SSL' communication.\nThe certificate will be generated in three different formats:\n* **.pem** - The *.pem is Base64 encoded public certificate only. One can use this file with the `-f` argument on `knife winrm` command.\n* **.pfx** - The PKCS12(i.e .pfx) contains both the public and private keys, usually used on the server. This can be added to a WinRM Server's Certificate Store using `knife windows cert install` (see command description below). **Note:** Do not use the *.pfx file with the `-f` argument on the `knife winrm` command. Use the *.pem file instead.\n* **.b64** - The *.b64 is Base64 PKCS12 key pair. Contains both the public and private keys, for upload to the Cloud REST API. e.g. Azure.\n\nThis command also displays the thumbprint of the generated certificate.\n\n    knife windows cert generate --cert-passphrase \"strong_passphrase\" --hostname \"myserver.myorganization.net\" --output-file \"~/server_cert.pfx\"\n    # This command will generate certificates in the user's home directory with names server_cert.b64, server_cert.pfx and server_cert.pem.\n\n### knife windows cert install\n\nThis command only functions on Windows and is intended to be run on a chef node. It adds the specified certificate to its certificate store. This command must include a valid PKCS12(i.e *.pfx) certificate file path such as the *.pfx file generated by `knife windows cert generate` described above.\n\n    knife windows cert install \"~/server_cert.pfx\" --cert-passphrase \"strong_passphrase\"\n\n### knife windows listener create\nThis command only functions on Windows and is intended to be run on a chef node. It creates the winrm listener for SSL communication(i.e HTTPS).\nThis command can also install certificate which is specified using --cert-install option and use the installed certificate thumbprint to create winrm listener.\n--hostname option is optional. Default value for hostname is *.\n\n    knife windows listener create --cert-passphrase \"strong_passphrase\" --hostname \"myserver.mydomain.net\" --cert-install \"~/server_cert.pfx\"\n\nThe command also allows you to use existing certificates from local store to create winrm listener. Use --cert-thumbprint option to specify the certificate thumbprint.\n\n    knife windows listener create --cert-passphrase \"strong_passphrase\" --hostname \"myserver.mydomain.net\" --cert-thumbprint \"bf0fef0bb41be40ceb66a3b38813ca489fe99746\"\n\nYou can get the thumbprint for existing certificates in the local store using the following PowerShell command:\n\n    ls cert:\\LocalMachine\\My\n\n## Requirements / setup\n\n### Ruby\n\nRuby 1.9.3+ is required.\n\n### Chef version\n\nThis knife plugins requires \u003e= Chef 11.0.0. More details about Knife plugins can be\n[found in the Chef documentation](https://docs.chef.io/plugin_knife.html).\n\n## Nodes\n\n### WinRM versions\n\nThe node must be running Windows Remote Management (WinRM) 2.0+. WinRM\nallows you to call native objects in Windows. This includes, but is not\nlimited to, running PowerShell scripts, batch scripts, and fetching WMI\ndata. For more information on WinRM, please visit\n[Microsoft's WinRM site](http://msdn.microsoft.com/en-us/library/aa384426\\(v=VS.85\\).aspx).\n\nWinRM is built into Windows 7 and Windows Server 2008+. It can also [be installed](https://support.microsoft.com/en-us/kb/968929) on older version of Windows, including:\n\n* Windows Server 2003\n* Windows Vista\n\n### WinRM configuration\n\n**NOTE**: Before any WinRM related knife subcommands will function\n  a node's WinRM installation must be configured correctly.\n  The settings below must be added to your base server image or passed\n  in using some sort of user-data mechanism provided by your cloud\n  provider. Some cloud providers will set up the required WinRM\n  configuration through the cloud API for creating instances -- see\n  the documentation for the provider.\n\nA server running WinRM must also be configured properly to allow\noutside connections for the entire network path from the knife workstation to the server. The easiest way to accomplish this is to use [WinRM's quick configuration option](http://msdn.microsoft.com/en-us/library/aa384372\\(v=vs.85\\).aspx#quick_default_configuration):\n\n    winrm quickconfig -q\n\nThis will set up an WinRM listener using the HTTP (plaintext)\ntransport -- WinRM also supports the SSL transport for improved\nrobustness against information disclosure and other threats.\n\nThe chef-client installation may take more\nmemory than the default 150MB WinRM allocates per shell on older versions of\nWindows (prior to Windows Server 2012) -- this can slow it down\nor cause it to fail. The memory limit was increased to 1GB with Windows Management Framework 3\n(and Server 2012). However, there is a bug in Windows Management Framework 3\n(and Server 2012) which requires a [hotfix from Microsoft](https://support.microsoft.com/en-us/kb/2842230/en-us).\nYou can increase the memory limit to 1GB with the following PowerShell\ncommand:\n\n```powershell\n    set-item wsman:\\localhost\\shell\\maxmemorypershellmb 1024\n```\n\nCommands can take longer than the WinRM default 60 seconds to\ncomplete, optionally increase to 30 minutes if terminates a command prematurely:\n\n```powershell\n    set-item wsman:\\localhost\\MaxTimeoutms 300000\n```\n\nNote that the `winrm` command itself supports the same configuration\ncapabilities as the PowerShell commands given above -- if you need to\nconfigure WinRM without using PowerShell, use `winrm -?` to get help.\n\nWinRM supports both the HTTP and HTTPS (SSL) transports and the following\nauthentication schemes: Kerberos, Digest, Certificate and Basic. The details\nof these authentication transports are outside of the scope of this\nREADME but details can be found on the\n[WinRM configuration guide](http://msdn.microsoft.com/en-us/library/aa384372\\(v=vs.85\\).aspx).\n\n### Working with legacy Windows versions\n\nIf you are attempting to use `knife winrm` with a version of windows that is older than server 2008 R2 or older than Windows 7 then you may need to alter the default UTF-8 codepage (65001) using the `--winrm-codepage` argument. You can use the codepage native to your locale but `437` is a safe codepage for older Windows versions.\n\n#### Configure SSL on a Windows node\n\nWinRM supports use of SSL to provide privacy and integrity of\ncommunication using the protocol and to prevent spoofing attacks.\n\n##### Configure SSL using `knife`\n\n`knife-windows` includes three commands to assist with SSL\nconfiguration -- these commands support all versions of Windows and do\nnot rely on PowerShell:\n\n* `knife windows cert generate`: creates a certificate that may be used\n  to configure an SSL WinRM listener\n\n* `knife windows cert install`: Installs a certificate into the\n  Windows certificate store so it can be used to configure an SSL\n  WinRM listener.\n\n* `knife windows listener create`: Creates a WinRM listener on a\n  Windows node -- it can use either a certificate already installed in\n  the Windows certificate store, or one created by other tools\n  including the `knife windows cert generate` command.\n\nHere is an example that configures a listener on the node on which the\ncommands are executed:\n\n    knife windows cert generate --domain myorg.org --output-file $env:userprofile/winrmcerts/winrm-ssl\n    knife windows listener create --hostname *.myorg.org --cert-install $env:userprofile/winrmcerts/winrm-ssl.pfx\n\nNote that the first command which generates the certificate for the\nlistener could be executed from any system that can run `knife` as\nlong as the certificate it generates is made available at a path at\nwhich the second command can access it.\n\nSee previous sections for additional details of the `windows cert generate`, `windows cert install` and `windows listener create` subcommands.\n\n##### Configure SSL using *Windows Server 2012 or later*\nThe following PowerShell commands may be used to create an SSL WinRM\nlistener with a self-signed certificate on Windows 2012R2 or later systems:\n\n```powershell\n$cert = New-SelfSignedCertificate -DnsName 'myserver.mydomain.org' -CertStoreLocation Cert:\\LocalMachine\\My\nnew-item -address * -force -path wsman:\\localhost\\listener -port 5986 -hostname ($cert.subject -split '=')[1] -transport https -certificatethumbprint $cert.Thumbprint\n# Open the firewall for 5986, the default WinRM SSL port\nnetsh advfirewall firewall set rule name=\"Windows Remote Management (HTTPS-In)\" profile=public protocol=tcp localport=5986 remoteip=localsubnet new remoteip=any\n\n```\n\nNote that the first command which uses the `New-SelfSignedCertificate`\ncmdlet is available only in PowerShell version 4.0 and later.\n\n##### Configure SSL using `winrm quickconfig`\n\nThe following command can configure an SSL WinRM listener if the\nWindows certificate store's Local Machine store contains a certificate\nthat meets certain criteria that are most likely to be met if the\nsystem is joined to a Windows Active Directory domain:\n\n    winrm quickconfig -transport:https -q\n\nIf the criteria are not met, an error message will follow with\nguidance on the certificate requirements; you may need to obtain a\ncertificate from the appropriate source or use the PowerShell or\n`knife` techniques given above to create the listener instead.\n\n##### Disabling peer verification\nIn the SSL examples above, the `-f` parameter was used to supply a\ncertificate that could validate the identity of the remote server.\nFor debugging purposes, this validation may be skipped if you have not\nobtained a public certificate that can validate the server. Here is an\nexample:\n\n    knife winrm -m 192.168.0.6 -x \"mydomain\\myuser\" -P $PASSWD -t ssl --winrm-ssl-verify-mode verify_none ipconfig\n\nThis option should be used carefully since disabling the verification of the\nremote system's certificate can subject knife commands to spoofing attacks.\n\n##### Connecting securely to self-signed certs\nIf you generate a self-signed cert, the fqdn and ip may not match which will result in a certificate validation failure. In order to securely connect and reduce the risk of a \"Man In The Middle\" attack, you may use the certificate's fingerprint to precisely identify the known certificate on the WinRM endpoint.\n\nThe fingerprint can be supplied to ```--ssl-peer-fingerprint``` and instead of using a certificate chain and comparing the CommonName, it will only verify that the fingerprint matches:\n\n    knife winrm --ssl-peer-fingerprint 89255929FB4B5E1BFABF7E7F01AFAFC5E7003C3F \\\n\t\t      -m $IP -x Administrator -P $PASSWD-t ssl --winrm-port 5986 hostname\n\t\t10.113.4.54 ip-0A710436\n\n## WinRM authentication\n\nThe default authentication protocol for `knife-windows` subcommands that use\nWinRM is the Negotiate protocol. The following commands show authentication for domain and local accounts respectively:\n\n    knife winrm -m web1.cloudapp.net -x \"proddomain\\webuser\" -P \"super_secret_password\"\n    knife winrm -m db1.cloudapp.net -x \"localadmin\" -P \"super_secret_password\"\n\nThe remote system may also be configured with an SSL WinRM listener instead of a\nplaintext listener. Then the above commands should be modified to use the SSL\ntransport as follows using the `-t` (or `--winrm-transport`) option with the\n`ssl` argument:\n\n    knife winrm -m web1.cloudapp.net -t ssl -x \"proddomain\\webuser\" -P \"super_secret_password\" -f ~/mycert.crt\n    knife winrm -m db1.cloudapp.net -t ssl -x \"localadmin\" -P \"super_secret_password\" ~/mycert.crt\n\n### Troubleshooting authentication\n\nUnencrypted traffic with Basic authentication should only be used for low level wire protocol debugging. The configuration for plain text connectivity to\nthe remote system may be accomplished with the following PowerShell commands:\n\n```powershell\nset-item wsman:\\localhost\\service\\allowunencrypted $true\nset-item wsman:\\localhost\\service\\auth\\basic $true\n```\nTo use basic authentication connectivity via `knife-windows`, the default\nauthentication protocol of Negotiate must be overridden using the\n`--winrm-authentication-protocol` option with the desired protocol, in this\ncase Basic:\n\n    knife winrm -m web1.cloudapp.net --winrm-authentication-protocol basic ipconfig -x localadmin -P \"super_secret_password\"\n\nNote that when using Basic authentication, domain accounts may not be used for\nauthentication; an account local to the remote system must be used.\n\n### Platform WinRM authentication support\n\n`knife-windows` supports `Kerberos`, `Negotiate`, and `Basic` authentication\nfor WinRM communication.\n\nThe following table shows the authentication protocols that can be used with\n`knife-windows` depending on whether the knife workstation is a Windows\nsystem, the transport, and whether or not the target user is a domain user or\nlocal to the target Windows system.\n\n\u003e \\* There is a known defect in the `knife winrm`\n\u003e winrm` subcommands invoked on any OS  platform when authenticating with the Negotiate protocol over\n\u003e the SSL transport. The defect is tracked by\n\u003e [knife-windows issue #176](https://github.com/chef/knife-windows/issues/176): If the remote system is\n\u003e domain-joined, local accounts may not be used to authenticate via Negotiate\n\u003e over SSL -- only domain accounts will work. Local accounts will only\n\u003e successfully authenticate if the system is not joined to a domain.\n\u003e\n\u003e This is generally not an issue for bootstrap scenarios, where the\n\u003e system has yet to be joined to any domain, but can be a problem for remote\n\u003e management cases after the system is domain joined. Workarounds include using\n\u003e a domain account instead or bypassing SSL and using Negotiate authentication.\n\n## General troubleshooting\n\n* Windows 2008R2 and earlier versions require an extra configuration\n  for MaxTimeoutms to avoid WinRM::WinRMHTTPTransportError: Bad HTTP\n  response error while bootstrapping. It should be at least 300000.\n\n  `set-item wsman:\\\\localhost\\\\MaxTimeoutms 300000`\n\n* When I run the winrm command I get: \"Error: Invalid use of command line. Type \"winrm -?\" for help.\"\n  You're running the winrm command from PowerShell and you need to put the key/value pair in single quotes. For example:\n\n   `winrm set winrm/config/winrs '@{MaxMemoryPerShellMB=\"1024\"}'`\n\n* If you receive a timeout when trying to connect to your instance for the first time, make sure your Firewall setting\n  is permissive enough.\n\n   `netsh advfirewall firewall set rule name=\"Windows Remote Management (HTTP-In)\" profile=public protocol=tcp localport=5985 remoteip=localsubnet new remoteip=any`\n\n### AWS User Data\n\nIf you are spinning up AWS instances to test against, you can use the following user data when spinning up your instances:\n\n```\n\u003cpowershell\u003e\n$logfile=\"C:\\\\Program Files\\\\Amazon\\\\Ec2ConfigService\\\\Logs\\\\kitchen-ec2.log\"\n# Allow script execution\nSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force\n# PS Remoting and \u0026 winrm.cmd basic config\nEnable-PSRemoting -Force -SkipNetworkProfileCheck\n\u0026 winrm.cmd set winrm/config '@{MaxTimeoutms=\"1800000\"}' \u003e\u003e $logfile\n\u0026 winrm.cmd set winrm/config/winrs '@{MaxMemoryPerShellMB=\"1024\"}' \u003e\u003e $logfile\n\u0026 winrm.cmd set winrm/config/winrs '@{MaxShellsPerUser=\"50\"}' \u003e\u003e $logfile\n#Server settings - support username/password login\n\u0026 winrm.cmd set winrm/config/winrs '@{MaxMemoryPerShellMB=\"1024\"}' \u003e\u003e $logfile\n# Firewall Config\n\u0026 netsh advfirewall firewall set rule name=\"Windows Remote Management (HTTP-In)\" profile=public protocol=tcp localport=5985 remoteip=localsubnet new remoteip=any  \u003e\u003e $logfile\n\u003c/powershell\u003e\n```\n\n## CONTRIBUTING:\n\nPlease file bugs against the KNIFE_WINDOWS project at https://github.com/chef/knife-windows/issues.\n\nMore information on the contribution process for Chef projects can be found in the [Chef Contributions document](http://docs.chef.io/community_contributions.html).\n\n# LICENSE:\n\nAuthor:: Seth Chisamore (\u003cschisamo@chef.io\u003e)\nCopyright:: Copyright (c) 2015-2016 Chef Software, Inc.\nLicense:: Apache License, Version 2.0\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchef%2Fknife-windows","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fchef%2Fknife-windows","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchef%2Fknife-windows/lists"}