In this tutorial, I briefly explain how to set up a webserver using nginx, openssl and uwsgi on Arch Linux. The tutorial is applicable to other Linux distributions and goes through the required configuration step by step. It is, I believe, beginner friendly.

On my webserver, I am hosting a couple of websites and -services written in different languages. So far, I used php-fpm for PHP, fcgiwrap and spawn-fcgi for Python/django and plain fCGI for C. An nginx server was (and still is) responsible for handling the requests.

Today I took a closer look at uWSGI, a full stack for building (and hosting) clustered/distributed network applications.. It has plugins for most scripting languages and supports many many parameters to fine-tune the setup.

There are nice blog posts on how to use nginx together with uWSGI to serve different kinds of scripting languages or websites, so I will not describe that once again.

Let me instead briefly describe the structure of my setup. I am hosting my websites in /srv/http/*project*/htdocs. uWSGI follows a one-server-per-app approach, so each app has its own processes and server. The different app-specific uWSGI configuration files for the projects reside in /srv/run/*project*/uwsgi.ini. They contain the details of how exactly the app is served, i.e. which plugin should be loaded, how many worker threads and processes are spawned etc.

The servers are started all together by the uWSGI emperor with the glob feature. The emperor looks for uWSGI configuration files in certain directories and upon finding one, starts that particular server. This is the systemd unit file for the uWSGI emperor:

[Unit]
Description=uWSGI Emperor
After=syslog.target

[Service]
ExecStart=/usr/bin/uwsgi --emperor "/srv/run/*/uwsgi.ini" --emperor-stats "/srv/run/uwsgi-emperor-stats.sock"
SuccessExitStatus=30
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT
Restart=always
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

The emperor looks for uswgi.ini files in /srv/run/*/. It also has some other nice features, like for example the stats server I am spawning to /srv/run/uwsgi-emperor-stats.sock.

All this is easy to set up and get running, and, most importantly, to maintain. Adding a new site to the stack is as easy as adding the uWSGI configuration file in the right directory and confiuring nginx for it.

So far, everything works smoothly and I can only recommend having a look at uWSGI.

Hi there. For quite some years I was using Wordpress to power this blog. Wordpress is nice and works fine, but has several disadvantages that led me to ditch it and write my own blog software. Before I describe that one, let me give you a couple of reasons why I went away from Wordpress:

• It’s PHP and more importantly, the code is so messy that hacking it gives you headache.
• It ships with tons of features I will never use
• There are always core or plugin updates that appear in the admin and annoy me.
• I don’t like WYSIWYG and also don’t really want to write plain HTML

For those reasons, and because I generally like web development, I wrote my own blog software. It is written in Python and uses the Django web framework. Although Django is also quite huge and brings tons of features that I will never need, it is very well-tested, actively developed and is a framework rather than a ready-to-use software.

So, some words about this software. It contains the following apps, all of them are self-written so I really depend only on Django itself.

• blog Contains articles, static pages and comments. Markup is done by python-markdown. The comment implementation features nested commenting, akismet spam checking and a honeypot to trick spam bots.
• gallery A simple image gallery app for uploading and categorizing images. The images are cropped into several dynamically defined size after the uploading.
• tags A simple tagging application used in both the blog and gallery app.

The django-admin is heavily used as well as python-markdown. It’s such a pleasure writing markdown!

Since Django ships with so many useful shortcuts and classes, the whole software is quite small. Below is the output of cloc, a source code counter.

$ cloc --exclude-dir=lib,migrations --not-match-f='akismet\.py|pygments\.css' .
      41 text files.
      38 unique files.                              
     826 files ignored.

http://cloc.sourceforge.net v 1.58  T=0.5 s (70.0 files/s, 3408.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                          23            234            152            669
CSS                              3             58              0            269
HTML                             7             51              2            227
Javascript                       2              4              3             35
-------------------------------------------------------------------------------
SUM:                            35            347            157           1200
-------------------------------------------------------------------------------

As you can see, the software has only 1200 (what a nice number!) source lines of code, which is quite small for a a complete blog software. At least, that’s what I think. :)

I hope this new app encourages me to write more and more often. I already know that the layout is somewhat ugly now, but feedback is still much appreciated.

A couple of months ago, I started a small project called i3pystatus, a collection of Python scripts through which the output of the i3status tool was piped and additional info added. Since then, the project was taken over by a friend of mine, enkore, and became a full grown replacement to i3status. Among others it contains scripts for displaying date and time, battery status, network connectivity, unread email with support for various programs and even a parcel tracking script. All of them are highly configurable and i3pystatus ships with an easy to use API to add additional functionality.

Please head over to github and give it a shot. If you are running Arch linux, you can use my AUR package to download and install it. Also you may be interested in reading the blog post of enkore on i3 and i3pystatus.

This is just a quick tip: Since recently, I am using a new PDF viewer called LLPP. It is written in the functional programming language ML, based on MuPDF and very slim and fast.

LLPP currently doesn’t support auto reloading, which is a very useful feature when writing, for example, on LaTeX documents. But what it DOES support is reload on the SIGHUP signal - and that I am using.

When I compile LaTeX documents, I use the amazing latexmk perl script. You definitely should try that out! latexmk knows a continuous build mode, where it keeps running and compiles, as soon as the document changes. It can also automatically open a PDF viewer with the document and (and here comes the useful stuff) do something after an update. One of the things it can do is sending a SIGHUP signal to the viewer.

So, let us bring it together with LLPP: We add the following two lines to our ~/.latexmkrc configuration file:

$pdf_previewer='start llpp %S';
$pdf_mode=1;
$pdf_update_method=2;

The first line tells latexmk how to start our PDF viewer, LLPP. The second line tells latexmk to use pdflatex (this is equivalent to the -pdf option) and the third line tells it to send the SIGHUP signal on document updates. As I wrote above, LLPP reloads the document as soon as it receives that signal. When we now run

latexmk -pvc document.tex

latexmk compiles, opens LLPP with the document and then waits for document changes. When it encounters a change, it recompiles and sends LLPP the update signal. With this stategy, you never have to leave the editor again while writing a LaTeX document. Nice, hum?