If you’ve used putty to generate your private key, you may need to convert it to a PEM file instead

Firstly install putty via Homebrew

$ brew install putty

Then convert the file

$ puttygen privatekey.ppk -O private-openssh -o privatekey.pem

Install the key by moving the file to ~/.ssh

$ mv privatekey.pem ~/.ssh

The latest docker:dind has breaking changes. Here are two fixes if you are enchanting issues with GitLab CI and your runners.

Fix 1: GitLab CI Config

Add the following to your .gitlab-ci.yml

variables:
    DOCKER_TLS_CERTDIR: ""

Fix 2: Change runner config

Alternatively, another fix is to change the runner:

$ nano /etc/gitlab-runner/config.toml

Modify to mach the following (specifically environment and volumes)

[[runners]]
  environment = ["DOCKER_DRIVER=overlay2","DOCKER_TLS_VERIFY=1","DOCKER_CERT_PATH=/certs/client"]
  [runners.docker]
    image = "docker:dind"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache","/certs"]

Then restart the gitlab runner

If you need to proxy your Wordpress blog via Nginx. This is the configuration I have recently used.

Update <server-name> with your intended domain name. <ip-address> and <port> with the Wordpress servers details.

server {
        server_name <server-name>;

        gzip on;
        gzip_min_length 10240;
        gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
        gzip_disable "MSIE [1-6]\.";

        add_header Cache-Control public;

        location / {
                proxy_set_header X-Real-IP  $remote_addr;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header Host $host;
                proxy_pass http://<ip-address>:<port>;
        }
}

To test your Nginx configuration files, run the following command:

nginx -c /etc/nginx/nginx.conf -t

It will indicate if your configuration file syntax is correct.

Configuration Check Failure

root@proxy:/etc/nginx/sites-enabled# nginx -c /etc/nginx/nginx.conf -t
nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/test01:2
nginx: configuration file /etc/nginx/nginx.conf test failed

Configuration Check Success

root@proxy:/etc/nginx/sites-enabled# nginx -c /etc/nginx/nginx.conf -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Like most of the code I write these days in my spare time, It’s usually for a little bit of fun! This time, I just wanted to get a random bunch of images from Imgurl.com to collect some “memes”. I’ll warn you now, the internet is not a nice place. People upload all sorts of random stuff to Imgurl. Be warned!

Let’s get technical!

Firstly, I decided to use Python 3 on an EC2 micro (AWS virtual server). Secondly, it was written in about 10 minutes. I’m sharing it for future use (if anyone dares find a legitimate reason for using it). Plus I just wanted a reason to embed GitHub’s Gist into my blog!

This weekend, I decided to attend Hack The North organised by the DWP Digital Team. A two-day event where like-minded people gathered together to identify and attempt to address the difficulties or hardships that individuals face when using support services offered by organisations in and around Manchester. This all-night event allows attendees to pitch their ideas and collaborate with others to implement a proof of concept which addresses these important issues.

Last brain dump of today. Here’s some quick commands to stop running docker containers and also clean up afterwards (remove container files, and images).

Stop all containers:

docker stop $(docker ps -aq)

Remove all containers:

docker rm $(docker ps -aq)

Remove all images:

docker rmi $(docker images -q)

Another brain dump for future reference. This is when setting up gitlab to build and run docker images when the CI/CD pipeline runs.

Install gitlab-runner

On a linux x86-64 download the gitlab-runner package:

sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

Give it permissions:

sudo chmod +x /usr/local/bin/gitlab-runner

Install docker:

curl -sSL https://get.docker.com/ | sh

Create the gitlab-runner user:

sudo useradd –comment ‘GitLab Runner’ –create-home gitlab-runner –shell /bin/bash

Install gitlab-runner:

sudo gitlab-runner install –user=gitlab-runner –working-directory=/home/gitlab-runner

If you are seeing the following error in the exim logs, you will need to reset the exim databases.

“The Exim database is most likely corrupted and the following steps should be followed”

To reset exim’s database of retry, reject, and wait-report_smtp attempts on cPanel, I find the safest way is to run the following commands.

/usr/sbin/exim_tidydb -t 1d /var/spool/exim retry > /dev/null /usr/sbin/exim_tidydb -t 1d /var/spool/exim reject > /dev/null /usr/sbin/exim_tidydb -t 1d /var/spool/exim wait-remote_smtp > /dev/null service exim restart

Another little fix for a issue I came across this week relating to CloudLinux’s LVEstats2

I had a server running 100% CPU, and doing an huge amount of read/write I/O - causing issues with the SAN shelf. After looking at top, I noticed the LVE process (which collects usage data on users) was consuming most of the CPU, and having a lot of read/write to the disk.

After some investigation, and looking at the lve sqlite database (/var/lve/lvestats2.db) it was apparent that LVE wasn’t updating the database correctly, and we can assume the database was corrupted. So I could then assume that users were not being restricted, and being able to abuse all the resources available - enhancing the issue further.