<h2>Intro</h2>
<p>I wanted a simple way to check a domain's mail configuration: DNS records, SMTP connectivity, TLS, and email authentication, all in one place. That's how <a href="https://github.com/wardpieters/mail-inspector">Mail Inspector</a> started. It's an open-source Laravel application that checks a domain's mail setup, shows what it finds, and suggests possible fixes. You can also <a href="https://mail-inspector.apps.ward.nl">try it out here</a>!</p>
<p>I used AI to build a large part of it, but I didn't want to just give it a prompt and accept whatever came out. I wanted the application to be maintainable, properly tested, and something I could actually host myself.</p>
<p>For this project, I used Codex together with <a href="https://github.com/obra/superpowers">obra's Superpowers workflow</a>. I also used <a href="https://learn.chatgpt.com/docs/security/plugin">Codex's Security plugin</a> to look for potential security issues.</p>
<h2>Tools used</h2>
<p>These are the main tools I used:</p>
<ul>
<li><strong>Codex</strong> to help write, debug, and improve the application.</li>
<li><strong><a href="https://learn.chatgpt.com/docs/security/plugin">Codex Security plugin</a></strong> to scan the code for potential security issues.</li>
<li><strong><a href="https://github.com/obra/superpowers">obra's Superpowers</a></strong> to give the development process some structure, from figuring out requirements to planning, implementing, and testing.</li>
<li><strong><a href="https://github.com/wardpieters/mail-inspector">GitHub</a> and GitHub Actions</strong> for version control, running tests, and publishing container images.</li>
</ul>
<p>What I liked about Superpowers is that it doesn't just jump straight into writing code. It starts by figuring out what you're trying to build, makes a plan, and breaks the work into smaller tasks.</p>
<p>That worked pretty well with Codex. Instead of asking it to build the entire application in one go, I could work through smaller pieces and review what it produced.</p>
<p>Of course, that doesn't mean everything it generated was correct. There were still things that needed fixing, and that's exactly why I wanted tests and a proper workflow in the first place.</p>
<h2>The approach</h2>
<p>I wanted to use Laravel, and I wanted people to be able to host the application themselves. Docker Compose seemed like a good fit for that.</p>
<p>But a mail inspector is a bit different from a typical web application. It needs to resolve DNS records, connect to mail servers over SMTP, check TLS certificates, and deal with all kinds of responses from servers that you have no control over.</p>
<p>I also didn't want to figure out the deployment side of things only after the application was finished.</p>
<p>The setup consists of the Laravel application, Nginx, background workers, a scheduler, PostgreSQL, Redis, and an Unbound DNS resolver. Docker Compose brings everything together, while the internal services don't need to be exposed to the public internet.</p>
<p>I also set up GitHub Actions to test the application and its container setup before publishing images to GitHub Container Registry.</p>
<p>It's easy to get an application working locally and assume it'll work the same way in Docker. But things like queues, DNS resolution, scheduled jobs, and container startup can introduce problems you wouldn't notice by just opening the application in your browser.</p>
<p>Having those checks in place helped catch issues without having to manually test everything after each change.</p>
<h2>The result</h2>
<p>Mail Inspector checks a domain's mail configuration and generates a report with findings and suggested fixes.</p>
<p>It discovers mail servers through DNS, checks SMTP connectivity and TLS, and looks at email authentication records like SPF, DKIM, and DMARC.</p>
<p>There are some limitations to what you can actually verify, though.</p>
<p>For example, having SPF, DKIM, and DMARC records doesn't mean that emails sent from the domain will automatically pass authentication. Those records only tell you what's configured. DKIM can also require a selector that isn't always possible to discover automatically.</p>
<p>The same goes for SMTP. Just because a mail server accepts a recipient doesn't mean the message will actually get delivered. Mail Inspector doesn't send an actual email body, so it can't test the entire delivery process.</p>
<p>I wanted the reports to make these differences clear. If something couldn't be verified, the application shouldn't just mark it as working or broken.</p>
<h2>Where the scanner runs</h2>
<p>One of the things I ran into wasn't really related to Laravel or AI. It was my internet connection.</p>
<p>My home internet provider blocks outgoing TCP port 25, which is exactly what the scanner needs to connect to other mail servers.</p>
<p>That meant I couldn't just run all the SMTP checks from my home server. They would fail because of my own network restrictions, not necessarily because something was wrong with the mail server being tested.</p>
<p>I ended up using an external virtual machine for the scanner traffic, while keeping the web application self-hosted.</p>
<p>There are some other things to consider as well. A connection timeout doesn't always mean the destination mail server is down. It could be a firewall, a routing issue, or something on the scanner's side. And if you want to test IPv6, the scanner also needs proper IPv6 connectivity.</p>
<p>This was probably one of the better examples of why the infrastructure matters just as much as the code. You can write a perfectly fine SMTP checker, but if the network it runs on can't reach the destination, the results won't be very useful.</p>
<h2>What I learned</h2>
<p>A few things I took away from building this project:</p>
<ul>
<li>
<p><strong>AI still needs a process.</strong> Codex can write a lot of code quickly, but that doesn't mean the result is automatically good. Having a plan, smaller tasks, and reviewing the changes made a big difference. Superpowers was useful for that.</p>
</li>
<li>
<p><strong>Working code doesn't mean secure code.</strong> I used Codex Security to look for potential vulnerabilities, but that doesn't replace reviewing the code yourself. AI can introduce security issues just like any developer can.</p>
</li>
<li>
<p><strong>The environment matters.</strong> SMTP checks don't tell you much if the machine running them can't connect to port 25. Where the scanner runs actually affects the results.</p>
</li>
<li>
<p><strong>Docker isn't just about the application container.</strong> You also have to deal with workers, scheduled jobs, databases, queues, DNS, and making sure everything starts and recovers properly.</p>
</li>
<li>
<p><strong>Tests are worth the effort.</strong> Especially for things like SMTP, DNS, TLS, and IPv6. There are plenty of cases where something looks fine locally but behaves differently in another environment.</p>
</li>
<li>
<p><strong>Not every check has a clear pass or fail.</strong> A timeout, missing response, or unexpected SMTP reply doesn't always tell you exactly what's wrong. I think it's better to show what happened than pretend the scanner knows more than it does.</p>
</li>
</ul>
<h2>Conclusion</h2>
<p>Mail Inspector started as a fairly simple idea: build something that makes it easier to check a domain's mail configuration without having to use several different tools.</p>
<p>Using Codex definitely made development faster, but it didn't mean I could skip the usual software engineering work. I still had to think about the architecture, deployment, testing, security, and all the little things that come up when you actually try to run an application.</p>
<p>That's also why I wouldn't really call this vibe coding. I used AI to write a lot of the code, but the process around it was still important. And I think that's a much better way to use these tools.</p>
<p>The project is open source, so feel free to check it out on <a href="https://github.com/wardpieters/mail-inspector">GitHub</a>. Feedback, bug reports, and suggestions are welcome!</p>
<p>You can also try the hosted version at <a href="https://mail-inspector.apps.ward.nl">mail-inspector.apps.ward.nl</a>.</p>


How I didn't vibe code a mail inspector app

<h2>Intro</h2>
<p>I've been moving external services, especially those based outside the EU, to EU-based providers or services I host myself. The goal is to reduce my dependence on non-EU providers, gain more control over my infrastructure, and keep services and data closer to home where possible. I don't necessarily want to eliminate external services altogether, but rather choose European or self-hosted alternatives where it makes sense.</p>
<p>Luckily, I already host a lot at home on my Proxmox server. Compute capacity wasn't a problem I needed to solve, and I didn't need to rent a new cloud server just to make this change. Most of the work involved replacing a handful of supporting services: DNS, authentication, serverless workloads, and object storage.</p>
<h2>DNS: Cloudflare to deSEC</h2>
<p>I moved my hosted DNS from Cloudflare to <a href="https://desec.io/">deSEC</a>. deSEC is operated by a German nonprofit and offers the features I need, including DNSSEC and a REST API.</p>
<p>deSEC has an <a href="https://github.com/caddy-dns/desec">integration for Caddy</a>, so I could keep the certificate workflow I was already using while changing DNS providers. In my experience, DNS changes take a little longer to propagate with deSEC than with Cloudflare. This was easy to accommodate by adding a propagation delay to my Caddy configuration (shown below), giving DNS records more time to propagate before Caddy checks them.</p>
<pre><code>(desec) {
    tls {
        dns desec {
            token {env.DESEC_API_TOKEN}
        }

        propagation_delay 5m
    }
}
</code></pre>
<p>DNS is one of those foundational services I didn't want to self-host, mainly because of the high availability and reliability requirements.</p>
<h2>Authentication: Cloudflare Access to Authelia</h2>
<p>I previously used Cloudflare Access as an authentication layer in front of some applications. <a href="https://www.authelia.com/">Authelia</a> isn't a direct drop-in replacement for that setup, so I had to change how authentication works in my infrastructure.</p>
<p>Instead of protecting applications at the proxy level, I configured them to use Authelia as their OpenID Connect (OIDC) provider. The applications are now publicly reachable, but users must authenticate through Authelia to access protected functionality.</p>
<p>Authelia also supports proxy-level authentication through Caddy's <code>forward_auth</code> directive, but I chose OIDC because it allows authentication to be handled directly by the applications.</p>
<p>This gives me more control over authentication, though it also means I'm responsible for operating Authelia and ensuring that each application correctly enforces authentication on its protected endpoints.</p>
<h2>Workloads: Cloudflare Workers to containers</h2>
<p>I also used Cloudflare Workers for a few workloads. I'm gradually moving these to container images built locally and deployed on Kubernetes instead.</p>
<p>This is a different operating model: instead of deploying code to a hosted serverless platform, I build an image and run it on infrastructure I control. Since I already have enough compute capacity at home, I can make that change without adding another cloud compute bill.</p>
<h2>Object storage: Backblaze to Scaleway</h2>
<p>I previously used Backblaze for off-site backups, but I've switched to <a href="https://www.scaleway.com/en/object-storage/">Scaleway Object Storage</a>, an EU-based alternative.</p>
<p>My backups are encrypted, while primary application data remains on my Proxmox server, stored on ZFS. Scaleway serves only as the off-site backup destination, ensuring I still have a separate copy of my data outside my home infrastructure.</p>
<p>This allows me to keep my existing storage setup while moving my off-site backups to a European provider.</p>
<h2>Email is still in progress</h2>
<p>Outgoing email is one part I haven't moved yet. I currently use SMTP2GO as my relay and plan to switch to Scaleway Transactional Email (TEM).</p>
<p>However, TEM doesn't yet support all the features I rely on, so I'm sticking with SMTP2GO for now. I'd rather keep a service</p>


Making my self-hosted infrastructure a little more European

<h2>Intro</h2>
<p>To improve the security of my webserver and mailserver, I made a few changes to enforce HTTPS and restrict TLS protocols, ciphers and signature algorithms.</p>
<p>The webserver is Caddy, which automatically obtains and renews TLS certificates. The mailserver is Mailcow, which uses Postfix for SMTP and Dovecot for IMAP.</p>
<h2>Enforcing HTTPS with Caddy</h2>
<p>Caddy automatically obtains and renews certificates and redirects HTTP traffic to HTTPS. I added an HSTS snippet so browsers remember that the site must only be accessed over HTTPS:</p>
<pre><code class="language-caddyfile">(hsts) {
    header / Strict-Transport-Security &quot;max-age=63072000; includeSubDomains; preload&quot;
}

mail.ward.nl {
    ...
    import hsts
    ...
}
</code></pre>
<h2>Hardening Mailcow</h2>
<p>Mailcow lets me add Postfix and Dovecot overrides in its <code>data/conf</code> directory. These files are preserved as configuration inputs and are applied when the mailcow stack is recreated.</p>
<h3>Postfix TLS settings</h3>
<p>I added the following to <code>data/conf/postfix/extra.cf</code>:</p>
<pre><code class="language-ini">tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION

smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high

smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high

tls_config_file = /opt/postfix/conf/openssl.cf
tls_config_name = postfix
</code></pre>
<p>The <code>smtp</code> settings control Postfix as a TLS client when it delivers mail. The <code>smtpd</code> settings control incoming SMTP connections. Both reject SSLv2, SSLv3, TLS 1.0 and TLS 1.1, leaving TLS 1.2 and newer protocols available.</p>
<p>The explicit cipher list uses authenticated encryption with forward-secret key exchange. <code>tls_preempt_cipherlist</code> lets the server choose the cipher, and disabling compression avoids TLS compression-related attacks. Postfix's <code>high</code> cipher policy is used for the broader SMTP settings.</p>
<p>Postfix also needs an OpenSSL configuration for the signature algorithms used during TLS negotiation. I created <code>data/conf/postfix/openssl.cf</code>:</p>
<pre><code class="language-ini">postfix = postfix_settings

[postfix_settings]
ssl_conf = postfix_ssl_settings

[postfix_ssl_settings]
system_default = postfix_tls_defaults

[postfix_tls_defaults]
SignatureAlgorithms = rsa_pss_rsae_sha512:rsa_pss_rsae_sha384:rsa_pss_rsae_sha256:RSA+SHA512:RSA+SHA384:RSA+SHA256:ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256
</code></pre>
<p>This keeps certificate signature negotiation to RSA-PSS, RSA and ECDSA algorithms with SHA-256 or stronger hashes.</p>
<h3>Dovecot TLS settings</h3>
<p>For IMAP and POP3, I added the following to <code>data/conf/dovecot/extra.conf</code>:</p>
<pre><code class="language-ini">ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
</code></pre>
<p>Dovecot now requires TLS 1.2 or newer and uses authenticated-encryption cipher suites, with DHE suites retained for clients that need them.</p>
<h2>Applying and testing the changes</h2>
<p>After adding the override files, I applied the Mailcow configuration from the Mailcow directory:</p>
<pre><code class="language-bash">docker compose restart mailcow-postfix mailcow-dovecot
</code></pre>
<p>I then checked the HSTS response header:</p>
<pre><code class="language-bash">curl -I https://mail.ward.nl/
</code></pre>
<p>The response should contain the <code>Strict-Transport-Security</code> header. For the mail services, I tested the public SMTP and IMAP endpoints with OpenSSL and verified that old protocol versions are rejected:</p>
<pre><code class="language-bash">openssl s_client -connect mail.ward.nl:25 -starttls smtp -tls1
openssl s_client -connect mail.ward.nl:25 -starttls smtp -tls1_2
openssl s_client -connect mail.ward.nl:993 -tls1
openssl s_client -connect mail.ward.nl:993 -tls1_2
</code></pre>
<p>The TLS 1.0 connections should fail, while TLS 1.2 connections should negotiate successfully. I also checked that normal mail delivery, IMAP login and certificate validation still worked with real clients.</p>
<h2>Problems?</h2>
<p>When a mail client stops connecting after a TLS change, check its supported protocol and cipher suites first.</p>
<p>For Mailcow issues, inspect the Postfix and Dovecot logs after recreating the stack. For HSTS issues, remember that a browser may cache the policy for up to two years, so test on a domain whose subdomains are all ready for HTTPS.</p>
<h2>Sources</h2>
<ul>
<li><a href="https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-harden_ciphers/">mailcow docs postfix</a></li>
<li><a href="https://docs.mailcow.email/manual-guides/Dovecot/u_e-dovecot-harden_ciphers/">mailcow docs dovecot</a></li>
<li><a href="https://caddyserver.com/docs/caddyfile/directives/header">caddy docs</a></li>
</ul>


Hardening Caddy and Mailcow with HSTS and modern TLS

<h2>Intro</h2>
<p>When a GitLab Runner does not have direct access to the internet, the runner, its job containers and Docker-in-Docker all need to know about the HTTP(S) proxy. Setting the proxy only on the runner host is not enough because the CI job and its Docker daemon run in separate containers.</p>
<h2>Prerequisites</h2>
<ul>
<li>A self-hosted GitLab instance.</li>
<li>Docker installed on the machine running GitLab Runner.</li>
<li>A Squid proxy reachable from the runner and its Docker network.</li>
<li>A registered GitLab Runner using the Docker executor.</li>
</ul>
<h2>Running GitLab Runner in Docker</h2>
<p>I run the runner as a Docker container and mount its configuration directory. The registration token is stored in the mounted configuration and is not included here:</p>
<pre><code class="language-yaml">services:
  gitlab-runner:
    image: gitlab/gitlab-runner
    container_name: gitlab-runner
    restart: unless-stopped
    volumes:
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - NO_PROXY=localhost,docker:2375,docker:2376
      - no_proxy=localhost,docker:2375,docker:2376
      - HTTP_PROXY=http://proxy:3128
      - http_proxy=http://proxy:3128
      - HTTPS_PROXY=http://proxy:3128
      - https_proxy=http://proxy:3128
</code></pre>
<p>The runner container needs access to the Docker socket to start job containers. If the runner and Squid container are on different Docker networks, make sure <code>proxy</code> resolves and is reachable from the runner's network.</p>
<h2>Configuring the runner</h2>
<p>In <code>config/config.toml</code>, the runner uses the Docker executor and passes both lowercase and uppercase proxy variables to every job. Some tools only read one casing, so I define both variants.</p>
<pre><code class="language-toml">[[runners]]
  name = &quot;some-gitlab-runner&quot;
  executor = &quot;docker&quot;

  # Make Git use the proxy while the runner fetches the repository.
  pre_get_sources_script = &quot;git config --global http.proxy $HTTP_PROXY; git config --global https.proxy $HTTPS_PROXY&quot;

  environment = [
    &quot;https_proxy=http://proxy:3128&quot;,
    &quot;http_proxy=http://proxy:3128&quot;,
    &quot;HTTPS_PROXY=http://proxy:3128&quot;,
    &quot;HTTP_PROXY=http://proxy:3128&quot;,
    &quot;no_proxy=localhost,docker:2375,docker:2376&quot;,
    &quot;NO_PROXY=localhost,docker:2375,docker:2376&quot;,
    &quot;NODE_USE_ENV_PROXY=1&quot;
  ]

  ... other runner configuration ...
</code></pre>
<p>The <code>pre_get_sources_script</code> is important because Git source retrieval happens before the job's normal <code>before_script</code>. It explicitly configures Git before the runner clones the repository.</p>
<p>The <code>no_proxy</code> list keeps connections to the local Docker service out of Squid. Add any other internal GitLab, registry or service hostnames that should bypass the proxy.</p>
<h2>Passing the proxy to Docker-in-Docker</h2>
<p>Optionally, a job can use the <code>docker:dind</code> service to run Docker commands in a separate daemon. The <code>docker:dind</code> service runs in its own container and does not automatically inherit the job container's environment variables. The <code>pre_build_script</code> creates Docker's proxy configuration before the build starts:</p>
<pre><code class="language-toml">  pre_build_script = &quot;mkdir -p $HOME/.docker/ &amp;&amp; echo \&quot;{ \\\&quot;proxies\\\&quot;: { \\\&quot;default\\\&quot;: { \\\&quot;httpProxy\\\&quot;: \\\&quot;$HTTP_PROXY\\\&quot;, \\\&quot;httpsProxy\\\&quot;: \\\&quot;$HTTPS_PROXY\\\&quot;, \\\&quot;noProxy\\\&quot;: \\\&quot;$NO_PROXY\\\&quot; } } }\&quot; &gt; $HOME/.docker/config.json&quot;
</code></pre>
<p>This writes a <code>config.json</code> in the job user's home directory. Docker uses it when creating containers, so image builds and other Docker operations can use the same proxy settings.</p>
<p>A CI job using Docker-in-Docker can then look like this:</p>
<pre><code class="language-yaml">default:
  image: docker:28.5

variables:
  DOCKER_TLS_CERTDIR: &quot;/certs&quot;
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_VERIFY: &quot;1&quot;
  DOCKER_CERT_PATH: &quot;$DOCKER_TLS_CERTDIR/client&quot;

build:
  stage: build
  services:
    - name: docker:28.5-dind
      alias: docker
  script:
    - docker build --pull -t &quot;$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA&quot; .
    - docker push &quot;$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA&quot;
</code></pre>
<h2>Testing the configuration</h2>
<p>First check that the runner can reach Squid from its Docker network:</p>
<pre><code class="language-bash">docker exec gitlab-runner sh -c 'wget -S -O - https://registry.npmjs.org/ 2&gt;&amp;1 | head'
</code></pre>
<p>Then run a small CI job that prints the proxy-related environment variables and tests both an HTTP and HTTPS endpoint:</p>
<pre><code class="language-yaml">proxy-test:
  image: node:latest
  script:
    - env | grep -i proxy
    - node -e &quot;fetch('https://registry.npmjs.org/').then(response =&gt; console.log(response.status))&quot;
</code></pre>
<h2>Tips and troubleshooting</h2>
<ul>
<li>Add internal GitLab and registry hostnames to both <code>NO_PROXY</code> and <code>no_proxy</code> when they should not go through Squid.</li>
<li>If HTTPS requests fail, check whether Squid permits the destination's <code>CONNECT</code> request and whether the job image has current CA certificates.</li>
<li>Avoid putting proxy credentials directly in <code>config.toml</code>; use protected CI/CD variables or another secret-management solution when authentication is required.</li>
<li>Make sure every application within the CI job is configured to use the proxy, as some tools ignore the environment variables and require explicit configuration.</li>
</ul>
<h3>Problems?</h3>
<p>If you find mistakes or have suggestions, let me know. When troubleshooting, first check the runner's logs and the Squid access logs. You can also run a job with <code>curl -v</code> to see how the proxy is being used.</p>


Configuring GitLab Runner on Docker to use a Squid proxy

<h2>Intro</h2>
<p>I wanted to give my self-hosted servers proper IPv6 connectivity, but my ISP does not provide native IPv6 (<a href="https://heeftodidoipv6.nl/" target="_blank">shame on you, Odido</a>). Instead of replacing my existing network setup, I decided to use Hurricane Electric's free IPv6 Tunnel Broker service.</p>
<p>The setup is fairly straightforward: Hurricane Electric provides an IPv6-over-IPv4 tunnel, and I use a small Debian server as the IPv6 router for the rest of my network.</p>
<h2>Creating the tunnel</h2>
<p>The first step is creating a tunnel through <a href="https://tunnelbroker.net/">Hurricane Electric's Tunnel Broker</a>.</p>
<p>After creating a tunnel, Hurricane Electric provides the IPv4 endpoints and the IPv6 addresses needed to configure it.</p>
<p>I configured the tunnel on my Debian server by creating a new network interface using the <code>v4tunnel</code> method. The configuration in <code>/etc/network/interfaces</code> looks like below. Variables are replaced with the actual values provided by Tunnel Broker displayed on the Tunnel Details page.</p>
<pre><code>auto he-ipv6
iface he-ipv6 inet6 v4tunnel
    address [Client IPv6 address]
    netmask 64
    endpoint [Server IPv4 address]
    local [Client IPv4 address, e.g., the public IPv4 of the Debian server (or local IPv4 if behind NAT)]
    ttl 255
    gateway [Server IPv6 address]

</code></pre>
<p>Once configured, I could verify that IPv6 connectivity through the tunnel was working:</p>
<pre><code>ping -6 [Server IPv6 address]
ping -6 google.com
</code></pre>
<h2>Forwarding protocol 41 on the EdgeRouter</h2>
<p>The Debian router is behind an EdgeRouter X, so the IPv6-over-IPv4 tunnel traffic must be forwarded to the VM. The tunnel does not use TCP or UDP; it uses IP protocol <code>41</code>.</p>
<p>I added a firewall rule on the WAN interface to allow protocol 41 from Hurricane Electric's tunnel endpoint.</p>
<pre><code>firewall {
    name WAN_IN {
        rule 21 {
            action accept
            description &quot;Allow protocol 41 for forwarding&quot;
            log disable
            protocol 41
            source {
                address [Server IPv4 address]
            }
        }
    }
}
</code></pre>
<p>The source address restriction is important because it only allows protocol 41 from the HE endpoint assigned to the tunnel. I then added a destination NAT rule to send that traffic to the Debian VM:</p>
<pre><code>service {
    nat {
        rule 1 {
            description &quot;Forward protocol 41 to IPv6 Router VM&quot;
            inbound-interface eth0.300
            inside-address {
                address [IPv4 address of the Debian VM]
            }
            log disable
            protocol 41
            type destination
        }
    }
}
</code></pre>
<h2>Forwarding IPv6 traffic</h2>
<p>Since the Debian machine is now acting as a router, IPv6 forwarding needs to be enabled in <code>/etc/sysctl.d/80-ipv6.conf</code>:</p>
<pre><code>net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.accept_ra=0
</code></pre>
<p>After enabling forwarding, traffic can flow between the HE tunnel and the internal network.</p>
<p>At this point, a server with an address such as:</p>
<pre><code>2001:470:1f15:4d6::20
</code></pre>
<p>can be reached directly over IPv6.</p>
<h2>Forwarding ports with nftables</h2>
<p>For some services I still wanted the Debian router to act as a simple IPv6 gateway and forward incoming connections to specific servers.
The reason behind this is that not all services are running on the same server, e.g. the reverse proxy is on a different server than the GitLab instance.</p>
<p>I used nftables to accomplish forwarding incoming connections to the appropriate server. For example, to forward HTTP and HTTPS traffic to a web server at <code>2001:470:1f15:4d6::10</code>, I added the following rules to <code>/etc/nftables.conf</code>:</p>
<pre><code class="language-nft">table ip6 nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;
        policy accept;

        iifname &quot;he-ipv6&quot; tcp dport 80  dnat to 2001:470:1f15:4d6::10
        iifname &quot;he-ipv6&quot; tcp dport 443 dnat to 2001:470:1f15:4d6::10
    }
}
</code></pre>
<h2>Hairpinning</h2>
<p>I also wanted connections from inside my network to behave the same way as connections from the Internet.</p>
<p>For example, accessing:</p>
<pre><code>2001:470:1f15:4d6::1
</code></pre>
<p>from the internal network should still reach the web server at:</p>
<pre><code>2001:470:1f15:4d6::10
</code></pre>
<p>I added separate DNAT and SNAT rules for the internal interface to accomplish this:</p>
<pre><code class="language-nft">table ip6 nat {

    chain prerouting {
        type nat hook prerouting priority dstnat;
        policy accept;

        iifname &quot;ens18&quot; ip6 daddr 2001:470:1f15:4d6::1 tcp dport 80 \
            dnat to 2001:470:1f15:4d6::10

        iifname &quot;ens18&quot; ip6 daddr 2001:470:1f15:4d6::1 tcp dport 443 \
            dnat to 2001:470:1f15:4d6::10
    }

    chain postrouting {
        type nat hook postrouting priority srcnat;
        policy accept;

        ip6 saddr 2001:470:1f15:4d6::/64 \
        ip6 daddr 2001:470:1f15:4d6::10 \
        tcp dport 80 \
        snat to 2001:470:1f15:4d6::1

        ip6 saddr 2001:470:1f15:4d6::/64 \
        ip6 daddr 2001:470:1f15:4d6::10 \
        tcp dport 443 \
        snat to 2001:470:1f15:4d6::1
    }
}
</code></pre>
<p>This makes the router handle the connection in both directions.</p>
<h2>Testing the setup</h2>
<p>When debugging IPv6, <code>tcpdump</code> is extremely useful.</p>
<p>For example:</p>
<pre><code class="language-bash">tcpdump -ni any 'ip6 host 2001:470:1f15:4d6::10'
</code></pre>
<p>When an external client connects to the router on port 80, I expect to see the packet arrive through the HE tunnel:</p>
<pre><code>he-ipv6 In
... &gt; 2001:470:1f15:4d6::1.80: Flags [S]
</code></pre>
<p>and after DNAT, leave through the internal interface:</p>
<pre><code>ens18 Out
... &gt; 2001:470:1f15:4d6::10.80: Flags [S]
</code></pre>
<p>This makes it much easier to determine where something is going wrong.</p>
<p>For example, if the packet arrives through <code>he-ipv6</code> but never appears on <code>ens18</code>, the problem is somewhere between the incoming connection and the forwarding decision.</p>
<h2>Conclusion</h2>
<p>Using Hurricane Electric's Tunnel Broker gave me a relatively simple way to add IPv6 to my existing network without changing my ISP or replacing my router.</p>
<p>The nice thing about this setup is that the servers now have proper globally routable IPv6 addresses, while the Debian machine can still be used to forward or NAT specific services when needed.</p>
<h3>Problems?</h3>
<p>If you find mistakes or have suggestions, let me know. If you encounter problems, check the tunnel endpoints, IPv6 routes, forwarding settings and nftables rules. <code>tcpdump</code> can help determine whether the packet reaches the router and which interface it leaves through. Also, make sure the EdgeRouter is forwarding protocol 41 to the Debian router and that your routers and hypervisors firewall rules allow the traffic to pass through.</p>


Setting up IPv6 for my servers using HE's tunnelbroker.net

<h2>Intro</h2>
<p>If you run GitLab in Docker on a host that must route outbound HTTP/HTTPS traffic through a (Squid) proxy, you need to configure the OS, Docker daemon, container environment and GitLab itself. Below are the working configuration snippets I used and important considerations.</p>
<blockquote>
<p>This guide assumes your Squid proxy is reachable at <code>proxy:3128</code> from the GitLab host/container network.</p>
</blockquote>
<h2>1. System environment (Debian)</h2>
<p>Make the proxy available to all processes on the host by exporting the environment variables in <code>/etc/environment</code> so services and systemd units can pick them up:</p>
<pre><code class="language-bash">export http_proxy=&quot;http://proxy:3128&quot;
export HTTP_PROXY=&quot;${http_proxy}&quot;
export https_proxy=&quot;http://proxy:3128&quot;
export HTTPS_PROXY=&quot;${https_proxy}&quot;
</code></pre>
<p>After editing, either reboot or re-source the environment for the running shells/services. Note that some services (systemd units) require <code>Environment=</code> in their unit files or a system-wide drop-in to pick up these vars.</p>
<h2>2. Docker daemon</h2>
<p>Tell the Docker daemon to use the proxy so pulls and other daemon-level operations go through Squid. Add or edit <code>/etc/docker/daemon.json</code>:</p>
<pre><code class="language-json">{
  &quot;proxies&quot;: {
    &quot;http-proxy&quot;: &quot;http://proxy:3128&quot;,
    &quot;https-proxy&quot;: &quot;http://proxy:3128&quot;
  }
}
</code></pre>
<p>Reload and restart Docker after changing this file:</p>
<pre><code class="language-bash">sudo systemctl daemon-reload
sudo systemctl restart docker
</code></pre>
<h2>3. docker-compose / container environment</h2>
<p>Containers also need the proxy variables so processes inside the container use the proxy for outbound requests. In <code>docker-compose.yml</code> I set the environment for the GitLab service:</p>
<pre><code class="language-yaml">services:
  gitlab-ee:
    environment:
      - no_proxy=localhost
      - http_proxy=http://proxy:3128
      - https_proxy=http://proxy:3128
      - HTTP_PROXY=http://proxy:3128
      - HTTPS_PROXY=http://proxy:3128
</code></pre>
<p>Notes:</p>
<ul>
<li>Include both lowercase and uppercase variants (<code>http_proxy</code> and <code>HTTP_PROXY</code>) because some programs read only one of the two.</li>
<li>Add <code>no_proxy</code> for local addresses you want to bypass the proxy.</li>
</ul>
<h2>4. GitLab configuration (<code>gitlab.rb</code>)</h2>
<p>GitLab's runtime (Puma, Sidekiq, Rails) can also pick up environment variables from <code>gitlab_rails['env']</code>. I added:</p>
<pre><code class="language-ruby">gitlab_rails['env'] = {
  &quot;http_proxy&quot; =&gt; &quot;http://proxy:3128&quot;,
  &quot;https_proxy&quot; =&gt; &quot;http://proxy:3128&quot;,
  &quot;no_proxy&quot; =&gt; &quot;localhost&quot;,
}
</code></pre>
<p>After updating <code>gitlab.rb</code> run the normal reconfigure/restart steps for your installation (for Omnibus Docker setups this typically means recreating the container or running the reconfigure inside the container if applicable).</p>
<h2>5. Testing and verification</h2>
<ul>
<li>Check that the host can reach the internet through Squid:</li>
</ul>
<pre><code class="language-bash">curl -v -I http://example.com
curl -v -I https://example.com
</code></pre>
<ul>
<li>From inside the GitLab container, verify the environment and outbound requests:</li>
</ul>
<pre><code class="language-bash">docker compose exec gitlab-ee bash
env | grep -i proxy
curl -v -I http://example.com
curl -v -I https://example.com
</code></pre>
<ul>
<li>Inspect Docker daemon logs if pulls are failing: <code>sudo journalctl -u docker -e</code>.</li>
</ul>
<h2>6. Common issues &amp; considerations</h2>
<ul>
<li><code>no_proxy</code> inaccuracies: Add all internal domains, registry hosts and metadata endpoints (e.g., <code>localhost,127.0.0.1,gitlab.example.com,registry.gitlab.com</code>) to <code>no_proxy</code> to avoid routing local or service-to-service traffic through Squid.</li>
</ul>
<h2>7. Restart and apply</h2>
<p>After making the above changes restart Docker and your compose stack.</p>
<pre><code class="language-bash">sudo systemctl restart docker
docker compose down
docker compose up -d
</code></pre>
<p>Optionally restart the host or re-login to pick up <code>/etc/environment</code> in shells.</p>
<h2>Tips and troubleshooting</h2>
<ul>
<li>If you encounter issues with local services (e.g., GitLab Runner, registry, etc.) not being reachable, double-check your <code>no_proxy</code> settings and ensure that the proxy is not intercepting local traffic.</li>
<li>If you have a firewall or network restrictions, ensure that the GitLab host/container can reach the Squid proxy and that the proxy allows the necessary outbound traffic.</li>
</ul>
<h3>Problems?</h3>
<p>If you find mistakes or have suggestions, let me know. If you encounter problems, check if the proxy is actually being used by the host and container processes, and verify the <code>no_proxy</code> settings for local addresses. Also, make sure the Squid proxy allows the necessary traffic and is reachable from the GitLab host/container network (firewall, DNS, etc.).</p>


Running GitLab behind a HTTP proxy (Squid)

<h2>Intro</h2>
<p>I built a small proof of concept to explore how background tasks can be managed in a React app without prop drilling or external state management libraries. The idea was to create a <code>BackgroundTaskProvider</code> that exposes a simple API for starting, pausing, resuming, and cancelling tasks, along with a hook for components to interact with the task system.</p>
<p>The code for the proof of concept is on GitHub: <a href="https://github.com/wardpieters/react-background-task-provider-example" target="_blank">wardpieters/react-background-task-provider-example</a>.</p>
<h2>What the demo does</h2>
<p>The <a href="https://wardpieters.github.io/react-background-task-provider-example/" target="_blank">demo</a> keeps task state inside a React context so any component wrapped by the provider can interact with the task system.</p>
<p>Each task tracks a few basic fields:</p>
<ul>
<li><code>progress</code></li>
<li><code>isPaused</code></li>
<li><code>isCompleted</code></li>
<li><code>isError</code></li>
<li><code>isCancelled</code></li>
<li><code>error</code></li>
</ul>
<p>The sample app starts a simulated long-running job that increments progress in steps. While it runs, the UI can pause, resume, or cancel the task, and the current task list is rendered directly from context state.</p>
<h2>Provider design</h2>
<p>The core of the proof of concept is the <code>BackgroundTaskProvider</code> component. It stores the visible task list in React state and also keeps a mutable ref for fast task lookups and updates.</p>
<p>That split is intentional:</p>
<ul>
<li>React state drives re-rendering of the UI.</li>
<li>The ref acts as the source of truth for task control flow inside async task runners.</li>
</ul>
<p>When <code>startTask</code> is called, the provider creates a new task ID, stores an initial status object, and immediately starts the supplied async function. The runner receives a small control API:</p>
<ul>
<li><code>getStatus()</code> to inspect the current task state.</li>
<li><code>setStatus()</code> to update fields like progress.</li>
<li><code>shouldPause()</code> to wait while the task is paused.</li>
<li><code>shouldCancel()</code> to stop execution if the task has been cancelled.</li>
</ul>
<p>That gives the task function enough information to cooperate with the provider without knowing anything about the surrounding UI.</p>
<h2>The hook interface</h2>
<p>The <code>useBackgroundTasks</code> hook is intentionally thin. It just reads the context and throws an error if used outside the provider.</p>
<p>That keeps consumer code simple while still making the dependency explicit. Components either live inside the provider and can control tasks, or they fail fast during development.</p>
<h2>How pause and cancel work</h2>
<p>Pause is cooperative. The runner checks <code>shouldPause()</code> and waits in a short loop until the task is resumed.</p>
<p>Cancel is also cooperative, but stricter. The task checks <code>shouldCancel()</code> and throws if the task has been marked as cancelled or removed.</p>
<p>That approach is enough for a proof of concept because it works cleanly with async JavaScript tasks. It also makes the tradeoff obvious: the task must periodically check in with the provider for cancellation and pause state.</p>
<h3>Why not use workers?</h3>
<p>Both Web Workers and service workers can communicate with the UI in both directions, so in theory pause actions could be sent from React and progress updates could be posted back.</p>
<p>I still chose not to use either one for this prototype. The main goal was to keep progress and control state easy to surface in the UI, and that is simpler when the task stays close to the React tree. Workers add message passing, serialization overhead, and a second state channel to keep in sync, which makes pause, cancel, and incremental progress updates harder to reason about for a small demo like this. Service workers also have a different lifecycle and are aimed at network and caching work, so they are not a natural fit for a UI-driven task runner.</p>
<h2>What I learned</h2>
<p>This prototype confirmed that React context is a reasonable fit for task orchestration when the task lifecycle is mostly UI-driven.</p>
<p>The main benefits are simplicity and discoverability. Any component can start or control a task through the same hook, and the UI can render directly from a shared task list. The provider encapsulates the task logic and state management, so components don't need to worry about the details of how tasks are tracked or updated.</p>
<h2>Conclusion</h2>
<p>The proof of concept showed that a <code>BackgroundTaskProvider</code> plus a <code>useBackgroundTasks</code> hook can form a clean, testable interface for background work in React.</p>
<p>If I turn this into a production feature, the next steps would be better task history and stronger error handling. But as a starting point, the architecture already makes the control flow easy to understand.</p>


Managing background tasks with a React context provider

<h2>Intro</h2>
<p>Keeping system time in sync is important for logs, 2FA, and various time-sensitive applications. In this post I will walk through the exact commands I use to enable NTP synchronization on a Debian system.</p>
<h2>Prerequisites</h2>
<ul>
<li>A Debian-based system</li>
<li>Root or sudo privileges</li>
</ul>
<h2>Install and enable systemd-timesyncd</h2>
<p>Install the systemd-timesyncd package, which provides NTP synchronization functionality:</p>
<pre><code class="language-bash">apt install systemd-timesyncd
</code></pre>
<p>Enable the service to run at boot and start it immediately:</p>
<pre><code class="language-bash">systemctl enable systemd-timesyncd.service --now
</code></pre>
<h2>Enable NTP at the system level</h2>
<p>Tell systemd/timedatectl to use network time synchronization:</p>
<pre><code class="language-bash">timedatectl set-ntp true
</code></pre>
<h2>Verify synchronization</h2>
<p>You can verify if NTP is active with:</p>
<pre><code class="language-bash">timedatectl status
</code></pre>
<p>Look for these lines:</p>
<ul>
<li><code>NTP service: active</code></li>
<li><code>System clock synchronized: yes</code></li>
</ul>
<p>If those values are not active yet, wait a minute and run the status command again.</p>
<h3>Problems?</h3>
<p>If synchronization does not start, first check the service status and logs:</p>
<pre><code class="language-bash">systemctl status systemd-timesyncd.service
journalctl -u systemd-timesyncd.service
</code></pre>
<p>Also verify the system has outbound network access to NTP servers (UDP port 123).</p>


Setting up NTP sync on Debian with systemd-timesyncd

<h2>Intro</h2>
<p>While hosting my own GitLab instance, I noticed one Docker container log had grown to about 55 GiB. That was way too much for a single log file and a good reminder to set log rotation limits.</p>
<p><img src="/images/gitlab-log-usage.png" alt="" loading="lazy"></p>
<p>By default, Docker's <code>json-file</code> log driver can grow indefinitely if you do not configure limits.</p>
<h2>Configure Docker log rotation</h2>
<p>Create or edit <code>/etc/docker/daemon.json</code> and add the following:</p>
<pre><code class="language-json">{
  &quot;log-driver&quot;: &quot;json-file&quot;,
  &quot;log-opts&quot;: {
    &quot;max-size&quot;: &quot;100m&quot;,
    &quot;max-file&quot;: &quot;3&quot;
  }
}
</code></pre>
<p>What this does:</p>
<ul>
<li><code>max-size: 100m</code>: rotate when the log reaches 100 MB.</li>
<li><code>max-file: 3</code>: keep 3 rotated files.</li>
</ul>
<p>So per container, Docker keeps about 300 MB of logs (plus the active file), instead of letting logs grow forever.</p>
<h2>Apply the change</h2>
<p>After updating <code>daemon.json</code>, restart Docker:</p>
<pre><code class="language-bash">sudo systemctl restart docker
</code></pre>
<p>On systems without <code>systemd</code>, use the service manager your distro provides.</p>
<p>Important: this only applies to newly created containers. Existing containers keep their current logging settings.</p>
<p>To apply the new logging options to existing containers, you can recreate them. For example, if you are using <code>docker-compose</code>, you can run:</p>
<pre><code class="language-bash">docker-compose down
docker-compose up -d
</code></pre>
<h2>Conclusion</h2>
<p>If you are running self-hosted services like GitLab, setting Docker log limits is one of those small maintenance tasks that prevents big disk usage surprises later.</p>


Keep Docker container logs from filling your disk

<h2>Intro</h2>
<p>Every now and then I attach an extra virtual disk to a VM. This post documents the full flow I used on a Debian-based VM so future me (and you) can mount a new drive without googling the steps again.</p>
<h2>Prerequisites</h2>
<ul>
<li>You already attached the block device to the VM (in my case it shows up as <code>/dev/sdb</code>).</li>
<li>You have root privileges.</li>
</ul>
<h2>Partition the disk</h2>
<p>Run <code>fdisk</code> against the new device and create a single primary partition that spans the entire disk.</p>
<p>Make sure to replace <code>/dev/sdb</code> with the actual device name of your new disk. You can confirm the device name with <code>lsblk</code> if you're unsure.</p>
<pre><code class="language-bash">fdisk /dev/sdb
</code></pre>
<p>Inside the interactive prompt, press the keys in this order:</p>
<ol>
<li><code>n</code> to create a new partition.</li>
<li><code>p</code> to make it a primary partition.</li>
<li><code>1</code> to accept partition number 1.</li>
<li>Press <code>Enter</code> twice to accept the default first/last sector (fills the disk).</li>
<li><code>w</code> to write the changes and exit.</li>
</ol>
<p>If you rerun <code>fdisk -l /dev/sdb</code> you should now see <code>/dev/sdb1</code> listed.</p>
<h2>Create an ext4 filesystem</h2>
<p>Format the new partition with ext4. This wipes any existing data on <code>/dev/sdb1</code>, so double-check the device path before continuing.</p>
<pre><code class="language-bash">mkfs.ext4 /dev/sdb1
</code></pre>
<h2>Create the mount point</h2>
<p>Pick a descriptive directory name for the mount point so you remember what lives there. I used <code>/mnt/big_data</code>.</p>
<pre><code class="language-bash">mkdir -p /mnt/big_data
</code></pre>
<h2>Add it to /etc/fstab</h2>
<p>To make the mount persistent across reboots, add a line to <code>fstab</code>. I still use <code>nano</code> for quick edits, but use whatever editor you prefer.</p>
<pre><code class="language-bash">nano /etc/fstab
</code></pre>
<p>Append the following line to the bottom of the file:</p>
<pre><code>/dev/sdb1  /mnt/big_data  ext4  defaults  0  2
</code></pre>
<p>Save and exit the editor. This tells <code>mount</code> to treat <code>/dev/sdb1</code> as an ext4 filesystem, mounted at <code>/mnt/big_data</code>, and to perform a non-root filesystem check at boot.</p>
<h2>Reload systemd units and mount everything</h2>
<p>Whenever <code>fstab</code> changes, I run a daemon reload so systemd notices the new mount unit. Then mount all entries to verify the syntax.</p>
<pre><code class="language-bash">systemctl daemon-reload
mount -a
</code></pre>
<p>If <code>mount -a</code> returns silently, the entry is good. To be extra sure, run <code>lsblk</code> and confirm the partition shows the mount point you expect.</p>
<pre><code class="language-bash">lsblk
</code></pre>
<p>At this point the VM automatically mounts <code>/dev/sdb1</code> on <code>/mnt/big_data</code> during boot.</p>
<h3>Problems?</h3>
<p>If you find mistakes or have suggestions, let me know. If you encounter problems, first check that the disk is properly attached and recognized by the OS with <code>lsblk</code>. Then review the <code>fstab</code> entry for typos. You can also check system logs with <code>journalctl -xe</code> for any mount-related errors.</p>


Mounting a fresh data disk on a Linux VM

<h2>Intro</h2>
<p>This post describes the process I went through on how to run a self‑hosted GitLab Runner with the Docker executor and Docker‑in‑Docker to build and push container images.</p>
<p>Below you'll find the relevant parts of my GitLab Runner configuration, and an example <code>.gitlab-ci.yml</code> that builds and pushes images to the registry.</p>
<h2>Prerequisites</h2>
<ul>
<li>A self-hosted GitLab instance.</li>
<li>A virtual machine or server to run the GitLab Runner.</li>
<li>Docker installed on the GitLab Runner host.</li>
<li>Basic knowledge of GitLab CI/CD and Docker.</li>
</ul>
<h2>Setting up a GitLab Runner instance</h2>
<p>To set up a GitLab Runner instance that can build Docker images, use below Docker compose file as a starting point. Adjust the runner token, image, environment variables and other settings to your needs.</p>
<pre><code class="language-yaml">services:
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    container_name: gitlab-runner
    restart: unless-stopped
    volumes:
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
</code></pre>
<h2>Configuring the GitLab Runner</h2>
<p>In the <code>config</code> directory, you'll need to create or edit the <code>config.toml</code> file to configure the runner. Below is an example configuration that enables Docker-in-Docker builds.</p>
<p>The key settings here are setting the executor to <code>docker</code>, enabling <code>privileged</code> mode, and adding the <code>/certs/client</code> volume for TLS certificates.</p>
<pre><code class="language-toml">concurrent = 4
check_interval = 0
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = &quot;gitlab-runner&quot;
  url = &quot;https://git.example.com&quot;
  id = some-runner-id
  token = &quot;some-runner-registration-token&quot;
  token_obtained_at = 2025-11-03T12:30:25Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = &quot;docker&quot;
  request_concurrency = 4

  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = &quot;node:latest&quot;
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false

    # https://docs.gitlab.com/ci/docker/using_docker_build#docker-in-docker-with-tls-enabled-in-the-docker-executor
    volumes = [&quot;/certs/client&quot;, &quot;/cache&quot;]
    shm_size = 0
    network_mtu = 0
</code></pre>
<div class="markdown-alert markdown-alert-warning">
<p class="markdown-alert-title">Warning</p>
<p>Setting <code>privileged</code> to <code>true</code> effectively disables the container’s security mechanisms and exposes your host to privilege escalation. This action can cause container breakout. For more information, see <a href="https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities">runtime privilege and Linux capabilities</a>.</p>
</div>
<h2>Example CI/CD configuration</h2>
<p>This CI configiration uses <code>docker:28.5</code> as the image, and <code>docker:28.5-dind</code> as a service. It logs in to the registry, builds the image using buildx, and pushes the image. Adjust tags, cache and build options to taste.</p>
<pre><code class="language-yaml">default:
  image: docker:28.5

variables:
  DOCKER_TLS_CERTDIR: &quot;/certs&quot;

.before-docker:
  - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

stages:
  - build
  - publish

Build image:
  stage: build
  services:
    - docker:28.5-dind
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  before_script:
    - !reference [.before-docker]
  script:
    - &gt;
      docker buildx build
      --push
      --provenance=false
      --cache-from $CI_REGISTRY_IMAGE:latest
      -f Dockerfile
      -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      .

Push latest:
  stage: publish
  services:
    - docker:28.5-dind
  variables:
    GIT_STRATEGY: none
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  before_script:
    - !reference [.before-docker]
  script:
    - docker manifest create $CI_REGISTRY_IMAGE:latest $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker manifest push $CI_REGISTRY_IMAGE:latest
</code></pre>
<h2>Tips and troubleshooting</h2>
<ul>
<li>If jobs fail to connect to the dind service, make sure your GitLab Runner is registered and the runner's Docker daemon supports the dind setup (privileged mode, matching docker versions).</li>
<li>Use <code>DOCKER_TLS_CERTDIR</code> to enable TLS between the client and the dind service and mount the certs via the runner <code>volumes</code> setting.</li>
<li>For faster builds, use build cache (<code>--cache-from</code>) or set up a dedicated cache registry.</li>
<li>If you don't need multi-platform buildx features, you can simplify to <code>docker build --push</code> instead of <code>buildx</code>.</li>
</ul>
<h3>Problems?</h3>
<p>If you find mistakes or have suggestions, let me know. If you encounter problems, check the runner registration, docker versions and <code>privileged</code> settings first.</p>


Setting up GitLab Runner to build Docker images

<p>Running Plex in an unprivileged LXC container on Proxmox 8.4 with Intel Intel Quick Sync Video — or any GPU-accelerated hardware encoding — is a great way to maximize performance of your Plex server. This guide covers updating your kernel, configuring device permissions, and setting up Docker Compose for hardware acceleration.</p>
<h2>1. Update Proxmox Kernel to 6.11</h2>
<p>To ensure the best compatibility and performance with Intel Quick Sync, update your Proxmox host to kernel 6.11:</p>
<pre><code class="language-bash">apt update &amp;&amp; apt dist-upgrade
apt install proxmox-kernel-6.11
reboot
</code></pre>
<p>After rebooting, verify the kernel version:</p>
<pre><code class="language-bash">uname -r
</code></pre>
<p>This should output something like: <code>6.11.x-pve</code>.</p>
<h2>2. Set Device Permissions for GPU Access</h2>
<p>In order to use Intel Quick Sync, the LXC container needs access to the <code>/dev/dri</code> devices. For unprivileged LXC containers, you need to adjust permissions before passing through the device.</p>
<h3>a. Set Kernel Parameter</h3>
<p>Run the following command on the Proxmox host to allow access to performance counters. Add the following line to <code>/etc/sysctl.conf</code> to make this persistent:</p>
<pre><code>kernel.perf_event_paranoid=0
</code></pre>
<p>Then reload sysctl settings:</p>
<pre><code class="language-bash">sysctl -p
</code></pre>
<h3>b. Create a udev Rule for <code>/dev/dri</code></h3>
<p>First, identify your GPU devices. You can do this by running:</p>
<pre><code class="language-bash">ls /dev/dri
</code></pre>
<p>You should see devices like <code>card0</code> and <code>renderD128</code>, which are used as an example in this guide. Create a new udev rule file to set the correct permissions for these devices:</p>
<pre><code class="language-bash">nano /etc/udev/rules.d/99-dri-permissions.rules
</code></pre>
<p>Add the following lines:</p>
<pre><code>KERNEL==&quot;card0&quot;, SUBSYSTEM==&quot;drm&quot;, MODE=&quot;0777&quot;
KERNEL==&quot;renderD128&quot;, SUBSYSTEM==&quot;drm&quot;, MODE=&quot;0777&quot;
</code></pre>
<p>Reload udev rules using below command, or reboot the Proxmox host:</p>
<pre><code class="language-bash">udevadm control --reload-rules &amp;&amp; udevadm trigger
</code></pre>
<h2>3. Pass Through <code>/dev/dri</code> to the LXC Container</h2>
<p>Shut down the LXC container if it is running. Edit your container's config file (e.g., <code>/etc/pve/lxc/100.conf</code>) and add the following lines to the end:</p>
<pre><code>lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.cgroup2.devices.allow: c 29:0 rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD128 dev/renderD128 none bind,optional,create=file
</code></pre>
<p>After editing the config file, start the LXC container again.</p>
<h2>4. Add <code>/dev/dri</code> Mount to Docker Compose</h2>
<p>In your Plex Docker Compose service, add the <code>/dev/dri</code> device to make the GPU available to the Plex container. A full working example is shown at the end of this guide.</p>
<pre><code class="language-yaml">services:
  plex:
    # ...other options...
    devices:
      - /dev/dri:/dev/dri
</code></pre>
<h2>5. Verify Hardware Transcoding in Plex</h2>
<p>Start your Plex container and check if hardware transcoding is enabled. You can do this by going to the Plex dashboard, navigating to Settings &gt; Server &gt; Transcoder, and looking for the &quot;Use hardware acceleration when available&quot; option.</p>
<p>If it is enabled, you should see (hw) next to the transcoder in the dashboard when playing a video that requires transcoding.</p>
<h3>Problems?</h3>
<p>This post has been written with the outmost care, but if you find any mistakes or have any suggestions, please let me know.</p>
<p>If you encounter any problems, check all the steps again and make sure you have followed them correctly.</p>


Setting up Plex in an Unprivileged LXC Container on Proxmox 8.4 with Hardware Encoding

<h2>Intro</h2>
<p>I keep forgetting how to setup manual port forwarding with hairpin NAT, so that's why this post exists.</p>
<h3>Ports/interfaces</h3>
<p>External port: <code>8081</code></p>
<p>Internal IP: <code>192.168.10.197</code><br>
Internal port: <code>8080</code></p>
<p>Note that the internal port is the port that the service is listening on, and the external port is the port that is exposed to the internet.</p>
<p>WAN: <code>pppoe0</code><br>
LAN: <code>switch0.1</code></p>
<p>Replace these details with your own.</p>
<h2>Firewall</h2>
<p>First, we need to create a firewall rule to allow the traffic to reach the destination. This is done by creating a new rule in the <code>WAN_IN</code> (interface <code>pppoe0/in</code>) group.</p>
<p><img src="/images/EdgeRouterX-firewall-port-forward.png" alt="" loading="lazy"><br>
<img src="/images/EdgeRouterX-firewall-port-forward-advanced.png" alt="" loading="lazy"></p>
<p>You can specify a source address or address group to limit the traffic to a specific IP or range of IPs. If you want to allow all traffic, leave this field empty.</p>
<p>Note: you don't have to add your local network range to the source address list, as this isn't a firewall rule for the LAN interface.
<img src="/images/EdgeRouterX-firewall-port-forward-source.png" alt="" loading="lazy"><br>
<img src="/images/EdgeRouterX-firewall-port-forward-destination.png" alt="" loading="lazy"><br>
<img src="/images/EdgeRouterX-firewall-port-forward-overview.png" alt="" loading="lazy"></p>
<h2>DNAT</h2>
<p>Next, we need to create a DNAT rule to forward external traffic to the internal IP and port.</p>
<p><img src="/images/EdgeRouterX-firewall-port-forward-dnat.png" alt="" loading="lazy"></p>
<p>And, another DNAT rule. This time, we need to forward the traffic to the external IP and port.</p>
<p><img src="/images/EdgeRouterX-firewall-port-forward-dnat-local.png" alt="" loading="lazy"></p>
<h2>SNAT</h2>
<p>Finally, to wrap it all up, we need to create an SNAT rule to allow the traffic to return to the client.</p>
<p><img src="/images/EdgeRouterX-firewall-port-forward-snat.png" alt="" loading="lazy"></p>
<h2>Profit!</h2>
<p>That's it! You should now have your port(s) forwarded and accessible from your local network and the internet.</p>
<h3>Problems?</h3>
<p>This post has been written with the outmost care, but if you find any mistakes or have any suggestions, please let me know.</p>
<p>If you encounter any problems, check all the steps again and make sure you have followed them correctly. Setting this up involves multiple steps, so it's important to double-check and ensure that each step is followed correctly.</p>
<h2>Sources</h2>
<p><a href="https://help.ui.com/hc/en-us/articles/204952134-EdgeRouter-Hairpin-NAT">EdgeRouter - Hairpin NAT (help.ui.com)</a><br>
<a href="https://help.ui.com/hc/en-us/articles/205231700-EdgeRouter-Destination-NAT">EdgeRouter - Destination NAT (help.ui.com)</a><br>
<a href="https://help.ui.com/hc/en-us/articles/204976494">EdgeRouter - Source NAT and Masquerade (help.ui.com)</a></p>


EdgeRouter manual port forward with hairpin NAT

<h2>Intro</h2>
<p>GitLab Pages is a great way to host static websites. However, when using a reverse proxy custom domains can be tricky to set up. The GitLab docs describe you need a secondary IP address for this, but this is not always possible.</p>
<p>This guide will show you how to set up GitLab Pages behind a reverse proxy with HTTPS using Caddy and a custom GitLab Pages API written by me (<a href="https://github.com/wardpieters/gitlab-pages-caddy-api">wardpieters/gitlab-pages-caddy-api</a>).</p>
<h2>Steps</h2>
<p>Note: make sure to replace <code>example.com</code> and other example domains with your own domain, and <code>ca@example.com</code> with your own Let's Encrypt contact email address.</p>
<h3>1. Enable GitLab Pages</h3>
<p>Update the values shown below in your <code>gitlab.rb</code> file to enable GitLab Pages, configure the external pages URL and expose the necessary ports locally. Leave everything else as-is.</p>
<h4><code>gitlab.rb</code></h4>
<pre><code class="language-ruby">##! Define to enable GitLab Pages
pages_external_url &quot;https://pages.example.com/&quot;
gitlab_pages['enable'] = true

##! Configure to expose GitLab Pages on external IP address, serving the HTTP
# gitlab_pages['external_http'] = []
gitlab_pages['external_http'] = ['0.0.0.0:8888']
</code></pre>
<pre><code class="language-ruby"># Below you can find settings that are exclusive to &quot;GitLab Pages NGINX&quot;
pages_nginx['enable'] = true
pages_nginx['listen_port'] = 8091
pages_nginx['listen_https'] = false
pages_nginx['redirect_http_to_https'] = true
</code></pre>
<h4><code>docker-compose.yml</code></h4>
<p>Make sure to expose the ports for GitLab Pages and add the local GitLab Pages API using the <code>docker-compose.yml</code> file, only the relevant lines are shown below.</p>
<ul>
<li>Port 8091 is used for the GitLab pages domain (e.g. <code>pages.example.com</code>).</li>
<li>Port 8888 is used for the external domains (e.g. <code>handbook.example.nl</code>).</li>
</ul>
<pre><code class="language-yml">services:
  gitlab-ee:
    ports:
      - &quot;127.0.0.1:8091:8091&quot;
      - &quot;127.0.0.1:8888:8888&quot;
  caddy-api:
    restart: unless-stopped
    image: ghcr.io/wardpieters/gitlab-pages-caddy-api:latest
    ports:
      - &quot;127.0.0.1:8000:5000&quot;
    env_file:
      - .env
</code></pre>
<h4><code>.env</code></h4>
<p>In the same directory as the <code>docker-compose.yml</code> file, create a <code>.env</code> file with the below contents.
Make sure to replace the values with your own. The <code>GITLAB_TOKEN</code> can be created from the GitLab UI and needs to have the <code>api</code> and admin <code>scopes</code>.</p>
<pre><code>GITLAB_TOKEN=xyz
GITLAB_DOMAIN=git.example.com
GITLAB_PAGES_DOMAIN=pages.example.com
</code></pre>
<h3>2. Configure Caddy</h3>
<p>The Caddyfile needs three additions:</p>
<pre><code>{
	on_demand_tls {
		ask http://localhost:8000/api
		interval 2m
		burst 5
	}
}
</code></pre>
<pre><code>:443 {
	tls ca@example.com {
		on_demand
	}

	reverse_proxy http://127.0.0.1:8888 {
		header_down -server
	}
}
</code></pre>
<pre><code>pages.example.com,
*.pages.example.com {
	tls ca@example.com {
		on_demand
	}

	reverse_proxy http://127.0.0.1:8091 {
		header_down -server
	}

	import hsts
}
</code></pre>
<h3>3. Restart</h3>
<p>Restart your GitLab instance and run <code>docker compose up -d</code> to make sure the local GitLab Pages API is running</p>
<h2>Profit!</h2>
<p>That's it! You should now have GitLab Pages running behind a reverse proxy with HTTPS!</p>
<h3>Problems?</h3>
<p>This post has been written with the outmost care, but if you find any mistakes or have any suggestions, please let me know.</p>
<p>If you encounter any problems, check all the steps again and make sure you have followed them correctly. Setting up GitLab Pages involves multiple steps, so it's important to double-check and ensure that each step is followed correctly.</p>


Running GitLab Pages behind a HTTPS reverse proxy

<h2>Intro</h2>
<p>Expo is a great tool for building React Native apps, and GitLab CI/CD is an excellent way to automate the process of building and submitting those apps. In this blog post, we'll walk through the steps necessary to set up a GitLab CI/CD pipeline for building and submitting an Expo React Native app, using semantic-release for versioning and Expo EAS for building and publishing.</p>
<h3>Prerequisites</h3>
<p>A basic understanding of GitLab CI/CD and Expo is assumed. If you are not familiar with these tools, you can learn more about them by reading the <a href="https://docs.gitlab.com/ee/ci/">GitLab CI/CD documentation</a> and the <a href="https://docs.expo.dev/">Expo documentation</a>. In case you are using a self-hosted GitLab instance, you will need to make sure that you have a GitLab Runner installed and configured. For more information on how to do this, see the <a href="https://docs.gitlab.com/runner/">GitLab Runner documentation</a>.</p>
<h2>Setting up semantic-release</h2>
<p>Semantic-release is a tool that automates the process of versioning and releasing code, using commit messages to determine the appropriate version number. To use semantic-release with GitLab CI/CD, we first need to install the necessary packages and configure them appropriately.</p>
<h3>Install semantic-release and plugins</h3>
<p>Use either Yarn or NPM to install the required packages.</p>
<pre><code>yarn add -D semantic-release semantic-release-expo @semantic-release/changelog @semantic-release/commit-analyzer @semantic-release/git @semantic-release/gitlab @semantic-release/npm @semantic-release/release-notes-generator
</code></pre>
<pre><code>npm install --save-dev semantic-release semantic-release-expo @semantic-release/changelog @semantic-release/commit-analyzer @semantic-release/git @semantic-release/gitlab @semantic-release/npm @semantic-release/release-notes-generator
</code></pre>
<p>After installing above packages, we need to make sure the private attribute in the package.json file is set to true. This will prevent the package from being published to the npm registry. Also, set the repository field to the SSH URL of your GitLab repository. You can find this on the GitLab project page under the Clone button.</p>
<pre><code class="language-json">{
  &quot;name&quot;: &quot;my-app&quot;,
  &quot;private&quot;: true,
  &quot;repository&quot;: &quot;git@&lt;YOUR_GITLAB_DOMAIN&gt;:ward/my-app.git&quot;
}
</code></pre>
<h3>Configure semantic-release</h3>
<p>Next, we need to configure semantic-release. We can do this by creating a file called <code>.releaserc.yml</code> in the root of our project. This file will contain the configuration for semantic-release. The configuration below is a good starting point, but you can customize it to your needs. For more information on the configuration options, see the <a href="https://semantic-release.gitbook.io/semantic-release/usage/configuration">semantic-release documentation</a>.</p>
<p>Notice: you should replace <code>YOUR_GITLAB_DOMAIN</code> with your own GitLab domain in the configuration below. Or replace it with <code>gitlab.com</code> if you are using GitLab.com.</p>
<pre><code class="language-yaml">plugins:
  - &quot;@semantic-release/commit-analyzer&quot;
  - &quot;@semantic-release/release-notes-generator&quot;
  - &quot;@semantic-release/npm&quot;
  - - &quot;semantic-release-expo&quot;
    - versions:
        android: &quot;${increment}&quot;
        ios: &quot;${increment}&quot;
  - - &quot;@semantic-release/changelog&quot;
    - changelogFile: CHANGELOG.md
  - - &quot;@semantic-release/git&quot;
    - assets:
        - CHANGELOG.md
        - package.json
        - package-lock.json
        - app.json
      message: &quot;chore(release): ${nextRelease.version}\n\n${nextRelease.notes}&quot;
  - - &quot;@semantic-release/gitlab&quot;
    - gitlabUrl: https://&lt;YOUR_GITLAB_DOMAIN&gt;
</code></pre>
<h2>Setting up GitLab CI/CD</h2>
<p>Now that we have our dependencies and configuration files in place, we can create our GitLab repository and set up our CI/CD pipeline. This involves creating a <code>.gitlab-ci.yml</code> file that specifies the stages of our pipeline (e.g. building the app, publishing the app, etc.) and the commands to run at each stage. We'll also need to set up some environment variables in GitLab to store sensitive information like our Expo credentials.</p>
<h3>Configure GitLab environment variables</h3>
<h4>SSH key</h4>
<p>First, we need to configure the SSH key that will have write access to our GitLab repository. This is necessary for semantic-release to be able to commit the new version to the default branch. To do this, we need to create a new SSH key and add it to our GitLab repository. Use the command below to generate a new SSH key, you can replace <code>my-app</code> with the name of your app or any other name you like.</p>
<p><code>ssh-keygen -f ~/.ssh/my-app -t rsa -b 4096 -C my-app</code></p>
<p>Once the keypair has been generated, copy the contents of the <strong>public</strong> key (e.g. <code>~/.ssh/my-app.pub</code>) and add it to your GitLab Project Deploy Keys by following the instructions <a href="https://docs.gitlab.com/ee/ssh/#deploy-keys">from the GitLab Docs</a>. Make sure the key has write access, as shown in the screenshot below.</p>
<p><img src="/images/GitLab-CI-deploy-key.png" alt="" loading="lazy"></p>
<p>Next, you will need to add the <strong>private</strong> key (e.g. <code>~/.ssh/my-app</code>) to your GitLab Project Environment Variables by following the instructions <a href="https://docs.gitlab.com/ee/ci/variables/index.html#define-a-cicd-variable-in-the-ui">from the GitLab Docs</a>. Make sure the variable name is set to <code>CI_SSH_KEY</code>, as shown in the screenshot below.</p>
<p><img src="/images/GitLab-CI-SSH-key.png" alt="" loading="lazy">
Note: this private key is used for demonstration purposes only and is not in use.</p>
<h4>GitLab token</h4>
<p>The <a href="https://github.com/semantic-release/gitlab"><code>@semantic-release/gitlab</code></a> package requires a GitLab token to be able to create releases. To create a new personal access token, go to your GitLab Preferences and click on Access Tokens. Then fill in the form as shown in the screenshot below and click on 'Create personal access token'.</p>
<p><img src="/images/GitLab-CI-personal-access-token.png" alt="" loading="lazy"></p>
<p>Now, add the token to your GitLab Project Environment Variables by following the instructions <a href="https://docs.gitlab.com/ee/ci/variables/index.html#define-a-cicd-variable-in-the-ui">from the GitLab Docs</a>. Make sure the variable name is set to <code>GL_TOKEN</code>, as shown in the screenshot below.</p>
<p><img src="/images/GitLab-CI-token-variable.png" alt="" loading="lazy"></p>
<h4>Expo credentials</h4>
<p>To build your app with Expo EAS, you will need to add an Expo token to your GitLab Project Environment Variables. You can generate one by going to the Access Tokens section of your Account Settings. As shown on the screenshot below, you will first need to create a Robot user and then generate a new token for that account.</p>
<p><img src="/images/GitLab-CI-Expo-Robot-Token.png" alt="" loading="lazy"></p>
<p>After you have generated the token, add it to your GitLab Project Environment Variables by following the instructions <a href="https://docs.gitlab.com/ee/ci/variables/index.html#define-a-cicd-variable-in-the-ui">from the GitLab Docs</a>. Make sure the variable name is set to <code>EXPO_TOKEN</code>, as shown in the screenshot below.</p>
<p><img src="/images/GitLab-CI-Expo-Robot-Token-variable.png" alt="" loading="lazy"></p>
<p>Now open the <code>app.json</code> file in the root of project and add the <code>owner</code> property, set the value to your Expo username. This is necessary for Expo EAS to be able to build your app.</p>
<pre><code>{
  &quot;expo&quot;: {
    &quot;name&quot;: &quot;my-app&quot;,
    &quot;slug&quot;: &quot;my-app&quot;,
    &quot;owner&quot;: &quot;YOUR_USERNAME&quot;,
    ...
  }
}
</code></pre>
<p>Next, run the <code>eas init</code> and <code>eas build -p all</code> command to initialize your Expo project. You will be asked to provide some information, such as your Apple Developer account details. After completing this, a new project on Expo is created and also a <code>eas.json</code> file in the root of your project. This file contains the configuration for Expo EAS. You can customize this file to your needs, but the default configuration should be fine for most projects.</p>
<h3>Configure GitLab CI/CD pipeline</h3>
<p>In the root of the project, create a file called <code>.gitlab-ci.yml</code>. This file will contain the configuration for our GitLab CI/CD pipeline. The configuration below is a good starting point, but you can customize it to your needs. For more information on the configuration options, see the <a href="https://docs.gitlab.com/ee/ci/yaml/">GitLab CI/CD documentation</a>.</p>
<p>The configuration may seem overwhelming at first, but it is straightforward. The first thing to notice is that we have two stages: test and release. The test stage is used to run tests and other checks on the code and will run on pull requests. The release stage is used to build and publish the app. The release stage is only run when a commit is pushed to the default branch (e.g. master) and the commit author is not <code>semantic-release-bot</code>. This is to prevent the pipeline from running when semantic-release commits a new version to the default branch, and cause an infinite loop.</p>
<pre><code class="language-yaml">stages:
  - test
  - release

before_script:
  - npm install -g expo-cli
  - npm install

node:16:
  image: node:16-alpine
  stage: test
  allow_failure: true
  only:
    - merge_requests
  script:
    - npx tsc
    - expo-cli doctor

bump-version:
  image: node:18-alpine
  stage: release
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH &amp;&amp; $CI_COMMIT_AUTHOR !~ /semantic-release-bot.*/)
  script:
    - &quot;which ssh-agent || ( apk --update add openssh-client git )&quot;
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - '[[ -f /.dockerenv ]] &amp;&amp; echo -e &quot;Host *\n\tStrictHostKeyChecking no\n\n&quot; &gt; ~/.ssh/config'
    - ssh-add &lt;(echo &quot;$CI_SSH_KEY&quot;)
    - npx semantic-release

publish:
  image: node:16-alpine
  stage: release
  environment:
    name: production
  only:
    refs:
      - tags
    variables:
      - $CI_COMMIT_TAG =~ /^v.*$/
  before_script:
    - apk --update add git
    - npm install -g expo-cli eas-cli
    - npm install
  script:
    - eas build --platform all --profile production --non-interactive --auto-submit
</code></pre>
<h2>Profit!</h2>
<p>That's it! You can now commit and push your code to GitLab (<code>git add . &amp;&amp; git commit -m &quot;feat(ci): add semantic release&quot; &amp;&amp; git push</code>).</p>
<p>With the GitLab repository and pipelines set up, you are ready to start building and publishing apps automatically. You can simply push code changes to GitLab, and the pipeline will take care of the rest - building the app and publishing it to the appropriate release channel!</p>
<p>You can see the pipeline in action by going to the CI/CD &gt; Pipelines page in your GitLab project.</p>
<p><img src="/images/GitLab-CI-pipelines.png" alt="" loading="lazy"></p>
<h3>Problems?</h3>
<p>This post has been written with the outmost care, but if you find any mistakes or have any suggestions, please let me know.</p>
<p>If you encounter any problems, check all the steps again and make sure you have followed them correctly. Setting up the pipeline involves multiple steps, so it's important to double-check and ensure that each step is followed correctly.</p>


Automating Expo App Builds and Submissions with GitLab CI/CD

<h2>Intro</h2>
<p>This blog post will describe the struggle I went through to set up a Site to Site VPN using two Debian VMs and an EdgeRouter X on both sides of the connection, so you (and future me) don't have to.
The image below describes my network setup. The public IP addresses are not displayed for obvious reasons.</p>
<p><img src="/images/S2S-VPN-diagram.svg" alt="" loading="lazy"></p>
<h2>Port forward</h2>
<p>The WireGuard server (host A) must be reachable from the internet. Therefore you’ll have to port forward UDP port 51825 on Host A (server). The screenshot below shows how to set this up on a EdgeRouter X. Port forwarding is not necessary on host B as this VM acts as a client.</p>
<p><img src="/images/EdgeRouterX-port-forward-WireGuard.png" alt="" loading="lazy"></p>
<h2>VM Setup</h2>
<p>Note: to do this yourself, some knowledge of networking and Linux is required.</p>
<p>To start, I installed Debian 11 running WireGuard on two VMs. The process is basically the same on Ubuntu.</p>
<pre><code class="language-bash">apt-get update
apt-get install -y wireguard iptables
</code></pre>
<p>Before we go any further, we need to edit the <code>/etc/sysctl.conf</code> file on both hosts. Add the line shown below to the file and run <code>sysctl -p</code>.</p>
<pre><code>net.ipv4.ip_forward=1
</code></pre>
<h2>WireGuard Setup</h2>
<p>After setting up the VMs, WireGuard is installed and some commands are now available for us to use. We will use them to generate the public and private key for the config files.
First we will do this on Host A (server):</p>
<pre><code class="language-bash">wg genkey &gt; host-a.key
wg pubkey &lt; host-a.key &gt; host-a.pub
</code></pre>
<p>And then on host B (client):</p>
<pre><code class="language-bash">wg genkey &gt; host-b.key
wg pubkey &lt; host-b.key &gt; host-b.pub
</code></pre>
<p>We will use the contents of the generated files in the WireGuard configuration. On host A (server) we create the file <code>/etc/wireguard/wg0.conf</code> with the content below. Replace the placeholders (e.g. &lt;host-a.key&gt;) with the content of the appropriate files and make sure to replace <code>eth0</code> with your actual network interface.</p>
<pre><code>[Interface]
PrivateKey = &lt;host-a.key&gt;
Address = 10.229.76.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
MTU = 1420
ListenPort = 51820
SaveConfig = false

### begin host-b

[Peer]
PublicKey = &lt;host-b.pub&gt;
AllowedIPs = 10.229.76.2/32, 192.168.10.0/24
PersistentKeepalive = 16

### end host-b

</code></pre>
<p>Then we'll create the file <code>/etc/wireguard/wg0.conf</code> on host B (client), but with different content. Make sure to replace <code>eth0</code> with your actual network interface and the <code>Endpoint</code> with the IP address of host A (server).</p>
<pre><code>[Interface]
PrivateKey = &lt;host-b.key&gt;
Address = 10.229.76.2/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = &lt;host-a.pub&gt;
Endpoint = 213.x.x.x:51820
AllowedIPs = 192.168.20.0/24
PersistentKeepalive = 16
</code></pre>
<p>On both hosts we set the WireGuard interface to start on boot and right now by running <code>systemctl enable wg-quick@wg0 --now</code>. If you did everything okay, you should not see any errors.</p>
<h2>Routing</h2>
<p>On the EdgeRouter of both networks you add a static route by clicking on 'Add Static Route' and then entering the information below. On the router of host A add the IP range of host B as destination network and the IP of host A as next hop address. The same goes for the router in the network of host B, but then the other way around.</p>
<p>Note: adjust the IP ranges to your situation!</p>
<p><img src="/images/S2S-VPN-routing.png" alt="" loading="lazy"></p>


Ward Pieters

Recent Blog Posts

How I didn't vibe code a mail inspector app

Making my self-hosted infrastructure a little more European

Hardening Caddy and Mailcow with HSTS and modern TLS