Cela n'a vraiment pas pris longtemps pour avoir un trou de securite exploitable sous Seven. Le plus amusant et la reponse de la compagnie produisant cet OS...
Microsoft said it may patch the problem, but didn't spell out a timetable or commit to an out-of-cycle update before the next regularly-scheduled Patch Tuesday of December 8. Instead, the company suggested users block TCP ports 139 and 445 at the firewall.
Il se pourrait eventuellement que un jour si l'age du capitaine et le vent tourne bien que l'on se bouge les fesses et corrige ce probleme de securite.
En attendant avec Seven vous pouvez oublier vous servir de samba pour quelques temps.
Precision smbv1 et v2 sont touches donc pas de roue de secours sauf downgrade vers une version precedente des OS redmondien ou mieux Linux!
http://computerworld.co.nz/news.nsf/scrt/E9592E1A9719742ACC2(...)
Journal meme pas un mois...
16
nov.
2009
# Comme d'hab
Posté par Maclag . Évalué à 8.
Mais là si je comprends bien, ils ne disent pas qu'ils ne vont rien faire, juste qu'il ne vont sans doute rien faire avant le 8 décembre.
Reste que "z'avez qu'à bloquer les ports!", c'est vrai que c'est un peu fort de café pour les entreprises/administrations où c'est "fort déployé".
3 semaines mini, ça va être très très long quand même!
[^] # Re: Comme d'hab
Posté par NeoX . Évalué à 8.
ca va etre pratique de bloquer les port 139/445 sur les machines clientes en entreprises
quand elles ont un serveur de fichier (windows ou linux/samba)
[^] # Re: Comme d'hab
Posté par Aldevar (site web personnel) . Évalué à 6.
[^] # Re: Comme d'hab
Posté par neologix . Évalué à 9.
[^] # Re: Comme d'hab
Posté par Aldevar (site web personnel) . Évalué à 9.
[^] # Re: Comme d'hab
Posté par niclone (site web personnel) . Évalué à 10.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Windows Seven est enormement plus deploye que la version serveur, la version client est toujours bcp plus en avance que les serveurs.
[^] # Re: Comme d'hab
Posté par Maclag . Évalué à 3.
Parce que autant comme on disait, Mme Michu qui voit son PC planter, elle se dira que c'est pas la fin du monde, et des Mme Michu, y'en a beaucoup ; autant l'admin sys qui a un utilisateur au téléphone toutes les minutes à cause de plantages intempestifs, c'est plus gênant.
[^] # Re: Comme d'hab
Posté par Croconux . Évalué à 2.
Il faut également rappeler que W7 n'est pas un OS serveur (limitation du nombre de connexion, etc). C'est Windows Server 2010 qui sera la version serveur basée sur W7.
[^] # Re: Comme d'hab
Posté par Kerro . Évalué à 4.
Et c'est utilisé en vrai.
[^] # Re: Comme d'hab
Posté par Olivier (site web personnel) . Évalué à 6.
Parmi les cas très classiques d'infection, il y a le portable pro de l'employé utilisé pour terminer un rapport pendant le WE, et utilisé pour surfer sur le web (éventuellement à titre professionnel, par exemple pour faire des recherche). Le portable se prend un virus à ce moment-là, et le ramène tranquillement dans le réseau de l'entreprise, le lundi matin...
Le routeur/firewall/proxy de la boîte est ainsi complètement contourné, et le virus peut ainsi se farcir tout le joli réseau interne en 192.168.x.y/10.x.y.y, avant éventuellement de se lancer à des connexions externes.
[^] # Re: Comme d'hab
Posté par suJeSelS . Évalué à 4.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Euh non, c'est Windows Server 2008 R2, qui est sorti en meme temps que Win7
[^] # Re: Comme d'hab
Posté par Dabowl_92 . Évalué à 4.
Donc si je comprends bien :
si la version grand public de windows seven avait été appelée Windows vista R2, cela aurait été un flop commercial dû à la mauvaise image qu'a vista ; donc pour se refaire une virginité il a été renommé en Windows Seven.
si la version serveur de windows seven s'appelle 2008 R2, moi ce que je comprends c'est que les changements liés à seven ne sont pas si profonds et/ou nombreux que ça.
Ils sont forts en marketing $krosoft !
Enfin bon je dis ça mais je poste depuis un vista (qui marche très bien).
[^] # Re: Comme d'hab
Posté par patrick_g (site web personnel) . Évalué à 9.
Je pense qu'à ce stade il doit y avoir fort peu d'administrations ou d'entreprises qui utilisent Seven (il est sorti il n'y a pas longtemps).
Peut-être que Microsoft se dit que ça n'urge pas quand ce sont des particuliers qui sont impactés ?
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 1.
a) On ne s'est jamais dit que ca n'urge pas
b) Sortir un patch ca prend du temps si on veut faire les choses correctement, t'as pas envie de sortir un patch qui corrige le probleme et qui casse le protocole en retour, ou cree un memory leak, ou autre, resultat faut le tester et ca prend du temps.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
c) Ce bug c'est un DoS, pas un EoP, alors oui ca peut un peu emmerder les societes, mais au final c'est pas un truc qui va les mettre serieusement en danger, le jour ou un laptop debarque dans la societe il fera tomber qqe serveurs, il sera vite localise et ca sera regle. C'est chiant, ca a un impact, mais c'est pas un _vrai_ danger vu que c'est pas qqe chose d'expose a internet (e-business toussa).
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Il est possible que certaines applications ne supportent pas les arrêts brutaux sans risque de corruption de données, c'est pour ça, notamment, qu'on met des ups aux serveurs.
C'est clair que ce n'est pas la fin du monde, mais c'est déjà très problématique. Un serveur qui démarre c'est quoi, 10-20 minutes. Après un arrêt un peu brutal tu fais quand même un petit scandisk, serveur de fichiers (dans un pme) 500Go, c'est pas fait en trois secondes.
Donc je dirais 30 minutes d'interruption (et c'est court encore). Tu as 20 employés que tu paies disons 4000.-/mois (c'est pas mirobolant), donc 250.- de perdu. 50 employés, 650.- de perdu. Durant le mois ça peut arriver plusieurs fois. Ce qui qui paie ? Microsoft ?
Le partage de fichier est quand même une fonction de base d'un serveur. Si celle-ci est défectueuse au point de pouvoir empêcher l'entreprise de fonctionner de manière aléatoire durant une demi-heure, c'est un problème.
Une vrai réponse de Microsoft aurait été un patch disponible rapidement mais pas super-testé et tout. Après l'administrateur décide si ce patch est nécessaire ou pas, c'est le minimum.
Microsoft n'est pas à la hauteur en terme de réactivité depuis toujours et ce n'est pas prêt de changer.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Tout a fait, mais ce n'est pas le cas, faut que tu sois attaque pour que ce soit le cas.
Si demain on voit que les attaques se multiplient, on sortira le patch en le testant moins, mais jusqu'a aujourd'hui il n'y a aucune raison de couper les tests.
Une vrai réponse de Microsoft aurait été un patch disponible rapidement mais pas super-testé et tout. Après l'administrateur décide si ce patch est nécessaire ou pas, c'est le minimum.
Non pas du tout, car nombre de gens utilisent les updates automatiques, leur balancer un patch pas teste pourrait leur crasher leur systeme si il y a un probleme, pas vraiment une bonne idee.
La vraie reponse c'est de voir ce qui se passe dans le monde reel, tu regardes autour de toi, tu verras que cette vulnerabilite n'est pas exploitee activement, personne n'est sous un deluge d'attaques ou autre, donc aucune raison de sortir un patch bacle.
Microsoft n'est pas à la hauteur en terme de réactivité depuis toujours et ce n'est pas prêt de changer.
Au contraire, entre un patch teste et un patch non teste, j'ai tres tres vite fait mon choix, surtout dans ce cas ou ce n'est visiblement pas exploite activement.
Faut que vous sortiez un peu de votre petit monde et vous rendiez compte que sortir un patch pour des millions de systemes utilises dans un tas de configs differentes par des gens souvent pas competents, c'est pas aussi simple qu'ecrire 3 lignes de code, compiler et jeter ca sur le net.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Mais j'ai parlé du système de mise à jour ? Un exe qu'on puisse aller télécharger sur le site. Simplement.
Faut que vous sortiez un peu de votre petit monde et vous rendiez compte que sortir un patch pour des millions de systemes utilises dans un tas de configs differentes par des gens souvent pas competents, c'est pas aussi simple qu'ecrire 3 lignes de code, compiler et jeter ca sur le net.
Toi sors de ton monde. Il y a des administrateurs très capables qui sont prêt à mettre en patch qui demande de redémarrer le serveur en fin de journée si cela permet de ne pas risquer de faire perdre de l'argent (et donc sa place) à son patron.
Tu as déjà bossé dans du service ? Le serveur il doit jamais planter, faire le café au boss, trouver les clés de la voiture, ... bref résoudre tous les problèmes.
Le fournisseur d'accès se broute et la connexion internet est perdue : "dring ... Allo ? Internet marche pas, il faut réparer. Mais c'est votre fournisseur d'accès qui a un problème. M'en fout, vous venez me réparer ça tout de suite ... tut tut tut"
Facile tes quelques millions de couillons, mais sors des labs de Microsoft et va dans une vrai PME (ce qui reste le gros du marché de Microsoft) et viens ensuite nous parler des tes problèmes de patch pas iso-machin-chose.
Il faut des solutions (des workarounds) dans les 5 minutes. C'est pas parfait, mais ça permet d'éviter le pire et pour un truc tip-top pile-poil, ça peut attendre.
C'est pour ça que mettre Microsoft dans une PME c'est de la connerie pur et simple.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
Ca ne regle qu'une partie du probleme, ca laisse ces PMEs qui comptaient sur les updates automatiques dans la mouise, ca nous oblige a tester un truc 2x alors que rien ne presse vraiment pour le moment ce qui nous fait perdre du temps, ...
Toi sors de ton monde. Il y a des administrateurs très capables qui sont prêt à mettre en patch qui demande de redémarrer le serveur en fin de journée si cela permet de ne pas risquer de faire perdre de l'argent (et donc sa place) à son patron.
Tout a fait, il y en a. Il en y a aussi enormement parmis eux qui vont faire la chose suivante :
- Attendre qu'on sorte le patch teste, car ils ne sont pas attaques
La plupart suivent les mailing-lists de securite et regardent si la vulnerabilite est activement exploitee pour decider si ils doivent sortir de leur cycle de patch ou pas, dans le cas present la reponse est toute claire : non
Tu as déjà bossé dans du service ? Le serveur il doit jamais planter, faire le café au boss, trouver les clés de la voiture, ... bref résoudre tous les problèmes.
Le fournisseur d'accès se broute et la connexion internet est perdue : "dring ... Allo ? Internet marche pas, il faut réparer. Mais c'est votre fournisseur d'accès qui a un problème. M'en fout, vous venez me réparer ça tout de suite ... tut tut tut"
Le truc que malheureusement tu ne comprends pas, c'est qu'avant, on sortait les patchs a peu pres comme tu le demandais, et on a change... Pourquoi ? Parce que les entreprises nous l'ont demande...
Facile tes quelques millions de couillons, mais sors des labs de Microsoft et va dans une vrai PME (ce qui reste le gros du marché de Microsoft) et viens ensuite nous parler des tes problèmes de patch pas iso-machin-chose.
Justement, la methode qu'on applique, elle vient de nos clients.
Il faut des solutions (des workarounds) dans les 5 minutes. C'est pas parfait, mais ça permet d'éviter le pire et pour un truc tip-top pile-poil, ça peut attendre.
Tout a fait, c'est pour ca que dans nos advisories on donne les workarounds quand il y en a. Mais le patch lui, si il peut attendre d'etre teste, on ne le sortira que teste.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Ensuite ce n'est pas à Microsoft de décider si c'est exploitable ou pas. Si j'en parle à mon apprenti de ce problème, ben tu peux être certain qu'au cours il va bien s'amuser avec les serveurs de l'école. Donc avoir le choix de pouvoir appliquer un patch risquer ou attendre la version finale, c'est un choix qu'un administrateur devrait pouvoir faire (et si je serais dans une école, par exemple, je choisirais le patch moisi). Mais comme vous prenez tous vos clients pour des cons, c'est clair que vous faites vous ce choix.
Le système de diffusion des patchs étaient décriés parce qu'il redémarrait le serveur automatiquement (même si c'était un patch qui changeait le fond d'écran). Donc les entreprises en avaient un peu plein l'os de voir leurs serveurs redémarrer de manière aléatoire. Donc oui, c'est insupportable de vivre avec une épée de Microsoft au-dessus de la tête ("Mon serveur redémarrera aujourd'hui ?").
Donc il faut arrêter de mettre la faute sur vos clients, vos clients ont choisi entre :
1) Redémarrage aléatoire automatique, mais toujours la dernière mise à jour
2) Un mois d'exposition mais on sait qu'on redémarre un jeudi par mois.
C'est un choix fantastique que Microsoft propose ... Vraiment ...
Finalement à vous cachez derrière "on doit tester pour que ce soit super parfait", montres bien que vous avez préférez protéger la campagne de marketing au lieu de la sécurité, un patch critique en période de lancement aurait fait trop de vagues.
Microsoft n'est pas un partenaire efficace quand on parle de sécurité, c'est connu et reconnu pas par hasard.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
Non ce n'est pas rien, mais ce n'est pas la fin du monde non plus.
Ensuite ce n'est pas à Microsoft de décider si c'est exploitable ou pas. Si j'en parle à mon apprenti de ce problème, ben tu peux être certain qu'au cours il va bien s'amuser avec les serveurs de l'école. Donc avoir le choix de pouvoir appliquer un patch risquer ou attendre la version finale, c'est un choix qu'un administrateur devrait pouvoir faire (et si je serais dans une école, par exemple, je choisirais le patch moisi). Mais comme vous prenez tous vos clients pour des cons, c'est clair que vous faites vous ce choix.
Ben oui evidemment qu'on prend tous nos clients pour des cons...
Le système de diffusion des patchs étaient décriés parce qu'il redémarrait le serveur automatiquement (même si c'était un patch qui changeait le fond d'écran). Donc les entreprises en avaient un peu plein l'os de voir leurs serveurs redémarrer de manière aléatoire. Donc oui, c'est insupportable de vivre avec une épée de Microsoft au-dessus de la tête ("Mon serveur redémarrera aujourd'hui ?").
Notre systeme n'a _jamais_ redemarre un serveur automatiquement, tu racontes n'importe quoi.
C'est un choix fantastique que Microsoft propose ... Vraiment ...
Visiblement tu n'as rien compris au systeme d'update de MS, heureusement que tu n'es pas mon admin.
Finalement à vous cachez derrière "on doit tester pour que ce soit super parfait", montres bien que vous avez préférez protéger la campagne de marketing au lieu de la sécurité, un patch critique en période de lancement aurait fait trop de vagues.
Oui bien sur, ca montre bien a quel point tu ne sais pas de quoi tu parles. On a deja sorti des patchs de securite pour Win7 depuis Octobre.
Microsoft n'est pas un partenaire efficace quand on parle de sécurité, c'est connu et reconnu pas par hasard.
Malheureusement pour toi c'est exactement l'inverse, MS est reconnu pour etre maintenant a l'avant-garde de ce cote dans le monde de la securite apres s'etre pris une claque qu'on pourrait qualifier d'enorme en 2002-2003.
Si tu demandes a des boites genre IOActive, Leviathan ou autre quelle boite il faut copier niveau securite, un des premiers noms que tu entendras est MS. C'est pas par hasard que Mozilla est alle chercher sa directeur de securite chez nous hein(Window Snyder, qui est partie de Mozilla depuis).
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Mais c'est ça que je critique. Ce n'est pas à vous de juger de la gravité de la situation. Celui qui a des apprentis informaticiens entre 16 et 18 ans et qui a des serveurs Windows 2008 R2, je penses qu'il doit trembler actuellement. C'est un exemple concret.
Et il y a bien d'autres situations (ou pas, je n'ai pas pensé à toutes les situations) où l'administrateur voudrait pouvoir patcher ça au plus vite.
Notre systeme n'a _jamais_ redemarre un serveur automatiquement, tu racontes n'importe quoi.
J'ai souvenir d'une boîte de dialogue qui venait tout les X temps et laissait X minutes avant de redémarrer automatiquement.
Visiblement tu n'as rien compris au systeme d'update de MS, heureusement que tu n'es pas mon admin.
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.
une claque qu'on pourrait qualifier d'enorme en 2002-2003
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)).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Rooh, sois sérieux, éteindre un serveur à distance il me semble que c'est grave. Suffisamment pour avoir un patch critique,
mais j'ai comme la drole d'impression que je sais 10x mieux de quoi je parles que toi.
Expliques au lieu de simplement nier (avec des sources, si possible, car tu ne mets jamais de source, c'est lourd à la fin).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Debian tu peux, par exemple, faire les mises à jour de tout, sauf ce qui nécessite un redémarrage. Prenez-en de la graine.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par thedude . Évalué à 1.
Installer la mise a jour automatiquement et redemarrer manuellement, c'est strictement identique a downloader la mise a jour automatiquement et l'installer+rebooter manuellement, vu que l'install sans reboot ne sert pas a grand chose.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
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).
vu que l'install sans reboot ne sert pas a grand chose.
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Désolé, c'est moi qui suit du côté pratique, tu ne peux pas utiliser ce mot ...
<i>sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem.</i>
... 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).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
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
[^] # Re: Comme d'hab
Posté par tuxsmouf . Évalué à 2.
Honnetement, j'aurai moins la haine envers les serveurs microsoft si côté MAJ, c'etait aussi bien geré qu'une debian par exemple.
"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."
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/).
En pratique pour avoir du microsoft en serveur depuis avril, c'est rare quand l'uptime depasse 1 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).
Un windows non mis à jour risque de tenir moins longtemps si les utilisateurs ont moyen, sans le vouloir, de faire rentrer virus, vers et compagnie par la "porte de derriere".
En ce qui me concerne, je met à jour mes serveurs debian par choix (parce qu'on ne sait jamais) et mes serveurs windows par obligation (parce que sans les MAJ, ils vont se faire "demonter" un jour ou l'autre les pauvres).
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Ce que fait le dpkg dans ce cas là, il arrête le service utilisant la bibliothèque, remplace le fichier et démarre le service.
Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres
Debian gère ça automatiquement. Lorsque tu mets à jour une bibliothèque genre openssl, il te mets la liste de tous les services devant être redémarrés. Tu peux décider de ne pas redémarrer un en le supprimant de la liste.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Donc la réponse est oui. dpkg te gère tout. Mais dans certain cas tu dois prévoir manuellement la possibilité X ou Y (les cas où tu ne reçois pas de .deb tout bien fait).
Et tu peux même faire plus que ça, tu peux gérer ta configuration avec, tu peux prévoir de faire des retours en arrière automatique en cas de mise à jour foireuse (ce qui n'arrive jamais, mais ça m'avait été demandé de prévoir un cas comme ça pour une certification ISO-1664).
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
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.
Enfin je me demande un truc : tu as déjà installé un logiciel ? Parce que j'ai des doutes, t'es un peu à côté de la plaque là.
Ce systeme de gestion de paquets ne resoud rien car il ne represente pas l'entier du systeme et ses dependances.
Si justement c'est une vue de tout ton système et toutes le dépendances
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
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).
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Ah oui, quand on ne sais pas se servir d'un gestionnaire de paquet, on peut imaginer que c'est difficile. Alors, pour obtenir la liste des paquets installes sur la machine, c'est une ligne de shell, pour savoir quels sont les paquets qui utilisent openssl, c'est une autre ligne de shell, reste ensuite a croiser les deux liste, ce qui doit se faire avec une troisieme ligne de shell (j'ai meme pas chercher à savoir s'il y avait une commande qui faisait déjà les trois opérations).
Et je doute que distribuer ca sur une liste de machines avec ssh ca soit vraiment plus compliqué...
Mais bon, je te comprends, tu n'as pas l'habitude...
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 2.
En fait, j'ai répondu directement a la question de pBpG, a savoir comment on fait pour trouver la liste des packages qui utilisent openssl, et je ne me suis pas soucié de savoir si le gestionnaire de paquet (qui connait bien sur cette info) s'en servait pour redémarrer automatiquement les services concernés... mais bon, evidemment, j'aurais pu me douter qu'il le faisait, parce qu'il le peut et que c'est super utile.
Bref, faut que je révise mon gestionnaire de paquet, il est encore plus puissant que je ne l'imaginais.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Et tu sais, Windows c'est incomplet, nombre de soft qui ne sont pas disponible du tout (et qui font parties des softs métiers).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 2.
J'ai donné une méthode manuelle en trois ligne de shell, et Etienne a précisé que le gestionnaire de paquet utilisait déja cette fonctionnalité pour les mises à jour.
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 ?
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.
- Et on a même la possibilité de créer des paquets "fictifs" pour que le gestionnaire de paquets prenne en charge les logiciels externes.
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.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 2.
Content de te faire rire, sache que toi aussi tu m'amuses beaucoup.
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.
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.
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.
Inutile de me retourner la question, la reponse est que c'est une chose impossible a faire quel que soit le systeme.
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 !
a) Oui, mais c'est plutot utopique
b) Oui, idem sous Windows en fait
Ben oui, quand on ne sais pas faire a), on fait systematiquement b), mais c'est pas glorieux.
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.
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.
Et puis... tu sais, il y a un truc qui s'appelle dpkg sous Debian, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Quand a faire un pseudo-package, j'ai demontre plus haut que non, ce n'est pas faisable pour bon nombre de softs.
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.
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, ...
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".
C'est triste que tu ne saches pas de quoi tu parles.
Je crois qu'il sait de quoi il parle, tu dois te tromper.
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.
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
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, ...
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
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.
resultat c'est absolument deconseille.
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.
Clairement non
Par contre toi tu ne sais pas de quoi tu parles et ça c'est certain.
Le probleme de MSI est le meme que .deb : ils ne couvrent pas tous les softs, les paquets ne sont pas tous detailles completement, ...
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.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
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.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Tu peux sûrement passer par un module noyau qui intercepte les chargements de librairies et transmet ça à un daemon qui s'occupe de mettre à jour le système de paquet.
Avec des outils d'analyse d'exécutable tu peux savoir si le logiciel fait appel à des fonctions de chargement de librairies et donc tu peux savoir quel librairie est appelée.
Tu peux décompiler le logiciel et le comprendre.
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.
??? Redémarrer un logiciel c'est compliqué ? Houlà mais attends, on parle de logiciel, pas de centrales nucléaires ... Tu veux pas une aspirine par hasard ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Tu peux sûrement passer par un module noyau qui intercepte les chargements de librairies et transmet ça à un daemon qui s'occupe de mettre à jour le système de paquet.
C'est tres propre ca, comme ca tu apprendras que Firefox depend de 5235 packages differents(tu sais, tous ces plugins), ce qui est faux.
Tu peux décompiler le logiciel et le comprendre.
Super ca, va t'amuser a decompiler Oracle qu'on rigole, surtout lorsqu il generera le nom des libs a charger dynamiquement.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Je n'ai jamais prétendu connaitre MSI, relis bien ce que j'ai écrit. J'ai juste déclaré avoir compris, d'après la description que tu en donnais, que MSI ne devait pas gérer les dépendances. Parce que s'il était capable de le faire, il devrait pouvoir s'en servir intelligemment (ne pas redemarrer si necessaire).
MSI gere les dependances, il est capable de te trouver tous les packages dependant du binaire X,
Ah, fantastique, MSI est capable de faire "une chose impossible a faire quel que soit le systeme", selon tes propres termes. J'espère que c'est breveté, au moins.
Mais bon, je ne sais pas de quoi je parle, alors je vais te laisser dans tes certitudes, tu a forcément raison.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Il le fait jusqu'a un point, comme .deb, c'est pas une methode sure a 100%
Ah, fantastique, MSI est capable de faire "une chose impossible a faire quel que soit le systeme", selon tes propres termes. J'espère que c'est breveté, au moins.
MSI fait la meme chose que .deb : il regarde sans sa base de donnees pour un fichier X, et sait quel package est marque comme dependant de X, ca veut pas dire que cette methode est suffisante et infaillible.
Mais bon, je ne sais pas de quoi je parle, alors je vais te laisser dans tes certitudes, tu a forcément raison.
Clairement, parce que tu n'arrives pas a faire la difference entre la description d'un package et la realite, c'est pas forcement la meme chose.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Fantastique, j'espere que c'est breveté. Plaisanterie mise à part, si MSI est capable de faire ceci, pourquoi ne pas laisser le choix a l'admin : lui proposer le reboot systématique (finfaillible) ou seulement d'après le calcul de dépendances de MSI (avec une fiabilité non garantie) ?
Clairement, parce que tu n'arrives pas a faire la difference entre la description d'un package et la realite, c'est pas forcement la meme chose.
Oui, tu as absolument raison, la description d'un package peut etre differente de la realité. Dans ce cas, la description est erronée, c'est un bug, on demande a ce que cela soit corrigé, ou on le corrige soit meme.
Si les logiciels ne sont pas correctement intégrés à la plateforme, ou si les administrateurs travaillent comme des pieds, alors le systeme de gestion de paquet n'est pas fiable. On est bien avancé, là, c'est pas la peine d'aller plus loin, on le savait dès le départ.
Maintenant, pose toi la question de savoir pourquoi tu supposes être dans cette situation, alors que je fais exactement la supposition inverse ? Indice: les mauvaises habitudes d'administration et de développement propagées par un certain OS depuis des années.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Parce que c'est un choix de merde, pourquoi donc proposer :
a) Ca marche a coup sur
b) On a aucune idee de si ca marche, et si ca marche pas tu ne le sauras pas
b) est extremement dangereux a proposer, partant de la, c'est un choix de merde.
Oui, tu as absolument raison, la description d'un package peut etre differente de la realité. Dans ce cas, la description est erronée, c'est un bug, on demande a ce que cela soit corrigé, ou on le corrige soit meme.
Non, je t'ai donne l'exemple plus bas d'un plugin externe charge par un soft, ce plugin est externe au soft, il n'est donc pas reference par le package de ce soft. C'est au contraire le package du plugin qui reference le soft.
Si les logiciels ne sont pas correctement intégrés à la plateforme, ou si les administrateurs travaillent comme des pieds, alors le systeme de gestion de paquet n'est pas fiable. On est bien avancé, là, c'est pas la peine d'aller plus loin, on le savait dès le départ.
Maintenant, pose toi la question de savoir pourquoi tu supposes être dans cette situation, alors que je fais exactement la supposition inverse ? Indice: les mauvaises habitudes d'administration et de développement propagées par un certain OS depuis des années.
Oh mais la reponse a la question est tres simple : J'ai raison et toi non, car plutot que partir sur l'idee que tout est parfait sous Linux je regardes la realite. Les logiciels sous Linux ne sont pas tous integres a la plateforme, et nombre d'admins travaillent comme des pieds. Et cela n'a bien entendu rien a voir avec Windows, c'est un probleme general.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
ce plugin est externe au soft, il n'est donc pas reference par le package de ce soft. C'est au contraire le package du plugin qui reference le soft.
Il est ou le probleme, la ? Le plugin référence le soft, le plugin est mis a jour, le plugin dit coucou au soft, tu redemarres s'il te plait ?
Tu es vraiment sur de savoir de quoi tu parles ?
Oh mais la reponse a la question est tres simple : J'ai raison et toi non, car plutot que partir sur l'idee que tout est parfait sous Linux je regardes la realite. Les logiciels sous Linux ne sont pas tous integres a la plateforme, et nombre d'admins travaillent comme des pieds.
Ah oui, tu as raison et moi non, ca c'est de l'argumentation béton, heureusement qu'on est vendredi.
Effectivement, nombre d'admins travaillent comme des pieds, mais c'est pas une raison pour empecher les bons admins de travailler correctement.
Je te laisse répondre une dernière fois, parce que j'ai l'impression qu'on va diminuer ton bonus si tu n'as pas le dernier mot sur chaque fil, mais après, j'arrête, ta mauvaise fois me fatigue.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Oui, si on fout le merdier intentionnellement, apres ca marche moins bien. Dis moi quelque chose que je ne sais pas, s'il te plait.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
C'est ca la beaute du systeme de packaging sous Linux, il garde tout propre, sauf si tu decides d'installer un soft qui n'etait pas prevu.
C'est sympa quand tu veux la derniere version d'un soft ca.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Et quand c'est pas prévu, on t'a déja donné la solution, plusieurs fois. Mais bon, il semble que tu ne veux pas comprendre.
Tiens, tu as parlé de Oracle plus haut... La version Express 10g est disponible sous forme de paquets .rpm et .deb ... Comme quoi, il suffit que les editeurs s'y mettent.
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
Dis-moi, quand ton Oracle il charge un plugin externe sous forme de librairies dynamique, tu le sais comment ?
Le systeme de packaging ne reference pas le .so dans le paquet Oracle vu que c'est un plugin externe a Oracle, tu n'as aucun moyen de savoir qu'Oracle l'a charge.
Tu pourrais t'amuser a trouver tous les packages dependant d'Oracle, mais la encore, ca ne te dit rien sur le fait que la lib est chargee ou pas en ce moment par un des executables Oracle, ...
Faut vous reveiller, le systeme de packaging il est la pour une chose : decider de quelles binaires sont necessaires au fonctionnement d'un soft et etre capable de les updater. Il est pas la pour gerer le redemarrage de softs lors d'une update, il n'en est tout simplement pas capable.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Je supposes qu'Oracle a pris le temps de faire un vrai paquet qui indique les dépendances, parce que sinon c'est sympa, t'installes le paquet d'Oracle, tu démarres, ça ne marche pas parce qu'il manque la lib XYZ. Tu installes la lib XYZ, tu démarres, ça marche pas parce qu'il manque la lib ABC, ... Je penses pas qu'Oracle souhaite passer pour une bande de charlot ? Donc ils auront certainement mis les bonnes dépendances pour que lors de l'installation du paquet, le système de gestion aille chercher toutes les dépendances nécessaires et lorsque tu démarres, ça fonctionne.
Mais je peux me tromper, Oracle est peut-être une bande de charlot.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Oui, je pense qu'il le fait exprès. Et tout son discours semble basé sur le fait que le vendeur d'un logiciel (par exemple Oracle) a un interêt quelconque a ne pas donner dans les informations du paquet les informations nécessaires a son bon fonctionnement. Je pense personnellement que ca doit venir d'une déformation professionnelle de sa part...
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Un plugin externe est par definition qqe chose qui n'est pas necessaire au fonctionnement, c'est un plugin.
Le fait qu'il soit externe signifie que Oracle ne connait peut-etre meme pas son existence.
Ca ne rend pas moins probable le fait que ce plugin soit charge par Oracle.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Je comprends mieux pourquoi Windows est une bouse sans nom. Je comprends mieux pourquoi je ne fais pas confiance au logiciel propriétaire.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Je me demandes, tu comprends ce qu'est un plugin ?
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Plugin X pour Firefox utilises disons Nautilus pour afficher qqe chose quand tu cliques sur un lien.
Partant de la, le package du plugin a au moins 2 dependances :
- Firefox
- Nautilus
et il n'y a aucune difference dans la definition de la dependance entre ces 2, car le systeme de dependance de .deb est basique : il te permet de dire de quel package ton package depend, et si ce package est necessaire, optionel, recommande, ...
L'enorme difference avec l'utilisation est que le plugin qui est une librairie est charge dans l'espace d'addresse de Firefox, mais pas dans Nautilus, c'est la librairie qui lance Nautilus.
Resultat, si tu updates ce plugin, il faut redemarrer Firefox, mais pas Nautilus, et le systeme de packaging n'a _aucun_ moyen de savoir la difference.
Alors soit il se mettra a redemarrer des trucs non-necessaire, avec le potentiel de redemarrages en cascade a cause des dependances, soit il ne fait rien.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
L'art de dire n'importe quoi afin de noyer le poisson dans l'eau.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Firefox et Nautilus etaient pris comme exemples pour illustrer le fait que le systeme de dependances n'est pas capable de gerer les redemarrages.
Tu peux les remplacer par des softs serveurs, ca revient au meme.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Oui en trouvant toujours une solution au problème que tu essaies de faire exister.
Bon je vais être bref parce que j'en ai un peu marre. Chaque fois qu'un logiciel charge un plugin, il y a moyen de le savoir puisque cela passe par diverse appelle dans les librairies de base du système et par le noyau du système. Celui qui veut faire le système tip-top nikel chrome il peut exploiter cette information et tenir à jour la liste des dépendances.
Ensuite les plugins sont souvent ajouté par l'administrateur donc celui-ci sait ce qu'il fait ou alors documenter par le fabricant du logiciel. On est pas chez Microsoft là, les logiciels qu'on installe sur des serveurs on lit la documentation avant et on a généralement une documentation assez complète et suffisante pour faire une intégration correcte.
Ce que tu essaies de prouver c'est qu'un système qui ne redémarre que quand c'est nécessaire lors des mises à jour n'existe pas. Moi je te dis il existe. Et toutes les théories que tu avances sont anéantis par le simple fait que j'ai des serveurs qui ne redémarrent seulement quand il y a mis à jour du noyau, ceux-ci font le partage des données (samba), la gestion des comptes utilisateurs (LDAP et tout), partage d'impression, réseau (dhcp, dns, ...), mail (Exim, dovecot), calendrier (caldav), agenda (LDAP). C'est déjà une bonne partie de l'infrastructure nécessaire en entreprise et c'est même la seule partie nécessaire dans la plus part des PME. Et ça ce n'est pas faisable sur le système de ton boss parce que c'est plus simple de forcer à tous redémarrer que de documenter une fois pour toute et de manière ouverte le système complet.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Oh ben bien sur qu'il y a moyen de le savoir. Mais ce n'est pas le systeme de dependances.
Maintenant dis-moi, tu connais qq'un qui utilise ce systeme ? Tu me trouves un lien sur ce systeme pour que je puisse l'utiliser demain ?
Non, il n'existe pas, pour une raison bien simple: si tu fais cela tu pourris la base de donnees des dependances avec des infos qui sont _fausses_ , un plugin n'est pas une dependance dans le sens Soft -> plugin mais dans l'autre sens.
Ensuite les plugins sont souvent ajouté par l'administrateur donc celui-ci sait ce qu'il fait ou alors documenter par le fabricant du logiciel. On est pas chez Microsoft là, les logiciels qu'on installe sur des serveurs on lit la documentation avant et on a généralement une documentation assez complète et suffisante pour faire une intégration correcte.
Oh joli la petite pique, mais sois honnete plutot que sortir des aneries sur MS. Que le plugin soit installe oui, mais ca ne veut pas dire qu'il est charge.
Ce que tu essaies de prouver c'est qu'un système qui ne redémarre que quand c'est nécessaire lors des mises à jour n'existe pas. Moi je te dis il existe. Et toutes les théories que tu avances sont anéantis par le simple fait que j'ai des serveurs qui ne redémarrent seulement quand il y a mis à jour du noyau, ceux-ci font le partage des données (samba), la gestion des comptes utilisateurs (LDAP et tout), partage d'impression, réseau (dhcp, dns, ...), mail (Exim, dovecot), calendrier (caldav), agenda (LDAP). C'est déjà une bonne partie de l'infrastructure nécessaire en entreprise et c'est même la seule partie nécessaire dans la plus part des PME. Et ça ce n'est pas faisable sur le système de ton boss parce que c'est plus simple de forcer à tous redémarrer que de documenter une fois pour toute et de manière ouverte le système complet.
Ce qui est triste, ce que tu ne comprends meme pas le sujet dont tu parles.
Oui ton systeme il ne reboote pas, ca ne veut pas dire qu'il a ete patche correctement !
Moi j'attends que tu m'expliques comment ton dpkg il regle le probleme que j'ai donne plus haut, et je veux la maniere de le regler en pratique, pas en theorie, si demain tu dois le faire, quelles commandes tu tapes, quel soft tu lances, parce que je suis sur a 100% que tu n'appliques pas cette technique d'interception de syscalls pour trouver les dependances, et que personne ne le fait.
[^] # Re: Comme d'hab
Posté par shbrol . Évalué à 1.
Et puis, surtout, n'oublie pas que nous ne savons pas de quoi nous parlons, contrairement à lui, qui affirme, je cite : le systeme de dependance de .deb est basique.
On devrait lui suggérer de faire une recherche sur les mots-clefs dpkg triggers, ca pourrait peut-être lui apprendre quelque-chose.
Mais quel clown...
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à 0.
Mais je serais ravi que tu m'expliques comment ton adorable dpkg resoud le probleme que j'ai donne plus haut, et je veux un exemple pratique de resolution qui puisse s'appliquer de maniere generale, pas un hack qui marche dans 1 cas et pas l'autre.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
PS: Tu noteras que j'ai une haine particulière envers Exchange, mais c'est le résultat de longues nuits blanches.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
En _pratique_ (donc si je voulais le faire demain, comment je ferais), tu fais comment pour :
a) Avoir les bonnes dependances et ne pas en rater y compris avec des softs non-packages originellement
b) T'assurer que ton systeme de dependances ne te sort pas 2353 softs qui n'ont rien a voir , parce qu'un plugin comme je te l'ai demontre ,ca peut dependre de tout un tas de trucs ayant un executable ou daemon parmis eux sans etre forcement charge dans leur espace d'addresse.
Quelles sont les commandes que tu utilises pour faire a) et b) de maniere efficace (c'est a dire que ca marche 99% du temps, par opposition a un hack qui marche 20-30% du temps)
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Comme d'hab
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Je te laisses relire la discussion en entier si tu la veux ta réponse, mais moi c'est mon dernier poste sur ce sujet.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Comme d'hab
Posté par pasBill pasGates . Évalué à -1.
Par exemple ton idee d'utiliser strace qui finirait par donner des centaines de dependances a un soft (car sa lib charge une autre lib, qui en charge une autre, etc...), qui a un impact reel sur ses perfs et qui donc empeche son utilisation sur machines de prod, etc...
Tu sais parfaitement que personne n'utilise les techniques que tu as donnees, car elles ne fonctionnent pas dans la vraie vie.
[^] # Re: Comme d'hab
Posté par tuxsmouf . Évalué à 3.
Le fait même qu'une personne malveillante puisse rentrer dans les locaux et reussir à se plugger sur le reseau sans que cela ne derange personne est déjà un gros problème de securité.
La securité informatiqye ne s'arrête pas au système d'exploitation...
# Ah bin zut alors
Posté par tuXico . Évalué à 10.
Heureusement dans Windows (after)Eight, on aura une commande pour savoir qui a le droit de le faire.
Ouf, sauvés.
# super
Posté par TImaniac (site web personnel) . Évalué à -10.
- Madame Michu sur son 7 Home Premium a le firewall avec ces ports de bloqué par défaut sur sa connexion internet.
- Une entreprise utilise un firewall qui bloque déjà ces ports vers l'extérieur de l'entreprise.
En gros, 99,9% des utilisateurs s'en foutent.
En attendant avec Seven vous pouvez oublier vous servir de samba pour quelques temps
Bah oué, moi je m'en sers et cette faille ne m'inquiète absoluement pas, dingue n'est ce pas ?
[^] # Re: super
Posté par tuxsmouf . Évalué à 2.
ça me fait d'ailleurs penser à conficker qui utilise aussi en partie une vulnerabilité netbios des windows 2000 à vista (je suppose, pas le 7) dont le patch existe depuis un moment.
Il s'est pas glissé de l'exterieur, mais bel et bien de l'interieur et pas que chez Mme Michu...à son travail aussi (comme par hasard ^^).
[^] # Re: super
Posté par TImaniac (site web personnel) . Évalué à -1.
Et pour cause, à part un admin boulet en entreprise qui aurait ouvert _volontairement_ les ports SMB vers l'extérieur, la menace ne peut que venir d'un intranet. Un ver peut bien sûr être un vecteur, m'enfin bon l'intérêt de faire un DoS depuis l'intérieur d'une entreprise, voilà quoi.
Pour l'instant à part 01Net, personne ne juge cette faille critique.
Suffit de voir le bulletin sur secunia : http://secunia.com/advisories/37347/
Franchement c'est juste bon pour la presse people informatique et notre cher Albert, trop fier d'annoncer une faille dans Windows 7.
[^] # Re: super
Posté par Albert_ . Évalué à 6.
Tu disais?
[^] # Re: super
Posté par tuxsmouf . Évalué à 2.
Re-exemple avec conficker. ce dernier n'avait pas pour but de foutre le "brin" dans les reseaux d'entreprise...N'empêche qu'il a fait plus ou moins de degât. Ok pas de pertes d'infos, mais de ce que j'ai pu lire et voir, ça pouvait aller d'une hausse de l'activité réseau à la desactivation de comptes utilisateurs selon la strategie utilisée par l'entreprise en passant par la perte des partages de fichiers pour le serveurs non patchés.
[^] # Re: super
Posté par TImaniac (site web personnel) . Évalué à -2.
[^] # Re: super
Posté par Larry Cow . Évalué à 2.
[^] # Re: super
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 9.
J'aurais tendance à penser comme Timaniac :
1/ C'est une faille
2/ Elle est exploitable
3/ Elle m'empêche pas de dormir pour autant, vues les conditions d'exploitation.
Et aussi, les "ça fait même pas un mois", ça me lourde.
Comme si toutes les failles des LL mettaient 10 ans avant d'être découvertes…
Sans parler des failles dans le noyau linux qui touchent une branche entière… Mais dans ce cas là, non, on félicite plutôt le modèle de développement du LL…
Proprio ou libre, des bugs, y en a dans tous les logiciels, alors arrêtez de jouer à qui pisse le plus loin, car vous n'aurez pas toujours le vent dans le dos…
Puis bon, attendre la prochaine update avec le firewall en attendant, ça vaut bien attendre la prochaine update sans la 3D en attendant, hein !
[^] # Re: super
Posté par tuxsmouf . Évalué à 8.
Je me ligue pas contre leur faille mais contre leur politique à traiter le problème...Surtout quand leur pub de ***** met en avant un système "plus securisé"...
[^] # Re: super
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: super
Posté par tuxsmouf . Évalué à 8.
[^] # Re: super
Posté par Larry Cow . Évalué à 2.
D'un autre côté, le mec qui va vouloir exploiter cette faille risque de faire de même. Sinon, effectivement, le danger sera très limité.
Si tous les malfaisants de la planète avaient ton attitude ("moué, bof") face à une faille, on dormirait TOUS beaucoup plus tranquilles ;)
[^] # Re: super
Posté par pasBill pasGates . Évalué à -1.
Faudrait arreter de prendre les conneries d'Albert pour des realites hein, personne n'a dit qu'on ne prenait pas cette vulnerabilite au serieux.
[^] # Re: super
Posté par Albert_ . Évalué à 3.
[^] # Re: super
Posté par TImaniac (site web personnel) . Évalué à 1.
Remplace "Windows 7" par "Windows Server 2008" dans ma phrase, ça ne change strictement rien à mes propos : en entreprise la vulnérabilité ne peut être exploitée que si une seule condition est réunie : l'admin est un gros boulet, qui :
- a ouvert _volontairement_ les ports SMB vers l'extérieur
- navigue sur internet depuis le serveur SMB.
Sauf si t'es admin, la probabilité que la faille soit exploitée est très faible.
Bref tout le monde s'en fou, sauf toi bien sûr.
[^] # Re: super
Posté par GeneralZod . Évalué à 8.
Effectivement, tout va bien sous le Soleil.
[^] # Re: super
Posté par Gniarf . Évalué à 5.
exactement
[^] # Re: super
Posté par Albert_ . Évalué à -2.
[^] # Re: super
Posté par TImaniac (site web personnel) . Évalué à 4.
Comme qui dirait Windows 7 est sorti avant.
[^] # Re: super
Posté par pasBill pasGates . Évalué à 0.
WS08 R2 n'est pas WS08, c'est la version serveur de Win7, apprends a lire.
[^] # Re: super
Posté par Gniarf . Évalué à 4.
c'est un peu comme le SP2 ou le SP3 de XP, si tu veux dire que XP a 8 ans tu ne comptes pas les services pack dedans, mais si tu veux dire qu'il est encore tout frais tu parles de XP SP2 ou XP SP3 et ça nous donne 5 ans ou même seulement 18 mois \o/
à ce compte-là, Windows 2000 SP4etcetc n'a que 4 ans, mais c'est étonnant tu préfères ne parler que de Windows 2000 tout court puisque c'est à chaque fois pour ne plus avoir à supporter cet OS de trop^W^W^W^W^W fustiger son ancienneté et son horrible obsolescence technique, alors qu'à un an près...
[^] # Re: super
Posté par pasBill pasGates . Évalué à -1.
- Enlevement du dispatch lock
- RDP avec remoting de DirectX et video
- DirectAccess
- Live Migration pour HV
- Passage de HV a 64 CPUs
- DNSSEC
- BranchCache
...
Jamais un service pack n'a eu de features pareilles, et de loin
[^] # Re: super
Posté par Kerro . Évalué à 4.
Je dirais même: jamais un Windows n'a eu de features pareilles :-)
[^] # Re: super
Posté par thedude . Évalué à 4.
Histoire de profiter du compositing sur le bureau, malgre l'absence de carte 3d decente sur ledit serveur?
Pour la video par contre, je seche.
Ou alors c'est juste parce que ca vient du devleoppement pour la version client de l'os et que tant qu'a faire, vous l'avez pousse sur le serveur, histoire d'avoir une base de code commune?
[^] # Re: super
Posté par pasBill pasGates . Évalué à -1.
Idem pour la video(faut que ca passe par DirectShow je crois)
[^] # Re: super
Posté par thedude . Évalué à 0.
[^] # Re: super
Posté par suJeSelS . Évalué à 6.
Et tu fais comment pour te protéger de l'intérieur? Pour une PME avec trois pecnots dans un bureau ce n'est peut-être pas un problème. Quand tu as plusieurs milliers d'utilisateurs dans ton domaine, déjà c'est plus ennuyeux. Bref cette vulnérabilité est très critique.
# même pas un jour
Posté par Hugo Roy (site web personnel) . Évalué à 3.
Donc il faudrait retitrer ça : même pas une seconde :)
Ce qui est vraiment inadmissible c'est que Microsoft ait mis plus d'un mois à communiquer officiellement autour de cette faille....
[^] # Re: même pas un jour
Posté par Albert_ . Évalué à 3.
[^] # Re: même pas un jour
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: même pas un jour
Posté par Hugo Roy (site web personnel) . Évalué à 4.
La BSI, agence fédérale de sécurité informatique allemande.
[^] # Re: même pas un jour
Posté par dinomasque . Évalué à 0.
BeOS le faisait il y a 20 ans !
[^] # Re: même pas un jour
Posté par Hugo Roy (site web personnel) . Évalué à 4.
Threat level: "4 high risk" (out of 1-5, with 5 being "very high").
Donc c'est "critique" mais pas "très critique"
Encore heureux... si une faille ultime mettait plus d'un mois avant que Microsoft avertisse ses clients, ça aurait fait beaucoup plus scandale.
[^] # Re: même pas un jour
Posté par theocrite (site web personnel) . Évalué à 8.
Raté, elle estime le risque "élevé" mais pas critique ;)« C'est grave, mais rassurez vous, ça aurait pu être pire »
Ouf, je suis rassuré ! Tout va bien en fait.
[^] # Re: même pas un jour
Posté par TImaniac (site web personnel) . Évalué à 3.
# 7
Posté par armanoid . Évalué à 1.
Je crois qu'on dit simplement "Sept".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.