Tribaal's blog

Setting up a ZNC bouncer on OpenBSD 6.4

2020-05-27T00:00:00+00:00

The latest version of OpenBSD contains everything you might need to create a really powerful (SSL) ZNC bouncer in just a few simple steps, fully secured by you very own letsencrypt certificate.</p>

</p>

Create an OpenBSD machine</h2>
Nothing could be more simple using Exoscale's "exo" command line client.</p>

Firewall considerations</h3>

We'll want to make sure the following ports are let through to our OpenBSD instance:</p>

22/TCP: of course, we'll need to SSH into our machine, so port 22 needs to be allowed through.</li>
80/TCP: We'll use the default HTTP port in the process to obtain our Let's Encrypt certificate (to serve the challenge response).</li>

6697/TCP: The actual IRC port! You could pick something else here, as long as it's used consistently during the rest of this article.</li> </ul>

This configuration can be easily applied using Exoscale security groups:</p>

exo firewall create bouncer -d "The firewall rules for our bouncer"
</code></pre>
This created a new security group, but it lacks rules for now. Let's fix that:</p>
exo firewall add bouncer ssh
exo firewall add bouncer http
exo firewall add bouncer -P 6697 -p tcp -c "0.0.0.0/0" -d "IRC over SSL"
</code></pre>
We're good to go! On with the actual instance.</p>
Creating an OpenBSD cloud instance</h3>
Once again, the Exoscale CLI tool makes this easy for us:</p>
VM_NAME="my-bouncer"
exo vm create -t OpenBSD $VM_NAME -s bouncer
</code></pre>
Once deployed, connecting to the machine is as simple as:</p>
exo ssh $VM_NAME
</code></pre>
That should drop you right into an OpenBSD root shell. Nice!</p>
You might want to install vim (or your favorite editor) now:</p>
pkg_add vim
</code></pre>
You can otherwise rely on vi.</p>
Now is also a good time to setup a normal user. ZNC refuses to run as root
(rightfully so), and this is good practice anyway.</p>
Since our user will have to read the SSL private key (in order to let ZNC use it),
let's prepare the ground and add the user to the wheel group as well.</p>
adduser $USERNAME wheel
</code></pre>
Setting up the acme/SSL with letsencrypt</h2>
OpenBSD comes preinstalled with all the tools we'll need to setup a proper SSL
certificate for our instance.</p>
Setting up DNS</h3>
This is a little bit outside of the scope of this article - but since we'll ask
for a real Let's Encrypt certificate, now is the time for you to make sure your
machine has a proper DNS name.</p>
The DNS name will be henceforth refered to as $DOMAIN_NAME</code> in the rest of this
article.</p>
Using httpd to serve the Let's Encrypt challenge</h3>
The way Let's Encrypt works is to send the acme client a challenge, that the
requesting machine must then answer by placing a signed file in an HTTP
accessible folder.</p>
OpenBSD ships with a very capable web server in main, and it will be more than
suited to serve the simple challenge. acme-client</code> even comes with
documentation on how to set it up!</p>
First, let's enable httpd:</p>
echo "httpd_flags=" > /etc/rc.conf.local
</code></pre>
Before it can start, it will need a config file. Thankfully it's a very simple
one, and is almost a perfect copy of the example given in acme-client's man
page.</p>
cat > /etc/httpd.conf <<EOF
server "default" {
        listen on * port 80

        location "/.well-known/acme-challenge/*" { 
                root "/acme" 
                request strip 2 
        }
}
EOF
</code></pre>
Once the config is there, we can enable the service (so it survives reboots),
and start it:</p>
rcctl enable httpd
rcctl start httpd
</code></pre>
Setting up and using acme client on OpenBSD</h3>
Thankfully, OpenBSD includes an acme client in base, so there's nothing for us
to install!</p>
Let's configure it:</p>
# /etc/acme-client.conf
domain $DOMAIN_NAME {
        domain key "/etc/ssl/private/$DOMAIN_NAME.key"
        domain certificate "/etc/ssl/$DOMAIN_NAME.crt"
        domain full chain certificate "/etc/ssl/$DOMAIN_NAME.fullchain.pem"
        sign with letsencrypt
}
</code></pre>
Now that we told acme client how to get a certificate for us and that we are
ready to serve up the challenge it will send us, we should be all set to get a
Let's Encrypt certificate.</p>
To actually make the client request one for us, simply invoke, as root:</p>
acme-client -vAD $DOMAIN_NAME
</code></pre>
Adding the renewal to a cron</h3>
OpenBSd makes managing cron jobs very simple - daily crons can be added to the
/etc/daily.local</code> file (the file itself is the script).</p>
echo 'acme-client $DOMAIN_NAME' >> /etc/daily.local
</code></pre>
Ensure your user can see the key</h3>
We will run ZNC as a regular user (it even refuses to run as root), so we need
to ensure that the user we selected to run our ZNC session can see the acme
private key (the ZNC server needs to see the key to sign packets, of course).</p>
Since the user we created is already in the wheel group, we just need to change
the key's ownership:</p>
chown $USERNAME /etc/ssl/private/$DOMAIN_NAME.key
chmod g+rx /etc/ssl/private  # This allows wheel members to list the dir.
</code></pre>
Install znc</h2>
pkg_add znc
</code></pre>
Make sure the configuration file does not</em> have ipv6 enable as it apparently
makes assumptions that are not valid on OpenBSD.</p>
The last step is to simply run ZNC as your user! Or, of course, importing your
configuration to ~/.znc/</code></p>
Enjoy :)</h2>
As usual don't hesitate to let me know if you found this helpful!</p>



Magic URLs in the Ubuntu ecosystem
2017-12-13T00:00:00+00:00
Because of the distributed nature of Ubuntu development, it is sometimes a
little difficult for me to keep track of the "special" URLs for various
actions or reports that I'm regularly interested in.</p>
Therefore I started gathering them in my personal wiki (I use the excellent
"zim" desktop wiki</a>), and realized some of my colleagues
and friends would be interested in that list as well. I'll do my best to keep
this blog post up-to-date as I discover new ones.</p>
</p>
If you know of other candidates for this list, please don't hesitate to get in
touch</a>!</p>
Behold, tribaal's "secret URL" list!</p>
Pending SRUs</h3>
Once a package has been uploaded to a -proposed pocket, it needs to be verified
as per the SRU process</a>.
Packages pending
verification</a> end up
in this list.</p>
https://people.canonical.com/~ubuntu-archive/pending-sru.html</a></p>
Sponsorship queue</h3>
People who don't have upload rights for the package they fixed need to request
sponsorship. This queue is the place to check if you're waiting for someone to
pick it up and upload it.</p>
http://reqorts.qa.ubuntu.com/reports/sponsoring/</a></p>
Upload queue</h3>
A log of what got uploaded (and to which pocket) for a particular release, and
also a queue of packages that have been uploaded and are now waiting for review
before entering the archive.</p>
For the active development release this is for brand new packages, for frozen
releases these are SRU packages. Once approved at this step, the packages
enter -proposed.</p>
https://launchpad.net/ubuntu/xenial/+queue?queue_state=1</a></p>
The launchpad build farm</h3>
A list of all the builders Launchpad currently has, broken down by
architecture. You can look at jobs being built in real time, and the occupation
level of the whole build farm in here as well.</p>
https://launchpad.net/builders</a></p>
Proposed migration excuses</h3>
For the currently in-development Ubuntu release, packages are first uploaded to
-proposed, then a set of conditions need to be met before it can be promoted to
the released pockets. The list of packages that have failed this automatic
migration and the reason why they haven't can be found on this page.</p>
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html</a></p>
Merge-O-matic</h3>
Not really a "magic" URL, but this system gathers information and lists for the
automatic merging system, that merges debian packages to the development
release of Ubuntu.</p>
https://merges.ubuntu.com/</a></p>
Transitions tracker</h3>
This page tracks transitions, which are toolchain changes or other package
updates with "lots" of dependencies. This tracks the dependencies build status.</p>
https://people.canonical.com/~ubuntu-archive/transitions/html/</a></p>
Component mismatches</h3>
This file tracks which packages are depended upon by packages in main via the
"Recommends" stanza. Some more documentation is available in the Archive Admin
section of the ubuntu wiki</a>.</p>
http://people.canonical.com/~ubuntu-archive/component-mismatches.txt</a></p>
A similar file is generated with proposed enabled.</p>
http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt</a></p>
Kernel SRU workflow</h3>
A page tracking the state of various kernel SRUs</p>
http://kernel.ubuntu.com/sru/kernel-sru-workflow.html</a></p>


Serving a static blog from a Snap
2017-11-29T00:00:00+00:00
Out of curiosity, I decided to try and package this blog as a snap
package</a>, and it turns out to be an extremely easy and
convenient way to deploy a static blog!</p>
</p>
Why?</h1>
There are several advantages that the snappy packaging format bring to the
table as far as applications developers are concerned (which I am, my
application in this case being my blog).</p>
Snapcraft makes it very easy to package things, there's per-application jails
preventing/sandboxing your applications/services that basically comes for free,
and it also comes with a distribution mechanism that takes care of
auto-upgrading your snap on any platform.</p>
Sweet!</p>
How?</h1>
Since this blog is generated using the excellent "pelican" static blog
generator</a> from a bunch of markdown articles and
a theme, there's not a lot of things to package in the first place :)</p>
A webserver for the container age</h2>
A static blog obviously needs to be served by a webserver.</p>
Packaging a "full" traditional webserver like apache2 (what I used before) or
nginx is a little outside the scope of what I would have liked to do with my
spare time, so I looked around for another way to serve it.</p>
Requirements:</p>

A static files webserver.</li>
Able to set headers for cache control and HSTS.</li>
Ideally self-contained / statically linked (because snapping the whole would
be much faster/easier this way)</li>
SSL ready. I've had an A+ rating on SSLlabs for years and intend to keep it
that way.</li>
Easy to configure.</li>
</ul>
After toying with the idea to write my own in
rust</a>, I instead settled on an already existing
project that fits the bill perfectly and is amazingly easy to deploy and
configure - Caddy</a>.</p>
A little bit of snapcraft magic</h2>
Of course, a little bit of code was needed in the snapcraft recipe to make it
all happen.</p>
All of the code is available on a github
project</a>, and most of the logic can
be found in the snapcraft.yaml
file</a>.</p>
Simply copying the Caddyfile</em> and the snap/</em> subfolder to your existing
pelican project should be all you need to get going, then run the following to
get a snap package:</p>
# On an Ubuntu system.
snap install snapcraft
snapcraft
</code></pre>
With your site's FQDN added to the Caddyfile and pushed to production, you can
marvel at all the code and configuration you did not</em> have to write to get an
A+ rating</a> with
SSLlabs :)</p>
Questions? Comments?</h2>
As usual, feel free to reach out</a> with any question
or comment you may have!</p>


Running an Ubuntu mirror with Juju!
2017-08-31T00:00:00+00:00
Running a mirror for your favorite distribution is much easier than it sounds
when leveraging the right tools (and the work of others, including yours
truly).</p>
You might be interested to see what we (the Public Cloud team and Web
Operations team at Canonical) developed over the years to mirror the Ubuntu
archives for our cloud partners (taking a hybrid cache approach).</p>
It's been available as free software from the start but perhaps lacked a little
bit of visibility, not being a top-level project in
launchpad</a>.</p>
</p>
Traditional approaches to building local archive mirrors</h2>
There are generally two main strategies when it comes to archive mirroring: an
actual mirror of everything, or a cache of everything.</p>
1. Mirroring everything</h3>
The go-to solution for this particular strategy is either to roll your own sync
scripts, or use something like ubumirror</a> as
I've written about in a previous blog
post</a>, to rsync all of the
archive's contents to a local disk.</p>
This might be a good solution for places with very limited bandwidth (the
initial sync being done with a good old hard drive, for example), but has a few
drawbacks:</p>

It's very big. The whole Ubuntu archive (for amd64 and i386) sits at around
2.5Tb. That's a lot of disk space and bandwidth.</li>
A simple rsync script won't usually check the consistency of the metadata,
and since the metadata transfer can take some time, it's likely to introduce
inconsistencies. These typically manifest by "hashsum mismatches" errors on
the apt client side.</li>
</ul>
2. Caching everything</h3>
This strategy usually means running squid or another caching proxy specifically
configured to be aware of debian packages and metadata layout. One such
project is squid-deb-proxy</a>, that will
happily cache debian packages in a sensible way.</p>
More viable than the "full mirror" case, this currently still exhibits the same
metadata inconsistency problem as the full mirror option.</p>
3. Our strategy: a hybrid</h3>
In the charm's case, a hybrid approach was taken: the metadata (roughly, this
is everything except pool/</em>) is mirrored locally on a schedule, and only
served to clients once its internal consistency has been established. Thus the
package indices never produce "hashsum mismatch" errors.</p>
The pool/</em> part of the archive is then cached using squid3. This means that
with default settings disk space requirements are much lower than a full
mirror, and the hit rate much better than mirroring everything under the sun
(most packages having a very small chance of being used - even more so in a
cloud environment).</p>
As an added benefit, running the charm means you're running the exact same
software that our infrastructure team runs in the biggest public clouds in the
world - and benefit from the same vigilance and expertise that we apply to our
own systems. For free.</p>
Deploying your own caching mirror with juju</h2>
For this deployment we'll first need to configure Juju. If it's not your first
time playing with Juju you can skip right ahead to the juicy bits :)</p>
This is intended to kick-start a deployment on a local LXD (as an example), but
of course will work on any other cloud supported by juju. For a more detailed
introduction to juju please refer to the juju
documentation</a>.</p>
To make sure we're up-to-date, let's install juju from the snap package:</p>
sudo snap install --classic juju
</code></pre>
Juju comes with a "localhost" cloud leveraging LXD, since that is free
(both as in speech and</em> as in beer), we'll use this as a reference cloud, but
the instructions should work for any other supported cloud provider (see juju list-clouds</code>).</p>
# This gives you a local LXD backed juju environment
juju bootstrap localhost
</code></pre>
Creating a charm configuration file</h3>
Let's ask our test deployment to only care about xenial, in order to speed up
initial sync with the upstream archives and save disk space:</p>
cat > cache.yaml << EOF
ubuntu-repository-cache
  mirror-series: xenial
EOF
</code></pre>
Each series will download around 2.4Gb of metadata on creation, and then
download it again every hour. It keeps at most two copies of the metadata on disk and therefore
about 5Gb per series should be planned.</p>
Actually deploying the charms</h3>
As usual in Juju land, the actual deployment couldn't be easier!</p>
juju deploy --config=cache.yaml ubuntu-repository-cache
juju deploy haproxy
juju add-relation ubuntu-repository-cache haproxy
juju expose haproxy
</code></pre>
If you're using a local deployment, you can see that juju spawned 3 LXD
containers: one juju controller, an HAproxy machine and the archive charm
itself.</p>
Scaling our deployment</h3>
You can then scale the archive cluster up by simply running</p>
juju add-unit ubuntu-repository-charm
</code></pre>
Using our fresh new archive</h2>
Simply pointing apt at the newly exposed HAproxy (public) IP address should
just work!</p>
Here's an example snippet to add to your sources.list configuration file:</p>
deb http://<HAproxy's IP address>/ubuntu/ xenial main universe
</code></pre>
Our deployments in the clouds</h2>
This is the charm that serves the Ubuntu archives for most of the cloud
instances you boot on the major cloud providers. We have one deployment per
cloud region, and make sure cloud-init</a> sets the
default ubuntu archive's address to them when relevant.</p>
For a production deployment we use at least 2 ubuntu-repository-cache instances
(juju deploy -n 2 ubuntu-repository-cache</strong>) behind 2 HAproxy instances
(juju deploy -n 2 haproxy</strong>) that are balanced with DNS round-robin.</p>
</p>
Disk and memory sizing for the ubuntu-repository-cache units</h3>
The squid cache space is computed based on available memory and disk space.</p>
On a machine with 12Gb of RAM and 300Gb of root disk, the following usage is
observed: ~200Gb</strong> of disk space dedicated to package caching, plus about
22Gb</strong> of disk for the default series metadata (the default behavior, in
other words, what you get without passing a configuration file when deploying).</p>
You can replicate this setup easily with the following deployment command:</p>
juju deploy --constraints "mem=12G, root-disk=300G" ubuntu-repository-cache
</code></pre>
This unfortunately doesn't work with the local LXD provider right now, but
should work with most other cloud options offered by juju.</p>
A note on disk size for the local provider</h3>
At the time of writing, the local substrate does not honour disk size
constraints unfortunately, so all LXD containers are created with
a root disk of 10Gb regardless of what is specified</a>.
This only applies to the LXD substrate however, and I'm sure the problem will
be fixed in a future version.</p>
More information</h2>
More information about the myriad of deployment options for monitoring and
general configuration can be found in the charm's store
page</a> or by browsing the
code</a></p>
Comments? Questions?</h2>
Don't hesitate to leave a comment on
Reddit</a>!</p>


Fixing a lost right-click after switching to 17.10's Gnome 3 and Wayland
2017-08-25T00:00:00+00:00
As you are probably aware, Ubuntu decided to drop my beloved Unity desktop
environment to switch to Gnome 3 and
Wayland</a>.</p>
The transition went much smoother than I expected, and the Gnome 3 experience
delivered by the desktop team is amazing!</p>
</p>
The lost right-click</h1>
One small bump I hit when making the switch was that I lost the ability to
right-click with my System76</a> Galago Ultrapro.</p>
After looking around for a while, it turns out that the fix is very simple, but
a little hard to find: 17.10 is not released yet so any "lost my
right-click" post are for previous releases :)</p>
Here's what I had to do to get my right-click back.</p>
Install gnome-tweak-tool</h2>
You can find the tool by searching for "gnome tweak" in the system search -
this will find the appropriate entry in the app store and allow you to download
it graphically, but otherwise you can simply use apt, as usual:</p>
sudo apt install gnome-tweak-tool
</code></pre>
Changing the touchpad settings</h2>
Change your touchpad's "click method" in gnome-tweak-tools to "Areas"</p>
</p>
Notice that you can set the touchpad to "disabled while typing" here as well,
it wasn't set for me, although I can't remember if that's because I messed
around with settings before or if that's default.</p>
Et voilà!</p>


Upgrading your Ubuntu-on-Windows install to the app version
2017-07-11T00:00:00+00:00
Our team and
Microsoft</a>
released Ubuntu as a Windows app store application today!</p>
</p>
If you, like me, toyed with the "bash on Ubuntu on Windows" version before and
would like to try the latest and greatest, read on!</p>
Saving your data</h2>
If you "bash on ubuntu on windows" environment has some data you'd like to
keep, make sure you back it up now. The uninstall process will nuke everything.</p>
Uninstall the old way</h2>
This is relatively simple. Opening a command line (cmd.exe) terminal and typing</p>
lxrun /uninstall
</code></pre>
will destroy your previous environment.</p>
Installing the new way</h2>
To find the app in the Microsoft
store</a>, just type
"Ubuntu" in the search bar.</p>
Click install. Voilà!</p>


Building a very simple debian package
2017-06-07T00:00:00+00:00
I sometimes read "building packages X is much easier than building .debs".</p>
While it is probably true that building a debian package is a little more
involved than other systems, the debian packaging system adds a lot of value
for end users, and properly packaged applications is what makes the Debian and
Ubuntu ecosystems extremely powerful.</p>
</p>
This blog post will guide you through making a very simple debian package from
scratch, that simply "copies" files (a wallpaper, for example) where you
specify them on the target file system. That is of course not how most packages
in the Debian & Ubuntu archives are created since it skips a lot of the
necessary subtleties, but it is hopefully a good first step to build further
articles upon.</p>
TL; DR</h1>
# Prerequisites
apt install devscripts
name=foo
ppa_address='ppa:myuser/myppa'
version=0.1
# Packaging
mkdir $package-$version
cd $package-$version
dh_make --indep --createorig
mkdir essentials
mv debian/{changelog,compat,rules,control} essentials
rm -r debian
mv essentials debian
# edit debian/control
mkdir tree
echo './tree/* ./' > debian/$name.install
# Add files to tree/ as if /tree was / on target system
dch
debuild -S
dput $ppa_address ../*.changes
</code></pre>
Anatomy of a package tree</h1>
In a nutshell, a debian package tree is:</p>

an untarred source bundle of the upstream program's source code.</li>
a debian/ subdirectory that the packager/maintainer adds to it. This
subdirectory contains all the information needed to build the surrounding
program.</li>
</ul>
Generating a package skeleton with dh_make</h1>
dh_make is a handy program that will generate a debian/</em> subdirectory for you,
a bit like paster</em> would do for ruby on rails projects. It asks for questions
interactively, but for such a simple project, we don't need most of its
features.  As usual in Ubuntu land, it all starts with:</p>
# That pulls way more than you need, poke around!
sudo apt install devscripts
</code></pre>
Start by picking a package name, and a version you want you package to be. I'll
go with the class "foo" and "0.1", but feel free to chose something more
relevant:</p>
mkdir foo-0.1
cd foo-0.1
# Here we pick "indep" to specify that the package is architecture independant.
dh_make --indep --createorig
</code></pre>
This will have created a debian/ subdirectory in you foo-0.1 directory. You can
have a peek inside, but again, we won't need most of it for our simple example.
Let's narrow it down to the essentials:</p>
mkdir essentials
mv debian/{changelog,compat,rules,control} essentials
rm -r debian
mv essentials debian
</code></pre>
Our little gymnastic here recreated the debian/ subdirectory, this time with
only the most important files present.</p>
You folder should now look like:</p>
foo-0.1/
└── debian
    ├── changelog
    ├── compat
    ├── control
    └── rules
</code></pre>
Filing the generated control file</h1>
The control file is the file that lists all the package's metadata, and,
roughly everything that will show up for your users when they use apt-cache to
query information about it.</p>
While the generated control file is almost useable as-is, we'll need to quickly
edit a couple of fields for our new package:</p>
Choosing a Section</h2>
Sections are used to group packages related to a particular topic. You should
pick one from the list</a> .</p>
For a wallpaper package the "universe/graphics" section is probably
appropriate.</p>
This is optional however, so you as well just remove the "Section:" line for
our dead simple package.</p>
Editing the homepage</h2>
Either add a link to a relevant website, or remove the line altogether.</p>
Adding a source control link</h2>
If you are planning to maintain this package with a version control system
(which is a pretty good idea in general), you should add the URL to it in the
control file, as modern dh_make</em> will have pre-filled for you.</p>
Users of your package will get a warning message when getting the package's
source (using "apt-get source" for example) telling them where the package is
maintained, and will therefore help potential contributors know how and where
to submit packaging fixes.</p>
Adding description fields</h2>
The most important part of this exercise: add a short and long description of
what your package does.</p>
Adding the actual files</h1>
It's time to add the files we want to ship. For this, let's prepare the ground
and add a "tree" directory in our foo-0.1 folder. That folder will be
"translated" into our target system's root by the install rules we'll create
just now:</p>
mkdir tree
echo './tree/* ./' > debian/foo.install
</code></pre>
Make sure to replace "foo.install" by "<your_package_name>.install"!</p>
You can now add your files in the "tree" subdirectory, as if it was the target
system's root.</p>
For example, adding a wallpaper to a desktop install:</p>
mkdir -p tree/usr/share/backgrounds/
cp my_penguin_picture.png tree/usr/share/backgrounds/.
</code></pre>
On the installed system, the penguin picture file will be installed in
/usr/share/backgrounds</p>
Your tree should now look like something like this:</p>
foo-0.1/
├── debian
│   ├── changelog
│   ├── compat
│   ├── control
│   ├── rules
│   └── foo.install
└── tree
    └── usr
        └── share
            └── backgrounds
                └── my_penguin_picture.png
</code></pre>
Create a changelog entry</h1>
Time to add a changelog entry to your package.</p>
The Debian changelog is the file that tracks what changes in your package, in a
machine-readable way, and is also the file that determines what the version
number for  particular build will be.</p>
The "dch" program will help you greatly in this task by doing most of the grunt
work for you. If your package were a "real" package to be distributed with
Ubuntu proper, you'd need to pay special attention to the version number, but
for now, we'll just go for the easy scheme and number things like "0.1" then
"0.2" and so on.</p>
Doing things this way is called creating a "native package".</p>
Here's what my example changelog looks like after editing it:</p>
foo (0.1) zesty; urgency=low

* Initial release. Add whatever is relevant here.

-- Christopher Glass <email.redacted@ubuntu.com>  Thu, 23 Jul 2015 18:26:05 +0300
</code></pre>
Make sure your name matches your GPG key's identity exactly here, that will
make signing the packages more simple.</p>
Important</strong>: Make sure you replace the default "unstable" by whatever
Ubuntu version you target! It's a classic source of failing builds (at least
for me).</p>
Building and uploading the package</h1>
Making a test binary deb</h2>
Before we think about publishing our work, let's build a test .deb file. Simply
running the following command in your top-level directory should take care of
the deb file creation:</p>
debuild
</code></pre>
debuild</em> will ask you for your GPG key's passphrase, since packages are always
signed.</p>
It will leave a fresh new debian package one directory up</strong> from your foo</em>
folder. You can copy this to a test system (I suggest a LXD
container</a>), and install it
there, for example with gdebi</em> or dpkg</em>.</p>
Making and uploading a source deb to a PPA</h2>
Once you are happy with you test deb, it's time to think about publishing your
work (if you want to)!</p>
The easiest way to do this in the Ubuntu world is to create and use a free PPA
(Personal Packages Archive</em>) on Launchpad. In your user
account</a> simply create a new PPA, and note down the
name you give it.</p>
</p>
From there, you simply need to invoke the following command from your top level
foo directory to build a source package</em>, suitable for upload to Launchpad:</p>
# The -S stands for "source" here. Build a source package.
debuild -S
</code></pre>
That will build the source package for you to upload to a PPA, and as for the
binary package, all the needed files will be stored one directory up</em> from
your top-level directory.</p>
PPAs do not accept binary packages, and will build the binary packages from
that source package for you. While it is trivial for this example, it is a very
nice feature for compiled programs since the Launchpad build farm will build
your packages for many different architectures for you automatically!</p>
As for the upload itself: simply move to one level above your work directory
(where the build artifacts are put), and invoke the following command:</p>
dput ppa:user-name/ppa-name name_of_your_package_0.1_source.changes
</code></pre>
You will receive an email at your main launchpad email address telling you that
your package was received, and that it (hopefully) build successfully!</p>
You can then install your package by adding the PPA to your machine and
installing it using apt, as you'd expect.</p>
sudo add-apt-repository --update ppa:user-name/ppa-name
sudo apt install name_of_your_package
</code></pre>
Next up</h1>
Next in this series of posts, I'll guide you through making a simple python
package, that should hopefully be more "shippable", and how to do equivalent
things using snaps</a>!</p>
Comments</h1>
You can comment on this article on
Reddit</a>.</p>


Switching themes, and Disqus
2017-06-02T00:00:00+00:00
Theme change</h1>
As you can see, I switched themes!</p>
It's based on fle</a>'s very nice pelican theme,
"pelican-sober</a>". I finally
admitted to myself that maintaining a pelican theme was not a good use of my
time, nor did my blog look exceptionally nice.</p>
I think this is a major improvement.</p>
Comments?</h1>
This update  was also supposed to introduce disqus
comments</a> to this blog, a long overdue feature. I reverted
the changes because I was a little bit out of touch with recent developments -
and it turns out disqus has a pretty bad reputation for tracking users and
other "nice" things.</p>


A nicer way to mount your /home in LXD
2017-01-11T00:00:00+00:00
Some time ago I blogged about mounting your /home</a> directory inside a LXD container,
and that required some slightly dirty tricks and privileged containers for it
to work.</p>
Hopefully my colleagues working on LXD now made it much easier</a> and cleaner to
do so, even without requiring privileged containers.</p>
</p>
Let's go through things step by step, and try to provide information about how
things work along the way.</p>
Mounting /home read-only</h1>
The basic idea is to use LXD's devices handling to mount your host's /home
directory to the guest's /home:</p>
lxc init ubuntu-daily:z unmapped
lxc config device add unmapped homedir disk source=$HOME path=/home/ubuntu
lxc start unmapped
</code></pre>
If you need it to be read-only, then that is the only step you need to take,
since the guest's Ubuntu user (UID 1000 inside the guest) will see your /home
files just fine, although they will be owned by a UID and GID of "65534" -
nobody. The guest's ubuntu can therefore not write to that directory, but can
see files according to normal "other" permissions.</p>
Mounting /home read-write</h1>
Allowing LXD to remap your user ID</h2>
The first step for that is to allow LXD to remap your user ID.
Remember, LXD uses linux namespaces to isolate processes, and by default even
root is not allowed to reuse UIDs from the host inside containers.</p>
We want to allow the LXD demon (running as root) to remap our host's user ID
inside a container:</p>
# Note: $UID is likely to be 1000 on an Ubuntu system if you're the only user.
echo "root:$UID:1" | sudo tee -a /etc/subuid /etc/subgid
</code></pre>
This is a one time step, you'll never need to do this again on your host.</p>
Remapping your user ID inside the container</h2>
Once LXD is allowed to remap your UID, we need to actually tell it to do it
on a per-container basis:</p>
lxd init ubuntu-daily:z remapped
lxc config set remapped raw.idmap "both $UID 1000"
</code></pre>
There is a little bit of magic-looking syntax there, but "both $UID 1000"
simply means "map both the UID and the GID, from the host's $UID to the guest's
1000".</p>
We could instead set "uid $UID 1000" and "gid $(id -g) 1000" to be more explicit,
but the "both" syntax is convenient.</p>
Mounting /home</h2>
As before, we can now mount /home inside our container, and we should hopefully
be able to access it read-write from inside the container:</p>
lxc config device add remapped homedir disk source=$HOME path=/home/ubuntu
</code></pre>
Let's try it now:</p>
lxc start remapped
# Get a root shell
lxc exec remapped /bin/bash
# Switch to our ubuntu user inside the container
su ubuntu
# create a file in /home/ubuntu inside the container
echo 'Opeth rocks' >> $HOME/message
</code></pre>
Let's look at our message form outside the container now:</p>
cat $HOME/message
</code></pre>
Putting it all together</h1>
Here's a more script-like summary:</p>
container_name=remapped
lxc init ubuntu-daily:z $container_name
lxc config set $container_name raw.idmap "both $UID 1000"
lxc config device add $container_name homedir disk source=$HOME path=/home/ubuntu
lxc start $container_name
</code></pre>
Easy!</p>


Making LXD fly on Ubuntu!
2016-10-27T00:00:00+00:00
deployment times.</p>
Since my last article</a>,
lots of things happened in the container world! Instead of using LXC, I find
myself using the next great thing much much more now, namely LXC's big
brother, LXD</a>.</p>
As some people asked me, here's my trick to make containers use my host as an
apt proxy, significantly speeding up deployment times for both manual and
juju-based workloads.</p>
</p>
Setting up a cache on the host</h1>
First off, we'll want to setup an apt cache on the host. As is usually the
case in the Ubuntu world, it all starts with an apt-get```</p>
sudo apt-get install squid-deb-proxy</p>
This will setup a [squid caching proxy](http://www.squid-cache.org/) on your
host, with a specific apt configuration listening on port 8000.

Since it is tuned for larger machines by default, I find myself wanting to make
it use a slightly smaller disk cache, using 2Gb instead of the default 40Gb is
way more reasonable on my laptop.

Simply editing the config file takes care of that```

$EDITOR /etc/squid-deb-proxy/squid-deb-proxy.conf
# Look for the "cache_dir aufs" line and replace with:
cache_dir aufs /var/cache/squid-deb-proxy 2000 16 256 # 2 gb

</code></pre>
Of course you'll need to restart the service after that```</p>
sudo service squid-deb-proxy restart</p>
# Setting up LXD

Compared to the similar procedure on LXC, setting up LXD is a breeze! LXD comes
with configuration templates, and so we can conveniently either create a new
template if we want to use the proxy selectively, or simply add the configuration
to the "default" template, and all our containers will use the proxy, always!

## In the default template

Since I never turn the proxy off on my laptop I saw no reason to apply the
proxy selectively, and simply added it to the default profile```

export LXD_ADDRESS=$(ifconfig lxdbr0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}')
echo -e "#cloud-config\napt:\n proxy: http://$LXD_ADDRESS:8000" | lxc profile set default user.user-data -

</code></pre>
Of course the first part of the first command line automates the discovery of
your IP address, conveniently, as long as your LXD bridge is called "lxdbr0".</p>
Once set in the default template, all LXD containers you start now have an apt
proxy pointing to your host set up!</p>
In a new template</h2>
Should you not want to alter the default template, you can easily create a new
one```</p>
export PROFILE_NAME=proxy
lxc profile create $PROFILE_NAME</p>
Then substitute the newly created profile in the previous command line. It
becomes```

export LXD_ADDRESS=$(ifconfig lxdbr0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}')
echo -e "#cloud-config\napt:\n proxy: http://$LXD_ADDRESS:8000" | lxc profile set $PROFILE_NAME user.user-data -

</code></pre>
Launching a new container needs to add this configuration template, so that the
container benefits form the proxy configuration```</p>
lxc launch ubuntu:xenial -p $PROFILE_NAME -p default</p>
## Reverting

If for some reason you don't want to use your host as a proxy anymore, it is
quite easy to revert the changes to the template```

lxc profile set <template> user.user-data

</code></pre>
That's it!</h1>
As you can see it is trivial to set an apt proxy on LXD, and using squid-deb-proxy
on the host makes that configuration trivial.</p>
Hope this helps!</p>
Discussion and/or comments welcome on Reddit!</a></p>


Brewing my first batch of mead
2016-03-20T00:00:00+00:00
Our last team sprint took place in London, and there I (re) discovered mead, in
a light carbonated form. It's bottled by Gosnells Mead</a>
and is absolutely delicious. This sparked my interest, and I
decided to get started brewing mead myself, since it's almost impossible to
find in Switzerland.</p>
Good news: mead is apparently super easy to brew - it's been done for millenia
using the most primitive tools and equipment, so surely, I can brew my own as
well!</p>
</p>
Choosing a recipe</h1>
Since it's my first batch ever of anything at all and I have no idea what
I'm doing, I decided to go for a foolproof spiced mead recipe</a> that uses very
easy to find ingredients, including trivially found baker's yeast instead of
harder to acquire brewer's yeast. Real mead brewers will probably think it's
wrong (or worse), but hey, I'll learn how to drive before I start worrying about
tuning my engine :)</p>
The carboy</em> (yay, new vocabulary!) I bought is 15 liters, so about 4 gallons. I
therefore scaled my recipe as follows:</p>

6.5 Kg of honey (I picked "forest honey" because it's more liquid and tastes great)</li>
3 full oranges</li>
4 cloves</li>
1 stick of cinnamon</li>
Originally, 2 "handfuls" of raisins, increased to 4 later on.</li>
</ul>
Gathering the equipment</h1>
Yet another advantage to living in the countryside: my local farming equipment
store offers everything you might need to brew your own stuff. I suspect my
neighbours (actual farmers) to all brew their own apples, prunes or grapes and
then illegally distill them for giggles. I'm not going that far, but the equipment
was easy to get anyway.</p>
I bought the smallest carboys</em> I could find (two of them), sealed food-grade plastic
containers of 15 liters.
The same store had the same brand of containers up to "big enough for me to walk in".
I didn't exactly have space for that in my car, so I went with the safe and
reasonable first batch size of "as small as I can" :)</p>
I plan to brew a single carboy</em>, but they were cheap so I bought a second just
in case.</p>
Other items needed are airlocks. There are deceptively simple mechanisms, basically
liquid-filled plumbing trap</a>
that lets fermentation CO² out when the vessel's pressure is high enough.</p>
I also needed some powerful sanitizer that doesn't leave a taste. I went the
nuclear route and bought bleach, that I used in obviously very diluted form.</p>
Gathering the ingredients</h1>
Obviously, getting large quantities of honey is not cheap, but I can certainly
get that relatively easily form neighbouring farms. However, raw honey can have
its own yeast and impurities, so since it's my very first batch, I went with
homogenized, store-bought honey.</p>
I bought 8 kg of honey from my local supermarket. All of whatever they had most
and looked tasty and liquid.</p>
I'm pretty sure I'm on some sort of watch list now.</p>
I'll use only 6,5 kgs, but I originally miscalculated the quantity (I thought
the carboys were 19l instead of 15, and didn't double check before leaving for
the store).</p>
The rest of the ingredients were easy enough to buy - oranges, cinnamon, raisins,
and cloves.</p>
</p>
I did spend a long time considering whether to buy specialist yeast (brewer's yeast,
ideally champagne yeast or mead-specific yeast), but all the Swiss online stores
were sold out, and Amazon won't ship yeast to me (probably because of tricky customs).</p>
The only place that would ship them to me gave me a delivery estimate of several
weeks.</p>
I decided to go with my locally made baker's yeast, as the recipe I chose said it'd
be OK.</p>
Putting it all together</h1>
Shopping is over, time for preparation.</p>
Sterilization</h2>
As every brewing website on the planet will tell you, it's super super important.</p>
I went with a good old fashioned vinegar-bleach mix, since again, "professional"
sterilizer was hard to order/get (although looks awesome and certainly is much
safer). Unscented bleach, of course.</p>
Warning</strong>: mixing bleach and vinegar is a very VERY bad idea. Never do this
directly (it creates very toxic fumes - as in chemical weapon level of toxic).</p>
I filled my carboy</em> with tap water (15 liters), and put everything I needed to
sterilize in there. A couple of pieces didn't fit so I also filled a salad bowl
full of water next to it.</p>
</p>
Add 2 table spoons of bleach to the carboy</em>, and one to the salad bowl. Same with
vinegar (2 and 1 table spoons respectively).</p>
</p>
Let it sit for a while (30 minutes).</p>
Once it sat long enough, empty everything of water and let it air dry for a few
minutes (I waited 10).</p>
Diluting the honey</h2>
Diluting the honey is much easier with hot water, so I filled my electric kettle
and boiled a bunch of water. I put about 2 liters of boiling water in the carboy</em>,
then had fun emptying as much of the honey pots in there as I could.</p>
</p>
Of course, honey is super sticky, so there was still quite a lot of it in the
almost empty pots. Another kettle of boiling water was spread between the almost
empty pots to dissolve the remaining, honey, and all of it was poured in the carboy</em>.</p>
Yummy!</p>
Adding extras</h2>
As per the recipe, I washed my oranges very well, and cut them in eights before
throwing them (skin and all) in the carboy</em>. The cloves and cinnamon were added,
and I ended up putting the very scientific "2 handfuls" of raisins in there.</p>
No idea how much that actually is :)</p>
I filled the carboy</em> to almost the top (leaving room for eventual foam to form)
with cold water. The temperature was about 30°C, and I let it cool down further
to about 25°C before adding the yeast.</p>
Pitching the yeast</h2>
Yeast came in a gooey-doughey cube, and I put half of it in the carboy</em> (about
20 grams).</p>
That's it.</p>
I closed the airlock and put that in a corner of the room while I cleaned the
huge mess I created.</p>
Fermentation</h1>
Fermentation being a very chaotic process, most websites give a rather large time
frame for your must</em> (the mixture of honey and water) to start fermenting: between
20 minutes and 3 hours. Some website tell you to wait 24 hours, up to 72 hours (!)
before you start wondering what's up.</p>
The way you can tell whether fermentation is occurring is to check your airlock for
bubbles - fermentation creates CO² as a byproduct, and the purpose of your airlock
is to let it escape, while preventing potentially contaminated air from entering.</p>
Oh noes! Nothing happens</h2>
I left my carboy</em> overnight, and came back in the morning to an airlock still showing
no signs of any bubbles.</p>
Assuming the fermentation failed for some reason, I stirred my must</em> and added
another two handfuls of raisins (their sugar is easier for the yeast to eat, so
it acts as a natural booster in case your yeast is struggling).</p>
How to properly fit an airlock</h2>
I finally realised I installed my 3 parts airlock wrong - silly me!</p>
</p>
I misunderstood how the airlock worked, and supposed it was enough
to let gravity push the mobile part of the lock (the red cylinder on top) back
down, but as it turns out, it isn't. The CO² pressure accumulating under that
part is strong enough to lift the light plastic piece completely out of the
water, and therefore, no bubbles are visible.</p>
Duh!</p>
Adding a rubber band to hold the mobile part in place yields immediate results:
after a few seconds, a large bubble sprayed water in my face. The airlock needs
just a little bit of liquid to work properly - and I put way too much in, so
it splashed out happily until reaching the optimal level.</p>
</p>
Letting it sit</h2>
The last part was to find a suitable place to leave the carboy</em> for two months.</p>
Space is rarely an issue here (I live in an old foundry), but finding a room
that would stay at a relatively stable 20°C proved to be a bit more challenging
than I thought, especially during the cold months of winter and spring. Of course,
the old foundry is not heated...</p>
Fortunately I bought the smallest possible carboy</em>, so I managed to fit it in a cabinet,
close to a radiator. Since yeast doesn't like light, the fact that it's a
seldom-used cabinet makes it even more appropriate.</p>
If that batch succeeds, I might start looking at refurbishing
part of the foundry into a brewery - but that'll be if and when :)</p>
</p>
See you in two months!</h1>
That's it for the preparation, I now have to do pretty much nothing at all for
a couple of months!</p>
I'll write another blog post when it's time to see what mother nature brewed for
me. In the mean time, feel free to leave a comment on Reddit</a> !</p>


Mount your /home in LXD
2016-03-14T00:00:00+00:00
UPDATE</strong>: There is now a nicer way to mount /home in your LXD containers</a>, please read my updated article instead.</p>
I've used LXC to host my development environment for a long time, and since the amazing LXD is the new kid on the block I decided to go ahead and see if I could equally easily use it for my day to day usage.</p>
Good news! I can! One feature is slightly less obvious with LXD than it was with LXC however, so after picking my colleague's brains on this, I decided to go ahead and write this blog post.</p>
One very convenient feature of LXC is the -b</code> option to the container creation command line, which allows the container to mount the host user's home inside the container. This allows, for example, several containers to work from the same files in different environments, saving disk space but allowing for testing different operating system versions or set of installed packages.</p>
Privileged containers</h2>
For this feature to work, we'll need to run privileged containers, since we'll need to do mounts, and that requires root. So unfortunately we won't be using LXD's awesome security and isolation features for this container, but I figure that is a limitation I can live with for a development machine.</p>
Also, remember that this will only work for the local case - the client can just as well connect to remote machines, but obviously your /home folder won't be present there. And you can't migrate the container either, of course.</p>
With all these disclaimers out of the way, telling LXD that you want a privileged container is easy:</p>
lxc launch ubuntu:xenial <container name> -c security.privileged=true
</code></pre>
User mangling</h2>
The default Ubuntu images will give you a locked down machine with a single user, the ubuntu</code> user, and no means to SSH into your new machine. You can however simply ask LXD to execute a command in your fresh container, and therefore can get a root shell there by executing /bin/bash</code>.</p>
We want our user inside the container to be called the same as the one outside the container, so we'll rename the ubuntu user to whatever the outside user is called.</p>
Warning</strong>: This probably</code> only works if your host's user has the same UID than the ubuntu</code> user inside the container. This should be the case if your laptop/dev machine has a single user, but beware of this limitation.</p>
Getting a shell inside the container is easy:</p>
lxc exec <container name> /bin/bash
</code></pre>
Tadaaa! Root!</p>
Let's now rename the ubuntu</code> user to whatever your user is called:</p>
sed -i 's/ubuntu/<new user name>/g' /etc/{passwd,shadow,group,gshadow}
</code></pre>
It feels a bit dirty but it should work. And of course, like one of my colleagues so eloquently said: "the beauty with containers is that if it doesn't work, you can trash them and start again" :)</p>
Resetting the user password</h2>
The newly renamed ubuntu</code> user has a locked password by default (a sane choice), so you might want to re-enable it from your in-container root shell before you log out:</p>
passwd <new user name>
</code></pre>
Mounting your home</h2>
LXD now includes a nifty feature allowing you to create "devices" and mount them into containers, and that is precisely what we'll use to mount our host's /home/ into the container's:</p>
lxc config device add <container name> homedir disk source=/home/$USER path=/home/<new user name you chose at the previous step>
</code></pre>
This should hopefully work its magic - and you can now try to either SSH login into your instance (because .authorized_keys</code> from your /home should now be inside the container's /home folder too!), or inspect what happened with root again by executing /bin/bash</code>.</p>
As long as your UIDs stay in sync between the outside host and the inside container, you should be good to go.</p>
Comments? Questions? Get in touch, or discuss on hackernews</a>.</p>


Flashing a Samsung Galaxy S5 from Ubuntu
2016-02-24T00:00:00+00:00
Unfortunately, it's a little more involved to flash a Samsung S5 using the Heimdall
software suite on Ubuntu than it should, so I've compiled a list of necessary steps
to get it all working together.</p>
The general process should normally looks like the following, as per
Cyanogenmod's flashing guide</a>:</p>

Install Heimdall</li>
Flash a custom recovery</a> partition to your phone</li>
Copy the image you want to flash to your phone's SD card</li>
Copy the google applications package to your phone's SD card</li>
Flash both the new ROM</a> and the google apps package</a> to your device.</li>
Reboot the phone</li>
</ul>
I found that the first step is actually a little more involved than it should because
the Heimdall version packaged with Ubuntu is old, so I had to compile Heimdall
from source and add some custom udev rules so that I could flash successfully.</p>
Compiling Heimdall from sources (from git master)</h1>
First of all, let's get the latest sources</a> on our machine```</p>
sudo apt-get install git
git clone https://gitlab.com/BenjaminDobell/Heimdall.git
cd Heimdall</p>
Of course, we'll need a few build dependencies before we can actually build```

sudo apt-get install build-essential cmake zlib1g-dev qt5-default libusb-1.0-0-dev libgl1-mesa-glx libgl1-mesa-dev

</code></pre>
I'm not sure why the openGL dependencies are needed, but I followed the HOWTO to
the letter and it worked.</p>
The build step itself is a standard cmake workflow, no surprises```</p>
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make</p>
That will create a set of `heimdall` binaries in the current directory's bin/ subfolder.

Let's check that everything worked OK with a quick test```

bin/heimdall version  # That should return whatever is the current version

</code></pre>
Adding custom (temporary) udev rules</h1>
Before we can actually flash anything we need to tell udev not to use the USB
modem driver with our phone. To do this, we simply add a custom udev rule in
/etc/udev/rules.d```</p>
sudo su -
cat > /etc/udev/rules.d/90-temp-samsung.rules <<EOF
ATTRS{idVendor}=="04e8", ENV{ID_MM_DEVICE_IGNORE}="1"
EOF</p>
This bit is a bit cryptic, especially the vendor magic number. But take my word
for it, "**04e8**" is actually whatever a Samsung Galaxy S5 advertises as vendorId.

You need to restart udev and re-plug your phone in for this to work```

sudo service udev restart

</code></pre>
Actually flashing!</h1>
Hurray! We should now be able to flash the downloaded recovery file to our phone with```</p>
bin/heimdall flash --RECOVERY /path/to/the/recovery.img --no-reboot</p>
Put the custom image you intend to flash on the SD card. I didn't manage to
workaround adb not being able to adb push to teamwin's recovery image, maybe
my udev rule up there interferes with it somehow, I got stuck with adb complaining
about a lack of permissions. No worries. I'll put the file on the actual SD card
(like, plugging it in another computer, physically).

You can now reboot into recovery mode (volume up + home + power) and use the recovery
UI to flash your new system and the google apps bundle you downloaded previously.

# Remove the custom udev rule

It's now time for our custom udev rule to be removed (or commented out), since
that will otherwise prevent the system from detecting the phone as a USB modem.

If you can live without the functionality feel free to leave the rule as-is,
but I personally love to be able to just plug the phone in and let it serve as
and extra line to the world.

That's all folks! As usual, if you have questions or comments feel free to
[tweet](https://twitter.com/3baal) or email me.
</code></pre>


Back to Ubuntu and Apache2 (and a couple of suggestions)
2015-10-13T00:00:00+00:00
As some of you probably have read</a>, I switched this blog to using OpenBSD's
httpd server a few days ago, because I wanted to try new things and it seemed
that httpd offered a pretty good out-of-the-box experience, with security and
sanity of the code being the main focus.</p>
There are, however, rough edges I've encountered in the form of
missing features before my (simple) use case is entirely satisfied, and before
httpd can be considered a truly great webserver for static content.</p>
Therefore I'm back on Ubuntu and Apache2 for now, until my use case can be fully
satisfied with OpenBSD's httpd server.</p>
The missing pieces (for me)</h1>
For my particular use case two features are missing from httpd before I can consider
it for production: cache control settings and client-side SSL renegotiation.</p>
Allow disabling client-side SSL renegotiation</h2>
Client-side SSL renegotiation is a know vector for CPU-bound denial-of-service
attacks, where a single connection socket can be used to make the server spend
a lot of CPU cycles quite easily.</p>
Most other HTTP servers let administrators disable client-side renegotiation to
mitigate this problem. The downside is that some applications need</em> client-side
renegotiation, but they are a minority use case.</p>
Suggestion</h3>
The relayd server (off which httpd is based) received a patch to add configuration
syntax to disable client-side renegotiation:</p>
- ssl [no] client-renegotiation
    -> allows the interception of ("secure") client initiated
        renegotioations, which are considered a risk in DDoS scenarios
        because many CPU cycles can be burned this way on a single TCP
        connection without an obvious way for the administrator to 
        immediately know what's happening.
</code></pre>
Porting this patch to httpd seems like a relatively straightforward ordeal to my
unfamiliar-with-the-code eyes.</p>
Tracking</h3>
Being new to OpenBSD, I wasn't sure where to report this, but it seems that
reky's github mirror of the http portion of the OpenBSD tree is actively looked
at, so I openened a github issue</a>
on there.</p>
Cache-Control headers</h2>
When serving static content it makes a lot of sense to let the webserver set Cache-Control
headers for some of the assets (images and CSS don't change often in my case, if at
all). This of course allows browsers to skip some of the requests they need
to make to the webserver, since they know how long a piece of information can be
considered "fresh".</p>
Httpd doesn't currently support setting headers, and I can understand that it's
a complex feature to implement that might not ever make it to the roadmap (if
there is such a thing).</p>
I'll be back!</h1>
My venture in the OpenBSD universe was a positive experience, I'll keep an eye
on the community for a bit and see if the features I'm missing get implemented.</p>
In that case I'd of course try it again!</p>


This blog now served by OpenBSD!
2015-07-21T00:00:00+00:00
While Ubuntu is still the OS of my heart, I decided to give OpenBSD</a> another
look, and especially their new httpd webserver, since it is extremely secure,
and like everything else on OpenBSD, extremely simple to use!</p>
Here's what I did to get rolling:</p>
Install OpenBSD</h1>
I decided to follow Tubsta's article</a>
to install OpenBSD on a DigitalOcean</a> droplet.</p>
Configure httpd</h1>
Configuring httpd to serve my blog (a bunch of static files, generated by
Pelican</a>) was a piece of cake. Here's the complete configuration file:</p>

# /etc/httpd.conf
# "egress" means "use the interface of the default route"
ext_if="egress"
# A simple macro defining my domain name. DRY
domain="tribaal.io"
# Run 6 child processes. The default is 3, and since I have plenty
# of RAM, I'm not sacrificing much here.
prefork 6
# Set mime type according to the file name.
types { include "/usr/share/misc/mime.types" }
server $domain {
    listen on $ext_if tls port 443
    # Enable HTTP Strict Transport Security (defaults to 1 year).
    hsts
    # The webroot folder (where the static content will be served from).
    # This is in a chroot under /var/www/
    root "/htdocs/tribaal.io"
}
server $domain {
    listen on $ext_if port 80 
    # Redirect non-SSL connections to the SSL endpoint.
    block return 301 "https://$SERVER_NAME$REQUEST_URI"
}

</code></pre>
Adding SSL certificates</h1>
My freshly renewed certificate in hand (thanks, Gandi</a>!), I simply put the files
in the default httpd locations (since that's the only SSL service running on
the machine)```</p>
Make a combined cert with gandhi's intermediate and my own certificate</h1>
cat server.crt > combined.crt
cat GandiStandardSSLCA2.pem >> combined.crt
mv combined.crt /etc/ssl/server.crt
mv server.key /etc/ssl/private/server.key</p>
The default configuration, plus adding the hsts stanza in the configuration file
[will get you an A+ grade on SSLlabs](https://www.ssllabs.com/ssltest/analyze.html?d=tribaal.io).

# Add the actual blog files

Of course, I needed to scp my blog files to the correct place in the
`/var/www/htdocs/tribaal.io/` folder.

# Enable httpd

By default, nothing runs on your OpenBSD install - so simply run the following
as root to get httpd running```

# Enable running the service
echo 'httpd_flags=""' >> /etc/rc.conf.local
# Actually run the service
/etc/rc.d/httpd start

</code></pre>
Edit</strong>: As Mischa Peters pointed out on twitter</a>, the more canonical way to
achieve this in OpenBSD would be to use```</p>
rcctl enable httpd # Enable the service to run
rcctl start httpd # Actually start the service</p>
# And that's it!

That's all. Piece of cake :)
</code></pre>


Monitoring Apache2 with Landscape
2014-10-24T00:00:00+00:00
It is important for most sysadmins to have a clear view of the overall trend
in their production system.</p>
Since I work on the Landscape</a> project,
I wanted to use it's nifty custom graphing feature to get an understanding of
the general trends of apache connections for this blog.</p>
Enter custom graphs</h1>
Custom monitoring graph scripts are Landscape's solution to arbitrary trend
graphing.
You can create one by navigating to "Custom graphs" from your main account page:</p>
</p>
Basically, it's a script that is expected to return a numeric value to standard
out, that Landscape will run every 5 minutes and plot the results
in the monitoring tab of your account.</p>
Simple as pie!</p>
Writing a script to monitor apache connections</h1>
The following script, written in Python, should allow you to plot the number of
connections to your website with minimal changes: adapt the location of
access.log to match your site, and make sure the TEMP_FILE path is unique per
machine.</p>

#!/usr/bin/env python
import os

ACCESS_LOG="/var/log/apache2/access.log"  # Adapt this to your needs
TEMP_FILE="/tmp/apache_last_line_reqs"  # This should be unique per machine

last_line = None
last_line_index = None
result = 0

if os.path.exists(TEMP_FILE):
    with open(TEMP_FILE, "r") as line_file:
        last_line = line_file.read()

logs = []
with open(ACCESS_LOG, "r") as log_file:
    logs = log_file.readlines()

if last_line in logs:
    last_line_index = logs.index(last_line)

if last_line_index and last_line_index != len(logs) -1:
    new_logs = logs[last_line_index+1:]
    result = len(new_logs)

# Write the last line we saw in the special file for next run.
with open(TEMP_FILE, "w") as line_file:
    line_file.write(logs[-1])

print result

</code></pre>
Landscape will take care of distributing this to your machines automatically,
and will start gathering results for you.</p>
Hope this helps!</p>


Setting up a full Ubuntu mirror on Trusty
2014-10-22T00:00:00+00:00
Why?</h2>
As some of my readers might know, I have recently moved to live in Tanzania.
While the network here is much better than in neighbouring countries (thanks
to a big investment to roll out a shiny national fiber optics backbone), there
is no official Ubuntu archives in the country at this point, and installing
new machines daily thanks to LXC containers can get a little slow.</p>
Since my awesome ISP</a> is running Ubuntu on pretty much
anything that is not a router, they already had a deb proxy - and they were
happy to provide bandwidth to go one step further!</p>
What you need</h2>
Installing a full Ubuntu mirror (full package archive, but also cdimages, the
release images, and possibly ports of Ubuntu to other architectures) is pretty
simple.</p>
You'll need to check a few things before we get started:</p>

A lot of storage space - around 1Tb without the ports, as of June 2014. While speed doesn't hurt, the most important is that it's safe and big.</li>
A reasonably powerful machine, but no need for a very beefy monster either since all the machine will be doing is serving static content with apache</li>
A lot of bandwidth for the initial sync, and a lot of time. Or a friend with an full mirror on a USB disk :)</li>
Ideally, a set of caches between your clients and your mirror.</li>
</ul>
Using Ubumirror</h2>
The easiest way to get a full mirror is to install the ubumirror package</a>.
It basically installs a few shell scripts in /usr/bin</code> that wrap rsync, and a
config file in /etc</code>.</p>
Since the ubumirror in the trusty archives is unfortunately a little outdated,
let's use the latest and greatest instead:</p>
sudo add-apt-repository ppa:ubumirror-devs/ubumirror
</code></pre>
The package was backported from utopic, so it also sits in backports, but the
PPA is probably a safer bet (I'm the maintainer for ubumirror).</p>
As usual in the Debian/Ubuntu world, it all starts with a:</p>
sudo apt-get install ubumirror
</code></pre>
Configuring ubumirror</h3>
That's the meat of the problem here, but hopefully the configuration should be
pretty straightforward.</p>
The four most important variables to set (rather, uncomment) are the ones
controlling the actual sync: UBUARC_DIR</code>, UBUCDI_DIR</code>, UBUREL_DIR</code>,
UBUPOR_DIR</code>.
If one of these is not set, the mirror scripts won't sync this particular
component.
Make sure the directories point to a partition with plenty of space (1Tb should
be just enough for deb packages and releases, but 2Tb is recommended).
Ports and cdimages do take quite some space, too.</p>
A word about components</h3>
The four components are:</p>

UBUARC</strong>: The ubuntu package archive. This means you can then point your
sources.list entries to your newly created mirror.</li>
UBUCDI</strong>: The CD archives. This includes most cd images, including cds for
flavors (kubuntu, xubuntu etc...). This includes the daily builds for the
in-development release, too, so they change relatively often (daily).</li>
UBUREL</strong>: The CD images for the released distribution (the main "Ubuntu"
flavor).</li>
UBUPOR</strong>: The ports. These are the packages for alternative architectures, such
as ARM, Power, Sparc... These will use a lot of space (roughly half a Tb per
architecture).</li>
</ul>
Running the initial sync</h3>
Now that the mirror is configured, it's time to start the sync process itself!
This will take a long, long time.
Of course, it is much faster to get the contents of /srv/mirror/</code> from a friend's
USB disk, but even this will take a while (a USB 2 disk took more than 14 hours
last time I tried):</p>
sudo /usr/bin/ubuarchive
</code></pre>
This should take care of the archive sync. In a similar fashion, you can run the
other sync components:</p>
sudo /usr/bin/uburelease
sudo /usr/bin/ubucdimage
sudo /usr/bin/ubuports
</code></pre>
Setting up a regular sync</h2>
Ubumirror ships with an example cron configuration file that syncs all the
components at regular, sensible intervals.</p>
The following will copy the shipped crontab file to the relevant place:</p>
sudo cp /usr/share/doc/ubumirror/examples/ubumirror.crontab /etc/cron.d/.
</code></pre>
Please take a second and tweak the minutes to avoid overloading the main archives
artificially at set minutes. Picking something to your liking or random is just fine.</p>
Serving the content</h2>
We'll use Apache for this, and the configuration is pretty simple since basically
it will be serving static content. As such, installing apache2 with the "worker"
model is a good idea:</p>
sudo apt-get install apache2-mpm-worker
</code></pre>
This will pull apache2 and required dependencies.</p>
An example apache2 configuration file that can be used almost as-is can be found
in /usr/share/doc/ubumirror/examples/apache2-ubuntu-mirror.conf</code>. You can
drop it in sites-available and enable it with:</p>
sudo cp /usr/share/doc/ubumirror/examples/apache2-ubuntu-mirror.conf /etc/apache2/sites-available/mirror.conf
</code></pre>
Remove the default website in there and don't forget to enable the "headers" and
"expires" modules, then enable the site itself:</p>
sudo a2enmod headers expires
sudo a2ensite mirror
</code></pre>
Restarting or reloading apache2 should do the trick.</p>
Checking it all works</h2>
At this point, you should have a working mirror! Check by pointing your web
browser to the mirror on port 80, and then by pointing your sources.list entries
to it!</p>
Don't hesitate to get in touch if you find errors or would like some more
information about running your own mirror. I disabled comments on the blog for
now.</p>


GPG: Restoring a private key's UID from a pubkey's UID
2014-07-10T00:00:00+00:00
The problem</h1>
When creating a new keypair since my old key was getting old (and insecure),
I decided to backup my private key to an undisclosed location for security.</p>
Unfortunately I did then add a UID to my private key and forgot to re-backup
the key, which resulted in my public key have several UIDs, but my private key
showing only one when restored from backup. I did try the restore procedure,
but maybe a little too</em> zealously and ended up nuking my .gnupg directory.</p>
Yeah, get some sleep before you mess with gpg :)</p>
The solution</h1>
It is actually pretty simple to solve the problem of "importing" your pubkey's
UIDs to your privkey.</p>
First, backup!</h2>
Let's not mess things any further and start with a good ol' backup of your
~/.gnupg directory```</p>
cp -rp ~/.gnupg ~/BACKUP.gnupg</p>
## The plan

The idea is that the public portion of the UID is created simply as a function
of your private key and the UID string. That means recreating a UID with the
same string and the same key will be mathematically equivalent, and since
the signatures you collected are function of the public key and the UID, they
will be valid if we recreate a UID with the exact same string.

So the plan is to delete the missing UID in the *pubkey*, and then recreate the
exact same UID, which will insert it in both the pubkey and the private key.

## Deleting the missing UID(s) from the pubkey

Let's delete the missing UID from the pubkey.

It starts by editing the key```

gpg --edit-key <key ID>

</code></pre>
At the GPG prompt, select the UID that is missing in the private key. Make sure
you note down the full</em> UID, exactly as it appears</em>```</p>
uid </p>
This will echo your pubkey UIDs back to you, and you should notice a little "*"
next to the key you selected.
Now, let's nuke it```

deluid

</code></pre>
Recreating the same UID</h2>
Now that the UID is gone, let's re-add the exact same UID to the keypair```</p>
adduid</p>
Make sure you fill in the exact same UID information as you had before!

## Don't forget to save

At the GPG prompt, make sure you save your work by issuing the following aptly
named command```

save

</code></pre>
Make sure it worked</h1>
You should now have your missing UIDs back in your private keyring!
Let's check with```</p>
gpg --list-private-keys</p>
Make sure it all outputs what you expect (all the UIDs are there).

That's all! Hope it helps!
</code></pre>


Making LXC (and Juju) fly on Ubuntu
2014-01-14T00:00:00+00:00
you might have also been frustrated about how network-hungry LXC is,
in particular when used with Juju. I will show you how to make it
automagically use a deb packages cache, to drastically speed up
subsequent downloads and installations.</p>
If like me you use LXC containers a lot, and are often on the road, you might
have also been frustrated about how network-hungry LXC is, in particular when
used with Juju.
I will show you how to make it automagically use a deb packages cache,
to drastically speed up subsequent downloads and installations.</p>
Installing the cache client</h1>
We'll use a clever piece of software called "squid-deb-proxy-client" to do the
heavy lifting for us. On the host</em> of your LXC installation, simply pull in
and install it with```</p>
sudo apt-get install squid-deb-proxy-client</p>
This will add a little script that detects squid-deb-proxies on your networks
via multicast DNS, so that APT will use a proxy if it finds one. More
information about this awesome piece of software [can be found here](http://www.linuxjournal.com/content/presenting-squid-deb-proxy-speed-your-update-downloads) .

It's great - I have a small local cache (10Gb) on my laptop (inside an LXC
container), and a bigger one on my home network (40Gb). This allows APT to
always know what is available.

# Enter LXC hooks

We don't want to have to install the package on every LXC container we spawn,
so instead, we'll inject the detected proxy setting in the container's apt
config when it boots. LXC provides a very handy "hooks" mechanism for that, so
we simply need to drop a script somewhere and add a simple config line in the
container's config file```

# In /var/lib/lxc/<container name>/config,
lxc.hook.pre-start=/path/to/an/executable/script

</code></pre>
The script will now be run before LXC starts a new container. It is passed
some handy environment variables to help us tweak the container's apt config
before it starts.</p>
The code</h2>
It's not rocket science - simply query the little executable provided by
squid-apt-proxy-client, and write the found URLs in the container's
/etc/apt/apt.conf.d/ directory (in an aptly named "50squid-deb-proxy" file).</p>
Instead of reproducing the code here, I encourage you to download it from
github instead```</p>
curl -L http://git.io/YlfYIQ | sudo tee /usr/share/lxc/hooks/squid-deb-proxy-client
sudo chmod +x /usr/share/lxc/hooks/squid-deb-proxy-client</p>
As an added bonus, the script checks for similar config files in the host,
and forwards it directly to the guest. That means nested containers will also
benefit from the caches the host can see :)

You just need to edit your container's config file and point it at the hook```

# Append the following to /var/lib/lxc/<container>/config
lxc.hook.pre-start=/usr/share/lxc/hooks/squid-deb-proxy-client

</code></pre>
A small workaround is needed for the time being, where you need to grant the
pre-start hook apparmor privileges to interact with dbus. It's quite easy
however, as simply adding```</p>
dbus,</p>
to the beginning of the `/etc/apparmor.d/abstractions/lxc/start-container` file
will do the trick. That will not be necessary in future releases of LXC in
Ubuntu, but is required at the time of this writing.

# More awesome with templates!

Even better, we can use the same technique to make creating completely new LXC
images much faster too!
Creating a container for a new Ubuntu release can take a little bit of time
since debootstrap needs to download all of the base packages, that can take
a while on a slow internet connection or when you do this several times a day.

Changing the base Ubuntu template to check for `squid-deb-proxy` servers using
the same mechanism when it's not supplied any other HTTP or apt proxy (we don't
want to override user input obviously) solves that problem.

## The code

It is a little more involved than simply adding a pre-start hook, as you'll
need to modify the Ubuntu template for this to work.

Here is an already patched version you can immediately use```

# backup your existing template
sudo mv /usr/share/lxc/templates/lxc-ubuntu /usr/share/lxc/templates/BACKUP.lxc-ubuntu
curl -L http://git.io/VJ7ZUQ | sudo tee /usr/share/lxc/templates/lxc-ubuntu
sudo chmod +x /usr/share/lxc/templates/lxc-ubuntu

</code></pre>
Creating a new LXC container will now use the proxy for the debootstrap phase
as well!</p>
Playing with Juju</h2>
It all comes together quite nicely when adding the proxy pre-start hook on the
lxc-ubuntu-cloud</code> template as well, since that will make all new containers
spawned with Juju use the cache too! Great for when you need to rapidly spawn
environments for development!```</p>
backup your existing template</h1>
sudo mv /usr/share/lxc/templates/lxc-ubuntu-cloud /usr/share/lxc/templates/BACKUP.lxc-ubuntu-cloud
curl -L http://git.io/CIAkrA | sudo tee /usr/share/lxc/templates/lxc-ubuntu-cloud
sudo chmod +x /usr/share/lxc/templates/lxc-ubuntu-cloud</p>
# Conclusion

These tricks really save me a considerable amount of time on my daily business
deploying containers, and since I hope it'll help other people too I'll submit
the patched templates and new hook to the core LXC code.

Hope this helps!
</code></pre>


Using the i3 window manager
2013-09-28T00:00:00+00:00
A colleague of mine suggested that I should try tiling window managers, and
proceeded to produce a list of them, including i3</a>,
awesome</a>,
wmii</a> and xmonad</a>.</p>
Having not used any tiling window manager for more than 5 seconds before, I
decided to try them, and finally settled for i3, because I got it to work in
less than 5 minutes, and it just feel "right" to me.</p>
Installation</h1>
As usual on debian-based systems, it all starts with an```</p>
sudo apt-get install i3</p>
Pretty straightforward :)

The installer guides you through some kind of wizard, where the only meaningful
decision is whether to have your "modifier" key be Alt or the famous "windows"
key.

# Running i3 for the first time

i3's interface is quite minimal (to say the least). First good news, it picks
up multiple monitors without hiccups. Launching a terminal is as simple as
mod+enter.

[The documentation](http://i3wm.org/docs/) is great, simple but direct. I highly encourage the reader to
bookmark it for future reference.

# Some tweaks

Here's a list of tweaks I had to make to the default i3 config to make the
system behave as I wanted.

## GTK theme

i3 does not come with the GNOME bells and whistles, and so the default look for
GTK programs is quite ugly.

Hopefully, a simple edit of the i3 config file (in ~/.i3/config) makes it
beautiful again, and painless. Add the following to the bottom of that file```

exec --no-startup-id gnome-settings-daemon

</code></pre>
All "exec" additions need you to restart i3 to take effect (log out by pressing
mod-shift-e - "e" for exit).</p>
Network mangement</h2>
Out of the box, i3 has no provision for a wireless selection mechanism. While
possible, I would rather not have to fill in wireless details by hand in a
config file every time (it's 2013!).</p>
Adding the following exec line to the config file did the trick```</p>
exec --no-startup-id nm-applet</p>
You need to restart i3 for the change to take effect.
i3 supports gnome applets in its bottom status bar, so all is well and you can
interact with the NetworkManager applet just as you would in Unity or GNOME.

## Sound management

In the same idea, I use a lot of different pulseaudio sinks, and I wanted to be
able to switch from one output to the other easily.

Again, adding an exec line to the i3 config file was the charm```

exec --no-startup-id gnome-sound-applet

</code></pre>
You know the drill - you need to restart i3 for this to work.</p>
Desktop background</h2>
While completely unnecessary with a tiling VM since you don't see your
background picture very often by design, I like having one, so I decided to use
feh</code> to set the root X window (what "the background" is in i3) to my
favorite picture of the month. So here's the magic exec line (as usual) to put
in your .i3/config</code> file, after the obvious `sudo apt-get install feh````</p>
exec --no-startup-id feh --bg-fill /path/to/penguin/picture.jpg</p>
## Locking your screen

A last nitpick for the perfect i3 desktop for me was the ability to quickly
lock my screen, ideally using the default Ubuntu lockscreen.

It's very easy, and as usual a small line in your `~/.i3/config` file does
the trick```

bindsym $mod+Shift+o exec "gnome-screensaver-command --lock "

</code></pre>
Since by default $mod-shift-l is already bound to "move the active window down"
I opted to bind the lock to O instead. But feel free to set it to anything
else of course :)</p>
More tweaks?</h1>
I'm sure some more could be done or added to this, but so far, this was all I
needed to use i3 on a day-to-day basis.</p>
Feel free to get in touch with me if you have more tips to share!</p>


Steam on LXC, on Saucy
2013-09-19T00:00:00+00:00
Steam is an awesome game and content distribution platform, but unfortunately
only runs on 32bit systems.</p>
If like me you like to keep your main install as pure 64bits as possible, it is
possible to run Steam inside an LXC container!</p>
The
original article and source code by Stephane Graber</a>
works wonders in Raring, but an API change makes it fail on Saucy. I recently
repackaged the software for Saucy, so it is now trivial to have a working
Steam LXC container again!</p>
Installation</h1>
Quite simply add the tribaal/steam-lxc</code> PPA to your system```</p>
sudo apt-add-repository ppa:tribaal/steam-lxc
sudo apt-get update && sudo apt-get install steam-lxc lxc</p>
# Creating a steam LXC container

Again, creating a steam LXC container is quite easy```

sudo steam-lxc create

</code></pre>
This might take a while, since it will download a base 12.04 image, update it,
install all the required libraries and finally install Steam.</p>
Running the container</h1>
Once the container is built, you can start it with the command```</p>
sudo steam-lxc run</p>
Of course, all the normal LXC commands work with the steam container, so you
can for example make sure it's running or get its IP address with the usual
listing command```

sudo lxc-ls --fancy

</code></pre>
Destroying the container</h1>
When (if) you get tired of Steam and want to reclaim the used space on your
system, you can quite simply delete the container you created using the
following```</p>
sudo steam-lxc destroy</p>
Running Steam in a container is a great idea, and hopefully the simple fix for
it to run seamlessly on Saucy will make it to the main repository to avoid
doing the PPA dance :)

Have fun!

</code></pre>


Rebuilding an Ubuntu package
2013-07-05T00:00:00+00:00
In this first article about debian/ubuntu packaging, we will learn to rebuild any
existing ubuntu package locally, to get more familiar with the various tools used
to build debian pacakges.</p>
Getting the package source</h2>
Provided your /etc/apt/sources.list</code> file contains deb-src</code> entries,
you can do the following:</p>
mkdir tmp
cd tmp
apt-get source $package_name
</code></pre>
Getting examples goes a long way in understanding something, and these simple steps
give you access to a lot</strong> of them.</p>
If you don't have deb-src entries in your sources.list file (if you are working
inside a default LXC container for example), you can easily add them with the
following command:</p>
sudo sed -i 's/^deb \(.*\)/deb \1\ndeb-src \1/g' /etc/apt/sources.list
</code></pre>
Getting the required tools</h2>
The second obvious step is to try and build the package you just obtained. We need
a few tools in order to do that:</p>
sudo apt-get install build-essential pbuilder
</code></pre>
These packages install the following:</p>

The build-essential</code> package contains most of the useful tools to build
binaries, like a compiler, linker, and plenty of other goodies.</li>
The pbuilder</code> package has all you need for the packaging itself.</li>
</ul>
Once you have the necessary tools, you will need to get the package's build dependencies</em>.
Build dependencies are packages needed to build a package, but not to run it. A common
example of this would be the python-setuptools</code> package to build python pacakges, while
paramount at package building time, it is not necessary to actually use the python package.</p>
It is quite easy to resolve and install build-dependencies for an arbitrary package:</p>
sudo apt-get build-dep $package_name
</code></pre>
This will fetch and install all the package's build dependencies.</p>
Rebuilding the package</h2>
Packages in Debian based systems are either source packages or binary packages.
It is advisable to start by building the source pacakge, since that will allow
you to distribute your changes to a number of architectures, and to send your
newly build package to a PPA, for example.</p>
Building a source package is easy, just cd into the pacakge's source directory
(the directory that was created for you with the apt-get source</code> command), and
run the following:</p>
debuild -S
</code></pre>
This will create a *.changes</code> file in the ../</code> directory. You can upload this
file to a PPA pretty easily to let launchpad build the package for several
different architectures easily.</p>
To build the corresponding binary package (at least the one for your current
architecture), run the following command instead:</p>
debuild
</code></pre>
This will create the debian package(s) in th ../</code> directory, once again.
You can now install these newly built packages just like you would any other
*.deb</code> file.</p>
Next time</h2>
Now that we know how to rebuild packages, we'll learn how to modify them before
rebuilding them (which is more interesting), as well as how to make your changes
available to the world using a PPA.</p>


Hello world!
2013-07-03T00:00:00+00:00
A new blog is born!</p>
I meant to do this for years, but today marks the debut of my new blog! A few
tech-related articles will be coming up.</p>
See you soon ;)</p>

Tribaal's blog

Archive

Setting up a ZNC bouncer on OpenBSD 6.4

Create an OpenBSD machine</h2> Nothing could be more simple using Exoscale's "exo" command line client.</p>

Setting up the acme/SSL with letsencrypt</h2> OpenBSD comes preinstalled with all the tools we'll need to setup a proper SSL certificate for our instance.</p>

Enjoy :)</h2> As usual don't hesitate to let me know if you found this helpful!</p>

Magic URLs in the Ubuntu ecosystem

Serving a static blog from a Snap

Running an Ubuntu mirror with Juju!

Creating a charm configuration file</h3> Let's ask our test deployment to only care about xenial, in order to speed up initial sync with the upstream archives and save disk space:</p>

Actually deploying the charms</h3> As usual in Juju land, the actual deployment couldn't be easier!</p>

Scaling our deployment</h3> You can then scale the archive cluster up by simply running</p>

Fixing a lost right-click after switching to 17.10's Gnome 3 and Wayland

Upgrading your Ubuntu-on-Windows install to the app version

Saving your data</h2> If you "bash on ubuntu on windows" environment has some data you'd like to keep, make sure you back it up now. The uninstall process will nuke everything.</p> Uninstall the old way</h2> This is relatively simple. Opening a command line (cmd.exe) terminal and typing</p>

Uninstall the old way</h2> This is relatively simple. Opening a command line (cmd.exe) terminal and typing</p>

Building a very simple debian package

Anatomy of a package tree</h1> In a nutshell, a debian package tree is:</p>

Adding the actual files</h1> It's time to add the files we want to ship. For this, let's prepare the ground and add a "tree" directory in our foo-0.1 folder. That folder will be "translated" into our target system's root by the install rules we'll create just now:</p>

Switching themes, and Disqus

Theme change</h1> As you can see, I switched themes!</p>

A nicer way to mount your /home in LXD

Mounting /home read-write</h1>

Making LXD fly on Ubuntu!

In a new template</h2> Should you not want to alter the default template, you can easily create a new one```</p> export PROFILE_NAME=proxy lxc profile create $PROFILE_NAME</p>

That's it!</h1> As you can see it is trivial to set an apt proxy on LXD, and using squid-deb-proxy on the host makes that configuration trivial.</p> Hope this helps!</p>

Brewing my first batch of mead

Putting it all together</h1> Shopping is over, time for preparation.</p>

See you in two months!</h1> That's it for the preparation, I now have to do pretty much nothing at all for a couple of months!</p> I'll write another blog post when it's time to see what mother nature brewed for me. In the mean time, feel free to leave a comment on Reddit</a> !</p>

Mount your /home in LXD

Resetting the user password</h2> The newly renamed ubuntu</code> user has a locked password by default (a sane choice), so you might want to re-enable it from your in-container root shell before you log out:</p>

Mounting your home</h2> LXD now includes a nifty feature allowing you to create "devices" and mount them into containers, and that is precisely what we'll use to mount our host's /home/ into the container's:</p>

Flashing a Samsung Galaxy S5 from Ubuntu

Back to Ubuntu and Apache2 (and a couple of suggestions)

I'll be back!</h1> My venture in the OpenBSD universe was a positive experience, I'll keep an eye on the community for a bit and see if the features I'm missing get implemented.</p> In that case I'd of course try it again!</p>

This blog now served by OpenBSD!

Monitoring Apache2 with Landscape

Setting up a full Ubuntu mirror on Trusty

GPG: Restoring a private key's UID from a pubkey's UID

Make sure it worked</h1> You should now have your missing UIDs back in your private keyring! Let's check with```</p> gpg --list-private-keys</p> Make sure it all outputs what you expect (all the UIDs are there). That's all! Hope it helps! </code></pre>

Making LXC (and Juju) fly on Ubuntu

Playing with Juju</h2> It all comes together quite nicely when adding the proxy pre-start hook on the lxc-ubuntu-cloud</code> template as well, since that will make all new containers spawned with Juju use the cache too! Great for when you need to rapidly spawn environments for development!```</p>

Using the i3 window manager

More tweaks?</h1> I'm sure some more could be done or added to this, but so far, this was all I needed to use i3 on a day-to-day basis.</p> Feel free to get in touch with me if you have more tips to share!</p>

Steam on LXC, on Saucy

Create an OpenBSD machine</h2>
Nothing could be more simple using Exoscale's "exo" command line client.</p>

Setting up the acme/SSL with letsencrypt</h2>
OpenBSD comes preinstalled with all the tools we'll need to setup a proper SSL certificate for our instance.</p>

`Enjoy :)</h2> As usual don't hesitate to let me know if you found this helpful!</p>`

That's it!</h1>
As you can see it is trivial to set an apt proxy on LXD, and using squid-deb-proxy on the host makes that configuration trivial.</p>
Hope this helps!</p>
Discussion and/or comments welcome on Reddit!</a></p>

Putting it all together</h1>
Shopping is over, time for preparation.</p>

See you in two months!</h1>
That's it for the preparation, I now have to do pretty much nothing at all for a couple of months!</p>
I'll write another blog post when it's time to see what mother nature brewed for me. In the mean time, feel free to leave a comment on Reddit</a> !</p>

I'll be back!</h1>
My venture in the OpenBSD universe was a positive experience, I'll keep an eye on the community for a bit and see if the features I'm missing get implemented.</p>
In that case I'd of course try it again!</p>

Make sure it worked</h1>
You should now have your missing UIDs back in your private keyring! Let's check with```</p>
gpg --list-private-keys</p>
`Make sure it all outputs what you expect (all the UIDs are there). That's all! Hope it helps! </code></pre>`

Playing with Juju</h2>
It all comes together quite nicely when adding the proxy pre-start hook on the lxc-ubuntu-cloud</code> template as well, since that will make all new containers spawned with Juju use the cache too! Great for when you need to rapidly spawn environments for development!```</p>

More tweaks?</h1>
I'm sure some more could be done or added to this, but so far, this was all I needed to use i3 on a day-to-day basis.</p>
Feel free to get in touch with me if you have more tips to share!</p>