Ubuntu сервер не отвечает

Обновлено: 07.07.2024

Неправильное имя хоста

При выполнении команды подключения по SSH на стороне клиента может быть получена ошибка:

Ошибка с истечением времени соединения

Такая ошибка происходит, когда сервер SSH не может ответить подключающемуся к нему клиенту в течение определённого промежутка времени:

Для исправления этой ошибки необходимо в первую очередь сделать следующее:

проверить правильность имени и/или IP-адреса хоста сервера SSH;
проверить, что указанный порт (22) доступен для подключения. В некоторых сетях он может быть заблокирован;
проверить режим политики брандмауэра, политика которого по-умолчанию должна быть не DROP.

Отклонение соединения

Данная ошибка схожа с ошибкой истечения времени соединения и выглядит следующим образом:

Методы её устранения такие же, как и в случае, описанном в предыдущей главе, но дополнительно нужно проверить, что для подключения используется именно тот порт, который настроен на стороне сервера. Иногда, в целях безопасности его задают отличным от стандартного 22.

Настройка брандмауэра

Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.

В зависимости от того, какой порт используется для подключения по SSH, необходимо настроить соответствующее подключение для обслуживания брандмауэром. Для начала нужно узнать, какие правила используются в данный момент. Для iptables это позволяет сделать команда:

Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:

Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.

Проверка состояния сервера SSH

При получении ошибок подключения также не лишним будет проверить, запущен ли сам сервер SSH. Это можно сделать при помощи команды systemctl:

В случае, если демон SSH не работает, то в строке Active будет следующее:

Для запуска демона следует использовать команду:

Следует также обратить внимание на то, что обычно в дистрибутивах CentOS демон SSH называется sshd, а в Ubuntu – ssh.

Проверка порта для работы SSH

Чтобы проверить, какой порт настроен для использования сервером SSH, можно просмотреть соответствующий параметр в конфигурационном файле /etc/ssh/ssh_config . Для этого можно использовать команду grep для поиска по файлу:

Как видно из данного вывода, сервер SSH настроен на работу по стандартному порту 22. Параметр Port можно переопределять, но тогда необходимо внести изменения в соответствующие правила для брандмауэров, а также проинформировать клиентов о том, какой порт используется для подключения по SSH вместо стандартного.

Заключение

В заключение следует заметить, что в данной статье были рассмотрены лишь самые общие и распространённые неполадки, связанные с подключением по SSH. Обычно это легко выявляемые и быстро устраняемые ошибки.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Мне доводилось видеть множество Linux-серверов, которые, без единой перезагрузки, работали годами, в режиме 24x7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.

И, кстати, в самом начале, сразу после сбоя, стоит ответить на весьма важный вопрос: «А сервер ли виноват в том, что случилось?». Вполне возможно, что источник проблемы совсем не в нём. Но, не будем забегать вперёд.

Поиск и устранение неполадок: раньше и теперь

Когда, в 1980-х, я начал работать системным администратором Unix — задолго до того, как Линус Торвальдс загорелся идеей Linux — если с сервером было что-то не так, это была реальная засада. Тогда было сравнительно мало инструментов для поиска проблем, поэтому для того, чтобы сбойный сервер снова заработал, могло понадобиться много времени.

Теперь всё совсем не так, как раньше. Как-то один системный администратор вполне серьёзно сказал мне, говоря о проблемном сервере: «Я его уничтожил и поднял новый».

В былые времена такое звучало бы дико, но сегодня, когда ИТ-инфраструктуры строят на основе виртуальных машин и контейнеров… В конце концов, развёртывание новых серверов по мере необходимости — это обычное дело в любой облачной среде.

Сюда надо добавить инструменты DevOps, такие, как Chef и Puppet, используя которые легче создать новый сервер, чем диагностировать и «чинить» старый. А если говорить о таких высокоуровневых средствах, как Docker Swarm, Mesosphere и Kubernetes, то благодаря им работоспособность отказавшего сервера будет автоматически восстановлена до того, как администратор узнает о проблеме.

Данная концепция стала настолько распространённой, что ей дали название — бессерверные вычисления. Среди платформ, которые предоставляют подобные возможности — AWS Lambda, Iron.io, Google Cloud Functions.

Благодаря такому подходу облачный сервис отвечает за администрирование серверов, решает вопросы масштабирования и массу других задач для того, чтобы предоставить клиенту вычислительные мощности, необходимые для запуска его приложений.

Бессерверные вычисления, виртуальные машины, контейнеры — все эти уровни абстракции скрывают реальные серверы от пользователей, и, в некоторой степени, от системных администраторов. Однако, в основе всего этого — физическое аппаратное обеспечение и операционные системы. И, если что-то на данном уровне вдруг разладится, кто-то должен привести всё в порядок. Именно поэтому то, о чём мы сегодня говорим, никогда не потеряет актуальности.

Помню разговор с одним системным оператором. Вот что он говорил о том, как надо поступать после сбоя: «Переустановка сервера — это путь вникуда. Так не понять — что стало с машиной, и как не допустить такого в будущем. Ни один сносный администратор так не поступает». Я с этим согласен. До тех пор, пока не обнаружен первоисточник проблемы, её нельзя считать решённой.

Итак, перед нами сервер, который дал сбой, или мы, по крайней мере, подозреваем, что источник неприятностей именно в нём. Предлагаю вместе пройти пять шагов, с которых стоит начинать поиск и решение проблем.

Шаг первый. Проверка аппаратного обеспечения

В первую очередь — проверьте железо. Я знаю, что звучит это тривиально и несовременно, но, всё равно — сделайте это. Встаньте с кресла, подойдите к серверной стойке и удостоверьтесь в том, что сервер правильно подключён ко всему, необходимому для его нормальной работы.

Я и сосчитать не смогу, сколько раз поиски причины проблемы приводили к кабельным соединениям. Один взгляд на светодиоды — и становится ясно, что Ethernet-кабель выдернут, или питание сервера отключено.

Конечно, если всё выглядит более-менее прилично, можно обойтись без визита к серверу и проверить состояние Ethernet-соединения такой командой:

Если её ответ можно трактовать, как «да», это значит, что исследуемый интерфейс способен обмениваться данными по сети.

Однако, не пренебрегайте возможностью лично осмотреть устройство. Это поможет, например, узнать, что кто-то выдернул какой-нибудь важный кабель и обесточил таким образом сервер или всю стойку. Да, это до смешного просто, но удивительно — как часто причина отказа системы именно в этом.

Ещё одну распространённую аппаратную проблему невооружённым взглядом не распознать. Так, сбойная память является причиной всевозможных проблем.

Виртуальные машины и контейнеры могут скрывать эти проблемы, но если вы столкнулись с закономерным появлением отказов, связанных с конкретным физическим выделенным сервером, проверьте его память.

Для того, чтобы увидеть, что BIOS/UEFI сообщают об аппаратном обеспечении компьютера, включая память, используйте команду dmidecode:

Даже если всё тут выглядит нормально, на самом деле это может быть и не так. Дело в том, что данные SMBIOS не всегда точны. Поэтому, если после dmidecode память всё ещё остаётся под подозрением — пришло время воспользоваться Memtest86. Это отличная программа для проверки памяти, но работает она медленно. Если вы запустите её на сервере, не рассчитывайте на возможность использовать эту машину для чего-нибудь другого до завершения проверки.

Если вы сталкиваетесь со множеством проблем с памятью — я видел такое в местах, отличающихся нестабильным электропитанием — нужно загрузить модуль ядра Linux edac_core. Этот модуль постоянно проверяет память в поиске сбойных участков. Для того, чтобы загрузить этот модуль, воспользуйтесь такой командой:

Подождите какое-то время и посмотрите, удастся ли что-нибудь увидеть, выполнив такую команду:

Эта команда даст вам сводку о числе ошибок, разбитых по модулям памяти (показатели, название которых начинается с csrow ). Эти сведения, если сопоставить их с с данными dmidecode о каналах памяти, слотах и заводских номерах компонентов, помогут выявить сбойную планку памяти.

Шаг второй. Поиск истинного источника проблемы

Итак, сервер стал странно себя вести, но дым из него ещё пока не идёт. В сервере ли дело? Прежде чем вы попытаетесь решить возникшую проблему, сначала нужно точно определить её источник. Скажем, если пользователи жалуются на странности с серверным приложением, сначала проверьте, что причина проблемы — не в сбоях на клиенте.

Например, друг однажды рассказал мне, как его пользователи сообщили о том, что не могут работать с IBM Tivoli Storage Manager. Сначала, конечно, казалось, что виновен во всём сервер. Но в итоге администратор выяснил, что проблема вообще не была связана с серверной частью. Причиной был неудачный патч Windows-клиента 3076895. Но то, как сбоило это обновление безопасности, делало происходящее похожим на проблему серверной стороны.

Кроме того, нужно понять, является ли причиной проблемы сам сервер, или серверное приложение. Например, серверная программа может работать кое как, а железо оказывается в полном порядке.

Для начала — самое очевидное. Работает ли приложение? Есть множество способов проверить это. Вот два моих любимых:

Если оказалось, что, например, веб-сервер Apache не работает, запустить его можно такой командой:

Если в двух словах, то прежде чем диагностировать сервер и искать причину проблему, узнайте — сервер ли виноват, или что-то другое. Только тогда, когда вы поймёте, где именно находится источник сбоя, вы сможете задавать правильные вопросы и переходить к дальнейшему анализу того, что произошло.

Это можно сравнить с неожиданной остановкой автомобиля. Вы знаете, что машина дальше не едет, но, прежде чем тащить её в сервис, хорошо бы проверить, есть ли бензин в баке.

Шаг третий. Использование команды top

Итак, если оказалось, что все пути ведут к серверу, то вот ещё один важный инструмент для проверки системы — команда top . Она позволяет узнать среднюю нагрузку на сервер, использование файла подкачки, выяснить, какие ресурсы системы используют процессы. Эта утилита показывает общие сведения о системе и выводит данные по всем выполняющимся процессам на Linux-сервере. Вот подробное описание данных, которые выводит эта команда. Тут можно найти массу информации, которая способна помочь в поиске проблем с сервером. Вот несколько полезных способов работы с top , позволяющих найти проблемные места.

Для того, чтобы обнаружить процесс, потребляющий больше всего памяти, список процессов надо отсортировать в интерактивном режиме, введя с клавиатуры M . Для того, чтобы выяснить приложение, потребляющее больше всего ресурсов процессора, отсортируйте список, введя P . Для сортировки процессов по времени активности, введите с клавиатуры T . Для того, чтобы лучше видеть колонку, по которой производится сортировка, нажмите клавишу b .

Кроме того, данные по процессам, выводимые командой в интерактивном режиме, можно отфильтровать, введя O или o . Появится следующее приглашение, где предлагается добавить фильтр:

Затем можно ввести шаблон, скажем, для фильтрации по конкретному процессу. Например, благодаря фильтру COMMAND=apache , программа будет выводить только сведения о процессах Apache.

Ещё одна полезная возможность top заключается в выводе полного пути процесса и аргументов запуска. Для того, чтобы просмотреть эти данные, воспользуйтесь клавишей c .

Ещё одна похожая возможность top активируется вводом символа V . Она позволяет переключиться в режим иерархического вывода сведений о процессах.

Кроме того, можно просматривать процессы конкретного пользователя с помощью клавиш u или U , или скрыть процессы, не потребляющих ресурсы процессора, нажав клавишу i .

Хотя top долго была самой популярной интерактивной утилитой Linux для просмотра текущей ситуации в системе, у неё есть и альтернативы. Например, существует программа htop обладает расширенным набором возможностей, которая отличается более простым и удобным графическим интерфейсом Ncurses. Работая с htop , можно пользоваться мышью и прокручивать список процессов по вертикали и по горизонтали для того, чтобы просмотреть их полный список и полные командные строки.

Я не жду, что top сообщит мне — в чём проблема. Скорее, я использую этот инструмент для того, чтобы найти нечто, что заставит подумать: «А это уже интересно», и вдохновит меня на дальнейшие исследования. Основываясь на данных от top , я знаю, например, на какие логи стоит взглянуть в первую очередь. Логи я просматриваю, используя комбинации команд less , grep и tail -f .

Шаг четвёртый. Проверка дискового пространства

Даже сегодня, когда в кармане можно носить терабайты информации, на сервере, совершенно незаметно, может кончиться дисковое пространство. Когда такое происходит — можно увидеть весьма странные вещи.

Разобраться с дисковым пространством нам поможет старая добрая команда df, имя которой является сокращением от «disk filesystem». С её помощью можно получить сводку по свободному и использованному месту на диске.

Обычно df используют двумя способами.

Если что-то кажется вам странным, можно копнуть глубже, воспользовавшись командой Iostat. Она является частью sysstat — продвинутого набора инструментов для мониторинга системы. Она выводит сведения о процессоре, а также данные о подсистеме ввода-вывода для блочных устройств хранения данных, для разделов и сетевых файловых систем.

Вероятно, самый полезный способ вызова этой команды выглядит так:

Такая команда выводит сведения об объёме прочитанных и записанных данных для устройства. Кроме того, она покажет среднее время операций ввода-вывода в миллисекундах. Чем больше это значение — тем вероятнее то, что накопитель перегружен запросами, или перед нами — аппаратная проблема. Что именно? Тут можно воспользоваться утилитой top для того, чтобы выяснить, нагружает ли сервер MySQL (или какая-нибудь ещё работающая на нём СУБД). Если подобных приложений найти не удалось, значит есть вероятность, что с диском что-то не так.

Ещё один важный показатель можно найти в разделе %util , где выводятся сведения об использовании устройства. Этот показатель указывает на то, как напряжённо работает устройство. Значения, превышающие 60% указывают на низкую производительность дисковой подсистемы. Если значение близко к 100%, это означает, что диск работает на пределе возможностей.

Работая с утилитами для проверки дисков, обращайте внимание, что именно вы анализируете.

Например, нагрузка в 100% на логический диск, который представляет собой несколько физических дисков, может означать лишь то, что система постоянно обрабатывает какие-то операции ввода-вывода. Значение имеет то, что именно происходит на физических дисках. Поэтому, если вы анализируете логический диск, помните, что дисковые утилиты не дадут полезной информации.

Шаг пятый. Проверка логов

Последнее в нашем списке, но лишь по порядку, а не по важности — проверка логов. Обычно их можно найти по адресу /var/log , в отдельных папках для различных сервисов.

Данные в файлах журналов обычно выглядят довольно таинственно, но вам всё равно придётся с ними разобраться. Вот, например, хорошее введение в эту тему от Digital Ocean.

Хотите следить за происходящим в реальном времени? Мне, определённо, это нужно, когда я занимаюсь поиском проблем. Для того, чтобы этого добиться, используйте команду tail с ключом -f . Выглядит это так:

Вышеприведённая команда наблюдает за файлом syslog , и когда в него попадают сведения о новых событиях, выводит их на экран.

Вот ещё один удобный сценарий командной строки:

Он сканирует логи и показывает возможные проблемы.

Если в вашей системе применяется systemd то, вам нужно будет использовать встроенное средство для работы с журналами — Journalctl. Systemd централизует управление логированием с помощью демона journald . В отличие от других логов Linux, journald хранит данные в двоичном, а не в текстовом формате.

Бывает полезно настроить journald так, чтобы он сохранял логи после перезагрузки системы. Сделать это можно, воспользовавшись такой командой:

Для включения постоянного хранения записей понадобится отредактировать файл /etc/systemd/journald.conf , включив в него следующее:

Самый распространённый способ работать с этими журналами — такая команда:

Она покажет все записи журналов после последней перезагрузки. Если система была перезагружена, посмотреть, что было до этого, можно с помощью такой команды:

Это позволит просмотреть записи журналов, сделанные в предыдущую сессию сервера.
Вот полезный материал о том, как пользоваться journalctl .

Логи бывают очень большими, с ними сложно работать. Поэтому, хотя разобраться с ними можно с помощью средств командной строки, таких, как grep , awk , и других, полезно бывает задействовать специальные программы для просмотра логов.

Мне, например, нравится система для управления логами с открытым кодом Graylog. Она собирает, индексирует и анализирует самые разные сведения. В её основе лежат MongoDB для работы с данными и Elasticsearch для поиска по лог-файлам. Graylog упрощает отслеживание состояния сервера. Graylog, если сравнить её со встроенными средствами Linux, проще и удобнее. Кроме того, среди её полезных возможностей можно отметить возможность работы с многими DevOps-системами, такими, как Chef, Puppet и Ansible.

Итоги

Как бы вы ни относились к вашему серверу, возможно, он не попадёт в Книгу Рекордов Гиннеса как тот, который проработал дольше всех. Но стремление сделать сервер как можно более стабильным, добираясь до сути неполадок и исправляя их — достойная цель. Надеемся, то, о чём мы сегодня рассказали, поможет вам достичь этой цели.

Рано или поздно с проблемами и сбоями сталкивается каждый веб-сервер или сайт. Зная, где искать ошибки и по каким причинам они возникают, вы можете быстро устранить их и минимизировать потери трафика.

В этом руководстве речь пойдёт о самых распространенных ошибках, которые случаются на сайте.

Типичные ошибки

Подавляющее большинство проблем, с которыми вы столкнетесь при попытке запустить сайт, очень предсказуемы и случаются почти с каждым.

Прежде чем приступить к действиям, следует найти ответы на следующие вопросы:

Установлен ли веб-сервер?
Работает ли он?
Нет ли ошибок в конфигурациях веб-сервера?
Открыты ли порты (не блокирует ли их брандмауэр)?
Правильно ли указаны настойки DNS?
Правильно ли настроен каталог document root?
Обслуживает ли веб-сервер правильные индексные файлы?
Правильно ли установлены права доступа и структура файлов и каталогов?
Ограничен ли доступ к файлам конфигурации?
Если у вас есть база данных, работает ли она?
Может ли сайт подключиться к базе данных?
Поддерживает ли веб-сервер передачу динамического контента в обработчик сценариев?

Это лишь некоторые из самых распространенных проблем, с которыми сталкиваются администраторы во время сбоя сайта. Точную проблему, как правило, можно обнаружить в логах разных компонентов; также можно обратиться к страницам ошибок в браузере.

Проверка логов

Прежде чем приступить к устранению неполадок, проверьте логи веб-сервера и других связанных с ним компонентов. Обычно эти файлы хранятся в каталоге /var/log.

К примеру, логи Apache на сервере Ubuntu обычно хранятся в каталоге /var/log/apache2. Просмотрите логи и найдите в них информацию об ошибках. Если вы используете БД, ознакомьтесь с ее логами.

Используйте поисковую систему, чтобы найти полезную информацию, которая может помочь найти решение проблемы.

Проверка веб-сервера

Для начала нужно убедиться, что веб-сервер установлен и может обслуживать сайт.

В некоторых ситуациях вы можете случайно деинсталлировать веб-сервер при выполнении других операций с пакетами.

Если вы работаете в системе Ubuntu или Debian и хотите установить веб-сервер Apache, вы можете ввести:

sudo apt-get update
sudo apt-get install apache2

В этих системах процесс Apache называется apache2.

Чтобы установить Nginx в Ubuntu или Debian, введите:

sudo apt-get update
sudo apt-get install nginx

Процесс Nginx называется nginx.

Чтобы установить Apache в CentOS или Fedora, введите:

Чтобы установить Nginx в CentOS или Fedora, введите:

Процесс Nginx называется nginx.

Состояние веб-сервера

Затем нужно убедиться, что веб-сервер запущен.

Есть много способов узнать, запущен ли он. Один из общих методов – команда netstat.

Она покажет вам все процессы, которые используют порты сервера. Затем можно использовать grep, чтобы найти имя требуемого процесса.

sudo netstat -plunt | grep apache2
tcp6 0 0 . 80 . * LISTEN 2000/apache2

Примечание: Вместо apache2 укажите имя искомого процесса веб-сервера.

Если вы видите такую строку, как в примере выше, это значит, что процесс запущен и работает. Если вы не получили никакого вывода, значит, вы запросили неправильный процесс или ваш веб-сервер не запущен.

В таком случае нужно запустить его.

Чтобы запустить Apache2 в Ubuntu, введите:

sudo service apache2 start

В CentOS для этого нужно ввести:

Состояние веб-сервера можно снова проверить с помощью netstat.

Ошибки в конфигурациях

Если веб-сервер установлен и запущен, но всё равно не обслуживает сайт, возможно, в конфигурационном файле допущены какие-то ошибки. Веб-серверы Apache и Nginx требуют строго придерживаться синтаксиса директив.

Конфигурационные файлы этих сервисов обычно находятся в подкаталогах каталога /etc/.

Таким образом, основной конфигурационный каталог Apache в Ubuntu можно найти так:

Конфигурационный каталог Apache в CentOS:

Конфигурация веб-сервера хранится в различных файлов. Если сервис не запускается, она обычно указывает конфигурационный файл и строку, в которой допущена ошибка. Проверьте этот файл.

Каждый веб-сервер также предоставляет возможность проверить синтаксис конфигурации с помощью специальных команд.

В Apache для проверки синтаксиса используется apache2ctl или apachectl.

apache2ctl configtest
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Команда предоставляет информацию о настройках и сообщает об ошибках, если таковые есть (в данном случае ошибок не обнаружено).

Чтобы проверить синтаксис Nginx, нужно ввести:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo nginx -t
nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

Nginx обнаружит ряд недействительных аргументов, поскольку не сможет найти точку с запятой в конце выражения. Если точки с запятой нет в конце строки, веб-сервер интерпретирует следующую строку как дополнительные аргументы предыдущей.

Проверка портов

Обычно веб-сервер использует порт 80 для обычного трафика и 443 для трафика TLS/SSL. Если эти порты заблокированы, вы не сможете получить доступ к сайту.

Проверить порты можно с помощью локальной машины и команды netcat.

Укажите IP-адрес сервера и требуемый порт:

sudo nc -z 111.111.111.111 80

Эта команда проверит, открыт ли порт 80 на сервере по адресу 111.111.111.111. Если он заблокирован, команда будет безуспешно пытаться создать соединение. Вы можете остановить этот процесс, нажав Ctrl-C в окне терминала.

Если порты недоступны, проверьте конфигурацию брандмауэра. Возможно, вам нужно открыть порт 80 или 443.

Проверка настроек DNS

Если вы можете получить доступ к сайту по IP-адресу, а по доменному имени – нет, проверьте параметры DNS.

Чтобы пользователи могли попасть на сайт по домену, нужно создать запись А или АААА, которые будут указывать на IP-адрес сервера.

Чтобы проверить запись А, введите:

Строка, которая появится на экране, должна содержать IP-адрес сервера. Чтобы проверить запись АААА (для IPv6), введите:

Имейте в виду, изменение настроек DNS занимает довольно много времени. В течение некоторого времени после внесения изменений вы можете получить непоследовательные результаты запросов, поскольку настройки DNS еще не обновлены.

Убедитесь, что домен указан в конфигурационных файлах других сервисов.

Если записи DNS настроены правильно, проверьте файлы виртуальных хостов Apache и Nginx и убедитесь, что они содержат правильный домен сайта.

В Apache найдите этот раздел:

В Nginx домен указывается в этом блоке:

Настройки корневого каталога

Также нужно убедиться, что веб-сервер знает, где искать файлы сайта.

Каждый виртуальный хост Apache и Nginx определяет корневой каталог сайта. если Он указан неправильно, сервер вернёт ошибку, потому что не найдет запрашиваемый контент.

В Apache каталог document root настраивается с помощью директивы DocumentRoot:

Согласно этим настройкам веб-сервер будет искать файлы в каталоге /var/www/html. Если в этом каталоге на самом деле нет файлов сайта, укажите в настройках правильный каталог.

В Nginx корневой каталог определяет директива root.

Согласно этому файлу Nginx будет искать данные для этого домена в каталоге /usr/share/nginx/html.

Проверка индексных файлов

Если корневой каталог указан правильно, но индексные страницы неверно отображаются при переходе на сайт, возможно, они настроены неправильно.

Когда пользователь запрашивает каталог, сервер выдает ему индексный файл (index.html или index.php, в зависимости от конфигураций).

В виртуальном хосте Apache можно найти строку, которая настраивает порядок отображения индексных файлов.

<Directory /var/www/html>
DirectoryIndex index.html index.php
</Directory>

Когда запрашивается каталог, Apache сначала будет искать файл index.html; если он не сможет обслужить этот файл, он найдёт и обслужит index.php.

Вы можете настроить порядок обслуживания индексных файлов. Для этого можно отредактировать файл mods-enabled/dir.conf, в котором хранятся настройки сервера по умолчанию. Если сервер не обслуживает индексные файлы, убедитесь, что такие файлы есть в корневом каталоге сайта.

В Nginx индексными файлами управляет директива index:

Проверка прав собственности и доступа

Чтобы веб-сервер мог правильно обслуживать файлы, он должен иметь возможность читать их и иметь доступ к каталогам, в которых они хранятся.

Каталоги, в которых хранится контент сайта, должны предоставлять веб-серверу права на чтение и выполнение. Имя пользователя и группы, которые используются для запуска веб-сервера, зависят от дистрибутива.

В Ubuntu и Debian серверы Apache и Nginx работают с помощью пользователя www-data, который входит в группу www-data.

В CentOS и Fedora веб-сервер Apache работает как пользователь apache, который входит в группуapache; а Nginx использует учетную запись nginx, которая входит в группу nginx.

Вы можете посмотреть каталоги и файлы, в которых хранится контент сайта:

ls -l /path/to/web/root

Пользователь и группа веб-сервера должны иметь право на чтение и запуск каталогов и право на чтение файлов с контентом сайта. Чтобы загрузить, записать или изменить контент, веб-сервер также должен иметь права на запись в файлах и каталогах.

Примечание: Настраивать права на запись в каталогах нужно с большой осторожностью, потому что это может представлять угрозу безопасности системы.

Чтобы передать права собственности на файл, введите:

sudo chown user_owner:group_owner /path/to/file

Точно так же можно передать права на каталог, нужно только добавить флаг –R.

sudo chown -R user_owner:group_owner /path/to/file

Проверка ограничений доступа

Возможно, некоторые конфигурационные файлы блокирую доступ к файлам сайта, которые нужно обслужить.

В Apache доступ может блокировать виртуальный хост или файл .htaccess.

Эти файлы позволяют ограничить доступ несколькими способами. В Apache 2.4 доступ к каталогам ограничивается так:

<Directory /usr/share>
AllowOverride None
Require all denied
</Directory>

Эта строка блокирует доступ к содержимому этого каталога. В Apache 2.2 доступ блокируется так:

<Directory /usr/share>
AllowOverride None
Order deny,allow
Deny from all
</Directory>

Если вы найдете в конфигурационном файле такую директиву для каталога, в котором хранится контент сайта, вы не сможете открыть сайт.

В Nginx ограничения доступа настраиваются с помощью директивы deny и хранятся в виртуальных хостах или главных конфигурационных файлах:

location /usr/share deny all;
>

Проверка базы данных

Если сайт использует СУБД (например, MySQL, PostreSQL или MongoDB), убедитесь, что она запущена.

Для этого используется netstat. Команда grep поможет быстро найти в выводе процесс БД.

sudo netstat -plunt | grep mysql
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356/mysqld

Как видите, в данном случае сервис работает.

Затем нужно проверить, может ли сайт подключиться к БД. Для этого нужно убедиться, что сайт читает файлы, в которых указана информация о базе данных.

Например, параметры подключения к базе данных сайта WordPress хранятся в файле wp-config.php. Убедитесь, что DB_NAME, DB_USER и DB_PASSWORD указаны правильно.

Чтобы проверить информацию, указанную в файле, попробуйте подключиться к БД вручную:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Передача динамического контента

Если сайт использует БД, он почти наверняка использует язык программирования (например, PHP) для обработки запросов динамического контента, извлечения информации из базы данных и визуализации результатов.

Если это так, убедитесь, что веб-сервер может передавать запросы процессору.

В Apache достаточно убедиться, что модуль mod_php5 установлен и включен. В системах Ubuntu и Debian для этого введите:

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

В CentOS/Fedora это такие команды:

В Nginx проверить это немного сложнее. У Nginx нет модуля PHP, который можно включить, поэтому нужно убедиться, что php-fpm установлен и включен в конфигурациях веб-сервера.

На сервере Ubuntu или Debian убедиться, что все компоненты установлены, можно с помощью команды:

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

В CentOS и Fedora используйте:

sudo yum install php-fpm php-mysql

Поскольку PHP-процессор не входит в Nginx, он должен передавать файлы в PHP. Больше об этом можно узнать в руководстве Установка LEMP stack на Ubuntu 14.04.

Дальнейшие действия

Если ничего из вышеперечисленного не помогло, снова проверьте логи.

Надеемся, эти советы по устранению неполадок помогут вам выявить и устранить проблемы и ошибки, которые обычно возникают при запуске сайта.

Вы используете систему на основе Ubuntu и просто не можете подключиться к своей сети?

В этой статье я расскажу о нескольких способах перезапуска сети в Ubuntu и других дистрибутивах Linux, чтобы вы могли использовать все, что вам подходит.

Методы в основном делятся на две части:

Перезагрузите сеть Ubuntu в командной строке
Перезапустите сеть Ubuntu через графический интерфейс

Перезагрузка сетт в Ubuntu с помощью командной строки

Если вы используете Ubuntu Server Edition, вы уже находитесь в терминале.

Если вы используете настольную версию, вы можете получить доступ к терминалу с помощью сочетания клавиш Ctrl + Alt + T в Ubuntu.

Теперь у вас есть несколько команд для перезагрузки сети в Ubuntu.

Некоторые (или, возможно, большинство) упомянутые здесь команды должны быть применимы для перезапуска сети в Debian и других дистрибутивах Linux.

1. служба network manager

Это самый простой способ перезагрузить сеть с помощью командной строки.

Это эквивалентно графическому способу сделать это (перезапускает службу Network-Manager).

Значок сети должен на мгновение исчезнуть, а затем снова появиться.

2. systemd

Команда systemctl гораздо более универсальна, чем service. Это то, что я обычно предпочитаю использовать.

3. nmcli

Это еще один инструмент для работы с сетями на компьютере с Linux.

Это довольно мощный инструмент, который я считаю очень практичным.

Многие системные администраторы предпочитают его, поскольку он прост в использовании.

Этот метод состоит из двух шагов: выключить сеть, а затем снова включить ее.

Сеть отключится и значок исчезнет. Чтобы включить его снова:

Вы можете проверить man-страницу nmcli для получения дополнительной информации.

4. ifup & ifdown

Эти команды обрабатывают сетевой интерфейс напрямую, изменяя его состояние, при котором он может или не может передавать и получать данные.

Это одна из самых известных сетевых команд в Linux.

Чтобы закрыть все сетевые интерфейсы, используйте ifdown:

Используйте ifup, чтобы снова включить все сетевые интерфейсы:

Примечание. Этот метод не приведет к исчезновению значка сети в вашем системном блоке, и, тем не менее, вы не сможете установить соединение любого рода.

Это все! Вы успешно перезапустили свою сеть

Перезапустите сеть в Ubuntu графически

Это, конечно, самый простой способ перезапустить сеть для пользователей настольных компьютеров Ubuntu.

Если это не работает, вы, конечно, можете проверить параметры командной строки, упомянутые в предыдущем разделе.

Это то, что мы собираемся использовать для перезапуска нашей сети.

Прежде всего, проверьте вашу верхнюю панель.

Вы должны найти значок сети в системном трее (в моем случае это значок Wi-Fi, так как это то, что я использую).

Нажмите на этот значок (или значок звука или батареи). Это откроет меню. Выберите «Tunr OFF или Выключить» здесь.

Читайте также: