- Команды для проверки валидности конфигов Apache, Nginx и SSH
- Изначальная конфигурация
- Проверяем конфигурационный файл SSH на ошибки
- Проверяем конфигурационный файл Nginx на ошибки
- Проверяем конфигурационный файл Apache на ошибки
- Подведем итоги
- 30 способов проверить файлы конфигурации или сценарии в Linux
- 2. Bash Script
- 3. Perl-скрипты
- 4. Файлы модулей Systemd
- 5. Сервер OpenSSH
- 6. Веб-сервер NGINX
- 7. PHP-FPM
- 8. Веб-сервер Apache
- 9. Балансировщик нагрузки HAProxy TCP/HTTP
- 10. HTTP-сервер Lighttpd
- 11. Apache Tomcat
- 12. Pound Reverse Proxy
- 13. Varnishd HTTP Accelerator
- 14. Squid Proxy Caching Server
- 15. Веб-сервер Caddy
- 16. FTP-сервер vsftpd
- 17. DHCPD-сервер
- 18. Сервер базы данных MySQL
- 19. Сервер базы данных MariaDB
- 20. Сервер PostgreSQL
- 21. Инструмент мониторинга Nagios
- 22. Инструмент мониторинга Monit
- 23. Почтовый сервер Postfix
- 24. IMAP-сервер Dovecot
- 25. Файловый сервер Samba
- 26. Системный журнал/Rsyslogd
- 27. DNS-сервер (BIND)
- 28. NTP – Network Time Protocol
- 29. OpenStack-Ansible
- 30. Logrotate
Команды для проверки валидности конфигов Apache, Nginx и SSH
Одним из самых первых с чем встречается новичок в системном администрировании при работе с клиентским сервером это настройка SSH и работа с веб-серверами, такими как Apache или Nginx. Полностью избегать ошибок и проблем на начальном этапе точно не получится, но можно свести риски к минимуму проверяя после изменений конфигурационные файлы до перезапуска службы. Как это сделать расскажу далее.
Другие материалы для новичков вы можете найти в соответствующих разделах на канале.
Изначальная конфигурация
У меня в виртуальной машине находится сервер CentOS 7, на котором установлены Apache, Nginx и имеется SSH. Конфигурационные файлы стандартные, но это не играет роли, главное показать то, как можно их проверять встроенными средствами самих сервисов.
Проверяем конфигурационный файл SSH на ошибки
Начнем с проверки SSH-конфига. В CentOS 7 конфигурационный файл находится по пути /etc/ssh/sshd_config. Откроем его в текстовом редакторе nano и изменим что-нибудь с явной ошибкой.
Как видно из презентации, в самом конце конфигурационного файла я указал строку This error true.
Если теперь попробовать перезапустить ssh, то ничего хорошего из этого не получится, поверьте. Но можно заранее проверить конфиг, используя следующую команду:
«Выхлоп» указал нам на то, что в 140 строке содержится ошибочный аргумент и конфигурационный файл неверен. Запустим теперь редактор vim, включим в нем нумерацию строк, найдем 140-ую и уберем ее.
Запустив после исправления команду sshd -t мы убеждаемся, что ошибок больше нет и последующий рестарт ssh не приведет ни к чему страшному.
Если до читали до этого момента, то настало время подписаться на канал и его обновления в Телеграме . Так вы сможете получать уведомления о выходе новых, интересных и полезных заметок.
Проверяем конфигурационный файл Nginx на ошибки
Для веб-сервера Nginx помимо основного (системного) конфига называемого nginx.conf может существовать большое количество других конфигурационных файлов, которые будут загружаться перед основным. Местоположение конфигурационных файлов в Nginx может быть различным, по-умолчанию в CentOS это папка /etc/nginx/conf.d. Там я положил обычный конфигурационный файл под названием test.ru.conf. Давайте посмотрим на его содержимое.
Казалось бы обычный файл, но я забыл поставить точку с запятой после директивы root, которая указывает серверу местоположение основных файлов сайта. И если сейчас попробовать перезапустить Nginx, то получим ошибку и сервер просто-напросто не запустится.
Этого можно было избежать, если вначале использовать следующую команду для проверки конфига:
Опять-таки, нам будет показана суть ошибки и строка, где она содержится. Открываем редактор, исправляем ошибку, проверяем конфиг еще раз и после рестартуем Nginx.
Вот так просто и без лишней нервотрепки мы можем избавить себя от проблем с падением сервера Nginx и следовательно от недоступности веб-сервисов клиента.
Проверяем конфигурационный файл Apache на ошибки
Конфигурационные файлы Apache в CentOS 7 по-умолчанию хранятся по пути /etc/httpd/conf.d. Опять-таки там я разместил обычный конфигурационный файл test.ru.conf. Взглянем на него.
Казалось бы все верно и можно рестартовать Apache, что мы и сделаем.
Внезапно ошибка, сервер не запустился. Чтобы такого не было нужно использовать следующую команду:
Запустим ее и увидим, что какие-то неполадки с директивой VirtualHost. Вернее при создании конфига я указал VitrualHost в начале и конце конфига, что и вызвало ошибку. Нужно это исправить и перезапустить сервер.
Подведем итоги
Даже если вы уверены на 200% в том, что конфигурационный файл написан без ошибок, то использование этих команд поможет вам сэкономить нервы, а клиентам деньги. Согласитесь, что их ввод не занимает много времени, но при этом как-раз именно время они и экономят. Особенно, если вы новичок, для которого ошибки в самом начале естественны.
Думаю, что материал окажется полезным для тех, кто только начинает свой путь в системном администрировании и изучении Linux-дистрибутивов. Если он уже принес вам пользу, то я только рад.
30 способов проверить файлы конфигурации или сценарии в Linux
Insomnia
2. Bash Script
Вы можете проверить скрипты Bash на наличие синтаксических ошибок следующим образом:
# bash -n /path/to/scriptname.sh
3. Perl-скрипты
Чтобы проверить сценарии Perl на наличие синтаксических ошибок, используйте следующую команду:
4. Файлы модулей Systemd
“systemd-analyze verify” позволяет проверить файл модуля systemd на наличие синтаксических ошибок. Он загружает юнит-файлы и выводит предупреждения, если обнаружены какие-либо ошибки.
По умолчанию он загружает файлы, указанные в командной строке в качестве аргумента, и любые другие модули, на которые они ссылаются:
# systemd-analyze verify /etc/systemd/system/test.service
5. Сервер OpenSSH
Чтобы проверить конфигурационный файл sshd и работоспособность ключей, введите следующую команду. Чтобы проверить конкретный файл конфигурации, укажите его с помощью -f флаг:
6. Веб-сервер NGINX
Чтобы проверить Nginx конфигурационный файл, запустите nginx команда с флагом -t . Чтобы указать другой файл конфигурации, используйте флаг -c :
# nginx -t OR # nginx -t -c /etc/nginx/conf.d/example.com.conf
7. PHP-FPM
Чтобы проверить файл конфигурации php-fpm, выполните следующую команду. Обратите внимание, что двойной вызов флага -t (-tt) вызывает сброс конфигурации перед выходом:
8. Веб-сервер Apache
Затем вы можете проверить Apache файл конфигурации веб-сервера с помощью следующей команды:
Кроме того, вы можете использовать следующие команды на Дистрибутивы на основе RedHat:
На Дистрибутивах на основе Debian ввести:
9. Балансировщик нагрузки HAProxy TCP/HTTP
Конфигурацию HAProxy можно протестировать с помощью следующей команды, где -f option указывает файл и -c включает тестовый режим:
# haproxy -f /etc/haproxy/haproxy.cfg -c
10. HTTP-сервер Lighttpd
Выполните следующую команду, чтобы проверить синтаксис файла конфигурации Lighttpd. -t Параметр командной строки позволяет Lighttpd проверить файл конфигурации по умолчанию на наличие синтаксических ошибок и завершить работу. Использовать -f флаг, чтобы указать пользовательский файл конфигурации:
# lighttpd -t OR # lighttpd -t -f /path/to/config/file
11. Apache Tomcat
Веб-сервер Tomcat позволяет выполнять базовую проверку синтаксиса конфигурации. Сначала перейдите в каталог установки tomcat и выполните следующую команду:
# ./bin/catalina.sh configtest OR # $TOMCAT_HOME/bin/catalina.sh configtest
12. Pound Reverse Proxy
Вы можете разобрать файл конфигурации сервера Pound перед запуском сервера. Запустите poun команда с -c флагом без каких-либо других аргументов, чтобы проверить файл конфигурации по умолчанию. Вы можете указать другой файл конфигурации, используя -f вариант командной строки:
# pound -c OR # pound -f /path/to/config/file -c
13. Varnishd HTTP Accelerator
Чтобы проверить синтаксис файла varnishd VCL (Varnish Configuration Language) на наличие любых ошибок, используйте следующую команду. Если все в порядке, dump выгрузит сгенерированную конфигурацию, в противном случае в файле отобразится конкретный номер строки, в которой есть ошибка:
# varnishd -C OR # varnishd -f /etc/varnish/default.vcl -C
14. Squid Proxy Caching Server
Чтобы передать файл конфигурации squid для кэширующего прокси-сервера Squid, введите следующую команду. -k вместе с подкомандами parse или debug, сообщите демону squid проанализировать файл конфигурации или включить режим отладки соответственно:
# squid -k parse # squid -k debug
15. Веб-сервер Caddy
Для выявления ошибок в конфигурации Caddy введите следующую команду. Первый проверяет конфигурацию по умолчанию, в качестве альтернативы используется —config параметр командной строки для указания файла конфигурации:
# caddy validate OR # caddy validate --config /path/to/config/file
16. FTP-сервер vsftpd
Выполните следующую команду, чтобы проверить файл конфигурации для vsftpd FTP-сервер:
# vsftpd OR # vsftpd -olisten=NO /path/to/vsftpd.testing.conf
17. DHCPD-сервер
Запустите dhcpd команду с -t флагом для проверки синтаксиса конфигурации сервера dhcpd:
# dhcpd -t OR # dhcpd -t -cf /path/to/dhcpd.conf
18. Сервер базы данных MySQL
Используйте следующую команду, для проверки синтаксиса файла конфигурации сервера MySQL базы данных. После запуска команды, если ошибок нет, сервер завершает работу с кодом выхода 0 в противном случае он отображает диагностическое сообщение и завершается с кодом выхода 1:
19. Сервер базы данных MariaDB
Эта же команда используется для сервера базы данных MariaDB:
20. Сервер PostgreSQL
На следующем снимке экрана показана ошибка в конфигурационном файле PostgreSQL.
Чтобы обнаружить такую ошибку, переключитесь на учетная запись пользователя базы данных psql . Затем запустите команду для выявления ошибок в файле конфигурации:
postgres=# select sourcefile, name,sourceline,error from pg_file_settings where error is not null;
21. Инструмент мониторинга Nagios
Чтобы проверить конфигурацию вашего Nagios, запустите команду nagios с флагом -v .
# nagios -v /usr/local/nagios/etc/nagios.cfg
22. Инструмент мониторинга Monit
Запустите команду monit с флагом -t для выполнения проверки синтаксиса. А так же вы можете указать конкретный управляющий файл, используя флаг -c :
# monit -t OR # monit -t -c path/to/control/file
23. Почтовый сервер Postfix
Следующая команда поможет вам проверить файлы конфигурации Postfix на наличие синтаксических ошибок.
Эта вторая команда более подробная, чем первая:
24. IMAP-сервер Dovecot
Проверить синтаксис конфигурации сервера Dovecot IMAP с использованием команды doveconf. Она завершится с нулевым кодом ошибки, если все в порядке, в противном случае завершится с ненулевым кодом ошибки и отобразит сообщение об ошибке:
25. Файловый сервер Samba
Вы можете проверить файл конфигурации файлового сервера samba с помощью следующей команды:
26. Системный журнал/Rsyslogd
Когда вы вызываете команду rsyslod с вариантом -N1 , она включает режим отладки, а также проверяет файл конфигурации по умолчанию на наличие синтаксических ошибок. Используйте флаг -f для чтения пользовательского файла конфигурации:
27. DNS-сервер (BIND)
Вы можете проверить файл конфигурации named следующим образом:
# named-checkconf /etc/named.conf
28. NTP – Network Time Protocol
Синтаксис конфигурации можно проверить с помощью следующей команды ntpd, где -d флаг включает подробный режим отладки, -f задает имя файла дрейфа частоты и -n подразумевает отсутствие форка:
29. OpenStack-Ansible
Выполните следующую команду, чтобы проверить синтаксис файла конфигурации OpenStack-ansible:
# openstack-ansible setup-infrastructure.yml --syntax-check
30. Logrotate
Чтобы отладить файл конфигурации Logrotate (средство ротации журналов), запустите команду logrotate с флагом -d и укажите файл конфигурации:
# logrotate -d /etc/logrotate.d/nginx
Это все, что у нас было для вас в этом руководстве. Поделитесь с нами своими мыслями или задайте вопросы через форму обратной связи ниже. Вы также можете поделиться другими примерами проверки синтаксиса конфигурации любых приложений или служб, не перечисленных здесь. Мы с удовольствием добавим ваши примеры в руководство.