Основная идея нашего варианта пакета — дать возможность эксплуатации нескольких независимых друг от друга экземпляров Zope (в пакете rpm, полученном в рамках проекта Zope, такой возможности нет). Для каждого такого экземпляра создается домашний каталог, содержащий специфические для него файлы: прикладные пакеты, внешние процедуры и собственно базу данных — ZODB3.
Пакет содержит скрипты и файлы настройки, обеспечивающие интеграцию Zope с остальными компонентами операционной среды. Обеспечиваются следующие возможности:
перезапуск сервера при перезагрузке системы,
переупаковка базы данных,
создание нового экземпляра сервера.
В нашем пакете, код Zope версии 2.6.1 изменен применением нескольких патчей, исправляющих ошибки, затрудняющие его эксплуатацию.
В Zope 2.6.0 появилась и продолжает развиваться поддержка unicode. Из-за особенностей ее реализации, сервер потерял возможность нормальной работы с национальными языками (в т.ч. с русским) в режиме, отличном от unicode.
Это патч устраняет ошибки в новом коде Zope и делает возможной полноценную работу с сервером в любой кодировке (подробнее см. файл UnicodePatch.txt).
Обычно, экспортируемые реплики попадают в каталог ./var экземпляра Zope, что вызывает некоторые проблемы: это тот же каталог где лежит сама база Z-объектов, и любые операции над файлами в этом каталоге чреваты ошибками, приводящими к полной потере данных.
Применение данного патча вынуждает сервер экспортировать реплики в каталог ./export экземпляра Zope, если таковой был предварительно создан. Это снижает возможный ущерб от ошибок при выполнениии различных технических операций.
Привязка пакета к операционной среде определяется следующими конфигурационными файлами:
Конфигурация экземпляров сервера по умолчанию, параметры из этого файла загружаются до файла конфигурации экземпляра;
Каждый файл в этом каталоге является конфигурационным файлом экземпляра сервера;
Список виртуальных хостов Zope, доступных через модуль proxy веб-сервера Apache, если он используется (см. также /etc/httpd/conf/zope_proxy.conf).
Формат файла — две колонки: первая колонка содержит имя виртуального хоста, вторая — URL соответствующего объекта в Zope. URL url может содержать протокол http или localhttp (условный протокол, разрашающий обращение только с адресов, перечисленных в файлк /etc/sysconfig/zope_local.cfg).
Список ip-адресов хостов и сетей, из которых разрешен доступ к виртуальным хостам Zope, для которых указан протокол localhttp. Обратите внимание: доступ к контрольной панели Zope разрешен только через протокол localhttp.
Формат файла — две колонки: первая колонка содержит IP-адрес хоста или сети (указывается префикс сети, например 192.168.0), вторая - слово "allow", если доступ разрешен.
Дополнительный конфигурационный файл к веб-серверу Apache, его использование должно быть явно разрешено в конфигурационном файле Apache. Конфигурационный файл описывает использование модулей proxy и rewrite для доступа к виртуальным серверам, хранимым в Zope. Список виртуальных серверов вносится в /etc/sysconfig/zope_hosts.cfg.
Каждый из конфигурационных файлов zope_default и /etc/sysconfig/zope/* содержит строки вида:
<СТРОКА> :== <ПЕРЕМЕННАЯ> '=' <ЗНАЧЕНИЯ>
Предполагается наличие следующих переменных:
Рабочая зона экземпляра Zope. Содержит все данные, расширения и продукты уникальные для этого экземпляра;
Каталог, в котором расположен шаблон домашнего каталога. Из этого каталога утилита addzopesite.py копирует файлы при создании нового домашнего каталога;
Каталог, в котором расположены рабочие зоны экземпляров серверов. Если при создании экземпляра не указывать полный путь, а указать только идентификатор, то рабочая зона для этого экземпляра будет создана в этом каталоге и её имя будет совпадать с идентификатором;
пользователь, под которым запускается Zope;
базовый порт, относительно которого захватываются порты Zope:
http-сервер;
ftp сервер;
количество тредов в стартующем сервере;
количество дней между переупаковками сервера;
игнорировать наличие данного экземпляра сервера при старте, если данный сервер не был указан явно (0 — запускать, 1 — игнорировать);
имя сервера, отображаемое в сообщениях скриптов и др.;
локаль сервера по умолчанию. Если не указана — сервер стартует без ключа -L и игнорирует какие-либо установки локали. Для не-англоязычных серверов это может оказаться фатальным: не будет работать поиск посредством ZCatalog и форматирование с использованием StructuredText. Кроме того, начиная с версии 2.6.0, будет невозможно использовать страницы управления свойствами.
если установлена и не равна 0, то Zope будет работать в режиме профилирования. Посмотреть текущий профиль Zope можно на вкладке ControlPanel/DebugInfo/manage_profile. Для профилирования используется файл /var/tmp/zope.<ИДЕНТИФИКАТОР>.profile; Убедитесь, что в этом каталоге достаточно места.
включить трассировку запросов: будет создан специальный лог /var/log/zope/<ИДЕНТИФИКАТОР>.trace.log, в котором будет сохраняться подробная трассировка запросов к серверу с указанием отметок времени;
включить журналирование отладочной информации (/var/log/zope/<ИДЕНТИФИКАТОР>.stupid.log), в котором будет сохраняться вывод отладочной информации о работе сервера. Содержимое журнала является подмножеством того, что выводится на консоль при старте в отладочном режиме;
если установлена и не равна 0, то при старте в отладочном режиме Zope будет монтировать хранилище в режиме READONLY: все завершённые транзакции будут сохраняться во временной памяти и при рестарте Zope произойдет автоматический откат изменений.
тип хранилища;
Файл, в который перенаправляется вывод по каналам STDERR и STDOUT - редко когда нужно, но при тяжелой отладке Z-продукта идущей далеко не первый день - незаменимо. При старте в отладочном режиме опция игнорируется : все выводится на терминал.
Существует несколько типов хранилищ для Zope, практически все из них находятся в состоянии вечных бета-версий, тем не менее при некоторых обстоятельствах оказывается интересным использовать хранилище, отличное от стандартного ZODB или же ZODB, смонтированное в нестандартном режиме (например «только для чтения»).
Обычный способ нестандартного монтирования хранилищ — размещение в каталоге /usr/lib/zope/lib/python модуля custom_zodb.py, который и выполняет собственно монтирование. Мы включили в наш дистрибутив готовый модуль custom_zodb.py, управлять которым можно посредством переменных ZOPE_STORAGE и ZOPE_READONLY конфигурационных файлов экземпляра сервера.
Переменная ZOPE_STORAGE может принимать одно из следующих значений:
обычное хранилище ZODB;
хранилище BerkeleyDB в режиме Packless;
хранилище BerkeleyDB в режиме Minimal;
хранилище BerkeleyDB в стандартном режиме;
Для любого из этих хранилищ может быть установлена переменная ZOPE_READONLY, после чего все закрываемые транзакции будут записываться во временное хранилище и исчезнут при перезапуске сервера (таким образом работает сервер http://demo.neural.ru).
Серьезному тестированию работоспособности подвергалось только хранилище ZODB — как в нормальном режиме, так и в режиме «только для чтения» (READONLY), остальные типы хранилищ добавлены исключительно для тех, кто знает, что делает. Мы не поддерживаем хранилище ZEO (хотя частично протестировали возможность такой поддержки), так как считаем, что большая часть пользователей не заинтересована в нём, а остальные могут собрать пакет сами.
С помощью этой утилиты вы можете создать новую рабочую зону для сервера Zope, установить права доступа к файлам и зарегистрировать зону в конфигурационных файлах. При создании экземпляра Zope в него копируется файл inituser, что вызывает при старте сервера установку суперпользователя admin с паролем 12345678 — помните, сразу после старта сервера вы должны создать другого пользователя, дать ему роль Manager и стереть пользователя admin.
каталог, в котором будет установлена рабочая зона экземпляра сервера, в простейшем случае указывается идентификатор экземпляра, при этом установка производится в каталог /var/lib/zope/<КАТАЛОГ_ДЛЯ_УСТАНОВКИ>, если параметр начинается с символа «/» — то он рассматривается как путь к каталогу для установки от корня сервера;
базовый порт, от которого будут отсчитываться рабочие порты Zope.
пользователь;
группа;
путь к прототипам;
конфигурация по умолчанию;
каталог с конфигурациями серверов;
название сервера;
идентификатор сервера;
количество тредов;
вносить в новую конфигурацию все переменные (иначе вносятся только необходимые);
локаль, которая будет установлена для сервера;
тип используемого хранилища;
хранилище [не]должно монтироваться в режиме readonly;
в[ы]ключить профилирование;
в[ы]ключить отладочный логинг;
в[ы]ключить трассировку запросов;
Эта утилита должна вызываться на регулярной основе, чтобы выполнять переупаковку ZODB
трассировка выполнения;
помощь;
игнорировать все операции;
количество дней при упаковке данных;
доля свободного пространства по отношению к размеру базы, при котором запускается переупаковка;
доля свободного пространства по отношению к размеру базы, при котором переупаковка считается невозможной;
принудительная упаковка, модификаторы: 1 — игнорировать игнор, 2 — игнорировать max_ratio, 3 — игнорировать min_ratio;
конфигурация по умолчанию;
каталог с конфигурациями серверов.
Сценарий для System V init scripts, выполняющий запуск сервера Zope в различных режимах и его останов.
экземпляры Zope, которые будут затронуты командой; если параметр не передан, то команда последовательно выполняется для всех экземпляров;
Утилита используется для создания хранилища с последующим его использованием в Zope в качестве основного или монтируемого хранилища.
пользователь;
группа;
конфигурация по умолчанию;
каталог с конфигурациями серверов;
создать точку монтирования;
идентификатор точки монтирования;
тип создаваемого хранилища;
Установка и первоначальная настройка Zope включает в себя следующие шаги.
Для установки пакетов необходимо дать команду вида :
rpm -ivh Zope-2.6.*rpm \
Zope-Module-2.6.*.i586.rpm \
Zope-core-2.6.*.i586.rpm \
Zope-DateTime-2.6.*.i586.rpm \
Zope-DocumentTemplate-2.6.*.i586.rpm \
Zope-RestrictedPython-2.6.*.i586.rpm \
Zope-StructuredText-2.6.*.i586.rpm \ Zope-TAL-2.6.*.i586.rpm \
Zope-Testing-2.6.*.i586.rpm \ Zope-ZHome-2.6.*.i586.rpm \
Zope-ZODB-2.6.*.i586.rpm \
Zope-ZPublisher-2.6.*.i586.rpm \ Zope-ZServer-2.6.*.i586.rpm \
Zope-ZUtils-2.6.*.i586.rpm
Если вы используете APT, то более простой и правильный способ установки:
apt-get install Zope
В процессе установки этих пакетов проводится ряд настроек:
создаётся пользователь и группа Zope, под которыми, по умолчанию, будет работать сервер;
создаётся рабочая зона Zope: /var/lib/zope;
устанавливаются вспомогательные пакеты Zope, эти пакеты могут использоваться без использования Zope;
устанавливается сам Zope;
После установки пакетов одна рабочая зона уже будет создана — var/lib/zope/basic. Вы можете добавить дополнительные рабочие зоны вызовом скрипта addzopesite.py (например, сама зона basic была создана командой addzopesite.py basic 8000).
здесь 8000 — номер базового порта, от которого отсчитываются порты веб-сервера (базовый порт + 80) и ftp (базовый порт + 21)
По умолчанию, вновь созданная рабочая зона не является автоматически запускаемой, т.е. при перезагрузке системы сервер для этой рабочей зоны не будет запущен. Изменить ситуацию можно установив в значение 0 параметр ignore в файле /etc/sysconfig/zope/<ИМЯ РАБОЧЕЙ ЗОНЫ> (/etc/sysconfig/zope/basic для основной зоны).
Первый раз стартовать сервер лучше в отладочном режиме, командой /etc/rc.d/init.d/zope debug <ИМЯ РАБОЧЕЙ ЗОНЫ>, например /etc/rc.d/init.d/zope debug test.
При работе в отладочном режиме, сервер будет выводить отладочную информацию на терминал, с которого он запущен. Это удобно при диагностировании проблем, вызываемых установкой некорреткно работающих программных продуктов;
В любой вновь созданной рабочей зоне есть пользователь admin с паролем 12345678. Единственная операция, которая может быть выполнена от имени этого пользователя — редактирование других пользователей. Поэтому рекомендуется создать пользователя с ролью «Manager» и удалить пользователя admin, после чего все работы проводить от имени пользователя с ролью «Manager». Чтобы сделать это, стартуйте сервер и проделайте следующие шаги:
Запустите ваш любимый броузер
Введите URL http://127.0.0.1:8080/manage
В появившемся запросе на ввод логина и пароля введите логин «admin» и пароль «12345678».
Перейдите в папку acl_users (http://127.0.0.1:8080/acl_users/manage)
Нажатием кнопки «» добавьте пользователей, хотя бы один из которых должен иметь роль «Manager» и «Owner».
Удалите пользователя admin. При возникновении аварийных ситуаций вы сможете создать его заново утилитой /usr/sbin/zpasswd, так что его удаление вполне безопасно, чего нельзя сказать о противоположном случае: дело в том, что из-под этого пользователя нельзя создавать какие-либо объекты, т.к. работать нормально они всё равно не смогут. Обычно Zope блокирует такие попытки, но есть способы это обойти
Введите URL
В появившемся запросе на ввод логина и пароля введите логин и пароль пользователя с ролью "Manager".
В дальнейшем, пользователь с ролью Manager всегда может изменить логины и пароли других пользователей. Если будут утеряны все логины и пароли пользователей с ролью Manager, то можно создать пользователя admin, используя утилиту zpasswd.py, и затем повторить все шаги данного раздела.
Все сайты, создаваемые с использованием сервера приложений Zope, рекомендуется запускать за proxy-сервером, в качестве которого может использоваться веб-сервер Apache с активированным модулем mod_proxy. Такое решение позволяет обеспечить более высокую производительность, создавать сайты для виртуальных доменов и защитить Zope от некоторых направленных против него атак.
В пакет Zope-ZUtils-2.6.*.i586.rpm входит дополнение к конфигурационному файлу Apache, /etc/httpd/conf/zope_proxy.conf, содержащее пример настройки web-сервера. С этими настройками веб-сервер будет читать содержимое файла /etc/sysconfig/zope_hosts.cfg и для перечисленных в нём виртуальных серверов запросы будут отображаться на каталоги Zope, при этом контекст обработки запроса настраивается экземпляром класса VirtualHostMonster, предварительно созданного в корне сайта: иначе базовые URL будут строиться неверно.
Чтобы активировать mod_proxy необходимо:
В конфигурационном файле /etc/httpd/conf/httpd.conf раскомментировать следующие строки:
LoadModule rewrite_module modules/mod_rewrite.so LoadModule proxy_module modules/libproxy.so AddModule mod_rewrite.c AddModule mod_proxy.c
Желательно убрать из файла существующее определение прокси, хотя всё будет работать и с ним.
В конец файла добавить вызов конфига прокси директивой:
Include conf/zope_proxy.conf
(Обратите внимание на то, что данный файл должен существовать. Он входит в пакет ZUtils).
Перезапустить web-сервер командой /etc/rc.d/init.d/httpd restart
Список виртуальных серверов хранится в файле /etc/sysconfig/zope_hosts.cfg, каждая строка которого соответствует одному виртуальному серверу и содержит два параметра: URL, видимый при обращении к прокси, и URL, на который такие обращения будут отображаться. Например, для сервера zope.localdomain:
zope.localdomain http://localhost:8080/VirtualHostBase/http/zope.localdomain:80/Zope/Main/VirtualHostRoot
Каталоги VirtualHostBase и VirtualHostRoot не должны специально создаваться: это псевдоимена, активирующие объект класса VirtualHostMonster, расположенный в корневом объекте Zope, и вызывающие переопределение среды таким образом, что в качестве базового URL при обработке запроса будет использоваться http://zope.localdmain:80/, а пути будут отсчитываться от каталога /Zope/Main. Это совсем не тоже самое, что chroot на файловой системе, но приводит к сходным последствиям при программировании.
После того, как отображение виртуального сервера добавлено в Конфигурацию прокси, можно создать контейнер под этот сервер в Zope. Мы рекомендуем для любого виртуального сервера создавать в иерархии Zope два уровня контейнеров:
контейнер служебного уровня («подвал»), имя которого совпадает с именем виртуального сайта;
вложенную в него каталог Main, содержащую корень сайта.
При таком планировании сервера, в контейнере служебного уровня будут размещаться файлы, необходимые для дизайна, коннекторы к базам данных и почтовым серверам, контейнеры авторизации пользователей (acl_users) и хранимые процедуры, а в каталоге Main Main — собственно контент-наполнение сайта.
Вы должны создать объект класса VirtualHostMonster в корне сайта, для этого нужно набрать в броузере URL http://localhost:8080/manage и добавить объект (пункт меню Add VirtualHostMonster) с именем VirtualHostMonster. Без добавления этого объекта при обращении к серверу через proxy не произойдет смещение корня виртуального сайта, и вы получите ошибку 404 (not found);
После выполнения предыдущих шагов, при вводе URL http://zope.localhost вы должны увидеть страницу index_html означенную в контексте папки Zope/Main. Обратите внимание, все вычисляемые ссылки (конструкцией вида <dtml-var absolute_url>) должны указывать на URL сайта .
Достаточно привлекательной кажется идея использования для закрытия канала между сервером и пользователем модуля mod_ssl веб-сервера Apache. Входящий в наш пакет конфигурационный файл Apache zope_proxy.conf предусматривает такой механизм. Для его активации вы должны проделать следующее (предполагается, что вы уже настроили сервер для обычной работы):
Установить модуль mod_ssl для веб-сервера Apache. >При установке модуля будет создан каталог /etc/httpd/conf/ssl, содержащий конфиги mod_ssl;
После установки модуля вы должны сгенерировать ключи к серверу обычным способом — т.е. так, как это описано в руководстве к apache, mod_ssl и openssl;
Файл /etc/httpd/conf/ssl/ssl.default-vhost.conf содержит конфигурацию доступа к сайту по умолчанию. Вы должны добавить в эту конфигурацию непосредственно перед закрывающей скобкой вызов того же конфигурационного файла, что и для обычного сайта, чтобы в защищённом режиме также происходила обработка виртуального хостинга. Конец файла после добавления должен выглядеть так:
Include conf/zope_proxy.conf </VirtualHost>
Такая конфигурация, возможно, не совсем идеальна, но достаточна для демонстрации принципа решения.
Перезапустите Apache;
Для проверки попробуйте ввести в броузере URL вида http://zope.localdomain/ и https://zope.localdomain/.
В обоих случаях вы должны увидеть ваш сайт, в последнем случае может (а может и должно) появиться предупреждение об установлении защищённого канала.
Как должна была показать проверка, проведённых настроек вполне достаточно для того, чтобы пользователи могли работать с сайтом как через http, так и через https. Но желательно, чтобы через https работали только зарегистрированные пользователи, тогда как обычным лучше работать через http (кеширование, нагрузка на аппаратное обеспечение при выполнении процедуры шифрования и т.п.). Кроме того, желательно гарантировать, чтобы никто из авторизованных пользователей вследствие ошибок или же злого умысла не начал работать через http.
Простейший способ добиться этого — выполнить перенаправление на https-канал при попытке авторизации. Если на вашем сайте используется http-авторизация, то раскомментируйте в файле zope_proxy.cfg следующие строки:
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{HTTP:Authorization} ^Basic.*
RewriteRule ^(.*) https://%{HTTP_HOST}$1 [R,L]
Теперь, увидев в запросе заголовок авторизации, Apache инициирует перенаправление на защищённый канал.
Для проверки такого перенаправления попробуйте ввести в броузере URL вида http://zope.localdomain/manage. Обычно этот URL используется для входа в интерфейс управления Zope. Если сайт использует http-авторизацию, то вы увидите запрос для ввода логина и пароля, а после удачного ввода обнаружите что уже работаете в с URL вида https://zope.localdomain/manage.
Обратите внимание, что уведомление о входе в https-режим появилось уже после ввода пароля: это означает, что вы, к сожалению, всё же передали пароль по открытому каналу. Такое автоматическое перенаправление не гарантирует сокрытия вашего пароля, но гарантирует, что авторизованные пользователи после ввода пароля будут работать только по https.
Для гарантированного сокрытия пароля вы должны либо явно вызывать https сразу при попытке обращения к закрытой части ресурса (попробуйте настроить соответствующим образом ссылки на вашем сайте), либо вызывать редирект на https до выполнения авторизации, по факту обращения к защищаемой странице.
Это было бы легко сделать, если бы не гибкая система настройки прав в Zope: любая страница может быть защищена. Таким образом, мы не можем предложить универсального решения, но можем предложить решение частного случая: редирект при попытке доступа к ZMI.
Чтобы включить такой редирект, раcкомментируйте в zope_proxy.cfg следующие строки:
RewriteCond %{SERVER_PORT} !^443$
RewriteCond $1 .*/manage_.*
RewriteRule ^(.*) https://%{HTTP_HOST}$1 [R,L]
Этот код будет инициировать перенарправление при обращении к странице вида «.*manage.*», т.е. странице интерфейса ZMI.
Хотя работа через https возможна и для других способов авторизации, автоматический редирект в момент авторизации будет организовать несколько труднее. Для частного случая использования mysqlUserFolder можно попробовать раскомментировать следующие строки в zope_proxy.conf:
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{HTTP_COOKIE} .*__ac_user.*
RewriteRule ^(.*) https://%{HTTP_HOST}$1 [R,L]
Дальнейшая эксплуатация сайта требует регулярного выполнения таких операций, как переупаковка базы данных и репликация каталогов сайта. Объектная база ZODB3, поверх которой построен сервер приложений, предоставляет возможность отменяемых транзакций: любая последовательность операций, изменяющих содержимое базы данных, может быть отменена без потери целостности сайта. Это полезное свойство имеет побочный эффект: при любых изменениях размер базы данных увеличивается. Именно поэтому, на регулярной основе, должна инициироваться процедура переупаковки базы, стирающая старые версии объектов. Эта процедура может быть инициирована со страницы http://zope.localhost/Control_Panel/Database/manage_pack, где можно указать параметры упаковки, но, так как процедура должна проводится на регулярной основе, в состав нашего пакета Zope-ZUtils входит скрипт, инициирующий процедуру переупаковки по crontab посредством утилиты zope_pack.py.
Скрипт запускается ежедневно, но переупаковка базы инициируется при соблюдении двух условий:
База занимает объем не меньше указанного в процентах от свободного пространства на диске;
Свободное пространство на диске не меньше указанного в процентах от размера базы.
Эти параметры хранятся в конфигурационном файле /etc/sysconfig/zope_default.cfg. Скрипт проверяет все экземпляры сервера, конфигурационные файлы которых размещены в /etc/sysconfig/zope.
Профилактическое архивирование сайтов, размещённых в Zope, может осуществляться сохранением базы ZODB3 /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>/var/Data.fs или репликацией отдельных папок сервера приложений. В первом случае ряд источников рекомендует пользоваться утилитой rsync (см. http://www.zope.org), но второй подход существенно более удобен и может выполняться, например, регулярным запуском команды wget со строкой вида :
wget -sS -O <ID> $(date +%Y%m%d).zexp \ "http://<LOGIN>:<PASSWD>@localhost:8080/manage_exportObject?download:int=1&id=<ID>"
идентификатор сохраняемой папки в корне Zope;
логин пользователя в Zope;
пароль пользователя в Zope;
При этом сервер отдаёт файл реплики в формате zexp. Вы можете получать реплику в формате *.xml, но: это будет работать более медленно, процесс репликации при ряде условий может сбоить и полученная реплика может занимать существенно больший объём — иными словами, это не выгодно.
Реплика может быть восстановлена импортом в Zope — в тот же самый экземпляр сервера или в любой другой. Для этого реплика должна быть размещена в каталоге /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА/import, после чего импорт может быть инициирован нажатием на кнопку «import/export» в любом контейнере менеджерского интерфейса. Подробно импорт реплик описан в ImportSite.txt.
Эксплуатация сайта также включает в себя решение ряда административных проблем, связанных с устранением ошибок и противостоянием вторжению. Существует ряд пакетов, помогающих справится с этими проблемами, часть которых подробно описана в InstallExtensionPackages.txt, кроме того, Digital Creations регулярно выпускает так называемые Hotfixes к текущим версиям Zope: Hotfix не изменяет сервер и не требует выполнения сложных процедур миграции сервера, он лишь в момент старта сервера переопределяет часть методов, исправляя таким образом ошибки, связанные, как правило, с дырами в защите. Hotfixes должны размещаться в каталоге /usr/lib/zope/lib/python/Products, более подробно процедура их установки описана в InstallExtensionPackages.txt и на сайте .
В заключении просто дадим ряд ссылок:
http://www.zope.org — сайт Zope, содержит продукты расширения и много подробной документации;
http://www.python.org — Zope реализован на языке Python, этот сайт содержит всю необходимую документацию;
http://www.neural.ru — мой сайт, я на нём вывешиваю некоторую информацию по поддерживаемым пакетам.
Сервер приложений Zope позволяет делать реплики базы данных и сохранять содержимое сайта в переносимом формате. При соблюдении ряда условий, такая реплика может быть впоследствии импортирована в новый сервер. Благодаря этому возможна разработка сайтов «под заказ» на сервере исполнителя и передача готового сайта заказчику в виде реплик базы данных, внешних процедур и определений объектов. Данный документ описывает обычную процедуру восстановления реплик такого сайта и проблемы, которые могут при этом возникнуть.
Как правило, результаты работ передаваемые заказчику включают в себя следующие группы файлов, точные названия вы должны уточнить у поставщика:
Реплики базы ZODB3, содержащие сам сайт — обычно файлы с расширением *.zexp, импортируемые в корень Zope.
Реплики базы ZODB3, содержащие определения Z-объектов — обычно файлы с расширением *.zexp, импортируемые в папку /Control_Panel/Products.
Внешние процедуры — обычно файлы с расширением *.py, размещаемые в каталоге Extensions экземпляра Zope.
Специализированные модули расширения Zope — архивы модулей расширения, идентичные описанным в InstallExtensionPackages.txt.
Реплики внешних баз данных — обычно используются реплики базы MySQL.
Вспомогательные скрипты и утилиты серверной части — состав, формат и правила установки определяются производителем.
В последующих разделах будут подробно описаны процедуры установки этих файлов, рекомендуется выполнять их именно в этом порядке.
Поставщик должен предупредить вас, какие именно значения параметров подключения (хост, порт, логин, пароль и т.п.) используются со стороны Zope, в противном случае установка реплик, содержащих некоторые продукты (например, mysqlUserFolder) может оказаться невозможной. Подавляющее большинство баз данных не поддерживаются стандартной поставкой Zope (единственное исключение — ZGadFly, демонстрационная SQL-база). Поэтому вы должны установить коннекторы к используемой вами базе данных. Для Zope 2.6.1 рекомендуемые коннекторы:
Пакеты ZMySQLDA-2.0.8, MySQL-python-0.9.2: в варианте, поддерживаемом нами, отключено порождение исключений при невозможности отката транзакций, кроме того, пакет ZMySQLDA-2.0.8 был доработан для совместимости с MySQL-python-0.9.2: обычный пакет работать правильно не будет;
Пакеты psycopg-1.0.12, psycopg-ZPsycopgDA-1.0.12: пожалуйста, не используйте другие коннекторы, или, по крайней мере, не пишите нам о том, что они не работают: наш выбор — коннектор psycopg
Как правило, процесс установки таких модулей идентичен описанному в InstallExtensionPackages.txt и не вызывает проблем какого-либо рода за исключением необходимости установить другие пакеты, на которые ссылаются данные.
Если не указано обратное, просто разместите внешние процедуры в каталоге /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>/Extensions
В первую очередь должны импортироваться реплики с определениями Z-объектов, следом за ними — реплики, содержащие сам сайт. Для выполнения импорта, все реплики нужно положить в каталог /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>/import
Определения Z-объектов импортируются в папку /Control_Panel/Products, для этого:
Введите URL /Control_Panel/Products/manage.
Нажмите на кнопку «».
Внизу страницы найдите форму импорта.
В поле «import file name» введите имя файла реплики.
Выберите «Take Owner Ship of imported objects».
Нажмите кнопку «».
Если продукт импортирован удачно, папка продукта должна появиться на вкладке /Control_Panel/Products/manage_main.
Сами сайты, как правило, импортируются в корневую папку, для этого:
Введите URL /manage;
Нажмите на кнопку «».
Внизу страницы найдите форму импорта.
В поле «import file name» введите имя файла реплики.
Нажмите кнопку «».
Если сайт импортирован удачно, папка с ним должна появиться на вкладке /manage_main;
Если импортируемый сайт содержит SiteRoot, то скорее всего вы должны изменить настройки прокси, чтобы переадресовывать обращения к этому сайту. Если вы используете Apache mod_proxy и наш конфигурационный файл Apache, то конфигурационный файл должен быть включен в /etc/httpd/conf/httpd.conf директивой Include conf/zope_proxy.conf, а доступ к новому сайту прописывается в файле /etc/sysconfig/zope_hosts.cfg в следующем формате:
<ИМЯ ВИРТУАЛЬНОГО ХОСТА> <URL реального хоста>
, например:
zope.localdomain http://10.0.0.9:8080/Zope/Main
Помните, что единственный способ отредактировать SiteRoot — это стереть его, а ухищрения типа SUPPRESS_SITEROOT=1 — лишь способ, облегчающий его стирание.
Если для доступа к импортируемому сайту использовался VirtualHostMonster, то строчки в файле /etc/sysconfig/zope_hosts.cfg будут немножко длиннее:
zope.localdomain http://localhost:8080/VirtualHostBase/http/zope.localdomain:80/Zope/Main/VirtualHostRoot
.
Как-либо редактировать или стирать VirtualHostMonster не надо, просто убедитесь, что в корневой папке Zope есть объект этого типа.
Если каким-либо методам назначены proxy-роли (т.е. проверка допусков при их обработке осуществляется так, как будто вызывавший их пользователь обладает такой ролью), то при выдаче прав будет выполняться проверка того, обладает ли этой ролью владелец этого метода. Если при импорте была изменена информация о владельцах таких методов, то обязательно проверьте, чтобы новый владелец существовал и обладал требуемыми ролями.
Связанные с этим проблемы чаще всего проявляются в запрете выполнения на сайте анонимным пользователем таких операций как регистрация, отправка сообщений в форум, использования почтовых и других форм. Если проблема возникла — попробуйте исправить поля Proxy Roles и Ownership для метода, выполняющего запрещенную операцию.
Особый случай — mysqlUserFolder. Без подробных комментариев: нужно создавать учётную запись администратора, логин которой совпадает с логином разработчика, создавшего объект mysqlUserFolder. Иначе использование mysqlUserFolder может приводить к труднообъяснимым ошибкам.
Сайт имеет SiteRoot и вписанное в него доменное имя нужно изменить. Рекомендуемые действия:
Перезапустите сервер с установленной переменной SUPPRESS_SITEROOT, например командой
SUPPRESS_SITEROOT=1 /etc/rc.d/init.d/zope restart <ИМЯ СЕРВЕРА>
Сотрите существующий объект SITE_ROOT (не тратьте время на его редактирование, не выйдет).
Создайте новый объект SITE_ROOT и при создании введите правильные данные.
Перезапустите сервер без переменной SUPPRESS_SITEROOT, например командой
/etc/rc.d/init.d/zope restart <ИМЯ СЕРВЕРА>.
Без подробных комментариев: редактирование объекта SITE_ROOT не работает. Всегда стирайте и создавайте его заново;
Какой-либо используемый продукт не существует. Тогда при попытке входа на страницу управления экземпляром класса этого продукта вы увидите надпись «This object is broken, because ...», исправить можно только одним способом — установить недостающий продукт.
Логичный выход — настроить её. К сожалению, это не всегда возможно: система авторизации может не поддерживаться в вашей среде, вам могут быть неизвестны пароли и тому подобные вещи. В тех случаях, когда есть или может быть получена XML-реплика, можно воспользоваться двумя способами. Способ первый: открыть реплику при помощи редактора и вычеркнуть из ObjectManager ссылку на идентификатор acl_users. Способ второй: сделать так:
sed -s "s/acl_users/acl_sonofbitch/g" <входная_реплика.xml >выходная_реплика.xml
После этого объекты acl_users перестанут быть таковыми, вы можете попробовать импортировать реплику обратно и стереть объекты acl_sonofbitch.
Использование таких подходов рекомендуется только в качестве последнего средства.
Сервер приложений Zope позволяет устанавливать расширения, дающие пользователям дополнительные возможности, такие как использование внешних баз данных, фильтрация и преобразование запросов, вспомогательные объектные модели для создания сайтов. Ниже описана процедура установки таких расширений и перечислен список расширений, рекомендуемых нами. Все эти расширения проверяются на совместную работу и тестируются на совместимость с текущей версией сервера. Если вы хотите расширить список поддерживаемых нами расширений, то свяжитесь с нами — <cray@neural.ru>.
Любой пакет расширения может быть установлен либо для использования всеми серверами, либо для использования одним из серверов. В первом случае корневой каталог пакета (т.е. каталог содержащий файл __init__.py) должен быть скопирован в каталог /usr/lib/zope/lib/python/Products, во втором — в каталог /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>/Products.
В любом случае сервер должен быть перезапущен.
Пакет расширения может быть получен в виде архива tar (в частности, в таком виде пакеты доступны на www.zope.org) или в виде пакетов RPM (в таком виде пакеты лежат в нашем дистрибутиве).
Пакеты RPM — из-за ряда ограничений, присущих как RPM, так и Python, устанавливаются только для всего сервера, для чего нужно дать команду rpm -ivh <ИМЯ ПАКЕТА>. При необходимости можно скопировать файлы продукта из каталога /usr/lib/zope/lib/python/Products в каталог /var/lib/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>/Products. Однако после этого вам необходимо стереть файлы с расширением *.pyc: rm -i *.pyc. По данным ряда источников, использование файлов *.pyc, построенных в другом каталоге, может приводить к сбоям в работе Python.
Есть ещё один вариант пакета расширения — пакеты в форматах zexp (xml), их установка подробно описана в ImportSite.txt.
Каким бы путём вы не устанавливали пакет, как правило, в результате его установки должен появится продукт в списке продуктов запущенного сервера, получить доступ к этому списку можно введя URL http://zope.localdomain:8080/Control_Panel/Products/manage_main и логин и пароль пользователя, имеющего роль «manager».
Особенностью, порождаемой концепцией заимствования в сервере приложений Zope, является то, что любой сайт имеет в принципе неограниченное множество допустимых URL. Такие URL могут строится, например, повторением элемента пути любое количество раз. Например, для URL http://zope.locadomain/Search/Forum существует бесконечное множество допустимых URL вида
"http://zope.locadomain/Search/" + "Search/" * n + "Forum"
, где n = [0:+inf]. Это не представляло бы проблемы, если бы не упорство роботов, выполняющих зеркалирование и индексирование сайтов и не ошибки в HTML и самих поисковых роботах: на сайте может появится ссылка на «неподвижную точку», т.е. ссылка вида
"http://zope.locadomain/Search/" + "Search/" * n + "Forum"
, вызывающая получение той же самой страницы, но содержащей ссылку вида:
"http://zope.locadomain/Search/" + "Search/" * (n + 1) + "Forum"
,
Очевидно, робот, перешедший по такой ссылке, попадает в бесконечный цикл, что вызывает проблемы не только у самого робота, но и у сайта: при достижении n величин порядка десятков и сотен такая деятельность робота больше напоминает DoS-атаку. Характерные примеры неподвижных точек — конструкции вида:
<a href="<dtml-var URLPATH0>/<dtml-var "getId()">"> _. </a>; <a href="<dtml-var "getId()">"> _. </a>
Или более сложные конструкции, использующие теги base и подобные возможности. Ситуацию осложняет то, что не все парсеры HTML обрабатывают относительные ссылки одинаково — причём именно дешёвые парсеры используемые в роботах страдают ошибками в этой области. Из-за этого проблема не может быть решена устранением ошибки в HTML, да и поиск неподвижной точки — достаточно сложная задача.
Продукт AqGuard позволяет решить проблему иначе: запретить использование url-ов в которых идентификатор одного и того же объекта повторяется больше некоторого порогового значения. Если такая ситуация обнаруживается, то AqGuard генерирует исключение AqGuardBlocked или вызывает специальный метод.
Установить пакет, как описано в начале документа;
Перезапустить защищаемый экземпляр Zope командой # service zope restart <ИМЯ_ЭКЗЕМПЛЯРА>
Войти в менеджерский интерфейс Zope введя URL вида http://zope.localdomain/manage
Войти в контейнер, в который вложены объекты и при отображении которых наблюдается это неприятное явление.
Создать в этом контейнере объект типа AqGuard. Желательно назвать его AqGuard — иначе возможны проблемы в старых версиях Zope.
Войти в объект AqGuard и выбрать вкладку «Настройка».
Подробно настройка AqGuard описана в файле помощи, здесь заметим только возможность указать пороговое количество повторений объектов установкой атрибута max_repeats: с атрибутами по умолчанию AqGuard будет блокировать появление любых имён в пути при обращении к объектам ниже содержащего его контейнера более четырёх раз.
Включить AqGuard установкой флага use_aqguard.
Ввести запрещённый теперь URL, чтобы проверить работоспособность — вы должны увидеть страницу с ошибкой: текст ошибки может быть изменён редактированием или перекрытием DTML-метода :
standard_error_message
или явным указанием обработчика ошибок.
Не рекомендуется оставлять в AqGuard настройки по умолчанию — это всегда работает, но далеко от оптимального.
Флуд — малоприятное явление, состоящее в том, что какой-то субъект заходит к вам на сайт, пишет двадцать сообщений в гостевой книге, начинает писать сам себе сообщения в форуме или даже пытается подобрать пароль к чьей-то учётной записи. По нашему опыту, такой субъект скорее всего на ваш сайт не зайдёт, но уж если зайдёт, то вам придётся пережить немало неприятных минут, объясняя высшему руководству вашей компании особенности протокола HTTP, HTML, TCP/IP и выслушивая основные положения КЗОТ.
Продукт FloodGuard даёт, возможно, не лучшее, но обобщённое решение проблемы: предоставляется возможность задать маску повторяющегося события и разрешённую частоту его повторений за указанный период времени с данного IP-адреса. Маска события включает в себя путь к объекту, возможно, заданный как регулярное выражение и ноль или более имён переменных.
Последовательностью событий считается появление совпадающих путей, снабжённых совпадающими значениями этих переменных. При превышении порогового значения генерируется исключение FloodGuardBlocked;
После установки пакета так, как описано в начале документа, вы должны его настроить и активировать, предприняв следующие шаги:
Войти в менеджерский интерфейс Zope введя URL вида
Войти в контейнер, содержащий объекты, в отношении отображений которых может быть предпринят флуд.
Создать объект типа FloodGuard, желательно с именем FloodGuard, иначе в ряде версий Zope возможны ошибки.
Войти в объект FloodGuard и выбрать вкладку «Настройка».
Подробно настройка описана в файле помощи, здесь отметим лишь возможность указать флаг use_referer — если он установлен, то при обращении с опознанной сигнатурой проверяется атрибут HTTP_REFERER запроса, и если он не указывает на тот же самый сайт, что и текущий, то запрос отбрасывается (это останавливает только особенно тупых злонамеренных флудеров, но их доля в общей массе может достигать заметных величин.
Вы должны указать сигнатуру запроса: по умолчанию, указана сигнатура запрещающая интенсивную работу с интерфейсом менеджера.
Установить флаг use_floodguard.
Отдать несколько раз запрос, удовлетворяющий сигнатуре атаки;
После перехода порогового значения должна отобразится страница с ошибкой, текст ошибки может быть изменен редактированием или перекрытием DTML-метода:
standard_error_message
или явным указанием обработчика ошибок.
Продукт FloodGuard позволяет посмотреть лог обращений с IP-адресами. Если Zope закрыт прокси-сервером, то прокси должен передавать IP-адрес в переменной ip, как это сделано, например, в нашем конфигурационном файле /etc/httpd/conf/zope_proxy.conf: прокси устанавливает переменную ip, если путь в URL заканчивается строчкой :ipset. Для нормальной работы FloodGuard все опознаваемые маски событий должны запрашиваться с такой строчкой и переменная ip должна быть указана в маске события: будьте внимательны в своих настройках!
Другой вариант передачи IP-адреса возможен при использовании HTTP/1.1 proxy (например apache > 1.3.27). Если такой прокси имеет место, вы должны установить флаг use_http11. Подразумевается, что прокси-сервер будет передавать IP-адрес в специальном заголовке.
Какой бы способ передачи IP вы не использовали, продукт будет устанавливать в запросе переменную REMOTE_ADDR в значение, равное этому адресу.
Особенностью пользователей российского Интернета является не только использование шести кодировок, но и то, что из всех доступных броузеров всегда выбирается тот, который обрабатывает их наиболее некорректным образом. При отсутствии ошибок, проблема кодировок полностью решается установкой заголовка charset, к сожалению, жизнь оказывается более суровой и ошибки имеют место. Устав объяснять счастливым обладателям решения от Microsoft причины непристойного поведения их броузера, мы написали этот продукт.
Не обращая внимания на то, под видом какой кодировки пытается броузер отдать запрос, определить реальную кодировку запроса по его содержанию и перекодировать в кодировку сервера.
Частотный анализ признаков.
Использование продукта на нескольких коммерческих сайтах продемонстрировало его способность противодействовать ошибкам в реализации работы с кодировками в броузерах некоторых известных компаний.
Последняя версия RequestDecoder легко интегрируется в сайт и обладает некоторыми дополнительными возможностями, скрашивающими жизнь редакторов сайта.
После обычной процедуры установки выполните следующие шаги:
Войти в менеджерский управления Zope введя URL вида http://zope.localdomain/manage
Войти в контейнер, содержащий объекты, при обработке запросов к которым запрос должен перекодироваться (например, корневой контейнер).
Создать объект типа RequestDecoder (желательно с именем RequestDecoder, иначе в ряде версий Zope возможны ошибки).
Войти в объект RequestDecoder и выбрать вкладку «Настройка».
Подробно настройка описана в файлах помощи, здесь отметим лишь возможность указать флаг use_censor — если он установлен, то запрос будет проверяться на наличие нецензурных выражений, рекомендуем вам сбросить этот флаг, если вы хотите использовать продукт на реальном сайте: флаг введен как опция, включающая прототип продукта SemanticGuard — любые предложения по ней приветствуются.
Вы должны перечислить регулярные выражения, описывающие пути к объектам, запросы к которым перекодируются. Настройки по умолчанию перекодируют запросы к интерфейсу управления.
Если вы хотите, чтобы RequestDecoder был по умолчанию активен, вы должны установить флаг use_decoder.
Если установлен продукт CrayFIX, то в левом фрейме появится кнопка, позволяющая включить или выключить RequestDecoder для текущей сессии.
Вы можете перейти на вкладку «тест» и ввести текст в неверной кодировке, протестировав таким образом перекодировщик. В текущей версии, RequestDecoder обслуживает только кодировки KOI8-R и Windows1251.
RequestDecoder содержит модельный прототип продукта SemanticGuard — продукта, проверяющего текст запроса в поиске запрещённых выражений и при их появлении генерирующий прерывание Uncensored. Разработчики обладают необходимыми знаниями в области лингвистических технологий, чтобы довести этот функционал до промышленного уровня, если пользователи найдут его полезным. В текущей версии это просто игрушка, позволяющая запретить ввод матерных выражений на сайте — эксперименты в её использовании крайне приветствуются, если будут отзывы, предложения и пожелания, то, возможно, работы над продуктом будут продолжены.
API для работы с базами PostgreSQL из утилит на языке Python. Должен быть установлен для использования любых продуктов Z, ориентированных на использование postgresql. Устанавливается установкой пакета rpm ;)
Коннектор используется для описания подключения экземпляра сервера приложений Zope к серверу баз данных PostgreSQL. Установка требует выполнения пунктов, перечисленных в начале документа.
Несмотря на все достоинства этого продукта, он не содержит явного способа установить кодировку клиента при работе с базой данных PostgreSQL с кодировкой, отличной от кодировки сервера. Лучший способ решения данной проблемы — добавление строчки вида:
export PGCLIENTENCODING=<КОДИРОВКА КЛИЕНТА>
в файл /etc/sysconfig/zope/<ИМЯ ЭКЗЕМПЛЯРА СЕРВЕРА>, подробности такого решения можно узнать в документации на postgresql.
Пожалуйста, не пытайтесь добавлять команду set clientencoding при отправке каждого запроса: мало того, что это методологически неверно, это ещё и приведёт к нерациональному расходу сил и появлению трудно диагностируемых ошибок.
API для работы с базами MySQL из утилит на языке Python. Должен быть установлен для использования любых продуктов Zope, ориентированных на использование MySQL. Устанавливается установкой пакета RPM.
Коннектор используется для описания подключения экземпляра сервера приложений Zope к серверу баз данных MySQL. Установка требует выполнения пунктов, перечисленных в начале документа. Предупреждение: в нашей версии отключена генерация исключения при невозможности откатки транзакции. Дело в том, что это исключение генерируется всегда при ошибочном завершении любой транзакции, заканчивающейся ошибочно по каким-либо причинам, что и не дает возможности ни диагностировать, ни корректно обработать исходную ошибку.
Если вы считаете такой патч пакета неверным — свяжитесь с нами.
В сервере приложений Zope существует единое API для хранения учётных записей пользователей. Один из вариантов использования этого API — mysqlUserFolder, позволяющий хранить учетные записи в базе данных MySQL. Предлагаемый пакет mysqlUserFolder полностью совместим с оригинальным пакетом, но существенно доработан нами для работы в России. Подробности доработок пакета см. в документации на пакет.
После установки пакета необходимо выполнить следующие шаги по его настройке:
Создать базу MySQL под список учётных записей пользователей;
Залить начальную версию базы из файла /usr/lib/zope/lib/python/Products/mysqlUserFolder/sql/create_tables.sql
Войти в менеджерский интерфейс Zope введя URL вида ;
Войти в контейнер, в котором будут действовать учётные записи, хранимые в этой базе;
Создать в этом контейнере объект типа mysqlUserFolder, объекту будет присвоен идентификатор acl_users. При создании объекта нужно указать параметры подключения к базе mysqlUserFolder;
Войти в acl_users и перейти на вкладку «Manage Users»;
Нажать кнопку «Create User» и заполнить поля формы, в поле Role указав Manager.
Перезапустите броузер и обратившись к контейнеру, содержащему этот объект, попробуйте войти в менеджерский интерфейс, введя логин и пароль только что созданного пользователя.
По умолчанию, в базу пользователей добавляются две роли — Manager и Anonymous. Для более тонкой настройки прав вы должны либо добавить дополнительные роли в таблицу Roles через интерфейс командной строки MySQL, либо использовать локальные роли Zope.