blog.crox.net

Add this line to /etc/apt/sources.list:

deb http://deb.debian.org/debian bookworm-backports main

Run:

# apt-get update
# apt install -t bookworm-backports libheif1

This solves the issues encountered when decoding HEIF (.heic) files produced by iPhone / iOS 18, causing for instance rendering in Nextcloud to fail.

This page has more details on using Backports.

I'm trying out the "Nextcloud Office" app together with "Collabora Online - Built-in CODE Server". That Nextcloud instance is behind a reverse proxy.

The problem I encountered was that regardless of the 'overwritehost' and 'overwriteprotocol' settings, the WOPI URL kept being automatically changed from https to http.

From other posts regarding similar issues I figured out that the WOPI URL is obtained by querying https://[yourinstance]/apps/richdocumentscode/proxy.php?req=/hosting/discovery

Looking at the proxy.php source code, I found the reason for the issue:

// URL into this server of the proxy script.
if ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off')
        || (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' )
        || (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on')
) { 
    $proxyURL = "https://";
} else {
    $proxyURL = "http://";
}

I then modified my reverse proxy (Apache) config to add the missing header:

RequestHeader set X-Forwarded-Proto "https"

Now everything works as expected

Everything you need in this excellent article: https://alexskra.com/blog/ubuntu-20-04-with-software-raid1-and-uefi/.

And many other things: https://webhook.site/.

I run a BackupPC instance that is still on Debian 10 / buster. The latest rsync package for Debian 10 has version number 3.1.3-6.

I recently noticed infrequent issues when backing up hosts that are either on Debian 11 / bullseye, or on Ubuntu 22.04 (which both ship rsync 3.2.3). The symptoms are as follows:

- backups take much longer than usual
- XferLog.z starts "normally", but after a certain point contains a lot of binary garbage, and gets much bigger than usual (hundreds of MB, or even in one case up to 12 GB)

After investigating and looking for information online, I came across these bug reports, which contain the explanation as well as a workaround: Debian Bug report #969463 and BackupPC issue #369.

=> The issue is caused by a combination of a change of default behaviour introduced with rsync 3.2.3, and a bug in File::RsyncP.

The solution that works for me (pending an update to Debian 11 and BackupPC 4) is to add the following line in the individual server config for each of the affected hosts:

$Conf{RsyncArgsExtra} = ['--no-msgs2stderr'];