Si vous utilisez "Mate" (avec "Metacity") vous avez du, comme moi, vous énerver avec ces foutues bordures de fenêtres tellement minces qu'agrandir légèrement une fenêtre tient du jeu de patience. 
En effet cette bordure qu'il faut "tirer" pour agrandir la fenêtre est tellement mince (un pixel de large) que, même avec une bonne souris, il est très difficile de positionner la souris juste sur cette fichue ligne, rien que le fait d'appuyer sur un bouton vous déplace en dehors de la zone sensible. 
La solution n'est pas très compliquée mais il faut effectuer quelques recherches pour trouver le bon fichier à modifier, la première chose est de savoir quel thème d'écran vous utilisez. 
Les explications qui suivent sont adaptées à la distribution Debian, je pense que Ubuntu doit être peu différent et que pour d'autres distributions le principe est le même à quelques racines de répertoires près. 
Allez dans le menu "Système --> Préférences --> Apparence" qui vous présente les thèmes disponibles, celui sélectionné apparait sur un fond de couleur différente. 
Pour moi le thème utilisé est "BlueMenta". Aller ensuite dans le répertoire "/usr/share/themes/BlueMenta" dans lequel de trouve un répertoire "metacity-1" qui contient, entre autres, deux fichiers "metacity-theme-1.xml" et "metacity-theme-3.xml", ce sont ces fichiers qu'il faut modifier, on se demande où est passé le fichier numéroté "2" ? 
La modification est très mince, 
Cherchez le paragraphe "General window layout". 
Repérez "left_width", "right_width" et "bottom_height" et passez la valeur liée, 1 par défaut, à une valeur de 3 ou 4 ce qui élargira la fameuse bordure de fenêtre au nombre de pixels spécifié permettant, enfin, de redimensionner facilement les fenêtres. 

    <distance name="left_width" value="1"/> 
    <distance name="right_width" value="1"/> 
    <distance name="bottom_height" value="1"/> 

Pour valider la modification il faut, bien sûr, sortir de la session courante et se reconnecter. LE REDIMENSIONNEMENT FACILE DE VOS FENETRES EST A VOTRE PORTEE ! Je viens de la faire sur une autre machine et ça a marché du premier coup, c'est quand même beaucoup plus reposant.  En regardant bien on voit une bordure (grise dans mon cas) qu'il est nettement plus facile de tirer à la souris pour adapter la fenêtre à nos envies. 
PS : cela marche de la même façon sur une distribution SUSE.

Les mises à jour doivent toujours être faites d'abord sur une machine de test ! 
J'en ai encore fait l'expérience (malheureuse) lors d'une mise à jour de la machine de test pour le site que vous consultez en ce moment. J'ai eu un premier ennui avec le changement de version (changement de version majeur de Mysql), mais la même mise à jour comportait une mise à niveau de Apache qui m'a aussi créé une chose bizarre et surtout ennuyeuse.

Suite à cette mise à jour, impossible de réussir un login sur le site. Administrateur ou user plus "simple" rien ne se passe ! Un message sybillin dans les logs Apache : 
File does not exist: /var/....../content 
et c'est tout !  
Après moult recherches, au passage j'ai appris comment modifier le mot de passe d'administration depuis Mysql, ce qui peut être utile pour ceux qui ont mauvaise mémoire .... j'ai enfin trouvé en "googlant" un peu des ennuis d'affichage avec Drupal lorsque la fonction "clean URL" se trouve désactivée. Je me suis rappelé que cette fonction faisait appel à un module Apache "mod_rewrite". Par acquis de conscience je me suis précipité dans le répertoire "/etc/apache2/mods-enabled" et la, pas de lien "mod_rewrite" correspondant à ce sacré module.

Après un beau "a2enmod rewrite" tout est redevenu normal et je peux accéder à Drupal en mode utilisateur ou administrateur.

La mise à jour Apache avait du désactiver ce foutu module et "oublier" de le réactiver ensuite.

Il arrive que des petits morceaux de RAM se mettent "en grève" et déclenchent des arrêts intempestifs de certains programmes. Cela se manifeste le plus souvent lors de traitements intensifs telles les compilations de noyaux. C'est ce qui m'est arrivé sur une machine assez ancienne pour laquelle je voulais installer un noyau récent. Le script de compilation abandonnait en route en signalant diverses erreurs telles des segfault; gcc visiblement se trouvais perdu, j'ai même eu un "oops" du noyau.

J'ai donc chargé le programme "memtest86" (apt-get memtest86) en prenant la version la plus récente disponible. Le programme s'installe pour démarrer au "boot", il ne reste alors qu'à rebooter et choisir l'exécution de "memtest86". Il faut le configurer pour une sortie des erreurs au format "BADRAM", frapper "c" au démarrage du programme et choisissez "Rapport" puis le format "BADRAM".

Après un temps certain .... prévoir une bonne heure pour un scan "consistant" et pas trop de mémoire vous pouvez voir apparaître au fur et à mesure sur l'écran les paramètres à utiliser pour BADRAM.

Le plus intéressant actuellement est d'utiliser ces valeurs dans GRUB (il faut disposer d'une version assez récente de GRUB2) sous la forme d'un paramètre "GRUB_BADRAM="0x.............,0x............" en utilisant les valeurs de la sortie écran de "memtest86".

Pour une Debian il faut aller voir dans /etc/default/GRUB où une ligne préfabriquée existe :

# Uncomment to enable BadRAM filtering, modify to suit your needs 
# This works with Linux (no patch required) and with any kernel that obtains 
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) 
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

J'ai effectué, sur une machine de test, la migration wheezy --> jessie. Un peu en avance sur la date officielle ... 
Suite à cette migration j'ai eu un problème avec synaptic qui démarre mais signale immédiatement une erreur :

et stoppe gentiment dès que l'on ferme la fenêtre sans donner possibilité de voir ce qui se passe.

Ce message :
 "The value 'wheezy-backports' is invalid for APT::Default-Release as such a release is not available in the sources"  
me semble bizarre car j'ai complètement mis à jour mon répertoire /etc/apt et qu'il n'y reste plus de fichiers contenant la chaîne "wheezy-backports" ! 
Après quelques recherches sur Internet je n'ai rien trouvé de bien probant et j'ai du me rabattre sur "strace" pour voir quels fichiers ce $*#?! de Synaptic ouvrait pour y trouver ce paramètre. 
Et je suis tombé sur l'endroit où ce brave programme pose ses paramètres : "/root/.synaptic" ... 
Un fichier "synaptic.conf" m'attire l'oeil, un petit "grep -i backports synaptic.conf" me donne immédiatement la réponse : 
synaptic.conf:  DefaultDistro "wheezy-backports"; 
Je supprime la ligne fautive et relance synaptic ... et le tour est joué. 

Ce bug a, bien sur, été soumis à Debian.

Le dernier ennui en date : la machine de Madame refuse de démarrer car elle ne trouve pas le disque « USERS » et reste en mode « reprise ».

Ce disque « USERS » est une partition LVM sur un RAID logiciel (RAID 1 , « miroir » /dev/md0), le device « STOCKAGE » est une autre partition LVM sur le meme RAID.
Après une petite enquête (journalctl -xb) je m’aperçois que les deux partitions contenant les données : USERS et STOCKAGE ne sont pas reconnues bien que le device /dev/md0 soit présent et que « cat /proc/mdstat » donne le « bon » résultat. Une tentative de montage « à la main » annonce que le device n’est pas trouvé !
Une tentative de lister les partitions LVM échoue, les commande vgdisplay, pvdisplay, lvdisplay sont absentes .... J’ai fait une mise à jour système hier mais je ne me souviens pas avoir vu que ces commandes avaient été supprimées ?

La ré-installation du paquet lvm2 résoud ce problème et la machine reboote « normalement » !

Encore un problème bizarre ?

Depuis la dernière mise à jour de mon système principal (Debian « unstable ») il m'était impossible d'accéder par « Nautilus » aux partages présents sur le réseau. Ceci n'était pas limité aux machines « Windows » mais touchait aussi les répertoires partagés par Samba sur d'autres machines Linux ou sur un NAS. Nautilus affichait un message du style « Nautilus coulnd not display this location ».

Après quelques recherches sur le mode de fonctionnement de Nautilus j'ai trouvé que Nautilus se servait des fonctions des paquets « gvfs…. ». 
Après comparaison de la liste des paquets présents avec une autre machine je me suis aperçu que le paquet « gvfs-backends » manquait … 
Je n'ai pas pu retrouver pourquoi ce paquet avait été désinstallé (erreur de manip ou dépendance intempestive) mais après ré-installation « Nautilus » fonctionne de nouveau normalement pour les accès aux partages de style "Windows".

J'ai constaté lors de la connexion à certaines machines par "ssh -X" que la redirection de X11 ne fonctionnait pas et tout appel à une application X donnait un message d'erreur du type :

E233: cannot open display

Après quelques recherches et tests une ligne du fichier /etc/ssh/sshd_config semble "coupable" et il suffit de modifier le paramètre "X11UseLocalHost" à "no" pour obtenir un fonctionnement correct de cette redirection. 

Petite curiosité, des machines sans cette option permettent pourtant le lancement d'applications X11 dans une connexion SSH, je n'ai pas compris le "truc". 
 

Lors d'une des dernières mises à jour de mes système Debian j'ai remarqué l'installation de "Apparmor", comme c'est un élément de sécurité j'ai laissé cette installation sans y toucher car je pensais que les règles installées étaient "convenables". 
Or j'ai eu un problème sur un DNS "bind9" secondaire car ce type de domaine esclave reçoit à chaque démarrage une mise à jour des zones gérées par le "maître" et Apparmor bloque cette mise à jour avec un message : 
apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" ... comm="named" requested_mask="c" denied_mask="c" fsuid=120 ouid=120 
Il est nécessaire de corriger le fichier "/etc/apparmor.d/usr.bin.named" en autorisant l'écriture dans le répertoire /etc/bind. 
Il suffit de trouver la ligne : 
/etc/bind/** r, 
Et de la remplacer par : 
/etc/bind/**  rw, 
Après un redémarrage de Apparmor "named" accepte de démarrer normalement.

Depuis une mise à jour d'un de mes systèmes j'ai constaté un phénomène de latence important lors d'une connexion réseau. Toute nouvelle connexion "consomme" un délai de 5 secondes, cela se voit bien avec "wget" qui donne toujours un temps d'exécution de 5 secondes ... et des broquilles.

Ce phénomène touche essentiellement la première connexion à un site, mais se manifeste aussi lors d'une connexion "ssh" et cela ajoute un délai important, attendre 5 secondes la demande de mot de passe est très énervant ! Pour les connexions suivantes on bénéficie du cache du DNS local.

Après quelques recherches je suis tombé sur différents articles impliquant la résolution DNS pour IPV6, j'ai donc, sans succès, limité le service DNS à IPV4 (option -4 de bind9). Comme cela ne résolvait pas le problème j'ai continué à chercher et trouvé sur une solution sur un site.

Le simple ajout dans "/etc/resolv.conf" d'une ligne (en rouge) :

search home 
options single-request-reopen 
nameserver 127.0.0.1 
nameserver 1.1.1.1

Résout ce problème du à des modifications dans la glibc, simple non ? 
Les connexions ssh sont redevenues rapides !
Depuis je met cette ligne dans les fichiers "resolv.conf".

Il m'est arrivé de devoir me connecter à distance (par ssh -X) et d'avoir besoin d'un accès à "mysql-workbench" pour vérifier commodément des bricoles dans une base de données. 
Le workbench se lance fort bien mais refuse de se connecter sur les bases en expliquant (à l'aide de vilaines boîtes de dialogue à croix rouge) qu'il ne pouvait pas accéder au "keyring" car il n'était pas débloqué. 
Ce déblocage est normalement fait à l'ouverture de la session X, mais, ici, pas de session X car la connexion pas ssh (même avec -X) ne s'occupe pas de ce genre de détail. 
Premier essai : 
Le lancement de seahorse ne permet pas de débloquer ce fichu keyring.

Deuxième essai : 
Il existe des bindings Python pour gnomekeyring, il faut donc charger le module pyrhon (2.7) qui va bien. 
pip install keyring 
Ensuite un mini module python permet de débloquer ce fichu "keyring" : 
#!/usr/bin/python2 
import gnomekeyring 
gnomekeyring.unlock_sync(None, 'mon_beau_mot_de_passe'); 
L'invocation magique de ce module permet ensuite de débloquer le machin et de pouvoir utiliser les mots de passe stockés dans ce keyring, et accéder au vrai problème, celui de la base de données. 
That's all folks.

Aujourd'hui petit ennui avec systemd.logind.service. 
Et en plus je suis loin de cette machine et je ne dois pas risquer de perdre la main, cette machine ne reboote pas toujours correctement (c'est un comble !) et elle est abandonnée car je suis en vacances, donc aucun moyen simple de la redémarrer. 
Premier symptôme : le login SSH est très long, de 30 à 40 secondes, mais il fonctionne. 
Deuxième symptôme : je regarde l'analyse des logs (rapidement avec l'interface Web d'OSSEC) et je constate qu'il y a plus de 20000 messages dans la catégorie "1002: unknown problem somewhere in the system". 
La liste des messages comporte N fois le même groupe de messages : 
Aug 25 01:22:32 portail systemd[1]: Starting Login Service... 
Aug 25 01:23:02 portail systemd[1]: systemd-logind.service: Start operation timed out. Terminating. 
Aug 25 01:23:33 portail systemd[1]: systemd-logind.service: Unit entered failed state. 
Aug 25 01:23:33 portail systemd[1]: systemd-logind.service: Failed with result 'timeout'. 
Aug 25 01:23:33 portail systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart. 
Aug 25 01:23:33 portail systemd[1]: Stopped Login Service. 
Et cela se répète environ toutes les 30 secondes .... de quoi remplir le log vite fait. 
Un petit tour sur Internet m' montré que ce type de "chose" est déjà arrivé mais que le problème est censé être résolu depuis assez longtemps ??? 
Finalement j'ai trouvé deux indications : 
1) regarder dans "/run/systemd/sessions" et y détruire les fichiers représentant les sessions, et il y en avait pas mal. 
Résultat pas merveilleux, après 30 secondes j'ai encore des messages ... 
2) Tenter un redémarrage des démons par "systemctl daemon-reexec" ... et là, super, les messages n'apparaissent plus et le temps de login est redevenu normal. Après deux heures plus aucun de ces fichus vilains messages. 
Mais je n'ai, malheureusement, pas d'explication valable pour ce phénomène et une analyse des logs sur deux semaines ne me montre pas d'autres groupes de tels messages. 
Le phénomène a commencé le 24 vers 16:16:32 et est précédé par des messages :
 "org.gtk.vfs.Daemon[31881]: A connection to the bus can't be made". 
J'ai eu un problème de multiples sessions interrompues vers ce serveur (liaison coupée plusieurs fois, c'était la France profonde) et de multiples processus "...dbus..." que j'ai du "killer" vers cette heure là. C'est peut-être ce qui a créé ce problème. C'est promis je ne recommencerais pas.

Depuis quelques temps je constatais un message incongru lorsque je redémarrais Apache :

"Failed to allocate directory watch: Too many open files"

Cela n'empêchait pas Apache de redémarrer mais cela m'intriguais un peu. Après pas mal de recherches je suis tombé sur la variable vm.max_map_count qui est, selon de nombreuses sources positionnée trop bas en standard et qu'il faut augmenter sérieusement. J'utilise pourtant beaucoup de machines Linux et je n'ai jamais rencontré ce type de problème ? 
La valeur indiquée couramment est 262144 que j'ai un peu réduite et utilisée avec succès ci dessous.

J'avais essayé de "forcer" un peu les valeurs de "nofile" dans le fichier /etc/security/limits.conf 
mais sans aucun succès. 
Après quelques recherches j'ai trouvé la bonne (?) variable kernel, visible par la commande :

sysctl -a | grep max_map_count

qui me retournait :  vm.max_map_count = 65530

En "forçant" un peu (euphémisme) cette valeur à 131072 le message a disparu, mais la consommation mémoire semble avoir augmenté, et j'ai du "forcer" un peu sur la mémoire de la VM.

Il faut donc impérativement surveiller la quantité de mémoire utilisée après ce type de manipulation.

Cette variable a très souvent une valeur insuffisante, le défaut de 65000 semble "gêner" beaucoup d'applications telles que Docker, des bases de données .... Elasticsearch ... et divers autres logiciels. 
C'est la première fois que je tombe sur ce problème mais il semble assez courant au vu du nombre de mentions sur le web mais cela se manifeste souvent par des messages très différents de celui qui m'a fait tiquer.

Il peut aussi être intéressant d'augmenter les valeurs des clefs suivantes : 
fs.inotify.max_queued_events = 16384 
fs.inotify.max_user_watches = 262144 
fs.inotify.max_user_instances = 2048

Les disques en RAID, dans mon cas du RAID1, c'est en principe très bien. On ne risque que peu de perdre ses données sur une panne de disque. Or les pannes peuvent arriver, même des pannes mettant hors service l'ensemble de la machine, j'ai vu un serveur ou tout avait "grillé", de l'alimentation aux disques système pourtant en RAID1. Comme quoi une bonne sauvegarde est un bien nécessaire, on ne le dira jamais assez. 
Revenons à mon ennui "bizarre" : il y a quelques jours un mail me signale que le device RAID md6 est en état de problème. 
Je regarde le statut de ces disques ( cat /proc/mdstat ) et un des devices est marqué défaillant. Les cas de désynchronisation d'un RAID1 ne sont pas une rareté (coupure de courant violente ...) mais dans la plupart des cas la resynchronisation est automatique et au bout d'un certain temps (voire un temps certain ?) le disque "fautif" ré-apparaît dans le device RAID et tout repart normalement. 
Dans mon cas le message me signalait une erreur "Rebuild33" ??? et le disque ne s'était pas resynchronisé. 
J'ai alors essayé de resynchroniser manuellement en :

"enlevant" la partition en erreur du device RAID  : 
mdadm --manage --remove /dev/pas_bon /dev/md6

"remettant" la partition dans le device  : 
mdadm --manage --add /dev/pas_bon /dev/md6

Et j'ai encore récupéré une erreur Rebuild33 ... 
J'ai alors testé la partition avec "badblocks" qui au bout de plusieurs heurs (#450Go) n'a signalé aucune erreur. Nouvel essai de resynchro qui me donne une erreur Rebuild40. La manip suivante a consisté à modifier le type de partition (de Linux Raid à Linux) et à formater cette partition récalcitrante en ext3, là non plus aucune erreur n'a été signalée. Je remet alors la partition en "Linux Raid" et retente une synchronisation qui se termine sur une erreur Rebuild80, le problème n'est donc pas encore résolu et je commence sérieusement à envisager de restaurer depuis une sauvegarde. 
Or ma sauvegarde date de quelques semaines et j'ai stocké "plein de choses" sur ce disque depuis.  
Je décide dons de retenter le coup :

• Passage de la partition en "Linux"
• Formatage en ext4

Quelques tests de copie pour "secouer" ce machin récalcitrant, prudent quand même car il y a une autre partition sur ce disque.

• Repassage de la partition en "Linux Raid"

Je retente la synchronisation et ... miracle ... la synchro se termine bien et le tout fonctionne maintenant depuis environ deux semaines sans autre problème.

J'ai quand même décidé de faire des sauvegardes un peu plus fréquentes, surtout quand j'ai bien travaillé et stocké des tas de trucs tels que des photos ajustées et retouchées avec amour et pas mal de temps.
J'ai aussi mis ces disques sur la liste des disques à changer .... prochainement.

Depuis quelques semaines j'ai reçu quelques message de mise en garde de "smartmontools" :

ou encore :

Vu que le nombre de secteurs à problème augmentait d'un message à l'autre j'ai décidé de changer le disque concerné. 
Ce disque fait partie d'un groupe de deux disques contenant trois partitions RAID1 (miroir). 
Premier problème, je n'ai pas sous la main de disque de 750GB mais un de 1TB, avec un partitionnement adéquat tout devrait malgré tout baigner. 
Détail des opérations :

• Mettre en place le nouveau disque dans la machine, heureusement il y avait un port SATA et une prise d'alimentation disponibles.

Le disque "KO" est /dev/sdc, le disque "OK" est /dev/sde et le nouveau s'est monté en /dev/sdd.

• Recopier le partitionnement :

• Ensuite, pour chaque partition effectuer les manipulations suivantes :

1. Signaler "cassé" le disque fautif du RAID : mdadm /dev/md125 --fail /dev/sdc1 Le groupe passe en mode dégradé.

2. Retirer ce disque du RAID

   mdadm /dev/md125 --remove /dev/sdc1

3. Insérer la nouvelle partition dans le RAID :

   mdadm /dev/md125 --add /dev/sdd1

   La synchronisation du RAID commence :

Il vaut mieux attendre la fin de la synchronisation avant de lancer les opérations sur la partition suivante afin de ne pas affoler inutilement les disques qui devraient trop agiter leurs petits bras d'une partition à l'autre ... 
Au total pour les trois partitions c'est très long ... 
Mais quelques heures plus tard les trois partitions sont OK sur des disques en bon état, c'est reparti pour un moment, du moins je l'espère.

Dans le même genre, et sur une autre machine, une salve de mails de "mdadm" me signale que les devices /dev/md0, /dev/md1, /dev/md2 sont passés en mode dégradé. 
Ces trois "devices" sont en miroir sur les deux mêmes disques : /dev/sdc et /dev/sdf, le disque /dev/sdf est bien présent mais une analyse par "fdisk" me montre que les trois partitions (400Go, 400Go et 1To) ne sont pas en "linux raid auto (code fd)" mais en partitions linux classiques. 
Je n'ai pas compris ce changement (???) et j'ai du appliquer la procédure ci-dessus pour les trois partitions, soit une perte de plusieurs heures, car il faut plus de 60 minutes pour une partition de 400Go et plus de deux heures pour la partitions de 1To.

Debian Jessie : problème installation extension Pack

L'installation de l'Extension Pack sur une Debian "virtualboxée" sous Windows n'est pas forcément évidente, si VirtualBox vous "monte" automatiquement l'image de CD des extensions aucune commande n'est exécutable directement depuis le CD pour des raisons de sécurité. 
Evidemment cela ne se produit pas "à la maison", pas de Windows ici, mais au bureau. Pour travailler sur des machines Unix/Linux il est plus intéressant de travailler avec une machine Linux ...

La solution :

Mais c'est très simple (à  faire en "root" évidemment ou au moins avec "sudo") :

1. Créer un répertoire bidon quelque part.
2. Copier le contenu du cd (cd le_répertoire ; cp -dpR /mnt/cdrom0/* . )
3. Dans ce répertoire exécuter :  "../VBoxLinuxAdditions.run "

Et c'est tout, mais il vaut mieux redémarrer la machine Windows et relancer la machine "virtualboxée" pour bénéficier des extensions. 
 

Cette semaine, après un redémarrage de la machine qui sert de frontal internet, le serveur DHCP du réseau ne fonctionnait plus. Après vérification le process /usr/sbin/dhcpd n'était plus présent et aucun message dans le log, merci systemd.

En lançant "à la main" :  
/usr/sbin/dhcpd -4 -cf /etc/dhcp/dhcpd.conf  
j'obtenais un message d'erreur me disant qu'aucun interface n'était déclaré et un arrêt du process ... une petite vérification dans "man" m'indique qu'il faut indiquer l'interface à gérer; Je relance donc avec : 
/usr/sbin/dhcpd -4 -cf /etc/dhcp/dhcpd.conf br1 
Et tout se passe bien, dhcp permet à certains clients de se connecter. 
Je regarde donc le script d'init et je m'aperçois que ce script fait référence à deux jeux de variables différentes XXXXXv4 et XXXXXv6, ce qui permet d'utiliser le programme en IPV4 ou en IPV6 (ou exclusif). Je me précipite sur le fichier /etc/default/isc-dhcp-server et, Oh horreur, celui-ci n'a pas été modifié lors de l'installation de la nouvelle version et la variable "INTERFACE" n'a pas été remplacée par INTERFACEv4 (avec un "v" minuscule). De même les variables DHCPD_CONF et DHCPD_PID n'ont pas été "éclatées" en leurs variantes v4 et v6. 
Après avoir mis en place les "bonnes" variables et valeurs dans "/etc/default.isc-dhcp-server" le process dhcpd démarre et fournit, normalement, des adresses aux clients. 
Mais une autre anomalie apparaît : certains clients "refusent" les adresses proposées avec un message tel que : 
DHCPDECLINE of 192.168.2.xxx from xx:8d:xx:be:xx:be via br1: not found 
Une petite recherche parmi les différents clients utilisant cette connexion montre que un portable Windows10 (pas à moi !) se connecte normalement, un portable Linux (le mien) se connecte normalement, un téléphone Samsung se connecte normalement, seuls les matériels Apple (Iphone 5c, Iphone 6, tablettes) refusent les adresses offertes malgré de nombreux essais, y compris avec l'option "oublier ce réseau" suivie d'une nouvelle tentative ! 
Comme il était tard j'ai remis le recherche de la suite au lendemain. Mais en revérifiant le matin, tous les appareils Apple acceptaient de se connecter sans rechigner !!! 
Je n'ai pas cherché la cause, probablement une protection lors d'un changement de serveur DHCP pour limiter les possibilités de piratage ???

Après migration d'une machine de Stretch à Buster, redis-server ne démarre plus avec un message cryptique de systemd avec "status ... exit-code" qui ne renseigne pas beaucoup ... comme d'habitude avec systemd ! 
J'ai donc lancé redis "à la main et en root" redis-server /etc/redis/redis.conf qui m'a donné un démarrage sans erreurs et un log correct. 
Les fichiers de log dans /var/log/redis ne sont pas plus bavards au sujet de ce refus de démarrage... ils ne disent même rien du tout au sujet d'une erreur quelconque, comme c'est malheureusement souvent le cas avec systemd et semblent normaux pour les démarrages manuels. 
Il faut examiner le syslog pour trouver une réponse : 
syslog:Oct 12 17:06:27 k2000 redis-server[5973]: >>> 'logfile /var/log/redis/redis-server.log' 
syslog:Oct 12 17:06:27 k2000 redis-server[5973]: Can't open the log file: Permission denied 
En regardant le répertoire "redis" dans /var/log je vois qu'il ne se présente pas bien : 
drwxr-s---  2 hplip                    159     4096 oct.  12 17:06 redis 
Après un petit "sudo chown redis redis" tout rentre dans l'ordre et le service redis-server se lance normalement. 
Je n'ai pas réussi à trouver l'origine de cette erreur ..

• Oubli de positionner les bons droits sur le répertoire lors du passage de Stretch à Buster ? Pourtant le vieux script (dans /etc/init.d) demandait aussi un fonctionnement avec le user "redis".
• Destruction de users suivi de re-création résultant dans un changement de libellé pour cet ID ?
• ......

Question sans réponse à ce jour ...

Le lendemain, nouveau refus de démarrage, vite voir le syslog et ce fichu répertoire a changé de propriétaire !!! Je repasse le chown, et ça repart. Quel est le foutu script qui effectue ce changement de propriétaire ?

Quelques jours après, j'ai enfin trouvé ... La machine sur laquelle cela se produit dispose d'un double boot avec deux SSD différents (un boot avec Xen, l'autre avec VirtualBox), mais beaucoup de répertoires sont communs aux deux environnements : 
/home, /var/lib, /var/log et d'autres. 
Lors du passage de Stretch à Buster j'ai "passé" les deux mises à niveau à quelques semaines d'intervalle et, mais c'est bizarre, certains users ont du être détruits et recréés, bien sûr avec des ID différents. 
Lors d'un changement de boot les répertoires de redis se trouvaient avec un ID qui n'était pas celui de redis ... et donc cela plantait en "access denied". 
La seule solution que j'ai trouvée c'est de modifier les fichiers password, group et shadow pour remettre tout cela dans l'ordre. 
Depuis tout baigne.

Sauvegarde et restauration de disque.

L'utilisation de machines virtuelles c'est super, mais la machine "support" finit par être encombrée de partitions "inutiles". J'aime bien créer mes MV sur des partitions LVM. 
Il est souvent utile lors de "manip" hasardeuses d'avoir une sauvegarde "à jour" ... 
La suite de cet article décrit la méthode que j'utilise pour que les images sauvegardées ne soient pas trop volumineuses ... Un script de sauvegarde et un script de restauration suffisent.

Ces deux scripts gèrent la sauvegarde et la restauration globales du contenu d'un disque par exemple celui d'une machine virtuelle. 
Leur particularité est d'utiliser "lbzip2" que compresse/décompresse à la volée en utilisant plusieurs coeurs du processeur permettant ainsi une meilleure performance et donc une durée de sauvegarde plus courte ainsi qu'un espace de stockage réduit. 
Les deux exemples suivants utilisent deux coeurs pour leurs opérations, sur des machines plus "musclées" on peut augmenter ce nombre mais on risque alors d'être limité (moins avec des SSD) par la vitesse des disques ! Ils nécessitent l'installation de "lbzip2" qui permet de compresser un fichier en utilisant plusieurs coeurs de processeur et de "pv" qui permet de "voir" la progression de l'opération. 
Le premier script permet de sauvegarder rapidement et en utilisant le minimum de place. Le deuxième permet de restaurer une sauvegarde précédente rapidement. Trace d'exécution de la sauvegarde d'un disque de 48Go :

./SV_NEW_SHINKEN_BZ Sauvegarde disque /dev/mapper/VGC2-NEW_SHINKEN sur : /LOG/SV_VM/VGC2-NEW_SHINKEN.dd.bz2     
O/N ? O 
786432+0 records in 786432+0 records out 51539607552 bytes (52 GB, 48 GiB) copied, 417,953 s, 123 MB/s 48GiB 0:06:57 [ 117MiB/s] 
Il faut moins de 10 minutes pour sauvegarder ou restaurer une partition LVM de 48Go sur un système muni de deux SSD de stockage de 480Go.

Télécharger le script de sauvegarde.

Télécharger le script de restauration.

Ces scripts sont à renommer en ".sh" pour  faire plus professionnel !

Ennui "bizarre" lors d'une migration de bullseye à bookworm. 
J'ai déjà migré plusieurs systèmes (physiques ou virtuels) sans rencontrer le moindre ennui lors du passage de "apt dist-upgrade", mais ici j'ai rencontré un problème très bizarre.

dpkg: unrecoverable fatal error, aborting:
 unknown system user 'geoclue' in statoverride file; the system user got removed
before the override, which is most probably a packaging bug, to recover you
can remove the override manually with dpkg-statoverride

La commande : dpkg-statoverride --list retourne :

geoclue geoclue 755 /var/lib/geoclue
root postdrop 2555 /usr/sbin/postqueue
postfix postdrop 2710 /var/spool/postfix/public
root crontab 2755 /usr/bin/crontab
root ssl-cert 710 /etc/ssl/private
root messagebus 4754 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
root postdrop 2555 /usr/sbin/postdrop

On y voit bien ce fichu utilisateur "geoclue", pas de "geoclue" installé sur cette machine. 
la commande :  
dpkg-statoverride --remove /var/lib/geoclue 
supprime bien le chemin /var/lib/geoclue .

Mais d'autres essais mènent toujours au même type d'erreur, un "apt --fix-broken install" retourne :

Processing triggers for man-db (2.9.4-2) ...
/usr/bin/mandb: the setuid man user "man" does not exist
Processing triggers for install-info (6.7.0.dfsg.2-6) ...
Processing triggers for libc-bin (2.36-9+deb12u3) ...
Errors were encountered while processing:
 rpcbind
W: No sandbox user '_apt' on the system, can not drop privileges
E: Sub-process /usr/bin/dpkg returned an error code (1)

Après quelque recherche il s'avère que le système ne "sait" plus lire les users, par exemple la commande "id" donne : 
id 
uid=0 gid=0 groups=0 
Il semble que tous les ennuis viennent de cette non-reconnaissance des users ... 
Le fichier /etc/nsswitch.conf contient des valeurs "bizarres" non conformes à celles présentes sur d'autres systèmes, après correction de ce foutu fichier tout semble revenir à le normale et la commande "id" renvoie des choses beaucoup plus sympathiques : 
id 
uid=0(root) gid=0(root) groups=0(root)

Le passage de "apt --fix-broken install" retourne un message "normal" et depuis tout est OK sur cette machine.

En migrant une machine de Bookworm à Trixie j'ai rencontré le problème suivant :
MariaDB ne démarre pas !

Le fichier /var/log/mysql/error.log contient les messages suivants :
mariadbd[12932]: 2024-09-12 22:24:55 0 [ERROR] Can't find messagefile '/usr/share/mysql/>
mariadbd[12932]: 2024-09-12 22:24:55 0 [ERROR] Could not load error messages for french
mariadbd[12932]: 2024-09-12 22:24:55 0 [ERROR] Aborting

Cause :
Le programme cherche dans /usr/share/mysql ... mais celui-ci n'est pas un lien vers /usr/share/mariadb ... qui, lui, est "plein de fichiers" alors que /usr/share/mysql ne contient qu'un vieux fichier debian-10.5.flag de novembre 2021 !
La solution ;
cd /usr/share
rm -rf mysql
ln -s mariadb mysql
Puis : systemctl start mariadb
et ... ça démarre, c'est OK !
 

Ce petit, pour le moment, groupe d'articles est consacré à "systemd" que je n'apprécie guère car je le trouve compliqué en peu "usine à gaz", on est loin du Keep It Simple Stupid. 
Mais comme il est offert (obligatoire !) avec la plupart des distributions il faut faire avec.

• Mon portable sert à la maison et en voyage, donc avec ou sans "cable" réseau, systemd s'employait à me faire perdre mon temps ...
• J'utilise "SNMP" et son démon "snmpd" pour surveiller (non je ne dirais pas "monitorer") quelques services et la livraison "standard" de snmpd est fournie avec des paramètres de Debug qui "crachent" des monceaux de lignes dans les fichier log.

Problème majeur de "systemd". 
Lors des mises à jour les fichiers ".service" sont systématiquement écrasés, ce qui ne permet pas (pas facilement et c'est très peu utilisé) de "personnaliser" les paramétrages de manière stable. 
Du temps des fichiers "services" de "init.d" les paquets posaient une question, si vous aviez modifié le script, afin de ne pas perdre vos laborieuses modifications et sur Debian les fichiers de paramètres de "/etc/default" n'étaient jamais "écrasés" sans prévenir.
Dans le cas de SNMP à chaque mise à jour de "systemd" ou "snmpd" je me retrouve avec un "daemon.log" bourré de lignes : 
..... Connection from UDP: [192.168.W.XX]:40608->[192.168.Y.ZZ]:161 
qui finissent par représenter plusieurs mégaoctets d'informations parfaitement inutiles. 
Note ; j'ai retrouvé ce comportement sur des machines CentOS, il n'est donc pas spécifique à Debian.