Le problème :
Avec un serveur dédié chez OVH, il arrive que l'on veuille gérer son DNS directement.
Donc le DNS primaire est votre serveur, OVH propose des DNS secondaires qui se synchronise avec vous. En général ces DNS secondaires sont plus utilisés par le reste du WEB que le votre.
Le serveur secondaire de chez OVH ne propagait pas mes modifications
Solution :
Bête comme choux, mais encore faut-il ne pas l'oublier, les enregistrements DNS ont un timestamp.
Il faut l'incrémenter à chaque fois, c'est sur ce critère que le DNS secondaire se remet à jour.
(On aurait aussi pu utiliser des outils tout fait, qui, eux, n'oublie pas ça !)
Sinon, éditer : /etc/bind/pri/mondomaine.fr et incrémenter la date (2015010107)
mondomaine.fr. IN SOA mondomaine.fr. postmaster.mondomaine.fr. (
2015010107
21600
3600
604800
86400 )
IN NS ns1234.ovh.net.
IN NS sdns2.ovh.net.
IN MX 10 mail.mondomaine.fr.
IN A 1.1.1.1
Ensuite
/etc/init.d/name reload
# ou tout autre commande suivant la version de votre système
Le problème :
Après avoir installé un serveur de mail. Gmail refusait les mails envoyés depuis ce serveur.
"Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information"
Et là, il faut suivre les conseils vagues de Google, heureusement d'autres sites sont de meilleurs aides, exemple : https://www.mail-tester.com/
Le contexte :
- un serveur de mail + un nom de domaine (MONDOMAINE)
- un deuxième serveur de mail qui envoie des mails sur ce même domaine
Solution :
Suivre les recommendations du site mail-tester :)
Cela m'a conduit à :
Déclarer des enregistrements DNS sur MONDOMAINE pour autoriser mon deuxième serveur à envoyer des mails :
SERVEUR2.MONDOMAINE IN A IP-SERVEUR-2
MONDOMAINE. IN TXT "v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"
MONDOMAINE. IN SPF "v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"
Vérifier que le postfix de mon 2eme serveur est identifié avec SERVEUR2.MONDOMAINE
-
maintenant les serveurs SMTP reçevant nos mails savent que le deuxième serveur est autorisé à les envoyé.
-
que le nom de domaine SERVEUR2.MONDOMAINE est cohérent avec qui est déclaré dans postfix
-
ne pas avoir configurer postfix en openrelay, mais ça il faut l'avoir fait exprès
Il faut aussi installer des signatures DKIM en sortant :
mail._domainkey.MONDOMAINE. IN TXT ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
-
on aurait pu avoir glustork à la place comme selecteur ! C'est aussi le principe d'avoir X domaines et X sélecteur pour avoir des clés de chiffrement différentes
glustork._domainkey.MONDOMAINE. IN TXT ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
-
des outis pour vérifier les DNS existent sur le Web (ici, là, ...)
-
mais un petit DIG suffit aussi :
dig mail._domainkey.<domaine>.fr TXT @dnsserver.com
Le problème :
Analyser les logs Apache (entre autre) avec un système de requêtage.
Alors il y a bien l'outil fait à la main, ça marche toujours :) mais je voulais tenter une stack ELK (Elasticsearch Logstash Kibana)
Solution :
Tout d'abord l'installation :
- je suis parti du docker qnib/elk (https://hub.docker.com/r/qnib/elk/).
- auquel j'ajoute le plugin elasticsearch-head pour la visulation des données
- création du docker initial (commité depuis avec le plugin elasticsearch) :
. envir.sh
sudo docker run -t -i --rm -h elk --name sgl-elk --privileged \
${DNS_STUFF} ${DEV_MOUNTS} ${LINK} \
${HTTP_PORT} ${LS_CONF} ${AP_LOG} \
-e HTUSER=${HTUSER} -e HTPASSWD=${HTPASSWD} \
${ES_PERSIST} qnib/elk:latest bash
- fichier d'environnement (envir.sh) :
# To get all the /dev/* devices needed for sshd and alike:
export DEV_MOUNTS="-v /dev/null:/dev/null -v /dev/urandom:/dev/urandom -v /dev/random:/dev/random"
export DEV_MOUNTS="${DEV_MOUNTS} -v /dev/full:/dev/full -v /dev/zero:/dev/zero"
### OPTIONAL -> if you want to store Elasticsearchs data outside
export ES_PERSIST="-v ${HOME}/elk/elasticsearch:/data/"
### OPTIONAL -> To use a mapped in configuration directory
# if not used, the default will be used within the container
export LS_CONF="-v ${HOME}/elk/logstash.d/:/etc/logstash/conf.d/"
### OPTIONAL -> map apache2 config into container
export AP_LOG="-v ${HOME}/elk/var/log/apache2/:/var/log/apache2"
### OPTIONAL -> set the external port to something else then 80
export HTTP_PORT="-e HTTPPORT=8080 -p 8080:80 -p 9200:9200 -p 5601:5601"
### OPTIONAL -> To secure kibana and elasticsearch user/passwd could be set
# if a user is set and no passwd, the user will be set as password
export HTUSER=kibana
export HTPASSWD=kibana
Utilisation en oneshot :
- je fais du parsing à la demande plutôt que d'utiliser la stack en monitoring de log continu :
bin/logstash -f /etc/logstash/conf.d/10_apache.conf
- un exemple de fichier configuration logstash pour Apache :
input {
file {
path => "/var/log/apache2/test.log"
start_position => "beginning"
type => "apache"
}
}
filter {
if [type] == "apache" {
grok {
match => [ "message", "%{COMBINEDAPACHELOG}" ]
add_tag => ["apachelog"]
}
if "apachelog" in [tags] {
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
}
geoip {
source => "clientip"
target => "geoip"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}
}
}
output {
if [type] == "apache" {
stdout { codec => rubydebug }
elasticsearch {
protocol => "http"
cluster => "logstash"
}
}
}
- ensuite je me connecte sur elasticsearch pour vérifier que les données ont bien été insérées :
http://localhost:9200/_plugin/head/
- puis sur Kibana pour exploiter les logs :
http://localhost:8080 (kibana3)
http://localhost:5601 (kibana4)
Edit :
- Utilsation de grok : https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html
- les patterns grok d'ELK : https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns
Le problème :
Connecter Yourkit à un Tomcat installé localement sur une machine Windows
Tomcat exécuté en tant que service avec le profil Administrateur
Solution :
Bon rappel de ce qui est décrit ici
-
Tomcat5 : installation / désintallation du service
-
Tomcat5w : fenetre de contrôle du service et de ses paramètres
Il faut donc exécuter ces programmes dans une console en ligne de commande "admin" :
# Démarrer
# Exécuter...
cmd
# Valider avec : "Ctrl + Shift + Enter"
Sinon, on peut toujours faire bouton droit sur Tomcat5w et "exécuter en tant qu'Administrateur".
Ensuite, ajouter le lien vers l'agent Yourkit :
-
Il faut mettre les chemins courts de Windows !
-
De cette manière :
# Nom court sous windows :
dir /x c:\
# Pour obtenir au final le chemin complet :
dir C:\PROGRA~2\YOURKI~1.6\bin\win32\yjpagent.dll
Ajouter le chemin aux paramètres de la JVM du service Tomcat :ourkit
-agentpath:C:\PROGRA~2\YOURKI~1.6\bin\win32\yjpagent.dll
Et ne pas oublier de démarrer Yourkit en mode Administrateur.
Le problème :
Comme d'autres, installer un serveur de mail sous une Debian.
En multidomaines.
Avec plusieurs serveurs de mails.
Solution :
Il y a d'excellent tutos sur Internet qui m'ont ammené quasiment la solution sur un plateau :
Solution générale :
-
postfix (SMTP + STARTTLS only)
-
délégation d'authentification à dovecot via SASL
-
dovecot pour IMAP + POP (en STARTTLS only aussi)
-
base de données pour les domaines multiples via postfixadmin
Quelques notes sur les difficultés que j'ai rencontré :
-
une architecture de postfix : http://loic.marrot.free.fr/travaux/rapportProjetMessagerie.html
-
Un peu de vocabulaire sur les protocoles :
-
SMTP : pour envoyer des mails à un serveur de mail (depuis un client mail ou entre les serveurs de mails)
-
POP : du client mail au serveur mail pour aller récupérer ses mails
-
IMAP : idem que POP, mais il y a un échange pour synchroniser l'état du client et du serveur. Ainsi on peut avoir la même vision de ses mails depuis plusieurs endroits
-
SASL : protocole pour déléguer l'authentificaiton à un tiers. Exemple ici, postfix se base sur Dovecot pour savoir si un utilisateur est connu ou non. Entre Postfix et Dovecot, on fait du SASL
-
STARTTLS : afin de sécuriser les échanges par défaut non chiffré des différents protocoles (POP, IMAP, SMTP), on peut démarrer une session sécurisé à partir d'une connexion non sécurisée à la base. On démarre le TLS (sucesseur de SSL) : STARTTLS.
-
IMAPS, POPS : variante de POP et IMAP directement en TLS, mais peu usité, au profit du STARTTLS
-
Pour chacun de ces protocoles, il y a des ports par défaut que l'on retrouve dans /etc/services
-
Il est possible d'ajouter des logs en ajoutant "-v" aux différents démons postfix (cf la documentation officielle)
-
Le hostname de la machine et le DNS doivent être cohérent ! (cf hostame & postfix)
-
Posftixadmin & Thunderbird portable sont bien pratique pour tester des clients mails
-
Multiple domaines :
-
mydestination ne doit pas contenir les hosts virtuels stockés en BDD Mysql (voir virtual_mailbox_domains)
-
Pour le lien avec Dovecot
-
J'ai ajouté une ligne dans /etc/postfix/master.cf, comme indiqué dans certains tutoriaux plus haut
-
Je n'ai pas activé l'option # -o smtpd_sasl_type=dovecot sur submission dans master.cf mais ajouté ces options dans main.cf
# SASL SMTPS
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
-
Bien valider l'authentification
-
pour Dovecot, utiliser le paramètre "ssl=required"
-
le paramètre smtpd_tls_auth_only peut-être mis à "no" le temps des tests, le mettre à "yes" ensuite
-
pour tester l'authentification (extrait d'ici) :
perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'
-
swaks est outil super ! mais il ne faut oublier de préciser le serveur smtp (sinon il s'adresse directement au MX du domaine ciblé et ne passe pas par votre serveur !)
echo "This is the message body" | swaks --to web-4pDEEq@mail-tester.com --from "www-data@test.fr" --server localhost 25
Ca a suffit pour envoyer / recevoir des mails en TLS sur des noms de domaines que je maitrisais.
Pour ne pas être considéré comme spammeur, ce fut une autre histoire !
Fil RSS des articles
