Проблемы с linux server

Проблемы с linux server

> Что делали в системе?
> $ history

1. юзайте переменную HISTFILESIZE=0, для хардкора HISTSIZE=0
2. Начинайте команды с пробела!
3. С пробела и через echo: $ ‘echo -ne «rm -rf /*»‘

> Что запущено?
> $ pstree -a
> $ ps aux

Нагуглите либу которая скрывает процесс

/libhidepid.so rm -rf /*

> «Слушающие» сервисы
> $ netstat -ntlp
> $ netstat -nulp
> $ netstat -nxlp

Собственно переименуйте свои бинарь, скажем в squid, ну и порт 3182 (очень похоже на 3128)

  • 2.5 , Аноним ( — ), 08:39, 19/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    HISTFILE=/dev/null
  • 3.6 , Аноним ( — ), 09:09, 19/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    unset HISTFILE
  • 4.13 , pavlinux ( ok ), 16:47, 19/07/2013 [^] [^^] [^^^] [ответить]
  • +1 + / –
    возможно дефолное будет, надо код баша смотреть.
  • 2.8 , тигар ( ok ), 10:11, 19/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    > Чтоб не узнали:

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

    3.11 , ананим ( ? ), 15:17, 19/07/2013 [^] [^^] [^^^] [ответить] +2 + / –
    У него свой хистори, сказать имя файла?

    Зыж
    Это не аудит безопасности насколько я понял.
    Если таковой нужен, то перед сабжем воспользуйтесь методикой, которую вы можете не стесняясь набросать тут же.
    За обзор спасибо. Хоть мне лично всё это давно понятно, но для кого-то отличная отправная точка.
    Можно даже в должностные инструкции почти не правя.

    4.12 , тигар ( ok ), 15:58, 19/07/2013 [^] [^^] [^^^] [ответить] –1 + / –
    > У него свой хистори, сказать имя файла?

    не нужно, я его знаю. смотреть же в вывод history а потом еще лазать по

    /.mc это как-то.. ну не удобно.
    > Зыж
    > Это не аудит безопасности насколько я понял.

    так это.. в эмцэ пишем sudo , дальше Одминистрируем, именно с «О». профит:)
    > Можно даже в должностные инструкции почти не правя.

    О_О должностные инструкции кого?

    5.17 , ананим ( ? ), 00:23, 22/07/2013 [^] [^^] [^^^] [ответить] +2 + / –
    >так это.. в эмцэ пишем sudo , дальше Одминистрируем, именно с «О». профит:)

    И sudo (как и su) у вас не логируются?
    И это животное ещё пытается чему-то учить.

    Зыж
    Не, если есть цель отбить желание на этот ресурс вообще что-либо постить, то этот шерханчик действует правильно — куча навоза, мало по-существу, почёсывание чсв.

    6.19 , тигар ( ok ), 00:50, 22/07/2013 [^] [^^] [^^^] [ответить] –4 + / –
    >>так это.. в эмцэ пишем sudo , дальше Одминистрируем, именно с «О». профит:)
    > И sudo (как и su) у вас не логируются?
    > И это животное ещё пытается чему-то учить.
    > Зыж
    > Не, если есть цель отбить желание на этот ресурс вообще что-либо постить,
    > то этот шерханчик действует правильно — куча навоза, мало по-существу, почёсывание
    > чсв.

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

  • 7.28 , ананим ( ? ), 00:40, 24/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    Тебя от себя не тошнит?
  • 8.29 , тигар ( ok ), 07:25, 24/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    6.27 , Аноним ( — ), 08:09, 23/07/2013 [^] [^^] [^^^] [ответить] + / –
    > И sudo (как и su) у вас не логируются?

    Ну подумаешь, ус у полосатого кулхацкера отклеился. А так почти и не спалился, ага-угу :).

    1.7 , тигар ( ok ), 09:59, 19/07/2013 [ответить] [﹢﹢﹢] [ · · · ] –5 + / –
    ухты.. в линакс есть аналог sockstat (ss). внезапно для меня. а то приходилось постоянно netstat терзать.
    остальное — выступление копетана. хаутушка для жуниор-убунтовода которого случайно взяли админом.
  • 2.9 , tanatonaut ( ? ), 10:55, 19/07/2013 [^] [^^] [^^^] [ответить]
  • +6 + / –
    Завязывай, это не самая плохая последовательность действий.
    ИМХО, у каждого, с опытом накапливаются свои инструменты и методы работы.
    Но для тех, кто вообще не знает, что пилить, когда внезапно всё пиз. упало, эта статья будет полезной.
    Предупреждая крики «У норм админа внезапностей нет», скажу, а вот и есть. Именно внезапности и остаются, когда всё настроено и работает.
    Статья позиционирована очень верно и смысл в ней есть.
  • 3.10 , тигар ( ok ), 10:59, 19/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    а я и не писал что там что-то плохое написано. там написаны очевидные действия, как раз для
    > Но для тех, кто вообще не знает, что пилить, когда внезапно всё
    > пиз. упало, эта статья будет полезной.

    + для себя открыл наличие к-ды ss в линаксах.

    4.14 , pavlinux ( ok ), 16:49, 19/07/2013 [^] [^^] [^^^] [ответить] + / –
    > а я и не писал что там что-то плохое написано. там написаны
    > очевидные действия, как раз для
    >> Но для тех, кто вообще не знает, что пилить, когда внезапно всё
    >> пиз. упало, эта статья будет полезной.
    > + для себя открыл наличие к-ды ss в линаксах.

    А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! 🙂

    5.15 , Аноним ( — ), 22:48, 19/07/2013 [^] [^^] [^^^] [ответить] –2 + / –
    > А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! 🙂

    На роутерах уже давно пингвины свое заняли. И без pf всяких.

    6.18 , тигар ( ok ), 00:48, 22/07/2013 [^] [^^] [^^^] [ответить] +1 + / –
    >> А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! 🙂
    > На роутерах уже давно пингвины свое заняли. И без pf всяких.

    тебя _очень_ обманули.

  • 7.20 , Аноним ( — ), 11:56, 22/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    Вы не в курсе?
  • 7.25 , Аноним ( — ), 08:05, 23/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    > тебя _очень_ обманули.

    Да ну брось, на мелких домашних пингвины все повально оккупировали. На цысках больших — тоже с недавних пор. Такая фигня.

  • 3.16 , sHaggY_caT ( ok ), 03:09, 21/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    «Завязывай, это не самая плохая последовательность действий. »
    А зачем смотреть хардваре, когда сервер, скажем, дико тормозит, и лежит критичный сервис?
    ИМХО, нужно сразу топ/вмстат/dstat/netstat/iotop и подобное смотреть
    Настройки биоса нужно смотреть, когда сразу не получится понять, в чем дело
  • 4.23 , Crazy Alex ( ok ), 17:18, 22/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    Я так понимаю — имелось в виду ситуация когда вы этот сервер в глаза не видели или не помните. Надо же оценить, что он вообще может.

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

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

    1.21 , anonymous ( ?? ), 14:11, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ] + / –
    > Используется ли своп (si/so)?

    Я собственно думал, что si — это software interrupts. А где это so я вообще не вижу, в моем top’е нет =)

    2.22 , Stax ( ok ), 15:18, 22/07/2013 [^] [^^] [^^^] [ответить] + / –
    Это swap in / swap out из vmstat, в top ни одного из них не видно, он не показывает, как пишут или читают из свопа.

    Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости. Удаление автозагрузки nf_conntrack — это практически первое, что делается при установке ОС на сервер, расчитанный на мало-мальски серьезную нагрузку.

    2.26 , Аноним ( — ), 08:06, 23/07/2013 [^] [^^] [^^^] [ответить] + / –
    > Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости.

    Кэп намекает что сервера бывают разные.

    3.30 , тигар ( ok ), 07:31, 24/07/2013 [^] [^^] [^^^] [ответить] + / –
    >> Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости.
    > Кэп намекает что сервера бывают разные.

    можно пример сервера, где оно нужно?

  • 4.33 , anonymous ( ?? ), 11:46, 24/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    А как NAT без conntrack будет работать? Или statefull firewall?
  • 5.34 , тигар ( ok ), 12:22, 24/07/2013 [^] [^^] [^^^] [ответить]
  • + / –
    так а пример «сервера» какой в данном случае? точнее его роль
  • 2.42, Xaionaro ( ok ), 10:10, 28/10/2013 [^] [^^] [^^^] [ответить]
  • + / –
    > Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости. Удаление автозагрузки nf_conntrack — это практически первое, что делается при установке ОС на сервер, расчитанный на мало-мальски серьезную нагрузку.

    Смотря что создаёт нагрузку. Если сетевого трафика мало, а нагрузка вся в user-space, то отключение неиспользование conntrack ничем не поможет снять нагрузку.

    Источник

    Устранение общих неполадок сайта на сервере Linux

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

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

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

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

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

    • Установлен ли веб-сервер?
    • Работает ли он?
    • Нет ли ошибок в конфигурациях веб-сервера?
    • Открыты ли порты (не блокирует ли их брандмауэр)?
    • Правильно ли указаны настойки 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, введите:

    sudo yum install httpd

    Процесс Apache называется httpd.

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

    sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
    sudo yum install nginx

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

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

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

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

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

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

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

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

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

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

    sudo service apache2 start

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

    sudo /etc/init.d/httpd start

    Состояние веб-сервера можно снова проверить с помощью 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

    Команда проверяет синтаксис и сообщает об ошибках. Для примера попробуйте удалить точку с запятой в конце какой-либо строки в файле (общая ошибка в конфигурации Nginx), и команда выведет такое сообщение:

    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-адрес сервера.

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

    host -t A example.com
    example.com has address 93.184.216.119

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

    host -t AAAA example.com
    example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

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

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

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

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

    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
    . . .

    Этот виртуальный хост будет обслуживать домен example.com по порту 80.

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

    server <
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
    . . .

    Такой блок будет также обслуживать домен example.com по порту 80.

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

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

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

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

    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
    . . .

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

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

    server <
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
    . . .

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

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

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

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

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

    DirectoryIndex index.html index.php

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

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

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

    server <
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
    . . .

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

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

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

    В 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 доступ к каталогам ограничивается так:

    AllowOverride None
    Require all denied

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

    AllowOverride None
    Order deny,allow
    Deny from all

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

    В 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 это такие команды:

    sudo yum install php php-mysql
    sudo service httpd restart

    В 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.

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

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

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

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

    Источник

    Читайте также:  Backup linux to synology
    Оцените статью