Smokes your problems, coughs fresh air.

Author: halfgaar (Page 2 of 26)

Halfgaar is Wiebe. Wiebe is a contributing author on this weblog. He also has a lot of stuff (such as long, in-depth articles) on his personal website.

Wiebe's day job is as a senior software developer and system administrator at YTEC.

In his free time, he built the free, open-source FlashMQ software. Together with Jeroen and Rowan, he is now building a managed MQTT hosting business around his open masterpiece.

Setting up a Zimbra authenticated proxy

On March 18th, Synacor posted about a critical Zimbra security vulnerability (CVE 2019 9670), which was quick to be exploited in the wild, and subsequently evolved to be harder to erradicate.

I’ve always had a weariness of authentication implementations by hosted applications, so I decided to block the Zimbra web mail interface using iptables (firewall), and only allow access through a separately hosted HTTP proxy which requires authentication. This way, no stray requests to API endpoints accidentally left open will be allowed. That is, almost none: I had to add exceptions to allow webdav traffic for contact and calendar synchronization. If you don’t use that, the exceptions can be left out.

Below is an example Apache configuration. Apache requires several modules to be enabled, which is an exercise left to the reader. Also, a similar proxy is easily implemented in Nginx; I just happened to have a spare Apache server.

Note that it’s best to not make the proxy the default virtual host on the web server. This avoids it being seen by IP probes. If set up properly, there is no trace visible from the outside that you’re using this proxy, and if you make it such that access to it requires the actual domain name (like, it’s very hard for bots to see it (especially if you make the domain name a bit more unguessable).

When you access the web mail page, first you have to authenticate using old style HTTP authentication:


Anyway, here’s the proxy config:

<VirtualHost *:80>
        RewriteEngine on
        RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [L,R]
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        SSLEngine on
        SSLCertificateFile    /etc/letsencrypt/live/
        SSLCertificateKeyFile /etc/letsencrypt/live/
        SSLCertificateChainFile /etc/letsencrypt/live/
        SSLProxyEngine On
        ProxyPass        /
        ProxyPassReverse /
        # For Webdav/carddav/caldav
        <Location /dav>
                Satisfy any
                Require all granted
        # For Let's Encrypt
        <Location /.well-known/>
                Satisfy any
                Require all granted
        # For Webdav/carddav/caldav
        <Location /principals/>
                Satisfy any
                Require all granted
        # For Webdav/carddav/caldav
        <Location /SOGo/>
                Satisfy any
                Require all granted
        # For Webdav/carddav/caldav
        <Location /groupdav.php>
                Satisfy any
                Require all granted
        <Location />
                AuthType Basic
                AuthName "Zimbra webmail pre-login"
                AuthUserFile /etc/apache2/htpasswd/webmail
                Require valid-user
                # Exception IPs: no auth needed (for monitoring for instance)
                Require ip
        ErrorLog ${APACHE_LOG_DIR}/
        CustomLog ${APACHE_LOG_DIR}/ combined

Git and Tig config base

Here’s just a quick .gitconfig:

        commentchar = %
[tig "color"]
        date = cyan black bold
        diff-header = cyan black
        ignore-case = yes

The colors are to make it readable on Windows Git Bash, because the dark blue is impossible to read.

And yes, I still have to set up my dotfiles github stuff.

Attempt to repair short on motherbord

At work, we had a small embedded PC that had a short in the mainboard. I attempted a fix, mostly for educational purposes. It wasn’t successful, but I wanted to post the method and result anyway. The method I used is elaborately explained on Youtube, so go hunt there for more details.

First I wanted to find the short. I opted for the method of connecting a current limited power supply and slowly cranking up the current till I can feel something heating up. To do so, I had to solder some wires to the input power jack first.

I set the supply to 1V and and started increasing the current. Given that small resistors have a rating of 250 mW, a 0.25 to 0.5 amps, giving 0.25 to 0.5 W, should be safe enough to gently heat up the shorted component. In the end, I had to increase the current to about 1.5 amps to detect a rising temperature.

I removed the cap in question:

Then I replaced it with hack (because I had no SMD parts here):

The short was gone, but it still didn’t power up. Then I gave up.

Nginx maintenance page

Just some example code for an nginx maintenance page:

server {
  listen 80;
  listen 443 ssl;
  ssl_certificate_key /etc/ssl/temp/;
  ssl_certificate /etc/ssl/temp/;
  location = /503.html {
      root /srv/http/maintenance/;
  location = /logo.png {
      root /srv/http/maintenance/;
  location / {
      if ($remote_addr != {
        error_page 503 /503.html;
        return 503;

Softstarter (ballast start) relay charred after years of use

This is an interesting case. I made a sound system for a friend in 2012. In it is a soft-starter, that engages the heavy transformer through a ballast, so that the fuse doesn’t trip. This is it:

Up until today, I never knew he had to replace the fuse a few times a year. The reason I found out now, is because the amp wouldn’t start anymore; it would always blow a fuse. So, I was called in to repair.

This is the relay now, with charred contacts:

One initial thought of course is that the amp was turned off/on super quick, so the relay didn’t have time to disengage, subsequently connecting the mains directly to the unstabilized transformer. However, my softstarter design can handle quick off-on (although not super quick, I just tested), and he was adamant that it often happened after hours of off-time, and being careful not to bounce the switch.

My theory is that the mains AC sometimes arced over the relay on turn-on, so that the ballast would be bypassed, obviously blowing a fuse. This arcing slowly wore out the contacts, and probably made it more susceptible, ultimately resulting in always arcing. However, I use the exact same design in my own builds, and I never have this problem.

The relay is rated for 250 Vac, 30 Vdc. But perhaps with the mains in the right position, the transformer acts as a fly-back.

Interestingly, the relay contacts still read near-zero Ohms, and there is little to no voltage over it with when I test it with my 30V, 3A bench supply.

I now replaced it with a nifty relay (Amplimo LRZ) that has a wider gap, and tungsten pre-contact:

I’ll report back in a year how it held up.

« Older posts Newer posts »

© 2024 BigSmoke

Theme by Anders NorenUp ↑