Turku Business Region webinaari 22.4.2020 kello 13–13.30, osana ICT-webinaarisarjaa.

Webinaarinaarissa kerromme lyhyesti mitä VPN (“Virtual Private Network”) tarkoittaa ja miksi VPN:n käyttö on käytännössä välttämätöntä turvallisten etäyhteyksien luomisessa. Lisäksi käymme lyhyesti läpi VPN-yhteyksien käyttöönoton yleiset vaatimukset.

Tämän jälkeen esittelemme OpenVPN:n, avoimen lähdekoodin VPN-sovelluksen, jota käytetään erittäin laajalti ympäri maailmaa. Sitten siirrymme OpenVPN:ään pohjautuvaan kaupalliseen OpenVPN Access Serveriin, joka tekee VPN-yhteyksien luomisesta ja ylläpidosta merkittävästi helpompaa. Esittelyn jälkeen teemme OpenVPN Access Serverin käyttödemon:

Occasionally when working with feature branch and updating types and providers you may run into environment leakage issues. 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 issue) 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:

OpenVPN and Wireguard are both used to provide secure, remote access to an organization’s internal services such as network shares (NFS and Samba), desktops and servers (SSH and RDP) or web services. Linux is generally a first-class citizen as far as clients are concerned but with one exception: accessing DNS through the VPN tunnel.

OpenVPN servers have the concept of pushing settings such as DNS servers to client. This happens by emulating a DHCP server. Windows OpenVPN clients for example are able to process this information automatically to update the (per-link) DNS server settings automatically. But Linux traditionally has not had this capability without support from “up” and “down” scripts. When one is using systemd-resolved the traditional ways such as using resolvconf or modifying /etc/resolv.conf directly no longer work or cause issues. Fortunately there is a good script, update-systemd-resolved, for automating the DNS server setup process for systemd-resolved. Basically it takes the list of DNS settings OpenVPN provides and converts them into dbus calls that modify the running systemd-resolved’s configuration.

NOTE: this article is somewhat outdated. Please refer to Serverless Puppet with control repo, Hiera, roles and profiles and Puppet Bolt instead.

Puppet Bolt is an orchestration tool similar to Ansible. It is suitable for multiple use-cases:

1. Running ad hoc commands on target nodes. We use this approach for testing Puppet feature branches before approving and merging them.

2. One-off configurations written in the Puppet language

3. Masterless Puppet environments (look here). You may not always have enough privileges, trust or will to manage a complete Puppet infrastructure including Puppetserver, PuppetDB and Puppet Agents.

As discussed in the introductory post one of the use-cases for Puppet Bolt is orchestration - running actions on multiple targets in a certain order, possibly using results of actions or data from some targets on other targets. Orchestration with Bolt plans is quite easy: you just create a plan with multiple TargetSpec parameters, each representing a target or a type of target. A classic example is two or more web servers behind a load balancer. In this case we do something even simpler and just take a fact from a node called “first” and create a file on node “second” that uses the value of that fact in a file.

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

In the previous blog post we created the Puppet type librenms_service and created a dummy skeleton for the provider implementation. We were able to use the type, but it did not yet do anything. In this blog post we move to implementing the create method, which in this case was the low-hanging fruit. At this point we do not need to worry about any existence checks (the exists? method) or trying to minimizing the number of API calls with self.prefetch or something similar.

This article is a part of this blog post series:

Writing Puppet types and providers looks like black magic even to those who have lots of experience in the Puppet language itself. While the official types development documentation is quite ok, provider documentation is definitely lacking. Not only are there no practical examples from real life, the important features such as prefetching, resource methods and flushing are described only on a very high level. The usual answer to lack of examples is “have a look at the built-in resources”. But when you look at any built-in resource, you realize that the code is very complex because

When you’re iterating over a hash you may end up having to treat the last hash entry differently. For example, if you’re creating entries to a JSON file you should have “},” in between the entries until you reach the last entry, where you must have just “}” or JSON data will be invalid.

Now, hashes do not have indexes, nor does Puppet support variable reassignment along the lines of $x = $x +1, so you’re out of luck trying to get the length and comparing that to a counter. So, you need some other way to detect when iteration has reached the last entry in the hash.

Usually writing rspec-puppet tests is straightforward. Then you run into some problem that does not make any sense. In my case I ran into a couple of duplicate resource declaration issues when adding rspec tests to our puppetmaster-installer. The error message was not that useful:

$ pdk test unit --tests=spec/classes/puppetboard_spec.rb
--- snip ---
 Failures:
 1) puppetmaster::puppetboard minimal settings on ubuntu-18.04-x86_64 is expected
    to compile into a catalogue without dependency cycles
    Failure/Error: it { is_expected.to compile }
      error during compilation: Evaluation Error: Error while evaluating a
      Resource Statement, Duplicate declaration: Class[Apache] is already
      declared; cannot redeclare (file: /home/samuli/opt/puppeteers/puppet-
      puppetmaster/spec/fixtures/modules/puppetmaster/manifests/puppetboard.pp,
      line: 156) (file: /home/samuli/opt/puppeteers/puppet-puppetmaster
      /spec/fixtures/modules/puppetmaster/manifests/puppetboard.pp, line: 156,
      column: 3) on node puppet.example.org
--- snip ---

That particular block of code in puppetboard.pp did include a parameterized call to the apache class. But nothing else (afaics) included that class. Also, in Vagrant the same code worked just fine, which made things seem even more bizarre. To add insult to the injury the error message did not tell where else the apache class was included. That would probably have been way too helpful.

I recently - again - had to import resources to Terraform (0.11.14) from AWS that were outside of the default AWS region and were managed in a nested (non-root) module. The root module contained the provider configuration, including multiple aliases to allow creation of resources in different regions, as well as the nested module call, here in a very simple version:

provider "aws" {
  region = "us-west-2"
}

provider "aws" {
  region = "us-east-1"
  alias  = "us-east-1"
}

provider "aws" {
  region = "us-west-2"
  alias  = "us-west-2"
}

module "cloud" {
  param = value
}

The goal was to import some aws_ses_email_identity resources into the “cloud” module. So, originally the cloud module had this: