My work as a cloud Solutions Architect is focused on OpenShift. Since I work in the financial sector, my customers are very security focused. These two factorshave converged on me working on OpenShift installs on disconnected networks.
The current emphasis on OpenShift is for virtualization. While virtualization can be nested, it typically has a performance penalty. More important, though, is that virtualization is a technology for taking advantage of bare metal installs.
I need to run OpenShift 4 on baremetal in my homelab via a disconnected install . Here we go.
While reviewing the comments on the Ironic spec, for Secure RBAC. I had to ask myself if the “project” construct makes sense for Ironic. I still think it does, but I’ll write this down to see if I can clarify it for me, and maybe for you, too.
OpenShift requires a load balancer for providing access to the hosted applications. Although I can run a three node cluster, I need a fourth location to provide a load balancer that can then provide access to the cluster.
For my home lab set up, this means I want to run one on my bastion host….but it is already running HTTP and (FreeIPA) Red Hat IdM. I don’t want to break that. So, I want to add a second IP address to the bastion host, and have all of the existing services make use of the existing IP address. Only the new HA Proxy instance will use the new IP address.
This would be trivial for a simple Ethernet port, but I am using a Bridge, which makes it a touch trickier, but not terribly so.
“I can do any thing. I can’t do everything.”
The sheer number of projects and problem domains covered by OpenStack was overwhelming. I never learned several of the other projects under the big tent. One project that is getting relevant to my day job is Ironic, the bare metal provisioning service. Here are my notes from spelunking the code.
The key piece of persisted data in an DHCP server is the lease. A lease is a the mapping between a MAC address and an IP address, limited in time. A Lease typically has a start time and an end time, but can be renewed. Because I am still living in an IPV4 world, I have to deal with arbitrarily small pools of IP addresses. Thus, the design needs to strike the balance between static and dynamic: a machine should generally get back the same IP address each time. However, if addresses get tight, address reuse should be aggressive.
To capture DHCP packets I ran:
tcpdump port 67 -i vnet0 -vvvv -w /tmp/packets.bin
That gave me a binary file 940 bytes long. This is actually 2 packets: the request and the response. This has the IP header, the UDP header, and the DHCP packet payload in it.
The Extract Function refactoring is the starting point for much of my code clean up. Once a “Main” function gets sufficiently complicated, I pull pieces of it out into their own functions, often with an eye to making them methods of the involved classes.
While working with some rust code, I encountered an opportunity to execute this refactoring on some logging code. Here’s how I executed it.
I took the container registry I ran via podman and put it behind an Apache HTTPD instance secured with mod_ssl. Now when I try to log in to it, I get:
error authenticating creds for “nuzleaf.home.younglogic.net”: error pinging docker registry nuzleaf.home.younglogic.net: invalid status code from registry 403 (Forbidden)
Here’s my debugging notes.
There are many reasons to run a web service in a container. One of the remote services I rely on most heavily is git. While git local operations are fine in a global namespace, running a shared git repository on a remote server is a web-service based use case. There are three protocols used most commonly to remotely access git: git, ssh, and https. I am going to focus on the last one here.