Infrastructure Lab: Initial Version Control and Gold Server

Now that we’ve got a basic network segment running, it’s time to start setting up a more managed infrastructure. I tend to follow along with Traugott, Huddleston, and Traugott’s infrastructures.org checklist where possible, wo we’ll start with version control and a gold server.

Options for Version Control

In 2020, you woouldn’t be faulted for starting your version control with a GitHub account and repositories. You could also set up a Docker container or a set of distribution packages for a self-hosted Gitlab or a self-hosted Gitea.

But the minimum amount of scaffolding required for bare-bones version control could be a Git repository on the gold server. Plus, if we standardize on Git from the beginning, it’s easy to add additional remote repositories to push and fetch with, and we can transition our local repository to other services as they become available.

The Gold Server

The gold server will be our primary management server, eventually housing our Puppet configuration management system. To get started, we’ll make a virtual machine with:

  • 2 CPUs
  • 2 GB RAM
  • 16 GB thin-provisioned disk
  • network connection to the blab.renf.ro port group
  • CentOS 7 ISO mounted to CD/DVD drive

and make a minimal CentOS installation with a single disk partition and a static IP of 192.168.1.2. I also created a firewall rule in pfSense allowing hosts on the home network to ssh into the gold server, so I’m no longer limited to using VMware Remote Console. Additionally, I can access the pfSense web interface by creating an ssh tunnel from localhost:8443 to 192.168.1.1:443.

ssh Tunnel from Home Mac to pfSense through Gold Server

Installing and Configuring Git

Start the Git installation with yum install git. We want a single folder tree to hold any local Git repositories, and give Puppet or any other applications read access to the repositories. The default umask for root on CentOS is set to 0022, which allows any user on the system to read files created by root. So we’ll create a shared demo repository on the filesystem that the other users will be able to read from. Later, we’ll apply the same strategy for our real repositories for Puppet or any other files we need to track.

mkdir /opt/gitrepos
git init --bare --shared=umask /opt/gitrepos/demo.git

Then clone the repository, make a change, and push the change back to the shared repository:

cd /root
git clone /opt/gitrepos/demo.git
cd demo
echo "This is the demo repository" > README.md
git add README.md
git commit -m 'Added README.md'
git push -u origin master

Now that the change has been pushed to the shared repository folder, verify the current contents can be cloned and examined as another user:

sudo -u nobody -s /bin/bash
cd /tmp
git clone /opt/gitrepos/demo.git
cd demo
cat README.md
git log --oneline

You should see the contents of README.md in nobody‘s working copy, and a log entry with root‘s commit hash and message. And now we have a method to deploy files to the gold server from a central location.