Meta's Client Platform Engineering tools. Some of the tools we have written to help manage our fleet of client systems.
License: Apache License 2.0
The CPE ("Client Platform Engineering") repo contains a suite of Chef cookbooks used to manage Facebook's client fleet.
We aim for compatibility with the latest public releases of the operating systems we manage.
Old IT-CPE tools are BSD-licensed with an additional patent grant; see LICENSE
and PATENTS.
New Chef cookbooks in the itchef directory are under the Apache 2.0 license.
cpe_chrome fails in exciting ways when you try to manage a key that isn't in ENUM_REG_KEYS. The error it throws is confusing and doesn't reflect that actual issue.
Because a key is used that it doesn't exist, it dumps all the cpe_chrome attributes somehow. As a result, it fails on line 53 when it tries to run .keys on the attributes, which no long exist because it wasn't expecting that key. (This is my working hypothesis, but not 100% sure).
14.12.9
Windows 10
Try managing the new key ExternalProtocolDialogShowAlwaysOpenCheckbox
NoMethodError: cpe_chrome[Configure Google Chrome] (cpe_chrome::default line 15) had an error: NoMethodError: undefined method `keys' for nil:NilClass
Since munki/munki#837 was merged it might be nice to add optional_installs support into cpe_munki. The following diff works for me.
A) would the fb team accept the PR?
B) should we wait until an official release of munki before merging into cpe_munki?
diff --git a/cookbooks/cpe_munki/attributes/default.rb b/cookbooks/cpe_munki/attributes/default.rb
index c2a2b35..dc43010 100644
--- a/cookbooks/cpe_munki/attributes/default.rb
+++ b/cookbooks/cpe_munki/attributes/default.rb
@@ -19,6 +19,7 @@ default['cpe_munki'] = {
default['cpe_munki']['local'] = {
'managed_installs' => [],
'managed_uninstalls' => [],
+ 'optional_installs' => [],
}
default['cpe_munki']['preferences'] = {
'AppleSoftwareUpdatesOnly' => false,
diff --git a/cookbooks/cpe_munki/resources/cpe_munki_local.rb b/cookbooks/cpe_munki/resources/cpe_munki_local.rb
index bb46ee8..507a135 100644
--- a/cookbooks/cpe_munki/resources/cpe_munki_local.rb
+++ b/cookbooks/cpe_munki/resources/cpe_munki_local.rb
@@ -20,7 +20,8 @@ default_action :run
action :run do
locals_exist = node['cpe_munki']['local']['managed_installs'].any? ||
- node['cpe_munki']['local']['managed_uninstalls'].any?
+ node['cpe_munki']['local']['managed_uninstalls'].any? ||
+ node['cpe_munki']['local']['optional_installs'].any?
return unless locals_exist
return unless ::File.exist?('/usr/local/munki/managedsoftwareupdate')
@@ -71,9 +72,13 @@ def gen_plist
uninstalls = validate_install_array(
node['cpe_munki']['local']['managed_uninstalls'],
)
+ optional = validate_install_array(
+ node['cpe_munki']['local']['optional_installs'],
+ )
plist_hash = {
'managed_installs' => installs,
'managed_uninstalls' => uninstalls,
+ 'optional_installs' => optional,
}
::Chef::Log.info("cpe_munki_local: Managed installs: #{installs}")
Plist::Emit.dump(plist_hash) unless plist_hash.nil?
diff --git a/cookbooks/cpe_user_customizations/recipes/clayton.burlison.rb b/cookbooks/cpe_user_customizations/recipes/clayton.burlison.rb
index 2ab8a19..c41ec2d 100644When running cpe_remote I noticed this warning today:
* cpe_remote_pkg[foo] action installnil versions are discouraged and will be deprecated in Rubygems 4
Chef 16.2.73
macOS 10.15.6
Install a new package with cpe_remote_pkg
* cpe_remote_pkg[foo] action installnil versions are discouraged and will be deprecated in Rubygems 4
This is creating a profile that modifies the /Users//Library/Preferences/com.apple.Bluetooth.plist keys... but the actual keys that the UI modifies are /Library/Preferences/com.apple.Bluetooth.plist
Does this cookbook actually work for you guys on El-Capitan?
https://github.com/facebook/IT-CPE/tree/master/chef/cookbooks/cpe_hosts#cpe_hosts-cookbook
mentions that the resource checks for the following tags: #Start-Managed-CPE-Hosts and #End-Managed-CPE-Hosts but it appears to only be checking for entires which end with # Chef Managed.
I'm not sure which way this should go: but either the resource should be updated or the readme should.
the cpe_remote cookbook currently warns if auth headers are not passed, but there is no actual way for people using the cookbook to pass these as it's an internal feature to FB. Could this be generalized and added to the cookbook?
I would love to have auth header usage to protect the chef_remote repo urls
Hi CPE,
I'd be very interested to see Chocolatey packages Facebook has written be open-sourced, similar to the Autopkg Recipes that have been open-sourced over at https://github.com/facebook/Recipes-for-AutoPkg. This would be a great help to me and I think the community as well!
Thanks,
Brandon
I noticed that there was a return unless locals_exist within the cpe_munki_locals resource to which didn't update the local plist if an empty list was provided.
It seems that this was added to prevent a local manifest to even be added to the run, but what if there was a local manifest set but purposely empty? Should it be better to detect if node['cpe_munki']['preferences']['LocalOnlyManifest'] was set and if not, then return?
Wanted to get a consensus before submitting a PR to change this.
I had an issue where the repo pointed to was being used to pull pkgs, but not manifests (I nettop'd it and was only seeing the http repo, but am using puppet+client certs on the build box). More verbosity would have been nice to help me detect the confusion earlier.
I'm getting the following error when trying to use cpe_chrome to set ManagedBookmarks on a Windows system:
NoMethodError: undefined method 'encode' for ["name", "My Bookmark"]:Array
Here's how I'm setting the node attribute:
node.default['cpe_chrome']['profile']['ManagedBookmarks'] = [
{
'name' => 'My Bookmark',
'url' => 'https://google.com'
},
{
'name' => 'Another Bookmark',
'url' => 'https://google.com'
}
]
-->
on Linux and macOS, cpe_chrome always returns with zero resources. This is because the resource names are identical for both windows/non-windows.
Chef 16 looks to not handle that any longer.
Chef 16.1
macOS/Linux
Run chef, notice that the profiles get removed.
Not needed
change cpe_chrome/recipes/default.rb
if node.windows?
cpe_chrome_win 'Configure Google Chrome'
else
cpe_chrome 'Configure Google Chrome'
end
change cpe_chrome/resources/cpe_chrome_win.rb
resource_name :cpe_chrome_win
provides :cpe_chrome, :os => 'windows'
default_action :config
I know this kind of goes against the whole "desired state", but this would help when testing new versions of tools without chef downgrading them immediately on the next run.
Missing 'maintainer_email' entry in cpe_utils/metadata.rb
Fix: When running knife upload, the upload consistently fails. Adding that metadata field fixes the error.
I'm not sure if this is exactly the relevant line, however, in any case, the default fallback setting for node['cpe_munki']['preferences']['LocalOnlyManifest'] doesn't get added to the Munki profile.
This preference doesn't get applied unless it is explicitly set. Currently I'm setting this in cpe_init::company_init.rb.
I have an interesting situation that I think others may eventually run into and I was thinking as a best practice, that we should flip cpe_launchd and cpe_profiles in the cpe_init runlist that you provide as an example:
I have a cookbook I wrote that uses cpe_launchd to create a LaunchAgent, but this app kind of sucks and needs to have the preferences available prior to the app launching.
With cpe_profiles after cpe_launchd in the run list, this makes it a bit hard.
I could write some new has_profile? in cpe_utils, but this seems like a better and easier approach.
as of commit 5822bc9, the __init__ of AdobeAPIObject was failing to gather and cache the productlist member of the cached data, and so the product list is always fetched from the server.
See lines 170-172 of adobe_api.py for details. I would suggest calling gather_product_list at that point in the initialization.
With Chef 16.2 now released, I am auditing all of the various cookbooks across repositories and seeing many inconsistencies that I believe we can and should correct.
Single platform cookbooks:
Method 1:
resource_name :cpe_applocker
provides :cpe_applocker, :os => 'windows'
default_action :configure
Method 2:
resource_name :cpe_dconf
provides :cpe_dconf, :os => 'linux'
default_action :update
Method 3:
resource_name :cpe_deprecation_notifier
provides :cpe_deprecation_notifier, :os => 'darwin'
default_action :prompt
Multiplatform cookbooks:
Method 1:
resource_name :cpe_adobe_flash_darwin
default_action :config
provides :cpe_adobe_flash, :os => 'darwin'
Method 2:
resource_name :cpe_adobe_flash_darwin
default_action :config
provides :cpe_adobe_flash, :os => 'darwin'
These are just some of the examples.
there are other method examples that would take me hours to document, but some cookbooks that do not follow any of these models:
Gusto, Pinterest and Uber's cookbooks have a few other examples of different methods.
We should come up with some methods and adhere to them - perhaps even co-author linter rules that can enforce these.
I believe we can bring this down to the following:
Single Platform cookbook
foo.rb with a configure resource block)configure.rb install.rb).Multi Platform cookbook
macos.rb, windows.rb) or unix.rb if it can handle multiple things (like darwin and ubuntu)configure.rb install.rb).Guards
Guards should either be in the resource or the recipe, but likely not both.
Multiplatform code deduplication
Libraries and/or attribute files should be designed for multi-platform so that code is not repeated across multiple resources. I think this will be the most pertinent/long part of the discussion and we may not be able to agree or come up with a solution for all cases.
To be clear, this is merely a suggestion and I am very open to differing opinions.
This should offer no downstream impact other than making it for consistent and creating a model that others can follow when "taking inspiration" from other open source cookbooks.
quickstart.json fails due to missing cpe_adobe_flash
chef_version=17.9.52
chef_version=17.9.52
platform=mac_os_x
platform_version=12.3
Run sudo chef-client -z -j quickstart.json
Redirecting to cinc-client
[2022-02-27T14:44:24-08:00] WARN: No config file found or specified on command line. Using command line options instead.
Cinc Client, version 17.9.52
Patents: https://www.chef.io/patents
Infra Phase starting
Resolving cookbooks for run list: ["cpe_init"]
================================================================================
Error Resolving Cookbooks for Run List:
================================================================================
Missing Cookbooks:
------------------
No such cookbook: cpe_adobe_flash
Expanded Run List:
------------------
* cpe_init
System Info:
------------
chef_version=17.9.52
platform=mac_os_x
platform_version=12.3
ruby=ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-darwin19]
program_name=/opt/cinc-workstation/bin/cinc-client
executable=/opt/cinc-workstation/bin/cinc-client
Running handlers:
[2022-02-27T14:44:30-08:00] ERROR: Running exception handlers
Running handlers complete
[2022-02-27T14:44:30-08:00] ERROR: Exception handlers complete
Infra Phase failed. 0 resources updated in 05 seconds
[2022-02-27T14:44:30-08:00] FATAL: Stacktrace dumped to /Users/brandon_kurtz/.cinc/local-mode-cache/cache/cinc-stacktrace.out
[2022-02-27T14:44:30-08:00] FATAL: ---------------------------------------------------------------------------------------
[2022-02-27T14:44:30-08:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2022-02-27T14:44:30-08:00] FATAL: ---------------------------------------------------------------------------------------
[2022-02-27T14:44:30-08:00] FATAL: Net::HTTPServerException: 412 "Precondition Failed"
I don't think stacktrace is necessary here but can provide if needed
much like munki, I think cpe_remote should be able to install a package should the package expire suddenly. Could be done like this: https://github.com/munki/munki/wiki/Allowing-Untrusted-Packages
Alternatively, let cpe_remote not hard fail and destroy chef runs.
Currently there are a handful of cookbooks which leverage 'Administrators' for defining owner, group, rights, et al. This is problematic when the default language of the Windows device is not set to English.
In order to circumvent this, I believe the gilded approach would be to use SID strings instead of the actual name of the securable resource that the SID would point to (i.e. 'S-1-5-32-544' instead of 'Administrators'). Given that the SIDs for specific builtin groups don't change, methinks this would be a safer approach.
This feature was introduced in Chef Infra client v16.5.64 (See: v16.5.64 release notes under "Windows securable resources").
Chef-client v16.13.16
Windows 10
Setup a Windows machine in a non-English language, run a Chef recipe which relies upon the usage of 'Administrators', 'Everyone', 'SYSTEM' and you should get back errors.
Chef::Exceptions::Win32APIError: Não foi feito mapeamento entre os nomes de conta e as identificações de segurança.
Translated to English this becomes:
Chef::Exceptions::Win32APIError: No mapping between account names and security IDs was done.
This comes up time and time again, even internally about how to properly manage chef runs, post initial deployment.
Many people end up using small launchdaemons controlled by things like cpe_launchd, but given that Facebook already open sources chefctl, it would be awesome if the (giant) CPE team could open source their controls over this.
@clburlison has somewhat addressed this situation, but I would love to see a battle-tested at scale, multiple OS version of this.
cpe_remote will say a url is invalid, yet the URL works as expected everywhere else (including curl/wget). In this specific case, it is a redirect to a shortlived AWS URL with creds/auth as parameters on the redirected URL.
Example URL: https://github.com/salopensource/sal-scripts/releases/download/2.1.3/sal_scripts.pkg
It should probably handle whatever redirects github does (as this is common elsewhere too).
I don't understand why some of the native Chef helper functions [1] -- like def linux?, def macos?, def debian_family?, et al -- are being duplicated in fb_helpers, cpe_helpers.
Rather than extending the node object to contain functions already available to the Chef DSL, why not just use the built-in ones?
Frame number: 0/26
From: /etc/chef/local-mode-cache/cache/cookbooks/cpe_my_org_init/recipes/default.rb:17 Chef::Mixin::FromFile#from_file:
12: # of patent rights can be found in the PATENTS file in the same directory.
13: #
14: require 'pry'
15: binding.pry
16: # Start an empty run_list so we can append to it
=> 17: run_list = []
18:
19: # All machines
20: run_list += [
21: 'global_base',
22: 'my_org_base',
[1] pry(#<Chef::Recipe>)> show-method linux?
From: /opt/chef/embedded/lib/ruby/gems/3.0.0/gems/chef-utils-17.7.29/lib/chef-utils/dsl/os.rb:28:
Owner: ChefUtils::DSL::OS
Visibility: public
Signature: linux?(node=?)
Number of lines: 3
def linux?(node = __getnode)
node["os"] == "linux"
end
[2] pry(#<Chef::Recipe>)> show-method node.linux?
From: /etc/chef/local-mode-cache/cache/cookbooks/fb_helpers/libraries/node_methods.rb:50:
Owner: Chef::Node
Visibility: public
Signature: linux?()
Number of lines: 3
def linux?
self['os'] == 'linux'
end
Can anyone explain why this is necessary/beneficial?
[1] See: https://github.com/chef/chef/blob/main/chef-utils/lib/chef-utils/dsl/os.rb & https://github.com/chef/chef/blob/main/chef-utils/lib/chef-utils/dsl/platform.rb & https://github.com/chef/chef/blob/main/chef-utils/lib/chef-utils/dsl/platform_family.rb
In this diff you back out a change and shifted cpe_nomad to use cpe_launchd (away from fb_launchd), but in your configure_launchd you still use fb_launchd.
Paste of lines 152-170
def configure_launchd
launchd lddomain do
only_if do
::File.exist?("/Library/LaunchAgents/#{lddomain}.plist")
end
type 'agent'
action :nothing
end
node.default['fb_launchd']['jobs'][lddomain.split('.')[-1]] =. < --- This line
node.default['cpe_nomad']['launchagent']
end
def profile_domain
"#{node['cpe_profiles']['prefix']}.nomad"
end
def lddomain
"#{node['fb_launchd']['prefix']}.nomad" < --- This line
end
I'm happy to do a quick PR to pull it back, but you may want to take a closer look at the sync tool to see where else this didn't get backed out correctly.
In your quickstart guide, it says to run sudo chef-client -z -j quickstart.json, but that file is non-existent.
I run a headless MacMini 7,2 at home and the cpe_powermanagement cookbook fails as it tries to install a portable profile.
Ohai returns
"battery": {
}
In the company_init.rb file, you can override the base_url for your munki install.
node.default['cpe_remote']['base_url'] = 'https://myserver/munki_repo/chef'
That url is derived from an attribute in the cpe_remote cookbook
default['cpe_remote'] = {
'base_url' => 'https://myserver/munki_repo/chef',
'server_accessible' => true
}
It doesn't matter where or how you specify that url as long as it is the correct one. If you skip it, the munki install just tells you it's up to date.
If you DO specify the url to your server, then when you run the cpe_init cookbook and the company_init.rb code is executed, you get the following error:
* cpe_remote_pkg[munkitools_core] action install[2018-01-16T16:16:54-08:00] INFO: Processing cpe_remote_pkg[munkitools_core] action install (/var/chef/cache/cookbooks/cpe_munki/resources/cpe_munki_install.rb line 72)
[2018-01-16T16:16:55-08:00] ERROR: Connection refused connecting to **https://https//mys**erver/munki_repo/chef/munkitools/munkitools_core-3.1.1.3447.pkg, retry 1/3
Notice that the URL is malformed. I cannot find what bit of code is injecting the broken https// piece into the url. Thoughts?
Commit 5822bc9 in the adobe_tools branch introduced an error at lines 56-64 of adobe_api.py. A copy of the __init__ function header, which was supposed to be indented along with the other members of the class, was left exdented and so the other members weren't defined.
I would like to see a cpe_utils cookbook come back, that simply calls cpe_helpers. Since cpe_helpers contains all the similar node calls, this should not result in any regressions and allow other providers to slowly move their cookbooks one at a time to cpe_helpers.
If cpe_utils is being used, it should give a warning on every chef run to encourage people off of it, otherwise it will have to be maintained from here on out.
Once all CPE repositories have moved to cpe_helpers, we can kill this transition cookbook.
When trying to slowly move from cpe_utils to cpe_helpers, it gets a bit stressful. With cpe_utils gone from this repo, it is somewhat unclear how other companies/repositories can successfully migrate, without multiple cookbook changes being done all at once.
This ultimately is a metadata issue as you cannot conditionally set them up with the CPE/API driven model (due to no-versioning).
Changing every cookbook you have in one single sweep and hoping nothing breaks.
I commit to helping with PR's across the various cookbook repositories in moving over to cpe_helpers if Facebook can help design an official migration path for the community. As it stands, the community is essentially in a forked state, which will be a barrier for new companies trying to get started with this model.
In reference to the cpe_osxserver cookbook (which may be redundant now that you have cpe_macos_server). Looks like Apple moved this in Sierra.
I see two files now when using profiles;
/Library/Preferences/com.apple.PowerManagement.plist
/Library/Preferences/com.apple.PowerManagement.${UUID}.plist
Converging the cookbooks in this repo on a v17+ Chef client result in the following deprecation warning being thrown (using cpe_launchd as an example):
The cpe_launchd resource in the cpe_launchd cookbook should declare `unified_mode true` at 1 location:
- /etc/chef/local-mode-cache/cache/cookbooks/cpe_launchd/resources/cpe_launchd.rb
See https://docs.chef.io/deprecations_unified_mode/ for further details.
https://docs.chef.io/unified_mode/
Anyone using Chef client v17+ will face this deprecation warning until unified_mode true is appended to the first line of each custom resource file.
Ignore the deprecation warning.
Should be an easy PR (or series of PR's) to craft.
Need to add def self.sevenzip_cmd to cpe_helpers and re-ref it in cpe_remote so it is being called from CPE::Helpers and not CPE::Utils.
Given the number of machines using the Adobe UM API, having a +/- splay of 3 days (72 hours) in the cache life is probably insufficient to get below the Adobe throttling limits. I suggest updating the default splay to be +/- 6 days (144 hours). This will spread things evenly of the course of the default two week cache period.
IT-CPE/chef/tools/chef_bootstrap.py
Line 455 in fc1128a
need to update to new style.
ohai.disabled_plugins = [:Passwd]
ohai.plugin_path << '/etc/chef/ohai_plugins'
In the readme I think it should be clearly stated what changes are expected to happen. Applying the default quickstart.json results in two profiles appearing, for managing screensaver and chrome, which I think should be no-op by default. Un-intuitively, no munki changes occur, so it's extra confusing.
Muting this behavior for chrome requires adding this to IT-CPE/chef/cookbooks/cpe_init/recipes/company_init.rb:
node.default['cpe_chrome']['profile'] = {}
I don't know how to nerf cpe_screensaver...
While we're discussing the readme, I'd also spell out the chef-zero --local-mode and --override-runlist flags for the non-savvy.
Seems a dependency was added in this commit but I don't see the requirement for it in the code.
Line:
There's a few instances of rescue StandardError in fb_helpers/libraries/node_methods.rb (https://github.com/facebook/IT-CPE/blob/main/itchef/cookbooks/fb_helpers/libraries/node_methods.rb) and that should probably be re-evaluated.
For Windows, the cpe_chrome cookbook references node.person in which I'm assuming you're using from an internal cpe_utils 😉 - node_functions.rb. Unless I'm missing something else here? 🙈
Places called:
Also, we don't need to know your business since we can't use intern as well 😢 :
IT-CPE/chef/cookbooks/cpe_chrome/resources/cpe_chrome_win.rb
Lines 31 to 34 in 66a71bb
IT-CPE/chef/cookbooks/cpe_chrome/resources/cpe_chrome_win.rb
Lines 47 to 50 in 66a71bb
IT-CPE/chef/cookbooks/cpe_chrome/resources/cpe_chrome_win.rb
Lines 60 to 63 in 66a71bb
Please update cpe_firefox with all the new autoconfig goodness. Nick is really proud of the work someone else did and wants to show it off.
When running the quickstart as per the README, the following error is thrown:
No such cookbook: cpe_deprecation_notifier
18.1.0
macOS
Follow README steps for the quickstart.
The following cookbooks are outright missing:
cpe_deprecation_notifier
cpe_spotlight
fb_osquery is also missing, but in cpe_chrome it marked as a depends in metadata.rb for some reason, which doesn't make sense. What if someone wants to use the chrome management cookbook without having osquery?
I got past this error by removing fb_osquery as a requirement in cpe_chrome/metadata.rb.
After the above mods (removing the two missing cookbooks and removing the errant depends), I get a clean run of the quickstart. I'm not sure if it is doing everything as it should, but I'll dig into that some more as well and find out.
In the current state, quickstart does not work out of the box.
Looks like cpe_firefox is not completely decoupled:
================================================================================
Recipe Compile Error in /Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_init/recipes/default.rb
================================================================================
NameError
---------
uninitialized constant #<Class:#<Chef::Recipe:0x007fbe3ac06340>>::CPE
Cookbook Trace:
---------------
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_firefox/recipes/mac_os_x_firefox.rb:62:in `block in from_file'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_firefox/recipes/mac_os_x_firefox.rb:22:in `each'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_firefox/recipes/mac_os_x_firefox.rb:22:in `from_file'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_firefox/recipes/default.rb:16:in `from_file'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_init/recipes/mac_os_x_init.rb:58:in `block in from_file'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_init/recipes/mac_os_x_init.rb:57:in `each'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_init/recipes/mac_os_x_init.rb:57:in `from_file'
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_init/recipes/default.rb:17:in `from_file'
Relevant File Content:
----------------------
/Users/nate/.chef/local-mode-cache/cache/cookbooks/cpe_firefox/recipes/mac_os_x_firefox.rb:
55: local_settings_file = resources_dir + local_settings
56: file local_settings_file.to_s do
57: action :delete
58: end
59:
60: # We're going to place the configs in /Library/CPE/browsers/firefox/
61: ff_central_store =
62>> Pathname.new(CPE.get_cpe_path('cpe')) + 'browsers' + 'firefox'
63: remote_directory ff_central_store.to_s do
64: source 'firefox'
65: owner 'root'
66: group 'wheel'
67: mode '0775'
68: recursive true
69: end
70:
71: # Apply the new config template
Platform:
---------
x86_64-darwin13
Trying to get "AutoDMG Cache Builder" working. Have a new machine setup with Munki and it is connecting to our repo without any problems, but when I run the cache builder I get this error:
$ sudo ./autodmg_cache_build.py
Password:
Using plistlib
Something went wrong! cannot import name MunkiDownloadError
Using Munki repo: https://munki.ourdomain.com/munki_repo
Error: HTTPS was used but no auth provided.
Note we use SSL, but we don't use Basic Authentication. So I'm not sure what auth it is asking for. Tried to google and ask others but no success yet.
As discussed, I discovered cpe_chrome was failing during our DEP enrollments due to Spotlight not finishing indexing during the initial bootstrap.
Chrome is integral in our deployment (and is installed on all machines), so for now I have opted to disable the return unless node.installed?('com.google.Chrome') function. The Master Preference functionality is a one-time thing, so it is crucial that it works.
Perhaps a case should be written to look for Google Chrome in it's default installation path(s) and if we don't find it there, then use the cpe_utils spotlight functionality.
I'd like to propose the following:
cpe_remote_file to download the file to the same path as the pkginstallerShould your team agree, I am happy to write the pull request myself. @nmcspadden has mentioned that cpe_remote_pkg might have reduced usage within Facebook, so I'm not sure if it would be valuable to you all, but it would likely be valuable to other companies.
The current process we use is not ideal.
Some packages need a ChoiceChanges.xml file to further customize the installation. This is built-in functionality in munki, however this cannot be worked into the current version of cpe_remote_pkg. I have worked around this by utilizing cpe_remote_file and a standard execute block.
I will ensure this is not a breaking change or even required functionality.
I changed only the following attributes:
node.default['organization'] = 'bkCo'
node.default['cpe_launchd']['prefix'] = 'com.bkCo.chef'
node.default['cpe_profiles']['prefix'] = 'com.bkCo.chef'
Running sudo chef-client -z -j quickstart.json results in a crash. See https://gist.github.com/discentem/4b19b516ae1318f3008f79d06adef40d for fatal output.
Commenting cpe_munki out in the runlist in mac_os_x_init.rb results in a finished run (no crash).
I'm assuming get_cpe_path is an internal node util.
Pretty easy to get around this by hardcoding the ff_central_store variable.
Seems CPE::Distro is referenced throughout cpe_remote cookbook. I don't see it initialized anywhere within the repo so I'm not sure if this is public.
Chef run would get:
================================================================================
Error executing action `create` on resource 'cpe_remote_file[fupayme.pkg]'
================================================================================
NameError
---------
uninitialized constant CPE::Distro
Cookbook Trace:
---------------
/var/chef/cache/cookbooks/cpe_remote/resources/file.rb:71:in `block (2 levels) in class_from_file'
/var/chef/cache/cookbooks/cpe_remote/resources/file.rb:65:in `block in class_from_file'
This is on Chef 14 if that matters.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.