I recently got myself a new web server. On this new server, I’m playing around with OpenLiteSpeed, which I have never used before. It comes with its own admin dashboard to manage the server. But it writes everything into configuration files.

Sometimes you also want or need to manipulate configurations files manually. If not for OpenLiteSpeed, then maybe the SQL or PHP configuration. But if you don’t really know what you do, you can easily screw things up.

Versioning your configuration files

This is why I have started to put my main configuration files under version control. This has several benefits:

• You can try things and revert them, if things are get broken
• You have a “backup” of your configuration
• You can use the same/similar configuration files on all your servers and synchronize them
• You can see changes made by other processes – like after an update or when using configuration tools

Only version the most important files and ignore sensitive information

On many Linux server systems, the configuration files are stored in the /etc folder. You may not think that you simply version that whole directory. But that’s not a good idea, as you might version files that contain sensitive information or that would even screw up your whole server, if you do something wrong. I once accidentally deleted the /etc/passwd file, which was not really good. ?

Ignoring nginx configuration files

So on my old server, I’ve versioned only the /etc/php and the /etc/nginx folders in two separate git repositories. For the nginx configurations, I used the following .gitignore file:

# /etc/nginx/.gitignore
*param*.pem
sites-enabled/
modules-enabled/
modules-available/

The second line ignores the dhparam-4096.pem files being used for better Diffie-Hellman key. I also ignored the *-enabled folder, which are just symlinks to the *-available folders. You can version them, if you want to keep track of which sites and modules are enabled. The modules-available also didn’t have too much value in my opinion, so I left this one out as well.

Ignoring OpenLiteSpeed configuration files

On the new server, I’m still figuring out how configuration files are structured. The OpenLiteSpeed files are stored in the folder /usr/local/lsws and as of now, I use the following .gitignore file:

# /usr/local/lsws/.gitignore
# Ignore all files by default but decent into subfolders
*
!*/

# Allow just some files and subfolders
!.gitignore
!/conf/**
!/lsphp*/**
!/php/**

# Still ignore some files and folders in those subfolders
*.conf.bak
*.conf.dpkg
*.conf.txt
*.conf0
*.conf0,v
*.properties0
*.properties0,v
/lsphp*/bin/
/lsphp*/include/
/lsphp*/lib/
/lsphp*/share/man/

As the /usr/local/lsws folder also contains binaries and log files, I’ve first ignored all files and folder. I then added only those folders containing the configuration files I wanted to put under version control.

When I upgrade some packages, a lot of “backup configuration files” appeared, so I ignored all with those file extensions in the previously allowed folders.

I might update this ignore list in the future, but as of now, I have all my files I want to have under version control.

Push the repository to a remote

As mentioned in the benefits, you might also use this approach to have a “backup” of your configuration files. While git (or any other version control system) is not an alternative to a backup, it can be a bonus to have them stored on some external server. As those configuration files are often not meant to be public, I use private git repositories on GitLab.com as my remote.

This also has the benefit, that I clone the repositories to my laptop and edit the configuration files in PhpStorm, which is a lot easier than using vim on the server. And I can also easily compare changes and revert some commits.

Automatically version changes

I usually do the commits (and pushes) manually. But in case you have changes to those files made by other processes, and you want to version every change, you could set up a cron to commit all changes. This is an example of a cron, that would auto-commit and push all changes to the nginx configuration files every 30 minutes:

30 * * * * cd /etc/nginx && git add -A && git commit -m "auto commit on `date`" && git push

Even new and deleted files would be versioned. But having a cron like this could also potentially result in a lot of commits, if you don’t have your ignores set correctly, as some of the new files might have been a log file that is changed quite frequently. So if you use a cron, you should check the auto-commits from time to time.

Conclusion

I really love git! You can use it for so many different things. Versioning my configuration files has saved me a lot of time trying to figure out why things are suddenly broken or when I wanted to make changes to many configuration files at once (editing them locally in PhpStrom).

Do you use a similar approach and might want to share your setup here as well? Or do you use git for other things? Then please leave a comment.