La mise à niveau de votre serveur Ubuntu est une étape importante pour garantir que votre système est toujours à jour et sécurisé. Avec le paquet unattended-upgrade, vous pouvez facilement activer les mises à niveau sans avoir à vous soucier du redémarrage manuel ou des temps d’arrêt.
Comme son nom l’indique, le paquet unattended-upgrade permet de lancer les mises à jour automatiquement à intervalles réguliers, sans action de la part de l’administrateur. Vous pouvez donc planifier les mises à jour lorsque le trafic est faible, et l’outil est même capable de redémarrer le serveur si besoin.
Dans ce tutoriel, nous allons vous montrer comment installer et utiliser unattended-upgrade sous Ubuntu Server 22.04. Nous aborderons également les avantages de l’utilisation de cet outil et la manière dont il peut contribuer à garantir que votre système est toujours à jour.
Pour commencer, vous devez d’abord installer unattended-upgrade sur votre serveur Ubuntu – ouvrez une fenêtre de terminal et entrez la commande suivante :
apt install unattended-upgrade
Une fois que unattended-upgrade est installé, on le paramètre:
dpkg-reconfigure -plow unattended-upgrades
Répondez “Yes” pour installer les mises à jour stable automatiquement.
Activez ensuite l’outil:
unattended-upgrade enable
Paramètrage d’unattended-upgrade
Le paquet est bien plus puissant qu’il n’y paraît. Personnellement, j’aime bien être informé des mises à jour et des changements sur le serveur, activons donc les notifications.
On édite notre fichier de configuration local (à créer si besoin). C’est le fichier qui ne sera pas écrasé si le paquet est mis à jour:
Et en suivant la documentation, on demande la notification récapitulative des mises à jour, le redémarrage automatique si besoin, vers deux heures du matin pour ne pas gêner nos visiteurs:
// email to send notifications
Unattended-Upgrade::Mail "skyminds@example.com";
// automatic reboot at 2:00 AM
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Sur votre instance Nextcloud, il est important de mettre en place un cron qui va permettre de lancer les tâches de maintenance à intervalles réguliers.
Dans Paramètres > Administration > Paramètres de base, sélectionnez l’option Cron pour les tâches de fond:
Ensuite, créez un fichier pour l’utilisateur www-data depuis le terminal:
crontab -u www-data -e
et à la fin du fichier on ajoute une tâche qui va se lancer toutes les 5 minutes:
*/5 * * * * php -f /home/www/nextcloud/cron.php
Pensez à changer le chemin pour celui de votre installation Nextcloud.
Et redémarrez le service cron pour appliquer les changements:
service cron restart
Notification automatique des nouvelles versions
Maintenant que le cron est en place, nous allons pouvoir planifier une tâche qui vérifiera chaque semaine s’il existe une nouvelle version de Nextcloud.
Cela peut sembler fou mais Nextcloud ne vous prévient pas lorsque de nouvelles mises à jour sont disponibles et il faut donc le mettre en place soi-même.
Nous ouvrons donc le fichier crontab pour notre utilsateur www-data :
crontab -u www-data -e
et nous ajoutons cette ligne, qui permet la vérification et notification des nouvelles versions par email, tous les vendredis à 19h:
0 19 * * 5 php /home/www/nextcloud/occ update:check # nextcloud update check, at 19:00 every Friday
Pensez à changer le chemin pour celui de votre installation Nextcloud.
Mise à jour automatique de votre installation Nextcloud
Être notifié des mises à jour, c’est bien – mais nous pouvons faire bien mieux : pourquoi ne pas installer automatiquement les mises à jour de NextCloud de manière à toujours avoir la dernière version ainsi que tous les correctifs de sécurité?
Ajoutez un nouveau cron:
0 20 * * 5 php /home/www/nextcloud/updater/updater.phar --no-interaction # automatic nextcloud upgrade, at 20:00 every Friday
Et redémarrez le service cron pour appliquer les changements:
service cron restart
Mise en place des alertes par email
Nextcloud est capable de vous alerter pour les mises à jour de sécurité ainsi que la gestion des mots de passe perdu pour les comptes utilisateurs mais encore faut-il qu’il soit configuré pour utiliser votre serveur mail correctement. Par défaut, rien n’est configuré.
J’ai récemment écrit un petit script bash qui me permet de sauvegarder rapidement toutes les bases de données d’un serveur. Le script est lancé par une tâche cron automatiquement, tous les jours.
Si l’on passe l’utilisateur et le mot de passe SQL dans la requête, avec mysql ou mysqldump, vous obtiendrez très certainement le message d’avertissement suivant:
Warning: Using a password on the command line interface can be insecure.
Et pour cause : cela veut dire que n’importe qui ayant accès au serveur pourra voir, dans les logs ou avec un simple ps, vos informations de connexion à vos bases de données. Ce n’est pas ce qui se fait de mieux en matière de sécurité !
Une solution est de passer en argument un fichier qui contiendra vos données de connexion à la base de données.
Note: L’argument --defaults-extra-file doit venir en premier, sinon il ne sera pas interprété.
Le fichier /etc/mysql/mysql-backup-script.cnf contient les identifiants de votre utilisateur SQL qui aura les droits sur chacune des bases de données à sauvegarder. Voici à quoi il ressemble:
[client]
user = 'backup'
password = 'GIGANTIC_SECURE_PASSWORD'
Par sécurité, on restreint les droits d’accès au fichier pour qu’il ne soit pas lisible par tout le monde:
chmod 400 /etc/mysql/mysql-backup-script.cnf
Il ne vous reste qu’à créer votre cron avec votre nouvelle commande, sans montrer les identifiants SQL en clair.
C’est en fait un problème de regex connu et la solution est très simple.
1. On édite le fichier /etc/logrotate.d/mysql-server:
nano /etc/logrotate.d/mysql-server
2. on recherche la ligne avec la regex de grep:
if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then
3. on ajoute m1 aux arguments de grep, ce qui nous donne:
if [ -f `my_print_defaults --mysqld | grep -oPm1 "pid-file=\K[^$]+"` ]; then
Sauvegardez le fichier. Vous ne recevrez plus de message d’erreur lors du lancement de la tâche cron et les fichiers logs de MySQL/MariaDB seront bien archivés.
La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit).
Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.
Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.
1. Méthode nucléaire : rendre la variable MAILTO nulle
Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:
MAILTO=""
Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron.
Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.
2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie
Si vous supprimez la sortie du script, crond n’aura rien à envoyer.
Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:
>/dev/null 2>&1
Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:
*/5 * * * * /example/script >/dev/null 2>&1
Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.
3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie
Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS.
L’argument -s envoie la sortie vers le log système et l’argument -m off désactive la notification email du résultat de la tâche.
Voici un exemple :
cat /etc/sysconfig/crond
Résultat:
# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS=-s -m off
Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:
service cron restart
Conclusion
Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.
Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:
Quoi de plus normal que de regarder des séries et films en VO ? Et si vos sous-titres étaient automatiquement téléchargés sur votre NAS tous les soirs ?
Regarder des séries et films en version originale, c’est ce que je passe mon temps à faire à recommander à mes élèves – et à leurs parents lors des réunions parents-professeurs.
On s’affranchit souvent de ces petits fichiers textes mais il peut arriver de tomber sur une série un peu plus coriace, qui demande de bien tout comprendre si on veut vraiment saisir le fin mot de l’histoire. Bref, parfois, les sous-titres, ça peut servir.
Voici donc un petit tutoriel pour récupérer automatiquement les bons sous-titres pour vos fichiers, avec en script en ligne de commande ou exécutable par votre NAS.
Synology : installation de pip
1. Ouvrez une session SSH sur le NAS et passez root :
Subliminal est une librairie Python qui permet de rechercher et télécharger des sous-titres. C’est ce que nous allons lancer, soit en ligne de commande, soit par un cron sur le NAS.
Script de téléchargement automatique des sous-titres
Passons maintenant au script de téléchargement automatique de nos sous-titres. Voici mes pré-requis :
dossier à scanner : /volume1/video
âge maximum des fichiers pour lesquels on recherche les sous-titres : 4 weeks
langue des sous-titres: eng pour l’anglais, fra pour le français. Ici, je ne souhaite que de l’anglais.
Créez donc un nouveau fichier (dans votre dossier utilisateur du NAS, pas dans root):
nano /volume1/homes/matt/subby.py
et ajoutez-y:
from datetime import timedelta
from babelfish import Language
from subliminal import download_best_subtitles, region, save_subtitles, scan_videos
# configure the cache
region.configure('dogpile.cache.dbm', arguments={'filename': 'cachefile.dbm'})
# scan for videos newer than 2 weeks and their existing subtitles in a folder
videos = scan_videos('/volume1/video', age=timedelta(weeks=10))
# download best subtitles in English
subtitles = download_best_subtitles(videos, {Language('eng')})
# save them to disk, next to the video
for v in videos:
save_subtitles(v, subtitles[v])
Vous pouvez lancer ce script directement depuis un terminal avec :
python /volume1/homes/matt/subby.py
Mise à jour : on peut encore mieux faire ! Lassé d’avoir à installer pip et subliminal à chaque mise à jour du DSM, j’ai écrit un script bash qui gère toute l’installation (pip, subliminal) et qui lance le script python pour le téléchargement des sous-titres.
On crée notre script bash :
nano /volume1/homes/matt/subby.sh
avec :
#!/bin/bash
# Script Name : Pip and Subliminal dependences FTW
# Script Author : Matt Biscay
# Script URL : https://www.skyminds.net/nas-synology-telecharger-automatiquement-sous-titres-subliminal/
# Script Version : 1.0 (2017-07)
# working dir
cd /volume1/homes/matt
# is pip installed ?
if which pip 2>/dev/null;
then
echo "pip is installed. Fetching subtitles..."
python subby.py
echo "Subs fetching complete. Enjoy !"
exit 1
else
echo "pip is missing. Installing it now..."
# remove pip install file
rm get-pip.py -f
# fetch pip install file
wget https://bootstrap.pypa.io/get-pip.py
# install pip
python get-pip.py
# install subliminal
pip install subliminal
# get subs
echo "pip and subliminal have been installed. Fetching subtitles..."
python subby.py
echo "Subs fetching complete. Enjoy !"
fi
Kaboom ! Si le binaire pip n’est pas présent sur le système, c’est qu’il n’a pas survécu à la mise à jour du DSM. On l’installe donc, ainsi que subliminal. Ensuite on lance le script de téléchargement.
Mise en place d’un cron pour automatiser le téléchargement des sous-titres
Si vous êtes sous Unix, vous pouvez mettre en place un cronjob avec le script tel quel.
Sur le Synology, tout se met en place en quelques clics :
Rendez-vous dans Panneau de configuration > Planificateur de tâches > Créer > Tâche planifiée > Script défini par l’utilisateur:
Donnez un nom à votre tâche et assignez-lui un utilisateur (root).
dans l’onglet Programmer, ajouter la fréquence de lancement du script :
enfin, dans l’onglet Paramètres de tâches, donnez le chemin du script précédé de la commande bash puisque c’est un script bash:
Ce matin, j’ai reçu ce message d’erreur de mon serveur par email :
/etc/cron.daily/logrotate:
error: line 672139 too long in state file /var/lib/logrotate/status
error: could not read state file, will not attempt to write into it
run-parts: /etc/cron.daily/logrotate exited with return code 1
Sous les systèmes GNU/linux, logrotate est le service qui archive les fichiers log de manière à ne pas travailler sur des fichiers trop lourds.
Les fichiers sont donc archivés plus ou moins régulièrement, selon leur taille et leur utilisation : certains sont archivés tous les jours, d’autres toutes les semaines.
Or, si logrotate ne fonctionne pas correctement, la taille des fichiers explose, ce qui posera tôt ou tard un souci sur le serveur.
Lorsque logrotate n’arrive pas à lire ou à écrire dans le fichier /var/lib/logrotate/status, il faut :
1. supprimer le fichier /var/lib/logrotate/status :
rm -rf /var/lib/logrotate/status
2. et relancer logrotate :
logrotate -f /etc/logrotate.conf
Le fichier /var/lib/logrotate/status ne sert finalement qu’à garder une trace de la dernière rotation des fichiers logs. Ce fichier ne devrait pas contenir énormément de lignes.
Ps : si vous utilisez Varnish, commentez les lignes le concernant dans /etc/logrotate.conf, il est peu utile d’encombrer le serveur avec les logs de ressources statiques.
Aujourd’hui, nous abordons la sauvegarde des fichiers essentiels du serveur.
Backup Manager permet d’effectuer des sauvegardes quotidiennes du système : il crée des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et peut les exporter vers un serveur FTP.
Dans notre cas, nous allons l’installer et le configurer pour envoyer tout ce qui est important sur notre serveur sur le serveur FTP externe de sauvegarde fourni gratuitement par OVH (100 Go).
Etape 1 : installation de Backup Manager
C’est classique :
apt-get install backup-manager
A la fin de l’installation, un assistant se lance et vous permet de configurer des options par défaut. Ou vous pouvez configurer à la main, comme indiqué dans l’étape suivante.
Quelques jours seulement après le transfert du site, OVH annonce le Kimsufi avec 250 Go mais… à moitié prix ! Et on ne peut rendre un serveur Kimsufi pour un autre, il s’agit de deux achats séparés.
Au niveau des performances, je dirai que mon Kimsufi 500G n’était pas terrible : il était constamment surchargé et j’avais l’impression de devoir relancer les services régulièrement pour assurer la disponibilité du service. Pas cool du tout.
Cela fait quelques semaines que je me demande comment mettre à jour Firefox sous Ubuntu alors qu’aucune mise à jour ne semble voir le jour dans les dépôts officiels.
Et voici que je tombe sur UbuntuZilla, un script Python qui permet d’installer les dernières versions de Firefox, SeaMonkey et Thunderbird sur les plateformes Ubuntu et dérivées, et cela automatiquement !
Téléchargement d’UbuntuZilla
Commencez par télécharger la version d’UbuntuZilla correspondant à votre système. Le fichier est un paquet .deb donc directement installable par Ubuntu.
Cron est le nom du programme qui permet aux utilisateurs Unix d’exécuter automatiquement des commandes ou des scripts à une heure spécifiée.
Cron est très utile pour lancer une procédure de sauvegarde à heure fixe, optimiser une base de données ou encore supprimer les courriers indésirables de votre boîte aux lettres.
C’est un peu l’équivalent Unix du planificateur de tâches de Windows.
Cron est basé sur une table référençant les tâches à lancer ainsi que l’année, le mois, le jour, l’heure et la minute à laquelle exécuter ces tâches.
En fait ce que l’on appelle communément “Cron” comprend deux éléments distinctifs :
crond, un programme résident en mémoire (daemon) qui lance automatiquement les tâches en fonction de la table cron.
crontab, un fichier de configuration qui comprend les travaux programmés et la date d’exécution. C’est ce fichier qui permet l’édition de la table des tâches à ordonnancer.
Syntaxe de crontab en image
La syntaxe de crontab est donc notée de la façon suivante:
mm hh jj MMM JJJ tâche > log
Légende :
mm représente les minutes (de 0 à 59)
hh représente l’heure (de 0 à 23)
jj représente le numéro du jour du mois (de 1 à 31)
MMM représente le numéro du mois (de 1 à 12) ou l’abréviation du nom du mois (jan, feb..)
JJJ représente l’abréviation du nom du jour ou le chiffre correspondant au jour de la semaine (0 représente le dimanche, 1 représente le lundi …)
tâche représente la commande ou le script shell à exécuter
log représente le nom d’un fichier dans lequel stocker le journal des opérations. Si la clause > log n’est pas spécifiée, cron enverra automatiquement un courriel de confirmation. Pour éviter cela il suffit de spécifier > /dev/null
Exemples
Lancer un script PHP tous les lundis à 22h34 :
34 22 * * 1 tâche
Lancer un script PHP tous les premiers du mois à 23h59 :
59 23 1 * * GET
Faire une sauvegarde de fichiers et des bases MySQL :
This post is an extension to my former tutorial : Backup all your MySQL databases with one line of cron, which can now be considered as obsolete since some people reported having some issues with the gzip file generation.
So here is another attempt at dealing with the security of your files and databases on your domain.
In this tutorial, I assume your web host has Cpanel installed with the cron features that will backup everything for us at regular intervals.
To access the Cron Manager in Cpanel :
Go to Cpanel > Cron Jobs
Select the Standard or Advanced view – the choice is yours !
Let’s assume you chose the “Standard view” for the sake of simplicity and ease of configuration. First, backup your files.