• https://ban.netlib.re/shaarli/?do=rss . IPv6 capricieuse (ne fonctionnait pas en début d'aprem, fonctionne depuis le milieu d'aprem).

Hum, en fait ma v6 était cassée depuis une migration de mon « hébergeur » (wink wink à l'intéressé) et j'avais pas mis à jour ma zone. Maintenant c'est fait, ça devrait marcher. Par contre, je ne comprend pas comment tu pourrais avoir revu ma v6 fonctionner, elle était juste obsolète depuis un moment…

C'est vrai, mais il y a une limite à ce raisonnement : pour qu'un gus prenne sur lui l'étude d'un autre logiciel (libre ou pas, ce n'est pas mon sujet), il faut que celui-ci soit techniquement ou qualitativement supérieur à la norme. Or, winwin versus nux ou MS Office versus LibreOffice, y'a pas de différence quand t'es une secrétaire. Les deux vont faire chier (si, nux peut faire chier), les deux permettent de saisir le courrier demandé par le boss, sur les fonctions de base, GIMP apporte rien par rapport à Photoshop (et inversement), etc. C'est juste une guéguerre de chapelles (genre en vrai winwin, quand t'as compris la logique, que tu t'es formé, que t'as les bons outils d'administration et les bonnes pratiques, ça juste fonctionne aussi bien que nux, faut arrêter de mentir). Donc quand tu vois l'ordi comme un simple outil pour faire le taff demandé afin de toucher ton salaire, t'en a rien à faire d'une alternative tant que ça t'apporte rien, que ça ne te simplifie pas la vie, que ça ne te permet pas d'aller plus vite (et même, si le boss s'en rend compte et qu'il te file plus de taff, t'as rien gagné, donc, parfois, faut pas chercher à optimiser son temps), etc.

On est d'accord, l'ordinateur, le logiciel, ce sont des outils, et tant qu'ils font ce qu'on leur demande, pourquoi en changer ? Et même si j'ai pris le chapeau melon du libriste évangéliste pour rebondir sur ta remarque, ce n'est (plus) mon cas, et je n'ai plus l'énergie à mettre dans ce débat avec des gens désintéressés, que je ferais d'ailleurs probablement plus chier qu'autre chose.

Je voulais juste souligner que l'homme est une créature aux habitudes tenaces. Même une solution "techniquement ou qualitativement supérieur" sera souvent ignorée car demandera une réadaptation ; il faut donc que cette solution apporte vraiment quelque chose de tangible à l'utilisateur, et que l'utilisateur s'en rende compte pour qu'il décide de faire l'effort de s'adapter.
Et même si c'est un trait humain des fois déplorable, il a de très bonnes raisons d'être également, et je le vois (parfois à regret) sur moi aussi : je n'apprend pas à utiliser certains outils qui je sais me simplifierait certaines tâches, car je pense que le facteur "temps perdu avec ma technique actuelle"/"temps d'apprentissage de la solution" est trop bas pour moi -- souvent par ce que ce sont des tâches relativement rares. En résumé, des fois le pragmatisme de "juste arriver au résultat" gagne sur "choisir l'outil techniquement et qualitativement supérieur".

En gros, si je devais faire plus court : je ne blâme pas le salarié lambda, il a raison de ne pas se poser de questions, car, dans l'écrasante majorité des cas, ça lui apportera aucun avantage. C'est mon point de divergence avec toi.

En fait on ne diverge pas vraiment, moi non-plus je ne blâme pas cette personne. Je ne blâme pas grand monde en fait, les outils qu'ils choisissent restent leur problème. Ça me gène un peu plus quand on impose un outil privateur, voir pire, qu'on oblige à signer des CDG douteuses, ce qui arrive de plus en plus (et même moi j'en signe plus que de raison, soyons réaliste), mais je m'éloigne pas mal du sujet.

• "Faire du graphisme / de la retouche avec GIMP ?! Vous êtes sérieux ?! Vous avez déjà essayé, au moins ?! Faites pas chier, je veux mon Mac, mon Illustrator et mon Photoshop. Laissez-moi exercer mon métier !".

Bref, arrêtons d'utiliser nos arguments d'informaticiens (libre = pas sûr, pas pro, gnagna), le débat avec les utilisateurs n'est pas du tout sur ce terrain. On est sur de l'affect (comme la deuxième personne sus-citée qui se sentait clairement dévalorisée de ne pas avoir de MS Office : pour elle, le prix qu'on met dans son environnement de travail est un indicateur de l'attention qu'on lui prête, et quand t'es payée que dalle sans possibilité d'évolution, je comprend qu'on se rattache à ce genre de choses), sur un effet de réseau / marketing (premier point), et sur un manque d'alternatives crédibles sur certains métiers couplé à un melon des libristes qui sont convaincus que leur solution fait le taff sans connaître celui de la personne à laquelle ils proposent une alternative trop-trop meilleure.

Je vais faire mon libriste au melon démesuré, mais pour ce dernier point je pense que tu ne couvre pas l'ensemble du problème qui est aussi en grande partie que les "alternatives" libres ne sont pas le même logiciel, et ne s'uitlisent pas pareil. Au final la qualité de l'outil n'a que peu de rapport avec la question, la question est beaucoup que la personne est là pour faire son taf, pas pour prendre en main quelque chose de nouveau.

J'ai envie d'inventer un exemple : va proposer à un gars d'un studio d'animation qui utilise un autre outil de passer au logiciel 3D Blender, pourtant reconnu par de nombreux "pros" comme excellent (pour certaines tâches à minima) voir meilleur que les alternatives non-libres. Il n'aura très probablement ni le temps ni l'énergie d'apprendre ce nouvel outil, sauf s'il est lui-même intéressé et prend sur son temps perso.
Au final, c'est presque l'histoire du gars qui essaie d'attraper des poissons avec ses mains et qui n'a pas le temps d'apprendre à utiliser un filet par ce qu'il doit attraper des poissons (oui, c'est une caricature, et elle biaise mon propos :)

Il y a des choses intéressantes, mais il manque ce qui me semble le plus important pour toute idée de défensivité en (Ba)SH : le quoting. Il faut grosso modo quoter toutes les variables, sauf cas particuliers. Par exemple, le snippet tout simple utilisé pour obtenir PROGNAME a un comportement probablement inattendu si $0 contient des espaces :

# avec un script "/tmp/foo bar.bash" :
$ bash foo\ bar.bash 
foo
# avec un script "/tmp/a b c d.bash" :
$ bash a\ b\ c\ d.bash 
basename: extra operand ‘c’
Try 'basename --help' for more information.
# ouch.

Tout ça est dû au fait que sans quoting, l'expansion des variables est sujette au découpage de mots et l'expansion des chemins (pour le fun, essayer avec un script nommé *), ce qui est en général (très) dangereux. La solution est simple : quoter toutes les subsitutions (ce qui inclus $()), et par exemple le PROGNAME devient readonly PROGNAME=$(basename "$0"). On note ici la seule exception : l'assignation à une variable, qu'il n'est pas nécessaire de quoter, mais je recommanderais de toujours quoter, même ça, par ce que ça protège par exemple d'une erreur de refactoring.

Aussi comme le mentionne Sky dans son commentaire (au milieu du reste), utiliser set -e (avorter le script si une commande dont le retour n'est pas vérifié échoue) est une excellente pratique qui évite une cascade de problèmes lorsque une commande échoue de façon inattendue, que je recommande fortement pour tout nouveau script.
À noter cependant que ça ne marche pas dans tous les cas qu'on pourrait attendre, par exemple foo=$(false) ne terminera pas le script (car la commande est considérée comme vérifiée). J'ai l'habitude d'avoir une fonction du style die() { echo "$@">&2 ; exit 1; } et de vérifier également ce type d'assignation en utilisant foo=$(false) || die "failed to do something".

(Via https://sebsauvage.net/links/?u4kZDg)

Je ne vois même pas comment on peut imaginer qu'une telle application soit pertinente, du moins si on ne dispose pas de moyen d'identification des cas efficaces, rapides et en grande quantité (les fameux tests) : l'application elle-même ne pourra qu'émettre des suppositions puisqu'elle n'a pas accès à des données fiables, mais peut au mieux détecter des situations à risque. On a deux possibilité : soit l'application est très encline à reporter des cas et on obtiendra obligatoirement une énorme quantité de faux-positifs (gens non-contaminés avertis), soit l'application est conservative et risque de créer de nombreux faux-négatifs (gens contaminés non avertis). Si on a beaucoup de faux-positifs, il faut pouvoir aisément et efficacement tester ces cas, et on risque dans tous les cas de créer un sentiment d'inefficacité et donc une baisse de l'utilisation. Si on a beaucoup de faux-négatifs, ça ne sert pas à grand chose, voire crée un faux sentiment de sécurité et un relâchement.

J'ajouterai que l'idée même d'une "appli" pour ce genre de situation me semble être un effet de mode, qu'on cherche à rendre l'informatique magique, la solution à tous les problèmes. Oui, l'informatique peut aider à traiter des données, mais non, elle ne peut pas les générer de nulle part. Je n'arrive pas à savoir si le gouvernement pense qu'ils sont obligés de proposer un outil informatique pour plaire aux citoyens, ou si eux-même croient au miracle de l'informatique et qu'aucun "expert" n'a noyé leurs illusions.

Via je ne sais plus qui… j'avais Guigui en tête mais je ne retrouve pas, donc allez savoir.

Aussi sur le même sujet (toute la forme ne me parle pas, mais grosso je suis d'accord) : https://grisebouille.net/stopconneries/ (via https://sebsauvage.net/links/?J9rs8A)

In Git 2.9, you can now ask it to filter the diffs [interactive staging] shows through any script you like:

$ git config interactive.diffFilter diff-highlight

When you change a swap partition (let's say you removed and added a new one because you wanted to change paritions layout on a non-LVM setup, and swap contents is not something to bother keeping), you'll have to update /etc/fstab; but that's not actually enough. With only this, initramfs will wait for a bit and complain that the resume partition couldn't be found. This is due to the setting in /etc/initramfs-tools/conf.d/resume which should match your preferred swap partition. Once updated, don't forget to re-run update-initramfs -u -k all.

$ dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n

Points intéressants sur des corner-cases de NULL qui peuvent se révéler problématiques.

Pour ceux qui utilisent Adwaita sans compositing avec les versions récentes de GTK, il y a des bordures moches et larges autour des fenêtres. Meh. Bon moi j'ai mis un certain temps à essayer de faire quelque chose, par ce que bon, ça m'empêche pas non-plus de vivre. Mais c'est pas beau. Et ça bouffe de la place pour rien. J'ai découvert que c'était les ombres des "Client Side Decorations". C'était pas un bug, donc j'ai pas cherche beaucoup plus loin. Et aujourd'hui, je me suis bougé les miches pour ajouter le petit bout de CSS qui va bien et enlever ça.

Donc, dans ~/.config/gtk-3.0/gtk.css, ajouter :

/* remove window shadows & the extra border */
decoration,
decoration:backdrop,
messagedialog.csd decoration,
.solid-csd decoration,
.solid-csd decoration:backdrop {
    box-shadow: none;
}
.solid-csd decoration {
    padding: 0;
}

Très pratique quand pour accéder à un host on doit rebondir sur un autre.

La solution naïve est bien sûr ssh host1 -t 'ssh host2', mais il y a plusieurs problèmes :

• ne peut pas être automatisé proprement (autant que je sache) : pas de ssh unalias
• nécessite -t pour un shell interactif
• comme le second SSH est bêtement lancé sur la seconde machine, l'agent SSH local n'est pas disponible (on pourrait utiliser -A, mais ça apporte son lot de problèmes)

La solution via ProxyCommand est beaucoup mieux, puisque ça donne un proxy au SSH local lui-même, donc pas besoin de -t explicite, et pas besoin de forwarder l'agent (ça se passe normalement à travers le tunnel ainsi créé).
<edit> De plus, comme c'est une configuration au niveau de SSH, tout ce qui l'utilise en profite : scp, rsync, etc. </edit>
<edit2> Ajout de la version avec ssh -W à la place de nc </edit2>

J'en arrive personnellement à ça (avec les hosts renommés)

# jump to server2 through server1
Host server2
    ProxyCommand ssh -W %h:%p %r@server1
    # ou alternativement avec `nc` si ssh est trop vieux pour connaître -W
    #ProxyCommand ssh %r@server1 nc %h %p

Bien sûr ça se combine avec un alias local facilement :

# jump to server2 through server1
Host localalias
    Hostname server2
    ProxyCommand ssh -W %h:%p %r@server1

À noter que le lookup de server2 a lieu sur le proxy, donc un nom local au proxy marchera -- mais pas l'inverse, un alias local sur le client ne résoudra pas.

Aussi, puisque la commande proxy est un SSH, on peut lui passer toute option SSH (dans mon cas, -4 par ce que le lien IPv6 entre moi et l'host a une forte latence que le lien IPv4 n'a pas).

Pour "corriger" les dépendances d'un paquet Debian un peu foireux, il y a plusieurs solutions. La plus maligne est sans doutes l'outil equivs qui permet de créer facilement des paquets virtuels qui fournissent des noms et/ou dépendent d'autre paquets.

Mais il y a des cas plus compliqués, par exemple avec les conflits : si on a un paquet A qui dépend du paquet B¹, mais que B² est installé et est en conflit avec B¹, on ne peut pas simplement créer le paquet virtuel B¹ qui dépend de B², puisque B² n'accepte pas que B¹ soit installé.

Mais on n'abandonne pas, et vu qu'à ce stade on est entrain de faire des gros hacks bien sales, éditons le .deb de A à la main pour le faire dépendre de B² à la place de B¹.

Pour ça, il faut connaître le format des paquets Debian, mais justement la page Wikipedia liée nous dit tout. Donc, allons-y :

$ # on va travailler dans un dossier temporaire
$ mkdir /tmp/debhack && cd /tmp/debhack
$ # on extrait les fichiers du .deb
$ ar x ~/paquet-version_arch.deb
$ # on extrait les fichiers de contrôle (ici tar.gz, mais peut être d'autre formats de tar)
$ tar xzvf control.tar.gz
$ # maintenant on s'amuse avec le fichier `control` nouvellement décompressé.  On peut faire ce qu'on veut, là on va juste changer les dépendances donc
$ sed -e 's/B¹/B²/g' -i control
$ # on en profite pour changer la version du paquet
$ sed -e 's/Version:.*$/&+local1/' -i control
$ # et à partir de là on recrée notre paquet
$ tar czvf control.tar.gz control md5sums
$ # attention, l'ordre de debian-binary est important !
$ ar cr …/paquet-version_arch+local1.deb debian-binary control.tar.gz data.tar.xz

Et voilà, on a un .deb mis à jour et tout frais.
On aurait pu aller plus loin et modifier le contenu du paquet, changer la description et je ne sais quoi. Attention cependant si vous changez le contenu du paquet (data.tar.xz), car il y a des sommes de contrôle pour chaque fichier dans le fichier md5sums de control.tar.gz, donc il faudra aussi les mettre à jour.

Vous avez une application qui ne fonctionne pas comme il faut, et vous n'avez pas le courage de tout rebuild pour faire des tests ? Vous sortez GDB, normal. Après quelques recherches, vous trouvez que cette application oublie purement et simplement d'initialiser une de ses bibliothèques ? Pas de problème, on va injecter l'appel manquant.

C'est tout simple : ajouter un breakpoint là où l'on souhaite injecter l'appel (moi j'ai choisi main tout simplement : break main), puis lancer le programme (run). Quand le breakpoint est atteint, on appelle la fonction le plus simplement du monde avec call, et on reprend l'exécution comme si de rien n'était avec continue.
Et voilà, pas besoin de patch binaire :] (bon OK le faire à chaque lancement c'est super chiant, même si ça peut se scripter en envoyant des commandes sur l'entrée standard de GDB)

Pour que ça fonctionne il faut bien sûr soit injecter à une adresse connue (par ex. une fonction exportée), soit avoir les symboles de débogage pour que GDB puisse trouver l'adresse.

Petite commande sympa pour connaître la progression d'une opération sur des fichiers (cp, sha*sum, dd, etc.), qui semble marcher vraiment et qui est packagée dans Debian (unstable).

Testé vite fait (donc pas en détail du tout), mais ça a l'air bien pratique pour créer des itinéraires ou traces à la main.

Ever got annoyed how you get "root" as author in your etckeeper commits made through sudo? I do. The problem does not exist with etckeeper commit, but the etckeeper interface doesn't allow for committing only a subset of the changes (which is one of many Git super-useful features). So I want to use git commit. But it records myself as root.

The problem is that sudo makes us essentially root. One could argue that well, it's the point! Indeed it is, though here we want to get root's rights, yet still be ourselves. There are various possible solutions to this, and here are some:

1) use sudo -E. This tells sudo not to reset any of the environment variables, which keeps among other things $HOME, in which Git will find your .gitconfig. This is easy, but it's a nuclear option with a nuclear cloud coming back your way: you lose all security advantages of sudo's environment cleanup.

2) if you're the only one on the machine, you can set user.name and user.email in the /etc repository. But if you're gonna do this, it's arguable how useful it is to know who committed, as it'll still always be the same person, just not root.

3) manually pass --author to git commit. This is annoying, though.

4) set GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL/GIT_COMMITTER_NAME/GIT_COMMITTER_EMAIL variables in your environment (.profile, .bashrc, wherever you get them the way you want), and list them in sudo's env_keep configuration setting. This mostly just Does What You Want™ -- but beware! these environment variables take precedence over Git's configuration, so it will apply whenever you use Git, not only in /etc, and regardless of your user.name and user.email settings.

You can pick whichever solution you like the best (or find another one). A clever user could even write a script or shell function to wrap the git call to set the author info when appropriate (either a full wrapper being "smart", or a special named one for use when committing in /etc).

Bonus, because I'm so kind, here's a script that picks the values from the .gitconfig of the user that called sudo, and runs git with whichever argument you gave it:

#!/bin/sh

# set to the git executable
GIT=git

# if running under sudo, try and use the caller's git config
if [ -n "$SUDO_USER" ]; then
  if [ -z "$GIT_CONFIG" ]; then
    sudo_user_home=$(getent passwd "$SUDO_USER" | cut -d: -f6)
    [ -n "$sudo_user_home" ] && GIT_CONFIG="$sudo_user_home/.gitconfig"
  fi
  [ -n "$GIT_CONFIG" -a -f "$GIT_CONFIG" ] && export GIT_CONFIG

  [ -z "$GIT_AUTHOR_NAME" ] && GIT_AUTHOR_NAME=$("$GIT" config user.name)
  [ -z "$GIT_AUTHOR_EMAIL" ] && GIT_AUTHOR_EMAIL=$("$GIT" config user.email)

  [ -n "$GIT_AUTHOR_NAME" ] && export GIT_AUTHOR_NAME
  [ -n "$GIT_AUTHOR_EMAIL" ] && export GIT_AUTHOR_EMAIL
fi

exec "$GIT" "$@"

Can be put in e.g. /usr/local/sbin/etcgit or something similar and called instead of git. Or it could be used as a drop-in replacement for git itself (just set GIT to the absolute path to the real git so the script doesn't call itself recursively).

Of course, the script has to be in the PATH sudo uses (~/bin is not).

Le s_client d'openssl peut être très pratique pour effectuer des tests… sauf quand il quitte ou renégocie comme ça sans raison apparente.

En effet, en "mode interactif" (par défaut), s_client se croit malin de renégocier quand il voit une commande qui commence par R (par exemple un "RCPT TO" SMTP), et de quitter quand il voit une commande qui commence par Q. Particulièrement pratique lors d'une tentative d'AUTH LOGIN avec des identifiants/mots de passe dont le base64 commence par l'un ou l'autre…

Mais tout n'est pas perdu ! Il est possible de désactiver le "mode interactif" avec les options -quiet ou -ign_eof. Et là, plus de problèmes de renégociation ou de déconnexion intempestive.

En écho à http://shaarli.guiguishow.info/?QBpzwg

I wanted to create a new LV on one of my VGs, but I wanted it to be allocated at the end of the PV because I knew that I wouldn't want to extend it (or if I ever did, I wouldn't care about its content -- it was for a /tmp partition), and I wanted the LVs on that same PV to be able to extend linearly if possible. Basically, I wanted to create a new LV that wouldn't get in the way.

The only solution I found was kind of the nuclear one, but it works great: specify which Physical Extents (PEs) the LV should be allocated on. This can easily be specified to lvcreate as a :PEStart-PEEnd suffix to the PhysicalVolumePath argument.

But to provide the correct PE range, we first need to find what "correct" is here. For that, pvdisplay --maps comes in handy, showing how PEs are allocated on a PV. Once you got the free PE range(s), and the PE size, you can easily calculate how many PEs you'll need, and so which range to specify. Beware though, apparently if you want to allocate the very last PE, you should not specify it, but simply give an "open" range, like ":PEStart-": otherwise, lvcreate told me the range was incorrect (and if you guess it was a 0-based PE value and lower start and end by 1, you get 1 free PE at the end).

As you provide PE ranges, I suggest you provide the size of the LV in Logical Extents (LEs, --extents) instead of megabytes or gigabytes (--size) -- anyway you already calculated how many PEs you needed for the size you wanted.

I also chose to explicitly specify the allocation policy as contiguous, just to be sure LVM wouldn't try and be a smartass behind my back in case I messed up with my ranges.

In the end, I ended up with this command:

lvcreate --alloc contiguous -l768 -n NewLVName VGName /dev/mapper/PVName:37149-

And a pvdisplay --maps nicely shows I got free PEs only before that LV -- so you could extend the previous one even with the contiguous allocation policy.

PS: well, actually I didn't use this command exactly, because I didn't know about that last PE range issue, so I first allocated it one PE too short of the range I wanted. But then, I decided it was alright and just extended the LV by one PE, using lvextend --alloc contiguous -l+1 /dev/mapper/VGName-LVName /dev/mapper/PVName:37148-.

I had problems with selecting the device to use for early-networking, because apparently its name was not very stable (e.g. upgrade from Linux 2.6.26 to 2.6.32 had changed it a the time, but there was more), leading to my early networking to fail unexpectedly -- which is especially problematic if you need it to boot.

Trying once again to fix this, I noticed that the documentation of the ip kernel parameter specifies that the device might be empty and then the kernel with try to find the first that actually works:

<device> Name of network device to use. If this is empty, all
devices are used for RARP/BOOTP/DHCP requests, and the
first one we receive a reply on is configured. If you
have only one device, you can safely leave this blank.

Although this snippet is not very clear on whether it would work with a static IP, it does work just fine :)
So, if your setup has no risk of finding an inappropriate interface (e.g. if you only have one actually working in early boot) it's very handy to simply let the kernel choose for you.

Voilà un outil que je ne connaissais pas et qui peut s'avérer bien utile dans certains cas :)