Giving up on

For years I’ve been bravely maintaining a instance residing at even though the project has some unhealthy red flags, the most important of which are no development community and definitely not even great involvement from its own father.

I think Evan is an awesome guy, but sadly pump did not gain traction. I’m afraid of running web software that is so unmaintained.

I don’t believe it is secure, no software is, specially secure enough to go on for almost an year without patches (and let’s not dwelve on how few there had been previously):

Screenshot from 2015-05-03 14:59:27

It’s not lightly that I do this, and it’s actually with a lot of sorrow that I’m retiring it.

It’s html5 web interface means it’s very hard to make a static version, and I’ve never shared anything so significant in it that I’ll be sad to let it go.

I’ll keep a backup but, I’m sad to say, I simply can’t take it anymore and it’s time for much due housekeeping. 🙁

How to fix your site name

A newbie mistake that is quite easy to do on is to set a name for your instance, then decide to change and… oops, you changed /etc/ but it doesn’t change! WTF!?

In my case I was particularly pissed off because there’s a bug on with certain characters, I had named my instance 1407’s Pumps but apparently doesn’t like that quote there… displayed instead 1407s Pumps. ANGRRRY!

After digging through all keys in my instance, I found out that mine was service:urn:uuid:b0f6e849-4a8b-4b8a-9f3d-1ee221d62d58 (faked uuid), but there may be a lot of service:urn:uuid: entries (234 when I did this)!

Here’s how you can fix it on your database as well (I’m using redis, you’ll have to adjust to your particular case if using another DB).

echo "keys service:urn:uuid:*" | redis-cli > uuids.txt
cat uuids.txt | while read KEY ; do
    echo "set $KEY '$(echo get $KEY | redis-cli)'" >> uuids-set.txt
grep "MISTAKEN TITLE" uuids-set.txt > title-fix.txt

So now you can edit title-fix.txt with your favorite text editor and fix the field displayName to your pleasure, and after saving your change you are now ready to apply it:

redis-cli < title-fix.txt

I doubt restarting is needed, but I did it anyway, you can try. 🙂

Forgot to set email in your Fix it! is an awesome distributed/federated social network, but it’s still green software and has many rough edges. One boring one is that when you’re setting up your instance you may run into the pitfall of not setting your email, and then after you posted more than you’d want to loose by resetting it… you can’t enable requireEmail anymore because you’ll be kept out of your own instance.

Sucks, innit? But there’s a fix, all you need to do is add the email field to your user’s data. In my example I’ll be using redis so your millage may vary according to your choice of databank, but the idea is the same, just figure out what your particular case needs to do to implement the same idea.

You can get your user’s data and fix it like this (note, lines broken for blog display):

redis your.ip.addr.ess:6379> get user:RuiSeabra

redis your.ip.addr.ess:6379> set user:RuiSeabra

So now it’s fixed and you can re-enable requireEmail in your

[rms@pump ~]$ sudo grep -i requir /etc/
    "requireEmail": true,

Raising awareness of

Hey guys, let’s try to expand awareness ok?

  • Do make an effort to post to Public (Evan… grrr…. why can’t we have a default “To:”)
  • Plug your public activity url on your web page like I did here (check the “Follow me…” box on the right)! 🙂
  • Link people’s names on your blog posts to their public activity urls

Come on, just do it! as systemd service

So what’s wrong with this first very basic attempt to start as a systemd service?




This is what’s wrong….

Sep 05 20:49:38 sudo[17482]: rms : TTY=pts/1 ; PWD=/opt/ ; USER=root ; COMMAND=/bin/systemctl start pumpio.service
Sep 05 20:49:38 systemd[1]: Starting
Sep 05 20:49:39 pump[17485]: path.js:360
Sep 05 20:49:39 pump[17485]: throw new TypeError('Arguments to path.join must be strings');
Sep 05 20:49:39 pump[17485]: ^
Sep 05 20:49:39 pump[17485]: TypeError: Arguments to path.join must be strings
Sep 05 20:49:39 pump[17485]: at path.js:360:15
Sep 05 20:49:39 pump[17485]: at Array.filter (native)
Sep 05 20:49:39 pump[17485]: at Object.exports.join (path.js:358:36)
Sep 05 20:49:39 pump[17485]: at getConfig (/opt/
Sep 05 20:49:39 pump[17485]: at main (/opt/
Sep 05 20:49:39 pump[17485]: at Object.<anonymous> (/opt/
Sep 05 20:49:39 pump[17485]: at Module._compile (module.js:456:26)
Sep 05 20:49:39 pump[17485]: at Object.Module._extensions..js (module.js:474:10)
Sep 05 20:49:39 pump[17485]: at Module.load (module.js:356:32)
Sep 05 20:49:39 pump[17485]: at Function.Module._load (module.js:312:12)
Sep 05 20:49:39 systemd[1]: pumpio.service: control process exited, code=exited status=8
Sep 05 20:49:39 systemd[1]: Failed to start
Sep 05 20:49:39 systemd[1]: Unit pumpio.service entered failed state.

An ideas why? Starting from the console with sudo /opt/ works fine.


HOWTO: behind Apache is very interesting, but it used to be very hard to put to work behind a frontend, mostly because of web sockets and being designed to be directly connected.

This means that your nodejs-enabled consumed an IP:port pair and since is an https oriented application (can be run in http but you really don’t want that) that means your https port (who has more than one IP either at home or his VPS?) is now BUSY with one single application… sucks and I gave up for some time and wasted my connection’s IP address at the standard https port.

Meanwhile… Good news, everyone!

I recently came up a new Apache module for web sockets: mod_proxy_wstunnel.

Searching for and wstunnel… it turns out my irrational friend Mark Jaroski also published a note about that! Please note that you may not need to build the module, if you have a recent enough Apache 2.4.x version it may already be there, check your bundled modules!

So here’s my setup: the OpenWRT router forwards port 443 incoming into a frontend KVM guest running Apache httpd which then forwards to some of my sites, one of which is my pump at

The frontend’s web site looks like this:

<VirtualHost *:443>
        CustomLog logs/ common
        ErrorLog logs/
        DocumentRoot /var/www/html/default

        SSLEngine On
        SSLCertificateFile conf/ssl.crt/
        SSLCertificateKeyFile conf/ssl.key/
        SSLCertificateChainFile conf/ssl.crt/startssl-chain.crt
        SSLCACertificateFile conf/ssl.crt/startssl-chain.crt

        SSLProxyEngine On

        <Location /main/realtime/sockjs>
                ProxyPass wss://192.168.x.y/main/realtime/sockjs
                ProxyPassReverse wss://192.168.x.y/main/realtime/sockjs

        <LocationMatch ".*\.(jpg|png|gif)$">
                CacheEnable disk

        ProxyPreserveHost On

        ProxyPass               /       https://192.168.x.y/
        ProxyPassReverse        /       https://192.168.x.y/

And at my KVM guest, 192.168.x.y, I have…

    "driver":  "redis",
    "noweb":  false,
    "site":  "1407 Pump",
    "owner":  "Rui Seabra",
    "ownerURL":  "",
    "port":  443,
    "hostname":  "",
    "nologger":  false,
    "serverUser":  "pumpio",
    "key":  "/etc/",
    "cert":  "/etc/",
    "uploaddir": "/opt/",
    "logfile": "/var/log/",
    "debugClient": false,
    "firehose": "",
    "disableRegistration": true,
    "requireEmail": false,
    "smtpserver": "",
    "smtpuser": "aLoginAtYourServer",
    "smtppass": "some good password",
    "smtpusetls": true,
    "smtpport": 587,
    "smtpfrom": "",
    "secret": "some good secret"

So there you go…