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

Question

Я поддерживаю некоторые веб-приложения CGI, которые я переношу на новый веб-сервер Linux, на котором у меня есть учетная запись, отличная от admin, например 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, e.g.in директории /home/www_maintainer/bin/ и /home/www_maintainer/lib/ и настроить веб-сервер, чтобы разрешить это?

Answer 1

EDIT: 05/23/2012 PT 3 вечера US

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

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

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

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

Каталог пример дерева:

/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, которая не управляется системой управления пакетами вашего дистрибутива.