Web Policy

Материал из ALT Linux Wiki
Версия для печати больше не поддерживается и может содержать ошибки обработки. Обновите закладки браузера и используйте вместо этого функцию печати браузера по умолчанию.

Policy по упаковке веб-приложений

Stub.png
Черновик политики Sisyphus
Автор(ы) — vvk,mike,solo


  • Все веб-приложения должны иметь зависимость на пакет webserver-common, который предоставляет группы webmaster и _webserver.
  • При сборке веб-приложений следует использовать макросы из пакета rpm-macros-webserver-common, ибо их использование упростит дальнейшую жизнь мейнтейнера при каких-либо изменениях Policy.

Системные веб-приложения и приложения для single-hosting

В этом разделе часть написана по мотивам Debian Web Policy

Размещение веб-приложений в иерархии URL

  1. CGI-bin файлы:
    • <домен>/cgi-bin/<cgi-файл> — независимые и самодостаточные cgi-файлы
    • <домен>/<приложение>/cgi-bin/<cgi-файл> — cgi-файлы приложений с cgi частью выделенной явно
    • <домен>/<приложение>/<cgi-файл> — cgi-файлы приложений без явного выделения cgi части

Размещение веб-приложений в иерархии файловой системы

  1. CGI-bin файлы:
    • %_libdir/cgi-bin/<имя> — архитектурно зависимые cgi-файлы
    • /usr/share/cgi-bin/<имя> — архитектурно независимые cgi-файлы
    • /usr/share/<имя>/<каталог> — любой уникальный каталог внутри директории веб-приложения
    • /var/www/cgi-bin/<имя>/
      исторически сложившееся место, от которого решено отказаться (?)
  2. Конфигурационные файлы:
    • /etc/<имя>/
  3. Статический и динамический контент:
    • /usr/share/<имя>/
  4. Данные, подвергающиеся модификации со стороны веб-приложения:
    • /var/www/webapps/<имя>/
    • /var/lib/<имя>/
  5. Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в /var/www/webapps/<имя>/

Права на конфигурационные файлы и модифицируемый контент

  1. Файлы, содержащую приватную информацию, пароли, и т. п.:
    • 640 root:_webserver
  2. Файлы, содержащую приватную информацию, пароли, и т. п., подлежащие модификации со стороны веб-сервера:
    • 660 root:_webserver
  3. Файлы, подлежащие модификации со стороны веб-сервера:
    • 664 root:_webserver
  4. Директории, подлежащие модификации со стороны веб-сервера:
    • 2770 root:_webserver
    • 2775 root:_webserver

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

Привязка к различным веб-серверам

  1. Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты.
  2. В понятие «привязка» входят:
    • Конфигурационные файлы под конкретный веб-сервер
    • Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения.

Привязка к php

  1. Основной пакет, содержащий веб-приложение, должен иметь зависимость на мета-пакет php-движка (Requires: php-engine).
  2. Чтобы избежать зависимости от конкретной major-версии php, зависимости на конкретные модули php должны быть вынесены в отдельные подпакеты. То есть если приложение поддерживает и php4, и php5, то зависимости на php-модули следует вынести в подпакеты %name-php4 и %name-php5, где первый подпакет содержит зависимость только на модули php4, а второй — только на php5.


Упаковка веб-приложений для использования на виртуальном хостинге

Краткое описание от dottedmag:

Там описаны две вещи:

  1. формат упаковки приложений
  2. протокол установки/удаления на vhost.

Берётся формат упаковки, из него нещадно стрипается всё, что уже есть в RPM, остальное раскладывается в метаинформацию, более пригодную к shell-скриптованию. Дальше. По спеке пишется набор CLI-утилит, умеющих

  1. устанавливать приложение в vhost
  2. апгрейдить
  3. удалять

Бонус: альтераторный модуль, одним кликом делающий щщастье. Результат — платформа для хостинга, в части web-приложений не уступающая тому же Plesk. Второй бонус: утилита для перепаковки приложений из формата apsstandard.com в RPM-ки под альт.