If you have several abandoned multipart uploads in a S3 bucket that you want to remove, here is a script using awscli that does the job:

#!/bin/bash
BUCKETNAME=my-bucket-name
aws s3api list-multipart-uploads --bucket $BUCKETNAME \
| jq -r '.Uploads[] | "--key \"\(.Key)\" --upload-id \(.UploadId)"' \
| while read -r line; do
    echo "aws s3api abort-multipart-upload --bucket $BUCKETNAME $line";
    eval "aws s3api abort-multipart-upload --bucket $BUCKETNAME $line";
done

 

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.

If you want to add fonts to Collabora CODE (for example used in Nextcloud), you can do the following:

• add your fonts (e.g. .ttf files) to /opt/cool/systemplate/usr/share/fonts/truetype
• re-run the generation fo the template with the command

coolconfig update-system-template

• restart coolwsd

systemctl restart coolwsd.service

And this it, the new fonts shall be available for use!

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!

When I upgraded to Debian 11 Bullseye (from Debian 10 Buster) on my laptop, I ended up after reboot on a black console screen. After a few seconds of disarray, I assumed the new configuration was lacking a proper Display Manager. And indeed, for a reason I ignore, the display manager was somehow removed when executing "apt autoremove" after the upgrade. I don't know why it was flagged as a useless package.

To fix this, I just re-installed a display manager, for example lightdm.

apt install lightdm

Then reboot et everything was back to normal! Enjoy Debian 11 Bullseye and thank you to all those making it possible!

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 !

À l'achat d'un nouvel ordinateur, tous les utilisateurs de Linux s'interrogent sur le support complet de la machine qu'ils visent par leur distribution préférée. Je n'échappe pas à ce questionnement (fort légitime). Je partage donc ici mon retour d'expérience sur l'installation de Debian Buster sur un ordinateur Asus Zenbook UX331.

Tout fonctionne parfaitement pendant et après l'installation sauf le Wifi qui nécessite un firmware non libre non disponible dans l'installateur. Il est toutefois possible de fournir à l'installateur le firmware à l'aide périphérique amovible avec le fichier en cours d'installation ou bien il faut installer avec un adaptateur Ethernet <-> USB reconnu par Linux.

Principaux points :

• affichage : écran parfaitement reconnu, la luminosité est correctement contrôlée par les touches ad-hoc du clavier
• son : parfaitement reconnu, en revanche les touches "volume +" et "volume -" du clavier ne fonctionnent pas
• rétro-éclairage du clavier : totalement fonctionnel et réglable avec les touches du clavier
• wifi : pleinement fonctionnel après installation du package "firmware-misc-nonfree"
• touchpad : pleinement fonctionnel sauf la touche de désactivation du touchpad
• lecteur d'empreinte : non testé
• la mise en veille (suspend) et en hibernation se fait sans problème

Au final, absolument rien de bloquant ou de gênant au quotidien ! Ah si, une petite particularité à laquelle il faut s'habituer : la batterie est équipée d'un système de prévention de son usure et donc par défaut la batterie ne se recharge que lorsqu'elle est descendue en-dessous de 80%. Autrement dit, branchée au secteur alors qu'elle se trouve à 88% de charge, la batterie ne bouge pas. Il existe un utilitaire sous Windows pour régler ce comportement. Cela n'existe pas à ma connaissance sous Linux.

Voici ce que rapporte lspci :

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)
00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO UART Controller #0 (rev 21)
00:1e.2 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO SPI Controller #0 (rev 21)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)

et lsusb :

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp. 
Bus 001 Device 002: ID 13d3:5a09 IMC Networks 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

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';

Ceux qui ont débuté sous Debian il y a quelques années ont peut-être découvert la formation Debian d'Alexis de Lattre. Celle-ci a récemment migré vers un nouveau domaine : https://formation-debian.viarezo.fr/ mais il me semble qu'elle n'a plus été mise à jour depuis quelques temps.

Je stocke ici les fichiers de paramétrage de ZSH légèrement modifiés pour tenir compte de ce billet et de ce billet.

• Fichier zshrc : zshrc
• Fichier zshenv : zshenv
• Fichier zlogin : zlogin
• Fichier zlogout : zlogout
• Fichier dir_colors : dir_colors

On pourra télécharger les fichiers et les placer à l'endroit adéquat du serveur avec cette série de commandes :

wget https://blog.bandinelli.net/public/zshrc
wget https://blog.bandinelli.net/public/zshenv
wget https://blog.bandinelli.net/public/zlogin
wget https://blog.bandinelli.net/public/zlogout
wget https://blog.bandinelli.net/public/dir_colors
mv zshrc zshenv zlogin zlogout /etc/zsh/
mv dir_colors /etc/

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 recently ran into the following error when running `certbox renew`:

Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.19.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 561, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2291, in load
    return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 11, in <module>
    from acme import jose
ImportError: cannot import name jose

I fixed it by launching the following command:

apt-get install certbot python3-certbot python3-acme python3-cryptography python3-josepy python3-setuptools -f -t stretch-backports

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!

Je viens de déployer une application NodeJS basée sur Angular et utilisant socket.io pour communiquer entre le "front-end" et le "back-end". Dans Firefox, je voyais toutefois ce message d'erreur :

Firefox can’t establish a connection to the server at wss://my.app/socket.io/?token=verylongtoken&EIO=3&transport=websocket&sid=verylongsid

et pourtant l'application fonctionnait parfaitement.

Après enquête, il semble que socket.io avait le bon goût de faire un "fallback" sur une méthode AJAX et s'accomodait donc du non établissement du WebSocket.

Pour régler proprement le problème, il fallait :

• activer le module proxy_wstunnel d'Apache

a2enmod proxy_wstunnel
service apache2 restart

• puis ajouter ces lignes dans la configuration (attention, le module rewrite d'Apache doit aussi être chargé !)

  RewriteEngine On
  RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
  RewriteCond %{QUERY_STRING} transport=websocket    [NC]
  RewriteRule /(.*)           ws://localhost:3000/$1 [P,L]

Et hop, tout était fonctionnel désormais !

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!

Pour accélérer l'accès à vos sites et services web propulsées par HAProxy, il est facile d'activer la compression automatique des contenus texte comme HTML, CSS, JS (s'ils ne le sont pas déjà par le serveur sous-jacent).

Rien de plus simple, il suffit d'ajouter les 2 lignes suivantes dans la section defaults de la configuration d'HAProxy :

compression algo gzip
compression type text/html text/plain text/xml text/css text/javascript application/javascript application/json text/json

et redémarrer HAProxy par une commande comme

/etc/init.d/haproxy restart

" Avec cette fonctionnalité activée, vous devez désormais voir dans les en-têtes des transmissions entre le serveur web et le navigateur que le contenu est compressé avec gzip (vérification facile avec le module "Développeur" de Firefox par exemple, onglet "Réseau") :

Content-Encoding: gzip

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

I was expecting an easy use of my brand new Wifi adapter AWUS036NHA under Debian Stretch but I hit an unexpected bug...

I started with

apt install firmware-atheros

and soon the blue LED on the Alfa device was blinking furiously. So good so far! But when I tried to connect to a Wifi network with Network-Manager the tool was unable to connect. And no matter what I did it failed to connect. This is what I could see in the system logs (dmesg):

[  217.118991] usb 1-3: USB disconnect, device number 5
[  219.137772] usb 1-3: new high-speed USB device number 6 using xhci_hcd
[  219.294368] usb 1-3: New USB device found, idVendor=0cf3, idProduct=9271
[  219.294373] usb 1-3: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[  219.294376] usb 1-3: Product: UB91C
[  219.294378] usb 1-3: Manufacturer: ATHEROS
[  219.294380] usb 1-3: SerialNumber: 12345
[  219.295099] usb 1-3: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[  219.295555] usb 1-3: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[  219.578229] usb 1-3: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[  219.829806] ath9k_htc 1-3:1.0: ath9k_htc: HTC initialized with 33 credits
[  220.096217] ath9k_htc 1-3:1.0: ath9k_htc: FW Version: 1.4
[  220.096221] ath9k_htc 1-3:1.0: FW RMW support: On
[  220.096224] ath: EEPROM regdomain: 0x833a
[  220.096225] ath: EEPROM indicates we should expect a country code
[  220.096227] ath: doing EEPROM country->regdmn map search
[  220.096229] ath: country maps to regdmn code: 0x37
[  220.096231] ath: Country alpha2 being used: GB
[  220.096232] ath: Regpair used: 0x37
[  220.101582] ieee80211 phy1: Atheros AR9271 Rev:1
[  220.115019] ath9k_htc 1-3:1.0 wlx00c0ca9751d9: renamed from wlan1
[  220.148280] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  220.332215] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  220.578623] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  220.642308] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  255.566737] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  259.745782] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  259.986747] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  265.841754] IPv6: ADDRCONF(NETDEV_UP): wlx00c0ca9751d9: link is not ready
[  276.133407] wlx00c0ca9751d9: authenticate with ec:08:6b:33:71:ba
[  276.391552] wlx00c0ca9751d9: send auth to ec:08:6b:33:71:ba (try 1/3)
[  276.394687] wlx00c0ca9751d9: authenticated
[  281.389219] wlx00c0ca9751d9: aborting authentication with ec:08:6b:33:71:ba by local choice (Reason: 3=DEAUTH_LEAVING)
[  282.900769] wlx00c0ca9751d9: authenticate with ec:08:6b:33:71:ba
[  283.164429] wlx00c0ca9751d9: send auth to ec:08:6b:33:71:ba (try 1/3)
[  283.167350] wlx00c0ca9751d9: authenticated

wlx00c0ca9751d9 is the name the system gave to the adapter and I was intrigued with this error line:

aborting authentication with ec:08:6b:33:71:ba by local choice (Reason: 3=DEAUTH_LEAVING)

After looking up on the web, I discovered that other users of Atheros firmware reported issue when the adapter was given a long name...

So I decided to teach udev to give a shorter name to the wifi device, for example wlan1. And by the way it would be easier to remember!

The first step was to detect the attributes seen by udev on the device. The right command to do so is:

udevadm info -a -p /sys/class/net/wlx00c0ca9751d9

Among many other attributes, I spotted quite precise ones:

ATTRS{manufacturer}=="ATHEROS"
ATTRS{product}=="UB91C"

Then I opened /etc/udev/rules.d/70-persistent-net.rules and added this line:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTRS{manufacturer}=="ATHEROS", ATTRS{product}=="UB91C", NAME="wlan1"

After restarting udev with

/etc/init.d/udev restart

I unplugged and then plugged back the Wifi adapter and it was recognized as wlan1. And then the Wifi connection could be established.

Complicated but quite effective fix!

Les versions 1.8.x d'HAProxy (premier représentant de la branche publié fin 2017) supportent le protocole HTTP/2 pour la communication frontale (section frontend). L'utiliser en amont de votre infrastructure est un moyen facile de rendre ce protocole disponible même si certains de vos serveurs sous-jacents (backend) n'en sont pas encore capables.

Installer HAProxy 1.8.x sur Debian Stretch

La version distribuée officiellement dans Debian Stretch est 1.7.x. Pour installer une version de la branche 1.8.x, il y a au moins 2 alternatives :

1. compiler l'outil à partir du code source disponible sur le site officiel
2. utiliser https://haproxy.debian.net/ qui va fournir un dépôt spécifique

Configurer HAProxy

La configuration d'HAProxy se fait par défaut dans /etc/haproxy/haproxy.cfg.

Voici un exemple de fichier de configuration dont les principales sections sont commentées plus bas :

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# Default ciphers offered by Mozilla here:
	#  https://mozilla.github.io/server-side-tls/ssl-config-generator
    ssl-default-bind-ciphers 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
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers 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
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend http-in
	bind :::80 v4v6

	acl host_letsencrypt path_beg /.well-known/acme-challenge/
	use_backend letsencrypt if host_letsencrypt

	redirect scheme https code 301 if !host_letsencrypt
 
frontend https-in
	bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt alpn h2,http/1.1
	option forwardfor
	http-request add-header X-Forwarded-Proto https

        # Define hosts
        acl host_alpha hdr_end(host) -i a.fr
	acl host_beta hdr(host) -i precis.b.fr
	acl host_gamma hdr_reg(host) ^d1.c.fr|d2.c.fr$

        # figure out which one to use
        use_backend alpha if host_alpha
	use_backend beta if host_beta
	use_backend gamma if host_gamma

	default_backend iota

backend alpha
        server alpha 192.168.1.1:80

backend beta
        server beta 192.168.1.2:80

backend gamma
        server gamma 192.168.1.3:80

backend iota
        server iota 192.168.1.4:80

backend letsencrypt
        server letsencrypt 192.168.1.1:8080

Quelques commentaires pour bien comprendre...

On écoute d'abord en HTTP (donc sur le port 80, en IPv4 et IPv6) et on redirige tout vers l'HTTPS (redirect scheme https code 301) car c'est une bonne pratique aujourd'hui de n'offrir que du contenu protégé par SSL/TLS.

frontend http-in
	bind :::80 v4v6
	redirect scheme https code 301

Si l'on utilise letsencrypt pour générer ses certificats et qu'ils sont tous générés sur une machine dédiée pour ne pas avoir à se poser de questions sur les différents types de serveurs sous-jacents, on peut rajouter une exception pour les appels utilisés dans l'ACME challenge de letsencrypt et rediriger alors le trafic vers une machine spécifique ici nommée letsencrypt.

frontend http-in
	bind :::80 v4v6

	acl host_letsencrypt path_beg /.well-known/acme-challenge/
	use_backend letsencrypt if host_letsencrypt

	redirect scheme https code 301 if !host_letsencrypt

On écoute bien sûr également sur le port 443 pour gérer les connexions en SSL/TLS :

frontend https-in
	bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt alpn h2,http/1.1
	option forwardfor
	http-request add-header X-Forwarded-Proto https

Il y a beaucoup de choses intéressantes ici :

• bind :::443 v4v6 : IPv4 et IPv6 activés
• bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt : on active le SSL/TLS et on spécifie un fichier texte qui contient la liste des certificats à charger pour chiffrer les communications
• bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt alpn h2,http/1.1 : on active l'HTTP/2 (en plus de l'HTTP/1)
• option forwardfor : comme on fonctionne en reverse proxy, on demande à HAProxy de passer les en-têtes X-FORWARDED-FOR aux serveurs sous-jacents (utile pour avoir les vraies adresses IP appelantes dans les logs)
• http-request add-header X-Forwarded-Proto https : on informe les serveurs sous-jacents que la communication est bien chiffrée (et on évite donc une boucle de redirection si le serveur sous-jacent veut forcer le passage en HTTPS, avec ce paramètre il sera déjà satisfait)

On définit ensuite quelques règles ACL pour, selon le nom d'hôte, orienter la connexion vers un backend ou autre. J'ai mis ici plusieurs exemples que j'utilise - il existe des dizaines d'autres filtres y compris sur d'autres critères que le nom d'hôte (on a vu l'URL dans le cas de letsencrypt un peu plus) : filtre sur la fin du nom d'hôte (tout nom d'hôte finissant par a.fr sera redirigé vers le backend alpha), filtre sur le nom d'hôte complet (precis.b.fr sera envoyé vers beta) ou filtre sur le nom d'hôte avec des expressions régulières.

        # Define hosts
        acl host_alpha hdr_end(host) -i a.fr
	acl host_beta hdr(host) -i precis.b.fr
	acl host_gamma hdr_reg(host) ^d1.c.fr|d2.c.fr$

        # figure out which one to use
        use_backend alpha if host_alpha
	use_backend beta if host_beta
	use_backend gamma if host_gamma

On définit également un backend par défaut (iota ici) :

	default_backend iota

Et il reste alors à définir chaque backend :

backend example
        server example 1.2.3.4:80

Pour aller plus loin

Les options possibles dans HAProxy sont fort évidemment beaucoup plus nombreuses ! La documentation est très détaillée et claire ici https://www.haproxy.org/#docs.

Pour activer IPv6 sur HAProxy, le plus simple est de modifier la directive bind dans votre fichier de configuration (par ex. /etc/haproxy/haproxy.cfg) pour devenir :

bind :::80 v4v6

ou

bind :::443 v4v6

Il y a 3 fois le caractère ":" car "::" correspond à toute adresse IPv4 ou IPv6, et le troisième ":" sépare l'adresse IP du port.