Web Policy: различия между версиями

Материал из ALT Linux Wiki
м (<tt> для технических терминов.)
м (переименовал «WebPolicy» в «Web Policy»)
 
(не показано 9 промежуточных версий 4 участников)
Строка 1: Строка 1:
{{h0|Policy по упаковке веб-приложений}}
{{DraftPolicy|responsible=vvk,mike,solo}}
{{DraftPolicy|responsible=vvk,mike,solo}}
* Все веб-приложения должны иметь зависимость на пакет {{pkg|webserver-common}}, который предоставляет группы {{term|webmaster}} и {{term|_webserver}}.
* При сборке веб-приложений следует использовать макросы из пакета {{pkg|rpm-macros-webserver-common}}, ибо их использование упростит дальнейшую жизнь мейнтейнера при каких-либо изменениях Policy.


== Policy по упаковке веб-приложений ==
== Системные веб-приложения и приложения для single-hosting ==
 
 
=== Системные веб-приложения и приложения для single-hosting ===
В этом разделе часть написана по мотивам [http://webapps-common.alioth.debian.org/draft/html/index.html Debian Web Policy]
В этом разделе часть написана по мотивам [http://webapps-common.alioth.debian.org/draft/html/index.html Debian Web Policy]


==== Размещение веб-приложений в иерархии URL ====
=== Размещение веб-приложений в иерархии URL ===
# CGI-bin файлы:
# CGI-bin файлы:
#* <tt><домен>/cgi-bin/<cgi-файл></tt> — независимые и самодостаточные cgi-файлы
#* <tt><домен>/cgi-bin/<cgi-файл></tt> — независимые и самодостаточные cgi-файлы
#* <tt><домен>/<приложение>/cgi-bin/<cgi-файл></tt> — cgi-файлы приложений с cgi частью выделенной явно
#* <tt><домен>/<приложение>/cgi-bin/<cgi-файл></tt> — cgi-файлы приложений с cgi частью выделенной явно
#* <tt><домен>/<приложение>/<cgi-файл></tt> — cgi-файлы приложений без явного выделения cgi части
#* <tt><домен>/<приложение>/<cgi-файл></tt> — cgi-файлы приложений без явного выделения cgi части
::


==== Размещение веб-приложений в иерархии файловой системы ====
=== Размещение веб-приложений в иерархии файловой системы ===
# CGI-bin файлы:
# CGI-bin файлы:
#* <tt>%_libdir/cgi-bin/<имя></tt> — архитектурно зависимые cgi-файлы
#* <tt>%_libdir/cgi-bin/<имя></tt> — архитектурно зависимые cgi-файлы
#* <tt>/usr/share/cgi-bin/<имя></tt> — архитектурно независимые cgi-файлы
#* <tt>/usr/share/cgi-bin/<имя></tt> — архитектурно независимые cgi-файлы
#* <tt>/usr/share/<имя>/<каталог></tt> — любой уникальный каталог внутри директории веб-приложения
#* <tt>/usr/share/<имя>/<каталог></tt> — любой уникальный каталог внутри директории веб-приложения
#* <tt>/var/www/cgi-bin/<имя>/</tt> <div style="display: inline; color: red;">исторически сложившееся место, от которого решено отказаться (?)</div>
#* <tt>/var/www/cgi-bin/<имя>/</tt> — <div style="display: inline; color: red;">исторически сложившееся место, от которого решено отказаться (?)</div>
# Конфигурационные файлы:
# Конфигурационные файлы:
#* <tt>/etc/<имя>/</tt>
#* <tt>/etc/<имя>/</tt>
Строка 27: Строка 26:
#* <tt>/var/www/webapps/<имя>/</tt>
#* <tt>/var/www/webapps/<имя>/</tt>
#* <tt>/var/lib/<имя>/</tt>
#* <tt>/var/lib/<имя>/</tt>
# Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в <tt>/var/www/webapps/<имя>/</tt>
# '''Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в <tt>/var/www/webapps/<имя>/</tt>'''


==== Права на конфигурационные файлы и модифицируемый контент ====
=== Права на конфигурационные файлы и модифицируемый контент ===
# Файлы, содержащую приватную информацию, пароли, и т. п.:
# Файлы, содержащую приватную информацию, пароли, и т. п.:
#* <tt>640 root:_webserver</tt>
#* <tt>640 root:_webserver</tt>
Строка 40: Строка 39:
#* <tt> 2775 root:_webserver</tt>
#* <tt> 2775 root:_webserver</tt>


==== Привязка к различным веб-серверам ====
При этом непонятно следующее: как быть с правами на файлы, подлежащими модификации вебмастерами (пользователями входящими в группу webmaster)...
 
=== Привязка к различным веб-серверам ===
# Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты.
# Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты.
# В понятие «привязка» входят:
# В понятие «привязка» входят:
Строка 46: Строка 47:
#* Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения.
#* Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения.


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




=== Упаковка веб-приложений для использования на виртуальном хостинге ===
== Упаковка веб-приложений для использования на виртуальном хостинге ==
* ''требуется обсуждение''
* ''требуется обсуждение''
* [http://apsstandard.com/r/doc/package-format-specification-1.0/index.html Упаковка веб-приложений в бывшем swsoft].  
* [http://apsstandard.com/r/doc/package-format-specification-1.0/index.html Упаковка веб-приложений в бывшем swsoft].  
Строка 68: Строка 69:
Результат — платформа для хостинга, в части web-приложений не уступающая тому же Plesk.
Результат — платформа для хостинга, в части web-приложений не уступающая тому же Plesk.
Второй бонус: утилита для перепаковки приложений из формата apsstandard.com в RPM-ки под альт.
Второй бонус: утилита для перепаковки приложений из формата apsstandard.com в RPM-ки под альт.
{{Category navigation|title=Web|category=Web}}

Текущая версия от 09:40, 21 июля 2010

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-ки под альт.


Web