Sytoka Modon a écrit 4550 commentaires

Ma question sur le transactionnel n'était pas à propos de SQL / NoSQL mais plutôt concernant le théorème CAP : https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP

Si on accepte de faire sauter le C (le coté transactionnel), on peut alors avoir une base répartie clusterisée master master beaucoup plus facilement.

En tout cas, je te remercie pour toutes tes réponses très détaillées. C'est vraiment un projet intéressant.

Je me pose toujours la question de la pertinence d'une BD qui stocke à la fois des paramètres de config et de session… En général, ce sont les mêmes identifiants qui permettent d'accéder aux deux alors que par exemple pour la config, seul un identifiant en lecture seule est utile dans 99% des cas et s'avèrent bien plus robuste aux attaques.

Par ailleurs, je n'aime pas trop les config en base de donnée, cela ne se pousse pas trop facilement via cfengine, puppet, salt… Mais c'est une opinion personnelle. Pour la sauvegarde, c'est mieux aussi de mettre les trucs vraiment important séparés des trucs pas fondamental.

A-t-on besoin d'une base de donnée relationnelle, donc avec transaction ? Si non, une base de donnée type Riak ou Etcd permet de clusteriser de manière quasi transparente. Si oui, a-t-on besoin des transactions sur toutes les tables ?

Avec un service clusterisé, pas besoin de se fatiguer à gérer le reboot, d'où ma question en RAM. Si un des noeuds du cluster reboot, les deux autres (si à trois) assure le job. Si les trois noeuds tombent, alors les sessions tombent mais cela devrait arriver très rarement. Bref, la clusterisation solutionne des problèmes et peut en amener d'autres. Mais comme le restart pour le HPC, si on y pense pas dès le début, c'est pas toujours facile à ajouter après.

Bonne continuation.

Non, il y a un annuaire LDAP… C'est indiqué dans la dépêche.

Pourquoi il a besoin d'une base de données pour fonctionner ? Il aurait pas pu en utiliser une qui soit en cache RAM ? Que doit-il écrire sur le disque ?

Sous jasent à ma question, il y a deux intérêts :

• coté RGPD, plus c'est en RAM et moins c'est sur le disque et plus c'est "facile" de montrer qu'on ne conserve pas les données

• coté Admin Système, plus c'est en RAM, moins il y a besoin de stockage persistent d'une instance à une autre en cas de reboot (VM OpenStack par exemple)

Autre question, ton service est capable de se clusteriser ?

Je n'y connais rien aux statuts des entreprises mais :

• il existe google.fr ;

• il y a des employés google en France.

Personnellement, cette histoire d'impôt traîne depuis plus de 20 ans donc soit on nous cache quelque chose, soit on y gagne nous aussi… Je pense un peu des deux. Je ne suis pas sur que Total, PSA, Renault, Airbus payent leur impôt de manière équivalente dans tous les pays…

Je suis donc persuadé que si le sujet n'avance pas, c'est que nos dirigeants n'ont pas envie que cela change. Au niveau global, la France (et les pays Européen doivent être gagnant.

PS : y a-t-il une loi disant qu'internet est un lieu ouvert sans règle ? Si non, qu'est ce qui empêche de bloquer google en France, si les machines sont physiquement hors du territoire de l'UE ? Je fais exprès de prendre la position inverse histoire de faire un raisonnement par l'absurde comme en Math.

En tout cas, en ne payant pas d'impôt (à sa mesure) en France, il vole les français ;-) (même si légalement, les bidouilles fiscales sont autorisées)

Installer le plugin Tasks :https://plugins.geany.org/addons.html

«The tasks plugin goes through a file being edited and picks out lines with configurable keywords (e.g. "TODO" or "FIXME") in them. It collects the text after those words and puts them in a new "Tasks" tab in the message window. Clicking on a task in that tab takes you to the line in the file where the task was defined.»

apt-get install geany-plugin-addons

Une petite lecture fortement instructive sur les capabilitys : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-164/Les-capabilities-sous-Linux

Une petite question que je met pose : quid des capabilités fourre tout ? Il me semble que dans le noyau il y a en quelques unes. Ne faudrait-il pas faire le ménage dans le noyau pour que certaines capabilités ne soit pas sur-utilisés par rapport aux autres. De mémoire, il y avait CAP_NET_ADMIN ou CAP_SYS_ADMIN par exemple.

Yep, ça sent effectivement l'exercice de cours à 10 km ;-)

Il sont de toute manière plus compétent que moi qui fait une fote par phrase et ait parfois du mal à me relire 24 h après !

Ces boites devraient prendre une énorme amende à chaque fois qu'elles font ce genre de connerie. Un particulier qui pose une caméra chez tous ses voisins pars directe en taule…

si on lui ajoutait les moyens mis sur stratis.

Justement, pour moi, il y a peu de moyen sur Stratis car l'objectif est d'avoir un système fonctionnel en partant de brique robuste et éprouvé. Donc on corrige ici ou là les implémentations "à la marge".

Le boulot fait dessus servira d'ailleurs à l'ensemble des systèmes de fichiers.

C'est une voie qui a été proposé dès le début mais il a été dit et redit par les partant de Btrfs qu'il n'y avait que la voie de ZFS qui s'occupe de tout qui était possible…

Perso, je ne suis pas mécontent qu'une voie plus traditionnel avec de la découpe par morceaux adaptable à tous les systèmes de fichier à terme soit déjà fonctionnelle.

Je disais cela car le recrutement à l'académie est ouvert sur toute personne parlant français (de mémoire) et que malgré tous les comités qu'on peut avoir ici ou là, c'est cette académie là aujourd'hui qui représente "officiellement" la langue.

Le fait que Redhat ne supporte plus btrfs ne signifie pas que le FS ne vaut rien, c'est un choix d'affectation de ressources.

La RHEL est une distribution orienté serveur avec support long terme. Si RH ne supporte plus Btrfs, c'est qu'ils considèrent qu'ils ne sont plus capables de fournir un vrai support sur 7 ans et que le système de fichier n'est pas assez robuste aux pannes. Donc ils ont estimé que trop de client auraient des soucis et qu'ils ne seront pas en état de les aider à récupérer des données.

En production, l'important est de ne pas perdre les données par une bête panne électrique ;-)

Cela ne signifie pas que Btrfs ne fonctionne pas dans un certain nombre d'autres cas.

La force de l'architecture en étage !

XFS est aussi très stable, très performant, gère des gros systèmes de fichier et la plupart des briques ont été ajoutés petit à petit. D'ailleurs, initialement, ils n'avaient pas prévu de pouvoir mettre tout cela puis, de mémoire, avec les extends, ils se sont rendus compte qu'au final, c'est possible de faire du cow sans coût énorme.

Je pense qu'il y a une bonne dynamique de développement communautaire sur XFS, mais en gardant des bases stables et très robustes. De mémoire, RH arrache par exemple les prises électriques de ses serveurs plusieurs fois, même au reboot, pour valider un système de fichier.

Oracle a besoin de ZFS et Oracle a abandonné Solaris. Il est donc plus que probable qu'Oracle mettre à jour la licence de ZFS et la bascule sur la GPL. Enfin, c'est ce qu'il me semble le plus naturel s'ils ne veulent pas se couper l'herbe sous le pied (mais avec Oracle, tout est possible).

À noter que SGI avait donné de la même manière XFS au noyau il y a maintenant pas mal d'année ;-)

L'Académie française n'a pas de réelle compétence juridique

L'Académie française est en réalité l'académie de la langue française. Il est tout naturel d'y retrouver des personnes de toute la francophonie.

Ne pas confondre le Français (langue) avec la France (pays).

Après, c'est clair qu'elle ne transpire pas le dynamisme ;-)

Et comme ZFS est de plus en plus intégré… il est de plus en plus probable que Btrfs finisse comme ReiserFS j'ai l'impression, bien que sa conception soit plus récente et ait essayé d'éviter certaines chausse-trappes de ZFS.

Moi je vois autour de moi que tous les gros volumes sont sous XFS… (ou ZFS) et qu'il y a très peu de soucis dessus. Je parle pas du / mais de partition au delà de 50To par exemple.

s/cryptage/chiffrement/

Voir https://chiffrer.info/

Il y a pleins de données sensibles sous /, par exemple ton mot de passe (mais aussi pas mal de données dans le log, dans les dossiers temporaires…), c'est absolument nécessaire de chiffrer cette partition comme les autres.

Il faut rajouter à luks du second non pas une phrase de passe mais une clef binaire sous forme de fichier (un dd de /dev/randon). Alors le montage peut être automatique.

Pour tout ce qui est réseau local, cela change…

Il n'a pas été prévu de mettre IPv4 dans IPv6 dès le début. C'est une des multiples options qui n'a pas été normalisé dans le standard et rendu obligatoire, ni mis en œuvre donc elle n'a pas été réellement abandonné. C'est plutôt cette voie qui a été abandonnée.

Et sinon, je ne suis pas d'accord, en gardant une logique très proche, via un système de template, tu avais un seul fichier pour les deux systèmes IP alors que là, tu as réellement deux implémentations qui sont assez éloignés. Tu ne peux pas faire de bête copier coller. C'est très différent. Pour un fabricant de commutateur, ce n'est pas un petit boulot que d'assurer deux piles fonctionnelles sans bogues. C'est d'ailleurs peut être une des raisons qui pousse tous les constructeurs de commutateurs à basculer sous Linux !

Je sais bien que changer la taille des IPv4 casse TCP/IP. Mais il y a une différence en casse et casse…

À mon sens, il était possible de refaire un IPv5 en augmentant la taille et presque rien d'autre. Tu aurais eu un préfixe imposé qui mettait IPv4 dans IPv5 et basta. Le code des OS et des routeurs aurait effectivement du être modifié, a minima, en prenant en compte cette nouvelle taille.

IPv6, ce sont des changements beaucoup plus profond. Tu oublies ta pile IPv4 et tu recode tout depuis le début. Bilan, il a fallu le faire dans tous les équipements réseaux et ce n'est pas finit. Il faut en plus continuer à maintenir et à faire évoluer les deux piles en parallèle. Plus de 20 ans que cela dure…

C'est pas toi qui programme les commutateurs et les routeurs. À trop virer de trucs, à trop changer les choses, il faut avoir deux piles complètement différentes.

Bilan : IPv6 était mal implémenté et bogué pendant des années. Et c'est pas encore parfait sur tous les commutateurs (administrable) en vente actuellement.

C'est pas comme cela qu'on change les choses en temps normal. On met un tag périmé sur une fonctionnalité qu'on enlève des années ensuite. Ici, il n'y a eu aucun recouvrement. En gros, on a mis deux réseaux IP sur internet en parallèle…