Проверката и/или тестването на синтаксиса на конфигурацията е ключова стъпка, която трябва да се извърши след извършване на промени в конфигурационния файл на приложение или услуга или дори след стартиране на актуализации. Това помага да се намалят шансовете услугата да не се рестартира поради грешки в конфигурацията.
Няколко приложения/програми или сервизни демони се доставят с команди за проверка на конфигурационните файлове за коректност на синтаксиса. Съставихме списък с общи приложения и услуги на Linux системи и как да тестваме или валидираме техните конфигурационни файлове.
Забележка: Използвайте, ако не сте влезли в сървър като root потребител, не забравяйте да използвате sudo команда когато е необходимо, докато извиквате команда, тъй като някои услуги работят с права на root и проверката на техните конфигурационни файлове изисква разрешения на root потребител.
Можете да проверите на sudo конфигурационен файл синтаксис, използващ висудо команда, която поддържа a --проверете
-° С
опция на командния ред само за валидиране на файл без редакция. The -f
опция показва съобщението за грешка и отваря файла за редактиране:
# visudo -c /etc/sudoers. ИЛИ. # visudo -c /etc/sudoers.d/my_config. ИЛИ. # visudo -f /etc/sudoers.d/my_config.
Можете да проверите Bash скриптовете за синтактични грешки, както следва:
# bash -n /path/to/scriptname.sh.
За да проверите Perl скриптовете за синтактични грешки, използвайте следната команда:
# perl -c /path/to/scriptname.
„systemd-analyze проверка” позволява тестване на системния файл за синтактични грешки. Той зарежда модулни файлове и отпечатва предупреждения, ако бъдат открити грешки.
По подразбиране той зарежда файлове, посочени в командния ред като аргумент, и всички други единици, посочени от тях:
# systemd-analyze проверка /etc/systemd/system/test.service.
За да проверите валидността на sshd конфигурационен файл и здравината на клавишите, издайте следната команда. За да проверите определен конфигурационен файл, посочете го с помощта на -f
флаг:
# sshd -t.
За да проверите NGINX конфигурационен файл, стартирайте nginx команда с -T
знаме. За да посочите различен конфигурационен файл, използвайте -° С
флаг:
# nginx -t. ИЛИ. # nginx -t -c /etc/nginx/conf.d/example.com.conf.
За да проверите php-fpm конфигурационен файл, изпълнете следната команда. Имайте предвид, че обаждането на -T
флаг два пъти (-tt)
кара конфигурацията да бъде изхвърлена преди излизане:
# php-fpm -t. ИЛИ. # php-fpm -tt.
След това можете да проверите Apache конфигурационен файл на уеб сървър, като използвате следната команда:
# apachectl configtest.
Като алтернатива можете да използвате следните команди на Базирани на RedHat дистрибуции:
# httpd -t.
На Базирани на Debian дистрибуции, стартирайте:
# apache2ctl -t.
Конфигурацията на HAProxy може да бъде тествана с помощта на следната команда, където -f
опцията указва файла и -° С
активира тестов режим:
# haproxy -f /etc/haproxy/haproxy.cfg -c.
Изпълнете следната команда, за да тествате синтаксиса на конфигурационния файл на Lighttpd. The -T
опцията за команден ред позволява на Lighttpd да тества конфигурационния файл по подразбиране за синтактични грешки и да излезе. Използвай -f
флаг за указване на персонализиран конфигурационен файл:
# lighttpd -t. ИЛИ. # lighttpd -t -f /path/to/config/file.
Уеб сървърът Tomcat позволява основна проверка на синтаксиса на конфигурацията. Първо се преместете във вашата инсталационна директория на tomcat и издайте следната команда:
# ./bin/catalina.sh configtest. ИЛИ. # $TOMCAT_HOME/bin/catalina.sh configtest.
Можете да анализирате Паунд конфигурационен файл на сървъра, преди да стартирате сървъра. Стартирайте паунд команда с -° С
флаг без друг аргумент за проверка на конфигурационния файл по подразбиране. Можете да зададете различен конфигурационен файл, като използвате -f
опция на командния ред:
# паунд -c. ИЛИ. # pound -f /path/to/config/file -c.
За да проверите varnishdVCL (Език за конфигуриране на лак) файлов синтаксис за всякакви грешки, използвайте следната команда. Ако всичко е наред, varnish ще изхвърли генерираната конфигурация, в противен случай ще покаже конкретен номер на ред във файла, който има грешка:
# varnishd -C. ИЛИ. # varnishd -f /etc/varnish/default.vcl -C.
За да предадете конфигурационния файл на squid за кеширащия прокси сървър на Squid, издайте следната команда. The -к
опция заедно с подкомандите за разбор или отстраняване на грешки, кажете на демона на squid да анализира конфигурационния файл или съответно да активира режима за отстраняване на грешки:
# squid -k анализира. # squid -k отстраняване на грешки.
За да разкрие всички грешки в Caddy уеб сървър конфигурация, издайте следната команда. Първият проверява конфигурацията по подразбиране, алтернативно използвайте --config
опция на командния ред за указване на конфигурационен файл:
# валидиране на caddy. ИЛИ. # caddy validate --config /path/to/config/file.
Изпълнете следната команда, за да тествате конфигурационния файл за vsftpd FTP сървър:
# vsftpd. ИЛИ. # vsftpd -olisten=НЕ /path/to/vsftpd.testing.conf.
Стартирайте dhcpd команда с -T
флаг за проверка на конфигурационния синтаксис на dhcpd сървъра:
# dhcpd -t. ИЛИ. # dhcpd -t -cf /path/to/dhcpd.conf.
Използвайте следната команда, за да тествате MySQL синтаксис на конфигурационния файл на сървъра на база данни. След изпълнение на командата, ако няма грешки, сървърът се прекратява с изходен код от 0, в противен случай той показва диагностично съобщение и завършва с код за изход от 1:
# mysqld --validate-config.
Същата команда, използвана за MariaDB сървърът на базата данни също работи за проверка на синтаксиса на конфигурационния файл на сървъра на база данни Mariadb:
# mysqld --validate-config.
Следната екранна снимка показва грешка в PostgreSQL конфигурационен файл.
За да откриете такава грешка, преминете към postgres потребителски акаунт на база данни и достъп до psql черупка. След това изпълнете командата, за да идентифицирате грешки във вашия конфигурационен файл:
postgres=# изберете изходен файл, име, изходна линия, грешка от pg_file_settings, където грешката не е нула;
За да потвърдите вашите Нагиос конфигурация, стартирайте нагиос команда с -v
знаме.
# nagios -v /usr/local/nagios/etc/nagios.cfg.
Стартирайте монит команда с -T
флаг за извършване на проверка на синтаксиса за по подразбиране Контролен файл на Monit. Можете да посочите конкретен контролен файл, като използвате -° С
флаг:
# monit -t. ИЛИ. # monit -t -c път/до/контролен/файл.
Следната команда ще ви помогне да проверите конфигурационните файлове на Postfix за синтактични грешки.
# проверка на постфикс.
Тази втора команда е по-подробна от първата:
# постфикс -vvv.
Проверете Dovecot IMAP синтаксис за конфигурация на сървъра, използвайки doveconf команда. Ще излезе с нулев код за грешка, ако всичко е наред, в противен случай ще излезе с ненулев код за грешка и ще покаже съобщението за грешка:
# doveconf 1>/dev/null. # ехо $?
Можете да проверите на Самба конфигурационен файл на файлов сървър, като използвате следната команда:
# testparm -v.
Когато извикате rsyslod команда с -N1
опция, той ще активира режима за отстраняване на грешки и също ще проверява конфигурационния файл по подразбиране за синтактични грешки. Използвай -f
флаг за четене на персонализиран конфигурационен файл:
# rsyslogd -N1.
Можете да проверите DNS на име конфигурационен файл, както следва:
# named-checkconf /etc/named.conf.
The ntpd конфигурационният синтаксис може да бъде тестван с помощта на следната команда, където -д
флаг активира подробен режим на отстраняване на грешки, -f
указва името на файла с дрейфа на честотата и -н
не предполага разклонение:
# ntpd -d -f /etc/ntp.conf -n.
Изпълнете следната команда, за да проверите синтаксиса на OpenStack-ansible конфигурационен файл:
# openstack-ansible setup-infrastructure.yml --syntax-check.
За отстраняване на грешки a logroate (съоръжение за ротация на регистрационни файлове) конфигурационен файл, стартирайте logrotate команда с -д
опция и посочете конфигурационния файл:
# logrotate -d /etc/logrotate.d/nginx.
Това е всичко, което имахме за вас в това ръководство. Споделете мислите си с нас или задайте въпроси чрез формата за обратна връзка по-долу. Можете също така да споделите повече примери за това как да проверите конфигурационния синтаксис на приложения или услуги, които не са изброени тук. С удоволствие ще добавим вашите примери към ръководството.