<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Bug on Puppeteers Oy</title>
		<link>https://www.puppeteers.net/categories/bug/</link>
		<description>Recent content in Bug on Puppeteers Oy</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Tue, 01 Jun 2021 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://www.puppeteers.net/categories/bug/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Making Vagrant work on Fedora 34</title>
				<link>https://www.puppeteers.net/blog/making-vagrant-work-on-fedora-34/</link>
				<pubDate>Tue, 01 Jun 2021 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/making-vagrant-work-on-fedora-34/</guid>
				<description>&lt;p&gt;We use Vagrant and Virtualbox a lot because it is an excellent tool for infrastructure code development. Unfortunately it is also very prone to breakage during operating system upgrades, especially if you depend on many plugins. When I upgraded from Fedora 32 to 34 Vagrant broken even more than usual due to conflicting rspec dependencies. Basically every Vagrant plugin refused to install with this error message:&lt;/p&gt;&#xA;&lt;div class=&#34;code-block&#34;&gt;&#xA;    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;&#xA;      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;&#xA;    &lt;/button&gt;&#xA;    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ vagrant plugin install vagrant-vbguest&#xA;Installing the &amp;#39;vagrant-vbguest&amp;#39; plugin. This can take a few minutes...&#xA;&#xA;Vagrant failed to properly resolve required dependencies. These&#xA;errors can commonly be caused by misconfigured plugin installations&#xA;or transient network issues. The reported error is:&#xA;&#xA;conflicting dependencies rspec (= 3.10.0) and rspec (= 2.14.1)&#xA;  Activated rspec-2.14.1&#xA;  which does not match conflicting dependency (= 3.10.0)&#xA;&#xA;  Conflicting dependency chains:&#xA;    rspec (= 2.14.1), 2.14.1 activated&#xA;&#xA;  versus:&#xA;    rspec (= 3.10.0)&#xA;&#xA;  Gems matching rspec (= 3.10.0):&#xA;    rspec-3.10.0&lt;/code&gt;&lt;/pre&gt;&#xA;  &lt;/div&gt;&lt;p&gt;The rspec dependency conflict does not sound particularly scary for somebody who is not &lt;em&gt;developing&lt;/em&gt; Vagrant or Vagrant plugins. Therefore ignoring the dependencies is likely to be just fine:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Microsoft Teams redirect loop mystery</title>
				<link>https://www.puppeteers.net/blog/microsoft-teams-redirect-loop-mystery/</link>
				<pubDate>Tue, 11 May 2021 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/microsoft-teams-redirect-loop-mystery/</guid>
				<description>&lt;p&gt;Some of our customers use Microsoft&amp;rsquo;s Office 365. Due to that they also use Microsoft Teams for collaboration. Recently, out of the blue, I ran into a &amp;ldquo;redirect loop mystery&amp;rdquo; in Teams. Basically I was able to login to &lt;em&gt;our&lt;/em&gt; Teams (which we only use when recording video calls). But when I tried to switch to a customer workspace I was able to get in, but got immediately redirected back to our own workspace. This issue affected both the official Teams client for Linux, as well as the Chrome browser. Fortunately this was a well-known issue that could be fixed by &lt;a href=&#34;https://docs.microsoft.com/en-us/microsoftteams/troubleshoot/teams-sign-in/sign-in-loop#resolution&#34;&gt;relaxing cookie security settings&lt;/a&gt; in the browser.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Terraform stalls when recreating security groups</title>
				<link>https://www.puppeteers.net/blog/terraform-stalls-when-recreating-security-groups/</link>
				<pubDate>Tue, 23 Mar 2021 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/terraform-stalls-when-recreating-security-groups/</guid>
				<description>&lt;p&gt;Sometimes Terraform stalls when trying to remove AWS EC2 security groups and Terraform does no give any hint as to what is wrong. The problem is caused by that security group being attached to an EC2 instance or network interface.&lt;/p&gt;&#xA;&lt;p&gt;Interestingly Terraform messes up the order of the AWS API calls even when it (attempts to) remove the security group &lt;em&gt;and&lt;/em&gt; detach it from all EC2 instances that use it. In other words, Terraform tries to remove the security group before it has been detached from the EC2 instances, which results in the stall:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Making per-link DNS servers pushed from OpenVPN to systemd-resolved survive NetworkManager connection changes</title>
				<link>https://www.puppeteers.net/blog/making-per-link-dns-servers-pushed-from-openvpn-to-systemd-resolved-survive-networkmanager-connection-changes/</link>
				<pubDate>Tue, 03 Nov 2020 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/making-per-link-dns-servers-pushed-from-openvpn-to-systemd-resolved-survive-networkmanager-connection-changes/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt; the problem described in this article seems to be resolved in Fedora 36 (NetworkManager 1.38.0-2.fc36). It is still present in Fedora 35 (NetworkManager 1.32.12-2.fc35).&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt; there a companion article about solving this problem for Wireguard in &lt;a href=&#34;https://www.puppeteers.net/blog/making-per-link-dns-servers-added-by-wireguard-to-systemd-resolved-survive-networkmanager-connection-changes/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;In an the &lt;a href=&#34;https://www.puppeteers.net/blog/manage-linux-client-dns-settings-in-openvpn-and-wireguard/&#34;&gt;Manage Linux client DNS settings in OpenVPN and Wireguard&lt;/a&gt; article we described how to use the &lt;a href=&#34;https://github.com/jonathanio/update-systemd-resolved&#34;&gt;update-systemd-resolved&lt;/a&gt; script to update systemd-resolved per-link DNS servers automatically based on DNS servers pushed from an OpenVPN server. This is very convenient if you have to be connected to multiple remote locations each with their own DNS servers and zones.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Terraform 0.11-&gt;0.12 migration: stabs at the state file</title>
				<link>https://www.puppeteers.net/blog/terraform-0-11-0-12-migration-stabs-at-the-state-file/</link>
				<pubDate>Fri, 30 Oct 2020 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/terraform-0-11-0-12-migration-stabs-at-the-state-file/</guid>
				<description>&lt;p&gt;We maintain a rather complex AWS environment built with Terraform that uses nested modules and lots of per-resource provider configurations. Recently the pain of staying with Terraform 0.11 became too much, so we had to start the migration to Terraform 0.12, with 0.13 going to follow soon after. In general the &lt;a href=&#34;https://www.terraform.io/upgrade-guides/0-12.html&#34;&gt;official upgrade instructions&lt;/a&gt; were pretty good. Of course there was a lot of manual fixing that had to be done, and as I did not keep detailed notes I can&amp;rsquo;t recall all the steps I went through. But I think all or most of those can be found from other sources.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Puppet environment leakage</title>
				<link>https://www.puppeteers.net/blog/puppet-environment-leakage/</link>
				<pubDate>Wed, 01 Apr 2020 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/puppet-environment-leakage/</guid>
				<description>&lt;p&gt;Occasionally when working with feature branch and updating types and providers you may run into &lt;a href=&#34;https://puppet.com/docs/puppet/5.5/environment_isolation.html&#34;&gt;environment leakage issues&lt;/a&gt;. They manifest themselves as issues that make no particular sense and are caused by the wrong version of a type/provider such as puppetlabs-apt (see this &lt;a href=&#34;https://tickets.puppetlabs.com/browse/MODULES-8019&#34;&gt;issue&lt;/a&gt;) leaking into your feature environment. This can happen when you update external modules in your Puppetfile. The solution (or band-aid) is fortunately fairly easy. On the Puppetmaster run this command:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Terraform S3 access denied problems</title>
				<link>https://www.puppeteers.net/blog/terraform-s3-access-denied-problems/</link>
				<pubDate>Wed, 11 Sep 2019 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/terraform-s3-access-denied-problems/</guid>
				<description>&lt;p&gt;I&amp;rsquo;ve stumbled upon interesting access denied problems with S3-based Terraform state files recently. Suppose you have two or more Terraform root modules which use the same bucket for storing the state and just use a different key (=state file):&lt;/p&gt;&#xA;&lt;div class=&#34;code-block&#34;&gt;&#xA;    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;&#xA;      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;&#xA;    &lt;/button&gt;&#xA;    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;terraform {   backend &amp;#34;s3&amp;#34; {     bucket = &amp;#34;terraform-state&amp;#34;     key    = &amp;#34;root-module-1&amp;#34;     region = &amp;#34;eu-central-1&amp;#34;   } }&lt;/code&gt;&lt;/pre&gt;&#xA;  &lt;/div&gt;&lt;p&gt;and&lt;/p&gt;&#xA;&lt;div class=&#34;code-block&#34;&gt;&#xA;    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;&#xA;      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;&#xA;    &lt;/button&gt;&#xA;    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;terraform {   backend &amp;#34;s3&amp;#34; {     bucket = &amp;#34;terraform-state&amp;#34;     key    = &amp;#34;root-module-2&amp;#34;     region = &amp;#34;eu-central-1&amp;#34;   } }&lt;/code&gt;&lt;/pre&gt;&#xA;  &lt;/div&gt;&lt;p&gt;However, trying to access the state file in one root module works, but on the other you get a generic S3 Access Denied error:&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
