Tag: notes - blog.dotcs.me

Copy large files to Nextcloud

2021-01-02T16:49:22+01:00

I'm running my own Nextcloud instance in a docker container with the data directory mounted from a local folder on my disk. Unfortuantely it's not very satisfying to use the web UI or using a davfs2 mount of the disk to copy large files to the Nextcloud instance. This is because files must be passed through the full LAMP stack which involves a lot overhead and slows down any large file uploads.

An alternative to upload files via the browser or WebDAV is to copy them directly into the user data folder and then force Nextcloud to sync the content with its internal file cache and database entries.

Say our Nextcloud instance data lives in /opt/nextcloud/data and our source files live in /tmp/stage on the server. Further let the Nextcloud username be my-user and say the source data should be copied to ~/my-folder in Nextcloud.

Copying the data would then look like this:

# copy files
rsync -avP /tmp/stage/ /opt/nextcloud/data/my-user/files/my-folder/
# fix permissions
chmod www-data:www-data /opt/nextcloud/data/my-user/files/my-folder

It's necessary to fix the permissions since the default user in the official Nextcloud docker images is the www-data user. See also the Nextcloud documentation. Details:

$ docker-compose exec nextcloud id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

After the files have been copied, Nextcloud must be forced to re-index all files within this directory:

$ docker-compose exec -u www-data nextcloud ./occ files:scan --path="/my-user/files/my-folder"
Starting scan for user 1 out of 1 (my-user)
+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 6       | 354   | 00:00:01     |
+---------+-------+--------------+

The internal database and caches have been updated and your files will pop up in the web UI afterwards.

Pi-hole User Group Management

2020-11-18T08:10:34+01:00

At home I have a Pi-hole in service which acts as my central DNS provider for all devices in my network. This means that by default all devices share the same filter lists, so effectively ads are blocked on all devices.

This setup is most likely the setup most people need and prefer. For our home it's not working, because some devices should see clear and unfiltered DNS entries. Let's see how we can exclude certain devices from the filter lists.

# Pi-hole Group Management

Since Pi-hole v5.0, which has been released in 2020-05, groups can be configured. Known devices can be put into groups which can have different filter lists assigned to them. The group management can be found under http(s)://my-pi.hole/admin/groups.php.

In my setup I created a group for all my devices which I named dotcs.

Pi-hole Admin: Group management

By default this group does nothing. First devices need to be assigned to the group. Those settings can be found under http(s)://my-pi.hole/admin/groups-clients.php.

Pi-hole Admin: Device management

After that the adlists need to be configured and attached to the group. In my case I removed all of the lists from the default group and attached them only to the dotcs group.

Pi-hole Admin: Adlist management

With this configuration all devices listed in the dotcs group see filtered DNS entries whereas all other devices see unfiltered DNS entries.

Thanks to the Pi-hole developers for this awesome feature and please consider donating to the project if you like it.

How to deploy a Next.js application to GitHub pages

2020-11-16T22:56:02+01:00

Next.js is becoming very popular - for good reasons. To me it's one of the best frameworks out there to create all kinds of web pages that are based on React. Since Next.js does allow for full server-side rendering and static html exports, pages can be rendered completely on the server and delivered to the client as dump static HTML pages with a little bit of CSS and JavaScript where needed. This makes them perfectly suitable to be hosted on GitHub pages.

My first thought was: Yeah, easy let's do this quickly. But not so fast! I've leared that there are a few things that require tweaks.

# Use GitHub Actions to build and export Next.js pages

I use GitHub actions to build the static pages. The corresponding project setting is set to deliver pages from the gh-pages branch.

GitHub Pages settings to deliver from branch gh-pages

The corresponding .github/workflows/gh-pages.yml is simple. Note that the npm run export script has an enviroment variable DEPLOY_TARGET: gh-pages attached to it. This env variable will be used in the second step. In the deploy step the branch is set to gh-pages and we deliver results from the out folder, which is the default target folder for the next export command.

Also note that the pipelie creates the (empty) file out/.nojekyll. This is necessary to bypass Jekyll processing on GitHub pages as mentioned here. Otherwise folders that start with an underscore are ignored, but Next.js puts merged assets, e.g. CSS and JS files, into a folder _next. 😵

name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2.3.1
        with:
          persist-credentials: false

      - name: Install and Build
        uses: actions/setup-node@v1
      - run: npm install
      - run: npm run build     # runs `next build`
      - run: npm run export    # runs `next export`
        env:
          CI: true
          DEPLOY_TARGET: gh-pages
      - run: touch out/.nojekyll

      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@3.7.1
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages  # The branch the action should deploy to.
          FOLDER: out       # The folder the action should deploy.
          CLEAN: true       # Automatically remove deleted files from the deploy branch

# Rewrite paths to static files

When serving websites via <username>.github.io any static assets must point to <username>.github.io/<projectname> with <projectname> being the name of the repository (typically again <username>.github.io). GitHub Pages rewrites some paths internally, so that they appear to come from <username>.github.io, but things will not work out if the <projectname> part is missing.

next export allows to set a assetPrefix, which tweaking the URL paths and re-write them from / to /<assetPrefix>/. This can be configured in the project's next.config.js:

const ghPages = process.env.DEPLOY_TARGET === 'gh-pages';

module.exports = {
  assetPrefix: ghPages ? '/dotcs.github.io/' : ''   // customize this value
};

With this line in place we detect if we're executed by the GitHub Action runner and re-write paths accordingly.

# Success

With those tweaks Next.js pages can be hosted via GitHub pages easily. You just need to be aware of them. 😉

Migrate from i3 to sway

2020-11-15T09:52:00Z

I recently changed from the Linux display server protocol X.org Server to Wayland on one of my machines. My favorite window manager i3 is not compatible with Wayland though, so I had to search for an alternative. Luckily there is a drop-in replacement for i3 available which is named Sway.

Sway is very similar to i3, it even uses the same syntax for the config, so the change required only a few tweaks which I will now talk about. I can also recommend to read the Sway article on the Arch Wiki.

At this let's take a brief moment to say "Thank you" to all contributors of Sway and Wayland and maintainers of the corresponding packages in the various distros out there. ♥

# Installation

Installation of sway under Arch Linux is easy. It's as simple as:

yay -S sway

# Copy configuration

Sway searches it's configuration in ~/.config/sway/config so I copied my i3 config there. All changes go into this config file.

# Adjust configuration

After the configuration has been copied use a separate TTY to try our sway and its configuration. Remember that <SUPER> + SHIFT + c does reload your configuration which is quite handy for trying things out. Also swaymsg can be used to send messages to sway, so for example the following command would set the scaling 2 for all output devices.

swaymsg output "*" scale 2

# Screen output resolution

I'm working with a HiDPI screen which was detected correctly in Sway. But I found the scaling factor of 2, which is the default in HiDPI screens, too much. Although it's not recommended to use float values here, I found a scaling factor of 1.3 to fit my needs, so I added this line to my config:

# Screen scaling (default is 2)
output eDP-1 scale 1.3

To list connected displays use swaymsg -t get_outputs which in my case now (after the change) shows as:

$ swaymsg -t get_outputs   
Output eDP-1 'Apple Computer Inc Color LCD 0x00000000' (focused)
  Current mode: 2560x1600 @ 59.972000 Hz
  Position: 0,0
  Scale factor: 1.300000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 4
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    2560x1600 @ 59.972000 Hz

# Background images with automatic rotation

I like to have randomly chosen background images that change every now and then. Sway makes it easy to implement this. I added the following line to my config which executes a script during start.

exec --no-startup-id ~/.local/scripts/sway-rotate-bg-image.sh

The script itself doesn't do much. It lists all files in a certain folder, shuffles the names and selects one of them. It updates the background on all attached displays image via swaymsg and then pauses for 300 seconds (=5min) before the next iteration.

#!/usr/bin/env bash
IMG_DIR=~/wallpapers
while true;
do
    IMG=`ls -t1 $IMG_DIR/* | shuf | head -n 1`
    swaymsg output "*" bg $IMG fill; sleep 300
done

# Detect idle state and lock screen

To automatically lock the screen there are luckily two programs available that do the heavy-lifting. They are called swayidle and swaylock and can be installed in Arch via:

yay -S swayidle swaylock

The following script is taken from the swayidle manpage:

This will lock your screen after 300 seconds of inactivity, then turn off your displays after another 300 seconds, and turn your screens back on when resumed. It will also lock your screen before your computer goes to sleep.

To make sure swayidle waits for swaylock to lock the screen before it releases the inhibition lock, the -w options is used in swayidle, and -f in swaylock.

exec --no-startup-id swayidle -w \
    timeout 300 'swaylock -f -c 000000' \
    timeout 600 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"' \
    before-sleep 'swaylock -f -c 000000'

# Screen backlight keys

In my i3 setup I used xbacklight to change the backlight of my screen.

bindsym XF86MonBrightnessUp exec xbacklight +10
bindsym XF86MonBrightnessDown exec xbacklight -10

This of course won't work anymore in Wayland, so I replaced the old configuration with brightnessctl which needs to be installed first:

yay -S brightnessctl

The syntax of brightnessctrl differs slightly:

bindsym XF86MonBrightnessDown exec brightnessctl set 5%-
bindsym XF86MonBrightnessUp exec brightnessctl set +5%

# Keyboard bindings

For me one key on the keyboard is completely superfluous: capslock. In my systems I either deactivate this key or map it to ESC if possible. Having ESC closer to the home row is benefitial to me - especially when working a lot with vim. This can done with xkb_options.

Another interesting setting is the key repeat delay and rate, which can be tuned also quite easily.

input "type:keyboard" {
    # Capslock key should work as escape key
    xkb_options caps:escape

    repeat_delay 350
    repeat_rate 45
}

# SSH Agent

To automatically start the SSH agent I use a systemd service which is placed in ~/.config/systemd/user/ssh-agent.service:

[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
# DISPLAY required for ssh-askpass to work
Environment=DISPLAY=:0
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Also configure the pam environment in ~/.pam_environment:

SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Then start the service and enable it for future system starts: systemctl --user enable --now ssh-agent.service.

# Exit script

Finally I updated my exit script that allows me to lock my screen, suspend, shutdown or reboot my machine, etc.

The Sway configuration looks as this

set $mode_system System (1) lock, (e) logout, (s) suspend, (h) hibernate, (r) reboot, (d) shutdown
mode "$mode_system" {
    bindsym l exec --no-startup-id ~/.local/scripts/sway-exit.sh lock, mode "default"
    bindsym e exec --no-startup-id ~/.local/scripts/sway-exit.sh logout, mode "default"
    bindsym s exec --no-startup-id ~/.local/scripts/sway-exit.sh suspend, mode "default"
    bindsym h exec --no-startup-id ~/.local/scripts/sway-exit.sh hibernate, mode "default"
    bindsym r exec --no-startup-id ~/.local/scripts/sway-exit.sh reboot, mode "default"
    bindsym d exec --no-startup-id ~/.local/scripts/sway-exit.sh shutdown, mode "default"
    # back to normal: Enter or Escape
    bindsym Return mode "default"
    bindsym Escape mode "default"
}

which utilizes the script located in ~/.local/scripts/sway-exit.sh

#!/bin/sh
lock() {
    swaylock -f -c 000000
}

case "$1" in
    lock)
        lock
        ;;
    logout)
        swaymsg exit
        ;;
    suspend)
        lock && systemctl suspend
        ;;
    hibernate)
        lock && systemctl hibernate
        ;;
    reboot)
        systemctl reboot
        ;;
    shutdown)
        systemctl poweroff
        ;;
    *)
        echo "Usage: $0 {lock|logout|suspend|hibernate|reboot|shutdown}"
        exit 2
esac

exit 0

# Notifications

In i3 I used dunst to handle notifications. Unfortunately it's not yet ready to work with wayland. I found mako to be a good replacement.
Using mako is dead simple. After installation an additional line exec mako in the sway config file does the job.

# Printer

CUPS was not properly started after the switch. What helped was to create the following configuration in /etc/systemd/system/cups.socket:

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=0.0.0.0:631
ListenDatagram=0.0.0.0:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=multi-user.target

Then enable/start the service with systemctl enable --now cups.service and make sure it started properly:

$ systemctl status cups.service
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-11-28 21:21:45 CET; 4min 31s ago
TriggeredBy: ● cups.socket
             ● cups.path
       Docs: man:cupsd(8)
   Main PID: 55543 (cupsd)
     Status: "Scheduler is running..."
      Tasks: 1 (limit: 19070)
     Memory: 5.2M
     CGroup: /system.slice/cups.service
             └─55543 /usr/bin/cupsd -l

Nov 28 21:21:45 mali systemd[1]: Starting CUPS Scheduler...
Nov 28 21:21:45 mali systemd[1]: Started CUPS Scheduler.

Automate tasks with docker-compose and systemd

2020-05-22T15:57:00Z

I have several tasks encapsulated in Docker containers which I need to trigger on a regular basis. The scheduling can be done with systemd. Both tools together have proven to be a quite powerful combination.

# Example: Backup service

Let's assume we have a backup service that lives in /opt/backup. This folder contains a docker-compose.yaml file which contains the configuration of a backup service.

We need one systemd unit for the service and one for the timer. Both are shown below. The setup is pretty straight forward.

# /etc/systemd/system/backup.service
[Unit]
Description=Backup service
Requires=docker.service
After=docker.service

# Send mail in case of an error
OnFailure=status-email-user@%n.service

[Service]
WorkingDirectory=/opt/backup

ExecStart=/usr/local/bin/docker-compose up

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/backup.timer
[Unit]
Description=Timer for backup service
Requires=backup.service

[Timer]
Unit=backup.service

# Time to wait after booting before we run first time
OnBootSec=10min

# Define a calendar event (see `man systemd.time`)
OnCalendar=*-*-* 03:00:00 Europe/Berlin

[Install]
WantedBy=multi-user.target

The service unit has a OnFailure hook which runs a separate systemd service in case the exit code of the service is non-zero. This idea comes from the Arch Wiki.
The status email service can be configured in a generic way such that it can be re-used in other systemd services as well.

# /etc/systemd/system/status-email-user@.service
[Unit]
Description=Status Email for %i to user

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email email@example.com %i
User=nobody
Group=systemd-journal

/usr/local/bin/systemd-email:

#!/bin/sh

/usr/bin/mail -Ssendwait -t <<ERRMAIL
To: $1
From: Monitor (systemd) <alert@example.tld>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL

Finally the timer needs to be started/enabled as usual:

systemctl start backup.timer
systemctl enable backup.timer

# Show logs

Logs can be read with journalctl:

journalctl -b -u backup.service

Webcam Support in Arch Linux on Macbooks

2020-04-01T18:07:00Z

I'm running Manjaro Linux (an Arch Linux derivative) on my MacbookPro12,1 (Retina, 13-inch, Early 2015).

Image source: support.apple.com, 2020/04/01

I was astonished how many things just worked out-of-the-box. Kudos to the Arch and Manjaro teams for their great work!

Unfortunately one thing that did not work out-of-the-box is the webcam. It requires a driver that is not part of the official kernel but must be installed separately.
The code is in the Arch User Repository (AUR). I use yay to install packages from AUR which I can highly recommend and which I will use in this article.

Let's get our hands dirty!

First let's get information about all installed kernels and see if the headers are installed for all of them:

$ pacman -Q | grep -E 'linux[0-9]+'  # see which kernels are installed

For each installed linux kernel there should be a -headers file next to it, e.g.

linux419 4.19.113-1
linux419-headers 4.19.113-1
linux54 5.4.28-1
linux54-headers 5.4.28-1
linux55 5.5.13-1
linux55-headers 5.5.13-1

If the headers are missing, make sure to install them:

$ yay -S linux-headers   # select the headers that are missing

Then let's get the driver and install it from AUR:

$ yay -S bcwc-pcie-git

After the installation we need to load the kernel module:

$ modprobe facetimehd

You can test if the video source has been identified correctly by executing v4l2-ctl --list-devices. If everything worked out, the output should be:

Apple Facetime HD (PCI:0000:02:00.0):
	/dev/video0

If the output is instead No /dev/video0 device, then make sure to unload the kernel module bdc_pci as described in the wiki. This can be done by running the following commands:

modprobe -r facetimehd  # temporary remove facetimehd module
modprobe -r bdc_pci     # remove disturbing kernel module

# make sure that the disturbing kernel module is blacklisted
# and cannot be loaded as a dependency of another module.
echo "blacklist bdc_pci\ninstall bdc_pci /bin/false" > /etc/modprobe.d/bcwc-pcie.conf

modprobe facetimehd     # load the facetimehd module again

The webcam should work now. You can test it on any website that requires a webcam, such as meet.jit.si. Have fun!

OfflineIMAP + systemd timer

2020-04-01T14:38:00Z

I use mutt to manage my emails and access them from the terminal. To sync the mails between the IMAP server and mutt I use OfflineIMAP.

To regularly check for new mails I use a systemd timer. The necessary files can be found in the official repository.

Let's clone the repository first and copy all necessary files to /etc/systemd/user.

cd /tmp
git clone --depth 1 git@github.com:OfflineIMAP/offlineimap.git  # a shallow copy is enough
cd offlineimap/contrib/systemd
sudo cp *.{service,timer} /etc/systemd/user/
systemctl --user daemon-reload
cd /tmp && rm -rf /tmp/offlineimap

By default the update interval of the timer is set to 15min. I preferred an update interval of 5 min, which can be easily accomplished.

$ systemctl --user edit offlineimap-oneshot.timer

In this file values can be overwritten as such:

[Timer]
OnUnitInactiveSec=5min

Finally it's time to enable and start the timer.

$ systemctl --user enable offlineimap-oneshot.timer # autostart at boot
$ systemctl --user start offlineimap-oneshot.timer  # start now

Let's check if the timer is up and running. systemctl --user status offlineimap-oneshot.timer should show that it is up and running and tell how many time is left until the next run:

● offlineimap-oneshot.timer - Offlineimap Query Timer
     Loaded: loaded (/usr/lib/systemd/user/offlineimap-oneshot.timer; enabled; vendor preset: enabled)
    Drop-In: /home/dotcs/.config/systemd/user/offlineimap-oneshot.timer.d
             └─override.conf
     Active: active (waiting) since Wed 2020-04-01 16:27:20 CEST; 8min ago
    Trigger: Wed 2020-04-01 16:37:34 CEST; 1min 55s left
   Triggers: ● offlineimap-oneshot.service

i3 + termite + custom themes = <3

2020-04-01T09:36:00Z

I love the sun – especially in Spring when temperatures are not too hot and taking a sunbath is a real pleasure. And I love working in the sun, which is often a challenge because of the poor contrast - especially if, like me, you like to use dark themes.

Since I recently changed to i3 as my window manager, I use termite as my default terminal which has by default no simple way to switch themes – at least not to my knowledge. But working in the sun requires a light theme, so I decided to work on a simple theme changer that is also integrated in i3.

So let's get to work.

First we need custom color themes. I have taken the two themes from this GitHub repository and put them in ~/.config/termite/themes. Of course you can also define custom themes and put them there. The theme files should have the following format:

[colors]
foreground = #000000
background = #ffffff
# and so on

Then copy your current ~/.config/termite/config to ~/.config/termite/config.base and remove the colors section.

We will now need a way to append a theme file to the config.base file. I've created a simple script that does this job:

#!/usr/bin/env bash

USAGE="$0 light|dark"

TERMITE_CONF_FOLDER=~/.config/termite
THEME=$1

change_theme() {
    echo "# THIS FILE HAS BEEN AUTOGENERATED. DO NOT CHANGE MANUALLY!" | \
        cat - /tmp/termite-switch-theme.hint $TERMITE_CONF_FOLDER/config.base $TERMITE_CONF_FOLDER/themes/$1 > $TERMITE_CONF_FOLDER/config
    killall -USR1 termite || true
}

case $THEME in
    light|solarized-light) change_theme solarized-light ;;
    dark|solarized-dark) change_theme solarized-dark ;;
    *) echo $USAGE ;;
esac

Put this script somewhere and make it executable. In my case I've saved the file in ~/.local/scripts/termite-switch-theme.sh. You should be able to switch themes now by calling the script, e.g. ~/.local/scripts/termite-switch-theme.sh light.

This is already great, but for a perfect integration with i3 put these lines into your ~/.config/i3/config:

set $mode_term_theme Terminal theme (l) light, (d) dark
mode "$mode_term_theme" {
    # choose which theme should be applied by pressing l (light) or d (dark)
    bindsym l exec --no-startup-id "~/.local/scripts/termite-switch-theme.sh light", mode "default"
    bindsym d exec --no-startup-id "~/.local/scripts/termite-switch-theme.sh dark", mode "default"
    # back to normal: Enter or Escape
    bindsym Return mode "default"
    bindsym Escape mode "default"
}
bindsym $mod+t mode "$mode_term_theme"

Finally reload the i3 config with mod+shift+c. Now you can change themes with mod+t and choose which theme should be applied (light or dark). All running terminals will immediately reflect your theme changes. Have fun!

# Base16 Themes

If you want to have even more themes to choose from take a look at the wonderful repository khamer/base16-termite. Those themes are working out-of-the-box just as described above.

# Acknowledgements

Thanks to @BarbUk for helping me find the correct signal to send to running termite instances.
Thanks to @nils-braun for reviewing this article.

Spotify Desktop App with HiDPI Scaling in GNOME 3

2019-11-12T16:45:00Z

When using a HiDPI screen, such as the MacBook Pro with Retina display, Spotify Desktop may not automatically detect the correct scaling factor. I have noticed issues in my Manjaro installation that runs with GNOME 3 Desktop. Spotify has been installed from the AUR package repository.
The wrong scaling factor leads to very small font size that is hard to read.

$ spotify --version
Spotify version 1.1.10.546.ge08ef575, Copyright (c) 2019, Spotify Ltd

Fortunately there is an option to force Spotify Desktop to use a (hardcoded) scaling factor. Use the following command and vary the scaling factor in order to find the correct factor first:

$ spotify --force-device-scale-factor=2

After the correct value has been found, adjust the desktop entry that GNOME uses to when starting the application via its launcher. The file lives in /usr/share/applications/spotify.desktop:

[Desktop Entry]
Type=Application
Name=Spotify
GenericName=Music Player
Icon=spotify-client
TryExec=spotify
Exec=spotify --force-device-scale-factor=2 %U
Terminal=false
MimeType=x-scheme-handler/spotify;
Categories=Audio;Music;Player;AudioVideo;
StartupWMClass=spotify

An "open" command in Linux

2019-11-11T21:03:00Z

As a previous macOS user I am used to call open <anything> in a terminal to open the current file or folder with the standard tool. So open . would open the current folder while open file.pdf would open the PDF in the default PDF viewer.

Today I learned that xdg-open serves the same purpose on the Linux desktop. So I configured an alias, to have the same behavior on both systems:

alias open="xdg-open &>/dev/null"

# Query and set defaults

xdg-open is part of xdg-utils, which describes itself as

xdg-utils is a set of tools that allows applications to easily integrate with the desktop environment of the user, regardless of the specific desktop environment that the user runs.

It's super convenient to change the default application for a given file, say a PDF. Let's change the default program:

First let's assume we don't know the mime-type of the PDF, which is application/pdf. We can find this type by query all known filetypes:

$ xdg-mime query filetype /path/to/a/file.pdf 
application/pdf

Let's see which default application is currently configured for this filetype:

$ xdg-mime query default application/pdf
chromium.desktop

If we don't want to use chromium to read PDFs, but for example zathura we can change the default application as follows:

$ find /usr/share/applications/ -name '*zathura*'
/usr/share/applications/org.pwmt.zathura-pdf-mupdf.desktop
/usr/share/applications/org.pwmt.zathura.desktop

$ xdg-mime default org.pwmt.zathura.desktop application/pdf

$ xdg-mime query default application/pdf
org.pwmt.zathura.desktop

Now PDF files are opened with zathura when using our new open command as defined above.

A lot programs bring their own .desktop file(s). Files are listed in /usr/share/appliations and can be overridden or suplemented with files located in ~/.local/share/applications. The specification of those files can be found here.

GNOME 3: Change wallpaper periodically

2019-11-10T18:52:00Z

If you are using GNOME 3 and you want to periodically change your desktop background using images in a folder, this is for you.

Put this script somewhere and make it executable.

#!/usr/bin/env bash

# You need to adjust this path
WALLPAPER_FOLDER=/path/to/your/wallpaper/folder

# https://askubuntu.com/a/1073769/277761
PID=$(pgrep gnome-session | tail -n1)
export DBUS_SESSION_BUS_ADDRESS=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$PID/environ|cut -d= -f2-)

FILE_PATH=`ls $WALLPAPER_FOLDER | shuf -n 1`
FILE_URI="file://$WALLPAPER_FOLDER/$FILE_PATH"
/usr/bin/gsettings set org.gnome.desktop.background picture-uri $FILE_URI

Then create a cronjob that executes this script periodically, e.g. by using this line:

*/10 * * * * /path/to/your/file.sh

And you're done. Have fun!