I have been playing with OpenBSD and httpd lately. It's a really simple and fun webserver to use, despite suffering huge limitations, but I quickly stumble across this horror:
No joke. httpd will serve all errors messages with the infamous Comic sans ms font. It's probably a troll from the maintainers, at least I hope so. Comic sans ms sucks, I don't want that on my server. Fortunately, there is a simple way to disable it.
Add this line into your /etc/httpd.conf:
errdocs "/errdocs"
Then create the file /var/www/errdocs/err.html with the following content:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>$RESPONSE_CODE $HTTP_ERROR</title>
<style type="text/css"><!--
body { background-color: white; color: black; }
hr { border: 0; border-bottom: 1px dashed; }
@media (prefers-color-scheme: dark) {
body { background-color: #1E1F21; color: #EEEFF1; }
a { color: #BAD7FF; }
}
--></style>
</head>
<body>
<h1>$RESPONSE_CODE $HTTP_ERROR</h1>
<hr>
<address>$SERVER_SOFTWARE</address>
</body>
</html>
Then restart httpd:
rcctl restart httpd
Explanation: httpd manage says:
A custom error document may contain the following macros that will be expanded at runtime:
$HTTP_ERROR
The error message text.
$RESPONSE_CODE
The 3-digit HTTP response code sent to the client.
$SERVER_SOFTWARE
The server software name of httpd(8).
So I just took the source code of a 404 error page, removed the Comic sans ms part in the CSS and replaced the values (error code, message, server identity) by the proper variables. Now all errors messages should be generated with this new template, with a fallback font.
If you need to install Zabbix-Agent2 on Ubuntu 16.04, you will find out that there is no available packages in Zabbix repository (unlinke Zabbix-Agent). You can try to use packages for other Linux systems, even RPMs, but you will always end up with library or ABI issues. The only way to make it work is compilation.
Install requirements:
apt install -y libpcre++-dev build-essential zlib1g-dev libssl-dev
Get Zabbix source code:
wget https://cdn.zabbix.com/zabbix/sources/stable/6.2/zabbix-6.2.4.tar.gz
tar xf zabbix-6.2.4.tar.gz
You need at least Go 1.17 (for Zabbix 6.2.4):
wget https://go.dev/dl/go1.19.3.linux-amd64.tar.gz
tar xf go1.19.3.linux-amd64.tar.gz
export PATH=$PATH:/root/go/bin
You should now be able to build Zabbix-Agent 2. I took these options from Zabbix documentation and made some ajustements from what I found in packages in Zabbix repository:
cd zabbix-6.2.4
./configure \
--enable-agent2 \
--enable-static \
--prefix=/usr \
--sysconfdir=/etc/zabbix \
--libdir=/usr/lib/zabbix \
--with-curl \
--with-openssl
Note: According Zabbix documentation, the --enable-static flag is useful if you want to create your own package and use it on other systems.
You can now build and install:
make install
You can now remove Go if you don't need it. A few steps are required to make Zabbix-Agent 2 work:
addgroup --system --quiet zabbix
adduser --quiet --system \
--disabled-login \
--ingroup zabbix \
--home /var/lib/zabbix \
--no-create-home zabbix
mkdir -p /etc/zabbix/zabbix_agent2.d/plugins.d
mkdir /run/zabbix/
chown -R zabbix:zabbix /run/zabbix
mkdir /var/log/zabbix
chown -R zabbix:zabbix /var/log/zabbix
Create /etc/logrotate.d/zabbix_agent2:
/var/log/zabbix/zabbix_agent2.log {
weekly
rotate 12
compress
delaycompress
missingok
notifempty
create 0640 zabbix zabbix
}
In the packages from Zabbix repository we have /usr/lib/tmpfiles.d/zabbix-agent2.conf:
d /run/zabbix 0755 zabbix zabbix - -
Don't forget to create a /etc/zabbix/zabbix_agent2.conf file. Here is a sample.
Finally, create a systemd unit file in /lib/systemd/system/zabbix-agent2.service:
[Unit]
Description=Zabbix Agent 2
After=syslog.target
After=network.target
[Service]
Environment="CONFFILE=/etc/zabbix/zabbix_agent2.conf"
EnvironmentFile=-/etc/default/zabbix-agent2
Type=simple
Restart=on-failure
PIDFile=/run/zabbix/zabbix_agent2.pid
KillMode=control-group
ExecStart=/usr/sbin/zabbix_agent2 -c $CONFFILE
ExecStop=/bin/sh -c '[ -n "$1" ] && kill -s TERM "$1"' -- "$MAINPID"
RestartSec=10s
User=zabbix
Group=zabbix
[Install]
WantedBy=multi-user.target
Reload, enable and start this new service:
systemctl daemon-reload
sytemctl enable --now zabbix-agent2
Check that everything works:
systemctl status zabbix-agent2
tail /var/log/zabbix/zabbix_agent2.log
Profit!
Il y a un an et demi, j'annonçais avoir migré mon blog sur Kubernetes (K3s). Bien que je sois globalement satisfait du résultat et que cela m'a permis de beaucoup apprendre, je rencontre tout de même des désagréments :
- Kubernetes, c'est lourd. Comptez 1 GB de RAM à vide. Pour être à l'aise, j'ai du prendre un VPS avec 4GB de RAM, là où 2 suffiraient largement sans Kubernetes.
- Absence de support d'IPv6. En 2022 c'est franchement difficile à justifier.
- La gestion des Ingress est complexe. J'utilise Traefik mais c'est compliqué, il m'a fallu quasiment 2 jours pour faire fonctionner les certificats ACME, et les montées de version ne se passent pas toujours très bien.
- Comme prévu, les mises jour à demandent un peu plus d'efforts car les composants ne sont pas gérés par la distribution. Il faut donc:
- Mettre K3s à jour régulièrement.
- Reconstruire et livrer les images même si l'application n'a pas changé, juste pour être sûr de ne pas trimbaler de failles de sécurité dans les librairies.
- Mettre à jour Traefik régulièrement.
Bref, même si je trouve que Kubernetes est une super solution qui a mis en valeur les containers et l'écosystème Linux, c'est clairement overkill pour moi et je souhaite me simplifier la vie. Et si au passage je peux me former à de nouvelles technos, c'est un plus.
La solution de facilité aurait été d'installer Debian et de coder quelques roles Ansible mais l'inconvénient est que je n'apprendrais rien de nouveau. Je suis donc parti sur NixOS. C'est une distribution où la configuration s'effectue de manière déclarative via le langage Nix, avec gestion des états et possibilité de rollback.
En effet lorsque vous gérez votre distribution Linux avec Ansible, Puppet ou Salt, vous pouvez déployer une configuration et des applications, en revanche le retour en arrière n'est pas géré. Par exemple si vous avez déployé Apache et que vous voulez changer pour Nginx, c'est à vous de coder la manière dont Ansible va désinstaller Apache, sinon il sera toujours présent. Avec NixOS, si vous retirez toute référence à httpd dans votre configuration, il ne sera plus du tout présent à la prochaine génération du système. C'est un fonctionnement atomic et stateful.
Pour l'installation, j'ai utilisé nixos-infect, un script à lancer sur la plupart des distributions Linux afin de les remplacer par NixOS. Associé à un cloud-init, il permet de faire le déploiement via Terraform de manière complètement automatique, ce qui est vraiment cool il faut le dire. Et pour les gens qui préfèrent une installation à la main, sachez que Hetzner proposer une ISO NixOS et un accès console distante même pour les VPS, c'est donc totalement possible :)
Pour la partie hébergement web, voici mon fichier de configuration /etc/nixos/web.nix :
{ config, lib, pkgs, ...}:
let
defaultVirtualHost = {
documentRoot = "/var/www/html/blank";
addSSL = true;
forceSSL = false;
sslServerKey = "/var/www/ssl/snakeoil.key";
sslServerCert = "/var/www/ssl/snakeoil.pem";
locations."/" = {
index = "index.html";
};
};
makeVirtualHost = webroot:
{ documentRoot = "${webroot}";
forceSSL = true;
enableACME = true;
locations."/" = {
index = "index.php";
};
extraConfig = ''
<Directory "${webroot}">
AllowOverride All
</Directory>
'';
};
in {
security = {
acme = {
email = "hostmaster@example.org";
acceptTerms = true;
};
};
services = {
httpd = {
enable = true;
mpm = "prefork";
adminAddr = "hostmaster@example.org";
enablePHP = true;
phpPackage = pkgs.php80;
phpOptions = "display_errors = off";
extraConfig = ''
SetOutputFilter DEFLATE
ServerSignature Off
ServerTokens prod
<FilesMatch ".(ico|pdf|jpg|jpeg|JPEG|png|gif|js|css)$">
Header set Cache-Control "max-age=3600, public"
</FilesMatch>
'';
extraModules = [
"deflate"
];
virtualHosts =
{"_default_" = defaultVirtualHost;
"utux.fr" = (makeVirtualHost "/var/www/html/utux.fr");
};
};
};
}
Explications : j'ai d'autres vhosts non mentionnés ici, et à chaque fois leur configuration est identique. Pour éviter d'avoir à répéter du code, j'utilise let (permet de définir des variables et des fonctions) ainsi que in (pour les appliquer). Je ne connais pas de moyen plus propre de faire des loop pour le moment, car c'est le but. Étant donné que j'utilise PluXml, il ne faut pas oublier le AllowOverride All qui permet aux .htaccess de fonctionner, sinon les fichiers XML qui contiennent les data deviennent accessible, ce qui fait fuiter pas mal d'infos sensibles.
Pour le moment, ça marche plutôt bien. Le serveur consomme 119 Mo de RAM, soit quasiment 10x moins que Kubernetes :) Et en prime le support de l'IPv6 est revenu.
En conclusion, je suis content de pouvoir enfin tester NixOS en production. Bien que je ne sois pas encore familier avec le langage Nix, et que je le trouve bien trop compliqué par rapport à un bon vieux Ansible, j'estime que c'est l'avenir de Linux sur serveur. Les distributions devront être atomiques, et leur configuration centralisée, versionnée et reproductible. J'espère que ceci est le début d'une aventure positive.
La nouvelle est tombée il y a quelques jours : le support de CentOS 8 se terminera fin 2021 et la distribution basculera à 100% sur le modèle Stream. C'est un changement de gouvernance brutal et destructeur pour ses utilisateurs car CentOS ne sera plus un clone de Red Hat gratuit mais plutôt son pendant "Windows Insider".
Il faut bien comprendre que CentOS c'est quelque chose de gros : c'est la 2e distribution la plus utilisée au monde sur les serveurs Web Linux en 2020 avec 18,8% de parts de marché. Moi qui travaille avec du Cloud et du Linux en entreprise, je confirme que ça représente à la louche 60% de nos serveurs (non Windows) peut-être même plus.
Qu'est-ce qui plaît autant dans cette distribution encore plus en retard que Debian et avec des dépôts tellement vides qu'il n'y a ni nginx ni htop ?
- C'est basiquement un clone gratuit de Red Hat, donc très stable et certifiée par des tas de constructeurs de matériel et éditeurs de middlewares.
- Support incroyablement long, une dizaine d'années.
- Bénéficie de l'énorme documentation en ligne de Red Hat.
- La pauvreté des dépôts est compensée par EPEL et SCL (mais aussi tout un tas d'autres).
- La version du kernel est vieille mais les drivers et correctifs de sécurité sont backportés dedans.
- Certains n'aiment pas les libertés prises par Debian dans le packaging de certaines applications (par exemple Apache). CentOS est un peu plus proche de l'upstream sur ce point.
En gros CentOS était une distribution incassable, prévisible, ennuyeuse, et avec un support extrêmement long. On comprend alors que l'abandon de cette stabilité au profil d'un modèle de type "testing" ou "insider" va totalement à l'encontre de ce qui faisait son intérêt. Mais alors, que peut-on faire ?
Si possible, ne plus déployer de CentOS 8 en attendant que la situation se stabilise. Cette annonce a provoqué de très nombreux retours négatifs de la communauté et il est évident que le projet se rend compte qu'il se saborde lui-même. En ce qui me concerne j'espère soit une annulation de cette décision, soit au contraire un message clair qui indique qu'IBM/Red Hat ne veut plus de CentOS dans sa forme actuelle, dans les deux cas nous serions fixés sur l'avenir.
En attendant, si vous devez déployer de nouveaux serveurs, il existe des alternatives :
- Si vous n'avez aucune fidélité à RHEL/CentOS ou aux RPMs, Debian et Ubuntu sont des alternatives de choix. J'ai une nette préférence pour la première que j'ai toujours trouvé plus légère, plus stable, et qui n'installe pas snap par défaut.
- CentOS 7 reste une option à ne pas négliger, car supportée jusqu'en 2024.
- Si vous avez besoin de la compatibilité RHEL/CentOS 8, il y a Oracle Linux. Alors oui le nom fait peur car quand on parle d'Oracle on pense aux tarifs exorbitants, à OpenOffice, et aux pratiques crapuleuses, il n'empêche que la distribution est bien gratuite et qu'elle perdure depuis 2013, en plus d'être elle aussi un clone de Red Hat. Elle est fournie avec deux kernel : RHCK (compatible Red Hat / CentOS) et UEK (Unbreakable Enterprise Kernel, plus récent et ne nécessitant pas de reboot). Oracle Linux est à mon sens l'alternative la plus crédible à CentOS. Pour couronner le tout, un script de migration est disponible : lien vers un retour d'expérience.
- Je ne recommande pas Rocky Linux, c'est beaucoup trop tôt. Des tas de distributions naissent et meurent chaque année, ou se retrouvent parfois dans un état intermédiaire façon Mageia, donc attendons de voir si Rocky aura les moyens de ses ambitions. Elle n'est de toutes manières pas encore disponible.
Il est urgent d'attendre, laissez passer les fêtes pour voir comment la situation évolue. Voilà mon avis sur le feuilleton CentOS ;)
I need to backup my NAS to a remote and secured location, and because I am a Azure AZ-103 associate, I have decided to use an Azure storage account. I will use Duplicati, a free backup software written in C# with the following features:
- Native AES-256 encryption.
- Wide variety of storage backends: Azure, S3, GCS, FTP, SSH, Onedrive...
- Works well on Windows, Linux, FreeBSD.
- Works on a headless server with a WebUI.
Storage account offers 3 tier with different pricing: hot, cool, archive. If you choose a hot tier, access is less charged, but storage is more expensive. This is the opposite for cool and archive, storage is cheap but access is expensive. Archive is the most interesting tier for backups but it has many constraints, such as the need to pick every object inside the container and move them to the tier. So I will use cool.
Create a Resource group and a Storage account
First you need to create a Resource group. Go to the Resource groups blade then click +Add. Take a look at Ready: Recommended naming and tagging conventions if you don't know how to name it. Select a region (does not really matters now).
Now you need to create a Storage account. Go to the Storage accounts blade then click +Add.
- Subscription: your subscription.
- Resource group: the one you just created
- Storage account name: must be unique accross Azure and as many limitations, so I recommend using a very short name + short random id.
- Location: Select the location of your choice (choose a close one with an interesting pricing, see Azure Calculator)
- Account kind: StorageV2
- Replication: LRS
- Access tier: cool
Now open you new Storage account and go to the Containers blade then click +Container. This time the name is private and does not need to be unique. Make sure the Public level access is set to Private (no anonymous access).
Go to the Access keys blade and retrieve the value of key1 or key2. These key are private and should not be shared with anyone because they basically give full access to the storage account and the data inside.
Configure Duplicati
Go into the Web UI then + Add backup > Configure a new backup.
Enter a name, a description and a very strong encryption passphrase (if you forget this passphrase, you wan't be able to decrypt your backups).
Select "Azure blob" for Storage type and set your credentials.
Click Test connection to make sure Duplicati can reach your Azure container.
Select the files you want to backup.
Schedule your backups. For me, monthly is enough.
Duplicati will not copy your files one by one but use "volumes". To select the size of each block, read this documentation. Smaller means more transactions but better de duplication. Bigger means less transactions but less optimized de duplication. If you have the bandwith, go for higher chunks. 1 Gbyte seems to be a good value for me. More is not good, takes too much resources.
You can also set a retention, for me it's 6 months.
Et voila, just run your backup now!
Pricing considerations
It is not easy to estimate monthly charges. It depends not only on used storage, but also on write and read operations. Here is how much I pay:
- Region: North Europe
- Chunks: 1 GB
- Monthly backups
- Used Storage: 488 GiB
- Monthly cost: < €5
Fil RSS des articles de cette catégorie