Архив метки: Настройка Debian

Установка и настройка Nginx на Debian 9

Nginx является свободный высоко-производительный HTTP-сервер с открытым исходным кодом. Он широко используется для балансировки нагрузки, почтовый прокси-сервер, общий TCP/UDP прокси-сервер, он предоставляет конфигурацию обратного прокси-сервера, потокового мультимедиа и многого другого. Он предназначен для эффективного обслуживания от низкого до высокого трафика веб-сайтов, и он является очень популярной альтернативой веб-сервера Apache. Nginx приводит в движение много нагруженных сайтов, таких как Яндекс, DropBox, Netflix, WordPress.

В этой статье мы покажем вам, как установить и настроить Nginx на Debian. Установка Nginx на сервере Debian является очень простой задачей, и если вы внимательно следовали всем инструкциям, приведенным ниже, вы должны иметь работоспособный сервер Nginx в течении менее чем 10 минут. Это руководство было написано и протестировано на Debian 9 VPS.



1. Вход с помощью SSH и обновление системы

Прежде чем мы начнем, вам необходимо войти на сервер через SSH с правами суперпользователя:

ssh root@IP_ADDRESS -p PORT_NUMBER

 

и заменить «IP_ADDRESS» и «PORT_NUMBER» на фактический IP-адрес сервера и номером порта SSH.

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

apt-get update && sudo apt-get upgrade

 

Вот пример вывода, который вы должны получить:

Reading package lists... Done

Building dependency tree

Reading state information... Done

Calculating upgrade... Done

The following packages will be upgraded:

libperl5.24 perl perl-base perl-modules-5.24

4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Need to get 7813 kB of archives.

After this operation, 9216 B of additional disk space will be used.

Do you want to continue? [Y/n] Y

Get:1 http://security.debian.org stretch/updates/main amd64 libperl5.24 amd64 5.24.1-3+deb9u3 [3527 kB]

Get:2 http://security.debian.org stretch/updates/main amd64 perl amd64 5.24.1-3+deb9u3 [219 kB]

Get:3 http://security.debian.org stretch/updates/main amd64 perl-base amd64 5.24.1-3+deb9u3 [1344 kB]

Get:4 http://security.debian.org stretch/updates/main amd64 perl-modules-5.24 all 5.24.1-3+deb9u3 [2723 kB]

Fetched 7813 kB in 0s (12.0 MB/s)

(Reading database ... 36668 files and directories currently installed.)

Preparing to unpack .../libperl5.24_5.24.1-3+deb9u3_amd64.deb ...

Unpacking libperl5.24:amd64 (5.24.1-3+deb9u3) over (5.24.1-3+deb9u2) ...

Preparing to unpack .../perl_5.24.1-3+deb9u3_amd64.deb ...

Unpacking perl (5.24.1-3+deb9u3) over (5.24.1-3+deb9u2) ...

Preparing to unpack .../perl-base_5.24.1-3+deb9u3_amd64.deb ...

Unpacking perl-base (5.24.1-3+deb9u3) over (5.24.1-3+deb9u2) ...

Setting up perl-base (5.24.1-3+deb9u3) ...

(Reading database ... 36668 files and directories currently installed.)

Preparing to unpack .../perl-modules-5.24_5.24.1-3+deb9u3_all.deb ...

Unpacking perl-modules-5.24 (5.24.1-3+deb9u3) over (5.24.1-3+deb9u2) ...

Setting up perl-modules-5.24 (5.24.1-3+deb9u3) ...

Setting up libperl5.24:amd64 (5.24.1-3+deb9u3) ...

Setting up perl (5.24.1-3+deb9u3) ...

Processing triggers for libc-bin (2.24-11+deb9u3) ...

Processing triggers for man-db (2.7.6.1-2) ...

2. Установка Nginx на Debian 9

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

apt-get install nginx

 

Вы получите следующий результат:

Reading package lists... Done

Building dependency tree

Reading state information... Done

The following additional packages will be installed:

libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter

libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream nginx-common nginx-full

Suggested packages:

fcgiwrap nginx-doc

The following NEW packages will be installed:

libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter

libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream nginx nginx-common nginx-full

0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.

Need to get 0 B/1585 kB of archives.

After this operation, 2865 kB of additional disk space will be used.

Do you want to continue? [Y/n] y

 

После завершения установки Nginx запускаться автоматически.

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

systemctl status nginx

● nginx.service - A high performance web server and a reverse proxy server

Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2018-04-14 11:44:12 CDT; 4min 10s ago

Docs: man:nginx(8)

Process: 6412 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)

Process: 6409 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)

Main PID: 6413 (nginx)

CGroup: /system.slice/nginx.service

├─6413 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;

├─6414 nginx: worker process

└─6415 nginx: worker process

3. Управление сервером Nginx

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

Во-первых, давайте удостоверимся, что ваш сервер Nginx запускается автоматически после перезагрузки сервера:

systemctl enable nginx

Synchronizing state of nginx.service with SysV service script with /lib/systemd/systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install enable nginx

 

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

systemctl disable nginx

 

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

systemctl status nginx

 

Чтобы запустить службу Nginx, вы можете использовать:

systemctl start nginx

 

Чтобы остановить службу Nginx, вы можете использовать:

systemctl stop nginx

 

Вы можете перезапустить службу Nginx с командой:

systemctl restart nginx

4. Настройка веб-сервера Nginx

По умолчанию, установка Nginx создает корневой каталог веб — сервера по следующему адресу /var/www/html/.

Файл конфигурации по умолчанию для этого находится в следующем месте: /etc/nginx/sites-enabled/default/.

Основной файл конфигурации Nginx расположен в /etc/nginx/nginx.conf

В этой статье мы покажем вам, как создать новый блок сервера для нового домена mydomain.ru и установить его корень документа в /var/www/mydomain.ru

Во-первых, нам нужно будет создать корневой каталог документов с помощью следующей команды:

mkdir -p /var/www/mydomain.ru

 

Затем создайте файл index.html внутри этого каталога и добавmnt следующее содержание:

nano /var/www/mydomain.ru/index.html

<!DOCTYPE html>

<html>

<head>

 <title>mydomain.ru</title>

</head>

<body>

 <h1>Добро пожаловать на mydomain.ru</h1>

 <p>Это тестовый блок сервера mydomain.ru.</p>

</body>

</html>

 

Далее, давайте создадим новый блок сервера по следующему адресу:

nano /etc/nginx/sites-available/mydomain.ru.conf

 

И добавьте следующее содержание:

server {

       listen 80;

       listen [::]:80;



       server_name mydomain.ru www.mydomain.ru;



       root /var/www/mydomain.ru;

       index index.html;



       location / {

               try_files $uri $uri/ =404;

       }

}

 

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

ln -s /etc/nginx/sites-available/mydomain.ru.conf /etc/nginx/sites-enabled/mydomain.ru.conf

5. Проверьте установку Nginx

Проверка конфигурации Nginx и перезагрузка Nginx:

nginx -t

systemctl restart nginx

 

Если все настроено правильно, как указано, то вы должны быть в состоянии открыть MYDOMAIN.RU в вашем браузере и увидеть блок сервера mydomain.ru, который вы создали ранее.

Вот и все. Был успешно установлен и настроен Nginx на сервере Debian 9.

 



2018-04-20T15:43:05
Настройка Debian

Как настроить sources.list на Debian 9

Это краткое руководство о том, как настроить файл sources.list на Debian 9, под кодовым названием stretch. Debian является одним из наиболее популярных дистрибутивов Linux, и большая часть его силы исходит из ядра управления пакетами Debian — apt. Все в Debian, будь то приложение или любой другой компонент — встроен в пакет, а затем этот пакет установлен на вашей системе (либо с помощью установщика или вами).

Понимание apt и sources.list

Менеджер пакетов для Debian и его инструмент .apt, который переводиться как Advanced Package Tool и представляет собой набор инструментов для управления пакетами Debian, и поэтому приложения, установленные в вашей системе Debian .apt позволяет:

  • Установку приложений
  • Удаление приложений
  • Обновление приложений
  • Исправление сломанных пакетов и т.д.

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

Файл /etc/apt/sources.list  в Debian используется Apt как часть своей работы. Этот файл содержит список «sources», из которых могут быть получены пакеты. Записи в этом файле обычно имеет следующий формат.

deb http://site.example.com/debian distribution component1 component2 component3

deb-src http://site.example.com/debian distribution component1 component2 component3

 

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

Тип архива:

Первая запись в каждой строке —   deb или  deb-src  представляет тип архива.

  • deb означает URL, при условии, что содержатся заранее скомпилированные пакеты. Эти пакеты, установленные по умолчанию при использовании менеджеров пакетов, как apt-get или aptitude.
  • deb-src указывают на источники пакетов с файлом управления Debian (.dsc) и diff.gz, содержащий изменения, необходимые для упаковки программы.

Хранилище URL:

Следующая запись в строке является URL в хранилище, куда пакеты будут загружены. Вы можете найти основной список Debian пакетов репозитория из зеркала Debian Worldwide sources.list.

Распределение:

«Распределение» может быть либо код релиза имя/псевдоним (jessie, stretch, buster, sid) или класс релиза (старое стабильное, стабильное, тестирование, нестабильный) соответственно. Если вы имеете в виду отслеживание, то класс выпуска может использовать имя класса, если вы хотите, отслеживать релизов Debian, используйте кодовое имя.

Компонент

Есть правило, три компонента, которые могут быть использованы на Debian, а именно:

  • main — он содержит пакеты, которые являются частью дистрибутива Debian. Эти пакеты DFSG совместимыми.
  • contrib — это пакеты  DFSG совместимые, но содержит пакеты, которые не находятся в главном хранилище.
  • non-free — содержит программные пакеты, которые не соответствуют с DFSG.

Полный файл sources.list на Debian 9 будет выглядеть следующим образом:

deb http://deb.debian.org/debian stretch main

deb-src http://deb.debian.org/debian stretch main



deb http://deb.debian.org/debian stretch-updates main

deb-src http://deb.debian.org/debian stretch-updates main



deb http://security.debian.org/debian-security/ stretch/updates main

deb-src http://security.debian.org/debian-security/ stretch/updates main

 

Затем, чтобы получить contrib и non-free, добавьте contrib non-free после основных, как показано ниже:

deb http://deb.debian.org/debian stretch main contrib non-free

deb-src http://deb.debian.org/debian stretch main contrib non-free



deb http://deb.debian.org/debian stretch-updates main contrib non-free

deb-src http://deb.debian.org/debian stretch-updates main contrib non-free



deb http://security.debian.org/debian-security/ stretch/updates main contrib non-free

deb-src http://security.debian.org/debian-security/ stretch/updates main contrib non-free

 

После того, как вы внесли изменения в файл sources.list, вы должны выполнить команду:

$ sudo apt-get update

 

Это обеспечит синхронизацию apt. Затем вы можете установить новые пакеты из репозитория.

Добавление пользовательских хранилищ

Это не всегда целесообразно, добавлять собственные и сторонние репозитории в файл  /etc/apt/sources.list. Вместо этого вы можете создать файл в директории /etc/apt/sources.list.d. Например, чтобы установить docker на Debian 9 из его вышестоящего хранилища, вы сделаете:

$ sudo vim /etc/apt/sources.list

 

Добавьте следующее:

deb https://apt.dockerproject.org/repo debian-stretch main

 

После этого вы можете продолжить обновление apt-cache и установить пакет Docker из него. Это рекомендуемый способ добавления каких-либо других репозиториев третьих лиц.

Импорт apt ключей

При работе с apt и хранилищем sources.list, в какой-то момент вы должны импортировать ключи GPG. Обычно это делается с помощью команды apt-key, чей синтаксис следующий:

# apt-key adv --keyserver  <server-address>--recv-keys  <key-id>

 

В качестве примера, чтобы загрузить Docker ключи репозитория GPG, вы укажете следующее:

# apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

 

затем

# apt-get update &&  apt-get install docker-engine

 

В общем, работать с файлом sources.list относительно легко. Единственное, что вы должны быть увлечены ставит правильное распределение. Если при стабильной установке вы добавляете репозиторий sid с нестабильными пакетами, вы можете в конечном итоге нарушить вашу систему или столкнуться со многими неразрешенными зависимостями.



2018-02-24T00:56:22
Настройка Debian

Как настроить в Apache виртуальные хосты на Debian 8

Веб-сервер Apache является один из наиболее популярных способов обработке веб-контента в Интернете. На его долю приходится более половины всех активных веб-сайтов в интернете и является чрезвычайно мощным и гибким.

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

При использовании виртуальных хостов, вы можете использовать один сервер для размещения нескольких доменов или сайтов из одного интерфейса или IP с помощью механизма согласования. Настроить запрос на домен, чтобы направить посетителя к конкретному каталогу, содержащего информацию об сайте. Другими словами, вы можете разместить более одного веб-сайта на одном сервере. Эта схема может быть расширена без каких-либо ограничений программного обеспечения до тех пор, пока ваш сервер может справиться с нагрузкой.

На этом уроке мы создадим два виртуальных хоста Apache на сервере Debian 8, с разным содержанием для посетителей на основе домена, которые они посещают.

Предпосылки

Для завершения этого урока вам понадобятся:

В этом руководстве мы создадим виртуальные хосты для example.ru и test.ru, но вы можете заменить на свои собственные домены или значения, следуя далее.

Если вы не имеете в наличии домены, вы можете использовать example.ru и test.ru и следовать Шагу 5 из этого учебника, чтобы настроить файл локальные хосты, чтобы сопоставить эти домены IP — адресу вашего сервера. Это позволит вам проверить вашу конфигурацию с локального компьютера.

Шаг 1 — Создание структуры каталогов

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

Наш корневой документ, каталог верхнего уровня, который указывает на Apache, будут установлены в отдельных каталогах в каталоге /var/www. Мы создадим каталог для каждого из виртуальных хостов, которые мы настроим.

В каждом из этих каталогов, мы создадим папку public_html, которая будет содержать веб — страницы. Это дает нам немного больше гибкости в том, как мы применяем более сложные веб — приложения в будущем; папка public_html будет держать веб — контент и родительская папка, может содержать сценарии или код приложения для поддержки веб — контента.

Создание каталогов с помощью следующих команд:

sudo mkdir -p /var/www/example.ru/public_html



sudo mkdir -p /var/www/test.ru/public_html

 

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

sudo chown -R $USER:$USER /var/www/example.ru/public_html



sudo chown -R $USER:$USER /var/www/test.ru/public_html

 

Переменная $USER использует значение пользователя, при помощи которого вы вошли в систему при нажатии кнопки ENTER. Делая это, наш обычный пользователь в настоящее время владеет подкаталогом public_html, где мы будем хранящие наше содержание.

Мы также должны изменить наши разрешения, чтобы гарантировать, что доступ на чтение разрешен к общему веб — каталогу и все файлы и папки, которые она содержит. Выполните эту команду, чтобы изменить права доступа к папке /var/www и ее подпапок:

sudo chmod -R 755 /var/www

 

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

Мы создали нашу структуру каталогов. Давайте создадим некоторое содержание.

Шаг 2 — Создание страниц по умолчанию для каждого виртуального хоста

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

Давайте начнем с страницы для example.ru. Отредактируем новый файл index.html с помощью следующей команды:

nano /var/www/example.ru/public_html/index.html

 

В этом файле, создадим простой HTML — документ, который указывает на главную страницу, когда посетитель попадает на example.ru:

/var/www/example.ru/public_html/index.html

<html>

  <head>

    <title>Добро пожаловать Example.ru!</title>

  </head>

  <body>

    <h1>успех! Виртуальный хост example.ru работает!</h1>

  </body>

</html>

 

Сохраните и закройте файл, когда вы закончите.

Теперь скопируйте этот файл на сайт test.ru:

cp /var/www/example.ru/public_html/index.html /var/www/test.ru/public_html/index.html

 

Затем откройте файл в редакторе:

nano /var/www/test.ru/public_html/index.html

 

Изменить файл так, чтобы он ссылался на test.ru вместо example.ru:

/var/www/test.ru/public_html/index.html

<html>

  <head>

    <title>Добро пожаловать на Test.ru!</title>

  </head>

  <body> <h1>Успех! Виртуальный хост test.ru работает!</h1>

  </body>

</html>

 

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

Шаг 3 — Создайте новый файл виртуальных хостов

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

Apache поставляется с файлом виртуальных хостов по умолчанию под названием 000-default.conf, которое можно использовать в качестве отправной точки. Скопируйте этот файл для первого домена:

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.ru.conf

 

Примечание : Конфигурация Apache по умолчанию в Debian 8 требует, чтобы каждый файл виртуальных хостов заканчивался расширением .conf.

Откройте новый файл в редакторе:

sudo nano /etc/apache2/sites-available/example.ru.conf

 

Файл будет выглядеть как на следующем примере, с некоторыми дополнительными комментариями:

/etc/apache2/sites-available/example.ru.conf

<VirtualHost *:80>



        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html



        ErrorLog ${APACHE_LOG_DIR}/error.log

        CustomLog ${APACHE_LOG_DIR}/access.log combined



</VirtualHost>

 

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

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

/etc/apache2/sites-available/example.ru.conf

ServerAdmin admin@example.ru

 

Далее, нам необходимо добавить две новые директивы. Первая из них , называется ServerName, устанавливает базовый домен для данного виртуального хоста. Вторая называется ServerAlias, определяет дальнейшие имена, которые должны соответствовать, как если бы они были базовым именем. Это полезно для сопоставления дополнительных узлов, которые вы определили, так как example.ru и www.example.ru оба работают, при условии, если оба этих хоста указывают на IP — адрес этого сервера.

Добавьте эти две директивы в файл конфигурации, сразу после строки ServerAdmin:

/etc/apache2/sites-available/example.ru.conf

<VirtualHost *:80>



        ServerAdmin webmaster@localhost

        ServerName example.ru

        ServerAlias www.example.ru

        DocumentRoot /var/www/html

...

 

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

DocumentRoot /var/www/example.ru/public_html

 

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

/etc/apache2/sites-available/example.ru.conf

<VirtualHost *:80>

        ServerAdmin admin@example.ru

        ServerName example.ru

        ServerAlias www.example.ru

        DocumentRoot /var/www/example.ru/public_html

        ErrorLog ${APACHE_LOG_DIR}/error.log

        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

 

Сохраните и закройте файл.

Затем создайте второй файл конфигурации, создав копию этого файла:

sudo cp /etc/apache2/sites-available/example.ru.conf /etc/apache2/sites-available/test.ru.conf

 

Откройте новый файл в редакторе:

sudo nano /etc/apache2/sites-available/test.ru.conf

 

Затем измените соответствующие настройки для ссылки на свой второй домен. Когда вы закончите, ваш файл будет выглядеть следующим образом:

/etc/apache2/sites-available/test.ru.conf

<VirtualHost *:80>

    ServerAdmin admin@test.ru

    ServerName test.ru

    ServerAlias www.test.ru

    DocumentRoot /var/www/test.ru/public_html

    ErrorLog ${APACHE_LOG_DIR}/error.log

    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

 

Сохраните и закройте файл.

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

Шаг 4 — Включение новых файлов виртуальных хостов

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

Активируйте первый сайт:

sudo a2ensite example.ru.conf

 

Вы увидите следующий вывод, если не было никаких ошибок синтаксиса или опечатки в вашем файле:

Вывод

Enabling site example.ru.

To activate the new configuration, you need to run:

  service apache2 reload

 

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

sudo a2ensite test.ru.conf

 

Вы увидите подобное сообщение, указывающее, что сайт был включен:

Вывод

Enabling site test.ru.

To activate the new configuration, you need to run:

  service apache2 reload

 

Затем отключите узел по умолчанию, определенный в 000-default.conf с помощью команды a2dissite:

sudo a2dissite 000-default.conf

 

Теперь перезапустите Apache:

sudo systemctl restart apache2

 

Сайты теперь настроены. Давайте проверим их. Если вы используете реальные домены, настроенные, указывающие на IP-адрес вашего сервера, вы можете пропустить следующий шаг. Но если ваши домены еще не настроены, или если вы просто сделали тестирование, читайте дальше, чтобы узнать, как проверить нашу установку с помощью локального компьютера.

Шаг 5 — Настройка локального файла Hosts (Необязательно)

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

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

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

Если вы на компьютере Mac или Linux, редактировать локальный файл с правами администратора, набрав:

sudo nano /etc/hosts

 

Если вы на Windows, откройте командную строку с правами администратора и введите:

notepad %windir%system32driversetchosts

 

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

/etc/hosts

127.0.0.1   localhost

...



111.111.111.111 example.ru

111.111.111.111 test.ru

 

Это позволит направлять любые запросы на example.ru и test.ru на вашем компьютере и отправить их на сервер в 111.111.111.111.

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

Шаг 6 — тестирование ваших результатов

Теперь, когда у вас настроены ваши виртуальные хосты, вы можете протестировать установку легко, перейдя в домены, настроенные в веб — браузере. Посетите первый сайт по адресу http://example.ru и вы увидите страницу, которая выглядит следующим образом :

Успех! Виртуальный хост example.ru работает!

Точно так же, если вы посетите ваш второй хост по адресу http://test.ru, вы увидите файл, который вы создали для своего второго сайта:

Успех! Виртуальный хост test.ru работает!

Если оба из этих сайта работают, вы успешно настроили два виртуальных хостов на одном сервере.

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


Вывод

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

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

Чтобы использовать Apache для обслуживания защищенного контента, следуйте учебнику, как установить сертификат SSL и SPDY на Ubuntu с помощью «Let’s Encrypt». Чтобы использовать Apache в передней части вашего веб — приложения, прочитайте гид как использовать Apache в качестве обратного прокси сервера с mod_proxy на Debian 8.

Как настроить Apache виртуальные хосты на Debian 8



2017-03-24T10:34:55
Настройка Debian

Как использовать Apache в качестве обратного прокси с mod_proxy на Debian 8

Обратный прокси — сервер представляет собой тип прокси — сервера, который принимает HTTP (S) запросы и прозрачно распределяет их на один или несколько внутренних серверов. Обратные прокси — серверы являются полезными, поскольку многие современные веб — приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.

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

В этом учебном пособии вы настроите Apache в качестве основного обратного прокси — сервера с помощью расширения mod_proxy для перенаправления входящих подключений к одному или нескольким внутренним серверам, работающих в той же сети. Этот учебник использует простой бэкенд написанный на Flask web framework, но вы можете использовать любой сервер данных, который вы предпочитаете.

Предпосылки

Следуя этому руководству, вам потребуется:

Шаг 1 — Включение необходимых модулей Apache

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

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

  • mod_proxy, главный прокси-модуль Apache модуль для перенаправления соединений; он позволяет Apache выступать в качестве шлюза для основных серверов приложений.
  • mod_proxy_http, который добавляет поддержку проксирования HTTP соединений.
  • mod_proxy_balancer и mod_lbmethod_byrequests, добавляет новые функции балансировки нагрузки для нескольких внутренних серверов.

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

sudo a2enmod proxy

sudo a2enmod proxy_http

sudo a2enmod proxy_balancer

sudo a2enmod lbmethod_byrequests

 

Чтобы эти изменения вступили в силу, перезапустите Apache.

sudo systemctl restart apache2

 

Apache теперь готов действовать в качестве обратного прокси-сервера для HTTP-запросов. В следующем (по желанию) шаге, мы создадим два самых основных внутренних сервера. Это поможет нам проверить, что конфигурация работает правильно, но если у вас уже есть собственное приложение(я) бэкэнд, вы можете перейти к шагу 3.

Шаг 2 — Создание внутренних тестовых серверов

Запуск некоторых простых внутренних серверов является простой способ проверить, что ваша конфигурация Apache работает должным образом. Здесь мы сделаем два тестовых сервера, которые отвечают HTTP — запросам с печатью строки текста. Один сервер скажет ‘Привет , мир! а другой скажет ‘AndreyEx мир! ,

Примечание
В не-испытательных установках, Backend серверы, как правило, возвращают один и тот же тип содержимого. Тем не менее, для этого теста, в частности, два сервера возвращают различные сообщения, что позволяет легко проверить, что механизм балансировки нагрузки использует оба.


Flask является microframework Python для создания веб — приложений. Мы используем Flask для создания тестовых серверов, так как основное приложение требует всего несколько строк кода. Вам не нужно знать Python, чтобы настроить их.

Обновление списка пакетов в первую очередь.

sudo apt-get update

 

Затем установите pip, рекомендуемый менеджер пакетов Python.

sudo apt-get -y install python3-pip

 

Используйте pip чтобы установить Flask.

sudo pip3 install flask

 

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

nano ~/backend1.py

 

Скопируйте следующий код в файл, а затем сохраните и закройте его.

~ / Backend1.py

from flask import Flask

app = Flask(__name__)



@app.route('/')

def home():

    return 'Hello world!'


Первые две строки инициализации фреймворка Flask. Существует одна функция, home(), которая возвращает строку текста ( Hello world!).  @app.route('/') над home() функции говорит Flask использовать home()‘s возвращаемое значение в качестве ответа на HTTP — запросы, направленных на /корневой URL приложения.

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

cp ~/backend1.py ~/backend2.py

 

Откройте вновь скопированный файл.

nano ~/backend2.py

 

Измените сообщение , которое будет возвращено из Привет , мир! в AndreyEx мир! А затем сохраните и закройте файл.

~ / Backend2.py

from flask import Flask

app = Flask(__name__)



@app.route('/')

def home():

    return 'AndreyEx world!'


Используйте следующую команду, чтобы запустить первый фоновый сервер на порту 8080. Это также перенаправляет вывод Flask к /dev/null.

FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &

 

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

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

Аналогичным образом, используйте эту команду, чтобы запустить второй сервер на порту 8081. Обратите внимание на другое значение для переменной окружения FLASK_APP.

FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &

 

Вы можете проверить, что оба сервера работают с использованием curl. Тестирование первого сервера:

curl http://127.0.0.1:8080/

 

Это выведет Привет , мир! в терминале. Проверка второго сервера:

curl http://127.0.0.1:8081/

 

Это выведет AndreyEx мир!

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


На следующем шаге мы будем изменять конфигурационный файл Apache, чтобы включить его использование в качестве обратного прокси-сервера на Debian 8.

Шаг 3 — Изменение конфигурации по умолчанию. Включение обратного прокси-сервера

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

Примечание

В этом руководстве мы применяем настройки на уровне виртуального хоста. При установке по умолчанию Apache, есть только один включен, виртуальный хост по умолчанию. Тем не менее, вы можете использовать все эти фрагменты конфигурации в других виртуальных хостах.

Если ваш сервер работает на Apache как HTTP и HTTPS — сервер, ваша обратная конфигурация прокси — сервера должна быть размещена как в HTTP и HTTPS виртуальных хостах.

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

sudo nano /etc/apache2/sites-available/000-default.conf

 

Внутри этого файла вы найдете блок<VirtualHost *:80>, начиная с первой строки. В первом примере ниже показано, как настроить этот блок для обратного прокси — сервера для одного сервера бэкэнда, а второй устанавливает балансировкой нагрузки обратного прокси для нескольких внутренних серверов.

Пример 1 — Обратное проксирование сервера

Заменить все содержимое внутри блока VirtualHost со следующим, ваш файл конфигурации должен выглядит следующим образом:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>

    ProxyPreserveHost On



    ProxyPass / http://127.0.0.1:8080/

    ProxyPassReverse / http://127.0.0.1:8080/

</VirtualHost>


Если вы следовали вместе с серверами например, на шаге 2, используйте 127.0.0.1:8080 как написано в блоке выше. Если у вас есть свои собственные серверы приложений, использовать их адреса.

Есть три директивы здесь:

  • ProxyPreserveHost делает Apache передают оригинальный Host заголовок на внутренний сервер. Это полезно, так как это делает сервер бэкенд осознаный адрес, используемый для доступа к приложению.
  • ProxyPass главная директива конфигурации прокси. В этом случае, он указывает, что все в корневом URL ( /) должен быть отображен на внутренний сервер по указанному адресу. Например, если Apache получает запрос на /example, он будет подключаться и вернет ответ на оригинальный клиент. http://your_backend_server/example
  • ProxyPassReverse должен иметь ту же конфигурацию, что и ProxyPass. Это говорит Apache, чтобы изменить заголовки ответа от сервера бэкэнда. Это гарантирует, что если внутренний сервер возвращает заголовок перенаправления местоположения, браузер клиента будет перенаправлен на адрес прокси — сервера и не адреса сервера, бэкенда, который не будет работать, как предполагалось.

Чтобы изменения вступили в силу, перезапустите Apache.

sudo systemctl restart apache2

 

Теперь, если вы получаете доступ к http://your_server_ip через веб — браузер, вы увидите ответ сервера бэкэнда вместо стандартной страницы приветствия Apache. Если вы следовали инструкциям Шаг 2, то вы будете видеть Привет мир!

Пример 2 — балансировки нагрузки между несколькими серверами Backend

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

Замените все содержимое внутри блока VirtualHost следующим, так что ваш файл конфигурации выглядит следующим образом:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>

<Proxy balancer://mycluster>

    BalancerMember http://127.0.0.1:8080

    BalancerMember http://127.0.0.1:8081

</Proxy>



    ProxyPreserveHost On



    ProxyPass / balancer://mycluster/

    ProxyPassReverse / balancer://mycluster/

</VirtualHost>


Конфигурация аналогична предыдущей, но вместо указания одного сервера бэкэнд напрямую, мы использовали дополнительный блок Proxy для определения нескольких серверов. Блок с именем balancer://mycluster (имя может быть свободно изменено) и состоит из одного или нескольких BalancerMember, которые определяют, лежащие в основе адреса бэкенда сервера. ProxyPass и директива ProxyPassReverse  используют пул балансировки нагрузки с именем mycluster вместо конкретного сервера.

Если вы следовали примеру на шаге 2, используя 127.0.0.1:8080 и 127.0.0.1:8081 для директивы BalancerMember, как написано в блоке выше. Если у вас есть свои собственные серверы приложений, используйте их адреса вместо этих.

Чтобы изменения вступили в силу, перезапустите Apache.

sudo systemctl restart apache2

 

Зайдите в веб — браузере по адресу http://your_server_ip, вы увидите бэкэнд сервера вместо стандартной страницы Apache. Если вы следовали инструкциям на Шаге 2, обновите страницу несколько раз должен показать Привет, мир! и AndreyEx мир!, То есть обратный прокси — сервер работал и балансировка нагрузки между обоими серверами.

Вывод

Теперь вы знаете , как настроить Apache в качестве обратного прокси — сервера для одного или нескольких основных серверов приложений. mod_proxy можно эффективно использовать для настройки обратного прокси — сервера для серверов приложений, написанных на широкий спектр языков и технологий, таких как Python и Django или Ruby, и Ruby On Rails. Он может также использоваться для балансировки трафика между множеством внутренних серверов для сайтов с большим количеством трафика или для обеспечения высокой доступности через несколько серверов, или для обеспечения безопасной поддержки SSL на серверах, не поддерживающих SSL изначально.

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

  • mod_proxy_ftp для FTP.
  • mod_proxy_connect для SSL туннелирования.
  • mod_proxy_ajp для AJP (Apache JServ Protocol), как Tomcat на основе движков.
  • mod_proxy_wstunnel для веб-сокетов.

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

Как использовать Apache в качестве обратного прокси с mod_proxy на Debian 8



2017-02-02T01:54:32
Настройка Debian

Первоначальная настройка сервера Debian 8

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

Шаг первый — Войти как root

Для того, чтобы войти на свой сервер, вам нужно знать общественный IP — адрес сервера и пароль для учетной записи пользователя «root». Если вы еще не вошли на свой сервер, вы можете следовать учебнику как подключиться к серверу с помощью SSH.

Если вы еще не подключены к серверу, идти вперед и войдите в систему как пользователь root, используя следующую команду (замените выделенное слово на IP адрес вашего сервера):

ssh root@SERVER_IP_ADDRESS

 

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

О root

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

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

Шаг второй — создание нового пользователя

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

В этом примере создается новый пользователь с именем «demo», но вы должны заменить его на имя пользователя, который вам нравится:

adduser demo

 

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

Введите надежный пароль и, при необходимости, заполните дополнительную информацию, если вы хотите. Это не требуется, и вы можете просто нажать «ENTER» в любой области, которую вы хотите пропустить.

Шаг третий — суперпользователь

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

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

Установка Sudo

Debian 8 не поставляется с установленным sudo, так что давайте установить его с помощью apt-get.

Во-первых, обновим индекс пакетов:

apt-get update

 

Затем используйте эту команду, чтобы установить sudo:

apt-get install sudo

 

Теперь вы можете использовать команды sudo и visudo.

О SUDO привилегиях

Чтобы добавить эти привилегии к нашему новому пользователю, нам нужно добавить нового пользователя в группу «sudo». По умолчанию в Debian 8, пользователи, принадлежащие к группе «sudo» разрешено использовать команду sudo.

Как root, запустите эту команду, чтобы добавить нового пользователя к группе sudo  (замените выделенное слово новым пользователем):

usermod -a -G sudo demo

 

Теперь ваш пользователь может запускать команды с пользовательскими привилегиями!

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

Генерация пары ключей

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

Для создания новой пары ключей, введите следующую команду в терминале вашей локальной машине (то есть вашего компьютера):

ssh-keygen

 

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

ssh-keygen output

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

Вернуться, принять это имя файла и путь к нему (или введите новое имя).

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

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

Это создает закрытый ключ id_rsa и открытый ключ, id_rsa.pub, в .ssh домашней директории localuser’s. Помните, что закрытый ключ не должен использоваться совместно с кем — либо, кто не должен иметь доступ к серверам!

Скопируйте открытый ключ

После генерации пары ключей SSH, вы хотите скопировать свой открытый ключ на новый сервер. Мы рассмотрим два простых способа сделать это.

Вариант 1: Использование ssh-copy-id

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

Запустите скрипт ssh-copy-id, указав пользователя и IP — адрес сервера, на который вы хотите установить ключ, так:

ssh-copy-id demo@SERVER_IP_ADDRESS

 

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

Вариант 2: Вручную установить ключ

Предполагая, что вы сгенерировали пару ключей SSH, используя предыдущий шаг, используйте следующую команду в терминале вашей локальной машине , чтобы напечатать ваш открытый ключ ( id_rsa.pub):

cat ~/.ssh/id_rsa.pub

 

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

id_rsa.pub contents

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

 

Выберите открытый ключ, и скопируйте его в буфер обмена.

Добавить открытый ключ для новых удаленных пользователей

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

На сервере , как root, введите следующую команду, чтобы перейти к новому пользователю (заменить собственное имя пользователя):

su - demo

 

Теперь вы будете в домашнем каталоге вашего нового пользователя.

Создайте новую папку с именем .ssh и ограничьте права доступа со следующими командами:

    mkdir .ssh

    chmod 700 .ssh


 

Теперь откройте файл .ssh под названием authorized_keys с помощью текстового редактора. Мы будем использовать nano для редактирования файла:

nano .ssh/authorized_keys

 

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

Нажмите , CTRL-X чтобы выйти из файла, а затем чтобы сохранить изменения, которые вы сделали, и , ENTER чтобы подтвердить имя файла.

Теперь ограничить права доступа к файлу authorized_keys с помощью следующей команды:

chmod 600 .ssh/authorized_keys

 

Введите эту команду один раз, чтобы вернуться к пользователю root:

exit

 

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

Шаг пятый — Настройка SSH

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

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

nano /etc/ssh/sshd_config

 

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

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

/etc/ssh/sshd_config (до)

#PermitRootLogin yes


Вы можете изменить эту строку на «no», если вы хотите отключить корневой логин:

/etc/ssh/sshd_config (после)

PermitRootLogin no


Отключение удаленного корневого входа настоятельно рекомендуется на каждом сервере!

Когда вы закончите внесения изменений, сохраните и закройте файл, используя метод, который мы использовали ранее ( CTRL-X, а затем Y, потом ENTER).

Перезагрузить SSH

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

Введите эту функцию, чтобы перезапустить SSH:

systemctl restart ssh

 

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

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

ssh demo@SERVER_IP_ADDRESS

 

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

Помните, что если вам нужно выполнить команду с привилегиями суперпользователя, введите «sudo» перед ним, как в примере:

sudo command_to_run

 

Если все хорошо, вы можете выйти из ваших сессий, набрав:

exit

 

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



2017-01-31T05:50:20
Настройка Debian

Как переписывать URL-адрес с помощью mod_rewrite для Apache на Debian 8

На этом уроке, мы научиться управлять перезаписью URL с помощью Apache 2 и модуля mod_rewrite. Этот модуль позволяет переписать URL — адреса в более чистой манере, переводя удобочитаемые пути в кодовые дружественных строки запроса или перенаправляют URL — адреса на основе дополнительных условий.

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

Предпосылки

Следуя этому руководству, вам потребуется:

Шаг 1 — Включение mod_rewrite

Во- первых, нам нужно активировать mod_rewrite. Он доступен, но не включен с чистой установкой Apache 2.

sudo a2enmod rewrite

 

Он активирует модуль или предупреждает вас о том, что модуль уже включен. Чтобы изменения вступили в силу, перезапустите Apache.

sudo systemctl restart apache2

 

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

Шаг 2 — Настройка .htaccess

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

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

Тем не менее, в этом простом примере, увеличение производительности будет незначительным. Кроме того, устанавливая правила .htaccess удобно, особенно с нескольких веб — сайтами на одном сервере. Она не требует перезагрузки сервера, чтобы изменения вступили в силу , и это не требует привилегий суперпользователя для редактирования этих правил, что упрощает техническое обслуживание и внесение изменений и возможные с непривилегированных аккаунтов. Некоторые популярные программы с открытым исходным кодом, такие как WordPress и Joomla, часто полагается на файл .htaccess в программном обеспечении, чтобы изменять и создавать дополнительные правила по требованию.

Нам нужно будет установить и обеспечить еще несколько настроек, прежде чем мы сможем начать.

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

sudo nano /etc/apache2/sites-available/000-default.conf

 

Внутри этого файла вы найдете блок <VirtualHost *:80>, начиная с первой строки. Внутри этого блока, добавьте следующий новый блок , чтобы ваш файл конфигурации выглядит следующим образом . Убедитесь , что все блоки правильно с отступом.

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>

    <Directory /var/www/html>

        Options Indexes FollowSymLinks MultiViews

        AllowOverride All

        Require all granted

    </Directory>



    . . .

</VirtualHost>

 

Сохраните и закройте файл. Чтобы изменения вступили в силу, перезапустите Apache.

sudo systemctl restart apache2

 

Теперь создайте файл .htaccess в корневой веб директории.

sudo nano /var/www/html/.htaccess

 

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

/var/www/html/.htaccess

RewriteEngine on


Сохраните файл и выйдите.

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

Шаг 3 — Настройка перезаписи URL

Здесь мы установим базовую перезапись URL, которая преобразует URL — адреса в реальные пути к коду. В частности, мы будем разрешать пользователям доступ. http://your_server_ip/about

Начнем с создания файла с именем about.html в корневой директории веб.

sudo nano /var/www/html/about.html

 

Скопируйте следующий HTML-код в файл, а затем сохраните и закройте его.

/var/www/html/about.html

<html>

    <head>

        <title>О нас</title>

    </head>

    <body>

        <h1>О нас</h1>

    </body>

</html>

 

Вы можете получить доступ к странице http://your_server_ip/about.html, но обратите внимание, что если вы попытаетесь получить доступ к http://your_server_ip/about, вы увидите ошибку 404 Not Found. Но чтобы пользователи получили доступ к странице с помощью about вместо того, чтобы, переписать правила позволит эта самая функциональность.

RewriteRules соблюдает следующий формат:

Общая структура RewriteRule

RewriteRule pattern substitution [flags]


  • RewriteRule определяет директиву.
  • pattern является регулярное выражение, которое соответствует желаемой строки из URL, типы просмотра в браузере.
  • substitution это путь к реальному URL, то есть путь файловых серверов Apache.
  • flags необязательные параметры, которые можно изменять, как работает правило.

Откройте файл .htaccess.

sudo nano /var/www/html/.htaccess

 

После первой строки, добавьте RewriteRule отмеченный красным цветом, и сохраните файл.

/var/www/html/.htaccess

RewriteEngine on

RewriteRule ^about$ about.html [NC]

 

В этом случае, ^about$ это шаблон, about.html это замена, и [NC] является флагом. Наш пример использует несколько символов со специальным значением:

  • указывает на начало URL, после your_server_ip/.
  • $ указывает на конец URL.
  • about соответствует строке «about».
  • about.html является фактическим файл, который обращается к пользователю.
  • [NC] является флагом, который делает случай правила нечувствительным.

Теперь, вы должны иметь возможность доступа к http://your_server_ip/about в вашем браузере. На самом деле, с правилом показанным выше, следующие URL — адреса будут указывать about.html:

  • http://your_server_ip/about, из-за определения правила.
  • http://your_server_ip/About, Так как правило не чувствительно к регистру.
  • http://your_server_ip/about.html, так как оригинальное собственное имя файла всегда будет работать.

Ниже не будет:

  • http://your_server_ip/about/, потому что правило четко указано, что не может быть ничего после about помощью $символа.
  • http://your_server_ip/contact, потому что она не будет соответствовать строке about в правиле.

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

Пример 1 — Упрощение строки запросов с RewriteRule

Веб — приложения часто используют строки запроса, которые добавляются к URL — адресу, используя знак вопроса ( ?) после адреса. Отдельные параметры разделяются с помощью амперсанда (&). Строки запроса могут быть использованы для передачи дополнительных данных между отдельными страницами приложения.

Например, страницы результатов поиска написанные на PHP, могут использовать URL, как http://example.ru/results.php?item=shirt&author=andreyex. В этом примере два дополнительных параметра передают воображаемый result.php сценария приложения: item со значением shirt и author со значением andreyex. Приложение может использовать информацию строки запроса, чтобы построить правильную страницу для посетителя.

Правила перезаписи Apache часто используются для упрощения таких длинных и неприглядных ссылок как выше в дружественные URL — адреса, которые легче вводить и интерпретировать визуально. В этом примере, мы хотели бы, упростить ссылку выше, чтобы сделать http://example.ru/shirt/andreyex. shirt и значения параметров author и andreyex к прежнему адресу, но без строки запроса и имени сценария.

Вот одно правило для реализации этого:

Простой пример

RewriteRule ^shirt/andreyex$ results.php?item=shirt&author=andreyex [QSA]

 

shirt/andreyex явно сопоставляются в запрашиваемом адресе и Apache указал запустить вместо этого results.php?item=shirt&author=andreyex.

флаги [QSA] обычно используются в правила[ перезаписи. Они говорят Apache, чтобы добавить любые дополнительные строки запроса к обслуживаемому URL. Без этого, дополнительная строка запроса будет отбрасываются. http://example.ru/shirt/andreyex?page=2results.php?item=shirt&author=andreyex&page=2

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

Для того, чтобы сделать правило более общо, мы можем использовать регулярные выражения, чтобы соответствовать части исходного адреса и использовать те части в схеме замещения. Модифицированное правило будет выглядеть следующим образом :

Простой пример

RewriteRule ^([A-Za-z0-9]+)/(andreyex|destroyer|fall|spring) results.php?item=$1&author=$2 [QSA]

 

Первое регулярное выражение группы в скобках соответствует строке, содержащей буквенно-цифровые символы и цифры, как shirt или pants и сохраняет совпавший фрагмент в качестве переменной $1. Вторая группа выражений в скобках соответствует точно andreyex, destroyer, fall или spring, и так же сохраняет совпавший фрагмент как $2.

Согласованные фрагменты затем в результирующий URL в переменные item и author вместо жёстко shirt и andreyex, которые мы использовали раньше.

Выше будет преобразовывать, например, http://example.ru/pants/andreyex в http://example.ru/results.php?item=pants&author=andreyex. Этот пример также на будущее, позволяя нескольким элементам и author правильно переписать с использованием единого правила.

Пример 2 — Добавление условия с помощью логики, используя RewriteConds

Правила перезаписи не обязательно всегда вычисляются один за другим без каких — либо ограничений. Директива RewriteCond позволяет нам добавлять условия для наших правил перезаписи, чтобы контролировать, когда правила будут обработаны. RewriteConds соблюдает следующий формат:

Общая структура RewriteCond

RewriteCond TestString Condition [Flags]


  • RewriteCond определяет директиву RewriteCond.
  • TestString это тестируемая строка.
  • Condition это шаблон или условие, чтобы соответствовать.
  • Flags необязательные параметры, которые могут изменить правила условий и оценки.

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

В качестве примера, давайте предположим, что вы хотели бы перенаправить все запросы на несуществующие файлы и каталоги на вашем сайте обратно на главную страницу вместо того чтобы показывать стандартную страницу ошибку 404 Not Found. Это может быть достигнуто с следующими условиями правил:

Перенаправить все запросы на несуществующие файлы и каталоги на главную страницу

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /


С учетом указанных выше:

  • %{REQUEST_FILENAME} это строка для проверки. В этом случае, запрашиваемое имя файла, которое является переменной системой, доступной для каждого запроса.
  • -f встроенное в условие, которое проверяет, существует ли запрашиваемое имя на диске, и является ли файлом. ! - Является оператором отрицания. В сочетании !-f оценивается как истина, только если указанное имя не существует или не является файлом.
  • Аналогичным образом , !-d оценивается как истина, только если указанное имя не существует или не является каталогом.

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

Вывод

mod_rewrite полезный модуль Apache, который может быть эффективно использован для обеспечения удобочитаемых URL. На этом уроке вы узнали, как использовать директиву RewriteRule для перенаправления URL — адресов, в том числе с строки запроса. Вы также узнали перенаправление URL — адреса с помощью директивы RewriteCond.

Если вы хотите узнать больше о mod_rewrite, посмотрите на введение в mod_rewrite Apache и официальной документации Apache для mod_rewrite.

Как переписывать URL-адрес с помощью mod_rewrite для Apache на Debian 8



2017-01-30T20:35:43
Настройка Debian