<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Git on The Comfy Seat</title><link>https://beanbag.technicalissues.us/tags/git/</link><description>Recent content in Git on The Comfy Seat</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 22 Apr 2014 00:00:00 +0000</lastBuildDate><atom:link href="https://beanbag.technicalissues.us/tags/git/index.xml" rel="self" type="application/rss+xml"/><item><title>Configuration Management Part 1: The Restart</title><link>https://beanbag.technicalissues.us/configuration-management-part-1-the-restart/</link><pubDate>Tue, 22 Apr 2014 00:00:00 +0000</pubDate><guid>https://beanbag.technicalissues.us/configuration-management-part-1-the-restart/</guid><description>&lt;p&gt;As mentioned in my &lt;a href="http://bit.ly/1eXR5cQ"&gt;last post&lt;/a&gt;, I’ve decided to start over on my journey to doing configuration management in an environment where we treat our infrastructure as code. Today I kicked things off by setting up a new Puppet Master on CentOS 6.5. Once my usual setup was applied to the system via a PXE boot &amp;amp; Kickstart installed Git and the puppetmaster package and was off.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Version Control&lt;/strong&gt;&lt;br&gt;
One of my main goals is to track everything in Git so my first task was to change the group ownership of /etc/puppet to my puppetadmins group and give them write access. Then I needed to initialize a repo in that directly, tell Git that it’s a shared repository so other admins can work in it too, and tell Git to ignore the modules folder. I then applied the group permissions to everything inside the folder, did setgid on modules &amp;amp; manifests, and lastly I did a setfacl on modules &amp;amp; manifests so that us admins would retain rwx on all files and folders. Lastly I cloned my first module from our GitLab instance into a folder under modules.&lt;/p&gt;</description></item><item><title>Foreman: Too Much Voodoo</title><link>https://beanbag.technicalissues.us/foreman-too-much-voodoo/</link><pubDate>Mon, 21 Apr 2014 00:00:00 +0000</pubDate><guid>https://beanbag.technicalissues.us/foreman-too-much-voodoo/</guid><description>&lt;p&gt;I finally got around to setting up &lt;a href="http://bit.ly/1eXLC65"&gt;Foreman&lt;/a&gt; at work and managing my first node with it.  After digging around I found that I felt really boxed in using this setup because so much of the work is done behind the scenes in some magical way.  One of my main goals is to facilitate the concept of infrastructure as code and, like my code, track changes via git and store them in our &lt;a href="http://bit.ly/1eXPDY8"&gt;GitLab&lt;/a&gt; instance.  The Foreman, as best I can tell, takes and hides &lt;span style="text-decoration: underline"&gt;everything&lt;/span&gt; it does inside a database which prevents me from being able to apply any version control to it’s settings.  This is an unforeseen and unfortunate reality because the developers have made a really good looking product that can do a lot of really cool things.  For me though, this is too much voodoo at this early of a stage of us doing configuration management and I think I’m going to back out my install and start over with a different approach that defines nodes in pain text .pp  files.  I’m sure I’ll take advantage of pulling in data from some external source like &lt;a href="http://bit.ly/1eXM6cm"&gt;Hiera&lt;/a&gt; and / or other systems we have to help make decisions dynamically but I don’t think I want the configs themselves in a db… who knows; guess I’ll try it out and see.&lt;/p&gt;</description></item></channel></rss>