Ubuntu 16.04 on MacBook Pro 11,1 success story

Once every blue moon I try some sort of Linux as the native operating system on my laptop. As I tend to have a recent laptop, this usually ends as a short experiment where I find out one or two devices just will not work.

As my wife moved to my previous laptop when I bought my current laptop, we had her old laptop more or less as a spare / for the kids. After about half a year I noticed the laptop had rarely been touched by said kids and I figured it was too good a machine to waste. So it was either selling it off or re-purposing it.

Re-purposing as a small / lightweight spare for myself sounded great. At first I set it up using MacOS, but soon I found myself installing Windows 10 and Ubuntu 16.04 as multiboot to toy around with.

This is by far the Best Ubuntu experience I ever had on a macbook, or any other laptop. It worked so well in the first couple of days, that I wiped everything from the machine to install Ubuntu exclusively on it.

Sound, wifi, graphics, hot plugging monitors, VPN, all with zero or really minimal fuss. Nice, fast, reliably. Really, I am impressed.

And the machine is from late 2013 / early 2014. But the performance of this thing is still pretty amazing.

Apparently the camera does not work, but I did not check as I have a Bits of Freedom sticker covering it up. Also the media controls on my apple earbuds do not work in Ubuntu apparently blocked by some Apple patent.

Batterylife is supposed to be a lot worse compared to MacOS. But I haven’t been bothered by it yet.

Thank you Ubuntu devs 🙂 #donationtime

Tor relay node back in business

When a leased server has bandwidth to spare, I try to give it to the tor network. Project servers come and go, but I am happy to report that my relay node is back in business.

Aug 5 14:45:48 droid Tor[8966]: Bootstrapped 0%: Starting
Aug 5 14:45:48 droid Tor[8966]: Starting with guard context "default"
Aug 5 14:45:48 droid Tor[8966]: Bootstrapped 80%: Connecting to the Tor network
Aug 5 14:45:48 droid systemd[1]: Started Anonymizing overlay network for TCP.
Aug 5 14:45:48 droid Tor[8966]: Signaled readiness to systemd
Aug 5 14:45:49 droid Tor[8966]: Opening Socks listener on /var/run/tor/socks
Aug 5 14:45:49 droid Tor[8966]: Opening Control listener on /var/run/tor/control
Aug 5 14:45:49 droid Tor[8966]: Bootstrapped 85%: Finishing handshake with first hop
Aug 5 14:45:49 droid Tor[8966]: Bootstrapped 90%: Establishing a Tor circuit
Aug 5 14:45:49 droid Tor[8966]: Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 5 14:45:49 droid Tor[8966]: Bootstrapped 100%: Done
Aug 5 14:45:49 droid Tor[8966]: Now checking whether ORPort 94.130.31.206:443 and DirPort 94.130.31.206:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 5 14:45:49 droid Tor[8966]: Self-testing indicates your DirPort is reachable from the outside. Excellent.
Aug 5 14:45:50 droid Tor[8966]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Aug 5 14:45:51 droid Tor[8966]: Performing bandwidth self-test...done.

(And it is all the server does at this time, the project work is still on the todo list 😉

I thought fixing the tor relay today would be a good thing as I am wearing my tor shirt at #sha2017

Validating puppet code changes using octocatalog-diff

During Puppetconf 2016 Github announces it was releasing one of its internal test tools called octocatalog-diff as open source. What the tools basicly does is compile the catalog for a certain machine using your old and new puppetcode to show you the diff output. This allows you to see the impact of your code without actually deploying and running it on puppet clients.

As this could potentially save me a lot of time, I decided to delve into the tool to see what it could bring me. This post describes to the proces of setting the tool up and the surprises I came across.

Environment

For my initial testing I used a vagrant provisioned box running Ubuntu 16.04. Next to that I installed the puppet agent 3.8.7 that is in the standard Ubuntu repositories.

Preparation

The following gems were needed during my trails. Just run ‘sudo gem install [GEMNAME]’ to get them on your system. When using Puppet v4 take note to use the gem binary in /opt/puppetlabs/puppet/bin/gem

  • hiera-eyaml
  • r10k
  • bundler
  • rspec

The tool can query the puppetdb instance of your setup, or you can use the facts in yaml format for the node(s) you are testing. As the puppetdb did not work for my at this point, I copied the contents of /var/lib/puppet/yaml/facts from my puppetmaster to my local test environment.

The tool also needs some develop utilities upon install. Get them using your systems package manager :

  • cmake
  • pkg-config
  • ruby-dev

Installing the tool

After trying the gem, I’ve installed the source version following the instructions on https://github.com/github/octocatalog-diff/blob/master/doc/installation.md . The rake test gave me a a couple of errors that I reported.

Setting up

There were three files I added to my puppet repo :

  • A hiera.yaml configuration valid for my setup
  • A bootstrap script to run r10k on my Puppetfile and to symlink local modules to the common modules dir (see below)
  • A .octocatalog-diff.cfg.rb configured as per the instructions on github Please note the the current example file has a key settings[:hiera_yaml_file]  that should read settings[:hiera_config] . (Github issue)

Running the tool

/vagrant/octocatalog-diff/bin/octocatalog-diff -f production -t [your current branch] -n [NODENAME] --fact-file /vagrant/puppetdb_facts/[NODENAME].yaml --to-fact-override vagrant_puppetrole=nagiosserver --from-fact-override vagrant_puppetrole=nagiosserver --bootstrap-script repo-bootstrap.sh

Installation paths may vary. Note: the fact override thing is my way to assign a role to host without a real ENC / foreman. This value is used by a small piece of code in my site.pp :

node default {
  ## This is a small hook to support local vagrant
  ## development. This special var get set as part
  ## of the vagrant provisioning process.
  if $vagrant_puppetrole != undef {
    class { "roles::${vagrant_puppetrole}": }
  }
}

When removing a single package from my ‘baseline’ it resulted in the expected output:

screen-shot-2016-11-03-at-14-26-40

 

 

 

diff production/NODENAME fea-puppetv4/NODENAME
*******************************************
  Package[tcpdump] =>
   parameters =>
     ensure =>
      - present
      + absent
*******************************************

Contents of  repo-bootstrap.sh

r10k puppetfile install Puppetfile
for i in site/*; do BLA=`echo $i |sed -e 's#site/##'`; ln -s ../site/$BLA modules/$BLA; done

Final notes

When trying to use the tool, I started out using Puppet 4.8. I run into some trouble with puppetlabs firewall module 1.8.1 (( [Puppet Error] Could not autoload puppet/provider/firewall/iptables: undefined method `value’ for nil:NilClass) . As soon as I downgraded to puppet 3.8.7 the firewall module stopped producing errors. Not sure if this is related to the puppet version or the combination with octocatalog-diff.

I will use the tool the coming weeks. The next step could be integrating it in the build pipeline(s).