sysadmin

• Sun, 19 Apr 2015

  Build Virtual Machines for Multiple Hypervisors with Jenkins and Packer

  Posted: Sun, 19 Apr 2015

  Building a virtual machine image for one target hypervisor probably doesn’t cut it anymore. If your organization is like most today, you run VMware in production, and you’re investigating AWS or OpenStack for burstability or a full blown migration, and your developers all run VirtualBox on their laptops. Except for Marvin. Marvin runs KVM because he’s a contributor to the project.

  We can define cross-hypervisor machine definitions with Packer.

  We can run Packer on a variety of machines to provide full hypervisor coverage with Jenkins.

  Packer and Jenkins make a great team. They’re like peanut butter and chocolate. Or coffee and chocolate. Or pastry and chocolate.

  /me grabs a chocolate bar from his drawer and gets back on track.

  Many organizations use a single Jenkins server to run continuous integration builds, but Jenkins supports any number of slave nodes to distribute load. Further, we can assign labels to those nodes that define capabilities or other characteristics (host OS, installed software, special hardware architecture, etc).

  Jobs can be pinned to nodes with specific labels, and the NodeLabel Parameter Plugin lets us use node labels as a parameter when building a job.

  I give each of my build nodes a label of packer-${builder-name}, then I can build any machine in my Packer Open Source Appliances repository on all of my available local hypervisors and cloud accounts. My personal list includes qemu, docker, virtualbox-iso, and openstack (with Rackspace).

  I’m pretty excited about this, and I’ll share more details and possible next steps in a future post. Until then, you can snag the job definition from my repository.

  Build Virtual Machines for Multiple Hypervisors with Jenkins and Packer
  • devops
  • sysadmin
• Sun, 06 Jan 2013

  dnsmasq and External Resolution of Internal Addresses

  Posted: Sun, 06 Jan 2013

  The dnsmasq program is used on many linux computers and devices to handle DNS and DHCP. If you’re connected to the Internet through a Buffalo router of any recent vintage, you’re using dnsmasq right now unless you’ve thoroughly fiddled with the configuration, in which case you probably already know everything I’m about to write.

  The —stop-dns-rebind option (or “No DNS Rebind” in the Buffalo DD-WRT GUI) throws away any DNS resolution responses from external name servers that contain IP addresses within the private address spaces. This prevents a class of attacks where bad dudes use short DNS TTL settings to make browsers give up internal network secrets. Zone administrators that publish private IP addresses within the public DNS space are usually either mistaken, dumb, or nefarious, and their results should be ignored whenever possible.

  I really wrote myself into a corner with that last sentence, because I have a zone that responds with private IP addresses within the public DNS space. I am testing some fun and completely above board things with Amazon’s Route 53 service, and the quickest way to do so was to copy an internal zone from within the Freund Data Center Complex out to the cloud.

  How do we fix it? If you’re using a recent version of dnsmasq, there’s a —rebind-domain-ok option that places provided domains on a white list. If your router doesn’t support that option, then you can always disable the behavior entirely.

  dnsmasq and External Resolution of Internal Addresses
  • linux
  • sysadmin