GTD tools

I’ve been using GTD to organize projects for a long time. The “tickler file” in particular is a crucial part of how I handle scheduling of upcoming and recurring tasks. I’ve blogged about some of the scripts I’ve written to help me do so in the past at and This week I’ve combined these tools, slightly updated them, and added an install script, and put them on github at


The opinions expressed in this blog are my own views and not those of Cisco.

Posted in Uncategorized | Leave a comment

Pockyt and edbrowse

I use r2e and pocket to follow tech related rss feeds. To read these I sometimes use the nook, sometimes use the pocket website, but often I use edbrowse and pockyt on a terminal. I tend to prefer this because I can see more entries more quickly, delete them en masse, use the terminal theme already set for the right time of day (dark and light for night/day), and just do less clicking.

My .ebrc has the following:

# pocket get
function+pg {
!pockyt get -n 40 -f '{id}: {link} - {excerpt}' -r newest -o ~/readitlater.txt > /dev/null 2>&1
e ~/readitlater.txt

# pocket delete
function+pd {
!awk -F: '{ print $1 }' ~/readitlater.txt > ~/pocket.txt
!pockyt mod -d -i ~/pocket.txt

It’s not terribly clever, but it works – both on linux and macos. To use these, I start up edbrowse, and type <pg. This will show me the latest 10 entries. Any which I want to keep around, I delete (5n). Any which I want to read, I open (4g) and move to a new workspace (M2).

When I'm done, any references which I want deleted are still in ~/readitlater.txt. Those which I won't to keep, are deleted from that file. (Yeah a bit backwards from normal 🙂 ) At that point I make sure to save (w), then run <pd to delete them from pocket.


The opinions expressed in this blog are my own views and not those of Cisco.

Posted in Uncategorized | 2 Comments

Genoci and Lpack


I’ve been working on a pair of tools for manipulating OCI images:

  • genoci, for GENerating OCI images, builds images according to a recipe in yaml format.
  • lpack, the layer unpacker, unpacks an OCI image’s layers onto either btrfs subvolumes or thinpool LVs.

See the for both for more detailed usage.

The two can be used together to speed up genoci’s builds by reducing the number of root filesystem unpacks and repacks. (See genoci’s for details)


While the project’s readme’s give examples, here is a somewhat silly one just to give an idea. Copy the following into recipe.yaml:

  base: empty
  base: cirros
  pre: mount -t proc proc %ROOT%/proc
  post: umount %ROOT%/proc
  run: ps -ef > /processlist
  run: |
    cat > /usr/bin/startup << EOF
    echo "Starting up"
    nc -l -4 9999
    chmod 755 /usr/bin/startup
  entrypoint: /usr/bin/startup

Then run “./genoci recipe.yaml”. You should end up with a directory “oci”, which you can interrogate with

$ umoci ls --layout oci

You can unpack one of the containers with:

$ umoci unpack --image oci:weird
$ ls -l weird/rootfs/usr/bin/startup
-rwxr-xr-x 1 root root 43 Nov 13 04:27 weird/rootfs/usr/bin/startup


I’m about to begin the work to replace both with a single tool, written in golang, and based on an API exported by umoci.


The opinions expressed in this blog are my own views and not those of Cisco.

Posted in Uncategorized | Tagged , | Leave a comment


It’s now possible to use CNI (container networking interface) with lxc. Here is an example. This requires some recent upstream patches, so for simplicity let’s use the lxc packages for zesty in ppa:serge-hallyn/atom. Setup a zesty host with that ppa, i.e.

sudo add-apt-repository ppa:serge-hallyn/atom
sudo add-apt-repository ppa:projectatomic/ppa
sudo apt update
sudo apt -y install lxc1 skopeo skopeo-containers jq

(To run the oci template below, you’ll also need to install git:// Alternatively, you can use any standard container, the oci template is not strictly needed, just a nice point to make)

Next setup CNI configuration, i.e.

cat >> EOF | sudo tee /etc/lxc/simplebridge.cni
  "cniVersion": "0.3.1",
  "name": "simplenet",
  "type": "bridge",
  "bridge": "cnibr0",
  "isDefaultGateway": true,
  "forceAddress": false,
  "ipMasq": true,
  "hairpinMode": true,
  "ipam": {
    "type": "host-local",
    "subnet": ""

The way lxc will use CNI is to call out to it using a start-host hook, that is, a program (hook) which is called in the host namespaces right before the container starts. We create the hook using:

cat >> EOF | sudo tee /usr/share/lxc/hooks/cni


CNI_COMMAND=ADD CNI_CONTAINERID=${LXC_NAME} CNI_NETNS=/proc/${LXC_PID}/ns/net CNI_IFNAME=eth0 CNI_PATH=${CNIPATH} ${CNIPATH}/bridge < /etc/lxc/simplebridge.cni

This tells the ‘bridge’ CNI program our container name and the network namespace in which the container is running, and sends it the contents of the configuration file which we wrote above.

Now create a container,

sudo lxc-create -t oci -n a1 -- -u docker://alpine

We need to edit the container configuration file, telling it to use our new hook,

sudo sed -i '/^' /var/lib/lxc/a1/config
cat >> EOF | sudo tee -a /var/lib/lxc/a1/config = empty
lxc.hook.start-host = /usr/share/lxc/hooks/cni

Now we’re ready! Just start the container with

lxc-execute -n a1

and you’ll get a shell in the alpine container with networking configured.


The opinions expressed in this blog are my own views and not those of Cisco.

Posted in Uncategorized | Tagged , | 2 Comments

Namespaced File Capabilities

Namespaced file capabilities

As of this past week, namespaced file capabilities are available in the upstream kernel. (Thanks to Eric Biederman for many review cycles and for the final pull request)


Some packages install binaries with file capabilities, and fail to install if you cannot set the file capabilities. Such packages could not be installed from inside a user namespace. With this feature, that problem is fixed.


What are they?

POSIX capabilities are pieces of root’s privilege which can be individually used.

File capabilites are POSIX capability sets attached to files. When files with associated capabilities are executed, the resulting task may end up with privilege even if the calling user was unprivileged.

What’s the problem

In single-user-namespace days, POSIX capabilities were completely orthogonal to userids. You can be a non-root user with CAP_SYS_ADMIN, for instance. This can happen by starting as root, setting PR_SET_KEEPCAPS through prctl(2), and dropping the capabilities you don’t want and changing your uid.  Or, it can happen by a non-root user executing a file with file capabilities.  In order to append such a capability to a file, you require the CAP_SETFCAP capability.

User namespaces had several requirements, including:

  1. an unprivileged user should be able to create a user namespace
  2. root in a user namespace should be privileged against its resources
  3. root in a user namespace should be unprivileged against any resources which it does not own.

So in a post-user-namespace age, unprivileged user can “have privilege” with respect to files they own. However if we allow them to write a file capability on one of their files, then they can execute that file as an unprivileged user on the host, thereby gaining that privilege. This violates the third user namespace requirement, and is therefore not allowed.

Unfortunately – and fortunately – some software wants to be installed with file capabilities. On the one hand that is great, but on the other hand, if the package installer isn’t able to handle the failure to set file capabilities, then package installs are broken. This was the case for some common packages – for instance httpd on centos.

With namespaced file capabilities, file capabilities continue to be orthogonal with respect to userids mapped into the namespace. However they capabilities are tagged as belonging to the host uid mapped to the container’s root id (0).  (If uid 0 is not mapped, then file capabilities cannot be assigned)  This prevents the namespace owner from gaining privilege in a namespace against which they should not be privileged.



The opinions expressed in this blog are my own views and not those of Cisco.

Posted in Uncategorized | 2 Comments

Containers micro-conference

The deadline for the CFP for the containers microconference at Plumber’s is coming up next week. See for more information

Posted in Uncategorized | Leave a comment

Outdoors laptop

i like to work outside, at a park, on the beach, etc. For years I’ve made do with regular laptops, but all those year’s I’ve really wanted an e-ink laptop to avoid the squinting and the headaches and the search for shade. The pixel-qi displays raised my hopes, but those were quickly dashed when they closed their doors. For a brief time there were two e-ink laptops for sale. They were quite underpowered and expensive, but more importantly they’re no longer around.

Maybe it’s time to build one. There are many ways one could go about it:

  • Get a toughbook with a transflective display
  • Get a rooted nook and run vncclient connected to a server on my laptop or in a vm
  • Get a dasung e-ink monitor connected to my laptop. Not cheap, and dubious linux support.
  • Actually it seems an external pixel-qi display may be available right now. Still pretty steep price.
  • Attach a keyboard to a nook and use that standalone
  • Get a used pixelqi, put it in some sort of case, and hook it up as a separate display
  • Get a small e-ink (2″) display, hook it up to a rpi or beaglebone black
  • Get a used pixelqi display and install it in something like a used lenovo s10-3
  • Get a freewrite and hack it to be an ssh terminal. Freewrite themselves don’t like that idea.
  • Get a used OLPG with pixelqi display.

So is there anyone in the community with similar goals? What are you using? How’s it working for you?

Posted in Uncategorized | 5 Comments