Zope の設定と実行

どのような方法で Zope をインストールし、サーバーインスタンスを作ったとしても（Zope のインストール を見てください）、最終的には同じ方法で設定と運用がなされます。

注釈

If you have installed Zope using zc.buildout in conjunction with plone.recipe.zope2instance as outlined in Zope のインストール, many of the following tasks are already done for you and some others differ slightly. You can immediately skip down to Running Zope (plone.recipe.zope2instance install).

Zope インスタンスを作る

Zope のインストールが済んだら、"インスタンスホーム"を作る必要があります。このディレクトリは Zope サーバープロセスの設定とデータを保持します。インスタンスホームは mkwsgiinstance スクリプトを使って作られます。

$ bin/mkwsgiinstance -d .

The -d argument specifies the directory to create the instance home in, where the dot (.) means the current folder.

mkwsiginstance の間に管理者（administorator）アカウントのユーザー名とパスワードを聞かれます。全ての利用できるコマンドラインオプションを見るには、 --help オプションをつけてスクリプトを実行してください。

$ bin/mkwsgiinstance --help

例に従って現在のディレクトリを選んだのなら、インスタンスファイルを virtualenv のサブディレクトリの中に確認できます。

  • etc/ は設定ファイルを保持します。

  • var/ はデータベースファイルを保持します。

  • var/log はログファイルを保持します。

ファイルシステムの権限

Zope がデータを格納するために使うディレクトリについての権限を設定する必要があります。通常は Zope のインスタンスホーム内の var ディレクトリで行います。Zope はこのディレクトリへのデータの読み書きを必要とします。Zope を実行する前に、Zope が実行されるユーザーに対して、このディレクトリには十分な権限が与えられているかを確認してください。

root として Zope を実行しないでください。Zope 専用のユーザーを作るか、管理者権限を持たない既存のアカウントを使ってください。

Zope を設定する

インスタンスの設定は、コンフィグファイル etc/zope.conf と etc/zope.ini の中で定義されています。

注釈

これらのコンフィグファイル内に変更があるときは、それらの変更を有効にする前に、 Zope インスタンスを再起動する必要があります。

zope.ini：WSGI の設定

etc/zope.ini ファイルは WSGI パイプライン、WSGI サーバー、そしてロギングに関する全ての設定を含みます。

Zope を起動するとき、アドレスが使用中であることを示すエラーに遭遇したら、Zope が HTTP で使うポートを変える必要があるかもしれません。Zope が使うデフォルトの HTTP ポートは 8080 です。[server] 設定セクションを編集することで、使用するポートを変えることができます。そのセクションは WSGI サーバー自体の設定を定義します。

[server:main]
use = egg:waitress#main
host = 127.0.0.1
port = 8080

デフォルトの waitress 以外の WSGI サーバーを統合する方法を知るには Using alternative WSGI server software の節を見てくだい。

Zope は [app] セクション内で設定されます。WSGI サーバーから呼ばれるいわゆる"エントリーポイント"と、Zope のコンフィグファイル zope.conf が配置される場所を定義します。

[app:zope]
use = egg:Zope#main
zope_conf = /path/to/zope.conf

ログの設定も同様に etc/zope.ini ファイルの一部です。mkwsgiinstance と plone.recipe.zope2instance で作られる設定はほとんどのアプリケーションに適しています。Python Logging Cookbook には、高度な設定のためのトピックが豊富に揃っています。

WSGI サーバーによってロギングの振る舞いが違うことに注意してください。アクセスやイベントのログを取るものもあれば、全くログを取らないものもあります。アプリケーションのロギングについてのニーズをうまくコントロールするために、デフォルトの設定では、Paste パッケージの translogger WSGI ミドルウェアを使用しています。それはアプリケーションから伝わる全てのエラーを捉えて、記録します。

注釈

もしカスタムの zc.buildout コンフィグを使ってアプリケーションを作り、ロギングのために translogger を使いたいのであれば、 buildout の eggs の指定において、Zope[wsgi] のように wsgi エクストラを Zope に指定することを忘れないでください。

zope.conf：Zope の設定

etc/zope.conf 内で Zope 自体を設定します。

zope.conf でサポートされるセクションやディレクティブについての詳細は、configuration reference section を参照してください。

Zope を実行する

フォアグラウンドで Zope を実行する

コンソールからデタッチすることなく Zope を実行するには、次のようにしてください。

$ bin/runwsgi -v etc/zope.ini
Starting server in PID 24934.
serving on http://127.0.0.1:8080

このモードでは、Zope がコンロールへログメッセージを吐き出します。そして、ターミナルからデタッチすることはありません。

デフォルトでは、このコマンドは Zope のデバッグモードを有効にしていません。なので、本番環境で使うことができます。

デバッグモードを有効にするには、追加で -d か --debug 引数をコマンドに加えてください。

$ bin/runwsgi -dv etc/zope.ini
Starting server in PID 55111.
serving on http://127.0.0.1:8080

runwsgi コマンドは PasteDeploy コンフィグファイルを引数として取ります。このファイルでは、異なる WSGI 対応サーバー、WSGI パイプライン、ロギングの設定をすることができます。

さあ、これであなたもブラウザを使ってログインできます。Logging In To Zope で説明されているようにしてください。

Zope をデーモンとして実行する

Zope itself has no built-in support for running as a daemon anymore.

もし plone.recipe.zope2instance を使って Zope インスタンスを作ったのなら、Zope をデーモン化するための起動/停止スクリプトを使えます。どうやるかは次節を見てください。

代わりに、supervisord のようなプロジェクトを使ったり、ほとんどのLinux バージョンに乗っている systemd のような OS 組み込みのプロセスマネージャーを使えます。例として、次の systemd のサービス設定は runwsgi スクリプトと一緒に動きます。buildout は /opt/zopeinstance に配置され、Zope インスタンスが走るユーザーアカウントは zope であると仮定します。

[Unit]
Description=Zope client zopeinstance
After=network.target

[Service]
Type=simple
User=zope
ExecStart=/opt/zopeinstance/bin/runwsgi /opt/zopeinstance/etc/zope.ini
KillMode=control-group
TimeoutStartSec=10
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

この設定を /etc/systemd/system/zopeinstance.service に保存し、systemd がそれを読めるように daemon-reload を実行します。その後、標準の systemctl コマンド使って Zope インスタンスを起動したり、再起動したり、停止したりできます。

[root@server]# systemctl start zopeinstance
[root@server]# systemctl restart zopeinstance
[root@server]# systemctl status zopeinstance
[root@server]# systemctl stop zopeinstance
...

Zope をデバッグする

Zope のアプリケーションをデバッグするために、データべースに接続して、コマンドラインから検査や変更をすることが役に立つ可能性があります。この機能は、以前は専用の zopectl debug コマンドを介して使うことができましたが、新しい WSGI セットアップでは、 zconsole モジュールとコンソールスクリプトを介して使うことができます。

$ bin/zconsole debug etc/zope.conf
>>> app
<Application at >

>>> app.acl_users
<UserFolder at /acl_users>

>>> import transaction
>>> transaction.begin()
>>> app.acl_users._doAddUser('foo', 'bar', ['Manager'], [])
<User 'foo'>
>>> transaction.commit()

スクリプトを実行する

以前は zopectl run <path_to_script> <scriparg1> ... を使うことができました。WSGI セットアップでは、 zconsole モジュールとコンソールスクリプトは次のように使えます。

$ bin/zconsole run etc/zope.conf <path_to_script> <scriptarg1> ...

ユーザーを追加する

既にある Zope インスタンスに Manager を追加する必要があるなら、addzopeuser を次のように使ってください。

$ bin/addzopeuser user password

デフォルトでは、このスクリプトは etc/etc/zope.conf にコンフィグファイルを見つけられることを期待しています。もし違う場所にあるなら、--configuration オプションを使って指定できます。

$ bin/addzopeuser --configuration /path/to/etc/zope.conf user password

Zope を実行する（plone.recipe.zope2instance でのインストール）

plone.recipe.zope2instance を使用したインストールでは、 スクリプトの名前と呼び出しが若干異なりますが、結果は上で述べた通りです。以下の例では、buildout セクションの名前が zopeinstance であったと仮定します。

フォアグラウンドで Zope を実行する

コンソールからデタッチすることなく Zope を実行するには、次のようにしてください。

$ bin/zopeinstance fg
...
Serving on http://127.0.0.1:8080

Zope をデーモンとして実行する

zopeinstance ランナースクリプトは Zope プロセスをデーモン化できます。

$ bin/zopeinstance start
...
daemon process started, pid=60116

ステータスの情報の取り方と Zope インスタンスの停止の仕方は次の通りです。

$ bin/zopeinstance status
program running; pid=60116
$ bin/zopeinstance stop
...
daemon process stopped

リブート時に自動的にインスタンスを起動させるには、OS のサービス起動機能と統合する必要があります。例として、次の systemd のサービス設定は plone.recipe.zope2instance によって生成された起動/停止スクリプトと連動します。スクリプト名は zopeinstance、buildout は /opt/zopeinstance、Zope インスタンスを動作させるユーザーアカウントは zope であると仮定します。

[Unit]
Description=Zope client zopeinstance
After=network.target

[Service]
Type=forking
User=zope
ExecStart=/opt/zopeinstance/bin/zopeinstance start
PIDFile=/opt/zopeinstance/var/zopeinstance/Z4.pid
ExecStop=/opt/zopeinstance/bin/zopeinstance stop
ExecReload=/opt/zopeinstance/bin/zopeinstance stop && /opt/zopeinstance/bin/zopeinstance start
KillMode=control-group
TimeoutStartSec=10
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

この設定を /etc/systemd/system/zopeinstance.service に保存し、systemd がそれを読めるように daemon-reload を実行します。その後、標準の systemctl コマンド使って Zope インスタンスを起動したり、再起動したり、停止したりできます。

[root@server]# systemctl start zopeinstance
[root@server]# systemctl restart zopeinstance
[root@server]# systemctl status zopeinstance
[root@server]# systemctl stop zopeinstance
...

Zope をデバッグする

コマンドラインでデバッグができます。

$ bin/zopeinstance debug
Starting debugger (the name "app" is bound to the top-level Zope object)
>>> app
<Application at >

>>> app.acl_users
<OFS.userfolder.UserFolder object at ...>

>>> import transaction
>>> transaction.begin()
>>> app.acl_users._doAddUser('foo', 'bar', ['Manager'], [])
<User 'foo'>
>>> transaction.commit()

スクリプトを実行する

コマンドラインから Python スクリプトを走らせることもできます。app という名前は、トップレベルの名前空間に挿入され、サイトのルートアプリケーションオブジェクトを表します。

$ bin/zopeinstance run <path_to_script> <scriptarg1> ...

ユーザーを追加する

既存の Zope インスタンスに Manager を追加する必要があるなら、次のようにしてください。

$ bin/zopeinstance adduser user password
Created user: user

Zope にログインする

Zope を起動したら、ブラウザで次の URL にアクセスすることで Zope のWeb サーバーに接続できます。

http://yourhost:8080/manage

'yourhost' の場所には Zope が走っているマシンの DNS 名か IP アドレスを入れてください。

ユーザー名とパスワードの入力を求められます。Zope インスタンスを作ったときに、プロンプトに応答して入力したユーザー名とパスワードを使ってください。plone.recipe.zope2instance に基づいてインストールしたなら、buildout コンフィグの中で設定したユーザー名とパスワードを使ってください。

これで Zope を実行する は終わりです！ふたつのフレームに別れた Zope の管理画面を見ているはずです。左側のものでは Zope オブジェクトの間を移動できます。右側のものではオブジェクトを編集できます。編集時にはフレームの上部にあるタブで異なる管理機能を選択できます。

http://yourhost:8080/ に描画する内容を作るには、index_html という名前の Page Template か DTML Document を作ってください。

特別なアクセス権限をもつユーザーアカウント

初期ユーザー（Initial User）

初期ユーザー名とパスワードは Zope サイトで通常の Manager を作成する "自動処理（bootstrap）" をするために必要になります。これはインスタンスホームとして指定されたディレクトリの中の 'inituser' ファイルを使うことによって実現されます。

Zope が初めて起動したとき、Zope はルートユーザーフォルダの中にユーザーが定義されていないことを検知します。Zope は 'inituser' ファイルを探して、もしあれば、そのファイル内に定義されたユーザーをルートフォルダに追加します。

通常、'inituser' は makewsgiinstance インストールスクリプトによって作られます。

スーパーユーザー（Super User：緊急用のユーザー）

Zope のインスタンスから締め出されてしまったら、インスタンスホームとして定義されたディレクトリ内の access という名前のファイルを置き換えることで、ユーザーを作ることができます。そのファイルはコロンで区切られたログインとパスワードを一行で持っていて、次のようになっています。

superuser:mysecretpassword

ファイルの中身を書き換えたら、Zope を再起動して、ログインするためにこれらの認証情報を使ってください。このユーザーアカウントのタイプではコンテンツを作ることはできません。しかし、ユーザーフォルダに新しいユーザーを追加したり、既存のユーザーを編集したりすることはできるので、窮地を脱することができます。

用事が済んだら、access ファイルを削除して、Zope を再起動することを忘れないでください。

トラブルシューティング

  • このバージョンの Zope は Python3.7 以上が必要です。PyPy ではどのバージョンを使っても Zope は動作しません。

  • Python 拡張をビルドするためには、Python の設定情報を利用できるようにしておく必要があります。もし RPM 由来の Python であったら、python-devel （または python-dev）パッケージもインストールしておく必要があるかもしれません。もし Python をソースからビルドしたなら、全ての設定情報は既に利用できるようになっているはずです。

  • このバージョンの Zope の重要事項については Change log を見てください。

他の WSGI サーバーソフトウェアを使う

WSGI の統合では、Zope アプリケーションを走らせる WSGI サーバーソフトウェアを選択できます。この節ではいくつかの選択肢を紹介します。それらの選択肢は PasteDeploy のエントリーポイントかシム（訳者注：プログラム間の差異を埋めるもの）ソフトウェアによって提供されるエントリーポイントを持っています。それはサービスを起動/停止するデフォルトの Zope スクリプトと連動することを意味します。

気を付けること

ZODB はコネクションプールを使っています。作業スレッドはプールからコネクションを取得してコンテンツを提供し、作業が終わるとコネクションを解放します。コネクションプールのデフォルトのサイズは 7 です。アプリケーションのスレッド数は、ZODB のコネクション数を下回る安全な数を選ぶべきです。WSGI サーバーでスレッド数を設定するなら、4 が安全な選択です。

Zope 2 から推奨されていて、今だに有効なものは他にもあります。スレッド数は多いがインスタンス数の少ない Zope の構成と、スレッド数は少ないがインスタンス数の多い Zope の構成なら、後者を選んでください。より多くの独立した Zope インスタンスを作り、WSGI サーバーのスレッドの値は、例えば 2 に設定してください。

警告

例えば gunicorn のような WSGI サーバーソフトウェアでワーカープロセスの数を設定できても、単一のワーカーより多く設定しないでください。そうしないと、複数のプロセスからの ZODB への同時アクセスによる問題が起こり、ZODB が壊れるかもしれません。

推奨のテスト基準

次のパラメーターを用いて、簡単な仕掛けを含む負荷テストを実施しました。

  • 100 クライアントから Zope への同時アクセス

  • 100 秒間の実行時間

  • "/" を取得するだけのクライアント

  • standard Zope 5.9 instances, one with ZEO and one without

  • Python 3.11.7 on macOS Sonoma/14.2.1

  • スレッド数および/または利用可能なワーカー数だけ変更した標準の WSGI サーバー設定

この負荷テストはいくつかの問題を明らかにしました。

  • cheroot (tested version: 10.0.0) seemed overwhelmed by the load. It kept resetting connections to the test client with an error rate of about 1.5%.

  • gunicorn (tested version: 19.9.0) does not work at all with ZEO. Without ZEO it only works if a single worker is configured. Even with a single thread client connections timed out, the failure rate was about 0.25%.

  • bjoern (tested version: 3.2.2) is the clear speed winner with 3,870 requests/second against both the ZEO and non-ZEO Zope instance.

  • waitress (tested version: 2.1.12) is the all-around best choice. It's just about 15% slower than bjoern, but both the built-in WSGI tools as well as plone.recipe.zope2instance use it as the default and make it very convenient to use.

WSGI の下で Zope アプリケーションをデバッグする

デバッガーを有効にするステートメントを追加することで、WSGI ベースの Zope アプリケーションをデバッグすることができます。加えて、WSGI ミドルウェアや、選択した WSGI サーバーに組み込まれたデバッグ機能を利用できます。

アプリケーションを開発する時やデバッグする時、つまりデバッグツールを使いたい時に、Zope インスタンスを 例外デバッグモード で起動できます。これは standard_error_message を含む全ての登録された例外ビューを無効にし、例外がマスクされたり隠されたりしないようにします。

組み込みの runwsgi スクリプトを使って、Zope を例外デバッグモードで走らせる方法は次の通りです。

$ bin/runwsgi -e etc/zope.ini

plone.recipe.zope2instance を使って環境を構築した場合は、Zope のコンフィグファイルを手動で変更する必要があります。アプリケーションを起動する前に、debug-exceptions on の設定を加えることで、例外デバッグモードを有効にしてください。この例では、Zope インスタンスは zopeinstance という名前であり、Zope のコンフィグファイルは parts/zopeinstance/etc/zope.conf にあることを想定しています。

bin/zopeinstance fg

Zope が WSGI に例外を処理させるように設定する時に、WSGI パイプラインのためのオプションがあります。

waitress を使う場合、expose_tracebacks を設定することでブラウザに例外のトレースバックを出力させることができます。このキーワードは標準と plone.recipe.zope2instance の構成で動きます。

[server:main]
use = egg:waitress#main
host = 127.0.0.1
port = 8080
expose_tracebacks = True

... or ...

[server:main]
paste.server_factory = plone.recipe.zope2instance:main
use = egg:plone.recipe.zope2instance#main
listen = 0.0.0.0:8080
threads = 2
expose_tracebacks = True

werkzeug にはフル装備のデバッグツールが含まれています。どのようにデバッガーを有効にするかは dataflake.wsgi.werkzeug のドキュメント を見てください。設定を終えて起動をすると、werkzeug デバッガー が表示されて、使い方を教えてくれます。

Zope configuration reference

zodb.storage*

<blobstorage> (ZODB.config.BlobStorage)

blob-dir (string)

Path name to the blob storage directory.

zodb.storage*

<demostorage> (ZODB.config.DemoStorage)

name (string)

The storage name, used by the getName() and sortKey() methods.

zodb.storage*

<filestorage> (ZODB.config.FileStorage)

path (existing-dirpath)

Path name to the main storage file. The names for supplemental files, including index and lock files, will be computed from this.

blob-dir (existing-dirpath)

If supplied, the file storage will provide blob support and this is the name of a directory to hold blob data. The directory will be created if it doesn't exist. If no value (or an empty value) is provided, then no blob support will be provided. (You can still use a BlobStorage to provide blob support.)

create (boolean)

Flag that indicates whether the storage should be truncated if it already exists.

read-only (boolean)

If true, only reads may be executed against the storage. Note that the "pack" operation is not considered a write operation and is still allowed on a read-only filestorage.

quota (byte-size)

Maximum allowed size of the storage file. Operations which would cause the size of the storage to exceed the quota will result in a ZODB.FileStorage.FileStorageQuotaError being raised.

packer (string)

The dotted name (dotted module name and object name) of a packer object. This is used to provide an alternative pack implementation.

pack-gc (boolean) (default: true)

If false, then no garbage collection will be performed when packing. This can make packing go much faster and can avoid problems when objects are referenced only from other databases.

pack-keep-old (boolean) (default: true)

If true, a copy of the database before packing is kept in a ".old" file.

<fullstorage> (ZODB.config.BDBFullStorage)

envdir (string)

interval (time-interval) (default: 2m)

kbyte (integer) (default: 0)

min (integer) (default: 0)

logdir (string)

cachesize (byte-size) (default: 128MB)

frequency (time-interval) (default: 0)

packtime (time-interval) (default: 4h)

gcpack (integer) (default: 0)

read-only (boolean) (default: off)

<mappingstorage> (ZODB.config.MappingStorage)

name (string) (default: Mapping Storage)

The storage name, used by the getName() and sortKey() methods.

<minimalstorage> (ZODB.config.BDBMinimalStorage)

envdir (string)

interval (time-interval) (default: 2m)

kbyte (integer) (default: 0)

min (integer) (default: 0)

logdir (string)

cachesize (byte-size) (default: 128MB)

frequency (time-interval) (default: 0)

packtime (time-interval) (default: 4h)

gcpack (integer) (default: 0)

read-only (boolean) (default: off)

<temporarystorage> (tempstorage.config.TemporaryStorage)

A nonundoing storage which keeps data in RAM and which does not need to be packed unless cyclic references are kept.

name (string) (default: Temporary Storage)

<zeoclient> (ZODB.config.ZEOClient)

server (*) (socket-connection-address)

blob-dir (string)

Path name to the blob cache directory.

shared-blob-dir (boolean) (default: no)

Tells whether the cache is a shared writable directory and that the ZEO protocol should not transfer the file but only the filename when committing.

blob-cache-size (byte-size)

Maximum size of the ZEO blob cache, in bytes. If not set, then the cache size isn't checked and the blob directory will grow without bound.

This option is ignored if shared_blob_dir is true.

blob-cache-size-check (integer)

ZEO check size as percent of blob_cache_size. The ZEO cache size will be checked when this many bytes have been loaded into the cache. Defaults to 10% of the blob cache size. This option is ignored if shared_blob_dir is true.

storage (string) (default: 1)

The name of the storage that the client wants to use. If the ZEO server serves more than one storage, the client selects the storage it wants to use by name. The default name is '1', which is also the default name for the ZEO server.

cache-size (byte-size) (default: 20MB)

The maximum size of the client cache, in bytes, KB or MB.

name (string)

The storage name. If unspecified, the address of the server will be used as the name.

client (string)

Enables persistent cache files. The string passed here is used to construct the cache filenames. If it is not specified, the client creates a temporary cache that will only be used by the current object.

var (string)

The directory where persistent cache files are stored. By default cache files, if they are persistent, are stored in the current directory.

min-disconnect-poll (integer) (default: 5)

The minimum delay in seconds between attempts to connect to the server, in seconds. Defaults to 5 seconds.

max-disconnect-poll (integer) (default: 300)

The maximum delay in seconds between attempts to connect to the server, in seconds. Defaults to 300 seconds.

wait (boolean) (default: on)

A boolean indicating whether the constructor should wait for the client to connect to the server and verify the cache before returning. The default is true.

read-only (boolean) (default: off)

A flag indicating whether this should be a read-only storage, defaulting to false (i.e. writing is allowed by default).

read-only-fallback (boolean) (default: off)

A flag indicating whether a read-only remote storage should be acceptable as a fall-back when no writable storages are available. Defaults to false. At most one of read_only and read_only_fallback should be true.

username (string)

The authentication user name of the server.

password (string)

The authentication password of the server.

realm (string)

The authentication realm of the server. Some authentication schemes use a realm to identify the logic set of user names that are accepted by this server.

drop-cache-rather-verify (boolean) (default: off)

A flag indicating whether the client cache should be dropped instead of an expensive verification.

client-label (string)

A label for the client in server logs

zodb.storage*

zodb.storage*

zodb.database+

Zope ZODB databases must have a name, and they are required to be referenced via the "zodb_db" database type because it is the only kind of database definition that implements the required mount-point argument. There is another database sectiontype named "zodb", but it cannot be used in the context of a proper Zope configuration (due to lack of a mount-point).

<zodb> (ZODB.config.ZODBDatabase)

zodb.storage*

cache-size (integer) (default: 5000)

Target size, in number of objects, of each connection's object cache.

cache-size-bytes (byte-size) (default: 0)

Target size, in total estimated size for objects, of each connection's object cache. "0" means no limit.

large-record-size (byte-size) (default: 16MB)

When object records are saved that are larger than this, a warning is issued, suggesting that blobs should be used instead.

pool-size (integer) (default: 7)

The expected maximum number of simultaneously open connections. There is no hard limit (as many connections as are requested will be opened, until system resources are exhausted). Exceeding pool-size connections causes a warning message to be logged, and exceeding twice pool-size connections causes a critical message to be logged.

pool-timeout (time-interval)

The minimum interval that an unused (non-historical) connection should be kept.

historical-pool-size (integer) (default: 3)

The expected maximum total number of historical connections simultaneously open.

historical-cache-size (integer) (default: 1000)

Target size, in number of objects, of each historical connection's object cache.

historical-cache-size-bytes (byte-size) (default: 0)

Target size, in total estimated size of objects, of each historical connection's object cache.

historical-timeout (time-interval) (default: 5m)

The minimum interval that an unused historical connection should be kept.

database-name (string)

When multi-databases are in use, this is the name given to this database in the collection. The name must be unique across all databases in the collection. The collection must also be given a mapping from its databases' names to their databases, but that cannot be specified in a ZODB config file. Applications using multi-databases typical supply a way to configure the mapping in their own config files, using the "databases" parameter of a DB constructor.

allow-implicit-cross-references (boolean)

If set to false, implicit cross references (the only kind currently possible) are disallowed.

<zodb_db> (Zope2.Startup.datatypes.ZopeDatabase)

We need to specialize the database configuration section for Zope only by including a (required) mount-point argument, which is a string. A Zope ZODB database can have multiple mount points, so this is a multikey.

zodb.storage*

cache-size (integer) (default: 5000)

Target size, in number of objects, of each connection's object cache.

cache-size-bytes (byte-size) (default: 0)

Target size, in total estimated size for objects, of each connection's object cache. "0" means no limit.

large-record-size (byte-size) (default: 16MB)

When object records are saved that are larger than this, a warning is issued, suggesting that blobs should be used instead.

pool-size (integer) (default: 7)

The expected maximum number of simultaneously open connections. There is no hard limit (as many connections as are requested will be opened, until system resources are exhausted). Exceeding pool-size connections causes a warning message to be logged, and exceeding twice pool-size connections causes a critical message to be logged.

pool-timeout (time-interval)

The minimum interval that an unused (non-historical) connection should be kept.

historical-pool-size (integer) (default: 3)

The expected maximum total number of historical connections simultaneously open.

historical-cache-size (integer) (default: 1000)

Target size, in number of objects, of each historical connection's object cache.

historical-cache-size-bytes (byte-size) (default: 0)

Target size, in total estimated size of objects, of each historical connection's object cache.

historical-timeout (time-interval) (default: 5m)

The minimum interval that an unused historical connection should be kept.

database-name (string)

When multi-databases are in use, this is the name given to this database in the collection. The name must be unique across all databases in the collection. The collection must also be given a mapping from its databases' names to their databases, but that cannot be specified in a ZODB config file. Applications using multi-databases typical supply a way to configure the mapping in their own config files, using the "databases" parameter of a DB constructor.

allow-implicit-cross-references (boolean)

If set to false, implicit cross references (the only kind currently possible) are disallowed.

mount-point (*) (Zope2.Startup.datatypes.mount_point)

The mount point is a slash-separated path to a 'Products.ZODBMountPoint.Mount.MountPoint' instance in Zope. If such an instance exists, it can mount an object (the mounted object) into Zope. By default, the object will be mounted at the same path in Zope (i.e. '/foo/bar' in the database will be mounted at '/foo/bar' in Zope).

The object can be mounted at a different point using the 'virtual_path:real_path' syntax (e.g. 'mount-point /foo/bar:/bar' will mount the object at '/bar' in the database to '/foo/bar' in Zope). The name of the mount point ('bar') must be the same as the mounted object.

It is also possible to specify the root that should be used in the mounted database by using the syntax 'virtual_path:~real_root:real_path'. The root defaults to 'Application' and should not normally be changed.

connection-class (Zope2.Startup.datatypes.importable_name)

Change the connection class a database uses on a per-database basis to support different connection policies. Use a Python dotted-path name to specify the connection class.

class-factory (Zope2.Startup.datatypes.importable_name) (default: Zope2.Startup.datatypes.simpleClassFactory)

Change the class factory function a database uses on a per-database basis to support different class factory policy. Use a Python dotted-path name to specify the class factory function.

container-class (string)

Change the container class a (mounted) database uses on a per-database basis to support a different container than a plain Folder. Use a Python dotted-path name to specify the container class.

zope.product.base+

Product-specific configuration stanzas.

Products may use the <product-config> section type, or may supply a component.xml which defines section types with their own schemas.

All sections for this multisection will be collected into the 'product_config' attribute of the configuration object.

Base type for product-specific configuration sections.

Specific products should implement configuration sections by defining section types that implement this abstract type and using their own schema component to define meaningful settings.

product-config (null)

Product-specific configuration, expressed as arbitrary name-value pairs.

+ (string)

dos_protection (null)

Options for DOS attack protection.

These options limit the amount of memory and disk resources for the request processing by Zope itself (in contrast to that by the application or the frontend WSGI server).

Note that the WSGI server (or WSGI middleware) may already have consumed similar resources. Those resources, too, should likely get limited by corresponding configuration options.

Zope's own request processing consists of the determination of the request parameters and access to the request body.

Request parameters can come from a query string and the body of POST requests with content type "application/x-www-form-urlencoded" or "multipart/form-data". The options limit essentially the resources used for parameter values from those POST requests. form-urlencoded requests are assumed to contain only small parameter values; for them, the complete body size is limited. "multipart/form-data" requests are typically used to upload (potentially) large files. For them, small values are held in memory while large values are stored on disk. An option controls when to switch from memory to disk storage. Other options limit the total memory and disk amount for the parameter values.

The protection options limit the resources used for the raw request parameter values. For non file values Zope maintains in addition preprocessed values; they usually need memory resources in the same order as the corresponding raw parameter values.

Zope provides access to the request body via request["BODY"] and request["BODYFILE"]. The former accesses the body as bytes and is limited; the latter provides access via a file API and is not limited.

form-memory-limit (byte-size) (default: 1MB)

Limits the total amount of memory for all parameter values held in memory. Limits the size of form-urlencoded request bodies. Limits the size of request bodies accessed via request["BODY"].

form-disk-limit (byte-size) (default: 1GB)

Limits the total amount of disk space used for parameter values stored on disk.

form-memfile-limit (byte-size) (default: 4KB)

Specifies the parameter value size at which its storage switches from memory to disk.

<environment> (Zope2.Startup.datatypes.environment)

A section which allows you to define simple key-value pairs which will be used as environment variable settings during startup.

+ (string)

Use any key/value pair, e.g. 'MY_PRODUCT_ENVVAR foo_bar'

zodb.database

zodb.storage

zope.product.base

Base type for product-specific configuration sections.

Specific products should implement configuration sections by defining section types that implement this abstract type and using their own schema component to define meaningful settings.

<environment *> (Zope2.Startup.datatypes.environment)

+ (string)

Use any key/value pair, e.g. 'MY_PRODUCT_ENVVAR foo_bar'

instancehome (existing-directory)

The top-level directory which contains the "instance" data for the application server. It may also contain "etc", "bin", "log", and "var" directories depending on how you've configured your Zope instance.

clienthome (existing-directory) (metadefault: $instancehome/var)

The directory used to store the default filestorage file used to back the ZODB database, as well as other files used by the Zope applications server during runtime.

debug-mode (boolean) (default: off) (metadefault: off)

A switch which controls several aspects of Zope operation useful for developing under Zope. When debug mode is on:

  • Errors in product initialization will cause startup to fail (instead of writing error messages to the event log file).

  • Filesystem-based scripts such as skins, PageTemplateFiles, and DTMLFiles can be edited while the server is running and the server will detect these changes in real time. When this switch is off, you must restart the server to see the changes.

Setting this to 'off' when Zope is in a production environment is encouraged, as it speeds execution (sometimes dramatically).

debug-exceptions (boolean) (default: off) (metadefault: off)

This switch controls how exceptions are handled. If it is set to "off" (the default), Zope's own exception handling is active. Exception views or a standard_error_message are used to handle them.

If set to "on", exceptions are not handled by Zope and can propagate into the WSGI pipeline, where they may be handled by debugging middleware.

This setting should always be "off" in production. It is useful for developers and while debugging site issues.

locale (locale) (metadefault: unset)

Locale name to be used. See your operating system documentation for locale information specific to your system. If the requested locale is not supported by your system, an error will be raised and Zope will not start.

datetime-format (Zope2.Startup.datatypes.datetime_format) (default: us) (metadefault: us)

Set this variable either to "us" or "international" to force the DateTime module to parse date strings either with month-before-days-before-year ("us") or days-before-month-before-year ("international"). The default behaviour of DateTime (when this setting is left unset) is to parse dates as US dates.

python-check-interval (integer) (default: 1000)

Value passed to Python's sys.setcheckinterval() function. The higher this is, the less frequently the Python interpreter checks for keyboard interrupts. Setting this to higher values also reduces the frequency of potential thread switches, which can improve the performance of a busy server.

http-realm (string) (default: Zope) (metadefault: Zope)

The HTTP "Realm" header value sent by this Zope instance. This value often shows up in basic authentication dialogs.

automatically-quote-dtml-request-data (boolean) (default: on) (metadefault: on)

Set this directive to 'off' in order to disable the autoquoting of implicitly retrieved REQUEST data by DTML code which contains a '<' when used in <dtml-var> construction. When this directive is 'on', all data implicitly retrieved from the REQUEST in DTML (as opposed to addressing REQUEST.somevarname directly) that contains a '<' will be HTML-quoted when interpolated via a <dtml-var> or &dtml- construct. This mitigates the possibility that DTML programmers will leave their sites open to a "client-side trojan" attack.

zmi-bookmarkable-urls (boolean) (default: on) (metadefault: on)

Set this directive to 'on' to cause Zope to show the ZMI right hand frame's URL in the browser navigation bar as opposed to the static '/manage'. The default is 'on'. To restore the behavior of Zope 2 where the URL was always static unless you opened the right-hand frame in its own browser window, set this to off.

pid-filename (existing-dirpath) (metadefault: $clienthome/Z4.pid)

The full path to which the Zope process will write its OS process id at startup.

trusted-proxy (*) (ipaddr-or-hostname) (metadefault: unset)

Define one or more 'trusted-proxies' keys, each of which is a hostname or an IP address. The set of definitions comprises a list of front-end proxies that are trusted to supply an accurate X_FORWARDED_FOR header to Zope (security-related).

max-conflict-retries (integer) (default: 3)

The maximum number of retries on a conflict error

security-policy-implementation (Zope2.Startup.datatypes.security_policy_implementation) (default: C) (metadefault: C)

The default Zope "security policy" implementation is written in C. Set this key to "PYTHON" to use the Python implementation (useful for debugging purposes); set it to "C" to use the C implementation.

skip-authentication-checking (boolean) (default: off) (metadefault: off)

Set this directive to 'on' to cause Zope to prevent Zope from attempting to authenticate users during normal operation. Potentially dangerous from a security perspective. Only works if security-policy-implementation is set to 'C'.

skip-ownership-checking (boolean) (default: off) (metadefault: off)

Set this directive to 'on' to cause Zope to ignore ownership checking when attempting to execute "through the web" code. By default, this directive is off in order to prevent 'trojan horse' security problems whereby a user with less privilege can cause a user with more privilege to execute code which the less privileged user has written.

verbose-security (boolean) (default: off) (metadefault: off)

Set this directive to 'on' to enable verbose security exceptions. This can help you track down the reason for Unauthorized exceptions, but it is not suitable for public sites because it may reveal unnecessary information about the structure of your site. Only works if security-policy-implementation is set to 'PYTHON'.

default-zpublisher-encoding (Zope2.Startup.datatypes.default_zpublisher_encoding) (default: utf-8)

This key controls what character set is used to encode unicode data that reaches ZPublisher without any other specified encoding.

webdav-source-port (integer) (default: 0)

This value designates a network port number as WebDAV source port.

WebDAV requires special handling for GET requests. A WebDAV client expects to receive the un-rendered source in the returned response body, not the rendered result a web browser would get.

If this value is set to a positive integer, any GET request coming into Zope via the designated port will be marked up to signal that this is a WebDAV request. This request markup resembles what ZServer did for requests coming though its designated WebDAV source server port, so it is backwards-compatible for existing code that offers WebDAV handling under ZServer.

Please note that Zope itself has no server capabilities and cannot open network ports. You need to configure your WSGI server to listen on the designated port.

enable-ms-public-header (boolean) (default: off) (metadefault: off)

Set this directive to 'on' to enable sending the "Public" header in response to an WebDAV OPTIONS request - but only those coming from Microsoft WebDAV clients.

Though recent WebDAV drafts mention this header, the original WebDAV RFC did not mention it as part of the standard. Very few web servers out there include this header in their replies, most notably IIS and Netscape Enterprise 3.6.

Documentation about this header is sparse. Some versions of Microsoft Web Folders after 2005 apparently require its presence, but most documentation links have expired.

<dos_protection *> (null)

form-memory-limit (byte-size) (default: 1MB)

Limits the total amount of memory for all parameter values held in memory. Limits the size of form-urlencoded request bodies. Limits the size of request bodies accessed via request["BODY"].

form-disk-limit (byte-size) (default: 1GB)

Limits the total amount of disk space used for parameter values stored on disk.

form-memfile-limit (byte-size) (default: 4KB)

Specifies the parameter value size at which its storage switches from memory to disk.