Re: Faille critique découverte dans GLIBC
Bonjour, Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit : Le 28/01/2015 14:34, Francois Lafont a écrit : echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/sources.list.d/squeeze-lts.list apt-get update apt-get upgrade Ah, au fait, petite question. Après les commandes ci-dessus, faut-il que je fasse un reboot ? Si j'ai bien compris, si un daemon dépend d'une lib, il faut redémarrer le-dit daemon après la mise à jour de la-dite lib. Seulement j'ai cru comprendre que globalement, quasiment tous les daemons (sous Debian) dépendent in fine de la glibc et qu'au final un reboot est globalement nécessaire. Bref, j'ai lu je ne sais plus où que l'idée selon laquelle seule la màj du noyau nécessitait un reboot était inexacte et que le reboot était également nécessaire pour la màj de la glic. Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;) Merci d'avance. Loin de moi l'idée de me considérer comme tel… Il y a justement une discussion à ce sujet en ce moment sur debian-security [1]. Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être redémarrés. On doit donc redémarrer les services qui l'utilisent. Dans le cas de la libc, ça devient problématique car _tous_ les programmes du système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement en fonctionnement. Deux approches : - tu les identifies un par un et tu les redémarres un par un (et tu ne fais rien d'autre de ta journée); - tu rebootes et c'est réglé en quelques minutes. 1: https://lists.debian.org/debian-security/2015/01/msg00035.html Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128135116.gd13...@sebian.nob900.homeip.net
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit : Non, seul squeeze-lts évolue encore. Ok, merci pour la réponse. En même temps ma question était sans doute un peu bête, car le dépôt LTS perdrait tout son sens si le dépôt squeeze évoluait encore. ;) Pourrait-on avoir le mode opératoire sous Debian, Sous Squeeze ? Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using Perso, je ne me suis pas embêté : echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/sources.list.d/squeeze-lts.list apt-get update apt-get upgrade sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade Perso, j'avoue que je l'utilise quotidiennement cette commande et je n'ai jamais eu de souci. Ai-je tort ? Si j'ai bien compris ce que dit la page man, avec upgrade aucune chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade ça peut arriver. Évidemment si je mets des dépôts de la distribution n+1 dans les sources.list alors là un dist-upgrade peut faire des dégats mais sinon j'ai l'impression que dans 99% des cas un upgrade et un dist-upgrade font au final la même chose. De toute façon, si tu veux être prudent, tu fais un upgrade et puis voilà (en plus même avec un dist-upgrade, tu jettes un œil sur les modifications que souhaite faire la commande avant de confirmer). -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maaohh$fco$1...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
Le mercredi 28 janvier 2015 à 14:34, Francois Lafont a écrit : Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit : sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade Perso, j'avoue que je l'utilise quotidiennement cette commande et je n'ai jamais eu de souci. Ai-je tort ? Je l'utilise également au quotidien (plutôt au gré des mises à jour qui arrivent) et sans aucun souci depuis plusieurs années. Si j'ai bien compris ce que dit la page man, avec upgrade aucune chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade ça peut arriver. C'est exactement ça, « upgrade » ne fera que ce qui ne nécessite aucun ajout ni aucune suppression alors que « dist-upgrade » mettra tout à niveau même si ça nécessite ajout ou suppression. Évidemment si je mets des dépôts de la distribution n+1 dans les sources.list alors là un dist-upgrade peut faire des dégats mais sinon j'ai l'impression que dans 99% des cas un upgrade et un dist-upgrade font au final la même chose. C'est exactement ça. Attention toutefois. On peut référencer la branche Debian dans le sources.list par son nom (« squeeze », « wheezy », « jessie ») ou bien par son type (« stable », « testing »). Si on référence le type, alors un « dist-upgrade » conduit au passage d'une branche à la suivante dès la publication. Si on veut vraiment maîtriser son système, mieux vaut référencer la branche par son nom. Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128135530.ge13...@sebian.nob900.homeip.net
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 14:55, Sébastien NOBILI a écrit : Attention toutefois. On peut référencer la branche Debian dans le sources.list par son nom (« squeeze », « wheezy », « jessie ») ou bien par son type (« stable », « testing »). Si on référence le type, alors un « dist-upgrade » conduit au passage d'une branche à la suivante dès la publication. Si on veut vraiment maîtriser son système, mieux vaut référencer la branche par son nom. Oh oui, perso j'ai toujours mis le nom sans penser au départ à ce que tu décris mais je connais des gens qui se sont pris un upgrade de distribution dans la figure comme ça. :) Merci pour ta réponse. -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maaqln$ksa$1...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 14:45, andre_deb...@numericable.fr a écrit : Je suis sous Wheezy... Et bien tu mets à jour ta Wheezy de manière on ne peut plus classique : apt-get update apt-get upgrade Je vois pas où est le problème. -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maapf8$ofv$2...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
On Wed, Jan 28, 2015 at 02:43:54PM +0100, Francois Lafont wrote: Ah, au fait, petite question. Après les commandes ci-dessus, faut-il que je fasse un reboot ? La commande checkrestart (paquet debian-goodies) permet de savoir facilement quels sont les processus à relancer après une mise-à-jour classique. A contrario, une m-a-j de la libc est tellement impactante (tout ou presque doit être relancé) que je ne me pose plus la question : c'est reboot direct après coup. -- Nicolas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128135433.ga2...@petole.demisel.net
Re: Faille critique découverte dans GLIBC
On Wednesday 28 January 2015 13:41:22 Francois Lafont wrote: Le 28/01/2015 12:47, Bernard Isambert a écrit : Est-ce qu'il y a une chance que le correctif soit tout simplement disponible sur les dépôts squeeze « normaux » ? Non, seul squeeze-lts évolue encore. Ok, merci pour la réponse. En même temps ma question était sans doute un peu bête, car le dépôt LTS perdrait tout son sens si le dépôt squeeze évoluait encore. ;) Pourrait-on avoir le mode opératoire sous Debian, sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade ce qui semble être un peu un canon pour tuer la mouche (même si elle est grosse). N'y a t-il pas une méthode plus soft ? Merci. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501281419.01720.andre_deb...@numericable.fr
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 14:34, Francois Lafont a écrit : Sous Squeeze ? Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using Perso, je ne me suis pas embêté : echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/sources.list.d/squeeze-lts.list apt-get update apt-get upgrade Ah, au fait, petite question. Après les commandes ci-dessus, faut-il que je fasse un reboot ? Si j'ai bien compris, si un daemon dépend d'une lib, il faut redémarrer le-dit daemon après la mise à jour de la-dite lib. Seulement j'ai cru comprendre que globalement, quasiment tous les daemons (sous Debian) dépendent in fine de la glibc et qu'au final un reboot est globalement nécessaire. Bref, j'ai lu je ne sais plus où que l'idée selon laquelle seule la màj du noyau nécessitait un reboot était inexacte et que le reboot était également nécessaire pour la màj de la glic. Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;) Merci d'avance. -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maap2l$ofv$1...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
Pourrait-on avoir le mode opératoire sous Debian, Sous Squeeze ? Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using Je suis sous Wheezy... Perso, je ne me suis pas embêté : echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/sources.list.d/squeeze-lts.list apt-get update apt-get upgrade sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-c entos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade Perso, j'avoue que je l'utilise quotidiennement cette commande et je n'ai jamais eu de souci. Ai-je tort ? Si j'ai bien compris ce que dit la page man, avec upgrade aucune chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade ça peut arriver. Évidemment si je mets des dépôts de la distribution n+1 dans les sources.list alors là un dist-upgrade peut faire des dégats mais sinon j'ai l'impression que dans 99% des cas un upgrade et un dist-upgrade font au final la même chose. De toute façon, si tu veux être prudent, tu fais un upgrade et puis voilà (en plus même avec un dist-upgrade, tu jettes un œil sur les modifications que souhaite faire la commande avant de confirmer). François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501281445.58433.andre_deb...@numericable.fr
Re: Faille critique découverte dans GLIBC
Bonjour à tous, Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 mais pas en i386. Le 28/01/2015 08:52, Frédéric MASSOT a écrit : Quelques autres liens : - Les paquets corrigés : https://security-tracker.debian.org/tracker/CVE-2015-0235 - http://www.openwall.com/lists/oss-security/2015/01/27/9 - https://linuxfr.org/users/peetah/journaux/faille-de-securite-glibc - http://www.frsag.org/pipermail/frsag/2015-January/005722.html -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c8a759.8080...@taranig.net
Re: Faille critique découverte dans GLIBC
Bonjour, Le 28/01/2015 10:09, Bernard Isambert a écrit : Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 mais pas en i386. Est-ce qu'il y a une chance que le correctif soit tout simplement disponible sur les dépôts squeeze « normaux » ? -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maafsl$mnj$1...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
Est-ce qu'il y a une chance que le correctif soit tout simplement disponible sur les dépôts squeeze « normaux » ? Non, seul squeeze-lts évolue encore. -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c8cc3d.4020...@taranig.net
Re: Faille critique découverte dans GLIBC
Bonjour à tous, Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 mais pas en i386. C'était juste une question de temps, maintenant il est arrivé. -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c8cd14.6070...@taranig.net
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 12:47, Bernard Isambert a écrit : Est-ce qu'il y a une chance que le correctif soit tout simplement disponible sur les dépôts squeeze « normaux » ? Non, seul squeeze-lts évolue encore. Ok, merci pour la réponse. En même temps ma question était sans doute un peu bête, car le dépôt LTS perdrait tout son sens si le dépôt squeeze évoluait encore. ;) -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maaldd$m52$1...@ger.gmane.org
Re: [testing] tracker-extract et conso cpu
Le mardi 27 janvier 2015 à 22:30 +0100, Gaëtan PERRIER a écrit : Bonjour, Depuis quelques jours je constate que tracker-extract consomme énormément de CPU voir par moment tous les CPU. Est-ce de même chez vous ? Tracker est une plaie qui ne devrait pas être installé par défaut. C'est un très bon outil quand on a un travail ou des besoins en rapport avec la gestion documentaire, sur un ordinateur fixe. Ça permet de faire des requêtes évoluées en ligne de commande avec SPARQL à travers les métadonnées et contenu des fichiers. Sur un portable ou un usage simple, ça bouffe non seulement du CPU mais aussi des I/O disque à n'en plus finir, ça plombe n'importe quel système en particulier si tu le laisse chercher dans les fichiers compressés, et n'est pas du tout adapté à un ordinateur portable. Voilà mon avis. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/1422440579.5032.39.ca...@aranha.fr
Re: Localhost
On 2015-01-26 11:54:44 +0100, andre_deb...@numericable.fr wrote: On Sunday 25 January 2015 22:52:11 Eddy F. wrote: En gros, tu trouves qu'indiquer 127.0.0.1 n_importe_quoi.pas_utilisé_ailleurs localhost n'est pas logique (et tu as raison !) mais l'ordinateur l'accepte et la doc n'a rien contre. Pourtant tu en déduis que c'est une faute, non pas de bonne pratique, mais de... Ben je ne sais pas de quoi au fait. Ce n'est pas parce que l'ordinateur l'accepte que c'est bon, C'est bon car c'est explicitement autorisé par la doc: la page man hosts(5) indique: IP_address canonical_hostname [aliases...] Fields of the entry are separated by any number of blanks and/or tab characters. Text from a # character until the end of the line is a comment, and is ignored. Host names may contain only alphanumeric characters, minus signs (-), and periods (.). They must begin with an alphabetic character and end with an alphanumeric character. Optional aliases provide for name changes, alternate spellings, shorter hostnames, or generic hostnames (for example, localhost). ^ Donc localhost est OK dans la partie aliases. c'est parce que tu as affaire à de la tolérance, et un jour ça ne marche plus. Si ça ne marche plus, c'est qu'il y a un bug, qu'il faut rapporter. En fait, s'il y a un tel bug, c'est probablement parce que ça n'a jamais été testé, puisque personne ne met localhost dans la partie aliases en pratique (car c'est inutile). Pourquoi s'obstiner à vouloir faire ? : 127.0.0.1 localhost eddy.net alors que la seconde ligne introduit bien le domaine intranet : 192.168.0.1 eddy eddy.eddy.net Non! 192.168.0.1 eddy.eddy.net eddy dans cet ordre obligatoirement, puisque eddy.eddy.net est le nom canonique. Mais si c'est le nom de la machine locale, alors mieux vaut choisir: 127.0.1.1 eddy.eddy.net eddy Ainsi, si l'interface 192.168.0.1 tombe, les connexions locales via le nom eddy ou eddy.eddy.net continuent de fonctionner. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128144138.ga14...@xvii.vinc17.org
Re: connaitre les paquets installés venant de sid et/ou experimental
On 2015-01-24 16:19:28 +0100, Gilles Mocellin wrote: Le 24/01/2015 15:59, Sylvain L. Sauvage a écrit : https://wiki.debian.org/fr/Aptitude donne l’exemple suivant pour savoir ce qui vient de testing et pas de stable : aptitude search '?narrow(?installed, ?archive(testing) !?archive(stable))' Mais si un paquet est à la même version dans deux dépôts, il n’y a aucune façon de déterminer d’où il vient. Il peut venir des deux puisque le .deb est le même dans les deux. Ça ne marche pas pour moi: aptitude search '?narrow(?installed, ?archive(testing) !?archive(stable))' ne me renvoie qu'une seule ligne: iF initramfs-tools - generic modular initramfs generator en étant sous Debian/unstable (avec quelques paquets non upgradés, dont celui ci-dessus). Je me disais qu'aptitude considère que les paquets viennent de unstable, même s'ils ont la même version qu'en testing. Mais ce n'est pas le cas: aptitude search '?narrow(?installed, ?archive(unstable) !?archive(stable))' ne me renvoie rien! Dans l'absolu, on pourrait avoir du paquets à la même version, mais différents dans stable et unstable, à cause des dépendances (librairies dynamiques...). Et dans ce cas, pouvoir les différentier serait intéressant. Mais peut-être que je me trompe et que cette situation n'est pas permise, que dans ce cas, les paquets doivent avoir une version différente. C'est effectivement interdit. (Ça peut peut-être arriver à cause d'un bug, mais alors je pense qu'il n'y a plus aucune cohérence, et les différentes commandes ne sont plus fiables.) -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128150926.gb14...@xvii.vinc17.org
Re: [HS] utiliser un disque plus grand
Le mardi 27 janvier 2015 22:00:55, vous avez écrit : Le vendredi 07 novembre 2014 à 12:19 +0100, Fabrice Regnier a écrit : salut la liste, J'ai une wheezy (une seule partition) sur un disque A de 320Go qui est full (97%). Et je souhaite tout passer sur un disque B plus gros (500Go) en sachant que je clone régulièrement, avec CloneZilla, le disque A vers le disque B. Ce dernier boote parfaitement mais avec une capacité de 320Go seulement. Voici ma question: si je démarre avec un livecd (gparted?) et le disque B non monté, ai-je la possibilité de modifier l'unique partition de B pour l'étendre jusqu'à 500Go et ce, sans perdre les data ? gparted est facile à utiliser et fait toutes les opérations nécessaires de manière fiable, mais une sauvegarde n'est jamais inutile. Si tu a cloné les disque, la sauvegarde semble avoir été faite si je ne me trompe. Si cette solution n'est pas jouable, je pensais à un simple cp -R de A vers B non montés. Plus rapide ? cp -R ne conserve pas les partitions, et pense aux liens. Cloner puis agrandir la partition est une manière simple de ne pas se tromper sur ces points. Au passage, songe à l'uuid du disque si tu l'utilise plutôt que le label ou le chemin. Salut, J'ai rencontré le même souci avec un problème en plus une partition système Windows . Si j'ai bien compris tu te sert du disque B comme sauvegarde et tu voudrais le mettre comme maître . Tu voudrais agrandir ta partition avec Gparted normalement il le fait correctement sans perte d'information. Et comme tu gardes le disque A tu ne risques pas grand chose. Mais aussi tu peux agrandir ta partition sur B et Cloner ton disque A sur B avec Clonezilla en mode expert et tu choisis l'option *-k *qui te feras cela très bien, tu vois tu as le choix. Amitié Philippe Merlin
Re: Faille critique découverte dans GLIBC
On Wednesday 28 January 2015 15:50:11 Frédéric MASSOT wrote: Pourrait-on avoir le mode opératoire sous Debian, sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-c entos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade ce qui semble être un peu un canon pour tuer la mouche (même si elle est grosse). N'y a t-il pas une méthode plus soft ? Oui bien sûr, tu mets à jour que la libc6. Quel paquet mettre à jour ? dpkg -l | grep libc6 Puis : apt-get install la liste des paquets Les processus serveurs vont continuer d'utiliser l'image de l'ancienne libc6 qui est en mémoire, jusqu'à ce qu'ils soient redémarrés. Merci beaucoup, mais cette méthode pourtant logique n'a pas marché. Malgré un reboot, le test ghosttest me répondait toujours : Vulnerable. J'ai fait un #apt-get upgrade et au reboot : ghosttest = Non vulnerable. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501281616.27938.andre_deb...@numericable.fr
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit : On Wednesday 28 January 2015 13:41:22 Francois Lafont wrote: Le 28/01/2015 12:47, Bernard Isambert a écrit : Est-ce qu'il y a une chance que le correctif soit tout simplement disponible sur les dépôts squeeze « normaux » ? Non, seul squeeze-lts évolue encore. Ok, merci pour la réponse. En même temps ma question était sans doute un peu bête, car le dépôt LTS perdrait tout son sens si le dépôt squeeze évoluait encore. ;) Pourrait-on avoir le mode opératoire sous Debian, sans faire ce que propose ce site : www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get dist-upgrade ce qui semble être un peu un canon pour tuer la mouche (même si elle est grosse). N'y a t-il pas une méthode plus soft ? Oui bien sûr, tu mets à jour que la libc6. Quel paquet mettre à jour ? dpkg -l | grep libc6 Puis : apt-get install la liste des paquets Les processus serveurs vont continuer d'utiliser l'image de l'ancienne libc6 qui est en mémoire, jusqu'à ce qu'ils soient redémarrés. Sur les anciennes distrib, tu peux utiliser la commande checkrestart du paquet debian-goodies pour avoir la liste des daemons à redémarrer. Sur les distrib plus récentes (wheezy-backports, jessie, sid) tu peux utiliser la commande needrestart, du paquet du même nom, qui liste les daemons à redémarrer et les redémarre si tu le souhaite. Une fois le paquet needrestart installé, il est lancé à la fin des installations par apt. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux=== -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c8f723.6090...@juliana-multimedia.com
Re: Localhost
On 2015-01-28 16:02:39 +0100, andre_deb...@numericable.fr wrote: Il faut savoir interpréter les man. Il faut surtout avoir la bonne interprétation! Je réitère dans /etc/hosts : # 127.0.0.1 = adresse littéraire local de l'ordinateur : 127.0.0.1 localhost localhost.localdomain # IP intranet si réseau intranet, p. ex. 192.168.0.0 192.168.0.1 eddy eddy.eddy.net Non! eddy.eddy.net doit être *avant* eddy. Cf plein de discussions d'il y a longtemps, et également: https://lists.debian.org/debian-devel/2013/07/msg00809.html Si on écrit : 127.0.0.1 localhost eddy.net l'ordinateur peut chercher le domaine eddy.net sur un autre poste du domaine, càd tous... Surtout le /etc/hosts n'est censé contenir que des noms d'hôte, pas des domaines. puisqu'ils sont censés avoir cette même ligne dans leur /etc/hosts 127.0.0.1 localhost eddy.net ne peut que s'écrire comme ci-dessus si le PC n'est relié à aucun réseau, Non. D'ailleurs l'installeur de Debian ne fait pas ça. /etc/hosts est un fichier DNS manuel de domaine intranet, Ce n'est pas un fichier de DNS. C'est juste un fichier de résolution de noms d'hôte (cf files vs dns dans /etc/nsswitch.conf). si celui-ci n'a pas de service DNS. On peut aussi se passer de /etc/hosts sans avoir de service DNS. C'est d'ailleurs ce qui se fait maintenant (pour la future release jessie). Cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756224#89 Pour la plupart des machines, les serveurs DNS sont externes. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128153758.gc14...@xvii.vinc17.org
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 20:59, Philippe Deleval a écrit : Bonjour à tous C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Cordialement Philippe Deleval Et ceux qui créé la fonction strcpy sont des criminels qui devraient être guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé l'informatique... -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c95fd0.4040...@taranig.net
Re: Faille critique découverte dans GLIBC
On 28/01/2015 15:00, Sébastien NOBILI wrote: Bonjour, Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit : Le 28/01/2015 14:34, Francois Lafont a écrit : echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/sources.list.d/squeeze-lts.list apt-get update apt-get upgrade Ah, au fait, petite question. Après les commandes ci-dessus, faut-il que je fasse un reboot ? Si j'ai bien compris, si un daemon dépend d'une lib, il faut redémarrer le-dit daemon après la mise à jour de la-dite lib. Seulement j'ai cru comprendre que globalement, quasiment tous les daemons (sous Debian) dépendent in fine de la glibc et qu'au final un reboot est globalement nécessaire. Bref, j'ai lu je ne sais plus où que l'idée selon laquelle seule la màj du noyau nécessitait un reboot était inexacte et que le reboot était également nécessaire pour la màj de la glic. Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;) Merci d'avance. Loin de moi l'idée de me considérer comme tel… moi non plus mais je voudrais nuancer ta réponse (car en pratique c'est clair qu'un reboot est juste simple et efficace mais: ) - La mise à jour de la glibc se contente peut-être de patcher quelques fichiers (diff), dans ce cas ce sont les programmes/daemons qui les utilisent qui auront besoin de la nouvelle version bien sûr. Peut-être aussi (pour ceux qui ne peuvent pas rebooter leur machine et il y en a, un simple logout/login) peut peut-être légèrement aider - La libc fourni une librairie (minimale) pour les programmes écrits en C, donc ton démon écrit dans un autre langage ne devrait pas être touché cependant: - Linux est écrit en C (bravo les gars au passage!), tous les appels systèmes ont été implémenté en C et en assembleur (qd c'était obligé, les registres par exemple ne sont pas directement accessibles en C, ou pour des raisons de performance) et: Certains appels systèmes en sont des vrais (par exemple fork je crois) mais d'autres ont des wrappers (désolé, je trouve pas la traduction là) autour ex: Des appels systèmes wait, waitpid, wait3, wait4 qui font tous à peu près la même chose (attendre (ou non) la fin d'un fils (présicément celui-là ou non)...) seul wait3 est réellement un appel système, les autres se contentant de l'appeler avec les bonnes options. Et je crois que ces wrappers (et d'autres trucs) dépendent de la libc. A moins qu'ils fassent également parti du noyau en fait. Bon là je me perd et je dois partir bosser, toute correction à mes propos appréciée, je ne prétend pas à la vérité, c'est juste un point de vue. Ceci étant dit, bonne journée les gars! Il y a justement une discussion à ce sujet en ce moment sur debian-security [1]. Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être redémarrés. On doit donc redémarrer les services qui l'utilisent. Dans le cas de la libc, ça devient problématique car _tous_ les programmes du système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement en fonctionnement. Deux approches : - tu les identifies un par un et tu les redémarres un par un (et tu ne fais rien d'autre de ta journée); - tu rebootes et c'est réglé en quelques minutes. 1: https://lists.debian.org/debian-security/2015/01/msg00035.html Seb -- -- mrr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c9d852$0$3081$426a7...@news.free.fr
Re: Faille critique découverte dans GLIBC
Merci Sébastien et Nicolas pour vos réponses. Ça confirme un peu ce que je pensais, à savoir que théoriquement on peut sans doute se passer d'un reboot mais qu'en pratique c'est quand même plus simple et plus sûr (à condition qu'on puisse se permettre de rebooter la machine bien sûr). Je retiens le coup du checkrestart aussi que je ne connaissais pas. Merci à vous deux. À+ -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/mab3j7$npm$1...@ger.gmane.org
Re: Localhost
Bonsoir, Le 28/01/2015 16:37, Vincent Lefevre a écrit : # 127.0.0.1 = adresse littéraire local de l'ordinateur : 127.0.0.1 localhost localhost.localdomain # IP intranet si réseau intranet, p. ex. 192.168.0.0 192.168.0.1 eddy eddy.eddy.net Non! eddy.eddy.net doit être *avant* eddy. Cf plein de discussions d'il y a longtemps, et également: https://lists.debian.org/debian-devel/2013/07/msg00809.html Merci pour ce lien que j'ai lu mais justement le point (enfin un des points) que tu soulèves ci-dessus n'est pas expliqué, enfin il me semble. Dans ton lien je vois ceci : So the only thing that needs to be secured for the correct resolution is that we don't mix up the localhost line with the foobar line. And the order of the line's entries is important, e.g. it must be: 127.0.0.1 foobar.bar.net foobar not 127.0.0.1 foobar foobar.bar.net » Mais l'auteur ne dit pas pourquoi « it must be ». Perso, je pensais qu'une ligne du type : adresse-IP était complètement équivalent à : adresse-IP Pourquoi est-ce que ce n'est pas le cas ? En espérant que l'explication ne soit pas trop complexe. Merci d'avance. PS : bon naturellement je mets le fqdn en premier moi aussi mais si en plus je sais pourquoi alors c'est plus sympa. :) -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/mab44g$1f6$1...@ger.gmane.org
Restauration avec backup manager
Bonsoir, Voilà erreur de manip et pouf ... tout un dossier aux oubliettes :( Heureusement j'ai des sauvegardes qui sont faites avec backup-manager. Après avoir restauré le master et tous les incrémentaux, la restauration a bien fonctionné ! Sauf que j'avais supprimé certains dossiers/fichiers qui du coup maintenant sont à nouveaux là ! Ma question, c'est y-til un moyen pour supprimer les fichiers qui ont été supprimés d'un incrémental à l'autre ? Quitte a créer un nouveau script de sauvegarde ou passer par autre chose que backup-manager. Par ce que là je dois me retaper le tri de tous les fichiers restaurés que j'avais supprimés :( -- Alain JUPIN -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c92a6d.6010...@jupin.net
pbuilder et compilation kernel custom
Bonjour à tous, Après avoir réussi à monter une configuration pbuilder pour construire quelques packages custom ou des recompilations avec patch de petits logiciels, je bloque néanmoins sur la compilation de kernel vanilla avec patch. Lorsque je faisais mes packages Debian pour un kernel custom, je prenais la version qui m'intéressait directement sur kernel.org, j'appliquais les patchs et les réglages que j'avais à faire dans le .config et j'utilisais make-kpgk qui est la méthode recommandée pour faire des kernel Debian. Sauf que pour pouvoir compiler un kernel avec pbuilder il faut générer un .dsc .orig et c'est seulement à partir de ces éléments que pbuilder va construire le package pour l'archi et la distribution demandée. Alors j'ai bien trouvé une façon de ne faire que le répertoire /debian/ dans les sources du package et générer les fichiers nécessaires à pbuilder avec les commandes : make-kpkg debian --initrd --revision 1 --append-to-version -patched pour préparer le kernel vanilla pour être packagé dpkg-buildpackage -nc -S pour générer le .dsc et .orig Jusque là tout va bien, le souci c'est lorsque je lance pbuilder avec ces fichiers, le makefile est appelé avec la commande clean qui supprime tout simplement le répertoire /debian/ des sources du kernel. Et forcément juste après il y a une erreur comme quoi ce répertoire n'existe pas et que les actions qui doivent y être faites ne sont plus possibles. Pour vous est ce la bonne voix pour compiler un kernel custom pour Debian? Ou faut il que je m'y prenne autrement? Je précise mes besoins, car j'ai tenté de partir des sources d'un kernel experimental pour être à jour mais vu la complexité du répertoire debian avec toutes les options pour chaque architecture, c'est overkill pour mes besoins, je souhaite juste compiler un kernel patché pour oldstable stable et jessie en amd64 et i386. Merci pour vos avis. signature.asc Description: OpenPGP digital signature
Re: Localhost
Il faut savoir interpréter les man. Je réitère dans /etc/hosts : # 127.0.0.1 = adresse littéraire local de l'ordinateur : 127.0.0.1 localhost localhost.localdomain # IP intranet si réseau intranet, p. ex. 192.168.0.0 192.168.0.1 eddy eddy.eddy.net Si on écrit : 127.0.0.1 localhost eddy.net l'ordinateur peut chercher le domaine eddy.net sur un autre poste du domaine, càd tous... puisqu'ils sont censés avoir cette même ligne dans leur /etc/hosts 127.0.0.1 localhost eddy.net ne peut que s'écrire comme ci-dessus si le PC n'est relié à aucun réseau, /etc/hosts est un fichier DNS manuel de domaine intranet, si celui-ci n'a pas de service DNS. Il faut donc le renseigner sans failles, surtout si le PC communique avec un réseau. Pour moi, le sujet est clos, j'en reste à ma configuration prescrite, tant pis pour ceux qui auront un jour des bugs... :-) André On Wednesday 28 January 2015 15:41:38 Vincent Lefevre wrote: On 2015-01-26 11:54:44 +0100, andre_deb...@numericable.fr wrote: On Sunday 25 January 2015 22:52:11 Eddy F. wrote: En gros, tu trouves qu'indiquer 127.0.0.1 n_importe_quoi.pas_utilisé_ailleurs localhost n'est pas logique (et tu as raison !) mais l'ordinateur l'accepte et la doc n'a rien contre. Pourtant tu en déduis que c'est une faute, non pas de bonne pratique, mais de... Ben je ne sais pas de quoi au fait. Ce n'est pas parce que l'ordinateur l'accepte que c'est bon, C'est bon car c'est explicitement autorisé par la doc: la page man hosts(5) indique: IP_address canonical_hostname [aliases...] Fields of the entry are separated by any number of blanks and/or tab characters. Text from a # character until the end of the line is a comment, and is ignored. Host names may contain only alphanumeric characters, minus signs (-), and periods (.). They must begin with an alphabetic character and end with an alphanumeric character. Optional aliases provide for name changes, alternate spellings, shorter hostnames, or generic hostnames (for example, localhost). ^ Donc localhost est OK dans la partie aliases. c'est parce que tu as affaire à de la tolérance, et un jour ça ne marche plus. Si ça ne marche plus, c'est qu'il y a un bug, qu'il faut rapporter. En fait, s'il y a un tel bug, c'est probablement parce que ça n'a jamais été testé, puisque personne ne met localhost dans la partie aliases en pratique (car c'est inutile). Pourquoi s'obstiner à vouloir faire ? : 127.0.0.1 localhost eddy.net alors que la seconde ligne introduit bien le domaine intranet : 192.168.0.1 eddy eddy.eddy.net Non! 192.168.0.1 eddy.eddy.net eddy dans cet ordre obligatoirement, puisque eddy.eddy.net est le nom canonique. Mais si c'est le nom de la machine locale, alors mieux vaut choisir: 127.0.1.1 eddy.eddy.net eddy Ainsi, si l'interface 192.168.0.1 tombe, les connexions locales via le nom eddy ou eddy.eddy.net continuent de fonctionner. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501281602.39373.andre_deb...@numericable.fr
Re: Localhost
Le mercredi 28 janvier 2015 à 16:02, andre_deb...@numericable.fr a écrit : # 127.0.0.1 = adresse littéraire local de l'ordinateur : 127.0.0.1 localhost localhost.localdomain # IP intranet si réseau intranet, p. ex. 192.168.0.0 192.168.0.1 eddy eddy.eddy.net Si on écrit : 127.0.0.1 localhost eddy.net l'ordinateur peut chercher le domaine eddy.net sur un autre poste du domaine, càd tous... puisqu'ils sont censés avoir cette même ligne dans leur /etc/hosts 127.0.0.1 localhost eddy.net ne peut que s'écrire comme ci-dessus si le PC n'est relié à aucun réseau, « eddy.net » est un domaine, il n'a _rien_ à faire dans le fichier hosts (qui référence des hôtes)… Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150128153431.gg13...@sebian.nob900.homeip.net
Re: Localhost
On Wednesday 28 January 2015 17:52:37 Francois Lafont wrote: Le 28/01/2015 16:37, Vincent Lefevre a écrit : # 127.0.0.1 = adresse littéraire local de l'ordinateur : 127.0.0.1 localhost localhost.localdomain # IP intranet si réseau intranet, p. ex. 192.168.0.0 192.168.0.1 eddy eddy.eddy.net Non! eddy.eddy.net doit être *avant* eddy. Cf plein de discussions d'il y a longtemps, et également: https://lists.debian.org/debian-devel/2013/07/msg00809.html Merci pour ce lien que j'ai lu mais justement le point (enfin un des points) que tu soulèves ci-dessus n'est pas expliqué, enfin il me semble. Dans ton lien je vois ceci : To: debian-de...@lists.debian.org Il s'agit d'un mail d'une liste Debian, qui n'a pas valeur de tuto officiel. So the only thing that needs to be secured for the correct resolution is that we don't mix up the localhost line with the foobar line. And the order of the line's entries is important, e.g. it must be: adresse-IP était complètement équivalent à : adresse-IP bon naturellement je mets le fqdn en premier moi aussi mais si en plus je sais pourquoi alors c'est plus sympa. :) C'est commutatif, ça n'a aucune importance. Pour la logique on met : ip nom d'hôte nom_d_hôte.nom_de_domaine Sans certitude, le FQDN serait : user@nom_d_hôte.nom_de_domaine qui varie selon les serveurs. Ici capital p. ex. pour un serveur de messagerie. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501281950.03780.andre_deb...@numericable.fr
Re: [testing] iceweasel et moteur de recherche yahoo en français
On 09/23/2014 10:08 AM, moi-meme wrote: Comment faire pour avoir le moteur de recherche yahoo en français dans iceweasel ? [testing] c'est un peu Debian et Iceweasel est le navigateur de base de Debian si je ne me trompe. Hello Ceci ne concerne pas Iceweasel. Suffit de taper la bonne adresse. https://fr.search.yahoo.com/ -- Maderios -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c93810.7030...@gmail.com
Re: Faille critique découverte dans GLIBC
Bonjour à tous C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Cordialement Philippe Deleval Le 28/01/2015 08:12, JUPIN Alain a écrit : Bonjour, Je ne l'ai pas vu ici sur la liste (ou alors je n'ai pas les yeux en face des trous) Une faille critique permettant d'avoir les droits administrateur (root) a été découverte sur les systèmes Linux. La faille est présente dans toutes les versions inférieure à 2.18 de GLIBC (paquet libc6 pour nous autres chez Debian). Pour Debian (ainsi que Ubuntu et RedHat) le correctif est sorti. Vous connaissez la marche a suivre je suppose ;) Source : http://www.01net.com/editorial/643126/ghost-la-faille-critique-qui-permet-de-prendre-le-controle-des-systemes-linux/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54c93fb6.1040...@wanadoo.fr
