Raoul Volfoni a écrit 919 commentaires

"It is taking a long time for the Linux code base to get where BSD was ten years ago."

Quand openBSD supportera l'architecture NUMA on pourra apporter un peu de crédit aux paroles du père UBU...

Sinon le reste de l'article me fait penser à la cathédrale et au bazar. Bien sur il ne raconte pas que des âneries (loin s'en faut) mais c'est vrai qu'on le sent très aigri.

> Pour moi, .Net est le successeur de COM+, mais il ne l'utilise pas.

Bon, j'arrive un peu en retard pour te répondre mais saches que ce sont 2 technologies totalement différentes. Pour prendre un grand raccourci on pourrait plutot dire que chronologiquement on a eu le droit à OLE, puis COM et DCOM et enfin COM+. Celà n'a strictement rien à voir avec l'environnement de développement qu'il soit .Net ou les anciens objects COM en C++, Delphi, VB ou autre. En fait le serveur d'appli héberge et gère les composants.

Si tu veux voir à quoi ressemble le serveur d'appli de COM+ va dans les outils d'admin puis service des composants (sur une version serveur de 2003 par ex). Là tu verras que tu peux inscrire des composants managés (donc en .Net)

Auparavant (à l'époque de COM puis DCOM) ce serveur d'appli s'appelait MTS alias Microsoft Transaction Server. Aujourd'hui c'est beaucoup plus puissant mais comme je l'ai indiqué auparavant il n'y a aucune alternative (à ma connaissance) à ce serveur d'appli, ce qui fait que pour les développements d'entreprise Mono n'est pas encore (loin s'en faut) au niveau de Java.

Mais comme dit plus haut, Mono pour le Desktop c'est peut-être bien (je n'ai pas d'avis tranché en la matière, c'est juste que je préfère utiliser un seul langage plutot que de changer au gré des modes et des saisons)

Voilà. ;)

> Quelqu'un a-t-il vraiment testé ce genre de logiciel sur Linux ?

Aux dernières nouvelles, il parait qu'un chercheur en biologie dans une université du Massachusset travail dessus, mais chuuut, personne ne doit le savoir...

> Je crois surtout qu'il y a un refus méfiant de la part des dev de Fedora Core, qui préfèrent diaboliser ce qui vient de MS et miser sur la plateforme de Sun.

AMHA ça n'a rien à voir. Autant on peut comparer .Net et Java sur une plateforme Windows, autant ça ne tient pas la route sous Linux.

Je m'explique: RHEL étant une distribution destinée avant tout aux entreprises, ils me parait évident qu'ils ont choisi la solution qui permet de développer des systèmes d'information à la hauteur de la demande de leur client.
Le jours où il existera un équivalent au serveur COM+ sur Linux on pourra en reparler. Pour le moment les serveurs d'appli Java (libres ou propriétaires) tournant sous Linux ou Windows sont légions. Pour .Net il n'existe rien d'autre que Com+ sous Windows et je crois que ça restera longtemps ainsi.

Alors cessons de comparer ces deux technologies qui si elles ont en commun d'être toutes les deux le socle des développements en entreprise, ont ceci de différent c'est que l'une des deux est conçue uniquement pour Windows. Faire tourner une simple appli desktop en .Net ou Mono sous Linux pour montrer la faisabilité de la chose n'est qu'un argument marketing de plus.

> Beeeeuuu... c'est pour rire. Je sais bien qu'il est bon !

Désolé, j'ai pris ton post au 1er degré. C'est fou comme l'attachement à une distrib nous rend parfois aveugle.

Du même site il y a moins d'un mois:
http://www.osnews.com/story.php?news_id=10616(...)

Bref après SFU, Cygwin, coLinux, MinGW et bien d'autres, voilà maintenant que Portage risque de débarquer dans Windows (via les SFU). Est-ce pour prendre de cours toutes les tentatives individuelles de port de Portage vers la plateforme W32? [1]
En tous cas je souhaite bon vent à D. Robbins qui j'en suis certain gardera toujours un oeil attentif à la croissance de son bébé.

[1] http://forums.gentoo.org/viewtopic-t-319691-highlight-portage+port+(...)

> Peut-être qu'il était pas si bon que ça, non ?

Je me demande si je dois en rire, marcher dedans ou te filer une paire de claques...

Vas jeter un oeil sur tout ce qu'il a produit (hormi Gentoo) comme doc et tu comprendras à qui tu as à faire: http://www.gentoo.org/main/en/articles.xml(...)

Désolé pour le ton agressif, mais ayant eu l'occasion d'échanger quelques emails avec lui, ton message m'a mis hors de moi.

> Bref, les LL c'est pas non plus une solution magique, ca depend comment on configure son serveur et ses scripts.

Ouf! Heureusement que tu es là, un instant j'ai cru que le réchauffement de la planète était dû à l'éditeur de Redmond...

Néanmoins et en référence au journal parut un peu avant ( http://linuxfr.org/~Skippy380/18481.html(...) , je trouve cette débauche de matériel pour un malheureux blog proprement scandaleuse. Je m'en vais de ce pas écrire à ce môssieur pour lui demander comment il a fait pour mettre son égo en orbite à plusieurs parsecs au dessus de notre pauvre planète.

A ce propos, j'ai lu hier qu'AMD passera ses processeurs en quadri-core l'année prochaine, mais encore bien plus important, qu'ils seront équipés de 'régulateurs' pour adapter dynamiquement leur fréquence de fonctionnement en regard de la charge. Le discours marketing est maintenant de parler de métrique/watt/seconde: http://www.extremetech.com/article2/0,1558,1826657,00.asp(...)

Alors pourra-t-on bientôt mesurer l'efficacité de Linux et des LL avec un simple wattmètre? En tous cas avec ce garçon il faudra prévoir un modèle de gamme supérieure. Qui a dit un Prumpleffer™ ?

> Voila comment je vois la suite des choses. [...]

Et bien bravo et bon courage pour la suite des opérations.

Mes meilleurs cieux (encore qu'à cette époque de l'année... ;)

Salut,

Voici un magnifique exemple de ce qui se passe quand on entame un projet en freeware: on attaque le développement avec des outils non libres (Delphi en l'occurence) puis on distribue gracieusement l'exécutable.

Ensuite après un succès étonnant auprès des astronomes amateurs (sous windows), on décide de passer en GPL (et d'avoir une version Linux) pour toucher le plus de monde possible et bénéficier de tous les avantages de ce mode de développement.

Hélas pour Patrick et son merveilleux soft, Kylix n'est pas un logiciel libre et fabriquer un ebuild pour Cartes du Ciel demanderait d'avoir le soft dispo sous Gentoo ce qui n'est pas le cas aujourd'hui.

Voilà, au début j'ai pensé que c'était une bonne nouvelle et maintenant je repense à ce qu'àvait écrit RMS à propos des développement en Java: s'assurer de ne pas utiliser de libs propres à l'implémentation de Sun, sinon on ne fait pas un logiciel libre. Pour moi c'est la même chose avec Cartes du Ciel. :-(

ps: je viens de retrouver une discussion sur le sujet qui d'ailleurs me fait penser que le Xnay est une mauvaise chose. :)
http://groups.google.fr/group/fr.sci.astronomie.amateur/browse_frm/(...)

> tu vas pouvoir la compiler et reporter gentiment des bugs a Apple.

Quoi, tu veux qu'il renvoit encore l'ascenseur?

> Par ex, j'ai un pôte qui a accés aux infos;

Donc il aura certainement signé un NDA (Non Disclosure Agreement).

> et me donne suffisemment d'infos pour en developper ma version à moi, libre évidemment.

Si jamais il viole le NDA (ce qui semble être traduit ici par 'clause de confidentialité') tu pourras vite remplacer la bière par des oranges...

Je ne suis pas un Touboniste acharné, mais pourquoi traduire refcard par carte de référence alors que le Français nous donne déjà "Aide-mémoire"?
Sinon bravo, c'est toujours agréable d'avoir ce genre de doc sous le clavier.

> M'enfin bon syslog est tellement pourri qu'on est plus à ca près

Mon conseil: regardes du coté de syslog-ng, c'est impressionnant tout ce qu'il permet de faire:
http://www.balabit.com/products/syslog_ng/(...)

> Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?

Et comme ça avec une IP spoofée tu peux te chopper un magnifique DOS. Si l'attaquant sait quelle est ton IP, tu ne pourras même plus te connecter à ton serveur! AMHA c'est une stratégie dangeureuse si implémentée sans précaution.

Il y a plusieurs solutions pour résoudre le petit désagrément des vilains bots:

- changer le port d'écoute de sshd (les bots pour ssh n'attaquent que le 22 la +part du temps)
- n'autoriser que les connections avec des clés valides (authorized_keys) depuis des machines connues (known_hosts)
- utiliser des mots de passes jetables (skey ou OPIE) très utile quand on se connecte depuis une machine que l'on ne connait pas (évidemment incompatible avec le known_hosts)
- désactiver la connection par mot de passe: PasswordAuthentication no
- comme indiqué + bas, utiliser Portknocking: http://www.portknocking.org/(...)
- enfin en dernier recours faire un script pour iptables qui bloque l'IP pendant un temps bien déterminé de façon à éviter le DOS. Mais je ne suis pas trop pour. :(

Sinon quelques conseils de bon sens:
- avoir évidemment des mots de passe à toute épreuve (y compris celle des Rainbow Tables C.f. http://passcracking.com/(...) Donc au minimum 20 caractères avec tous ceux que l'on utilise habituellement que pour les jurons. ;)
- éventuellement bloquer la connection à root sauf si on utilise des mots de passe jetables pour administrer la machine depuis une autre machine sans confiance. Auquel cas un su ou sudo mettrait toute la sécurité par terre si la machine est infectée par un logger.
- s'il s'agit d'une machine passerelle et que l'on a pas besoin de s'y connecter depuis un des réseaux, ne mettre sshd qu'en écoute sur l'autre adresse.
- vérifier les options de son sshd_config et surtout MaxAuthTries, PermitEmptyPasswords, UsePAM (dans ce cas voir aussi la config de PAM) et ne pas oublier de bloquer SSH1: Protocol 2
- et enfin si on est vraiment parano, utiliser Kerberos.

Finalement mettre un message d'interdiction des connections non authorisées dans /etc/ssh/banner. Les bots s'en foutent, mais si quelqu'un réussit à percer toutes les barrières précédentes, il ne pourra pas prétendre qu'il n'a pas vu l'interdiction d'entrer (pour le forensic).

> Même raisonnement pour celles qui ont leur messagerie sous Exchange ou Notes. Ou celles qui ont des progiciels sous SAP.

Puis-je te demander en quelques lignes ce qui caractérise un méta-annuaire stp? J'ai un peu de mal à suivre mais j'aimerai bien comprendre. ;)

Merci.

> Oui mais c'est sûr que si tu n'écoutes pas les vrais talents de la StarAc comme tout le monde ...

Et puis surtout l'album des Fatal Picards c'est comme la Sarge il est encore en Freeze...

> une chanson d'un quelconque Universal, Sony Music, etc. car ils se sont rendus eux-même coupable de vol envers les artistes et s'engraissent sur leur dos et le nôtre!

C'est ce qu'on appelle la St'arnaque non?

----->[pas la peine]

> Bon donc, faut vraiment que je fasse qqc pour bosser sous linux

Tout n'est peut-être pas perdu, j'ai dégotté ça:

http://bbman.sourceforge.net/(...)

Par contre je n'ai pas trouvé comment lui faire utiliser ma clé et ses options ssh semblent être très limitées. Sinon il y a aussi Tunnelier mais s'il est gratuit pour une utilisation perso, il n'est malgré tout pas libre (donc pas testé):

http://www.bitvise.com/tunnelier.html(...)

Sinon effectivement reste coLinux ou WMware mais c'est de l'artillerie lourde pour avoir juste des onglets. ;)

C'est en effet quelque chose que j'aimerai également beaucoup avoir. Hélas d'après Simon Tatham (l'auteur de PuTTY) c'est pas pour demain la vieille comme on dit d'nos jours:

http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/multiple(...)

Par contre il indique un paliatif mais je ne sais pas ce que ça vaut:

http://spoox.org/projects/twsc/(...)

Pour ceux qui ne supportent vraiment pas la ligne de commande (CLI) je conseille aussi de jeter un oeil à Firewall Builder:
http://www.fwbuilder.org/archives/cat_about.html(...)

> solution technologique capable de supporter un trafic 40 fois supérieur au trafic régulier durant les pics de fréquentation ;

Les commerciaux d'IBM devraient envoyer des invitations au service informatique du ministère des finances...

Sinon j'aimerais bien voir Tux sur les banderolles qui parsèment le stade. Ce serait quand même un juste retour d'ascenseur, enfin je trouve.

Quant à la plate-forme technologique il y a longtemps que les DBA savent que rien ne vaut Linux: Cf. n° July 2003 de Oracle Magazine ou le n° plus récent de DB2 mag (fin d'année 2004)

http://www.oracle.com/technology/oramag/oracle/03-jul/index.html(...)
http://www.db2mag.com/db_area/archives/2004/q4/(...)

Bonjour,

Je n'ai fait que parcourir sa thèse qui est surement passionnante, mais j'ai l'impression qu'il ne s'attache qu'à l'aspect logiciel. Or un système d'information c'est beaucoup plus que celà. Et quand on parle de haute disponibilité il faut prendre en compte toutes les composantes du SI sous peine d'avoir effectué un boulot aussi faramineux qu'inutile.

En bref et pour répondre à Djinns, je lui conseillerai comme démarche d'identifier dans un 1er temps toutes les composantes du SI: postes clients, matériels serveurs, réseaux, logiciels, load-balancing, procédures de backups, etc., redondance à tous les niveaux y compris pour les processus humains (et oui le SI n'est pas toujours 100% automatisé). Ensuite d'étudier chacune des ces composantes et d'y détecter les failles et les moyens d'y remédier. Ce n'est qu'après cette phase d'étude que l'on peut proposer une véritable stratégie.

Car un serveur ou un switch qui tombe en rade ce n'est pas bien grave s'il y a un équipement de répartition de charge en amont. Mais les plus anciens se rappeleront par exemple l'incendie d'une banque dont je tairais le nom où le plan de reprise d'activité (PRA pour les + agés) avait permis une interruption de quelques heures seulement.

Bel exemple d'un plan sécurité correctement mis en oeuvre.

Bien vu.
En production on peut éventuellement se passer du Dump/Restore en exécutant les instructions suivantes en superuser:

UPDATE pg_proc SET proacl = '{=}'
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;

Pour chacune des bases de données y compris template1 et template0. Pour modifier cette dernière qui est normalement verouillée pour les connections, il faut au préalable la rendre dispo avec:

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

Puis exécuter la requête plus haut et ne pas oublier de verrouiller à nouveau la base ensuite avec un petit VACUUM auparavant:

VACUUM FREEZE;
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

La seconde vulnérabilité concerne le module tsearch2 et peut elle aussi être corrigée sans Dump/Restore:

UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
WHERE oid IN (
'dex_init(text)'::regprocedure,
'snb_en_init(text)'::regprocedure,
'snb_ru_init(text)'::regprocedure,
'spell_init(text)'::regprocedure,
'syn_init(text)'::regprocedure);

Voilà, tout ceci pour dire qu'il n'est même pas nécessaire d'interrompre la production pour corriger ces deux petites vulnérabilités.

> Comme c'est une faille CPU il me semble évident que tous les OS sont touchés.

Sauf ceux qui ne supportent pas l'hyperthreading comme OpenBSD dont les devs ont jugé que ce n'était que du pur marketing. ;)