I always thought that it would be impossible for me to make convincing looking websites. But I did learn it and enjoy it very much. But as soon as I’m ready with a new, beautiful web page on my screen, my joy is cut short by the fact that I still need to make it responsive. Learning website development is in fact a double battle: first learning the techniques to make nice things on a web page, and then learning another set of techniques on how to keep the design beautiful on smaller screens. In my experience, the latter battle is way bigger, and thus hope that sharing the lesson I learned will save someone from the agony I had to go through. I’ll focus on modals because making them responsive has been the toughest part for me.

Introduction

In the “Packer QEMU: Building Ubuntu 20.04/22.04/24.04 VM images” blog post we briefly mentioned ways to improve Packer QEMU performance. In this article we’ll go into the details on how this is implemented. The key in improving Packer QEMU performance is to split the build into two distinct stages:

1. Operating system installation stage

2. Provisioning stage

This setup cuts down development time considerably as repeating the provisioning stage becomes a lot faster.

The Using tags in Puppet Bolt aws_inventory target_mapping showed how to use AWS “Name” tag as the target name for Puppet Bolt. Use of tags can be extended to creating Bolt target groups:

groups:
  - name: webservers
    targets:
     - _plugin: aws_inventory
       region:
         _plugin: env_var
         var: AWS_DEFAULT_REGION
       filters:
         - name: tag:Type
           values: [webserver]
       target_mapping:
         name: tags.Name
         uri: public_ip_address

All you need to do is add a “filter” section with one filter. The “name” parameter tells Bolt that the filter is based on tags and what tag to look for. The “Type” that follows “tag” is the name of the tag you want to filter by. The “values” array lists acceptable values for that tag. Any nodes that don’t have the tag (here: “Type”) or where tag value is not acceptable (e.g. “db”) will not be shown in the group.

Vagrant has built-in support for connecting to Windows VMs using the vagrant rdp command. It does basically does the same as vagrant ssh for Linux VMs. There are a few shortcomings, though: vagrant rdp fails to automatically accept the host key of the VM it is connecting to, at least when using it from Linux with xfreerdp. So, you first need to connect to the VM directly once with raw xfreerdp, then vagrant rdp will start working. Then, when you wipe out the VM, you need to repeat the process again. If you have a high resolution screen you will also notice that vagrant rdp will give you a tiny Windows desktop where you need a magnifying glass to read the text.

I’ve been doing lots of Windows automation recently. My goal has been to be able to reproducibly create a Windows Server 2019-based Buildbot workers, first in a Vagrant environment, then later in AWS EC2 using pre-built images created with Packer. This task requires installing Visual Studio 2019 build tools automatically and fetching the project’s dependencies with vcpkg automatically. It is possible to install Visual Studio 2019 with Chocolatey quite easily, but what if you need to install additional components to Visual Studio without using the Visual Studio installer GUI? Looking around did not quickly reveal any de facto instructions on how to do it, so this article aims to fill that gap.

We’re migrating away from Ansible to Puppet Bolt and the fact that Ansible updates broke the old ec2.py inventory script expedited that process. While that inventory script was quite rudimentary, it was able to automatically add human-readable names to the EC2 instance names. So, for example, you could target a node using “server_example_org” if the Name tag was set to “server.example.org”.

Puppet Bolt’s aws_inventory seemed to lack that feature, but after taking a good look at its code this was just a case of missing documentation, which I fixed in this PR. Here’s an example of inventory.yaml for Bolt that maps the value of the “Name” tag to the name of the Bolt target:

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:

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.

A few days ago I looked at our Azure costs and they were around $8. That’s a ridiculously small amount, except for the fact that we don’t really use Azure for anything. So I started investigating.

After having published the Configuration Manager (Puppet master installer image) and LibreNMS in Azure Marketplace I knew that we had a bunch of BLOBs lying around. I knew how to find these blobs using the Storage Explorer. So I tested wiping them all out, as I knew Azure does not delete them immediately, but only after one day. Then I attempted to launch Configuration Manager and LibreNMS from the Azure Marketplace GUI. My thought was that those blobs had already been copied elsewhere (for global distribution) and would not be used by the Marketplace anymore, but it looked like I was wrong. At least I got odd behavior when trying to launch those images and reverting the blob deletion fixed things.