When Monty Taylor and company looked to update the Ansible support for OpenStack, they realized that there was a neat little library waiting to emerge: Shade. Pulling the duplicated code into Shade brought along all of the benefits that a good refactoring can accomplish: fewer cut and paste errors, common things work in common ways, and so on. However, this means that the OpenStack modules are now dependent on a remote library being installed on the managed system. And we do not yet package Shade as part of OSP or the Ansible products. If you do want to use the OpenStack modules for Ansible, here is the “closest to supported” way you can do so.
Red Hat Satellite Server is a key tool in the provisioning process for the systems in our Labs. In one of our labs we have an older deployment running Satellite 6 which maps to the upstream project The Foreman version 1.11. Since I want to be able to perform repeatable operations on this server, I need to make Web API calls.
The easiest way to do this is to use the Hammer CLI. But it turns out the version of Hammer is somewhat tied to the version of Satellite server; the version I have in Fedora 27 Does not talk to this older Satellite instance. So, I want to run an older Hammer.
I decided to use this as an opportunity to walk through running an RPM managed application targetted for RHEL 6/EPEL 6 via Docker.
Edit: actually, this might not be the case, but the rest of the learning process was interesting enough that I kept working at it.
Edit2: This was necessary, see the bottom. Also, the 1.11 in the URL refers to the upstream repo for theforeman. I’d use a different repo for building using supported RH RPMs.
Here is what I learned.
“Ooops.” — Me, doing something as admin that I didn’t mean to do.
While the sudo mechanism has some warranted criticism, it is still an improvement on doing everything as the root account. The essential addition that sudo provides for the average sys admin is the ability to only grant themselves system admin when they explicitly want it.
After the previous two days debugging, Simo Sorce suggested that I need to tell the OS to show all AVCs, some are hidden by default.
My cloud may not look like your cloud. The contract between the application deployment and the Kubernetes installation is a set of manifest files that guide Kubernetes in selecting, naming, and exposing resources. In order to make the generation of the Manifests sane in KubeVirt, we’ve provided a little bit of build system support.
I have been geting prepped to build the OpenShift origin codebase on Centos 7. I started from a fairly minimal VM which did not have docker or Development Tools installed. Once I thought I had all the prerequisites, I kicked off the build and got
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
This seems to be due to the fact that the ayoung user does not have permissions to read/write on the domain socket. /var/run/docker.sock
In my continued investigations of networking stuff, I came across the question “How do you bond two ethernet devices together?” While I did this years ago on RHEL3, I have pretty much forgotten how, so I decided to research and relearn this.
I recently created a new Centos VM. When it booted, I noticed it did not have a working ethernet connection. So, I started playing with things, and got it working. Here are my notes:
While many people referred me to run one of the virtualized setups of OpenShift, I wanted something on baremetal in order to eventually test out KubeVirt. Just running
oc cluster up
As some people suggested did not work, as it assumes prerequisites are properly set up; the docker registry was one that I tripped over. So, I decided to give openshift-ansible a test run. Here are my notes.