Yeah with expertise on staff you can certainly afford to review and
improve the quality of external 3rd party software, there is a
non-zero cost though; it's often comparable to starting over (with the
requisite expertise, again).
Unfortunately with the pretty much limitless capabilities of
cookbooks, it's seems super hard to build automated Supermarket-based
acceptance criteria - imagine the infrastructure permutation matrix
and cost to ChefSoftwareInc; they already have great systems in place
for official ChefSoftwareInc cookbooks testing/acceptance/regression
testing.
I think my original comment stands: If you understand the code having
CR'd it to appropriate quality level for your organization, feel free
to trust in it, but don't placate yourself. Conversely, if you're
having trouble reasoning through the basic Chef cookbook functionality
in-use in the third-party software; I would probably recommend trying
something simpler, especially with the relevant experience.
cheers,
--aj
On Fri, Feb 20, 2015 at 8:54 AM, Daniel Condomitti
daniel@condomitti.com wrote:
There’s no official process for vetting cookbooks or publishing that they
have been through any kind of audit process. It’s just good practice in
general to audit anything you’re using in your infrastructure; just like
you’d do with an internal review of a codebase within your organization.
Has anything like that been proposed? Obviously there’s no way to warranty
it saying that a specific cookbook isn’t going to break something in your
infrastructure or work properly. Some sort of review process to ensure that
a cookbook isn’t doing anything malicious or pulling in un-signed
dependencies would probably be really helpful to the community.
On Thursday, February 19, 2015 at 2:48 PM, Douglas Garstang wrote:
Thanks AJ. I'll check that out, but ...
"I wouldn't really recommend using any community cookbooks (not even
mine), especially if you don't know what the code is doing. You are
effectively backdoor/root shelling all of your machines with
ignorance.".
... your pretty much poo-pooing the entire chef community cookbook approach
there aren't you?
Doug.
On Thu, Feb 19, 2015 at 11:42 AM, AJ Christensen
aj@junglistheavy.industries wrote:
No need to use a cookbook. Try aptly, it's stand-alone
http://www.aptly.info/ -- packagecloud.io is similar, but a hosted
SaaS.
You might be able to use the LWRPs from that Heavy Water repository
cookbook without using the recipes.
It looks like the resource declaration at line 34-37 is the wrong type
of resource. It looks as though you want a
Chef::Resource::RepositoryPackage (repository_package), which has the
repository parameter/argument:
https://github.com/hw-cookbooks/repository/blob/master/resources/package.rb
The repository resource is special 'default' LWRP.
I wouldn't really recommend using any community cookbooks (not even
mine), especially if you don't know what the code is doing. You are
effectively backdoor/root shelling all of your machines with
ignorance.
cheers,
--aj
On Fri, Feb 20, 2015 at 8:32 AM, Douglas Garstang
doug.garstang@gmail.com wrote:
I'm trying to set up an apt repository with chef. Trying to use a
community
cookbook, I found this one: GitHub - hw-cookbooks/repository: Repository builder
It's readme says to drop new deb files into the /srv/repository_incoming
directory and then run the chef-client. Doing that gets me this error:
==> default: NoMethodError
==> default: -------------
==> default: undefined method `repository' for Chef::Resource::Repository
==> default:
==> default:
==> default: Cookbook Trace:
==> default: ---------------
==> default:
/tmp/vagrant-chef/8c7b6c4971128a90594d5194827546c6/cookbooks/repository/recipes/incoming.rb:36:in
`block (3 levels) in from_file'
==> default:
/tmp/vagrant-chef/8c7b6c4971128a90594d5194827546c6/cookbooks/repository/recipes/incoming.rb:33:in
`each'
==> default:
/tmp/vagrant-chef/8c7b6c4971128a90594d5194827546c6/cookbooks/repository/recipes/incoming.rb:33:in
`block (2 levels) in from_file'
==> default:
==> default:
==> default:
==> default: Resource Declaration:
==> default: ---------------------
==> default: # In
/tmp/vagrant-chef/8c7b6c4971128a90594d5194827546c6/cookbooks/repository/recipes/incoming.rb
==> default:
==> default: 30: ruby_block 'Repository - Process incoming' do
==> default: 31: action :nothing
==> default: 32: block do
==> default: 33:
Dir.glob(File.join(node[:repository][:incoming][:directory],
'*.deb')).each
do |deb_file|
==> default: 34: r = Chef::Resource::Repository.new(deb_file,
run_context)
==> default: 35: r.action :nothing
==> default: 36: r.repository node[:repository][:incoming][:name]
==> default: 37: r.run_action(:add)
==> default: 38: end
==> default: 39: end
==> default: 40: only_if do
==> default: 41:
File.directory?(node[:repository][:incoming][:directory])
==> default: 42: end
==> default: 43: end
I've been digging around and I can't even find the
Chef::Resource::Repository resource, so I have no idea what's going on.
Any
idea? Or, is there a better community cookbook for managing a private apt
repository?
Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627