Set up Foreman and manage it with Ansible

Managing Foreman recently and got bored to configure it each time I set it up from scratch.

This blog post will cover initial foreman install on a CentOS 7 server and then manage it with ansible through the foreman ansible collections.

The repository used in this article is locate here.

Servers recommendations

Minimum Foreman server hardware recommendations to support CentOS 7 & 8.

  • CentOS 7
  • 4 CPUs
  • 8Gb RAM
  • 100 Gb HDD

Minimum ansible server recommendations:

  • CentOS 7
  • 1 CPU
  • 256 Mb RAM
  • 8 Gb HDD

Setting up the Foreman server

Configure the OS

Create a CentOS 7 server with the above hardware setting and make sure to have a working DNS for that server or edit its own /etc/hosts with that hostname. For simplicity I am using ->
$ cat /etc/hosts
...    foreman
Reboot the server and make sure the new hostname is set.

Install Katello & Foreman

Next step is to install the foreman application with katello content management.
This is a pretty straightforward step:
Install repositories
yum -y localinstall
yum -y localinstall
yum -y localinstall
yum -y localinstall
yum -y install foreman-release-scl
Then update the OS and restart if any kernel or glibc upgrade
yum -y update
Install katello packages to prepare for the installation step later. This might take some time
yum -y install katello
Finally install foreman with katello. change the variables accordingly:
$ foreman-installer –scenario katello –foreman-initial-organization ‘CloudAlbania’ –foreman-initial-location ‘YYZ’ –foreman-initial-admin-username ‘admin’ –foreman-initial-admin-password ‘password123’ –foreman-foreman-url ‘’ -v
After 10-15 minutes the server should be up and running and reachable from your browser

Install and configure the ansible server

To manage the Foreman server you can already do all the configurations in the GUI. If you need to have a more documented and automated configuration then Ansible is the way.
In this guide I am using a CentOS 7 server.
$ yum -y install epel-release
$ yum -y install ansible git
Make sure the ansible host can connect to the foreman server without a password the sake of this guide. You can implement vaults or sudo users in a production environment for better security
Create your ansible workplace:
$ mkdir -p git/foreman
$ cd git /foreman
Install the foreman.ansible collections:
$ ansible-galaxy collection install theforeman.foreman
Install the ansible dependencies with pip:
$ pip install subnet ipaddress rpm deb apypie PyYAML
Now your ansible server should be ready to configure the foreman server.

Collections Usage

Full documentation for each individual module can be obtained with the ansible-doc command as follows:
ansible-doc theforeman.foreman.foreman_architecture

Your first playbook

In order to start configuring the Foreman server we can start with a Day 1 configuration item which is the Organization name.
NOTE: The Foreman collections do not need to connect to the foreman server itself rather we will use the local connection and then ansible will reach to foreman on port 443 (the API).
The first playbook we can start with is the definition of the Organization itself. Even though we have defined it in the setup command above, it is a good practice to have it defined in a configuration management system for consistency.
The playbook content:
[root@ansible foreman]# cat foreman1.yml
– name: Day 1
  hosts: localhost
    – name: “Create CI Organization”
        username: “admin”
        password: “password123”
        server_url: “”
        name: “{{ item }}”
        state: present
        validate_certs: no
        – “CloudAlbania”
        – “Organization 2”
And when run we will see the below:
and in the foreman organizations list we will see:
If we run again the playbook there will be no changes
This is the end of this guide. Will follow up with a more detailed Day 1 configurations

Set up a Powershell dev environment

For us sysadmins it is important to create scripts on the fly and make things work. By working in an ad-hoc way, our scripts will get lost, not cured and especially not searchable.

Initial tools setup

To better organize our code some personal best practices follow:
Environment: Windows
Install and download TortoiseGit and of course GIT. While installing GIT just select the defaults for you.

Saving code

For every single script it is a better idea to integrate or put all its relative files in a separate folder. Then put all these folders in a single one named: scripts.

After installing TortoiseGIT it is a good idea to go with the First Start wizard.
Select the defaults and in the “configure user information” screen input your name and a valid email address.

The next thing to do is to integrate all your scripts in a GIT repo. With the help of TortoiseGIT this can be easily achieved with only the right click of the mouse

And you are done with the repository creation.

After each working sessions it is a good idea to commit your work. With TortoiseGIT again this can be easily done by a mouse right-click.

Then fill out the commit screen with an appropriate message and then click commit

The commit confirmation screen will show up.

Do the same steps (commit) after each coding session to save your work and your coding history.

Pushing code remotely

After working locally, you might consider storing your code in a server repo. A good one is at GitLab which offers private repos for free.


Build open source clouds with 4 OpenStack guides and tutorials

Every time you turn around, it seems like there’s a new open source project which might be of value to a cloud administrator. A huge number of these projects fall under the umbrella of OpenStack, the open source cloud toolkit.
Fortunately, there are plenty of tools out there to help with growing your OpenStack knowledge base, from meetups and in-person training, to mailing lists and IRC channels, to books, websites, and the official documentation.
Adding to that list are many individual members of the OpenStack community who are sharing their own tutorials, guides, and other helpful information across their own blogs and community sites. In order to help you keep up with these, every month takes a look a the latest community-created educational content for OpenStackers and brings it to you here.

  • One of the more interesting aspects of OpenStack is that it really is a composable toolkit of different projects which are designed to be used in conjunction with one another but which can provide value to other projects outside of OpenStack itself. One great example of that are OpenStack’s storage projects, which can be used independently of OpenStack or swapped out within an OpenStack cloud. Recently, John Griffith provided a great tutorial for how OpenStack’s Cinder block storage project can be used with Docker and Linux container systems.
  • One of the challenges that comes up in having so many different interchangeable parts, particularly with storage components, is knowing how to choose the right one for your needs and the needs of your cloud’s users. Learn all about the various factors that are important to consider in this guide to selecting a storage backend for OpenStack.
  • Mistral provides a workflow service within OpenStack, which the TripleO project recently adopted in the most recent release cycle. Like any cloud project, the team encountered a few unexpected hiccups along the way, and documented them in this look at debugging Mistral in TripleO.
  • One challenge of a large project like OpenStack with a diversity of contributors, often working on pseudo-independent projects is that the code base can reflect a variety of different coding styles and bring ambiguities related to uncertainties in the code. Various automated tools can help to reign this in; one such tool, Eslint, is specifically oriented towards JavaScript code. Learn how to implement Eslint for your OpenStack project’s JavaScript-based sections.

Thanks for checking out our website.