pasBill pasGates a écrit 16060 commentaires

Tu peux mettre à jour tes dépendances au moment même où le logiciel va charger la librairie (enfin quelque ms plus tard). Et en prenant plus de temps, tu peux savoir avant l'exécution du programme quelle librairie il va charger.

J'attends que tu me montres comment tu fais cela

Non, c'est pas déconseillé bien au contraire puisque les outils pour gérer des logiciels hors système de paquets sont fourni par le système de paquets.

Au jour d'aujourd'hui, tu fais quoi ? Tu redemarres tes softs proprios constamment, visiblement tu ne le fais pas. Pourquoi ? Ben oui, trop complexe a mettre a oeuvre.

Par contre toi tu ne sais pas de quoi tu parles et ça c'est certain.

Moi j'attends toujours que tu m'expliques _COMMENT_ faire, pas que tu me dises que tu peux.

Non le problème est différent. MSI a été créé par Microsoft et les premiers à ne pas avoir respecter ce système de paquet, c'est Microsoft. Donc crédibilité zéro. Debian respecte les règles définies par le projet. Et ça c'est une _énorme_ différence sur un serveur.

Non le probleme est identique, d'un point de vue technologique, MSI c'est .deb , les 2 ont le meme probleme : des softs ne rentrent pas dans le moule pour diverses raisons.

Faire des pseudo-paquets est faisable moyennant un peu de temps pour le faire. Peu importe la méthode que le logiciel utilise. Tu peux toujours savoir quelle librairies un logiciel charge.

Tu peux savoir a l'instant T quelle librairie il a charge, je te mets au defi de me donner une methode qui permet de garantir que tu sauras quelle librairie il *peut* charger. Hors, c'est ce qu'il faut pour pouvoir generer un paquet complet, sinon quand tu fais ta query pour savoir quels paquets dependent de la lib X, tu auras faux.

Je suis pas certain de comprendre ta phrase, mais je crois en comprendre l'essence. C'est très simple d'installer un logiciel non-empaqueté ou empaqueté pour une autre distribution. Installer un des ces logiciels et ses dépendances ne met pas en danger le système de paquet puisque les systèmes de paquets respectes la "Filesystem Hierarchy Standard".

Non ca ne met pas le systeme de dependances en danger, mais dieu sait si ca installe un merdier enorme sur le systeme(ben oui, parce que cette nouvelle version du paquet, elle depend des nouvelles versions des dependances, et faut tout ramener), resultat c'est absolument deconseille.

Je crois qu'il sait de quoi il parle, tu dois te tromper.

Clairement non vu qu'il ne sais meme pas que MSI gere les dependances.

MSI n'est pas la panacée, loin de là. Et ça fait pas longtemps que MS Office peut-être installé en silencieux (ce qui est normalement requis pour les paquets MSI). Le problème de MSI c'est que Microsoft n'a pas joué le jeu avec MS Office (pas de mode silencieux), donc d'autres ont fait pareil. Le produit a été gâché. Dommage.

Non MSI n'est pas la panacee, tout comme .deb n'est pas la panacee non plus, ni .rpm d'ailleurs. La panacee ca n'existe pas.
Le probleme de MSI est le meme que .deb : ils ne couvrent pas tous les softs, les paquets ne sont pas tous detailles completement, ...

Donc, la solution que je donne marche a 100% lorsque tous les softs sont packagés, merci de le démontrer. Et sans trop de difficultés, on peut toujours faire un pseudo-package autour d'un soft non-packagé, juste pour l'inscrire dans le gestionnaire de paquet.

Moi je t'ai demande une solution qui marche a 100% dans la realite, pas une solution qui marche a 100% dans un monde hypothetique.

Quand a faire un pseudo-package, j'ai demontre plus haut que non, ce n'est pas faisable pour bon nombre de softs.

Maintenant, le libre a effectivement quelque chose a voir la dedans, parce que les softs libres sont presque toujours packagés, contrairement au softs proprios.

Eh oui... "presque toujours", enfin bon, sauf dans les cas ou la version qu'on veut est plus recente que la distrib, car la le package fourni met un merdier pas possible dans les dependances, sauf dans le cas ou le soft n'est pas fourni par la distrib, ...
Et chacun de ces cas constitue un trou dans ta solution qui garderait ton systeme vulnerable.

Magnifique. Tu ne sais pas le faire sur le systeme commercialisé par ton employeur, donc tu généralise à tous les systemes existants, alors qu'on vient de te donner au moins un exemple du contraire. Quelle belle démonstration !

C'est triste que tu ne saches pas de quoi tu parles.

Oui, je vais aller voir, parce que je n'ai pas la prétention de tout connaitre. Mais d'après ton discours, j'ai bien peur que ce machin ne sache pas gérer les dépendances, alors je ne m'attends pas à une révélation.

C'est bien ca le probleme, tu parles de ce que tu ne connais pas. MSI gere les dependances, il est capable de te trouver tous les packages dependant du binaire X, il est aussi capable de te dire comment arreter / redemarrer les services dependants.

Mais rien de tout cela ne resoud le probleme.

Euh ouais mais bon, la video de grand-maman ou les 300 photos en 4032x3024 du voyage en Egypte, tu peux etre sur que personne ne les a deja uploadees hein...

Le 1er compte, car il faut un admin, les autres non (Vista +)

Ensuite, au lieu de reconnaitre la puissance du gestionnaire de paquet, tu dévie la question sur les logiciels propriétaires qui ne rentrent pas dans le moule. Je te remercie de nous montrer la supériorité du libre sur le propriétaire, mais ca on le savait déjà. Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

Tu me fais rire, je te demandes un truc, tu me donnes une solution qui ne marche qu'a 50%
La superiorite du libre sur le proprio elle est tres drole et n'a rien a voir la dedans, c'est le fait que le soft ne soit pas package qui est le point faible.

Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

Inutile de me retourner la question, la reponse est que c'est une chose impossible a faire quel que soit le systeme.

Pour revenir au sujet :
- Si la machine ne comporte que des logiciels packagés, alors je peux laisser le gestionnaire de paquet gérer les dépendances, c'est son boulot.
- Si elle héberge en plus des logiciels non packagés (propriétaires ou pas), on sait reconnaitre ces logiciels et les redémarrer, parce qu'on s'est donné la peine de les installer avec un peu de méthode. Si on ne veut pas se prendre
la tête, on redémarre systématiquement ces logiciels en cas de mise à jour.

a) Oui, mais c'est plutot utopique
b) Oui, idem sous Windows en fait

J'aimerais que tu nous explique quel sont les cas qui ne sont pas pris en compte par les trois points ci-dessus, et surtout comment on peut faire la meme chose sous Windows.

Il y a un truc qui s'appelle MSI sous Windows, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.

Si c'est possible, ça demande du temps. Après tu pèses le pour et le contre. Perso je me prends pas la tête, les softs proprios je les redémarre quand je fais une mise à jour.
Mais il est possible de d'automatiser cette tâche de détection de librairie. Je n'ai jamais essayé, mais vu que tu arrives à isoler tous les fichiers, tu peux facilement faire un script qui va te donner la liste de toutes les librairies nécessaires puis lister les paquets contenant ces librairies (le gestionnaire de paquet de Debian te permet de savoir à quel paquet un fichier appartient).

Non tu ne peux pas le faire. Tu ne sais pas quand et sous quelles conditions le soft va decider de charger la librairie, si tu fais tourner ton script hors de cette condition, tu ne verras pas la librairie.

Quand a ne pas te prendre la tete, c'est justement la bonne solution, parce que c'est la seule qui soit sure.
Maintenant quand tu deploies ton patch et que tu dois redemarrer tous ces softs sur X machines differentes, faut savoir comment le faire sur chaque machine, garder la chose a jour, etc... un vrai bordel compare a "je me prends pas la tete" comme tu le dis qui est de redemarrer le systeme.

De la magie personne ne peut en faire. Ni Microsoft, ni Debian, ni Apple. Mais actuellement le seul système qui s'approche de la perfection en terme de gestion des mises à jour reste Debian et je crois pas que Microsoft s'approche de ça.

Que Microsoft ne soit pas parfait je n'en doutes pas une seconde, que Debian en soit proche sur ce point, permet moi de rire, c'est le genre de systeme ou soit tu y arrives completement, soit tu n'y arrives pas, il y a pas de milieu, car le milieu signifie que tu restes vulnerable sans le savoir, et Debian n'y arrives pas completement, bref, il est exactement au meme stade que MS.
Que les gens ne s'en rendent pas compte et suivent aveuglement le troupeau ne signifie pas que le troupeau a raison.

Si il charge les librairies à la demande, il n'y a rien à faire, je vois pas où tu veux en venir, là ...

Vraiment ?

Le soft X charge a la demande OpenSSL, un patch pour OpenSSL surgit.

Tu l'installes, tu redemarres tous les softs, sauf le soft X car tu ne sais pas qu'il utilise OpenSSL, ce soft reste vulnerable.

Sinon quand tu prends un logiciel, tu dois toute façon savoir quelles librairies (autres que celle qu'il amène lui-même) tu dois avoir sur ton système et ton logiciel tu vas l'installer dans un répertoire bien délimiter pour que tu puisses voir l'entier du truc sans te prendre la tête.

Quand le soft depend de librairies qui sont quasiment toujours presentes et que l'editeur ne te donne pas l'info (souvent il ne l'a pas d'ailleurs ce qui est drole), tu fais comment ?

Si justement c'est une vue de tout ton système et toutes le dépendances

Je viens de te demontrer par A+B que non, car il ne gere pas les softs non-packages, et qu'il n'est pas possible de creer ces packages soi-meme de maniere sure et complete.

Rien j'est jamais complet, mais il est assez evident que niveau softs dispos Linux a qqe trains de retard

Si l'admin a prévu le coup il a fait un paquet qui permet de "caler" ton logiciel dans le système de paquet. C'est un paquet qui ne fait rien d'autre que de te garantir les dépendances et tout et tout durant les mises à jour. Le paquet en lui même ne met pas de fichier.

Ben ca va etre drole a faire quand tu te rendras compte que le soft il loade des librairies a la demande plutot qu'en etant linke directement a elles(sans parler que ca va etre rigolo de faire cette liste des libs linkees, car faut la refaire a chaque update du soft en question, pour chaque soft au cas ou ca change, et il faut trouver les binaires de chaque soft, nombre qui peut augmenter a chaque release / update).

Eh oui pas de chance, marche pas non plus.

Debian a un système de gestion de paquets connu et reconnu, ce n'est pas un hasard, c'est un outil qui a été développé par une communauté qui fait tourner le monde des serveurs depuis longtemps et ça se ressent à l'utilisation, c'est un vrai régal.

Ce systeme de gestion de paquets ne resoud rien car il ne represente pas l'entier du systeme et ses dependances.

Ouais mais toi t'es suisse, tu vis sur une ile un peu aussi :+)

Ben non c'est incomplet, nombre de softs proprio ne sont pas disponibles dans le packaging de la distribution.

Ton systeme ne fonctionne pas et est dangereux pour le systeme.

Mais bon, je te comprends, tu n'as pas l'habitude...

Au contraire, j'ai l'habitude, la preuve.

Ton dpkg il inclut tous ces softs metiers et autres qui ne sont pas livres en tant que .deb ? Il est baleze dis donc.

Parce que le gros probleme c'est bien ca, le systeme de packaging il ne couvre pas tout, surtout lorsque il s'agit de logiciels proprio et dieu sait si les entreprises en utilisent.

Essaie de faire ca sans etre admin, ca va etre tres drole

Je te suggeres d'utiliser un compte utilisateur plutot qu'admin, il est un peu normal qu'on te demande pas le mot de passe admin si t'es logge en tant que tel...

Tout a fait, mais personne n'a jamais essaye de faire croire qu'ils etaient securises, contrairement a Fedora.

Je parles evidemment de la lignee NT, les versions precedentes n'avaient meme pas le concept d'admin/user, permettre a un "utilisateur" d'installer des softs etait donc tout a fait normal et pas un trou dans l'architecture de securite du systeme, vu qu'il n'y avait tout simplement pas de securite.

Le fait qu'un compte soit admin ou pas n'a absolument rien a voir avec le fait de laisser un utilisateur quelconque installer des softs globalement sur le systeme. Dans un des cas, le systeme fonctionne en suivant l'architecture de securite prevue, dans l'autre, on cree un trou beant dans cette architecture.

Faire cela signifie que l'on ouvre toutes grandes les portes du systeme a tout un chacun, c'est a mon sens une tres tres grosse betise, car l'admin n'est plus capable de controler ce que le systeme devient, hors la raison principale de cette separation entre user et admin c'est ca, l'admin gere et controle le systeme, l'utilisateur utilise le systeme.

De plus etant quelqu'un d'assez coherent, je trouvais ce comportement idiot sous windows et donc je ne vois pas pourquoi je le trouverai bien parceque c'est sous linux.

Tu manques de memoire en tout cas, Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global.

On pourra mettre toutes les possibilités imaginables sur le redemarrage lors de l'install des mises à jour, ça change pas le problème de base. Pourquoi faut il systematiquement redemarrer un serveur pour n'importe quelle mise à jour ?

C'est du a la maniere dont Windows gere les dlls et exe (tu peux pas remplacer un dll ou exe pendant qu'il est utilise).

En pratique, j'ai compté 7 mises à jour du noyau sous debian depuis Janvier 2009, donc ceux qui ont redemarré pour charger le nouveau noyau ont quand même eu des uptimes plus long qu'un mois (http://www.debian.org/security/2009/).

Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres ? Sur toutes tes machines ? Ca a du etre drole a faire.

En pratique pour avoir du microsoft en serveur depuis avril, c'est rare quand l'uptime depasse 1 mois.

Logique vu qu'on sort nos patchs chaque mois.

Encore pratique, dans un réseau d'entreprise, un linux non mis à jour peut tenir plusieurs années sans poser de problème en terme de piratage ou attaque de virus (c'est du vecu).

Mets moi dans ton reseau d'entreprise, tu commenceras tres vite a avoir des sueurs froides.

Ce n'est pas parce que les gens ne le font pas que ce n'est pas faisable.

Choix au hasard :
- http://www.samba.org/samba/security/CVE-2009-0022.html
- http://www.vupen.com/english/advisories/2009/0029
- http://www.samba.org/samba/security/CVE-2008-1105.html

Désolé, c'est moi qui suit du côté pratique, tu ne peux pas utiliser ce mot ...

Dis nous alors, tes machines ont ete attaquees ? Tu as des elements montrant que c'est utilise activement ?

... surtout quand c'est complètement à côté. Depuis le début de l'année, 8 redémarrages, dont 2 redémarrage d'affilé (2 jours d'intervalle).

Tu vas chez Redhat, tu comptes le nombre de patchs de securite du kernel, cette annee ils en sont a 8, l'annee passee a 10.

Sur les serveurs, tu peux rajouter les libs genre openssl vu le nombre de softs qui les utilisent (tu peux t'amuser a aller sur chaque machine, trouver les softs les utilisant, trouver comment les arreter un par un et etre bien sur que t'en as pas oublie mais un reboot sera bien plus simple et sur), sur les clients les libs KDE et Gnome.

Au final, t'arrives a environ un mois voire plus

Non je serais cohérent si je continuais à dire que c'est un scandale que Microsoft ne sorte pas un patch pour le trou smb1 et 2, mais je crois que le débat à glisser un peu parce que Microsoft a décidé que ce n'est pas grave. Donc ce n'est pas grave.

On a dit qu'on sortirait pas de patch ? Non.

Enfin bon, desole de faire les choses proprement plutot que sortir un truc en 30s qui se refera trouer en 2 jours et qui risque de tout casser. Visiblement depuis l'annonce tu as eu tous tes serveurs qui ont ete attaques.

Sinon pour les mises à jour (puisqu'on est sur le sujet), il y a moyen de faire plus précis que "auto / pas auto" (ça c'est Microsoft).

Et hop, on ressort les petites phrases la con sur MS.

Tu remarqueras que c'est plus que auto / pas auto , il peut toutes les installer et retarder le reboot, ne pas rebooter si qq'un est logge, etc... mais visiblement cette partie de la phrase tu l'as ratee.

Oui dans le cas de Windows, mais dans les autres systèmes (je dirais presque tous les autres), il y a possibilité de mettre à jour des parties du système pouvant être rechargée sans nécessité un redémarrage complet de la machine. En fait on redémarre uniquement quand on met à jour le noyau Linux.

En pratique sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem.

Rooh, sois sérieux, éteindre un serveur à distance il me semble que c'est grave. Suffisamment pour avoir un patch critique

C'est grave oui,au point de sortir un patch oui, au point de sortir le patch dans les 30 secondes sans le tester correctement, non.

Expliques au lieu de simplement nier (avec des sources, si possible, car tu ne mets jamais de source, c'est lourd à la fin).

Tu veux que je t'expliques quoi ? Que notre systeme ne reboote pas les serveurs automatiquement ?

http://blogs.technet.com/mu/archive/2008/10/02/windows-updat(...)

Le systeme te demande ce que tu veux faire au setup, si tu decides de les installer automatiquement, alors il y aura reboot avec le pop-up et t'as des options pour le delai de reboot, ne pas rebooter si qq'un est logge, ..., si tu decides de download et laisse l'utilisateur decider, alors elles s'installeront quand tu le voudras, si tu decides de rien faire, alors il ne fera rien.

Ben justement, peu importe la carte graphique sur le serveur, ton client sur connecte sur le serveur Terminal Services, il ecrit son document Word a la con, trouve son boulot chiant et il veut voir une anim Direct3D, les instructions D3D seront executees en local sur le client, en tirant partie de la carte graphique du client. Resultat le serveur n'est pas charge par tout ce bordel et c'est plus fluide pour l'utilisateur qu'avoir simplement le buffer de l'anim qui passe.

Idem pour la video(faut que ca passe par DirectShow je crois)

Mais c'est ça que je critique. Ce n'est pas à vous de juger de la gravité de la situation.

Alors on fait quoi ? On sort 300 patchs par jour car pour chacun d'eux il cree une situation critique pour quelqu'un quelque part sur la planete ? C'est irrealiste, il faut donc qu'on fasse un jugement sur la gravite du probleme.

J'ai souvenir d'une boîte de dialogue qui venait tout les X temps et laissait X minutes avant de redémarrer automatiquement.

Et si tu lisais la doc, tu saurais comment l'eviter.

Non, c'est toi qui ne connaît pas bien l'histoire de ta boîte je crois. Par contre les licences j'y ai jamais, au grand jamais, rien compris ... Mais t'inquiète pas, je ne fais plus de Microsoft maintenant ... Je ressasse seulement mes souvenirs.

Voyons voir, ca fait 9 ans que je bosses sur les patchs de Windows chez MS, marrant, mais j'ai comme la drole d'impression que je sais 10x mieux de quoi je parles que toi.

Tu voulais dire 1975-2003 ?
Sinon je penses bien que vous débauchez les meilleures. Mais ça veut pas dire que votre système est le meilleure (c'est pas parce que Ian Murdock est chez OpenSolaris que ce système va être aussi bon que Debian (en terme de distribution)).

Mais mon cher, les boites de securite, elles basent pas leur jugement sur qui on embauche, elles basent leur jugements sur nos produits et nos processus.

Snyder elle etait chez nous pendant plusieurs annees, c'est la ou elle s'est fait un nom en bonne partie, si le resultat de son boulot avait ete de la merde, crois-moi ca se saurait dans les milieux specialises