Version control is a huge topic and I won’t even attempt to do the rationale for it justice. Suffice to say, a state of the art source control repository is an essential piece of partner software that will keep information, configuration, code etc. properly versioned and, if so desired, open to collaboration.
The version control of choice here is git. Why? It is incredibly efficient, heavily used throughout the Open Source Software community and it’s architected at its core to function while detached from remote repositories.
The Pro Git book is published online and freely available and is in my mind the git resource and I rarely go elsewhere for git info.
So, what are we trying to do here? As I have many VMware images typically running various versions of Linux and running a purely local git repositories on my trusty laptop is not sufficiently redundant to suit my tastes, I need a server that hosts my git remote instance. For this purpose, I’m using my Synology NAS 713+ machine. Not a spectacular piece of hardware, but it’s got redundant drives and performs well enough for this purpose.
The net result I’m after here is that I have a remote repository that I can clone in any of my ‘worker’ images so that I can get reliable access to configuration commands, code etc. without having to resort to shared folder access.
As I have VPN access to my own network when outside of it, I strictly speaking won’t need to forward any ports when working with the remote repository outside my firewalls, but because I enable SSH with certificate authentication only for accessing said repositories, it presents a light-weight options for working truly remotely with the repository.
First off, the NAS needs to be configured with a share, optionally a dedicated account and appropriate security definition. To keep things simple as my client account name matches that in my NAS, I’ve opted to not setup a distinct account for access the remote git repository. Again, this is the trivial alternative and people looking for configurations more conducive to robust collaboration, will find plenty of resources outlining their options in detail.
In the steps below, I’ve artificially altered the shell prompt ot indicate where the commands are executed, client or NAS,
Authorize your client account to log on to the NAS via SSH without having to specify a password. You do this by adding your client account’s public key to the NAS account’s
authorized_keys file. Generate a key-pair with
ssh-keygen only if you don’t have a key pair already. The NAS’s hostname is set to ‘syno’ in
client$ ssh-keygen client$ scp ~/.ssh/id_rsa.pub syno: client$ ssh syno nas$ cat id_rsa.pub >> ~/.ssh/authorized_keys nas$ rm id_rsa.pub
While you should have been prompted for you NAS account’s password the first time, with the key now be ‘authorized’, an attempt to
ssh syno should now provide password-less access.
Once we’re setup with password-less access to remote storage, we’re ready to actually push an empty repository. To do that you need to create the repository locally. I’ll create a repository called ‘own’:
client$ mkdir -p git/own && cd git/own client$ git init
Now that we have an empty repository, we need to clone a ‘bare’ representation of it
client$ cd .. client$ git clone --bare own own.git
Before pushing this repository to the NAS, to save on typing when cloning and pushing, I setup a server-side symolic link to point to the ‘storage root’ where all the git remote repositories will be added. This is a trivial operation that impacts the account for which SSH access has been setup only. E.g. in my case:
client$ ssh syno nas$ ln -s /volume1/depot git
Now we can copy this repository to the server using standard SSH vernacular:
client$ scp -r own.git syno:git/
That’s it. Now you can remove the local own and own.git and fetch the server one. Presuming you have git installed and configured in your VM images, cloning your repository is as simple as:
client$ git clone syno:git/own.git
When working with virtual machine images in a development or lab capacity, it’s recommended to snapshot base images with SSH and git not only installed but also configured. It can then be really efficient to spin up new images or revert back to something that was last known to be working without having to go through the setup steps every time. Also, with a base configuration as a snapshot, you avoid polluting your NAS-side authorized_keys files with a high number of distinct public keys, some of which may belong to long-ago discarded VM images.