The first question you might be asking yourself after reading the title of this post is
“Why in the @#$%&! would you do that”
If that wasn’t the first thing that came to your mind, you’re probably wondering what EAP even is and why you should be so taken aback. Don’t worry, I will try to answer both of these questions with this blog post.
This post will describe how to setup a docker registry using distribution/distribution to allow for “passwordless” authentication. Now of course, this is not actually passwordless, there’s still a password. But we can (ab)use the fact that both GitLab CI and GitHub Actions give you a JWT signed by the platform, valid for the duration of the run.
Recently, as I’ve been implementing authentik for more of my services, I was looking for a way to get tokens from authentik into some other systems to, for example, deploy them on machines with Puppet. Because authentik doesn’t (yet) support certificate authentication, and I already have Hashicorp Vault setup for that, I wondered if I could build an integration that syncs tokens into vault.
Even though Gitlab has been around for a long time, there are still times where it can crash. Normally that wouldn’t cause any issues, besides being mildly annoying. However, when Gitlab crashes (and I mean really crashes) during a CI Build, sometimes invalid data remains in the Database.
Recently, Home-Assistant have changed their stance, and only “support” installations on HassOS and Debian 10 (at the time of writing this).
Normally, this wouldn’t really matter to me, as I don’t really care about having a “supported” system or not. However, they also decided, that unsupported installations can’t get OTA Updates through Supervisor, such as upgrading to the recently recently released version 2020.12.
Ubuntu Server 20.04 has been out for a few days, which I think is a perfect time to build start my migration from Debian to Ubuntu. Now, with Debian, I had a nice Packer setup, that automatically builds base-images. These images have some default packages installed, some miscellaneous settings and a default user. These images are used by an Ansible Workflow that creates new VMs on the fly, and deploys whatever tools I need into the VM.
It’s been a day since vSphere 6,5 came out, and sysadmins all over the world have been updating their test systems. This works really well if you update to vCenter 6.5 first, since it has the Update Manager integrated.
Shoutout to /u/dantho and /u/CBRJack for helping me with this
I’ve recently started to mess around with IPv6, mostly for the reasons of being future-proof (somewhat), a lot of free addresses and also cause it seemed interesting. Now at home I already have IPv6, at least in theory. My home connection is a UnityMedia Cable Connection. This is running DS-Lite, so the whole aparetmeent complex has an external IPv4, and every flat has their own IPv6 space. Sounds pretty easy to deal with, right? No. (But this is also not the point of this post).
#It’s colo time baby!
######the structure of this post was totally not stolen from MonsterMuffin (<3 bb)
After a recent power bill reminded me that Servers were not free to run, but rather pulled some rather big power costs behind them, I decided to downsize.
This weekend I decided to upgrade my Foreman to 1.12, which finally supports Puppet 4. I was pretty excited for this, since I always try to run the latest software since April 2015. I used this guide to upgrade my Puppet install since Foreman still supports Puppet 3, and won’t force you to upgrade. The guide in itself wasn’t too hard, so I was able to finish it within the hour. Shortly finishing the guide, I started getting bombarded with mails from my foreman, since nodes started to fail. Now it’s Sunday evening, and I still haven’t fixed all the issues that came up since the upgrade. Now that might be due to my (relative) inexperience with Puppet (about 1 year), but I’d still like to share my thoughts on Puppet 3 vs Puppet 4. So here’s a list of thoughts in no particular order: