This was a revelation that came to me when fixing Vagrant on my Fedora 34 laptop: Vagrant plugins seem to be just Ruby gems installed into an isolated runtime environment, with “vagrant plugin” ensuring that the gems are installed in the correct place.

The same gems that you can install with “vagrant plugiin install” can be found using vanilla gem command:

$ vagrant plugin list
rexml (3.2.5, global)
vagrant-hostmanager (1.8.9, global)
vagrant-vbguest (0.29.0, global)
winrm (2.3.6, global)
winrm-elevated (1.2.3, global)
winrm-fs (1.3.5, global)

$ gem info --remote rexml

*** REMOTE GEMS ***

rexml (3.2.5)
    Author: Kouhei Sutou
    Homepage: https://github.com/ruby/rexml

    An XML toolkit for Ruby

$ gem info --remote vagrant-vbguest

*** REMOTE GEMS ***

vagrant-vbguest (0.29.0)
    Author: Robert Schulze
    Homepage: https://github.com/dotless-de/vagrant-vbguest

    A Vagrant plugin to install the VirtualBoxAdditions into the guest
    VM

$ gem list|grep vagrant
<no output>

On the remote side you can find all the familiar Vagrant plugins as gems, but vanilla gem won’t find them installed locally, because they’re in a different path.

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

The self.instances is a provider class method that is used to produce an array containing all resources found from the system. For example, a yum package provider might run “rpm -qa” in self.instances to get a list of packages installed on the system. This serves two main purposes:

• Allows using of “puppet resource type” to produce Puppet code for all resources of type found on the system.
• Data created by self.instances can be passed to self.prefetch to cache resource properties. The cached properties are then reused for every resource of that provider type. For example, a yum package provider might create a list of packages installed on a system when Puppet encounters the first “yum” package resource of “yum” type. That cache would then be reused, thus removing the need to individually check each package’s state.

As discussed in Puppet types and providers development part 4: caching resource properties to improve performance self.instances or self.prefetch are not really suitable for scenarios where you need to manage (multiple) remote systems using the same provider, because things like connection would be given in the Puppet resource definition are at the provider instance level, to which provider class level methods like self.instance and self.prefetch do not have access to.

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.

GitLab has an extensive API which allows managing its internal configuration such as users, groups and projects. The official GitLab Terraform provider builds on top of this API.

It assumed here that the Terraform controller (e.g. your laptop) is able to reach your GitLab instance’s TCP port 443 - if it can’t there’s no way Terraform’s API calls will work. The same approach should work with gitlab.com - you can probably (=untested) skip the base_url parameter in that case.

This blog post shows how to grant access to an AWS account for some external party. For simplicity we will call this external party a “contractor”. If you want to do the same for Microsoft Azure look at this blog post instead.

This method requires the contractor to have its own AWS account, but it has several benefits:

• No need to create AWS user accounts for every single person working for the contractor
• You can force the contractor’s personnel to use two-factor authentication (2FA)
• You can force the contractor to use an additional password (shared secret)
• You can disable contractor’s access completely by just removing the IAM role

This approach works equally well for AWS Console access, AWS CLI and tools like Terraform. Some tools may not like the extra security measures required here or be able to assume a role out of the box.

In Microsoft Azure you can grant an external user (“contractor”) guest access to your Azure subscription. The approach is quite different from what AWS uses (see Delegating external parties access to AWS).

Here we grant access to john.doe@contoso.com using the Azure Portal. Preferably john.doe@contoso.com would already exist as a Microsoft account.

1. Login to your Azure Portal
2. Type “Users” in the search box
3. Click on the “Users” service
4. Click on “New guest user”
5. Select “Invite User”
6. Fill in the fields. The email address should be the one given by the external user.
7. Click on “Invite” at the bottom
8. The external user will receive an invite to your Azure in the email address you defined above.

Now the user has been created. However, it is lacking permissions to do anything useful. We will fix that in the next steps by assigning it a role:

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:

Introduction

Integrating Keycloak with Gitlab SAML makes it easier to manage users in an organization from a central point. You could manage separate accounts on Gitlab, but for us it makes sense to utilize Keycloak as we are already using it for other applications.

Setting up Keycloak

The first step is to create a Gitlab SAML client in the Keycloak dashboard. With the correct realm selected, navigate to the Clients configuration page and click the create button to add a new client.