Updated to support greater configuration options.

[mbrennan-afa]

Also provides a recipe for Apache2

[mbrennan-afa]

Hopefully the documentation is detailed enough. I'm not sure what you want to do about about the shared maintainer / author but I'm happy to help with support. My companies information can come out if required.

I'll leave it with you :)

[mbrennan-afa]

bump

[mpasternacki]

Good idea, but the implementation is lacking. I haven't included creating and serving the repository, as the details will vary depending on the setup (whether packages will be added manually or in a continuous integration setup; details of the CI setup, permissions, etc) and didn't want to force my particular setup.

I don't really like the idea of using a data bag here - it's just a single piece of information, and it is tied to a specific node. Attributes seem to be a more natural place for that.

Keeping freight's PGP key in a repository (especially a private key in an unencrypted data bag item) is not a good idea. In my setups, I've just let Chef recipe generate a new key pair and store the public key in node's attributes, and I think this should be the default.

It seems like freight is supposed to run as root in your setup. It's not necessary.

Please also note comments on particular lines of the patches.

It may make sense to create a freight_repository LWRP, and have the specific cookbook use it to create repositories. This gives possibility of using the cookbook as a library (just for the package and LWRP) or as a high-level ready to use setup.

Similarly, it may be good to split the cookbook into three recipes:

• default - only installs the packages
• repository.rb - only creates the repository (repositories), owner user, and gpg keys
• apache2.rb - includes repository.rb, serves the created repository (repositories) over http

I won't include this PR in this shape. My question is, will you refactor the PR to address these issues? If yes, I'll give you the assistance and information you'd need to make it work; if not, I will close this PR and implement this feature someday as outlined here.

[mbrennan-afa]

Good feedback. I'll address each.

Databag over attributes. Yeah I tend to agree, its a little silly unless you're sharing gpg keys across nodes. Happy to make this into an attribute. Storing the key against the node is much cleaner and allows better querying. I guess if you were creating redundant setups (with shared keys) you can always reference these from a role attribute.

Generating the key automatically vs specifying keys in a hash. Should we make allowances for both methods? What provider/resource are you using to generate the keys currently?

freight_repository LWRP sounds like a great idea. I was a bit hasty only allowing 'one' repository..woops. Should we also consider an LWRP for adding items into the freight cache? maybe something similar to reprepro's (https://github.com/opscode-cookbooks/reprepro/blob/master/providers/deb.rb) .. though I haven't seen anything in freight for removing debs from the repository.

Freight running as root, is also an oversight :( that should be a configurable attribute also with a default like 'freight'.

Splitting cookbooks, absolutely. How do you want to tackle the structure of repository.rb, should it be a hash of repository attributes? We could then just use the LWRPs to do the bulk of the work.

I'm definitely keen to push on with this. With your constructive feedback I'm confident we can get this sorted.

[mpasternacki]

Re shared key setups: yes, this is a use case I didn't think of. When attributes are used, they can be shared through role or environment. Alternatively, if we use LWRP, it can accept keys in different forms: directly as a string (taken from attribute), as a data bag name and item id (and possibly a key for encrypted data bag), maybe as URL to the key (together with a checksum or fingerprint for out-of-band verification), or as a boolean parameter telling it to generate the key (defaulting to true if none of previous options were specified). On the other hand, this starts to smell like overengineering for a nonexistent use case (YAGNI).

To generate the key, I'm usually making a small custom recipe that looks more or less like this: https://gist.github.com/mpasternacki/40c1e450782cd06cfd3a . It doesn't run freight cache as your PR - by doing that it could be simplified to something like this:

execute 'freight_cache …' do
  creates '/path/to/cache/pubkey.gpg'
end

ruby_block "save-freight-gpg-key" do
  block do
    node.set['freight']['public_gpg_key'] = File.read('/path/to/cache/pubkey.gpg')
  end
end

I'm not sure about LWRP for adding debs - I don't really see a use case. Still, it may be useful to gather third-party packages that aren't available in an apt repository (such as Ruby Enterprise Edition) or to mirror third-party apt repositories from chef run. If you feel it's useful, I won't oppose merging it in.

Removing deb files from freight is as simple as removing it from lib directory and rerunning freight cache.

Re splitting the cookbook - I'd do it like this:

1. recipes/default.rb only installs freight, and doesn't setup anything else.
2. a freight_repository LWRP allows user to sets up freight.conf, user and group (if needed), gpg key, etc. For custom setup, user includes only default recipe, and can use either LWRP, or use execute resource or their own scripting to work with the repositories
3. recipes/repository.rb takes an attribute hash (node['freight']['repositores']) and calls out to LWRP to create the repositories. Serving the repository and putting the packages in is left for the user to customize. node['freight']['repositories']['default'] is filled in with some default settings that user can use for a simple one-repo setup, but can also override or set to nil for their own settings.
4. recipes/apache2.rb includes recipes/repository.rb, and sets up Apache to serve node['freight']['repositories']['default']. It should be able to set up htpasswd authentication, generating a random password and storing it in node's attributes. Full URL is stored in node['freight']['repository_url']
5. recipes/client.rb does search(:node, 'freight_repository_url:[* TO *]'), and creates apt_repository resources to set up clients automatically.

It's possible to make it even more customizable, but this setup seems to be a good entry point - it covers all the use cases I personally have or want, and makes the simple setup easy. If there's any real need for more customization, it can always be refactored to provide that.

[mpasternacki]

Also: if you need any assistance or a review of code before it's ready to be merged, feel free to ping me - I'll be happy to help out, as this will be a really useful addition to the cookbook.

[mihasya]

Came across this PR while looking for a freight cookbook. Seems like it has stalled a bit, anything I can do to help? I'm a chef noob, but let me know if you've made any progress towards the goals you guys outlined and I'll see if I can fill in any of the gaps..

[mbrennan-afa]

@mihasya Hey there. Unfortunately I haven't had time as yet to get to this, lots of family drama's at the moment :(

Some of what we discussed is in my PR but needs heavy refactoring, I'd be happy for you to pick it up from where I left off.

I'll be away for 3 weeks in Europe and probably won't have much time to look at it once I'm over there either. It's probably best making a start rather than stalling more.

If you need any assistance then just pop another comment in this thread and I'll look when I can.

Much appreciated. Cheers

[mihasya]

RIP, this thread. Hope all's well with your family, @mbrennan-afa