Linux Miscellaneous Shell

Using sendmail with a Relay Host

It is useful when Docker containers can send e-mail to you in case there is an error condition that needs attention. Here is how to.

Install the sendmail package from your distribution and edit the file /etc/mail/ Add this line to the end of it:

define('SMART_HOST', '<dns-name-of-your-relay')

Done! Just restart sendmail:

/etc/init.d/sendmail stop
/etc/init.d/sendmail start

Long Time No See

A long time has passed since the last post on this blog. Not because I was lazy. It was merely because there were more important things to do than writing blog posts about things that most people can look-up in the internet anyway.

However, the Open Source software projects were still going on. Not so frequent updates but once in a while. The current Corona pandemic now gives me some possibilities to finish things that were long time on my list. First and most importantly is to gain independance of hosting all my software on my own and maintaining the infrastructure for it. Still, some main parts will be on me. Such as build tools, issue tracking and automation.

However, I managed to host all my code now at GitHub. This task alone cost me about two weeks until each and every Subversion repository was migrated. I have been writing code now for more than 20 years. That’s why about 110 software projects piled up at my previous Subversion repository. Most of them are not public, only 26 can be accessed by everyone. But migrating all 110 physically took me 3 days. Another 10 days I was busy to update the CI/CD pipelines for the still active projects (around 50). And the last week passed with upgrading the Open Source projects to new software versions, documenting them, changing the workflows, upgrading build tools and writing CI/CD tools for these changes. Finally, I managed to bump up the versions of the major OSS projects – after 3 weeks of work. Most of them were API breaking. That’s why the major versions increased (Check Maven Central for an overview).

You will find updates on them here in this blog – and you will see more updates coming soon. The main changes are:

  • Upgrading to Java 9: My Java projects will not support any older runtime environment.
  • Documentation moves to GitHub along withe code and the respective version. It is still going on. So this blog will become less important for documentation and the respective sections will be removed from the menu (but still be available).
  • Development workflow will follow the Gitflow workflow model now.

Feel free to contact me for any of the projects, the new or the old ones. For the moment, I wish you all the best and stay healthy!


PS: Of course, I will try to blog more IT stuff and more frequently than before 🙂


IPv6 with Kubernetes

Awwww – so much work I had put into setting up a Kubernetes cluster (this blog will run there in a few days). I set up the pods and containers, cron jobs, services, and, and, and. Then I started renewing my SSL certificates from LetsEncrypt. This renewal failed hilariously, but with a weird error message:


What? I can reach my websites. Did I miss something? I checked connectivity. The IP addresses were right, the ACME challenge directory was available as required by LetsEncrypt, the DNS was working properly. Why couldn’t LetsEncrypt servers not reach my cluster? I soon found out that they prefer IPv6 over IPv4 which I had both enabled. But the IPv6 connection failed. From everywhere. Ping6 though succeeded.

Further analysis revealed that Kubernetes is not able to expose IPv6 services at all (or at least at now, so I researched). What shall I do now? All my work was based on the assumption that IPv4 and IPv6 will be there. But it’s not with Kubernetes. Of course I could move my reverse proxy out of Kubernetes and put it in front of it. But that would require more work as all the automation scripts for LetsEncrypt would need to be rebased. Testing again and again. Let aside the disadvantage of not having it all self-contained in containers anymore. Another solution must be there.

Luckily there was an easy solution: socat. It’s a small Linux tool that can copy network traffic from one socket to another. So that was setup easily with a systemd script (sock_80.service):

 Description=socat Service 80
 ExecStart=/usr/bin/socat -lf /var/log/socat80.log TCP6-LISTEN:80,reuseaddr,fork,bind=[ip6-address-goes-here] TCP4:ip4-address-goes-here:80

That’s it. Enabled it (systemctl enable sock_80.service), reloaded systemd (systemctl daemon-reload), and started the service (systemctl start sock_80). Voilá! Here we go. IPv6 traffic is now routed to IPv4. I repeated it with port 443 and the setup is done. And LetsEncrypt servers are happy too 🙂