DEV Community: Cristian

Meet Ruby!

Cristian — Thu, 13 Aug 2020 15:09:57 +0000

She's an 11 week old Golden Retriever!

GitHub is down...again. How is your week going?

Cristian — Thu, 23 Apr 2020 13:24:56 +0000

Share your WFH setup!

Cristian — Fri, 03 Apr 2020 15:26:41 +0000

To cd or not to cd...in a shell script?

Cristian — Tue, 18 Feb 2020 15:55:57 +0000

In a few cases, I've noticed the use of cd in shell scripts, and this practice never really made sense to me. It seems so broken to change the current working directory to perform a command in a given context, such as another directory. I think using cd seems broken to me because it opens up the door that you might forget to cd back to the original directory if needed.

What do you think?

Bad?

#!/usr/bin/env bash

set -euo pipefail

EASYRSA_PATH='/etc/openvpn/easy-rsa'

cd $EASYRSA_PATH

./easyrsa init-pki

# other commands unrelated to EASYRSA_PATH

Good?

#!/usr/bin/env bash

set -euo pipefail

EASYRSA_PATH='/etc/openvpn/easy-rsa'

"${EASYRSA_PATH}/easyrsa" init-pki

# other commands unrelated to EASYRSA_PATH

Practicing Safe S...hell

Cristian — Tue, 18 Feb 2020 00:38:26 +0000

While creating SkyHole, I found myself writing a few shell scripts. They get the job done, and although I could have written them in a language such as Ruby or Python, it's a safe bet to make that any UNIX machine that execute these scripts have a shell.

As I was writing these scripts, it became clear that out of the box, a shell script doesn't have the niceties that you might expect when coming from another language. Things such as the script exploding when a variable isn't defined or the script exiting when a step in the function has failed aren't handled normally in a shell script. The purpose of this post is to share a few tricks to make scripting in a shell a bit safer.

Have a shebang

Not every machine a script runs on might have an up to date version of bash at /bin/bash. For example, macOS ships with an old version on this path.

#!/usr/bin/env bash

Set the exception parameter

If a script fails at a certain point, what would you like to happen? Most of the time, you want it to stop and not continue because the rest of the script might depend on that command to succeed. You can tell the shell to exit if anything throws an error immediately, and therefore the rest of the script won't continue running.

set -e

If you want to take this a step further, you can add -o pipefail, which protects against any failure anywhere in a pipeline, rather than just the last command.

set -eo pipefail

Set the undefined parameter

A script might rely on user input or data from another source to run correctly. What happens when that data is empty, and a variable never gets set? Nothing. The script will continue and fail only when an empty input is invalid for that command. What about when you interpolate a path? For example:

rm -rf "${USER_FOLDER}/"

What's going to happen here if the variable USER_FOLDER is never set? You guessed it; the shell will interpret that command as rm -rf "/". That would not be very good. You can prevent this from happening by adding the following to the top of your scripts.

set -u

Conclusion

What does this look like all together? I always add these two lines to the top of every shell script I write.

Hint: you can combine multiple set parameters.

#!/usr/bin/env bash

set -euo pipefail

Check out Anybody can write good bash (with a little effort) for more tips and tricks when scripting in shell. It was the inspiration for this post.

How do you maintain your security and privacy?

Cristian — Thu, 13 Feb 2020 19:03:23 +0000

macOS

iOS

Brave Browser

I recently started using Brave as my daily browser, and I couldn't be happier. I was using the latest Firefox but noticed a few websites didn't render correctly. Brave is built on Chromium and is Chrome without Google plus more security features built right in. The best part is, all of your existing Chrome extensions will continue to work in Brave.

OpenVPN and Pi-hole

I recently wrote a post regarding OpenVPN and Pi-hole. More information on both of these great projects can be found here.

1Password

I'm not sure what I would do if I never found 1Password. It's a password manager loaded with features, and they have a ton of information related to the security practices they employ. Fast forward a few years, and now all of my login passwords are unique and consist of 64 alphanumeric characters, including symbols. It even supports two-factor authentication out of the box.

GPG Suite

Granted, I don't use GPG to its full potential, but it doesn't hurt. Public/Private key cryptography is very popular. At the moment, I sign all of my Git commits and emails using GPG so their authenticity can be validated at any point in the future. Public-key cryptography is a method that I want to utilize more in the future.

macOS-Security-and-Privacy-Guide

drduh has compiled a vast collection of techniques for improving the security and privacy of a modern Apple Macintosh computer. Many of the methods are extreme and require quite a bit of technical know how but many are painless to implement and go a long way.

SkyHole: Privacy In A Digital Age

Cristian — Thu, 13 Feb 2020 15:08:48 +0000

Overview

First and foremost, this post is not a guide explaining how to shield your online identity to engage in illegal activity.

The dictionary definition of privacy is:

the state or condition of being free from being observed or disturbed by other people. E.g. "she returned to the privacy of her own home."

When people think about privacy, they think of things such as:

Closing the blinds in their home at night
The right to enjoy time alone without intrusion
Whispering when talking about something sensitive

The examples above are only related to your personal space. We live in a digital age, where we increasingly share our lives on the internet. If you treat your personal space with such methods of privacy, why shouldn't you manage your online presence with the same effort? No one knows yourself better than you and your smartphone. In some cases, it's easier for someone to intrude on your privacy online than it is physically.

As a software engineer, I like to think that I have a firm grasp of the reach the internet has on my privacy. To protect against that, I put specific practices in place to better safeguard and maintain my privacy. The problem is, not everyone is tech-savvy to the point where they can put in place the same measures with ease.

There are many services where anyone can sign up and download an application that masks their internet traffic. The problem is that some of those services don't have the best track records, and their implementation is often private (go figure). The technology I'm referring to is a VPN or Virtual Private Network. In short, a VPN creates a tunnel from your device to a server on the internet. When configured correctly, nobody in-between you and the server can see your internet traffic.

A VPN is useful when you want to protect yourself from:

Public WiFi hotspots
Internet Service Providers

A VPN doesn't/shouldn't do:

Safeguard you when engaging in illegal activity
Natively block access to trackers or analytics services

The Fun Part

Now that you know what this post is centered around (VPNs), let's see how easy it is to set one up. The most popular VPN software is OpenVPN. It's open-source, which allows the code to be tested and verified to work correctly.

The easiest and most straightforward way to set up your own OpenVPN server on AWS is by launching a preconfigured solution from the AWS Marketplace. Preconfigured solutions are also available for Azure, DigitalOcean, or Google Cloud and, while easy to set up, they lack in terms of default security settings and customizability. A lot of magic happens to spin these solutions up, and when it comes to security, this is often not considered a best practice.

The most difficult and least straightforward way to set up your own OpenVPN server on AWS is by provisioning a fresh flavor of Linux on an EC2 instance of your choice. We haven't begun the OpenVPN installation process, and we already have to think about things such as OS and hardware requirements. Once you settle on a desired EC2 configuration, you can install OpenVPN using various Linux packages. In the case of Ubuntu, something as simple as apt -y install openvpn would work. The OpenVPN Community contains full step-by-step instructions.

Once you've completed either form of getting OpenVPN up and running, you can enjoy many of the benefits that a VPN provides, such as the ones listed earlier. There's one issue, while you're more protected on public WiFi networks, and ISPs can't see your traffic anymore; trackers and analytics services are still using your new VPN IP address to target you. Wouldn't it be great if there was an open-source solution for this too? Luckily for you, there is, and it's called Pi-hole.

Pi-hole considers itself as a black hole for advertisements and trackers. Its goal is to act as your primary DNS server and filter all queries while only letting the good ones through to real DNS servers. The bad queries are DNS lookups for advertising or tracking services such as Google or Facebook. Pi-hole was initially developed to run on a Raspberry Pi since that would allow you to attach it to your local network and have your modem route all DNS traffic through it. Then your Kindle, Apple Watch, FireTV, and even your WiFi connected coffee maker would pass through Pi-hole without ever knowing it. Once a DNS request comes into Pi-hole for an advertiser such as Google, Pi-hole will recognize it based on Whitelists or Blacklists and either allow it through to upstream DNS servers or block it. If Pi-hole blocks it, the device that requested it thinks Google is offline and doesn't track or show you the advertisement.

I know what you're thinking, this is so cool, can I use OpenVPN to secure my traffic and Pi-hole to filter it? You're in luck again. Although these two projects are entirely separate from each other, they can be used in tandem. You can spin up another EC2 instance alongside OpenVPN and install Pi-hole on it. Once completed, update your OpenVPN config to tell all of its clients to use the new Pi-hole server as the default DNS server. It just so happens that Pi-hole has some documentation on how to go about this. Though the documentation is a great start, it leaves some questions unanswered and assumes your configuration matches theirs.

If only there were an open-source configuration that setups up OpenVPN and Pi-hole on AWS. It would be even better if it also set up the networking components required for OpenVPN and Pi-hole to work together seamlessly. Well, you're in luck. I felt that security and privacy online should be easy to obtain. Yet, there are so many guides and methods for achieving it that most people get lost and either make mistakes or give up in frustration.

SkyHole is an open-source Terraform configuration that will install and configure OpenVPN, Pi-hole, all networking components and leave you with a client.ovpn file. This file can be imported into any compatible OpenVPN client and used to connect to the VPN instantly. The configuration also contains the required setup for OpenVPN to use Pi-hole.

SkyHole is very opinionated. It's in the early stages of development and has a long way to come, but it works, and it works pretty well. Most of the default OpenVPN settings are replaced with hardened choices. I would greatly appreciate any contributions to the project in the form of suggesting or adding new features, writing, clarifying, or fixing documentation and reporting or fixing bugs. The best part of open-source is anyone can learn from everyone. I hope this project serves as an excellent resource for anyone to take their security and privacy into their own hands.

Lastly, you might think this sounds expensive, but SkyHole uses two of the smallest EC2 instances, which comes out to about $8 a month. Roughly the same amount that other 3rd party VPN services cost, but now you are in full control of the entire VPN implementation.

Enjoy!

SkyHole

Stay tuned for other posts involving device security and simple things you can do to shield yourself in this digital age.

How did we upgrade and containerize our largest Rails monolith in one quarter?

Cristian — Wed, 13 Nov 2019 18:19:43 +0000

Early days

In the early days, we built Aircall with a single Ruby on Rails app. Using Rails was great because we were able to bootstrap the development process. Besides, it helped us focus on reiterating until we landed upon a market fit. Though, as we grew, it was clear this app was becoming too big, so we split it into four Ruby on Rails apps.

The first of the four apps contained most of the product, such as user accounts, number settings, and both the internal/public API. The second contained all logic used to connect Aircall to custom integrations such as Salesforce and Zendesk. The third handled all real-time call logic, such as routing and conferences. Lastly, the fourth handled all billing related tasks such as processing payments and generating invoices.

While this helped our engineering team manage different parts of the product in a more organized manner, the main app containing most of the product continued to grow. Also, we were using AWS Elastic Beanstalk to host these applications since it allowed us to build our infrastructure and serve our customers quickly but would later prove to be a major pain point in our CI pipeline.

Now

Fast forward a few short years, we now have a rapidly growing engineering team with an elaborate fleet of containerized microservices. That being said, at the heart of it all is still our very first Ruby on Rails app. Granted, the responsibility of this app has significantly diminished over the years, but it still serves an essential role within our company being the single source of truth for most of our data.

During Q2 of 2019, we decided to show a little love to this app, which for the rest of this post, we'll call Web. Web was running Rails 4.2 on Elastic Beanstalk. Rails 6 was on the horizon, and many of our other applications were already running in Docker containers on ECS, so it was logical to upgrade Web to a newer Rails version and containerize it. Though this process is much easier said than done, we managed to achieve this in just a single quarter.

Upgrading Rails from 4.2 to 5.2

It was the second to last day of Rails Conf 2019 where I was sitting in on a talk given by Eileen M. Uchitelle, a Software Engineer at GitHub and a member of the Rails Core Team. Her talk highlighted how GitHub managed to upgrade both Ruby and Rails. If they managed to upgrade from Rails 2.3 to 5.2 and ditch their custom fork of Ruby while maintaining uptime, why couldn't we do the same? I mean, we were only going from Rails 4.2 to 5.2, so this should be a piece of cake. I was wrong. Here's what we learned and how we did it.

We decided early on that those who managed the Rails upgrade would continuously merge master into the feat/upgrade-rails branch and retroactively fix any deprecation issues as we progressed. This process left us with our master branch running Rails 4.2 and a feat/upgrade-rails branch running Rails 5.2. Next came the fun part, fixing all deprecation warnings, and since we went straight to Rails 5.2, they were mostly exceptions instead of warnings.

It's worth it to note that it isn't recommended to skip versions and is suggested to first begin with 5.0, then 5.1, and finally 5.2. Ultimately, we decided on jumping straight to 5.2 because it would help us smoke test problems quicker and saved us from having to scrub test logs for deprecation warnings.

There are many changes from Rails 4.2 to 5.2, some breaking and some not. Below are the ones we think are the most important and the steps needed to upgrade

Ruby

Rails 5 requires a minimum of Ruby 2.2.2 or later. If you're using rvm, rbenv, or asdf, this should be as simple as running the following commands from your shell.

rvm install 2.2.2

rbenv install 2.2.2

asdf install ruby 2.2.2

Dependencies

Dependencies in your Gemfile might not be compatible with newer versions of Rails. I suggest locking your Rails version in your Gemfile on a newer version: gem 'rails', '~> 5.2'. Then run bundle update rails while incrementally bumping conflicting gems until you get a successful bundle.

Configuration

After you’ve achieved a successful bundle, run rails app:update to interactively upgrade configuration files in bin/ and /config.

Schema

Unique and foreign indexes now live inside the create_table method. Running rails db:migrate generates a new db/schema.rb file with these changes regardless of whether or not you have any pending migrations.

Migrations

ActiveRecord migration files need to be tagged with the version of Rails in which they were generated. CreateCalls < ActiveRecord::Migration now becomes CreateCalls < ActiveRecord::Migration[4.2].

class CreateCalls < ActiveRecord::Migration[4.2]
  def change
  end
end

ActionController

Strong parameters have replaced protected attributes. If you’ve been using strong parameters already, then this shouldn’t cause problems. It’s important to note ActionController::Parameters now returns an Object instead of a Hash.

To access the raw parameters as a Hash, you can add #to_h to the Object: params.to_h.

params.permit(:page, :per_page).to_h.reverse_merge(page: 1, per_page: 15)

ActiveRecord

ActiveRecord models now inherit from ApplicationRecord instead of ActiveRecord::Base.

# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

# app/models/call.rb
class Call < ApplicationRecord
  belongs_to :number
end

belongs_to associations are required by default, and the use of required: true in belongs_to :company, required: true has now been replaced by optional: false.

# app/models/call.rb
class Call < ApplicationRecord
  belongs_to :number, optional: false
end

ActiveRecord and ActiveModel callbacks no longer halt when returning false. You need to use throw(:abort) instead.

class Number < ApplicationRecord
  before_create do
    throw(:abort) if you_need_to_stop_creation
  end
end

Tests

ActionController::TestCase now only accepts keyword arguments. Inside your specs, get :show, id: 1 becomes get :show, params: { id: 1 }.

What didn’t work?

Tests

As mentioned, Web has been around for a while, and many hands have touched it over the years. In any codebase, things could get out of hand, and we knew some parts might not have extensive tests in place. This lack of tests caused some issues because once we got the existing RSpec suite green, we still knew some things might not work as a result of the upgrade.

At this point, we had two solutions. First, manually testing the product and trying to reproduce any edge cases that came to mind. Second, deploying the upgraded app to only a percentage of our production traffic and acting fast to patch issues. Smoke testing this way was not an ideal situation, but it worked for us and kept our uptime at 99.99%.

To prevent this from happening in the future, we’ve stressed importance on code coverage within our engineering team. Simplecov is excellent for this and is now a part of our CI pipeline, calculating test coverage for every branch of Web, seamlessly. I’ll be releasing a blog post in the coming weeks showing how we aggregate code coverage across multiple CPU cores and containers on CircleCI to produce a single report.

Communication

Besides testing, communication is essential when executing a migration of this scale. To sum it up, communication was good, not great. We’re a multinational engineering team with 10 engineers in NYC and 50 in Paris. In retrospect, a project of this scale is better suited for the team with the largest amount of engineers, but the NYC team handled it instead, given the availability of resources at the time.

Failure of communication became apparent as the Paris team would leave for the day while the NYC team would arrive and work vigorously on the upgrade. Shortly after that, as the NYC team went home, the Paris team would arrive back the next day and occasionally be faced with an unstable staging environment. Since Web is at the core of our ecosystem, an unstable environment hindered the development of some projects. In most cases, the unstable portions were those in which there were no tests. You could say this was beneficial because it allowed us to spot issues before they reached our customers. At the same time, the Paris team was not familiar with the procedures or status of the upgrade and often had to troubleshoot in the dark until the NYC team arrived. To make matters worse, in some cases, the Paris team didn’t know if an issue was related to their project or the upgrade of Web.

This upgrade quickly pointed out an area in which we needed to improve on as a team. Additionally, we think when undertaking an upgrade of this scale, you need to make sure all engineering teams are looped in on every aspect, regardless of location or perceived interactions.

Conclusion

All in all, this project was a success. Our legacy monolith is now ready to run another few years while we continue to grow. We learned a lot and continue to apply our findings to every new project here at Aircall. This upgrade wasn’t easy, but it was worth it. Now we can better serve our customers by releasing new features and bug fixes quicker than ever, thanks to our improved CI pipeline.