Preparing the Server¶
Preparing to install Plone¶
Plone and Zope are generally not available via platform package or port systems. So, you can’t say “apt-get install plone” to add it to a Debian server. (There are packages and ports out there, if you search hard enough to find them. But don’t do it: they’ve generally had a poor record for maintenance.)
This means that you typically need to build Plone (compiling source code to binary components) on your target server. Binary installers for Plone are available for Windows and OS X, but not for Linux and BSD systems. And, the OS X binary installer isn’t really meant for production use - though it’s great for theme and add-on development and testing.
A build environment for Plone requires two sets of components:
- The GNU compiler kit and supporting components
- The development versions of system libraries required by Plone. The libraries themselves are in common use, and often included in standard distributions. But, we need the development header files.
It's generally best to install as many of these components as you can via platform packages or ports. That way, you'll be able to use your platform's automated mechanisms to keep these up-to-date, particularly with security fixes.
System python?¶
Plone's Unified Installer will install a suitable Python for you. However, you may wish to use your system's Python if it meets Plone's requirements. Plone 4.0 and 4.1 require Python 2.6. Plone 4.2+ will work with Python 2.6 or 2.7.
If you choose to use the system Python, you'll want to use virtualenv to create a virtual Python environment to isolate the Zope/Plone install from system Python packages. The Unified Installer will automatically do this for you. If you're not using the Unified Installer, learn to use virtualenv.
Basic build components¶
All installs will require the basic GNU build and archive tools: gcc, g++, gmake, gnu tar, gunzip, bunzip2 and patch.
On Debian/Ubuntu systems, this requirement will be taken care of by installing build-essential. On RPM systems (RedHat, Fedora, CentOS), you'll need the gcc-c++ (installs most everything needed as a dependency) and patch RPMs.
On Arch Linux you'll need base-devel (installs most everything needed as a dependency).
System Python¶
If you're using your system's Python, you will need to install the Python development headers so that you'll be able to build new Python components. On Debian/Ubuntu systems, this is usually the python-dev package. Port installs will automatically include the required python.h requirement as part of their build process.
If you're using your system Python, you will not need the readline and libssl development packages mentioned below. The required libraries should already be linked to your Python.
System libraries¶
For any install, the development versions of:
- libssl
- libz
- libjpeg
- readline
- libxml2/libxslt
If you're using the System Python, add:
- build-essential (gcc/make tools)
- python-dev
Without the system Python (Unified Installer builds Python):
build-essential (gcc/make)
Optional libraries¶
If Plone can find utilities that convert various document formats to text, it will include them in the site index. To get PDFs and common office automation formats indexed, add:
- poppler-utils (PDFs)
- wv (office docs)
Development versions are not needed for these.
Platform notes¶
Debian/Ubuntu¶
Use
apt-get
install. The matching package names are:
- build-essential
- libssl-dev
- libz-dev
- libjpeg-dev
- libreadline-dev
- libxml2-dev
- libxslt-dev
- python-dev
Fedora/CentOS¶
Using
yum
install:
gcc-c++ patch openssl-devel libjpeg-devel libxslt-devel readline-devel make which
OpenSUSE¶
Using
zypper
in
- gcc-c++
- make
- readline-devel
- libjpeg-devel
- zlib-devel
- patch
- openssl-devel
- expat-devel
- man
--build-python will be needed as the system Python 2.7 is missing many standard modules.
OS X¶
Installing XCode and activating the optional command-line utilities will give you the basic GNU tools environment you need to install Plone with the Unified Installer. You may also use MacPorts (the BSD ports mechanism, tailored to OS X) to install libjpeg, libxslt and readline. If you do, remember to keep your ports up-to-date, as Apple's updates won't do it for you.
Creating a Plone user¶
While testing or developing for Plone, you may have just used an installation in a home directory, owned by yourself. That is not suitable for a production environment. Plone's security record is generally excellent, however there have been - and probably will be again in the future - vulnerabilities that allow an attacker to execute arbitrary commands with the privileges of the process owner. To reduce this kind of risk, Plone - and all other processes that allow Internet connections - should be run with user identities that have the minimum privileges necessary to maintain their data and write logs.
In a Unix-workalike environment, the most common way of accomplishing this is to create a special user identity under which you will run Plone/Zope. That user identity should ideally have no shell, no login rights, and write permissions adequate only to change files in its ./var directory.
The ideal is hard to achieve, but it's a good start to create an unprivileged "plone" user, then use "sudo -u plone command" to install Plone and run buildout. This is basically what the Unified Installer will do for you if you run its install program via sudo. The installer uses root privileges to create a "plone" user (if one doesn't exist), then drops them before running buildout.
Don't run buildout as root!
Don't use bare "sudo" or a root login to run buildout. Buildout fetches components from the Python Package Index and other repositories. As part of package installation, it necessarily executes code in the setup.py file of each package.