> D'ailleurs, je ne comprends pas pourquoi cela n'existe pas plus.
J'aurais tendance à dire de façon provocatrice : parce que ce n'est peut-être pas si utile que ça :)
Ou plus exactement : parce que les solutions actuelles et éprouvées se rapprochent de ce que peuvent fournir les solutions de stockage RAM+BBU :
- Pour les lectures : la RAM "centrale" de la machine produit les mêmes effets car elle est exploitée par le page cache de l'OS ; de plus elle peut être utilisée pour d'autres choses en cas de besoin de l'OS ou des applications. Dans le cas de MySQL par ex., le buffer_pool_cache d'InnoDB est nettement plus rapide d'accès que le cache de l'OS (et probablement, qu'un accès via stockage de masse "ram-based") parce qu'il est "sur mesure" et n'impose pas de passer par la conversion en requètes de lecture/écriture et les diverses couches scsi/block/io_scheduler/... de l'OS pour atteindre les données. Ce n'est généralement pas protégée par batterie, mais ce n'est pas critique (ormi la dégradation initiale des perfs lors d'un cold boot, le temps que le cache de l'OS ou de l'appli se remplisse).
- Pour les écritures, il y a la RAM dans le contrôleur RAID (protégée par BBU). Si elle est de taille suffisante, elle permet souvent d'agréger suffisamment les I/O aléatoire pour s'approcher du débit linéaire du stockage de masse (ce qui est quand même pas mal, le débit linéaire d'un simple agrégat de 4 disques SAS 15krpm en RAID 10 est honorable de nos jours).
En comparaison, le SSD reste intéressant pour les machines ne pouvant intégrer suffisamment de RAM (par ex. les desktop ou serveurs installés en 32 bits), de contrôleur raid moderne (ditto). Et aussi (surtout) pour des questions de place et d'économie d'énergie : les disques durs, ça suce.
Alors :
1- Ils ne gèrent eux-même qu'une fraction des serveurs qu'ils hébèrgent.
2- Vu les merdes que remontent mes services et mon fw (bots scannant depuis des serveurs voisins), en nombre bien plus conséquent que chez mes autres et mes précédents hébergeurs, je ne dirait pas qu'ils s'en sortent bien
> Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux
J'aurais tendance à dire que c'est à eux d'amener la preuve qu'ils fournissent autre chose que de la "snake oil security" vu que :
- Ils ont des prétentions dans ce sens (voir leur com')
- C'est eux qui vendent des services, pas moi.
- Ils installent d'office un frankenkernel "grsec" contre l'avis des spécialistes du kernel au sujet de ce patchset (les mainteneurs), et bien sûr compilé sans SELinux. "Qui sont-ils pour prétendre mieux savoir que les devs du kernel eux-même ?".
- Ils l'installent aussi lorsqu'ils fournissent des serveurs installés avec autre chose que leur distro cocasse. Par exemple ils fournissent les Debian avec leur kernel (installé et booté). "Qui sont-ils pour prétendre mieux faire que les fournisseurs de ma distro ?".
Pour donner tout son sel au dernier point (les Debian sont installées sans le kernel standard de la distro), il faut préciser que la kermerde qu'ovh nous inflige _n'est pas packagée_ (ils posent un bzimage dans /boot et basta). Histoire de donner de bonnes chances aux users de louper les upgrades sécu importantes telles que fournis par les canaux usuels de la distro. Chapeau.
Ca ne veux pas dire qu'ils n'ont pas des gens compétents et intelligents en interne, mais il y a de bonnes chances pour qu'il s'agisse d'une de ces boites où un manager/décideur/monsieur-je-sais-tout fort en gueule et ne sachant pas déléguer, au hasard Oles, décide arbitrairement de choses qui le dépasse, et l'équipe technique n'a plus qu'à faire au mieux ... (pure supposition bien sûr...).
De mon point de vue, lorsque quelqu'un s'amuse à distribuer des versions patchées "pour la sécu" de logiciels bien maintenus et développés par des gens compétents, je crois que la preuve de la qualité et fiabilité de l'apport en incombe au amateurs du tuning. Le carnage de l'OpenSSL patché de Debian devrait le montrer assez pour faire réflechir les jackys de service. Le passé de Grsec aussi*.
> Sur une ML OVH, une personne se pense victime, voici son récit (qui n'apprend rien, hormis son inquiétude):
Pour relativiser un tel témoignage, il est bon de préciser que les m-l d'OVH sont saturées de bras cassés et autres admins du dimanche... (pas toujours capables de découvrir _comment_ ils se sont fait pirater, par ex.).
Quant au "patch" fournis par OVH (une réaction du type : "la *rumeur* semble vaguement indiquer qu'un problème touches les vielles [sans précisions] versions alors upgradons tout sur la dernière release"), là aussi il convient de connaître cet hébergeur pour ne pas s'affoler prématurément.
OVH est champion de la sécu à la kéké / jacky (on sécurise une distro comme on tune une voiture : en ajoutant des ailerons qui brillent). En témoigne leur distro (un fork de gentoo, ça va de soi) basée sur un kernel patché GRsec, le fameux jeux de patchs dont les mainteneurs du noyau - et les distros commerciales employant des devs noyaux (pas le cas d'ovh à priori...) - ne veulent pas.
Alors les voir "résoudre" au pifomètre ("on upgrade à la dernière release") un problème dont personne ne sait rien (y compris comment le résoudre) ne doit pas vous alarmer, et n'est en aucun cas un signe indiquant que la rumeur serait fondée.
Je crois que la meilleur source d'information à cette heure (la plus crédible) reste l'analyse du mainteneur principal d'OpenSSH. S'il y a un vrai problème, il sera l'un des premiers informés, et probablement l'un des premier à trouver/fournir la solution adaptée :
Concernant la prévention : pour contenir les vrais problèmes courants ou avérés (mots de passes faibles ou "leakés", applis installées ayant crée des users avec mots de passes std/par défaut, certificats/clefs pourries, brute force, mdp saisi sur une machine keylogguée dans un cybercafé polonais, ...), il est utile de restreindre (avec un firewall) l'accès au port 22 aux seules IP utilisées par les admins. Ne pas exposer un tel service à tout l'internet tant que ce n'est pas nécessaire.
> mais le comportement standard dans Android est partout le même : tu es obligé de
> cliquer sur un textbox pour ouvrir le clavier virtuel alors qu'il devrait apparaitre
> naturellement dès que sélectionné
Alors en fait non ; astuce : appuis sur la touche "menu", et maintient-la enfoncée pendant plus d'une seconde : ça fait apparaitre le clavier virtuel, n'importe où que tu sois (même dans des applis où le clavier n'a aucun sens comme l'appareil photo etc).
En parlant d'astuce, l'un d'entre vous saurait-il comment on peux exploiter les trois bureaux (aka "workspaces") pour y faire tourner plusieurs applis simultanément, comme sur un bon vieux desktop linux ? à moins que ça ne soit pas possible et que les bureaux multiples ne servent qu'à fournir plus de surface pour accumuler plus d'icones, de raccourcis et de widgets ?
Bonne remarque sur les annuaires LDAP. Eux ont la vie plus facile que les SGBD dans la mesure ou leur ratio lecture/écriture est censé être bien plus important (normalement) ; délayer un brin la vitesse d'écriture pour gagner en redondance est censé être un compromis généralement acceptable, dans le cas d'un annuaire.
D'autant que si les écritures sont vraiment nombreuses, il y a d'autres solutions que le multimaster horizontal/non hiérarchisé : le protocole supporte le fait de rediriger les écritures (et aussi les lectures, en fait) sur des parties de l'arbre vers divers serveurs dédiés. En gros, le "sharding" est prévu d'emblée, c'est mignon tout plein.
> D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend
> de stockage des données ([...]). Dans le cas le plus courant, il s'agit de bases Berkeley, et
> la réplication est faite au niveau ldap [...]
(sans rapport immédiat avec le commentaire parent, car effectivement dans le cas d'utilisation décrit, la réplication applicative native est bien plus judicieuse).
D'ailleurs sur ce point, une dépêche, un journal (ou mieux un article de Linux Mag !) recensant l'état des divers projets de key-value-stores (et autre imitations de Google BigTable / Amazon Dynamo) serait une bénédiction.
J'ai récemment cherché à faire le point, et ai découvert qu'il y a une orgie d'implémentations, toutes très jeunes, au point qu'il ai vraiment difficile de choisir le bon cheval.
J'avais recensé (en ne considérant que les implémentations libres ayant un nom sonnant "nom de tribu de hard tech/gabber" ;) :
Project Voldemort, CoucheDB, Ringo, Scalaris, Kai, Dynomite, ThruDB, MemcacheDB, Cassandra, HBase, Hypertable, MongoDB, Neptune, SimpleDB, Redis, Tokyo Tyrant + Toky Cabinet, Tripod, Dystopia.
> exemple de cas problématique :
> j'insère une donnée avec auto incrément à gauche.
Heu non, super mauvais exemple.
MySQL dispose d'une paire de paramètres, auto-increment-increment et auto-increment-offset, qui permettent de faire en sorte que les valeurs générées par auto increments soient systématiquement différents sur les divers serveurs.
Exemple, si on a deux serveurs, on mettra :
* my.cnf du server1:
auto-increment-increment = 2 # le nombre total de serveur du cluster
auto-increment-offset = 1 # un nombre unique par serveur inclus entre 1 et auto-increment-increment
Dès lors, server1 ne générera que des incréments impairs et server2 que des incréments pairs : pas de conflits possibles sur les clefs primaires tant qu'on utilise l'auto increment natif.
Le même principe fonctionne avec n serveurs (on aura un "auto-increment-increment = n" partout, des "auto-increment-offset = x" distincts sur chaque serveurs, et les ids générés sur les divers serveurs seront des multiples de "n % x", toujours distincts).
> donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
Exact, disons qu'elle est asynchrone et qu'il n'y a pas de verrous partagés ; donc il est possible que des transactions exécutées sur divers serveurs simultanément s'exécutent bien, mais que leurs modifs respectives soient écrasées lors de la synchro, en particulier dans le cas des UPDATE (ce qui est assez différent d'un très gênant conflit sur une clef primaire).
Ca peux néanmoins suffire prou des applis très exigeantes en termes de répartition de charge et perfs et moins exigeantes en terme de garantie de persistance des modifs (cas courant pour des applis du "web 2.0 social"), ou du moins pour la partie (le "bulk") des données pouvant tolérer ces contraintes (il n'est pas forcément toujours nécessaire de répartir la charge en écriture sur un cluster master-master sur l'ensemble des données).
Le cas échéant (applis ayant un besoin impérieux de garanties), ça peux toujours servir pour préparer un hot spare redondant sur lequel on n'écrit pas (on peux y lire, l'utiliser comme un slave), mais dont on sait qu'il est vraiment pret à prendre la main de façon robuste et supportera bien les problèmes éventuels de flip-flop ; bref, assortis à keepalived ou hearbeat ou wackamole, un "slave amélioré" prêt à être promu en vrais master sans bidouille / intervention manuelle / exécution de script / bricolage de protection (pas besoin de s'inquiéter, par ex., que le précédent master déchu puisse être de retour et re-promu en master principal). L'automatisation de la reprise d'activité sur des environnement ne supportant que la réplication unidirectionnelle (master->slave) est toujours très dangereuse et fragile...
Si j'ai bien suivi, il semble que l'auteur de xz a aussi amélioré le format au passage.
Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
« This document describes the .xz file format (filename suffix
.xz, MIME type application/x-xz). It is intended that this
this format replace the old .lzma format used by LZMA SDK and
LZMA Utils.
[...]
LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
LZMA internally, but adds support for flushing the encoder,
uncompressed chunks, eases stateful decoder implementations,
and improves support for multithreading. Thus, the plain LZMA
will not be supported in this file format. ».
« The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».
Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?
J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).
Le gars ne donne aucun détail sur les conditions de ses benchs : version du bench, type de machine (raid ou pas, qté de ram, configs, systèmes de fichiers utilisés, params passés aux outils de benchs, etc), ils ne sont pas reproductibles en l'état.
Je ne connais pas hackbench ni les détails de son test build.sh. Mais au moins concernant sysbench, qui est effectivement un bench très reconnu, les petits détails de paramétrage ont un impact notoirement significatifs (et connus pour être différents selon les OS, justement...).
Par ex. certains OS s'écroulent très vite si on augmente trop le innodb_thread_concurrency, mais peuvent tenir la même charge que d'autres si on le configure avec justesse.
Ou encore : sous linux, les différences de résultat sur ce test (en fait, sur tout les benchs OLTP / de SGBD) entre l'ordonanceur d'E/S cfq (par défaut sous Linux, très bien pour le desktop mais très mauvais pour les bdd) et le deadline (plus adapté) sont immenses. Et bien sûr la proportion entre la taille des bases et le cache (innodb_buffer_pool_size) change complètement le sens du test (si le cache est assez grand, on mesure réellement les perfs du scheduler CPU, de VM, de l'implémentation du threading, s'il est petit on mesure les perfs des drivers block/raid, du scheduler d'I/O et du système de fichier). La méthode de flush des dirty pages a aussi un impact important (sous Linux, utiliser O_DIRECT améliore significativement les résultats).
@patrick_g
> plus de gens qui utilisent OpenBSD comme routeur ou firewall
C'est aussi ce que j'avais supposé.
Et supposé par ailleurs que la maturité des outils comme kvm, xen, qemu, virtualbox et compagine devait sérieusement entamer la part d'utilisateurs restants, les curieux qui veulent jeter un oeil : de nos jours il est sans doute plus pratique pour eux de tester en restant dans leur environnement familier, et d'avoir accès aux divers OS simultanément.
Pure supposition pifométrique bien entendu ;), et ça n'enlève rien au constat que le fdisk d'OpenBSD pourrait être moins abscons.
@reno :
> Pour un utilisateur habitué quasiment tout est simple..
> C'est bien plus difficile de fournir un outil simple a utiliser pour un nouvel utilisateur!
Là où les français parlent seulement d'ergonomie, les anglais distinguent subtilement l'usability (efficacité de l'outil pour le type d'utilisateur cible) et la discoverability (facilité d'auto-apprentissage, de découvert de l'outil).
Pour un habitué tout est simple, certes, mais il existe des outils qui leurs permettent d'aller plus vite, d'autres dont la complexité apporte autre chose que de l'efficacité. Par exemple vim, emacs et eclipse ont une assez mauvaise discoverability comparé à MS Word, mais une bien meilleure usability pour certains types d'utilisation.
Voila pourquoi je disais que l'installeur d'OpenBSD est confortable et rapide pour un habitué (je n'ai pas dit qu'il est "simple").
Hmmm j'aime bien les *BSD, NetBSD compris, mais en toute bonne fois il faut reconnaitre que les gestionnaires de ports, pkgsrc et paquets sont *très* loin de l'ergonomie, du nombre de fonctionnalités, etc. de dpkg/apt (je ne compare pas à yum, qui est lui aussi passablement nul).
Franchement, quitte à vouloir faire partager son goût pour les *BSD, autant parler de leurs vrais atouts (de la même façon, j'ai beaucoup de peine pour ceux qui cherchent à promouvoir Fedora en parlant de yum au lieu d'évoquer son superbe support SELinux, le travail avec l'upstream, le LVM par défaut, le grand nombre de paquet fournissant les symboles de débogguage, les outils de gestion de masse comme Cobbler, Spacewalk, Func, FreeIPA, libvirt & co).
Si je voulais faire partager les plaisirs d'un linux à un bsdiste, par exemple, je chercherais pas à mettre en avant la documentation et les pages de man (surtout pas la doc des drivers), je ne parlerais pas de l'intégration, l'unification et la relecture systématique au niveau du code source / de la ligne de code du système de base, je ne m'aventurerais pas sur la possibilité de recompiler simplement l'intégralité du système de base après un changement d'API, j'éviterais de parler de la très unixienne beauté par la simplicité, etc...
> Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.
> Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.
> Ba supposons que tu veuille compiler un application avec une option de compilation,
> ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui
> est automatisé grâce au nombreuses pkg_option.
Là aussi, les autres systèmes offrent évidement diverses options. Comme simplement renseigner la variable d'environnement DEB_BUILD_OPTIONS, ou pour une modif plus radicale, éditer le fichier de rêgles de compil et reconstruire le .deb ainsi :
apt-get build-dep foo
apt-get source foo
cd ./foo-0.1/
vim debian/rules # ajouter ses options de compil'
dch -i
dpkg-buildpackage -rfakeroot -uc -b
Et puis pour être honnête, il faudrait penser à indiquer pourquoi NetBSD propose si peu de paquet pré-compilés pour les architectures minoritaires... (et aussi, rappeler ce que Debian et OpenBSD pensent de la cross-compilation systématique par opposition à la compilation native).
Enfin, dans tout les cas le fait que pkgsrc permette la compilation croisée ou la personnalisation est une bonne chose, mais il n'est pas le seul, et surtout cette fonctionnalité ne devrait pas masquer les lacunes pour les cas d'utilisation plus courants (0 subtilité pour la gestion des conflits, gestion des dépendances rudimentaire, par ex.).
> Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install
> openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
Oui, je crois que son commentaire était relatif à l'absence de "yum search" dans pkg_add. Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche (ou pour chercher à partir de la description, etc.).
> la chose la plus repoussante dans le projet, c'est l'installateur (surtout la partie qui demande de calculer le nombre de cylindre pour la partition du disque).
En pratique, la création ajustée manuellement de partitions DOS avec fdisk ne devrait pas concerner la majorité des utilisateurs (je pense). On en a besoin lorsque on ne souhaite pas dédier l'ensemble du disque à OpenBSD (sinon, il suffit de répondre "yes" à la question "Do you want to use *all* of wd0 for OpenBSD?" et toute cette partie fdisk est zappée comme indiqué dans la doc http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...) ) ; même dans ce cas, il suffit de créer une seule partition (en général l'installeur indique les valeurs min/max, qu'il suffit de recopier pour dire "allouer l'espace restant"). La création de partition DOS est en fait une étape permettant la cohabitation avec les systèmes utilisant ce système. Mais je reconnais volontiers que cette étape mériterai une ergonomie revisitée.
Le partitionnement fin (faire des partitions distinctes pour /, /var, la swap, etc.) tel qu'il est pratiqué par OpenBSD, c'est la création de labels avec disklabel et non les partitions fdisk, et heureusement disklabel est plus "user friendly" (il permet d'indiquer les tailles en bytes, kilobytes, megabytes, gigabytes, etc. au choix).
Cette distinction, ou plutôt ce double mode de partitionnement est souvent déconcertant et opaque pour les nouveaux venus, ce qui est bien dommage.
Donc oui, un fdisk permettant d'indiquer les dimensions en KB, MB et GB serait une bonne chose, mais peut-être encore plus utile serait une doc expliquant clairement ces notions.
Sur ce point, cette page de la doc NetBSD, avec des zolis diagrammes graphiques, est exemplaire ; dommage que la FAQ d'OpenBSD ne l'ai pas reprise ou imitée, mais en attendant vous pouvez la lire : elle s'applique telle quelle pour Open aussi: http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...)
> un installateur en ncurses comme celui de archlinux ne serait pas un mal.
Il faut garder à l'esprit qu'une des contraintes de l'installeur est qu'il doit pouvoir contenir, au grand complet (avec tout les outils nécessaires, le kernel, etc.) sur une et une seule disquette, ce qui limite pas mal les options ;). Ca ne laisse pas de place pour du "futile" comme une libcurse. OpenBSD est sûrement l'un des derniers unix modernes à permettre l'installation à partir d'une seule disquette ; vu le déclin rapide de ce média (est-ce qu'il y a encore des constructeurs qui assemblent des ordis avec un lecteur de disquette de nos jours ?) on peut supposer que cette contrainte pourrait être abandonnée dans quelques temps ...
Sinon je tient à dire que pour un utilisateur habitué, la simplicité et la concision de cet installeur s'avère confortable ; on installe son système en 15mn montre en main et hop, il ronronne :).
Réponse du tac au tac du gouvernement : le projet de loi «n'est retardé que de quelques semaines» et le gouvernement le représentera à l'Assemblée nationale «à la rentrée des vacances parlementaires de Pâques», selon le secrétaire d'Etat aux Relations avec le Parlement, Roger Karoutchi.
Si ça ne passe pas avec un tournevis, utilisez un marteau.
> Nous avons renoncé à utiliser libvirt qui pose de nombreux problèmes dans un
> environnement de production. De plus, libvirt supporte principalement Xen,
> que nous avons écarté aussi, trouvant KVM plus prometteur.
Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres solutions resteront... très confidentielles.
D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen) : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression que c'est une cause perdue d'avance :(
Alors, pour m'être posé la même question, et après avoir relu les réponses de Mac Hardy sur LWN, je crois avoir trouvé quelques éléments de réponse. Je crois qu'il faut y voir un compromis entre "tout casser" (pas de rétro/forward compatiblity, pas de plan de transition progressive) et un changement "incrémental" d'iptables qui n'aurait pas permis de résoudre les problèmes les plus pressants (langage dédié, vérifications de syntaxe et atomicité par exemple).
Mac Hardy indique qu'il compte à terme rendre le passage d'iptables à nftables totalement automatisable (scriptable). Cela n'est pas possible en changeant radicalement les paradigmes sous-jacents : sur plusieurs points, la logique chaines/tables d'iptables ne peut pas être transcrite telle quelle automatiquement en rêgles pf : ce n'est plus une retranscription mais une ré-écriture, car il faut repenser la structure du jeux de règles pour arriver aux mêmes fins. Par exemple pf a pris le partis de ne pas traiter le layer7 et de déléguer ça à l'espace utilisateur (proxys ftp ou sip...). Je crois que c'est en ce sens que Mac Hardy disait, dans les commentaires de LWN, qu'il aurait perdu en flexibilité/fonctionnalités en passant vers pf : certaines façons d'exprimer les choses "à la iptables" ne seraient plus possibles, un problème qu'il cherche de toutes évidences à éviter avec nftables, pour de bonnes raisons. Il exprime ailleurs ce soucis explicitement sur LWN, en disant au sujet de pf :There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.
Même remarque en ce qui concerne la vaste gamme d'outils générant des rulesets iptables (nufw, shorewall, ipkungfu, ...) : si la structure logique reste suffisamment identiques (au point qu'on puisse scripter la transcription de rulesets iptables en nftables), ils seront peut-être adaptables à moindre frais, mais si elle change radicalement les adapter pourrait imposer une refonte complète (ou autrement dit : iptables continuerai d'être utilisé pendant longtemps). Et vu de l'autre coté des outils, face noyau, il y ne faut pas sous-estimer la possibilité de réutiliser ce qui est déjà en place dans le noyau Linux.
Je crois que c'est sur ce même compromis (paradigmes et logique sous-jacente repris mais étendus et complétés) que la transition de ipchains vers iptables a pu se faire en douceur, au point qu'iptables fut finalement adopté assez rapidement, et que les mainteneurs ont en conséquence pu se permettre de passer ipchains en mode maintenance molle. Notez que chez OpenBSD, pf a d'abord été une quasi ré-écriture d'ipf qu'il remplaçait, et dont il reprenait la syntaxe : dans ces conditions la transition est relativement "facile". DragonFlyBSD est sortis après pf (pas d'historique à respecter). FreeBSD et NetBSD ont conservé le support ipf (et même le vieillissant ipfw pour Free) malgré l'intégration de pf. Et enfin le port de pf sous Windows (oui oui ! ça existe !) ne permet certainement pas à Microsoft de se passer de maintenir leur solution de firewalling native (si ridicule soit-elle).
Mac Hardy n'a certainement pas envie d'avoir à faire évoluer iptables toute sa vie. La contrepartie, c'est qu'iptables puis nftables vont hériter de certains petits problèmes de design et d'ergonomie initiés à l'époque d'ipchains.
Evidement, dans le meilleurs des mondes, Linux aurait des mainteneurs à vie pour ses outils actuels et intégrerait aussi les meilleures choses de ses cousins, pf et bioctl d'OpenBSD, Dtrace et ZFS de Solaris,...
Pour l'anecdote, et toujours dans les commentaires de LWN, Rusty Russel, l'auteur d'ipchains et iptables dit avec son humour légendaire :
But I always intended iptables as the assembler language of firewalls. Someone was supposed to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching this stuff. I'm still waiting :)
> But porting the kernel side doesn't make sense at all.
Ça ne fait pas de doutes, mais ça n'explique pas vraiment pourquoi il n'a pas essayé de reprendre - un minium, disons - l'interace utilisateur (la grammaire et la logique, si on veux), à moins que je n'ai pas compris son explication.
Mon hypothèse non informée à ce sujet, c'est qu'étant un des principaux développeurs de la partie noyau (netfilter), l'interface qui devait être la plus conceptuellement "naturelle" pour lui devait certainement être une interface qui se modelait sur les concepts de la structure interne au noyau (comme les outils précédents, iptables & co). C'est quand même le modèle conceptuel qui doit lui être le plus familier, et de loin.
Or il n'est pas du tout certain que la façon la plus pertinente (ergonomiquement parlant, ou en terme d'UI) d'exposer les fonctionnalités de firewalling de Linux à l'utilisateur soit de se coller au modèle interne du noyau. De même qu'un système de fichier expose une interface utilisateur adaptée, définie par posix en l'occurrence, avec open(), close() et compagnie, et pas une api collée au block layer de Linux.
Après iptables, et avec GIT et SELinux, on pourrait finir par croire que les développeurs noyau sont frappés d'une malédiction les conduisant à écrire des outils super puissant avec des interfaces toutes pourries ;). Sur ce point, au fait, les développeurs d'OpenBSD n'ont aucun mérite : ils ont initialement repris, puis amélioré la syntaxe propre et bien pensée d'ipf, le firewall de Darren Reed (sans quoi ils auraient sans doute fait quelque chose d'imbitable eux aussi).
> Il va vraiment falloir que je reprenne ce projet de test d'OpenBSD,
> car si tout ce que vous dites au sujet de PF est vrai, alors c'est la révolution...
Tu peux juger sur pièce avant même d'essayer en parcourant rapidement la zolie page de man (cf. plus bas).
> je m'étonne que PF soit si peux présent dans les environnements d'entreprise que j'ai croisé.
Il faut quand même préciser qu'il n'existe pas de support commercial pour OpenBSD (pas de Novell ni de RHEL, par ex., et personne contre qui se retourner, etc.), ce qui est rédhibitoire pour de nombreuses sociétés. Il n'y a pas non plus de support marketing, évidement. Ce n'est peut-être pas la seule raison, mais ça n'aide pas...
> Ce qui m'amène à la question suivante : existe t'il
> une bonne présentation de PF qui soit pas une page de man ?
Il faut avoir à l'esprit qu'il y a dans le monde *BSD l'idée que tout doit être complètement documenté dans les pages de man (y compris les drivers et les fichiers de conf), plutôt que (ou avant) toute doc sur un site web.
Donc si ton souhait d'éviter la page de man est motivé par le besoin d'une doc pratique qui ne soit pas une simple et très formelle liste d'options cli d'un outil, je te rassure, celle-ci est vraiment rédigée comme une documentation pratique tout en restant la doc de référence. Vous pouvez par exemple scroller vers la fin (juste avant la partie "GRAMMAR"), où il y a une (longue) section d'exemples :
Pas de bol, la logique (plus que la syntaxe) de nftables (telle qu'exposée par Patrick Mac Hardy, c'est évidement moins visible dans l'exemple de la dépêche) est encore a des années lumières d'être aussi simple et naturelle que celle de pf, d'où la plainte justifié de l'auteur de la dépêche : "c'est un véritable cadeau empoisonné car il faudra tout réapprendre.". La syntaxe est elle-aussi moins bonne, mais c'est moins grave à mes yeux.
On garde, par exemple, au coeur de l'outil, l'ensemble des concepts de chaines et tables, qui correspondent effectivement à ce qui se trouve coté noyau chez linux, mais qui ne sont certainement pas la façon la plus ergonomique d'exposer les choses à l'utilisateur (et donc avec la nécessité, toujours, de garder en tête leurs contextes respectifs d'application, leurs ordres de traitement, etc., qui font qu'aujourd'hui la sécurité effectivement assurée par un gros firewall iptables based est très difficile à vérifier en le lisant seulement (ie. sans le tester), à la différence de pf). La syntaxe reste assez verbeuse à priori, mais tout de même en net progrès par rapport à iptables (véritable langage et non plus options cli d'un binaire, notion d'implicites selon le contexte, par ex...). Mais ce qui aurait été à revoir fondamentalement n'a pas changé : la possibilité de faire des rulesets vraiment propres structurés, lisibles, au moins linéairement ; les sauts de chaines sont aux configuration structurées précisément ce que le GOTO était à la programmation à l'époque de Djikstra....
Quelques progrès tout de même, qui nous rapprochent un brin de pf, comme la possibilité de tester la syntaxe d'un ruleset avant de le charger (enfin !). Reste qu'il est vraiment dommage que Mac Hardy ai préféré s'amuser à inventer son langage à lui plutôt que de reprendre au moins l'interface utilisateur de pf.
> Genre j'ai un fichier de 2Go et mon disque est plein, il ne reste que 100Mo,
> avec le copy-on-write, je peux en faire une copie mais pas le modifier?
Il y a une imprécision dans la description du COW de la dépêche qui peux induire en erreur: ce qui est "copié" à l'écriture (en fait, tout simplement : écrit ailleurs qu'à l'emplacement d'origine), c'est le bloc écrit, pas le fichier lui-même. Copie un fichier complet aurait un cout énorme.
> on pert la notion d'espace maximal de stoquage d'un disque, non ?
Sur un système de fichier posix traditionnel, la taille d'un fichier et son occupation disque sont déjà des notions relativement indépendantes.
Dans la même catégorie d'outils sympas, il y a aussi lsyncd. Celui-ci synchronise des fichiers et répertoires par rsync en cas de changement détecté par inotify.
Auparavant j'utilisais des rsync lancés en boucles infinies, ce qui avait pas mal de désavantages : cela consomme des I/O disque inutilement (du fait de la traversé permanente de l'ensemble de l'arborescence sur la source et sur les mirroirs), cela consomme de la bande passante et du temps de calcul inutilement (tout les fichiers de l'arborescence sont comparés), et ne distribue effectivement les modifications qu'avec un inutile retard (le temps qu'il ai refait un tour de boucle, donc une traversée de l'arborescence et qu'il découvre le fichier modifié).
Lsyncd au contraire réplique *immédiatement* tout fichier ou répertoire modifié, et uniquement lui, et dort le reste du temps.
> De toute façon, je risque d'y avoir droit bientôt, on parle de basculer Fedora à Git.
C'est ça le nerf de la guerre.
La question de la complexité ou de la phase d'apprentissage peut être envisagée autrement désormais.
On a tous de grandes chances d'avoir à apprendre Git (pour participer ou accéder à l'historique du noyau, de perl, de gnome et de ses composants, ...), beaucoup moins d'avoir à apprendre les autres DVCS. Git est en passe de devenir la lingua franca du DVCS de projet libre. En conséquence, le sur-coût d'apprentissage (pour soi et surtout pour aux autres qui pourraient vouloir accéder à son projet), serait, précisément, de vouloir utiliser autre chose que Git.
C'est ce que fait remarquer Lennart Poettering ici http://0pointer.de/blog/projects/on-version-control-systems.(...) :
What matters more is not scaring contributors away by making it hard for them to contribute by requiring them to learn yet another VCS. [...] don't make it hard for me by asking me to learn your favourite one, please. [...] If you start a new Open Source project today, and you don't choose GIT as VCS then you basically ask potential contributors to go away.
"KVM" était deux choses distinctes :
- Une module noyau pour Linux gérant l'accélération de la virtualisation
- Un fork amical et temporaire de Qemu exploitant ce module
Maintenant "KVM" devient :
- Un module noyau, toujours
- Un des "accelerator" possibles dans Qemu (avec tcg (le natif / non assisté par le noyau), kqemu, peut-être bientôt Xen, ou, qui sait, peut-être un jour l'"accelerator" de virtualbox ?)
- La branche "expérimentale" de Qemu concernant les modifications relatives à la virtualisation, et destinées à être mergées après cleanup et tests
> Quel intérêt d'utiliser QEMU avec le support KVM si c'est pour avoir KVM au final?
En gros que KVM devient la branche "bleeding edge" de la partie de qemu exploitant le module KVM de Linux. Donc dans un cas, tu aura moins de risques de bugs, dans l'autre les fonctionnalités en avant première.
>> C'est KVM.
> Je pense qu'il parlait plutôt de KQemu, voir en:kqemu.
Ce qui est sûr, c'est que l'essentiel du code de kvm en espace utilisateur (qui était de fait un fork de qemu) a été mergé, et qu'il est prévu de merger tout le reste au fur et à mesure. Les drivers virtio aussi ont été mergés d'ailleurs. Pour ce que j'en comprends, KVM (le logiciel userland) est censé devenir, à moyen terme, une simple branche "staging" des fonctionnalités destinés à atterir dans le qemu upstream.
Les patchs de Gerd Hoffmann amenant l'implémentation du support/émulation d'un dom0, et permettant de gérer des domU depuis qemu n'ont pas encore été mergés en revanche (les types de Xen on fait un peu de resistance, on les comprends, et on réussi à délayer l'intégration en réclamant du temps pour la relecture depuis des mois).
Quant à kqemu, il n'est désormais plus « l'accélérateur officiel » de qemu visiblement ; le mainteneur actuel de qemu ne veux pas appliquer les patchs sur ce module, et recommande aux personnes intéressées de forker.
En vrac, quelques autres nouveautés de cette release pas cités dans la dépêche ni dans le changelog (il y a eu énormément de changement entre la 0.9 et cette release, et un regain d'activité *énorme* autour du projet) :
- Le support de VDE (les virtual ethernet switchs)
- Le support du balooning (offrant la possibilité d'augmenter/réduire dynamiquement à chaud la mémoire dispo pour un guest donné).
- Le support de NBD, permettant de monter les images qcow2 (ou autre) sur l'ordi hote.
- Le support de la peste pulseaudio
- Les drivers virtio (paravirtualisation), en particulier ethernet et block, offrant d'excellentes performances
- Le support de l'IPv6
- L'option -vga (qemu -vga std, "-vga cirrus", "-vga vmware")
- Une interface curse
- Plein d'amélioration autour du support VNC : la possibilité d'avoir plusieurs clients vnc sur un même guest, de l'utiliser en même temps que le SDL, l'authentification par SASL, le support du SSL, le support de la compression tight, ...
- L'émulation en userpace marche maintenant sur les BSD (au moins OpenBSD)
- Le SCSI passtrough (comme pour l'USB, permet à un guest d'accéder directement à un périphérique physique de l'hote)
Les fonctionnalités apportées par Qt Extended / qtpe / Qtopia devraient y survivre. La "communauté" travaille depuis belle lurette sur un fork de Qtopia (Qt 2) appelé OPIE (Open Palmtop Integrated Environment) : http://opie.handhelds.org/cgi-bin/moin.cgi/ . Il existe aussi un projet OPIE II re-basé sur Qtopia 4.2 (la première version libérée) : http://opie.home.linuxtogo.org/ (mais ce projet ne semble pas hyper actif).
Le développement de Qtopia n'a, de toutes façons, été ouvert que depuis très peu de temps (depuis la version 4.2, datant de fin 2006). Tout les projets embarqués libres et Qt-based dont j'avais connaissance jusqu'à présent (en général basés sur OpenEmbedded et Angstrom) avaient en conséquence concentré leurs efforts sur OPIE plutôt que Qtopia.
Ce double abandon de la part de Nokia réouvre la question de leurs objectifs et de leur stratégie. Pourquoi Nokia a racheté Trolltech ? Les vieilles hypothèses s'effondrent.
Lorsqu'on sait que les téléphones - des périphériques embarqués avec interfaces graphiques - constituent leur principal fond de commerce de Nokia, que java est un environnement de dev capital et très utilisé dans cet écosystème, que le toolkit graphique de Symbian, l'OS maintenu par Nokia, est épouvantable, frustre, et non portable, quand on sait que Nokia finance le portage de Qt sur Symbian, on pouvait jusqu'à présent imaginer que Nokia comptait sur Qt pour moderniser (en remplaçant) l'interface, le toolkit et les API haut niveau de leurs périphériques. Voir carrément pour succéder à Symbian UI sur les téléphones les plus évolués. Mais pour mettre en oeuvre cette hypothèse, il leur faut une suite PIM et un gestionnaire de fenêtres basé sur Qt (Qtopia), et un binding java sachant exploiter ce toolkit (comme Qt Jambi), soit précisément ce qu'ils ont abandonné. Qtopia été tout de même la version "smartphone" & PDA de Qt. Il est donc maintenant clair que Nokia ne compte pas produire massivement des smartphones basés (ou plutôt uniquements basés) sur Qt.
Mais si l'on supposait, à l'inverse, que Nokia avait acheté Trolltech hors de toute stratégie globale, sans rapports avec leurs propres produits, et plus simplement parce qu'ils auraient voulu diversifier leurs activités et avaient flairé une bonne affaire, on se heurte de nouveau aux faits récents : le changement de licence qu'ils viennent de décider fera quasiment disparaitre du même coup la source de revenus de Trolltech. Ils n'ont donc pas acheté Trolltech pour les revenus directs de cette société.
Alors, que veut Nokia (et en conséquence, où vas Qt) ?
Pour installer les OS à distance, sans avoir à bricoler les CD d'install afin de leur dire de lancer l'installeur sur la console série virtuelle en mode texte (ce qui n'est d'ailleurs pas toujours possible), et au passage attacher une image iso locale de l'OS à la machine comme un "cdrom virtuel".
Selon l'environnement, un boot pxe d'un bootloader + kernel + installeur paramétrés pour utiliser la console virtuelle série fournie/émulée par la carte de management conviennent très bien, mais pas lorsque les OS à installer changent souvent, ou qu'il y a des non-unix parmi eux, ou qu'on ne peux pas poser de serveur tftp sur le réseau cible.
Une fois l'OS installé, je n'utilise jamais ce truc bien sûr, je ne suis pas maso ;-) (là, effectivement, un ssh est très bien, ou encore le serial over ipmi, et encore j'ai vraiment rarement besoin d'accéder à la vraie console principale d'un serveur une fois celui-ci installé).
Aussi, pour tripatouiller dans l'interface des controleurs raid...
[^] # Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 1.
J'aurais tendance à dire de façon provocatrice : parce que ce n'est peut-être pas si utile que ça :)
Ou plus exactement : parce que les solutions actuelles et éprouvées se rapprochent de ce que peuvent fournir les solutions de stockage RAM+BBU :
- Pour les lectures : la RAM "centrale" de la machine produit les mêmes effets car elle est exploitée par le page cache de l'OS ; de plus elle peut être utilisée pour d'autres choses en cas de besoin de l'OS ou des applications. Dans le cas de MySQL par ex., le buffer_pool_cache d'InnoDB est nettement plus rapide d'accès que le cache de l'OS (et probablement, qu'un accès via stockage de masse "ram-based") parce qu'il est "sur mesure" et n'impose pas de passer par la conversion en requètes de lecture/écriture et les diverses couches scsi/block/io_scheduler/... de l'OS pour atteindre les données. Ce n'est généralement pas protégée par batterie, mais ce n'est pas critique (ormi la dégradation initiale des perfs lors d'un cold boot, le temps que le cache de l'OS ou de l'appli se remplisse).
- Pour les écritures, il y a la RAM dans le contrôleur RAID (protégée par BBU). Si elle est de taille suffisante, elle permet souvent d'agréger suffisamment les I/O aléatoire pour s'approcher du débit linéaire du stockage de masse (ce qui est quand même pas mal, le débit linéaire d'un simple agrégat de 4 disques SAS 15krpm en RAID 10 est honorable de nos jours).
En comparaison, le SSD reste intéressant pour les machines ne pouvant intégrer suffisamment de RAM (par ex. les desktop ou serveurs installés en 32 bits), de contrôleur raid moderne (ditto). Et aussi (surtout) pour des questions de place et d'économie d'énergie : les disques durs, ça suce.
[^] # Re: Pas facile de ce prononcer...
Posté par herodiade . En réponse au journal Faille OpenSSH : qu'une rumeur mais.... Évalué à 10.
Alors :
1- Ils ne gèrent eux-même qu'une fraction des serveurs qu'ils hébèrgent.
2- Vu les merdes que remontent mes services et mon fw (bots scannant depuis des serveurs voisins), en nombre bien plus conséquent que chez mes autres et mes précédents hébergeurs, je ne dirait pas qu'ils s'en sortent bien
> Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux
J'aurais tendance à dire que c'est à eux d'amener la preuve qu'ils fournissent autre chose que de la "snake oil security" vu que :
- Ils ont des prétentions dans ce sens (voir leur com')
- C'est eux qui vendent des services, pas moi.
- Ils installent d'office un frankenkernel "grsec" contre l'avis des spécialistes du kernel au sujet de ce patchset (les mainteneurs), et bien sûr compilé sans SELinux. "Qui sont-ils pour prétendre mieux savoir que les devs du kernel eux-même ?".
- Ils l'installent aussi lorsqu'ils fournissent des serveurs installés avec autre chose que leur distro cocasse. Par exemple ils fournissent les Debian avec leur kernel (installé et booté). "Qui sont-ils pour prétendre mieux faire que les fournisseurs de ma distro ?".
Pour donner tout son sel au dernier point (les Debian sont installées sans le kernel standard de la distro), il faut préciser que la kermerde qu'ovh nous inflige _n'est pas packagée_ (ils posent un bzimage dans /boot et basta). Histoire de donner de bonnes chances aux users de louper les upgrades sécu importantes telles que fournis par les canaux usuels de la distro. Chapeau.
Ca ne veux pas dire qu'ils n'ont pas des gens compétents et intelligents en interne, mais il y a de bonnes chances pour qu'il s'agisse d'une de ces boites où un manager/décideur/monsieur-je-sais-tout fort en gueule et ne sachant pas déléguer, au hasard Oles, décide arbitrairement de choses qui le dépasse, et l'équipe technique n'a plus qu'à faire au mieux ... (pure supposition bien sûr...).
De mon point de vue, lorsque quelqu'un s'amuse à distribuer des versions patchées "pour la sécu" de logiciels bien maintenus et développés par des gens compétents, je crois que la preuve de la qualité et fiabilité de l'apport en incombe au amateurs du tuning. Le carnage de l'OpenSSL patché de Debian devrait le montrer assez pour faire réflechir les jackys de service. Le passé de Grsec aussi*.
* http://www.digitalarmaments.com/2007200184936274.html
[^] # Re: Pas facile de ce prononcer...
Posté par herodiade . En réponse au journal Faille OpenSSH : qu'une rumeur mais.... Évalué à 10.
Pour relativiser un tel témoignage, il est bon de préciser que les m-l d'OVH sont saturées de bras cassés et autres admins du dimanche... (pas toujours capables de découvrir _comment_ ils se sont fait pirater, par ex.).
Quant au "patch" fournis par OVH (une réaction du type : "la *rumeur* semble vaguement indiquer qu'un problème touches les vielles [sans précisions] versions alors upgradons tout sur la dernière release"), là aussi il convient de connaître cet hébergeur pour ne pas s'affoler prématurément.
OVH est champion de la sécu à la kéké / jacky (on sécurise une distro comme on tune une voiture : en ajoutant des ailerons qui brillent). En témoigne leur distro (un fork de gentoo, ça va de soi) basée sur un kernel patché GRsec, le fameux jeux de patchs dont les mainteneurs du noyau - et les distros commerciales employant des devs noyaux (pas le cas d'ovh à priori...) - ne veulent pas.
Alors les voir "résoudre" au pifomètre ("on upgrade à la dernière release") un problème dont personne ne sait rien (y compris comment le résoudre) ne doit pas vous alarmer, et n'est en aucun cas un signe indiquant que la rumeur serait fondée.
Je crois que la meilleur source d'information à cette heure (la plus crédible) reste l'analyse du mainteneur principal d'OpenSSH. S'il y a un vrai problème, il sera l'un des premiers informés, et probablement l'un des premier à trouver/fournir la solution adaptée :
http://marc.info/?l=openssh-unix-dev&m=124705272824524&a(...)
Concernant la prévention : pour contenir les vrais problèmes courants ou avérés (mots de passes faibles ou "leakés", applis installées ayant crée des users avec mots de passes std/par défaut, certificats/clefs pourries, brute force, mdp saisi sur une machine keylogguée dans un cybercafé polonais, ...), il est utile de restreindre (avec un firewall) l'accès au port 22 aux seules IP utilisées par les admins. Ne pas exposer un tel service à tout l'internet tant que ce n'est pas nécessaire.
[^] # Re: HTC Magic
Posté par herodiade . En réponse au journal SmartPhone/PdaPhone + GPS sous Symbian ? Je sèche un peu.... Évalué à 2.
> cliquer sur un textbox pour ouvrir le clavier virtuel alors qu'il devrait apparaitre
> naturellement dès que sélectionné
Alors en fait non ; astuce : appuis sur la touche "menu", et maintient-la enfoncée pendant plus d'une seconde : ça fait apparaitre le clavier virtuel, n'importe où que tu sois (même dans des applis où le clavier n'a aucun sens comme l'appareil photo etc).
En parlant d'astuce, l'un d'entre vous saurait-il comment on peux exploiter les trois bureaux (aka "workspaces") pour y faire tourner plusieurs applis simultanément, comme sur un bon vieux desktop linux ? à moins que ça ne soit pas possible et que les bureaux multiples ne servent qu'à fournir plus de surface pour accumuler plus d'icones, de raccourcis et de widgets ?
[^] # Re: et les annuaires ?
Posté par herodiade . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 2.
D'autant que si les écritures sont vraiment nombreuses, il y a d'autres solutions que le multimaster horizontal/non hiérarchisé : le protocole supporte le fait de rediriger les écritures (et aussi les lectures, en fait) sur des parties de l'arbre vers divers serveurs dédiés. En gros, le "sharding" est prévu d'emblée, c'est mignon tout plein.
> D'ailleurs, avec openldap, il est possible d'utiliser un mysql par exemple comme backend
> de stockage des données ([...]). Dans le cas le plus courant, il s'agit de bases Berkeley, et
> la réplication est faite au niveau ldap [...]
J'en profite pour signaler, parce que c'est un fait souvent peu connu, que BDB dispose de fonctionnalités de réplication :
http://www.oracle.com/technology/documentation/berkeley-db/d(...)
(sans rapport immédiat avec le commentaire parent, car effectivement dans le cas d'utilisation décrit, la réplication applicative native est bien plus judicieuse).
[^] # Re: RDBMS sucks
Posté par herodiade . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 7.
> http://www.erlang.org/doc/apps/mnesia/
> http://jackrabbit.apache.org/
> http://www.mongodb.org/
> http://incubator.apache.org/cassandra/
> ...ne sont que quelques exemples...
D'ailleurs sur ce point, une dépêche, un journal (ou mieux un article de Linux Mag !) recensant l'état des divers projets de key-value-stores (et autre imitations de Google BigTable / Amazon Dynamo) serait une bénédiction.
J'ai récemment cherché à faire le point, et ai découvert qu'il y a une orgie d'implémentations, toutes très jeunes, au point qu'il ai vraiment difficile de choisir le bon cheval.
J'avais recensé (en ne considérant que les implémentations libres ayant un nom sonnant "nom de tribu de hard tech/gabber" ;) :
Project Voldemort, CoucheDB, Ringo, Scalaris, Kai, Dynomite, ThruDB, MemcacheDB, Cassandra, HBase, Hypertable, MongoDB, Neptune, SimpleDB, Redis, Tokyo Tyrant + Toky Cabinet, Tripod, Dystopia.
Autrement dit, un bon paquet. Ceci m'a aidé, mais ce n'est pas complet ni à jour :
http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib(...)
L'un de vous aurait des expériences à partager sur le sujet ?
[^] # Re: Réplication Mysql master/master
Posté par herodiade . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 10.
> j'insère une donnée avec auto incrément à gauche.
Heu non, super mauvais exemple.
MySQL dispose d'une paire de paramètres, auto-increment-increment et auto-increment-offset, qui permettent de faire en sorte que les valeurs générées par auto increments soient systématiquement différents sur les divers serveurs.
Exemple, si on a deux serveurs, on mettra :
* my.cnf du server1:
auto-increment-increment = 2 # le nombre total de serveur du cluster
auto-increment-offset = 1 # un nombre unique par serveur inclus entre 1 et auto-increment-increment
* my.cnf de server2 :
auto-increment-increment = 2
auto-increment-offset = 2
Dès lors, server1 ne générera que des incréments impairs et server2 que des incréments pairs : pas de conflits possibles sur les clefs primaires tant qu'on utilise l'auto increment natif.
Le même principe fonctionne avec n serveurs (on aura un "auto-increment-increment = n" partout, des "auto-increment-offset = x" distincts sur chaque serveurs, et les ids générés sur les divers serveurs seront des multiples de "n % x", toujours distincts).
Hop, la doc de ref : http://dev.mysql.com/doc/refman/5.1/en/replication-options-m(...)
> donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
Exact, disons qu'elle est asynchrone et qu'il n'y a pas de verrous partagés ; donc il est possible que des transactions exécutées sur divers serveurs simultanément s'exécutent bien, mais que leurs modifs respectives soient écrasées lors de la synchro, en particulier dans le cas des UPDATE (ce qui est assez différent d'un très gênant conflit sur une clef primaire).
Ca peux néanmoins suffire prou des applis très exigeantes en termes de répartition de charge et perfs et moins exigeantes en terme de garantie de persistance des modifs (cas courant pour des applis du "web 2.0 social"), ou du moins pour la partie (le "bulk") des données pouvant tolérer ces contraintes (il n'est pas forcément toujours nécessaire de répartir la charge en écriture sur un cluster master-master sur l'ensemble des données).
Le cas échéant (applis ayant un besoin impérieux de garanties), ça peux toujours servir pour préparer un hot spare redondant sur lequel on n'écrit pas (on peux y lire, l'utiliser comme un slave), mais dont on sait qu'il est vraiment pret à prendre la main de façon robuste et supportera bien les problèmes éventuels de flip-flop ; bref, assortis à keepalived ou hearbeat ou wackamole, un "slave amélioré" prêt à être promu en vrais master sans bidouille / intervention manuelle / exécution de script / bricolage de protection (pas besoin de s'inquiéter, par ex., que le précédent master déchu puisse être de retour et re-promu en master principal). L'automatisation de la reprise d'activité sur des environnement ne supportant que la réplication unidirectionnelle (master->slave) est toujours très dangereuse et fragile...
[^] # Re: tar
Posté par herodiade . En réponse à la dépêche Slackware abandonne les tgz. Évalué à 10.
Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
« This document describes the .xz file format (filename suffix
.xz, MIME type application/x-xz). It is intended that this
this format replace the old .lzma format used by LZMA SDK and
LZMA Utils.
[...]
LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
LZMA internally, but adds support for flushing the encoder,
uncompressed chunks, eases stateful decoder implementations,
and improves support for multithreading. Thus, the plain LZMA
will not be supported in this file format. ».
Concernant la justification de ces divergences/améliorations du format, je cite l'auteur ( source : http://sourceforge.net/forum/forum.php?thread_id=2918394&(...) ):
« The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».
Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?
J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).
# Méthodologie ?
Posté par herodiade . En réponse au journal Benchmark NetBSD5, NetBSD4, Fedora et FreeBSD. Évalué à 7.
Je ne connais pas hackbench ni les détails de son test build.sh. Mais au moins concernant sysbench, qui est effectivement un bench très reconnu, les petits détails de paramétrage ont un impact notoirement significatifs (et connus pour être différents selon les OS, justement...).
Par ex. certains OS s'écroulent très vite si on augmente trop le innodb_thread_concurrency, mais peuvent tenir la même charge que d'autres si on le configure avec justesse.
Ou encore : sous linux, les différences de résultat sur ce test (en fait, sur tout les benchs OLTP / de SGBD) entre l'ordonanceur d'E/S cfq (par défaut sous Linux, très bien pour le desktop mais très mauvais pour les bdd) et le deadline (plus adapté) sont immenses. Et bien sûr la proportion entre la taille des bases et le cache (innodb_buffer_pool_size) change complètement le sens du test (si le cache est assez grand, on mesure réellement les perfs du scheduler CPU, de VM, de l'implémentation du threading, s'il est petit on mesure les perfs des drivers block/raid, du scheduler d'I/O et du système de fichier). La méthode de flush des dirty pages a aussi un impact important (sous Linux, utiliser O_DIRECT améliore significativement les résultats).
[^] # Re: Un bon projet
Posté par herodiade . En réponse à la dépêche OpenBSD 4.5, Games. Évalué à 3.
> plus de gens qui utilisent OpenBSD comme routeur ou firewall
C'est aussi ce que j'avais supposé.
Et supposé par ailleurs que la maturité des outils comme kvm, xen, qemu, virtualbox et compagine devait sérieusement entamer la part d'utilisateurs restants, les curieux qui veulent jeter un oeil : de nos jours il est sans doute plus pratique pour eux de tester en restant dans leur environnement familier, et d'avoir accès aux divers OS simultanément.
Pure supposition pifométrique bien entendu ;), et ça n'enlève rien au constat que le fdisk d'OpenBSD pourrait être moins abscons.
@reno :
> Pour un utilisateur habitué quasiment tout est simple..
> C'est bien plus difficile de fournir un outil simple a utiliser pour un nouvel utilisateur!
Là où les français parlent seulement d'ergonomie, les anglais distinguent subtilement l'usability (efficacité de l'outil pour le type d'utilisateur cible) et la discoverability (facilité d'auto-apprentissage, de découvert de l'outil).
Pour un habitué tout est simple, certes, mais il existe des outils qui leurs permettent d'aller plus vite, d'autres dont la complexité apporte autre chose que de l'efficacité. Par exemple vim, emacs et eclipse ont une assez mauvaise discoverability comparé à MS Word, mais une bien meilleure usability pour certains types d'utilisation.
Voila pourquoi je disais que l'installeur d'OpenBSD est confortable et rapide pour un habitué (je n'ai pas dit qu'il est "simple").
[^] # Re: NetBSD Desktop Project
Posté par herodiade . En réponse à la dépêche Sortie de NetBSD 5.0. Évalué à 5.
Franchement, quitte à vouloir faire partager son goût pour les *BSD, autant parler de leurs vrais atouts (de la même façon, j'ai beaucoup de peine pour ceux qui cherchent à promouvoir Fedora en parlant de yum au lieu d'évoquer son superbe support SELinux, le travail avec l'upstream, le LVM par défaut, le grand nombre de paquet fournissant les symboles de débogguage, les outils de gestion de masse comme Cobbler, Spacewalk, Func, FreeIPA, libvirt & co).
Si je voulais faire partager les plaisirs d'un linux à un bsdiste, par exemple, je chercherais pas à mettre en avant la documentation et les pages de man (surtout pas la doc des drivers), je ne parlerais pas de l'intégration, l'unification et la relecture systématique au niveau du code source / de la ligne de code du système de base, je ne m'aventurerais pas sur la possibilité de recompiler simplement l'intégralité du système de base après un changement d'API, j'éviterais de parler de la très unixienne beauté par la simplicité, etc...
> Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.
> Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.
Il existe bien entendu une méga foultitude de façon de faire ça avec Debian, par ex. et entre autres :
http://www.linux.codehelp.co.uk/apt-cross/re01.html
http://psas.pdx.edu/DebianCrossCompilerHowto/
L'élégance de NetBSD est ailleurs.
> Ba supposons que tu veuille compiler un application avec une option de compilation,
> ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui
> est automatisé grâce au nombreuses pkg_option.
Là aussi, les autres systèmes offrent évidement diverses options. Comme simplement renseigner la variable d'environnement DEB_BUILD_OPTIONS, ou pour une modif plus radicale, éditer le fichier de rêgles de compil et reconstruire le .deb ainsi :
apt-get build-dep foo
apt-get source foo
cd ./foo-0.1/
vim debian/rules # ajouter ses options de compil'
dch -i
dpkg-buildpackage -rfakeroot -uc -b
Et puis pour être honnête, il faudrait penser à indiquer pourquoi NetBSD propose si peu de paquet pré-compilés pour les architectures minoritaires... (et aussi, rappeler ce que Debian et OpenBSD pensent de la cross-compilation systématique par opposition à la compilation native).
Enfin, dans tout les cas le fait que pkgsrc permette la compilation croisée ou la personnalisation est une bonne chose, mais il n'est pas le seul, et surtout cette fonctionnalité ne devrait pas masquer les lacunes pour les cas d'utilisation plus courants (0 subtilité pour la gestion des conflits, gestion des dépendances rudimentaire, par ex.).
> Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install
> openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
Oui, je crois que son commentaire était relatif à l'absence de "yum search" dans pkg_add. Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche (ou pour chercher à partir de la description, etc.).
[^] # Re: Un bon projet
Posté par herodiade . En réponse à la dépêche OpenBSD 4.5, Games. Évalué à 5.
En pratique, la création ajustée manuellement de partitions DOS avec fdisk ne devrait pas concerner la majorité des utilisateurs (je pense). On en a besoin lorsque on ne souhaite pas dédier l'ensemble du disque à OpenBSD (sinon, il suffit de répondre "yes" à la question "Do you want to use *all* of wd0 for OpenBSD?" et toute cette partie fdisk est zappée comme indiqué dans la doc http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...) ) ; même dans ce cas, il suffit de créer une seule partition (en général l'installeur indique les valeurs min/max, qu'il suffit de recopier pour dire "allouer l'espace restant"). La création de partition DOS est en fait une étape permettant la cohabitation avec les systèmes utilisant ce système. Mais je reconnais volontiers que cette étape mériterai une ergonomie revisitée.
Le partitionnement fin (faire des partitions distinctes pour /, /var, la swap, etc.) tel qu'il est pratiqué par OpenBSD, c'est la création de labels avec disklabel et non les partitions fdisk, et heureusement disklabel est plus "user friendly" (il permet d'indiquer les tailles en bytes, kilobytes, megabytes, gigabytes, etc. au choix).
Cette distinction, ou plutôt ce double mode de partitionnement est souvent déconcertant et opaque pour les nouveaux venus, ce qui est bien dommage.
Donc oui, un fdisk permettant d'indiquer les dimensions en KB, MB et GB serait une bonne chose, mais peut-être encore plus utile serait une doc expliquant clairement ces notions.
Sur ce point, cette page de la doc NetBSD, avec des zolis diagrammes graphiques, est exemplaire ; dommage que la FAQ d'OpenBSD ne l'ai pas reprise ou imitée, mais en attendant vous pouvez la lire : elle s'applique telle quelle pour Open aussi:
http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...)
> un installateur en ncurses comme celui de archlinux ne serait pas un mal.
Il faut garder à l'esprit qu'une des contraintes de l'installeur est qu'il doit pouvoir contenir, au grand complet (avec tout les outils nécessaires, le kernel, etc.) sur une et une seule disquette, ce qui limite pas mal les options ;). Ca ne laisse pas de place pour du "futile" comme une libcurse. OpenBSD est sûrement l'un des derniers unix modernes à permettre l'installation à partir d'une seule disquette ; vu le déclin rapide de ce média (est-ce qu'il y a encore des constructeurs qui assemblent des ordis avec un lecteur de disquette de nos jours ?) on peut supposer que cette contrainte pourrait être abandonnée dans quelques temps ...
Sinon je tient à dire que pour un utilisateur habitué, la simplicité et la concision de cet installeur s'avère confortable ; on installe son système en 15mn montre en main et hop, il ronronne :).
[^] # Re: Au fond, ça ne change rien
Posté par herodiade . En réponse au journal HADOPI rejeté. Évalué à 6.
Il faut prendre ses sources dans l'organe de com' officiel du gouvernement (non non, pas la télévision publique, je parlais du figaro cette fois ;) :
http://www.lefigaro.fr/politique/2009/04/09/01002-20090409AR(...)
Le projet de loi devra désormais repasser devant les deux chambres. Roger Karoutchi promet que ce sera le cas dans quelques semaines.
et
Réponse du tac au tac du gouvernement : le projet de loi «n'est retardé que de quelques semaines» et le gouvernement le représentera à l'Assemblée nationale «à la rentrée des vacances parlementaires de Pâques», selon le secrétaire d'Etat aux Relations avec le Parlement, Roger Karoutchi.
Si ça ne passe pas avec un tournevis, utilisez un marteau.
[^] # Re: Libvirt ?
Posté par herodiade . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. Évalué à 2.
> environnement de production. De plus, libvirt supporte principalement Xen,
> que nous avons écarté aussi, trouvant KVM plus prometteur.
Ca c'est balot, parce qu'en ce moment, tout converge vers libvirt. RH emploi du beau linge pour travailler dessus, mais c'est aussi le seul gestionnaire de vm descent des dernières Debian, ... bref ce n'est plus l'affaire de quelques mois avant que libvirt soit l'outil de base/quasi standard pour les sysadmins. Autant dire que les autres solutions resteront... très confidentielles.
D'autre part les devs de libvirt contribuent fortement à Qemu/KVM (et un peu à Xen) : ce sont donc eux qui infléchirons la direction qui leur convient en ce qui concerne la gestion ; ils ont déjà implémenté le support d'auth par certificat X.509 sur le VNC de Qemu, ainsi que le support des multiples sorties graphiques simultanées, de l'auth SASL, ils travaillent sur le design de l'interface stdio de Qemu, l'intégration avec func (un projet RH aussi), FreeIPA, Cobbler, Puppet, ...
Un peu de concurrence et d'émulation ne feront pas de mal, mais j'ai l'impression que c'est une cause perdue d'avance :(
[^] # Re: Réinventer
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 7.
Mac Hardy indique qu'il compte à terme rendre le passage d'iptables à nftables totalement automatisable (scriptable). Cela n'est pas possible en changeant radicalement les paradigmes sous-jacents : sur plusieurs points, la logique chaines/tables d'iptables ne peut pas être transcrite telle quelle automatiquement en rêgles pf : ce n'est plus une retranscription mais une ré-écriture, car il faut repenser la structure du jeux de règles pour arriver aux mêmes fins. Par exemple pf a pris le partis de ne pas traiter le layer7 et de déléguer ça à l'espace utilisateur (proxys ftp ou sip...). Je crois que c'est en ce sens que Mac Hardy disait, dans les commentaires de LWN, qu'il aurait perdu en flexibilité/fonctionnalités en passant vers pf : certaines façons d'exprimer les choses "à la iptables" ne seraient plus possibles, un problème qu'il cherche de toutes évidences à éviter avec nftables, pour de bonnes raisons. Il exprime ailleurs ce soucis explicitement sur LWN, en disant au sujet de pf :There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.
Même remarque en ce qui concerne la vaste gamme d'outils générant des rulesets iptables (nufw, shorewall, ipkungfu, ...) : si la structure logique reste suffisamment identiques (au point qu'on puisse scripter la transcription de rulesets iptables en nftables), ils seront peut-être adaptables à moindre frais, mais si elle change radicalement les adapter pourrait imposer une refonte complète (ou autrement dit : iptables continuerai d'être utilisé pendant longtemps). Et vu de l'autre coté des outils, face noyau, il y ne faut pas sous-estimer la possibilité de réutiliser ce qui est déjà en place dans le noyau Linux.
Je crois que c'est sur ce même compromis (paradigmes et logique sous-jacente repris mais étendus et complétés) que la transition de ipchains vers iptables a pu se faire en douceur, au point qu'iptables fut finalement adopté assez rapidement, et que les mainteneurs ont en conséquence pu se permettre de passer ipchains en mode maintenance molle. Notez que chez OpenBSD, pf a d'abord été une quasi ré-écriture d'ipf qu'il remplaçait, et dont il reprenait la syntaxe : dans ces conditions la transition est relativement "facile". DragonFlyBSD est sortis après pf (pas d'historique à respecter). FreeBSD et NetBSD ont conservé le support ipf (et même le vieillissant ipfw pour Free) malgré l'intégration de pf. Et enfin le port de pf sous Windows (oui oui ! ça existe !) ne permet certainement pas à Microsoft de se passer de maintenir leur solution de firewalling native (si ridicule soit-elle).
Mac Hardy n'a certainement pas envie d'avoir à faire évoluer iptables toute sa vie. La contrepartie, c'est qu'iptables puis nftables vont hériter de certains petits problèmes de design et d'ergonomie initiés à l'époque d'ipchains.
Evidement, dans le meilleurs des mondes, Linux aurait des mainteneurs à vie pour ses outils actuels et intégrerait aussi les meilleures choses de ses cousins, pf et bioctl d'OpenBSD, Dtrace et ZFS de Solaris,...
Pour l'anecdote, et toujours dans les commentaires de LWN, Rusty Russel, l'auteur d'ipchains et iptables dit avec son humour légendaire :
But I always intended iptables as the assembler language of firewalls. Someone was supposed to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching this stuff. I'm still waiting :)
[^] # Re: Linux Weekly News
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 6.
Ça ne fait pas de doutes, mais ça n'explique pas vraiment pourquoi il n'a pas essayé de reprendre - un minium, disons - l'interace utilisateur (la grammaire et la logique, si on veux), à moins que je n'ai pas compris son explication.
Mon hypothèse non informée à ce sujet, c'est qu'étant un des principaux développeurs de la partie noyau (netfilter), l'interface qui devait être la plus conceptuellement "naturelle" pour lui devait certainement être une interface qui se modelait sur les concepts de la structure interne au noyau (comme les outils précédents, iptables & co). C'est quand même le modèle conceptuel qui doit lui être le plus familier, et de loin.
Or il n'est pas du tout certain que la façon la plus pertinente (ergonomiquement parlant, ou en terme d'UI) d'exposer les fonctionnalités de firewalling de Linux à l'utilisateur soit de se coller au modèle interne du noyau. De même qu'un système de fichier expose une interface utilisateur adaptée, définie par posix en l'occurrence, avec open(), close() et compagnie, et pas une api collée au block layer de Linux.
Après iptables, et avec GIT et SELinux, on pourrait finir par croire que les développeurs noyau sont frappés d'une malédiction les conduisant à écrire des outils super puissant avec des interfaces toutes pourries ;). Sur ce point, au fait, les développeurs d'OpenBSD n'ont aucun mérite : ils ont initialement repris, puis amélioré la syntaxe propre et bien pensée d'ipf, le firewall de Darren Reed (sans quoi ils auraient sans doute fait quelque chose d'imbitable eux aussi).
[^] # Re: Bonne nouvelle
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 6.
> car si tout ce que vous dites au sujet de PF est vrai, alors c'est la révolution...
Tu peux juger sur pièce avant même d'essayer en parcourant rapidement la zolie page de man (cf. plus bas).
> je m'étonne que PF soit si peux présent dans les environnements d'entreprise que j'ai croisé.
Il faut quand même préciser qu'il n'existe pas de support commercial pour OpenBSD (pas de Novell ni de RHEL, par ex., et personne contre qui se retourner, etc.), ce qui est rédhibitoire pour de nombreuses sociétés. Il n'y a pas non plus de support marketing, évidement. Ce n'est peut-être pas la seule raison, mais ça n'aide pas...
> Ce qui m'amène à la question suivante : existe t'il
> une bonne présentation de PF qui soit pas une page de man ?
Il y a en particulier ceci http://www.openbsd.org/faq/pf/index.html , mais c'est plutôt un tuto basique, bien moins complet que la page de man.
Il faut avoir à l'esprit qu'il y a dans le monde *BSD l'idée que tout doit être complètement documenté dans les pages de man (y compris les drivers et les fichiers de conf), plutôt que (ou avant) toute doc sur un site web.
Donc si ton souhait d'éviter la page de man est motivé par le besoin d'une doc pratique qui ne soit pas une simple et très formelle liste d'options cli d'un outil, je te rassure, celle-ci est vraiment rédigée comme une documentation pratique tout en restant la doc de référence. Vous pouvez par exemple scroller vers la fin (juste avant la partie "GRAMMAR"), où il y a une (longue) section d'exemples :
Bref, c'est la doc de référence :
http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf
En complément il y a aussi :
* L'outil pour charger et manipuler les jeux de règles :
http://www.openbsd.org/cgi-bin/man.cgi?query=pfctl
* Quelques outils complémentaires :
http://www.openbsd.org/cgi-bin/man.cgi?query=pflog
http://www.openbsd.org/cgi-bin/man.cgi?query=pflogd
http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync
http://www.openbsd.org/cgi-bin/man.cgi?query=pflow
[^] # Re: Bonne nouvelle
Posté par herodiade . En réponse au journal NFtables, successeur d'Iptables. Évalué à 10.
On garde, par exemple, au coeur de l'outil, l'ensemble des concepts de chaines et tables, qui correspondent effectivement à ce qui se trouve coté noyau chez linux, mais qui ne sont certainement pas la façon la plus ergonomique d'exposer les choses à l'utilisateur (et donc avec la nécessité, toujours, de garder en tête leurs contextes respectifs d'application, leurs ordres de traitement, etc., qui font qu'aujourd'hui la sécurité effectivement assurée par un gros firewall iptables based est très difficile à vérifier en le lisant seulement (ie. sans le tester), à la différence de pf). La syntaxe reste assez verbeuse à priori, mais tout de même en net progrès par rapport à iptables (véritable langage et non plus options cli d'un binaire, notion d'implicites selon le contexte, par ex...). Mais ce qui aurait été à revoir fondamentalement n'a pas changé : la possibilité de faire des rulesets vraiment propres structurés, lisibles, au moins linéairement ; les sauts de chaines sont aux configuration structurées précisément ce que le GOTO était à la programmation à l'époque de Djikstra....
Quelques progrès tout de même, qui nous rapprochent un brin de pf, comme la possibilité de tester la syntaxe d'un ruleset avant de le charger (enfin !). Reste qu'il est vraiment dommage que Mac Hardy ai préféré s'amuser à inventer son langage à lui plutôt que de reprendre au moins l'interface utilisateur de pf.
NIH to the rescue !
[^] # Re: Btrfs
Posté par herodiade . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 7.
> avec le copy-on-write, je peux en faire une copie mais pas le modifier?
Il y a une imprécision dans la description du COW de la dépêche qui peux induire en erreur: ce qui est "copié" à l'écriture (en fait, tout simplement : écrit ailleurs qu'à l'emplacement d'origine), c'est le bloc écrit, pas le fichier lui-même. Copie un fichier complet aurait un cout énorme.
> on pert la notion d'espace maximal de stoquage d'un disque, non ?
Sur un système de fichier posix traditionnel, la taille d'un fichier et son occupation disque sont déjà des notions relativement indépendantes.
$ dd if=/dev/zero of=fichier count=1 seek=10M
$ du -h fichier
16K fichier
$ ls -lh fichier
-rw-r--r-- 1 pouet pouet 5,1G 2009-03-24 20:42 fichier
# ... et lsyncd (pour du rsync déclenché par inotify)
Posté par herodiade . En réponse au journal Incron :: inotify cron system. Évalué à 10.
Auparavant j'utilisais des rsync lancés en boucles infinies, ce qui avait pas mal de désavantages : cela consomme des I/O disque inutilement (du fait de la traversé permanente de l'ensemble de l'arborescence sur la source et sur les mirroirs), cela consomme de la bande passante et du temps de calcul inutilement (tout les fichiers de l'arborescence sont comparés), et ne distribue effectivement les modifications qu'avec un inutile retard (le temps qu'il ai refait un tour de boucle, donc une traversée de l'arborescence et qu'il découvre le fichier modifié).
Lsyncd au contraire réplique *immédiatement* tout fichier ou répertoire modifié, et uniquement lui, et dort le reste du temps.
http://code.google.com/p/lsyncd/
[^] # Re: Git powaaa !
Posté par herodiade . En réponse à la dépêche GNOME 2.26 est disponible. Évalué à 5.
C'est ça le nerf de la guerre.
La question de la complexité ou de la phase d'apprentissage peut être envisagée autrement désormais.
On a tous de grandes chances d'avoir à apprendre Git (pour participer ou accéder à l'historique du noyau, de perl, de gnome et de ses composants, ...), beaucoup moins d'avoir à apprendre les autres DVCS. Git est en passe de devenir la lingua franca du DVCS de projet libre. En conséquence, le sur-coût d'apprentissage (pour soi et surtout pour aux autres qui pourraient vouloir accéder à son projet), serait, précisément, de vouloir utiliser autre chose que Git.
C'est ce que fait remarquer Lennart Poettering ici http://0pointer.de/blog/projects/on-version-control-systems.(...) :
What matters more is not scaring contributors away by making it hard for them to contribute by requiring them to learn yet another VCS. [...] don't make it hard for me by asking me to learn your favourite one, please. [...] If you start a new Open Source project today, and you don't choose GIT as VCS then you basically ask potential contributors to go away.
[^] # Re: C'est quoi la différence finalement????
Posté par herodiade . En réponse au journal qemu 0.10 is out \o/. Évalué à 5.
- Une module noyau pour Linux gérant l'accélération de la virtualisation
- Un fork amical et temporaire de Qemu exploitant ce module
Maintenant "KVM" devient :
- Un module noyau, toujours
- Un des "accelerator" possibles dans Qemu (avec tcg (le natif / non assisté par le noyau), kqemu, peut-être bientôt Xen, ou, qui sait, peut-être un jour l'"accelerator" de virtualbox ?)
- La branche "expérimentale" de Qemu concernant les modifications relatives à la virtualisation, et destinées à être mergées après cleanup et tests
> Quel intérêt d'utiliser QEMU avec le support KVM si c'est pour avoir KVM au final?
En gros que KVM devient la branche "bleeding edge" de la partie de qemu exploitant le module KVM de Linux. Donc dans un cas, tu aura moins de risques de bugs, dans l'autre les fonctionnalités en avant première.
[^] # Re: Qemu 0.10
Posté par herodiade . En réponse au journal qemu 0.10 is out \o/. Évalué à 10.
> Je pense qu'il parlait plutôt de KQemu, voir en:kqemu.
Ce qui est sûr, c'est que l'essentiel du code de kvm en espace utilisateur (qui était de fait un fork de qemu) a été mergé, et qu'il est prévu de merger tout le reste au fur et à mesure. Les drivers virtio aussi ont été mergés d'ailleurs. Pour ce que j'en comprends, KVM (le logiciel userland) est censé devenir, à moyen terme, une simple branche "staging" des fonctionnalités destinés à atterir dans le qemu upstream.
Les patchs de Gerd Hoffmann amenant l'implémentation du support/émulation d'un dom0, et permettant de gérer des domU depuis qemu n'ont pas encore été mergés en revanche (les types de Xen on fait un peu de resistance, on les comprends, et on réussi à délayer l'intégration en réclamant du temps pour la relecture depuis des mois).
Quant à kqemu, il n'est désormais plus « l'accélérateur officiel » de qemu visiblement ; le mainteneur actuel de qemu ne veux pas appliquer les patchs sur ce module, et recommande aux personnes intéressées de forker.
En vrac, quelques autres nouveautés de cette release pas cités dans la dépêche ni dans le changelog (il y a eu énormément de changement entre la 0.9 et cette release, et un regain d'activité *énorme* autour du projet) :
- Le support de VDE (les virtual ethernet switchs)
- Le support du balooning (offrant la possibilité d'augmenter/réduire dynamiquement à chaud la mémoire dispo pour un guest donné).
- Le support de NBD, permettant de monter les images qcow2 (ou autre) sur l'ordi hote.
- Le support de la peste pulseaudio
- Les drivers virtio (paravirtualisation), en particulier ethernet et block, offrant d'excellentes performances
- Le support de l'IPv6
- L'option -vga (qemu -vga std, "-vga cirrus", "-vga vmware")
- Une interface curse
- Plein d'amélioration autour du support VNC : la possibilité d'avoir plusieurs clients vnc sur un même guest, de l'utiliser en même temps que le SDL, l'authentification par SASL, le support du SSL, le support de la compression tight, ...
- L'émulation en userpace marche maintenant sur les BSD (au moins OpenBSD)
- Le SCSI passtrough (comme pour l'USB, permet à un guest d'accéder directement à un périphérique physique de l'hote)
# OPIE à la place de Qtopia, projet de Nokia
Posté par herodiade . En réponse au journal Après Jambi, Qtopia ?. Évalué à 1.
Le développement de Qtopia n'a, de toutes façons, été ouvert que depuis très peu de temps (depuis la version 4.2, datant de fin 2006). Tout les projets embarqués libres et Qt-based dont j'avais connaissance jusqu'à présent (en général basés sur OpenEmbedded et Angstrom) avaient en conséquence concentré leurs efforts sur OPIE plutôt que Qtopia.
Ce double abandon de la part de Nokia réouvre la question de leurs objectifs et de leur stratégie. Pourquoi Nokia a racheté Trolltech ? Les vieilles hypothèses s'effondrent.
Lorsqu'on sait que les téléphones - des périphériques embarqués avec interfaces graphiques - constituent leur principal fond de commerce de Nokia, que java est un environnement de dev capital et très utilisé dans cet écosystème, que le toolkit graphique de Symbian, l'OS maintenu par Nokia, est épouvantable, frustre, et non portable, quand on sait que Nokia finance le portage de Qt sur Symbian, on pouvait jusqu'à présent imaginer que Nokia comptait sur Qt pour moderniser (en remplaçant) l'interface, le toolkit et les API haut niveau de leurs périphériques. Voir carrément pour succéder à Symbian UI sur les téléphones les plus évolués. Mais pour mettre en oeuvre cette hypothèse, il leur faut une suite PIM et un gestionnaire de fenêtres basé sur Qt (Qtopia), et un binding java sachant exploiter ce toolkit (comme Qt Jambi), soit précisément ce qu'ils ont abandonné. Qtopia été tout de même la version "smartphone" & PDA de Qt. Il est donc maintenant clair que Nokia ne compte pas produire massivement des smartphones basés (ou plutôt uniquements basés) sur Qt.
Mais si l'on supposait, à l'inverse, que Nokia avait acheté Trolltech hors de toute stratégie globale, sans rapports avec leurs propres produits, et plus simplement parce qu'ils auraient voulu diversifier leurs activités et avaient flairé une bonne affaire, on se heurte de nouveau aux faits récents : le changement de licence qu'ils viennent de décider fera quasiment disparaitre du même coup la source de revenus de Trolltech. Ils n'ont donc pas acheté Trolltech pour les revenus directs de cette société.
Alors, que veut Nokia (et en conséquence, où vas Qt) ?
[^] # Re: Pourquoi du Dell
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
Selon l'environnement, un boot pxe d'un bootloader + kernel + installeur paramétrés pour utiliser la console virtuelle série fournie/émulée par la carte de management conviennent très bien, mais pas lorsque les OS à installer changent souvent, ou qu'il y a des non-unix parmi eux, ou qu'on ne peux pas poser de serveur tftp sur le réseau cible.
Une fois l'OS installé, je n'utilise jamais ce truc bien sûr, je ne suis pas maso ;-) (là, effectivement, un ssh est très bien, ou encore le serial over ipmi, et encore j'ai vraiment rarement besoin d'accéder à la vraie console principale d'un serveur une fois celui-ci installé).
Aussi, pour tripatouiller dans l'interface des controleurs raid...