Some Slackware tips


I've been using Slackware Linux since around 2010-2011, moving from Debian mainly because I got tired of the package churn and following the internal politics of DDs. Initially I tried it as a way of getting a close to BSD experience on Linux, since I was already using OpenBSD at the time (more on that on a later post.) Turns out that having a prior BSD experience helps a lot, especially as Slackware is as "upstream" as upstream gets (very minimal, if any, distro-specific changes, as a matter of policy.)

Since it was Slackware's birthday just sometime ago, let me share some tips and tricks I've learned over the years.

Let's Encrypt with Crypt::LE

It has been a while since I last posted, let alone update my infra a bit, so here's one quick entry to document it.

For the longest time I haven't enabled SSL on my blog or other HTTP sites; I used to use Comodo, then StartCom SSL. However, I got wind that StartCom (along with WoSign) will soon be distrusted by Google Chrome, et al. after some reviews of their operation. The good thing though, is that there's now a Let's Encrypt initiative which provides free SSL certificates, so I figure it is high time for me to re-integrate SSL once more.

Hello again

Hello again! Testing posting using weblogger.el

Yes, it has been a long while since I've blogged. I'm such a lazy git, so I should try to change that. I'll probably post a bit more about Docker since I've been playing around with it along with some new tooling (such as docker-compose and swarm,) so better write what I know down for future reference.

Furthermore, I'm coming back to using Emacs, so, I should post some bits about it as well, maybe some pieces off my ~/.emacs.d/init.el configuration. Much of it is on GitHub though, and is constantly more updated there than elsewhere, so I'll probably concentrate on large bits of customization such as Helm and programming/IDE modes for Perl/Ruby. And probably, some bits off my other dotfiles as well... So, looking forward to writing again!

Following up with my previous post, let me show an example of setting up a container with sshd running by default, under daemontools supervision:

Key commands:

  • update-service from daemontools-run Ubuntu package is used here to add the service directory in /etc/sshd. This is really just a fancy way in Ubuntu to do cd /etc/service && ln -sf /etc/ssh/service sshd which would be done otherwise on other systems.
  • docker ps -l -q is a very useful Docker idiom, so much that I've made and alias of it in my .bashrc as docker last.
  • docker inspect can be used to retrieve external information about the running container, such as its IP address, that can then be used on the host to connect to (like in this example, via ssh.)

You can get this image from the Docker index under zakame/base, default root password is docker. Additionally, I set sshd to not use PAM authentication here as I'm on a Slackware host, and I needed to make /var/run/sshd manually this directory is normally made at startup during init.

Docker and daemontools: best buddies

I've been running docker for quite a while now, as I found it fun to use, and rather easy to deploy even on a Slackware system. It is even better to use it with daemontools, both to supervise the docker process as well as to be an alternative to init inside containers. Here are some notes regarding this kind of usage:

Docker service under daemontools

Docker has a simple server mode called using docker -d, which simply listens to a local socket (typically /var/run/docker.sock) and emits logs to STDOUT. This mode is naturally suitable for running docker under daemontools as a supervise service, so much so that it is almost a no-brainer to configure:

$ cat /service/docker/run
exec 2>&1
exec docker -d

Notice that the docker output is redirected, which can then be collected in a logger subprocess like multilog:

$ cat /service/docker/log/run
exec multilog t ./main

daemontools in Docker containers

Docker containers can be thought of as lightweight virtual machines; some even view it as a better chroot environment with its own networking and namespaces separate from the host system. Thus, one can run init like supervisor services inside these containers, and daemontools is a good choice for such a supervisor:

# docker run -i -t ubuntu /bin/bash
# sed -e 's/main$/main universe' /etc/apt/sources.list > /etc/apt/
# mv /etc/apt/sources.list{.new,}
# apt-get update
# apt-get install daemontools-run
# sh -c 'exec /usr/bin/svscanboot &'
# ps axf
... add daemons, scripts and install them in /etc/service
# exit

Once you've created an image, you can use docker commit with the -run option to add a Cmd that will be run be default when creating container with docker run -d:

# $myservice_id=`docker ps -l -q`
# docker commit -run '{"Cmd": ["/usr/bin/svscanboot"]}' $myservice_id myservice

If you have services listening on ports, be sure to add a PortSpecs key in your docker commit -run invocation with the appropriate ports to be exposed on the container, like this:

# docker commit -run '{"Cmd": ["/usr/bin/svscanboot"], "PortSpecs": ["22", "80"]}' $myservice_id my_ssh_web_container

Once created, you can now run your container with docker run -d:

# docker run -d my_ssh_web_container
# docker inspect `docker ps -l -q` | grep IPAddress
... ssh or browse the IP address found above...

So, I found myself installing Movable Type on my site to start posting once more. I set it up using the PSGI deployment notes from the GitHub docs, though there are a few things I missed that I should put down:

  • There's a lack of cpanfile listing down Plack, XMLRPC, and Starman dependencies, so install those manually according to the wiki doc. In addition, install some graphics library like Imager and set it in mt-config.cgi or MT will complain about a missing ImageDriver.
  • There are several config directives that need to be tweaked aside from PIDFilePath that need to be added:
    • CGIPath should point to the URL going to the MT installation, normally this can be some path in $url/cgi-bin/mt but one can just shorten it to $url/mt
    • StaticPath must not be your website's document root, but rather the path where MT's static files will be (e.g. /var/www/html/mt-static if the website root is in /var/www/html)
    • StaticFilePath should be set to correspond to the URL in StaticPath
  • Take care to set the first website root to a directory other than the MT directory; something like /path/to/mt/html would be ok.
  • Finally, deploy Starman with something like daemontools just like any proper PSGI application (I should put this under a separate note later :)