Introduction:

This article describes a customer’s experience with their poll thread configuration while upgrading from IDS 7.31.FD9 to IDS 10.00.FC6. This particular upgrade was related to their busiest IDS server running on an HP Superdome. Typically, one could observe upwards of at least 3000 short-lived soctcp connections on this system.

Original IDS 7.31 Configuration:

Key configuration settings that were active in the IDS 7.31 environment were initially used after upgrading to IDS 10.00:

• 23 CPU VPs
• 20 poll threads running on NET VPs
• multiple server aliases

Optimal IDS 10.00 Configuration:

An optimal configuration was ultimately determined and incorporated the following configuration settings in the IDS 10.00 server:

• 23 CPU VPs
• a handful (3-5) of poll threads running on NET VPs
• enable new IDS 10.00 ONCONFIG parameter, FASTPOLL
multiple server aliases

Relevant Testing:

Stress testing supportive of this optimal configuration was conducted on a 16-processor/32-core HP server using the latest IDS 7.31 and IDS 10.00 64 bit products. The testing involved a multi-threaded ESQL/C application that would spawn 3000 threads over 3 server aliases. Each thread would connect to the server, complete a small amount of read-only work and disconnect from the server 30 times. These 90,000 total connections mimicked the customer’s workload and considered poll threads running both on CPU VPs (inline) and on NET VPs against servers configured with 23 CPU VPs. The following chart shows results from the stress testing that were considered for the optimal customer configuration:

Jeff Laube

History:

Through online forums and technical support cases, Informix users have requested the ability to limit the number of connections to IDS servers.

Introduction:

Available now in 11.50 IDS, the ONCONFIG parameter, LIMITNUMSESSIONS, can be used to define the maximum number of sessions that you want connected to IDS.

This ONCONFIG parameter uses the following syntax:

LIMITNUMSESSIONS maximum_number_of_sessions, print_warning

The maximum_number_of_sessions option defines the limit for the maximum number of sessions and can be set to a value in the range of 0 to 2,097,152. The value of 0 is the default and indicates that this feature is turned off.

The print_warnings option can be set to 1 or 0. When this value is set to 1, a warning message is written to the online.log when the number of sessions approaches the limit. These warning messages are not reported when the value is set to 0. The default is 0.

The limit imposed by LIMITNUMSESSIONS takes effect when the database server is shut down and restarted. It can also be started, modified or stopped dynamically by using onmode –wf or onmode –wm.

When the number of connections reaches this limit, new connection requests are rejected with the error -25571 Cannot create a user thread, until the number of connections fall below this limit. A message is reported to the online.log when this limit has been reached.

Database Server Administrators (DBSAs) are the exception to this limit. When the limit has been reached, a DBSA user will still be allowed to connect to IDS.

Example:

The following example specifies that you want a maximum of 100 sessions to connect to the server and that you would like a warning message printed to the online.log when the number of connected sessions approaches 100.

LIMITNUMSESSIONS 100,1

For more information:

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.admin.doc/ids_admin_1221.htm

Disclaimer:

This feature is not intended to enforce terms or conditions of the User License Agreement.

 

Jeff Laube

Introduction:Multiple installation of IBM Informix Dynamic Server is now enabled in IDS 11.50 xC2. With this, users will be able to install multiples copies of IDS on a single machine with the ability to create instance(s) per installation. For example, a user can have 11.50 xC1 and 11.50 xC2 co-existing on the same machine with instances related to each installation running on that machine.

With this new effort, a user that has an installation of IDS 11.50 can invoke setup.exe and will be presented with existing installation of IDS on the machine. The user can then make a choice between installing a new copy of IDS and maintaining an (one of the) existing copy(ies). If there is an existing installation of IDS 11.50 on a machine, a user that launches setup.exe in graphical mode will be presented a panel similar to the one below:

However, with an existing installation of IDS 11.50, launching setup.exe in silent mode will require a maintenance response file. Without a maintenance response file or with an installation response file, the installer will abort. To install a subsequent copy of IDS 11.50 in silent mode, the user should pass the ‘-multiple’ command line option to setup.exe.

In addition to the "-multiple" command line option, there are 2 command line options for maintenance namely "-path" and "-instnum". These 2 new command line options are used to launch maintenance mode for a specified installation. Since they perform the same functionality, they should be used interchangeably and not in conjunction with one another.

Usages of the newly implemented options:

-multiple usage

setup.exe -multiple

This option can be used in conjunction with other installation command line options. E.g.

setup.exe -multiple -s -f1"C:\TEMP\server.ini" -f2"C:\TEMP\server.log"

-path usage

setup.exe -path [installation path]

The user invokes setup.exe with the ‘-path’ option passing the installation path for which maintenance is required. This option can be used in conjunction with other maintenance command line options. E.g.

setup.exe -path [installation path] -s -f1"C:\uninst.ini"

-instnum usage

setup -instnum [installation number]

The user invokes setup.exe with the ‘-instnum’ option passing installation number for which maintenance is required. Note that each installation is tagged with an installation number in shortcut menu (except for the first installation which doesn’t have a tag). This option can be used in conjunction with other maintenance command line options. E.g.

setup.exe -instnum [installation number] -s -f1"C:\uninst.ini"

For more information on installing IDS, visit http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp

Tosin Ajayi

The newest version of OpenAdmin Tool for IDS, Version 2.22, is available now! The latest features center on a Enterprise Replication (ER) monitoring and security.

ER Plug-in Version 1.1: Version 1.1 of OAT’s ER plug-in greatly enhances OAT’s Enterprise Replication monitoring capability.

• The ER Routing Topology page has been transformed to allow monitoring of all nodes in the ER domain from a single page without having to drill-down on each node. Users can set thresholds for key ER statistics and then use the Routing Topology page to monitor alerts and profile data for each node in their domain. (Requires IDS server version 11.50xC2.)



• The ER Node Details pages have been expanded to show errors for the current node or the entire ER domain (Errors tab) and to list current values of the ER configuration parameters (Configuration tab).
• Check out a demo of the newest ER monitoring features here: ER Monitoring with Alerts Demo

Secure SQLToolbox: OAT admins can now choose to turn on an additional level of security for the SQL Toolbox pages. If “Secure SQLToolbox” is turned on, OAT users will have to re-authenticate in order to view schema data or use the SQL Editor. This additional layer of security can be used to ensure that OAT users are not automatically allowed free access to databases or tables as the user informix.

Download OAT Version 2.22 now at https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-informixfpd

For additional information on OpenAdmin Tool for IDS, including feature details, screenshots and demos, go to www.openadmintool.org.

Also check out the new DeveloperWorks article on writing custom plug-ins for OAT: www.ibm.com/developerworks/db2/library/techarticle/dm-0808vonbargen

Erika Von Bargen

Introduction

HTTPS protects the OAT webserver from eavesdropping, tampering, and message forgery. It protects the OAT webserver from hackers who are trying to secretly listen or interfere with the OAT network. Enabling HTTPS will encrypt OAT clients’ messages before sending it to the OAT webserver. This prevents hackers from listening over the line and stealing sensitive information. Sometimes hackers will setup a fake OAT webserver and deceive OAT clients as to whom the real OAT host is. Enabling HTTPS also allow OAT clients to authenticate with the OAT host, so that hackers cannot deceive OAT clients with a fake OAT webserver.

Please note that HTTPS only encrypts communication between OAT webserver and OAT client. It does not encrypt communication between IDS server and the OAT webserver.

IBM® Informix® Dynamic Server, Version 9.4 and later, enables encryption of data between IDS server and OAT webserver using an encryption communication support module. You can find more information in the following link:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0401dandekar/index.html

Enabling HTTPS in OAT will involve the following steps:

• 1. Replacing OAT’s Apache webserver with another mod_ssl enabled Apache webserver.
• 2. Creating an encryption key and a certificate for your new OAT webserver, so that OAT clients can authenticate your webserver based on your certificate.
• 3. Configure httpd.conf (the Apache configuration file) to enable HTTPS

Replacing OAT’s Apache Webserver with another mod_ssl enabled Apache Webserver

In order to use OAT with https, you will need to have an apache webserver, PHP with some extensions and the apache mod_ssl module. HTTPS functionality is provided by the apache mod_ssl module. Using the OAT automated installer will install an apache webserver and PHP with all the required PHP extensions, however apache webserver bundled with installer is NOT shipped with the mod_ssl module.

Therefore you have to install another apache webserver compiled with the mod_ssl module to replace OAT’s apache webserver. Then dynamically load OAT’s PHP apache handler (a file named libphp5.so, or php5apache2_2.dll on windows, which is the apache and php ‘glue’) to your new apache webserver.

Dynamically loading the mod_ssl module to OAT’s original apache webserver is not possible because the version of OAT’s original apache webserver is 2.2.4. Mod_ssl dynamic module only supports the older apache 1.3.x, It does not support OAT’s apache webserver.

On Linux and Mac OS X,

In order to compile Apache with mod_ssl support, you need to have OpenSSL installed. OpenSSL might have been installed on your Linux distribution already and you only need to find out the installation directory. Note that the OpenSSL binaries have to be 32-bit, because the binaries from the OAT automated installer are 32-bit. We suggest doing this only on a 32-bit machine so that there will be no architectural mismatch among the binaries.

If OpenSSL has not been installed already, you can download the latest source code release from here:

http://www.openssl.org/source/

Then you have to compile the OpenSSL source code. Note that you have to compile 32-bit OpenSSL binaries because the binaries from the OAT automated installer are 32-bit. This can be done by setting CFLAGS to be –m32. Use the following commands:

cd /path/to/openssl/source/code
export CFLAGS=-m32
./config --prefix=/openssl/installation/directory/ --openssldir=/openssl/installation/directory/
make
make install

Stop OAT’s apache webserver by running the /oat/installation/directory/StopApache script. Rename OAT’s Apache_2.2.4 directory to Apache_2.2.4_noSSL. This is a will serve as a backup copy of the apache binaries. You will also need to use some configuration files from this backup Apache directory in later steps. Do make a copy.

Then you have to compile the latest Apache with mod_ssl support. Download the latest Apache source code and compile with the following commands. Note that you have to compile 32-bit Apache binaries because the binaries from the OAT automated installer are 32-bit. This can be done by setting CFLAGS to be –m32. The compilation prefix should match the old OAT apache’s directory (/oat/installation/directory/Apache_2.2.4/)

cd /path/to/apache/source/code
export CFLAGS=-m32
./configure --prefix= /oat/installation/directory/Apache_2.2.4/ --enable-so --enable-ssl --with-ssl= /openssl/installation/directory/
make
make install

Right now Apache should be installed with mod_ssl support. Use the following commands to check if mod_ssl is enabled in Apache.

cd /oat/installation/directory/Apache_2.2.4/bin/
./httpd –M
(Here you will see a list of Apache modules. See if the SSL module is on the list)

Then you have to change the Apache configurations file to load OAT’s PHP Apache handler (The PHP and Apache ‘glue’). Edit the Apache configuration file (/oat/installation/directory/Apache_2.2.4/conf/httpd.conf). Add the following lines. Uncomment if these lines exist but are commented out.

LoadModule php5_module /oat/installation/directory/PHP_5.2.4/libphp5.so
AddType application/x-httpd-php .php
PhpIniDir ‘/oat/installation/directory/PHP_5.2.4/lib’
Setenv INFORMIXDIR ‘/oat/installation/directory/Connect_3.50/’

Search for the line “Listen 80” in the httpd.conf file. This indicates the port number that the OAT webserver should run on. You should use the same port number as OAT’s original Apache webserver that comes with OAT installer.

Search for the line “ServerName www.example.com:80” in the httpd.conf file. This indicates the name and the port that the server uses to identify itself. You should use the same ServerName as the original non-SSL Apache webserver that comes with OAT installer.

Search for the line “DirectoryIndex index.html” in the httpd.conf file. This sets the files that Apache will serve if a directory is requested. Change this line to “DirectoryIndex index.html index.php”

Copy the file /oat/installation/directory/Apache_2.2.4_noSSL/bin/envvars to /oat/installation/directory/Apache_2.2.4/bin/envvars. Apache will read this file to setup the Apache environment variables for OAT to run.

Copy the entire directory /oat/installation/directory/Apache_2.2.4_noSSL/htdocs/openadmin/ to /oat/installation/directory/Apache_2.2.4/htdocs/openadmin/. All the OAT source code resides in this directory.

Run the following commands to make sure that the PHP Apache handler is properly loaded.

cd /oat/installation/directory/Apache_2.2.4/bin/
./httpd –M
(Here you will see a list of Apache modules. See if the php5 module is on the list)

Right now your new webserver should be properly setup for OAT. You may start your webserver by running /oat/installation/directory/StartApache and visit OAT using your web browser.

Note that this server has mod_ssl enabled but HTTPS is not switched on yet. A few more steps are needed to enable HTTPS in the following sections.

On Windows,

First we have to download and install Openssl from the following website:

http://www.openssl.org/related/binaries.html

Then we need to setup Apache with mod_ssl support. Download the latest Win32 Binary including OpenSSL 0.9.8g (MSI Installer). This should be available here:

http://httpd.apache.org/download.cgi

Stop the OAT Apache webserver. There should be a OpenAdmin shortcut in the start menu. You should be able to stop the OAT Apache webserver from there. Make sure that the Apache Monitor is not running on your system tray.

Rename OAT’s Apache_2.2.4 directory to Apache_2.2.4_noSSL. This is a will serve as a backup copy of the apache binaries. You will also need to use some configuration files from this Apache directory in later steps. Do make a copy.

Run the Apache MSI installer. Do a typical install and choose the installation directory to be /oat/installation/directory/Apache_2.2.4

Edit the Apache configuration file (/oat/installation/directory/Apache_2.2.4/conf/httpd.conf). Add or uncomment the following lines in the httpd.conf file:

LoadModule php5_module "c:\oat\installation\dir\PHP_5.2.4\php5apache2_2.dll"
LoadModule ssl_module modules/mod_ssl.so
AddType application/x-httpd-php .php
PhpIniDir 'c:\oat\installation\dir\PHP_5.2.4'

Search for the line “Listen 80” (or “Listen 8080”) in the httpd.conf file. This indicates the port number that the OAT webserver should run on. You should use the same port number as OAT’s original Apache webserver that comes with OAT installer.

Search for the line “ServerName www.example.com:80” in the httpd.conf file. This indicates the name and the port that the server uses to identify itself. You should use the same ServerName as OAT’s original Apache webserver that comes with OAT installer.

Search for the line “DirectoryIndex index.html” in the httpd.conf file. This sets the files that Apache will serve if a directory is requested. Change this line to “DirectoryIndex index.html index.php”

Search for the line “setenv INFORMIXDIR” in the OAT’s original Apache’s configuration file (c:\oat\installation\dir\Apache_2.2.4_noSSL\conf\httpd.conf). This line sets the INFORMIXDIR variable in the Apache environment for OAT. This has NOT been set in your new Apache webserver yet. Copy this line to your new Apache webserver’s httpd.conf file. You can put this at the end of the httpd.conf file.

Copy the entire directory c:\oat\installation\dir\Apache_2.2.4_noSSL\htdocs\openadmin\ to c:\oat\installation\dir\Apache_2.2.4\htdocs\openadmin\. All the OAT source code resides in this directory.

Run the following commands in a command prompt to make sure that the PHP Apache handler and the mod_ssl modules are properly loaded.

cd c:\oat\installation\dir\Apache_2.2.4\bin\
httpd.exe –M
(Here you will see a list of Apache modules. See if the php5 module and the ssl_module are on the list)

Right now your new webserver should be properly setup for OAT. You may now click on ‘Start Apache Service for OpenAdmin’ in OpenAdmin Menu under the Start Menu. You should be able to access OAT using your web browser.

Note that this server has mod_ssl enabled but HTTPS is not switched on yet. A few more steps are needed to enable HTTPS in the following sections.

Creating an Encryption Key and a Certificate for your OAT Webserver

Keys are used in encryption and decryption. They usually come in pairs, the public key and private key. Public keys are used to encrypt messages and private keys are used to decrypt messages. The message encrypted by a public key can only be decrypted by its associated private key.

A HTTPS enabled webserver will have its own pair of public and private key. The webserver will make its public key available to all clients. But nobody else except the webserver will know its private key. Thus all clients will be able to encrypt messages, but only the webserver can decrypt the message. If a client wants to send encrypted messages to the webserver, he will encrypt the message with the public key provided by the webserver and then send out the message. The webserver will use its secret private key to decrypt the client’s message. Hackers who are trying to listen over the network and steal the client’s message will not be able to decrypt the client’s message, because the hacker does not have the private key.

A certificate is a document authenticating a person to be whom he claims to be. A HTTPS enabled webserver will have its certificate, signed by a trusted certificate authority, to authenticate itself to be the real webserver that the clients are talking to. Before a client talks to the webserver, he will be prompted to view and accept the webserver’s certificate. To the client can make sure that the webserver’s certificate is signed by a trusted certificate authority before proceeding with the communication. This prevents hackers from setting up fake webservers to deceive clients.

Once a webserver is HTTPS enabled, clients get to choose whether they want to do a normal connection to the webserver or a secure connection to the webserver. If clients want to do a normal connection, they will type “http://webserver_url” in their web browser. If clients want to do a secure connection, they will type “https://webserver_url”. In a secure connection, the webserver will send the client its certificate and its public key. The client will be prompted to view and accept the webserver’s certificate before the webpage is loaded, so that the client can be sure that the webserver is not a fake webserver created by hackers to deceive you. Once the client accepts the certificate, the client’s web browser will use the public key that it received from the webserver to encrypt communication. Only the webserver has the associated private key, thus only the webserver can decrypt the client’s encrypted communication. Hackers cannot secretly listen and decrypt the communication.

To generate private/public key pairs and the certificate, we use the openssl executable. You should be able to find it under the bin directory of your openssl installation.

To generate a private key, use the following command:

openssl genrsa -des3 -out privkey.pem 2048

The private key will be stored in the privkey.pem file. Store this file in a secure location because this is the webserver’s secret decryption key. This file will be used to generate the associated public key. When we generate the certificate, it will look for this file, it will generate its associated public key and include the public key in the certificate.

To generate a certificate, we create need to create a certificate signing request, and send the certificate signing request to a trusted certificate authority (Such as VeriSign). The authority will then issue you a certificate. Use the following command to generate a certificate request. For more information about the process of signing certificate requests, contact your certificate authority.

openssl req -new -key privkey.pem -out cert.csr

If you don’t want to deal with another certificate authority and you just want to create a certificate for yourself, you can create a self-signed certificate. Note that this is not the recommended way of creating a certificate.

openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Openssl will prompt you to enter your personal information. After that the certificate will be stored in the cacert.pem file. This file will be displayed to web clients to verify your identity. It will also include the public key for web clients, thus they can start encrypting communication.

Openssl will also prompt you to enter a pass phrase. This is an extra layer of security. You will need to enter your pass phrase when you start your webserver.

For more information about encryption keys, please consult the OpenSSL documentations:

http://www.openssl.org/docs/HOWTO/keys.txt

For more information about certificates, please consult the OpenSSL documentations:

http://www.openssl.org/docs/HOWTO/certificates.txt

Configure httpd.conf (the Apache configuration file) to enable HTTPS

Edit the apache configuration file. The file should be /oat/installation/directory/Apache_2.2.4/conf/httpd.conf

Search for the following line:

#Include conf/extra/httpd-ssl.conf

This line is commented out by default. Uncomment it so that httpd.conf will include the apache ssl configuration file.

Then edit the apache ssl configuration file. The file should be /oat/installation/directory/Apache_2.2.4/conf/extra/httpd-ssl.conf

HTTPS will require one more ssl port. By default, the ssl port number is set to be 443. Make sure this port is available. If you wish to change this port, edit the Listen directive and the Virtual Host section of the httpd-ssl.conf file.
Search for the ‘SSLCertificateKeyFile’ directive and the ‘SSLCertificateFile’ directive in the httpd-ssl.conf file. These two directives indicate the location of your private key file and the certificate file. Make sure that they point to the privkey.pem and the cacert.pem created in the previous section.
Search for the ‘SSLCipherSuite’ directive. This directive indicates the ciphers for your HTTPS webserver. By default the HTTPS webserver will accept all encryption ciphers. If you wish to accept only the seven strongest ciphers, edit the directive as follow, or else you can keep the default configuration:

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM

For more information about HTTPS configurations, please refer to the following website:
http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html

Final Testing

Your OAT webserver should be secured with HTTPS right now. Restart your webserver and launch OAT with your web browser. Instead of using http://hostname:portnumber/openadmin, try using https://hostname:ssl_portnumber/openadmin. You will be prompted to view and accept OAT webserver’s certificate before the OAT login page is launched.
Note:
On Linux, you can restart your webserver by running the StopApache script and then the StartApache script in the OAT installation directory. You will be prompt to enter the pass phrase before you can start you webserver.
On Windows, you have to restart your webserver with the command prompt. Starting the webserver with Apachemonitor.exe or with the start menu shortcuts doesn’t work because they do not support pass phrases. Use the following command to restart your webserver.

httpd –k restart

If you wish to use Apachemonitor.exe or with the start menu shortcuts to control your webserver, you have to disable pass phrases. Note that this reduces the level of security.

Run the following command:

cd c:/openssl/installation/directory/bin/
openssl rsa -in privkey.pem -out privkey_nopassphrase.pem

Now an unencrypted copy of your private key will be stored in the privkey_nopassphrase.pem file. Edit your httpd-ssl.conf file SSLCertificateKeyFile directive to use the privkey_nopassphrase.pem file instead of the privkey.pem file. Then you will not be prompted to enter a pass phrase when starting your webserver. Apachemonitor.exe and the start menu shortcuts should work now.

Leo Chan

OAT 2.21 has incorporated IDS Enterprise Replication monitoring, a plugin manager to allow customization of OAT functionality and an automated installer on Mac OS X. OpenAdmin Tool for IDS (OAT) is a PHP-based Web browser administration tool for IDS 11 and IDS 11.5 that provides the ability to administer multiple database server instances from a single location. OAT makes administration easy by allowing you to drill down on resource usage and events, view query performance statistics, and much more. And since the tool is written in PHP and available as open source, you can customize it with your own business logic and installation requirements.

New feature highlights of OpenAdmin Tool for IDS version 2.21 include:

• Mac OS X Automated Installer: Automatically setup Apache, PHP, I-Connect and OAT on Mac OS X. For users who want to use or install their own Apache/PHP configurations, OAT is also released as a stand-alone package.
• IDS Enterprise Replication Monitoring: Monitors Spool Disk usage, Send and Receive queues, Receiving/Apply statistics, Routing Topology, node details and much more. OAT Enterprise Replication is provided as a separate plugin. The latest automated installer will install the ER plugin for you, you can also manually place the ER plugin zip file under the OAT plugin_install directory and install it with the plugin manager (requires php zip extension).
• Plugin manager: A simple way to customize OAT functionality. You can download customized OAT plugins and install it with the plugin manager. Sample plugin code is also provided and you can follow the sample in creating your own plugins. Note that the plugin manager requires the php zip extension. The latest OAT2.21 automated installer includes the php zip extension, but OAT2.20 installer does not.

Download OAT version 2.21 now at https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-informixfpd .

Click here to see OAT Enterprise Replication at work!

Leo Chan

In some cases it can be useful to have different copies of same versions of CSDK installed in the same machine, though this is not an officially recommended approach by IBM technical support. This document identifies the most common problems when using different copies of same versions of CSDK on the same machine and how to solve them. The first problem you will encounter if you try to install another copy of the same version of CSDK is with the Windows Installer. By design, the Windows Installer detects if you have a pre-existing installation of CSDK and it gives you the options of Modify, Repair or Remove.

Windows keeps a database of products installed on the machine. Every time you install a product using the Windows Installer a new key is added to the registry with specific information about the product, install media location and options used for the install.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

This is the database used when you run the “Add or Remove Programs” applet from the “Control Panel”

When you launch the install process for a product, Windows Installer checks if there is already an entry in the Uninstall registry key with the same id, if so it assumes that the product is already installed and launches the installer in Maintenance mode (with options Modify, Repair and Remove).

Different major versions of CSDK have unique product id’s, this means you can easily install CSDK 2.90.TC1 and CSDK 3.00.TC1, but if you try to install two releases of the same minor version (e.g.: 3.00.TC1 and 3.00.TC3) the installer would not allow it. Currently the Windows installer does support single installation of various CSDK versions in different locations on the same host.

To overcome this design restriction, you can use a Microsoft tool like Windows Installer CleanUp to remove the Registry entry corresponding to the version. Note that this will not uninstall the binaries; it would only remove the entry from the Uninstall database. This may allow us to reinstall the product.

Due to these shortcomings sometimes there can be a need to bypass the Informix Client SDK or I-Connect installation process and copy the Informix library and API files directly to a machine. Though the officially recommended and supported approach is to use the supplied CSDK/I-Connect installer, these instructions are provided as an alternative approach involving copying files for scenarios where using the installer is not possible.

CSDK 3.x is a bundle containing the following application-programming interfaces:

IBM Informix Object Interface for C++
IBM Informix ESQL/C
IBM Informix ODBC Driver
IBM Informix OLE DB Provider
IBM Informix .NET Provider
LIBMI Client API

While some of these components can easily be used and redistributed without the complete CSDK bundle, there are some other components which are more challenging to redistribute due to the way they interact with the Windows operating system. APIs such as the ODBC driver and the OLE DB provider depend on additional CSDK libraries to work. These libraries must be accessible to your application.

In most cases, Windows searches in the directories included in the PATH variable to load these libraries. One of the main problems when supporting multiple versions of CSDK is mixing libraries between versions (e.g.: .NET provider from a newer version loading the ODBC library from an old version). In the same way as Windows uses the PATH variable to search for DLLs, Informix components use the INFORMIXDIR directory to load additional resources such as GLS conversion files or message files.

The primary rule when using multiple versions is to have the INFORMIXDIR and PATH environment variables pointed to the directory containing the version you want to use. You can accomplish this creating a batch file (e.g.: .BAT or .CMD file) to start your application or running the application as a user which has different environment settings.

Here is an example:

- - test.cmd - - - -
set INFORMIXDIR=D:\infx\CSDK300TC1
set PATH=D:\infx\CSDK300TC1\bin;%PATH%
test.exe
- - - test.cmd- - - -

Interface for C++, ESQL/C and LIBMI

If you want to use the Object Interface for C++, ESQL/C or LIBMI you can follow the steps in following IDS Experts article: Redistributing IBM Informix Client products.

You will need to ensure that both the PATH and INFORMIXDIR variables are pointing to the version of the CSDK installation folder you want to use.

ODBC Driver

Using different versions of the IBM Informix ODBC driver can be more complex. Any ODBC driver on a Windows machine must have a unique name. In the case of CSDK 3.50 and 3.00 the name for the ODBC driver is “IBM INFORMIX ODBC DRIVER”. Windows keeps the list of installed drivers in the ODBCINST.INI registry key.

HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI

Note that in previous versions of the CSDK package the name for the ODBC driver was different (e.g.: IBM INFORMIX 3.82 32 BIT).

When you create a DSN using the ODBC Data Source Administrator tool (odbcad32.exe)

An entry is created in the registry with all the values used in your DSN and the full path of the ODBC library used to create the DSN.

Windows uses the directory in the “Driver” registry key to load the ODBC library. You can use different versions of the ODBC driver by manually changing the directory in the “Driver” key.

Even if you can update this key from the console or a shell script before your application starts, the best approach is having a different DSN depending on the driver you want to use, or use a relative path (e.g.: “.\iclit09b.dll”) and only rely on the Windows DLL loader mechanism.

The ODBC Data Source Administrator tool always loads the ODBC library specified in the “ODBCINST.INI\%DRIVER NAME%\Setup” key, even if the DSN entry you are modifying has a different path in the “Driver” key.

For other APIs, the values for the variables PATH and INFORMIXDIR need to be changed depending of which DSN you want to use.

OLE DB Provider

The OLE DB provider library is called Ifxoledbc.dll. Windows uniquely identifies an OLE DB provider based on the Class id (CLSID) and the provider name (e.g.: Ifxoledbc). In the CSDK install process the OLE DB provider is automatically registered in the Windows registry. At any point you can manually register a different version of the provider using the REGSVR32.EXE Microsoft tool.

This tool creates the needed keys in the Windows registry so you can load the OLE DB provider using the “Ifxolebdc” name.

There are two places where the full path of the OLE DB library is stored, one for the “Ifxoledbc” provider and a second for the “IfxoledbcErrorLookup”.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes \CLSID\

{A6D00422-FD6C-11D0-8043-00A0C90F1C59} Ifxoledbc

{A6D00423-FD6C-11D0-8043-00A0C90F1C59} IfxoledbcErrorLookup

Note: the CLSID could change with different versions

The registry key that contains the path for the OLE DB library is “InProcServer32”.

The best approach to use different versions of the Ifxoledbc.dll library is to use a relative path rather than the full path…

Remember to update both keys with the desired value (Ifxoledbc and IfxoledbErrorLookup). When an application wants to load the “Ifxoledbc” provider, it would follow Windows operating system rules to search for the library. You should point your PATH and INFORMIXDIR to the version you want to use.

Further information related to the DLL Search Order could be found in the following link.

Dynamic-Link Library Search Order

NET Provider

Windows has a central place for .NET assemblies called the Global Assembly Cache or GAC. During the CSDK install process the IBM Informix .NET Provider is installed in the GAC with the unique name (strong name) “IBM.Data.Informix”.

You can have multiple versions of the .NET Provider if the assembly version is different.

The assembly version for CSDK 2.81 and CSDK 2.90 is 2.81.0.0, and for CSDK 3.00 and CSDK 3.50 the version is 3.0.0.2. (Note that 9.0.0.1 and 9.0.0.2 correspond to the IBM Data Server Provider.)

The assembly version for the .NET provider in minor releases (e.g.: 3.00.TC1, 3.00.TC3, etc) is the same, which means that only one version of the library could be registered in the global cache.

To be able to use more than one .NET provider, first you need to uninstall the IBM.Data.Informix assembly from the GAC. To do this you can use the “gacutil.exe” with the “/u” flag for uninstall, or use the Explorer context menu…

When a .NET assembly is not in the global cache the .NET runtime would try to load the class from the same directory as the executable. (You can find more information about the assembly loading in the following link: How the Runtime Locates Assemblies.)

Copy the .NET Provider (IBM.Data.Informix.dll) to the directory where your application would start; this would allow you to use different versions of the .NET provider.

Alternatively you can specify the location of the assembly at runtime using the Assembly.LoadFile method and the AssemblyResolve event. Further information on this topic can be found in the following MSDN links: Assembly.LoadFrom and AppDomain.AssemblyResolve

Before contacting IBM technical support

The officially recommended approach is to uninstall the previous version of CSDK before installing the new one. If you need to run different versions of any of the CSDK components on the same machine, you should be aware of the potential issues.

Always check that the versions of the libraries loaded by your application belong to the same CSDK versions. (You can use a tool like TLIST.EXE from Microsoft to find which libraries your process is using) - Debugging Tools for Windows

 

Javier Sagrera

Snigdha Sahu

Depending on your existing Database Server setup, you might be able to upgrade directly to the
current version by basically installing the product in a new directory, copying a few configuration
files, and starting the new server to convert your database data. You can upgrade directly from any
of the following products: Dynamic Server Version 11.10, 10.00, 9.40, 9.30, 9.21, or 7.31.

Upgrading is an in-place migration method that uses your existing test and production hardware. The
operating system on those machines must be supported by Dynamic Server Version 11.50. Also, you must
have enough space for the system database data conversion.

Upgrading consists of these steps:

1. Prepare your system. That includes removing outstanding in-place alters, closing all transactions,
verifying the integrity of the data with oncheck, and performing a level-0 backup. If you are
using Enterprise Replication or High Availability Data Replication, stop replication.

2. Install the new product on the machine.
Important: Do not install it over the existing product.

3. Copy the ONCONFIG file to the target and set parameters that are new for the current release.

4. Start the Dynamic Server Version 11.50 instance. The database data is automatically converted.

5. Run UPDATE STATISTICS MEDIUM for non-leading index columns, then run UPDATE STATISTICS FOR PROCEDURE.

This type of migration minimizes the risk of introducing errors. You can always revert from the new
server to the old one. In the event of a problem during reversion, you can restore the level-0 backup.

This method works perfectly on Windows thought it is not documented well.

1. When installing IDS 11.50 on Windows, choose the option "Install to a default/different directory".










2. Make sure that you do not initialize the server when installing.










3. Copy the ONCONFIG file to the target and set parameters that are new for the current release.

4. Bring the server up using Control Panel->Services or any other method without initializing.

5. Monitor the online.log for the Conversion Successful message.

Once the upgrade has completed successfully, you can remove the old instance. When you run the
uninstaller make sure that you select "Retains all databases, but removes server binaries".

If for some reason, you like to go revert to the previous instance, restore it from the level 0 backup.

The only time this will not work on Windows is if you are upgrading from a 11.10.UC1 version to
another 11.10 version say 11.10.UC2.

Suma Vinod

OpenAdmin Tool for IDS has been greatly enhanced in version 2.20 with a completely redesigned user interface, a new automated installer, and lots of new IDS admin functionality. OpenAdmin Tool for IDS (OAT) is a PHP-based Web browser administration tool for IDS 11 and IDS 11.5 that provides the ability to administer multiple database server instances from a single location. OAT makes administration easy by allowing you to drill down on resource usage and events, view query performance statistics, and much more. And since the tool is written in PHP and available as open source, you can customize it with your own business logic and installation requirements.

New feature highlights of OpenAdmin Tool for IDS version 2.20 include:

• Automated Installer: For users who want an easy, hassle-free install, there is a new automated GUI installer that will install and configure Apache, PHP, I-Connect, and OAT. For users who want to use or install their own Apache/PHP configurations, OAT is also released as a stand-alone package.
• All-New Look: OAT version 2.20 has a completely new and improved UI
• Automated Update Statistics: Configure rules and define a schedule to have IDS automatically maintain your database server's statistics
• Onconfig Recommendations: Get recommendations for your onconfig settings that are tuned to your specific database server instance; modify dynamic onconfig parameters directly through OAT
• Enhanced Mach11 Support: Including a Connection Manager interface, an SDS Setup Wizard, and the ability to start and stop Mach11 servers remotely
• Historical Performance Graphs: View and monitor historical trends of key performance measurements
• Task Scheduler Wizard: Use OAT’s new wizard to define new tasks in the scheduler
• Read-Only Access: Define groups in OAT that can monitor IDS database servers but not perform administrative tasks
• And the list goes on…. Virtual Processor Administration, System Integrity Checks, a Privileges Manager, environment variable support on OAT connections, the ability to kill database sessions remotely through OAT, and more!

Download OAT version 2.20 now at https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-informixfpd, or at www.iiug.org in the Members Area.

Erika Von Bargen

Scope: This article covers redistributing ESQL/C based demos and application. The steps required to redistribute other Informix client applications by copying files are being investigated.

Depending on how you deploy your Informix applications there is sometimes a need to bypass the Informix Client SDK or I-Connect installation process and copy the Informix library and API files directly to a target computer. Though the officially recommended and supported approach is to use the supplied CSDK/I-Connect installer, these instructions are provided as an alternative approach involving copying files for scenarios where using the installer is not possible. This article demonstrates how and where to copy all the required CSDK files and Microsoft Windows DLLs to a target computer in order to deploy applications.

Note that while this is not an officially recommended approach, these instructions have been tested by IBM and demonstrated to work. If you encounter problems with this method and need to talk to IBM technical support you may be asked to try installing via the installer to rule out other problems with your configuration.

Steps:

1. Install Client SDK 3.50 or I-Connect on your Windows development computer. After successful installation, verify that all the shortcuts in the programs groups are created and registry keys are updated.
2. Make a copy of the entire CSDK installation folder (INFORMIXDIR) and transfer those to the target computer (For example by zipping the files and unzipping on the target computer). Choose any location on target computer for copying files for example c:\informix.
3. Copy the required Microsoft Windows runtime DLLs.
   Since the Informix product is not being installed via the regular installer the required runtime DLLs may not be present on the target computer. As a result applications such as setnet32.exe, ilogin.exe and finderr may not run correctly.

If a manifest is present in your application but a required Visual C++ library is not installed in the WinSxS folder, you may get one of the following error messages depending on the version of Windows on which you try to run your application:

• The application failed to initialize properly (0xc0000135).
• This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem.
• The system cannot execute the specified program.

Recommended approach: The Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe,VCRedist_ia64.exe) has to be executed on the target system as a prerequisite to deployment of the application. The Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) (http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en) installs runtime components of Visual C++ Libraries required to run applications developed with Visual C++ on a computer that does not have Visual C++ 2005 installed.

Alternative approach: If your deployment requirements prevent you from installing the Visual C++ Redistributable Package directly, from the development computer, copy the %WINDIR%\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 directory to same location on the target computer. (Create the same directory structure on the target computer as the development computer if it does not exist.)

Also copy the policy files from the development computer %WINDIR%\WinSxS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773 to the same location on target computer. (Again, create the same directory structure on target computer as the development computer if it doesn’t exist.)

Note: This workaround is only applicable to Microsoft Visual C++ 2005 SP1 runtime components. If later versions of the Client SDK are built with a later version of Visual Studio then the corresponding version of the runtime components would be required. Check your release notes to see which version of Visual Studio is required.

 

Running ESQL/C demos:

If you do not have the required Visual C++ libraries installed in the WinSxS folder then while running the demo1 program the following error pops up.

 

Once you install Visual C++ libraries or copy the runtime DLLs and policy files in C:\WINDOWS\WinSxS folder you should see the ESQL/C demos successfully as shown below.

Snigdha Sahu

Introduction IBM_USER IBM_USER 2 81 2008-05-13T20:03:00Z 2008-05-13T20:03:00Z 1 1638 9340 IBM 77 21 10957 10.6830 Clean Clean MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";}

Setting Up OpenAdmin Tool (OAT) on Mac OS

 

Introduction

 

The Open Admin Tool (OAT) is an open source web-based administration tool for Informix Dynamic Server (IDS). It is a web console where users can manage dbspaces, schedule tasks and monitor MACH 11 clusters etc. through their web browsers.

 

OAT is a web console that is hosted on a single web server. Other machines that have access to the web server’s network can simply open up a web browser, type in the web server machine’s URL, and they can use OAT to manage their database servers.

 

In order to host the Open Admin Tool website, the following prerequisites have to be setup:

 

1. Informix Client SDK or Informix Connect
2. A web server, such as Apache 2.0.
3. PHP 5.2.4 dynamically loaded as an Apache 2.0 module. It also has to have the following extensions enabled
• Pcre
• Pdo
• Pdo_sqlite
• Pdo_informix
• Soap
• Gd   (requires libpng and libjpeg libraries)
• Openssl  (requires libssl and libcrypto libraries)
• Sockets
• Libxml  (requires libxml2 libraries)
• Session
• Simplexml

 

The Open Admin Tool can be hosted on any platforms that have all of the above setup.

 

This article will provide the steps on how to setup OAT on a Mac OS X Platform.

 

Setting up Open Admin Tool (OAT) on Mac OS

 

First step is to install Informix Client SDK for Mac OS.

 

The Mac OS will already have an Apache web server installed. We can use the Apache web server that comes with Mac OS. We do not need to install other web servers.

 

The Mac OS will also have an installed PHP, however the PHP that comes with Mac OS does not have all the extensions that OAT requires. We cannot use the PHP that comes with Mac OS. We have to compile PHP binaries from source.

 

Our goal here is to build our own PHP binaries and dynamically load it to the Apache web server that comes with Mac OS.

 

Compiling PHP on Mac OS

 

Before starting to compile PHP, make sure that you have libpng, libjpeg, openssl and libxml2 installed into /usr/local/ or /usr/. Some PHP extensions require these libraries in order to compile.

 

Obtain the latest PHP source code from php.net (http://www.php.net/downloads.php). Decompress the source code package and issue the following commands.

 

cd /path/to/php/source/code

 

./configure --prefix=/path/to/where/you/want/to/install/php --with-apxs2=/usr/sbin/apxs --enable-soap --enable-pdo --with-pdo-sqlite --with-gd --with-pcre-regex --enable-session --with-openssl --enable-sockets --enable-libxml --enable-simplexml

 

make

 

 

The “configure” command will generate a makefile specific to your machine’s build environment. The “make” command will use the generated makefile to create PHP binaries.

 

The “configure” and “make” command will not always run smoothly. It is dependent on your machine’s setup. Please see the following section about debugging the “configure” command for more information.

 

If the “configure” and “make” command ran smoothly, you can run the “make install” command. This command will copy the php binaries to /path/to/where/you/want/to/install/php. It will also overwrite the PHP apache handler (the glue between Apache and PHP, called libphp5.so) at /usr/libexec/apache2/. You may want to backup the Mac OS’s default libphp5.so before running “make install”

 

##Be sure that you have backed up /usr/libexec/apache2/libphp5.so##

make install

 

After the “make install” command, the php binaries can be found under /path/to/where/you/want/to/install/php/.

 

Right now we have compiled the PHP binaries that have all the extension modules that OAT requires, EXCEPT the pdo_informix extension. This extension DOES NOT come with PHP source code from php.net. We have to compile it from source code separately from PHP, and enable it as a dynamic PHP extension module. We will go through the process of compiling pdo_informix in the later section “Compiling pdo_informix extension and enabling it in PHP”.

 

Right now we also have compiled the PHP apache handler (the glue between PHP and apache). This will appear as a file called “libphp5.so”, under /usr/libexec/apache2/. This file will be loaded as a dynamic Apache module. This will be described in the later section “Enabling PHP in Apache”

 

The next thing you have to do is to create a php configuration file. Copy the sample php.ini file from /path/to/php/source/code/php.ini-dist to /path/to/where/you/installed/php/lib

 

cd /path/to/php/source/code/

cp ./php.ini-dist /path/to/where/you/want/to/install/php/lib/php.ini

 

Then edit the php.ini file. Make the following changes to the php.ini file.

 

memory_limit = 128M Change this to à memory_limit = 300M

extension_dir = "./"     Change this to à extension_dir = “/path/to/where/you/installed/php/lib/extensions”

 

OAT requires a greater memory limit. Thus we increased the memory limit here.

 

The extension_dir is the directory where dynamic PHP extension modules will reside. Dynamic PHP extensions have to be placed under extension_dir, and enabled in the php.ini configuration file. The pdo_informix extension module will be handled in this fashion.

 

Debugging Information about the “configure” and “make” command

 

The --prefix tag lets you specify where you want to install the php binaries. You have to make sure that you have the write permissions to that directory before configuring PHP.

 

The --with-apxs2 tag lets you specify where to find your apache binaries, so that the apache handler (i.e. the glue between Apache and PHP) can be built. This apache handler will appear as a file called “libphp5.so” after the compilation. It will appear under /usr/libexec/apache2/. This document will talk about how to dynamically load this handler to the Apache web server in the later section “Enable PHP in Apache”. Here we are using the Mac OS default Apache web server, thus this flag should be set to point to /usr/sbin/apxs.

 

The --enable and --with flags specify what extensions you want to enable. Pdo_informix will be enabled separately after we compile the PHP binaries.

 

The “configure” and “make” command will not always run smoothly. One possible reason is that the prerequisite libraries are not present. For example, the php gd extension will not compile if libpng and libjpeg libraries are not found on your machine. The openssl extension will not compile if libssl and libcrypto libraries are not found. The libxml extension will not compile if libxml2 libraries are not found. Make sure that you have libpng, libjpeg, openssl and libxml2 installed into /usr/local/ or /usr/ before running the configure command.

 

Another possible reason is that the library architecture and the compilation flag do not match. If your libpng, libjpeg, libssl, libcrypto and libxml libraries are in 32bit mode, you have to set the compilation flag CFLAGS to –m32. If your libraries are in 64bit mode, you have to set CFLAGS to –m64. For example, if you want to see whether your libxml2 library is 32bit/64bit, run the following commands:

 

cd /usr/lib

 

file libxml2.2.dylib

 

##If your libraries are 64bit, set CFLAGS to be –m64##

setenv CFLAGS –m64

 

##If your libraries are 32bit, set CFLAGS to be –m32##

setenv CFLAGS –m32

 

If you encounter problems, you can look into the config.log file generated by the configure script. You can also open up the configure script (i.e. /path/to/php/source/code/configure) or the makefile (i.e. /path/to/php/source/code/Makefile) with a text editor, search for the error message and debug the problem. Sometimes the configure script cannot find libraries because they are not installed on /usr/ or /usr/local/. In that case, hardcoding your library paths to the configure script’s library search path will solve the problem.

 

You may also add the --disable-all tag to the configure command. This will disable all other extensions that we did not specify in the configure command. Compiling fewer extensions will give us fewer errors. Since OAT doesn’t require those extra extensions, it is okay to add the --disable-all flag.

 

Compiling PDO_INFORMIX extension and enabling it in PHP

 

Download the latest pdo_informix source code from http://pecl.php.net/package/PDO_INFORMIX

 

Before you compile pdo_informix. Make sure that CFLAGS are set accordingly. If your Client SDK/IConnect libraries are 32bit, then set CFLAGS to be –m32. If your Client SDK/IConnect libraries are 64bit, then set CFLAGS to be –m64

 

Decompress the pdo_informix source code and run the following commands

 

cd /path/to/pdo_informix/source/code/

 

/path/to/where/you/installed/php/bin/phpize

 

./configure --with-php-config=/path/to/where/you/installed/php/bin/php-config –with-pdo-informix=/path/to/where/you/installed/ClientSDK/or/IConnect/

 

make

 

This compiles the pdo_informix extension module. It will appear as a file “pdo_informix.so” under /path/to/pdo_informix/source/code/modules/

 

Copy pdo_informix.so to the PHP extension_dir ( We have set this to be /path/to/where/you/installed/php/lib/php/extensions/ in previous sections)

 

cd /path/to/pdo_informix/source/code/modules/

cp ./pdo_informix.so /path/to/where/you/installed/php/lib/php/extensions/

 

Add the following line to the php.ini configuration file (Under /path/to/where/you/installed/php/lib/php.ini)

 

extension=pdo_informix.so

 

This will enable the pdo_informix extension in PHP.

 

Enabling PHP in Apache

 

After PHP has been built successfully, the PHP apache handler (the glue between PHP and apache) will be created. This will appear as a file called “libphp5.so”, under /usr/libexec/apache2/

 

We have to edit the Apache configuration file (httpd.conf) to load the libphp5.so. This can be done by adding the following three lines in /etc/apache2/httpd.conf. These lines might already exist in the httpd.conf but are commented out. In that case you only have to uncomment them.

 

LoadModule php5_module libexec/apache2/libphp5.so

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

 

 

You also have to setup the Apache environment variables. You will have to edit the /usr/sbin/envvars file. Add the following lines in the envvars file.

 

INFORMIXDIR=”/path/to/IConnect/or/CSDK/installation/”

export INFORMIXDIR

 

PATH=”$INFORMIXDIR/bin:$PATH”

export PATH

 

DYLD_LIBRARY_PATH=”$INFORMIXDIR/lib: $INFORMIXDIR/lib/cli: $INFORMIXDIR/lib/esql: $INFORMIXDIR/incl: $INFORMIXDIR/incl/cli: $INFORMIXDIR/incl/esql: /usr/lib: $DYLD_LIBRARY_PATH”

export DYLD_LIBRARY_PATH

 

You may now start the Apache web server. Issue the following command with root user access permissions.

 

/usr/sbin/apachectl –f /etc/apache2/httpd.conf –k start

 

 

Unpack OAT source code at /Library/WebServer/Documents/OpenAdminTool. The ownership of all files under this directory has to be changed too. Make sure these files are owned by the user and group that runs apache. (These should match the user and group settings in /etc/apache2/httpd.conf)

 

Visit http://<hostname>.<domainname>//OpenAdminTool/index.php and continue with the OAT web install. OAT should be operational after the OAT web install.

Leo Chan