Cédric Félizard

How to install encrypted Linux with systemd-boot and Btrfs subvolumes

Fri, 05 May 2023 13:37:00 +0000

I recently reinstalled my system and struggled to find the right configuration to use systemd-boot with Btrfs as a root subvolume so here it is in case it helps someone.

# /boot/loader/loader.conf
default @saved
editor yes
timeout 3

# /boot/loader/entries/arch.conf
title   Arch Linux
linux   vmlinuz-linux
initrd  initramfs-linux.img
options rd.luks.name=<UUID>=root root=/dev/mapper/root rootflags=subvol=@

Replace <UUID> with the UUID of the physical disk partition. The rootflags=subvol=@ part is important and should not contain any slashes, i.e. rootflags=subvol=/@ won’t work. Don’t ask me how much time I wasted on that…

How to update Ruby with AWS ElasticBeanstalk

Thu, 29 Mar 2018 09:44:00 +0000

The AWS web interface for ElasticBeanstalk doesn’t let you update Ruby. Thankfully there is a way to do it via the command line using the aws utility.

First, we need to identify the so-called “solution stack name” we want to use:

$ aws --profile foo elasticbeanstalk list-available-solution-stacks | grep -E "SolutionStackName.+ Ruby 2\.5"
            "SolutionStackName": "64bit Amazon Linux 2017.09 v2.7.1 running Ruby 2.5 (Puma)",
            "SolutionStackName": "64bit Amazon Linux 2017.09 v2.7.1 running Ruby 2.5 (Passenger Standalone)",

Then we need to retrieve the environment name:

aws --profile foo elasticbeanstalk describe-environments | grep "EnvironmentName"
            "EnvironmentName": "foobar-rails",

Finally, we can update the environment:

aws --profile foo elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2017.09 v2.7.1 running Ruby 2.5 (Puma)" --environment-name foobar-rails

Done!

It will take a few minutes to redeploy your app. I like to monitor it using eb health --refresh.

Bye Octopress, welcome Jekyll!

Sat, 17 Sep 2016 14:41:18 +0000

I decided it was about time to upgrade this site to Octopress 3. Then I realised that Octopress 3 is basically Jekyll and some deployment scripts, which I don’t need, therefore I’m converting this blog to Jekyll.

Thank you Octopress, you’ve been very helpful for all these years. But it’s time to go back to the roots with a slimmed down design and no more JavaScript bloat, yay!

While I’m at it, I’m adding DNSSEC, HTTPS (thanks Let’s Encrypt) and hopefully IPv6 as well…

Cross-compile Bitcoin for ARM

Tue, 23 Feb 2016 23:21:39 +0000

Introduction

So you want to cross-compile Bitcoin (or any C/C++ program in fact) from your x86_64 host machine for an ARM “target” machine.

This little howto aims to help you with that. It’s intended for intermediate level, i.e. you should be familiar with the ./configure and make commands but you don’t need to have earlier experience with cross-compilation.

The first step is to identify what’s called the target triplet. An easy way to do so is to run gcc -dumpmachine on the target machine. If you don’t have gcc installed, you can install it to run that command then uninstall it right away.

In my case, I have:

$ gcc -dumpmachine
arm-linux-gnueabihf

You’ll have to replace arm-linux-gnueabihf with whatever you get for the rest of this howto.

Install a cross-compiler for our target platform

If you’re running Arch Linux, there might be an AUR package for you. If you’re not running Arch or you want to use a more generic method, you can skip to the next paragraph which explains how to use crosstool-ng.

On Arch Linux using AUR

$ yaourt -S arm-linux-gnueabihf-gcc # pulls all dependencies, compiles for several hours on a quad-core...

$ yaourt -Q | grep arm-linux
local/arm-linux-gnueabihf-binutils 2.25.1-3
local/arm-linux-gnueabihf-gcc 5.3.0-2
local/arm-linux-gnueabihf-glibc 2.22-3
local/arm-linux-gnueabihf-linux-api-headers 4.1.4-1

$ arm-linux-gnueabihf-g++ -v # should be working and in the $PATH

On any distro using crosstool-ng

First, you need to install crosstool-ng, the executable is named ct-ng and should be available to a non-root user.

Then we check if ct-ng knows our target architecture:

$ ct-ng list-samples | grep arm-linux-gnueabihf

If you can’t find an exact match, just run ct-ng list-samples and pick the closest one, like arm-unknown-linux-gnueabi or maybe armv7-rpi2-linux-gnueabihf. To select it, simply run:

$ ct-ng arm-unknown-linux-gnueabi

Now we need to build the actual toolchain. This will take a long while as it downloads a copy of the Linux kernel, binutils, gcc, etc. then builds gcc itself, etc. That will require a few gigs of disk space and burn your CPU for a while…

If you’re in a rush, you can skip building some of the tools such as gdb, etc. You can do that with ct-ng menuconfig then unselect what you don’t need.

$ ct-ng build

When it’s finally done, you should have a new directory named ~/x-tools/:

$ ls ~/x-tools/arm-unknown-linux-gnueabi/bin
arm-unknown-linux-gnueabi-addr2line  arm-unknown-linux-gnueabi-ct-ng.config  arm-unknown-linux-gnueabi-gcc-nm      arm-unknown-linux-gnueabi-ld.gold   arm-unknown-linux-gnueabi-size
arm-unknown-linux-gnueabi-ar         arm-unknown-linux-gnueabi-dwp           arm-unknown-linux-gnueabi-gcc-ranlib  arm-unknown-linux-gnueabi-nm        arm-unknown-linux-gnueabi-strings
arm-unknown-linux-gnueabi-as         arm-unknown-linux-gnueabi-elfedit       arm-unknown-linux-gnueabi-gcov        arm-unknown-linux-gnueabi-objcopy   arm-unknown-linux-gnueabi-strip
arm-unknown-linux-gnueabi-c++        arm-unknown-linux-gnueabi-g++           arm-unknown-linux-gnueabi-gprof       arm-unknown-linux-gnueabi-objdump
arm-unknown-linux-gnueabi-cc         arm-unknown-linux-gnueabi-gcc           arm-unknown-linux-gnueabi-ld          arm-unknown-linux-gnueabi-populate
arm-unknown-linux-gnueabi-c++filt    arm-unknown-linux-gnueabi-gcc-4.9.4     arm-unknown-linux-gnueabi-ld.bfd      arm-unknown-linux-gnueabi-ranlib
arm-unknown-linux-gnueabi-cpp        arm-unknown-linux-gnueabi-gcc-ar        arm-unknown-linux-gnueabi-ldd         arm-unknown-linux-gnueabi-readelf

Add the bin sub-directory to your $PATH with export PATH=~/x-tools/arm-unknown-linux-gnueabi/bin:$PATH

$ export CXX=arm-unknown-linux-gnueabi-cpp
$ $CXX -v
arm-unknown-linux-gnueabi-gcc (crosstool-NG crosstool-ng-1.22.0) 5.2.0

Great! We now have a working cross-compiler.

Compiling Bitcoin

We’re on the home stretch! Getting a cross-compiler to work was probably harder than compiling Bitcoin itself. Let’s start by fetching the source code and checking out the latest tagged release (v0.12.0 at the time of this writing):

$ git clone https://github.com/bitcoin/bitcoin
$ cd bitcoin
$ git checkout v0.12.0
$ cd depends
$ less README.md # the following is inspired from this README

Now we need to pull all the dependencies to compile Bitcoin. I don’t need a GUI – NO_QT=1 – nor wallet support nor UPNP but adapt the next line to your needs:

$ make HOST=arm-linux-gnueabihf NO_QT=1 NO_WALLET=1 NO_UPNP=1 -j4

This will also take a while since it downloads a bunch of dependencies including the fat libboost. When it’s done let’s go back to the root directory and generate the configure file:

$ cd ..
$ ./autogen.sh

Once again, I pass in a few flags to ./configure but you can adapt them to your needs. Run ./configure --help for more details about the flags.

$ ./configure --prefix=`pwd`/depends/arm-linux-gnueabihf --with-gui=no --disable-wallet --without-miniupnpc --disable-zmq --enable-reduce-exports
$ make -j4 # takes about 5 minutes

Awesome! Let’s check out our freshly compiled binaries and strip them to save some size.

$ find src -maxdepth 1 -type f -executable
src/bitcoind
src/bitcoin-cli
src/bitcoin-tx

$ find src -maxdepth 1 -type f -executable -exec arm-linux-gnueabihf-strip {} \;

$ find src -maxdepth 1 -type f -executable -exec ls -lh {} \;
-rwxr-xr-x 1 infertux infertux 4.8M Feb 24 22:27 src/bitcoind
-rwxr-xr-x 1 infertux infertux 1.6M Feb 24 22:27 src/bitcoin-cli
-rwxr-xr-x 1 infertux infertux 2.0M Feb 24 22:27 src/bitcoin-tx

$ find src -maxdepth 1 -type f -executable -exec file {} \; | grep -Eo "^([^,]+,){6}"
src/bitcoind: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
src/bitcoin-cli: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
src/bitcoin-tx: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,

The last step is to copy these three files to your ARM machine then run ./bitcoind --help to make sure it works.

Enjoy!

Troubleshooting

Wrong libstdc++ version

After copying my binary to the target machine and running it, I get a message like version `GLIBCXX_3.4.21’ not found (required by ./bitcoind).

$ ./bitcoind --help
./bitcoind: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./bitcoind)

$ strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20

$ ls -l /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 # on target machine (Debian)
lrwxrwxrwx 1 root root     19 Dec 27  2014 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.20

$ ls -l /usr/arm-linux-gnueabihf/lib/libstdc++.so.6 # on host machine (Arch)
lrwxrwxrwx 1 root root 19 Feb 24 21:00 /usr/arm-linux-gnueabihf/lib/libstdc++.so.6 -> libstdc++.so.6.0.21

$ # Dammit, our host machine was using a newer version of libstdc++ than our target machine...
$ # Let's copy the old version to our host machine and recompile Bitcoin with that lib...

$ scp target:/usr/lib/arm-linux-gnueabihf/libstdc++.so.6 /tmp/lib/
$ ./configure ... LDFLAGS=-L/tmp/lib
configure: error: No working boost sleep implementation found.

$ # Using libstdc++.so.6.0.20 seems to be breaking boost sleep implementation for some reason... :/
$ # Let's try something else by copying the newer lib to the target and set LD_LIBRARY_PATH instead

$ scp /usr/arm-linux-gnueabihf/lib/libstdc++.so.6.0.21 target:~/libstdc++.so.6
$ LD_LIBRARY_PATH=. ./bitcoind --version
Bitcoin Core Daemon version v0.12.0

$ # Success!

Announcing Zeyple

Sun, 25 Oct 2015 16:20:20 +0000

What is it?

Zeyple. What’s that? A brand of cereals? A new app for your smartphone? The name of a pizza-making robot?

Well, it’s none of the above. It’s actually the funky name I gave to a project I started several years ago, sometime in 2012 according to the Git history.

It was the pre-Snowden era but I was already worried about blackhats doing MITM attacks onto my WiFi network. One thing which particularly annoyed me was that it was relatively easy for someone to sniff the unencrypted emails I was receiving from various servers I was root on. This made me wonder how you could Encrypt Your Precious Log Emails [1] all the way from the originating server to your inbox.

Obviously, GPG was the answer. But how do you make your server automatically encrypt all outgoing emails sent from a variety of applications? That is exactly what Zeyple does. Assuming you configured Postfix to send your emails, Zeyple acts as a proxy (or filter in Postfix slang) to encrypt emails for the intended recipient(s).

Is it ready?

Today, I’m glad to say the project can be considered stable with release 1.1.0. I got feedback from solo hobbyists to universities using it and this is quite exciting to see that some people do care about encryption and IT security in general. Anyway, if that sounds of interest to you, you’re very welcome to try it out on your own setup. There are a few ways to install it but I haven’t gotten to build official packages for your favorite distribution, yet.

And here’s the README for more information: https://github.com/infertux/zeyple

Footnotes

[1] In case you’re wondering, yes this is where the name Zeyple came from - it’s just a good old recursive acronym like GNU’s Not Unix!

SELinux cheat sheet

Wed, 29 Apr 2015 17:36:22 +0000

SELinux is quite powerful but I never remember how to create a new module off the top of my head so here’s a cheat sheet for it.

First you might want to use audit2allow to help you getting started:

cat /var/log/audit/audit.log | audit2allow -m mymodulelocal > mymodulelocal.te
vim mymodulelocal.te

When you’re happy with the rules in your .te file, it’s time to compile it:

checkmodule -M -m -o mymodulelocal.mod mymodulelocal.te
semodule_package -m mymodulelocal.mod -o mymodulelocal.pp

And finally you can reload your .pp policy file:

semodule -vr mymodulelocal; semodule -vi mymodulelocal.pp

Or as a handy one-liner:

checkmodule -Mmo mymodulelocal.mod mymodulelocal.te && semodule_package -m mymodulelocal.mod -o mymodulelocal.pp && (semodule -vr mymodulelocal || true) && semodule -vi mymodulelocal.pp

ISO 8601 for programmers

Sat, 28 Dec 2013 10:02:16 +0000

As programmers, we all know we should use ISO 8601 to format date and time when represented numerically.

Unfortunately, the POSIX standard does not always provide us with an easy way to use ISO 8601 with strftime. That’s why I’m posting here the right way to do it:

date: %Y-%m-%d or %F for recent implementations (example: 2013-12-31)
time: %H:%M:%S or %T for recent implementations (example: 23:59:59)

How to remove an email address from a GPG key

Sun, 03 Nov 2013 12:15:00 +0000

This is a quick howto to explain how to remove one of the identities of your GPG key. This is particularly useful if this email address is no longer yours for some reason.

Unless you’ve never published your key to a public server (unlikely!), you can’t delete an email address from your GPG key, but you can revoke it.

Here are the few steps you’ll need to take:

Edit your key with gpg --edit-key <KEY_ID>
Select the sub-key to revoke with uid <ID>
Revoke it with revuid
Save your changes with save
Publish your updated key with gpg --send-keys <KEY_ID>

You can also have a look at the example output below to see what is looks like:

$ gpg --edit-key 01234567
pub  2048R/01234567  created: 2010-01-01  expires: 2015-01-01  usage: SCA
                     trust: ultimate      validity: ultimate
sub  2048R/FEDCBA98  created: 2010-01-01  expires: 2015-01-01  usage: E
[ultimate] (1). John Doe <john@doe.tld>
[ultimate] (2)  John Doe (Corp) <john.doe@corp.tld>

gpg> uid 2

pub  2048R/01234567  created: 2010-01-01  expires: 2015-01-01  usage: SCA
                     trust: ultimate      validity: ultimate
sub  2048R/FEDCBA98  created: 2010-01-01  expires: 2015-01-01  usage: E
[ultimate] (1). John Doe <john@doe.tld>
[ultimate] (2)* John Doe (Corp) <john.doe@corp.tld>

gpg> revuid
Really revoke this user ID? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  4 = User ID is no longer valid
  Q = Cancel
(Probably you want to select 4 here)
Your decision? 4
Enter an optional description; end it with an empty line:
>
Reason for revocation: User ID is no longer valid
(No description given)
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "John Doe <john@doe.tld>"
2048-bit RSA key, ID 01234567, created 2010-01-01


pub  2048R/01234567  created: 2010-01-01  expires: 2015-01-01  usage: SCA
                     trust: ultimate      validity: ultimate
sub  2048R/FEDCBA98  created: 2010-01-01  expires: 2015-01-01  usage: E
[ultimate] (1). John Doe <john@doe.tld>
[ revoked] (2)  John Doe (Corp) <john.doe@corp.tld>

gpg> save

$ gpg --send-keys 01234567
gpg: sending key 01234567 to hkp server keys.gnupg.net

$ gpg --list-keys 01234567
pub   2048R/01234567 2010-01-01 [expires: 2015-01-01]
uid                  John Doe <john@doe.tld>
sub   2048R/FEDCBA98 2010-01-01 [expires: 2015-01-01]

Trolling the bots with a teapot

Mon, 01 Apr 2013 23:47:00 +0000

I finally got rid of the superfluous blog/ in the URL having already a blog sub-domain. Of course, I didn’t want to break old links so I added the following line in my nginx config:

rewrite ^/blog(.*)$ $1 permanent;

But as always with nginx, that worked like a charm and was just too easy. So I thought I would troll some nasty crawlers while I was at editing my nginx config.

Even though I don’t use PHP, a lots of bots are spamming my logs with GET /wp-login.php?action=register and so forth.

So from now on, I just tell them I’m a teapot:

location ~ \.(aspx|php|jsp|cgi)$ {
  return 418 "I'm a teapot!";
}

Hopefully, that will make them confused enough to GTFO for good.

PS: I should point out this would not have been possible without that brilliant RFC written exactly fifteen years ago.

Announcing Bashcov 1.0.0

Sat, 16 Mar 2013 15:25:00 +0000

Hey look! There’s a demo: infertux.github.io/bashcov/test_app.

What is it?

I’m a big fan of both Ruby’s SimpleCov and Bash. Bashcov is my dream to have in Bash what SimpleCov is to Ruby.

Oddly enough, I didn’t find any coverage tool for Bash except shcov but as stated there, shcov is:

somewhat simplistic and doesn’t handle all possible cases very well (especially when we’re talking about long and complex lines)

Indeed, it doesn’t work very well for me. I have covered lines marked as uncovered and some files completely missed although executed through another script (via source). Moreover, I’m not sure it is still being actively maintained. This makes me feel like a sad panda :(

Bashcov aims to be a neat and working coverage tool backed by SimpleCov and simplecov-html.

How does it work?

Ruby has a coverage module which computes the coverage on demand. Unfortunately, Bash doesn’t have such niceties but we can use the xtrace feature which prints every line executed using PS4.

After a bit of parsing, it sends results through SimpleCov which generates an awesome HTML report.

And of course, you can take great advantage of SimpleCov by adding a .simplecov file in your project’s root (like this).

Is it ready?

Well, I’ve been working on it for a few months now and it looks stable enough for a 1.0.0 release. There is one glitch I’d like to get rid of but apart from that, it works pretty well for me.

My yardstick is currently RVM because it has a relatively big codebase and extensive tests.

If you have a Bash project and tests for your code, you could give Bashcov a try to see what code you’re actually covering through your testsuite. I’d love to hear your feedback if so!