Thursday, October 18, 2018

Mozilla Thunderbird developers once again lose their minds

It's fingers in their ears time over at Mozilla once again.

Got the new Thunderbird 0.60.x release ? Got a load of extensions ? Good luck.

The devs at Mozilla and Thunderbird once again reveal their complete intransigence and blinkered vision.

Here's a really good summary:

In short:

TB 60 decided to jump on the new FF engine, and as Firefox with the 60
release, the following happened:

- TB 60 doesn't have the WebExtension APIs required yet to develop
  FileLink extensions.

  See TB 63
  "should" be the first TB version that includes the required API. At
  the time, the API is still being discussed.

- Despite knowing several extensions won't work with TB 60, they still
  decided to disable "Legacy extensions" by default. Note that,
  contrarily to Firefox, TB extensions won't have *anything* in common
  with other browsers or clients, so there's no rush for "WebExtension"
  compatibility here.

- TB also deliberately changed several APIs with TB 60, which they could
  have avoided. This broke existing "legacy" extensions exactly at the
  worst possible moment.

- Cherry on top, TB also removed the installation of the xpcom SDK,
  which caused Debian to drop most of the utilities *needed* to
  fix/rebuild the extensions.

Just like FF 60, I'm actually mad at how the transition was handled.
TB is clearly understaffed, but there's no excuse for such a poor
release handling. TB 60-62 will require a specific extension just for
the transition period, and that code will have to be trashed again for
TB 63.

'Possibly working in 0.63'? Are they taking the piss or just plain stupid?

I'm sick to the back teeth of the devs. If you dare to criticise you just get banned. Anything that is remotely considerd criticism is called offensive and you get kicked.

How many times I have I seen this?

"we think it is a great idea and you will too"

No we bloody well won't. There is crap and bugs that they have ignored for years.

Mozilla have left Thunderbird in the worst of all worlds. Technically hived off from Mozilla, but still run by Mozilla with an iron fist and with no chance of community input.

Thunderbird is still one of the best independent email clients around. It is just a crying shame that the management suck. Big.

Tuesday, June 12, 2018

Gitlab reverse proxy with Apache and https behind router/firewall

Lordy I struggled.

I just could not get this running.

I wanted a single machine running an instance of Gitlab behind a gateway firewall. Not too bad if you want to accept the http defaults, but who the hell wants to use plain old http these days ?

Gitlab config is messy and this particular issue is not very well explained IMHO. But anyways, here is how I did it. I am assuming you know what you are doing here.

I had Gitlab running, but like many I struggled with the reverse proxy. I am grateful to this post which finally helped me unravel things. It was a bit out of date as it was for Apache 2.2 and not 2.4 I think (the proxy lines gave an error) but it pointed me in the right direction:

This method leaves Gitlab running it's own version of nginx with SSL and reverse proxying Apache to that. It is simple and works.

First, get your ducks in a row.

I decided to use Devuan. A bit of systemd free goodness :-)

I am going to use an external port of 8443 with apache then reverse proxying that to the Gitlab port on 4443 Make sure you have the port forwarded on your firewall. I also suggest adding some iptables on your server just for good measure so allow the right ports there too.

So install Devuan (ASCII), gitlab-ce (cheat and use the debian repo) and apache

For gitlab-ce a sources.list file with this - you'll need keys & all that jazz :

deb jessie main

Get yourself a Letsencrypt certificate. They are free. It is pointless not doing this.

You don't need bloatware - use the dehydrated script from here:

Here's my gitlab.rb It lets Gitlab run its own instance of nginx but on a https/ssl port. We will then use Apache to proxy to it.

Here's the gitlab.rb configuration file showing the only uncommented lines.

cat /etc/gitlab/gitlab.rb |egrep -v "(^#.*|^$)"

external_url ''
nginx['ssl_certificate']= "/etc/gitlab/trusted-certs/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/trusted-certs/privkey.pem"

For Apache you will need some modules:

a2enmod proxy proxy_ajp proxy_http rewrite deflate headers proxy_balancer proxy_connect proxy_html xml2enc ssl

I suggest you can hit the Apache instance both internally and externally, using first http and then https.

cat /etc/apache2/ports.conf |egrep -v "(^#.*|^$)"

# http Listen disabled
# Note if you do not add you will get IPv6 only !


cat /etc/apache2/sites-available/gitlab-https.conf |egrep -v "(^#.*|^$)"

        SSLEngine on
        SSLCertificateFile /etc/gitlab/trusted-certs/fullchain.pem
        SSLCertificateKeyFile /etc/gitlab/trusted-certs/privkey.pem
        Require all granted
    SSLProxyEngine on
    ProxyRequests Off
    ProxyPass /
    ProxyPassReverse /
    Header edit Location ^
    RequestHeader set X-Forwarded-Proto "https"

(make sure there is a symlink to sites-enabled)

I basically got Gitlab running in standard mode with no ssl. Then Apache in http mode. Then I finally added SSL to Gitlab and to Apache.

Some handy check commands for ports etc:

netstat -anp |grep apache

netstat -tan | grep 4443

iptables -L -n -v

Hope that helps someone.

Wednesday, November 29, 2017

iPXE boot from tftpd

Why do they keep making life difficult ?

Upgraded to the latest Prox v5 and went to do a test tftp boot. Always worked before. Suddenly faced with a continuously looping iPXE BIOS thingy.

And rubbish documentation on the subject.

All I wanted was a simple 'boot from existing tftpd setup'. Easy. Or not.

So, the answer is easy, ish.

Boot, press Control + B and then type

chain tftp://

No idea how to make this default on Proxmox though.

What is inexcusable is that it can't figure this out by itself and means I have to go wasting time hunting about for stuff.

Grrrrrrrr. Bloody smartarse developers.

Thursday, August 24, 2017

OpenVPN error CRL has expired

I have webmin and openvpn installed.

After an upgrade to openvpn and openssl I recreated certificates and after a bit I got the following error:

error=CRL has expired

I couldn't see how to regenerate the required files in webmin, and on the commandline it kept throwing errors. I did not have easy-rsa installed.

There is some guidance on this eg here:

However, this doesn't help too much. What I did was this open this:


Modify this line to something longer eg 365

default_crl_days= 30            # how long before next CRL

Add the following details from:


to the to openvpn-ssl.cnf file:

# This definition stops the following lines choking if HOME isn't
# defined.
HOME            = .
RANDFILE        = $ENV::HOME/.rnd

# From here

# To here

Now cd /etc/openvpn

openssl ca  -gencrl -keyfile keys/your-server/ca.key -cert keys/your-server/ca.crt  -out keys/your-server/crl.pem -config ./openvpn-ssl.cnf

Restart Openvpn and you should be good to go until the crl_days expire

Thursday, July 20, 2017

Linux Mint 18 RTL8723BE wifi disconnecting

HP 14-an062sa with RTL8723BE

Here's a tail of woe.

A friend asked me to install linux on a W10 laptop. I decided to try Mint.

Installed fine and all was good. Except complaints that the wifi kept disconnecting etc.

On inspection it clearly did, and it appear the kernel driver for version 4.4.x does not work correctly. There are lots of posts on this and how to download and compile the Realtek driver.

Unfortunately on upgrade to the 4.8.x kernel it all breaks again and will not compile. Allegedly the kernel includes a newer version of the driver.

I unloaded and reloaded it, but again the usual tales of woe.

I tried the suggested ant_sel=2 and that was a fail.

Eventually out of desperation I tried ant_sel=1 and Lo ! the damn thing fired into life.

To persist across reboots do the following

echo "options rtl8723be ant_sel=2" | sudo tee /etc/modprobe.d/50-rtl8723be.conf

That should fix it.

Monday, February 6, 2017

Mongod logrotate failure

I had an issue with rocketchat and mongod with RedHats SCL version of mongod. Basically mongod failed when it tried to rotate its own logs which then caused rocketchat to fail.

There are a number of sources on line for this notably here:

Here is my (apparently) successful version:

 cat /etc/logrotate.d/rh-mongodb26-mongodb  

 /var/opt/rh/rh-mongodb26/log/mongodb/*.log {  
 rotate 10  
 # Original line  
 # /bin/kill -USR1 `cat /var/opt/rh/rh-mongodb26/run/mongodb/ 2>/dev/null` 2> /dev/null|| true  
 # New line  
 /usr/bin/kill -USR1 `cat /var/opt/rh/rh-mongodb26/run/mongodb/ 2>/dev/null` 2> /dev/null|| true  
 rm /var/opt/rh/rh-mongodb26/log/mongodb/mongod.log.????-??-??T??-??-??  

Test with:

 logrotate -v -f /etc/logrotate.d/rh-mongodb26-mongodb  

Sunday, November 6, 2016

Remote debugging pydbgpproxy dbgp.proxy: No server with key

I decided to try and run a debug proxy so I could run multiple connections to xdebug from KomodoIDE.

That has caused a lot of frustration.

First I copied the dbgpproxy files to the server.

I then hacked php.ini as suggested setting the xdebug.remote_host to localhost/ so my php.ini looked like this:

xdebug.remote_enable                   = true
xdebug.remote_host                     =
xdebug.remote_port                     = 9000
xdebug.remote_handler                  = dbgp
xdebug.remote_log                      = /var/log/xdebug.log
xdebug.remote_mode                     = req

Restarted Apache and then I then ran the proxy like this:

root@home php.ini]# python /root/dbgp/bin/pydbgpproxy -l DEBUG
INFO: dbgp.proxy: starting proxy listeners.  appid: 9795
INFO: dbgp.proxy:     dbgp listener on
INFO: dbgp.proxy:     IDE listener on

In Komodo I set the Listening port to 'system provided free port'

I set 'I am listening to a proxy' and added the IP and port of the server

But I kept getting errors:

Failed to start the listener socket on port 9001, error: -1 (the debugger proxy could not be contacted.)

If I tried to debug a file like this:

I would get a proxy error like this:

WARNING: dbgp.proxy: No server with key [users], stopping request

Having tried multiple settings I finally found this page which gave me the clue :

You have to set the proxy like this.

-i proxyserverExternalIP:port you specify in the proxy settings
-d IP:local debug port on the server (set in php.ini)


python /root/dbgp/bin/pydbgpproxy -d -i

And presto ! You can now connect multiple users.