Create an encrypted /home partition

In my previous Artix post I mentioned that I had trouble creating an encrypted /home partition during installation. I could do that, but then the system wouldn’t boot. So I went for a quite basic installation and set up things afterwards, among others the encrypted home partition.

Although at installation stage I already created an empty partition which should later be used for /home, in my case that was /dev/sda3.

So given you have an empty partition /dev/sda3 which you want to use for you /home: First set it up for encryption: (you might have to install cryptsetup first)

cryptsetup -y -v luksFormat /dev/sda3

Open the encrypted partition and create a file system:

cryptsetup luksOpen /dev/sda3 home

# Check if that worked, you should see a 'home' entry there:
ls -lh /dev/mapper/

# create file system:
mkfs.ext4 -m 1 /dev/mapper/home

# close the device again:
cryptsetup close home

Add entry to crypttab:

echo "home	/dev/sda3	none	luks" >> /etc/crypttab

Create a temporary mount directory and fstab entry to test if you can mount the partition at boot time.

mkdir /mnt/tmp

echo "/dev/mapper/home	/mnt/tmp	ext4	defaults,noatime	0	1" >> /etc/fstab

Reboot. You should be asked about your encryption credentials. When the system has booted up again, you should see it mounted as /mnt/tmp.

If that worked, then copy your old /home over to the encrypted partition:

cp -a /home/* /mnt/tmp/

# double check again if everything is ok, then
rm -rf /home/*

Finally adjust the fstab accordingly:

/dev/mapper/home	/home	ext4	defaults,noatime	0	1

Reboot.

Tip

If you haven’t dedicated a whole partition for this purpose and/or you just want to have an additional encrypted device, then you can simple use a file instead of a parition for that. For example you want something like /home/user/encrypted as place for sensitive data, not a whole parition.

Then you could do:

mkdir /home/user/encrypted

# create an empty 25GB file (take care of this file, it will
# hold all the encrypted data, do not delete accidentaly!)
dd if=/dev/zero of=/home/user/encrypted.luks bs=1G count=25

cryptsetup -y -v luksFormat /home/user/encrypted.luks

cryptsetup luksOpen /home/user/encrypted.luks encrypted

mkfs.ext4 -m 1 /dev/mapper/encrypted

cryptsetup close encrypted

echo "encrypted	/home/user/encrypted.luks	none	luks" >> /etc/crypttab

echo "/dev/mapper/encrypted	/home/user/encrypted	ext4	defaults,noatime	0	1" >> /etc/fstab

Manage a blog with Gitlab

Thought it’s actually time to write something about how this blog is built. All posts are written in Markdown language, which is then transformed by Jekyll into plain static HTML.

The Jekyll files and posts are all in a (private) Gitlab repository. Before I write a new entry I create a new branch, then commit the new post and changes to the branch. When I’m finished I create a ‘Merge request’ and merge it. The merge then triggers a pipeline job which builts the actual website using Jekyll. This is done by a .gitlab-ci.yml file in the root directory of the repository:

image: ruby:2.3

variables:
  JEKYLL_ENV: production

before_script:
- bundle install

buildSite:
  stage: build
  script:
  - ./createTagPages.sh
  - bundle exec jekyll build -d _site
  artifacts:
    paths:
    - _site
  only:
  - master
  after_script:
    - 'curl https://floki.cc/<SOME_IDENTIFIER>/deploy/$CI_JOB_ID'

It’s probably time to update this file at some point…

Anyway, what it does is: It uses the ruby docker image (Jekyll is written in Ruby). Installs Jekyll and the dependencies (which are specified in a ‘Gemfile’, see at the bottom of the page). Then calls Jekyll to build the website in the _site directory. Ignore the ./createTagPages.sh for now, this only - surprise - updates the tags which you see on the left hand side of the page. When Jekyll’s done, the _site directory is used as ‘artifact’ of the build, i. e. a zip file which contains the built website is created. When the build is finished I just ‘ping’ the webserver hosting it on a specific URL passing on the ID of the build job.

A script on the webserver runs periodically and checks for this call in the nginx logs and if it’s found, it will get the artifact from gitlab and deploy the new website:

#!/bin/bash

deployedId=`cat /var/www/version`

tmp=`cat /var/log/nginx/access.log | awk '/<SOME_IDENTIFIER>\/deploy/ {print $7}'`
jobId=${tmp##*/}
if [[ -n "$jobId" && "$jobId" != "$deployedId" ]]
then
	cd /tmp
	curl -L --header "PRIVATE-TOKEN: <GITLAB_TOKEN>" https://gitlab.com/api/v4/projects/<PROJECT_ID>/jobs/$jobId/artifacts >> artifacts.zip
	unzip artifacts.zip

	cd _site
	chown -R www-data:www-data *
	cp -r * /var/www/html/

	cd ..
	rm -rf _site artifacts.zip

	echo $jobId > /var/www/version

	dt=`date`
	echo "$dt - Deployed $jobId" >> /var/log/blog.log
fi

Finally the Gemfile for the Jekyll installation:

source "https://rubygems.org"

gem "jekyll", "~> 3.8.3"

group :jekyll_plugins do
  gem 'jekyll-paginate'
  gem 'jekyll-sitemap'
  gem 'kramdown'
  gem 'rouge'
end

/var/backups/alternatives.tar.0

A few days ago my Raspberry Pi “died”, which was pretty annoying because I just wanted to watch a movie which is on the NFS drive (served by this Raspberry Pi)… Tried to boot it up again, no success, just hangs at some random boot state. So investigated the SD-card. Turned out that a file /var/backups/alternatives.tar.0 filled up all the disk space! WTF!? Usually root has a few percentage reserved disk space (by default 5%) to prevent the system to “die” if it runs out of space. But as the process creating this altneratives.tar.0 file was run by root, it just carried on writing to the disk until everything died, great.

Fix:

# Mount second partition of the SD card 
# on another machine, e.g. /tmp/mnt

# Delete everything under /var/backups
rm -rf /tmp/mnt/var/backups/*

To prevent this from happening again:

# Delete dpkg cron job (which I suspect creates these files)
rm /tmp/mnt/etc/cron.daily/dpkg