Re: Bloquer un TLD sous Postfix

2018-04-04 Par sujet JUPIN Alain

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

2018-04-04 Par sujet Ph. Gras
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

2018-04-04 Par sujet Grégory Bulot
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

2018-04-04 Par sujet Daniel Caillibaud
Le 04/04/18 à 14:56, JUPIN Alain  a é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

2018-04-04 Par sujet JUPIN Alain

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

2018-04-04 Par sujet Benoit B
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

2018-04-04 Par sujet Daniel Caillibaud
Le 04/04/18 à 09:29, Christophe De Natale  a
é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

2018-04-04 Par sujet Christophe De Natale

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

2018-04-04 Par sujet Daniel Caillibaud
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