PAB's blog

Utilisant des machines Debian chez Scaleway, je rencontrai l'avertissement suivant après mise à jour de Debian 12 à Debian 13.

Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://ppa.launchpad.net/scaleway/stable/ubuntu focal InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key 15061C3CA651AD8DF110A37BFEC8C91445F9E441, which is needed to verify signature.
Warning: Failed to fetch http://ppa.launchpad.net/scaleway/stable/ubuntu/dists/focal/InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key 15061C3CA651AD8DF110A37BFEC8C91445F9E441, which is needed to verify signature.
Warning: Some index files failed to download. They have been ignored, or old ones used instead.

Pour régler ce souci, j'identifiai ce dépôt PPA géré par Scaleway : https://launchpad.net/~scaleway/+archive/ubuntu/debian-stable

J'y trouvai l'adresse du dépôt et la clé de signature associée. Pour implémenter cela sur la machine, j'effectuai alors les opérations suivantes :

curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x15061c3ca651ad8df110a37bfec8c91445f9e441"|gpg --dearmor -o /usr/share/keyrings/scaleway.gpg

puis je modifiai le fichier /etc/apt/sources.list.d/scaleway.list avec ce contenu :

deb [signed-by=/usr/share/keyrings/scaleway.gpg] http://ppa.launchpad.net/scaleway/debian-stable/ubuntu jammy main

et le tour était joué !

As I speak, there is no repository for PgAdmin4 targeting Debian 13 Trixie. I have no doubt this will change soon with the official release of Debian Trixie in a few days.

If you are impatient, it is however possible to install PgAdmin4 as a Python library and launch it as a service for easy use.

Here is how you can proceed.

As root or with sudo, create a pgadmin4 folder in /opt and change the owner for non-root user

sudo mkdir /opt/pgadmin4
sudo chown $USER /opt/pgadmin4

Now is time to create the folders needed by pgadmin4 to operate:

sudo mkdir /var/lib/pgadmin
sudo mkdir /var/log/pgadmin
sudo chown $USER /var/lib/pgadmin
sudo chown $USER /var/log/pgadmin

Then it is possible to install pgadmin4 in a virtualenv :

cd /opt/pgadmin4
python3 -m venv pgadmin4
source pgadmin4/bin/activate
pip install pgadmin4

and to launch pgadmin4:

pgadmin4

If it launches well, you can visit http://127.0.0.1:5050/ with your browser to start using pgadmin4.

If you would like pgadmin4 server to start as a service, you can create a pgadmin4.service file in /etc/systemd/system/ with the following content:

[Unit]
Description=Pgadmin4 Service
After=network.target

[Service]
User=pab
Group=pab
WorkingDirectory=/opt/pgadmin4/pgadmin4
Environment="PATH=/opt/pgadmin4/pgadmin4/bin"
ExecStart=/opt/pgadmin4/pgadmin4/bin/pgadmin4
PrivateTmp=true

[Install]
WantedBy=multi-user.target

You can then start and enable it:

systemctl daemon-reload
systemctl start pgadmin4
systemctl enable pgadmin4

If you use the S3-compatible GLACIER storage of Scaleway, you may have wondered how to restore all files from GLACIER to STANDARD to download them. Well, there is no button on the web interface to provoke the restoration of a full bucket and no need to say that clicking on each file is not an option. Contra-intuitively, you should know that the lifecycle rules cannot be used for restoration from GLACIER.

The solution I found is to use the s3cmd tool.

First install it, for example on a Debian-based system with

apt install s3cmd

Then create a .s3cfg file in your home folder with the following (to be adapted to your situation of course):

[default]
host_base = s3.fr-par.scw.cloud
host_bucket = %(bucket).s3.fr-par.scw.cloud
bucket_location = fr-par
use_https = True

access_key = ACCESSKEY
secret_key = SECRETKEY

Now, to list all files in a bucket, you can call:

s3cmd ls -l --recursive s3://my-bucket-name

To count the number of files left in GLACIER, you can do:

s3cmd ls -l --recursive s3://my-bucket-name |grep GLACIER|wc -l

And to request a restoration of all files from GLACIER, here is the way to go:

s3cmd restore -v --recursive s3://my-bucket-name

Of course the restoration is not immediate: in my experience with a 1 Tb bucket with 1200 files, small files were retrieved in a few minutes but big files (> 1 Gb) could take up to several hours.

I've installed the official Linux driver for the Samsung M2020 laser printer. It is well recognized in Cups but impossible to print as I encounter the "filter failed" error message.

In fact it seems that libcupsimage2 lib is missing.

Just do

apt install libcupsimage2

and it should work!

L'application "Talk" de Nextcloud gagne toujours plus en maturité à chaque nouvelle version. Pour en profiter pleinement, il est nécessaire de paramétrer un serveur TURN/STUN dans la page de configuration du module Talk de Nextcloud.

Nous allons voir ici comment installer un serveur TURN/STUN sous Debian Buster.

On commence, sans originalité, par installer le paquet :

apt install coturn

Et on le configure dans /etc/turnserver.conf :

tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=secretkey
realm=turn.monurl.tld
total-quota=100
bps-capacity=0
stale-nonce
cert=/etc/turnserver/cert.pem
pkey=/etc/turnserver/privkey.pem
cipher-list="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
no-loopback-peers
no-multicast-peers

Conformément à ce que nous venons d'écrire dans le fichier de configuration, il faut alors ouvrir le port 5349 de l'éventuel pare-feu, par exemple si on utilise nftables en ajoutant cette ligne dans /etc/nftables.conf :

tcp dport 5349 accept

Il convient également de rendre la clé et le certificat permettant le chiffrement accessibles à l'utilisateur turnserver dans /etc/turnserver/*.pem. Si les certificats ont été obtenus avec letsencrypt, on pourra par exemple effectuer les commandes suivantes :

mkdir /etc/turnserver
cp /etc/letsencrypt/live/turn.monurl.tld/privkey.pem /etc/turnserver/
cp /etc/letsencrypt/live/turn.monurl.tld/cert.pem /etc/turnserver/
chmod a+r /etc/turnserver/privkey.pem
systemctl restart turnserver

Il sera nécessaire de répéter les opérations ci-dessous à chaque mise à jour du certificat et de la clé privée par let's encrypt (ou votre fournisseur de certificat TLS) !

Le serveur TURN/STUN doit alors être fonctionnel !

En déployant Prestashop derrière un proxy qui gérait le chiffrement TLS/SSL, j'ai été confronté à un problème de boucle de redirection qui rendait le magasin en ligne inacessible. Le problème a été réglé en exécutant cette modification sur la base de données :

UPDATE ps_configuration SET value='1' WHERE name='PS_SSL_ENABLED';

Sur une version de Debian Buster fraîchement installée, il était impossible de déployer une instance LXC car aucun template n'était trouvé :

get_template_path: 918 No such file or directory - bad template: debian

Il faut seulement installer les templates de LXC par :

apt install lxc-templates

I share below my configuration of GitLab when served behind a reverse proxy (haproxy to name it) that is handling the HTTPS part of the communication (and is also load balancing). <Disclaimer> I am not claiming this is the best configuration or the only possible configuration but I can report that it works well</Disclaimer>.

Infrastructure

The network transaction is established as follows:

User <- HTTPS HTTP/2 -> HAPROXY <- HTTP -> NGINX <- HTTP -> Unicorn/GitLab

I will not detail here the configuration of HAProxy which is pretty classical.

Configuration of GitLab

In gitlab.yml (presumably in /home/git/gitlab/config/ if you installed from source), I have the following:

production: &base
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: gitlab.domain.tld
    port: 443
    https: true

And yes I indicate https true and port 445 even if Gitlab itself does not handle the https part of the communication.

Configuration of Nginx

In the config of Nginx (another layer of reverse proxy), I have:

    proxy_set_header    X-Forwarded-Proto   https;

which differs from the configuration proposed by the Gitlab team. Indeed, it does not convey the protocol that is seen by Nginx but rather forces the header to https as initially the communication was https-secured.

And it works flawlessly!

Installing LineageOS on a One Plus X E1001 (not E1003, I believe E1001 is an Asian version whereas E1003 was old in Europe) was a bit painful. This article will not repeat all instructions to install LineageOS on One plus X (which can be found here: https://wiki.lineageos.org/devices/onyx/install) but only cover some unexpected behaviors I need to circumvent to install LineageOS.

First no recent (3+) TWRP version was running fine: all refused to boot (fastboot boot path/to/recovery/file.img) with the following error message:

Remote: dtb not found error

I had to use an old TWRP 2.8.7 version to make it work. Here is the version that worked fine for me: twrp-2.8.7.0-6.0-onyx.img.

Then, the LineageOS zip file could not install because of the following error message:

Comparing TZ version TZ.BF.2.0-2.0.0137 to TZ.BF.2.0-2.0.0134
assert failed: oppo.verify_trustzone("TZ.BF.2.0-2.0.0137") == "1"
E:Installation aborted.

To fix this one, I had to first flash the firmware/bootloader with a more recent version. Installing the following file with TWRP did the trick: OPXBLUpdateOOS3.1.zip.

After that, LineageOS (one of the nightly version of May 2018) installed just fine.

I hope this will help some people facing the "dtb not found" and "assert failed: oppo.verify_trustzone" error messages!

Unicorn, the "Rack HTTP server for fast clients", is really for "fast clients". Fast clients mean clients on the same local network (or even same machine) with very low latency and near-zero chance of packets loss. Slow clients are the usual web users: far away from the server. Unicorn has been designed to serve fast clients and if you try to use it to serve slow clients then the performance may be dismal. This is why the Unicorn developers recommend to use Nginx in front of Unicorn. To know more on the Unicorn philosophy, visit this page.

I recently tried to use HAProxy in front of Unicorn and was disappointed to see that:

• the system was slow and unresponsive
• a lot of 502 Gateway errors popped up for seemingly no reason (and this popped up unconsistently)

I came to the conclusion that the default configuration of HAProxy was not appropriate for Unicorn. After some web digging, I discovered the "http-buffer-request" option.

Here is what the HAProxy 1.8 documentation says about the "http-buffer-request" option :

It is sometimes desirable to wait for the body of an HTTP request before taking a decision. This is what is being done by "balance url_param" for example. The first use case is to buffer requests from slow clients before connecting to the server. Another use case consists in taking the routing decision based on the request body's contents. This option placed in a frontend or backend forces the HTTP processing to wait until either the wholebody is received, or the request buffer is full, or the first chunk is complete in case of chunked encoding. It can have undesired side effects with some applications abusing HTTP by expecting unbuffered transmissions between the frontend and the backend, so this should definitely not be used by default.

It seems to be the best fit with Unicorn's philosophy! Let's activate the option in each backend corresponding to a Unicorn-run application:

backend unicorn-app
	option http-buffer-request
	server unicorn-app 1.2.3.4:3000

and restart HAProxy:

/etc/init.d/haproxy reload