Re: Bloquer un TLD sous Postfix
Bonjour, Le 04/04/2018 à 15:57, Daniel Caillibaud a écrit : La doc ;-) http://www.postfix.org/postconf.5.html#check_client_access http://www.postfix.org/postconf.5.html#check_sender_access http://www.postfix.org/access.5.html check_client_access vérifie le host qui te cause, check_sender_access le domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions car ça c'est pas une restriction sur le destinataire, faut le mettre dans une restriction sur l'expéditeur (smtpd_sender_restrictions). Effectivement, il fallait mettre le blacklist email dans sender_restrictions et le blacklist_hosts dans client_restrictions. Cela semble fonctionner pour l'instant Sinon, juste un avis, je trouve plus facile de s'y retrouver en mettant du check_sender_access hash:check_sender_access.hash (avec un suffixe .list ou .pcre suivant les cas), je trouve que ça permet de mieux savoir ce qu'on modifie quand on édite le fichier (et aussi de faire du postmap *.hash pour pas en oublier un). Ça reste une convention parmi d'autres, le tout est d'en suivre une qui te semble logique et où tu t'y retrouve. Une autre solution pour le spam (en plus de ton antispam), moins radicale mais efficace, c'est de filtrer sur les headers et de marquer les mails comme spam ou bulk ou ce que tu veux, mais de les livrer quand même, avec par ex : [] Après, si tu es le seul à avoir des boîtes mails sur ce serveur, tu peux bien sûr adopter des règles plus radicales et jeter ou refuser des mails, chose que je me permet pas ayant des boites pour d'autres personnes. En fait, sur ce TLD précis, 100% des mails envoyés sont non sollicités et cela n'a rien à voir avec des newsletters. Voilà pourquoi je souhaite opter pour une solution radicale. Par ailleurs, suite à ce message, j'ai eu une réponse en privée (et non sur cette liste) d'une personne qui a carrément juger bon de m’appeler sur mon téléphone portable perso pour savoir si sa réponse convenait ! C'est nouveau çà ? c'est un cas généralisé ici ? car sincèrement, je trouve la démarche "douteuse". Mais merci à vous pour vos réponses. Alain
Re: Bloquer un TLD sous Postfix
Salut, > Sur mon installation Postfix sous Wheezy, je cherche à rejeter tous les > messages dont l'adresse email provient du tld .top (donc toutes les adresse > en x...@.top) car 100% des emails reçus depuis ce TLD sont des publicités > non sollicitées … g ayant été emmerdé aussi par ce voyou, j'ai constitué un système pour récupérer toutes ses plages IP à bloquer (avec bash et ipcalc), et que je vous livre dans un fichier à télécharger ici : https://fichiers.enpret.com/top.txt Bonne réception, Ph. Gras
Re: Bloquer un TLD sous Postfix
Bonjour, Pas sur de la syntaxe, mais je propose ceci : Le Wed, 4 Apr 2018 14:56:08 +0200 JUPIN Alain a écrit >Et dans le fichier blacklist_hosts /^*.\.top$/ REJECT >Puis dans le fichier blacklist_email /^*.\.top$/ REJECT
Re: Bloquer un TLD sous Postfix
Le 04/04/18 à 14:56, JUPIN Alaina écrit : JA> Bonjour, JA> JA> Sur mon installation Postfix sous Wheezy, je cherche à rejeter tous les JA> messages dont l'adresse email provient du tld .top (donc toutes les JA> adresse en x...@.top) car 100% des emails reçus depuis ce TLD sont JA> des publicités non sollicitées ... g JA> JA> Dans le main.cf, j'ai mis ceci : JA> smtpd_recipient_restrictions = JA> permit_mynetworks, JA> permit_sasl_authenticated, JA> check_client_access hash:/etc/postfix/blacklist_hosts, JA> check_sender_access hash:/etc/postfix/blacklist_email, JA> reject_non_fqdn_recipient,. JA> JA> Et dans le fichier blacklist_hosts JA> .top REJECT JA> JA> Puis dans le fichier blacklist_email JA> .top REJECT JA> JA> Bien sur j'ai effectué le postmap des fichiers blacklist_hosts et JA> blacklist_email, redemarré Postfix et les mails passent toujours :( JA> JA> J'ai foiré quelle étape ? La doc ;-) http://www.postfix.org/postconf.5.html#check_client_access http://www.postfix.org/postconf.5.html#check_sender_access http://www.postfix.org/access.5.html check_client_access vérifie le host qui te cause, check_sender_access le domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions car ça c'est pas une restriction sur le destinataire, faut le mettre dans une restriction sur l'expéditeur (smtpd_sender_restrictions). Sinon, juste un avis, je trouve plus facile de s'y retrouver en mettant du check_sender_access hash:check_sender_access.hash (avec un suffixe .list ou .pcre suivant les cas), je trouve que ça permet de mieux savoir ce qu'on modifie quand on édite le fichier (et aussi de faire du postmap *.hash pour pas en oublier un). Ça reste une convention parmi d'autres, le tout est d'en suivre une qui te semble logique et où tu t'y retrouve. Une autre solution pour le spam (en plus de ton antispam), moins radicale mais efficace, c'est de filtrer sur les headers et de marquer les mails comme spam ou bulk ou ce que tu veux, mais de les livrer quand même, avec par ex : header_checks = pcre:/path/to/header_checks.pcre et dedans tu peux mettre par ex des regex sur les headers comme /^Received:.*\.(demarque-en-cours\.com|elasticemail\.info|tendances-maison\.com/ PREPEND X-Bulk: YES detected 32 Le n° me sert juste à savoir quelle règle il s'est pris quand je regarde un faux positif (ça peut toujours arriver), et coté livraison si y'a du X-Bulk dans les headers je mets ça dans un dossier bulk, car l'envoi en masse n'est pas forcément du spam ;-) (et celui qui est vraiment abonné à une newsletter qu'il veut recevoir ailleurs que dans bulk peut se mettre une règle avant celle-là pour choisir son dossier de livraison) Après, si tu es le seul à avoir des boîtes mails sur ce serveur, tu peux bien sûr adopter des règles plus radicales et jeter ou refuser des mails, chose que je me permet pas ayant des boites pour d'autres personnes. -- Daniel Le mec qui a convaincu les aveugles de porter des lunettes de soleil est quand même un excellent commercial.
Bloquer un TLD sous Postfix
Bonjour, Sur mon installation Postfix sous Wheezy, je cherche à rejeter tous les messages dont l'adresse email provient du tld .top (donc toutes les adresse en x...@.top) car 100% des emails reçus depuis ce TLD sont des publicités non sollicitées ... g Dans le main.cf, j'ai mis ceci : smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/blacklist_hosts, check_sender_access hash:/etc/postfix/blacklist_email, reject_non_fqdn_recipient,. Et dans le fichier blacklist_hosts .top REJECT Puis dans le fichier blacklist_email .top REJECT Bien sur j'ai effectué le postmap des fichiers blacklist_hosts et blacklist_email, redemarré Postfix et les mails passent toujours :( J'ai foiré quelle étape ? Merci à vous pour votre aide. -- Alain JUPIN
Re: Backups automatiques d'une base de donnée vers un périphérique de stockage
Salut, Deux pistes parmi d'autres : a) la crontab a1- Une instruction(script) nocturne qui monte un point de montage réseau a2- Une autre (qlq min plus tard) qui arrête le serveur sql, mais ca peut aller jusqu'à substituer et présenter une jolie page d'accueil avec un sablier. a3- Une autre (qlq min plus tard) qui fait le dump en écrivant sur le point de montage. a4- Une autre (qlq min plus tard) qui redémarre le serveur (éventuellement remet l'appli web en service) et démonte le pt de montage. b)Je me demande si lsyncd ne te permettrait pas de lancer des scripts dans lequel tu ferais un dump https://axkibe.github.io/lsyncd/manual/config/layer2/ https://packages.debian.org/stretch/lsyncd J'utilise ça pour des backups de mon système de fichier, ça m'étonnerait qu'il ne soit pas utilisable au moins pour une partie des opérations de 1 à 4. @+ -- Benoit Le 23 mars 2018 à 16:49,a écrit : > Bonjour à tous, > > Je possède un petit Rasberry sur lequel je me suis amusé à créer une > application web « locale ». Dans un souci de prévoir à l’imprévu, j’aimerais > effectuer une backup automatique des bases de données stocké dans ce dernier > vers une clef USB (par exemple). > > Il va de soi que le RPI est sous Rasbian ! > > Merci d’avance pour vos pistes de réflexion et votre aide avisée ! > > Bonne fin de semaine à tous ! > > > > Clément VANDENDAELEN > > Web : www.vandendaelen.com > >
Re: Plantage bizarre
Le 04/04/18 à 09:29, Christophe De Natalea écrit : CDN> Je me lance : Merci :-) CDN> le pc n'a jamais été déconnecté du réseau électrique et CDN> la pile 3 volts est à plat ? C'est bien possible, mais l'heure était bonne lorsque je suis allé dans le bios après avoir éteint l'alim, je vais tester de nouveau à la pause dej en laissant l'alim coupée un moment. CDN> Du coup les réglages du bios affectés à l'époque ont disparu ? CDN> Du style le lien ahci passé en ide ou la gestion d'énergie modifiée... Et ça expliquerait le plantage, pourquoi pas, sauf que je me souviens pas du tout avoir modifié ces paramètres de gestion d'énergie… Et ça n'explique pas vraiment mon pb réseau, car y'a pas eu de reboot entre avant / après le changement de box (y'en a eu un hier soir, redémarrage "propre" depuis debian, et j'ai pas eu l'image avant le bios à ce moment là), le pb github est apparu après cette modif réseau, mais sans reboot. J'ai eu un bios différent (avec l'image) après le boot qui m'a obligé à éteindre l'alim, donc ça pourrait coller, sauf que le plantage a eu lieu avant ce boot, donc y'aurait déjà eu un pb de bios avant ? C'est possible d'avoir un bios qui reset certaines valeurs mais pas toutes en cas de pile fatiguée ? Il va falloir que je me replonge dans la doc pour comprendre chaque param du bios, et le hardware est vraiment un truc qui m'intéresse pas :-/ (aussi pour ça que je garde mes machines aussi longtemps, le matériel marche => on touche plus au hardware) Je vais commencer par désinstaller mes paquets de gestion d'hibernation, et remettre le bios par défaut, mais apparemment je peux pas désactiver l'acpi - Suspend Mode [Auto] avec aussi S1 (power on suspend sleeping mode), et S3 (Suspend to RAM) P'tet forcer S3 ? - ACPI 2.0 Support [Disabled] Allows you to add more tables for Advanced Configuration and Power Interface (ACPI) 2.0 specifications. Je suppose que c'est mieux d'activer vu que debian gère ça depuis longtemps, mais j'en sais rien - ACPI APIC Support [Enabled] Allows you to enable or disable the Advanced Configuration and Power Interface (ACPI) support in the Advanced Programmable Interrupt Controller (APIC). When set to Enabled, the ACPI APIC table pointer is included in the RSDT pointer list. Idem… -- Daniel Un clavier azerty en vaut deux.
Re: Plantage bizarre
Le 04/04/2018 à 08:35, Daniel Caillibaud a écrit : Bonjour, Bonjour, J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand même un truc louche coté réseau [1]. Quelques heures plus tard, mon PC s'est figé (image fixe, plus de clavier ni de souris), et les logs kernel sont curieux, on dirait une mise en veille [2]. Pas moyen de le redémarrer au bouton en façade (ventilos mais pas l'image habituelle du bios qui précède grub, écrans noirs), il a fallu couper l'alim et redémarrer. Au redémarrage, j'ai comme l'impression que le bios s'est remis avec ses réglages par défaut car il m'a affiché l'image du constructeur au début du démarrage (que j'avais pas avant). [...] Une piste ? [...] Je me lance : le pc n'a jamais été déconnecté du réseau électrique et la pile 3 volts est à plat ? Du coup les réglages du bios affectés à l'époque ont disparu ? Du style le lien ahci passé en ide ou la gestion d'énergie modifiée... -- Christophe
Plantage bizarre
Bonjour, J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand même un truc louche coté réseau [1]. Quelques heures plus tard, mon PC s'est figé (image fixe, plus de clavier ni de souris), et les logs kernel sont curieux, on dirait une mise en veille [2]. Pas moyen de le redémarrer au bouton en façade (ventilos mais pas l'image habituelle du bios qui précède grub, écrans noirs), il a fallu couper l'alim et redémarrer. Au redémarrage, j'ai comme l'impression que le bios s'est remis avec ses réglages par défaut car il m'a affiché l'image du constructeur au début du démarrage (que j'avais pas avant). J'ai bossé qq heures, puis en rédigeant ce mail j'ai voulu faire un lshw pour filer plus d'infos et il s'est de nouveau figé, mais sans rien raconter dans les logs (plantage 10 à 20s après le lancement de `lshw -short`, je viens de relancer la commande qui répond en 1~2s). C'est une debian stretch classique, avec un 4.9.0-4-amd64, sur un vieux coucou qui devrait fêter bientôt ses 10 ans, mais vu qu'il me suffit pour mon taf quotidien je pensais pas le changer tout de suite :-/ C'est un cpu intel Q9550 avec une CM Asus P5QL PRO, et network AR8121/AR8113/AR8114 Gigabit or Fast Ethernet display GF119 [GeForce GT 610] Une piste ? [1] Pb github Après changement de box fibre et avoir récupéré du réseau (en laissant le dhcp gérer le fait que la connexion était revenue), tout fonctionnait bien sauf github : - git clone https://github… OK - git clone g...@github.com… KO - commandes git sur mes dépôts locaux avec un remote sur github HS - commandes git sur mes dépôts locaux avec un autre remote OK - github.com via un navigateur est chaotique (coupures tcp sur la plupart des requêtes, login difficile, coupure systématique sur les sockets http) - depuis mon PC portable qui utilise la même box en wifi tout ça fonctionne normalement Après 2h à chercher, tenté un reboot, ça n'a logiquement rien changé. Modifier l'adresse mac de ma carte réseau non plus. [2] logs kernel Apr 4 03:25:43 quad kernel: [10946.508298] PM: Syncing filesystems ... done. Apr 4 03:25:43 quad kernel: [10946.524369] PM: Preparing system for sleep (mem) Apr 4 03:25:43 quad kernel: [10946.524561] Freezing user space processes ... (elapsed 0.002 seconds) done. Apr 4 03:25:43 quad kernel: [10946.526759] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Apr 4 03:25:43 quad kernel: [10946.527954] PM: Suspending system (mem) Apr 4 03:25:43 quad kernel: [10946.527988] Suspending console(s) (use no_console_suspend to debug) Apr 4 03:25:43 quad kernel: [10946.531763] serial 00:06: disabled Apr 4 03:25:43 quad kernel: [10946.531769] serial 00:06: System wakeup disabled by ACPI Apr 4 03:25:43 quad kernel: [10946.532036] sd 2:0:0:0: [sda] Synchronizing SCSI cache Apr 4 03:25:43 quad kernel: [10946.532056] sd 2:0:1:0: [sdb] Synchronizing SCSI cache Apr 4 03:25:43 quad kernel: [10946.532668] nouveau :01:00.0: DRM: suspending console... Apr 4 03:25:43 quad kernel: [10946.532672] nouveau :01:00.0: DRM: suspending display... Apr 4 03:25:43 quad kernel: [10946.532730] nouveau :01:00.0: DRM: evicting buffers... Apr 4 03:25:43 quad kernel: [10946.535273] sd 2:0:0:0: [sda] Stopping disk Apr 4 03:25:43 quad kernel: [10946.535417] sd 2:0:1:0: [sdb] Stopping disk Apr 4 03:25:43 quad kernel: [10947.677212] nouveau :01:00.0: DRM: waiting for kernel channels to go idle... Apr 4 03:25:43 quad kernel: [10947.677253] nouveau :01:00.0: DRM: suspending client object trees... Apr 4 03:25:43 quad kernel: [10947.677759] nouveau :01:00.0: DRM: suspending kernel object tree... Apr 4 03:25:43 quad kernel: [10949.368231] PM: suspend of devices complete after 2839.975 msecs Apr 4 03:25:43 quad kernel: [10949.368725] PM: late suspend of devices complete after 0.492 msecs Apr 4 03:25:43 quad kernel: [10949.369073] ehci-pci :00:1d.7: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369107] uhci_hcd :00:1d.2: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369146] uhci_hcd :00:1d.1: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369183] uhci_hcd :00:1d.0: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369357] ehci-pci :00:1a.7: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369358] uhci_hcd :00:1a.2: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369411] uhci_hcd :00:1a.1: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.369426] uhci_hcd :00:1a.0: System wakeup enabled by ACPI Apr 4 03:25:43 quad kernel: [10949.388047] PM: noirq suspend of devices complete after 19.319 msecs Apr 4 03:25:43 quad kernel: [10949.388862] ACPI: Preparing to enter system sleep state S3 Apr 4 03:25:43 quad kernel: [10949.389127] PM: Saving platform NVS memory Apr 4 03:25:43 quad kernel: [10949.389361] Disabling non-boot CPUs ... Apr 4