Category: Web/Tech | Page 20

Serveur dédié : installer et configurer Varnish 4

3 October 202127 octobre 2014 by Matt Biscay · Lecture: 11 minutes

Cette semaine, j’ai décidé de mettre mon installation de Varnish à jour.

La version 3.0.5 date de décembre 2013 et il est temps de mettre le serveur à jour pour bénéficier des dernières nouveautés et corrections de bugs. Nous passons donc de Varnish 3 à Varnish 4.

Cela ne se fait pas sans peine car chez Varnish, ils renomment certaines directives d’une version à l’autre… ce qui fait planter le serveur Varnish puisqu’il ne reconnait plus les directives.

Résultat : le fichier de configuration de la version précédente plantera obligatoirement sous la dernière version !

Ce tutoriel en 3 étapes nous donnera l’occasion de mettre à jour Varnish et de scinder notre fichier de configuration en plusieurs modules de manière à en simplifier l’édition et la maintenance futures.

Etape 1 : mise à jour des dépôts Varnish

Pour mettre à jour Varnish, il suffit de pointer apt vers les derniers dépôts à jour. On édite donc /etc/apt/sources.list :

nano /etc/apt/sources.listCode language: PHP (php)

et on y met à jour nos dépôts:

# varnish
deb http://repo.varnish-cache.org/debian/ wheezy varnish-4.0Code language: PHP (php)

On rafraîchit la liste des paquets et on lance la mise à jour :

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

Varnish est maintenant mis à jour mais loin d’être fonctionnel étant donné que le format du fichier de configuration a changé.

Etape 2 : le nouveau fichier de configuration de Varnish 4 pour WordPress

Certaines directives ont changé de nom et, malgré avoir lu le guide de migration officiel, j’ai modifié mon fichier de configuration en corrigeant les erreurs une à une. Cela prend du temps mais au final, le fichier est plus clair qu’avant.

PHP : résoudre l’erreur “it is not safe to rely on the system’s timezone settings”

30 March 202219 octobre 2014 by Matt Biscay · Lecture: 3 minutes

Voici le message d’erreur PHP qui est apparu récemment dans mes logs Apache :

PHP Warning: strtotime(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone ‘UTC’ for now, but please set date.timezone to select your timezone.

Ajout de la directive date.timezone dans php.ini

On commence par trouver le fichier php.ini qui est actuellement utilisé par le serveur. Il en existe plusieurs, suivant les modules activés donc on commence par repérer le bon avec :

php -i | grep 'Configuration File'Code language: JavaScript (javascript)

Résultat :

Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini
PHP Warning:  Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Unknown on line 0Code language: JavaScript (javascript)

Effectivement, l’erreur est répétée même dans un simple phpinfo(). On édite donc notre fichier :

nano /etc/php5/cli/php.ini

La page de manuel des timezones nous indique toute la liste des fuseaux horaires disponibles. Nous choisissons celle qui correspond à l’emplacement de notre serveur : ‘Europe/Paris’.

On recherche la bonne directive avec Ctrl + W et en tapant :

date.

On trouve alors :

[Date]
; Defines the default timezone used by the date functions
; http://php.net/manual/en/datetime.configuration.php#ini.date.timezone
;date.timezone =Code language: JavaScript (javascript)

qu’il faut modifier en :

[Date]
; Defines the default timezone used by the date functions
; http://php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'Europe/Paris'Code language: JavaScript (javascript)

On relance Apache pour prendre en compte la nouvelle configuration :

service apache2 restart

Linux : installation d’une carte WiFi b/g/n Broadcom 43222

30 March 202215 octobre 2014 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, je me suis encore amusé à mettre à jour mon portable Toshiba de 2005 : après lui avoir mis un SSD et Linux Mint, je lui ai offert une carte WiFi Broadcom 43222, en remplacement de l’Intel WM3B2200BG d’origine.

Je me suis aperçu que c’était difficile pour cette machine de capter le signal WiFi, que ce soit à la maison ou lorsque je suis à l’étranger : il n’y a rien de plus vexant que d’amener sa machine et de ne pas pouvoir se connecter au réseau.

Changer une carte réseau sur un ordinateur portable n’a rien de bien compliqué mais il m’a fallu du temps pour trouver une carte de remplacement compatible : toutes les nouvelles cartes sont en PCI-Express maintenant, or mon Toshiba n’accepte que du Mini-PCI Type III.

La carte Broadcom est la seule que j’ai trouvé qui fasse WiFi N et qui soit en Mini-PCI, je l’ai achetée pour une dizaine d’euros sur Ebay.

Par conséquent, voici un petit tutoriel qui montre comment changer une carte WiFi sur un Toshiba Satellite.

Etape 1 : démontage et remplacement de la carte

On commence par la base : on éteint la machine, on enlève le courant et on retire la batterie. Et on touche un objet métallique pour décharger l’électricité statique, on ne sait jamais.

Voici quelques images intéressantes pour le démontage du Toshiba Satellite.

1. Retourner le laptop pour avoir accès aux modules et enlever la batterie.

2. Retirer la vis du module WiFi.

3. Déconnecter les câbles de l’antenne de la carte. Le fil blanc va sur MAIN et le fil noir sur AUX.

4. Retirer la carte WiFi. Il suffit d’écarter simplement les deux pattes qui la retiennent : elle va se lever doucement et vous pourrez la retirer doucement. Il ne faut surtout pas utiliser la force : juste écarter les deux pattes et lever la carte.

5. Insérer la nouvelle carte. Elle est plus compacte donc aucun souci pour la placer. Remettre les deux fils d’antenne. Revisser le compartiment.

Etape 2 : installation des pilotes

Une fois la carte changée, un reboot et vous vous apercevez que nous n’avez plus le WiFi ? C’est normal, la nouvelle carte nécessite des pilotes qui ne sont pas installés par défaut… il faut donc passer par une connexion Ethernet le temps de les installer.

Je n’avais pas anticipé cela quand j’avais commencé le tutoriel mais étant chez moi, cela n’a pas posé de souci. C’est une chose importante à souligner toutefois.

Notre nouvelle carte est normalement gérée par les pilotes b43. On peut le vérifier avec cette commande :

sudo lspci -vnn -d 14e4:

qui retourne ceci :

06:02.0 Network controller [0280]: Broadcom Corporation BCM43222 Wireless Network Adapter [14e4:4350]Code language: CSS (css)

La dernière partie entre crochet – 4350 – signifie que nous avons bien affaire à une carte Broadcom BCM43222, prise en charge depuis la version 3.8 des pilotes, et capable de WiFi a/b/g/n.

Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL

30 March 202213 octobre 2014 by Matt Biscay · Lecture: 3 minutes

TLS est activé sur notre serveur Apache, WordPress sert désormais ses pages avec une connexion chiffrée et Webmin se sert de notre certificat SSL.

Aujourd’hui, je cherche à lancer le client bittorent Transmission et… je tombe sur un message d’erreur qui m’empêche d’accéder son interface web : “Error code: ssl_error_rx_record_too_long”.

Voici donc comment corriger le problème et afficher l’interface Web de Transmission en HTTPS. Ce tutoriel prend moins de 10 minutes à réaliser.

Erreur : “SSL received a record that exceeded the maximum permissible length”

Le premier message d’erreur sur lequel je tombe est le suivant :

Secure Connection Failed
An error occurred during a connection to www.example.com:9091. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

Je commence par vérifier le fichier de configuration de Transmission et m’aperçoit assez rapidement qu’il ne sera d’aucun secours.

Une recherche sur le net m’informe qu’il faut probablement voir du côté de la configuration Apache – qui ne contenait jusqu’alors aucune référence à Transmission.

Plusieurs essais de configuration plus tard, l’erreur se transforme en erreur 409.

Erreur “409: Conflict”

Le second message auquel je me heurte est le suivant :

409: Conflict
Your request had an invalid session-id header.
To fix this, follow these steps:
When reading a response, get its X-Transmission-Session-Id header and remember it
Add the updated header to your outgoing requests
When you get this 409 error message, resend your request with the updated header
This requirement has been added to help prevent CSRF attacks.

C’est la première fois que je tombe sur une erreur 409, je suis plutôt content. Je continue donc de tester diverses directives Apache jusqu’à trouver la bonne recette pour faire fonctionner le client web UI de Transmission over SSL.

Serveur dédié : configurer Webmin en TLS avec un certificat SSL

20 August 202110 octobre 2014 by Matt Biscay · Lecture: 2 minutes

Après avoir ajouté la couche TLS/SSL au serveur Apache puis configuré WordPress pour fonctionner uniquement en HTTPS, je me suis intéressé à Webmin.

Je n’utilise pas Webmin pour configurer le serveur parce que c’est une sacrée usine à gaz mais pour certaines choses, c’est utile.

Erreur Webmin : Secure Connection Failed

Après le passage aux connexions sécurisées, j’ai obtenu l’erreur suivante :

Secure Connection Failed
An error occurred during a connection to example.com:10000. The server presented a certificate with a key size that is too small to establish a secure connection. (Error code: mozilla_pkix_error_inadequate_key_size)

En substance, ce message d’erreur indique que la clé du certificat créé par Webmin lors de son installation est trop faible par rapport aux nouvelles exigences de notre certificat. Pas de problème, il suffit de créer un certificat spécialement pour Webmin.

Serveur dédié : passer WordPress en HTTPS (TLS/SSL)

14 February 202407 octobre 2014 by Matt Biscay · Lecture: 9 minutes

Vous avez sauté le pas et avez validé votre nom de domaine avec un certificat TLS/SSL. Très bien ! Voyons comment passer WordPress sur la version sécurisée de votre site.

Il existe des plugins WordPress entièrement dédiés à SSL pour rediriger vers les pages sécurisées mais on peut très bien faire sans, avec un peu d’huile de coude.

Le tutoriel est pour Debian et WordPress tourne sous Apache chez moi. Cela prend moins d’une heure pour configurer l’essentiel mais il est probable que vous ayez des petites corrections (thèmes, plugins) pour que tout soit servi en https.

Le but est de tout (oui, absolument tout!) servir via la connexion sécurisée.

Étape 1 : configurer Apache

On édite notre fichier de configuration :

nano /etc/apache2/sites-available/www.skyminds.net

et voici ce que garde pour VirtualHost *:80 :

ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/
Redirect 301 / https://www.skyminds.net/Code language: JavaScript (javascript)

La directive ServerName est nécessaire. Ensuite, une simple redirection renvoie toutes les requêtes du port 80 vers le port 443, sécurisé. Même pas besoin de mod_rewrite!

Android : résoudre l’erreur “aucun APN détecté sur cet appareil”

5 January 202204 octobre 2014 by Matt Biscay · Lecture: 2 minutes

Je suis chez Virgin Mobile depuis quelques années déjà et à chaque fois que je me rends dans un autre pays, c’est la même chose : mon smartphone “perd” toutes ses données APN.

La conséquence est simple : sans les noms de points d’accès, plus moyen de se connecter au réseau de données (3G) et impossible d’envoyer et recevoir des MMS.

Solution : ajouter les APN manuellement

Voici donc les APN de Virgin Mobile, mon FAI mobile.

1. Rendez-vous dans Paramètres > Réseau mobile > Noms des points d’accès.

2. créez un nouvel APN pour la data avec ces informations :

Nom : VM data
APN : virgin-mobile.fr
Proxy :
Port :
Username :
Password :
Serveur :
MMSC : 
Proxy MMS :
Port MMS : 
MCC : 208
MNC : 23
Type d'authentification :
Type d'APN : defaultCode language: PHP (php)

3. créez ensuite un second APN pour les MMS avec :

Nom : VM MMS
APN : virgin-mobile.fr
Proxy :
Port :
Username :
Password :
Serveur :
MMSC : http://mmc.omeatelecom.fr/servlets/mms
Proxy MMS :10.6.10.1
Port MMS : 8080
MCC : 208
MNC : 23
Type d'authentification :
Type d'APN : mmsCode language: PHP (php)

4. validez, et sélectionnez l’APN data avec le bouton radio par défaut.

Redémarrez votre téléphone, vous devriez maintenant être capable de vous connecter au réseau Virgin et d’envoyer et recevoir des MMS.

Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy

5 March 202429 septembre 2014 by Matt Biscay · Lecture: 10 minutes

Cela fait quelques mois que j’en parle mais aujourd’hui je le fais, je passe le site en HTTPS – ou techniquement en HTTP avec la couche TLS.

Après les révélations d’Edward Snowden et les multiples affaires concernant les écoutes et les fuites des données des citoyens, je pense qu’il est temps de reprendre un peu les choses en main et de nous intéresser au chiffrement de nos connexions.

La réalisation de ce tutoriel prend moins de 30 minutes, il y a peu de fichiers à éditer et de lignes à copier mais il faut être assez attentif aux diverses manipulations (notamment lors de la génération du certificat).

SSL ou TLS ?

Secure Sockets Layer (SSL) est un protocole cryptographique qui permet une communication sécurisée sur Internet. SSL a été développée par Netscape. SSL 2.0 date de 1995, SSL 3.0 de 1996. Les navigateurs actuels ne supportent plus SSL 2.0.

Transport Layer Security (TLS) est le successeur de SSL. TLS 1.0 date de 1999, TLS 1.1 de 2006 et TLS 1.2 de 2008.

Depuis septembre 2014, la dernière version de tous les navigateurs majeurs supporte SSL 3.0, TLS 1.0, 1.1, et 1.2 activés par défaut et les mitigations contre les attaques connues ont été implémentées.

Les navigateurs qui posent encore problème :

– support de TLS 1.1 and 1.2 mais désactivés par défaut : Internet Explorer (8–10 for Windows 7 / Server 2008 R2, 10 for Windows 8 / Server 2012, Mobile 10 for Windows Phone 8), Opera 12

– non-support de TLS 1.1 et 1.2: Internet Explorer (6-8 for Windows Server 2003, 7–9 for Windows Vista / Server 2008, Mobile 7 and 9 for Windows Phone 7.x), Safari 6 for Mac OS X 10.7 and 10.8

– mitigations contre les attaques connues non implémentées: Safari 6 for Mac OS X 10.7

HTTPS et TLS

Le protocole HTTPS (“Hypertext Transport Protocol Secure” ou protocole de transfert hypertexte sécurisé) protège l’intégrité et la confidentialité des informations des visiteurs d’un site.

Par exemple, lorsqu’un internaute saisit des informations dans un formulaire en ligne afin de recevoir des notifications ou d’acheter un produit, un site sécurisé protège les informations personnelles de cet internaute et garantit que ce dernier communique bien avec le propriétaire autorisé du site.

Avec le HTTPS, les informations sont sécurisées via le protocole Transport Layer Security (TLS), qui offre trois niveaux clés de protection.

1. le chiffrement : consiste à coder les données échangées pour les protéger des interceptions illicites. Cela signifie que lorsqu’un internaute navigue sur un site Web, personne ne peut “écouter” ses conversations, suivre ses activités sur diverses pages ni voler ses informations.

2. l’intégrité des données : les informations ne peuvent être ni modifiées, ni corrompues durant leur transfert, que ce soit délibérément ou autrement, sans être détectées.

3. l’authentication : prouve que les internautes communiquent avec le bon site Web. Cet élément protège contre les attaques de l’homme du milieu (“Man In The Middle” aka MITM) et instaure un climat de confiance pour l’internaute.

Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim

6 February 202423 septembre 2014 by Matt Biscay · Lecture: 8 minutes

Cela fait quelques années maintenant que mon serveur tourne et je trouvais le serveur de mail (postfix) bien fonctionnel plutôt bien jusqu’à ce que je reçoive des messages de la part de Gmail comme quoi les emails envoyés par le site sont considérés comme spam!

Et c’est à ce moment que l’on réalise qu’être bloqué par son fournisseur email, ce n’est pas cool du tout : à chaque fois qu’un nouveau commentaire est publié et que quelqu’un y est abonné, l’erreur se déclenche et le mail part en mail delivery service.

Voici le message type que l’on reçoit de Gmail dans ce cas:

Final-Recipient: rfc822; ***@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit
    https://support.google.com/mail/answer/81126 to review our Bulk Email Senders Guidelines. Code language: JavaScript (javascript)

Lorsque l’on monte un serveur email, rien n’est sécurisé par défaut. Avec tout le spam en circulation, il y a des entêtes à ajouter lors de l’envoi pour que le courrier ne soit pas considéré comme indésirable :

Il est donc temps de sécuriser un peu notre serveur de mail.

Étape 1 : diagnostics

Sur le serveur dans le terminal, on envoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Résultat:

==========================================================
Summary of Results
==========================================================
SPF check:          softfail
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    softfail
SpamAssassin check: ham

Du fail et du neutral, ce n’est pas trop bon! Nous allons commencer par activer SPF et Sender-ID.

Étape 2 : ajouter SPF et Sender-ID à BIND

Nous allons donc ajouter l’authentification SPF (Sender Policy Framework) à notre enregistrement DNS. On édite le fichier de configuration BIND de notre domaine :

nano /etc/bind/skyminds.net.hosts

Et on y ajoute à la fin du fichier :

;SPF
skyminds.net. IN TXT "v=spf1 ip4:IP4SERVEUR mx -all"
skyminds.net. IN SPF "v=spf1 ip4:IP4SERVEUR mx -all"
mail.skyminds.net. IN  TXT  "v=spf1 ip4:IP4SERVEUR a -all"
mail.skyminds.net. IN  SPF  "v=spf1 ip4:IP4SERVEUR a -all"Code language: JavaScript (javascript)

Remplacez IP4SERVEUR par l’IPv4 de votre serveur et skyminds.net par votre nom de domaine. Enregistrez le fichier et relancez BIND :

/etc/init.d/bind9 restart

On renvoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Nouveau résultat :

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

Pas mal, on vient d’activer le SPF et le Sender-ID en 2 minutes !

Étape 3 : installation de l’authentification DKIM

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique : DKIM fonctionne par signature cryptographique du corps du message et d’une partie de ses en-têtes.

Une signature DKIM vérifie donc l’authenticité du domaine expéditeur et garantit l’intégrité du message. Idéal pour lutter contre le spam.

1. On installe opendkim :

apt-get install opendkim opendkim-toolsCode language: JavaScript (javascript)

Et on édite le fichier de configuration:

nano /etc/opendkim.conf

On supprime tout le contenu de ce fichier et on met :

 # Enable Logging
Syslog yes
SyslogSuccess yes
LogWhy yes

# User mask
UMask 002

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From

# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

# Trusted Hosts
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

# Hashing Algorithm
SignatureAlgorithm rsa-sha256

# Auto restart when the failure occurs. CAUTION: This may cause a tight fork loops
AutoRestart Yes
DNSTimeout  5

# Set the user and group to opendkim user
UserID opendkim:opendkim

# Specify the working socket
Socket inet:12345@localhost

Canonicalization relaxed/relaxedCode language: PHP (php)

2. On édite la configuration par défaut d’opendkim:

nano /etc/default/opendkimCode language: JavaScript (javascript)

Avec :

# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
#
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
#SOCKET="local:/var/run/opendkim/opendkim.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:12345@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345Code language: PHP (php)

3. On crée un nouveau répertoire pour notre clé et on assigne les droits à l’utilisateur opendkim, du groupe opendkim:

mkdir -pv /etc/opendkim/skyminds.net/
chown -Rv opendkim:opendkim /etc/opendkim
chmod go-rwx /etc/opendkim/*

Ensuite, on crée une paire de clés pour chaque domaine :

cd /etc/opendkim/skyminds.net/
opendkim-genkey -r -h rsa-sha256 -d skyminds.net -s mail -b 4096
mv -v mail.private mail
chown opendkim:opendkim *
chmod u=rw,go-rwx * Code language: PHP (php)

Cela nous crée 2 fichiers : un fichier mail (clé privée) et un fichier mail.txt qui contiendra notre clé publique.

4. On ajoute notre clé publique à l’enregistrement DNS du domaine dans BIND:

nano /etc/bind/skyminds.net.hosts

On y copie notre clé publique (/etc/opendkim/skyminds.net/mail.txt) à la fin du fichier :

;DKIM
_domainkey.skyminds.net. IN TXT "t=y; o=-;"
mail._domainkey.skyminds.net. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6YG5lJXmZxgz1eFprQfEV8oqUjYceMNPctuhi/Fo+oE+4oeDwMTDyPJcGCuJMp2XZxL2X3a8/Q9g3StekiHWqPehY7cyrnYZg6ttTCdbJYGAc/t0rVCKut/2baiGw9lcMq5sbUG9YywEEI/rN4Fu0PCU1A6BkqtNAepPhDwVRAQIDAQAB; t=s"; ----- DKIM key mail for skyminds.net
_adsp._domainkey.skyminds.net. IN TXT "dkim=unknown"Code language: JavaScript (javascript)

On enregistre le fichier et on relance BIND :

/etc/init.d/bind9 restart

5. On associe les domaines avec les clés :

nano  /etc/opendkim/KeyTable

La syntaxe du fichier est la suivante :
KeyID Domain:Selector:PathToPrivateKey

Nous ajoutons donc :

skyminds.net skyminds.net:mail:/etc/opendkim/skyminds.net/mailCode language: JavaScript (javascript)

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.netCode language: CSS (css)

7. On définit les domaines considérés comme trusted :

nano /etc/opendkim/TrustedHosts

Avec :

127.0.0.1
localhost
ns.kimsufi.com
skyminds.netCode language: CSS (css)

Il ne faut pas oublier d’ajouter le DNS de votre hébergeur (ns.kimsufi.com chez moi).

8. On applique maintenant les bons droits à nos fichiers :

chown opendkim:opendkim /etc/opendkim/KeyTable
chown opendkim:opendkim /etc/opendkim/SigningTable
chown opendkim:opendkim /etc/opendkim/TrustedHosts

9. On édite maintenant la configuration Postfix :

nano /etc/postfix/main.cf

Et on rajoute :

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = $smtpd_miltersCode language: PHP (php)

On redémarre bind, opendkim et postfix pour vérifier que tout va bien :

/etc/init.d/bind9 restart
/etc/init.d/opendkim restart
/etc/init.d/postfix restart

10. On vérifie qu’opendkim est bien lancé sur le serveur :

ps aux | grep dkim
netstat -tanp | grep dkim

Étape 4 : tests et vérifications

Il faut maintenant attendre que la propagation DNS prenne effet, cela peut prendre quelques heures.

Vous pouvez lancer un test DKIM ici : http://www.brandonchecketts.com/emailtest.php

Vérifiez les erreurs mail dans les logs :

tail -f /var/log/mail.logCode language: JavaScript (javascript)

Envoyez-vous un email via le terminal. Voici ce que vous devriez obtenir :

Étape 5 : optimiser la vitesse d’envoi

Quelques jours après la réalisation et la mise en place du tutoriel, je me suis aperçu que Gmail grognait toujours à cause de la vitesse à laquelle étaient envoyés les emails, notamment lorsque beaucoup de gens sont abonnés aux commentaires : en cas de nouveau commentaire, une flopée de notifications partent au même moment – ce qui déclenche le message d’erreur chez Gmail.

Pour améliorer cela, on édite à nouveau le fichier de configuration postfix :

nano /etc/postfix/main.cf

Et on y rajoute :

# Matt : NOT TOO FAST COWBOY!
# This means that postfix will up to two concurrent
# connections per receiving domains. The default value is 20.
default_destination_concurrency_limit = 2
# Postfix will add a delay between each message to the same receiving domain.
default_destination_rate_delay = 5s
# Limit the number of recipients of each message.
# If a message had 20 recipients on the same domain, postfix will break it out
default_extra_recipient_limit = 3Code language: PHP (php)

Cela se connecte au maximum avec 2 connexions par domaine, avec un délai de 5 secondes entre chaque message s’ils sont envoyés au même domaine et on envoie par tranche de 3 messages. Un peu alambiqué mais cela semble satisfaire Google.

Voilà, c’est fini. Les messages de votre serveur de mail devraient maintenant être un peu plus acceptés dans les boîtes de réception !

Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403

30 March 202215 septembre 2014 by Matt Biscay · Lecture: 1 minute

Le problème : l’adresse du site sans WWW renvoie une erreur

Après avoir ajouté un sous-domaine pour mes images, j’ai remarqué qu’en lançant skyminds.net sans le www, je tombais sur une erreur 403 alors que le domaine avait toujours été redirigé vers l’adresse en www jusqu’à présent.

En analysant les logs Apache, je me suis rendu compte que le domaine seul tentait d’afficher le contenu de mon sous-domaine. Or ce contenu est caché étant donné qu’il ne contient que des images.

La solution : indiquer le nom de domaine seul dans ServerAlias

La solution est d’ajouter le nom de domaine seul dans la directive ServerAlias du VirtualHost principal :

ServerName www.skyminds.net
ServerAlias skyminds.netCode language: CSS (css)

Et voilà, tout revient à la normale.

Linux : résoudre l’erreur cron “line too long in state file /var/lib/logrotate/status”

8 April 202212 septembre 2014 by Matt Biscay · Lecture: 2 minutes

Ce matin, j’ai reçu ce message d’erreur de mon serveur par email :

/etc/cron.daily/logrotate:
error: line 672139 too long in state file /var/lib/logrotate/status
error: could not read state file, will not attempt to write into it
run-parts: /etc/cron.daily/logrotate exited with return code 1Code language: JavaScript (javascript)

Sous les systèmes GNU/linux, logrotate est le service qui archive les fichiers log de manière à ne pas travailler sur des fichiers trop lourds.

Les fichiers sont donc archivés plus ou moins régulièrement, selon leur taille et leur utilisation : certains sont archivés tous les jours, d’autres toutes les semaines.

Or, si logrotate ne fonctionne pas correctement, la taille des fichiers explose, ce qui posera tôt ou tard un souci sur le serveur.

Lorsque logrotate n’arrive pas à lire ou à écrire dans le fichier /var/lib/logrotate/status, il faut :

1. supprimer le fichier /var/lib/logrotate/status :

rm -rf /var/lib/logrotate/statusCode language: JavaScript (javascript)

2. et relancer logrotate :

logrotate -f /etc/logrotate.conf

Le fichier /var/lib/logrotate/status ne sert finalement qu’à garder une trace de la dernière rotation des fichiers logs. Ce fichier ne devrait pas contenir énormément de lignes.

Ps : si vous utilisez Varnish, commentez les lignes le concernant dans /etc/logrotate.conf, il est peu utile d’encombrer le serveur avec les logs de ressources statiques.

Linux : résoudre l’erreur de montage/démontage de disque dur “Error unmounting: umount exited with exit code 1: helper failed with: umount: only root can unmount”

30 March 202230 août 2014 by Matt Biscay · Lecture: 2 minutes

Sur mon ordinateur, surnommé The Reaper, j’ai plusieurs disques dur : mon disque principal est un disque formaté en EXT4, entièrement dédié à Linux.

Les deux autres disques durs sont formatés en NTFS car ils datent du temps où j’avais Windows dessus.

Le problème : un disque en lecture seule

L’autre jour, Cécile cherche à sauvegarder ses fichiers sur son disque externe, qui ne semble pas être détecté.

Je lui propose alors le mien et le branche sur ma machine pour voir s’il reste de la place dessus.

Je le monte et là je m’aperçois qu’il est en mode lecture seule (aka read-only ou r-o) : impossible de copier le moindre fichier dessus alors qu’avant c’était bien possible.

Après de multiples recherches, essais, installations de paquets divers et variés, la situation a un peu changé : mes 2 disques internes se montent maintenant automatiquement au démarrage du système (ce que je ne veux absolument pas).

Lorsque je veux les démonter, j’obtiens le fameux message d’erreur “Error unmounting: umount exited with exit code 1: helper failed with: umount: only root can unmount” qui me dit en substance que seul l’utilisateur root peut monter ou démonter le disque.

Bref, je tombe de Charybde en Scylla. Voici comment régler la situation une bonne fois pour toute, disques internes et externes à la fois.

1. On liste les disques du système avec :

df

2. On démonte les disques en question (sda chez moi) :

sudo umount /dev/sda1

3. On installe le paquet ntfs-config :

sudo apt-get install ntfs-configCode language: JavaScript (javascript)

4. On lance ntfs-config depuis Applications > Outils Système > Outil de configuration NTFS ou depuis le terminal avec :

gksudo ntfs-config

5. On active l’écriture des disques internes et externes :

6. On édite le fichier de configuration /etc/fstab :

sudo nano /etc/fstab

et on retire les lignes qui correspondent aux disques durs dont on ne veut pas le montage automatique. Vous pouvez commenter les lignes pour plus de sécurité.

7. Voilà, vous devriez être en mesure d’accéder à vos disques durs normalement.

Conclusion

J’ai beaucoup joué avec les options avancées de ntfs-config mais je ne suis pas sûr d’en maîtriser toutes les subtilités.

J’ai retrouvé un accès complet à mes disques en montage/démontage/lecture/écriture en éditant le fichier /etc/fstab et en supprimant les lignes relatives aux disques incriminés. Et depuis tout va bien.

← Précédent Suivant →