One Year at Red Hat


I’ve working for one year at Red Hat and it has been the best gig ever

My year in numbers

#1 Contributions

My contributions on GitHub

My contributions on GitHub

#2 Memberships

Member of 3 organizations on GitHub,
of 5 meetups,
of 8 mailing lists,
of 2 Google groups

#3 Contributed to

I have contributed to ~20 projects. Here are some to name a few:

  • Foreman
  • foreman_openscap
  • Smart Proxy
  • Fog
  • ruby-openscap
  • foreman-docker
  • foreman_discovery
  • smart_proxy_discovery
  • Foreman Packaging
  • patternfly-sass
  • Hammer
  • foreman_infra
  • Scaptimony
  • hammer-cli-foreman
  • foreman_tasks
  • grimstad
  • smart_proxy_openscap
  • foreman_scap_client

Seems like I have been focused in contributing to Foreman this year 😉

#4 Notable days

  • September 1st. 2014 – The day I have joined Red Hat
  • September 2nd. 2014 – First contribution to the Foreman project.
  • December 14th. 2014 – The day I have contributed most (Should have more days like this…)
  • My longest streak: 5 days (Oct. 19 – Oct. 23)

#5 Travels

  • Traveled 43232 km. this year. Most of it to work and back (cost of living in the village)
  • Traveled to Munich
  • Traveled to Brussels

#6 playground

I have learnt so much this year! I came with little no dev-ops knowledge and discovered an amazing world. Here are some of the things I have tried / played with:

  • Docker
  • Kubernetes
  • Libvirt (duh!)
  • Manageiq
  • OpenShift
  • Atomic OS
  • LDAP (on Docker)
  • vmware
  • And probably some other I have forgot

#7 People

This is the most important part of this post.
I honestly believe it is all about people. I am blessed and honored to work with such an amazing group of people.

Thank you Ohad, Joseph, Ori, Dominic, Daniel, Stephen, Bryan, Shimon, Simon, Alon, Amir, Tom C., Marek, Ivan, Tomas, Greg, Dmitri, Mike, Michael, Tom M, Eric, Lukas, Martin, Tomer, Ondrej and all the amazing people at the Foreman organization

  • Special thanks to the Foreman bot who helps me get my PRs in the right manner.
  • Another thanks to nudnik who tells me which PR is what. May you have a good !karma

Thank you all !

#8 Social media

(This part is a total fake, yet I need to get to #10)

  • I have tweeted 439 times about my work this year
  • I have posted 126 times about my work on facebook
  • I have posted 5 blog posts
  • I have 1 Instagram picture with Richard Stallman, which I have also posted to facebook (sorry Richard, I had to) <- True fact

#9 Longest pull requests threads

  1. The longest one to date: Reports STI with 156 discussions (Dominic, Please…. )
  2. Review before build with 101 discussions
  3. Drop Ruby 1.8.7 with 86 discussions

#10 Future

Plan #1:
Win the lottery, move to the Maldives, contribute code

Plan #2:
Fly somewhere, plane crashes, contribute code

(realistic) Plan #3:
Keep on enjoying and loving what I currently do: contribute code

On openldap in a docker container


So I needed to test some ldap functionality on the Foreman, and I wanted to setup a local openldap server.
One option could have been to install openldap server on my laptop, but as I am enthusiastic about docker, I have decided to have an ldap server running within a container.

The solution was pretty much straight-forward:
I have found an openldap docker container @ nickstenning/slapd  which provides exactly that…
so I have run

docker run -e -e LDAP_ORGANIZATION="Example Ltd." \-e LDAP_ROOTPASS=mySecretPass --name ldap -p 389:389 -d nickstenning/slapd

* One important param to remember is to expose port 389 (this is done with -p 389:389)
The rest of the parameters are pretty much self-explanatory.

For some reason the container failed to start :/
I have checked the container logs with “docker logs -f CONTAINER_ID” and saw some weird permission issues.
I setenforce 0 my laptop – and boom, I had an openldap server up & running.

Next, I wanted to add my own user, besides the default admin user.
I have created an ldif file which looked like:


dn: uid=test,ou=users,dc=example,dc=com
objectclass: inetOrgPerson
objectclass: person
givenName: Test
sn: User
uid: test
userPassword: MyAlsoSecretPassword
cn: Test User

Now I needed to apply it:

ldapadd -v -h localhost:389 -c -x -D cn=admin,dc=example,dc=com -W -f users.ldif

* Please note the cn=admin,dc=example,dc=com, which required the password we provided at LDAP_ROOTPASS

And the test user has been added…. 😀

To ensure, it was created I have run:

ldapsearch  -v -h localhost:389 -b 'ou=users,dc=example,dc=com' -D 'cn=admin,dc=example,dc=com'  -x -W '(&(objectClass=person)(uid=test))'

Finally I have set my Foreman instance to authenticate with ldap and spent the next two hours logging in and out from Foreman with my test user 😉

An afternoon with project Atomic


Paul Cormier keynote encouraged me to install project Atomic on one of my VMs.
The keynote itself outlined the importance of decentralized / containerized data center and you should watch it to understand where the future datacenter it going to.

I have followed Atomic’s excellent rtfm and the result was a VM with kubernetes with a pod running nginx.
I do not remember myself being so happy to see the nginx welcome page


I think you should try creating your own docker / kubernetes / Atomic test environment and play with it, as it is where servers are going to.

Select2 landing in Foreman


tl;dr – select2 is now part of the Foreman and will help you search in long select list


Select2 gives you a customizable select box with support for searching, tagging, remote data sets, infinite scrolling, and many other highly used options.

We have added select2 in Foreman (with the gem select2-rails) and enabled it on all select fields, which make using and searching (especially the long) selects much easier.


One little issue I have encountered is in the puppetclasses -> edit -> Smart Variables tab, where Select2 “refused” to work – so we defaulted to the regular select. (I’d love to hear comments on how to solve this)


On OpenSCAP and Foreman


tl;dr – install foreman_openscap to run automated vulnerability audits on your foreman hosts.


The Foreman-OpenSCAP gem suite enables Foreman to receive automated vulnerability assessment and security compliance audits from Foreman hosts.
You can upload SCAP compliance contents, create compliance policies out of them and assign the policies to hosts or hostgroups. The  foreman_openscap plugin provides three default SCAP contents, so you can start testing security compliance on RHEL6/7 and Fedora.

OpenSCAP reports (aka ARF reports) will help you find vulnerabilities on your hosts and also suggest a remediation plan to fix those vulnerabilities. OpenScap report

The Foreman OpenSCAP suite is made up of 5 components (gems):

  • Scaptimony – Rails engine which creates and persists SCAP content, compliance policy and ARF report objects
  • foreman_openscap – UI to display the Scaptimony engine (which actually connects to OpenSCAP)
  • smart_proxy_openscap – Smart-Proxy plugin which distributes SCAP content to hosts and post ARF reports from client hosts to Foreman
  • foreman_scap_client – A client script which runs OpenSCAP scan and uploads the scan report to the Smart-Proxy
  • puppet-foreman_scap_client – A puppet module which configures foreman_scap_client



Pretty easy (I think 🙂 ):
On Foreman:

yum install ruby193-rubygem-foreman_openscap

restart foreman

On the Proxy:

yum install rubygem-smart_proxy_openscap

restart foreman-proxy

On puppet master:

puppet module install isimluk-foreman_scap_client

That was pretty easy, no?
Please note that foreman_openscap will install scaptimony engine with it, and the puppet module will install foreman_scap_client on the client hosts.

OpenSCAP basic concepts

There are three basic concepts (entities) in the OpenSCAP plug-in: SCAP Contents, Compliance Policies and ARF Reports.

SCAP Content – A file which contains SCAP DataStream XML.
The DataStream contains the compliance, configuration or security baselines. Meaning, in this file there are the SCAP security guidelines and policies in a form called XCCDF (Extensible Configuration Checklist Description Format) where the XCCDF profile is the checklist which audits the specific security target.

Compliance Policy- in Foreman, you can create a compliance policy   and assign it to a host / hostgroup. The important part is to choose which XCCDF profile you wish to test on that policy. A compliance policy is made of:

  • SCAP Content
  • XCCDF Profile from particular SCAP Content
  • Hostgroups that should comply with the policy
  • Schedule – the period in which the audit shall occur

ARF Report – When a Compliance policy is run on the selected host(s) – they result is an ARF report which is uploaded back to foreman and generates a report where you can learn about your host’s security vulnerabilities and security issues.

Using foreman_openscap

Import foreman_scap_client puppet module into Foreman.
In the menu: Configure -> Puppet classesImport from <your puppet master>

The menu for using SCAP is set under: Hosts -> Compliance

Creating SCAP content.
Please note that in the latest foreman_openscap, we provide RedHat default SCAP content for RHEL 6, RHEL 7 and Fedora. However, you can also upload your own SCAP content.

New SCAP Content

Now that we have some SCAP contents (which contains one or more XCCDF profiles) we can create policies.
A policy is the mapping of which XCCDF profile to run on which host(groups) at what time.

Creating a Policy

To create a policy, go to Hosts -> Policies and choose “New Compliance Policy” and follow the wizard’s steps:

  • Name your policy
  • Choose which SCAP content & SCAP profile to apply
  • Choose schedule when to run this policy
  • Select to which locations / orgaginations this policy belongs to, if enabled
  • Choose to which hostgroup you wish apply this policy

In the final part, the policy will be applied to each host which belongs to the selected hostgroup.
Another method to assign a policy to a host is via the hosts index “select action” button:

Assign Hosts

** In the background, foreman_scap_client is configuring which Proxy will serve openscap and which policies to apply to the client hosts. When ‘puppet agent’ will run on the client it will install “foreman_scap_client” and configure the policies and the proxy to upload the scan reports. The puppet module will also set a cron line to run the policy on its selected schedule.

And finally, reports from our hosts are starting to get in….

ARF reports

as soon as the client is running it generates reports which are uploaded back to Foreman (via the Smart Proxy).

To access reports: Hosts -> Reports

ARF reports index

The reports index shows a brief status of how many tests have passed / failed on that report.
To view the detailed report, click on “View Report”

ARF report
In the detailed report, you could find which tests have passed, and more important which tests have failed and do not comply with the security standard. On each failed test you could also find a remediation procedure which will help you eliminate the failing test (and make your host more secure!)