Kamal was introduced in 2023 (back then as MRSK) as an alternative way to deploy and manage containers on a server. It is marketed as Capistrano for containers, and as a big fan of the simplicity of Capistrano I was intrigued. I despise the political ideas of one of Kamal’s creators, but I think on the tech/implementation side he is promoting solutions that I honestly think are good (including HTML over the wire). Kamal is ‘simply’ some tooling around running images using Docker on a server, with zero-downtime deployments.

Some preparation

This is how I prepared for my testing:

1. I had to set up an SMTP server as my sendmail solution (that actually worked quite well for my smallish projects, no need for sendgrid or the like); see my post on getting Chasquid up and running on Debian.
2. I installed docker from the Debian repo’s (and not Docker’s), so it is automatical…

I don’t mind running my own virtual servers. Fail2ban is a tool I’ve had running on my servers for years. It helps fencing of requests from ip-addresses that repeatedly misbehave when connecting to SSH and postfix. I never got to creating my own rules. I thought I had to write it in some arcane scripting language, but recently I learned it is pretty easy.

In this case I wanted to block 500 (internal server error) and 422 (Unprocessable Entity) errors. A server error once in a while is expected, but repeated server errors are suspicious. Common source of these errors are scripts that scan for things like SQL injections.

Examples given are for Debian.

/etc/fail2ban/filter.d/nginx-errors.conf

[Definition]

failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*" (500|422)
port = http,https
ignoreregex =
backend = auto
logpath = /var/log/nginx/access.log
bantime = 600
maxretry = 10

And appending to `/etc/fail2ban/jail….

Vaak is het belangrijk om te weten hoe een website wordt gebruikt. Dit informeert discussies en voorkomt daarmee dat er kostbare tijd van ontwikkelaars wordt gestoken in zaken die wellicht nauwelijks gebruikt worden. Het is daarom verstandig om meer te gaan analyseren. Soms hoef je er niet eens meer voor te meten(!)

Zonder meer meten toch meer inzicht

Zonder meer te meten kun je vaak toch al analyses maken. Een webserver registreert standaard alle pagina aanvragen, en wat basis gegevens over iedere bezoeker. Ook houdt een applicatie zelf vaak nog een logboek bij. Met een simpele scriptingtaal zoals python of ruby is het vaak niet moeilijk om hier statistieken uit te halen. Voordeel is dat er geen nieuwe informatie vastgelegd hoeft te worden én dat de eindgebruiker het ook niet kan blokkeren (al kan een gebruiker zich relatief gemakkelijk voordoen als b.v. een ‘zoekmachine’). Het nadeel is wel dat je veel dingen zelf moet doen zoals het we…

There important reasons to use HTTPS. It makes your systems more secure, helps to protect your users privacy, and will prevent others to hijack your account to deface your site.

If you’ve ever tried to secure your site you may have found how hard it is. You have to generate a private key, a certificate signing request, upload that request somewhere, pay, process the e-mail, upload the certificate, configure your server and set a reminder that in 1, 2, 3 or 5 years you’ve got to go through most of that same process again (which I described before in more detail in an earlier “how I do it”-article. Well, no longer! Enter: Let’s encrypt.

Actually, Let’s encrypt is so easy that I had doubts whether I should even write this post. But maybe it wins an extra soul or two over.

The recommended way to get sta…

Nginx’s default configuration needs a bit of extra configuration (at least on Debian systems) to enable gzip and client side caching. Two very quick wins for better performing web-apps.

Enabling gzip for more content types

Compression makes files smaller. By default only HTML is gzipped, but it it makes sense for quite a list of other file types too. This, however, excludes(!) images, which have their own methods of compression: compression over compression delivers you nothing, and costs you and your end-user a few more CPU cycles.

So find the gzip on; line in /etc/nginx/nginx.conf file (make sure it is not turned off or commented), and either uncomment the gzip_types-line or use this, more complete, line (including svg):

gzip_types image/svg+xml text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Client side caching

Every browser has a cache of its own, …

In case you do something with user accounts on your website, you definitely want to make sure you’re using https. In general it protects the user’s privacy, also when just reading content on your website. The only thing that can be seen by a middleman is that the person is viewing something at your server, the rest is all encrypted. And since Google has started to rank https-websites higher it has even become a SEO technique :) ). This article explains you how to serve your pages over https.

Update: a better option exists nowadays for non-domain validated certificates: Let’s encrypt!

While the path to your server from someones desktop could be considered relatively ok in the past (harder to tap, putting a lot of trust in everything from the ISP to the internet exchanges and everything else in between), things have changed now. Wit…

Basically this is a technical note to myself, in case I need to setup another server for running yet another personal Ruby on Rails project. And don’t worry, I’m not going to replicate all nice guides out there, just filling in the gaps.

So let’s start with the list of bookmarks I follow as a start. Note that in these tutorials mostly a user is used named ‘deploy’. Typically I create a user per project and name databases etc. accordingly.

1. Get security right first: My first 5 minutes on a server or essential security for Linux servers
2. Then I get Rails up and running with this how to install Ruby on Rails with rbenv on Debian
3. (in case you want to use the server as your remote git repo too) [Git setting up a …