Psychofox a écrit 10949 commentaires

…c'est qu'en est-il de l'intégration avec libreoffice?

Oubliez mon dernier point qui n'est valide qu'avec certains pilotes de stockage et pas le projet docker lui-même.

Suis-je le seul supris de voir un projet avec un script de backup et absolument rien pour décrire le process de restoration des données?

Soit dit en passant GLPI est le cas typique d'une appli qui peut souffrir de quelques secondes d'arrêt chaque nuit et pour laquelle il y a peu de chance de vouloir restaurer seulement quelques lignes ou une table. Et ils semble que les volumes semblent être des bind mounts de répertoires de la machine hôte.

Du coup pourquoi ne pas faire plus simple:
1. docker-compose stop
2. snapshot des volumes et montage sur un autre point de montage sur l'hôte
3. docker-compose up
4. backup des snapshots
5. cleanup des snapshots (peut aussi être réalisé en début de point 2 si on peut supporter d'avoir l'espace utilisé et qu'on veut une copie locale de restauration pour des petites bévues)

L'avantage c'est qu'il n'y a quasi aucun scripting, que t'es absolument sûr que le volume de ta db et du reste de l'appli sont cohérents. Avec ta méthode je ne vois rien qui garantie la cohérence entre le dump mysql et les fichiers copiés. Donc à la restauration tu peux te retrouver avec des fichiers uploadés qui ne sont pas référencés en DB et avoir des trucs pas propres..

Et pour le restore ce serait aussi très simple:
- docker-compose stop
- restoration des données dans le point de montage désiré
- docker-compose up

Du reste en utilisant des vrais volumes plutôt que des bind mounts tu pourrais bénéfichier des capacités de snapshots de docker et faire des backups sur des clones.

Dans les faits t'as tout intérêt à mettre les données dans des volumes séparés des conteneurs car quand tu changes d'image (cas typique de mise à jour), tu remplaces le conteneur par un nouveau.

il peut ou pas impliquer sa hiérarchie dans la publication du code, et si non, il met la licence qu'il veut. Évidemment, dans ce cas, la légalité de la licence est discutable.

Hmmm je ne suis pas juriste mais je doute que le fais qu'un employé fasse une erreur rende la distance non valable/illégale. L'employé en question va avoir des problèmes, pourrait probablement être poursuivi en justice aussi, mais ça n'en terni pas ce qui a été publié.

C'est comme si un employé d'une entreprise vend un produit ou signe un contrat de service à une autre entité. Si son employeur n'était pas d'accord, le produit ne peut pas être retiré au client. Le service rendu ne peut pas être inversé, tout au plus on peut l'interrompre et encore si un contrat est signé avec une date finale probablement pas.

Donc à vue de nez si la licence reste légale et le seul recourt que peut avoir l'employeur c'est de changer la licence pour les futures versions. Et si entre temps il y a eu des contributions externe pour changer la licence il devrait repartir d'une version avant publication ou nettoyer tout le code des contribs externes avant de rechanger la licence.

D’où l'importance aussi du vent dans l'équation. Suivant sa direction, il peut casser le peloton, et provoquer des sous groupe favorisant les échappées. C'est les fameuses bordures

Les bordures c'est pas seulement l'effet du vent. C'est l'association du vent de côté avec la nature égoiste de l'être humain.

Pas besoin de vélo couché ou vélomobile pour aller plus vite que 20-25. Avec un peu d'entrainement et une position adaptée ce n'est pas bien dur de rouler à 30-35 (pour les moins de 60ans j'entends).

Mais sinon vous êtes un peu d'accord. Le VAE non immatriculé, ça sert essentiellement pour aller doucement ou circuler en zones vallonées mais c'est franchement désagréable pour aller vite sur le plat, d'autant plus pour les modèles à assistances chinoises dont la coupure d'assistance n'est pas du tout progressive*.

* bon eux sont débridables sans difficulté via un menu à peine caché donc tout le monde les utilise au dessus des 25km/h autorisé, comme les bonne vieilles mobylettes en somme.

J'ai rapidement été voir et c'est quand même un jolie sac dans le répertoire /var/lib/docker/overlay2. Il y a autant de répertoires que de volumes et comme ça il est difficile de savoir qui appartient à qui. Sans compter les volumes fantômes qui peuvent exister.

En général c'est pas ça qu'on fait. On monte le même volume dans un nouveau container qui fait le copie de backup.

Profiter de la résilience du système pour augmenter la taille de l'infra et diminuer le personnel, tout en parlant d'équipe plus reposée, il fallait oser ;) Je propose d'aller plus loin encore et de remplacer les admins sys chevronnés par des admins junior, car c'est tout bénef (je gueule contre mon presta hébergeur de données de santé à ce sujet, où les "spécialistes" de chez eux arrivent à me détecter des problèmes de certificats invalides car ils ont testé un accès HTTPS en localhost)

Tu mélanges des trucs qui n'ont rien à voir. Une équipe de sysadmin a tout intérêt à diminuer son coût opérationnel pour être plus performants et avoir du temps à dédier sur des projets qui améliore le service rendu. Je ne vois pas le rapport avec ton délire sur les certificats.

Si toi tu préfères gérer tes serveurs comme des petis joujous individuels, t'es soit resté bloqué dans les années 90, soit tu es juste un hobbyiste.

Absolument pas. Croire que les données sont safe car reposant sur un stockage objet est juste une hérésie. A croire que l'incendie d'OVH cette année n'a pas encore servi de leçon. Le jour où ton presta est HS, si tu n'as pas un backup de tes données, tu seras incapable de remonter ton service.

Si c'est hors-sujet. Quelque soit le stockage utilisé pour tes donnérs tu dois faire des sauvegardes. Je ne vois pas pourquoi tu mets stockage objet et distribué en opposition avec les backups.

C'est aussi difficile de classer les pistes cyclables unilatéralements comme plus sûres quand tant d'entre elles semblent conçues pour tuer du cycliste:

Ouais, enfin, en même temps, tu dois impérativement prendre en considération des "microinterruptions" quand tu montes un service. Les sources sont nombreuses (connectivité réseau, surcharge réseau, collisions, attaque DDOS, etc…).

Raison de plus pour en limiter les possibilités quand cela est possible. Je ne vois pas en quoi monter un service plus fragile est un avancement.

Croire que parce que tu utilises un services comme Amazon S3 te protège est une erreur. Certains se souviennent encore très bien de la panne de 2017 qui a duré de longues heures…

Où ais-je parlé de Amazon S3?

Si planifier une interruption de service de quelques secondes le temps de redémarrer la VM dans la nuit du dimanche au lundi à 2h une fois tous les 2 mois est problématique, je pense que tu as d'autres éléments plus urgents à considérer avant

Si je peux avoir un service qui m'offre plus de flexibilité je suis toujours preneur. Une interruption de service quelque secondes pour une vm tous les 2 mois c'est rien en soit. De multiples opérations de maintenance toutes les nuits ça l'est moins. Avoir des systèmes résilients à la perte d'un noeud, c'est moins de maintenance de nuit, des équipes plus reposées, possibilité de gérer des infras plus grandes avec moins de personnel. C'est tout bénef.

, comme la sauvegarde des données par exemple ;)

C'est hors-sujet.

Il n'existe pas que NFS. Je l'ai cité pour l'exemple, mais il y a pléthore de solution pour le partage bien plus robuste !

Oui comme les filesystem distribués comme cephfs.

Je pense que c'est difficile à calculer car les feux ont parfois une période/synchronisation qui change selon les heures de la journée (et parfois sont pilotés dynamiquements en fonction de l'affluence) et suivant l'expérience du cycliste il saura éviter les arrêts. Par exemple un débutant va aller vaguement tout le temps à la même vitesse que le feu suivant à 80-100m soit vert ou rouge. Un cycliste plus expériementé qui passe souvent au même endroit regarde en général plus loin, sait que tel ou tel feu prend généralement x secondes et va anticiper et ralentir un peu plus tôt pour arriver au niveau du feu si possible quand il est au vert ou économiser de l'énergie pour plus tard. Le feu a beau être vert à 150m de là, si tu sais qu'il n'est pas lon autant t'économiser et récupérer un peu plutôt que de maintenir ta vitesse pour devoir freiner fort devant le feu. Aussi en heure de pointe je gagne un temps fou par rapports aux automobilistes en anticipant les verts. La plupart s'agglutinent comme des dégénérés le plus vite possible devant le feu rouge pour pas perdre leur place pendant que moi je ralenti, remonte la file et passe au vert avec déjà 25 à 35km/h et remonte déjà la file du feu suivant avant que les premières autos ont démarrées.

De fait, il pourrait être intéressant de calculer voire mesurer le coût énergétique d'un trajet. C'est sûrement possible avec des capteurs de puissance sur le vélo couplé a un gps, de collecter de façon anonyme les données, de reverser les mesures dans des base de donnée géographique de manière à pouvoir optimisé les trajets en ce basant sur ce coût, fixe pour les dénivelés mais qui peut varier dans le temps suivant le sens et la force du vent, ou les conditions de trafic, ou d'autres paramètres comme le revêtement.

Sans avoir besoin de capteur de puissance, les données openstreetmap contiennent des clés nommés ele= pour connaitre l'altitude. Donc il est possible de calculer des pentes moyennes toutes les X centaines de mètre donc ça peut donner une idée de la vitesse donnée pour différents profiles de wattages moyens.

Sinon tu as cette solution

Heartbeat c'est mignon mais il y a toujours un jour où tu te retrouves avec un split brain à gérer. Et si tu pars sur des solutions de clustering type corosync + pacemaker ça devient finalement plus compliqué qu'un système distribué.

perte de flexibilité…
En quoi ?

Tu patches une machine et la redémarre, tu as entre quelques secondes et quelques minutes d'interruption d'accès selon que c'est une VM ou un serveur physique. Avec un volume distribué dont le client a connaissance de tous les noeuds actifs tu reboote n'importe quel noeud sans qu'il y ait d'impact niveau client, tu peux perdres connectivité à un datacenter complet sans souffrir, etc.

Et nfs et les coupures réseaux, ça n'a jamais fait hyper bon ménage et suivant l'application qui utilise ce FS ça peut être franchement pénible.

Moi j'ai surtout tiqué sur le "avant d'aller au lit".

Je ne crois pas qu'une heure d'écran de temps en temps (mais c'est une drogue dure) si c'est fait au moment opportun.

Après les conseils de parents aux autres parents, c'est toujours compliqué. Qui fait tout parfaitement?

Tu perdrait beaucoup de l'intérêt de la distribution quand même avec ce point de défaillance unique et la perte de flexibilité…

ça n'aurait pas été plus simple d'utiliser rqlite pour rester plus proche de S3QL et pouvoir proposer comme patch?

En général quelque soit le système utilisé tu commence par configurer chaque noeud comme serveur, puis comme client à lui-même pour monter le fs distribué.

Ça peut être un peu perturbant, par exemple sous glusterfs tu vas avoir un volume logique lvm qui va être monté et visible mais servir pour les données locales de ton volume glusterfs et en même temps tu vas avoir un point de montage vers le volume glusterfs et c'est dans celui-là que tu devras travailler pour avoir les données distribuées et ne pas corrompre ton glusterfs. Sous ceph pas besoin de point de montage pour l'OSD (le serveur de volume) mais par contre un peu plus de config à faire pour un simple point de montage distribué entre 3 serveurs.

enfin un projet qui propose le chiffrement.

J'étais peiné de voir que par exemple nextcloud support s3 comme stockage mais que les devs du projets à priori se contrefoutent du chiffrement. Officiellement dans les issues c'est, "ton hébergeur s3, tu lui fais confiance aveuglement ou tu le quittes".

Ils cherchent les problèmes légaux.

Concernant le modèle rolling release, mis à part quelques amateurs éclairés qui mettent à jour leurs serveurs très régulièrement, je n'ai pas vu beaucoup de grandes sociétés "orchestrer" des campagnes de mises à jour sur des parcs de centaines de serveurs de manière régulière (quand je dis régulière, ce ne serait qu'une à deux fois pas an)

Et pour avoir mis en place des mises à jours mensuelles ou bi-mensuelles sur des parcs de >1500 serveurs à plusieurs entreprises ça me désole profondément car c'est essentiellement de l'obstruction psychologique et qu'il n'y a pas de barrière majeure. Ça s'automatise même très bien si on a un bon process qui assure par exemple d'avoir des snapshots de miroirs pour que la mise à jour effectuée en prod se fait exactement avec les mêmes versions de paquets que testés 15j avant en environnement de test, avoir une bonne gestion et connaissance des applis clusterisées, des fenêtres de maintenance bien précises pour les bascules de noeud primaires, etc.

La plupart des admins windows le font mensuellement, un sysadmin unix/linux qui ne le fait pas ou n'en est pas capable est une honte pour la profession.

une table lumineuse c'est pas forcément du gros équipement. Tu en fabriques une facilement et rapidement avec une boite ne carton ou bois, du papier alu, du plexi opaque et ces kits de bandes leds à coller.

Et ça peut servir quand pas utilisé comme objet de déco avec une silhouette ou quelques lettres en bois.

Il manque dans les recommandations l'usage d'une télécommande ou une obturation commandée via un son car même avec un trépied on a vite fait de bougwr un peu.La plupart des réflexes ont un support des télécommandes, voire sont venus avec, j'en ai une pour mon pentax. Á défaut nombre d'appareils compacts ou camera sport style go pro ont une fonction timer qui prend des photos à intervalles donné en continu (mais il faut trier les déchets après). Sur android, opencamera peut être configuré pour prendre la photo au son de la voix.

La pâte à modeler c'est bien. Mais pour commencer avec les enfants les legos ou playmobils sont plus faciles, avec plus de flexibilité pour les legos qui permettent des "effets spéciaux".

Tu te farcis le chrome du browser (window chrome, pas le navigateur) qui sert à rien, des raccourcis clavier qui n’ont aucun sens, des pop up bloquées et autre incongruité du genre.

Les popups sont débloquées au premier usage, inconvénience mineure donc. En contre partie si tu utilises le navigateur plutôt qu'une ribambelle d'applis electron, tu vois une amélioration de ton empreinte mémoire. Ce n'est pas pour ça que je le fais car avec 32GB de ram je suis assez comfort mais sur une bestiole à 4 ou 8GB ça compte.

Je suis certain que l'appli sous windows et Mac avait reçu un peu plus d'amour et de rafinement mais l'appli en version beta sous linux était rellement dysfonctionnelle pour plein de truc. C'est dans ce contexte là que j'ai switché à la version navigateur. Je parle au passé parce que depuis que j'utilises Edge je n'ai pas de souçis donc je ne l'ai pas réssayée recemment mais je ne vois pas de raison objective de retester.