Attention : si on modifie la commande forcée liée à la clef SSH (command=) utilisée pour la connexion ControlMaster, il faut relancer la connexion, le fichier n'est pas relu.
Ne pas oublier que pour un service systemd, stdin est /dev/null… sinon on peut passer du temps de debug bizarre au moment où on veut passer un script en service systemd… ici socat, qui y est très sensible puisque c'est son seul taff (de gérer des flux).
Ho sympa ça, l'implémentation OpenSSH permet de créer une connexion persistante "ControlMaster" qu'on pourra utiliser par la suite pour aller taper régulièrement sur un serveur sans à chaque fois refaire la connexion à zéro (et donc spammer les logs, manger la latence etc.).
Lancée via autossh, on a donc une sorte de connexion permanente et qui doit être résiliente en cas de coupure (volontaire ou panne).
Petit outil d'estimation de la bande passante CPU⇔RAM, avec cœur écrit en assembleur directement (pour s'assurer d'avoir toujours le même code).
Nous allions changer de RAM sur une machine et passer de 2133 à 2666 MHz, du coup j'ai cherché et testé cet outil pour voir s'il y avait réellement une différence.
Il y en a une légère, de l'ordre du Go/s en brut… mais les tests de memset/memcpy, eux, n'ont pas vraiment montré de changement significatif.
En tous cas, petit outil simple et facile à utiliser, qui sait même générer quelques graphs en fonction du test et de la taille des échantillons.
Quand tu as une BMC, il peut être parfois compliqué de lui causer depuis le système hôte. Sauf que se connecter à l'interface web c'est pas toujours pratique non-plus. Et SSH peut être en carafe ou pas configuré.
Il y a une norme IPMI pour cela. Des fois ça marche, des fois ça marche pas. Ce qui est à noter c'est que sur des carte mères presque grand public (les Asrock Rack X470D4U) ça fonctionne directement, avec le module mainline Linux 5.4 sans avoir rien besoin de faire (d'autre qu'installer un outil pour lui parler comme ipmitool). La plupart des fonctions sont OK comme changer l'IP par exemple ou voir les sensors directement. C'est cool \o/
Qu'est-ce qui fait réagir un système avec systemd aux événements ACPI (poweroff etc.) ? logind !
Du coup la doc qui dit qu'il faut acpid n'est plus utile : quand acpid fonctionne, il appelle un script qui vérifie juste que logind tourne et qu'un appel dbus précis est possible (voir /usr/share/acpi-support/policy-funcs).
J'ai creusé tout ça parce que une seule VM parmi une grosse dizaine ne répondait pas aux injonctions d'extinction "propre" de son hyperviseur…
Il se trouve que cette VM était à la base un conteneur LXC non-privilégié (oui j'ai testé ça un moment pour voir). Et dans ce conteneur, le service systemd-udevd était masqué…
J'ai appris plein de choses sur udev, acpi, logind.
J'ai découvert les modules noyal "button" et "evdev".
Par hasard je suis tombé sur lsinitramfs.
Pas si mal :)
Pour lancer acpid en mode debug + log : acpid -d -l -f
Pour faire un gros transfert (plusieurs centaines de To), j'ai tenté d'après cette réponse le coup de tar + mbuffer. Avec de gros buffers côté mbuffer, c'est vraiment pas mal. Et mbuffer gère lui-même la partie réseau (avec -I et -O). On pourrait peut-être imaginer compresser en plus ou éviter les header de tar mais c'est déjà pas si mal je trouve.
Sur réseau 10 Gbps, on arrive à monter à du 250 Mo/s avec le vent dans le dos : c'est probablement un des systèmes de fichiers distribué qui traine, le transfert tourne alors que tout est en prod, etc. En tous cas c'est beaucoup plus rapide qu'un simple rsync (encore heureux). Mais forcément on ne peut pas reprendre s'il y a un crash…
ffmpeg utilisé comme ici et couplé à un serveur rstp (comme spydroid, disponible sur f-droid) sur le téléphone permet d'avoir une webcam via android sur son linux. v4l2loopback est packagé dans Debian. C'est donc assez simple à tester.
Je n'ai cependant pas réussi à avoir mieux que 320×240 de définition depuis spydroid et il faut passer un paramètre au module v4l2loopback (https://github.com/umlaeute/v4l2loopback/issues/78) pour le rendre compatible avec les applis "relou" comme Chromium. Sinon ça va. Et non je ne vais pas montrer ma tronche en visio conf mais j'ai quand même tout testé comme si… histoire de savoir.
J'ai voulu tester un hébergement web + PHP + MariaDB rapidement et j'avais vu passer adminer sans vraiment prêter attention. J'ai donc testé… et oui ça juste marche. Un simple fichier PHP et c'est parti on peut a priori faire ce qu'on veut avec ses bases de données (il y a plein de SGBD reconnus) sans se prendre la tête avec les commandes SQL reloues. Ça permet de mettre son nez "graphiquement" et tester toute la chaine, tester des sauvegardes, etc.
En tous cas beaucoup plus simple que phpMyAdmin…
J'ai quelques sites web qui tournent chez moi depuis un moment (2010…), et au fur et à mesure j'ai appris des choses, mis d'autres choses en vrac, changé des configurations, etc.
Je suis en train de migrer une partie de mes services dans des VM sur d'autres machines. C'était donc le moment de revoir de fond en comble mon setup web.
J'ai beaucoup cherché s'il n'y aurait pas moyen de tout mettre dans un système magique qui s'occupe un peu de tout, calcule des infos en plus (graph), permet de filer un coin de web rapidemement à quelqu'un sans se prendre la tête etc. et forcément il y a plein d'outils qui existent et qui prétendent faire le café.
Grosso modo j'ai vu soit des gros trucs pour revendeurs à la cpanel/vesta/ispconfig/… soit des scripts maison mais qui du coup ne fonctionnent que sur par exemple Ubuntu (LEMPer) ou CentOS (VPSSIM). Or toute mon infra est en Debian, et je n'ai pas besoin d'intégration mail/DNS/TLS/… car tout cela est déjà géré par d'autres briques. Sortent un peu du lot, froxlor et tinycp…
J'ai hésité pour froxlor mais beaucoup de doc date de Debian wheezy, il y a tout de même cette notion de revendeur, DNS, mail, … qui ne m'intéresse pas (mais il suffit de ne pas les utiliser, on est d'accord… alors que ça rajoute quand même de la complexité et des risques de failles). Et au final ça ne semblait pas me rajouter beaucoup de facilité. Il aurait aussi fallu gérer les mise à jour et mises à niveau (comme pour tout outil quoi).
Tinycp avait l'air vraiment sympa mais actuellement les dev sont en train de se demander comment ils vont fournir leur bidule et dans tous les cas le code n'est pas libre. Donc compliqué dans le temps si on a pas envie de se prendre le chou et pas propre éthiquement.
J'ai donc perdu beaucoup de temps pour au final écrire le script qui fait juste ce que je veux et voilà. J'espère que je ne suis pas passé à côté de certaines notions élémentaires que les panel sus-cités ont déjà pris dans la tronche et corrigé : le web c'est compliqué et pas vraiment passionnant.
De nos jours sur un système avec systemd (comme une Debian "à jour" sans bidouille pour l'enlever), logrotate est lancé par un timer systemd, et enregistré en tant qu'unit systemd. Pour faire un run de test, il suffit de le start comme un service normal du coup… trop simple.
Pour tester une configuration logrotate, on peut aussi feinter la date de dernière exécution dans /var/lib/logrotate/status et donc après un start, bien vérifier que tout se passe bien… trop simple aussi, mais j'ai dû chercher pour tout ça, je me dis que ça peut servir souvent plutôt que "flemme".
J'ai un système de fichiers corrompu (un rootfs de RPi), mais pas trop, et pour la science je me demande quels sont les fichiers impactés. Je me suis souvenu qu'il y a dans les metadata de tous les paquets deb (ou presque) un fichier avec les md5sum de tout ce qu'ils contiennent. Je me suis dit qu'il devait bien y avoir un moyen de les utiliser. C'est possible avec debsum.
Sur le post ci-lié ils suggèrent debsums -a, pour mon cas c'est plutôt debsums -s qui m'intéresse.
On obtient une liste des fichiers qui ne correspondent pas au md5sum d'origine (pour peu que lui-même ne soit pas corrompu…) avec pour chaque le nom du paquet auquel il appartient.
Pas la peine de troller sur les collisions dans md5sum etc. pour ça, ça suffit amplement.
J'ai toujours trouvé checkinstall pratique pour complier, tester avec installation réelle et modifier un soft sans risquer de mettre le bazar sur son système (oui on peut aussi faire des chroot, des VM, … mais bon).
Apparemment cmake a une fonction équivalente, cpack. On peut soit le configurer dans le projet, et il suffit de faire "make package" pour que le projet soit packagé/taré à la fin soit directement lancer l'outil cpack avec toutes les variables sur la ligne de commande. Ici le lien utilise la configuration.
Pour être honnête j'ai pas trop compris, je me mangeais un mur tout le temps comme quoi cpack ne pouvait pas initialier la sortie en "DEB" mais tout à coup ça s'est débloqué après avoir testé d'autres sorties… les magies de cmake et des configurations changées à la volée je suppose (oui j'avais reset le dossier build…).
Bref bien pratique !
Bug entre uswsusp et plymouth de 2013, dup d'un de 2010, qui apparait en 2019 dans Debian Buster car desktop-base dépend de plymouth… on adore les broutilles qui passent entre les mailles des filets et qui pètent à la gueule des années plus tard.
Sur une idée basée sur ce script qui affirme qu'il n'y a pas besoin de partition pour créer un disque de machine virtuelle et en utilisant extlinux, j'ai passé un peu de temps à transférer un conteneur LXC non-privilégié (fait alamano au début quand LXC 1.0 est sorti) vers une VM full qemu/kvm sous Proxmox.
Voici ce que j'ai fait :
sudo qm create 302
sudo qm set 302 -virtio0 local-zfs:10
=> création de la VM, avec un disque de 10 Go dans le zfs ; oui ça aurait pu se faire en une ligne mais entretemps j'ai réfléchi et au lieu de faire un fichier qcow2 et de le monter avec qemu-nbd et tout ce bazar je me suis dit que ça serait plus simple avec un bon vieux block device
sudo mkfs.ext4 /dev/rpool/data/vm-302-disk-0
=> pas de partition
sudo mount /dev/rpool/data/vm-302-disk-0 /mnt/
cd /mnt
=> tellement simple par rapport à un qcow2 + partition + éventuellement LVM… oui c'est pas chiffré mais pour un site d'affichage public, ça devrait aller
ssh IP-VM-avec-LXC 'sudo -S -u lxcguests lxc-usernsexec -- tar cf - /home/lxc/lxcguests/.local/share/lxc/web/rootfs/' | sudo tar xf -
=> copie avec tar pour la préservation des attributs de tout le rootfs ; lxc-usernsexec pour que tar soit exécuté dans le namespace uid du lxc (sinon root aurait été uid 100000 etc. selon ma configuration de l'époque). EDIT: Si l'on copie un LXC booté ou avec des montages, ajouter --one-file-system au tar cf pour être sûr de ne pas emporter trop de monde (/dev, /proc …) - FEDIT
sudo chroot .
apt install linux-image-amd64
=> on ajoute un noyau, ça va servir…
exit
sudo extlinux --install /mnt/
=> on le fait de l'extérieur, partition montée. d'après le man, c'est fait pour et ça nous évite de bind-mount /dev et compagnie dans le chroot ; là si on lance la VM on est déjà dans notre bootloader, qui demande quoi faire avec boot:
On peut alors booter en tapant tout à la main dans extlinux. Après un peu de tests et en regardant la config d'un autre extlinux qui fonctionne, j'ai pu arriver dans l'initramfs, puis dans un système qui boot mais avec le / en read-only.
Ma commande à la main dans extlinux (promt boot:) était :
/vmlinuz initrd=/initrd.img modules=ext4 root=/dev/vda
On utilise les liens dans / qui sont encore créés par le paquet du noyau sous Debian… :)
Ensuite j'ai posé ça dans un fichier de conf histoire de booter facilement quand même :
DEFAULT virt
LABEL virt
MENU LABEL Linux oasis
LINUX vmlinuz
INITRD initrd.img
APPEND root=UUID=db01b05e-2e90-4df7-a9b2-96a1ee04b1aa modules=ext4
J'ai aussi créé un fstab puisqu'il était vide (mais a priori pas vraiment utile du coup). L'histoire du / qui restait en read-only a perduré même avec un rw sur la cmdline linux, même avec le fstab… et est parti dès que j'ai mis systemd…
EDIT: sans fstab et avec systemd, read-only aussi ; réglé avec un fstab donc il faudrait les deux… ?
Bref ça fonctionne bien. J'ai perdu du temps à vouloir booter depuis extlinux à la main, à ne pas pouvoir monter / car pas de module ext4 (il disait juste "no such file or directory" ce con de mount…) et avec le read-only. Et j'ai aussi passé la mise à jour de jessie à stretch que j'avais jamais faite avant…
J'ai voulu tester du let's encrypt (oui…) sur une VM Alpine. Apparemment il y a enfin un setup simple, qui fait ce qu'on veut et qui juste marche. Mais je n'ai pas encore pu tester le renouvellement auto évidemment.
Avec les paquets, on peut installer acme-client-plus et acme-client. Le dernier est le client ACME d'OpenBSD, écrit en C et avec pas mal de fontionnalités (mais pas les wildcard si j'ai bien compris). Le premier est un script shell et les quelques fichiers de conf pour qu'il renouvelle au besoin.
Plus rien à copier, mettre en place, installer, il suffit de faire un "acme-client-plus issue" et hop on a son certificat (une fois qu'on a corrigé nos erreurs de DNS/routage/config serveur web/…). Un peu comme le script que j'avais mis en place il y a longtemps, à la main. Là c'est pareil mais en tout prêt.
À voir au renouvellement… !
Apparemment Alpine, bien qu'utilisant /etc/networg/interfaces à la Debian, n'a pas les petits sugar genre autoconf, dad-attempts, accept_ra etc.
Dans leur doc ils disent de désactiver la prise en compte des RA d'IPv6 avec un pre-up (soit avec un echo, soit avec sysctl). Seulement chez moi ça ne suffit pas, la route par defaut est déjà mise en place avant que ifup ne se bouge, donc on a une erreur "file exists" (mais qui ne gène pas). Par contre, la default est valide seulement le temps d'expiration du RA qui a été pris en compte. Donc au bout d'un moment la default disparait \o/ pour le voir, champ "expires" :
default via fe80::xxxx dev eth0 proto ra metric 1024 expires 1778sec hoplimit 64 pref medium
J'ai simplement créé un fichier sysctl :
$ cat /etc/sysctl.d/01-noslaac.conf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.dad_transmits = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.eth0.dad_transmits = 0
et là plus de problème. Oui je bourrine, mais on sait jamais si le nom de l'interface venait à changer par exemple #traumatisé. :)
On peut ajouter dans Qemu via virtio une source de random qui remonte de l'hôte. A priori c'est pour accéder aux sources "matérielles" mais on peut aussi coller ça sur par exemple /dev/urandom.
J'ai testé pour voir, et ça a effectivement débloqué le "problème" que je vois, à savoir que ssh boot tellement avant que urandom soit setup qu'il attend des fois plus d'une minute d'avoir de l'entropie. Pas très important, juste pour le level up/connaissance.
Je n'ai pas eu besoin de lier cette sources au random "kernel" d'une manière ou d'une autre genre avec hwrng comme proposé par-ci par-là.
Pour pouvoir déverrouiller le disque chiffré de ma VM, je me suis dit que plutôt que de passer par l'interface et le noVNC ou de bidouiller le VNC hors interface, je pourrais utiliser le port série. J'avais déjà joué avec ça dans des VM il y a un moment, bah ça s'est pas trop arrangé.
Avec systemd, maintenant on a bien un getty partout automatiquement, ça c'est pas si mal.
Par contre, les messages de boot et le prompt pour le mot de passe ça a l'air d'être le chantier (et pas à cause de systemd, hein, no troll).
https://github.com/systemd/systemd/issues/9899
Le workaround qu'on retrouve partout, c'est d'installer plymouth… sur une VM serveur etc. je me suis d'abord dit que nope nope nope. Mais en vrai ça juste marche, y'a un thème "text only" par défaut et l'installation a pris…882 ko donc bon si ça fait le job, en vrai, pourquoi pas… bootlogd par exemple ne fonctionne pas avec systemd, donc pas trop d'alternative pour le mot de passe en lui-même donc bidouiller un truc juste pour le blabla de boot c'est pas si utile.
Bref en gros, ajouter un serial au KVM, configurer le cmdline de Linux, configurer grub, installer plymouth et on peut tout faire par les deux moyens (qm terminal et noVNC).
Utilisant depuis peu un serveur sous proxmox pour la virtualisation, avec du ZFS pour la gestion du raid soft et des "partitions" des VM, j'ai eu la surprise de voir une utilisation complètement folle de la RAM d'après les outils classiques (top/free/htop).
Il s'agit apparemment d'un cache ARC utilisé par ZFS qui est supposé être meilleur dans le cadre d'un serveur de fichiers (ce qui du coup n'est pas le cas mais est un cas fréquent).
D'après https://superuser.com/questions/1137416/how-can-i-determine-the-current-size-of-the-arc-in-zfs-and-how-does-the-arc-rel :
Because of how ZFS on Linux is implemented, the ARC memory behaves like cache memory (for example, it is evicted if the system comes under memory pressure), but is aggregated by the kernel as ordinary memory allocations.
Pour regarder :
arcstat, /proc/spl/kstat/zfs/arcstats, arc_summary
Pour jouer un peu :
https://www.svennd.be/tuning-of-zfs-module/
pour le désactiver :
zfs set zfs set secondarycache=none rpool
zfs set secondarycache=none rpool
cela réagit bien à un drop des caches (mais pas complètement, moi il restait dans les 400 méga) :
echo 3 > /proc/sys/vm/drop_caches
Pour l'instant j'ai remis, c'est supposé être capable de réagir en cas de demande de mémoire (mais pas toujours : some applications will require a certain amount of memory to start, or request memory on a rate that is quicker then ARC size can lower, resulting in a crash/swapping). Je verrai bien mais il vaut mieux être prévenu…
Si jamais systemctl --user marche pas avec cette erreur, il suffit de définir la variable d'environnement qui va bien pour débloquer la situation :
XDG_RUNTIME_DIR=/run/user/$(id -u)
Pas besoin de bricoler avec du dbus ou quoi. On peut l'exporter dans son bashrc par exemple. Probablement dû à un sshd configuré sans PAM dans mon cas mais il y a sûrement d'autres raisons possibles.
Ma syncho mail était cassée depuis quelques temps par perte de connectivité entre mes deux réplicats dovecot (en IPv6, pas d'accès tunnel HE chez Cogent).
Pour contourner cela, je me suis demandé s'il n'y avait pas moyen de faire du routage dans un tunnel SSH. Et la réponse est oui, c'est même facile : ssh -w 0:0 (en root des deux côtés) va créer une paire de tun0 qu'il suffira de configurer !
ip link set tun0 up
ip route add … dev tun0
… le forwarding, etc.
En lisant la page liée, j'ai donc juste eu à créer une paire de clefs SSH, faire la config (sshd_config without-password et PermitTunnel) et c'est tombé en marche rapidement :)
Fichiers sysfs faciles à accéder pour voir les compteurs des interfaces réseau sans passer par une commande ou parser des sorties plus ou moins obsolètes comme ifconfig. Exemple pour le rx :
/sys/class/net//statistics/rx_bytes
/sys/class/net//statistics/rx_packets
Article que j'ai trouvé très complet, avec de bonnes explications sur comment fonctionne qemu-user, à quoi ça sert etc.
Pour utiliser qemu-arm-static, j'ai dû installer le paquet qemu-user-static (ce n'est pas décrit). Le -static désinstalle le -binfmt. Bizarre. Pourtant même après ça, le bon interpréteur est tout de même utilisé automagiquement et les fichiers de "registration" des formats sont toujours là (voir /proc/sys/fs/binfmt_misc/).
En fait en rédigeant j'ai regardé et le -static rajoute de lui-même les binfmt… voir /var/lib/dpkg/info/qemu-user-static.postinst pas très homogène tout ça on dirait.
3.3V apparemment ça marche ? Bah moi d'abord j'ai fait tourner un RPi zero WH avec du 3V, na.
En fait j'ai oublié de vérifier la tension sur le transfo avant de brancher le RPi, je l'avais mis au minimum pour un petit ventilateur… ça aurait pu faire de la casse.
Au contraire, tout fonctionnait même le WiFi et l'HDMI. Juste pas l'USB…
J'ai aussi de la corruption sur certains fichiers, mais j'ai passé les mises à jour pendant la période 3V donc je pense que le contrôleur de la carte SD a fait ce qu'il a pu (ou que la carte est foireuse de toutes façons).
À noter qu'une libpam corrompue, ça te laisse à la porte de ta machine comme une merde, que ce soit SSH ou login. Normal mais bon… après réinstallation du paquet ça va quand même mieux.
J'ai voulu ajouter rapidement un petit daemon à un système Alpine pour qu'il démarre au boot. J'ai donc cherché des infos sur les script openrc. On tombe principalement sur les wiki de Gentoo et Arch, puis enfin celui d'Alpine.
Les deux premiers sont super remplis mais ne disent pas comment définir un user particulier… sauf à redéfinir la fonction start et stop et la ligne start-stop-daemon. Le wiki Alpine dit que la page est en chantier et de pas l'utiliser (et n'en parle pas non plus).
J'ai donc lu la page de man directement, lu les exemples, pris ce qui me semblait minimal, trouvé le paramètre user… pas si compliqué au final. Un peu frustrant. Et pas différent de systemd au final, pour les trolleurs ;)
command=/srv/davmail-4.9.0/davmail.sh
command_args="/srv/davmail-4.9.0/davmail.properties"
pidfile=/var/run/davmail.pid
command_background=true
command_user=davmail
name="Davmail Daemon"
Les applications CUDA indexent les GPU de la machine par défaut dans l'ordre de performance supposée, alors que dans nvidia-smi le listing est donné par ordre PCI.
On peut changer le comportement dans les applications avec CUDA_DEVICE_ORDER=PCI_BUS_ID dans l'environnement.
Depuis un moment j'avais des mails de cron sur mon conteneur web, disant que logrotate n'arrivait pas à reload apache. J'ai un peu creusé le problème au début, puis étant bloqué sur systemd parlant de namespace, j'étais resté coincé puis étais passé à autre chose.
Pour compliquer le debug, une fois un restart d'apache effectué, pas de problème pendant "un certain temps"…
Là j'ai retenté ma chance et pouf, je suis tombé sur ce rapport de bug Debian.
En fait, c'est tmpreaper qui nettoie les dossiers de "PrivateTmp" de systemd. Du coup au moment de mettre en place l'environnement pour lancer le reload, systemd n'arrive pas à accéder au namespace du /tmp puisqu'il a été viré !
Un message d'erreur plus explicite de la part de systemd aurait été appréciable. Et le problème n'est pas lié à LXC, ni à apache.
Quick fix (pour être complet) :
TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private/'
Pour ARN, pour travailler sur un incident on aurait eu besoin d'une sorte de smokeping (ping en continu avec graph pour voir quand il y a des problèmes (latence, pertes, …)). J'ai cherché rapidement et à part "smokeping" qui a un mode daemon et visualisation web, le reste avait l'air proprio/winwin/…
Je suis tombé par hasard sur la page liée ici, où, simplement, ils font ça avec… ping et gnuplot.
J'ai donc bidouillé à partir de là, et au final ça donne :
ping4 -i 10 addresse-à-tester -D -n | grep --line-buffered icmp_seq | awk -F [=\ ] -W interactive {'print $1, " ", $(NF-1); fflush()'} | stdbuf -o0 tr -d '[]' > /dev/shm/pings4
Le plus difficile est à chaque commande pour être sûr de ne pas bufferiser, ce qui permet de lire le fichier de sortie immédiatement, sans arrêter la commande ou autre. Pas de soucis de faire des petites écritures puisqu'on envoie dans un ramdisk.
On a donc des paires "timestamp RTT"
Pour grapher cela, on peut utiliser :
gnuplot -e 'set term png size 1280,1024; set output "ping.png"; set xlabel "Time (UTC)"; set ylabel "RTT in milliseconds"; set xtics rotate; set xdata time; set timefmt "%s"; set format x "%b %d %H:%M"; clamp(a) = (a < 42) ? a : 42; plot "pings4" using 1:(clamp($2)) notitle'
Ici le plus sioux c'est d'une part la gestion du temps (timestamp vers "pretty"), d'autre part la limite (min ou clamp) pour éviter d'avoir un graph tassé/pollué par les ping vraiment trop hauts. Ici tout ce qui est plus grand que 42 ms est affiché à 42.
Ce qui reste difficile, c'est la détection de pertes. On ne les voit pas vraiment, surtout quand le graph commence à être large. En général en cas de problème on le remarquera autrement (nous ici, session BGP qui tombent). Après on peut aller fouiller en mode interactif (sans utiliser la sortie PNG de gnuplot). Et là on voit rapidement quand il y a un "trou" dans une certaine zone. En général ça correspond aussi à des moments où il y a eu un lot de ping à plus de 42 ms de RTT.
Si des gens veulent utiliser ça, en tous cas c'est relativement sans prise de tête et sans installation ou autre !
En faisant du debug sur un conteneur LXC, je me suis rendu compte qu'au milieu de syslog par exemple, il y avait des messages du noyau concernant l'hôte ou un autre LXC. J'ai trouvé ça pas top (même si pas très important).
Il y a apparemment deux facettes :
Le lien lié ici propose comment bloquer le syscall via les seccomp. Ça fonctionne.
Pour kmsg le lien précédent prétend que cela va casser des choses, j'ai tout de même voulu essayer. Par contre par défaut sur Debian Stretch, apparmor n'a pas l'air activé complètement, le module est là mais pas l'accès via proc (https://wiki.debian.org/AppArmor/HowToUse et aa-status). Je n'ai donc pas pu essayer de modifier cela (les autres restrictions, qui ont tout de même l'air de fonctionner malgré l'absence des paramètres cmdline sont dans /etc/apparmor.d/abstractions/lxc/container-base).
En attendant il suffit de cat /proc/kmsg depuis n'importe où pour tout savoir sur ce qu'il se passe sur le système côté noyau :P
Ah et aussi, ce n'est pas si simple que cela : https://lxadm.com/Lxc:_restricting_container_view_of_dmesg
D'autant que l'option est maintenant activée par défaut depuis Debian Stretch. En LXC root (pas non-privilégié donc) ça fonctionne tout de même (comme dit dans le lien github ci-dessus).
Si certains mails ne passent pas, supposément parce qu'ils sont en "userunix@localhost" et ce même si le header From: est juste, c'est probablement une histoire de Sender/Return-Path, eux aussi validés par les MTA.
504 5.5.2 wp@localhost: Sender address rejected: need fully-qualified address
Il ne faut pas s'acharner sur mail/sendmail/php mail(). Ce champ est ajouté par le MTA local.
Plusieurs options sont listées dans la page liée. Pour moi, il a suffit de corriger /etc/mailname en mettant quelque chose de valide (oui j'aurais pu y penser au début, avant de passer 2h sur le problème…).
Juste pour éviter à des gens d'être surpris, maintenant sous Debian Stretch, les outils systemd pour la conteneurisation (nspawn/machinectl) sont dans un paquet séparé -- et c'est tant mieux ! :)
Après un upgrade, une fois le paquet installé, tout repart normalement.
Passer un gitlab du postgresql du système à celui qui est intégré au paquet omnibus, c'est faisable, c'est pas trop tricky quand on a la doc de quelqu'un qui l'a déjà fait et qui s'y connait (j'aurais jamais pu deviner tout ça perso). Par contre il faut bien suivre les instructions à la lettre, sinon ça marche pas (j'en ai fait les frais).
Est-ce une bonne idée de le faire ? Probablement pas en absolu, mais c'était un reste de mon setup "from source" alors que je suis passé au paquet omnibus depuis un moment, pour des raisons de facilité : c'est vraiment pratique les paquets et j'ai jamais eu de problème avec le leur.
Il y avait des problèmes de version entre les outils (postgresql plus vieux dans la distro). Là au moins c'est homogène… et les dump se passent bien, par exemple.
Je n'avais jamais entendu parler de busctl… encore un outil de systemd.
La commande sert à interagir avec dbus/sd-bus de manière plus simple et plus intégrée que dbus-send et compagnie.
C'est relativement pratique, par exemple si on veut lister les différentes sessions/seat ouvertes, etc. et il y a un mode tree, monitor, introspect, …
J'ai remarqué que l'hibernation prenait parfois super longtemps sur mon Debian 9 Stretch, avec LED d'activité stockage allumée en continu. En faisant un tour dans dmesg j'ai remarqué la ligne :
PM: Need to copy XXXXXXX pages
Avec des pages de 4096, j'avais environ 13Go d'image ! Ce qui correspondait en gros à l'utilisation de ma mémoire en incluant le cache (alors que j'étais à environ 1G utilisé réellement par les programmes). Ça me parait stupide de sauver le cache dans l'image mais bon. Du coup j'ai un peu creusé.
Au final, la solution la plus simple est de passer à uswsusp, qui s'occupe en userspace de gérer l'image et surtout de drop le cache, accessible via les commandes s2* que je connaissais déjà. On l'installe, puis on le reconfigure pour avoir droit aux questions. Mettre 0 comme taille d'image pour la minimaliser (drop la mémoire cache).
aptitude install uswsusp
dpkg-reconfigure uswsusp
Il faut encore demander à systemd de l'utiliser lui. Pour ça, voir la page liée, mais en gros :
systemctl edit systemd-hibernate.service
et mettre :
[Service]
ExecStart=
ExecStartPre=-/usr/bin/run-parts -v -a pre /lib/systemd/system-sleep
ExecStart=/usr/sbin/s2disk
ExecStartPost=-/usr/bin/run-parts -v --reverse -a post /lib/systemd/system-sleep
(attention, sur la doc liée c'est /usr/bin/s2disk et pas sbin ! sous Debian apparemment c'est sbin… de même, le dossier pre/post est dans /lib sous Debian, alors que la doc Arch dit /usr/lib) :-'
Maintenant je ne bourrine plus les write de mon SSD avec du cache, j'ai un joli progress à l'écriture/lecture de l'image et le tout est plus rapide (quelques secondes au lieu de l'ordre de la minute). Oui j'ai passé plus de temps à chercher/tester/rédiger, mais j'ai appris des trucs au moins :)
Je re-shaarli juste encore une fois le coup du mount bind pour voir le contenu d'un point de montage y compris ce qui serait caché par un autre montage… j'y ai plus pensé, et j'avais le cas de données prenant de la place mais non atteignables…
"This is why I use the initrd.gz from stable hd-media, because the 8.2 multiarch netinst ISO is missing the iso-scan toolset entirely."
Passer 2h là dessus juste pour booter une netinst depuis une clef multiboot… check. L'affirmation semble encore exacte pour Debian 9.
La commande "pv" a pas mal d'options. Pour avoir rapidement une idée du nombre de requêtes sur une page web qui se fait par exemple DDoS, on peut construire quelque chose comme :
tailf /var/www/<site>/access.log | grep lapage | pv -l -i 10 -r > /dev/null
On aura le nombre de ligne par seconde, sur les 10 dernières secondes.
Tester simplement si un dossier a été copié, sans tenir compte des owner/dates/etc. donc sans passer par tar :
find /path -type f | sort -u | xargs cat | md5sum
On peut troller sur md5 mais pour ça, ça fait largement le boulot, et si vraiment ça t'amuse, pas compliqué de mettre un sha42sum quelconque :)
Pour appliquer une limite de débit à n'importe quel flux en ligne de commande : pv --rate-limit ! Ici appliqué à dd, mais ça devrait être pareil pour tout (cat, nc, …).
Apparemment le client DHCP ISC place toujours la valeur DSCP des paquets émis à 4 :
DSCP 4 (Hex 10 if you look at the entire 8 bits incl ECN) is the old
ToS low delay value. Currently there is no way to change this in ISC DHCP.
Et comme il utilise des socket raw on peut pas non plus y toucher via netfilter…
Lorsqu'on configure la réplication dans dovecot, on peut donner un intervalle uid_min / uid_max de filtre sur les utilisateurs qui seront synchronisés.
Sauf que si la synchro a déjà fonctionné mais qu'on modifie ces limites après (par exemple on a des erreurs sur l'utilisateur "nobody"), dovecot continue s'en préoccuper. En fait apparemment il "retient" qui est concerné par la réplication.
Il suffit de :
doveadm replicator remove nobody
pour s'en débarrasser ! Je n'avais pas trouvé, mais là en replongeant dans ma configuration ces erreurs faisaient un peu trop de bruit dans les logs… et je suis tombé rapidement sur ce mail.
Liste des utilisateurs qui seront synchronisés :
doveadm replicator status ' '*'
Sale : pour "palier" au "problème" que Ubuntu a 127.0.0.1 comme serveur DNS dans le resolv.conf par défaut (dnsmasq en local), les paquets docker utilisent google DNS par défaut pour le serveur DNS des conteneurs.
Forcément si on a un FW qui bloque on le remarque... mais même sinon, c'est très pas beau.
Je ne savais pas que strace avait des catégories de syscall prédéfinies, pratique.
On peut donc avec strace -e trace=network tracer tous les calls en rapport avec le réseau d'un process. Il y a pas mal d'autres catégories comme signal, memory…
Petite "découverte" du jour, ou plutôt une remarque : il existe dans Debian des backports de backports, en gros qui "traversent" 2 versions, dans backports-sloppy.
Je cherchais à faire du lookahead/lookbehind avec sed. Apparemment, pour avoir l'option perl regex, il faut passer à ssed, super sed. Et ça fonctionne.
Les userdir apache, vieux comme le monde. Mais je ne connaissais pas la variante "hors home" où en fait on peut choisir n'importe quel dossier racine dans lequel seront, par dossier, les données de chaque utilisateur. Ça me semble pas mal pour éviter de devoir ajuster les permissions x de tout le home par exemple.
Je ne savais pas non plus qu'on pouvait activer/désactiver des utilisateurs, ou rediriger vers des URLs externes.
Si toi aussi tu comprends pas pourquoi ton "appli" python sort rien dans le journal de systemd, pense juste aux basiques, et au buffer sur stdout.
Lancer python avec -u pour passer en unbuffered, au moins le temps du debug.
Un gros disque formaté en ext4 et de l'activité lente bizarre une fois monté ? C'est juste une étape d'initialisation qui se fait en arrière-plan : ext4lazyinit.
Je voulais faire un miroir chiffré de mes photos à distance qui soit simple, et sans trop de configuration à refaire en cas de problème. Pas de sauvegarde, pas d'incrémental ou quoi que ce soit, juste une copie de sécurité (cas où y'a l'feu quoi).
Là de base, on pense à rsync et ssh. Restait à trouver la partie chiffrement, avant transfert de préférence. J'ai déjà touché à ecrypts mais pas toujours très bien compris comment ça fonctionne et comment refaire le montage sur une autre machine (on y arrive mais des clefs sont dans un keyring lié à la session etc.). On trouve rsyncrypto qui chiffre d'une manière compatible avec la synchronisation des modifications (comme par rsync). Mais il faut donc une copie des données chiffrées avant de lancer le rsync. Pas le bon plan si on a des données qui peuvent potentiellement devenir volumineuses.
Encfs est une solution : entièrement userspace, simple à initialiser et utiliser.
On peut donc imaginer : données ⇒ rsync ⇒ encfs ⇒ sshfs vers le serveur distant.
Facile à mettre en place pour un administrateur système :
sshfs serveur:stockage montage-sshfs
encfs montage-sshfs montage-encfs
rsync -vriit données montage-encfs
Lorsque le dossier source d'encfs n'est pas encore initialisé, on nous demande ce qu'on veut comme option et un mot de passe. Les options sont enregistrées par défaut dans .encfs6.xml à la racine du dossier chiffré, donc sur le serveur distant. C'est pas forcément le plus malin mais au moins tout est au même endroit.
À noter :
Je me suis fait un petit script pour ne pas avoir besoin de reconstruire à chaque fois l'assemblage, et qui permet donc de faire un miroir de n'importe quoi n'importe où facilement (tant qu'il y a ssh sur le serveur distant et les 3 outils en local).