Why a separate Internet mode

ShimmerCat has two top modes, “devlove”, and “Internet”. Devlove mode is always available, and Internet mode is available by request.

The mode is a mandatory argument of the command line, and it allows the user to state his intention when running the software. Devlove mode should support developers while they code and test their applications, and internet mode should make easy and secure to deploy websites on the Internet.

$ shimmercat internet -h
A master mode for monitoring workers and running in the Internet

The two use cases have sometimes contradictory goals. When an application is being developed, developers need to see as much information as possible, even when that information is presented in the webpage being served. Think about pages with status code 404 and 500 reported from Django for example. However, the same information can prove to be too sensitive for public eyes, which are likely to access the site through Internet mode.

In this documentation page, we detail the features of Internet mode in ShimmerCat.

Breaking with tradition

Unix has a long tradition of running services on the Internet. For that purpose, the most sophisticated and used variant of Unix is Linux, whose latest editions come with some fantastical features. These modern features often do things different, and we think that’s for the better.

As a rule, we have embraced the new ways of doing things, and in this article we explain what we mean.

Should we stick more to tradition?

(No) Fork gymnastics

Internet mode is a simple worker manager

When shimmercat internet is run, the first process creates a few worker children, and an instance of Redis (bound to a unix socket). Children use the Redis instance to exchange information and to send log messages to the parent process or any other logs agent.

Every few minutes, workers undergo apoptosis and are re-spawn by the original process. The time interval for the apoptosis is random and always greater than 15 minutes, so there should always be a few worker processes alive and handling requests.

Note that each worker can handle an unlimited number of concurrent sessions and requests, the only limits being CPU, RAM and I/O resources. We launch multiple workers in Internet mode to profit better from multi-core architectures and to have increased redundancy.

No fork gymnastics to become a daemon

Classical internet servers do a lot of tricks to become daemons. But modern system supervisors like SystemD, Upstart and Supervisord can do that on behalf of the service. We think that modern supervisors do an outstanding work, and therefore do not support process daemonization from inside ShimmerCat.

We however check if stdout is a tty, and if it is not, suppress the ANSI escape sequences for colors.

No fork gymnastics to share a port

We just set SO_REUSEPORT in all ports we bind to.

No fork gymnastics to drop privileges

We do not drop privileges.

ShimmerCat can run as an unprivileged user, just by indicating such user to the supervisor (Systemd, Supervisord, Upstart, etc). To bind directly to ports 443 or 80 without being root, you can use setcap:

setcap cap_net_bind_service=+ep `which shimmercat`

Most of ShimmerCat is written in Haskell, and that mitigates the risk of privilege escalation attacks based on buffer overflow.

To strengthen the security of your setup, we recommend using either containers (e.g. Docker) or any of Cgrups, AppArmor or SELinux.

Let us know what do you think

Redirects from HTTP at port 80 to HTTPS at port 443

ShimmerCat doesn’t serve sites over plain HTTP. But there is a common use case for still listening to plain HTTP requests, namely redirecting users from to

To enable listening for plain HTTP requests and doing redirects on them, simply use the the -t option followed by a local network address to bind to, or a wildcard address. E.g: shimmercat internet -t

For enhanced security, connections on the HTTP to HTTPS redirects port are shutdown as soon as ShimmerCat finishes sending the redirect response, or after three seconds, whatever happens first.

One certificate per ShimmerCat’s instance

You can run different virtual domains simultaneously with ShimmerCat, the only restriction being that they use a common certificate.

Which questions we didn’t answer?