I recently picked up a new Framework laptop to replace my aging Chromebook, so I’m back on a “real” Linux laptop for the first time in nearly a decade.

That meant it was time to revisit a few old blog posts.

This time, though, I’m running Fedora, so all the work above gets replaced with a single checkbox in the installer!

But my new laptop has a TPM chip, so I can make this even more painless using systemd-cryptenroll. The Fedora installer prompts for a passphrase which I have to enter at every boot. But, if the system hasn’t changed significantly (e.g. from UEFI firmware or Linux kernel updates), then the TPM chip can handle unlocking things on my behalf.

I found a fedora-users mailing list post that gave me the most succinct version of things to get working. Key parts:

• Use systemd-cryptenroll --tpm2-device=auto -tpm2-pcrs=0+7 /dev/$DEVICE to enroll an additional token to unlock the LUKS volume. In my case, $DEVICE was /dev/nvme0n1p3, but your mileage may vary. This would be the block device backing your LUKS volume. lsblk should make it clear.
• Edit /etc/crypttab, and change the end of the one line (starting with luks-$UUID) to tpm2-device=auto,discard
• Until Fedora uses Dracut 056 (see #1976462), you need to create a file called /etc/dracut.conf.d/tss2.conf, with this in it:

  install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* "
  

  then run sudo dracut -f

• Reboot, and enjoy a fancy secure boot experience!

Of course, if your threat model includes state actors or the like, this may not be the right choice to make, but if you’re just wanting to make sure that your system is relatively secure if stolen, and that your boot disk is basically gibberish whenever you dispose of it some day, then I think this is a pretty good compromise.

I could have just paid Mojang the $7.99/month for Realms, but I decided to use this as a learning exercise.

So, I baked up an AWS CloudFormation template to spin up a minimal viable server.

You can find the full template on its GitHub Project.

In the designer, it looks like this:

There’s just a few moving parts here:

• An EC2 instance to run the server itself
• A Security group to act as a firewall to limit access to it
• An Elastic IP to keep a static IP for the server
• A Route 53 record set, to point to the server (so I have a simple name to give to my son’s friends’ parents)
• A custom record from the AWS Instance Scheduler, so that we can have the server stop automatically at bed time, and start up again the next day (saving cost as well as being a parental control of sorts)

So, this stack has to be deployed along with the Instance Scheduler, and it assumes that you called that stack “instance-scheduler” (should probably parameterize that). But, hopefully this is useful to someone else.

Some tasks to do in the future:

• Get the server to update to the latest minecraft server automatically
• Push some of the configuration into the template: right now, the template starts the EC2 instance but doesn’t auto-start the server. It’s expected that you’ll want to customize the server.properties before starting it the first time. Then, you can enable it with sudo systemctl enable minecraft-bedrock-server.service and start it with sudo systemctl start minecraft-bedrock-server.service

It has a lot of “enterprise” features that I don’t need for most of my personal stuff, but (IMHO) it does a better job of doing basic service monitoring, performance metric collection, etc than things like Nagios (or other hacks I’ve made in the past).

One thing I’ve done with it is start to collect my local weather data, so that I can graph it side-by-side with data pulled from my thermostat, etc.

Unfortunately, the Weather Underground API is no longer free (“as in beer”) no longer available, but hopefully this serves as an example of the sort of stuff you can do with OpenNMS.

OpenNMS is able to collect data from a number of sources, including SNMP, and basically anything you get fetch over HTTP.

To get data from Wunderground, we’ll use the XmlCollector. Despite its name, it can also work with JSON, though in this case, Wunderground gives us XML anyways.

We need to update collectd-configuration.xml with two new parts:

   <package name="wunderground-conditions" remote="false">
      <filter>IPADDR != '0.0.0.0'</filter>
      <include-range begin="1.1.1.1" end="254.254.254.254"/>
      <include-range begin="::1" end="ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff"/>
      <service name="Wunderground-Conditions" interval="300000" user-defined="true" status="on">
         <parameter key="collection" value="wunderground_conditions_home"/>
         <parameter key="handler-class" value="org.opennms.protocols.xml.collector.DefaultXmlCollectionHandler"/>
      </service>
   </package>
   <!-- ... -->
   <collector service="Wunderground-Conditions" class-name="org.opennms.protocols.xml.collector.XmlCollector"/>

This tells OpenNMS that, if we have a node configured with the “Wunderground-Conditions” service, it should trigger this datacollection.

Next, we need to add some specific configuration for the XmlCollector, in xml-datacollection-config.xml:

    <xml-collection name="wunderground_conditions_home">
        <rrd step="300">
            <rra>RRA:AVERAGE:0.5:1:2016</rra>
            <rra>RRA:AVERAGE:0.5:12:1488</rra>
            <rra>RRA:AVERAGE:0.5:288:366</rra>
            <rra>RRA:MAX:0.5:288:366</rra>
            <rra>RRA:MIN:0.5:288:366</rra>
        </rrd>
        <xml-source url="http://api.wunderground.com/api/YOURAPIKEY/conditions/q/SOMEWHERE/Outthere.xml">
            <import-groups>xml-datacollection/wunderground.xml</import-groups>
        </xml-source>
    </xml-collection>

Here, the “name” of the collection matches up with the paramter we defined in the Collectd config.

If you’re lucky enough to still have a Wunderground API key, you just need to put it in place of YOURAPIKEY above, and change the rest of the query to be something like /conditions/q/NY/New_York.xml.

That tells OpenNMS where to get the data from, but we still need one more file to tell it how to parse the data, and decide what to store. We put that in xml-datacollection/wunderground.xml (the import-groups entry above):

<xml-groups>
   <xml-group name="wunderground_conditions" resource-type="node" resource-xpath="/response/current_observation">
      <xml-object name="temp_c" type="GAUGE" xpath="temp_c"/>
      <xml-object name="temp_f" type="GAUGE" xpath="temp_f"/>
      <xml-object name="UV" type="GAUGE" xpath="UV"/>
      <xml-object name="dewpoint_c" type="GAUGE" xpath="dewpoint_c"/>
      <xml-object name="dewpoint_f" type="GAUGE" xpath="dewpoint_f"/>
      <xml-object name="feelslike_c" type="GAUGE" xpath="feelslike_c"/>
      <xml-object name="feelslike_f" type="GAUGE" xpath="feelslike_f"/>
      <xml-object name="heat_index_c" type="GAUGE" xpath="heat_index_c"/>
      <xml-object name="heat_index_f" type="GAUGE" xpath="heat_index_f"/>
      <xml-object name="precip_1hr_in" type="GAUGE" xpath="precip_1hr_in"/>
      <xml-object name="precip_1hr_metric" type="GAUGE" xpath="precip_1hr_metric"/>
      <xml-object name="precip_today_in" type="GAUGE" xpath="precip_today_in"/>
      <xml-object name="precip_today_metric" type="GAUGE" xpath="precip_today_metric"/>
      <xml-object name="pressure_in" type="GAUGE" xpath="pressure_in"/>
      <xml-object name="pressure_mb" type="GAUGE" xpath="pressure_mb"/>
      <xml-object name="visibility_km" type="GAUGE" xpath="visibility_km"/>
      <xml-object name="visibility_mi" type="GAUGE" xpath="visibility_mi"/>
      <xml-object name="wind_degrees" type="GAUGE" xpath="wind_degrees"/>
      <xml-object name="wind_gust_kph" type="GAUGE" xpath="wind_gust_kph"/>
      <xml-object name="wind_gust_mph" type="GAUGE" xpath="wind_gust_mph"/>
      <xml-object name="wind_kph" type="GAUGE" xpath="wind_kph"/>
      <xml-object name="wind_mph" type="GAUGE" xpath="wind_mph"/>
      <xml-object name="windchill_c" type="GAUGE" xpath="windchill_c"/>
      <xml-object name="windchill_f" type="GAUGE" xpath="windchill_f"/>

      <xml-object name="display_location" type="String" xpath="display_location/full"/>
   </xml-group>
</xml-groups>

That should “just work” for any Wundergroud location, and should tell OpenNMS to hold on to basically all of the numeric values I saw in the results. All of that get stored in your time series database of choice (JRobin, RRDtool, or Newts).

It also holds onto the “display_location” string (just the latest value), which you can use to help give a more meaningful label to your graphs.

Finally, we’ll want to build a pretty graph to show that our datacollection is working:

reports=wunderground.conditions.temp

report.wunderground.conditions.temp.name=Temperature
report.wunderground.conditions.temp.columns=temp_f,feelslike_f,dewpoint_f
report.wunderground.conditions.temp.type=nodeSnmp
report.wunderground.conditions.temp.command=--title="Temperature" \
  --vertical-label="Degrees F" \
  DEF:temp_f={rrd1}:temp_f:AVERAGE \
  DEF:feelslike_f={rrd2}:feelslike_f:AVERAGE \
  DEF:dewpoint_f={rrd3}:dewpoint_f:AVERAGE \
  LINE2:temp_f#00ff00:"Temperature " \
  GPRINT:temp_f:AVERAGE:"Avg \\: %10.2lf" \
  GPRINT:temp_f:MIN:"Min \\: %10.2lf" \
  GPRINT:temp_f:MAX:"Max \\: %10.2lf\\n" \
  LINE2:feelslike_f#ee42f4:"Feels Like  " \
  GPRINT:feelslike_f:AVERAGE:"Avg \\: %10.2lf" \
  GPRINT:feelslike_f:MIN:"Min \\: %10.2lf" \
  GPRINT:feelslike_f:MAX:"Max \\: %10.2lf\\n" \
  LINE2:dewpoint_f#42e8f4:"Dewpoint    " \
  GPRINT:dewpoint_f:AVERAGE:"Avg \\: %10.2lf" \
  GPRINT:dewpoint_f:MIN:"Min \\: %10.2lf" \
  GPRINT:dewpoint_f:MAX:"Max \\: %10.2lf\\n"

That gets you a pretty little graph, like this:

Updated 2019-03-06: note that the Wunderground API appears to be really and truly dead.

Here’s a quick update since the last time:

• I've changed jobs twice.
• I've had a bunch of kids.

I also switched everything (both blog and website) over to a Jekyll site about… 2 years ago.

I don’t have the time to contribute as much to open source as I used to, but here’s a little tidbit.

Deploying a Jekyll Blog to a Traditional Web Host, using GitLab CI

I’ve been using GitLab at work for a while now, and it’s grown on me. I’ve recently managed to get my entire website fully deployed by GitLab, both to a staging area with their Pages tool, and to my ‘ole reliable pair Networks hosting account.

I still have to audit my repo before I can make it fully public, but here’s the .gitlab-ci.yml I’m using:

# This file is a template, and might need editing before it works on your project.
# Full project: https://gitlab.com/pages/jekyll
image: ruby:2.3.1

before_script:
  - bundle install

test:
  stage: test
  script:
  - bundle exec jekyll build -d test
  artifacts:
    paths:
    - test
  except:
  - master

pages:
  stage: deploy
  environment: staging
  script:
  - bundle exec jekyll build -b /pioto-org -d public
  artifacts:
    paths:
    - public
  only:
  - master

production:
  stage: deploy
  environment: production
  when: manual
  variables:
    JEKYLL_ENV: production
  before_script:
  - bundle install
  - apt-get update && apt-get install -y rsync
  - umask 0077 && mkdir -p /root/.ssh
  - umask 0047 && echo "${PROD_KNOWN_HOSTS}" >> /root/.ssh/known_hosts
  - umask 0077 && echo "${PROD_DEPLOY_KEY}" > /root/.ssh/id_rsa
  script:
  - bundle exec jekyll build -d public
  - rsync -crvz --delete-after --delete-excluded public/ "${PROD_USERNAME}@${PROD_HOSTNAME}:"
  artifacts:
    paths:
    - public
  only:
  - master

Here’s basically how this works:

• There’s a basic “test” job, which just confims that everything can actually be built.
• There’s a “pages” job, which is how things get deployed to GitLab Pages. Every commit on the master branch goes there automatically.
• There’s a “production” job, which is where the magic happens to deploy my site live:
  • Before the build, we make sure we have rsync, and set up the ssh keys needed for the deploy. The contents of the key files are stored as secure variables.
  • We build with the correct baseurl setting.
  • We build with JEKYLL_ENV=production, so that things like Google Analytics get wired in.
  • We use rsync (with rrsync set up on the other end) to deploy the site.

• Unix::Uptime - Determine the current uptime, in seconds, and load averages, across different *NIX architectures.
• Remind::Client - class for working with remind’s daemon mode

I also have a few other scripts I’ve been messing around with, for doing some reporting and such:

• git-author-stats.pl - Gives a URL to draw a pretty pie chart of the top 10 committers to the current git repository. Examples:
  • Exherbo:
    • ::x11
    • ::vim
    • ::arbor’s multilib branch
  • Paludis
• git-daemon-report.pl - Given some log file, scrape it stats on who is pulling which of your git repos, and from where. Won’t work unless you run git-daemon with –verbose.

It’s available now from my git repo, and on CPAN

As always, “patches welcome”.

Things of interest might be:

• rbtpb – A replacement for tpb which is hopefully more robust.
• rubeak – A tool for handling multimedia keyboard keys, and some IR remotes.

Update: fixed links.

First off, you’re going to want to have your livecd handy, because it’s likely something won’t quite be right the first time around. Also, you’ll want to make sure your kernel is built with support for initramfs. This requires the BLK_DEV_INITRD configure option, named “Initial RAM filesystem and RAM disk (initramfs/initrd) support” in the “General setup” menu. You’ll then need to specify the location of a source file for the initramfs.

Probably the easiest thing to do is to grab my current initramfs package and tweak it to suit your needs. You’ll at the least need to change some paths in the config.txt and init files. But, it should serve as a good starting point. When you’re done, put the path to the config.txt file in the “Initramfs source file(s)” (CONFIG_INITRAMFS_SOURCE) setting in the kernel.

Now, rebuild and reinstall your kernel, reboot, and pray.

I hope this will help people improve their laptop’s security. Feel free to post any questions you have in the comments. Good luck!

The partitioning scheme I’m currently using is like this:

/dev/sda1 - /boot (ext2)
/dev/sda2 - LUKS encrypted lvm2 physical volume

The /boot partition is created like any normal ext2 partition.

The sda2 partition is created like so:

cryptsetup luksFormat /dev/sda2

This usually is sufficient to provide decent encryption, but it is worth checking the documentation for cryptsetup to look for further options — in particular, the option to use a keyfile.

Once we formatted this partition, we’ll need to open it, so that we can then add our lvm pv to it:

cryptsetup luksOpen /dev/sda2 sda2_crypt

We’ll now have a new device available as /dev/mapper/sda2_crypt. This can be treated just like any other block device — we could just format it as a regular ext3 partition, but then we can’t really ever resize it. So, we’re going to make a LVM2 partition:

pvcreate /dev/mapper/sda2_crypt

Now, we create a volume group. I choose ‘Exherbo’ as the name, but you can really just use whatever (often people just use ‘vg’).

vgcreate Exherbo /dev/mapper/sda2_crypt

Now, we just need to make our partitions:

lvcreate -L 1G -n swap Exherbo
lvcreate -n root Exherbo
vgscan
vgchange -a y

This creates a 1G swap partition, and uses the rest of the space for our root (/) partition. Again, see the documentation for lvm2 for more options.

Finally, we need to format those partitions:

mkswap /dev/mapper/Exherbo-swap
mke2fs -T ext3 /dev/mapper/Exherbo-root

Next time, I’ll go over how to boot this system.

The basic kernel configuration that I mentioned a long time ago still holds. Basically, you need to have the following options built into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES. Most of those will be turned on when you enable:

Device Drivers ->
  Multiple devices driver support (RAID and LVM) ->
    Device mapper support ->
      Crypt target support

However, the SHA256 support will not be. It can be found at:

Cryptographic API ->
  SHA224 and SHA256 digest algorithm

On the note of kernel configuation: for this process, you will need to do a fair amount of work from within another linux environment (most likely a LiveCD). For Gentoo, the most recent CD image I’ve found that has all the necessary configuration is the 2006.1 version… As I recall, some of the intermediate minimal CDs, at least, didn’t possess cryptsetup at all. And the most recent weekly build I tried, while it did have lvm and cryptsetup installed, didn’t have CONFIG_CRYPTO_SHA256 either built in, or as a module.

Probably the best bet is an Ubuntu 8.10 Alternative CD. You’ll have to either boot in recovery mode, or go through a bit of the installation procedure, as it doesn’t initially have cryptsetup available. But, once it’s detected the CD and loaded the modules from it, you can just switch to another virtual console and do things from there.

Next time, I’ll outline creating the disk partitions.