[{"uuid":"d01088b3-ce3f-4815-8096-ff2a7a958dec","slug":"20201129-url-non-valide-dans-le-champ-id","title":"URL non valide dans le champ \"id\"","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-11-29 23:12:26","created_at":"2020-11-29 23:12:26","updated_at":"2020-11-29 23:12:26","tags":[],"plain":"Erreur trouvée dans Google Search avec un site Internet fabriqué avec WordPress.   URL non valide dans le champ \"id\""},{"uuid":"2963b0cc-7055-4114-b5db-d370a6184d3e","slug":"partitions-disques-toujours-disponibles-avec-linux","title":"Partitions et disques toujours disponibles","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 15:01:11","created_at":"2023-02-09 15:01:11","updated_at":"2023-02-09 15:01:11","tags":[],"plain":"Commandes abordées dans cet article :    Fichier édité dans cet article : \nPhrase philosophique\nOn ne monte pas un disque, on monte des partitions. Monter un disque dur au démarrage Points de montage\nPour ajouter un ou plusieurs partitions, il faut utiliser un dossier comme point de montage. J'ai pris par habitude depuis Fedora Core 3 de les ajouter dans le dossier . Sur d'autres distributions et habitudes, le dossier des points de montages se trouve dans . A vous de choisir entre  et . Information sur les partitions\nIl est primordial de référencer les partitions par leurs  vues par le système. Quelque soit le port où est branché le disque, l'id sera toujours le même. La commande blkid permet d'afficher le partuuid ou l'uuid : Le système retourne les informations suivantes : Le disque sda (de 80 Go) est réservé au système Linux.\\\\\nCe sont les partitions des disques sdb, sdc, sdd et sde que je veux monter.\\\\\nToutefois, pour une raison ou une autre, les disques peuvent être affecter différemment de sdb, sdc, sdd ou sde. De ce fait, je conseille d'utiliser l'identifiant de disque, appelé UUID. Modification du fichier /etc/fstab\nDès qu'on connaît les UUID des partitions, on peut les renseigner dans le fichier .\nIl faut modifier le fichier  avec les droits root pour qu'à chaque démarrage de l'ordinateur les partitions soient montées. Monter les disques durs sans redémarrer\nAprès avoir modifier le fichier  et les dossiers créés, il faut utiliser la commande  avec les droits  afin de monter les disques durs immédiatement : Voir aussi"},{"uuid":"eaa75131-5d97-4a9b-a48b-ceeb23d1370d","slug":"create-raid","title":"Créer un système RAID","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 11:28:46","created_at":"2023-02-09 11:28:46","updated_at":"2023-02-09 11:28:46","tags":[],"plain":"<note important>Attention, les disques utilisés seront entièrement effacés durant les opérations.</note> Instructions\nL'objectif est de créer un système RAID avec deux disques durs physiques. J'utilise l'application mdadm\n  sudo apt install mdadm\n  \nOn prépare les deux disques\n  sudo dd if=/dev/zero of=/dev/sda bs=256M count=1\n  \n  sudo dd if=/dev/zero of=/dev/sdb bs=256M count=1 On créer une partition primaire sur le disque sda\n  sudo parted /dev/sda Puis dans parted, sélectionner :\n  mklabel gpt\n  print\n  mkpart primary 0% 100%\n  print\n  quit On reproduit le même scénario pour sdb On créer le RAID  mirror avec mdadm\n  sudo mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1 On obtient un disque RAID nommé /dev/md0. On créer la configuration\n  sudo -i\n  mdadm --detail --scan >> /etc/mdadm/mdadm.conf\n  exit On formate le disque /dev/md0 en ext4\n  sudo mkfs.ext4 -v -m .1 -b 4096 -E stride=32,stripe-width=64 /dev/md0 Utiliser le disque RAID\nVous pouvez le monter sur votre machine\n  sudo mkdir /mnt/md0\n  sudo mount /dev/md0 /mnt/md0\n  sudo chmod -R 777 /mnt/md0 Si vous perdez votre RAID, vous pouvez le ré-affecter\n  mdadm /dev/md0 -a /dev/sdX0\n  \nMonter automatiquement votre RAID\n  sudo blkid\n  sudo nano /etc/fstab\n    UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /mnt/md0 ext4 defaults 0 0"},{"uuid":"593c8ceb-9071-4db8-85a4-2bca8a98774f","slug":"40-20200601-ssd-sur-raspberry-pi","title":"SSD sur Raspberry Pi / Passerelle, DNS et DHCP : le réseau à la maison","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-06-01 09:13:29","created_at":"2020-06-01 09:13:29","updated_at":"2020-06-01 09:13:29","tags":[],"plain":"Voici un rapide tour des informations que je traite dans ce 40ème épisode : SSD sur Raspberry Pi / Passerelle, DNS et DHCP : le réseau à la maison Je vous parle de deux sujets : le branchement d'un SSD sur Rasbperry Pi et le fonctionnement du réseau IP à la maison. Cette page est amenée à évoluer. Réagissez à cet épisode dans la partie  [Épisode disponible sur https:info.mindcast.fr/]\n-- Est-ce qu'un disque dur branché sur un Raspberry Pi 2 est vraiment utile ? Evidemment, je pose la question d'un point de vue de performance, car le RPI est limité par la présente de ports USB 2.\nJe vous présente comment j'ai préparé mon disque dur et je réalise les tests de performances. Les commandes utilisées dans cette vidéo sont :\nlsblk - lister les périphériques de type bloc\nblkid - lister les id des périphériques de type bloc\nrsync - copier et synchroniser les fichiers\ndd - copier en bloc, me permet de faire des tests de performance d'écriture\niostat - statistique sur les périphériques Les fichiers modifiés dans cette vidéo sont :\ncmdline.txt dans la partition '/boot' de la carte SD\n/etc/fstab dans la partition '/' du disques dur externe La première partie de la vidéo indique comment j'ai préparé le disque dur.\nCette étape est interessante car je vous indique comment copier les données de la carte S vers le disque dur externe sans casser toutes les permissions et propriétaires des différents fichiers.\nLa méthode utilisée permet de toujours conserver le moyen de démarrer la carte SD en cas de défaillance du disque (mauvais branchement USB, mauvaise alimentation électrique, defaillance mécanique...). Le secondes partie, vous dévoile les moyens logiciels pour évaluer les performances d'écriture sur un périphérique. Ces moyens sollicitent énormément la RAM, donc il faut les utiliser avec précaution. En conclusion, même pour une carte comme le Raspberry Pi 2 qui ne possède qu'un Port USB, avoir un disque dur externe branché en autoalimentation sur USB, ça vaut franchement le coup pour des questions de débit d'écriture sur le disque. Vidéo disponible sur la chaine Youtube 'S'informer sur la Tech' https:youtu.be/MDzLiVKCeXE\n-- Comment fonctionne le réseau à la maison ? Pourquoi avons-nous besoin de routeur ? Pourquoi un DHCP est utile ou inutile ? Comment mettre en place un filtrage Internet ? Première vidéo incontournable, d'une longue série, très instructive et qui permettra de poser de bonnes bases pour la suite. Je vous recommande de passer un moment dessus pour enfin assurer la maitrise de votre réseau domestique. Les commandes utilisées sont ,  et . Vidéo disponible sur la chaine Youtube 'S'informer sur la Tech' https://youtu.be/qs-J9oXkUEA"},{"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."}]