OpenCA uses the usual Open Source method to configure the source. We only use configure to compile and install the software but we don't use configure for the configuration of the installed system. configure make some defaults settings but the real configuration is described in the post-install section.
We will describe the ideas and options in the next section grouped by such things like path settings, mail, web-server related stuff. If you don't understand an explanation then please contact <openca-user@lists.sf.org>. The install options are now lesser because we changed the installation process from 0.9.1 to 0.9.2 to get usable packages and better internationalization.
We don't document the general options of configure because it is not our job to document autoconf. We will only describe OpenCA specific options.
You should define the used system before you start configureing OpenCA itself. OpenCA must know several parameters about your system to work properly.
Table 3.2. Supported parameters for host configuration
Parameter | Description |
---|---|
--with-openssl-prefix=DIR | Usually OpenSSL is present on the most Unix systems because it is the best available Open Source cryptotoolkit. The problem is that several old distributions only include support for OpenSSL 0.9.6 but OpenCA needs version 0.9.7. If you install an OpenSSL from source then it installs in /usr/local/ssl. This is the directory which you must specify. If you system already includes a proper version then you have not to use this option or you can enter /usr on the most linux boxes. |
--with-openca-user=ARG | OpenCA installs several files which should not be owned by the webserver user. Usually the owner can be root or special OpenCA user. It is recommended to use another user than root. |
--with-openca-group=ARG | OpenCA installs several files which should not be owned by the webserver group. Usually the group can be root or special OpenCA group. It is recommended to use another user than root. If you install several CA you can setup a group openca or pki for example. |
We have three different groups of paths - common stuff, prefixes for the different components of OpenCA and the paths for files of the webserver.
One path cannot be classified - --with-module-prefix=DIR. This path can be used to put all Perlmodules which OpenCA installs in one directory to be able to remove OpenCA from your system without any residues. It is also a good idea to use this option if you need different OpenCA installations with different versions of OpenCA on your system. Later versions of OpenCA can have different modules with different interfaces which are not backwards compatible.
OpenCA includes a directorystructure to store all relevant data in one central place. This place can be specified with --with-openca-prefix. This installation option is recommended for normal installations from the source code. Secure or not the most users want to install packages (e.g. RPM or DEB). Packages have the big advantage that you remove or add a software without any risks. In this case we have to support the package maintainers with configuration options to build packages which conform with the guidelines for the distros. Therefore you can use --with-etc-prefix, --with-lib-prefix and --with-var-prefix too.
Today there are six different components - ca, ra, ldap, pub, node and scep. Every component must have a different name to have distinguished configuration files and distinguished paths. All the names will be calculated automatically. You have only to edit these prefixes if you need a special configuration like a second RA on the same machine.
The webserver configuration is the most complex and most simple part of the configuration too. If you have single http-server for OpenCA then you only need four options to configure OpenCA for this server. If you have a full featured corporate portal then you can integrate this software seemlessly in the the server. Therefore you can configure a lot of details. So we hope you find a good tradeoff ;-)
Every webserver needs some basic informations. These informations are the hostname (--with-web-host), the user (--with-httpd-user) and the group of the server (--with-httpd-group). These are the rudimentary informations which OpenCA needs before you can start configuring the paths. The defaults are an empty hostname, nobody and nogroup.
The most trivial installation case is the default apache installation. In this case you have only to set --with-httpd-fs-prefix to the directory where your apache is. All other directories will be set automtically.
The standard webserver doesn't use Apache's default installation. Therefore it is possible to configure every detail of the installation. The first splitting is into CGI (--with-cgi-fs-prefix) and HTDOCS (--with-htdocs-fs-prefix). The most test systems don't need the other options. They have only to know where the appropriate directories are.
Our software was designed for really big companies and organizations too. They have usually portals for their employees and customers. If you have to integrate an OpenCA interface into such a portal then there are good news for you - you don't have to edit paths and links by hand. You can configure the placement of CGI and HTDOCS area of every interface seperately. The options are --with-(ca|ra|ldap|pub|node|scep)-(cgi|htdocs)-fs-prefix). We think that more flexibility is not necessary. So if you think OpenCA is to unflexible then write a mail to us with your ideas.
The mailoptions are deprecated too. Please read the post-install section to understand how to configure mail. Please don't use the configure option because they can be removed in the next releases.
You can enable three extra features for compilation and installation. SCEP and OCSP can be enabled because they are extra softwarepackages which can work independently from OpenCA but they are included in the distribution. The option --enable-package-build is used to support package maintainers. If it is activated all common parts of OpenCA are not installed automatically. This allows packagers to build seperate conflict free packages for every interfaces because all Perl modules and the common stuff can be put into seperate packages.