Loupé, ca sert aussi dans les transmissions (matrices utilisées dans les codes correcteurs). Ca doit aussi servir en crypto (notion de distance).
En fait, des matrices, y'en a vraiment partout, et pas seulement en infographie pour faire des rotations...
Comme quoi, on ne nous bourre pas le crane qu'avec des conneries en prepa, ou en deug...
A mon tour de faire de la pub pour l'ESIL. Bon, tout d'abord, pour situer les choses, je suis sorti de l'ESIL en 2001, et je suis prestataire pour une SSII, actuellement en poste chez Equant (groupe France Telecom) à Rennes. Mon boulot, c'est concevoir les réseaux d'hébergement pour les clients Equant/Transpac (c'est essentiellement du LAN, avec des contraintes de disponibilité et de sécurité). Avant l'ESIL, je n'avais pas de réelle formation en informatique puisque je sortais de Prépa PSI.
Le gros avantage de l'ESIL, c'est que c'est une école généraliste dans l'informatique. On y aborde une grande partie de l'informatique, au sens large : théorie des systèmes d'exploitation, réseaux, langages (Pascal, C, C++, Java, mais aussi Scheme [programmation fonctionnelle], Prolog [inventé à deux pas de l'ESIL], assembleur...), électronique, théorie du signal, théorie des codes, cryptographie, bases de données, systèmes & programmation distribuées, infographie, droit informatique... Bref, y'a de quoi faire, et cela permet de se faire une bonne idée du paysage informatique dans son ensemble.
A côté de cela, comme Olivier l'a dit, y'a Elingsys, un sympathique groupe de geeks. Pour ceux qui s'y investissent, c'est un moyen d'apprendre pas mal de trucs pratiques relatifs à l'administration système (ça a été mon cas). Le but d'Elingsys est également de filer un coup de main aux élèves : installations d'outils sur les serveurs de l'Ecole, installation de bécanes d'élèves sous Linux, résolution de problèmes d'OS ou de matériel...
A la sortie de l'ESIL, je n'ai eu aucune difficulté à trouver du travail (c'est vrai que la conjoncture, au printemps 2001, était plus que favorable : on pouvait se permettre de choisir dans quelle entreprise et dans quelle région on voulait bosser !). Avec le recul, je ne regrette vraiment pas d'être entré dans cette Ecole "peu connue" à l'époque (en 1998).
De façon générale, je pense que les "petites" Grandes Ecoles on bien des avantages pour compenser leur manque de notoriété : d'abord, les diplomés sont polyvalents (à l'opposé d'ecoles spécialisées dans les telecoms par exemple), tout en ayant une forte compétence dans l'informatique (à l'opposé d'ecoles généralistes comme Centrale, par exemple).
Enfin, il est plus facile d'entrer dans ces "petites" Ecoles qu'à Centrale, aux Mines ou à Sup Info...
Et puis souvenez-vous d'une choses : si une Ecole est reconnue par la Commission des Titres d'Ingénieurs, c'est une bonne Ecole.
... mais seulement une sur les deux. Eh oui, il y a deux formes de NAT !
> repete apres moi: LE NAT N'EST QU'UNE VICIEUSE RUSTINE FAITE POUR PAS QUE ON N'AIE PLUS D'ESPACE D'ADDRESSAGE..
Ah là là... y'a des idées qui ont la vie dure, quand même, hein... Commençons par le début : le NAT, (Network Address Translation) est une technique qui permet de traduire (et pas de translater) des adresses IP d'un plan d'adressage vers un autre. Voilà pour l'idée générale. Mais il y a plusieurs façons de le mettre en place : le NAT "Hide" et le NAT "1:1" (un pour un).
Le NAT hide, c'est ce qui permet de masquer un plan d'adressage (privé, par exemple, de type RFC 1918) derrière une (ou plusieurs) adresses, en jouant sur les ports TCP et UDP source. Là, je suis d'accord : le Nat "hide" disparaitra avec IPv6.
Le NAT 1:1, c'est une technique encore plus simple qui permet de faire apparaitre virtuellement une machine sur un réseau, alors que cette machine appartient en réalité à un autre réseau. Le firewall ou le routeur qui effectue le NAT prend à sa charge ces adresses virtuelles, modifie l'adresse IP dans le paquet (sans toucher au port TCP ou UDP) et route ce paquet vers le réseau designé par la nouvelle adresse. C'est utile, par exemple, lors de migrations de machines (comme un serveur DNS interne), le temps de mettre à jour tous les postes clients avec la nouvelle adresse du serveur DNS. Cela dure parfois des semaines, voire même des mois si il y a beaucoup de clients, et cela peut même être définitif si la machine qui se sert du serveur DNS est administrée par une personne indépendante (le propriétaire de la machine chez un hébergeur, par exemple). Ainsi, le serveur reste joignable avec son ancienne adresse, même si ce n'est plus son adresse réelle.
Il est clair que ce deuxième usage ne disparaitra pas avec IPv6.
Hummm... Ca ne vous est jamais arrivé de vouloir installer une appli qui demande à installer pas mal de dépendances, et en particulier à upgrader la GLIBC ? Personnellement, j'ai rencontré le problème sur Mandrake 5.3 et sur Redhat 6.<je_sais_pu_combien>...
Moralité : je me suis tourné vers Debian et apt-get... Oui, c'est vrai, dans la branche unstable, les upgrades sont souvent lourdes, mais au moins, je n'ai jamais eu de problème alors que cela fait deux ans que ma Debian est installée...
Par contre, c'est vrai que c'est parfois un peu lourd. Je fais un update/upgrade une fois par mois, et je suis obligé de récupérer pas loin d'une centaine de megas à chaque fois... En plus, je me connecte par modem RTC, ça prend pas loin de 8 ou 9 heures pour tout télécharger... Heureusement pour moi, j'ai un gros forfait (30 heures/mois) donc ça peut aller. Je lance l'update le matin (dans une session screen), avant de partir au boulot, et je me connecte en SSH (merci le DNS Dynamique) pour récupérer ma session screen et voir où ça en est...
<pub>
Pour ceux qui l'auraient oublié, FreeTelecom (http://www.freetelecom.com/sommaire.html(...)) propose un forfait 50 heures pour 15 euros par mois, communications incluses... A bon entendeur...
</pub>
Après nous avoir concocté le serveur FTP le plus troué de l'histoire (http://www.wu-ftpd.org/(...)), célèbre pour ses failles dans quasiment toutes les versions (2.4, 2.5, 2.6...), les développeurs de l'université Washingtown reviennent en force avec un buffer overflow dans leur serveur IMAP.
Il y a deux ans, après les nombreuses alertes concernant les versions successives de WU-FTPd, j'avais bani ce serveur et depuis, je ne jure plus que par ProFTPd (<pub>ProFTPd est génial !!!</pub>).
Va-t-il falloir en faire autant avec leur serveur IMAP ? Et pour Pine ? Eh oui, Pine est aussi un produit "WU"... mais bon, c'est seulement un client, pas un serveur (ouf !).
Pfff... Je sais bien que développer un serveur, c'est pas simple. Mais il existe des méthodes pour produire du code sûr : vérifier tous les codes de retour, les allocations mémoire, traiter les erreurs correctement... Oui, je sais, ça alourdit _énormément_ le code et en plus, ça suppose que le programme ait été conçu dès le début en respectant ces rêgles. Mais c'est faisable. De plus, puisque les machines sont de plus en plus rapides, on peut se permettre d'alourdir le code avec une floppée de tests dans tous les sens. En plus, dans le cas d'un serveur, c'est bien souvent le réseau qui ralentit tout.
il faudrait développer une alternative a l'architecture NetBIOS/SMB/DC/Active Directory etc...
Sous Unix, on peut remplacer SMB par NFS, DC et Active Directory par LDAP. Sous Linux, les modules PAM sont là pour cela, NFS est dans le kernel et LDAP sert à tout centraliser. Certes, ce sont des composants séparés, mais c'est déjà ça.
Bref, ces afficheurs se democratisent au niveau de leurs tarifs et pour peu que votre machine serve exclusivement de serveur, cela vous permettra de vous passer d'ecran de contrôle...
Pour un serveur (sans écran bien sur), l'idéal reste encore le port console relié à un serveur de terminaux genre Annex ou Xcell. Avec ça, tu accèdes à la console, tu fais ce que tu veux comme dans un Xterm, même si la conf réseau du serveur est HS.
Et en plus, tu n'as même pas besoin de rester près du serveur pour lire les infos...
Mais c'est vrai que pour un particulier, ça peut être pratique.
L'idéal serait d'avoir une compatibilité avec les anciens fichiers de conf, si possible (au moins pour les parties les plus lourdes : VirtualHost et Directory). Les autres parties (qui sont en fait la config de base) ne sont pas forcément très complexes à mettre à jour je pense. Mais pour un site professionnel (pour un hébergeur, au hasard), les parties "répétitives" devront clairement être compatibles.
_ CacheNegotiatedDocs remplacée par CacheNegotiatedDocs on|off
_ ErrorDocument 403 "Some Message remplacé par ErrorDocument 403 "Some Message"
_ AccessConfig et ResourceConfig à remplacer par Include
_ BindAddress à remplacer par Listen
_ <ServerType> n'existe plus
Pour ces modifs, il suffit d'un simple grep ou sed sur les fichiers de conf et d'une petite modif de syntaxe dans les outils de création de fichiers de conf. Rien de grave de ce côté, donc.
Plus gênant :
_ ExtendedStatus n'existe plus. Dommage, certains hébergeurs s'en servent pour superviser leurs serveurs Web :o( L'air de rien, ça a un gros impact. En plus, la doc (http://httpd.apache.org/docs-2.0/mod/mod_status.html(...)) n'a pas été remise à jour... Là ça bloque !
_ mod_log_agent et mod_log_referer sont remplacés par CustomLog. Esperons que résultat final puisse être identique afin de ne pas troubler les outils de stats déjà utilisés avec Apache 1.3 (souvent développés à la main par les hébergeurs).
Ces deux dernières modifs risquent de retarder pas mal le déploiement d'Apache 2.0 chez les hébergeurs, et à mon avis, les stats NetCraft ne vont pas être boulversés dès demain.
Ici, on dit que l'authentification de l'utilisateur permet d'ajouter des règles personnalisées pour cet utilisateur. Or, dans le Authentication-Gateway-HOWTO, on se contente d'ouvrir tous les flux possibles pour n'importe quel utilisateur authentifié... Nuance ! Si on regarde de près les sources de pam_iptables.c (http://www.itlab.musc.edu/~nathan/pam_iptables/pam_iptables.c(...)), aux alentours de la ligne 226, on remarque que la conf du firewall ne fait qu'ajouter cette règle :
Dommage, c'est quand même un peu léger, le "tout ou rien"... L'avantage d'authpf, c'est que chaque utilisateur peut disposer de ses propres règles, présentes dans $HOME/.authpf/authpf.rules. C'est là que ça devient intéressant !!!
Comme quoi, les deux projets ne sont pas comparables, et donc, je répète, à ma connaissance, il n'existe pas d'outil semblable sous Linux (bien que le Authentication-Gateway-HOWTO et pam_iptables donnent déjà de bonnes bases...).
Enfin un firewall qui permet de faire cela ! Pour l'instant, à ma connaissance, seul FW-1 de CheckPoint (avec son agent d'authentification) permettait cela. Le gros avantage, c'est que l'on peut baser des règles firewall non plus sur une machine et une adresse IP, mais sur un utilisateur... Très pratique quand un utilisateur se balade de machine en machine ou quand l'adresse de sa bécane change sans cesse (par exemple : connexion RTC).
Entre nous, c'est une fonction qui pourrait aussi être implémentée sous Linux avec IPChains ou IPTables. En plus, cela n'implique pas de développement au niveau du kernel, mais "seulement" au niveau utilisateur.
je ne sais pas si vous avez remarqué, mais certains utilisent le serveur prout.linux.fr.org pour accéder à LinuxFR (ça doit se traduire par un contournement du load-balancer ou quelque chose comme ça). J'en fais partie et il y a une bonne raison : je suis dans une boite dont le proxy n'accepte pas les hostnames qui ne disposent pas d'au moins trois parties séparées par un point. En gros, http://linuxfr.org(...) ne passe pas, et http://prout.linuxfr.org(...) passe. Je suis dans une très grosse boite et je n'ai aucun poids pour faire modifier le truc (j'ai d'ailleurs aussi le problème avec slashdot, mais là je n'ai pas encore trouvé la soluce).
Moralité : serait-il possible de mettre en place un alias genre "www.linuxfr.org" qui pointe sur linuxfr.org afin que nous disposions d'un accès "simplifié" et que, si prout tombe, nous ne nous en rendions pas compte ?
Je sais, ça n'a pas vraiment de rapport avec DaCode, mais bon, tant qu'on y est...
PS : je sais que je ne suis pas le seul à avoir le problème, car d'autres boites utilisent le proxy que nous avons (je taierai le nom du proxy en question). Alors faites quelque chose (par pitié pour prout) ;o)
Résumons: d'un côté, on a M$ qui fait un bench histoire de montrer qu'il peut s'attaquer au monstre sacré qu'est Oracle. Forcément, pour que ça tienne la route, M$ réécrit tout le soft en C#, l'optimise et compare avec un soft dont le seul but était de montrer une API (et certainement pas de faire un comparatif de perfs). En effet, Oracle avait codé son appli avec plein de lignes de codes qui exploitent au maximum l'API J2EE sans forcément pondre un algo optimisé, puisque ce n'était pas le but.
Forcément, M$ sort vainqueur (sinon ils n'auraient pas publié leur bench) et écrase littéralement Oracle.
Oracle, voyant cela, ne peut pas rester silencieux et décide de répondre. Oracle réécrit son appli en optimisant à fond le truc (là, c'est le but, même si Oracle n'avoue qu'avoir peu modifié le soft), en diminuant le nombre de lignes et les appels à l'API J2EE. Pour couronner le tout, Oracle fait tourner son appli sur le premier foudre de guerre qui lui tombe sous la main (en soulignant que ces bécanes sont les mêmes que pour le premier test, et qu'elles sont moins performantes que celles utilisées par M$) :
_ les clients sont systématiquement des biproc à 2x360 ou 2x450 MHz tournant sous solaris 6,7 ou 8 (certainement des UltraSparcs) avec 512 Mo ou 1 Go de RAM
_ Du coté de la base de données, on passe en solaris 8 et quadripro à 400 Mhz chacun (UltraSparc aussi, je pense).
M$ ne détaille pas l'architecture sur laquelle il teste son soft, mais je ne sais pas si cela tient la route face à un UltraSparc (quoique, avec les dernieres version de P4 à 2GHz, ça doit commencer à booster correctement).
Bref, tout ça pour dire que même si M$ a fait le gros méchant, Oracle a bien fait de le remettre en place en employant les mêmes méthodes !
... mais c'est un peu léger... On n'y parle que de zope, python, postgreSQL et deux ou trois autres trucs, mais ça reste assez anectodique... L'inconvénient, c'est que ça donne une vue extremement limitée du logiciel libre. J'ai bien peur que les lecteurs se disent "Quoi ? c'est que ça, le libre ? bah y'a encore des progrès à faire !" :o(
Des réponses ont également été reçues de diverses grandes organisations, d'autres associations industrielles et des professionnels de la propriété intellectuelle. Ainsi, même si les réponses dans cette catégorie ont été beaucoup moins nombreuses que celles en faveur de l'approche "libre", il semble évident que le poids économique mesuré par le nombre d'emplois concernés et l'importance des investissements nécessaires, fait pencher la balance en faveur de l'harmonisation au sens du document de consultation.
Moralité : c'est confirmé : le libre compte pour du beurre
Et les firewalls !!! En effet, une vieille bécane est l'idéal pour un firewall :
1) un firewall n'a pas besoin de grosses ressources CPU si les règles sont bien agencées
2) un firewall n'a pas besoin de faire tourner X11, donc pas besoin de bcp de RAM
3) les vieilles architectures du style SPARC sont très bien supportées par Linux et OpenBSD, y compris les cartes d'extension du genre QUADFAST (4 ports ethernet différenciés sur une seule carte), au moins sous Linux (je ne sais pas pour OpenBSD).
4) Enfin, l'argument massue en faveur des bécanes "propriétaires" : elles disposent très souvent d'un port "console" qui permet de prendre la main à distance sur l'équipement dès que la machine est sous tension, avant même qu'elle ait commencé à charger l'OS (sous SPARC, l'OpenFirmware est un vrai régal !). Je n'ai pas encore vu la même chose sur un PC.
non, et pour cause : d'ici, je ne peux pas lire slashdot, pour une sombre histoire de proxy HTTP qui refuse certaines requetes du style "http://slashdot.org"(...) ou "http://linuxfr.org",(...) parce qu'il n'y a pas de nom de host, juste un nom de domaine. La ruse, pour lire LinuxFr, c'est faire pointer le butineur sur une adresse avec host (au hasard, http://prout.linuxfr.org(...)).
Moralité : si tu peux poster l'info sur ./, vas-y.
Je voudrais exprimer de façon synthétique les raisons qui me conduisent à ne pas approuver la pétition Eurolinux, et à proposer une solution intermédiaire. La pétition Eurolinux s'oppose à l'usage des brevets dans le domaine des logiciels, et vise à imposer un modèle économique unique, le modèle dit " libre ".
Explications
Or, je soutiens que (a) le brevet constitue un instrument de régulation économique vertueux { car il est encadré par des règles claires et transparentes, car le brevet protège les efforts d'innovation, quel qu'en soit le bénéficiaire (grand ou petit)}.
Que le modèle libre (b) présentant d'indéniables succès, présente néanmoins des zones d'ombres qui excluent toute initiative autoritaire visant à l'imposer comme modèle unique."
C'est à peu près du même tonneau que le document Word ci dessus. Bonne lecture :o(
En effet, c'est très grave, et je pense que si cela se confirme, les médias doivent être alertés. Pour résumer, cela revient à dire que les USA, aux travers de leurs entreprises, se permettent de diriger la commission européenne.
L'AFUL peut-elle envoyer un communiqué officiel à ce sujet ?
Je suis en train de lire en diagonale le document, on y parle d'EuroLinux, de logiciel libre, et ils opposent à ces petits courants "libres" de grandes associations de "professionnels" (UNICE, EICTA,EITSA). Pour jeter le discrédit sur le logiciel libre, on ne peut pas faire plus odieux. Je cite :
"The individual responses were dominated by supporters of open source software, whose views ranged from wanting no patents for software at all to the "official" position of the Eurolinux Alliance which is to oppose patents for software running on general-purpose computers. On the other hand, submissions broadly in support of the approach of the consultation paper tended to come from regional or sectoral organisations representing large numbers of companies of all sizes, such as UNICE, the Union of Industrial and Employer's Confederations of Europe, EICTA, the European Information and Communications Technology Industry Association, and the European IT Services Association. There were also individual large organisations, other industry associations and IP professionals. Thus although the responses in this category were numerically much fewer that those supporting the open source approach, there seems little doubt that the balance of economic weight taking into account total jobs and investment involved is in favour of harmonisation along the lines suggested in the paper."
Je n'ai pas le temps de traduire, mais l'idée est là : "bien que les supporters du logiciel libre aient beaucoup fait parler d'eux, leur poids économique est négligeable, et donc leur opinion compte pour du beurre" (traduction libre).
Par ailleurs, cela me fait légèrement sourire que le fichier soit au format Word... Ils auraient pu le mettre en HTML ! Mais c'est vrai que le HTML, y'a des brevets dessus (les liens hypertexte par exemple). <troll> Mieux vaut encore publier un document dans un format propriétaire, c'est vrai ! </troll>
Pour le ssh, si il n'y a pas de texte paru il n'y a donc rien qui interdit, non ? je ne sais plus quelle est le niveau de cryptage utilise...
Justement, aucun texte ne révise la dernière législation qui plafonnait la taille des clefs à 128 bits. Or SSH utilise comme méthode de repli (si aucune autre méthode n'est dispo) un 3DES (donc 3*56 bits, ce qui est supérieur à 128 bits). Dommage, donc. C'est également la raison de l'existance en France de SSF...
J'allucine, là... D'une part c'est lourd, mais en plus, la niouze contient une phrase qui m'étonne (et c'est peu de le dire) :
Enfin, ce système est très difficile à sécuriser par un firewall.
Huuummmm... quelqu'un peut me dire dans quel contexte un flux NFS doit traverser un firewall ? La tendance actuelle est plutôt d'isoler ce genre de trafic sur un LAN dédié (un SAN ou quelquechose du genre...). En effet, NFS est très gourmand, et a une légère tendance à saturer les réseaux. Il faut dire que les fichiers que l'on transfère aujourd'hui n'ont plus grand chose à voir avec ce que l'on faisait au moment de la conception de NFS... Même si entre temps, on est passé de 10Mbps à 100Mbps...
PS : si un flux NFS doit passer un firewall, j'ose à peine imaginer la puissance de la machine qui fera office de firewall... Au fait, quelqu'un a déjà tenté de mettre un firewall Linux (ou BSD) entre deux LANs à 100Mbps et de faire passer un max de connexions avec des protos bizzares, des petits paquets et plein de cochonneries pour voir si la bécane arrive à suivre ?
[^] # Re: espace vectoriel
Posté par Ludovic Boisseau . En réponse à la dépêche Quelle formation d'informatique choisir ?. Évalué à 1.
[^] # Re: ESIL [l'avis d'un ancien élève]
Posté par Ludovic Boisseau . En réponse à la dépêche Quelle formation d'informatique choisir ?. Évalué à 1.
[^] # Non, le toutes les formes de NAT ne disparaitront pas avec l'IPv6...
Posté par Ludovic Boisseau . En réponse à la dépêche Performances IPv4 vs IPv6 pour le 2.4.17. Évalué à 2.
> repete apres moi: LE NAT N'EST QU'UNE VICIEUSE RUSTINE FAITE POUR PAS QUE ON N'AIE PLUS D'ESPACE D'ADDRESSAGE..
Ah là là... y'a des idées qui ont la vie dure, quand même, hein... Commençons par le début : le NAT, (Network Address Translation) est une technique qui permet de traduire (et pas de translater) des adresses IP d'un plan d'adressage vers un autre. Voilà pour l'idée générale. Mais il y a plusieurs façons de le mettre en place : le NAT "Hide" et le NAT "1:1" (un pour un).
Le NAT hide, c'est ce qui permet de masquer un plan d'adressage (privé, par exemple, de type RFC 1918) derrière une (ou plusieurs) adresses, en jouant sur les ports TCP et UDP source. Là, je suis d'accord : le Nat "hide" disparaitra avec IPv6.
Le NAT 1:1, c'est une technique encore plus simple qui permet de faire apparaitre virtuellement une machine sur un réseau, alors que cette machine appartient en réalité à un autre réseau. Le firewall ou le routeur qui effectue le NAT prend à sa charge ces adresses virtuelles, modifie l'adresse IP dans le paquet (sans toucher au port TCP ou UDP) et route ce paquet vers le réseau designé par la nouvelle adresse. C'est utile, par exemple, lors de migrations de machines (comme un serveur DNS interne), le temps de mettre à jour tous les postes clients avec la nouvelle adresse du serveur DNS. Cela dure parfois des semaines, voire même des mois si il y a beaucoup de clients, et cela peut même être définitif si la machine qui se sert du serveur DNS est administrée par une personne indépendante (le propriétaire de la machine chez un hébergeur, par exemple). Ainsi, le serveur reste joignable avec son ancienne adresse, même si ce n'est plus son adresse réelle.
Il est clair que ce deuxième usage ne disparaitra pas avec IPv6.
Voilà. Il fallait que cela soit dit.
[^] # Re: effectivement
Posté par Ludovic Boisseau . En réponse à la dépêche Le RPM est-il condamné?. Évalué à 2.
Moralité : je me suis tourné vers Debian et apt-get... Oui, c'est vrai, dans la branche unstable, les upgrades sont souvent lourdes, mais au moins, je n'ai jamais eu de problème alors que cela fait deux ans que ma Debian est installée...
Par contre, c'est vrai que c'est parfois un peu lourd. Je fais un update/upgrade une fois par mois, et je suis obligé de récupérer pas loin d'une centaine de megas à chaque fois... En plus, je me connecte par modem RTC, ça prend pas loin de 8 ou 9 heures pour tout télécharger... Heureusement pour moi, j'ai un gros forfait (30 heures/mois) donc ça peut aller. Je lance l'update le matin (dans une session screen), avant de partir au boulot, et je me connecte en SSH (merci le DNS Dynamique) pour récupérer ma session screen et voir où ça en est...
<pub>
Pour ceux qui l'auraient oublié, FreeTelecom (http://www.freetelecom.com/sommaire.html(...)) propose un forfait 50 heures pour 15 euros par mois, communications incluses... A bon entendeur...
</pub>
# Encore un WU-gruyere !
Posté par Ludovic Boisseau . En réponse à la dépêche wu-imapd. Évalué à 10.
Il y a deux ans, après les nombreuses alertes concernant les versions successives de WU-FTPd, j'avais bani ce serveur et depuis, je ne jure plus que par ProFTPd (<pub>ProFTPd est génial !!!</pub>).
Va-t-il falloir en faire autant avec leur serveur IMAP ? Et pour Pine ? Eh oui, Pine est aussi un produit "WU"... mais bon, c'est seulement un client, pas un serveur (ouf !).
Pfff... Je sais bien que développer un serveur, c'est pas simple. Mais il existe des méthodes pour produire du code sûr : vérifier tous les codes de retour, les allocations mémoire, traiter les erreurs correctement... Oui, je sais, ça alourdit _énormément_ le code et en plus, ça suppose que le programme ait été conçu dès le début en respectant ces rêgles. Mais c'est faisable. De plus, puisque les machines sont de plus en plus rapides, on peut se permettre d'alourdir le code avec une floppée de tests dans tous les sens. En plus, dans le cas d'un serveur, c'est bien souvent le réseau qui ralentit tout.
Alors, à quand des serveurs sécurisés ?
Pour mémoire, le HOWTO relatif à la programmation sécurisée : http://www.dwheeler.com/secure-programs/(...)
[^] # Re: Heu ?
Posté par Ludovic Boisseau . En réponse à la dépêche Contrôleur de domaine avec Samba. Évalué à 10.
Sous Unix, on peut remplacer SMB par NFS, DC et Active Directory par LDAP. Sous Linux, les modules PAM sont là pour cela, NFS est dans le kernel et LDAP sert à tout centraliser. Certes, ce sont des composants séparés, mais c'est déjà ça.
[^] # Re: sysctl : doc complète
Posté par Ludovic Boisseau . En réponse à la dépêche Bidouiller dans le /proc pour sécuriser son Linux. Évalué à 3.
Tous les parametres présents dans /proc/sys/net/ipv4/ y sont expliqués.
Mais je persiste à dire que l'utilisation du /proc est plus simple (pas de programme supplémentaire...)
# Oui, mais...
Posté par Ludovic Boisseau . En réponse à la dépêche Afficheur LCD sous Linux. Évalué à 10.
Pour un serveur (sans écran bien sur), l'idéal reste encore le port console relié à un serveur de terminaux genre Annex ou Xcell. Avec ça, tu accèdes à la console, tu fais ce que tu veux comme dans un Xterm, même si la conf réseau du serveur est HS.
Et en plus, tu n'as même pas besoin de rester près du serveur pour lire les infos...
Mais c'est vrai que pour un particulier, ça peut être pratique.
# Migration vers apache 2.0 pour un hébergeur
Posté par Ludovic Boisseau . En réponse à la dépêche Apache 2.0 disponible pour tous. Évalué à 10.
C'est d'ailleurs ce qui semble être le cas. La page "migrer vers Apache 2.0" (http://httpd.apache.org/docs-2.0/upgrading.html(...)) indique les modifs dans les fichiers de conf :
_ CacheNegotiatedDocs remplacée par CacheNegotiatedDocs on|off
_ ErrorDocument 403 "Some Message remplacé par ErrorDocument 403 "Some Message"
_ AccessConfig et ResourceConfig à remplacer par Include
_ BindAddress à remplacer par Listen
_ <ServerType> n'existe plus
Pour ces modifs, il suffit d'un simple grep ou sed sur les fichiers de conf et d'une petite modif de syntaxe dans les outils de création de fichiers de conf. Rien de grave de ce côté, donc.
Plus gênant :
_ ExtendedStatus n'existe plus. Dommage, certains hébergeurs s'en servent pour superviser leurs serveurs Web :o( L'air de rien, ça a un gros impact. En plus, la doc (http://httpd.apache.org/docs-2.0/mod/mod_status.html(...)) n'a pas été remise à jour... Là ça bloque !
_ mod_log_agent et mod_log_referer sont remplacés par CustomLog. Esperons que résultat final puisse être identique afin de ne pas troubler les outils de stats déjà utilisés avec Apache 1.3 (souvent développés à la main par les hébergeurs).
Ces deux dernières modifs risquent de retarder pas mal le déploiement d'Apache 2.0 chez les hébergeurs, et à mon avis, les stats NetCraft ne vont pas être boulversés dès demain.
[^] # Re: ENFIN !
Posté par Ludovic Boisseau . En réponse à la dépêche Pare-feu avec authentification. Évalué à 3.
Ici, on dit que l'authentification de l'utilisateur permet d'ajouter des règles personnalisées pour cet utilisateur. Or, dans le Authentication-Gateway-HOWTO, on se contente d'ouvrir tous les flux possibles pour n'importe quel utilisateur authentifié... Nuance ! Si on regarde de près les sources de pam_iptables.c (http://www.itlab.musc.edu/~nathan/pam_iptables/pam_iptables.c(...)), aux alentours de la ligne 226, on remarque que la conf du firewall ne fait qu'ajouter cette règle :
iptables -I FORWARD -s <host> -o <interface> -j ACCEPT
Dommage, c'est quand même un peu léger, le "tout ou rien"... L'avantage d'authpf, c'est que chaque utilisateur peut disposer de ses propres règles, présentes dans $HOME/.authpf/authpf.rules. C'est là que ça devient intéressant !!!
Comme quoi, les deux projets ne sont pas comparables, et donc, je répète, à ma connaissance, il n'existe pas d'outil semblable sous Linux (bien que le Authentication-Gateway-HOWTO et pam_iptables donnent déjà de bonnes bases...).
# ENFIN !
Posté par Ludovic Boisseau . En réponse à la dépêche Pare-feu avec authentification. Évalué à 10.
Entre nous, c'est une fonction qui pourrait aussi être implémentée sous Linux avec IPChains ou IPTables. En plus, cela n'implique pas de développement au niveau du kernel, mais "seulement" au niveau utilisateur.
# Problème de hostname
Posté par Ludovic Boisseau . En réponse à la dépêche Mise à jour LinuxFr. Évalué à 3.
je ne sais pas si vous avez remarqué, mais certains utilisent le serveur prout.linux.fr.org pour accéder à LinuxFR (ça doit se traduire par un contournement du load-balancer ou quelque chose comme ça). J'en fais partie et il y a une bonne raison : je suis dans une boite dont le proxy n'accepte pas les hostnames qui ne disposent pas d'au moins trois parties séparées par un point. En gros, http://linuxfr.org(...) ne passe pas, et http://prout.linuxfr.org(...) passe. Je suis dans une très grosse boite et je n'ai aucun poids pour faire modifier le truc (j'ai d'ailleurs aussi le problème avec slashdot, mais là je n'ai pas encore trouvé la soluce).
Moralité : serait-il possible de mettre en place un alias genre "www.linuxfr.org" qui pointe sur linuxfr.org afin que nous disposions d'un accès "simplifié" et que, si prout tombe, nous ne nous en rendions pas compte ?
Je sais, ça n'a pas vraiment de rapport avec DaCode, mais bon, tant qu'on y est...
PS : je sais que je ne suis pas le seul à avoir le problème, car d'autres boites utilisent le proxy que nous avons (je taierai le nom du proxy en question). Alors faites quelque chose (par pitié pour prout) ;o)
A+ et bon vent à tous,
[^] # Re: un lien
Posté par Ludovic Boisseau . En réponse à la dépêche Le libre et plus dans Télérama de la semaine prochaine. Évalué à 3.
http://www.telerama.fr/verity/result.asp?cle=linux&x=5&y=0(...)
# Oracle se met à la hauteur de M$ et utilise les mêmes méthodes
Posté par Ludovic Boisseau . En réponse à la dépêche Oracle Pet Store vs. .NET Pet Store. Évalué à 4.
Forcément, M$ sort vainqueur (sinon ils n'auraient pas publié leur bench) et écrase littéralement Oracle.
Oracle, voyant cela, ne peut pas rester silencieux et décide de répondre. Oracle réécrit son appli en optimisant à fond le truc (là, c'est le but, même si Oracle n'avoue qu'avoir peu modifié le soft), en diminuant le nombre de lignes et les appels à l'API J2EE. Pour couronner le tout, Oracle fait tourner son appli sur le premier foudre de guerre qui lui tombe sous la main (en soulignant que ces bécanes sont les mêmes que pour le premier test, et qu'elles sont moins performantes que celles utilisées par M$) :
_ les clients sont systématiquement des biproc à 2x360 ou 2x450 MHz tournant sous solaris 6,7 ou 8 (certainement des UltraSparcs) avec 512 Mo ou 1 Go de RAM
_ Du coté de la base de données, on passe en solaris 8 et quadripro à 400 Mhz chacun (UltraSparc aussi, je pense).
M$ ne détaille pas l'architecture sur laquelle il teste son soft, mais je ne sais pas si cela tient la route face à un UltraSparc (quoique, avec les dernieres version de P4 à 2GHz, ça doit commencer à booster correctement).
Bref, tout ça pour dire que même si M$ a fait le gros méchant, Oracle a bien fait de le remettre en place en employant les mêmes méthodes !
# Dans "programmez" aussi on parle du libre en entreprise
Posté par Ludovic Boisseau . En réponse à la dépêche Le logiciel libre en entreprise. Évalué à 6.
[^] # Re: La bataille est pas encore gagnee ...
Posté par Ludovic Boisseau . En réponse à la dépêche La CE rend publique sa proposition sur les brevets. Évalué à 10.
Des réponses ont également été reçues de diverses grandes organisations, d'autres associations industrielles et des professionnels de la propriété intellectuelle. Ainsi, même si les réponses dans cette catégorie ont été beaucoup moins nombreuses que celles en faveur de l'approche "libre", il semble évident que le poids économique mesuré par le nombre d'emplois concernés et l'importance des investissements nécessaires, fait pencher la balance en faveur de l'harmonisation au sens du document de consultation.
Moralité : c'est confirmé : le libre compte pour du beurre
[^] # Re: Surtout pour les serveurs ...
Posté par Ludovic Boisseau . En réponse à la dépêche Comment sauver vos vieilleries. Évalué à 10.
1) un firewall n'a pas besoin de grosses ressources CPU si les règles sont bien agencées
2) un firewall n'a pas besoin de faire tourner X11, donc pas besoin de bcp de RAM
3) les vieilles architectures du style SPARC sont très bien supportées par Linux et OpenBSD, y compris les cartes d'extension du genre QUADFAST (4 ports ethernet différenciés sur une seule carte), au moins sous Linux (je ne sais pas pour OpenBSD).
4) Enfin, l'argument massue en faveur des bécanes "propriétaires" : elles disposent très souvent d'un port "console" qui permet de prendre la main à distance sur l'équipement dès que la machine est sous tension, avant même qu'elle ait commencé à charger l'OS (sous SPARC, l'OpenFirmware est un vrai régal !). Je n'ai pas encore vu la même chose sur un PC.
Alors pourquoi se priver ?
[^] # Re: si c'est vérifié, c'est extrèmement grave !
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 8.
Moralité : si tu peux poster l'info sur ./, vas-y.
Et -1 parce que c'est complètement hors-sujet
# [FR] Site concernant les brevets logiciels
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 10.
"Pour ou contre la brevetabilité des logiciels
Je voudrais exprimer de façon synthétique les raisons qui me conduisent à ne pas approuver la pétition Eurolinux, et à proposer une solution intermédiaire. La pétition Eurolinux s'oppose à l'usage des brevets dans le domaine des logiciels, et vise à imposer un modèle économique unique, le modèle dit " libre ".
Explications
Or, je soutiens que (a) le brevet constitue un instrument de régulation économique vertueux { car il est encadré par des règles claires et transparentes, car le brevet protège les efforts d'innovation, quel qu'en soit le bénéficiaire (grand ou petit)}.
Que le modèle libre (b) présentant d'indéniables succès, présente néanmoins des zones d'ombres qui excluent toute initiative autoritaire visant à l'imposer comme modèle unique."
C'est à peu près du même tonneau que le document Word ci dessus. Bonne lecture :o(
[^] # Re: Y en a marre !!
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 6.
Des idées ?
Un communiqué officiel de l'AFUL ou de la FSF Europe, envoyé aux médias. C'est la grosse artillerie, mais le risque est à la hauteur.
[^] # Re: si c'est vérifié, c'est extrèmement grave !
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 10.
L'AFUL peut-elle envoyer un communiqué officiel à ce sujet ?
# Le logiciel libre compte pour du beurre !!!!
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 10.
"The individual responses were dominated by supporters of open source software, whose views ranged from wanting no patents for software at all to the "official" position of the Eurolinux Alliance which is to oppose patents for software running on general-purpose computers. On the other hand, submissions broadly in support of the approach of the consultation paper tended to come from regional or sectoral organisations representing large numbers of companies of all sizes, such as UNICE, the Union of Industrial and Employer's Confederations of Europe, EICTA, the European Information and Communications Technology Industry Association, and the European IT Services Association. There were also individual large organisations, other industry associations and IP professionals. Thus although the responses in this category were numerically much fewer that those supporting the open source approach, there seems little doubt that the balance of economic weight taking into account total jobs and investment involved is in favour of harmonisation along the lines suggested in the paper."
Je n'ai pas le temps de traduire, mais l'idée est là : "bien que les supporters du logiciel libre aient beaucoup fait parler d'eux, leur poids économique est négligeable, et donc leur opinion compte pour du beurre" (traduction libre).
# Et meeerde :o(
Posté par Ludovic Boisseau . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 8.
Par ailleurs, cela me fait légèrement sourire que le fichier soit au format Word... Ils auraient pu le mettre en HTML ! Mais c'est vrai que le HTML, y'a des brevets dessus (les liens hypertexte par exemple). <troll> Mieux vaut encore publier un document dans un format propriétaire, c'est vrai ! </troll>
[^] # Re: Deux détails concernant la news
Posté par Ludovic Boisseau . En réponse à la dépêche Le GNU bientôt dans (tous) les collèges ?. Évalué à 1.
Justement, aucun texte ne révise la dernière législation qui plafonnait la taille des clefs à 128 bits. Or SSH utilise comme méthode de repli (si aucune autre méthode n'est dispo) un 3DES (donc 3*56 bits, ce qui est supérieur à 128 bits). Dommage, donc. C'est également la raison de l'existance en France de SSF...
# NFS et Firewalls (!)
Posté par Ludovic Boisseau . En réponse à la dépêche NFS chiffré avec OpenSSH et Linux. Évalué à 10.
Enfin, ce système est très difficile à sécuriser par un firewall.
Huuummmm... quelqu'un peut me dire dans quel contexte un flux NFS doit traverser un firewall ? La tendance actuelle est plutôt d'isoler ce genre de trafic sur un LAN dédié (un SAN ou quelquechose du genre...). En effet, NFS est très gourmand, et a une légère tendance à saturer les réseaux. Il faut dire que les fichiers que l'on transfère aujourd'hui n'ont plus grand chose à voir avec ce que l'on faisait au moment de la conception de NFS... Même si entre temps, on est passé de 10Mbps à 100Mbps...
PS : si un flux NFS doit passer un firewall, j'ose à peine imaginer la puissance de la machine qui fera office de firewall... Au fait, quelqu'un a déjà tenté de mettre un firewall Linux (ou BSD) entre deux LANs à 100Mbps et de faire passer un max de connexions avec des protos bizzares, des petits paquets et plein de cochonneries pour voir si la bécane arrive à suivre ?