[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.625.2.12 DEBUGGING.txt:1.8.208.1 SETUID.txt:1.1.70.1 SIGNALS.txt:1.3.44.1 TODO.txt:1.18.2.4 ENVIRONMENT.txt:NONE LOGGING.txt:NONE
Chris McDonough
chrism@zope.com
Mon, 21 Jul 2003 12:39:01 -0400
Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv17213/doc
Modified Files:
Tag: Zope-2_7-branch
CHANGES.txt DEBUGGING.txt SETUID.txt SIGNALS.txt TODO.txt
Removed Files:
Tag: Zope-2_7-branch
ENVIRONMENT.txt LOGGING.txt
Log Message:
Merge changes from HEAD since the release of Zope 2.7a1 into the Zope-2_7-branch in preparation for release of Zope 2.7b1.
=== Zope/doc/CHANGES.txt 1.625.2.11 => 1.625.2.12 ===
--- Zope/doc/CHANGES.txt:1.625.2.11 Tue Jul 15 13:14:55 2003
+++ Zope/doc/CHANGES.txt Mon Jul 21 12:34:52 2003
@@ -4,11 +4,43 @@
Change information for previous versions of Zope can be found in the
file HISTORY.txt.
- 2.7.0a2
+ 2.7.0b1
Features added
- - Windows installer will contain NT/2K/XP service support on
+ - zopectl command now has 'debug' and 'run' options.
+
+ - the zodb_db section in zope.conf now accepts a 'connection-class'
+ key that accepts a python dotted-path-name to use as the
+ connection class for the database.
+
+ - The ReST input and output encodings are now configured via the
+ 'rest-input-encoding' and 'rest-output-encoding' config file
+ directives rather than the REST_INPUT_ENCODING and
+ REST_OUTPUT_ENCODING environment variables.
+
+ - Datetime-format settings are now configured via the
+ 'datetime-format' configuration file directive rather than the
+ DATETIME_FORMAT environment variable.
+
+ - Trusted proxies are now configured via the 'trusted-proxy'
+ configuration file directive rather than the
+ ZOPE_TRUSTED_PROXIES environment variable.
+
+ - The maximum number of sockets that ZServer will open in order to
+ service incoming connections can now be specified via the
+ max-listen-sockets conf file parameter.
+
+ - Shane Hathaway's DBTab product has been integrated. The
+ Control_Panel -> Databases tab now allows you to control all
+ mounted databases. You can add a mount point by editing the
+ zope.conf file, adding a zodb_db section for the main database
+ and other mounted databases, and choosing "ZODB Mount Point"
+ from the Zope "Add" list.
+
+ - DTML Methods and Documents supply a traceback supplement when called.
+
+ - Windows installer contains NT/2K/XP service support on
a per-instance-home basis.
- zopectl command now has 'debug' and 'run' options.
@@ -18,6 +50,17 @@
connection class for the database.
Bugs Fixed
+
+ - mkzopeinstance did not expand tildes in directory name input.
+
+ - The 'configure' script did not work under Solaris sh.
+
+ - The SiteErrorLog object did not ignore NotFound errors,
+ which caused (mainly) useless messages to be kept in the log.
+
+ - The addition of a linefeed to version.txt in lib/python caused
+ Apache proxies to choke because the string was injected into
+ a header including the linefeed. This has been fixed.
- Collector: #964: standard_error_message refers to looking into the
HTML code for more information which is deprecated. Referring to
=== Zope/doc/DEBUGGING.txt 1.8 => 1.8.208.1 ===
--- Zope/doc/DEBUGGING.txt:1.8 Thu Aug 9 01:08:43 2001
+++ Zope/doc/DEBUGGING.txt Mon Jul 21 12:34:53 2003
@@ -1,21 +1,44 @@
Running Zope in Debug Mode
- If you wish to run Zope in debug mode, use the -D command line
- switch. This will have the following effects::
+ If you wish to run Zope in debug mode, set the 'debug-mode'
+ configuration file parameter to 'on' (this is the default). This
+ will have the following effects::
o On UNIX, Zope will not detach from the controlling terminal.
- o Zope will print logging information to standard error.
-
- o The Z_DEBUG_MODE environment variable gets set, which causes some
- other cool stuff to happen in Zope.
+ o The Z_DEBUG_MODE environment variable gets set, which causes
+ behavioral changes to Zope appropriate for software development.
+ See the configuration file description of 'debug-mode' for more
+ information.
+
+Using 'zopectl debug'
+
+ In Zopes 2.7 and better, a utility known as 'zopectl' is installed
+ into generated instance homes. You can use it to inspect a Zope
+ instance's running state via an interactive Python interpreter by
+ passing zopectl the 'debug' parameter on the command line. The
+ 'top-level' Zope object (the root folder) will be bound to the name
+ 'app' within the interpreter. You can then use normal Python method
+ calls against app and use the Python interpreter normally to inspect
+ results::
+
+ [chrism@james Trunk]$ bin/zopectl debug
+ Starting debugger (the name "app" is bound to the top-level Zope object)
+ >>> app.objectIds()
+ ['acl_users', 'Control_Panel', 'temp_folder', 'browser_id_manager', 'session _data_manager', 'error_log', 'index_html', 'standard_error_message', 'standa rd_html_footer', 'standard_html_header', 'standard_template.pt']
+ >>>
Using the Medusa Monitor
- If you're running ZServer with a medusa monitor port, you can
- connect and interact via a python prompt with a running Zope
- session, while others interact with it over the web.
+ NOTE: as of Zope 2.7, the Medusa monitor client is known to have
+ operational problems due to lack of maintenance. It may work, it
+ may not. If it doesn't work as advertised, please try 'zopectl
+ debug' instead.
+
+ If you're running Zope with a medusa monitor port, you can connect
+ and interact via a python prompt with a running Zope session, while
+ others interact with it over the web.
Some constraints:
@@ -29,7 +52,7 @@
To use the monitor, start it from the shell prompt like so (as if
from the Zope root):
- python ZServer/medusa/monitor_client.py localhost 8099
+ python lib/python/ZServer/medusa/monitor_client.py localhost 8099
You'll get back a python prompt. To connect with the running Zope
session:
=== Zope/doc/SETUID.txt 1.1 => 1.1.70.1 ===
--- Zope/doc/SETUID.txt:1.1 Fri Aug 9 12:38:30 2002
+++ Zope/doc/SETUID.txt Mon Jul 21 12:34:53 2003
@@ -1,30 +1,29 @@
-ZServer 'setuid()' support
+Zope effective user support
- ZServer (Zope's server) supports 'setuid()' on POSIX systems in order to
- be able to listen on low ports such as 21 (FTP) and 80 (HTTP) but drop
- root privileges when running; on most POSIX systems only the 'root' user
- can do this. Versions of Zope prior to 2.6 had less robust versions
- of this support. Several problems were corrected for the 2.6 release.
+ Zope can bind its network service to low ports such as 21 (FTP) and
+ 80 (HTTP). In order to bind to low ports, Zope must be started as
+ the root user. However, Zope will only run as root long enough to
+ bind to these low ports. It will then attempt to setuid to a less
+ privileged user.
- The most important thing to remember about this support is that you
- don't *have* to start ZServer as root unless you want to listen for
- requests on low ports. In fact, if you don't have this need, you are
- much better off just starting ZServer as a user account dedicated to
- running Zope. 'nobody' is not a good idea for this user account;
- see below.
+ You must specify the user to which Zope will attempt to setuid by
+ changing the 'effective-user' parameter in the zope.conf
+ configuration file to an existing username or UID. All runtime
+ files will be written as this user. If you do not specify an
+ 'effective-user' in the configuration file, and you attempt to start
+ Zope, it will refuse to start.
- If you do need to have ZServer listening on low ports, you will need to
- start 'z2.py' as the 'root' user, and also specify what user ZServer
- should 'setuid()' to. Do this by specifying the '-u' option followed
- by a username or UID, either in the 'start' script or on the 'z2.py'
- command line. The default used to be 'nobody'; however if any other
- daemon on a system that ran as 'nobody' was compromised, this would
- have opened up your Zope object data to compromise.
+ Zope additionally emits a warning if you specify 'nobody' as the
+ 'effective-user'. The rationale for this warning stems from the
+ fact that, historically, many other UNIX services dropped privileges
+ to the 'nobody' account after starting as root. Any security
+ defects in these services could cause someone to gain access as the
+ 'nobody' account on your system. If someone was to gain control of
+ your 'nobody' account they could compromise your Zope files.
- You must also make sure the var directory is owned by root, and that
- it has the sticky bit set. This is done by the command 'chmod o+t
- var' on most systems. When the sticky bit is set on a directory,
- anyone can write files, but nobody can delete others' files in order
- to rewrite them. This is necessary to keep others from overwriting
- the PID file, tricking root into killing processes when 'stop' is run.
+ The most important thing to remember about effective user support is
+ that you don't have to start Zope as root unless you want to listen
+ for requests on low ports (ports beneath 1024). In fact, if you
+ don't have this need, you are much better off just starting Zope
+ under a dedicated user account.
=== Zope/doc/SIGNALS.txt 1.3 => 1.3.44.1 ===
--- Zope/doc/SIGNALS.txt:1.3 Thu Oct 10 10:26:31 2002
+++ Zope/doc/SIGNALS.txt Mon Jul 21 12:34:53 2003
@@ -4,32 +4,23 @@
If you are using Windows then this documentation does not apply.
Zope responds to signals which are sent to the process id
- specified in the file 'ZOPE_HOME/var/Z2.pid'::
+ specified in the file '$INSTANCE_HOME/var/Z2.pid'::
SIGHUP - close open database connections, then restart the server
- process. The common idiom for restarting a Zope server is:
+ process. A idiom for restarting a Zope server is:
- kill -HUP `cat ZOPE_HOME/var/z2.pid`
+ kill -HUP `cat $INSTANCE_HOME/var/z2.pid`
- SIGTERM - close open database connections then shut down. The common
+ SIGTERM - close open database connections then shut down. A common
idiom for shutting down Zope is:
- kill -TERM `cat ZOPE_HOME/var/Z2.pid`
+ kill -TERM `cat $INSTANCE_HOME/var/Z2.pid`
SIGINT - same as SIGTERM
SIGUSR2 - close and re-open all Zope log files (z2.log, event log,
- detailed log.) The common idiom after rotating Zope log files
+ detailed log.) A common idiom after rotating Zope log files
is:
- kill -USR2 `cat ZOPE_HOME var/z2.pid`
+ kill -USR2 `cat $INSTANCE_HOME/var/z2.pid`
- The process id written to the 'z2.pid' file depends on whether Zope
- is run under the 'zdaemon' management process. If Zope is run under
- a management process (as it is by default) then the pid of the
- management process is recorded here. Relevant signals sent to the
- management process are forwarded on to the server process.
- Specifically, it forwards all those signals listed above, plus
- SIGQUIT and SIGUSR1. If Zope is not using a management process (-Z0
- on the z2.py command line), the server process records its own pid
- into 'z2.pid', but all signals work the same way.
=== Zope/doc/TODO.txt 1.18.2.3 => 1.18.2.4 ===
--- Zope/doc/TODO.txt:1.18.2.3 Mon Jul 7 10:52:45 2003
+++ Zope/doc/TODO.txt Mon Jul 21 12:34:53 2003
@@ -2,18 +2,18 @@
changes proposed for the Zope trunk. It is organized into these
categories:
- "BEFORE RELEASE OF ZOPE 2.7B" (items to do before the beta
- release of Zope 2.7)
-
"BEFORE 2.7 FINAL" (things that need to be done before we're
finished, but not currently on the critical path)
"MAYBE NEVER BUT NICE TO HAVE" (items that are not on any critical
path)
---------------------------------
- BEFORE RELEASE OF ZOPE 2.7B
---------------------------------
+ "COMMUNITY CONCERNS" (uncategorized concerns dealing with features
+ missing from HEAD and prior 2.7 releases)
+
+----------------------------------
+ BEFORE RELEASE OF ZOPE 2.7 FINAL
+----------------------------------
Provide more intuitive command line option overrides
@@ -82,38 +82,6 @@
port cannot be bound, an error is raised. The error currently doesn't
include the port number, and should.
-Review impact of missing Data.fs.in
-
- The branch install process doesn't copy the "Data.fs.in" file to an
- instancehome/var directory. This file is the "initial" filestorage
- for Zope that gets copied to "Data.fs" during installation in every
- prior branch of Zope. This file is evil and must die at some point,
- and most of the necessary code to set things up properly in the face
- of an empty Data.fs already exists in OFS.Application.initialize.
- Things seem to work fine without Data.fs.in but we should just give
- it a bit of review to see what gets left out, if anything.
-
- When we find that Data.fs.in isn't necessary, we need to remove it
- from the HEAD.
-
- XXX What is actually needed to verify that it isn't needed?
-
- AAA The best way to do this is to write a unit test which verifies
- that the default objects installed into a "new" ZODB when Zope
- starts are present and working, and their content either matches
- the content of what would have come from Data.fs.in or is "close
- enough". The code that installs these default objects exists in
- the initialize function within lib/python/OFS/Application.
-
-Integrate DBTab functionality
-
- Integrate DBTab functionality driven by zconfig.
-
-
------------------
-BEFORE 2.7 FINAL
------------------
-
Review the Zope Book 2.6 Edition chapters and come up with revisions
or at least create a Zope 2.7 Install HowTo
@@ -187,15 +155,6 @@
disentangled from one another and specifiable individually.
- Need to support arbitrary storage types.
-
- - ZOPE_TRUSTED_PROXIES envvar is not configureable via config file.
-
- - REST_INPUT_ENCODING and REST_OUTPUT_ENCODING are not config-file
- configurable
-
- - DATETIME_FORMAT is not config-file configurable.
-
- - Is ZEO_CACHE_TRACE configurable?
- Provide --swhome and ---with-python switch to mkzopeinstance, which will
allow folks to create an instance that points to particular (known)
=== Removed File Zope/doc/ENVIRONMENT.txt ===
=== Removed File Zope/doc/LOGGING.txt ===