• Strange problems with self-hosted Mattermost? It might be your router’s fault

    I spent the last few days online trying to get Mattermost working on my home server. It looks like a promising replacement for Slack, very polished and professional and the installation process is well documented. The only twist was that, since I’m already running Apache on the server, I figured I’d set it up to also function as a proxy for Mattermost. (The developers apparently favor nginx, whereas documenting usage with Apache rests on the community.)

    Everything seemed to go smoothly, and the web app worked just fine when called locally. But when I tried to access it using my FQDN, it just kept failing with the “We’re having trouble connecting to Mattermost” page staring me bluntly. I’ve lost count how many times I’ve hit refresh only to see that page again and again.

    Today I had a breakthrough when I realized that a statically served JavaScript file was failing to load, and bizarrelly only in Firefox: when I finally fired up Chrome out of desperation, everything was working just fine. With Firefox, or with wget for that matter, trying to load the JS file directly only resulted in loading a fraction of the file, or not at all.

    This was only halfway towards the solution, I still spent hours tearing my hair out until I finally figured out the root of the problem: my home router doesn’t do NAT loopback.

    After I pointed my FQDN to the home server in my desktop’s hosts file, the static JS came through in Firefox just as easily as it had in Chrome. (I shudder to think what it is that Chrome does that made it able to circumvent the problem.)

    Now, I did try to access Mattermost from outside my home network previously, but being utterly disorganized in my debugging, I apparently had mangled the Apache configuration for the site each time I did those tests. With both the correct Apache configuration and the local hosts file fix in place, the FQDN works from inside the home LAN as well as from outside.

  • gnome-session: Expression error: unknown function bitrate()

    The problem: my syslog is full of these three lines repeating

    gnome-session[3926]: Expression error: unknown function
    gnome-session[3926]:  Net: down  $ ( bitrate ( net.down ) ) , up  $ ( bitrate ( net.up ) )
    gnome-session[3926]: ---------------^

    So bitrate() is unknown.

    The message is caused by the System Load Indicator (indicator-multiload), and more specifically a non-default value of the indicator-expressions key in the de.mh21.indicator-multiload.general schema. The value I had somehow managed to set there was:

    ['', 'Mem $(size(mem.user))', 'CPU $(percent(cpu.inuse))', 'Net $(bitrate(net.down))/$(bitrate(net.up))', 'Swap $(size(swap.used))', 'Load $(decimals(load.avg,2))', 'Disk $(speed(disk.read))/$(speed(disk.write))']

    The default value, as I read it from /usr/share/glib-2.0/schemas/de.mh21.indicator-multiload.gschema.xml just now, is

    [ "", "CPU $(percent(cpu.inuse))", "Mem $(size(mem.user))", "Net $(speed(net.down))/$(speed(net.up))", "Swap $(size(swap.used))", "Load $(decimals(load.avg,2))", "Disk $(speed(disk.read))/$(speed(disk.write))" ]

    So the correct function to replace bitrate() is speed().

  • The Google browser

    Looks like I’ve failed to mention that alongside the disposable Firefox I’m now using a regular Chrome window for all things Google. That means my Gmail, Google Calendar, Google+, some of my Hangouts use and age-verification requiring YouTube-viewing now happens within that profile.

    This has freed me from having to sign in to Google in the disposable Firefox. It was a bit of hassle because of 2FV, but to be honest, I’m sure I could have lived with it; what I think this was more about was the satisfaction from dividing the uses between the two browsers: Google’s browser for the Googly stuff, disposable Firefox for everything else.

    I’m still using Android on the mobile side, and prefer to use Chrome there because pretending to gain any privacy from alternatives would be just that, pretense. So the divide on the desktop follows this reasoning, to maintain the strong mental association of Google’s services to Google’s browser. I also picked Chrome proper instead of Chromium for this reason: I don’t see any point in pretending to be safe from Google’s prying eyes when using their services, signed in.

    There’s one (perhaps notable) exception among those services: if I use Google to search things, I use Firefox. For me, search benefits from my being signed in mostly only on the mobile (where I do often want to repeat earlier searches to save typing), on the desktop not so much. And on the desktop, searching on Google proper is the exception for me, I usually just use Startpage.

    On Chrome’s side (on the desktop), my use is pretty strictly limited to the Google services I listed. That means that any external links within those services I will copy and paste into a Firefox instance. Thankfully, of those services, Hangouts is currently the only one using redirect URLs causing some extra hassle. The same issue is much more severe on Twitter, which goes to irritating lengths to obscure the original addresses behind their stupid shortening service. It’s one of those issues I previously would have fixed simply by installing an add-on, but now have to contemplate whether those links are worth manually decrypting, or even the site worth browsing at all because of the irritation that it causes.

    I should also mention that I’ve extended the disposable profile idea to Chrome, so that I can launch a disposable Chrome window (alongside the main profile) from Unity’s launcher. (Unlike Ubuntu’s Chromium package, the Google-provided .desktop for Chrome did not provide this function out of the box.) This is mainly to have a browser with Adobe Flash for the few remaining sites I still occasionally deem worth having it on (I can only think of one off the top of my head).

  • HTTPS, HTTPS Everywhere

    During this past week (IIRC, could have also been last week) I installed the first two add-ons to my disposable Firefox profile: the first was HTTPS Everywhere (from the EFF), the second was HTTPS By Default. Both installations started out as experiments, but there have been no issues and so I’m going to continue with them for the time being.

    HTTPS Everywhere goes slightly against my starting premise of “take sites in as they come, or stop using them if they’re unbearable as such”. But in theory, it shouldn’t influence the end-user experience very much, so I should still feel equally at home in other casual setups I might be using the web on. The add-on should just help to give me slightly better privacy when at home without me having to think about it.

    HTTPS By Default, by contrast, does not go against the premise. Although I will be using HTTPS on some sites I’d be using over plain HTTP outside home (due to failing to remember to explicitly request for https://), the purpose here for me is just the opposite: to become aware of sites that fail to present themselves over https, by forcing me to explicitly request them over http://. (The add-on causes such sites to fail hard when requested without a protocol.)

    Installing these two add-ons was prompted by my successful deployment of Let’s Encrypt on my own sites, which means I no longer have to make exceptions for them. Those exceptions would have been pretty big as my sites make up a big portion of my web use.

    (Sidebar: I didn’t realize it had been such a long while since the last post, but the fact that I had trouble remembering the blog’s name should have been a hint. But for this blog, “no news is good news” basically holds true; it means my setup continues to Just Work.)

  • Fixing a Bluetooth headset to A2DP mode (Ubuntu 14.04)

    I had a nice pair of Jabra Revo Wireless headphones to toy with, and getting them to work in A2DP (the quality mode better suited for music) on my desktop computer turned out to be a bit more than just plug ‘n’ play, so I’m writing this down for future reference.

    Pairing the headphones with my Bluetooth adapter (“ISSCEDRBTA”; one of those cheap thumbnail-sized dongles, I don’t even know whether it does BT 3.0 let alone 4.0) went without problems in both Ubuntu 12.04 and 14.04 so I’ll not cover that here. What became a problem was switching the headset to A2DP (“high fidelity”) mode in system sound settings: it just wouldn’t switch over, instead causing the settings window to freeze and/or crash, or at best just revert back to HSF/HFP (telephony mode).

    After scratching my head for quite a while I finally figured out the reason behind this: on sound settings’ input tab the headset, when connected, was the only listed input device. Apparently this always locked it into telephony mode (either on the headset side or Ubuntu’s Bluetooth stack, I don’t know the intricacies) and prevented it from switching/being switched to A2DP. The way I verified my initial suspicion of this was by plugging an analog microphone into the computer, at which point I was immediately able to switch the headset to A2DP without problems.

    For first aid I stuck an adapter plug into the rear microphone port to have Pulseaudio think I have an analog microphone always attached. But turns out there’s a slightly more elegant solution, at least if you’re not going to use your headset for telephony at all (like me): adding a Disable=Headset line to the [General] section of /etc/bluetooth/audio.conf (and restarting the Bluetooth stack afterwards with `sudo service bluetooth restart`). This way the headset microphone does not show up in sound settings as an input device, and so won’t get selected even when no other inputs are present.

    Overall Bluetooth unfortunately still seems pretty shaky on Ubuntu 14.04. During troubleshooting I had to keep dis- and reconnecting the Bluetooth dongle and turning the headset off and on again to properly reset everything; otherwise even things that otherwise worked would randomly fail. With Android devices the headset Just Works.

  • Stabilized Firefox and search engine switchback

    I now officially take back any bad suspicions I may have cast over Firefox’s stability in the previous post: after I replaced the temporary profiles hack with properly isolated ephemeral profiles, Firefox has been rock solid. I would even venture so far as to say that it’s now more stable than Chromium was for me back when I still used it, though the comparison is slightly skewed to Firefox’s favor by my removing of Adobe Flash at the time of the switch.

    V42 has already been supplanted by V43, and it broke the userChrome tweak I also mentioned in the last post, but in a good way: the irritating, obtrusive full-screen warning pop-up is so much more subtle in V43 that I no longer mind it at all. In fact, I should remove the CSS tweak altogether now that it no longer serves any purpose and, even if it did, doesn’t work.

    Another major change that I made that coincided with the switch from Chromium to Firefox was to move from Startpage to Disconnect.me’s Search page. I first became aquainted with the latter when trying out Tor Browser, which defaulted to Disconnect Search. I felt like experimenting with an alternative so I decided to give it a go as my default in regular Firefox too.

    Unfortunately Disconnect’s results don’t feel as good as Startpage’s do for me. Disconnect apparently employ some kind of quick filtering which is triggered by an immediate (or -ish) return from a site you’ve picked from the search results listing, hiding or lowering the page/site in question from the search results listing from there on. I found it would often degrade my search results near or entirely to uselessness, as I tend to skip back and forth between the results listing and found pages themselves, and only settle for what I deem the best source after sampling a few of the top results. I obviously can’t do that if my search provider keeps hiding the links I’ve visited from me.

    Sometime between the last post and this one Disconnect Search also began to occasionally show remarkably poor results for very basic searches — searches I would then take to Google proper to find that Disconnect had left out a huge portion of raw Google results (I exclusively used Google as Disconnect’s backend). Note that this was not caused by the aforementioned “quick filtering”, as these inferior results would also show up in a fresh, clean Firefox window quite often (that was the first thing I tried when I began to notice these poor results).

    Hence I’ve now returned to Startpage as my search provider. It may very well be that Disconnect could be configured to not do the “quick filtering” thing it does, but I can’t be bothered to investigate the possibility, as switching back to Startpage is a much easier route out of this problem while also resolving the “generally poor results compared to Google proper” issue. (Doing an identical search in clean windows of both Disconnect and Startpage only seconds apart clearly showed Startpage’s superiority in this too.)

  • Instability with V42

    Firefox 42 came and with it my hitherto working hack of clean profiles became extremely unstable. At least, that’s what I’m hoping the instability is due to and not just that FF 42 is in itself so buggy. (It did use to fall down before also quite easily whenever I started messing around in the console, but with V42 it just kept crashing left and right during regular use.)

    So I changed my approach quite drastically in the script: now I’m generating individual temporary profile clone directories from the read-only profile and modifying profiles.ini on the fly. This was actually the way I intended to go about it from the start, but with V<42 I just found that deleting any existing profile (& related cache) directory had little effect on already-running Firefox windows, so I took the shortcut.

    Anyway, a couple of hours of Bash-wrangling and I now think I have it working just as before. It remains to be seen whether this actually has any effect on the crashing problem though.

    I’ve also done one minor tweak in the read-only profile: I added a userChrome.css file to hide the full screen warning.

    @-moz-document url(chrome://browser/content/browser.xul) {#full-screen-warning-container {display: none;}}

    I know it’s a safety measure but god damn is it annoyingly obtrusive.

  • Problem updating the read-only profile after a Firefox update

    Something wicked seems to happen every time I let Firefox update my clean profile and then try to sync it back to my stash. I suspect it’s Owncloud-related (the stash directory is under Owncloud’s sync directory), but anyway, here’s what happens:

    1. I update Firefox. This causes it to check extension compatibility on every startup (because read-only profile).
    2. I close Firefox, manually copy the pristine profile to ~/.mozilla/firefox and start Firefox from the command-line (with -P clean). I let Firefox do its compatibility check thing and close it again.
    3. I rename the old stash directory to have a .O postfix. I then copy (cp -a) the updated profile from ~/.mozilla/firefox to the original stash location. (This is how I created it in the first place.)
    4. I start Firefox with my read-only profile script, and watch it go nuts (search engines are reset, Pocket integration is all fucked up etc.).

    Like I said, the syncing back is no different from how I originally created the profile, and this issue doesn’t always manifest itself. When it does, I have to use some yet-to-be-pinpointed-exactly combination of cp’s, rsync’s, stoppings and startings of Owncloud to make work as intended.

    The irritation this causes naturally correlates with how often Firefox gets updated.

    In other, unrelated news, I finally dropped Tor browser from Firefox’s .desktop file. I simply never used it and it only caused me to accidentally launch it when I just wanted a new disposable Firefox.

  • In Focus

    Time it takes to fully load The Atlantic’s In Focus with Adblock: 5 s. Without Adblock: got tired of waiting at around 2 minutes. Looks like In Focus will be the first of my RSS subscriptions to get the axe due to this.

  • Daily Twitter log-in’s a by-gone

    And just like that, I’ve now ditched daily Twitter logins too. Turns out that Twitter’s lists feature, which I had never used prior to this, is completely analogous to Reddit’s multireddits feature. I set up two lists: one for international people and one for domestic, and again the shortlinks via my own system.

    One aspect of these non-logged-in followings that I haven’t touched upon is the obvious lessening of interaction: it now takes some effort to give someone an upvote, a retweet or a favorite. To be honest, I’m very close to not caring at all. I think I’ve been interactive mostly because the effort involved was so small, and now that the effort is more significant, I just won’t bother.

    I do still get the reflexive urge to interact, but not being able to immediately do so does not leave me yearning. I’m not opposed to interaction per se, but for the most part I also do not value it enough to bother to log in to be able to interact.