Mois de novembre oblige, une nouvelle version d'OpenBSD est publiée. Nous sommes désormais en version 5.6.
OpenBSD est un système d'exploitation orienté sécurité et réseau, dont les principaux avantages sont la stabilité, grâce aux audits sur le code source, mais également l'ensemble très large de fonctionnalités réseau qu'il fournit. L'équipe d'OpenBSD s'est notamment illustrée cette année par son fork d'OpenSSL, LibreSSL
Mises à jour
Logiciels
- Xserver 1.15.2
- Gnome 3.12.2
- KDE 4.13.3
- PostgreSQL 9.3.4
- Firefox & Thunderbird 31
- PHP 5.4.30 et 5.5.14
- et bien d'autres…
Ajouts
Plusieurs logiciels ont été ajoutés, remplaçant certains anciens logiciels :
- unbound a été ajouté.
- httpd(8) est un nouveau serveur HTTP(S) basé sur relayd(8).
- sendmail(8) est remplacé par smtpd(8), le serveur OpenSMTPD.
- libreSSL remplace openSSL.
Suppressions
Plusieurs logiciels ont été supprimés de la distribution OpenBSD :
- Spray.
- Il n'est plus possible d'utiliser ppp dans l'espace utilisateur, et le daemon ppd a été supprimé.
- Apache est supprimé, et on lui préfèrera nginx(8) (qui sera supprimé pour la version 5.7).
- rsh(1) a été supprimé.
- rdist(1) a été supprimé.
Améliorations
- Les services prennent désormais en compte la variable
daemon_timeoutdéfinissant une limite de temps d'allumage. - Une réécriture du programme apropos(1) a eu lieu ; on peut maintenant faire des recherches plus poussées à l'aide d'une base de données makewhatis(8).
Réseau
- npppd, le démon PPTP/L2TP d'OpenBSD peut désormais écouter plusieurs interfaces réseau.
- IPv6 est désormais désactivé par défaut sur les interfaces. Il s'active lors de l'ajout d'une adresse IPv6 sur celles-ci.
- Le système de qualité de service ALTQ a été supprimé.
Sécurité
- Relayd dispose d'une fonctionnalité de séparation des privilèges lors de l'utilisation de clefs privées.
- Gestion des enregistrements DNS SSHFP pour les types de clef ED25519.
- Suppression de Kerberos.
- LibreSSL remplaçant OpenSSL, SSLv2 n'est plus supporté.
- L'authentification MSChapv1 a été supprimée de pppd.
Packet Filter
- Lors d'une translation de paquet d'une famille d'adressage à une autre, les paquets générés gardent le champ TOS/Traffic Class du paquet original.
- pfctl interdit désormais les règles de translation d'adresse contenant à la fois des IPv4 et IPv6.
Pilotes
- La prise en charge des cartes SCSI QLogic ISP HBAs a été ajoutée au travers du pilote qlw.
- Prise en charge des cartes Realtek 8168G.
- Meilleure gestion des disques 4k (growfs fsck_ffs tunefs…).
- La prise en charge du bluetooth a été supprimée. Cela ne fonctionnait pas correctement.
- Prise en charge du multi-chemin SCSI.
- Des améliorations ont été apportées à la mise en veille et au retour de veille pour les cartes graphiques Intel et AMD.
Performances
- Les appels à getuid, getgid, getresuid, setreuid and setuid ne nécessitent plus de verrou noyau.
- Amélioration des performances d'hibernation.
Installeur
- Il n'est plus possible d'installer OpenBSD via un FTP ou des cartouches.
Aller plus loin
- OpenBSD Release Notes (349 clics)
- OpenBSD 5.5 to 5.6 changes (167 clics)
# Plus de sslv3 non plus
Posté par gaston . Évalué à 7.
A noter que depuis POODLE, sslv3 est aussi considéré non sécurisé, donc un errata (http://www.openbsd.org/errata56.html) le désactive.
# libreSSL
Posté par nanard . Évalué à 2.
Ca veux dire que maintenant libressl est utilisable, et personne ne nous dis rien, ou c'est juste la version d'obenbsd qui est valide pour l'instant ?
Allez tous vous faire spéculer.
[^] # Re: libreSSL
Posté par gaston . Évalué à 5.
Il y'a deja eu un certain nombre de releases indépendantes de libressl(-portable), et je crois qu'au moins une obscure distrib linux l'a pris pour remplacer openssl. Donc oui,on peut considerer que c'est utilisable, au même titre qu'openssl..
# suppressions ?!
Posté par c^3 . Évalué à 5.
J'ai l'impression qu'il y a beaucoup de suppressions dans cette liste. Pour un OS qui se veut «stable», c'est gênant de forcer l'utilisateur à migrer d'apache vers nginx, non ? Idem si on veut du kerberos, etc.
Peut-être qu'ils sont juste supprimés de la liste par défaut / de l'installeur ?
The cake is a lie.
[^] # Re: suppressions ?!
Posté par Cédric Krier (site web personnel) . Évalué à 6.
Soit la suppression est due au fait qu'un meilleur solution existe (généralement en terme de sécurité) comme pour rsh vs ssh.
Soit c'est des logiciels qui n'étaient pas développés par OpenBSD et donc ils sont sorties du système de base en faveur d'un « package ».
[^] # Re: suppressions ?!
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6.
Je trouve quand même bien étrange par rapport à Kerberos, par exemple, que l'on ait que ceci dans le changelog :
Est-ce que ça signifie que Kerberos a une faille ? Je vois mal comment ça pourrait améliorer la sécurité de le supprimer sinon…
[^] # Re: suppressions ?!
Posté par Cédric Krier (site web personnel) . Évalué à 6.
Voici l'explication pour Kerberos : http://undeadly.org/cgi?action=article&sid=20140425065910
[^] # Re: suppressions ?!
Posté par flan (site web personnel) . Évalué à 4.
Kerberos est-il donc si peu utilisé que ça ? Je suis assez surpris, c'est tout de même très simple d'emploi tout en étant super pratique.
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 2.
Concernant ngix et sa future suppression, il y a une explication du développeur de httpd ici. En gros, l'équipe ne reproche rien de particulier à ngix mais trouve que le code est trop optimisé et loin de leurs pratiques pour qu'ils le maîtrisent. D'où httpd qui est beaucoup mieux intégré au reste du code.
[^] # Re: suppressions ?!
Posté par lasher . Évalué à 3.
Hum, un code « trop optimisé » ça fait bizarre. Le style je peux comprendre. Mais du moment que le code est sûr, je ne vois pas en quoi être optimisé est un mal… (je vais lire le lien histoire de voir si je suis d'accord avec ton résumé ;-)).
[^] # Re: suppressions ?!
Posté par X345 . Évalué à 2.
Et comment tu sais si le code est sûr ?
Typiquement c'est bien plus facile de vérifier un code écrit de manière "standard" qu'un obscur code optimisé au petits oignons. Et pour avoir jeté un œil à certaines parties d'nginx, on peut dire que c'est bien golfé par endroits…
[^] # Re: suppressions ?!
Posté par Le Gab . Évalué à 3.
Ce qui veut dire? (Question sincère)
merci.
[^] # Re: suppressions ?!
Posté par Anonyme . Évalué à 2.
Sans doute une réference au Perl Golf:
http://c2.com/cgi/wiki?PerlGolf
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 6.
Deux exemples : ngix utilise un gestionnaire d'allocation mémoire spécifique et n'utilise pas directement (ou pas du tout) la libc pour certaines fonctionnalités. Ça veut dire que l'équipe d'OpenBSD devrait auditer un allocateur mémoire et des fonctions de type libc dont les versions standards dont déjà auditées. Ça ajoute un surcoût et OpenBSD optimise en général pour la sécurité/simplicité plutôt que pour les performances/fonctionnalités (quand la question d'un compromis se pose, je ne dis pas qu'OpenBSD est lent et qu'il manque de fonctionnalités).
[^] # Re: suppressions ?!
Posté par lasher . Évalué à 3.
Oui, j'ai lu le post original après ma réponse. Et tout revient autour de la même chose : ils ne comprennent pas suffisamment le code pour garantir la sûreté du programme et sa maintenance. C'est complètement OK selon moi. Mais un code ne peut pas être « trop » optimisé, dans le sens où une optimisation qui provoque des résultats incorrects n'en est pas une, par définition.
[^] # Re: suppressions ?!
Posté par anaseto (site web personnel) . Évalué à 8.
En un certain sens, oui : certaines mesures de mitigation d'exploit utilisées sur OpenBSD impactent (un peu) les performances. Les annuler pour des raisons de performance peut, suivant les cas, être considéré comme une optimisation de trop.
Et au-delà, le fait qu'optimiser en général complique le code et le rend moins auditable, fait que performance et sécurité ne vont pas forcément bien ensemble, donc du point de vue sécurité, on peut avoir du code trop optimisé (à moins que l'optimisation soit prouvée formellement, bien sûr, mais il y a peu de chances).
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 9.
Certes, mais ce n'est pas ce qu'ils disent, comme tu le résumes bien, d'ailleurs. Ils parlent bien sûr de code compréhensible.
As-tu déjà lu un code de calcul matriciel optimisé ? Le produit de deux matrices, c'est vraiment le code plon plon par excellence : une bête triple boucle, rien de plus simple. Sauf que pour que ça fonctionne efficacement, il faut respecter les caches, ce qui demande de faire du « blocking ». En gros, tu calcules le produit des matrices par sous-blocs, ce qui rend le programme nettement moins clair. Ensuite, on ajoute du respect de l'alignement, celui de la TLB (voire de NUMA), les threads, les instructions SSE et autres, et ça devient incompréhensible. L'excellent article de Drepper à ce sujet est plein d'exemples édifiants : le code standard en page 49 et celui un peu optimisé en page 50, puis la version hardcore en page 97. Les écarts de performances entre la version simple et la version optimisée sont incroyables.
Je ne sais pas si ngix utilise du code optimisé à ce niveau de sophistication, mais si c'est le cas, je comprends la frousse des gars d'OpenBSD et l'idée que c'est trop optimisé. Les algos qui respectent les caches sont souvent impanables, ce qui pourrait bien être une source de complexité parmi d'autres dans ngix.
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . Évalué à 3.
En général, on optimise pour atteindre un objectif. Si c’est juste pour le sport (passer 1 mois à gagner 3 requêtes par seconde), le code devient crade.
Avant d’optimiser, il faut avoir un objectif. Pour nginx ça pourrait-être livrer 1000000 de pages statique d’une certaine taille par seconde.
Ensuite, il faut vérifier que le code simple initial ne répond pas déjà à l’objectif.
Si ce n’est pas le cas, il faut trouver quels sont les points de ralentissement du logiciel.
Optimiser intelligemment certains points uniquement jusqu’à atteindre l’objectif. Et surtout documenter et prouver chaque optimisation.
En faisant tout ça dans les règles, optimiser coûte cher. C’est simple de gagner au début en organisant correctement les données en fonction de l’usage : ne pas utiliser des listes chaînés si on accède principalement par index…, mais gratter les dernière μs pour passer en dessous de 1 ms sur des processeurs pas tout jeune, en étant capable de prouver qu’il n’y a de régression, ce n’est pas évident.
[^] # Re: suppressions ?!
Posté par barmic . Évalué à 3.
Je ne pense pas qu'il ai plus de quelques projets dans le monde qui se permettent ce genre de choses.
Les règles que tu donne n'ont aucun sens sans les prérequis suivant :
Je ne vois vraiment pas comment des projets pourraient investir autant dans la performance alors qu'il y a si peu de projet qui investissent la moité dans la correction de leur logiciel.
D'ailleurs la valeur ajouté est tout de même limité. Il faut cibler une plateforme cible (sinon la complexité explose) et être sûr de gagner au moins un minimum de performance (investir des sommes folles pour gagner un temps non mesurables n'a pas de sens) et s'assurer que le gain ne pourrait pas être obtenu avec un coût moindre en investissant dans la plateforme cible.
Bref AMHA tout ça est plus théorique qu'autre chose. Je ne vois pas vraiment de cas qui réunirait toutes ces hypothèses (peut être quelques projets critiques dans l'aéronavale ou l'aérospatial).
Doux euphémisme, je pense que démontrer qu'un programme s'arrête n'est pas évident non plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . Évalué à 3.
Oui, je suis d’accord avec toi. C’est la conclusion à laquelle je voulais venir, c’est que d’un côté les projets libres n’ont pas les moyens d’optimiser dans les règles. Et que openBSD n’a pas les moyens d’auditer les optimisations de logiciel tiers. Donc ils ont fait le choix de faire les choses simplement. Avec des exigences perfo simple et pas trop contraignantes. La sécurité est, de leur point de vu, à ce prix.
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 7.
Je ne parle pas de ça, je parle de facteurs 10 à 30. Dans un code intensif en mémoire, c'est-à-dire dès que les données ne tiennent pas dans les caches, le schéma d'accès à la mémoire a une influence cruciale sur les performances. Alors que la puissance normale d'un cœur intel est de l'ordre de 6 Gflop/s (une addition et une multiplication par cycle d'horloge), un code naïf sur l'accès mémoire récupère au mieux du 600 Mflop/s, voire seulement 200 Mflop/s. C'est pourquoi il est indispensable pour du code numérique d'utiliser une implémentation compliquée. Dans un langage de très haut niveau comme le C++, tout est caché dans des expressions templates, ce qui permet de faire du calcul matriciel lisible à très hautes performances. Dans des langages de très bas niveau comme le C, il faut faire les optimisations à la main, ce qui rend les bibliothèques très difficiles à lire.
Dans le contexte du web, on peut aussi gagner des facteurs de l'ordre de 10. Par exemple Varnish utilise des techniques sophistiqués pour faire ça, cf l'article de ACM queue à ce sujet.
Le fond de l'histoire est que pour utiliser vraiment bien le matériel moderne, il faut modifier les algorithmes pour qu'ils respectent les caches, ce qui rend les programmes plus complexes directement au niveau algorithmique, sans parler de l'implémentation.
C'est aussi vrai pour le multithread : pour avoir des structures de données efficaces en multithread, il faut des algorithmes d'une sophistication assez effrayante. Et de nouveau, on n'est pas dans l'optimisation d'une requête de plus ou de moins, mais bien d'un facteur 10. Je conseille vivement à ce sujet le bouquin the art of multiprocessor programming écrit par des pontes du sujet.
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . Évalué à 1.
Oui et non.
Oui, je suis d’accord sur le principe, mais dans la pratique, le coût non négligeable de te baser sur des euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération, car :
n’est pas intéressant. Il vaut mieux se concentrer sur les structures de données, et faire des algo compréhensible par les compilateurs de façon à se qu’ils optimisent. Par expérience, à moins d’investir énormément, le choix de l’algo et son codage simple permet au compilateur de donner de très bon résultat.
De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.
C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.
Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances… mais pour de l’applicatif, ce n’est pas généralisable.
Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.
Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)
Sur certains projets, on peut même diminuer une contrainte temporelle si on sent qu’elle risque de coûter trop cher.
[^] # Re: suppressions ?!
Posté par jyes . Évalué à 5. Dernière modification le 06 novembre 2014 à 10:30.
Tu n’as vraiment pas l’air de bosser dans le domaine. Dans ce que décrit Boubou, un facteur 30, c’est ce que tu obtiens en réécrivant tes algos sous une forme « cache friendly » ce qui les rend déjà beaucoup moins lisible mais n’est pas encore au niveau des optimisations d’implémentation. C’est bien l’algo qui est réécrit et les données qui sont réorganisées. Une telle optimisation fonctionne plus ou moins efficacement selon la taille des lignes de cache, c’est à dire que le coefficient gagné sera facilement compris entre 5 et 100, mais il est toujours très significatif indépendamment du processeur 1, au prix d’une modification souvent profonde des algos qui peut entraîner une compréhension bien plus difficile du code. Et à ce stade, on n’a pas optimisé de façon spécifique à une architecture, et encore moins à un processeur.
Pour le reste je suis bien d’accord avec toi que la course à l’optimisation est sans intérêt pratique au delà d’un certain niveau, mais le fait est que certaines écritures qui compliquent la compréhension d’un code peuvent avoir des effets suffisamment importants pour ne pas rentrer dans la case masturbation intellectuelle.
Peut-être pas un Z80 ou un truc vraiment pas adapté au calcul de toute façon, mais tous les processeurs courants ont un rapport entre leur performance brute et leur latence d’accès à la mémoire tellement effarant que l’optimisation des caches est toujours significative. ↩
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . Évalué à 5. Dernière modification le 06 novembre 2014 à 11:41.
On ne parle pas de la même chose. D’un côté vous parlez de calcul scientifique, recherche modification d’algo pour gagner du temps. Quand l’algo est prêt, après plusieurs années de recherche, il est publié, intégré dans une bibliothèque et utilisable.
De l’autre, je parle rationalisation, coût.
Le problème à la base est de savoir si openBSD a raison de refuser les optimisations qui nuise à la lisibilité du code. Je réponds : « oui ». Car openBSD est la comme serveur, ce n’est pas un super calculateur numérique.
Quand à ta remarque :
Tu as raison, je ne suis pas mathématicien, je suis spécialisé dans le temps réel aéronautique. Ce qui nous intéresse par exemple, c’est de garantir que l’information du capteur vts, alt soit afficher au pilote en moins de x ms. On s’en fout complètement de rendre l’algo obscure pour donner l’information en x÷5, car le coût induit en test, certification etc. explosera d’un facteur × 10 ou plus.
Mon expérience, d’optimisation est là. Quand ça passe pas, il faut trouver une solution. Le plus contraint que j’ai eu à optimiser, c’est sur un calculateur relier à d’autre par 3 bus différents. Où il fallait caler les échanges bus + les calculs en dessous de 1ms. Avec un proc PowerPC en dessous de 1GHz. On a fait des analyses de ce qui passait sur les bus (vive les analyseurs PCI). Quand on a atteint les 987μs, on a fait validé le produit.
[^] # Re: suppressions ?!
Posté par jyes . Évalué à 7.
Ok, alors pour en revenir au sujet initial (puisque c’est vrai que le fil qui a abouti à ma réponse a déjà bien dérivé), je suis bien d’accord avec toi là dessus. C’est une décision qui oriente la finalité du projet mais qui est en parfait accord avec la direction qu’il a toujours tenu jusqu’ici : la sécurité.
Il est indéniable que les optimisations peuvent fortement perturber la lisibilité du code, et si Nginx peut faire sa pub en étant « le plus utilisé parmi les 1 000 sites les plus actifs en avril 2014 » (dixit Wikipedia), ce n’est sûrement pas l’objectif de httpd dans OpenBSD. Ce dernier ne souffrira d’un ordre de grandeur de différence sur ses performances lors de pics de charge, ils n’aura le même rôle. Et de son côte le projet OpenBSD se donne les moyens pour clamer sa sécurité avec
0seulement 12peu de trous depuistoujours10 ansun certain temps.[^] # Re: suppressions ?!
Posté par jyes . Évalué à 2.
J’étais à deux pas de rédiger mon commentaire de façon intelligible. Je me relirai mieux à l’avenir.
[^] # Re: suppressions ?!
Posté par X345 . Évalué à 10.
Je sais pas si je me suis progressivement transformé en vieux con, mais qu'est-ce qu'on peut lire comme c*nn*eries sur linuxfr (excusez le terme).
Je passe sur l'utilisation douteuse du mot heuristique, qui paraîtrait ici très avantageusement remplacé par hypothèse ou propriété.
Haswell, cache line size (2013) : 64o (p. 2-5)
Sandy Bridge, cache line size (2011) : 64o (p. 2-17)
Nehalem, cache line size (2008) : 64o (p. 2-43)
Core, cache line size (2006): 64o (p. 2-36)
Référence : Intel 64 and IA-32 Architectures Optimization Reference Manual (March 2014), les numéros de pages sont donnés pour chaque architecture.
Donc bon, ça fait quand même au moins 4 générations (8 ans) que les lignes de cache font 64 octets. Certes il arrive que la taille des lignes de cache change, mais c'est bien loin d'être "à chaque génération". Pour information, le Pentium 4 avait des lignes de caches de 64o (aussi) pour le L1 et des lignes de caches de 128o pour le L2.
Si on veut, je peux difficilement te contredire là dessus vu qu'Intel ne publie pas les spécifications complètes de ses prédicteurs de branchements.
Nehalem, misprediction penalty : ~17 cycles
Sandy Bridge, misprediction penalty : ~15 cycles
Haswell, misprediction penalty : 15-20 cycles
Référence : The microarchitecture of Intel, AMD and VIA CPUs, Agner Fog
http://www.agner.org/optimize/microarchitecture.pdf
De là a dire que les changements au niveau du predicteur de branchement vont mettre en l'air tes optimisations, ça me parait carrément péremptoire.
Xeon X5560 (Nehalem) : LLC 2MB/core, L2 256KiB/core
Xeon E5-2660 (Sandy Bridge) : LLC 2.5MB/core, L2 256KiB/core
Xeon E5-2660 v3 (Haswell) : LLC 2.5MB/core, L2 256KiB/core
Référence : https://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors
Là encore, pas très significatif comme différences…
C'est effectivement la base de la base d'utiliser les bonnes structures de données, mais on se tue à t'expliquer qu'entre une implémentation naïve et une implémentation optimisée, y'a parfois de gros speedups : 10 fois, 100 fois dans certains cas.
Vive la contradiction. Donc d'un côté t'as des contraintes budgétaires et de l'autre tu t'amuses à optimiser ton code pour 40 architectures différentes. Dans l'"industrie" comme tu dis, la manière raisonnable de procéder serait d'optimiser ton code pour qu'il tourne sur des Xeon Ivy Bridge (ou ce que tu as comme machines) et point. Tu vas pas t'amuser à l'optimiser pour toute la planète si t'as des contraintes budgétaires. Et si t'as deux générations de processeurs en production, bah tu optimises pour les deux générations et basta (et comme je le montrais plus haut, ça ne varie pas forcément énormément).
Wow ! de l'applicatif PC ! Il ne t'a pas échappé à l'esprit de l'applicatif PC, ben, ça ne représente pas un marché énorme. On est plus en 1995 hein. Et c'est toi qui parle de masturbation intellectuelle. On se dirige beaucoup vers un modèle de service donc le code s'exécute de plus en plus sur des serveurs. Et code plus performant = moins de serveurs = moins de coûts d'exploitation. 10 machines c'est moins cher que 100.
Dans l'applicatif PC, je pense que les jeux vidéos et les logiciels d'ingénierie doivent représenter une bonne partie du marché (MATLABS, Comsol etc.). Justement du code qui demande d'être optimisé !
Mais personne ne passe 30 jours pour une nano-seconde. Personne. On se tue à t'expliquer que si on passe 30 jours, c'est pour avoir un speedup de 10. Et puis parfois, c'est rentable, Facebook paye des ingés à optimiser son code et dès qu'ils gagnent 0.5%, ça part en prod. Parce 0.5% de performance en plus, c'est x € économisés en serveurs (https://www.youtube.com/watch?v=Qq_WaiwzOtI)
Sinon, tu peux aussi embaucher des ingés compétents qui ont pas besoin de 30 jours pour écrire du SIMD et faire du cache blocking…
Bon, et merci pour bashing gratuit des universitaires qui passeraient leur temps à faire des choses pas très utiles et à faire du sport et de la masturbation intellectuelle. Tu sais si tu veux que ton papier passe dans une bonne conf, t'as intérêt à démontrer que ton axe de recherche et tes résultats sont utiles.
Plus généralement, tu nous ressors le poncif classique répété à loisir jusqu'à l'écœurement en école d'ingénieur "ça sert à rien d'optimiser", "premature optimization is the root of all evil" mais c'est ça la masturbation intellectuelle. Refuser de sortir de ses idées préconçues et de sa zone de confort intellectuelle pour aller voir ce qu'il en est en réalité. Ça ne sert pas toujours à quelquechose mais ça ne sert pas toujours à rien.
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 4.
On t'a déjà répondu en dessous, mais j'en rajoute une couche.
Mais non !
1) c'est stable depuis des années (cf en dessous). Le coût de la mémoire cache rapide est délirant contrairement à celui de la mémoire lente. C'est très bien expliqué dans l'article de Drepper.
2) les méthodes dont je parle sont « cache oblivious » c'est-à-dire qu'elles travaillent sur le principe de la hiérarchie mémoire, pas sur les valeurs fines des caches
3) pour les bibliothèques open source, les réglages fins sont faits à la compilation (cf atlas). Pour les bibliothèques propriétaires (genre MKL intel), il a plusieurs versions. Matlab intègre par exemple ces bibliothèques super optimisées.
4) la prédiction de branchement n'a pas grand impact sur les codes intensifs en calcul. En outre, son amélioration est impossible sans introspection. Il faut faire tourner le code de base instrumenté, puis donner le résultat au compilateur pour qu'il améliore le code par la suite. C'est ce que fait la JVM et c'est expliqué pour le C dans l'article de Drepper.
Ceci me semble bien naïf. Un compilateur compile, il ne comprend rien. Surtout si c'est du C qui est un langage peu structuré que les compilateurs ont beaucoup de mal à optimiser (comparé à du fortran, par exemple). Et à ma connaissance, aucun compilateur ne tient compte aujourd'hui des schémas d'accès à la mémoire, au moins pour les langages de bas niveau. En revanche, le C++ et ses expressions templates ou scale et ses DSL permettent de faire ça. Il faut bien sûr se pogner la bibliothèque de bas niveau qui fait ça.
Non, cf le code d'Atlas (qui a exactement été conçu pour résoudre ce problème, il y a plus de 10 ans).
Mais bien sûr. Je te suggère d'en discuter avec des développeurs de jeu dont l'influence sur le hardware est considérable (pas de jeu, pas de cartes Nvidia qui crachent du teraflop/s). Et plus généralement, qui de sérieux peut cracher sur un facteur 10 ?
Je ne comprends pas ta remarque dans le contexte de ngix, par exemple.
Ah, le bon vieil homme de paille… Je ne parle pas de ça, nom de dieu ! Je parle d'un facteur 10 !!!!
Si tu veux faire intervenir la personnalité de ton interlocuteur dans une discussion, ce qui frise à mon avis l'ad hominem et donc n'apporte rien, autant te renseigner sur le dit interlocuteur. Et plus généralement sur l'université. Par exemple, j'ai fait ma thèse dans l'industrie en contribuant (modestement) à l'amélioration d'un radar de Thalès (Thomson CSF à l'époque, ma barbe est grise). J'encadre des doctorants en CIFRE dans des minuscules startup comme Lokad, dans des entreprises moyennes comme Viadeo ou dans des grands groupes comme Orange et Snecma. Nos travaux sur le machine learning dans le cloud, sur l'amélioration de l'estimation des performances d'algorithmes de recommandation, sur l'exploration de grandes bases de données clients ou sur le monitoring des moteurs d'avions sont tous appliqués à des problèmes concrets. Ils sont passés en production dans certains cas. Je pratique aussi la masturbation intellectuelle en faisant des preuves de convergence pour certains algorithmes d'apprentissage automatique. Mais bon, tout ça on s'en fout car ça n'a rien à voir avec la discussion sur l'optimisation de code ! Mais c'est sûr qu'avec une telle mentalité, tu risques de ne pas suivre ce qui se fait en recherche et conserver des habitudes de programmation complètement dépassées.
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . Évalué à 5.
Je te prie de m’excuser, mon but n’était pas d’insinuer ce que tu as cru comprendre. Ce que je voulais dire, c’est que nous n’avons pas la même approche du fait que nous n’avons pas les même contraintes.
J’ai beaucoup d’estime pour les chercheurs, car, de ce que je crois en percevoir, ils ont du temps pour réfléchir, tester en efficacité et performance des nouveaux algo. Ce qui lorsqu’on peut lire les publications sert au plus grand nombre.
Sur l’ensemble de ce que tu écris je suis d’accord, je voulais juste apporté une nuance, car en te lisant j’avais compris : « Pour programmer, il faut absolument comprendre l’architecture d’un processeur. » Je voulais nuancer en disant deux choses :
Pour avoir testé des boucles imbriquées simple avec accès par indice, ou par pointeur, les compilateurs aujourd’hui et depuis quelques années sont capables de d’analyser le code et de l’optimiser. Souvent il fait beaucoup mieux que l’ingénieur moyen que je suis d’après ton reproche. Hélas nous sommes nombreux à n’être que très moyen, et pour s’adapter à ça, il me semblait intéressant de préciser que l’optimisation ne devait être que la réponse à un vrai besoin. Pas juste pour se faire plaisir. (Tu noteras que j’évite le terme de masturbation intellectuelle que je qualifierais d’ailleurs volontiers le gars qui a fait ça, et ce n’était pas péjoratif dans mon esprit).
Bah, si tu passes 10s dans un algo qui prend 4h, le fait qu’on peut passer que 1s dans cette partie, ramené à 4h, ça fait une belle jambe.
Je me souviens étudiant, on cherchait à optimiser des boucles de remplissage de triangle. On passait au final 90% du temps dans la fonction putpixel. Qui ne prenait déjà que l’accès RAM. Sachant que on écrivait en ligne, les caches de l’époque étaient mis à contribution. mais on ne pouvait raisonnablement gagner que dans les 10%. Cela valait-il l’effort, nous avons laissé là notre TP.
Ce que je veux dire par là, c’est que, dans mon métier, il faut choisir les endroits où tu optimises. Pour les chercheurs en algo, si j’ai bien compris, c’est de prendre un algo (× de matrice) et l’optimiser à mort. Ce n’est simplement pas comparable.
Bon, j’espère m’être mieux exprimé, et ne blesser personne cette fois ci. Et que mon propos sera mieux compris.
[^] # Re: suppressions ?!
Posté par flan (site web personnel) . Évalué à 2.
C'est la base de tout cours d'optimisation : on commence par évaluer (parfois à la louche, c'est suffisant) les endroits qui ont besoin d'optimisation. Personne n'ira faire une méthode de parsing des arguments en ligne de commande qui respecte le cache des processeurs…
Et quand un chercheur en algo va essayer d'optimiser à mort une méthode, c'est que cette méthode est connue pour avoir besoin d'être optimisée.
[^] # Re: suppressions ?!
Posté par Enj0lras . Évalué à 5.
Tu as déjà lu le code d'nginx ? C'est propre, il n'y a pas à dire, très portable, chaque fonctionnalité spécifique à un OS est cachée sous une couche de compatibilité.
Par contre, c'est une base de code assez compliquée à maitriser. Nginx est écrit pour être entièrement asynchrone, en utilisant epoll/kqueue, avec des mécanismes pour abstraire cela (c'est un peu une libevent à lui seul).
[^] # Re: suppressions ?!
Posté par David Carlier . Évalué à 3. Dernière modification le 04 novembre 2014 à 21:00.
Je confirme, pour avoir fait 2/3 modules nginx, je zieutais le code source et trouvais ca vraiment tres propre. Loin devant apache … Le fait que nginx utilise des fonctions custom pour l'allocation memoire n'est pas en soit forcement une mauvaise chose. Peut etre plus difficile a debugger de ce point de vue la par contre. Ceci dit ce nouveau daemon httpd m'intéresse.
[^] # Re: suppressions ?!
Posté par claudex . Évalué à 3.
C'est marrant, c'est un gros reproche qui est fait à OpenSSL, notamment par l'équipe OpenBSD.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: suppressions ?!
Posté par xcomcmdr . Évalué à 2.
Peut-être parce que la couche de compatibilité d'OpenSSL incluait des OS obsolètes, et qu'elle était trouée / mal fichue ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: suppressions ?!
Posté par AgentSteel (site web personnel) . Évalué à 2.
et surtout que OpenSSL réinventait les fonctions d'allocations/libération de mémoire (entre autres), avec un code "optimisé" (tout pourri), plutôt que d'utiliser les implémentations standard, ce qui a permis les exploits heartbleed & co
[^] # Re: suppressions ?!
Posté par boubou (site web personnel) . Évalué à 4.
Ba oui et c'est aussi un reproche qu'ils font à ngix, si j'ai bien compris.
[^] # Re: suppressions ?!
Posté par Enj0lras . Évalué à 2. Dernière modification le 04 novembre 2014 à 21:45.
Bein, je suis pas openBSD moi :p, que ça soit bien fait est une opinion personnelle. Par contre je rejoins les gars d'openBSD sur le fait que la base de code est difficile à maitriser, et je pense qu'avoir un httpd basique dans base est une bonne idée, beaucoup d'installations n'ont pas besoin de servir beaucoup de traffic et là un truc plus simple fait sens.
[^] # Re: suppressions ?!
Posté par barmic . Évalué à 3.
Le problème c'est probablement qu'elle était mal faite, parce que c'est ce qu'il font pour toute leur application portable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: suppressions ?!
Posté par MTux . Évalué à 7.
Les logiciels peuvent toujours être installés à partir des ports :)
# MySQL 5.1 et pas de de MariaDB
Posté par HanX (site web personnel) . Évalué à 3.
C'est dommage de toujours rester sur une vieille version :(
[^] # Re: MySQL 5.1 et pas de de MariaDB
Posté par Kwiknclean . Évalué à 4.
OpenBSD n'est pas vraiment un OS à usage hosting HTTP mais se veut plutôt orientée : "sécurité", Firewalling, Gateway, Routage …
Pour une liste des paquets bien à jour avec MariaBD5.5 par exemple, va faire un tours du côté de FreeBSD.
[^] # Re: MySQL 5.1 et pas de de MariaDB
Posté par Cédric Krier (site web personnel) . Évalué à 4.
La version 10.0.12 de MariaDB est présente dans le ports.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/databases/mariadb/
[^] # Re: MySQL 5.1 et pas de de MariaDB
Posté par gaston . Évalué à 4.
Mariadb est dans les ports depuis un petit moment mais la bascule depuis mysql n'avait pas été encore faite car mariadb ne compilait pas sur beaucoup d'architectures exotiques, ce qui n'a été corrigé que récemment.
# Ipv6...
Posté par chaispaquichui . Évalué à -1.
"IPv6 est désormais désactivé par défaut sur les interfaces. Il s'active lors de l'ajout d'une adresse IPv6 sur celles-ci."
Et ben… Heureusement qu'il s'agit d'un OS orienté réseau…
"Il n'est plus possible d'installer OpenBSD via un FTP ou des cartouches."
J'ai du aller voir dans la release notes pour comprendre ce qu'était une "cartouche". Un peu ironique non ?
[^] # Re: Ipv6...
Posté par claudex . Évalué à 10. Dernière modification le 02 novembre 2014 à 14:54.
Justement, ça évite d'avoir une dual-stack sans le savoir (ce qui doit être une des plus grosse faille de sécurité en ce moment), par exemple avec un système compromis qui balance des RA.
Autant, un OS grand public doit prêt out of the box pour IPv6, autant je ne m'inquiète pas trop pour les utilisateurs d'OpenBSD, ils auront l'activer (et s'ils ne savent pas, c'est sans doute une bonne chose que ce ne soit pas activé).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ipv6...
Posté par Firwen (site web personnel) . Évalué à -2. Dernière modification le 04 novembre 2014 à 12:07.
Dans ce cas, et si ils sont paranoïaques à ce point :
Il suffit simplement de désactiver les RA par défaut, en supportant uniquement DHCPv6 ou similaire.
Ou encore d'implémenter un mécanisme de protection maison contre le spoofing RA.
Je vais trés certainement m'attirer les foudres des BSD-boys ici présent mais je dirai que ça sent surtout le retard du à un manque de man power ou/et du à la procédure d'intégration
nazisuper stricte d'OpenBSD…..L’extrémisme en sécurité c'est merveilleux.
Ça peut justifier tout et n'importe quoi et surtout n'importe quoi quand il s'agit d'inaction :
La sécurité poussé à l’extrême, dans tous les domaines, c'est la prise de decision par la peur.
Et dans tous les domaines, la prise de decision par la peur, ça n'apporte que des emmerdes.
[^] # Re: Ipv6...
Posté par Enj0lras . Évalué à 5.
c'est marrant, j'ai comme l'impression que tu avais envie de troller et que tu as juste cherché un pretexte pour placer ton petit laius sur la sécurité.
Désactiver ipv6 par défaut, ça veut dire :
Bref, ça ressemble pas mal à ce que tu dis non ?
[^] # Re: Ipv6...
Posté par Firwen (site web personnel) . Évalué à -1.
Non c'était gratuit au passage ça.
Non.
Y a une grande différence entre tout désactiver par défaut, et désactiver simplement ce que tu trouves risqué ( en l'occurence le spoofing RA )
Laissez le DHCPv6 activé fait déja une belle différence.
[^] # Re: Ipv6...
Posté par Enj0lras . Évalué à 4.
Je comprends pas ce que tu veux dire… DHCP n'est activé par défaut sur une aucune interface, encore heureux, que ça soit v6 ou v4. Il faut que tu dises explicitement que tu veux un daemon DHCP.
Au passage, DHCP, ça peut être dnagereux, souviens toi de la faille bash et de dhclient (celui de l'isc, je sais pas si c'était aussi possible sous le fork de openbsd).
[^] # Re: Ipv6...
Posté par Firwen (site web personnel) . Évalué à -2.
Ben tu confirmes exactement ce que je disais sur la sécurité. Car tous les autres OS / distributions linux l'ont généralement activé par défaut.
[^] # Re: Ipv6...
Posté par Enj0lras . Évalué à 1.
C'est bien la première fois que j'entends ça, j'ai jamais utilisé un OS ou dhcp était activé par défaut sur les interfaces réseax…
[^] # Re: Ipv6...
Posté par lasher . Évalué à 5.
Ubuntu le fait par exemple.
[^] # Re: Ipv6...
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 04 novembre 2014 à 18:22.
pas que Ubuntu:
- toutes les distributions qui ont network-manager
- 99% des OS qui ont une auto configuration pour les interfaces réseaux potables ( OSX, même Windows…. )
Et c'est normal j'ai envie de dire.
Le logique par défaut communément admise c'est "avoir du réseau qui marche par défaut", et "configure en manuel si tu veux".
La logique OpenBSD ça serait plutot "c'est potentiellement vérolé ! ne faisons rien !", configurons donc tous notre eth0 à grand coup d'ifconfig.
[^] # Re: Ipv6...
Posté par Enj0lras . Évalué à 1.
Non mais là tu compares NetworkManager à la configuration d'ipv6 dans le noyau… Ça n'a rien à voir. Rien ne t'interdit d'avoir un truc comme NetworkManager (je crois pas que ça marche sur openBSD) d'installé qui va lancé automatiquement un dhcp. Mais bon, ça n'a strictement rien à voir avec ce qui est décrit ici. Si tu as un truc similaire à NetworkManager installé et lancé au démarage de ta machineę il lancerait un dhcp sur ton interface, et activerait peut être l'autroconfiguration ipv6. Bref, ça serait pareil que sous ubuntu, parce que "DHCPv6" activé par défaut, ça veut pas trop dire grand chose, il faut que quelque chose le lance. Alors que les addresses link local, ça par contre, c'est le noyau qui s'en charge.
Sinon, ça fait un long moment que j'ai pas utilisé NetworkManager, mais vers l'époque de Gnome 3.0 quand je l'avais, il fallait que l'utilisateur clique sur "activer la connexion filaire" pour que ça se connecte automatiquement, je ne me souviens pas que c'était par défaut. Si c'est maintenant par défaut, je trouve ça dommage.
[^] # Re: Ipv6...
Posté par xcomcmdr . Évalué à 2.
Euh pas moi. Quand je viens de brancher un câble Ethernet, je m'attends à ce que ça se connecte.
L'esclave, c'est pas moi, c'est l'ordinateur. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ipv6...
Posté par Enj0lras . Évalué à -1. Dernière modification le 04 novembre 2014 à 19:05.
Un exclave est censé obéir aux ordres de son maitre et pas faire des choses sans son autorisation. Enfin du moment que tu lui dis que tu veux qu'il se connecte automatiquement, c'est bon, mais que l'OS face ça de base, ça me gène.
[^] # Re: Ipv6...
Posté par gaston . Évalué à 8.
Je ne sais pas vraiment si je devrais répondre vu le ton trolleur que tu utilise, mais bon…
Lors de l'installation, on te demande si tu veux configurer les interfaces réseau détectées, éventuellement en dhcp ou RA ou adressage statique, v4 ou v6. Tu peux choisir de ne rien faire, auquel cas oui tu n'auras pas de réseau actif par défaut.
Et a tout moment, ça peut être reconfiguré via ifconfig (temporairement) ou de manière permanente via le fichier de config de l'interface.
Après, pour ce qui est de ta vision de "la logique par défaut", tu comprendras que la cible utilisateur n'est pas la même…
[^] # Re: Ipv6...
Posté par kowalsky . Évalué à 7.
La raison d'être d'OpenBSD, c'est la sécurité. Pas le desktop ou le dev. La sécurité. Ils font juste pas (ou moins) de concessions la dessus.
Au passage, que ce passe t'il sur ton réseau 192.168.1.0/24 ou tu as configuré un DHCP qui donne :
192.168.1.X/24 pour IP
192.168.1.1 pour GW
192.168.1.2 pour DNS
et que moi je branche sur ce réseau PC (192.168.1.10) qui fait DHCP que je donne :
192.168.1.X/24 pour IP
192.168.1.10 pour GW
192.168.1.10 pour DNS
Ensuite mon serveur route tout (ou pas) vers 192.168.1.1, discretoss.
Arf, le MITM, le "ce que tu veux" pour pas chère !! Tu peux le prévenir coté switch, mais je ne vois jamais cela implémenté.
Ah oui, quelle bande de nul OpenBSD de ne pas mettre le DHCP par défaut !
[^] # Re: Ipv6...
Posté par Neo_13 . Évalué à 1.
Sauf erreur ou omission de ma part, je pense que vous ne vous comprenez que partiellement : l'un parle de DHCP client et l'autre de serveur. Du coup, c'est un dialogue de sourd.
[^] # Re: Ipv6...
Posté par claudex . Évalué à 6.
En fait, on se retrouve avec la même situation qu'IPv4 (je ne crois pas que la RFC 3927 soit appliquée par défaut dans OpenBSD). Du coup, c'est bien plus cohérent, même si potentiellement chiant. Et c'est la même chose sous les distribs Linux (pour les versions serveurs), aucune n'active le DHCP sans le demander/dire à l'installation.
Je crois que plein de monde sera très impressionné si tu y arrive (vu que le but des RA, c'est de découvrir l'IP du routeur sans la connaître). La seule technique actuelle qui fonctionne, c'est dans les switch (ou alors avec une conf manuelle dans l'hôte, mais ça perd de son intérêt).
C'est parfois mon impression avec OpenBSD mais pas du tout sur ce cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# httpd
Posté par 0xfg (site web personnel) . Évalué à 4.
Je viens de découvrir l'existence de httpd, leurs serveur web minimaliste, la configuration est simple et lisible dans le même style que OpenSmtpd et tout le reste.
Est-ce que quelque-un à un retour d'expérience là-dessus ?
Vu qu'il supporte FastCGI, peut-on faire tourner PHP correctement avec httpd ?
[^] # Re: httpd
Posté par MTux . Évalué à 2.
Si je ne m'abuse, httpd était une implémentation de Apache à leur sauce, et a justement été retiré de cette version au profil de nginx.
[^] # Re: httpd
Posté par Cédric Krier (site web personnel) . Évalué à 6.
Oui mais nginx sera retiré de la futur version 5.7 au profit d'un nouveau serveur httpd(8) basé sur relayd(8).
[^] # Re: httpd
Posté par gaston . Évalué à 4.
Oui, c'est un des usecase de base, cependant en 5.6 httpd est basique (servir des fichiers statiques, debut de support du fcgi..), mais en -current ca marche très bien avec php-fpm (cf http://marc.info/?l=openbsd-cvs&m=140706459726750&w=2)
[^] # Re: httpd
Posté par 0xfg (site web personnel) . Évalué à 4.
Cool :)
Dommage qu'il n'y a pas beaucoup d'hébergeurs web/vps qui proposent OpenBSD. Apparemment OVH propose FreeBSD sur ses serveurs dédiés mais pas d'OpenBSD.
Pourtant OpenBSD semble être un bon candidat pour du hosting web, c'est simple à administrer, stable, sécuriser par défaut et bien documenter. Peut-être un peu moins performant que du Linux mais bon pour la plus part des usages ça doit bien faire l'affaire.
[^] # Re: httpd
Posté par ntimeu (site web personnel) . Évalué à 4.
Alors concernant ce sujet, tu n'es pas le seul à te demander quand sera disponible un hébergemnet sous OpenBSD !
Si tu es (comme moi) sous Kimsufi, le lien suivant pourra t'être utile (pour DragonFlyBSD mais s'adapte à OpenBSD). A essayer chez soi avant de tester directement en prod.
Après si tu as un serveur plus "cher", il y a possibilité d'avoir du vKVM (une sorte de console graphique par le réseau, qui te permets de voir ce qui se passe à "l'écran", comme si étais avec le serveur chez toi). Du coup tu peux indiquer le CD d'installation sur ton PC et le serveur bootera dessus à distance. Mais c'est disponible que sur les serveurs chers OVH.
Sinon il me semble que Online (filiale d'Illiad) propose du vKVM sur leurs serveurs low cost, mais je m'en suis jamais servit.
Et enfin, Digicube louerait des serveurs sous OpenBSD, mais l'option ne m'as jamais été proposée.
Ce post semble donner des pistes sur des loueurs de VPS avec de l'OpenBSD.
[^] # Re: httpd
Posté par claudex . Évalué à 3.
Sinon, il y a la possibilité de prendre un serveur un peu cher (mais pas trop), de laisser le Linux et de virtualiser l'OpenBSD.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: httpd
Posté par Phil_S . Évalué à 1.
Digicube ne supporte pas officiellement OpenBSD, mais (comme la plupart des autres) propose des KVM IP (soit sur la durée, pour le haut-de gamme, soit au coup par coup, à la demande pour les digione).
Une fois installé, vous montez votre ISO locale et faites une installation tout ce qu'il y a de plus classique.
Le SAV est assez réactif (sauf le WE…), le débit proposé est tenu, le prix raisonnable.
Mais on parle de dédié, là. Pour du VPS avec OpenBSD proposé en standard, TransIP m'a fait une TB impression. Après,choisir un OS orienté sécurité pour le coller en VM dans le cloud quelque part, c'est un choix que je n'ai pas fait…
[^] # Re: httpd
Posté par MTux . Évalué à 3.
Bof, installer OpenBSD pour ensuite compiler un Apache vanilla t'exposera aux mêmes failles que les autres OS. OpenBSD reste secure tant que tu n'utilises pas les ports, et donc les possibilités sont largement réduites sur un serveur dédié…
De plus la compatibilité matérielle et les performances (UFS) sont vraiment mauvaises ce qui bloque sûrement son entrée sur les serveurs flambants neufs.
[^] # Re: httpd
Posté par barmic . Évalué à 7.
C'est un peu plus subtile que ça. La sécurité peut aussi venir de la partie intégration avec le système. Typiquement un logiciel lancé dans une jail, ce n'est pas pareil qu'un logiciel lancé directement ou que celui qui est soumis à la politique d'un LSM.
Il y a des hébergeurs qui ne sont absolument pas impactés par ce genre de choses. Si on prend l'exemple d'hébergement type free. Tu as très peu d'écriture disque (en fait c'est le serveur de base de données qui fait tout le boulot d'optimisation de ce coté là).
Ensuite il y a beaucoup de monde qui manipulent tellement peu de données que tout peut tenir en cache.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: httpd
Posté par MTux . Évalué à 2.
Oui mais il n'y a pas de jails sous OpenBSD.
[^] # Re: httpd
Posté par barmic . Évalué à 3.
Les solutions que j'ai listées sont les plus connues, mais la liste n'est pas exhaustive. Il y a d'autres méthodes pour améliorer la sécurité. Par exemple OpenBSD n'a pas eu besoin d'artifice sophistiqué pour lancer Xorg en simple utilisateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: httpd
Posté par Enj0lras . Évalué à 3.
oui mais il ya privsep.
[^] # Re: httpd
Posté par wolowizard . Évalué à 5.
Bonjour,
Pourrais-tu développer ce que tu entends par mauvais?
[^] # Re: httpd
Posté par MTux . Évalué à 2.
Décompresse un truc contenant des milliers de fichiers (exemple : l'arbre des ports de FreeBSD) sur OpenBSD et sur n'importe quelle distribution Linux. Ensuite lance un rm -rf /usr/ports.
Sur OpenBSD le temps de suppression est extrêmement long…
Alors qu'avec des fs modernes c'est presque instantané.
[^] # Re: httpd
Posté par xcomcmdr . Évalué à 2.
C'est bizarre, même sur FAT12 ça devrait être rapide (seules les références aux fichiers sont détruites).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: httpd
Posté par Enj0lras . Évalué à 2.
Tu peux même pas comparer avec FAT12, parce que ça gère pas assez de fichiers :P (on parle d'un truc de l'ordre de 200k fichiers là, c'est lent même sur ext4 un rm -rf là dessus)
[^] # Re: httpd
Posté par Sidonie_Tardieu . Évalué à 2.
Toi, tu n'as jamais fait de rm sur un fs ext2… (ou tu as une mémoire sélective _).
Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
[^] # Re: httpd
Posté par Patrick Lamaizière (site web personnel) . Évalué à 3.
Pour FreeBSD, typiquement l'amélioration à ce niveau (effacement) sur UFS vient des softupdates. Faut essayer sous Open avec les softupdates activées
Ceci dit je suis d'accord que OpenBSD est pas trop performant.
les pixels au peuple !
[^] # Re: httpd
Posté par AgentSteel (site web personnel) . Évalué à 2.
Apache (la version 1.3, pas la 2.x) et nginx sont chrootés par défaut, sur OpenBSD.
# Detail sur pppd
Posté par gaston . Évalué à 5.
Petite correction: effectivement la commande ppp en userspace a disparu, mais le démon pppd dialoguant avec le driver ppp du noyau est toujours présent, il n'a pas été supprimé, mais ce sera probablement le cas quand npppd proposera aussi une implémentation cliente de ppp.
Pour la justification, cf http://marc.info/?l=openbsd-cvs&m=139507658201106&w=2 et http://marc.info/?l=openbsd-cvs&m=139507609700910&w=2. En gros, avec npppd, ca fait 3 implems du même protocole, celle la moins auditée dégage.
# Traduction de translation
Posté par Naha (site web personnel) . Évalué à 1.
La traduction de l'anglais « translation » est… « traduction ». Il y a deux occurrences à corriger dans la dépêche.
[^] # Re: Traduction de translation
Posté par Bapt (site web personnel) . Évalué à 8.
Il ne faut pas voir des anglicisme partout une translation en français ça éxiste et ça veut dire selon le larousse par exemple: "Action par laquelle on fait passer quelque chose d'un lieu dans un autre : La translation des cendres de Napoléon Ier aux Invalides." (qui vient du latin translatio)
Définition qui me semble tout a fait appropriée à packet filter.
translation en angais peut se traduire en français soit par translation, soit par traduction suivant les contextes.
[^] # Re: Traduction de translation
Posté par boubou (site web personnel) . Évalué à 5.
Mouai, sauf que « translation d'adresse », ça veut bien dire (NAT)[https://fr.wikipedia.org/wiki/Network_address_translation] ici, non ? Si c'est le cas, c'est bien une transformation d'une adresse en une autre, pas un déplacement de quelque chose. Et donc dans le contexte, c'est bien traduction qu'il faut mettre.
[^] # Re: Traduction de translation
Posté par Naha (site web personnel) . Évalué à 2.
C'était effectivement mon propos, je sais bien que « translation » est un mot en français, mais c'est un faux-ami vis-à-vis de l'anglais.
# Pour les développeurs
Posté par David Carlier . Évalué à 4. Dernière modification le 03 novembre 2014 à 15:12.
Un nouvelle fonction reallocarray dans l'espace user (un wrapper autour de realloc mais qui checke un possible overflow), assez utile :-) et dans l'espace kernel mallocarray … Bonne release ! et le CD set est just cool !
[^] # Re: Pour les développeurs
Posté par David Carlier . Évalué à 1.
Ah j'oubliais, gets a ete retire (yessssssssssssss !!). Autre petite nouvelle fonction … getentropy. pratique quand l'OS est a court de file descriptors, toujours avoir sous le coude max 256 bytes random.
# perf réseau ?
Posté par Patrick Lamaizière (site web personnel) . Évalué à 5.
Bonjour,
Y'a-t-il du nouveau sur les performances réseau / PF ?
Merci.
(au taf ça commence à devenir inquiétant de ce coté…)
les pixels au peuple !
[^] # Re: perf réseau ?
Posté par gaston . Évalué à 4.
Oui, les performances ont été améliorées de 0,27% en situation de jumbo parallax reverse tunnelling, et ont été optimisées de +24.0n/m en lancé de troll xxl-sized.
Plus sérieusement, je ne vois pas à quoi tu fais référence, et "au taf ça commence à devenir inquiétant de ce coté.." (comme si les performances s'écroulaient littéralement lorsque la lune et jupiter sont alignées) c'est de l'argumentation d'un fort beau gabarit, auquel je serais tenté de te répondre chezmoicamarche.org.
[^] # Re: perf réseau ?
Posté par Bapt (site web personnel) . Évalué à 7.
Quand tu commences a avoir un réseau avec un fort trafique les perfs de pf deviennent vraiment bloquantes (en particulier avec beaucoup de connexions simultanées). pf ne sait pas prendre en compte le smp.
J'ai pas mal rencontré le cas aussi et du coup nous envisageons de virer les firewalls OpenBSD parce qu'ils s'écroulent sous un très fort trafique. pf ne tient pas du tout la comparaison en terme de perf (note que je ne parle pas de fonctionnalité parce que de ce point de vue la il est au top) avec les autres firewalls.
Pour nous les candidats pour le moment sont ipfw ou pf sur freebsd, problème c'est que le pf de freebsd (qui supporte le smp) est trop vieux et nous ferait perdre certaines fonctionnalités, ipfw est spécial :) mais coté perfs c'est de très loin le meilleur. pf(avec support smp) est plus que correct.
[^] # Re: perf réseau ?
Posté par barmic . Évalué à 3.
Je ne connais pas plus que ça le domaine, netfilter/nftables n'est pas une option ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: perf réseau ?
Posté par Bapt (site web personnel) . Évalué à 2.
1/ nftables c'est un peu vert (? je n'ai pas regardé depuis longtemps)
2/ ces serveurs font beaucoup de magie avec d'autres outils en standard ou presques sur Free/Open BSD qui serait un enfer a passer sous linux.
[^] # Re: perf réseau ?
Posté par Patrick Lamaizière (site web personnel) . Évalué à 6.
Ce n'est pas une argumentation, c'est un constat. Ça ne tient plus notre charge (avec juste des liens 1 Gbps). À mon avis tant qu'il n'y a pas de SMP noyau faut pas en attendre beaucoup d'un pare-feu sous Open.
Dommage parce que sous OpenBSD ça marche vraiment très très bien hormis ce soucis de perf.
Plus de détails là : https://2013.jres.org/archives/31/paper31_article.pdf
Bref on va être obligé de passer sous PF/FreeBSD (sur lequel je n'ai pas trop confiance sur le PF SMP) à court terme.
Un autre comparatif : http://dev.bsdrp.net/benchs/BSD.network.performance.TenGig.png
les pixels au peuple !
[^] # Re: perf réseau ?
Posté par Bapt (site web personnel) . Évalué à 3.
Si ça peux te rassurer le pf/smp de freebsd est utilisé dans des contextes assez critique par des boîtes qui ne le laisseraient pas couler :) du coup il n'est pas près de partir. Donc si tu n'as pas besoin de fonctionnalités "nouvelles" alors c'est une bonne option. De plus 2 goulots d'étranglement potentiel sont identifiés qui si quelqu'un prend le temps de travailler devraient avoir un inpact significatif en SMP
Il a un seul probleme majeur c'est sur la fragmentation on ipv6 (iirc)
[^] # Re: perf réseau ?
Posté par patrick_g (site web personnel) . Évalué à 3.
Merci pour le document, c'est très intéressant.
A un endroit il est écrit : "à terme il est prévu une réécriture pour éviter le filtrage en sortie du pare-feu, et profiter pleinement des capacités de PF."
Est-ce que cela a été fait depuis ? Est-ce que ça peut améliorer les perfs ?
[^] # Re: perf réseau ?
Posté par gaston . Évalué à 2.
Ce que je vois surtout, c'est que tu dit (dans le papier des JRES) qu'il "n'y a pas de SMP noyau", ce qui est totalement faux, et du pur FUD. Certes, il y'a toujours le giant lock dans le kernel, mais certains travaillent a démêler tout ça couches par couches, et si tu t'obstines a utiliser un noyau GENERIC au lieu de GENERIC.MP, tu ne verras jamais d'améliorations…
Pour info, l'UBP à Clermont-Ferrand utilise un peu la même config réseau sur du 5.4, et ils ne m'ont jamais parlé de problèmes de performances.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.