We realized we needed an External Node Classifier (ENC) for our Puppet environments in 2011, after it became clear that iClassify would no longer be a viable solution for the future. (The author of iClassify, Adam Jacob, had moved on to write Chef.) After evaluating our options, we narrowed it down to Puppet Dashboard, and Foreman. It turned out at the time, Puppet Dashboard wasn't really an ENC, and was largely just a reports processor and dashboard, for monitoring the status of Puppet runs. We looked at Foreman, and functionality-wise, even in 2011, it had a fully featured API, and full ENC support, not to mention bare-metal provisioning options, which we didn't need at the time. Shortly after migrating to Foreman we realized that we needed a way to pull lists of hosts out of Foreman for other management purposes. This led to us writing a tool, that eventually got fleshed out into the first official Foreman CLI, called "foremancli". It was fairly basic, in that it could only pull information out of a foreman server, but it did meet our most pressing needs. We started development on foremancli's successor, hammer, but we got busy, and with RedHat really building up their Foreman team and having human-power to spare, we handed off further development of Hammer to RedHat. At some point along the way, The theforeman.org infrastructure needed to grow, and we offered to host a number of their servers, including their build environments, website and wiki. (This was around the time that the website was refactored to actually not look terrible.) We still sponsor the project in this way. Currently, we also still contribute to the project via bug reports, and testing pre-release builds. Over the years we have organized many Foreman talks in the New York City area, and have generally tried to support this great project any way we can.
A few things of note
I wrote a CLI for Foreman, that I creatively named foremancli. It's now available as a gem, for easy installation. To install, simply run: $ gem install foremancli For usage: Creating a personal apt repo is a great idea for managing custom packages while still utilizing apt's management and dependency abilities. (We are not going to cover all the specifics of why one would want to create a custom apt repo, that should be self-explanatory.) Creating a secure apt repo accessible via apt is relatively straight forward, three items need to be setup: the repo dir, httpd, and GPG to sign the packages. Conventions
Setting up the repository directory The first step is to create the directory structure. In the conf directory there must be a configuration file called distributions. For the sake of simplicity, we are only defining one component to work with, called main. It works just like the main component of official repos from vendors like Debian and Ubuntu. (Note: for the time being we are not signing our packages just yet. Soon!) The other directories will be created as needed by the tool that adds packages to the repo, reprepro. Therefore you do not need to worry about them. Setting up httpd Regardless of what httpd you choose to use, you want to allow for HTTP access to the /home/jason/apt-repo directory. For apache use the following directory defintion: Adding packages to repo Adding packages to the repo is very easy: Use apt-get to fetch packages with your new repo You must tell your clients machines to use the new repo in order to fetch packages from it: If your packages are sane (which will be covered in another blog post!), you should have been able to install your packages without any problems. Almost .... did you get an error about your repository being unsigned? Read on! Signing the repo Dpkg packages do not have the ability to be individually signed the way RPM packages do. Instead, the package publisher must sign the contents of the repo the package comes in order to validate the authenticity of the package. The first step is to create a GPG key used to sign the repo. In the section below, the material in CAPS is example user input. If you haven't done so already, secure the permissions of your .gnupg directory. Now lets generate that key! We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. You should be able to see the key now: It is the latter part of the pub key ID we are concerned about, in this case EE519117 We want to add the following line to the distributions file: The next time you add a package to the repo, add it with the following command: Adding the package will cause the repo to be signed with the key. If you do not want to wait till you've added a package to sign the repo, you may do the following: Client configuration for the new key You need to publish your key and have the clients install it in order to use it. You can extract it like so: On your client machiness you can install it like so: You should be able to install packages with out any issues regarding security signatures! Future blog posts: Multi component repos Pass-phrase less repos (dangerous! but easy to manage in trusted environments) Custom dpkg packages Easy backporting of dpkg packages This month (April 13th) we gave a presentation to the NYC puppet User Group, on the node classification tool Foreman.
Joe Crobak, who attended wrote up an excellent blog post capturing our preso. Foreman is an ENC system for puppet, which greatly enhanced Puppet’s functionality, by acting as a central datastore of node metadata, that assists in provisioning workflows. (It also handles bare metal provisioning, and VM image management, but we aren’t using it for that yet.) We have been running the latest stable version (currently 0.2) of Foreman as our ENC (External Node Classifier) and really love it, and are working on contributing code to the project. (Which currently has over 20 active contributors). * Project homepage: http://theforeman.org/ * Release notes: http://theforeman.org/projects/foreman/wiki/ReleaseNotes * Full Rest API docs (Read/write): http://theforeman.org/projects/foreman/wiki/API * Github: https://github.com/ohadlevy/foreman * IRC: irc://irc.freenode.net/theforeman (ohadlevy is the original author) December AWS news: PCI compliance, bigger S3 objects, Mobile SDKs and FreeBSD running on EC212/16/2010
Colin Percival has gotten FreeBSD running on EC2. This is great news for all those BSD shops out their waiting for cloud support.
Amazon finally launched a much requested (at least by us) DNS service Amazon also just raised their S3 object size limit to a whopping 5TB (from 5GB). Now the race is on to see our favorite tools get updated with multipart upload support. The biggest news though is Amazon finally achieving PCI DSS 2.0 Validated Level 1 Service Provider status (for EC2, S3, EBS and VPC) For you mobile devs out there don’t forget to check out Android and iOS SDKs, which allow you to point your mobile apps directly at S3, SimpleDB and SNS. |
AuthorBrandorr Group LLC is a one-stop cloud computing solution provider, helping companies manage growth and ship new projects using cloud and scalability best practices.
Recent Posts
June 2019
|