Je ne suis plus le mainteneur de la section Sécurité depuis le noyau 4.3. Est-ce qu'un modérateur peut retirer mon nom de la dépêche ? Merci de ne pas me rajouter dans les suivantes.
Merci pour la correction ! Il nous faut un nouveau mainteneur pour la partie système de fichier pour éviter justement les traductions un peu rapides de ma part :). Intéressé ?
Pour éviter d'avoir à sortir le live-cd pendant les tests ou suite à une mise à jour fâcheuse d'une version du noyau, je conseille :
l'installation du noyau LTS en plus du noyau classique (paquet linux-lts) ;
la création de plusieurs initrd pour chaque noyau, un avec et un sans systemd, au cas où.
Tout ceci est très facile à faire puisqu'il suffit de copier /etc/mkinitcpio.conf vers /etc/mkinitcpio-systemd.conf par exemple, de faire les modifications désirées, puis de modifier les fichiers /etc/mkinitcpio.d/linux*.preset pour ajouter un nouveau PRESET utilisant la config systemd ;
Un petit mkinitcpio -p linux && mkinitcpio -p linux-lts et hop, il ne reste plus qu'à créer les entrées dans GRUB/gummiboot pour avoir le choix au boot en cas d'imprévu.
Seul inconvénient : il faut avoir de la place dans sa partition /boot.
Mon Firefox 32 ne voulait plus se connecter à mon FFSync 1.1 auto-hébergé. Je pense qu'il faut garder une "ancienne"/lts version de Firefox pour continuer à utiliser l'ancien FFSync.
Je suis en train de faire les paquets pour Arch Linux de la nouvelle version de Firefox Sync et de Firefox Accounts. Et bien c'est très pénible. RIEN n'as été prévu pour que ce soit installé proprement (il n'y a même pas de target install dans le Makefile).
Pour Dave Chinner, le mainteneur actuel de XFS, c'est le système de fichier le plus abouti à l'heure actuelle :
Moi aussi, tout ce que je fais, c'est le meilleur et les autres sont plus nuls. Quelle référence.
J'ai clairement mentionné que c'était l'opinion du mainteneur de XFS et donc que c'était probablement biaisé. J'aurais dû dire « stable » plutôt que « abouti ».
Comme toujours, c'est uniquement le système de fichiers choisi par défaut, il est tout à fait possible d'utiliser Ext4 ou Btrfs à l'installation.
Il manque quelques points que je n'ai pas eu le temps de traduire pour la dépêche. Ils sont détaillés (avec ceux que l'on a traduit) dans ce document qui référence une grande partie des nouveautés.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Ca s'appelle du SSL Pinning. Le client refuse de continuer si le certificat présenté par le serveur n'est pas le meme que celui present cote client. En clair: a moins d'avoir la cle privee du certificat, ton homme de le milieu il va être dur.
Encore une fois, ce n'est pas du tout de cela dont je parle.
Rappels sur l'établissement d'une session TLS :
ClientHello: Le client envoie la liste des algo supportés ;
ServerHello: Le serveur choisit une version du protocole TLS et quelle "CipherSuite" sera utilisée. Ceci indique entre autre la méthode utilisée pour échanger la clé qui sera utilisée par la suite ;
Certificate: Le serveur envoie son certificat ;
ServerKeyExchange (optionnel suivant les méthodes) et ClientKeyExchange : Échange de clés pour établir le secret utilisé pour chiffrer le contenu de la session ;
ServerHelloDone: Fin du handshake.
L'élément qui pose problème ici est que l'échange d'information (Key Exchange) pour établir la clé de chiffrement se fait avec très peu d'entropie du côté client vu que le client pollen est exécuté très tôt au démarrage du système, avant que les autres services ne se lancent.
Si l'on prend l'exemple de l'algorithme d'échange de clé Diffie-Hellman, et en considérant que le secret généré aléatoirement par le client n'est pas si aléatoire que cela, alors il est très facile pour un attaquant de déterminer le secret partagé obtenu à la fin de l'échange à partir des informations envoyées par le serveur. Il n'a qu'à essayer tous les nombres aléatoires potentiellement générés par le client qui ne dispose pas d'une bonne entropie.
Cela s'applique aussi aux autres algorithmes d'échange de clé parce qu'ils reposent tous sur le principe que le client (au minimum) a généré un nombre aléatoire que lui seul connaît. Ce n'est pas une faiblesse du protocole, seulement un prérequis.
Donc la clé de chiffrement de la connexion TLS peut être obtenu par une personne positionnée en man in the middle entre le client et le serveur, ce qui lui permet ensuite de déchiffrer le contenu de la connexion et donc d'obtenir les données aléatoires renvoyées par le serveur, et donc d'obtenir une très grande partie des informations qui seront par la suite utilisées pour amorcer le PRNG.
Tu l'as super mal prepare ton troll quand meme, tes arguments sont tous bateaux et tu passes surtout pour un clown quand tu réponds.
Je suis presque déçu que cela ai été perçu comme un troll. Je ne me permets pas non plus de traiter les autres de clown. Par contre beaucoup de gens se sont permis de se débarrasser de mes arguments (qu'ils soient bons ou mauvais) en les traitant de FUD, ou en me traitant d'incompétent, ce qui simplifie bien les choses.
Il y a cette page, mais je ne sais pas si elle est vraiment à jour par rapport à ce qui a été implémenté en pratique. Les grandes lignes sont là en tout cas.
A en croire cette partie, l'intégration (pour la partie mobile si j'ai bien compris) consiste à effectuer les actions suivantes avant de lancer une application :
Définir des variables d'environnement ;
Définir quel profil AppArmor va être utilisé.
On a vu plus poussé (et plus difficile à reproduire avec systemd) comme intégration.
Rien ne pointe vers une difficulté particulière pour le passage à systemd et oui, je pense qu'il n'y a presque rien de plus à faire qu'un copier / coller des units systemd depuis une autre distribution et de tester cela. En plus, c'est typiquement dans ce genre de cas que le système de gestion de paquet de Debian est sensé être le plus efficace : changements massifs impactant un grand nombre de paquets de la même façon (ici le remplacement des jobs upstart par les units system).
« Stable » ne veut pas dire sans bug (comme on te l'a fait remarquer, même systemd a des bugs !).
Merci d'énoncer l'évident, tout logiciel a des bugs. Cf commentaire au dessus qui explique le problème avec ces bugs.
Si Upstart était vraiment non-maintenable et broken by design, il n'aurait pas été adopté par RedHat avant l'arrivé de systemd.
Encore une fois, Upstart a bien été utilisé dans RHEL / Fedora mais les services n'ont presque pas été migrés pour utiliser les fonctionnalités d'Upstart. Tout est resté sous forme de script SysVinit.
Je n'ai pas non plus dit que Upstart était broken by design et non maintenable, j'ai dit que le design de systemd était considéré comme meilleur et que plus personne ne serait intéressé par la maintenance d'Upstart.
Le travail d'intégration dans Debian (qui est loin d'être fini) étant fait avec les devs Ubuntu, je ne comprends pas le sens de ton "c'est des feignasses les gens d'Ubuntu, ils n'avaient qu'à faire un copier-coller depuis ailleurs et ça aurait juste marché pour la 14.04" (je schématise, mais c'est ce que j'ai compris de ton commentaire en tout cas).
Si le travail d'intégration est fait avec les développeurs d'Ubuntu pourquoi est-ce que systemd n'est pas disponible dans les dépôts de cette LTS ? La remarque "Il n'est pas supporté" n'est pas valide, il y a plein de logiciels non supportés dans les dépôts d'Ubuntu et même Red Hat propose parfois des "Technical Preview" qui ne sont pas supportés mais qui mettent à disposition des logiciels récents ou des fonctionnalités particulières.
Ouhais enfin upstart est utilise depuis des annees et je n'ai jamais vu un plantage de sa part.
En informatique particulièrement, le fait que « cela marche » n'est pas significatif de la validité de l'approche employée, et ne signifie pas que l'on ne vas pas rencontrer de soucis lorsque que l'on va s'en servir de façon un peu plus intensive par exemple. Sinon on pourrait chmod 777 tous les fichiers et cela marcherait pour tous les utilisateurs lambda (Windows avec le compte administrateur par défaut ?) mais cela ne rendrait pas l'approche plus valide.
Je l'attendais celle là. Je ne me suis pas contenté de prendre tous les bugs ouverts dans Upstart pour les balancer comme argument. Ici, les bugs (qui ont été regroupés par une autre personne que moi) concernent tous des fonctionnalités d'Upstart plus ou moins utilisées dans Ubuntu (pour le démon CUPS par exemple) mais qui sont acceptées comme étant cassées. Tous les fixs relatifs à ces bugs ont été sous forme de contournement dans les programmes impactés et rien n'as été fixé à la source dans Upstart. Je trouve cette situation plutôt étrange.
Si demain je veux écrire un job Upstart pour un démon sous Ubuntu, il va falloir que je prenne la doc, et que je retire toutes les fonctionnalités considérés comme cassées dans les bugs reports. Si ces bugs n'ont pas été fixés pour la LTS, il ne le seront pas plus tard.
Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle).
Ce qui est beaucoup plus facile vu que le noyau utilisé dans la 10.04 par exemple est le 2.6.32, peut-être le noyau le plus supporté de toute l'histoire de Linux et que RHEL 6 est basé sur à peu près les même logiciels, donc que ceux-ci aussi sont supportés.
Fedora has a reputation for focusing on innovation, integrating new technologies early
Intègre vite. Donc, peu de test, donc de bugfixes.
Les versions de Fedora intègrent quasiment les mêmes versions de logiciels que ce qu'il y a dans Ubuntu (Ils sont généralement un poil plus à jour). Par contre, quand il y a des bugs, il ne font pas semblant de ne pas les voir pour ne pas retarder la sortie d'une version (http://www.h-online.com/open/news/item/Ubuntu-10-04-LTS-delayed-by-last-minute-GRUB-bug-990277.html) et ils prennent le temps de les fixer et de tester les changements. C'est notamment pour cette raison que Fedora 20 est sortie si tard. Alors l'argument Fedora intègre plein de trucs donc il y a des bugs est complètement à côté de la plaque vu qu'ils prennent justement le temps de fixer les bugs quand c'est nécessaire. Bonus, ils essaient de fixer les bugs upstream en premier pour que tout le monde en bénéficie.
Ici, c'est expliqué pourquoi en prod c'est moyen… je vais pas paraphraser.
Fedora 20 (la version que je recommande) est encore un cas particulier, et son support est particulièrement long vu les retards de la version 21. De plus, je ne recommande Fedora 20 que comme palliatif en attendant RHEL/CentOS 7 qui sera de configuration très similaire, et de support bien plus long.
Donc, par défaut, une interface graphique est installée? Pour un serveur? ( je sais, la plupart des distros aussi l'installent par défaut, et j'imagine que ça se désactive lors de l'install, mais je me mets au niveau de ton journal en restant sur le par défaut. )
Par défaut avec Ubuntu tu installes la version desktop sur un serveur ? Non, tu prends la version serveur pour les serveurs. Fedora c'est pareil, il y a une version serveur qui n'installe pas d'interface graphique par défaut.
Ah… moi, je préfère celui de Debian, donc celui Debian est mieux et celui de fedora/RHL mauvais. Je suis encore une fois à ton niveau quand tu dis "Debian, si on aime bien sa gestion de paquets".
Je n'ai jamais dit que le gestionnaire de paquet sous Debian/Ubuntu était mauvais. Je ne l'aime pas personnellement ; j'ai donc ajouté la remarque "si vous êtes OK avec le système de gestion de paquets" parce que c'est un facteur à considérer. Je ne rentrerai pas dans le débat RPM/Deb et je n'aurais peut-être pas dû mettre cette mince remarque en premier lieu.
Fedora c'est une version de test et ne doit jamais etre utilise en prod surtout pas sur un serveur.
Je ne conseille pas d'utiliser n'importe quelle version de Fedora, je conseille la version 20, qui est peut être la version de Fedora la plus testée à ce jour et dont le cycle de vie sera le plus long vu les retards de la version 21.
Ce n'est donc pas prédictible, ce qui peut être un problème pour l'admin sys qui veut prévoir ses déploiements à l'avance.
Encore une fois, je ne conseille pas d'utiliser Fedora sur un serveur sur la durée, je conseille de l'utiliser en attendant de pouvoir migrer sur CentOS 7 qui ne devrait pas tarder à sortir.
D'autant plus qu'Ubuntu utilise toutes les features d'Upstart, particulièrement sur le téléphone où il fait partie intégrante du système de gestion du cycle de vie des applications ainsi que du système de sandboxing.
Si tu as un lien avec des informations à ce sujet je suis intéressé.
Upstart est stable et éprouvé, sa maintenance pour 5 années supplémentaire ne devrait pas poser le moindre problème.
Cette collection de bugs encore ouverts et acceptés laisse penser qu'Upstart n'est pas aussi stable qu'annoncé : https://lwn.net/Articles/582585/.
Sur un autre point, je te ferais remarquer que l'intégration de systemd dans Debian est faite en collaboration avec Ubuntu. Ce n'est pas « Ubuntu contre le reste du monde » ici, comme j'ai l'impression que tu le laisse entendre.
Je pointe les cas où Ubuntu est effectivement la seule distributions à supporter certains logiciels. Ce n'est en effet pas le cas pour systemd.
As-tu déjà installé un serveur ubuntu ? As-tu déjà installé et maintenu un serveur tout court ?
Le serveur hébergeant le blog est sous Arch Linux. J'ai géré pendant un temps un serveur sous Debian et j'en gère en ce moment sous Fedora.
Non parce que citer Fedora et Archlinux pour des serveurs, bravo.
Je ne conseille pas d'utiliser Arch Linux sur un serveur. Je conseille uniquement Fedora 20 comme alternative en attendant la sortie de CentOS 7. Dès que CentOS 7 sera sorite, il n'y aura plus aucune raison de mettre Fedora sur un serveur.
RedHat, que tu sembles tant aimer, supporte encore un kernel 2.6.18 en 2014. Je ne crois pas que ce soit encore upstream. Donc cela ne semble pas infaisable.
Red Hat est particulièrement connu pour avoir à disposition une partie non négligeable des développeurs contribuant au noyau Linux. De plus, le support du noyau 2.6.18 (RHEL 5) est dans la phase 3, ce qui signifie qu'ils ne font plus que les mises à jour de sécurité, ce qui réduit considérablement le travail. De plus, ils sont payés par les entreprises achetant du support pour le faire.
Comme 95% des sysadmin, je m'en fiche un peu, du moment qu'on peut faire service mescouilles start.
Si la gestion des services sur un serveur était aussi simple que cela je pense que systemd n'existerai pas.
J'ai toujours eu l'impression qu'à l'inverse c'est RedHat qui ne les ajoute pas automatiquement. Les autres le font.
A ma connaissance, les seules distributions activant les services par défaut sont dérivées de Debian.
Souvent ces services sont inoffensifs tant qu'ils ne sont pas configurés (par exemple Postfix ne relaie pas le courrier). Donc faux problème.
C'est le « Souvent » qui importe ici.
Tu peux installer MariaDB à partir des repo
En effet, c'est une erreur de ma part.
Très peu de distributions utilisent MariaDB par défaut, donc il ne faut pas pointer du doigt Ubuntu comme si c'était une exception.
Non les administrateurs consciencieux n'auront pas laissé des ports ouverts non utilisés donc ils prendront leur temps de savourer leur café ou leur thé avant de se précipiter pour faire une chose ou une autre.
Cela résout en effet une partie du problème. Je vais mettre à jour avec cette remarque.
Ce n'est pas permanent parce qu'ils n'ont pas décris qu'il est tout à fait possible d'utiliser DPkg::Pre-Invoke et DPkg::Post-Invoke dans /etc/apt/apt.conf.
Je ne connaissais pas. Merci pour cette précision.
Donc, Red Hat, on peut la prendre même si on n'est pas OK avec le système de gestion de paquet ?
J'attends les arguments contre le format de paquet RPM :).
Sinon, pourquoi justifier de passer à systemd 44 sous Debian 7 alors qu'il est pris en charge que par Debian alors que c'est un problème pour Ubuntu et le noyau ?
C'est pour cela que je suggère de prévoir tout de suite la migration vers Debian 8 qui supportera une version plus à jour de systemd. La taille et la complexité du projet systemd n'est pas non plus comparable à celle du noyau ou encore à celle des éléments de la pile graphique.
Pur procès d'intention. Pourquoi est-ce que tu doutes ? Tu as des raisons objectives ou bien est-ce juste du FUD ? En quoi est-ce différent de la situation de Debian Wheezy ? C'est bien Ben Hutchings qui maintient le noyau 3.2 dans ce cas, alors pourquoi reprocher par avance à Ubuntu de maintenir le 3.13 ?
Parce que la décision n'as pas été prise arbitrairement sans concertation avec les autres projets. Le noyau 3.2 est supporté à la fois par Debian et Ubuntu ce qui réduit certainement la charge de travail. Si Debian base la version 8 sur le noyau 3.13, alors mon argument n'aura plus de poids. Ce n'est pas encore le cas.
Là encore il n'y a aucun argument factuel qui expliquerait que ce choix est mauvais.
Voici une liste de bugs qui pointe vers des problèmes techniques dans Upstart (https://lwn.net/Articles/582585/). Ces bugs ont été acceptés par le mainteneur d'Upstart (à l'époque) comme valides. Cela aurait peut-être dû les pousser à envisager une alternative plus tôt.
Il est évident qu'Ubuntu ne pouvait pas faire la transition vers systemd en quelques semaines, après la décision Mark Shuttleworth de suivre Debian et de basculer vers systemd.
Plusieurs choix s'offraient à eux, et ce n'est pas comme si cette décision n'était pas pressentie depuis un moment au vu du mouvement général des distributions vers systemd. Ils auraient pu aussi prévoir le coup et avoir gardé un paquet systemd à peu près fonctionnel sans le mettre par défaut (une grosse partie du boulot a été déjà fait par les autres distributions).
La seule critique que tu exprimes c'est que ce "sera donc supporté uniquement par les développeurs d'Ubuntu". Encore une fois ou est le problème ?
Les projets annoncés comme « morts » n'ont jamais attirés une foule de contributeurs volontaires. Les bugs mentionnés ci dessus datent pour certains de plusieurs années. Permets moi de douter fortement qu'ils soient corrigés dans Ubuntu 14.04.
Et puis de toute façon MariaDB est dans Universe.
Je n'avais pas connaissance de ce fait. Merci pour la précision, cette réserve n'a donc plus lieu d'être.
C'est faux puisque (..) on peut parfaitement changer la liste des serveurs. Cela se paramètre dans /etc/default/pollinate donc il n'est nullement nécessaire de faire confiance aux serveurs de Canonical.
C'est un argument auquel je réponds dans la suite : les options de configurations par défaut ne sont pas souvent changées et il est très peu probable qu'elles ne le soient jamais sur les clouds qui ne changent déjà pas les seeds des machines virtuelles.
Là encore il faut lire ce qu'écris Dustin Kirkland dans sa présentation : We are mitigating that (risk) by bundling the public certificates in the client. The pollinate package ships the public certificate of entropy.ubuntu.com.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Pourquoi pas un serveur local qui distribuerait la graine aux machines virtuelles ?
Si il est possible de mettre un serveur local pour le faire alors les autres solutions bien moins intrusives et tout aussi efficaces sont aussi réalisables.
Cela ne peux pas faire de mal (c'est comme RDRAND, on ne l'utilise pas exclusivement, on l'ajoute à tout le reste).
Le problème ici est qu'un attaquant aura connaissance d'une partie importante des données qui seront ajoutée dans la « pool » d'entropie, et peut potentiellement bruteforcer le reste des données dont il n'as pas connaissance.
Contacter inconditionnellement un serveur au démarrage d'une machine n'est pas non plus une action neutre en terme de sécurité. Que se passe-t-il si ce certificat est volé ou si une faille de sécurité est trouvée dans curl ?
Mais en quoi est-ce un problème ?
La quasi totalité des développeurs de la pile graphique sous Linux ne travaillent pas sous Ubuntu. Les projets annoncés comme morts n'attirent pas les contributeurs. De plus il leur faudra supporter à la fois Compiz et Mir pour les années à venir. Comme tous les projets, les ressources ne sont pas illimités et ils vont devoir faire de plus en plus de travail sans aide extérieure, ce qui impactera nécessairement le nombre de bugs qui seront corrigés.
Les autres distros aussi utilisent des trucs spécifiques quils sont les seuls à supporter.
Je veux bien des exemples. GNOME 3 n'en est pas un.
Sur LWN cette semaine on parlait de firewalld pour Fedora. Est-ce que tu vas beugler en disant que firewalld n'est supporté que par les devs de Fedora et qu'en conséquence on ne peut pas utiliser cette distribution ?
Non, parce qu'il est tout à fait possible de se passer de firewalld qui est chargé de la gestion des règles iptables. Trois commandes simples suffisent pour s'en débarrasser et rester dans une configuration complètement supportée :
systemctl stop frewalld
systemctl disable firewalld
systemctl mask firewalld
Il n'est pas du tout aussi facile de se débarrasser des modifications faites dans la pile graphique sous Ubuntu (il faut au minimum changer le noyau et mesa). Je veux bien un lien vers cette discussion sur firewalld.
Donc cela ne peut pas servir d'argument pour ne pas utiliser Ubuntu. Donc le citer est du pur FUD.
Je mentionne juste après la raison pour laquelle cet ajout affecte aussi ceux qui n'utilisent pas Mir sur Ubuntu.
Et puis conseiller Fedora 20 comme serveur…heu comment te dire…
Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?
# Plus mainteneur de la section sécurité
Posté par Siosm (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.7. Évalué à 2.
Je ne suis plus le mainteneur de la section Sécurité depuis le noyau 4.3. Est-ce qu'un modérateur peut retirer mon nom de la dépêche ? Merci de ne pas me rajouter dans les suivantes.
[^] # Re: Ceph & discard
Posté par Siosm (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.18. Évalué à 4.
Merci pour la correction ! Il nous faut un nouveau mainteneur pour la partie système de fichier pour éviter justement les traductions un peu rapides de ma part :). Intéressé ?
# Petites précisions utiles
Posté par Siosm (site web personnel) . En réponse à la dépêche Sortie de Fedora 21. Évalué à 6. Dernière modification le 14 décembre 2014 à 17:27.
Voilà un ensemble de notes trouvées sur le planet de Fedora sur divers sujets tels que :
https://www.happyassassin.net/2014/12/10/fedora-21-greatest-hits-non-server-non-live-installs-fedup-product-behaviour/
http://fedoramagazine.org/5tftw-five-fedora-21-faqs/
# Pour éviter le live-cd
Posté par Siosm (site web personnel) . En réponse à la dépêche Aujourd’hui c’est déjà demain : systemd dans l’initrd sous Arch Linux. Évalué à 5.
Pour éviter d'avoir à sortir le live-cd pendant les tests ou suite à une mise à jour fâcheuse d'une version du noyau, je conseille :
linux-lts) ;Tout ceci est très facile à faire puisqu'il suffit de copier
/etc/mkinitcpio.confvers/etc/mkinitcpio-systemd.confpar exemple, de faire les modifications désirées, puis de modifier les fichiers/etc/mkinitcpio.d/linux*.presetpour ajouter un nouveauPRESETutilisant la config systemd ;Un petit
mkinitcpio -p linux && mkinitcpio -p linux-ltset hop, il ne reste plus qu'à créer les entrées dans GRUB/gummiboot pour avoir le choix au boot en cas d'imprévu.Seul inconvénient : il faut avoir de la place dans sa partition
/boot.[^] # Re: Firefox Sync
Posté par Siosm (site web personnel) . En réponse à la dépêche Firefox 32. Évalué à 1.
Mon Firefox 32 ne voulait plus se connecter à mon FFSync 1.1 auto-hébergé. Je pense qu'il faut garder une "ancienne"/lts version de Firefox pour continuer à utiliser l'ancien FFSync.
[^] # Re: Firefox Sync
Posté par Siosm (site web personnel) . En réponse à la dépêche Firefox 32. Évalué à 5.
Je suis en train de faire les paquets pour Arch Linux de la nouvelle version de Firefox Sync et de Firefox Accounts. Et bien c'est très pénible. RIEN n'as été prévu pour que ce soit installé proprement (il n'y a même pas de target install dans le Makefile).
Pour l'instant je n'arrive pas encore à faire fonctionner FFSync avec le FFAccounts de Mozilla (https://mail.mozilla.org/pipermail/sync-dev/2014-August/000955.html). Je n'ose pas imaginer ce que me réserve l'étape d'après (passer à un FFA self-hosted).
[^] # Re: xfs ?
Posté par Siosm (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 1.
J'ai clairement mentionné que c'était l'opinion du mainteneur de XFS et donc que c'était probablement biaisé. J'aurais dû dire « stable » plutôt que « abouti ».
Comme toujours, c'est uniquement le système de fichiers choisi par défaut, il est tout à fait possible d'utiliser Ext4 ou Btrfs à l'installation.
[^] # Re: xfs ?
Posté par Siosm (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 0.
Pour Dave Chinner, le mainteneur actuel de XFS, c'est le système de fichier le plus abouti à l'heure actuelle :
Si je ne me trompe pas, il supporte mieux les systèmes de fichiers de très grande taille que Ext4.
[^] # Re: Ce que l'on n'a pas eu le temps de mettre dans la dépêche
Posté par Siosm (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 3.
Ceux qui veulent aussi des logiciels plus à jour peuvent se tourner vers les Software Collections, qui sont supportées sur RHEL 7 :
# Ce que l'on n'a pas eu le temps de mettre dans la dépêche
Posté par Siosm (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 3.
Il manque quelques points que je n'ai pas eu le temps de traduire pour la dépêche. Ils sont détaillés (avec ceux que l'on a traduit) dans ce document qui référence une grande partie des nouveautés.
[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 1.
Je pense qu'il y a une erreur dans le lien présent dans le commentaire parent. Il faudrait demander à un modérateur de le retirer.
[^] # Re: Fallait attendre vendredi
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -4. Dernière modification le 03 mai 2014 à 21:43.
Encore une fois, ce n'est pas du tout de cela dont je parle.
Rappels sur l'établissement d'une session TLS :
L'élément qui pose problème ici est que l'échange d'information (Key Exchange) pour établir la clé de chiffrement se fait avec très peu d'entropie du côté client vu que le client pollen est exécuté très tôt au démarrage du système, avant que les autres services ne se lancent.
Si l'on prend l'exemple de l'algorithme d'échange de clé Diffie-Hellman, et en considérant que le secret généré aléatoirement par le client n'est pas si aléatoire que cela, alors il est très facile pour un attaquant de déterminer le secret partagé obtenu à la fin de l'échange à partir des informations envoyées par le serveur. Il n'a qu'à essayer tous les nombres aléatoires potentiellement générés par le client qui ne dispose pas d'une bonne entropie.
Cela s'applique aussi aux autres algorithmes d'échange de clé parce qu'ils reposent tous sur le principe que le client (au minimum) a généré un nombre aléatoire que lui seul connaît. Ce n'est pas une faiblesse du protocole, seulement un prérequis.
Donc la clé de chiffrement de la connexion TLS peut être obtenu par une personne positionnée en man in the middle entre le client et le serveur, ce qui lui permet ensuite de déchiffrer le contenu de la connexion et donc d'obtenir les données aléatoires renvoyées par le serveur, et donc d'obtenir une très grande partie des informations qui seront par la suite utilisées pour amorcer le PRNG.
Tout ceci n'est même pas de moi. C'est ce qui est expliqué dans ce post et les commentaires qui suivent, que j'ai déjà mentionné dans l'article.
Je suis presque déçu que cela ai été perçu comme un troll. Je ne me permets pas non plus de traiter les autres de clown. Par contre beaucoup de gens se sont permis de se débarrasser de mes arguments (qu'ils soient bons ou mauvais) en les traitant de FUD, ou en me traitant d'incompétent, ce qui simplifie bien les choses.
[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -4.
A en croire cette partie, l'intégration (pour la partie mobile si j'ai bien compris) consiste à effectuer les actions suivantes avant de lancer une application :
On a vu plus poussé (et plus difficile à reproduire avec systemd) comme intégration.
Rien ne pointe vers une difficulté particulière pour le passage à systemd et oui, je pense qu'il n'y a presque rien de plus à faire qu'un copier / coller des units systemd depuis une autre distribution et de tester cela. En plus, c'est typiquement dans ce genre de cas que le système de gestion de paquet de Debian est sensé être le plus efficace : changements massifs impactant un grand nombre de paquets de la même façon (ici le remplacement des jobs upstart par les units system).
Merci d'énoncer l'évident, tout logiciel a des bugs. Cf commentaire au dessus qui explique le problème avec ces bugs.
Encore une fois, Upstart a bien été utilisé dans RHEL / Fedora mais les services n'ont presque pas été migrés pour utiliser les fonctionnalités d'Upstart. Tout est resté sous forme de script SysVinit.
Je n'ai pas non plus dit que Upstart était broken by design et non maintenable, j'ai dit que le design de systemd était considéré comme meilleur et que plus personne ne serait intéressé par la maintenance d'Upstart.
Si le travail d'intégration est fait avec les développeurs d'Ubuntu pourquoi est-ce que systemd n'est pas disponible dans les dépôts de cette LTS ? La remarque "Il n'est pas supporté" n'est pas valide, il y a plein de logiciels non supportés dans les dépôts d'Ubuntu et même Red Hat propose parfois des "Technical Preview" qui ne sont pas supportés mais qui mettent à disposition des logiciels récents ou des fonctionnalités particulières.
[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 0.
En informatique particulièrement, le fait que « cela marche » n'est pas significatif de la validité de l'approche employée, et ne signifie pas que l'on ne vas pas rencontrer de soucis lorsque que l'on va s'en servir de façon un peu plus intensive par exemple. Sinon on pourrait
chmod 777tous les fichiers et cela marcherait pour tous les utilisateurs lambda (Windows avec le compte administrateur par défaut ?) mais cela ne rendrait pas l'approche plus valide.[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 0.
Je l'attendais celle là. Je ne me suis pas contenté de prendre tous les bugs ouverts dans Upstart pour les balancer comme argument. Ici, les bugs (qui ont été regroupés par une autre personne que moi) concernent tous des fonctionnalités d'Upstart plus ou moins utilisées dans Ubuntu (pour le démon CUPS par exemple) mais qui sont acceptées comme étant cassées. Tous les fixs relatifs à ces bugs ont été sous forme de contournement dans les programmes impactés et rien n'as été fixé à la source dans Upstart. Je trouve cette situation plutôt étrange.
Si demain je veux écrire un job Upstart pour un démon sous Ubuntu, il va falloir que je prenne la doc, et que je retire toutes les fonctionnalités considérés comme cassées dans les bugs reports. Si ces bugs n'ont pas été fixés pour la LTS, il ne le seront pas plus tard.
[^] # Re: Pitoyable
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -3.
Payer quelqu'un ne vas pas en faire automatiquement un bon mainteneur noyau ou un bon décideur de quels patchs doivent intégrer une branche stable.
Ben Hutchings (http://www.linux.com/news/special-feature/linux-developers/632197-30-linux-kernel-developers-in-30-weeks-ben-hutchings) a déjà contribué au noyau. Je n'ai pas d'opinion sur sa compétence de mainteneur du noyau 3.2.
Ce qui est beaucoup plus facile vu que le noyau utilisé dans la 10.04 par exemple est le 2.6.32, peut-être le noyau le plus supporté de toute l'histoire de Linux et que RHEL 6 est basé sur à peu près les même logiciels, donc que ceux-ci aussi sont supportés.
[^] # Re: Fallait attendre vendredi
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -3.
Les versions de Fedora intègrent quasiment les mêmes versions de logiciels que ce qu'il y a dans Ubuntu (Ils sont généralement un poil plus à jour). Par contre, quand il y a des bugs, il ne font pas semblant de ne pas les voir pour ne pas retarder la sortie d'une version (http://www.h-online.com/open/news/item/Ubuntu-10-04-LTS-delayed-by-last-minute-GRUB-bug-990277.html) et ils prennent le temps de les fixer et de tester les changements. C'est notamment pour cette raison que Fedora 20 est sortie si tard. Alors l'argument Fedora intègre plein de trucs donc il y a des bugs est complètement à côté de la plaque vu qu'ils prennent justement le temps de fixer les bugs quand c'est nécessaire. Bonus, ils essaient de fixer les bugs upstream en premier pour que tout le monde en bénéficie.
Fedora 20 (la version que je recommande) est encore un cas particulier, et son support est particulièrement long vu les retards de la version 21. De plus, je ne recommande Fedora 20 que comme palliatif en attendant RHEL/CentOS 7 qui sera de configuration très similaire, et de support bien plus long.
Par défaut avec Ubuntu tu installes la version desktop sur un serveur ? Non, tu prends la version serveur pour les serveurs. Fedora c'est pareil, il y a une version serveur qui n'installe pas d'interface graphique par défaut.
Je n'ai jamais dit que le gestionnaire de paquet sous Debian/Ubuntu était mauvais. Je ne l'aime pas personnellement ; j'ai donc ajouté la remarque "si vous êtes OK avec le système de gestion de paquets" parce que c'est un facteur à considérer. Je ne rentrerai pas dans le débat RPM/Deb et je n'aurais peut-être pas dû mettre cette mince remarque en premier lieu.
[^] # Re: Fallait attendre vendredi
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -5.
Je ne conseille pas d'utiliser n'importe quelle version de Fedora, je conseille la version 20, qui est peut être la version de Fedora la plus testée à ce jour et dont le cycle de vie sera le plus long vu les retards de la version 21.
Encore une fois, je ne conseille pas d'utiliser Fedora sur un serveur sur la durée, je conseille de l'utiliser en attendant de pouvoir migrer sur CentOS 7 qui ne devrait pas tarder à sortir.
[^] # Re: Mr Pernickety
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 1.
Merci, c'est corrigé.
[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -2.
Si tu as un lien avec des informations à ce sujet je suis intéressé.
Cette collection de bugs encore ouverts et acceptés laisse penser qu'Upstart n'est pas aussi stable qu'annoncé : https://lwn.net/Articles/582585/.
Je pointe les cas où Ubuntu est effectivement la seule distributions à supporter certains logiciels. Ce n'est en effet pas le cas pour systemd.
[^] # Re: Pitoyable
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 0.
Le serveur hébergeant le blog est sous Arch Linux. J'ai géré pendant un temps un serveur sous Debian et j'en gère en ce moment sous Fedora.
Je ne conseille pas d'utiliser Arch Linux sur un serveur. Je conseille uniquement Fedora 20 comme alternative en attendant la sortie de CentOS 7. Dès que CentOS 7 sera sorite, il n'y aura plus aucune raison de mettre Fedora sur un serveur.
Red Hat est particulièrement connu pour avoir à disposition une partie non négligeable des développeurs contribuant au noyau Linux. De plus, le support du noyau 2.6.18 (RHEL 5) est dans la phase 3, ce qui signifie qu'ils ne font plus que les mises à jour de sécurité, ce qui réduit considérablement le travail. De plus, ils sont payés par les entreprises achetant du support pour le faire.
Si la gestion des services sur un serveur était aussi simple que cela je pense que systemd n'existerai pas.
A ma connaissance, les seules distributions activant les services par défaut sont dérivées de Debian.
C'est le « Souvent » qui importe ici.
En effet, c'est une erreur de ma part.
http://en.wikipedia.org/wiki/MariaDB#Prominent_users
C'est peut-être pour cela que j'ai mis ça à la fin en précisant bien que cela concernait les machines de bureau ?
[^] # Re: Raison 3
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 0.
Cela résout en effet une partie du problème. Je vais mettre à jour avec cette remarque.
Je ne connaissais pas. Merci pour cette précision.
[^] # Re: systemd-login
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 0.
Tout à fait, si l'on n'utilise pas systemd. Ce que je ne recommande pas dans l'article.
[^] # Re: Mouarf
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -3.
J'attends les arguments contre le format de paquet RPM :).
C'est pour cela que je suggère de prévoir tout de suite la migration vers Debian 8 qui supportera une version plus à jour de systemd. La taille et la complexité du projet systemd n'est pas non plus comparable à celle du noyau ou encore à celle des éléments de la pile graphique.
[^] # Re: Fallait attendre vendredi
Posté par Siosm (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -5.
Parce que la décision n'as pas été prise arbitrairement sans concertation avec les autres projets. Le noyau 3.2 est supporté à la fois par Debian et Ubuntu ce qui réduit certainement la charge de travail. Si Debian base la version 8 sur le noyau 3.13, alors mon argument n'aura plus de poids. Ce n'est pas encore le cas.
Voici une liste de bugs qui pointe vers des problèmes techniques dans Upstart (https://lwn.net/Articles/582585/). Ces bugs ont été acceptés par le mainteneur d'Upstart (à l'époque) comme valides. Cela aurait peut-être dû les pousser à envisager une alternative plus tôt.
Plusieurs choix s'offraient à eux, et ce n'est pas comme si cette décision n'était pas pressentie depuis un moment au vu du mouvement général des distributions vers systemd. Ils auraient pu aussi prévoir le coup et avoir gardé un paquet systemd à peu près fonctionnel sans le mettre par défaut (une grosse partie du boulot a été déjà fait par les autres distributions).
Les projets annoncés comme « morts » n'ont jamais attirés une foule de contributeurs volontaires. Les bugs mentionnés ci dessus datent pour certains de plusieurs années. Permets moi de douter fortement qu'ils soient corrigés dans Ubuntu 14.04.
Je n'avais pas connaissance de ce fait. Merci pour la précision, cette réserve n'a donc plus lieu d'être.
C'est un argument auquel je réponds dans la suite : les options de configurations par défaut ne sont pas souvent changées et il est très peu probable qu'elles ne le soient jamais sur les clouds qui ne changent déjà pas les seeds des machines virtuelles.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Si il est possible de mettre un serveur local pour le faire alors les autres solutions bien moins intrusives et tout aussi efficaces sont aussi réalisables.
Le problème ici est qu'un attaquant aura connaissance d'une partie importante des données qui seront ajoutée dans la « pool » d'entropie, et peut potentiellement bruteforcer le reste des données dont il n'as pas connaissance.
Contacter inconditionnellement un serveur au démarrage d'une machine n'est pas non plus une action neutre en terme de sécurité. Que se passe-t-il si ce certificat est volé ou si une faille de sécurité est trouvée dans curl ?
La quasi totalité des développeurs de la pile graphique sous Linux ne travaillent pas sous Ubuntu. Les projets annoncés comme morts n'attirent pas les contributeurs. De plus il leur faudra supporter à la fois Compiz et Mir pour les années à venir. Comme tous les projets, les ressources ne sont pas illimités et ils vont devoir faire de plus en plus de travail sans aide extérieure, ce qui impactera nécessairement le nombre de bugs qui seront corrigés.
Je veux bien des exemples. GNOME 3 n'en est pas un.
Non, parce qu'il est tout à fait possible de se passer de firewalld qui est chargé de la gestion des règles iptables. Trois commandes simples suffisent pour s'en débarrasser et rester dans une configuration complètement supportée :
systemctl stop frewalld
systemctl disable firewalld
systemctl mask firewalld
Il n'est pas du tout aussi facile de se débarrasser des modifications faites dans la pile graphique sous Ubuntu (il faut au minimum changer le noyau et mesa). Je veux bien un lien vers cette discussion sur firewalld.
Je mentionne juste après la raison pour laquelle cet ajout affecte aussi ceux qui n'utilisent pas Mir sur Ubuntu.
Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?