3. Installation Issues

3.1. FreeBSD, OpenBSD and OpenCA

Please ignore this section for OpenCA 0.9.2.0+ and snapshots after 2004-Sep-15.

3.1.1. make

FreeBSD and potentially several other BSDs use an own make. Nearly the complete development of OpenCA is done on Linux. The result is that our makefiles works perfectly with GNU make but there are several unresolved problems with FreeBSD because we cannot test and fix on FreeBSD. The solution is to add GNU make to configure. You can do this this way:

Please check Makefile.global_vars to include the correct setting of MAKE. If the correct setting of make is missing then please add the following line:

GNU make is fully tested with OpenCA.

3.1.2. install

There is an additional problem with install like with make. FreeBSD doesn't support the parameter -D. This parameter is only required if some of the used installation paths like BINDIR do not exist. If you perform a normal installation and use default paths then there should be no problems without -D.

You have to check Makefile.global_vars.in before you run ./configure or Makefile.global_vars after you run ./configure. There you have to remove the parameter -D from the definition of the variable INSTALL.

If you are not the hacker which like to dig for bugs and the removal of -D doesn't work then you have one final option. You can install the port "coreutils" which includes the GNU install. this is not a real bugfix but it works.

3.2. Solaris and OpenCA

Please ignore this section for OpenCA 0.9.2.0+ and snapshots after 2004-Sep-15.

3.2.1. make

Solaris has the same problems like the BSDs. The Solaris make doesn't work with OpenCA's makefiles. The solution is to install the binutils and gmake from sunsolve. You can configure OpenCA after the installation at this way:

Please check Makefile.global_vars to include the correct setting of MAKE. If the correct setting of make is missing then please add the following line:

GNU make is fully tested with OpenCA.

3.3. What is a hierarchy level?

OpenCA 0.9.1 and earlier includes some protection mechanism to avoid state injections during the dataexchange. Therefore you have to configure the level at which OpenCA performs the dataexchange, so that ./configure can make a good preconfiguration. This is only correct for 0.9.1. 0.9.2+ uses OPENCADIR/etc/config.xml to configure the dataexchange.

  1. If you export from a public area to a server with the RA then must use pub.

  2. If you export from a server with a RA to a server with a CA then you have to use ra.

  3. If you export from a server with a RA to a server with a public interface then you have to use ra.

  4. If you export from a server with a CA to a server with a RA interface then you have to use ca.

  5. If you have another case then you have to chosse one of the above defined options and then you have to edit the options for the dataexchange manually like described in the administrator guide.

3.4. Undefined subroutine &main::xyz

Usually the errortext is a little bit more descriptive and looks like this:

Example E.4. Full errormessage for missing functions

[Thu Oct 09 14:50:52 2003] [error] [client 127.0.0.1] Undefined
subroutine &main::configError called at /var/www/cgi-bin/ca/ca line 86.,
referer: http://localhost/htdocs/ca/ 

The reason for such an error is a missing library - in this case misc-utils.lib. There is only one well-known error - you used --enable-package-build as configure option. This happens if somebody uses a configure example which is used for package builds. The disables the installation of all common software parts like modules, libraries and configuration files. If you configure again without --enable-package-build and then run make install-xyz again then all libraries should be present.

3.5. Symbolic link installaton failed

Several user observed that OpenCA 0.9.1.x installation failed during the installation of symbolic links for commands. The errormessage simply reports an already present symbolic link.

Example E.5. Already present symbolic link

 make[8]: Entering directory
`/home/linux/tar/openca-0.9.1.2/src/web-interfaces/ca/cmds'
cd /usr/local/openca.0.9.2/openca/lib/servers/ca/cmds; \
        ln -s ../../../cmds/add_module
ln: `./add_module': File exists
make[8]: *** [/usr/local/openca.0.9.2/openca/lib/cmds/add_module] Error 1
make[8]: Leaving directory
...
make[1]: Leaving directory `/home/linux/tar/openca-0.9.1.2'
make: *** [install-ca] Error 2 

The reason for this failure is a defect symbolic link. The makefile removes an already present symbolic link only if the symbolic link is correct. If the target of the symbolic link doesn't exist then the symbolic link is not removed and the error occurs.

3.6. After the installation all common parts are missing

If the command make install-* doesn't report an error and after the installation all common parts like modules, configuration, libraries, openca-sv and commands are missing then please check your configure options. Sometimes the people simply copying our configuration examples without noticing that some of these examples are used for package creation. These examples include an option --enable-package-build. This option prevents all common stuff from installation to build better packages.

3.7. Conflicting Modules

Sometimes there are reports about errormessages which signal an unknown login type or another empty configuration option. First you should check that there are at minimum two running processes - one is the OpenCA daemon which handles the requests and one is the XML cache. If there is only one server then there is a problem during the startup of the daemons. There two well known issues during the startup - wrong permissions and duplicate installations of a module. Please allways check first that there are no problems with the permissions.

If you are sure that you have no problem with the permissions then it is usually a problem with different installed version of the Perlmodule XML::Twig. This can cause a crash of the daemon at startup or always empty results for a configurationfile. First you should search for the different version of XML::Twig.

Example E.6. Search for XML::Twig modules

## every Unix
find / -name Twig.pm -print

## rpm based Unix (RedHat, SuSE, Mandrake ...)
rpm -qa | grep -i twig

## dpkg based Unix (Debian)
dpkg -l "*twig*"
        

After you know the installed modules you have to remove all versions older than 3.09. OpenCA was developed with 3.08 and 3.09 but the last tests were only performed with 3.09. So we don't know what's happen if you use an earlier version.

3.8. The xml path to the access control is missing

If you installed OpenCA and try to login to OpenCA then it can happen that you see the errormessage The xml path to the access control is missing. The errorcode should be 6292010. Usually the missing XML path is access_control/acl_config/module_id.

Please check that a XML parser is installed on your system. We use XML::Twig to parse huge XML files. This module uses an already installed XML parser. If there is no XML parser installed for XML::Twig then we cannot read and interprete our configuration files.

3.9. Unknown Login Type

Sometimes you get the errormessage An unknown login type was specified in the configuration! after you installed OpenCA and try to login for the first time. The errorcode in this situation should be 6273966.

Please check the UID of the socket which the XML cache uses. Sometimes the UID of the socket is root and not the UID of the webserver. We don't known how this can happen. Please verify that this socket is not owned by root.

To solve the problem you can stop openca with openca_stop or openca_rc stop. Then you have to remove the socket OPENCADIR/var/tmp/openca_xml_cache. After this you can start openca again and please verify that the permissions and owner are now correct.

3.10. Type Mismatch during request generation with Internet Explorer

If an Internet Explorer reports a type mismatch during the request generation then please check the configuration of your Apache. Usually the reference to the VB script ieCSR.vbs is wrong. This happens if the document root of the Apache is wrong.

3.11. openca(_rc) start failed

Example E.8. Failed startup with wrong Net::Server version

#> /etc/rc.d/init.d/openca start
Starting OpenCA: Process Backgrounded
2004/04/22-12:34:19 OpenCA::Server (type Net::Server::Fork) starting!
pid(3195)
Binding to Unix socket file /var/lib/openca/tmp/openca_socket using
SOCK_STREAM
Setting gid to "73 73"
Setting uid to "73"
Couldn't POSIX::setuid to "73" []
        

This errormessage is caused by an outdated perl module Net::Server. Please update to a Net::Server version higher or equal to 0.86. The server itself will usually starting nevertheless the error is reported or not. Please use ps -efa to check for the two necessary daemons - XML cache and OpenCA server.

3.12. Missing modules

3.12.1. XML::Parser

If you see one of the following errormessages during the compilation or installation of OpenCA then you are missing the perl module XML::Parser.

The first symptom can be a failing make in XML::Twig. Please notice that a second make in the same directory does not show any anomaly. Sometimes only the first make shows up an error message because of the missing XML parser.

The second symptom can happen if you try to configure your OpenCA software.

If you try to locate the installed Twig.pm files and check there length then usually only Twig.pm.slow is not empty.