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".

Suite à une discussion sur le chan IRC de proxmox, il semblerait que désactiver ce pointeur absolu lorsqu'on a par exemple une machine virtuelle sans interface graphique (un serveur par exemple) diminue la charge à vide d'environ 2% à autour de 0.7, parfois 0.0 même.
Je reproduis ce comportement chez moi… pourquoi pas du coup. Ça se fait en live, et côté kernel de la VM ça se voit comme une déconnection de périphérique USB.
Celui qui en parlait avait dans les 8% en permanence, et retombe aux même valeurs sans.
À noter que la même option est gérée par libvirt, et que là j'ai déjà remarqué que c'est plutôt utile d'avoir un pointeur absolu lorqu'on utilise une interface graphique via Spice par exemple. Sinon on retombe dans le "vieux" mode où le pointeur se fait "coincer" sur l'affichage et il faut explicitement sortir via une combinaison de touches.

Notes de mon approche pour passer sur une fibre Orange du vieux PPPoE à DHCP. Le principal problème étant que dans ma zone il est nécessaire de taguer les paquets DHCP avec la bonne priorité VLAN… j'ai donc patché busybox et odhcpc6.

À noter qu'au passage, j'ai de l'IPv6 native, un débit qui passe de 100/100 à 400/400 et je ne remonte plus forcément à Paris (donc meilleur routage vers Francfort par exemple et géoloc au bon endroit). Et aussi, plus de changement d'IP systématique toutes les semaines, même si l'IP risque de changer quand même en cas de coupure prolongée.

Toi aussi passe 2h à comprendre pourquoi ton scanner (HP, bien géré par hplip normalement) marche plus depuis mise à jour en Debian Buster…
Verdict : il faut recompiler hplip avec le patch ci-lié…

Problème : tout marche avec hp-scan mais au moment de lire des données
error: No data read.

Éléments notables :
3.18.12 buster = pas marche
3.17.10 VM mint = marche

Très utile :
SANE_DEBUG_DLL=128
hp-scan -g

S'il y a du rouge ou des erreurs à la construction du paquet, je suppose que c'est normal en tous cas ça gène pas…

On ne doit plus voir la ou les lignes d'appel à l'option après patch :
[dll] sane_control_option(handle=0x134a1d0,option=9,action=1,value=0x7ffdf74d0b60,info=0x7ffdf74d0b54)

Le patch modifie une lib cpython, distribuée par le paquet hplip, donc il faut soit l'installer lui (et pas la partie libsane comme je faisais un moment) soit juste copier la lib comme un bourrin.

Rapport de bug d'où le patch semble venir (Debian a "juste" importé 34 (!) patches de Fedora… entre autres) : https://bugzilla.redhat.com/show_bug.cgi?id=1684434

Proxmox est passé (il y a longtemps) d'un simple tar disque virtuel + conf à un format perso (mais ouvert) pour contenir les backup. Pourquoi pas, et il y a des raisons apparemment compréhensibles.

Cependant, on peut être amené à vouloir vérifier un backup ailleurs, sur une machine non-Proxmox (son desktop par exemple). Il existe un outil pour gérer ces sauvegardes mais apparemment pas trop dissocié ni dissociable… il vaut mieux être prévenu du coup, ce que je fais là.

Au pire du pire on peut faire comme moi et juste copier l'exécutable et les libs à la main, si on est sur une distro pas trop différente ça se passera bien (moi du coup de Debian 10 à Debian 10 ça a été crème :)).

Si on s'est trompé de nom (ou a oublié une parie) à l'installation d'une machine Proxmox, renommer n'est pas trop compliqué, suivre la doc officielle. Par contre (comme dit ici : https://memo-linux.com/proxmox-renommer-un-noeud/) il peut être nécessaire de faire un bon vieux reboot au bout, en tous cas on n'a pas réussi sans, même à relancer la plupart des services.

Sous Proxmox, il y a en fait une base sqlite qui reprend les configurations et qu'on ne croise quasiment jamais. Les fichiers texte sont matérialisés au lancement du démon PVE, et sont synchronisés (de manière bidirectionnelle, on peut les éditer) en permanence. Si on a des vieux restes par contre, et que éditer les fichiers nous est refusé (on se fait jeter sur les permissions d'écriture), il peut être nécessaire de taper dans la base. Il faut le savoir…

Après la base est pas bien méchante, c'est une seule table "tree" où il y a les fichiers quasiment tels qu'ils sont créés, que ce soit le corosync.conf ou ceux propres à PVE. Voir l'article lié sur comment purger, mais c'est sur SQL de base.

… en tous cas sur un Tplink Archer C7 v4, le hardware offloading fonctione avec OpenWRT 19.07 ! Je suis passé de environ 350 mbps avec iperf3 à 750 mbps (donc proche de la limite à 800 de mon abonnement fibre). C'est pas mal de savoir qu'un firmware libre arrive à ces débits sur du NAT sur un routeur grand public.

À savoir que l'offload se fait à coup de règles iptables, se configure donc au niveau du firewall (et si on utilise l'interface luci, ce sont des cases à cocher : Système -> Firewall -> software offload et hardware offload).

Exemple :
FLOWOFFLOAD all -- anywhere anywhere / !fw3: Traffic offloading / ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw

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 !

Intéressant ces mini-différences de prononciation à travers la francophonie d'Europe… et comment ils voient même maintenant encore se balader des prononciations comme pour le klaxon. Et moi dans ma grotte qui ai toujours supposé que les gens qui disent -onne savent pas lire :P

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.

Je confirme que copier la DB SQLite mmssms.db et les data MMS à la main fonctionne encore, d'un android 4.4 vers un 7.1 en tous cas.
Par contre si l'appli était déjà lancée avant, les données n'étaient pas vues, j'ai dû reboot… je suppose qu'il y a un cache.

Tiens jouons un peu sur les chiffres, pour comparer à la louche (ordre de grandeur) la rente du gentil pauvre et la rente du méchant riche. Partons du RSA. Pas de troll "c'est pas assez/trop/branleur/etc." pour l'un ou pour l'autre, on s'en fiche là, on parle juste maths et on se concentre sur les revenus/rentes, pas le capital. On ne parle pas non plus de chômage ou autre allocation, juste le RSA.

Donc d'après ce site le RSA pour une personne seule c'est 559.74€ par mois. Donc 6716,88 par an.

Si on part sur de l'assurance vie, le placement préféré des français (!), on trouve à ce lien-là que du 2% de rendement c'est possible, pas rare : https://www.lerevenu.com/placements/assurance-vie/assurance-vie-les-rendements-2018-des-meilleurs-contrats. On soustrait la CSG de 17,2% et on ignore l'impôt sur le revenu (trop compliqué avec des délais de possession, un choix entre forfaitaire abattement ou barème progressif etc. et existe aussi pour le RSA) et on arrive à 1.656% par an. 6716,88÷1.656×100 = 405608 et donc une personne au RSA a une rente équivalente à 400k€ d'assurance vie.

Si on part sur un placement en actions, qu'on ignore la spéculation (bah oui on parle de rente là, pas de capital on a dit), entre les boites qui n'ont pas de dividende et celles qui baissent de cours tout en gardant leur dividende haut on doit atteindre en moyenne du 3% sans trop se fouler (voir des pages avec les descriptions de porte-feuille de tel ou tel ponte du domaine). En appliquant la flat tax de 30% (oui ici j'inclus donc l'impôt sur le revenu, le calcul sera d'autant plus juste) on a du 2,1%. 6716,88÷2.1×100 = 319851 et donc une personne au RSA a une rente équivalente à 320k€ de placement pépère en actions.

Si on part sur de l'obligataire, je n'ai pas trouvé de moyenne mais de toutes façons le taux actuariel, si la valeur est assez liquide, s'ajustera en fonction du moment… là j'ai sous les yeux une obligation du crédit agricole 1,50 % décembre 2018 / 2028 et actuellement en juin 2019 elle cote à 102% donc à peine au-dessus. Si on applique aussi la flat tax, on a 1,05% (oui c'est pire que l'assurance vie car eux ils ont d'anciens placements à des taux plus hauts, alors que ici on parle de là maintenant sans arriérés). 6716,88÷1.05×100 = 639702 donc il faudrait 640k€ à investir dans la CASA 1.5 2018 pour arriver à un RSA.

Je trouve intéressant de voir cette comparaison, parce que pour moi 400k€ d'assurance vie à son nom c'est déjà une rente conséquente alors qu'au final, actuellement, c'est ce qui correspond à un RSA… il faut croire que rentier sur le capital avec peu de risque c'est pas efficace actuellement. Même si cette comparaison rapide est pleine d'approximation.

Je squate de plus en plus /dev/shm sans soucis pour tout ce qui est temporaire/calcul, soit pour économiser des écritures sur carte SD (ou même SSD avant), soit pour la rapidité d'accès et je n'ai jamais eu de problème. Je vais là simplement parce que c'est un tmpfs (~ ramdisk) qui est souvent disponible, en tous cas sur du Debian(-like).
Mais il semblerait que par défaut systemd soit supposé vider les fichiers à la fin de la session d'un utilisateur (typiquement quand on quitte la dernière connexion SSH à une machine). J'ai rencontré ce "problème" seulement maintenant… en mode gros WTF.
Bon à savoir donc (et si vraiment on veut on peut facilement le désactiver avec RemoveIPC=no dans logind.conf apparemment).

Souvent cité comme visualiseur de données de Graphite, Grafana est un outil web de visualisation de données arbitraires. Comme il n'est pas lié à un format de données ou une base de données précise, il est obligé d'être très souple, ce qui est plutôt pratique MAIS forcément on doit tout définir à la main… ce qui les a conduit à mettre en place un espace d'échange de "dashboards" communautaire plutôt pratique.
Pour l'installation, j'ai juste pris le deb fourni, dans une VM dédié… ça juste marche et puis c'est tout. Après on peut se balader dans l'interface, ça fait très web 2.0 lourd appli etc. mais en vrai c'est quand même pratique d'avoir ses graph interactifs, de pouvoir zoomer/voir précisément, etc.
Il y a un mécanisme de "commit" des modifications, ce qui fait qu'on ne risque pas trop de "casser" ses graph par erreur.
En plus de Proxmox, j'ai aussi installé un collectd (paquet dispo dans Debian) qui envoie dans Graphite. Le grafana a donc accès à ces deux sources via l'API de Graphite.
Le dashboard qui a marché immédiatement pour collectd (les autres avaient des problèmes d'accès aux données, genre sous-dossier vs '.' etc.) est : https://grafana.com/dashboards/9576
Dans les variables du dashboard, ils ont pensé à laisser une variable pour le nom du serveur ce qui fait qu'on a un menu déroulant pour passer de l'un à l'autre, pratique.
Pour l'instant le seul "problème" de Grafana outre le côté appli web, c'est que le format des dates est hard-codé de partout, on ne peut pas le changer, et est à l'américaine, ce qui est confusionnant pour nous… https://github.com/grafana/grafana/issues/1459

Je pense qu'avec proxmox + collectd + graphite + grafana on a moyen de faire quelque chose de vraiment propre pour surveiller une infrastructure (probablement plus propre qu'avec un outil tout fait comme zabbix, mais beaucoup moins clé en main car les données et le visualiseur sont décorrélés donc il faut passer du temps à tout définir, ou tomber sur un dashboard tout fait qui répond au problème).

Lié depuis la page de Proxmox comme outil de stockage/centralisation de données de monitoring implémenté en natif, graphite est un petit outil simple qui permet de stocker/gérer n'importe quelle série de données.
La partie serveur est dans Debian stretch. La partie lecture (API/Web) n'est que dans les backports…

À partir du README Debian (/usr/share/doc/graphite-web/README.Debian), j'ai dû faire cela pour qu'il tombe en marche :
sudo touch /var/lib/graphite/graphite.db
sudo chown _graphite:_graphite /var/lib/graphite/graphite.db
sudo chmod 0600 /var/lib/graphite/graphite.db
sudo chown _graphite:_graphite /var/lib/graphite/
sudo chmod 0700 /var/lib/graphite/
(éditer /etc/graphite/local_settings.py au besoin)

Pour la partie Django/web :
sudo -u _graphite /bin/bash -c 'graphite-manage migrate --run-syncdb'
sudo -u _graphite /bin/bash -c '/usr/bin/django-admin runserver --settings graphite.settings 0.0.0.0:8080'
sudo -u _graphite /bin/bash -c 'graphite-manage createsuperuser'

Le serveur HTTP intégré à Django pour les tests/développement n'a pas voulu me servir les fichiers statiques, même en mode debug. En suivant des tuto, j'ai pu utiliser uwsgi à la place…
sudo -u _graphite uwsgi --plugin python,http --http 0.0.0.0:8080 --chdir /usr/share/graphite-web/ --wsgi-file /usr/share/graphite-web/graphite.wsgi --master --processes 4 --threads 2 --stats 127.0.0.1:9191 --static-map /static=/usr/share/graphite-web/static/
Ce service HTTP est utile soit pour accéder directement à graphite-web (mais j'ai pas trouvé super pratique même si ça fait le boulot), soit accéder au données via l'API, via d'autres outils.

Pour la partie stockage/serveur, simplement installer le paquet graphite-carbon a suffit.