Un pine64 dans un coin et envie de monter vite-fait une sonde de température avec un DS18B20 sous la main ?
C'est devenu facile…
  - il y a une image armbian basée sur Debian Buster toute prête
  - le pine64 est "mainline" depuis un moment donc on peut utiliser un Linux standard
  - il y a même ce qu'il faut pour activer le w1 (one-wire) facilement, aussi facilement que sous raspbian, à coup d'overlay dans le DT

Doc utile :

le branchement des connecteurs
http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64%20Pin%20Assignment%20160119.pdf

Des thread de forum (pointus en tous cas pour moi à propos de DTD) :
https://forum.pine64.org/archive/index.php?thread-1004-1.html
https://forum.pine64.org/archive/index.php?thread-6987.html

et ci-lié comment activer les overlays et utiliser leurs paramètres.

Dans mon cas j'utilise le GPIO 18 du connecteur Pi-2-like. Donc pin PC8.

Il m'a suffit d'ajouter ces deux lignes dans /boot/armbianEnv.txt et pouf le thermomètre est reconnu et fonctionne :
overlays=w1-gpio
param_w1_pin=PC8

Le plus long a été de trouver les infos, essayer de la comprendre, découvrir que tout est déjà prêt et pré-mâché…

Source de l'edit : expérience. Après si t'es bien avec ta banque tu peux toujours demander l'extourne de ces frais… par exemple dans le cas d'une assurance-vie qui traine dans un coin (lire : pas dans ta banque principale pour raison historique) mais que leur SI lie forcément à un compte courant pour leur simplifier la gestion (ce que je comprends)… et que donc ce compte sera toujours inactif par définition et n'est en réalité pas du fait du client.

Ça serait une clause du contrat avec la banque, limite ça serait moins pire qu'une sorte d'arnaque légale… même si ce sont peut-être les lobbys banquiers qui l'ont institutionnalisée. Et oui j'ai lu l'argumentaire de la loi eckert, mais je suis pas pour autant convaincu, surtout en 2020.

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

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.

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

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.

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