Стандарты инфраструктуры в каталоге cgi-bin

Я поддерживаю некоторые веб-приложения CGI, которые я переношу на новый веб-сервер Linux, на котором у меня есть учетная запись без прав администратора, скажем, www_maintainer. Итак, я устанавливаю приложения CGI внутри /home/www_maintainer/, и я хотел бы взять возможность навести порядок, в частности каталог cgi-bin/ можно было бы лучше организовать; Я хотел бы узнать о стандарте передовой практики для этого.

Например, нормально ли иметь подкаталоги с именами bin/ и lib/ внутри cgi-bin/ с двоичными файлами и библиотеками вспомогательных вещей?

Я опишу конкретный пример, а именно с приложением для построения графиков и математических данных gnuplot и его зависимостями (libfontconfig, libpng, libgd, libjpeg, libreadline.so, ...).
Python может быть другим примером (дистрибутив предоставляет 2.4, но мне нужно > 2.6), однако я надеюсь, что администратор сможет установить 2.6 из пакета, поэтому у меня нет беспокоиться об этом.

Новый веб-сервер имеет Scientific Linux (SL), основанный на Redhat RHEL. К сожалению, репозиторий дистрибутива для нашей текущей версии SL не предоставляет нужную мне версию gnuplot 4.4, поэтому его нельзя установить в обычном месте, таком как /usr/bin/, поэтому я мог бы собрать и установить его и его зависимости в несистемном месте, например cgi-bin/tools/. Фактические веб-приложения CGI представляют собой двоичные исполняемые файлы, запускаемые сценариями launch1.sh или launch2.sh.

Вот иллюстрация дерева каталогов и некоторых файлов в нем (конечно, многие каталоги и файлы опущены).

cd /home/www_maintainer/www_root/

|-- html/
|   |-- index.html
|   `-- info.html
|-- cgi-bin/
|   |-- gen/
|   |   |-- status.sh*
|   |   `-- sybase/
|   |       `-- DataAccess64/
|   |           `-- ODBC/
|   |               |-- lib/
|   |               |-- samples/
|   |               `-- spl/
|   |-- exe1/
|   |   `-- launch1.sh*
|   |-- exe2/
|   |   `-- launch2.sh*
|   |-- javascript/
|   |   `-- check-input.js
|   |-- scripts/
|   |   |-- decode.pl*
|   |   |-- generate-random-string.bash*
|   |   |-- gnuplot -> ../tools
|   |   `-- upload.php*
|   |-- tools
|   |   |-- bin/
|   |   |   |-- gnuplot*
|   |   |   |-- python -> python2.6
|   |   |   |-- python-config -> python2.6-config
|   |   |   |-- python2.6*
|   |   |   |-- python2.6-config*
|   |   |   `-- xmlwf*
|   |   |-- etc
|   |   |   `-- fonts/
|   |   |-- include/
|   |   |-- info/
|   |   |-- lib/
|   |   |   |-- libfontconfig.so
|   |   |   |-- libpdf.so
|   |   |   |-- libreadline.so
|   |   |   |-- libpng15.so
|   |   |   |-- libpng15.so
|   |   |   |-- pkgconfig/
|   |   |   |-- libpng.so
|   |   |   |-- libjpeg.so
|   |   |   |-- libreadline.so
|   |   |-- libexec/
|   |   |-- man/
|   |   `-- share/
|-- tests/
|   `-- results/
|       `-- info/
|           |-- readme.pdf
|           `-- readme.html
|-- fonts/
|-- index.html -> html/index.html
|-- log/
|   `-- log.txt
`-- tmp -> /tmp/


Не лучше ли установить за пределами www_root, например, в каталоге /home/www_maintainer/bin/ и /home/www_maintainer/lib/, и настроить веб-сервер, чтобы разрешить это?


person user1069609    schedule 14.05.2012    source источник


Ответы (1)


РЕДАКТИРОВАНИЕ: 23 мая 2012 г., 15:00 по тихоокеанскому времени, США

Если вы ограничены каталогом пользователя, вы можете делать практически все, что захотите.

Что раньше было распространенным случаем, так это то, что вы помещаете все файлы, использующие CGI (Perl и т. д.), в каталог cgi-bin, и вы можете (и, вероятно, должны) помещать их в подкаталоги в зависимости от цели или приложение.

Затем вы помещаете не-CGI-файлы вне каталога cgi-bin, который включает в себя любые чистые HTML-файлы, графические файлы, файлы CSS, файлы JS и т. д.

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

Пример дерева каталогов:

/home/www_maintainer/public_html/index.html
/home/www_maintainer/public_html/images/logo.png
/home/www_maintainer/public_html/scripts/something.js
/home/www_maintainer/public_html/cgi-bin/application1/app1.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2helper.cgi
/home/www_maintainer/tools/gnuplot/gnuplot
/home/www_maintainer/tools/python/python -> python2.6
/home/www_maintainer/tools/python/python2.6
/home/www_maintainer/tools/python/python2.6-config

Затем в ваших файлах CGI убедитесь, что пути к tools указаны правильно, как это необходимо. Веб-пользователям нет необходимости обращаться к этим инструментам напрямую, поэтому держите их вне доступа. Если вы выполняете python через CGI (что я предполагаю в данном случае), убедитесь, что ваша строка shebang показывает правильный путь; #!/home/www_maintainer/tools/python/python, например.


Исходный ответ:

Что делают многие приложения, например те, что распространяются вместе с Debian, помещают свои приложения в каталог /usr/share/lib/programname, а затем используют Apache Alias и ScriptAlias для сопоставления их с базовым URL-адресом. Именно так я запускал наши собственные приложения, разработанные внутри компании, и это работало очень хорошо.

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

У вас есть какие-нибудь конкретные примеры, которые я мог бы использовать, чтобы продемонстрировать то, что я описал?

Кроме того, что касается древнего /usr/bin/python, ваша система полностью обновлена? Или проблема в том, что ваш дистрибутив Linux просто не поддерживает более новую версию? Я бы не стал устанавливать версию Python, которой не управляет система управления пакетами вашего дистрибутива.

person Emmaly Wilson    schedule 19.05.2012
comment
Большое спасибо! Я отредактировал вопрос, включил конкретный пример проблемы и иллюстрацию структуры каталогов веб-сервера. - person user1069609; 23.05.2012
comment
Это помогло? До того, как ваша награда отправится в мусорку, осталось всего пять часов... - person Emmaly Wilson; 24.05.2012
comment
Абсолютно. Вы должны получить награду сейчас, так как я принял ваш ответ. - person user1069609; 24.05.2012
comment
У меня есть, да. Довольны ли вы ответом или вам нужна дополнительная информация? Если да, дайте мне знать, чего не хватает. - person Emmaly Wilson; 25.05.2012