web hosting

Automate OpenVPN client on CentOS 7

I need to setup OpenVPN client to start automatically on a CentOS 7 server for one of our recent projects at work. I’m not well versed in VPN technology, but the majority of the time was spent on something that I didn’t expect.

I go the VPN configuration and all the necessary certificates from the client, installed OpenVPN and tried it out. It seemed to work just fine. But the setting it up to start automatically and without any human intervention took much longer than I though it would.

The first issue that I came across was the necessary input of username and password for the VPN connection to be established. The solution to that is simple (thanks to this comment):

Create a new text file (for example, /etc/openvpn/auth) with the username being the first line of the file, and the password being the second. Don’t forget to limit the permissions to read-only by root.
Add the following line to the VPN configuration file (assuming /etc/openvpn/client.conf): “auth-user-pass auth“. Here, the second “auth” is the name of the file, relative to the VPN configuration.

With that, the manual startup of the VPN (openvpn client.conf) was working.

Now, how do we start the service automatically? The old-school knowledge was suggesting “service openvpn start”. But that fails due to openvpn being an uknown service. Weird, right?

“rpm -ql openvpn” pointed to the direction of the systemd service (“systemctl start openvpn”). But that failed too. The name of the service was strangely looking too:

# rpm -ql openvpn | grep service
/usr/lib/systemd/system/openvpn@.service

A little (well, not that little after all) digging around, revealed something that I didn’t know. Systemd services can be started with different configuration files. In this case, you can run “systemctl start openvpn@foobar” to start the OpenVPN service using “foobar” configuration file, which should be in “/etc/openvpn/foobar.conf“.

What’s that config file and where do I get it from? Well, the OpenVPN configuration sent from our client had a “account@host.ovpn” file, which is exactly what’s needed. So, renaming “account@host.ovpn” to “client.conf” and moving it together with all the other certificate files into “/etc/openvpn” folder allowed me to do “systemctl start openvpn@client“. All you need now is to make the service start automatically at boot time and you are done.

Install Ansible 2.0+ on Amazon AMI

Today, while upgrading some of my Ansible roles I’ve hit the problem. Some of the newer roles require Ansible 2.0. My Amazon AMI machine that runs the playbooks was still on version 1.9. EPEL repository doesn’t seem to have the newer Ansible version yet. Gladly, Google brough in this StackOverflow thread, which suggested installing Ansible with pip, not with yum. This helped a lot:

rpm -e ansible
pip install ansible

It actually brought in Ansible v2.2 (see also Ansible v2.1), which is even better.

Rundeck – Job Scheduler and Runbook Automation

Rundeck is yet another one of those services that I want to get my hands on but haven’t yet got the time to. The simplest way to describe it is: cron on steroids.

Rundeck allows one to define the commands and then allow for execution on those commands manually, periodically or based on a certain trigger. Imagine, for example, a deployment command that needs to run across some servers to which you are not comfortable giving access to developers, or even non-technical users. You can create a command in Rundeck and give access to certain users to execute it, via clicking a button or two in a user friendly web interface.

A side benefit to using Rundeck versus cron are the metrics. Rundeck collects metrics like successful and failed executions, execution times, etc. So it makes it easier for you to see that certain jobs are getting progressively slower or fail on specific weekdays, etc.

The best part is that Rundeck is Open Source and self-hosted, so you don’t need to give sensitive access to some external web service.

Amazon Linux AMI 2016.09

AWS Blog lets us know that Amazon Linux AMI 2016.09 is now available. It comes with a variety of updates, such as Nginx 1.10, PHP 7, and PostgreSQL 9.5 and Python 3.5. Another thing that got quite a bit of improvement is the boot time of the Amazon Linux AMI instances. Here’s a comparison chart:

Read about all the changes in the release notes.

P.S.: I’m still stuck with Amazon AMI on a few of my instances, but in general I have to remind all of you to NOT use the Amazon AMI. You’ve been warned.