That Yocto Thing

Many hardware vendors use Yocto as a way to provide a version of the Linux Kernel and board bring up package. This is a very Linux-from-scratch type approach that grew out of GenToo. My current work is on closing the gap between these vendors and the RPM based code management approach in Fedora etc.

This is a lot of fun.

Our code repository is on gitlab.

I’ll be posting some of the more interesting things that I learn while working on this.

Getting hostname information from the beaker command line

We use Beaker to allocate and loan computer hardware. If you want to talk to it via the comand line, you can use the bkr executable. Some of the information comes back as json, but beaker tends to speak xml. To look up a host name from a job, you need to be able to parse the xml. To do that, I used the xq execuable from the python yq package. Yes, x and y.

I installed yq via pip. That puts both the xq and yq executablees into ~/.local/bin.

If i know the job ID, I can parse it using the following syntax.

bkr job-results 'J:5078388' | xq -r  ".job | .recipeSet | .recipe| .task | .[] | .roles | .role | .system | .\"@value\""

UPDATE: So here is a useful script that makes use of bkr, jq, and xq to list the hostnames of the hosts I currently have on loan from beaker.

for job in $( bkr job-list -o $USER  --unfinished | jq -r '.[]' ) ; do bkr job-results $job | xq -r  ".job | .recipeSet | .recipe| .task | .[] | .roles | .role | .system | .\"@value\"" ; done

Homelab OpenShift 4 on Baremetal: Part 1

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.

Continue reading

Getting SweetHome3D To Run on Fedora 33

When I tried running SweetHome3D, I got two different problems depending on which of the scripts I tried. I eventually was able to get ./SweetHome3D-Java3D-1_5_2 to run. At first I got this error:

$ ./SweetHome3D-Java3D-1_5_2 
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/ayoung/apps/sweet/SweetHome3D-6.4.2/lib/ cannot open shared object file: No such file or directory

I was able to resolve with guidance from this thread. I had to install libnsl .

$ yum search libnsl
========================= Name Exactly Matched: libnsl =========================
libnsl.i686 : Legacy support library for NIS
libnsl.x86_64 : Legacy support library for NIS
======================== Name & Summary Matched: libnsl ========================
libnsl2-devel.i686 : Development files for libnsl
libnsl2-devel.x86_64 : Development files for libnsl
============================= Name Matched: libnsl =============================
libnsl2.x86_64 : Public client interface library for NIS(YP) and NIS+
libnsl2.i686 : Public client interface library for NIS(YP) and NIS+
[ayoung@ayoungP40 SweetHome3D-6.4.2]$ sudo yum install libnsl

And then it runs.

Adding an IP address to a Bridge

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.

Continue reading

Content Based Access Control in Messaging

In an OpenStack system, the communication between the compute nodes and the scheduler goes through a messaging system such as RabbitMQ. While there have been different models over the years, the basic assumption has remained that all actors identify themselves to the broker via a password and are trusted from that point forward.

What would happen if a compute node was compromised? The service running on the node could send any message one the bus that it wanted. Some of these messages are not ones that a compute node should ever send, such as “Migrate VM X to Node Y.” If the compromise was delivered via a VM, that hostile VM could then attempt to migrate itself to other nodes and compromise them, or could attempt to migrate other VMs to the compromised nodes and read their contents.

How could we mitigate attacks of this nature?

Continue reading