Posted on September 6, 2015

So there are now 3 different things happening in this update:

  1. upgrade to yesod-1.4
  2. upgrade to ClassyPrelude
  3. make everything configurable, so parallel instances can be run on a single machine

In retrospect, I should have started with the last item as a single contained change, then attacked the first two. But there you go.

Anyway, here is all the new configury.


Yesod bind details and base URL.


Postgres connection details.


Postgres connection pool size. Default: 10. (Not all components respect this.)


The MX target that is considered local.


The FIFO used to trigger the router. Default: /run/mpv6/trigger


IP address to bind. Supports the usual HostPreference magic values. Default: “*”


Port to bind. Default: 25


The location of the message store.

I definitely want to look at factoring out the “do something with the database” code, because not only is this a complex monad stack that gets repeated in each component (and the library upgrades broke), but the use of database pools is not consistent.

One thing so far not enviroconfigurable is the dspam database. Now, this is wrong, and means my test instance will share some stuff with the real one. (I can possibly bodge around this simply by choosing higher user ids for the test system. I’ll need to remind myself exactly how it works.)

I am considering very strongly the possibility of replacing dspam with bfilter. Not that I think it’s a better filter (I’m sure it’s not, although hope that some tweaks will bring it close). However, I haven’t been finding dspam very satisfactory recently, and at least I can own bfilter. Anyway, that’s really a topic for a separate post.

The conclusion is that I’m not going to bother configuring up all the dspam stuff since it’s going to go away. (Actually, I don’t believe flare knows anything about the dspam database.)