Gérer l'état d'un serveur avec update-alternatives
Bonjour, J'ai souvent besoin de coordonner la bascule simultanée de plusieurs liens symboliques quand je bascule un serveur d'un état "En préparation" à son état "En production" (ou réciproquement). Dans l'état "En préparation", j'ai l'application toto qui doit utiliser le fichier prep.configtoto.conf et l'application foo qui utilise le fichier prep.configfoo.cfg. Dans l'état "En production", ces applications utilisent respectivement les fichiers prod.configtoto.conf et prod.configfoo.cfg. Outre les modifications de lien symbolique, la bascule d'un état à l'autre exige le re-démarrage d'un service ou un simplment rechargement d'un autre. Que pensez-vous d'utiliser le programme update-alternatives (que je connais très mal) et ses sbires pour cela ? Slts
Re : Re: Plantage suite à ajout de desktop icon dans /usr/share/applications/
Le mardi 8 août 2023 à 10:49, RogerT a écrit : > > xml a *toujours* été lourdingue ! > Aucun problème pour lire ou écrire du xml avec un interpréteur xml sans > s’empêtrer les yeux dans des crochets et les enfants. > Ou même, plus simple, avec un éditeur graphique de xml. > > Le truc important c’est de savoir quoi écrire. > > Je ne trouve pas d’API d’openbox. Ça existe ? > Ou au moins un xsd pour écrire un fichier xml qui soit bien formé ? > > Il y a beaucoup d’exemples dans la doc, à commencer par : > http://openbox.org/wiki/Help:Configuration > > Sais-tu la taille que peut prendre un très gros fichier rc.xml (qui semble > être LE fichier) ? > % wc -l .config/openbox/rc.xml 1009 .config/openbox/rc.xml Mon fichier de config fait 1009 lignes. Obconf fait un fichier de base, mais il n'y a pas beaucoup de possibilités d'actions, mais la base de l’apparence est là. https://packages.debian.org/bookworm/obconf Ou prendre celui de déjà plus complet. /etc/xdg/openbox/rc.xml Après ce que je trouve le plus intéressant, c'est les actions: http://openbox.org/wiki/Help:Actions Elles ne sont pas toutes documentées très en détail. Ce que j'apprécie, c'est la possibilité de simuler sommairement un Tiling window manager. 3 fenêtres qui occupe 1/3 de la largeur de l’écran 100 % de la hauteur , bien regarder -x (moins x): Alt-Win 1 (du pavé numérique) 0 0 33% 100% 33% 0 34% 100% -0 0 33% 100% Fenêtre 1/2 de la largeur 1/2 de la hauteur qu’on peut mettre haut gauche, haut droite, en bas, gauche, droite. 0 0 50% 50% 0 -0 50% 50% -0 0 50% 50% -0 -0 50% 50% La fenêtre s’étire jusqu’au bord de l’écran ou une autre fenêtre(faire pareil pour les 4 directions) : west Maximiser l’axe des X, (on fait pareil pour Y) Maximiser mais en gardant la décoration Sans la décoration : Ou bien virer la décoration sans maximiser C = contrôle A = Alt W = win Donc ça fait Alt-Ctrl b Avec ça tu peux manipuler tes fenêtres par raccourci, clavier comme dans Tiling window manager, tout en gardant les possibilités d’un window manager "normal" (stacking je crois). -- Benoît
Re: RIP VIM
Le Mon, 7 Aug 2023 11:22:23 +0200, "ajh-valmer" a écrit : > car VIM à partir d'une nouvelle version > a du mal avec les copier/coller. C'est pas plutôt la Widowisation de Linux qui a du mal a copier-coller, Gnome en tête ? Fusionner les presse-papiers est une solution de contournement.
Re: sauvegardes: Vorta/Borgbackup et Deja-Dup/Duplicity-Borgbackup-Restic (was: sauvegardes: Vorta/Borgbackup et Deja-Dup/Duplicity)
suite et fin du feuilleton Deja-Dup et sa compatibilité avec Duplicity/Borgbackup/Restic: - le paquet Deja-Dup 44.0 de Bookworm appelle systématiquement Duplicity même si on sélectionne Borg ou Restic dans les paramètres dconf - le paquet Deja-Dup 44.2 de Sid n'affiche pas la même interface que les paquets Fedora (.rpm) ou Flathub (flatpak): il n'y a pas d'onglet GUI où on peut choisir un autre backend que Duplcity. Je n'ai pas cherché à modifier les paramètres dconf. A priori le paquet Debian Sid se comporte comme le paquet Debian Bookworm: il appelle systématiquement Duplicity - Deja-Dup 44.2 (flatpak sous Debian ou rpm sous Fedora) propose un onglet GUI où on peut choisir parmi deux backends: Duplicity ou Restic. Autant le flatpak que le rpm fonctionnent correctement avec le backend Restic.
Re: Plantage suite à ajout de desktop icon dans /usr/share/applications/
> Le 8 août 2023 à 09:30, benoit a écrit : > > Le lundi 7 août 2023 à 15:27, RogerT a écrit : > > >> Merci de cette confirmation ! >> J’avais découvert openbox dans un PSL et trouvé super le fait de partir de >> zéro et pouvoir tout configurer avec un fichier xml. > > > Je voudrais juste tempérer mon enthousiasme, justement à propos du xml… > Demander à des humains de travailler dans des fichiers xml, c'est de la > maltraitance de cerveau ! ;-) > Le xml, c’était moderne au siècle précédant… ;-) > C’est peut-être bien pour les machines(communiquer entre elles ou avec > des GUI comme Glade pour GTK, bien que ça occupe une place de dingue > par rapport aux données transmises), mais est-ce « human-readable » ? > Déjà, c’est pas agréable à lire, mais à rédiger à partir de rien… > Comme dirait Coluche : « Déjà à manger c'est pas bon, mais alors à > vomir… » ;-) > > -- > Benoît xml a *toujours* été lourdingue ! Aucun problème pour lire ou écrire du xml avec un interpréteur xml sans s’empêtrer les yeux dans des crochets et les enfants. Ou même, plus simple, avec un éditeur graphique de xml. Le truc important c’est de savoir quoi écrire. Je ne trouve pas d’API d’openbox. Ça existe ? Ou au moins un xsd pour écrire un fichier xml qui soit bien formé ? Il y a beaucoup d’exemples dans la doc, à commencer par : http://openbox.org/wiki/Help:Configuration Sais-tu la taille que peut prendre un très gros fichier rc.xml (qui semble être LE fichier) ?
Re : Re: Plantage suite à ajout de desktop icon dans /usr/share/applications/
Le lundi 7 août 2023 à 15:27, RogerT a écrit : > Merci de cette confirmation ! > J’avais découvert openbox dans un PSL et trouvé super le fait de partir de > zéro et pouvoir tout configurer avec un fichier xml. Je voudrais juste tempérer mon enthousiasme, justement à propos du xml… Demander à des humains de travailler dans des fichiers xml, c'est de la maltraitance de cerveau ! ;-) Le xml, c’était moderne au siècle précédant… ;-) C’est peut-être bien pour les machines(communiquer entre elles ou avec des GUI comme Glade pour GTK, bien que ça occupe une place de dingue par rapport aux données transmises), mais est-ce « human-readable » ? Déjà, c’est pas agréable à lire, mais à rédiger à partir de rien… Comme dirait Coluche : « Déjà à manger c'est pas bon, mais alors à vomir… » ;-) -- Benoît
