This blog post is a part of this blog post series:

I will open this blog post with a quote from the famous Gary Larizza:

After wading the waters of self.prefetch, I’m PRETTY SURE its implementation might have come to uncle Luke after a long night in Reed’s chem lab where he might have accidently synthesized mescaline.

http://garylarizza.com/blog/2013/12/15/seriously-what-is-this-provider-doing/

After reading Gary’s rather elaborate explanation about self.prefetch I still did not fully get what self.prefetch actually does and the official documentation surely does not help:

Buildbot is a continuous integration framework which many open source projects seem to be using. Unlike continuous integration applications or automation servers like Jenkins Buildbot does not make many assumptions about your use-case. In fact, when you build your CI or CD pipeline you’re actually writing Python code and hence have all the flexibility of Python directly at your disposal. In other words, you’re not being blocked or obstructed by assumptions hidden in the tool itself, like often tends to happen with Jenkins.

Having a staging server for Wordpress is quite useful for testing new features without the worry of breaking something in production. It is also helpful when you have a multi user environment and need to test something that could impact others. In this article it is assumed that your Wordpress instance has SELinux enabled as is the case on RHEL/CentOS for example. On other distros like Ubuntu or Debian you can omit the steps specific to SELinux.

Foreman’s provisioning system allows creating provisioning templates with highly dynamic content. This article describes how to create dynamic content in your Foreman provisioning templates. While the example is related to dynamic partitioning in kickstart, the basic mechanisms for setting this up applies to any kind of template.

Foreman provisioning templates are written in ERB format. This allows having logic in the template itself based on user-defined host parameters. For example the Kickstart default template consumes a bunch of host parameters that allow you to define what kind of kickstart file you want Foreman to spit out for each host or host group. To give a simple example there’s the “lang” parameter which sets the value for “lang” kickstart option:

This posting comes strictly from the land of esoteria. We have a Vagrant + Virtualbox environment that sets up Foreman used for PXE booting baremetal servers. The environment work fine on Linux and MacOS. But we needed to make this environment work also on Windows. Easy, right? Vagrant and Virtualbox are supposed to abstract all those pesky operating system settings away, correct? After resolving a non-Windows related challenge provisioning of Foreman on Windows almost worked. Except that it failed when foreman-installer attempted to start[*]. The error message was this:

If you’re at all like me, you every now and then find yourself thrown out of your comfort zone, when you should actually be in it.

The pattern usually goes something like this:

1. It’s something simple. I’ll fix it in a couple of minutes and document it for others. I know my stuff. 

2. Hmm, this seems to be a bit stubborn. I need to take a closer look.

3. Still doesn’t work. I need to run this in a debugging set up and break it into pieces, to see where the problem is. 

Grafana is a common tool to visualize data from multiple datasources. Perhaps the most common datasource is Prometheus. If an organization has a Single-Sign On solution, it makes sense to authenticate users centrally with that solution That will make authentication easier and friendlier for end users (authenticate once and then access multiple services), and also enable stronger authentication by adding multifactor authentication.

In addition to authenticating user, it is also possible to authorize Grafana users based on their group membership. 

In this blog we consider JBoss/Wildfly domain mode in the context of the wonderful Keycloak software. It is not necessarily trivial to understand how the interfaces  should be configured, especially if you want to do something other than the defaults, for example to secure your Wildfly/JBOSS configuration, or if you are dealing with a more complex nodes with multiple network interfaces. 

Assumptions:

• We want to use Keycloak in domain mode. In this operating mode Keycloak application is clustered and also the caches, like user sessions are replicated in the cluster. 

We use Kanban to coordinate our projects and tasks. Kanban is focused on visualizing and improving throughput, that is, making projects (high-level) and tasks (low-level) go through the system as fast as by limiting work in progress, which in turn minimizes waste (time and money).

Our field of work is IT operations and we’re generally quite busy with fulfilling requests from our internal and external stakeholders. Most of our tasks are quite small, about 1-4 hours each, and produce value immediately. We can generally get these done (“through the system”) quickly without having to stop in the middle and can then forget about them. However, we also have bigger tasks that tend to take a lot longer, maybe 8-24 hours of focused work and often involve multiple persons.

We recently hit an interesting issue with an “almost in production” Keycloak high-availability clustered domain mode setup that was behind an Amazon EC2 load balancer with sticky sessions enabled. The symptom was that changes from the domain controller did not propagate to the slave. This included:

• Changes made to realms and clients using the Admin REST API

• User sessions

This lead us into a quest to truly understand how Infinispan caches in the Wildfly application server and consequently in Keycloak work. Before you read this article you should probably read all of these: