Picking the Right Hammer for the Job

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.

Continue reading

todo.txt done

While I like the functionality of the todo.txt structure, I do not like the fact that done tasks stay in my todo list in perpetuity, and I also don’t want to lose them.  So, I’ve made a simple hack that allows me to move done items to a done folder.  Here’s the code:

#!/bin/sh
awk '/^x/ {print $0}' ~/Dropbox/todo/todo.txt >> ~/Dropbox/todo/done.txt 
awk '!/^x/ {print $0}' ~/Dropbox/todo/todo.txt > ~/Dropbox/todo/todo2.txt
mv ~/Dropbox/todo/todo2.txt ~/Dropbox/todo/todo.txt

 

I call it todo_done.sh.

I copied my original to /tmp/pre in order to test and make sure I have a backup.  After running todo_done.sh I get:

 

$ diff -u /tmp/pre/todo.txt ~/Dropbox/todo/todo.txt
--- /tmp/pre/todo.txt 2017-11-15 17:46:21.794510999 -0500
+++ /home/ayoung/Dropbox/todo/todo.txt 2017-11-15 17:46:24.584515043 -0500
@@ -7,7 +7,6 @@
 2017-10-02 Expenses
 2017-10-04 Containerize hammer
 2017-10-06 Complete steam setup 
-x 2017-10-12 Trrc time resource reduce cost 
 2017-10-12 Whiteboard training 
 2017-10-14 Subscription manager extensions for skis or products? 
 2017-10-15 Workcenter is made up of 4 things: machine, man, method, measures.

and

$ diff -u /tmp/pre/done.txt ~/Dropbox/todo/done.txt 
--- /tmp/pre/done.txt 2017-11-15 17:46:17.914505377 -0500
+++ /home/ayoung/Dropbox/todo/done.txt 2017-11-15 17:46:24.580515037 -0500
@@ -26,3 +26,4 @@
 x 2017-10-19 Drs appt? 
 x 2017-11-02 Letter of Support
 x 2017-11-15 2017-09-27 LinkedIn TJX
+x 2017-10-12 Trrc time resource reduce cost

Different CloudForms Catalogs for Different Groups

One of the largest value propositions of DevOps is the concept of Self Service provisioning. If you can remove human interaction from resource allocation, you can reduce both the response time and the likelihood of error in configuration. Red Hat CloudForms has a self service feature that allows a user to select from predefined services. You may wish to show different users different catalog items. This might be for security reasons, such as the set of credentials required and provided, or merely to reduce clutter and focus the end user on specific catalog items. Perhaps some items are still undergoing testing and are not ready for general consumption.

Obviously, these predefined services may not match your entire user population.

I’ve been working on setting up a CloudForms instance where members of different groups see different service catalogs. Here is what I did.
Continue reading