[devel] web packaging: init!

[devel] web packaging: init!

[Илья Евсеев]

   Всем привет!
Поразмыслив над упаковкой IlohaMail (Web-mail приложение для SMTP, POP3 и IMAP), я пришёл к следующим заключениям.

ПЕРВОЕ. Каталог /var/www/html предназначен для данных, а не для программ. Не имеет смысла пихать туда программу, чтобы в каждый её подкаталог тут же записывать .htaccess "Deny from all". По умолчанию IlohaMail ставится %libexecdir/%name, т.е. в /usr/lib/%name. Вот пусть она там и сидит, а на один-единственный её подкаталог с Веб-формами будет указывать симлинк ФС или (лучше) alias/vhost Апача.

ВТОРОЕ. Поскольку /usr содержит константные данные, %libexecdir/%name/conf должен быть не каталогом с настройками, как это сделано у IlohaMail по умолчанию, а симлинком на определённый Альтом каталог %apache_addconfdir/%name, где и будут лежать настройки.

Обычно делают почему-то ровно наоборот: настройки сваливают в %apache_datadir, хотя, как следует из имени макроса, им там совершенно не место, и из %apache_addconfdir делают на него симлинк.

ТРЕТЬЕ. Если теперь поддерживается conf/addon-modules.d/*.conf (кстати, а макрос %apache_??? этому соответствует какой?), то в этот каталог должен помещаться файл %name.conf с <Directory> Order Allow,Deny; Allow from 127.0.0.1 </Directory>, чтобы:
а) не открывать сервис в сеть без подготовки (по аналогии с xinetd.conf и xinetd.d/*);
б) заставить сисадмина заглянуть в него и, возможно, что-то исправить: сделать доступ только из Интранета, только по HTTPS, только для отдельных пользователей и т.д.

В conf-файле должен быть Alias, указывающий на /usr/lib/%name, но _закомментированный_, потому что специфичным для программы алиасом мы громко сообщаем, что у нас установлена эта программа, чем облегчаем работу потенциальным взломщикам.

Кроме того, пользователи вряд ли захотят набирать your.host.ru/addon-modules/imp/ или .../ilohamail, а потребуют host.domain.ru/mail (на такое имя каталога ни у какого конкретного пакета прав претендовать, по-моему, нет, поэтому нужен ещё один _закомментированный_ Alias) или mail.domain.ru (который к тому же зависит от имени хоста/сети, т.е. должен быть назначен сисадмином, а не сценарием установки). Поэтому тут же в %name.conf должен быть закомментированный VirtualHost.

Вопрос: будет ли собранный по этим правилам пакет принят нашим неформальным Web Development Team как корректный? Имеет ли смысл распространять эту практику на прочие пакеты с Веб-приложениями?

Благодарю за внимание,
Илья Евсеев

Re: [devel] web packaging: init!

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Илья Евсеев пишет:
> Кроме того, пользователи вряд ли захотят набирать your.host.ru/addon-modules/imp/ или .../ilohamail,
> а потребуют host.domain.ru/mail (на такое имя каталога ни у какого конкретного пакета прав
> претендовать, по-моему, нет, поэтому нужен ещё один _закомментированный_ Alias) или mail.domain.ru
> (который к тому же зависит от имени хоста/сети, т.е. должен быть назначен сисадмином, а не сценарием
> установки). Поэтому тут же в %name.conf должен быть закомментированный VirtualHost.

По поводу virtualhosts, я думаю надо сделать папку conf/vhosts.d/, где и
складывать описания хостов. У себя я так всегда делаю. Вот все в
багзиллу FR написать забываю...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] web packaging: init!

[Vladimir Lettiev]

Илья Евсеев пишет:
>    Всем привет!
> Поразмыслив над упаковкой IlohaMail (Web-mail приложение для SMTP, POP3 и IMAP), я пришёл к следующим заключениям.
> 
> ПЕРВОЕ. Каталог /var/www/html предназначен для данных, а не для программ. Не имеет смысла пихать туда программу, чтобы в каждый её подкаталог тут же записывать .htaccess "Deny from all". По умолчанию IlohaMail ставится %libexecdir/%name, т.е. в /usr/lib/%name. Вот пусть она там и сидит, а на один-единственный её подкаталог с Веб-формами будет указывать симлинк ФС или (лучше) alias/vhost Апача.

/var/www предназначен для веб-приложений, а на веб-сервере я даже выношу 
  /var/www как отдельную партицию. Поэтому мне удобнее было бы плясать 
от /var/www:
/var/www/webapps - каталог для веб-приложений (данные и скрипты)
/var/www/vhosts - каталог для виртохостов.
/etc/httpd/addon-modules.d/ - каталог для всех настроек (alias, access и 
  т.д.)

> ВТОРОЕ. Поскольку /usr содержит константные данные, %libexecdir/%name/conf должен быть не каталогом с настройками, как это сделано у IlohaMail по умолчанию, а симлинком на определённый Альтом каталог %apache_addconfdir/%name, где и будут лежать настройки.
 > Обычно делают почему-то ровно наоборот: настройки сваливают в 
%apache_datadir, хотя, как следует из имени макроса, им там совершенно 
не место, и из %apache_addconfdir делают на него симлинк.

s/%libexecdir/%libdir/ ?
По идее для данных, программ не зависящих от платформы предназначен 
/usr/share/%name , а для файлов конфигурации идеален /etc. Вы фактически 
устанавливаете веб-приложение как обычную программу.

> 
> ТРЕТЬЕ. Если теперь поддерживается conf/addon-modules.d/*.conf (кстати, а макрос %apache_??? этому соответствует какой?), то в этот каталог должен помещаться файл %name.conf с <Directory> Order Allow,Deny; Allow from 127.0.0.1 </Directory>, чтобы:
> а) не открывать сервис в сеть без подготовки (по аналогии с xinetd.conf и xinetd.d/*);
> б) заставить сисадмина заглянуть в него и, возможно, что-то исправить: сделать доступ только из Интранета, только по HTTPS, только для отдельных пользователей и т.д.
> В conf-файле должен быть Alias, указывающий на /usr/lib/%name, но _закомментированный_, потому что специфичным для программы алиасом мы громко сообщаем, что у нас установлена эта программа, чем облегчаем работу потенциальным взломщикам.
> Кроме того, пользователи вряд ли захотят набирать your.host.ru/addon-modules/imp/ или .../ilohamail, а потребуют host.domain.ru/mail (на такое имя каталога ни у какого конкретного пакета прав претендовать, по-моему, нет, поэтому нужен ещё один _закомментированный_ Alias) или mail.domain.ru (который к тому же зависит от имени хоста/сети, т.е. должен быть назначен сисадмином, а не сценарием установки). Поэтому тут же в %name.conf должен быть закомментированный VirtualHost.

в conf/addon-modules.d/ кладётся файл настройки для вашего 
веб-приложения. Там всё и определяется, какие alias'ы, как разруливаются 
права доступа и т.д. Виртохосты невозможно сделать без участия админа, 
так что вы правы, - можно дать лишь закомментированный пример, но вот 
хоть какой-то работающий вариант нужен, просто сделать его доступным 
лишь для 127.0.0.1.

Вы постоянно упоминате IMP. Так я вам скажу - 
your.host.ru/addon-modules/horde/imp/ набирать не надо. В файле 
конфигурации апаче этот путь выпрямляется до your.host.ru/horde/imp/. 
Файлы .htaccess лежат там, поскольку они есть в исходном тарболе 
приложения и нужны не более чем "на всякий пожарный", поскольку все 
права доступа жёстко забиваются в файле конфигурации для апаче. Доступ 
также по умолчанию только с `hostname -i`.

> Вопрос: будет ли собранный по этим правилам пакет принят нашим неформальным Web Development Team как корректный? Имеет ли смысл распространять эту практику на прочие пакеты с Веб-приложениями?
> 
Пока нету никакой полиси и стандарта все делают кто как умеет... :(

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>

Re: [devel] web packaging: init!

[Anton Farygin]

Vladimir Lettiev пишет:
> Илья Евсеев пишет:
> 
>>    Всем привет!
>> Поразмыслив над упаковкой IlohaMail (Web-mail приложение для SMTP, 
>> POP3 и IMAP), я пришёл к следующим заключениям.
>>
>> ПЕРВОЕ. Каталог /var/www/html предназначен для данных, а не для 
>> программ. Не имеет смысла пихать туда программу, чтобы в каждый её 
>> подкаталог тут же записывать .htaccess "Deny from all". По умолчанию 
>> IlohaMail ставится %libexecdir/%name, т.е. в /usr/lib/%name. Вот пусть 
>> она там и сидит, а на один-единственный её подкаталог с Веб-формами 
>> будет указывать симлинк ФС или (лучше) alias/vhost Апача.
> 
> 
> /var/www предназначен для веб-приложений, а на веб-сервере я даже выношу 
>  /var/www как отдельную партицию. Поэтому мне удобнее было бы плясать от 
> /var/www:
> /var/www/webapps - каталог для веб-приложений (данные и скрипты)
> /var/www/vhosts - каталог для виртохостов.
> /etc/httpd/addon-modules.d/ - каталог для всех настроек (alias, access и 
>  т.д.)
> 
>> ВТОРОЕ. Поскольку /usr содержит константные данные, 
>> %libexecdir/%name/conf должен быть не каталогом с настройками, как это 
>> сделано у IlohaMail по умолчанию, а симлинком на определённый Альтом 
>> каталог %apache_addconfdir/%name, где и будут лежать настройки.
> 
>  > Обычно делают почему-то ровно наоборот: настройки сваливают в 
> %apache_datadir, хотя, как следует из имени макроса, им там совершенно 
> не место, и из %apache_addconfdir делают на него симлинк.
> 
> s/%libexecdir/%libdir/ ?
> По идее для данных, программ не зависящих от платформы предназначен 
> /usr/share/%name , а для файлов конфигурации идеален /etc. Вы фактически 
> устанавливаете веб-приложение как обычную программу.
> 
>>
>> ТРЕТЬЕ. Если теперь поддерживается conf/addon-modules.d/*.conf 
>> (кстати, а макрос %apache_??? этому соответствует какой?), то в этот 
>> каталог должен помещаться файл %name.conf с <Directory> Order 
>> Allow,Deny; Allow from 127.0.0.1 </Directory>, чтобы:
>> а) не открывать сервис в сеть без подготовки (по аналогии с 
>> xinetd.conf и xinetd.d/*);
>> б) заставить сисадмина заглянуть в него и, возможно, что-то исправить: 
>> сделать доступ только из Интранета, только по HTTPS, только для 
>> отдельных пользователей и т.д.
>> В conf-файле должен быть Alias, указывающий на /usr/lib/%name, но 
>> _закомментированный_, потому что специфичным для программы алиасом мы 
>> громко сообщаем, что у нас установлена эта программа, чем облегчаем 
>> работу потенциальным взломщикам.
>> Кроме того, пользователи вряд ли захотят набирать 
>> your.host.ru/addon-modules/imp/ или .../ilohamail, а потребуют 
>> host.domain.ru/mail (на такое имя каталога ни у какого конкретного 
>> пакета прав претендовать, по-моему, нет, поэтому нужен ещё один 
>> _закомментированный_ Alias) или mail.domain.ru (который к тому же 
>> зависит от имени хоста/сети, т.е. должен быть назначен сисадмином, а 
>> не сценарием установки). Поэтому тут же в %name.conf должен быть 
>> закомментированный VirtualHost.
> 
> 
> в conf/addon-modules.d/ кладётся файл настройки для вашего 
> веб-приложения. Там всё и определяется, какие alias'ы, как разруливаются 
> права доступа и т.д. Виртохосты невозможно сделать без участия админа, 
> так что вы правы, - можно дать лишь закомментированный пример, но вот 
> хоть какой-то работающий вариант нужен, просто сделать его доступным 
> лишь для 127.0.0.1.
> 
> Вы постоянно упоминате IMP. Так я вам скажу - 
> your.host.ru/addon-modules/horde/imp/ набирать не надо. В файле 
> конфигурации апаче этот путь выпрямляется до your.host.ru/horde/imp/. 
> Файлы .htaccess лежат там, поскольку они есть в исходном тарболе 
> приложения и нужны не более чем "на всякий пожарный", поскольку все 
> права доступа жёстко забиваются в файле конфигурации для апаче. Доступ 
> также по умолчанию только с `hostname -i`.
> 
>> Вопрос: будет ли собранный по этим правилам пакет принят нашим 
>> неформальным Web Development Team как корректный? Имеет ли смысл 
>> распространять эту практику на прочие пакеты с Веб-приложениями?
>>
> Пока нету никакой полиси и стандарта все делают кто как умеет... :(
> 

IMHO нужно кому-то все-таки написать policy и оформить его в пакет, 
также как было сделано с python, kernel, perl и т.д.

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

Rgds,
Rider

Re: [devel] web packaging: init!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Mon, Sep 20, 2004 at 02:43:42PM +0400, Anton Farygin wrote:

 AF> Просьба только не забывать про сложности, связанные с обновлением 
 AF> использующих SQL сервер приложений. (главный вопрос - как менять 
 AF> структуру базы данных при обновлении приложения).

В самописных приложениях я это решал написанием на перле модуля
экспортирования всей _информации_ из базы в XML формате (например в
/var/lib/%name/database.xml), правда не оформлял это в виде чего-то
работоспособного при автоматических обновлениях -- делал скрипты
/usr/lib/%name/exportdb и /usr/lib/%name/importdb. 

Соответственно можно при удалении пакета делать exportdb и убивать базу
данных. Естественно _обязательно_ делая ещё и дамп самой базы данных
(средствами используемой SQL-базы). При установке, если существует файл
/var/lib/%name/database.xml, то натравливать на него importdb.

Вопрос только в одном -- как сделать так, чтобы при _обновлении_ файлик
сохранялся, и при _удалении_ таки убивался (дабы не замусоривать систему)?
 
-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: web packaging: init!

[Michael Shigorin]

On Sun, Sep 19, 2004 at 04:16:12AM +0400, Илья Евсеев  wrote:
> Поразмыслив над упаковкой IlohaMail (Web-mail приложение для
> SMTP, POP3 и IMAP), я пришёл к следующим заключениям.

(я не игнорирую данный тред, просто сейчас не получается
_адекватно_ добраться до вопроса...)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/