Les serveurs Linux et Unix sont généralement configurés à l’aide de nombreux fichiers texte. N’importe quel système serveur peut contenir des dizaines de fichiers de configuration. Il est donc extrêmement important de vérifier la validité de ces fichiers de configuration.
Dans certains cas, il est possible de vérifier la validité des répertoires ( comme /var/lib/cache/). Les fichiers texte sont plus faciles à gérer à distance en utilisant ssh et un éditeur de texte. S’il existe une erreur de configuration, le serveur ne peut pas démarrer. Voici donc comment trouver les erreurs de syntaxe des fichiers de configuration d’ un serveur Linux / Unix.
Tout d’abord, testez la configuration de votre serveur avant de redémarrer les services Linux/ Unix.
Les options suivantes ne lanceront pas et n’éteindront pas votre serveur, elles serviront simplement à tester le fichier de configuration. Elles vérifieront la validité de la syntaxe de la configuration. Dans la plupart des cas, vous pouvez spécifier quel fichier de configuration doit être utilisé en lieu et place du fichier par défaut. Lorsque vous avez vérifié vos fichiers de configuration et modifié les erreurs, vous pouvez enfin relancer les services requis.
A propos du reload des serveurs
Sous Linux, la syntaxe est la suivante:
/sbin/service SERVICE-NAME [reload|restart]
ou
/etc/init.d/SERVICE-NAME [reload|restart]
L’option reload relance le fichier config sans interrompre les opérations en cours. Par exemple, la commande suivante va reload le serveur web Apache après les changements de fichiers de configuration:
# /sbin/service httpd reload
Cependant, la plupart des programmes daemon Unix / Linux utilisent SIGHUP comme signal pour se relancer. La syntaxe est la suivante:
kill -HUP $(cat /var/run/SERVICE.pid)
ou
kill -HUP `cat /var/run/SERVICE.pid`
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur OpenSSH
Pour tester le fichier config OpenSSH, vous pouvez utilisez la syntaxe suivante:
# /usr/sbin/sshd -t && echo $?
sample configuration error session:
# usr/sbin/sshd -t
Sample outputs:
/etc/ssh/sshd_config line 26: Bad yes/without-password/forced-commands-only/no argument: Naa
Pour imprimer la ligne # 26, entrez:
# sed -n ’26p’ /etc/ssh/sshd_config
Sample outputs:
PermitRootLogin Naa
Utilisez un éditeur de texte pour modifier le fichier, puis entrez:
# vi +26 etc/ssh/sshd_config
Modifiez la syntaxe puis entrez:
PermitRootLogin No
Sauvegardez et fermez le fichiez, puis testez-le à nouveau:
# /usr/sbin/sshd -t
OpenSSH Extended Test Mode
Utilisez l’option T pour vérifier la validité du fichier config, sortez la configuration effective vers stdout puis sortez:
# /usr/sbin/sshd -T
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur web Apache
Pour lancer des tests de syntaxe uniquement pour les fichiers de configuration, la syntaxe est la suivante:
# /usr/sbin/apache2 -t
Sample error reporting:
apache2: Syntax error on line 50 of /etc/apache2/apache2.conf: ServerRoot must be a valid directory
Sur RHEL and friend, entrez:
# /usr/sbin/httpd -t
Sample outputs:
Syntax OK
Vous pouvez également utiliser la commande apachectl qui lancera un test de syntaxe des fichiers config:
# apachectl configtest
ou
# apachectl -t
Relancez le serveur Apache server, entrez:
# apachectl -k graceful
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur web Nginx
Pour lancer les tests de syntaxe des fichiers config nginx, entrez:
# /usr/local/nginx/sbin/nginx -t
# /usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
Sample outputs:
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
Ainsi,
-c /path/to/file : Spécifie quel fichier confif Nginx doit utiliser à la place du fichier par défaut.
-t : teste seulement le fichier config.
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur web Lighttpd
Pour tester le fichier config puis sortir, entrez:
# /usr/local/sbin/lighttpd -t -f /usr/local/etc/lighttpd/cyberciti.biz/lighttpd.conf
Sample outputs:
Syntax OK
Ainsi,
-f filename : Utilise le nom de fichier du fichier config.
-t : teste le fichier config.
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur DNS BIND
Utilisez la commande named-checkconf pour vérifier la syntaxe, mais pas les termes utilisés.
# named-checkconf /etc/named.conf
Vous pouvez également vérifier les fichiers zone de BIND, entrez:
# named-checkzone cyberciti.biz /var/named/zone.cyberciti.biz
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur Proxy Squid
Pour tester le fichier de configuration, entrez:
# /usr/sbin/squid -k check
# /usr/sbin/squid -k parse
Sample outputs:
2012/03/30 07:44:35| Processing Configuration File: /etc/squid/squid.conf (depth 0)
2012/03/30 07:44:35| Initializing https proxy context
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur de bases de données MySQL
Entrez la commande suivante:
# mysqld –verbose –help
Il est recommandé de rediriger la sortie vers /dev/null et de seulement afficher les erreurs et avertissements à l’écran.
# /usr/libexec/mysqld –verbose –help 1>/dev/null
Sample outputs:
120330 7:52:43 [Warning] ‘–log_slow_queries’ is deprecated and will be removed in a future release. Please use ”–slow_query_log’/’–slow_query_log_file” instead.
Vous pouvez spécifier un nouveau fichier config tel que /root/test-my.cnf
# mysqld –defaults-file=/root/test-my.cnf –verbose –help 1>/dev/null
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur mail Postfix
Utilisez la syntaxe suivante pour être alerté des mauvaises permissions ou possessions de fichiers ou dépertoires et pour créer des répertoires manquants:
# postfix check
ou
# postfix -vvv
Sample outputs:
postfix: dict_register: mail_dict 1
postfix: dict_update: config_directory = /etc/postfix
postfix: dict_update: queue_directory = /var/spool/postfix
postfix: dict_update: command_directory = /usr/sbin
postfix: dict_update: daemon_directory = /usr/libexec/postfix
postfix: dict_update: data_directory = /var/lib/postfix
postfix: dict_update: mail_owner = postfix
postfix: dict_update: inet_interfaces = localhost
postfix: dict_update: inet_protocols = all
postfix: dict_update: mydestination = $myhostname, localhost.$mydomain, localhost
postfix: dict_update: unknown_local_recipient_reject_code = 550
postfix: fatal: /etc/postfix/main.cf, line 385: missing ‘=’ after attribute name: “sss”
Vous pouvez voir les erreurs dans le fichier log maillog, entrez:
# tail -f /var/log/maillog
Sample outputs:
And it’ll run mysqld (or drizzled), parse tMar 30 08:01:34 mx421 postfix[2284]: dict_update: command_directory = /usr/sbin
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: daemon_directory = /usr/libexec/postfix
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: data_directory = /var/lib/postfix
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: mail_owner = postfix
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: inet_interfaces = localhost
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: inet_protocols = all
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: mydestination = $myhostname, localhost.$mydomain, localhost
Mar 30 08:01:34 mx421 postfix[2284]: dict_update: unknown_local_recipient_reject_code = 550
Mar 30 08:01:34 mx421 postfix[2284]: fatal: /etc/postfix/main.cf, line 385: missing ‘=’ after attribute name: “sss”
Mar 30 08:01:42 mx421 postfix[2285]: fatal: /etc/postfix/main.cf, line 385: missing ‘=’ after attribute name: “sss”he config, report any problems, print help, and exit without initializing storage engines or trying to
Trouver les erreurs de syntaxe du fichier serveur Samba (SMB/CIFS)
Entrez la commande suivante:
# testparm -v
tcpd
La commande tcpdchk examine la configuration et reporte les éventuels problèmes rencontrés:
# tcpdchk
# tcpdchk -a
# tcpdchk -d
# tcpdchk -i /path/to/inetd.conf
# tcpdchk -v
Ainsi,
-a : Reporte les règles de contrôle d’accès qui permettent l’accès sans aucun mot clef explicite.
-d : Examine les fichiers hosts.allow et hosts.deny dans le répertoire actuel au lieu de ceux par défaut.
-i inet_conf : Specifiez cette option quand tcpdchk est incapable de trouver votre fichier config réseau inetd.conf, ou quand vous pensez que le programme utilise le mauvais.
-v : Affiche les contenus de chaque règle de contrôle d’accès. Les listes daemon, listes client, commandes shell ainsi que les options sont affichées.
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur dhcpd
Pour vérifier la syntaxe, entrez:
# dhcpd -t
ou
# dhcpd -t -cf /path/to/dhcpd.testing.conf
ou
# dhcpd -T
ou
# dhcpd -T -lf /path/to/dhcpd.lease.file
Ainsi,
-t : le serveur testera seulement la syntaxe du fichier config mais ne réalisera aucune opération sur le réseau. Cela peut être utilisé pour tester automatiquement un nouveau fichier de configuration avant son installation.
-T : pour tester les fichiers de la base de données.
-cf /path/to/dhcpd.testing.conf : utilise le fichier config alternatif /path/to/dhcpd.testing.conf.
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur FTP vsftpd
Pour vérifier les erreurs de syntaxe du fichier config de votre serveur FTP vsftpd, entrez:
# vsftpd
ou
# vsftpd -olisten=NO /path/to/vsftpd.testing.conf
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur Nagios
Pour vérifiez la validité de la syntaxe sur nagios.cfg :
# nagios -v /path/to/testing/nagios.cfg
Ainsi,
-v : vérifie votre configuration
Trouver les erreurs de syntaxe des fichiers de configuration d’un serveur Openntpd
Pour vérifier la syntaxe sur ntpd.conf, entrez :
# ntpd -n
# ntpd -f /usr/local/etc/ntpd.conf -n
# ntpd -d -f /usr/local/etc/ntpd.conf -n
Ainsi,
-n : Vérifie seulement la validité du fichier de configuration.
-f /usr/local/etc/ntpd.conf : utilise /usr/local/etc/ntpd.conf file comme fichier de configuration à la place du fichier par défaut /etc/ntpd.conf.
-d : ne daemonize pas and ntpd tournera en fond et se connectera à stderr.
Trouver les erreurs de syntaxe des fichiers de configuration sur Xorg – le serveur X11
Linux et les OS de type Unix utilisent X11 pour offrir aux utilisateurs une interface graphique puissante. X11 estune version gratuite du système X Window implémenté dans Xorg. Le fichier xorg.conf par défaut est localisé dans /etc/X11 directory. Vous pouvez créer un fichier de configuration initiale en entrant la commande suivante:
# Xorg -configure
Pour vérifier la configuration existante afin de vérifier que Xorg peut bien fonctionner avec hardware graphique sur le système ciblé, entrez la commande:
# Xorg -config /path/to/xorg.conf.new -retro
Le nouveau Xorg est entièrement auto-configuré et ne nécessite donc pas de configuration manuelle. Cependant, si vous utilisez des drivers propriétaires ( de type Nvidia), il vous faudra tester la syntaxe via la méthode décrite ci-dessus.
Trouver les erreurs de syntaxe des fichiers de configuration de syslogd / rsyslogd
Pour vérifier les erreurs de syntaxe, entrez la commande:
# syslogd -f /etc/rsyslog.testing.conf -d
ou
rsyslogd -c4 -f /etc/rsyslog.testing.conf -N 1
Sample outputs:
rsyslogd: version 4.6.4, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: invalid or yet-unknown config file command – have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ]
rsyslogd: the last error occured in /etc/rsyslog.conf, line 11:”$FilesOnwer root”
rsyslogd: CONFIG ERROR: could not interpret master config file ‘/etc/rsyslog.testing.conf’. [try http://www.rsyslog.com/e/2124 ]
Une vérification sans erreur:
rsyslogd: version 4.6.4, config validation run (level 1), master config /etc/rsyslog.testing.conf
rsyslogd: End of config validation run. Bye.
Ainsi,
-c4 : Sélectionne le mode de compatibilité de fond désiré ( # 4 dans cet exemple).
-f /etc/rsyslog.testing.conf : Spécifie un fichier de configuration alternatif à la place de /etc/rsyslog.conf, qui est le fichier config par défaut.
-d : Debug mode ( fonctionne seulement avec syslogd)
-N 1 : Vérifie le fichier de configuration. Le niveau d’argument modifie le comportement. 0 revient au même que de ne pas spécifier l’option -N, et 1 active le code.
Vérifier les erreurs de syntaxe des fichiers de configuration d’un système d’impression CUPS
CUPS est le système d’impression standard développé par Apple, pour Mac OS X ainsi que pour d’autres OS UNIX/Linux. cupsd est le planificateur pour CUPS. Il implémente un système d’impression basé sur le protocole d’impression Internet version 2.1. Pour trouver les erreurs des fichiers de configuration, entrez la commande:
# cupsd -f -c /path/to/cupsd.testing.conf -t
Sample outputs:
Unknown directive Loggslevel on line 6.
/etc/cups/cupsd.conf is OK
Une vérification sans erreur:
/etc/cups/cupsd.conf is OK
Ainsi,
-f : lance cupsd en fond.
-c /path/to/cupsd.testing.conf : utilise le fichier de configuration /path/to/cupsd.testing.conf
-t : teste le fichier de configuration pour les erreurs de syntaxe.
Trouver les erreurs de syntaxe des fichiers de configuration sur varnishd
Pour tester les erreurs de syntaxe de varnishd vlc , entrez:
# varnishd -C -f /path/to/wordpress.vlc
Ainsi,
-C : imprime le code VCL en langage C puis sort. Spécifie le fichier VCL à compiler avec l’option -f.
-F /path/to/wordpress.vlc : utilise le fichier de configuration VLC spécifié à la place du fichier par défaut.
Quelques astuces supplémentaires pour vérifier les erreurs de synthaxe
Bash / KSH Shell Scripts
Il est possible de vérifier la syntaxe d’un scripte bash sans l’exécuter:
$ bash -n ./myscript
Sample outputs:
./myscript<: line 16: syntax error near unexpected token `fi’
./myscript<: line 16: `fi’
ou
$ ksh -n /path/to/backup.ksh
ting.conf : Load the firewall rules contained in a file called /path/to/pf.testing.conf.