Web Policy: различия между версиями
м (В категорию Web) |
Ilis (обсуждение | вклад) Нет описания правки |
||
Строка 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. | |||
== Системные веб-приложения и приложения для 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 === | |||
# 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-файлы | ||
Строка 31: | Строка 28: | ||
# '''Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в <tt>/var/www/webapps/<имя>/</tt>''' | # '''Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в <tt>/var/www/webapps/<имя>/</tt>''' | ||
=== Права на конфигурационные файлы и модифицируемый контент === | |||
# Файлы, содержащую приватную информацию, пароли, и т. п.: | # Файлы, содержащую приватную информацию, пароли, и т. п.: | ||
#* <tt>640 root:_webserver</tt> | #* <tt>640 root:_webserver</tt> | ||
Строка 44: | Строка 41: | ||
При этом непонятно следующее: как быть с правами на файлы, подлежащими модификации вебмастерами (пользователями входящими в группу webmaster)... | При этом непонятно следующее: как быть с правами на файлы, подлежащими модификации вебмастерами (пользователями входящими в группу webmaster)... | ||
=== Привязка к различным веб-серверам === | |||
# Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты. | # Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты. | ||
# В понятие «привязка» входят: | # В понятие «привязка» входят: | ||
Строка 50: | Строка 47: | ||
#* Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения. | #* Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения. | ||
=== Привязка к 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]. |
Версия от 21:46, 1 мая 2009
Policy по упаковке веб-приложений
- Все веб-приложения должны иметь зависимость на пакет webserver-common, который предоставляет группы webmaster и _webserver.
- При сборке веб-приложений следует использовать макросы из пакета rpm-macros-webserver-common, ибо их использование упростит дальнейшую жизнь мейнтейнера при каких-либо изменениях Policy.
Системные веб-приложения и приложения для single-hosting
В этом разделе часть написана по мотивам Debian Web Policy
Размещение веб-приложений в иерархии URL
- CGI-bin файлы:
- <домен>/cgi-bin/<cgi-файл> — независимые и самодостаточные cgi-файлы
- <домен>/<приложение>/cgi-bin/<cgi-файл> — cgi-файлы приложений с cgi частью выделенной явно
- <домен>/<приложение>/<cgi-файл> — cgi-файлы приложений без явного выделения cgi части
Размещение веб-приложений в иерархии файловой системы
- CGI-bin файлы:
- %_libdir/cgi-bin/<имя> — архитектурно зависимые cgi-файлы
- /usr/share/cgi-bin/<имя> — архитектурно независимые cgi-файлы
- /usr/share/<имя>/<каталог> — любой уникальный каталог внутри директории веб-приложения
- /var/www/cgi-bin/<имя>/ — исторически сложившееся место, от которого решено отказаться (?)
- Конфигурационные файлы:
- /etc/<имя>/
- Статический и динамический контент:
- /usr/share/<имя>/
- Данные, подвергающиеся модификации со стороны веб-приложения:
- /var/www/webapps/<имя>/
- /var/lib/<имя>/
- Если распил согласно вышеуказанным пунктам не производится, веб-приложение должно располагаться в /var/www/webapps/<имя>/
Права на конфигурационные файлы и модифицируемый контент
- Файлы, содержащую приватную информацию, пароли, и т. п.:
- 640 root:_webserver
- Файлы, содержащую приватную информацию, пароли, и т. п., подлежащие модификации со стороны веб-сервера:
- 660 root:_webserver
- Файлы, подлежащие модификации со стороны веб-сервера:
- 664 root:_webserver
- Директории, подлежащие модификации со стороны веб-сервера:
- 2770 root:_webserver
- 2775 root:_webserver
При этом непонятно следующее: как быть с правами на файлы, подлежащими модификации вебмастерами (пользователями входящими в группу webmaster)...
Привязка к различным веб-серверам
- Привязки к конкретным веб-серверам должны быть вынесены в отдельные подпакеты.
- В понятие «привязка» входят:
- Конфигурационные файлы под конкретный веб-сервер
- Команды (или файлы с директивами) для активации модулей веб-сервера, необходимые для корректной работы web-приложения.
Привязка к php
- Основной пакет, содержащий веб-приложение, должен иметь зависимость на мета-пакет php-движка (Requires: php-engine).
- Чтобы избежать зависимости от конкретной major-версии php, зависимости на конкретные модули php должны быть вынесены в отдельные подпакеты. То есть если приложение поддерживает и php4, и php5, то зависимости на php-модули следует вынести в подпакеты %name-php4 и %name-php5, где первый подпакет содержит зависимость только на модули php4, а второй — только на php5.
Упаковка веб-приложений для использования на виртуальном хостинге
- требуется обсуждение
- Упаковка веб-приложений в бывшем swsoft.
Краткое описание от dottedmag:
Там описаны две вещи:
- формат упаковки приложений
- протокол установки/удаления на vhost.
Берётся формат упаковки, из него нещадно стрипается всё, что уже есть в RPM, остальное раскладывается в метаинформацию, более пригодную к shell-скриптованию. Дальше. По спеке пишется набор CLI-утилит, умеющих
- устанавливать приложение в vhost
- апгрейдить
- удалять
Бонус: альтераторный модуль, одним кликом делающий щщастье. Результат — платформа для хостинга, в части web-приложений не уступающая тому же Plesk. Второй бонус: утилита для перепаковки приложений из формата apsstandard.com в RPM-ки под альт.