rahan a écrit 145 commentaires

On peut faire tourner du code libre sur les calculatrice de SwissMicros. Par exemple, il y a une ré-implémentation libre de la HP-48: DB48X dont le code est sous licence LGPL-3.0.

Bien sûr, le coût de ces calculatrices n'est pas le même qu'une Casio, une TI ou une NumWorks…

A priori, pour charger pendant des heures à 16 A, il faut une prise spécifique dite "renforcée". Je ne pense pas que les prises pilotées sont conçues pour fonctionner dans ce mode opératoire. Tu as deux risques : surchauffe dans le temps liée à une mauvaise connexion ou un mauvais dimensionnement ; arc électrique lors de la coupure en charge. Dans les deux cas, c'est un risque de départ de feu. Internet est plein d'exemples de ce genre de prises qui ont tendance à brûler lorsque des courants importants sont en jeu.

Je n'ai pas les détails de ton installation électrique ni de la prise que tu utilises. Tu es peut être dans le régime normal de fonctionnement mais je pense qu'il faut faire attention lorsqu'on doit gérer de forts courants avec ce genre de prises pilotées souvent provenant de fournisseurs à bas coût.

Des prises connectées ZigBee car ma voiture électrique se recharge dès que le courant arrive.

Je ne suis pas sûr qu'une prise connectée ZigBee soit prévue pour faire passer pendant des heures des courants de l'ordre de 10 A. Tu n'as pas un moyen de piloter plutôt le chargeur ou la voiture ?

Oui c'est possible mais il faut faire attention car on ne veut pas que la machine de backup compromise puisse attaquer toutes les machines qu'elle peut contacter. Une manière simple de le faire avec rsync est de n'autoriser dans .ssh/authorized_key que la commande exacte utilisée pour faire le backup. C'est un peu plus contraignant car rajouter un dossier à sauvegarder implique de changer la commande sur les 2 machines.

Bonne remarque. C'est quelque chose que j'avais fait dans mon précédant système de sauvegarde. J'utilisais Burp qui permet d'avoir un client qui ne peut que pousser des sauvegardes sans pouvoir les effacer. Le nettoyage est effectué côté serveur par une logique définie à l'avance. J'aimais bien cette solution mais j'avais eu des problèmes avec incompatibilité de versions entre clients et serveur. Je voulais aussi m'affranchir de la gestion du stockage de sauvegarde pour lequel je pense que les solutions "cloud" sont plus intéressantes : abordable, sans risque de sécurité (sauvegardes chiffrées), sans besoin de maintenance…

Je pense que restic sur du stockage S3 ne permet pas ce genre de séparation.

475 Go utilisé sur 1,8 To soit 28 % d'utilisation. On est loin du disque rempli. Mais c'est une bonne remarque, ça faisait parti des mes soupçons premiers (btrfs gère mal les disques pleins, sans Trim activé le contrôleur peut penser que le disque est plein, ma volonté de faire un formatage par le firmware…)

Mon modèle de SSD a une garantie de 3 ans ou 720 To TBW (Total Bytes Written): Samsung SSD Limited Warranty For All Samsung SSDs

Mes SSD ont 46 To ou 50 To TBW. On est loin des limites mais effectivement, le choix de QLC n'était peut-être pas pertinent pour un NAS…

Tu as testé de faire tourner llama.cpp (ou autre) sur openCL/ROCm ? Parce que toutes mes tentatives ont été infructueuses. Je ne sais pas si c'est lié à ma distribution (Debian testing), ma carte vieillotte ou les drivers qui hésitent entre libre et propriétaires…

Je suis preneur d'un retour positif d'utilisation d'openCL sur AMD. Il y a quelques années, j'avais réussi à utiliser ma carte avec Blender, mais tout est cassé chez moi depuis environ 2 ans en ce qui concerne openCL sur GPU (ça marche sur CPU, mais il y a peu d'intérêt).

Je serais curieux de savoir comment tu arrives à faire tourner ces modèles avec un GPU AMD. J'avais essayé de voir si ma vénérable Radeon RX 570 pouvait être utile mais visiblement, en dehors de CUDA (NVIDIA propriétaire), point de salut…

Je vais dans Aliases, puis + Ajouter un alias.

Là, dans le champ Alias d'adresse(s), je lis:

Adresse(s) courriel complète(s) ou @example.com, pour capturer tous les messages d'un domaine (séparées par des virgules). Seulement des domaines Mailcow.

Qu'est-ce qui t'empêche d'avoir des alias * dans Mailcow ? Pour mes mails perso, j'utilise Mailcow et j'ai un alias *. Cela fonctionne sans soucis.

Je me réponds, j'ai testé hier pour une présentation simple. La conclusion est : Ce n'est pas sec.

J'ai utilisé ce template : https://github.com/andreasKroepelin/typst-slides. Rapidement je me suis rendu compte que les tables de base de typst ne supportent les cellules fusionnées, j'ai donc rajouté le module : https://github.com/PgBiel/typst-tablex.

C'est là que les ennuis ont commencés. tablex n'est visiblement pas compatible avec les animations de slides. Il faut choisir : une jolie table statique ou une table plus simple qui ne peut pas s'animer.

Et puis soudainement typst plante aléatoirement. Visiblement c'est un bug connu : https://github.com/typst/typst/issues/1370. Par contre ma distribution n'a pas la bonne version de Rust pour recompiler typst.

J'ai finalement copié mon fichier sur https://typst.app/ pour terminer le boulot rapidement. Cela n'a pas fonctionné longtemps : pour une raison inconnue, impossible de rajouter une quatrième page.

Au final, j'ai passé 2 heures à essayer de faire 4 diapos que j'ai finalement fait salement avec le PowerPoint du boulot…

Sur ma TODO list de ma transition de LaTeX à typst:

• https://github.com/andreasKroepelin/typst-slides
• https://github.com/lvignoli/diapo

Merci pour ces explications et pour permettre de mieux comprendre les modes de fonctionnement des éoliennes. En fait ce que je n'avais pas bien compris c'est l'échelle de la courbe de puissance ; je la voyais plus raide. Je pensais que les éoliennes étaient plus souvent à puissance nominale alors que dans les faits, elle ne le sont que 2 % du temps.

Je crois que tu te trompes dans ton calcul de facteur de charge.

1.3 MW de production moyenne totale
1.3 ÷ 4 = 325 kW de production moyenne par éolienne
2 MW de puissance nominale (voir première colonne des graphiques)
325 ÷ 2000 = 16 % de facteur de charge moyen.

Justement, c'est ce qui m'interpelle : ce sont des éoliennes de plus de 10 ans. Elles auraient dû être installées sur un site rentable. Et là, elles ne semblent qu'atteindre 15-19 % de la puissance max.

D'après ce que je lis des graphs, le facteur de charge de ces éoliennes est entre 15 et 19 %. (Si on considère la puissance nominale de chaque éolienne à 2 MW comme le laisse supposer la première courbe; une énergie fournie sur 5 ans de 13 à 17 MWh). On est donc bien en-dessous de la moyenne européenne.

Les données interrogent sur la rentabilité d'un tel site. La production a l'air vraiment sous-optimale. Tu es sûr des données ?

Je ne comprends pas comment un tel site a pu être construit. Il y a peut-être un paramètre fiscal/subventions que j'ignore…

C'est d'autant plus étonnant que c'est l'unique site mis en open-data par Engie. Ce n'est pas la meilleure pub pour l'éolien…

Mon seul regret de cette version de Debian c'est l'absence de FreeIPA-client. Toutes mes machines s'authentifient sur 2 serveurs FreeIPA. Je vais devoir attendre que le paquet apparaisse dans les backports avant de faire la mises à jour…

Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…

Pour la partie SQL, tu peux faire un truc du genre :

TMPDIR=`mktemp -d`

echo "  Backup MySQL..."
docker-compose exec -T maria sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > $TMPDIR/dump.sql

RESULT="$?"
if [ "$RESULT" != "0" ]; then
   echo "Error in MySQL dump."
   exit $RESULT
fi

echo "  Running your backup software...."
rm -rf $TMPDIR

Après, il faut que tu gères la sauvegarde des données (et aussi du php). Perso, j'utilise Burp.

Tu as aussi un peu de doc sur le site de Nextcloud.

Désolé d'être rabat-joie mais les bonnes pratiques te disent qu'en cas de compromission, il faut tout effacer pour repartir sur des bases saines. Tu t'assures que tu as sauvegardé les données puis tu formates et tu réinstalles tout proprement en t'assurant d'utiliser des sources sûres et à jour.

Une fois qu'un système a été compromis, il est très difficile de s'assurer qu'aucune porte dérobée n'a été laissée.

Une autre chose : tu changes tous les mots de passe. Tu peux considérer que tous le mots de passe utilisés sur les services de cette machine sont compromis. Il faut donc les changer ainsi que ceux que tu aurais réutiliser sur d'autres services.

Bon courage.

Je recommande BURP. Je m'en sers depuis des années pour sauvegarder des serveurs linux, des PC linux, des portables linux et des portables Windows. C'est packagé dans Debian donc il n'y a pas grand chose à faire pour l'installer. Il y a aussi un installateur Windows. Ça marche très bien et se laisse oublier. En cas de souci, le développeur est très réactif sur la mailing list.

SQL est sûrement beaucoup plus adaptée à mon usage mais je crains de devoir réinventer la roue pour chaque fonction déjà prévue par sssd. Mon idée était de s'ennuyer un petit peu avec la partie serveur pour pouvoir utiliser coté client des procédures simples et déjà intégrées dans les distributions.

Merci pour ce retour. Je vais essayer FreeIPA sur une machine virtuelle (CentOS) ou dans un container (docker).

Toutes mes configurations sont déjà gérées par Ansible dans un dépot git. C'est très pratique quand on a tendance à réinstaller régulièrement de vielles machine.

C'est une des solutions que j'avais testé (avec GoSA qui ne semble plus développé). Je ne l'avais pas retenu car une partie des modules que je voulais utiliser à terme (sudo, Kerberos) n'est disponible que dans la version propriétaire : https://www.ldap-account-manager.org/lamcms/featureMatrix