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 :
ssh unalias
-t
pour un shell interactifLa 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 :)
Le monde n'est pas super clair à ce sujet, donc un petit tuto/récapitulatif :
1) il faut bien sûr commencer par monter le système de fichier racine qui contient les ecryptfs (la partition système du Ubuntu) :
sudo mount /dev/sda1 /mnt
(/dev/sda1 est bien sûr à adapter au cas où)
2) à partir de là il y a deux solution : la solution « magique » avec le script ecryptfs-recover-private
et la solution manuelle où l'on comprend ce qui se passe. S'il s'agit simplement de récupérer des données, je conseille le script qui est beaucoup plus simple et nécessite moins de connaissances sur l'ecryptfs à ouvrir.
2.1) avec le script ecryptfs-recover-private
il n'y a presque rien à faire, juste le lancer en root :
sudo ecryptfs-recover-private
On peut éviter de le laisser chercher l'ecryptfs à monter en lui donnant en argument :
sudo ecryptfs-recover-private /mnt/home/.ecryptfs/<username>/.Private/
(il faut bien sûr remplacer <username>
par l'identifiant de l'utilisateur)
L'outil va poser quelques questions simples (comme le mot de passe de l'utilisateur à qui appartient les données chiffrées), et normalement va monter une version (en lecture seule, sauf si l'option --rw
a été passée) des données déchiffrées quelque part dans /tmp/ecryptfs.*
(il dit bien sûr où).
2.2) La solution manuelle est un peu plus complexe, et reproduit à peu près ce que fait le script. Le seul réel avantage est de comprendre ce qui se passe.
2.2.1) Il faut connaître la passphrase utilisée pour l'ecryptfs lui-même, qui n'est pas le mot de passe de l'utilisateur à qui appartient les données. Si vous ne l'avez pas, il est cependant possible de la retrouver avec le mot de passe utilisateur :
sudo ecryptfs-unwrap-passphrase /mnt/home/.ecryptfs/<username>/.ecryptfs/wrapped-passphrase
2.2.2) maintenant il faut insérer les clés FNEK (chiffrement des noms de fichiers, FileName Encryption Key) dans le keyring :
sudo ecryptfs-add-passphrase --fnek
Cette commande demande la passphrase de l'ecryptfs telle que retrouvée ci-dessus, pas le mot de passe utilisateur.
Cette commande affiche deux tokens, le premier est la signature du mount (ci après $mount_sig
), et la deuxième celle du FNEK (si après $fnek_sig
). On va en avoir besoin juste après.
Note : il est nécessaire de ré-invoquer ecryptfs-add-passphrase
avant chaque montage, car les tokens sont retirés du keyring lors du démontage.
2.2.3) Il ne reste plus qu'à monter l'ecryptfs. On crée d'abord un point de montage bien sûr :
mkdir ~/priv
(ou n'importe où ailleurs)
puis on monte l'ecryptfs :
sudo mount -t ecryptfs /mnt/home/.ecryptfs/<username>/.Private/ ~/priv -o ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_sig=$mount_sig,ecryptfs_fnek_sig=$fnek_sig,ecryptfs_passthrough=n,no_sig_cache
(certaines options ici ne sont pas absolument nécessaires et si non renseignées seront demandées interactivement, les donner sur la ligne de commande évite ça)
La passphrase de l'ecryptfs sera demandée, et une fois renseignée le montage devrait réussir, et les fichiers disponibles dans ~/priv
(ou quel que soit le point de pontage choisi) \o/
3) Note : le point de montage appartient à l'UID de l'utilisateur à qui appartiennent les fichiers chiffrés, ce qui n'est pas forcement celle de l'utilisateur d'un live Ubuntu (999), donc il faudra peut-être changer les droits du point de montage après coup, ou accéder aux fichiers en root.
Vous vous souvenez peut-être de mon post blâmant journald qui polluait mes logs et remplissait /var/log ? (http://ban.netlib.re/shaarli/?RVgspw) Bon et bien j'avais assez tort, ce n'est pas directement la faute de systemd en fait (ça passe par lui, mais ce n'est pas sa faute).
Ce qui remplit /var/log c'est juste syslog, qui écrit les logs de journald sur le disque (et les écrit trois fois, je n'ai pas cherché pourquoi). Quoi qu'il en soit ça fait longtemps que syslog fait ça, mais ça n'a pas grande incidence car peu d'applications logguent via syslog.
Le vrai problème est que les développeurs de GDM ont imaginé que c'était une bonne idée que de logguer la sortie de la session X explicitement via journald au lieu du bon vieux .xsession-errors (ou de $XDG_CACHE_HOME/gdm/session.log dans les versions plus récentes de GDM). Ça a l'air gentillet dit comme ça, mais ça envoie beaucoup de choses dans jounrald, qui sous Debian les renvoie à syslog, qui les écrit sur le disque.
Bref, maintenant il faut attendre que ce problème soit corrigé dans Debian. Pour ça il y a probablement deux solutions :
(3. ne pas utiliser GDM. Là le problème est qu'avec par exemple lightdm certaines choses fonctionnent moins bien (au moins sous MATE, mais je pense que ce sera pareil sous GNOME), comme les mises en veilles/reboot/changement d'utilisateurs/délock depuis le DM, etc.)
Pas très nouveau non-plus mais ce billet présente très bien ces différentes sources qui en effet contiennent de vrai petits (ou grands) bijoux.
Comme il dit pas un scoop mais toujours intéressant.