Just bough a "tower" style power strip, in the hopes that it would reduce the problem of large power plugs blocking neighbouring sockets.
It worked partially, at least now a big power plug only blocks a single neighbouring socket instead of (potentially) two on a long horizontal power strip.

Still, not entirely happy with the solution.

What are you guys all doing for power strips when you've got a lot of large power plugs?

I'm still getting mails from my single user Mastodon server about new trending hashtags to approve. I don't care about those, as this is a single user instance.

But: It is a very nice way to know that the mail sending setup in my homelab still works. 😂

The final post of the Netbooting a Raspberry Pi series: blog.mei-home.net/posts/rpi-ne

Note especially the point at the end: Does anybody have a good book on technical blogging/writing, especially style, which goes a bit beyond "Here are the 12 points every blogger should keep in mind"?

And another post from my "Netbooting a Raspberry Pi" series:

I'm rather proud of my productivity this fine weekend.

Finished the next installment of my ""Netbooting a Raspberry Pi" series:

This time, I'm explaining how to create a Raspberry Pi image with Hashicorp Packer using the very cool binfmt_misc kernel feature and chroots.


While writing the article, I realized how long it had gotten. So I decided to move the Ansible playbook and the final deployment to later articles.

Difficult decision: Repurpose my testing/experimenting Raspberry Pi 4 as my DMZ host?

Pi 4 4GB are pretty hard to come by at the moment, and I would like to have a dedicated "Bastion Host" Pi.

I think I'm slowly getting used to the advantages of Linux tool's UX. I just found out that LXD's "delete", removing a Virtual Machine in my case, does not have any sort of scary prompt asking me whether I'm really sure I want to remove the machine.
That was a bit scary for a moment or two.

Successfully set up the Netbooting with syslinux/pxelinux for my newest cluster host. This needed a (partially) new setup, because my previous Raspberry Pi netboot setup did not need syslinux, due to the fact that the Pis already come with a netboot bootloader able to load kernel and initrd.
Last step remaining is to put it all into Ansible.

Alright, next milestone reached: My new host is getting the syslinux.efi file from the Bootserver. Now to actually configure it.

Also: Far too much time spend fighting a permission problem thinking it was NFS, though it actually was the mount directory itself having the wrong perms. 🤦‍♂️

Finally, success! My Packer Ubuntu Image creation works. The fix was switching to SFTP instead of SCP for file transfers in Ansible. I currently think that the SSH Proxy Packer uses by default is at fault somehow.

Now researching how generic netbooting works to configure my Udoo x86 II with it. Seems it is a bit different than the Raspberry Pi netboot I've already set up.

Still fighting with Ubuntu, Ansible and Packer.

Discovered one idiotic mistake: I'm using a freshly installed Ubuntu VM here, not the preinstalled Ubuntu Raspberry Pi image. So the "ubuntu" user I create is not in the sudoers file.

But that still doesn't seem to be the whole story. It is still failing to transfer files.

Fun sunday night activities: Fighting with Ansible privilige escalation.

Arrrrrrrghhhhhh. I've just spend three hours debugging why my Ubuntu Server install VM is not coming up.

It crashed with "No working init found".

The problem? The initramfs could not be unpacked, because the Qemu default 512 MB were simply not large enough. 🤦‍♂️

CrowdSec introduction put on ice, because I've just ordered an Udoo X86 II Ultra which will serve as the x86 node in my Raspberry Pi cluster.

I've finished the basic planning and already decided that I will netboot the Udoo with a Ceph RBD root disk.

Now I just need to figure out how to best provision the Machine. Packer, which I'm already using for my Pi nodes, looks like it might be good for image creation here too.

Success! Snagged an UDOO x86 II Ultra: shop.udoo.org/en_eu/udoo-x86-i

It will serve as the single x86 node in my homelab once I've switched to the Turin Pi 2 with Pi CM4s, just in case I want to run something which is not available for aarch64.

Started reading up on CrowdSec. I like the idea of "Distributed thread intelligence". It also already has a plugin for my OPNsense firewall.

Only problem is getting logs into it from my Fluentd/Loki stack. I would like to avoid pushing all logs from everywhere to disk, just so that CrowSec can read them.

While writing an article about creating Raspberry Pi images with HashiCorp Packer, I came across one of my favourite "Wait, it can do what?!" moments in working with Linux:

binfmt_misc. [1]

With that functionality, you can execute e.g. aarch64 binaries directly on your host, without having to spin up a VM, using Qemu's static user binaries and a bit of Kernel magic.

[1] docs.kernel.org/admin-guide/bi

Redraft: Hashtags

Does anybody have an arm64 host available with Docker installed? If so, could you execute the command "docker run envoyproxy/envoy:v1.23.0" on it? That image is supposed to have an arm64 variant, but for me it throws an exec format error.

Finally Done: My host TLS certificates now come out of Vault instead of using Ansible's SSL cert module.

One tip for all the Nomad users out there: If you're using TLS for Nomad's cluster traffic, make sure your certificates contain the SAN "DNS:server.global.nomad" for Nomad server hosts and "DNS:client.global.nomad" for Nomad client hosts.
It doesn't matter whether those DNS names actually resolve in your setup. Without them, Nomad throws TLS cert errors.

Show older
Meier's Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!