Category Archives: Linux

Certbot and apache

I promised a blog post detailing changes I needed to make to my apache config in order to move BRBcoffee to Https, but in hindsight there isn’t much to write about it, it’s basically just a refactor.

Certbot, the tool from EFF (written in Python, yay!) that gets ssl certs from Let’s Encrypt, doesn’t work with monolithic conf files with multiple hosts. I run all my projects on the same server, routing traffic based on the site address using apache’s VirtualHost directive. It used to look like this:

<VirtualHost *:80>
    DocumentRoot "/var/www/blog"
    # Some more directives
<VirtualHost *:80>
    DocumentRoot "/var/www/archive"
    # Some more directives
<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass / http://localhost:5000/
    ProxyPassReverse / http://localhost:5000

So what you need to do is rip all of that out, you don’t want it in there. In their place you want this:

IncludeOptional conf.d/*.conf

Depending on your packager, it may be that this directive is already somewhere in your httpd.conf file. If it is, great, just leave it be. After that you want to take each VirtualHost that you ripped out of the main httpd.conf, and place them in individual files, like so:

<VirtualHost *:80>
    DocumentRoot "/var/www/blog"
    # Some more directives


The configuration doesn’t change, it just needs to be in separate file for certbot to be able to do its thing. You see, after certbot goes out and gets your certificates it needs to add some rules to each vhost for redirecting traffic to ssl, which I guess they didn’t want to write a lot of ugly parsing code to be able to do in a program that really isn’t about that (although it should be trivial with BeautifulSoup.

Anyway, before, running certbot –apache probably didn’t work, it got the certs for you, but couldn’t edit your conf to do what we want. Now, when you run it, it’ll complete just fine. If you chose to set all traffic to go to https, it will add three redirect lines to your conf files, and it will create a new file as well, in my case, blog-le-ssl.conf. It’s identical to the old conf file, except that it is on port 443, and that it checks that mod_ssl is loaded. All of this is stuff we could have done ourselves, of course, but it’s a convenience thing.

So that’s all there is to it. Refactor your httpd.conf by separating each virtualhost into a different file, and run certbot –apache again.

Switching from screen to tmux

Hello avid readers of yesteryear!

I’ve recently moved from working in a Linux/Windows environment to a Linux/Windows/OS X environment, and as such I’ve had to make some small changes to my workflows. I’m here to tell you what went wrong and how to fix it (hint: it’s in the title)

XKCD comic about using old software configured for you
Relevant XKCD title text: 2078: He announces that he’s finally making the jump from screen+irssi to tmux+weechat.

Now I’m the guy who just has it set up the way I want. I use screen in linux, and I use screen in the amazingly named Bash on Ubuntu on Windows. It works how I need it to work and I’m able to get things done. Now we introduce Mac OS X to the mix, and a seemingly tiny problem arises:

screenshot of vim
vim in normal terminal session
Screenshot of vim with different colors
vim inside a screen session

Try to spot the difference. I’ll wait.

The problem is a vim plugin called airline, which uses a lot of colors while enhancing vim’s normal ui. Something happens with the way screen identifies itself, that confuses airline, and makes the colors change slightly. No big deal, but it also makes the text less readable, which can be a bigger problem. Now there exists a separately compiled gnu screen for mac, specifically made to fix problems with screen colors. That screenshot was taken using that binary, and it looks identical to the native one. I spent about 2 hours trying to figure out a workaround for this problem, but in the end I decided to just finally give tmux a try, I’d been meaning to get around to that anyway.

vim in tmux session
That was easy

Okay, so tmux can handle colors better than screen, but what about all the other features from screen that we’re used to and love? Well once you’ve remapped your escape key to the one you’re used to from Gnu screen, you should be totally fine. To do this just add unbind C-b with C-a, replacing ‘a’ with whatever key you prefer. Splitting panes is done with ‘%’ and ‘”‘ in tmux, but you can simply unbind and bind to whatever you’re used to. Detaching is the same as always, attaching is done with “attach” instead of “-r”, so fairly easy to remember. Mouse mode is just as easy to enable as before, just replace mousetrack on from .screenrc with set -g mouse on in .tmux.conf.

All in all there isn’t much to write about when moving from screen to tmux. They do the same job, but tmux does it better, since it’s been built for a modern world than the literally 30 year old GNU Screen. If you’re using screen still, give tmux a try. You may spend a little time in the config file at first remapping things, but I swear it’s worth it.

Configuring a linux firewall

So you’ve got your Linux server going, it’s configured the way you want it , and everything is coming up roses. You try to ping it, but the server doesn’t seem to exist. You’ve been blocked by some of the best/most insane firewall in the galaxy: iptables. A firewall’s job is to block unwanted traffic, and iptables takes its job seriously. By default, it. drops. everything. Got a http request incoming? Psh, drop that packet. I don’t care if you’ve got apache running. FTP request? Same story. Mysql? Nope.

A cat shoving things off a desk
This is iptables

Ssh is usually fine though, so we can log in and edit the rules. Iptables rules are added to rule chains. The only chain we’re interested in is the INPUT chain for now; We want to be able to receive http requests to our server, ssh connections, and nothing else. We’ll also want to allow existing connections to persist. These are the switches we’ll be using (you can find all these in the manpages, of course, but some are in the iptables-extensions manpage).

  • -F flushes the rulechains. This means exactly what you’d think.
  • -A [chain] adds a rule to the specified chain.
  • -I [chain] [number] same as -A but inserts rule at a given point in the chain.
  • -i [interface] specifies the interface the rule will act on. If you don’t specify this, the rule will act on all interfaces, including loopback (more on this later).
  • -p [protocol] specifies whether the rule is for tcp, udp, or whathaveyou.
  • --dport [port] further narrows down the packets to look at by checking which port they’re headed for.
  • -m [match] this is an extension that looks at the type of traffic the packet belongs to. We use it with:
  • --state [state], which asks a different module called conntrack whether the connection is INVALID, NEW, ESTABLISHED, RELATED, or UNTRACKED. This is magic, I have only a vague understanding of how it works.
  • -j [policy] says whether to accept or drop the packet.

Alright, let’s get to it. You can think of iptables as a sieve, where every rule along the way checks out a packet and decides whether to keep it or discard it. If the rule doesn’t match the packet, it moves further down the sieve to be checked by other rules. Therefore, at the end of it, if the packet doesn’t match any of our rules, we will just discard it. A good policy for internet traffic is that if you don’t know what it is, don’t touch it. Every rule we add gets added last in the chain/sieve.

A script demonstrating the use of iptables

And that’s it. We’ve configured our firewall. It will reset every time you reboot your server, but that isn’t often. I just keep a script like the one above to reconfigure it. You can get NetworkManager to configure it for you on boot, but I don’t really see the point unless you reboot your server all the time, which, I mean, why would you do such a thing?