[ start | index | login ]
start > knowledgebase > linux > webserver > setting up plone

setting up plone

Created by retep. Last edited by dominic, one year and 277 days ago. Viewed 3,044 times. #13
[diff] [history] [edit] [rdf]
labels
attachments

Skeleton Plone Install Notes

Updated by Justin Nov 12, 2006

Plone is an enterprise class Content Management System, or ECM/CMS, built using Python and XML on the Zope Application Server and Framework. Plone is translated into around fifty languages and provides world-class translation tools and for this reason is the official CMS of choice of most of the world's governments. Plone competes with thousands of CMS products such as EMC Documentum, Vignette Story Server, Drupal, and Joomla. Customers may select a solution such as Drupal or Joomla because it runs in PHP and MySQL and is simpler to deploy alongside other such applications. Plone is a good choice for them if they want something which will last a long time, provides a modular approach to customization, and is highly scalable, especially across several machines in order to handle thousands of requests per second. It's architected to interoperate with web caches both on client and server, and provides unmatched Programmer Productivity via the Python programming language.

For new users of Plone with Plone 2.5, a "Universal" Linux installer is available which, for the most part, executes these steps via a shell script. We have had reports of this failing on some Linux distributions, namely Ubuntu6, and its' default configuration may not be ideal for everyone, so knowing how to install from source is still poignantly important.

To use the Universal Linux / Unix installer:

cd /tmp
wget "http://easynews.dl.sourceforge.net/sourceforge/plone/Plone2.5-UnifiedInstaller-r2.tgz"
tar zxvf Plone-2.5-UnifiedInstaller-r2.tgz
cd Plone-2.5-UnifiedInstaller
./install.sh

This will install everything into /opt/Plone-2.5 and configure a "zeo cluster" with three independent server processes:

  • A ZEO, or Zope Enterprise Objects, Master, this is the database server
  • Two ZEO Clients, or Application Servers
Some users point their port 80 at one client, while using another for management tasks, and others use a tool such as balance to round-robin requests between the two zeo clients for increased performance.

To control the cluster, use the scripts in /opt/Plone-2.5/bin.

To install from source:

There is a great tutorial which most of this is based on, with some small diversion, at:

>>http://plone.org/documentation/tutorial/robust-installation

First and foremost, Plone requires Zope to work, and Zope depends on Python, so the install process is essentially to get appropriate versions of Python and Zope going, then add in the Plone 'products'.

The following are skeleton notes I took from one install. The next install chance I get I'll flesh them out a bit more.

I install everything relative to a given root which I refer to as $ZOPE_HOME, this could be any of:

/home/zope
/home/plone
/usr/local/plone/
/usr/local/zope
/opt/zope
/opt/plone

My preference is for /home/zope, because you want to run everything as a zope user anyway, and it makes more sense to focus on Zope being the server application, whilst Plone is one of many applications which can run in a Zope.

I unpack source code into $ZOPE_HOME/src, and software such as Python and Zope itself I install into $ZOPE_HOME/base/$PACKAGE_NAME/$VERSION. Over the life of a Plone site, it's likely to depend on multiple versions of Zope, which in turn have specific requirements for the version of Python in use.

For Zope 2.7 or 2.8, install Python 2.3.5 from source, for Zope 2.9 or 2.10, install Python 2.4.3. Always consult Zope's README.txt if you are not familiar with the specific version of Zope, as it is very important to use a certified version of Python, especially once which has been security audited and for which all unit tests pass. A side note: Installing python is necessary at least for RHEL4 and WBEL3, your distro may vary, but it is always recommended. Zope may stay a major version behind Python at times, due to aforementioned certification and testing process, and the last thing that you want is an OS Python upgrade to render Zope and Plone useless.

Example for Zope 2.9.4, which is recommended for Plone 2.5:

export ZOPE_HOME=/home/zope
mkdir -p $ZOPE_HOME/src
cd $ZOPE_HOME/src
wget "http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2"
tar jxvf Python-2.4.3.tar.bz2
cd Python-2.4.3
./configure --prefix=$ZOPE_HOME/base/python/2.4.3
make && make install
wget "http://www.zope.org/Products/Zope/2.9.4/Zope-2.9.4-final.tgz"
tar zxvf Zope-2.9.4-final.tgz
cd Zope-2.9.4-final
./configure --with-python=$ZOPE_HOME/base/python/2.4.3  --prefix=$ZOPE_HOME/base/zope/2.9.4
make && make install

I jam the instances into $ZOPE_HOME/instance/$FOO, like so:

mkdir -p $ZOPE_HOME/instance
cd $_ # $_ is the last argument to the last command, in a bourne shell
../base/zope/2.9.4/bin/mkzopeinstance.py --dir=$FOO

For convenience, upgrading, and testing purposes, I keep the Plone Products in $ZOPE_HOME/src and symlink into $INSTANCE_HOME/Products, $INSTANCE_HOME being the full path to the instance we just created. So, for Plone 2.5:

cd $ZOPE_HOME/src
wget "http://easynews.dl.sourceforge.net/sourceforge/plone/Plone-2.5.tar.gz"
tar zxvf Plone-2.5.tar.gz
mkdir Products-2.5-shared-bundle
for i in Plone-2.5/*;
  do ln -s $ZOPE_HOME/src/Plone-2.5/$i Products-2.5-shared-bundle/$i;
done
rm -rf $INSTANCE_HOME/Products # empty by default
ln -s $ZOPE_HOME/src/Products-2.5-shared-bundle $INSTANCE_HOME/Products

I maintain a master folder, per plone version, which contains absolute symlinks to each Product in use. This makes it easy to manage a pool of addons and to start from scratch without re-downloading.

Plone is downloaded from SourceForge, so the url may change, I start at:

>>http://plone.org/products/plone/releases/

For Plone 2.5, that sends us to:

>>http://prdownloads.sourceforge.net/plone/Plone-2.5.tar.gz?download

I stop the download and copy / paste the download URL so that I can use wget on the server, as shown above.

Zope is managed, by default, using the command $INSTANCE_HOME/bin/zopectl stop|start|fg, and may also be managed using a service monitor such as daemontools by creating a custom version of the $INSTANCE_HOME/bin/runzope script. It's important to use the scripts in each instance, because they contain absolute paths to Zope and are designed to properly set up its' environment.

Add $ZOPE_HOME/bin/zopectl start to /etc/rc.local so zope will start up on bootup - this is not necessary when running under daemontools.

Set the zope username to root and the zope password to what you wish.

Set the 'effective user' under which Zope runs, e.g. adduser zope. All files under /usr/local/plone should be owned by that user. e.g. run

chown -R zope:zope $ZOPE_HOME

You can then access the zope public root at:

"http://yourip:8080/"

The root of ZMI, or the Zope Management Interface, can be accessed most easily at:

"http://yourip:8080/manage_main"

I recommend using this interface over the frames-driven /manage interface, as I feel it's simpler. You can tack /manage_main onto the end of any Zope / Plone URL to get a context-specific ZMI.

Now that you are in ZMI, select "Plone Site" from the drop-down and create a Plone Site, or leave this up to the customer, as you prefer. Even if you are leaving this up to the customer, you should confirm that "Plone Site" is an option, and try creating a throwaway site to be sure that everything is kosher.

Plone and Zope should be backed up indirectly, using the repozo.py hotbackup tool, rather than directly having the $INSTANCE_HOME/var, especially the Data.fs file within, backed up, as it's unsafe to read this file while the server is running. I've submitted a patch for inclusion into Zope which will properly set this up, but for now, the process is a bit manual.

In $ZOPE_HOME/base/$VERSION/bin, you will find a script named repozo.py which expects to run under the same version of Python as Zope, with all of Zope's environment. In order to accomplish this, I create a copy of the runzope shell script in each instance, pointing to repozo.py instead of Zope's run.py. I also create an $INSTANCE_HOME/backup folder, to which I point repozo via the -r option, usually in a crontab entry like so:

25 * * * * $INSTANCE_HOME/bin/repozo -B -v -r $INSTANCE_HOME/var/backup  -f $INSTANCE_HOME/var/Data.fs -Q -z

Migrating from an old instance on the same or another server? Make sure to:

  • Make a copy of your existing $INSTANCE_HOME/var/Data.fs - make sure Zope is not running when you do this, or use repozo, the incremental backup tool for ZODB. Whether you have existing repozo backups or new ones, send these in a tar, zip, or other archive file.
  • Use -h (dereference) flag for tar to make a backup of $INSTANCE_HOME/Products/, you can also --exclude=*.pyco, but it's not necessary.
You should reconstruct Products/ from scratch periodically and be aware of what addons you have available, installed, and for what purpose. The less code you run, the less likely you are to have conflicts, and your zope will start faster.

This is also something that RimuHosting Support can help you with if it is daunting for you.

no comments | post comment
Powered by snipsnap.org Found a mistake in a howto? Let us know via an email to p.blikibugs at rimuhosting com.