Nonsense and other useful things

As the last step of migration to kubernetes I am migrating my DLNA server to kubernetes. This will allow me to play content from my server on my TV. As part of my previous migration of the NAS I already migrated over all my data (including media) to kubernetes so this should be easy: just run a DLNA server on kubernetes and give it a mount of the media content. This new setup is going to replace my old mediatomb setup.

Continue reading →

As one of the last steps in moving my VM based setup at home to kubernetes, it is now the turn to migrate my ‘NAS’. The term ‘NAS’ is a too much honor for it since it is basically just a single shared file system exposed over SSHFS, Samba, and rsync. The setup discussed below however still supports multiple shares. Basically what I need from my NAS setup is the following:

• it must be accessible on Windows and linux
• efficient backups of important files must be possible using rsync (such as my complete home directory on linux)

Continue reading →

The migration of my old VM based infrastructure at home to k8s is almost finished. The final steps to do are:

• moving version control to kubernetes: subversion and git
• moving my file shares/NAS server
• hosting my DLNA server for playing movies from my server on my TV

This post describes the first. There are of course many free alternatives for hosting version control, but nonetheless, I like to be in control completely and therefore I am also hosting my own subversion and git repositories. These are basically just Apache using a certain configuration.

Continue reading →

As part of my project to move everything from VMs to kubernetes and to get rid of some really old VMs (talking OpenSuSE 11 from 2010 here), it is now time to migrate my old java applications to kubernetes. These apps are basic web apps but I am using some advanced stuff such as my own flexible JDBC realm database integration with Java EE and also using some tricky CDI things. The applications are stable and I even use one of them on almost a daily basis. However, I don’t want to spend time porting these apps over to a different environment. This is why a want to migrate this old (ancient) Glassfish V4 application server as is to Kubernetes.

The aim is to basically freeze this setup in time. I do not plan to work on these applications but I still use them. Instead of updating them at a later point in time, I would probably rewrite them from scratch and perhaps even in python instead of java using for instance django. Therefore, the aim is to freeze this setup in time as it were so I can keep on using it. No need to spend more time on it now. So this is going to get a little bit dirty.

Continue reading →

Up until now I have been running, a by now ancient, version of Jenkins on a virtual machine. The virtual machine on which it was running was so old that it was even unable to download any more newer artifacts from the internet because of its lack of support for the newer TLS versions. Time then, as part of my ongoing project to migrate everything to kubernetes, to move jenkins there as well.

Continue reading →

The final step in migrating ‘everything-email’ from my old server to a kubernetes setup is the migration of mailing lists based on mailman. In previous posts, I migrated the core mailserver and webmail to kubernetes. It s recommended to read the first post first because that one explains the full mail system architecture and dependencies. In this post we will be focusing on the last part, which is migrating mailman.

Continue reading →

This is a continuation of my earlier post on migrating my mailserver to kubernetes. The next component of my mail setup to migrate is webmail. In the past I used squirrelmail for this, so I started with investigating that. However, it turns out that the squirrelmail project does not provide any docker containers. There are some containers you can get from docker hub, but these are largely unmaintained and are mostly private projects. After some looking around I found roundcube. Quick prototyping with roundcube containers, provided by the roundcube project, using docker compose showed that it was not difficult to get it to work.

Continue reading →

It has been a long time since I setup a mail server. It started with my first mailserver on linux somewhere in 2000 using sendmail and University of Washington IMAP. This setup was assuming mail delivery to local system users. In other words, every e-mail had to correspond to a local system user. Getting it working was absolute hell, but it finally worked. Sendmail in particular seemed not to behave according to the documentation.

Then in 2006 my next setup was based on postfix and cyrus IMAP, decoupling mail boxes from system users. I bought a book about postfix and read it front to cover before starting. This was a much more pleasant experience. However, this was also not without fights in getting basic stuff to work. Over time, I added black listing, grey listing,  and spam detection to the setup. I also added a webmail user interface using squirrelmail later on. Finally, my ISP increased security and my mails often would get rejected. To fix this, my ISP required my to relay outgoing mail through their mail server and it turned out my postfix version was too low and could not handle it. I made a quick workaround for that by relaying outgoing mail to a newer postfix mail server running on another virtual server in my network. Problem solved, but it was getting painfully clear that the old setup was nearing its expiration date.

However, now it is time to say goodbye to this old setup. As part of my home project to migrate every workload from VMs to containers using kubernetes this is an ideal chance to get a new setup. Still a lot of respect for these older versions of cyrus and postfix for running for such a long time (16 years!) with basically zero maintenance. Would it be easier now, after all this time, to setup a new mail system? (spoiler alert: yes).

Continue reading →

As part of moving everything that is running in VMs on my server to kubernetes, the old wordpress installation had to be migrated to kubernetes as well. The website was previously running in a linux container based on systemd-nspawn, using a container which is basically running a full linux OS, including database.

The intention of the old setup was to move wordpress hosting away from an old server that also contained some private data. The intention was damage control by reducing the consequences of a hack of my wordpress website. At that time, my experiences running docker were not that positive regarding stability, so I chose to use standard linux containers with a simple interface on top called systemd-nspawn. Now, a few years on, the whole container ecosystem has matured, and now there are better ways to run containers such as kubernetes.

Continue reading →