Qubit Renegade

Migrating to GitLab

2019-09-08T07:00:29+00:00

After a bit of debate, I’ve moved the blog to GitLab Pages. This has nothing to do with the change in ownership at GitHub and everything to do with wanting more control over the build process. Unfortunately, GH Pages only supports a specific list of Jekyll plugins.

The blog may end up back on GitHub as the idea is “as little work as possible”… but for now we’re trying the GitLab experiment.

I’ll probably have more to say on this topic at a later point. This mostly serves to validate that our CDN is working.

Initial impressions (12 hours after initial post)

Well, out of the gate it was easy to implement automated spellcheck, however, redirecting the default gitlab.io domain to qubitrenegade.com was a bit tricky… It looks like this may be a feature coming soon, which is so far the only thing missing for feature parity with GitHub Pages.

Configuring Matrix and Riot for private Chat

2019-08-01T02:38:21+00:00

Configuring Matrix and Riot for Private Chat

It’s time to replace Slack and Discord. While they provided chat to make the transition to a “Virtual Workplace” easier, they are the very antithesis of the decentralized web. IRC was, and still is, an amazing technology. However, running an IRC server, while not hard, isn’t exactly easy, IRC suffers from the Network Effect making stand alone servers a bit pointless, and it’s not encrypted (yes you can do encryption over the wire, but the data is unencrypted at rest). Not to mention, you’re reliant on external tools for keeping history.

Enter Matrix. Matrix is “An open network for secure, decentralized communication”. Practically what this means, is Matrix attempts to solve the centralization problem by making federation easy, it solves the security problem by implementing an easy to use end-to-end encryption system, and attempts to solve the “Network Effect problem” by providing easy to use bridging with existing chat platforms (including but not limited to Slack, Discord, and IRC). It’s a complete, secure, chat, VoIP, and Video calling platform.

Mattermost is another “Slack alternative” that deserves a special mention and received serious consideration before Matrix was ultimately chosen. Mattermost vs Matrix is really out of the scope of this conversation. (Though I will say you absolutely can edit posts with Matrix)

Introduction

Matrix is a protocol. Which is defined by the Matrix Specification. Matrix defines client-to-server, server-to-server, and client-to-client interactions. What this means to the administrator/user is there is [potentially] a variety of server and client software to chose from. The reference implementation known as Synapse and Riot.im appear to be the de facto standard server at client, at the time of this writing.

Synapse has some great docs which cover nearly every scenario. There’s also some great guides to help get started.

In short we need to install and configure:

Synapse
Riot Web
NGINX
PostgreSQL
CertBot
TURN Server (we’ll use coturn)

This is an attempt to collate all the information into a single procedure based on the information learned before it is forgotten.

This guide is written as if all applications are running on the same server, however, each service can be run in its own VM/container/etc.

Prerequisites

Minimum Virtual Machine
- 1 CPU
- 1 GB Ram
- 25 GB root /
- 10 GB /var/lib/postgresql chown postgres:postgres /var/lib/postgresql XFS, mounted noatime
Free CloudFlare account
- DNS Subdomain Entries, recommend both A and AAAA entries if IPv6 is supported:
  - chat - Riot Web address
  - matrix - Matrix Server Address
  - turn - TURN Server address

To make it easier on ourselves since we’re using CloudFlare, we’ll leverage the certbot-dns-cloudflare CertBot plugin for CertBot authentication.

Install Packages

Add Matrix.org Repo

wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
sh -c 'echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" |  sudo tee /etc/apt/sources.list.d/matrix-org.list'

Add CertBot Repo

add-apt-repository ppa:certbot/certbot
add-apt-repository universe

Add PostgreSQL Repo

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'

Package List

Synapse

apt install matrix-synapse-py3 nginx certbot python-certbot-nginx python3-certbot-dns-cloudflare

PostgreSQL

Common and/or Contrib you be the judge.

apt install postgresql postgresql-contrib postgresql-common

Riot Web

apt install nginx certbot python-certbot-nginx python3-certbot-dns-cloudflare

TURN Server

apt install coturn certbot python3-certbot-dns-cloudflare

All in one

apt install matrix-synapse-py3 coturn \
    postgresql postgresql-contrib postgresql-common \
    nginx certbot python-certbot-nginx python3-certbot-dns-cloudflare \
    libjemalloc

libjemalloc is optional, results are unclear if it actually helps memory usage in Python3.

Setup CertBot

CloudFlare Credentials

Create an /etc/certbot-cloudflare.ini. N.b.: you currently must use the “CloudFlare Global API Key” for certbot to be able to authenticate.

dns_cloudflare_email = "your-cloudflare-email@protonmail.com"
dns_cloudflare_api_key = "<GLOBAL API KEY>"

Run CertBot

CertBot will use the first domain listed when generating the certificate path.

certbot certonly -a dns-cloudflare --dns-cloudflare-credentials /etc/certbot-cloudflare.ini \
  --expand -d example.com,www.example.com,matrix.example.com,chat.example.com,turn.example.com

This will create a timer which can be validated with systemctl list-timers

# systemctl list-timers -all | grep certbot
Thu 2019-08-01 04:41:16 UTC  14min left    Wed 2019-07-31 21:19:33 UTC  7h ago      certbot.timer                certbot.service

Configure PostgreSQL

See Tuning for info on tuning PgSQL.

Create Database User

sudo -u postgres createuser --pwprompt synapse_user

Create Database

sudo -u postrees psql -c '
  CREATE DATABASE synapse
    ENCODING 'UTF8'
    LC_COLLATE='C'
    LC_CTYPE='C'
    template=template0
    OWNER synapse_user;'

Configure Coturn

Coturn Config

Create a /etc/turnserver.conf. This is the minimal options required.

Enable Coturn

sh -c 'echo TURNSERVER_ENABLED=1 >> /etc/default/coturn'

Start Coturn

systemctl enable coturn # this might actually not be required because it still uses sysv init...
systemctl start coturn

Install Riot Web

Download latest Release

The latest release can be found here

wget -O- https://github.com/vector-im/riot-web/releases/download/v1.3.0/riot-v1.3.0.tar.gz | tar vzxf - -C /var/www/html

Link to Riot root dir

We’ll use /var/www/html/riot as the DocumentRoot of our chat.example.com domain. This makes upgrading (or downgrading) in the future easier. e.g.: we can upgrade without restarting NGINX.

ln -s /var/www/html/riot-v1.3.0 /var/www/html/riot

Configure Synapse

Server Name Config

We don’t want our name to show up as @foo:matrix.example.com, so we’ll update /etc/matrix-synapse/conf.d/server_name.yaml to point our server name to example.com.

server_name: example.com

Homeserver Config File

This is an opinionated /etc/matrix-synapse/homeserver.yaml file and by no means covers every config option. (We’ll look at how we can break this into multiple smaller files in a future post)

Optional Tuning

jemalloc purportedly reduced memory usage in Python2 up to 40% in some cases. However, it is unclear how jemalloc affects Python3 memory usage. If any instability is encountered, this would be the first thing to undo.

sh -c 'echo "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1" | tee -a /etc/default/matrix-synapse'

Start Synapse

systemctl start matrix-synapse

Verify our Setup by registering a new user

Execute the register_new_matrix_user script to register a new user and validate our Synapse configuration is operational.

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Troubleshooting

If any errors are encountered with the registration of a new user, refer to /var/log/matrix-synapse/homeserver.log and systemctl status matrix-synapse and journalctl -u matrix-synapse

Configure NGINX

We need to configure three sites, the “default” page, or the example.com main site, chat.example.com where we’ll host the Riot Web app, and matrix.example.com which is where Synapse is running.

We’ll mimic the Apache method of creating our site configs in /etc/nginx/sites-available and linking them to /etc/nginx/sites-enabled/. This makes enabling/disabling sites easy for purposes of scaling.

Setup Sites

Default - `example.com`

In many cases, this will already be configured and running a site. We need to be able to serve two files from example.com/.well-known/matrix, the below config identifies a SIMPLE configuration. The most important part for the operation of Synapse/Riot is the location

Riot Web - `chat.example.com`

Nothing too fancy here, we’re just serving the static files, all the magic happens in the client.

Synapse - `matrix.example.com`

Create “well known” files

`/var/www/html/.well-known/matrix/client`

{
    "m.homeserver": {
        "base_url": "https://matrix.example.com"
    },
    "m.identity_server": {
        "base_url": "https://vector.im"
    }
}

`/var/www/html/.well-known/matrix/server`

{ "m.server": "matrix.example.com:443" }

Restart Nginx

systemctrl restart nginx

Firewall Rules

UFW Setup

Update /etc/services

# grep turn /etc/services
stun-turn       3478/tcp                        # Coturn
stun-turn       3478/udp                        # Coturn
stun-turn-tls   5349/tcp                        # Coturn
stun-turn-tls   5349/udp                        # Coturn
turnserver-cli  5766/tcp                        # Coturn

Enable UFW

ufw allow ssh
ufw allow http
ufw allow https
ufw allow stun-turn
ufw allow stun-turn-tls
ufw enable

Digital Ocean Rules

This terraform sets up firewall rules to block all communication to the server on 80 and 443 except for traffic from CloudFlare servers.

N.b. CloudFlare doesn’t proxy TURN traffic, so we recommend running your TURN server on a separate host.

Conclusion

At this point you should have a running and functional

Next up, we’ll look at how to automate deploying Synapse, Riot, and Coturn.

Configuring GPU Passthrough with VFIO on Fedora 30 notes

2019-07-17T02:38:21+00:00

GPU Passthrough is all the rage. The ArchLinux Wiki does an amazing job explaining all the different ways to setup VFIO/GPU passthrough. These are my notes for setting up GPU Passthrough in Fedora 30 with two identical cards. This does not aim to be a comprehensive guide.

I believe, while untested, this method can be used for setups with a different cards as well.

Setup KVM

Install KVM

sudo dnf -y install bridge-utils libvirt virt-install qemu-kvm virt-top libguestfs-tools virt-manager

Configure bridge networking using NetworkManager (this is largely due to laziness when setting the OS up, NM is the default, so I kinda just deal with it…)

# make up a bridge name, I like br0
export BR_NAME=br0
# this will vary depending on the mobo/eth card.  see `ip addr` to find device name
export BR_INTERFACE=enp5s0

# Get our device UUID
BR_INT_OG_UUID=$(nmcli -g GENERAL.CON-UUID device show "${BR_INTERFACE}")

# Create bridge
nmcli connection add type bridge autoconnect yes con-name "{BR_NAME}" ifname "${BR_NAME}"

# Disable STP
nmcli connection modify "${BR_NAME}" bridge.stp no

# Add our interface to our bridge
nmcli connection add type bridge-slave autoconnect yes con-name ${BR_INTERFACE} ifname ${BR_INTERFACE} master ${BR_NAME}

# Turn off our old interface
nmcli con down "${BR_INTERFACE}"

# Turn on our new bridge
nmcli con up "${BR_NAME}"

# delete our old interface config
nmcli con delete "${BR_INT_OG_UUID}"

Update Kernel CLI parameters

Append to GRUB_CMDLINE_LINUX in /etc/default/grub to enable iommu and load our vfio-pci driver. We do this early to ensure vfio is able to claim the devices before the kernel does.

GRUB_CMDLINE_LINUX="amd_iommu=on iommu=pt rd.driver.pre=vfio-pci"

Modprobe Config

Create /etc/modprobe.d/vfio.conf to tell modprobe how to load vfio-pci

install vfio-pci /sbin/vfio-pci-override.sh

Dracut Config

Create /etc/dracut.conf.d/vfio.conf to load our drivers and setup script into our initramfs.

add_drivers+="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"
install_items+="/sbin/vfio-pci-override.sh /usr/bin/dirname"

VGA Passthrough Script

Create /sbin/vfio-pci-override.sh, this will passthrough all non-boot VGA devices, including audio and USB controllers if they exist.

Update our boot system

# update initramfs
# or dracut -f --regenerate-all
dracut -f --kver $(uname -r)

# update grub
grub2-mkconfig > /etc/grub2-efi.cfg

Post setup Check

(this could be improved)

“failed to setup container for group XX: failed to set iommu for container: Operation not permitted”

Shoutout to /u/degerdem and /u/WiFivomFranman for identifying that you need to go into the BIOS

Advanced -> AMD PBS ** Enumerate all IOMMU in IVRS = Enabled

Nvidia GeForce Card reports Error 43 in Guest OS

In the <features></features> stanza, add ` to the hyperv block and hidden state=on`.

Before:

  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
    <vmport state='off'/>
  </features>

After:

  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor_id state='on' value='10DE'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
    <vmport state='off'/>
  </features>

HabiChef: Pt2 Applying Change

2019-04-28T22:29:47+00:00

In our last post we discussed how to package our Chef Cookbooks in a Habitat package using Policyfiles. We showed that we could package all of our cookbooks into a single, easily distributable, package.

We were even able to set node attributes via the Policyfile enabling us to create Policyfile specific settings. However, we don’t want to manage a dozen different versions of the resolver package since the only thing that changes is node attributes.

For instance, all of our servers use the same DNS server but will have a different domain based on the data center they live in. We’ll use qubitrenegade.com, so suppose we have us-east-1.qubitrenegade.com and us-west-1.qubitreengade.com.

Setup

First, let’s update our base policy file. Let’s add a domain attribute to our default settings.

--- a/policyfiles/base.rb
+++ b/policyfiles/base.rb
@@ -4,7 +4,10 @@ name 'base'
 default_source :supermarket

 # Environment Attributes
-default['resolver']['nameservers'] = ['1.1.1.1']
+default['resolver'] = {
+  'domain' = 'qubitrenegade.com',
+  'nameservers' = ['1.1.1.1'],
+}

Multiple Policyfiles

Since policy files include other policy files, we could create a new policy for each environment.

First, let’s update our Habitat plan.sh to include the policy name in the name of our package.

--- a/habitat/plan.sh
+++ b/habitat/plan.sh
@@ -1,6 +1,11 @@
 # habichef_demo/habitat/plan.sh
-scaffold_policy_name="base"
-pkg_name="habichef_demo"
+if [ -z ${CHEF_POLICYFILE+x} ]; then
+  policy_name="base"
+else
+  policy_name="${CHEF_POLICYFILE}"
+fi
+
+pkg_name="habichef_demo-${policy_name}"

Next, let’s create a Policyfile for us-east-1 that includes our base Policyfile.

# habichef_demo/policyfiles/us-east-1.rb
name 'us-east-1'

include_policy 'base'

default['resolver']['domain'] = 'us-east-1.qubitrenegade.com'

Then we can build our project, using the same process as before. (If you’re receiving errors, you can check out the 2019-04-28-pt1-multiple-policy-files branch of the HabiChef Demo repo.

$ hab studio enter

... snip ...

[1][default:/src:0]# build
... snip ...

  habichef_demo-base: Installed Path: /hab/pkgs/qbrd/habichef_demo-base/0.1.0/20190428185221
   habichef_demo-base: Artifact: /src/results/qbrd-habichef_demo-base-0.1.0-20190428185221-x86_64-linux.hart
   habichef_demo-base: Build Report: /src/results/last_build.env
   habichef_demo-base: SHA256 Checksum: 4a126ec5c47dba1643ef767c7ccc02acd36ea780d2f88110db9c964c4598c2b9
   habichef_demo-base: Blake2b Checksum: 7fc45fcf07bebe57f90301c0c83df6700f772fc8925ec0162b1efbfa85b89b6a
   habichef_demo-base:
   habichef_demo-base: I love it when a plan.sh comes together.
   habichef_demo-base:
   habichef_demo-base: Build time: 0m5s
[2][default:/src:0]#

However, note that the name of our package is habichef_demo-base. We need to set ` CHEF_POLICYFILE` environment variable to build the correct package.

[2][default:/src:0]# CHEF_POLICYFILE=us-east-1 build
... snip ...
Building policy us-east-1
Error: Failed to generate Policyfile.lock
Reason: (ChefDK::LocalPolicyfileLockNotFound) The provided path ./base.lock.json does not exist.

Well, it seems that something is blowing away the base.lock.json file… This probably needs follow up with the Habitat team.

UPDATE: #2536 indicates I may have misunderstood the usage pattern.

Regardless, this example starts to break down as you start to deploy to more environments as you have effectively the same package being generated with minor changes.

`user.toml` Config Changes

Let’s continue working with habichef_demo package.

If you’ve been following along, we’ll want to explicitly set our scaffold_policy_name="base"

--- a/habitat/plan.sh
+++ b/habitat/plan.sh
@@ -5,8 +5,8 @@ else
   policy_name="${CHEF_POLICYFILE}"
 fi

-scaffold_policy_name="${policy_name}"
-pkg_name="habichef_demo-${policy_name}"
+scaffold_policy_name="base"
+pkg_name="habichef_demo"

(You can also remove the conditional statement, or just check out the 2019-04-28-pt2-user.toml branch)

Next, let’s create our user.toml file. Habitat will load user config settings from /hab/user/<service name>/config/user.toml.

[15][default:/src:130]# mkdir -p /hab/user/habichef_demo/config/
[16][default:/src:0]# printf '[attributes]\n  [attributes.resolver]\n    domain = "us-east-1.qubitrenegade.com"\n' | tee /hab/user/habichef_demo/config/user.toml
[attributes]
  [attributes.resolver]
    domain = "us-east-1.qubitrenegade.com"

Then we’ll build and run the package.

$ hab studio enter
... snip ...
[1][default:/src:0]# build
... snip ...
   habichef_demo: Installed Path: /hab/pkgs/qbrd/habichef_demo/0.1.0/20190428192425
   habichef_demo: Artifact: /src/results/qbrd-habichef_demo-0.1.0-20190428192425-x86_64-linux.hart
   habichef_demo: Build Report: /src/results/last_build.env
   habichef_demo: SHA256 Checksum: b0016e36ae76f77e876e27681219eae415eb84ef5801813d83fbd56c46163099
   habichef_demo: Blake2b Checksum: 1be21e1176536917f28b50f3b2856acdc7ad51116009c8aee23ef7bb48708880
   habichef_demo:
   habichef_demo: I love it when a plan.sh comes together.
   habichef_demo:
   habichef_demo: Build time: 0m7s
[2][default:/src:0]# source results/last_build.env
[3][default:/src:0]# hab svc load $pkg_ident
[4][default:/src:0]# sup-log
... snip ...
habichef_demo.default(O):     +# This file is generated by Chef
habichef_demo.default(O):     +# Do not edit, changes will be overwritten
habichef_demo.default(O):     +#
habichef_demo.default(O):     +domain us-east-1.qubitrenegade.com
habichef_demo.default(O):     +nameserver 1.1.1.1

As you can see, you can set per-instance settings via user.toml. Typically this is populated by a third-party tool such as Chef (though in the case of HabiChef, is it the chicken or the egg?), or Terraform. Terraform is particularly useful when coupled with the Habitat provisioner.

Running config changes

We’ve been running HabiChef for a few weeks now and have several nodes deployed (possibly even with a bastion ring, but that is a topic for another day). A mandate comes down from management that we need to change all of the domains. Sure, we could log into every node and update the user.toml file… but that seems like a lot of work and rather error prone.

Fortunately, Habitat provides a method for applying config changes to a running cluster.

First, let’s create a temporary .toml file. (There is an example file in the habichef_demo/habitat directory)

# /tmp/config-demo.toml
[attributes]
  [attributes.resolver]
    domain = "example.local"

Then we can apply it with:

hab config apply <SERVICE_GROUP> <VERSION_NUMBER> <FILE>

We’ll use a timestamp generated with $(date +%s) as the version number. This way when we apply the update again we don’t have to modify the command.

Our command should look something like:

hab config apply habichef_demo.default $(date +%s) habitat/config-apply-demo.toml

And we should see something to the effect of:

[2][default:/src:0]# hab config apply habichef_demo.default $(date +%s) habitat/config-apply-demo.toml && sup-log

... snip ...

hab-sup(CMD): Setting new configuration version 1556489698 for habichef_demo.default
habichef_demo.default(CF): Modified configuration file /hab/svc/habichef_demo/config/attributes.json

... snip ...

habichef_demo.default(O):   * template[/etc/resolv.conf] action create
habichef_demo.default(O):     - update content in file /etc/resolv.conf from 217c99 to 19c14a
habichef_demo.default(O):     --- /etc/resolv.conf      2019-04-28 19:44:54.719939924 +0000
habichef_demo.default(O):     +++ /etc/.chef-resolv20190428-32280-15wxpjo.conf  2019-04-28 22:15:11.311781489 +0000
habichef_demo.default(O):     @@ -2,7 +2,7 @@
habichef_demo.default(O):      # This file is generated by Chef
habichef_demo.default(O):      # Do not edit, changes will be overwritten
habichef_demo.default(O):      #
habichef_demo.default(O):     -domain asdf.com
habichef_demo.default(O):     +domain example.local

Success! Typically these changes would be applied to a cluster, and the update propagated through the cluster via Habitat’s inbuilt gossip layer. So if you’re thinking this is a lot of work to change the domain in the resolv.conf file, you’re not wrong.

Conclusion

Today we’ve seen three different ways (well, two and a half) to apply changes to HabiChef cookbooks. Big picture, you’d probably want to manage these via some form of CI pipeline, and discourage users from manually hab config applying changes. Hopefully the gravity of being able to apply config changes to a cluster will become more apparent in the “Habitat: PtX Running at Scale”.

Tune in next time when we discuss the internals of scaffolding-chef and how to include local cookbooks.

HabiChef: Packaging Chef for easy consumption

2019-04-28T04:29:47+00:00

Dependencies are hard. There are many different strategies to attempt to solve this problem.

Policyfiles

Chef Environments have issues. They’re unversioned meaning they require an external process of managing version. Once your environments get to a certain size, it can be a daunting task to update them. Unless you are explicitly pinning the cookbook versions of every cookbook in your environment, you also expose yourself to risk when pushing changes to cookbooks. In an environment where there may exist multiple Chef Servers that aren’t all managed by the same team/process, communicating the updated version pinnings can also be a pain point.

Policy files are effectively an attempt to version environments and cookbook version pinnings while providing a simplified user interface. This promotes safer workflows as new cookbooks published to the Chef Server won’t be immediately consumed by all nodes, similar to managing version pinnings via environment.

Habitat

Habitat automates applications by bundling the application–typically compiling from source, configuration, and logic to manage the configuration–including configuration updates–together. However, not all applications lend themselves to being neatly packaged. We all have those monolithic, CotS, prepackaged from the vendor, applications.

For those cases where our application can’t be built from source, or doesn’t lend itself to easily being packaged up: enter HabiChef. With HabiChef we’re bundling our standard set of Chef tools, which is the desired state of the system, in an easily distributable and manageable artifact.

Example

Let’s try an example.

Currently, there isn’t a generator, so we’re going to go at it by hand. There’s a skeleton project linked later on that you’ll be able to clone and use.

Skeleton File Structure

First we’ll create our skeleton file structure. Minimally we’ll need a directory for our: project, policy files, and habitat plan. In this example we’ll also write our own cookbook, but the cookbook directory is optional.

$ mkdir -p habichef_demo/{cookbooks,habitat,policyfiles}
$ printf 'results\n.kitchen\n' > .gitignore

Habitat Plan

Next we’ll create the Habitat plan.sh and default.toml files. We’re going to assume we’re not reporting to Automate for the purposes of this demo, refer to the project linked at the end for those configuration options.

`plan.sh`

The plan.sh is the brains of the operation. This describes how to package and run our application.

# habichef_demo/habitat/plan.sh
scaffold_policy_name="base"
pkg_name="habichef_demo"
pkg_origin="qbrd"
pkg_version="0.1.0"
pkg_maintainer="QubitRenegade"
pkg_description="The Chef $scaffold_policy_name Policy"
pkg_upstream_url="http://chef.io"
pkg_scaffolding="core/scaffolding-chef"
pkg_svc_user="root"
pkg_svc_group="root"

We’ve discussed Habitat plans in the past so we won’t delve too much into detail here. What’s interesting to note is that we’ve eschewed any of our standard hooks for leveraging this core/scaffolding-chef scaffolding. This manages the chef-client in the same way as any other Habitat managed service (hooks etc.).

`defaut.toml`

The default.toml sets up default options for our Chef Client as a Service. We need to set a few options here otherwise our scaffolding will fail with some less than obvious errors.

# habichef_demo/habitat/default.toml
log_level = "warn"
# All times are in seconds
interval = "1800"
splay = "300"
splay_first_run = "10"
run_lock_timeout = "30"

[data_collector]
  enable = false

These are fairly standard chef-client options. Refer to the chef-client documentation for full explanation of the remaining options.

Policyfile

Next we’ll create a basic policy file. We’ll modify this later, but for now, we want to include a cookbook from the Supermarket.

# policyfiles/base.rb
name 'base'
# Where to find external cookbooks:
default_source :supermarket

# Environment Attributes
default['resolver']['nameservers'] = ['1.1.1.1']

# Your Run List
run_list [
  'resolver::default',
]

Building Our Package

Now it’s time to build our project!

If you haven’t already, change into your habichef_demo directory. i.e.: assuming it’s in your home dir:

$ cd ~/habichef_demo

If you’re building from a CI tool, you likely want to build your package directly with hab pkg build . or similar.

Habitat Studio

However, Habitat comes with a handy chroot environment. We can enter this cleanroom build environment, then build and test the package there.

Let’s enter the studio with hab studio enter, you’ll see a lot of output, and it should drop you into a shell.

$ hab studio enter
[sudo hab-studio] password for qubitrenegade:
   hab-studio: Creating Studio at /hab/studios/home--qubitrenegade--habichef_demo (default)

... snip ...

   hab-studio: Entering Studio at /hab/studios/home--qubitrenegade--habichef_demo (default)
   hab-studio: Exported: HAB_ORIGIN=qbrd

--> Launching the Habitat Supervisor in the background...
    Running: hab sup run
    * Use 'hab svc start' & 'hab svc stop' to start and stop services
    * Use 'sup-log' to tail the Supervisor's output (Ctrl+c to stop)
    * Use 'sup-term' to terminate the Supervisor
    * To pass custom arguments to run the Supervisor, export
      'HAB_STUDIO_SUP' with the arguments before running
      'hab studio enter'.

--> To prevent a Supervisor from running automatically in your
    Studio, export 'HAB_STUDIO_SUP=false' before running
    'hab studio enter'.

[1][default:/src:0]#

Build our Package

As we said above, from outside of the studio we can execute hab pkg build . to build our package. Without any flags this will destroy any existing studios, spawn a new one, and build our package in the new studio. However, since we are now in the Habitat Studio and therefore in a chroot environment, we can’t run hab pkg build . as this will attempt to spawn a chroot jail inside a chroot jail.

From within our studio we need to issue the build command.

[1][default:/src:0]# build
   : Loading /src/habitat/plan.sh
   habichef_demo: Plan loaded
   habichef_demo: Validating plan metadata
   habichef_demo: Using HAB_BIN=/hab/pkgs/core/hab/0.79.1/20190410220617/bin/hab for installs, signing, and hashing
   habichef_demo: hab-plan-build setup
   habichef_demo: Writing pre_build file
   habichef_demo: Resolving scaffolding dependencies
» Installing core/scaffolding-chef

... snip ...

   habichef_demo: Installing /src/habitat/../policyfiles/base.rb
Building policy base
Expanded run list: recipe[resolver::default]
Caching Cookbooks...
Installing resolver 2.1.0

Lockfile written to /src/policyfiles/base.lock.json
Policy revision id: eb77ea2f4542b34427531c139129bd1bc026c57b12733c53442e2af1f5340293

... snip ...

   habichef_demo: hab-plan-build cleanup
   habichef_demo:
   habichef_demo: Source Path: /src
   habichef_demo: Installed Path: /hab/pkgs/qbrd/habichef_demo/0.1.0/20190428033409
   habichef_demo: Artifact: /src/results/qbrd-habichef_demo-0.1.0-20190428033409-x86_64-linux.hart
   habichef_demo: Build Report: /src/results/last_build.env
   habichef_demo: SHA256 Checksum: 1cacfcb1f90f9a162331fb85376a16e578bc9a6740e1eecbd3d2e78639fea111
   habichef_demo: Blake2b Checksum: 5e35d5950dc75e35ea7eb43f3a4e8745c6ac3c4cf350e51221bdbc0b546632b8
   habichef_demo:
   habichef_demo: I love it when a plan.sh comes together.
   habichef_demo:
   habichef_demo: Build time: 0m51s
[2][default:/src:0]#

Congrats! You now have your first Habitat bundled Chef cookbook!

If we ls the results/ directory, you should see a .hart artifact and a last_build.env file.

The last_build.env file contains information about the last build.

pkg_origin=qbrd
pkg_name=habichef_demo
pkg_version=0.1.0
pkg_release=20190428033409
pkg_target=x86_64-linux
pkg_ident=qbrd/habichef_demo/0.1.0/20190428033409
pkg_artifact=qbrd-habichef_demo-0.1.0-20190428033409-x86_64-linux.hart
pkg_sha256sum=1cacfcb1f90f9a162331fb85376a16e578bc9a6740e1eecbd3d2e78639fea111
pkg_blake2bsum=5e35d5950dc75e35ea7eb43f3a4e8745c6ac3c4cf350e51221bdbc0b546632b8

This means that we can source the file to export these variables to our environment.

Next, let’s run it!

Running our package in Habitat Studio

To make things easier, first, let’s source our last_build.env file.

[4][default:/src:0]# source results/last_build.env
[5][default:/src:0]# echo $pkg_ident
qbrd/habichef_demo/0.1.0/20190428031740

Now that we have our environment variables loaded, we can run our package.

[6][default:/src:0]# hab svc load $pkg_ident
The qbrd/habichef_demo/0.1.0/20190428033409 service was successfully loaded

And then we’ll start our package:

[7][default:/src:0]# hab svc start $pkg_ident
Supervisor starting qbrd/habichef_demo/0.1.0/20190428033409. See the Supervisor output for more details.

We can see our service is running with hab svc status

[8][default:/src:0]# hab svc status
package                                  type        desired  state  elapsed (s)  pid   group
qbrd/habichef_demo/0.1.0/20190428033409  standalone  up       up     2            1918  habichef_demo.default

If we view our log, with either sup-log or less -R /hab/sup/default/sup.log, we should see the update to the resolv.conf.

[9][default:/src:0]# sup-log
--> Tailing the Habitat Supervisor's output (use 'Ctrl+c' to stop)
habichef_demo.default(SR): Initializing
habichef_demo.default(SV): Starting service as user=root, group=root
habichef_demo.default(O): Starting Chef Client, version 14.12.9
habichef_demo.default(O): Using policy 'base' at revision 'eb77ea2f4542b34427531c139129bd1bc026c57b12733c53442e2af1f5340293'
habichef_demo.default(O): resolving cookbooks for run list: ["resolver::default@2.1.0 (6bbbd0f)"]
habichef_demo.default(O): Synchronizing Cookbooks:
habichef_demo.default(O):   - resolver (2.1.0)
habichef_demo.default(O): Installing Cookbook Gems:
habichef_demo.default(O): Compiling Cookbooks...
habichef_demo.default(O): Converging 1 resources
habichef_demo.default(O): Recipe: resolver::default
habichef_demo.default(O):   * template[/etc/resolv.conf] action create
habichef_demo.default(O):     - update content in file /etc/resolv.conf from 14236b to 82a27b
habichef_demo.default(O):     --- /etc/resolv.conf      2019-04-28 03:41:22.037991908 +0000
habichef_demo.default(O):     +++ /etc/.chef-resolv20190428-1929-1o2aqzr.conf   2019-04-28 03:41:27.218028370 +0000
habichef_demo.default(O):     @@ -1,5 +1,7 @@
habichef_demo.default(O):     -# Generated by NetworkManager
habichef_demo.default(O):     -nameserver 1.0.0.1
habichef_demo.default(O):     -nameserver 8.8.8.8
habichef_demo.default(O):     +#
habichef_demo.default(O):     +# This file is generated by Chef
habichef_demo.default(O):     +# Do not edit, changes will be overwritten
habichef_demo.default(O):     +#
habichef_demo.default(O):     +search
habichef_demo.default(O):     +nameserver 1.1.1.1
habichef_demo.default(O):
habichef_demo.default(O): Running handlers:
habichef_demo.default(O): Running handlers complete
habichef_demo.default(O): Chef Client finished, 1/1 resources updated in 01 seconds

Conclusion

Today we’ve seen how we can bundle our Chef cookbooks using policy files to set the environment and run list. The habichef-skeleton repo contains the basic skeleton we’ve outlined here. The habichef_demo contains the project we’ve built here, there is a 2019-04-27 branch and tag. You can also download and run the Habitat package with a hab pkg install qbrd/habichef_demo.

Tune in next time when we demonstrate adding local cookbooks and applying changes to running environments.

Habitat and Consul: Client Mode and Registering Services

2018-06-06T06:29:47+00:00

Previously on “As the QubitRenegade turns…”

Consul an OpenSource(ish, there’s an enterprise version that has some awesome features) Distributed, Highly Available, Service Discovery, Health Checking, KV Store, that provides federated Multi Datacenter support. (disclaimer: I am in absolutely no way, shape, or form associated with HashiCorp. All opinions are my own and not influenced by schwag. I just happen to think they make a pretty swell product… even if it is written in go ;) )
Habitat an OpenSource, Artifact Builder, Artifact and Service Manager, Docker/Kubernetes/Serverless Enabler, sane Docker container builder system, with Distributed Service Discovery and “build once run anywhere (no really)” mentality.
Docker is how most people do containers. Just… I’ll post the opinion piece soon. Docker is fine.

Prerequisites

High level Overview

In the last installment, we exported a Core habitat package to a Docker container, then started several instances to build a cluster leveraging Habitat’s service discovery. To follow along you don’t necessarily need all five servers, a single node running in dev mode would be sufficient. We’ll proceed as though you have a full cluster to work with.

Today we’ll explore running Consul in “client” mode.

Justification

Initially, I wanted to have the ability to run core/consul in either “Client” or “Server” mode. The primary difference is that Consul “Servers” participate in gossip and present a Web UI. Technically the client could present a Web UI. When running other services (Vault, Nomad, etc. which we’ll touch on in a later post), HashiCorp recommends running Consul in client mode locally and not allowing the tools to communicate directly with the consul server.

When discussing Consul, we speak about “Server” and “Client” mode; even though it’s the same binary run with different CLI parameters, “client” and “server” makes a natural demarcation which lends itself to the segregation of packages.

Security

It’s worth noting that Habitat and Consul both have methods of encrypting communication. For the time being this guide is putting that aside, with a note that we will cover it eventually.

Building Consul Client

The Habitat plan source can be found on github

If you want to just run it, skip to Exporting Consul Client below.

Service Config Files

To enable what is essentially “arbitrary” configuration files, we can use the toJson helper method to turn the default.toml/user.toml config into JSON structures. As Handlebars is fairly limited, there is no “else if” clause, we generate correct JSON and allow Consul to complain about the configuration file.

{
  {{ #if cfg.service }}
    "service": {{toJson cfg.service}}{{#if cfg.services}},{{/if}}
  {{ /if }}
  {{ #if cfg.services}}
    "services": {{toJson cfg.services}}
  {{ /if }}
}

This will allow a minimal configuration such as:

[service]
name = "foo"
[service.checks]
interval = "1s"

Which will generate the JSON:

{
  "service": {
    "name": "foo",
    "checks": [
      {
        "interval": "1s"
      }
    ]
  }
}

(just not pretty formatted)

Exporting Consul Client

The Consul Client package is really designed as a building block for other packages that need to leverage a Consul Client. For demonstrative purposes, we’re just going to run Consul by itself.

Enter Studio

If you’re not in a Linux environment, you’ll need to enter the habitat studio:

$ hab studio enter

Export `qubitrenegade/consul-client`

Run the hab pkg command to export qubitrenegade/consul-client to a docker container.

$ hab pkg export docker qubitrenegade/consul-client

This will create a directory $(pwd)/results and a file $(pwd)/results/last_docker_export.env which exports a number of environment variables if sourced. This enables such idioms as docker run -it $name.

We will specify the origin and package name in examples below.

Run your docker containers:

You will either need to open multiple terminal windows, or replace the -e with -de

This also assumes you have no more than one (1) running container before starting this process. If you have more than one (1) running container, adjust your IPs accordingly.

Create a service config file and save it as services.json:

{
  "client": {
    "enable_script_checks": true
  },
  "service": {
    "name": "simple-service",
    "checks": [
      {
        "name": "is_alive",
        "args": ["/bin/bash", ":(){ echo "I'm alive!"; return 200; }; :"],
        "interval": "1s"
      }
    ]
  }
}

Then start your docker container while importing your settings (adjust peer IPs as necessary):

docker run -e "HAB_CONSUL_CLIENT=$(< services.json)" qubitrenegade/consul-client --peer 172.17.0.4 --bind consul-server:consul.default

Now when visit http://localhost:8500 You should see your service registered!

Examples

A number of service examples are provided in the example directory.

To use any of the examples, you can import the config values as environment variables:

docker run -e "HAB_CONSUL_CLIENT=$(curl https://raw.githubusercontent.com/qubitrenegade/habitat-consul-client/master/example/service-with-no-checks.json)" qubitrenegade/consul-client --peer 172.17.0.4 --bind consul-server:consul.default

Habitat & Consul: Gossip: You won’t believe the dirt!

2018-06-04T18:29:47+00:00

Previously on “As the QubitRenegade turns…”

Consul an OpenSource(ish, there’s an enterprise version that has some awesome features) Distributed, Highly Available, Service Discovery, Health Checking, KV Store, that provides federated Multi Datacenter support. (disclaimer: I am in absolutely no way, shape, or form associated with HashiCorp. All opinions are my own and not influenced by schwag. I just happen to think they make a pretty swell product… even if it is written in go ;) )
Habitat an OpenSource, Artifact Builder, Artifact and Service Manager, Docker/Kubernetes/Serverless Enabler, sane Docker container builder system, with Distributed Service Discovery and “build once run anywhere (no really)” mentality.
Docker is how most people do containers. Just… I’ll post the opinion piece soon. Docker is fine.

Prerequisites

You’ll need to install them both. Basically we’re going to run a bunch of containers instead of a bunch of servers. If we were going to push this into production, it doesn’t really make sense to run three-five instances of a service on on VM… if that VM dies, then there goes your cluster. But with Habitat we can basically run the service in any format we want, containers the same way we’d run them if they were individual VMs or being published to a Kubernetes cluster. Kubernetes expects you to show up to the party with containers ready to go, Habitat is the one who comes up with the kegs in the trunk.

High level Overview

Habitat needs at least three nodes to form consensus and elect a “leader”. This prevents “split brain” where two nodes both think they are the leader. Clusters then scale to uneven numbers… 3, 5, 7, etc. Consul needs at least three nodes to form consensus and elect a leader… (sound familiar)…

It’s definitely easier to bootstrap a Habitat cluster than a Consul cluster. By leveraging Habitat we can bootstrap a consul cluster more easily… This is for sure not a “Habitat vs Consul” this is 100% a “Habitat + Consul”, I think they are the perfect compliment for each other.

Building Consul

You have multiple choices actually. That’s the whole point!

If you have three (or five!) VMs to run on, you can just install hab on each VM then run:

hab sup run core/consul --peer <node X-1> --peer <node X+1>

You probably don’t want to do this for production, but you get the idea, you can run the packages natively in Linux or in a container on any other platform.

On to the task at hand:

Enter Studio

If you’re not in a Linux environment, you’ll need to enter the habitat studio:

$ hab studio enter

Export `core/consul`

Run the hab pkg command to export core/consul to a docker container.

$ hab pkg export docker core/consul

We will specify the origin and package name in examples below.

Run your docker containers:

You either need to open three or five terminal windows, or replace the -e with -de in the examples below.

This also assumes you have no more than one (1) running container before starting this process. If you have more than one (1) running container, adjust your IPs accordingly.

Run once:

docker run -e HAB_CONSUL='{ "server": { "beta_ui": true, "bind": "0.0.0.0" }, "client":{"bind": "0.0.0.0"}}' -p 8500:8500 -p 8600:8600/udp core/consul --peer 172.17.0.3 --topology leader --peer 172.17.0.4

Run thrice (well, 2 or 4 times but actually not specifically not 3 times)

docker run -e HAB_CONSUL='{ "server": { "beta_ui": true, "bind": "0.0.0.0" }, "client":{"bind": "0.0.0.0"}}' core/consul --peer 172.17.0.3 --topology leader --peer 172.17.0.4

Now visit http://localhost:9500

you should see 5 nodes!

Habitwhat? Habitat!

2018-05-28T22:51:27+00:00

Habitat is an artifact builder. Habitat is a package/dependency manager. Habitat is a service manager. Habitat is a cluster coordinator.

Habitat is pretty slick!

I promise to expand this post… but I really want to talk about Habitat and Consul… so go check out Habitat for yourself!

To be continued…

ChefDK: Rakefile for common tasks

2018-02-07T19:08:21+00:00

Introduction

Good practice is to run rubocop, foodcritic, and ChefSpec (rspec) tests, and test kitchen before pushing your changes, as we’ve talked about before.

And it’s really not THAT much to type every time to go:

$ rubocop
$ rubocop -D
$ rubocop -a
$ foodcritic
$ foodcritic . # I always forget the dot...
$ rspec --color -f d
$ kitchen test

But wouldn’t it be nice to automate this, so we just have one command to type?

Actually, you can now do that with delivery locally. But that comes with some other considerations which deserves its own post.

So for now, enter, Ruby’s Make! aka rake

Rakefile

Rake really is a very powerful tool. I recommend reading over the documentation linked as well as this article. We’ll focus on just enough rake to automate our tests.

Basic Rakefile

task default: :reticulate_splines

desc 'Reticulate splines'
task :reticulate_splines do
  puts 'Reticulating Splines...'
  # doing something useful like reticulating splines...
end

Then we can run it. Also we can run rake with the -T flag to see all tasks available.

$ rake -T
rake reticulate_splines  # Reticulate splines
$ rake
Reticulating Splines...

This isn’t very useful, but is a good structure to show the basics of a Rakefile.

Rakefile explanation

task default: :reticulate_splines

The first line describes the default task. This is the task that will be run when rake is called without any arguments.

desc 'Reticulate splines'

The next line is the description of the task. The desc function call must precede a task block.

task :reticulate_splines do
  puts 'Reticulating Splines...'
  # doing something useful like reticulating splines...
end

Finally, the task block. The task is named as a symbol, then within the block a function is performed. In this case we’re only printing a message, but it’s just Ruby, so we can do any useful functions.

Chef Rakefile

What are the things we always do?

To that end, let’s get started!

Rake Rubocop

The first thing to do, include RuboCop! Since version 0.10 RuboCop comes with a rake task.

require 'rubocop/rake_task'

RuboCop::RakeTask.new do |rubocop|
  rubocop.options = ['--display-cop-names']
end

First we require the library with the rake task.

Then we initialize the task, by calling RuboCop::RakeTask.new.

Personally, I like to have the cop names displayed when I run rubocop, so we take the opportunity to add that option when we run rubocop. You can pass any flags here you would pass on the command line.

Then when we run rake -T we get:

$ rake -T
rake rubocop               # Run RuboCop
rake rubocop:auto_correct  # Auto-correct RuboCop offenses

Now we can have rake run rubocop for us!

Rake Foodcritic

Similar to RuboCop, FoodCritic has built in rake tasks.

require 'foodcritic'

FoodCritic::Rake::LintTask.new do |foodcritic|
  foodcritic.options[:fail_tags] = %w(any)
end

First we again require the library. Then we initialize the FoodCritic tasks. Additional options can be set as keys:value pairs to #options.

Now we should have:

$ rake -T
rake foodcritic            # Lint Chef cookbooks
rake rubocop               # Run RuboCop
rake rubocop:auto_correct  # Auto-correct RuboCop offenses

Rake RSpec

Finally, RSpec tests. This also has a rake task. So following the same pattern…

require 'rspec/core/rake_task'

RSpec::Core::RakeTask.new do |rspec|
  rspec.rspec_opts = "--color --format documentation"
end

And now we should have one more rake task:

$ rake -T
rake foodcritic            # Lint Chef cookbooks
rake rubocop               # Run RuboCop
rake rubocop:auto_correct  # Auto-correct RuboCop offenses
rake spec                  # Run RSpec code examples

Rake Test Kitchen

Finally Test Kitchen. And we follow the same pattern.

require 'kitchen/rake_tasks'
Kitchen::RakeTasks.new

We don’t really have any options to change, so we just call “new”. Now we have something along the lines of:

$ rake -T
rake foodcritic                   # Lint Chef cookbooks
rake kitchen:all                  # Run all test instances
rake kitchen:default-centos-7     # Run default-centos-7 test instance
rake kitchen:default-ubuntu-1604  # Run default-ubuntu-1604 test instance
rake rubocop                      # Run RuboCop
rake rubocop:auto_correct         # Auto-correct RuboCop offenses
rake spec                         # Run RSpec code examples

Pulling it all together

Remember I said I was lazy? Probably too lazy to say it. It’s great that we have one command to run everything, but I still have to remember and give rake a subcommand… if only there was a way that we could have one rake task call another…? Also note, we haven’t declared a default task yet.

task default: :all

desc 'Run all tests'
task all: [:test, :kitchen:all]

desc 'Run Rubocop and Foodcritic style checks'
task style: [:rubocop, :foodcritic]

desc 'Run all style checks and unit tests'
task test: [:style, :spec]

This gives us a few new commands that will call the various linters and test tools for us directly. You should have something like:

$ rake -T
rake all                          # Run all tests
rake foodcritic                   # Lint Chef cookbooks
rake kitchen:all                  # Run all test instances
rake kitchen:default-centos-7     # Run default-centos-7 test instance
rake kitchen:default-ubuntu-1604  # Run default-ubuntu-1604 test instance
rake rubocop                      # Run RuboCop
rake rubocop:auto_correct         # Auto-correct RuboCop offenses
rake spec                         # Run RSpec code examples
rake style                        # Run Rubocop and Foodcritic style checks
rake test                         # Run all style checks and unit tests

Final Form

Conclusion

Hopefully this will encourage you to run your tests before you push your code!

Chef: Getting Started

2018-02-01T19:13:57+00:00

Introduction

This does not intend to be a replacement for the tutorials on the Chef Website. In fact, I highly recommend reading and working through those tutorials as this blog intends to build on ideas and concepts presented there. In fact, most of this guide is based on the Chef Tutorial and Documentation on the same subject.

This page exists to document my workflows. So without further ado.

Chef Account Setup (Hosted Chef)

Head on over to the Sign Up Page to get signed up with a Hosted Chef. You can run Chef.io Hosted Chef for free up to 5 nodes. If you need more than that then you’re looking at paying for nodes, or hosting your own Chef Server.

Knife Setup

Head over to The Organizations page in your manage interface (Administration -> Organizations). Find your organization, and select “Generate Knife Config”. You should download a knife.rb file.

Then head over to Users (Administration -> Users) and find your user, then select “Reset Key”. You should download a ` .pem ` file.

Create a ` ~/.chef ` directory, and move your newly downloaded files into the ` ~/.chef ` directory.

$ mkdir ~/.chef
$ mv ~/Downloads/{knife.rb,qubitrenegade.pem} ~/.chef

Knife.rb file

Your knife.rb will look like

# See http://docs.chef.io/config_rb_knife.html for more information on knife configuration options

current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
node_name                "qubitrenegade"
client_key               "#{current_dir}/qubitrenegade.pem"
chef_server_url          "https://api.chef.io/organizations/qubitrenegade"
cookbook_path            ["#{current_dir}/../cookbooks"]

ChefDK Install

This guide assumes you’re not doing other Ruby development. If you use bundler and things get weird (Chef can’t find gems that are installed when you gem list), you can remove the ~/.chefdk/gems directory.

Download ChefDK

Head over to the [ChefDK Downloads page}(https://downloads.chef.io/chefdk) and select the appropriate package. For me, I selected the Red Hat 7 rpm.

$ wget -P /tmp https://packages.chef.io/files/stable/chefdk/2.4.17/el/7/chefdk-2.4.17-1.el7.x86_64.rpm
2018-02-04 17:34:40 (3.33 MB/s) - ‘/tmp/chefdk-2.4.17-1.el7.x86_64.rpm’ saved [106718859/106718859]

$ sha256sum /tmp/chefdk-2.4.17-1.el7.x86_64.rpm 
ab2d62b1eeb5248949f044f4c4bf489babe652fc649dc93cc2dac30607eb207e  /tmp/chefdk-2.4.17-1.el7.x86_64.rpm

$ sudo dnf install /tmp/chefdk-2.4.17-1.el7.x86_64.rpm
Running transaction
  Preparing        :                                                                                                                                                                                           1/1 
  Installing       : chefdk-2.4.17-1.el7.x86_64                                                                                                                                                                1/1 
  Running scriptlet: chefdk-2.4.17-1.el7.x86_64                                                                                                                                                                1/1 
Thank you for installing Chef Development Kit!
  Verifying        : chefdk-2.4.17-1.el7.x86_64                                                                                                                                                                1/1 

Installed:
  chefdk.x86_64 2.4.17-1.el7                                                                                                                                                                                       

Complete!

Configure ChefDK

Once our ChefDK package is installed, we need to set up our shell. (Windows users, head over to ChefDK on Windows)

echo 'eval "$(chef shell-init bash)"' >> ~/.bash_profile

Then we can either log in a new shell, or just source our file:

source ~/.bash_profile

If you’re using rbenv to manage Ruby, you’re own your own for now…

Verify

At this point you should have the ChefDK installed and should be able to communicate with your Hosted Chef account. We can verify by running a few commands:

$ chef -v
Chef Development Kit Version: 2.4.17
chef-client version: 13.6.4
delivery version: master (73ebb72a6c42b3d2ff5370c476be800fee7e5427)
berks version: 6.3.1
kitchen version: 1.19.2
inspec version: 1.45.13

$ knife client list
<your orgname>-validator
node1
node2
node3

(note: I already have nodes registered, you likely will not. So you’ll likely only see the validator key)

SSL Errors

If you’re working with self signed certs or are behind some corporate proxies, Ruby will have a bad time validating SSL certs. While the best answer is always “fix your SSL”, but that is, unfortunately, not always a possible solution. These can be worked around with the below solutions.

Chef SSL Errors

Download SSL Certs

The first thing we can try is to download the SSL certs from the server.

$ knife ssl fetch
WARNING: Certificates from api.chef.io will be fetched and placed in your trusted_cert
directory (/home/qubitrenegade/.chef/trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.

Adding certificate for wildcard_opscode_com in /home/qubitrenegade/.chef/trusted_certs/wildcard_opscode_com.crt
Adding certificate for DigiCert_SHA2_Secure_Server_CA in /home/qubitrenegade/.chef/trusted_certs/DigiCert_SHA2_Secure_Server_CA.crt

Disable SSL Checking

If you’re dealing with a proxy, the above may not work still. You can disable ssl checking with knife entirely, though this is not recommended, disabling SSL for Knife is documented below.

echo 'ssl_verify_mode :verify_none' >> ~/.chef/knife.rb

Again, this disables all SSL checking and is not recommended!!!

Berkshelf SSL Errors

Disable ssl checking for berkshelf:

mkdir ~/.berkshelf
echo '{"ssl":{"verify": false }}' > ~/.berkshelf/config.json

Docker

This should not be seen as condoning the use of docker in production! However, for the purposes of the next few posts, it will serve our needs. Again, this post mostly just follows the instructions found in the official documentation

# Remove old versions of Docker
sudo dnf -y remove docker docker-common docker-selinux docker-engine-selinux docker-engine

# install dnf plugins
sudo dnf -y install dnf-plugins-core

# add docker-ce repo
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo

# install docker-ce
sudo dnf -y install docker-ce 

# start docker
sudo systemctl start docker

# optionally enable docker to start at boot
sudo systemctl enable docker

# and validate we can run a container
sudo docker run hello-world

# if you get an error like the following, your daemon probably isn't started.
$ sudo docker run hello-world
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

# Add your user to the docker group.
# This doesn't seem to work on F27?  Further investigation to follow
# Maybe try logging out then logging back in.
$ sudo usermod -aG docker $USER

First cookbook

I like to do my work in my ~/chef-dev directory. So let’s create this first.

$ mkdir ~/chef-dev
$ cd ~/chef-dev

Then we’ll create our first cookbook, this can be found on github, but it’s not much more than a base chef generate cookbook <cookbook name>.

$ chef generate cookbook my_test
$ cd my_test

Running Test Kitchen

At this point, we should be in our new cookbook directory, and be able to run kitchen test, but I’m having trouble and didn’t want to reboot at the moment…

So more on this later,

Conclusion

At this point, we should have:

installed the ChefDK,
installed Docker,
Configured our knife.rb
created our first cookbook using the ChefDK generator
Run Test Kitchen

We’re now ready to rock! Tune in next time when we discuss the cookbook development process.

Qubit Renegade

Migrating to GitLab

Initial impressions (12 hours after initial post)

Configuring Matrix and Riot for private Chat

Configuring Matrix and Riot for Private Chat

Introduction

Prerequisites

Install Packages

Add Matrix.org Repo

Add CertBot Repo

Add PostgreSQL Repo

Package List

Synapse

PostgreSQL

Riot Web

TURN Server

All in one

Setup CertBot

CloudFlare Credentials

Run CertBot

Configure PostgreSQL

Create Database User

Create Database

Configure Coturn

Coturn Config

Enable Coturn

Start Coturn

Install Riot Web

Download latest Release

Link to Riot root dir

Configure Synapse

Server Name Config

Homeserver Config File

Optional Tuning

Start Synapse

Verify our Setup by registering a new user

Troubleshooting

Configure NGINX

Setup Sites

Default - example.com

Riot Web - chat.example.com

Synapse - matrix.example.com

Create “well known” files

/var/www/html/.well-known/matrix/client

/var/www/html/.well-known/matrix/server

Restart Nginx

Firewall Rules

UFW Setup

Digital Ocean Rules

Conclusion

Configuring GPU Passthrough with VFIO on Fedora 30 notes

Setup KVM

Update Kernel CLI parameters

Modprobe Config

Dracut Config

VGA Passthrough Script

Update our boot system

Post setup Check

“failed to setup container for group XX: failed to set iommu for container: Operation not permitted”

Nvidia GeForce Card reports Error 43 in Guest OS

Links

HabiChef: Pt2 Applying Change

Setup

Multiple Policyfiles

user.toml Config Changes

Running config changes

Conclusion

HabiChef: Packaging Chef for easy consumption

Policyfiles

Habitat

Example

Skeleton File Structure

Habitat Plan

plan.sh

defaut.toml

Policyfile

Building Our Package

Habitat Studio

Build our Package

Running our package in Habitat Studio

Default - `example.com`

Riot Web - `chat.example.com`

Synapse - `matrix.example.com`

`/var/www/html/.well-known/matrix/client`

`/var/www/html/.well-known/matrix/server`

`user.toml` Config Changes

`plan.sh`

`defaut.toml`

Export `qubitrenegade/consul-client`

Export `core/consul`