OpenVPN Setup on Ubuntu 18.04 LTS

I could not remember exactly when I setup OpenVPN for the first time. As far as I remember, it was not an easy task. But, I need to have it installed, and I found it easier. Probably, because it’s easier to setup on Ubuntu 18.04 LTS?

I need to have it setup because I have some sites blocked by my internet provider. Using Google’s DNS ( or even ClouFlare’s did not help either. Changing the DNS made my internet connection do not work.

So, I need to set OpenVPN up somewhere. I was thinking of having it setup on my own cloud server at Linode. Lucky that there is a straight-forward tutorial on how to setup OpenVPN on Ubuntu 18.04 LTS. I will write it down also here for my personal documentation.


First, update the system by running apt-get update and then apt-get upgrade. For me this is optional.


DigitalOcean $5 2018

Walaupun situs blog ini berada dalam layanan cloud server dari Linode, namun saya ada juga menggunakan layanan dari DigitalOcean. Dari sisi harga, keduanya hampir mirip. Hanya saja, per awal Januari 2018, DigitalOcean menawarkan harga yang sedikit lebih murah ($US5 untuk 1GB RAM dan 25GB SSD storage).


Moving to Google Apps for Work

Google Apps for Work

It’s been two for around two months since my small office moved the email service to Google Apps for Work. So far, it’s been a great experience and I think it was the right decision to make.

Why Moving?

Before moving to Google Apps for Work, we manage the email servers on our own. Meaning, we needed to do the setup, maintenance, including backup. There are less than twenty email accounts to manage under two main domains. The email was hosted on a cloud-based server — we used DigitalOcean. Everything was running almost without any issues.

We depend on emails on day-to-day operation. At the same time, we need to have (almost) zero maintenance and increase our productivity. Our small team needs to share lots of things like documents, spreadsheets, and agendas. The thing is that we need to use our personal Google account to share documents. The other things is on the storage. I have more than 6 GB of email (for work). So, moving to Google Apps for Work is an anticipation. Here are some main reasons on the migration:

  1. Zero maintenance. By outsourcing the email service to Google, we at least only need to keep the domain active.
  2. Integration with other Google services like Google Docs, Google Sheets, Google Calendar, and more. The integration also includes the seamless collaboratoin between coworkers.
  3. Flexible storage. By default, I have 30 GB of storage for my Gmail, Google Drive, and photos. If later I need to upgrade, the price is pretty reasonable. 100 GB for IDR 27,000 (per account) is a good deal.
  4. Simple setup and management. Setting up each service provided by Google Apps for Work is very easy.

Migration Process

The migration process was pretty easy. Since there were only around 12 email accounts, so moving them individually did not take too much time. My coworkers moved all the email account by themselves. The only challenge is not to have the downtime. There is a simple guide to work on this area. During the registration process, I only need to use a primary domain — and setup the secondary domain as domain alias later on.

For the cost efficiency, I worked on the settings on email routing. For example, if there is an email address that was only accessed by specific people in the organisation, I created some routing rules. By this, I can minimise the number of accounts.

After all emails (including attachments) had been migrated to Google Apps, we kept the “old” servers online for few days just to make sure that no data left behind. I was not sure how long the whole processes was completed, but it was around one week.


Switch to Letsencrypt

Since my Comodo PositiveSSL Certificate for this blog is about to expired, I decided to switch to Let’s Encrypt. The implementation was easy. I was refering to DigitalOcean‘s community tutorial: How To Secure Nginx with Let’s Encrypt on Ubuntu 16.04.


nginx error: client intended to send too large body

After moving this site to DigitalOcean‘s cloud environment, I found a problem when uploading a file from my blog posting interface. Looking up from the error log, it says "client intended to send too large body: 1122400 bytes". I wanted to upload a file larger than 1 MB. I’m using nginx for the web server, and the solution is pretty simple.

Edit /etc/nginx/nginx.conf configuration file, and add client_max_body_size 20M; between http { }. Save the config file and start the nginx. Problem solved. If you need higher value, just change the 20 MB to something higher.