C'est vrai que c'est passé assez inaperçu, alors que le choix d'un annuaire en entreprise a un impact direct sur ce qu'on va retrouver au niveau OS sur le reste du parc.
Cependant, RedHat ne joue pas encore dans la même cours que SUN et Novell (je sais j'exclue AD là, mais j'ai encore du mal à le considérer comme un annuaire généraliste). SUN One a plus grand chose à voir avec iPlanet maintenant (il y a plein de fonctionnalités en plus, notamment de méta-annuaire).
Je pense cependant que RedHat va tenter de s'aligner et fournir en opensource les services de meta-annuaire qui vont bien. Je pense que c'est surtout sur çà que se démarquent les différents annuaires actuels.
Il reste donc pas mal de boulot encore pour RedHat, mais ca reste malgré tout une petite révolution. La route a beau être encore longue, la pente est douce :)
Vu que samba repose sur du LDAP pur (comprendre qu'il n'y a pas d'intéractions avec des objets cachés de l'annuaire comme sur les domaines AD), je mets ma main à couper que ca marchera quasiment out-of-the-box (à la limite quite à faire une extension de schéma, qui, soit dit en passant, est aussi nécessaire pour OpenLDAP).
J'avais réussi à faire un truc similaire avec PAM/pam_ldap, nss_ldap et eDirectory, sans trop faire couler de sueur, et je sais que c'est dors et déjà possible sur des serveurs iPlanet.
Nop, c'est clairement du code différent. OpenLDAP date du milieu d'année 1998 alors que iPlanet Directory Server en était déjà à la version 3 ou 4 à cette époque. Par contre il est très probable que OpenLDAP ait repris la même ligne de commande (un peu comme Postfix et Exim assurent une compatibilité Sendmail).
Sur un nombre d'objets raisonnable, OpenLDAP est certainement imbattable au niveau performance. Là où la différence se fait sentir, c'est sur de grandes quantité de données et quand on a besoin d'autres choses que de la performance ;)
Il y a des infos intéressantes sur le pourquoi du comment du rachat de Directory Services par Red Hat sur le blog de Chris Blizzard (dev de chez Red Hat et membre de la Mozilla Foundation): http://www.0xdeadbeef.com/html/2005/01/(...)
Quel développement ? Le WRT54G est déjà un linux dans sa version de base (avec aucun accès au système).
Donc soit tu as peu de temps à tuer et tu mets à jour le firmware avec un firmware HyperWRT, qui te gardera les fonctionnalités originelles du WRT54G ainsi que des fonctionnalités en plus ET un shell sur la machine (si tu veux rajouter des règles iptables a la mimine).
Soit tu as bcp de temps à tuer et tu installes OpenWRT qui te donnera un linux minimaliste sur lequel tu pourras rajouter les fonctionnalités que tu veux.
En ce qui concerne H323, il y a (avait ?) un conntrack spécifique dans netfilter. Sinon, tu as Upnp (qui est en l'occurence utilisé par Linksys pour faire ca sur le WRT).
Franchement, pour le prix d'un joujou comme ca (dans les 70¤), ca serait dommage de se priver :)
En ce qui concerne le kernel NT, il s'agit d'un micro-kernel conçu par Microsoft par des personnes débauchées de feu Digital UNIX. Le kernel avait donc à l'origine un design très proche de celui de OpenVMS (qui est d'ailleurs toujours commercialisé par HP).
Après, on se doute bien que Microsoft n'a pas récupéré la partie TCP/IP sur VMS qui était prévu à l'origine pour fonctionner sur DECnet (même si une pile TCP/IP a été rajoutée depuis).
A propos des jails BSD, il est intéressant de noter que Grsecurity implémente justement ces mécanismes pour le noyau Linux. Ca peut être intéressant de regarder ça avant de se lancer dans une installation de SElinux, qui est quand même bien plus lourd à mettre en place et à gérer (quoique, dans ce domaine je pense que c'est plus une question d'habitude).
Perso, je reste plutôt partisan de la solution du vserver (c'est simple à mettre en place et ca ouvre pas mal de possibilités au niveau administration).
J'en profite pour lancer une question qui me taraude depuis pas mal de temps. Je sais bien que ports <1024 ne peuvent être ouverts qu'avec les privilèges root, afin déviter que n'importe quel utilisateur puisse lancer les services standards. Cependant, l'impact d'une compromission sur ces services là a des effets plutôt moches (même si maintenant la plupart sont capables d'abandonner les capacités de l'utilisateur root une fois qu'ils se sont initialisés). Pourquoi cette limitation perdure-t-elle ? Est-ce pour une question de conformité POSIX ?
je savais que SUNOne et Netscape Directory Server avait la même base, mais je pensais que Netscape Directory Server était mort.
C'etait effectivement le cas. Quand redhat a repris le code, celui-ci n'avait pas bougé depuis decembre 2003, ca fait pratiquement un an de totale inactivité...
Apparemment l'API cliente de Mozilla fait partie du même projet. D'ailleurs sa doc ressemble énormément à celle de SUNOne.
D'ailleurs, lorsque le code de netscape avait mis en opensource, il manquait toute la partie interfaçage LDAP, que le projet Mozilla a depuis refait si je ne m'abuse
Je me demande ce que vaut vraiment la version Netscape, et ce que vaudra la version RedHat...
Beaucoup d'entreprises tournent encore avec le serveur de Netscape, avec des bases d'utilisateurs non négligeables. Il est assez fréquent de voir des annuaires Netscape gérer des centaines de milliers de comptes sans broncher. De plus, ce serveur se mariait très bien avec le pendant web de iPlanet, quand il s'agissait de faire des portails web, avec gestions de pages blanches utilisateurs (il arrive souvent de voir des sites avec comme favicon l'icone de Netscape... je l'ai vu il y a pas longtemps quelque part sur le site de France Telecom par exemple)
Un autre point intéressant est la gestion de PKI facilitée qu'offre ce serveur. J'ai pas vraiment d'idée des fonctionnalités qu'elle offre exactement, mais je suppose que ca doit être quelque chose de comparable aux fonctionnalités qu'offre eDirectory en la matière. Sur OpenLDAP, c'est au mieux une couche qui vient se rajouter par dessus (OpenCA par ex, ou IDX-PKI). Ca permettrait d'avoir une gestion de certificat native dans l'annuaire et surtout qui sera aisée à interfacer avec Mozilla ou Thunderbird.
Tout ca pour dire que je suis bien excité par la potentielle mise en opensource d'un produit comme ca, quand en plus il y a une boîte comme RedHat derrière pour guider le navire :)
Non, il ne s'agit pas d'une erreur.
Pour info, sunONE (annuaire de sun) et Netscape Directory Server sont tous deux dérivés du projet iPlanet. Redhat a racheté récemment à AOL les sources de Netscape Directory Server qu'ils avaient récupéré lors du rachat de Netscape.
Je te conseille donc de jeter un petit coup d'oeil à cette news: http://linuxfr.org/2004/10/01/17329.html(...)
Il faut cependant bien voir que depuis la séparation de sunONE, Sun a fait énormément de travail dessus et l'annuaire n'a plus grand chose à voir avec iPlanet.
J'avoue avoir un peu de mal à m'en sortir avec ton journal, ca part un peu dans tous les sens :)
eDirectory est un très bon annuaire (son principal défaut étant vraisemblablement de ne pas être opensource). C'est historiquement un annuaire X.500 avec une couche de compatibilité LDAP par dessus (on voit toujours apparaître les dénominations du schéma Novell: User au lieu de inetOrgPerson, etc.) Par contre, le connecteur LDAP lui est totalement conforme à la norme (tu peux créer des utilisateurs inetOrgPerson et l'annuaire se charge de tout mettre en forme).
eDirectory est relativement léger (il reste cependant plus lourd que OpenLDAP), assez robuste et monte en charge largement mieux que OpenLDAP.
Sa vraie puissance se situe surtout au niveau des mécanismes de réplication, qui sont autrement plus poussés que ceux actuellement disponibles sur OpenLDAP, et sur les outils fournis pour mettre en place un méta-annuaire (connecteurs pour différentes sources de données: fichiers textes, AD, Notes, etc., que l'on configure via des fichiers xml et des feuilles de style XSLT). C'est très élégant, mais aussi très cher (je crois que c'est de l'ordre de 4 euros par utilisateur...).
J'espère sincèrement que l'on pourra avoir des outils de ce style en opensource, et particulièrement que Redhat mette le code d'iPlanet en opensource rapidement
Cela vient en grande partie du fait que toute la gestion des recherches correspond en fait au même code dans Exim, que ca soit du LDAP, du SQL ou un fichier texte. Après il n'y a que les fonctions de bas niveau d'accès aux données qui changent. Pour Postfix, ce sont dans mes souvenirs des options de configuration bien différentes.
Réponse point à point:
Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable. Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.
Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur... Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...
Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
De plus, pour avoir eu à réparer assez ponctuellement des serveurs mails totalement freezés, parce que amavis partait en vrille à 100% du proc pour une raison inconnue, si je peux me passer d'amavis, c'est aussi bien.
Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches. La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.
Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.
Ca se fait en natif et de façon super simple car tu peux utiliser le résultat d'une recherche ldap/sql/db pour décider du routage du mail, ou l'endroit du disque ou il doit être stocké.
Exim est utilisé par des hébergeurs comme Lost-Oasis pour faire la gestion des mails des différents domaines qu'ils hébergent.
Je peux me tromper, mais je vois beaucoup (tout est relatif cependant) de gens sur irc qui resolvent en gaoland.net, donc je pense qu'il s'agit plutot d'un FAI...
Un whois par exemple permet d'apprendre que c'est rattaché à LDCOM (donc à Neuf Telecom...). Que ca prenne 2% du volume du site me choque un peu moins du coup.
Juste une remarque cependant concernant les documentations que vous fournissez (et notamment ubuntu-pratique.pdf): c'est un avis tout à fait personnel, mais quand je lis une documentation remplie de fautes d'orthographe, je ne vois que ça... et ça ne me rassure pas pour la suite. Vous devriez peut-être faire une seconde lecture.
En vrac ce que j'ai noté:
première partie: manque un s à disque
deuxième partie: CD-ROM
Si après quelques secondes...: la phrase est grammaticalement incorrecte, il faudrait mettre une ,
apparaît s'écrit avec deux p
Passage alternatif de l'infinitif à la deuxième personne du pluriel (il vaudrait mieux utiliser tout le temps cette deuxième forme)
d'autres options sont disponibleS
après quelqueS secondeS
souhaiteZ
En matant un peu, les sources du mail envoyé, on trouve ça:
From: "challenge8" <ch8@club-internet.fr>
Subject: Votre e-BADGE d'accès au salon et aux conférences gratuites Solutions LINUX
X-Mailer: Microsoft CDO for Windows 2000
X-DSPAM-Result: Spam
Franchement, quand je vois ça, la première chose à laquelle je pense est "phishing", et honnêtement j'espère sincèrement que ca en est... Niveau sérieux et crédibilité pour un salon qui se veut professionnel, je crois qu'il va falloir repasser... (même si je sais bien que la gestion des badges n'est pas gérée directement par l'organisation du salon, mais par une boite externe, infopromotions il me semble)
Je sais que chez certains ca marche bien, mais sur ma premiere machine (madwifi) le kernel part en vrille (keventd à 100% du proc) et reboote au bout de 15s.
Sur l'autre machine, ca marche tout simplement pas (impossible d'activer l'interface...).
Les fonctionnalités du driver sont de plus assez limitées sous linux (évidemment ca doit largement suffir si c'est juste pour la faire fonctionner en mode infrastructure)
Aucune carte que tu peux trouver dans le commerce et ayant une puce prism ne marche à l'heure actuelle. Peut-être que sur eBay tu trouveras des "anciennes" cartes prism...
C'est bien dommage, car c'est un des seuls drivers a gérer le mode Master (AP) en 802.11g (madwifi le propose aussi, mais aucune carte que j'ai vu ne supporte le bitrate 54Mb/s en master...). Elle s'interface bien en plus avec HostAP (depuis un patch assez récent).
La liste citée dans le post précédent est totalement obsolète et il ne faut pas s'y fier.
Un lien a priori plus fiable serait le suivant: http://users.linpro.no/janl/hardware/wifi.html(...)
Désolé de faire un peu de hors sujet par rapport à la news, mais comme ca parle de prism54... ;)
En ce qui concerne prism54, j'en ai fait les frais dernièrement. Par contre, d'une révision à l'autre, la puce à l'intérieur est toujours un prism. Ce qui a changé sur a peu près toutes les cartes normalement reconnues par prism54, c'est la manière de charger le firmware qui est passé récemment à un mécanisme dit softmac, qui n'est bien entendu pas supporté (encore) par le driver prism54.
Attention donc, il ne faut pas se fier au tableau fourni sur le site du driver. Les SMC, 3com, Netgear qui sont marquées comme fonctionnant bien, ne fonctionnent plus, et la seule façon de distinguer quelle carte marche est de regarder le numéro de révision inscrit sur la carte elle-même... Seul Netgear a pris le soin d'estampiller sa carte WG511v2. D'après les mailing list, le support softmac n'est pas une priorité... Dommage.
Le kernel que j'utilise est un kernel vanilla (2.6.7) sur lequel j'ai rajouté le patch -epia. Globalement, ce patch n'apporte aucune optimisation spécifique en terme de performances, mais plutot un support amélioré (et opensource !) des différents périphériques embarqués sur l'epia.
Tu peux le trouver assez facilement sur http://www.epiawiki.org.(...)
Entre autres, ca apporte:
- Support du framebuffer via: assez bizzare, j'ai reussi à le faire marcher uniquement sur un kernel 2.4... Il semblerait qu'il y ait quelque chose de cassé... Celui embarqué dans ce patch fournit en théorie un embryon d'accélération 2D pour le framebuffer contrairement au driver fournit par via, mais honnetement j'ai vu aucune différence... Ca fournit aussi dans le même domaine le helper spécifique au CLE266 pour directfb.
- Driver DRI pour via: il est possible que ce driver marche pour l'eden aussi. C'est quoi exactement la dénomination du controleur graphique de l'epia ? Si c'est le cyberblade trident, il y a deja un driver DRI qui traine quelque part il me semble, et il y a aussi un driver vidix (ca j'en suis a peu pres sur).
+ Quelques autres bricoles supplémentaires.
Pour le kernel, j'ai mis la cible c3-2 (nehemiah), qui est de toute facon un alias pour i686 pour gcc, donc je doute que ca apporte grand chose au niveau optimisation. Il faut cependant bien voir que l'eden est plus proche au niveau structure d'un 586 voire 486 que d'un processeur i686 (notamment une compilation en i686 entrainera des erreurs un peu bizarres du fait de l'absence d'instructions spécifiques, et notamment l'instruction CMOD). Sur epiawiki tu trouveras les paramètres de compil les plus adaptés pour ton eden, je pense...
Pour Mplayer, je pense qu'il vaut mieux le laisser faire sa sauce tout seul, vu qu'il détecte le processeur lors de la phase de compil (par contre ca peut clairement être une bonne idée d'utiliser une version recompilée dans ton cas qu'une version binaire, les quelques % de gain en terme de perf valent bcp plus sur une epia qu'une machine classique ;)).
Pour la lecture avec mplayer, je pense que ce qui a été dit plus haut résume bien ce qui est le plus efficace: utiliser vidix si ca marche, puis xv, en modulant avec des -framedrop ou -hardframedrop si c'est encore trop juste.
J'ai pas essayé le réencodage avec cette machine, ca prendrait une éternité (fréquence d'horloge pas très haute, cache processeur très faible (64ko)). La meilleure solution que j'ai trouvé, c'est encore d'utiliser mon bon vieux (sic...) Athlon 1.4 pour faire ca... A priori si tu réencodes en xvid, sans trop forcer sur le bitrate, tu dois obtenir une vidéo de bonne qualité que tu pourras lire sans trop de souci avec ton epia. J'ai été assez agréablement surpris par l'efficacité du codec, que ce soit par la qualité d'encodage/décodage, que par l'utilisation cpu lors de la lecture.
Ne t'inquiètes pas, tu n'es pas le seul à passer des nuits et des week-ends à tenter d'optimiser la bête ;)
Ce texte est trompeur. D'une part, VeXP ne tire partie que du CLE266 et du tout récent CN400 de Via. Ce que ce texte ne dit pas, c'est à quoi cette accélération s'applique.
En ce qui concerne le MPEG2, les deux chipsets ont un début d'accélération MPEG2 (uniquement la phase de compensation de mouvement) et les gains sur mon EPIA sont plutot de l'ordre 20-30% (grosso modo). Pour ceux que ca intéresse, il y a dans le cvs de Xorg un support du xmvc via et aussi un plugin mplayer sur le site du projet unichrome ( http://unichrome.sf.net(...) ) .
En ce qui concerne le MPEG4, seul le CN400 est accéléré. Il n'y aura aucun gain sur les autres chipsets.
En ce qui concerne le vidix, il y a un début de support du chipset VIA dans le cvs de mplayer (malheureusement je pense que ca ne concerne à nouveau que le CLE266). Ce driver ne marche pas terrible encore (pas du tout en fait chez moi...).
Pour la différence de perf entre framebuffer et X, je n'ai pas vu de différence notable (même en utilisant directFB). Xv est à mon avis la meilleure solution pour l'instant.
Avec une epia MII-10000 avec 256Mo de RAM, j'arrive à lire les DVDs sans le moindre problème à environ 50% d'utilisation CPU (sans l'accélération) , des fichiers Xvid de très bonne qualité à une utilisation CPU qui varie entre 20 et 60%. La machine commence à être "limite" pour les wmv9 (qui n'est pas vraiment connu pour être un codec vraiment économe au niveau proc...). En -vo null et -nosound, le cpu ne suit pas sur certaines scenes tres rapides.
Pour avoir une idée de ce que ca peut donner sur un eden, il faut avoir en tête la différence de fréquence entre les deux, mais aussi les différences d'architecture (pas de gestion de SSE, FPU cadencé à la moitié de la vitesse d'horloge, etc.).
Pour le firewall, il y a une autre solution, mais je sais pas si ca convient exactement à ce que tu cherches: http://www.nufw.org/(...)
Ca avait fait l'objet d'une dépêche sur DLFP il y a quelques temps et ca a le mérite de très bien s'interfacer avec ldap.
# Vis à vis de la concurrence
Posté par sk . En réponse au journal RedHat Directory Server. Évalué à 1.
Cependant, RedHat ne joue pas encore dans la même cours que SUN et Novell (je sais j'exclue AD là, mais j'ai encore du mal à le considérer comme un annuaire généraliste). SUN One a plus grand chose à voir avec iPlanet maintenant (il y a plein de fonctionnalités en plus, notamment de méta-annuaire).
Je pense cependant que RedHat va tenter de s'aligner et fournir en opensource les services de meta-annuaire qui vont bien. Je pense que c'est surtout sur çà que se démarquent les différents annuaires actuels.
Il reste donc pas mal de boulot encore pour RedHat, mais ca reste malgré tout une petite révolution. La route a beau être encore longue, la pente est douce :)
[^] # Re: samba ?
Posté par sk . En réponse au journal Sortie imminente de Red Hat Directory Services. Évalué à 2.
J'avais réussi à faire un truc similaire avec PAM/pam_ldap, nss_ldap et eDirectory, sans trop faire couler de sueur, et je sais que c'est dors et déjà possible sur des serveurs iPlanet.
[^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat
Posté par sk . En réponse au journal Sortie imminente de Red Hat Directory Services. Évalué à 1.
Sur un nombre d'objets raisonnable, OpenLDAP est certainement imbattable au niveau performance. Là où la différence se fait sentir, c'est sur de grandes quantité de données et quand on a besoin d'autres choses que de la performance ;)
Il y a des infos intéressantes sur le pourquoi du comment du rachat de Directory Services par Red Hat sur le blog de Chris Blizzard (dev de chez Red Hat et membre de la Mozilla Foundation):
http://www.0xdeadbeef.com/html/2005/01/(...)
[^] # Re: linksys
Posté par sk . En réponse au journal Firewall indépendant. Évalué à 1.
Donc soit tu as peu de temps à tuer et tu mets à jour le firmware avec un firmware HyperWRT, qui te gardera les fonctionnalités originelles du WRT54G ainsi que des fonctionnalités en plus ET un shell sur la machine (si tu veux rajouter des règles iptables a la mimine).
Soit tu as bcp de temps à tuer et tu installes OpenWRT qui te donnera un linux minimaliste sur lequel tu pourras rajouter les fonctionnalités que tu veux.
En ce qui concerne H323, il y a (avait ?) un conntrack spécifique dans netfilter. Sinon, tu as Upnp (qui est en l'occurence utilisé par Linksys pour faire ca sur le WRT).
Franchement, pour le prix d'un joujou comme ca (dans les 70¤), ca serait dommage de se priver :)
[^] # Re: troll ...
Posté par sk . En réponse au journal Bug dans le TCP/IP de Windows Server 2003. Évalué à 2.
Après, on se doute bien que Microsoft n'a pas récupéré la partie TCP/IP sur VMS qui était prévu à l'origine pour fonctionner sur DECnet (même si une pile TCP/IP a été rajoutée depuis).
Pour les curieux:
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=4494(...)
--
SK
[^] # Re: la roue?
Posté par sk . En réponse au journal Partition auto. Évalué à 2.
Doc (officielle ?) d'Autoyast:
http://www.suse.de/~nashif/autoinstall/9.1/html/(...)
[^] # Re: C'est normal
Posté par sk . En réponse au journal User root de apache : une faille ?. Évalué à 1.
Perso, je reste plutôt partisan de la solution du vserver (c'est simple à mettre en place et ca ouvre pas mal de possibilités au niveau administration).
J'en profite pour lancer une question qui me taraude depuis pas mal de temps. Je sais bien que ports <1024 ne peuvent être ouverts qu'avec les privilèges root, afin déviter que n'importe quel utilisateur puisse lancer les services standards. Cependant, l'impact d'une compromission sur ces services là a des effets plutôt moches (même si maintenant la plupart sont capables d'abandonner les capacités de l'utilisateur root une fois qu'ils se sont initialisés). Pourquoi cette limitation perdure-t-elle ? Est-ce pour une question de conformité POSIX ?
[^] # Re: LDAP, etc.
Posté par sk . En réponse au journal Solution TSE, annuaire et autres (Trademarks inside). Évalué à 2.
C'etait effectivement le cas. Quand redhat a repris le code, celui-ci n'avait pas bougé depuis decembre 2003, ca fait pratiquement un an de totale inactivité...
D'ailleurs, lorsque le code de netscape avait mis en opensource, il manquait toute la partie interfaçage LDAP, que le projet Mozilla a depuis refait si je ne m'abuse
Beaucoup d'entreprises tournent encore avec le serveur de Netscape, avec des bases d'utilisateurs non négligeables. Il est assez fréquent de voir des annuaires Netscape gérer des centaines de milliers de comptes sans broncher. De plus, ce serveur se mariait très bien avec le pendant web de iPlanet, quand il s'agissait de faire des portails web, avec gestions de pages blanches utilisateurs (il arrive souvent de voir des sites avec comme favicon l'icone de Netscape... je l'ai vu il y a pas longtemps quelque part sur le site de France Telecom par exemple)
Un autre point intéressant est la gestion de PKI facilitée qu'offre ce serveur. J'ai pas vraiment d'idée des fonctionnalités qu'elle offre exactement, mais je suppose que ca doit être quelque chose de comparable aux fonctionnalités qu'offre eDirectory en la matière. Sur OpenLDAP, c'est au mieux une couche qui vient se rajouter par dessus (OpenCA par ex, ou IDX-PKI). Ca permettrait d'avoir une gestion de certificat native dans l'annuaire et surtout qui sera aisée à interfacer avec Mozilla ou Thunderbird.
Tout ca pour dire que je suis bien excité par la potentielle mise en opensource d'un produit comme ca, quand en plus il y a une boîte comme RedHat derrière pour guider le navire :)
[^] # Re: LDAP, etc.
Posté par sk . En réponse au journal Solution TSE, annuaire et autres (Trademarks inside). Évalué à 5.
Pour info, sunONE (annuaire de sun) et Netscape Directory Server sont tous deux dérivés du projet iPlanet. Redhat a racheté récemment à AOL les sources de Netscape Directory Server qu'ils avaient récupéré lors du rachat de Netscape.
Je te conseille donc de jeter un petit coup d'oeil à cette news:
http://linuxfr.org/2004/10/01/17329.html(...)
Il faut cependant bien voir que depuis la séparation de sunONE, Sun a fait énormément de travail dessus et l'annuaire n'a plus grand chose à voir avec iPlanet.
# LDAP, etc.
Posté par sk . En réponse au journal Solution TSE, annuaire et autres (Trademarks inside). Évalué à 3.
eDirectory est un très bon annuaire (son principal défaut étant vraisemblablement de ne pas être opensource). C'est historiquement un annuaire X.500 avec une couche de compatibilité LDAP par dessus (on voit toujours apparaître les dénominations du schéma Novell: User au lieu de inetOrgPerson, etc.) Par contre, le connecteur LDAP lui est totalement conforme à la norme (tu peux créer des utilisateurs inetOrgPerson et l'annuaire se charge de tout mettre en forme).
eDirectory est relativement léger (il reste cependant plus lourd que OpenLDAP), assez robuste et monte en charge largement mieux que OpenLDAP.
Sa vraie puissance se situe surtout au niveau des mécanismes de réplication, qui sont autrement plus poussés que ceux actuellement disponibles sur OpenLDAP, et sur les outils fournis pour mettre en place un méta-annuaire (connecteurs pour différentes sources de données: fichiers textes, AD, Notes, etc., que l'on configure via des fichiers xml et des feuilles de style XSLT). C'est très élégant, mais aussi très cher (je crois que c'est de l'ordre de 4 euros par utilisateur...).
J'espère sincèrement que l'on pourra avoir des outils de ce style en opensource, et particulièrement que Redhat mette le code d'iPlanet en opensource rapidement
[^] # Re: vhost
Posté par sk . En réponse au journal Sortie de Exim 4.50. Évalué à 1.
[^] # Re: J'ose espérer que tu rigoles
Posté par sk . En réponse au journal Sortie de Exim 4.50. Évalué à 3.
Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable. Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.
Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur... Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...
Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
De plus, pour avoir eu à réparer assez ponctuellement des serveurs mails totalement freezés, parce que amavis partait en vrille à 100% du proc pour une raison inconnue, si je peux me passer d'amavis, c'est aussi bien.
Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches. La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.
Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.
[^] # Re: vhost
Posté par sk . En réponse au journal Sortie de Exim 4.50. Évalué à 2.
Exim est utilisé par des hébergeurs comme Lost-Oasis pour faire la gestion des mails des différents domaines qu'ils hébergent.
[^] # Re: houla !
Posté par sk . En réponse au journal Nemerle. Évalué à -2.
# Gaoland.net
Posté par sk . En réponse au journal Des mauvais usages des nouvelles technologies.... Évalué à 10.
Un whois par exemple permet d'apprendre que c'est rattaché à LDCOM (donc à Neuf Telecom...). Que ca prenne 2% du volume du site me choque un peu moins du coup.
# Juste une remarque
Posté par sk . En réponse au journal Des CD Ubuntu au CNAM de Nantes. Évalué à 3.
Juste une remarque cependant concernant les documentations que vous fournissez (et notamment ubuntu-pratique.pdf): c'est un avis tout à fait personnel, mais quand je lis une documentation remplie de fautes d'orthographe, je ne vois que ça... et ça ne me rassure pas pour la suite. Vous devriez peut-être faire une seconde lecture.
En vrac ce que j'ai noté:
première partie: manque un s à disque
deuxième partie: CD-ROM
Si après quelques secondes...: la phrase est grammaticalement incorrecte, il faudrait mettre une ,
apparaît s'écrit avec deux p
Passage alternatif de l'infinitif à la deuxième personne du pluriel (il vaudrait mieux utiliser tout le temps cette deuxième forme)
d'autres options sont disponibleS
après quelqueS secondeS
souhaiteZ
Dernière phrase: Utilisez, jetez
Hope this helps...
[^] # Re: LDLC est quand même un revendeur très correct
Posté par sk . En réponse au journal LDLC et leur migration .... Évalué à 9.
Cette phrase vient de me faire dire NON à la drogue :)
# Il faut voir aussi la tête du mail en question
Posté par sk . En réponse au journal Solution quoi ?. Évalué à 4.
From: "challenge8" <ch8@club-internet.fr>
Subject: Votre e-BADGE d'accès au salon et aux conférences gratuites Solutions LINUX
X-Mailer: Microsoft CDO for Windows 2000
X-DSPAM-Result: Spam
L'url dans le corps du message pour télécharger le badge est un truc ressemblant à:
http://212.37.219.20/linux/server_ebadge.asp?blabla(...)
Franchement, quand je vois ça, la première chose à laquelle je pense est "phishing", et honnêtement j'espère sincèrement que ca en est... Niveau sérieux et crédibilité pour un salon qui se veut professionnel, je crois qu'il va falloir repasser... (même si je sais bien que la gestion des badges n'est pas gérée directement par l'organisation du salon, mais par une boite externe, infopromotions il me semble)
[^] # Re: NdisWrapper ?
Posté par sk . En réponse au journal Experience: quel carte wireless pour Linux. Évalué à 1.
Sur l'autre machine, ca marche tout simplement pas (impossible d'activer l'interface...).
Les fonctionnalités du driver sont de plus assez limitées sous linux (évidemment ca doit largement suffir si c'est juste pour la faire fonctionner en mode infrastructure)
[^] # Re: Site du driver Prism
Posté par sk . En réponse au journal Experience: quel carte wireless pour Linux. Évalué à 6.
http://linuxfr.org/comments/515546.html#515546(...)
Aucune carte que tu peux trouver dans le commerce et ayant une puce prism ne marche à l'heure actuelle. Peut-être que sur eBay tu trouveras des "anciennes" cartes prism...
C'est bien dommage, car c'est un des seuls drivers a gérer le mode Master (AP) en 802.11g (madwifi le propose aussi, mais aucune carte que j'ai vu ne supporte le bitrate 54Mb/s en master...). Elle s'interface bien en plus avec HostAP (depuis un patch assez récent).
La liste citée dans le post précédent est totalement obsolète et il ne faut pas s'y fier.
Un lien a priori plus fiable serait le suivant:
http://users.linpro.no/janl/hardware/wifi.html(...)
[^] # Re: parfait
Posté par sk . En réponse à la dépêche Du Wifi exemplaire pour Linux : Ralink. Évalué à 4.
En ce qui concerne prism54, j'en ai fait les frais dernièrement. Par contre, d'une révision à l'autre, la puce à l'intérieur est toujours un prism. Ce qui a changé sur a peu près toutes les cartes normalement reconnues par prism54, c'est la manière de charger le firmware qui est passé récemment à un mécanisme dit softmac, qui n'est bien entendu pas supporté (encore) par le driver prism54.
Attention donc, il ne faut pas se fier au tableau fourni sur le site du driver. Les SMC, 3com, Netgear qui sont marquées comme fonctionnant bien, ne fonctionnent plus, et la seule façon de distinguer quelle carte marche est de regarder le numéro de révision inscrit sur la carte elle-même... Seul Netgear a pris le soin d'estampiller sa carte WG511v2. D'après les mailing list, le support softmac n'est pas une priorité... Dommage.
[^] # Re: Freebx et GPL
Posté par sk . En réponse au journal CeCILL : l'utilisation réseau est une distribution. Évalué à 1.
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/0534.html(...)
[^] # Re: Et pourquoi pas xine ?
Posté par sk . En réponse au journal Divx sous config Restreinte. Évalué à 1.
Tu peux le trouver assez facilement sur http://www.epiawiki.org.(...)
Entre autres, ca apporte:
- Support du framebuffer via: assez bizzare, j'ai reussi à le faire marcher uniquement sur un kernel 2.4... Il semblerait qu'il y ait quelque chose de cassé... Celui embarqué dans ce patch fournit en théorie un embryon d'accélération 2D pour le framebuffer contrairement au driver fournit par via, mais honnetement j'ai vu aucune différence... Ca fournit aussi dans le même domaine le helper spécifique au CLE266 pour directfb.
- Driver DRI pour via: il est possible que ce driver marche pour l'eden aussi. C'est quoi exactement la dénomination du controleur graphique de l'epia ? Si c'est le cyberblade trident, il y a deja un driver DRI qui traine quelque part il me semble, et il y a aussi un driver vidix (ca j'en suis a peu pres sur).
+ Quelques autres bricoles supplémentaires.
Pour le kernel, j'ai mis la cible c3-2 (nehemiah), qui est de toute facon un alias pour i686 pour gcc, donc je doute que ca apporte grand chose au niveau optimisation. Il faut cependant bien voir que l'eden est plus proche au niveau structure d'un 586 voire 486 que d'un processeur i686 (notamment une compilation en i686 entrainera des erreurs un peu bizarres du fait de l'absence d'instructions spécifiques, et notamment l'instruction CMOD). Sur epiawiki tu trouveras les paramètres de compil les plus adaptés pour ton eden, je pense...
Pour Mplayer, je pense qu'il vaut mieux le laisser faire sa sauce tout seul, vu qu'il détecte le processeur lors de la phase de compil (par contre ca peut clairement être une bonne idée d'utiliser une version recompilée dans ton cas qu'une version binaire, les quelques % de gain en terme de perf valent bcp plus sur une epia qu'une machine classique ;)).
Pour la lecture avec mplayer, je pense que ce qui a été dit plus haut résume bien ce qui est le plus efficace: utiliser vidix si ca marche, puis xv, en modulant avec des -framedrop ou -hardframedrop si c'est encore trop juste.
J'ai pas essayé le réencodage avec cette machine, ca prendrait une éternité (fréquence d'horloge pas très haute, cache processeur très faible (64ko)). La meilleure solution que j'ai trouvé, c'est encore d'utiliser mon bon vieux (sic...) Athlon 1.4 pour faire ca... A priori si tu réencodes en xvid, sans trop forcer sur le bitrate, tu dois obtenir une vidéo de bonne qualité que tu pourras lire sans trop de souci avec ton epia. J'ai été assez agréablement surpris par l'efficacité du codec, que ce soit par la qualité d'encodage/décodage, que par l'utilisation cpu lors de la lecture.
Ne t'inquiètes pas, tu n'es pas le seul à passer des nuits et des week-ends à tenter d'optimiser la bête ;)
[^] # Re: Et pourquoi pas xine ?
Posté par sk . En réponse au journal Divx sous config Restreinte. Évalué à 3.
Ce texte est trompeur. D'une part, VeXP ne tire partie que du CLE266 et du tout récent CN400 de Via. Ce que ce texte ne dit pas, c'est à quoi cette accélération s'applique.
En ce qui concerne le MPEG2, les deux chipsets ont un début d'accélération MPEG2 (uniquement la phase de compensation de mouvement) et les gains sur mon EPIA sont plutot de l'ordre 20-30% (grosso modo). Pour ceux que ca intéresse, il y a dans le cvs de Xorg un support du xmvc via et aussi un plugin mplayer sur le site du projet unichrome ( http://unichrome.sf.net(...) ) .
En ce qui concerne le MPEG4, seul le CN400 est accéléré. Il n'y aura aucun gain sur les autres chipsets.
En ce qui concerne le vidix, il y a un début de support du chipset VIA dans le cvs de mplayer (malheureusement je pense que ca ne concerne à nouveau que le CLE266). Ce driver ne marche pas terrible encore (pas du tout en fait chez moi...).
Pour la différence de perf entre framebuffer et X, je n'ai pas vu de différence notable (même en utilisant directFB). Xv est à mon avis la meilleure solution pour l'instant.
Avec une epia MII-10000 avec 256Mo de RAM, j'arrive à lire les DVDs sans le moindre problème à environ 50% d'utilisation CPU (sans l'accélération) , des fichiers Xvid de très bonne qualité à une utilisation CPU qui varie entre 20 et 60%. La machine commence à être "limite" pour les wmv9 (qui n'est pas vraiment connu pour être un codec vraiment économe au niveau proc...). En -vo null et -nosound, le cpu ne suit pas sur certaines scenes tres rapides.
Pour avoir une idée de ce que ca peut donner sur un eden, il faut avoir en tête la différence de fréquence entre les deux, mais aussi les différences d'architecture (pas de gestion de SSE, FPU cadencé à la moitié de la vitesse d'horloge, etc.).
[^] # Re: LDAP c'est bon mangez-en
Posté par sk . En réponse au journal LDAP, c bien ?. Évalué à 1.
http://www.newwave.net/~masneyb/(...)
et pour Bind 9:
http://www.venaas.no/ldap/bind-sdb/(...)
Pour le firewall, il y a une autre solution, mais je sais pas si ca convient exactement à ce que tu cherches:
http://www.nufw.org/(...)
Ca avait fait l'objet d'une dépêche sur DLFP il y a quelques temps et ca a le mérite de très bien s'interfacer avec ldap.