Versioning of debian / ubuntu server configurations

Good day, dear community.
I decided to share a small idea, maybe someone will be interesting and useful.

Tired of lost and broken configurations, authorization on servers under the root, in order to transfer new optimal configurations, I decided to create repositories from configuration folders and give them access in a more accessible place.

A little bit about yourself

I myself am a web programmer, for some time I was sitting on ubuntu, the server (VPS) almost everything was on debian. There is not much experience in server administration, unlike colleagues and hosters, but it has always attracted knowledge in this direction. I could sit in the console for hours and solve certain tasks. When the time was up, the more experienced colleagues took away the task toys and told me what I was doing wrong. But it was always interesting what exactly they did themselves and how the settings of the more loaded projects occur. All projects we store in bitbucket using the Mercurial version control system. One day they decided to maintain the current version of the projects on the servers using the same tool and made their lives much easier. Now you can pick up the latest updates on the server in two commands:

hg pull && hg up 

Why hosters do not offer similar software on their shared-hosting is a mystery. In my opinion upload via FTP yesterday. Now new employees are coming and they are slowly giving access to the servers, but already under my control, seeing the picture from the other side, I was horrified that what they had done on the server was very difficult to find. After several hours, the server returned to its normal state and came to me:
')

Idea for a million

Having received a new server (VPS) based on debain, without thinking twice, I created a repository in the configuration folder.

New server

We make all commands from under a root-user.
First of all, we update the software on the server:

 apt-get update && apt-get upgrade 

We put the Mercurial package (appeared in debian 6, but saw installation articles under debian 5):

 apt-get install mercurial 

Go to the configuration folder:

 cd /etc 

Create a repository:

 hg init 

which will create a hidden folder ".hg"
Tell a little about yourself:

 nano /etc/.hg/hgrc 

Specify the data:

 [ui] username = User <****@gmail.com> 

Already, you can find out about all the files by running the command:

 hg status 

Mercury will only show a list of files that are still new to it.

Let us indicate that we want to add all new files to the following commit:

 hg add 

Finally, we fix the first state of the configurations:

 hg commit -m 'first commit' 

Now you can safely install and configure the rest of the software.

At any time, you can check the status of the configurations using the command:

 hg status 

What exactly changed in the files can be found with the command:

 hg diff ./   

You can roll back the changes with the command:

 hg revert ./   

It will be even better to get acquainted with all the teams:

 hg help 

Publication

When we raise a new server or update the old one, all the time you remember:

• Where are your server setup reminders?
• On which project has similar software been raised?
• What is the root password from the server (to read the configs)

and the list can be great.

I decided to pour everything into a private repository. I repeat that we use bitbucket . Create a repository on it, get the path, something like:

 https://bitbucket.org/username/etc-project-a 

re-open our repository configuration:

 nano /etc/.hg/hgrc 

And we specify below:

 [paths] default = https://bitbucket.org/username/etc-project-a 

Run the command:

 hg push 

To which the mercury will ask you the authorization data on the bitbeat server. The good news is that you can set up authorization by ssh-key.

Now our configuration in a dry, cool place. You can always see how this or that server is set up and use the examples to raise a new one. To do this, you need to clone the repository to a local machine, or use a completely convenient web-interface from the bitcode.

Pros:

• Store configuration versions
• You can always roll back to a stable version.
• You can determine in one team what you have done without you.
• You can quickly find out how the server is configured without logging in.

Minuses:

• Do not forget to commit the latest changes.

I wanted to add automatic commits over the crown, but I thought that it was better to leave such a simple solution. Perhaps there are other ready-made solutions about which I would gladly read. Who knows, maybe this small article will help you come up with a simpler and more useful solution, which I hope you will share with us too.

Thank.