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 https://packages.gitlab.com/gitlab/gitlab-ce/debian/ 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 'https://gitlab.example.com:4443'
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 "(^#.*|^$)"

        ServerName gitlab.example.com
        SSLEngine on
        SSLCertificateFile /etc/gitlab/trusted-certs/fullchain.pem
        SSLCertificateKeyFile /etc/gitlab/trusted-certs/privkey.pem
        Require all granted
    SSLProxyEngine on
    ProxyRequests Off
    ProxyPass / https://gitlab.example.com:4443/
    ProxyPassReverse / https://gitlab.example.com/
    Header edit Location ^http://gitlab.example.com/ https://gitlab.example.com/
    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/mongod.pid 2>/dev/null` 2> /dev/null|| true  
 # New line  
 /usr/bin/kill -USR1 `cat /var/opt/rh/rh-mongodb26/run/mongodb/mongod.pid 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.

Tuesday, October 18, 2016

UK Privacy does not exist

Why Privacy is important

We live in a supposedly democratic state under the rule of law.

That law is quite clear. You are innocent until proven guilty.

If you have allegedly committed a crime then it is up to the powers of law enforcement to find the evidence to support their allegations.

In normal life you do not expect to be followed and surveyed 24/7 just in case you may commit a crime. You have an inalienable right to privacy. You are presumed innocent until proven guilty.

The problem with online surveillance (and this includes 'legal' sites such as Google, Facebook etc) is that you can't see it, so people do not consider it important. But it is as much an invasion of your privacy as having a policeman following you all day everyday, just in case you commit a crime.

Think about it like this.

Your daughter decides to go shopping. As she leaves the house, the policeman who has been assigned to her 24/7 follows along behind noting her every move. She meets her friends. Who are also followed by their officers.

Because she has her location services on her every movement is being tracked. She uses her messaging service to chat to friends. The messaging service takes all her contact details. Which would be fine if the people who had given her their details were happy for a third party to take them without their consent.

They stop at a map of the shopping centre where a guide (think Google 'cookie') kindly shows them where various shops are, and points out all what the guide thinks are the best deals (for which they get commission). As they head off to the shops, the guide follows them noting their every move, and helpfully adding suggestions as they go.

They pop into a store. The store assigns them a watcher (think 'cookie') who follows and notes their every move. When they leave the shop the follower is in tow, all the while noting their every move. As she has wifi on her phone and , even without logging on, her movements are tracked and her details are passed to other shops who rush to add their followers, even though she has never been in their shops. If she logs on to the wifi then the wifi station will then watch every piece of data flowing through which is also passed to numerous third parties.

They go to another shop, browse and buy something. The bank assigns a follower, who happily advises them of all the great banking deals they can avail themselves of and, as they can then track them to individual shops, can offer specific deals. The shop also assigns them another follower. The goods have a RFD tag, which can register in other shops as they browse, even if they have no intention of buying.

After some more browsing, and a bite to eat they arrive home. With a policeman, a spy, and numerous followers, all with their clipboards and wanting to bed down for the night so they can continue to watch her every move. They know where she lives, and where you live, and in the morning they are going to be following you too.

If you opened the door to see that, what would your reaction be ? Your daughter has done nothing wrong, and broken no laws. The issue is you cannot physically see it happening. That does not for one moment make it right.

Living your life like that in a permanently watched police state is what happened in the Eastern Bloc during the cold war. It still happens in numerous countries throughout the world. North Korea, China etc. You think the UK is any different ? It is not.

The UK population is one of the most watched populations on earth, from CCTV through to bulk internet surveillance. No, it may not be a physical presence, but it is a presence nonetheless. Just because you cannot see it does not mean that it is not there. You breathe, but cannot see the air. Surveillance is the same.

If you want to live in a nation where you are presumed guilty from the start then just carry on.

Personally I don't.