apt-get ignore mon APT::Install-Recommends 0
Bonjour, J'ai eu aujourd'hui une bizarrerie avec apticron qui me notifie d'une mise à jour sur un paquet non installé. C'est e2fsprogs et libss2, apparemment parce que i initscripts Recommends e2fsprogs p e2fsprogs PreDepends libss2 (= 1.34-1) alors que j'ai dans un /etc/apt/apt.conf.d/81no_reco_sugg (le dernier de /etc/apt/apt.conf.d/) // on veut pas des recommandés ou suggérés APT::Install-Recommends 0; APT::Install-Suggests 0; Et visiblement, aptitude en tient compte mais pas apt-get, et apticron a l'air d'utiliser apt-get après un apt-get update, j'ai apt-get dist-upgrade ... The following NEW packages will be installed: e2fsprogs libss2 et aptitude dist-upgrade No packages will be installed, upgraded, or removed. Qqun comprend la raison ? Merci -- Daniel Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne mérite ni l'une ni l'autre, et finit par perdre les deux. Thomas Jefferson -- 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/20150114202855.51699...@quad.lairdutemps.org
Re: Rafraichissement ecran
Le 14/01/2015 17:28, Diogene Laerce a écrit : On 01/13/2015 10:05 PM, A. Dawson wrote: [...] Ce qui fonctionne aussi, c'est de passer au driver libre nouveau (mais j'utilise parfois Cinelerra qui est optimisé pour le driver nvidia propriétaire). Mais il ne fait pas la 3D si je ne m'abuse ? Si si, j'arrive à jouer à Nexuiz avec ma GeForce GTX 770 et nouveau. Jusqu'à il y a peut il manquait la gestion du ventilateur, qui était toujours à fond. Mais depuis quelques temps vers Noël, le driver nouveau gère aussi le ventillo. Me revoici donc sans drivers proprio ! [...] -- 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/54b6f117.6010...@nuagelibre.org
fail2ban
Bonsoir à tous, J'ai un truc un peu bizarre avec fail2ban 0.9.1 que j'ai installé sur un serveur. J'ai patché l'outil pour qu'il traite aussi les IPv6 (https://tetsumaki.net/blog/article/2014-03-04-ajout-du-support-ipv6-sur-fail2ban.html). J'observe un comportement étrange sans savoir si ce comportement est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si c'est dû à l'augmentation ces derniers jours des attaques. En effet, j'ai un /29 et je subis actuellement en IPv4 des attaques sur toutes les IP à un rythme soutenu. ip(6)tables -L renvoient : ... (mes règles habituelles) Chain f2b-apache-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Chain f2b-courier-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Chain f2b-ejabberd-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Il m'arrive d'avoir une centaine de RETURN au bout d'une journée. Je relance fail2ban et ça fonctionne jusqu'à la prochaine fois. Suis-je le seul à observer cela ? Cordialement, JKB -- 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/54b6e498.4050...@systella.fr
Re: fail2ban
Bonsoir, On va encore dire que ça ne répond pas au besoin de l'OP , mais : Le 14/01/2015 22:50, BERTRAND Joël a écrit : Bonsoir à tous, J'ai un truc un peu bizarre avec fail2ban 0.9.1 que j'ai installé sur un serveur. J'ai patché l'outil pour qu'il traite aussi les IPv6 (https://tetsumaki.net/blog/article/2014-03-04-ajout-du-support-ipv6-sur-fail2ban.html). Je m'étais tenté à ça, il y a quelques mois/années, sans aucun succès (en particulier ce qui concerne IPv6) . Depuis j'utilise sshguard ... @+ Christophe. -- 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/54b6edc2.5040...@stuxnet.org
Re: fail2ban
Philippe Gras wrote: Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit : Philippe Gras wrote: Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit : Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est x 3 ? Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors de la règle 'recidive' toutes augmentent en même temps et comportent le même nombre de RETURN. Rien compris ! Quand j'observe tes extraits : Chain f2b-apache-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il y a 3 fichiers à patcher. Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne retournent pas chacun une On s'est mal compris. En ce moment, j'ai trois lignes RETURN par cible. Mais lorsque je lance fail2ban, je n'ai qu'un RETURN par cible. Et ce soir, j'avais 49 RETURN par cible avant de relancer le service. J'ai regardé les fichiers en question avant d'écrire ici et je ne vois pas trop ce qui pourrait provoquer un tel comportement. Cordialement, JKB -- 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/54b6f3aa.9070...@systella.fr
Re: fail2ban
Le 14 janv. 15 à 23:54, BERTRAND Joël a écrit : Philippe Gras wrote: Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit : Philippe Gras wrote: Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit : Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est x 3 ? Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors de la règle 'recidive' toutes augmentent en même temps et comportent le même nombre de RETURN. Rien compris ! Quand j'observe tes extraits : Chain f2b-apache-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il y a 3 fichiers à patcher. Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne retournent pas chacun une On s'est mal compris. En ce moment, j'ai trois lignes RETURN par cible. Mais lorsque je lance fail2ban, je n'ai qu'un RETURN par cible. Et ce soir, j'avais 49 RETURN par cible avant de relancer le service. Ça veut dire que le patch te balance 1 RETURN par IP bannie, c'est ça ? J'ai regardé les fichiers en question avant d'écrire ici et je ne vois pas trop ce qui pourrait provoquer un tel comportement. Sinon, tu peux regarder ça : iptables -S | grep fail2ban et cat /var/log/fail2ban.log Je me sers beaucoup du fichier de log en ce moment pour voir comment f2b se comporte, car je l'ai installé récemment. (offert à mon serveur pour Noël) Cordialement, JKB -- 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/54b6f3aa.9070...@systella.fr -- 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/b68ee115-9b34-4337-a7a6-9344bf4ee...@worldonline.fr
Re: fail2ban
Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Cordialement, JKB -- 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/54b6ec0d.1020...@systella.fr
Re: fail2ban
Philippe Gras wrote: Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit : Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est x 3 ? Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors de la règle 'recidive' toutes augmentent en même temps et comportent le même nombre de RETURN. Cordialement, JKB -- 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/54b6ef45.6090...@systella.fr
Re: récupérer des données en RAID 1
Vincent Bernat a écrit : BERTRAND Joël joel.bertr...@systella.fr : Si c'est du Raid1, tu dois pouvoir monter les disques à la main comme s'il s'agissait de disques non raid. Typiquement, si /dev/md0 est composé de /dev/sda1 et de /dev/sdb1, tu peux monter /dev/sdb1 tout seul. Avec des métadata en 1.1 ou 1.2, le superblock est maintenant en début de volume, on ne peut donc plus monter une partition comme si de rien n'était. On peut la monter en loop avec l'offset qui va bien pour sauter le superbloc, obtenu grâce à mdadm -E : root@raid-gpt-efi:~# mdadm -E /dev/sdb2 /dev/sdb2: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 502f5850:ca3c0adb:e19a5529:50c46b7b Name : raid-gpt-efi:0 (local to host raid-gpt-efi) Creation Time : Mon Dec 29 22:37:16 2014 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 7809024 (3.72 GiB 4.00 GB) Array Size : 3904448 (3.72 GiB 4.00 GB) Used Dev Size : 7808896 (3.72 GiB 4.00 GB) Data Offset : 4096 sectors (...) root@raid-gpt-efi:~# losetup -v -r -o $((4096*512)) -f /dev/sdb2 Loop device is /dev/loop0 root@raid-gpt-efi:~# file -s /dev/loop0 /dev/loop0: sticky Linux rev 1.0 ext4 filesystem data, UUID=7c0d3084-a66a-46b3-9fd0-2893d0ba9e59 (needs journal recovery) (extents) (large files) (huge files) root@raid-gpt-efi:~# file -s /dev/md0 /dev/md0: sticky Linux rev 1.0 ext4 filesystem data, UUID=7c0d3084-a66a-46b3-9fd0-2893d0ba9e59 (needs journal recovery) (extents) (large files) (huge files) Mais c'est se compliquer la vie pour rien : il suffit d'assembler explicitement un volume RAID avec cette seule partition. -- 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/54b703b9.20...@plouf.fr.eu.org
Re: fail2ban
Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit : Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est x 3 ? Cordialement, JKB -- 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/54b6ec0d.1020...@systella.fr -- 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/7a063146-193c-41a0-aa68-a61edb48c...@worldonline.fr
Re: fail2ban
Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Le 14 janv. 15 à 22:50, BERTRAND Joël a écrit : Bonsoir à tous, J'ai un truc un peu bizarre avec fail2ban 0.9.1 que j'ai installé sur un serveur. J'ai patché l'outil pour qu'il traite aussi les IPv6 (https://tetsumaki.net/blog/article/2014-03-04-ajout-du- support-ipv6-sur-fail2ban.html). J'observe un comportement étrange sans savoir si ce comportement est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si c'est dû à l'augmentation ces derniers jours des attaques. En effet, j'ai un /29 et je subis actuellement en IPv4 des attaques sur toutes les IP à un rythme soutenu. ip(6)tables -L renvoient : ... (mes règles habituelles) Chain f2b-apache-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Chain f2b-courier-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Chain f2b-ejabberd-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere Il m'arrive d'avoir une centaine de RETURN au bout d'une journée. Je relance fail2ban et ça fonctionne jusqu'à la prochaine fois. Suis-je le seul à observer cela ? Cordialement, JKB -- 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/54b6e498.4050...@systella.fr -- 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/ba95a7b8-9391-4c00-8ab7-9f6160072...@worldonline.fr
Re: fail2ban
Le 14 janv. 15 à 23:35, BERTRAND Joël a écrit : Philippe Gras wrote: Le 14 janv. 15 à 23:22, BERTRAND Joël a écrit : Philippe Gras wrote: Je crois que le RETURN, ça veut seulement dire que la règle subit un transfert. De fait si j'ai bien compris, elle est passée par iptables à fail2ban qui va prendre la main dessus et la passer au tamis, puis la retourner à iptables avec les IP qu'il faut bannir. Ça, je sais. Ce qui m'étonne, ce n'est pas qu'il y ait un RETURN sur chacune des nouvelles cibles ajoutées par fail2ban, mais qu'il y ait plusieurs RETURN par cible et que ce nombre va en croissant au fil du temps... Tu as 3 références à chaque règle ou ça augmente ? Si ça augmente, c'est x 3 ? Non, j'ai plutôt l'impression que c'est un par un. Mais en dehors de la règle 'recidive' toutes augmentent en même temps et comportent le même nombre de RETURN. Rien compris ! Quand j'observe tes extraits : Chain f2b-apache-auth (3 references) target prot opt source destination RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere RETURN all -- anywhere anywhere C'est par 3, toujours par 3. Ce qui peut sembler logique vu qu'il y a 3 fichiers à patcher. Tu pourrais jeter un coup d'œil à l'intérieur pour voir s'ils ne retournent pas chacun une instruction similaire, pas vrai ? Cordialement, JKB -- 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/54b6ef45.6090...@systella.fr -- 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/578373bf-3777-47f4-9972-3fa327ba7...@worldonline.fr
Re: récupérer des données en RAID 1
Jose CHARTERS a écrit : Un disque n'est plus reconnu, le premier /dev/sda. Il ne reste plus que le second mais la machine n'arrive pas à démarrer dessus. Je suis surpris car il me semble que justement le raid 1 permettait de palier à ce type de panne. Non, pas par défaut avec le RAID logiciel md. Il faut explicitement installer le chargeur sur chaque disque. La procédure dépend du mode d'amorçage du firmware, BIOS/CSM/legacy ou UEFI. Ce serait différent avec du RAID matériel vrai ou faux (fakeRAID géré par le firmware et dm-raid). Bien sûr, je veux récupérer mes données sur le disque qui reste. Normalement on récupère les données à partir d'une sauvegarde, pas d'un RAID boiteux. Le RAID n'apport que la tolérance de panne, il ne remplace pas une sauvegarde. -- 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/54b6ff17.9000...@plouf.fr.eu.org
Re: Rafraichissement ecran
On 01/13/2015 10:05 PM, A. Dawson wrote: Le mardi 13 janvier 2015 à 21:52 +0100, Diogene Laerce a écrit : On 01/13/2015 03:20 PM, Diogene Laerce wrote: On 01/13/2015 12:03 PM, Alain Dawson wrote: J'ai le même problème depuis une récente mise à jour du driver propriétaire nvidia dans wheezy-backports. Qu'est-ce qui t'a permis de [...] A vrai dire je n'ai touché à rien : la solution que j'ai trouvée (revenir à une version antérieure du driver nvidia en utilisant snapshot.debian.net ; en l'occurrence la version du 1/12/2014) fonctionne, je n'ai pas trop envie de compliquer les choses. Je ferais peut être ca quand j'aurais le temps. Ce qui fonctionne aussi, c'est de passer au driver libre nouveau (mais j'utilise parfois Cinelerra qui est optimisé pour le driver nvidia propriétaire). Mais il ne fait pas la 3D si je ne m'abuse ? Le problème semble repéré, il y a un rapport de bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755683 mais pas de solution proposée à ce jour. Je fais confiance aux devs, ca se fera.. Un jour. :) Ce qui m'inquiète, c'est le futur passage à jessie, je me dis que je ne pourrai pas éternellement bloquer la version de nvidia-kernel-dkms et paquets associés... Il te faudra trafiquer ton /etc/apt/preferences sans doute. ;) -- “One original thought is worth a thousand mindless quotings.” “Le vrai n'est pas plus sûr que le probable.” Diogene Laerce signature.asc Description: OpenPGP digital signature
