Apache2 django astra linux

Документация Django 1.6

Развертывание Django с Apache и mod_wsgi это испытанный способ установки на “боевой” веб-сервер.

mod_wsgi является модулем веб-сервера Apache, который может взаимодействовать с любым приложением Python, в том числе Django. Django работает с любой версией Apache, поддерживающей mod_wsgi .

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

Базовая конфигурация¶

После того как вы установите и активируете mod_wsgi отредактируйте файл httpd.conf веб-сервера Apache, изменив его следующим образом. Если вы используете Apache версии ниже чем 2.4, замените Require all granted` на Allow from all .

Значение WSGIScriptAlias указывает местоположение ваших приложений, ( / обозначает корневую директорию), вторым значением указывается расположение файла “WSGI” – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite ). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.

WSGIPythonPath гарантрует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.

Значение просто предоставляет Apache доступ к файлу wsgi.py .

Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии Django 1.4 команда startproject создаёт его; в противном случае вы можете создать этот файл самостоятельно. См. Развёртывание с WSGI, чтобы узнать изначальное содержимое файла и то, какие настройки вы можете добавить.

Если несколько сайтов на Django запащены в одном процессе mod_wsgi, они все будут использовать настройки сайта, который первый загрузился. Это можно исправить поправив « wsgi.py«(смотрите комментарий в файле), или используя mod_wsgi daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.

Использование virtualenv¶

Если вы установили зависимости проекта с помощью virtualenv вам следует добавить путь к директории site-packages , находящейся в вашем виртуальном окружении. Для этого добавьте дополнительный путь к WSGIPythonPath , разделив его двоеточием:

Убедитесь в том, что путь к виртуальному окружению указан верно и замените python2.X на используемую вами версию Python (например, python2.7 ).

Использование mod_wsgi в режиме демона¶

“Режим демона” рекомендуемый режим для запуска mod_wsgi (но не на ОС Windows). Для создания требуемой группы процесса-демона и передачи управления Django вы должны добавить директивы WSGIDaemonProcess и WSGIProcessGroup . Еще одно важное дополнение: при использовании данной конфигурации в режиме демона вы не сможете работать с WSGIPythonPath ; вместо этого укажите сопцию python-path , чтобы использовать возможности WSGIDaemonProcess , к примеру:

Обратитесь к официальной документации mod_wsgi , чтобы узнать подробнее о настройке в режиме демона.

Обслуживание файлов¶

Django не должен обрабатывать файлы самостоятельно; эта задача передаётся любому выбранному вами веб-серверу.

Мы рекомендуем использовать отдельный веб-сервер – то есть тот, что идёт не в поставке с самим Django – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:

Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте ( VirtualHost ) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.

Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt , favicon.ico , различным CSS-файлам, а также директориям /static/ и /media/ для их обработки как статических файлов. Все прочие URL-адреса будут обработаны при помощи mod_wsgi:

Обслуживание административных файлов¶

Если добавить приложение django.contrib.staticfiles в INSTALLED_APPS , сервер разработки Django автоматически обрабатывает административные приложения (и любые другие установленные приложения ), но это не годится для случая с другим сервером разработки. Вы сами несете ответственность за настройку Apache или любого другого сервера при использовании его для обслуживания административных файлов.

Административные файлы находятся по пути ( django/contrib/admin/static/admin ) в директории, где установлен Django.

Мы настоятельно рекомендуем использовать django.contrib.staticfiles для работы со статикой административного раздела (так же, как и в случае с веб-сервером, как это описано выше); это означает использование команды collectstatic для сбора статики в STATIC_ROOT , и настройку веб-сервера для обслуживания STATIC_ROOT в STATIC_URL ), но есть и несколько иных подходов:

Создание символьной ссылки на статические файлы, которые должны содержаться в корневом каталоге (для этого может потребоваться добавление +FollowSymLinks в конфигурации Apache).

Использование директивы Alias , как было показано выше, для создания псевдонима соответсвующего URL-адреса (вероятно это будет STATIC_URL + admin/ ), указывающего на фактическое расположение файлов.

Копирование директории с административной статикой в корень Apache.

Идентификация пользовательской базы данных с Apache¶

Django предоставляет возможность идентификации пользовательей средствами Apache см. mod_wsgi authentication documentation.

Если вы столкнулись с ошибкой UnicodeEncodeError ¶

Если вы воспользовались настройками стандартной интернационализации Django (см. Интернационализация и локализация) и позволили пользователям загружать файлы, то должны убедиться, что среда для запуска Apache настроена для обработки не ASCII символов.Если это не так, будет возбуждено исключение UnicodeEncodeError при вызове функций, подобных os.path() с именами файлов, содержащими отличные от ASCII символы.

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

Обратитесь к документации вашей операционной системы, чтобы подобрать соответствующий синтаксис и настроить расположение конфигурационных файлов; /etc/apache2/envvars является общей для Unix-like систем. После внесения соответствующих изменений перезапустите Apache.

Источник

Веб-приложения в защищённой среде

В последнее время в «Вопросах и ответах» часто спрашивают о различных нюансах работы Apache, WSGI и веб-приложений в Astra Linux Special Edition.

Работа веб-приложений в ОС СН Astra Linux Special Edition имеет ряд особенностей, обусловленных наличием мандатного разграничения доступом и режимов аутентификации пользователей.

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

Мы рекомендуем использовать встроенные механизмы защиты и идентификации пользователей с помощью защищённого веб-сервера Apache. Штатный веб-сервер Astra Linux Special Edition требует принудительной аутентификации во всех случаях взаимодействия и обеспечивает мандатное разграничение доступа.

Для разработчиков и администраторов предлагаются два механизма:

• PAM (использование базы локальных пользователей);
• ALD (использование базы доменных пользователей).

В основе PAM-аутентификации лежит метод простой аутентификации протокола HTTP (RFC 7617). Для использования в распределенных сетевых системах более подходящим является метод на базе протокола GSS-API (SPNEGO) с использованием механизма Kerberos.

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

1. Создать принципала для сервиса:
2. Добавить его в группу mac:
3. Создать файл ключей:
4. И установить на него режим доступа 0644 для пользователя и группы www-data.

После подключения пользователя Apache выполняет аутентификацию пользователя и определяет мандатные атрибуты подключения. После этого запрос обрабатывается процессом-обработчиком с UID аутентифицированного пользователя и соответствующими мандатными аттрибутами.

Модуль mod_wsgi для работы с приложениями WSGI присутствует в дистрибутиве ОС. Штатно поддерживается аутентификация и учитываются мандатные метки. Особенностью mod_wsgi в Astra Linux SE является возможность работы только в режиме embbeded. Т.о. при каждом запросе сервер в принудительном порядке создает процесс для запроса пользователя и происходит загрузка приложения. На данный процесс устанавливается мандатные атрибуты и UID подключенного пользователя.

Веб-сервер Apache из состава Astra Linux Special Edition запускает приложения WSGI для каждого пользовательского запроса. Такой подход обеспечивает необходимые условия для работы мандатной защиты данных. Следствием является увеличение потребления ресурсов и времени ответа на запросы.

Существует возможность использования запущенного WSGI-процесса для обработки последовательности запросов от пользователя в рамках постоянного HTTP-соединения. Веб-сервер не завершает запущенные обработчики WSGI в пределах параметра KeepAliveTimeout. Клиенты могут повторно использовать установленное соединение для ускорения обработки запросов.

Приложение Django

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

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

Аутентификация по Kerberos

Для правильной работы аутентификации по Kerberos необходимо:

1. Настроить сайт в веб-сервере Apache;
2. Настроить приложение Django.

Настройка сайта сводится к указанию типа аутентификации для обслуживаемого каталога:

При использовании аутентификации по Kerberos (Astra Linux Directory) возникает необходимость получения билетов для подключения к внутренним модулям и сервисам, скрытым от пользователя. Для каждого подключения необходимо получить билет Kerberos на основе пользовательского запроса, что влечет за собой обращение к Kerberos KDC. Получается, что один пользовательский запрос приводит к необходимости нескольких запросов в Kerberos и, скорее всего, в LDAP.

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

В обоих случаях необходимо настроить мандатные атрибуты на контейнер (БД и каталог соответственно).

При использовании для кэша PostgreSQL возможны две стратегии использования Kerberos (посредством GSS-API) при аутентификации в PostgreSQL:

1. Использование данных аутентификации (билетов) пользователя.
2. Делегирование полномочий веб-приложению.

Пример сайта для Apache

Авторизация пользователей в веб-приложении

При использовании ALD для аутентификации пользователей, авторизация в веб-приложении может быть выполнена стандартными функциями ППИ.

Получения идентификатора пользователя возможно двумя путями:

1. Получение UID процесса.
2. Получение учетной записи из REMOTE_USER.

Самый простой способ авторизации — использование групп ALD. В этом случае возможно использовать стандартные функции: pwd. getpwnam, grp. getgrgid и др. Такой подход исключает необходимость непосредственного обращения в базу LDAP.

Получение метки текущего процесса

При создании сложных веб-приложений возникает задача получения мандатной метки пользователя. Получить мандатную метку в WSGI приложении можно используя библиотеку python-parsec.

Похожие статьи

Сборка Mono для Debian и Astra Linux

Команда Лаборатории 50 подготовила сборку Mono для Debian Buster и Astra Linux Special Edition 1.6. Состав В сборку входит: Mono 6.12; LibGdiPlus 6.0.6; Entity Framework 6; драйвер Npgsql Entity Framework.

ГосJava 2020.3

Изменения по сравнению с версией 2020.2 Java Runtime Environment Импортированы исправления из OpenJDK 8u262. Закрыты уязвимости: CVE-2020-14583: incomplete interface type checks in Graal compiler (Hotspot, 8236867). CVE-2020-14664: out-of-bounds write in.

Запуск нескольких экземпляров Tomcat

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

Источник

Обслуживание приложений Django с помощью Apache и mod_wsgi в Ubuntu 16.04

Django – это производительный веб-фреймворк для разработки приложений или сайтов в Python.

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

Данное руководство поможет установить и настроить Django в виртуальном окружении Python, а также настроить Apache для поддержки приложения и обработки клиентских запросов (для этого используется модуль Apache под названием mod_wsgi, который взаимодействует с Django через интерфейс WSGI).

Требования

Для выполнения данного руководства нужно предварительно настроить сервер Ubuntu 16.04 и создать не-root пользователя с доступом к sudo. Подробные инструкции по начальной настройке сервера и создании пользователей можно найти здесь.

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

После запуска приложения нужно настроить взаимодействие веб-сервера Apache с приложением Django. Для этого используется модуль mod_wsgi, который преобразует HTTP-запросы в понятный Django формат согласно спецификации WSGI.

Установка пакетов из репозитория Ubuntu

Для начала нужно установить из репозитория Ubuntu все необходимые пакеты: веб-сервер Apache, модуль mod_wsgi и pip (пакетный менеджер Python).

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

Если вы используете Python 2, введите:

sudo apt-get update
sudo apt-get install python-pip apache2 libapache2-mod-wsgi

В Python 3 используется другой пакет pip:

sudo apt-get update
sudo apt-get install python3-pip apache2 libapache2-mod-wsgi-py3

Настройка виртуальной среды

Подготовив сервер, можно приступать к работе над приложением Django. Сначала создайте виртуальное окружение Python для хранения инструментов проекта.

Для этого используйте команду virtualenv. Чтобы установить эту утилиту, введите:

Python 2:
sudo pip install virtualenv
Python 3:
sudo pip3 install virtualenv

Теперь утилита virtualenv установлена, и можно использовать её для создания окружения. Создайте каталог, в котором будет находиться виртуальное окружение, и перейдите в него:

В этом каталоге создайте виртуальную среду Python:

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

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

source myprojectenv/bin/activate

После этого командная строка изменится, указывая, что текущей средой является виртуальная среда Python:

Включив виртуальную среду, установите Django:

pip install django

Примечание: Вне зависимости от версии Python в активной виртуальной среде используется команда pip, а не pip3.

Создание и настройка Django-приложения

Установив Django в виртуальную среду, можно приступать к созданию файлов Django-проекта.

Создание Django-проекта

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

django-admin.py startproject myproject .

Настройка Django-проекта

Первое, что нужно сделать после создания приложения, – отредактировать его настройки. Откройте файл settings в текстовом редакторе:

В руководстве используется стандартная БД SQLite, потому настройка не займёт много времени.

Примечание: Для поддержки масштабных приложений рекомендуется настроить более надёжную СУБД.

В центре внимания будет настройка каталога статических файлов Django.

В конец файла добавьте директиву STATIC_ROOT, которая задаёт фреймворку Django местонахождение статических файлов.

. . .
STATIC_URL = ‘/static/’
STATIC_ROOT = os.path.join(BASE_DIR, ‘static/’)

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

После этого можно открыть исходную схему БД при помощи скрипта управления:

/myproject
./manage.py makemigrations
./manage.py migrate

Создайте аккаунт администратора проекта:

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

Затем нужно собрать статический контент в один каталог:

После подтверждения все статические файлы будут помещены в каталог static в каталоге проекта.

Теперь нужно разблокировать порт сервера разработки Django, 8000. На данный момент он закрыт брандмауэром UFW (если вы настроили сервер согласно этому руководству).

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

sudo ufw allow 8000

Протестируйте проект, запустив сервер разработки Django:

./manage.py runserver 0.0.0.0:8000

Откройте браузер и посетите доменное имя или IP сервера на порте 8000:

На экране должна появиться приветственная страница Django:

It worked!
Congratulations on your first Django-powered page.

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

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

Чтобы остановить сервер разработки, нажмите CTRL-C.

Чтобы отключить виртуальную среду, введите:

Настройка Apache

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

Чтобы настроить WSGI, отредактируйте стандартный виртуальный хост.

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

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

Сначала настройте статические файлы; после этого Apache будет направлять все запросы, начинающиеся с /static, в каталог static, который находится в каталоге проекта. Для этого нужно определить Alias и предоставить доступ к требуемому каталогу.

. . .
Alias /static /home/8host/myproject/static

Require all granted

Затем нужно настроить права доступа к файлу wsgi.py (второй уровень каталогов проекта), в котором хранится код проекта. Для этого используйте раздел Directory.

. . .
Alias /static /home/8host/myproject/static

Require all granted

Require all granted

Теперь можно перейти к настройкам, обрабатывающим WSGI. Для запуска процессов WSGI используйте режим демона; для этого используется директива WSGIDaemonProcess. Эта директива принимает для процесса произвольное имя. В руководстве используется имя myproject.

Затем нужно указать путь к Python, где сервер Apache сможет найти все необходимые компоненты. Поскольку в настройке используется виртуальное окружение, нужно указать путь к каталогу виртуальной среды, а затем – путь Python к базовому каталогу проекта Django.

После этого нужно указать группу процессов; это значение должно совпадать со значением директивы WSGIDaemonProcess (в данном случае это myproject). В завершение нужно установить алиас скрипта, чтобы сервер Apache передавал запросы для корневого домена в файл wsgi.py:

. . .
Alias /static /home/8host/myproject/static

Require all granted

Require all granted

WSGIDaemonProcess myproject python-home=/home/8host/myproject/myprojectenv python-path=/home/8host/myproject
WSGIProcessGroup myproject
WSGIScriptAlias / /home/8host/myproject/myproject/wsgi.py

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

Права доступа

Используя базу данных SQLite (которая является стандартной), не забудьте предоставить веб-ерверу Apache доступ к ней.

Для этого нужно предоставить группе-владельцу права на запись и чтение. По умолчанию файл БД называется db.sqlite3 и должен находиться в каталоге проекта:

Передайте права на файл группе, в которую входит Apache; это группа www-data.

sudo chown :www-data

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

sudo chown :www-data

Теперь нужно снова отредактировать настройки брандмауэра. Закройте порт 8000 и добавьте исключение для трафика Apache:

sudo ufw delete allow 8000
sudo ufw allow ‘Apache Full’

Проверьте синтаксис файлов Apache:

sudo apache2ctl configtest

Если в файлах нет ошибок, команда вернёт:

Перезапустите сервис Apache, чтобы обновить настройки.

sudo systemctl restart apache2

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

Примечание: Номер порта указывать не нужно.

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

Теперь приложение Django работает в индивидуальной виртуальной среде, а модуль mod_wsgi помогает Apache преобразовывать запросы в понятный Django формат.

Убедившись, что приложение работает, вы можете приступать к настройке безопасности. Если у приложения есть доменное имя, можно получить бесплатный SSL-сертификат от Let’s Encrypt.

Источник