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/master.cf 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.
Archives de la catégorie: Hebergement
Collectd, monitorer mysql
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’;
mysql> FLUSH PRIVILEGES;
iocube loader, php 5.3 sous debian
Sous debian 64 bits
mkdir /home/tmpioncube
cd /home/tmpioncube
wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz && tar -zxf ioncube_loaders_lin_x86-64.tar.gz && cd ioncube && cp ioncube_loader_lin_5.3.so /usr/lib64/php5/
echo « zend_extension=/usr/lib64/php5/ioncube_loader_lin_5.3.so » > /etc/php5/conf.d/ioncube-loader.ini
et sa roule
Tune apache2 for more concurrent connections – Open-Xchange
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 http://httpd.apache.org/docs/2.2/mod/worker.html and http://httpd.apache.org/docs/2.2/mod/mpm_common.html.
viaTune apache2 for more concurrent connections – Open-Xchange.
Postfix et Spamassassin
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/local.cf’ 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/spamd.pid
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
spamassassin:x:1015:1015::/var/spool/spamassassin:/bin/false
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
20
21 # DKIM – perform DKIM verification
22 #
23 # Mail::DKIM module required for use, see INSTALL for more information.
24 #
25 # Note that if C
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 Master.cf 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/master.cf’ à 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 Master.cf 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/mail.info 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=127.0.0.1,rport=37360,mid=<20070704175908.CA0D8564271@smtp.linuxwall.info>,autolearn=no
Et les entetes des mails contiennent maintenant :
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sachiel.linuxwall.info
X-Spam-Level:
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 !
Messages d’erreurs sur PrestaShop et sécurité
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/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :
1
2
3
4
5
6
7
8
/* Debug only */
@ini_set(‘display_errors’, ‘on’);
define(‘_PS_DEBUG_SQL_’, true);
$start_time = microtime(true);
/* Compatibility warning */
define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, true);
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/config.inc.php, et modifier les variables telles qu’elles sont présentées ci-dessous :
1
2
3
4
5
6
7
8
/* Debug only */
@ini_set(‘display_errors’, ‘off’);
define(‘_PS_DEBUG_SQL_’, false);
$start_time = microtime(true);
/* Compatibility warning */
define(‘_PS_DISPLAY_COMPATIBILITY_WARNING_’, false);
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/smarty.config.inc.php, et en autorisant la valeur ci-dessous :
1
$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 :
1
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 :
1
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 :
1
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 :
1
error_reporting(0);
De même pour les templates Smarty, propre à PrestaShop, et à spécifier après le chargement du framework Smarty Template :
1
$smarty->error_reporting = 0;
Pour php, vous avez aussi la possibilité de contrôler les niveaux d’alertes :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 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)
error_reporting(E_ALL);
// Reporte toutes les erreurs PHP
error_reporting(-1);
// 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é.
MySQL Error 23 on Linux | Chris Johnson’s Blog
If you have ever encountered a “23 error” you are most likely running MySQL on a windows machine.
The error looks something like this:
ERROR 23 (HY000): Out of resources when opening file ‘./somedb/sometable.MYD’ (Errcode: 24)
What this error typically means is that MySQL has exceeded the limit for the number of files you can open at once. This is easy to fix in Linux by upping that number.
edit /etc/security/limits.conf
and add:
mysql soft nofile 4096
mysql hard nofile 4096
This effectively doubles the number of files MySQL can open (default is half this).
On windows you can’t really fix this. It is an OS limitation. See: http://dev.mysql.com/doc/refman/5.0/en/limits-windows.html
Alternatively, the error may come up if you are using partitioned tables, as was the case for me. It is a confusing error in this situation. I learned more about the MyISAM engine when this happened. It turns out that each table (or (sub)partition) requires up to 3 files to be opened when accessed. So for a table with a large number of partitions, like my weather data table a large number of files are opened. This is because MyISAM stores the table format, table data and table indexes in separate files.
In my situation doubling the number of files MySQL could open didn’t have any effect… so I searched on.
What I found was that MySQL keeps some files open for previously cached queries. So, once I executed a FLUSH TABLES; I no longer had any problems.
What FLUSH TABLES; does is clear the internal cache. After this I had no problem working with my 204 subpartitioned table anymore.
Hope this is helpful for someone else!
-Chris
PHP 5.3 : Configuration par répertoire basée sur des fichiers .ini – Pascal MARTIN (n+1).zéro
php.ini : Sections PATH et HOST
La seconde nouveauté au niveau de la configuration de PHP, toujours en mode CGI, est l’ajout du support des sections PATH et HOST, utilisables dans le fichier php.ini.
Section PATH
Il est possible, à partir de PHP 5.3, de définir dans le fichier php.ini système des valeurs de directives de configuration qui ne seront appliquées que pour certains répertoires, un peu à la manière de ce que nous faisons plus haut avec les fichiers .user.ini…
… La différence étant que, cette fois :
La configuration est centralisée au niveau d’un seul fichier,
Et puisque nous travaillons dans le fichier php.ini système, accessible seulement par l’administrateur du serveur, nous pouvons modifier des options de configuration qu’il ne nous était pas possible de modifier dans les fichiers .user.ini, pour raisons de sécurité.
Une section PATH se défini en prenant en paramètre le chemin (au sens « système de fichiers ») sur lequel les directives qu’elle défini doivent s’appliquer.
Par exemple, définissons deux sections PATH dans notre fichier php.ini, comme suit :
[PATH=/home/php/php53/ini/exemple-2/a]
variables_order = GPC
upload_max_filesize = « 5M »
upload_tmp_dir = « /home/php/temp/ »
[PATH=/home/php/php53/ini/exemple-2/b]
variables_order = GPC
upload_max_filesize = « 7M »
Pour les scripts PHP qui seront exécutés depuis le répertoire « a », nous pourrons par exemple uploader des fichiers allant jusqu’à 5 Mo :
ini-config-section-PATH-a-2.png
Et on constate que, cette fois-ci, la modification de valeur de la directive upload_tmp_dir a bien été prise en compte : dans le fichier php.ini système, nous avons le droit de la modifier, contrairement à ce que nous avions remarqué plus haut pour les fichiers .user.ini.
Dans le second répertoire, « b », la limitation de taille en upload est cette fois-ci configurée à 7 Mo :
ini-config-section-PATH-b-1.png
A chaque fois, j’ai pris des directives de configuration « géographiquement proches » dans la sortie de phpinfo, pour me faciliter les choses…
… Bien entendu, vous pouvez aussi essayer avec d’autres options ^^
Section HOST
Cela intéressera surtout ceux d’entre-vous qui hébergent plusieurs sites sur un seul serveur : depuis PHP 5.3, en mode CGI, il est possible de définir des directives de configuration en fonction de l’hôte — et donc du site — auquel l’utilisateur accède.
Par exemple, on peut ajouter au sein du fichier php.ini système une section telle que celle-ci :
[HOST=172.16.133.128:8080]
variables_order = GPC
upload_max_filesize = « 5M »
upload_tmp_dir = « /home/php/temp/ »
Une section HOST prend en paramètre le nom d’hôte pour lequel elle doit être considérée.
Vous noterez que ici, un numéro de port est inclu ; en effet, le numéro de port est considéré comme faisant parti du nom d’hôte, comme on peut le constater ci-dessous :
ini-cgi-_server-host.png
Accessoirement, si vous obtenez une section « PHP Variables » vide suite à l’appel de phpinfo, vérifiez que la directive variables_order prise en compte pour l’exécution de votre script inclut bien les variables serveur — la lettre S, donc.
Mais, au fait, avec ces nombreuses nouvelles possibilités de configuration, où va être définie la directive variables_order ?
Dans le fichier php.ini système ?
Eventuellement, re-définie, au sein d’une section PATH ou HOST ?
Ou est-ce qu’elle sera re-définie dans le .user.ini de votre répertoire ?
Ou même dans un fichier .user.ini situé dans l’un des répertoires père de celui où se trouve votre script ?
Vous l’aurez compris, ces nouvelles fonctionnalités ne sont pas sans présenter un risque : celui d’avoir du mal à vous y retrouver au sein de vos fichiers de configuration !
A vous donc de ne pas en abuser, et de les utiliser à bon escient %)
Pour ce qui est de la documentation officielle, vous pouvez vous référer à List of php.ini sections.
With a Little Help from my Friend | How to recreate root account in MySQL
Today I was trying to log in to mysql database administration on one of my hosting machines and as I was getting ‘permission denied for user rott@localhost’ I tried to fix the root account and reset its password. But I wasn’t successful and later on I realized, that the root account was deleted from the mysql database by one of my friends accidentally. I started to search the internet what to do, but the only thing I have found regarding this issue was question on MySQL forum with exactly the same problem but no answer. So as usual, I tried to solve it by myself and here is it is.
The pre requisition is a shell access on your MySQL machine. Then you have to stop the standard mysql daemon and start the database in safe mode.
/etc/init.d/mysql stop
mysqld_safe –skip-grant-tables &
Then log in as a root and switch to mysql system database.
mysql -u root
mysql> use mysql;
Try to check that the root user is not present in user table:
mysql> select * from user where User=’root’;
If the database return empty record, lets manually insert the root user with empty password and then set all the permissions which he normally needs:
mysql> insert into user (Host, User, Password) values (‘localhost’,'root’, »);
Query OK, 1 rows affected (0.04 sec)
mysql> update user set Select_priv=’Y',Insert_priv=’Y',Update_priv=’Y',Delete_priv=’Y',Create_priv=’Y',Drop_priv=’Y',Reload_priv=’Y',Shutdown_priv=’Y',Process_priv=’Y',File_priv=’Y',Grant_priv=’Y',References_priv=’Y',Index_priv=’Y',Alter_priv=’Y',Show_db_priv=’Y',Super_priv=’Y',Create_tmp_table_priv=’Y',Lock_tables_priv=’Y',Execute_priv=’Y',Repl_slave_priv=’Y',Repl_client_priv=’Y',Create_view_priv=’Y',Show_view_priv=’Y',Create_routine_priv=’Y',Alter_routine_priv=’Y',Create_user_priv=’Y’ where user=’root’;
Query OK, 1 rows affected (0.03 sec)
Then quit the database console, kill the mysqld_safe daemon and start the standard mysql daemon again:
mysql> quit
killall mysqld_safe
/etc/init.d/mysql start
Try to log in into mysql console again with an empty password and for double check, try to run ‘grant’ command to see that the account is fully working:
Postfix with SASL-Authentication in Debian – Jonas Genannt
I think SMTP-AUTH is very important! Here is a short HowTo for Postfix with sasl authentication against shadow.
First install the necessary packages:
apt-get install postfix-tls libsasl2-modules sasl2-bin
Open the /etc/default/saslauthd for the configuration.
# This needs to be uncommented before saslauthd will be run automatically
START=yes
# You must specify the authentication mechanisms you wish to use.
# This defaults to « pam » for PAM support, but may also include
# « shadow » or « sasldb », like this:
MECHANISMS= »shadow »
PARAMS= »-m /var/spool/postfix/var/run/saslauthd/ »
PIDFILE= »/var/spool/postfix/var/run/${NAME}/saslauthd.pid »
Postfix have to know which authentication mode the daemon will use.
You can define this in the /etc/postfix/sasl/smtpd.conf! (chmod 0644)
saslauthd_path: /var/run/saslauthd/mux
pwcheck_method: saslauthd
mech_list: plain login
Then configure the postfix to ask for a username and password then anybody will send a mail to the server.
Add the following lines to the /etc/postfix/main.cnf
#sasl
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtp_sasl_auth_enable = no
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks, reject_unknown_recipient_domain, permit_sasl_authenticated, reject_unauth_destination
For security reason you should change that postfix runs in a chroot environment. You can change that in the /etc/postfix/master.cnf
smtp inet n – y – - smtpd
(Change the – to y!)
Create now the directory for the saslauthd:
mkdir -p /var/spool/postfix/var/run/saslauthd
Set the right directory permission:
chown root.sasl -R /var/spool/postfix/var/
Instead that dpkg change the permission we have to create an override for dpkg!
dpkg-statoverride –add root sasl 710 /var/spool/postfix/var/run/saslauthd
At last postfix musst have the right permission to speak to the saslauthd daemon, add postfix to the sasl group.
adduser postfix sasl
Restart postfix and saslauthd and try to send a mail to the mailserver.
(Don’t forget to set a username and a password in your mailclient for mailsending)