Parfois on a le besoin de rester sous d’ancienne version de php, sans pour autant ne pas profiter d’une version plus récente de debian donc :

1- Ajout des clé suivantes :
apt-key add dotdeb.gpg

2- Ajout dans sources.list :
deb wheezy all
deb wheezy main

3- Création du fichier php54.pref dans /etc/apt/preferences.d :
Package: *
Pin: release,n=jessie
Pin-Priority: 600

Package: php5
Pin: release,n=wheezy
Pin-Priority: 650

4- et enfin :
aptitude update && aptitude upgrade && aptitude install php5

Use certtool instead of openssl. It is less flexible but much more user friendly.1. Installation:Certtool is part of GnuTLS. On debian-based distributions you have to install the gnutls-bin package.2. Create a private key:# certtool -p –outfile server.key.pem3. Generate the self signed certificate:# certtool -s –load-privkey server.key.pem –outfile server.crt.pemYou will get a prompt to enter various informations required for a certificate. For a server certificate you only need to fill common name with the server name e.g. and validity period.For some applications, like openvpn, you may need your own certificate authority CA. These are the steps required:- create a CA key- create a self signed certificate for the CA. Say yes to the questions: “Does the certificate belong to an authority?” and “Will the certificate be used to sign other certificates?”- create a key- create a certificate using the CA key, CA certificate and the above key. For openvpn the common name is the user name.# certtool -p –outfile ca.key.pem# certtool -s –load-privkey ca.key.pem –outfile ca.crt.pem# certtool -p –outfile user.key.pem# certtool -c –load-privkey user.key.pem –load-ca-privkey ca.key.pem –load-ca-certificate ca.crt.pem –outfile user.crt.pem

viaSelf signed certificate, fast and easy | my repository.

HowTo/PostfixAndDovecotSASL – Dovecot Wiki.

Postfix and Dovecot SASL

Since version 2.3, Postfix supports SMTP AUTH through Dovecot SASL as introduced in the Dovecot 1.0 series. If using Postfix obtained from a binary (such as a .rpm or .deb file), you can check if Postfix was compiled with support for Dovecot SASL by running the command:

postconf -a

Once you have verified that your installation of Postfix supports Dovecot SASL, it’s very simple to configure:

Example conf.d/10-master.conf excerpt

service auth {

unix_listener /var/spool/postfix/private/auth {
mode = 0660
# Assuming the default Postfix user and group
user = postfix
group = postfix


Example Postfix excerpt

smtpd_sasl_type = dovecot

# Can be an absolute path, or relative to $queue_directory
# Debian/Ubuntu users: Postfix is setup by default to run chrooted, so it is best to leave it as-is below
smtpd_sasl_path = private/auth

# and the common settings to enable SASL:
smtpd_sasl_auth_enable = yes
# With Postfix version before 2.10, use smtpd_recipient_restrictions
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Using SASL with Postfix submission port

When Dovecot is used as the authentication backend for Postfix it is good practice to use a dedicated submission port for the MUAs (TCP 587). Not only can you specify individual parameters in overriding the global ones but you will not run into internet mail rejection while the Dovecot Auth Mechanism is unavailable. In this example Postfix is configured to accept TLS encrypted sessions only, along with several other sanity checks:

Verification of alias ownership via Login Maps
Domainname and recipient plausibility

submission inet n – – – – smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_sasl_local_domain=$myhostname
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_login_maps=hash:/etc/postfix/virtual
-o smtpd_sender_restrictions=reject_sender_login_mismatch
-o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject


file=$1 # the input file
directory= »$file-splitted » # the output directory
output= »$directory/header » # the first file containing the header
GREP= »DROP TABLE » # what we are looking for

mkdir $directory # create the output directory

while read line
# if the current line contains the wanted statement
if [ $(echo « $line » | grep -c « $GREP ») == « 1 » ]
# extract the file name
myfile=$(echo $line | awk ‘{print $5}’ | sed -e ‘s/`//g’ -e ‘s/;//g’)
# set the new file name
output= »$directory/$myfile »
echo « $line » >> $output # write to file
done < $file

How to Change the Port Number in PostfixThe default network SMTP port for Postfix, Sendmail and most other mail servers is 25. This is the port used to send email, and most email clients will use it by default. Unfortunately, some Internet service providers have started to block port 25 because of the high volume of spam sent through it. For SMTP, they require their users to use the ISP’s SMTP.This is a the primary reason why server administrators might change their SMTP port, but there are others. Some server administrators use proxy servers to redirect mail traffic through SPAM and DNS filters before eventually resolving to another port. Others change it, for security purposes, to a port that is more difficult for spammers and hackers to guess.To change your Postfix port, you will need to have root access to your server. Edit the Postfix configuration file: /etc/postfix/ and comment out the following line:# smtp innet n – n – – smtpdCode can be commented out by placing the “#” sign in front of a lineNext, add this line:7538 inet n – n – – smtpdReplace “7538″ with whatever port you prefer to use for your SMTP server.Finally, restart Postfix:/etc/init.d/postfix restart OR service postfix restartIf you are using a software firewall, you will need to configure it to allow the new port and deny port 25. After that, you are all finished. Do not forget to inform any users will mail accounts that they will need to send mail through the new port.

viaHow to Change the Port Number in Postfix.

coté collectd

Host « localhost »
User « collectd »
Password « Secrets of the Universe with Philo »
Database « mysql »
# MasterStats true

coté Ligne de commande
mysql -u root
mysql> CREATE USER ‘collectd’@’localhost’ IDENTIFIED BY ‘password’;
mysql> GRANT SELECT, PROCESS, SHOW DATABASES, SUPER ON *.* TO ‘collectd’@’localhost’;

Sous debian 64 bits

mkdir /home/tmpioncube
cd /home/tmpioncube

wget && tar -zxf ioncube_loaders_lin_x86-64.tar.gz && cd ioncube && cp /usr/lib64/php5/

echo « zend_extension=/usr/lib64/php5/ » > /etc/php5/conf.d/ioncube-loader.ini

et sa roule

The problemBy default apache2 is configured to support 150 concurrent connections. This forces all parallel requests beyond that limit to wait. Especially if, for example, active sync clients maintain a permanent connection for push events to arrive.The solutionThis is an example configuration to provide 800 concurrent connections. Please ensure that your apache is using the mpm_worker module. This allows us to serve lots of concurrent connections by using less RAM than with mpm_prefork as we are going to start much less processes.<IfModule mpm_worker_module> ServerLimit 25 StartServers 10 MinSpareThreads 75 MaxSpareThreads 250 ThreadLimit 64 ThreadsPerChild 32 MaxClients 800 MaxRequestsPerChild 10000</IfModule>Short explanation of the parameters:ServerLimit Declares the maximum number of running apache processes. If you change this value you have to restart the daemon.StartServers The number of processes to start initially when starting the apache daemon.MinSpareThreads/MaxSpareThreads This regulates how many threads may stay idle without being killed. Apache regulates this on its own very well with default values.ThreadsPerChild How many threads can be created per process. Can be changed during a reload.ThreadLimit ThreadsPerChild can be configured as high as this value during runtime. If you change this value you have to restart the daemon.MaxClients This declares how many concurrent connections we provide. Devided by ThreadsPerChild you get the suitable ServerLimit value. May be less than ServerLimit ThreadsPerChild to reserve some resources that can be engaged during runtime with increasing MaxClients and reloading the configuration.MaxRequestsPerChild Defines the number of Connections that a process can handle during its lifetime keep-alives are counted once. After that it will be killed. This can be used to prevent possible apache memory leaks. If set to 0 the lifetime is infinite.For further information on these parameters see and

viaTune apache2 for more concurrent connections – Open-Xchange.

par julien, juillet 2007

Avez-vous déjà essayer de brancher un serveur mail sur le Net sans configurer d’antispam au préalable ? Je l’ai fait quelques fois, et bas c’est pas triste !!! On arrive vite au point ou checker sa mailbox est un supplice sans nom. La solution c’est de demander à Postfix de soumettre les mails entrants à l’excellent Spamassassin avant de les faire suivre au serveur Imap (enfin, je dit imap, mais ya ptete des sadiques qui utilisent encore pop…).
Spamassassin vite fait bien fait

Les packages qui vont bien sous Debian (Etch ici) sont :

apt-get install spamassassin spamc razor pyzor

Attention, ya du monde qui va s’installer 🙂 Et une fois que c’est fait, il suffit d’aller dans ‘/etc/default/spamassassin’ et de passer la valeur de ENABLED à 1. Une petite relance du serveur, et hop, c’est dans la poche. Spamd est maintenant dans les processus :

root 17989 1 3 19:38 ? 00:00:00 /usr/sbin/spamd –create-prefs –max-children 5 –helper-home-dir -d –pidfile=/var/run/spamd
root 17990 17989 0 19:38 ? 00:00:00 spamd child
root 17991 17989 0 19:38 ? 00:00:00 spamd child

Bon, c’est quand même mieux de le configurer un peu plus précisément, en particulier pour activer l’utilisation des modules Pyzor et Razor (des outils collaboratifs de détections des spams). Pour cela, il faut aller dans ‘/etc/spamassassin/’ et modifier un peu le fichier. Ci-dessous, le fichier que j’utilise :

# This is the right place to customize your installation of SpamAssassin.
# See ‘perldoc Mail::SpamAssassin::Conf’ for details of what can be
# tweaked.
# Only a small subset of options are listed below

# Add *****SPAM***** to the Subject header of spam e-mails
rewrite_header Subject *****SPAM*****

# Save spam messages as a message/rfc822 MIME attachment instead of
# modifying the original message (0: off, 2: use text/plain instead)
report_safe 1

# Set which networks or hosts are considered ‘trusted’ by your mail
# server (i.e. not spammers)
# trusted_networks 212.17.35.

# Set file-locking method (flock is not safe over NFS, but is faster)
lock_method flock

# Set the threshold at which a message is considered spam (default: 5.0)
required_score 5.0

# Use Bayesian classifier (default: 1)
use_bayes 1

# Bayesian classifier auto-learning (default: 1)
bayes_auto_learn 1

# Set headers which may provide inappropriate cues to the Bayesian
# classifier
# bayes_ignore_header X-Bogosity
# bayes_ignore_header X-Spam-Flag
# bayes_ignore_header X-Spam-Status

# Enable or disable network checks
skip_rbl_checks 0
use_razor2 1
use_pyzor 1

Désactiver les préférences par utilisateur

Dans /etc/default/spamassassin, il faut changer la ligne d’options pour désactiver les préférences par utilisateur (qui serait normalement stockées dans leur home directory) et utiliser les préférences globales à la place.

On remplace l’option –create-prefs par -x:

# vim /etc/default/spamassassin


17 #OPTIONS= »–create-prefs –max-children 1 –helper-home-dir »
18 OPTIONS= »-x –max-children 3 –helper-home-dir »

Changer l’utilisateur de spamassassin

Par défaut spamassassin est lancé par Root. On va créer un user spamassassin et lancer le daemon sous ce user.

# useradd spamassassin -d /var/spool/spamassassin -m -s /bin/false

Cela crée un user qui ne peux pas se loguer et à un répertoire home dans /var/spool. Maintenant on change l’option de lancement de spamassassin dans /etc/default/spamassassin/

# vim /etc/default/spamassassin


18 OPTIONS= »-x –max-children 3 –helper-home-dir -u spamassassin »

Et on relance le daemon. Il est maintenant lancé sous l’utilisateur spamassassin.

# /etc/init.d/spamassassin restart
Restarting SpamAssassin Mail Filter Daemon: spamd.

# ps -edf|grep spam

root 31991 1 33 12:40 ? 00:00:01 /usr/sbin/spamd -x –max-children 3 –helper-home-dir -u spamassassin -d –pidfile=/var/run/

1015 31993 31991 0 12:40 ? 00:00:00 spamd child
1015 31994 31991 0 12:40 ? 00:00:00 spamd child

root@zerhuel:/var/spool# grep spamassassin /etc/passwd

Activer la validation DKIM

Il est possible d’activer la validation DKIM. Pour cela, le package libmail-dkim-perl doit être installé. Ensuite, il suffit d’activer le module DKIM dans la configuration de spamassassin.

# vim /etc/spamassassin/v312.pre


18 ###########################################################################
19 # experimental plugins
21 # DKIM – perform DKIM verification
22 #
23 # Mail::DKIM module required for use, see INSTALL for more information.
24 #
25 # Note that if C version 0.20 or later is installed, this
26 # renders the DomainKeys plugin redundant.
27 #
28 loadplugin Mail::SpamAssassin::Plugin::DKIM

Relancez spamassassin. Lorsqu’un mail arrivera avec une signature DKIM, Spamassassin placera la valeur suivante dans le résultat de l’inspection

X-Spam-Status: No, score=2.9 required=8.0 tests=DKIM_SIGNED,DKIM_VERIFIED,
HTML_MESSAGE,TVD_SPACE_RATIO autolearn=no version=3.2.5

(test effectué avec un email provenant de gmail)
Postfix tout aussi rapidement

Seul le fichier est à modifier. Il faut demander (poliment hein) au daemon smtpd d’appeler spamassassin, que l’on va définir juste après. Donc, dans ‘/etc/postfix/’ à la fin de la ligne smtp, on ajoute ‘-o spamassassin’ :

# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: « man 5 master »).
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n – – – – smtpd -o content_filter=spamassassin

De fait, à la fin du fichier il faut créer un service spamassassin :

spamassassin unix – n n – – pipe user=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Bon, normalement les chemins des exécutables sont bons pour Debian Etch mais faites quand même une vérif avant 😉

Et hop, on reload postfix et ça roule.
Ils disent quoi les logs ?

Le fichier /var/log/ contient maintenant les notifications de spamassassin. Un peu partout vous verrez des lignes du type :

Jul 4 19:59:09 mailbox spamd[17990]: spamd: result: . 4 – EXTRA_MPART_TYPE,HTML_10_20,HTML_IMAGE_ONLY_24,HTML_MESSAGE,HTML_SHORT_LINK_IMG_3,MSGID_FROM_MTA_ID scantime=0.1,size=11864,user=nobody,uid=65534,required_score=5.0,rhost=localhost,raddr=,rport=37360,mid=<>,autolearn=no

Et les entetes des mails contiennent maintenant :

X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed

Variable selon que le mail est detecté comme spam ou non.

That’s all folks !

La sécurité du contenu est primordiale dans la publication d’un site web. Il n’en est pas moins pour PrestaShop. La politique sécuritaire est alors de n’afficher par défaut aucun message d’erreur, ou de retour d’un quelconque débogage de code, ou même de configuration de serveurs / services liés à l’hébergement web. Afficher des erreurs éventuelles, ou plutôt laisser la possibilité de les afficher expose votre site web à la divulgation d’informations qui pourraient servir mal-intentionnellement à votre égard.
En mode production, contrairement au mode développement, et / ou en pré-production, il est impératif de laisser cet option par défaut, afin de ne rien afficher, même si votre page est en erreur. De cette manière, toute tentative mal-seine de provocation volontaire d’erreur ne mènera son auteur qu’à un résultat nul qui pourrait l’informer d’une faille éventuelle dans votre boutique PrestaShop.
2 options sont donc envisageables pour PrestaShop

Si vous êtes un développeur / intégrateur, si vous avez besoin d’une assistance ponctuelle pour résoudre un problème de comportement anormal sur votre boutique ou si vous avez une page blanche et que vous ne comprenez pas pourquoi, etc., alors éditez votre fichier ./config/, et modifier les variables telles qu’elles sont présentées ci-dessous :

/* Debug only */
@ini_set(‘display_errors’, ‘on’);
define(‘_PS_DEBUG_SQL_’, true);

$start_time = microtime(true);

/* Compatibility warning */

Si vous ne constatez rien d’anormal, si votre boutique est en production, ou si vous n’êtes pas en phase de développement ou de débug, alors éditez votre fichier ./config/, et modifier les variables telles qu’elles sont présentées ci-dessous :

/* Debug only */
@ini_set(‘display_errors’, ‘off’);
define(‘_PS_DEBUG_SQL_’, false);

$start_time = microtime(true);

/* Compatibility warning */
Le debug de smarty peut vous aider

Il existe aussi la possibilité d’activer la résultante complète du template Smarty en cours d’exécution. Ce mode débug n’est pas un résultat d’erreurs, mais un contenu permettant de visualiser si les démarches du développeur sont bien prises en compte pour l’intégration des traitements et des valeurs dans le template de la boutique PrestaShop. Vous pouvez alors l’activer ponctuellement en éditant votre fichier ./config/, et en autorisant la valeur ci-dessous :

$smarty->debugging = true;

Pensez à remettre cette valeur à false par défaut, une fois vos démarches terminées.
Vous souhaitez sécuriser un peu plus votre hébergement web

Ce qui suit ne s’arrête pas simplement à l’usage de PrestaShop dans votre hébergement web, mais ceci est une partie des optimisations web qui font la différence au quotidien et sur Internet en terme de sécurité et de garantie d’avoir un site web qui dure dans le temps.

Si votre hébergement web fait partie d’un service web que vous gérez, et si les publications web mises à disposition sont vouées à l’utilisateur final et non à un mode de développement ou de pré-production, alors je vous conseille vivement de modifier un élément important dans votre fichier php.ini, et de le désactiver comme ceci :

display_errors = Off

Cette option est associée à la variable error_reporting de ce même php.ini. Elle permet de donner le niveau d’alertes à afficher si des erreurs et/ou warnings failliraient le traitement. En mode de développement pure, il convient de passer cette valeur comme ceci :

error_reporting = E_ALL | E_STRICT

Ce niveau permet au développeur d’afficher l’ensemble des erreurs et warnings, même de bas niveaux, ce qui assure pendant toute la phase de développement la création d’un code propre et fonctionnel. Mais le rapport d’erreur ne s’affichera que si sa dépendance display_errors est activée. C’est pour cela qu’il convient de passer l’option display_errors à false par défaut sur votre serveur web en production, ce qui n’est pas le cas par défaut habituellement.

Dans le cas où vous n’avez pas l’accès à ce fichier de configuration php.ini, vous pouvez essayer de contrôler cette option par le biais du .htaccess (de préférence celui à la racine du votre dossier web), ou par code php (de préférence avant tous les traitements).
Désactiver l’affichage des erreurs depuis le fichier .htaccess

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante fera l’affaire en haut de votre fichier .htaccess :

php_flag display_errors off
Désactiver l’affichage des erreurs depuis le code

Si vous en avez les autorisations dans les options de votre hébergement, la ligne suivante en début des traitements php pourra annuler l’affichage des messages d’erreurs php :


De même pour les templates Smarty, propre à PrestaShop, et à spécifier après le chargement du framework Smarty Template :

$smarty->error_reporting = 0;

Pour php, vous avez aussi la possibilité de contrôler les niveaux d’alertes :

// Rapporte les erreurs d’exécution de script
error_reporting(E_ERROR | E_WARNING | E_PARSE);

// Rapporter les E_NOTICE peut vous aider à améliorer vos scripts
// (variables non initialisées, variables mal orthographiées..)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

// Rapporte toutes les erreurs à part les E_NOTICE
// C’est la configuration par défaut de php.ini
error_reporting(E_ALL ^ E_NOTICE);

// Reporte toutes les erreurs PHP (Voir l’historique des modifications)

// Reporte toutes les erreurs PHP

// Même chose que error_reporting(E_ALL);
ini_set(‘error_reporting’, E_ALL);
Parano, non, mais prévoyant

Je pense que cet article peut inviter les développeurs web, les agences web, ou même monsieur tout le monde qui s’initie au développement, a considérer que les publications dynamiques sur le web sont des proies permanentes sur Internet. Si vous autorisez l’affichage d’erreurs, et que vous-même pensez que 99% de votre site est bien conçu, les 1% restant générant des erreurs sur des pages introuvables, de code, ou pire, des erreurs SQL, peuvent être indexés par les moteurs de recherches. Si vous utilisez un framework connu, un CMS en vogue, votre site web peut sortir dans les résultats de recherches liés à des erreurs engendrant des tentatives d’intrusions, ou des injections SQL ou de codes.

En conclusion, soyez prévoyant sur cet aspect parfois délesté.