Cédrix
1 line
15 KiB
JSON
1 line
15 KiB
JSON
[{"uuid":"3c0dbff9-caa3-4fc9-b58b-20b33a88013c","slug":"setting-default-locale","title":"Setting default locale","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-11-05 07:57:07","created_at":"2022-11-05 07:57:07","updated_at":"2022-11-05 07:57:07","tags":[],"plain":"Dans un Terminal Linux sous Raspberry Pi OS, lorsque j’exécute une commande par exemple, le message suivant apparaît : Cela signifie que les locales ne sont pas renseignées correctement. On peut vérifier les locales actives avec la commande Imaginons que nous voulions activer la locale . 1. Dé-commenter la ligne dans le fichier sudo sed -i 's/^# \\(frFR.UTF-8\\)/\\1/' /etc/locale.gen 2. Exécuter la commande pour générer les fichiers sudo locale-gen 3. La commande modifie le fichier afin de définir correctement les variables pour tous les comptes Linux. sudo update-locale LANG=frFR.UTF-8 LANGUAGE=frFR.UTF-8 LCALL=frFR.UTF-8\n \n4. Redémarrer et vérifier avec la commande"},{"uuid":"80069e1f-202a-407e-91f5-71344ba4fd6b","slug":"20230113-afficher-le-nombre-de-mise-a-jour-avec-dnf-a-l-ouverture-de-session","title":"Afficher le nombre de mise à jour en attente avec DNF à l'ouverture de session","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-15 22:02:45","created_at":"2023-02-15 22:02:45","updated_at":"2023-02-15 22:02:45","tags":[],"plain":"Il y a plusieurs façons d'exécuter une commande automatiquement lors de l'ouverture d'une session sur un système basé sur Linux :\nAjoutez la commande dans le fichier .bashprofile : Vous pouvez ajouter la commande que vous voulez exécuter automatiquement dans le fichier de votre répertoire personnel. Ce fichier est exécuté lorsque vous ouvrez une session de terminal.\nUtilisez un gestionnaire de sessions : Les gestionnaires de sessions tels que systemd ou peuvent être utilisés pour exécuter des commandes automatiquement lors de l'ouverture d'une session. Par exemple, vous pouvez utiliser systemd pour créer un service qui exécute une commande automatiquement au démarrage.\nUtilisez le fichier /etc/profile : Ce fichier est exécuté pour tous les utilisateurs lors de l'ouverture d'une session, vous pouvez donc y ajouter la commande que vous souhaitez exécuter automatiquement. Avec dnf (Dandified Yum) vous pouvez utiliser la commande pour afficher le nombre de mises à jour en attente. Pour afficher cette information dans le fichier , vous pouvez utiliser une commande de type : echo \"Il y a $(dnf check-update -q -y | grep -c \"^.\") mise(s) à jour en attente\" Cette ligne utilise la commande pour vérifier les mises à jour en attente. Le paramètre (quiet) permet de n'afficher que le nombre de paquets à mettre à jour, sans afficher les détails sur les paquets. Ensuite, elle utilise la commande pour compter le nombre de lignes de sortie, ce qui correspond au nombre de mises à jour en attente. Le résultat est ensuite affiché avec la commande . Note importante 1 : cette commande fonctionnera uniquement si vous utilisez comme gestionnaire de paquets, et non qui est utilisé sur les anciennes version de Fedora, Red Hat ou Cent OS**. Note importante 2 : pour utiliser ces méthodes, vous devrez avoir les privilèges d'administrateur pour accéder et éditer les fichiers système. Il est également important de vérifier que la commande que vous souhaitez exécuter automatiquement est sûre et ne causera pas de problème pour votre système."},{"uuid":"fcdd80a9-e5fb-4e3d-9b97-526c4019bfae","slug":"20230113-afficher-le-nombre-de-mise-a-jour-avec-yum-a-l-ouverture-de-session","title":"Afficher le nombre de mise à jour en attente avec YUM à l'ouverture de session","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-15 22:02:45","created_at":"2023-02-15 22:02:45","updated_at":"2023-02-15 22:02:45","tags":[],"plain":"Il y a plusieurs façons d'exécuter une commande automatiquement lors de l'ouverture d'une session sur un système basé sur Linux :\nAjoutez la commande dans le fichier .bashprofile : Vous pouvez ajouter la commande que vous voulez exécuter automatiquement dans le fichier de votre répertoire personnel. Ce fichier est exécuté lorsque vous ouvrez une session de terminal.\nUtilisez un gestionnaire de sessions : Les gestionnaires de sessions tels que systemd ou peuvent être utilisés pour exécuter des commandes automatiquement lors de l'ouverture d'une session. Par exemple, vous pouvez utiliser systemd pour créer un service qui exécute une commande automatiquement au démarrage.\nUtilisez le fichier /etc/profile : Ce fichier est exécuté pour tous les utilisateurs lors de l'ouverture d'une session, vous pouvez donc y ajouter la commande que vous souhaitez exécuter automatiquement. Sous Fedora, CentOS ou Red Hat, vous pouvez utiliser la commande pour afficher le nombre de mises à jour en attente. Pour afficher cette information dans le fichier , vous pouvez utiliser une commande de type : echo \"Il y a $(yum check-update -y -q | grep -c \"^.\") mise(s) à jour en attente\" Cette commande utilise la commande pour vérifier les mises à jour en attente. Le paramètre (quiet) permet de n'afficher que le nombre de paquets à mettre à jour, sans afficher les détails sur les paquets. Ensuite, elle utilise la commande pour compter le nombre de lignes de sortie, ce qui correspond au nombre de mises à jour en attente. Le résultat est ensuite affiché avec la commande . Cette commande fonctionnera uniquement si vous utilisez comme gestionnaire de paquets, et non qui est utilisé par défaut sur les dernières version de Fedora, Cent OS et Red Hat**."},{"uuid":"ee7ae0b2-bf21-4710-81d7-d12e7af4807d","slug":"parametrage-raspi-config-pour-raspberrypi-3-plus","title":"raspi-config, le menu de configuration du Raspberry Pi 3+","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 14:18:28","created_at":"2023-02-02 14:18:28","updated_at":"2023-02-02 14:18:28","tags":[],"plain":"Il faut exécuter la commande avec les droits admin pour exécuter l'assistant de configuration. Ce programme propose :\nChange User Password - Changer le mot de passe de l'utilisateur \nNetwork Options - Paramétrer les options réseau\nBoot Options - Choisir de démarrer dans le terminal ou dans l’environnement graphique LXDE\nLocalisation Options - Configurer les options linguistiques\nInterfacing Options - Paramètre les connections aux périphériques\nOverclock - Paramétrer l'overclocking pour votre Pi\nAdvanced Options - Paramétrer les options avancées\nUpdate - Mettre à jour raspi-config avec la dernière mise à jour\nAbout raspi-config - Information concernant cet outil de configuration Je vous propose de suivre les que j'ai pu glaner sur différents supports."},{"uuid":"5a0cced3-40d0-46bf-8501-b533f3c2608e","slug":"reparer-une-instance-uptime-kuma-installee-via-le-script-proxmox","title":"Réparer une instance Uptime Kuma installée via le script Proxmox","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-26 08:33","created_at":"2025-11-26 08:33:49","updated_at":"2026-05-12 09:16:00","tags":[],"plain":"Méthode basée sur l'installation via le script communautaire :\r\ncommunity-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma\r\n\r\nSi tu utilises Uptime Kuma pour monitorer ton infra, tu finiras tôt ou tard par tomber sur un de ces grands classiques : le service qui refuse de démarrer après une mise à jour, des erreurs SQLite louches dans , ou pire — l'interface qui tourne mais ne remonte plus aucun heartbeat. Dans 90 % des cas, c'est la base SQLite qui a pris cher, souvent à cause d'un arrêt brutal du conteneur LXC ou d'une migration qui s'est mal passée.\r\n\r\nAvant de paniquer et de tout réinstaller, il y a une série d'étapes à dérouler. Je les mets ici dans l'ordre, parce que l'ordre compte : on commence toujours par le moins destructif.\r\n\r\nPourquoi SQLite et pas un vrai SGBD ?\r\n\r\nPetite parenthèse pour les juniors qui se demanderaient. Uptime Kuma embarque SQLite parce que c'est une appli pensée pour être facile à déployer : pas de serveur de base à installer à côté, pas de credentials à gérer, juste un fichier sur le disque. C'est génial pour démarrer, mais ça a un défaut majeur — SQLite n'aime pas du tout être coupé en plein milieu d'une écriture. Si ton LXC tombe pendant que Kuma écrit un heartbeat, tu peux te retrouver avec un fichier corrompu. D'où l'importance de toujours arrêter proprement le service avant de toucher au fichier.\r\n\r\n1. Arrêter le service proprement\r\n\r\n\r\n\r\nC'est la première chose à faire, toujours. Tant que le service tourne, il a un verrou sur et il continue d'y écrire. Tu peux ouvrir le fichier en lecture avec malgré ce verrou, mais dès que tu veux faire un ou un , tu vas soit avoir une erreur , soit — pire — corrompre encore plus la base si tu forces.\r\n\r\nVérifie que c'est bien arrêté avant de continuer :\r\n\r\n\r\n\r\nTu dois voir . Pas , pas , pas avec un process encore en l'air.\r\n\r\n2. Aller dans le dossier de l'app\r\n\r\nLe script communautaire installe Kuma dans :\r\n\r\n\r\n\r\nDans ce dossier, ce qui nous intéresse c'est le sous-dossier . C'est là que vit tout ce qui compte : le fichier (la base), les uploads, et quelques fichiers de config. Le reste (, , etc.) c'est le code de l'application — tu peux le casser, un ou une réinstallation le remettra en place. Mais , si tu le perds, tu perds toute ta config de monitoring.\r\n\r\n3. Sauvegarder avant de toucher à quoi que ce soit\r\n\r\nRègle d'or de l'ops : on ne touche jamais à une base de données sans avoir une copie au chaud. Jamais.\r\n\r\n\r\n\r\nLe te génère un suffixe du genre . Comme ça si tu fais plusieurs interventions dans la même semaine, tu sais laquelle date de quand, et tu ne risques pas d'écraser une sauvegarde par une autre.\r\n\r\nCette copie embarque :\r\nla base elle-même\r\nles fichiers WAL (, ) si SQLite est en mode Write-Ahead Logging — c'est important de les prendre avec, sinon ta sauvegarde est incomplète\r\nles uploads et certificats si tu en as\r\n\r\nSi tu sautes cette étape et que tu te plantes à l'étape 5 ou 6, tu n'auras aucun moyen de revenir en arrière. Sérieusement, fais-le.\r\n\r\n4. Vérifier l'intégrité de la base\r\n\r\n\r\n\r\n, c'est la commande de diagnostic native de SQLite. Elle parcourt toute la base, vérifie que les index pointent bien sur les bonnes lignes, que les pages ne sont pas corrompues, que les contraintes sont respectées. Deux issues possibles :\r\n* : la base est saine sur le plan structurel. Si Kuma ne démarre toujours pas, le problème vient probablement d'une migration coincée (voir étape 5) ou du code de l'app, pas du fichier.\r\nUne liste d'erreurs : il y a de la corruption. Selon ce qui est touché, on passera à l'étape 5 ou 6.\r\n\r\nPour les juniors qui découvrent SQLite : , c'est le mot-clé que SQLite utilise pour les commandes qui ne sont pas du SQL standard — c'est spécifique à SQLite, tu ne le verras pas dans PostgreSQL ou MySQL.\r\n\r\n5. Supprimer un paramètre de migration corrompu\r\n\r\nSur certaines versions de Kuma (notamment autour des montées de version qui touchent à l'agrégation des heartbeats), il y a un bug connu : l'entrée dans la table se retrouve dans un état incohérent, et le service refuse de démarrer parce qu'il pense être au milieu d'une migration qui n'avance plus.\r\n\r\nLa fix :\r\n\r\n\r\n\r\nCe qu'on fait, c'est qu'on dit à Kuma : \"oublie où tu en étais, repars de zéro sur ce point\". Au redémarrage, il va recréer la clé proprement et relancer la migration depuis le début. C'est non destructif pour tes données de monitoring — on ne touche qu'à un drapeau d'état interne.\r\n\r\nSi ce n'est pas ton problème (clé absente ou suppression sans effet), passe à la suite.\r\n\r\n6. Solution radicale : vider la table \r\n\r\nSi la corruption est concentrée sur l'historique de monitoring (et c'est souvent le cas, parce que c'est la table où Kuma écrit le plus souvent — un INSERT toutes les 20-60 secondes par sonde, ça finit par faire du volume), tu peux la vider :\r\n\r\n\r\n\r\nÀ lire attentivement : cette commande supprime tout l'historique des sondes. Tu perds les graphes de uptime, les SLA calculés sur les 30/90/365 derniers jours, tout. En revanche :\r\ntes sondes sont conservées (table )\r\ntes utilisateurs aussi (table )\r\ntes notifications également (table )\r\nta config générale est intacte (table )\r\n\r\nC'est à utiliser uniquement quand :\r\npointe vers des problèmes sur ou ses index\r\nKuma refuse de démarrer et l'étape 5 n'a rien donné\r\nou plus simplement, ta base a tellement grossi que Kuma rame et que tu acceptes de perdre l'historique pour repartir propre\r\n\r\nTant qu'à faire, profites-en pour faire un derrière, qui va vraiment libérer l'espace disque (un seul ne récupère pas la place sur le disque, il marque juste les pages comme libres pour réutilisation) :\r\n\r\n\r\n\r\n7. Redémarrer le service\r\n\r\n\r\n\r\nEt vérifie qu'il a bien démarré :\r\n\r\n\r\n\r\nTu dois voir . Si tu vois ou si le service redémarre en boucle, ne le laisse pas dans cet état — passe directement à l'étape 8 pour comprendre pourquoi.\r\n\r\n8. Lire les logs\r\n\r\n\r\n\r\nLe cible le service, le fait du (équivalent de ) — les nouvelles lignes s'affichent en temps réel. Laisse tourner pendant deux ou trois minutes, le temps que Kuma rejoue ses migrations, recharge ses sondes, et envoie les premiers heartbeats.\r\n\r\nCe qu'il faut chercher dans les logs :\r\nerreurs SQLite : , , — ça veut dire que t'as encore un problème de fichier, voire de permissions\r\nmigrations bloquées : des messages du genre qui ne sont jamais suivis d'un \r\npermissions : , — typiquement après une intervention faite en root sur des fichiers qui doivent appartenir à un autre utilisateur. Vérifie avec que les fichiers sont bien possédés par l'user qui fait tourner le service\r\nmodules Node manquants : — ça arrive après une mise à jour qui s'est mal passée. La fix, c'est généralement de relancer dans \r\nport déjà utilisé : — tu as un autre process qui squatte le port 3001 (ou celui que tu as configuré)\r\n\r\nPour sortir du , c'est .\r\n\r\nEt après ?\r\n\r\nUne fois que Kuma tourne propre, prends cinq minutes pour mettre en place ce qui t'aurait évité d'arriver ici :\r\n\r\n1. Une sauvegarde régulière de . Un simple cron qui fait du dossier vers un autre serveur, ça suffit largement pour un Kuma perso. Pense à arrêter le service avant le tar, ou utilise qui fait un snapshot cohérent sans devoir couper Kuma.\r\n2. Un monitoring du monitoring. Oui, c'est méta. Mais si Kuma tombe, c'est lui qui t'aurait alerté de la chute de tes autres services — donc personne ne te prévient. Un check externe (UptimeRobot gratuit, healthchecks.io, ou un autre Kuma sur une autre machine) qui ping ton instance, c'est cinq minutes à mettre en place.\r\n3. Garder ta sauvegarde au moins une semaine** avant de la supprimer. Au cas où un effet de bord apparaîtrait quelques jours plus tard.\r\n\r\nEt voilà. Avec ces huit étapes, tu couvres 95 % des cas de Kuma cassé. Pour les 5 % restants — typiquement quand le LXC lui-même a un souci de filesystem — c'est une autre histoire, et il faudra sortir l'artillerie côté Proxmox."}] |