Re: [stable] gestion sous domaines

2020-11-17 Par sujet Dethegeek 
Bonjour

Sous NGINX il faut créer autant blocs server {} que de sous domaines. Chaque 
bloc a une entrée 

Chacun peut avoir son certificat TLS.

Côté DNS le mieux est d'avoir un enregistrement A avec NSxxx.ip-xx-xx-xx.eu et 
des enregistrements CNAME pour les sous domaines.

https://nginx.org/en/docs/http/server_names.html



Le 18 novembre 2020 04:40:40 GMT+01:00, "Gaëtan Perrier" 
 a écrit :
>Bonjour,
>
>J'ai un serveur dédié sur lequel tourne une stable.
>Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
>fournisseur du serveur).
>J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
>adresse.
>Maintenant je voudrais gérer un 2e service.
>J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
>au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
>service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
>façon de le faire et des prérequis pour pouvoir le faire ?
>
>Gaëtan
>
>
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: [stable] gestion sous domaines

2020-11-17 Par sujet fabricer 

Hello Gaëtan,

Tes 2 sous-domaines, tu les crées dans ta gestion DNS ('A' et ''). 
Tu les fais pointer vers la même machine nsXXX.ip-xx-xx-xx.eu. C'est 
probablement chez ton hébergeur que ça se passe.


Ensuite, comme du parles de ngnix, je suppose que tu veux associer un 
site différent en fonction du sous-domaine. Alors, dans 
/etc/ngnix/sites-available, tu créés 2 fichier de conf différents qui 
commencent par:


server {
  server_name service1.TON_DOMAINE;

 location / {
root /data_service1;
  }
...

ensuite, tu n'oublies de créer un lien dans /etc/ngnix/sites-enable et 
de redémarrer ngnix.


Je ne te parles pas de SSL, de ngnix en mode proxy, ...

a+

f.


Le 18/11/2020 à 04:40, Gaëtan Perrier a écrit :

Bonjour,

J'ai un serveur dédié sur lequel tourne une stable.
Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
fournisseur du serveur).
J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
adresse.
Maintenant je voudrais gérer un 2e service.
J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
façon de le faire et des prérequis pour pouvoir le faire ?

Gaëtan

[stable] gestion sous domaines

2020-11-17 Par sujet Gaëtan Perrier 
Bonjour,

J'ai un serveur dédié sur lequel tourne une stable.
Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
fournisseur du serveur).
J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
adresse.
Maintenant je voudrais gérer un 2e service.
J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
façon de le faire et des prérequis pour pouvoir le faire ?

Gaëtan





signature.asc
Description: This is a digitally signed message part

Re: Installation des page en français pour "man" en Buster

2020-11-17 Par sujet didier gaumet 
Le mardi 17 novembre 2020 à 16:20:03 UTC+1, bubu a écrit :
[...]
> Si je veux avoir mon "man" en français sur Buster
> 
> Les paquets "manpages-fr-extra", "manpages-fr-dev", "manpages-fr" sont
> désuets en Buster.
> 
> Je pourrais installer ceux de Stretch ou ceux de testing (Bullseys) avec
> dpkg?

Je crains que ma réponse ne fasse qu'épaissir le mystère (avant qu'une bonne 
âme ne nous éclaire):

les paquets précités sont effectivement absents des dépôts de Buster alors 
qu'ils sont présents dans les dépôts
des distributions précédentes et suivantes.
Pourtant je suis en Buster (avec un peu de Backports), aucun de ces paquets 
n'est présent sur mon installation et mes pages man sont en français (testé à 
l'instant avec man man et man vim).
Je ne sais pas comment cela se fait, j'ai cherché (sans doute mal) une 
explication dans le journal des modifs Debian et je n'en ai pas trouvé. 
Peut-être une organisation de l'internationalisation des pages man différente 
dans Buster par rapport aux releases précédentes et suivantes?

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

2020-11-17 Par sujet Jérémy Prego 



Le 17/11/2020 à 17:21, Roger Price a écrit :
> On Tue, 17 Nov 2020, JUPIN Alain wrote:
>
>> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
>> un nombre relativement important de messages qui viennent d'adresse IP
>> "inconnues"
>> Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])
>>
>> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
>> J'ai la directive suivante dans le main.cf :
>> smtpd_sender_restrictions = reject_non_fqdn_sender,
>> reject_unknown_sender_domain, permit_sasl_authenticated,
>> permit_mynetworks
>>
>> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
>> autant tous les bloquer !
>
> Y compris ceci ?
>
> Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown
> [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])
>     (Authenticated sender: ajupin)
>     by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
>     for ; Tue, 17 Nov 2020
> 15:53:21 + (UTC)
> From: JUPIN Alain 
>
il ne faut pas tout confondre.

là, tu as collé une ip d'un client qui se connecte au smtp de free pour
envoyé le mail par ce dernier. le smtp de free lui a un reverse correct.
du coup le mail passse. ce n'est pas l'ip collé précédemment qui se
connecte directement au smtp distant. :)
> Roger

Jerem

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

2020-11-17 Par sujet Roger Price 

On Tue, 17 Nov 2020, JUPIN Alain wrote:


Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
un nombre relativement important de messages qui viennent d'adresse IP
"inconnues"
Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])

On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
J'ai la directive suivante dans le main.cf :
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks

PS : La plupart de ces messages passent en SPAM mais pas tous, mais
autant tous les bloquer !


Y compris ceci ?

Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown 
[IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])

(Authenticated sender: ajupin)
by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
for ; Tue, 17 Nov 2020 15:53:21 + 
(UTC)

From: JUPIN Alain 

Roger

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

2020-11-17 Par sujet Cyrille Bollu 
Apparement, il s'agit de l'option "reject_unknown_reverse_client_hostname"
que tu dois ajouter à ta liste de smtpd_sender_restriction

 

Bàt,

 

Cyrille

 

"JUPIN Alain" aju...@jupin.net – 17 novembre 2020 16:53
 

> Bonjour,
>
> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
> un nombre relativement important de messages qui viennent d'adresse IP
> "inconnues"
> Exemple : Received: from [149.27.181.246[1]] (unknown
[149.27.181.246[1]])
>
> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
> J'ai la directive suivante dans le main.cf[2] :
> smtpd_sender_restrictions = reject_non_fqdn_sender,
> reject_unknown_sender_domain, permit_sasl_authenticated,
permit_mynetworks
>
> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
> autant tous les bloquer !
>
> Merci par avance
>
>  



Links:
--
[1] http://149.27.181.246
[2] http://main.cf

[Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

2020-11-17 Par sujet JUPIN Alain 
Bonjour,

Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
un nombre relativement important de messages qui viennent d'adresse IP
"inconnues"
Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])

On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
J'ai la directive suivante dans le main.cf :
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks

PS : La plupart de ces messages passent en SPAM mais pas tous, mais
autant tous les bloquer !

Merci par avance

-- 
Alain JUPIN

Fwd: Installation des page en français pour "man" en Buster

2020-11-17 Par sujet bubu 




 Message transféré 
Sujet : Installation des page en français pour "man" en Buster
Date :  Tue, 17 Nov 2020 09:35:38 -0500
De :Martin Vézina 
Pour :  bu...@no-log.org



bubu, pourrait tu posté ce message sur
 pour moi? C'est le message que je
voulais posté initialement avant cette dérape.

--

Si je veux avoir mon "man" en français sur Buster

Les paquets "manpages-fr-extra", "manpages-fr-dev", "manpages-fr" sont
désuets en Buster.

Je pourrais installer ceux de Stretch ou ceux de testing (Bullseys) avec
dpkg?

Re: Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux

2020-11-17 Par sujet Gabriel Moreau 



PS: j'ai eu l'occasion de bosser sur un système dérivé d'un Unix où tous
les exécutables étaient signés par une clef locale. C'était chiant
(parce que la clef privée n'était forcément pas sur la machine en
question), mais ça évite l'exécution de programmes récupérés ici ou là.


Avec SElinux, tu peux faire cela...

gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015



smime.p7s
Description: Signature cryptographique S/MIME

Re: Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux

2020-11-17 Par sujet BERTRAND Joël 
Bureau LxVx a écrit :
> SaluX !
> 
> *Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux :
> *https://www.lemondeinformatique.fr/actualites/lire-le-ransomware-ransomexx-s-attaque-maintenant-aux-systemes-linux-80969.html?utm_source=ActiveCampaign_medium=email_campaign=NL+LMI+Selection+15112020_ee=93a54153fccd51d8123d50ee9c178ae270c63fcc_ee=Qk9kvX42OTXT0ijFpE0OJ%2BhteTmyolKtig6scymBiX8%3D*
> *
> Bon dimanche,

Bonjour à tous,

Deux informations, une bonne et une moins bonne. La bonne, c'est que
les serveurs Linux sont un peu partout, qu'il y a des données
importantes dessus et que si les pirates en question ciblent maintenant
ces serveurs, c'est qu'il y a de l'argent à se faire dessus.

La moins bonne, c'est que le développement de Linux est devenu
tellement anarchique qu'il n'y a plus aucune réelle revue de code (pour
s'en convaincre, regarder la gestion des modules dans le noyau à grands
coups de pointeurs nuls et ce qu'un individu mal intentionné peut en
faire). On se retrouve avec des failles non corrigées depuis trop
longtemps, des concepts pas trop secs avec des effets de bord bizarres
et la sensation de toujours essuyer les plâtres avec une brique. Je
n'avais pas cette sensation il y a vingt ans où je pouvais redémarrer
des serveurs à distance sans me poser de question. Aujourd'hui, je ne
prends plus ce risque sans avoir un système me permettant de reprendre
la main sur la console ! Je ne parle même pas de l'éditeur de liens
dynamiques qui est un poème (et un problème) à lui tout seul. Bon,
j'avoue, le problème de ld nécessite d'avoir accès à un shell local.
Mais il suffit d'une autre faille ailleurs pour avoir un tel accès.

Linux est maintenant à la mode mais je considère qu'il faut être fou
pour avoir des données critiques sur un tel système _aujourd'hui_,
surtout sans un sérieux système de sauvegarde ou d'archivage permettant
de repartir vite. Si des postes clients sont sous Windows et requièrent
des droits d'administrateurs locaux, c'est encore pire parce que c'est
généralement open bar côté serveur.

Bref, il va être temps de penser réellement à la sécurité (donc pas
avec des machines ouvertes à tous les vents grâce à une installation de
base). Ce point est trop souvent ignoré des distributions et des
développeurs. Il est aussi trop souvent ignoré par les administrateurs
et les utilisateurs.

Bien cordialement,

JKB

PS: j'ai eu l'occasion de bosser sur un système dérivé d'un Unix où tous
les exécutables étaient signés par une clef locale. C'était chiant
(parce que la clef privée n'était forcément pas sur la machine en
question), mais ça évite l'exécution de programmes récupérés ici ou là.

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

2020-11-17 Par sujet Daniel Caillibaud 
Le 16/11/20 à 20h15, Étienne Mollier  a écrit :
> L'ID d'un message est visible dans les en-têtes des messages
> envoyés

Pas vraiment, il n'est visible qu'une fois que le mail a transité par le
smtp (c'est lui qui fixe cet id), en général le mail que tu retrouves dans
tes messages envoyés est celui qui a été soumis au smtp (avant qu'il le
traite, donc sans cet id).

On peut tenter de récupérer l'id en se mettant en copie du mail pour
récupérer l'id dans la copie reçue (à vérifier, pas sûr que le smtp mette
toujours le même id pour un mail envoyé à deux destinataires ≠).

Mais ici il y a un bounce (le message d'erreur retourné à l'expéditeur),
toutes les infos sont dedans (dont l'id).

-- 
Daniel

C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je
ne plais pas, je me demande si ça me dérange vraiment . J'en suis même très 
souvent content.
Coluche

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

2020-11-17 Par sujet Daniel Caillibaud 
Le 16/11/20 à 18h53, Martin Vézina  a écrit :
> J'ai écrit as "Support du site:
> debian-l10n-fre...@lists.debian.org"
> pour signaler le problème et avec videotron.ca, il me sont revenus avec
> le même message...

C'est ce message d'erreur (complet) qu'il faudrait faire parvenir à
"listmas...@lists.debian.org", ici on ne pourra pas t'aider.

-- 
Daniel

L'urgent est fait. L'impossible est en cours. Pour les miracles, prévoir un
délai.

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

2020-11-17 Par sujet Daniel Caillibaud 
Le 16/11/20 à 19h35, Pierre Malard  a écrit :
> >> Ce serait bien plus simple pour diagnostiquer le problème d’avoir des
> >> logs des tentatives d’envoi. Ne pourrait-on l’avoir ?
> >> 
> >> En général c’est un fichier « /var/log/mail.xxx » pour Postfix.  
> > 
> > Ce serait effectivement plus simple, mai je doute qu'il puisse accéder
> > aux logs de ses fournisseurs de mail (ici hotmail ou videotron.ca) ;-)  
> 
> Sauf s’il envoie ses mail depuis son poste local et pas d’un Webmail…

J'avais compris que le pb ne se posait que pour 
  hotmail => lists.debian.org
  videotron.ca => lists.debian.org

> Si c’est du Webmail il faut se retourner uniquement sur son fournisseur
> d’accès alors et pas essayer de résoudre son problème à sa place !

Certes…

-- 
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.