This new version of the Hiawatha Monitor has an improved dashboard, an hourly graph for the day overview and a setup module for easy installation.

To upgrade from v1.2, simply replace the v1.2 code with this one and request the page /setup. This will take care of the database upgrade.

Tags: Monitor
by Hugo Leisink

The responses to my previous weblog article made me think about centralized configuration a lot. I've decided not to implement database support in Hiawatha. That's simply too much work, adds too much complexity and makes Hiawatha too much bloated. I also don't like the idea of constantly connecting to a database for every request. The whole idea simply doesn't feel right.

So, what else? Before explaining my new idea, I just want to make clear that the original way of loading the configuration from a file will always be available. That will never change. Any centralized configuration storing will just be an extra option. Now, back to my new idea. Instead of using database connections, I can make use of the type of connections Hiawatha already knows best: HTTP. What if the local configuration file only contains a single option which tells Hiawatha to which webserver it can connect to to retrieve its configuration? Hiawatha connects via HTTP(S) to that webserver, downloads the configuration file and handles it like it was loaded from a file. That's not hard to implement.

Now the changing of the configuration without restarting the webserver. Simply reloading the configuration is not an option. It's simply too complex. What to do with the old configuration upon reload? It's very likely still in use for the current connections. What to do with changes in binding configuration? Kicking all clients after configuration reload is the same as a restart. This whole configuration reloading is simply asking for trouble, so I won't go that way.

My biggest question in all this is: how bad is restarting a webserver really? Those 2 seconds offline time, does it really hurt anybody? And how fast does a new website need to be online? What can be done is a cronjob that checks every night for a configuration change and restarts the webserver if so. Is that acceptable? If so, the solution is simply. It's like I just described. If not, there are some options, but I haven't figured out which I think is best.

One option is to use some sort of dynamic virtual host configuration. A special configuration option points to a directory, in which each subdirectory is named after its virtual host. So, simply adding a new directory adds a new virtual host. This works only if a new website is comparable to the other websites (same URL toolkit, same FastCGI daemon, etc). Otherwise, adding the extra configuration options for that new virtual host makes it all more complex.

Another option I thought of is to make the centralized configuration server use some sort of POST request to the webserver, with the new virtual host or URL toolkit as the request body. This makes it more flexible than the first option, but making sure the configuration that has been pushed to the webserver is in sync with the one stored in the database adds extra complexity.

Both options can be implemented as an extra feature of the Hiawatha Monitor. That way you have a centralized tool to maintain your webserver configurations and to keep track of their performance and status.

Although there is still a lot to think of and to work out, I like the general idea of it a lot more than the previous idea (using database connections). This simply feels more right. I'm really interested in your thoughts about this idea.

by Hugo Leisink
26 July 2015, 11:57

In the past, I've playing with the idea of using an SQL database to store parts of the configuration, so one can add, change or remove website configurations without restarting the webserver. Recently, someone also asked about this in a forum post. This opion might also be usefull for people who own a lot of webservers.

There are of course many ways to implement this. A separate configuration for each webserver, multiple webservers using one and the same configuration, temporarily caching of configuration for improved speed, etc. What I'm looking for is people who have experience at maintaining large clusters of webservers who are willing to share their thoughts on this with me.

I started a poll to see how many people are actually interested in this feature. Hiawatha is not used by many people and this feature will require quite some work to implement. Of course, I won't go through all this trouble if not many people are interested in it.

by Hugo Leisink
26 July 2015, 11:42

Version 9.14 of the Hiawatha webserver has been released. This one brings you mbed TLS v2.0.0. Because of this major change in the SSL library, this version of Hiawatha is no longer compatible with previous versions of mbed TLS / PolarSSL.

In this version, a bug has been fixed that made Hiawatha crash when a very large request (several hundreds of megabytes) was send to a FastCGI server.

Rush to the download page to get your copy.

Tags: releaseSSL
by Hugo Leisink

In Hiawatha v9.14-beta, mbed TLS has been updated to v2.0.0. Because of this change, Hiawatha is no longer compatible with previous versions of mbed TLS. Please, let me know of any issues with this beta release. If I don't hear of any issue, I'll release within a few days.

Tags: releaseSSL
by Hugo Leisink