Complete Contents
About This Guide
Chapter 1 Before You Install
Chapter 2 Installing Netscape Enterprise Server
Chapter 3 Troubleshooting Installation
Chapter 4 Migrating from 3.6 to 4.0
Netscape Enterprise Server Installation and Migration Guide: Migrating from 3.6 to 4.0
Previous Contents Index


Chapter 4 Migrating from 3.6 to 4.0

This chapter contains information on migrating your configuration settings and data from Enterprise Server 3.6 to Enterprise Server 4.0.

This chapter contains the following sections:


Migrating from Earlier Versions
The migration program handles migrating your server's configuration settings and data from a 3.6 server to a 4.0 server. If you have an earlier version of Netscape Enterprise or if you have Netscape FastTrack server installed, you must first migrate from that version to Enterprise 3.6. You can get a copy of Enterprise Server 3.6 at the following URL:

http://home.netscape.com/testdrive/download/index.html

Instructions for migrating from an earlier release to 3.6 are at the following URL:

http://home.netscape.com/eng/server/webserver/3.0/ es36upg.htm


Migration Overview
The Enterprise Server 4.0 migration process migrates the following information from earlier versions of the server:

Note. In general, when this document refers to Enterprise Server 3.6, the information applies not only to Enterprise 3.6 but to service pack releases as well, for example, Enterprise Server 3.6 SP2.

Obsolete Features
The following 3.6 features are not supported for 4.0:

Data and settings are not migrated for these features.

Obsolete obj.conf Directives
The following directives are not used with Enterprise Server 4.0. If the migration program finds them in your 3.6 server's obj.conf file, it does not carry them forward to the 4.0 server.

Start and Stop Script
If you've made modifications to your start or stop scripts in your 3.6 server, those changes will not be carried forward by the migration program.

Symbolic Links in Configuration Files (Unix)
Symbolic or relative links in server configuration files may cause problems when upgrading. Make sure that server configuration files that contain absolute references to files under the server root always reference the path to the server root in the same way, and preferably without traversing any symbolic links.

Post-Migration on Windows NT
Because Enterprise Server 3.6 and Enterprise Server 4.0 cannot coexist on the same system, once you have migrated Enterprise Server 3.6 you should remove it from any system that also contains Enterprise Server 4.0.


Migrating Settings and Data
To migrate settings and data from a 3.6 server to the 4.0 server, follow these steps:

  1. In the Enterprise Administration Server page, click the Servers tab.

  2. Click Migrate Server.

  3. Enter the server root of the server from which you want to migrate and click Search.

    4. Enterprise Server detects whether there are servers installed in the directory you specified and displays the servers you can migrate in a section of the page called "Installed Servers."

  4. Choose a server from the drop-down list and click Migrate.

    5. A new window appears showing the migration parameters.

  5. Fill in the form.

    6. The sections on the form that you see depend upon which features your 3.6 Enterprise Server is using and which 4.0 components you installed. The following sections of parameters are possible:

  6. Click Migrate.

    7. The Migrate Server_name page appears. It shows the results of the migration, including the parameters successfully migrated and the parameters that you need to migrate manually. It also shows any features of your 3.6 server that are not supported in 4.0.

  7. Click Configure Migrated Server to configure your migrated server instance in the Server Manger, or click Close to close the migration window.
The Migrate Server Page
When you migrate, you see a page (Migrate Server_name) that logs all the migration information, including all errors encountered. The following is an example of this page.

Figure 4.1    Migration information

 As shown in this example, you receive warnings for the features you used in 3.6 that are not supported in 4.0. The migration program does not migrate entries in obj.conf that are for obsolete features.

If you get fatal errors while migrating, the migration continues. The results page shows what errors occurred an you can use this information to troubleshoot.

Migrating the Administration Server
You can only migrate individual server instances. You cannot migrate your administration server. After you have migrated your Enterprise Server instances, you need to set up features such as distributed administration and clusters again in your 4.0 Enterprise Administration Server.

When you migrate an Enterprise Server instance, you have the option of migrating user and group information, which spans multiple server instances. Once you have migrated user and group information or set up your 4.0 environment, you do not need to migrate users and groups again.

You can also migrate keys and certificates.

Migrating User and Group Information
In Enterprise Server 3.6, you had the option of maintaining user and group information in or in a local database or in a Directory Server.

Migrating from a Local Database
If you used a local database for your user and group information, follow these steps:

  1. During the migration process, choose to export your local database to an LDIF file.

  2. In your 4.x Directory Server, use the file ldif2ldap to add DN information to your exported file. The ldif2ldap file is in your Directory Server instance folder. To run it on Windows NT, type:

    3. ldif2ldap.bat filename

    where filename is the name of the exported LDIF file.

    On Unix, type:

    ./ldif2ldap filename

  3. Open Directory Server in Netscape Console. From the Configuration tab, right-click on the Database item and choose Import. Browse to your converted file.

  4. In Enterprise Administration Server, on the Global Settings tab, use the Configure Directory Service page to point to the Directory Server where you imported your database information.
Migrating from Directory Server
If you used the Directory Server, you do not need to do anything during the migration process to migrate users and groups. After migrating, in the Enterprise Administration Server, on the Global Settings tab, use the Configure Directory Service page to point to a Directory Server. You must use a 4.x Directory Server.

Migrating ACLs
Enterprise Server 4.0 has a new default ACL called es-internal. It controls who can change files internal to Enterprise Server, for example, help files, onscreen icons, and so on. This new default ACL is added when you migrate.

If you had ACLs set up in your administration server 3.6 for distributed administration, these ACLs are not migrated. You must add them manually to your new Enterprise Administration Server.

Migrating Certificates
Keys and certificates are migrated as part of the migration process only if your server has security enabled. You can also migrate keys and certificates by themselves using the Security tabs in the Enterprise Administration Server page and the Server Manager page.

During the migration process, you can migrate the certificates from either the individual server instance or from the administration server.

The way Enterprise Server 4.0 uses and manages certificates has changed from Enterprise Server 3.6. Enterprise Server 3.6 used an alias to refer to a certificate and key pair. Multiple server instances could use to a single alias. The administration server managed all the aliases and the certificates in them.

In Enterprise Server 4.0, each server instance (including the Enterprise Administration Server) has its own certificate/key pair, which is now called a trust database. You manage the trust database from the Server Manager's Security tab. The trust database includes the server certificate and all the included Certificate Authorities. The certificate and key database files are now named after the server instance that uses them. If multiple Enterprise Server 3.6 instances use the same alias, when you migrate each instance you can choose to migrate the certificate and key pair. The migrated certificate and key pair are named for the Enterprise Server 4.0 instance each time you migrate.

The migration not only migrates the certificate, it migrates the whole trust database associated with the server instance. All the Certificate Authorities (CAs) in your 3.6 database are migrated to the 4.0 database. If they duplicate 4.0 CAs, use the 3.6 CA until it expires; then use the 4.0 CA. Do not attempt to delete duplicate CAs.

When you migrate certificates from Enterprise Server 3.6 to Enterprise Server 4.0 make sure that the Enterprise Administration Server user for 4.0 has read and write permissions on the Enterprise Server 3.6 database files. The files are alias-cert.db and alias-key.db, located in the 3.6_server_root/alias directory.

For more information on using certificates with Enterprise Server, see the Netscape Enterprise Server Administrator's Guide.

Note. If you are migrating an SSL-enabled server, you will have to manually start the migrated server because you have to specify a password when starting it.

Migrating Web Publishing
If you had web publishing turned on in Enterprise Server 3.6 server, the configuration files are migrated automatically as part of the migration process.

To successfully migrate web publishing data, you must choose the following options on the Migration Parameters page:

In addition, you may need to install filters that render non-HTML documents in HTML for web publishing and search. For more information, see "Document Filters."

Migrating Netshare
If you had Netshare turned on in Enterprise Server 3.6, you migrate the configuration files automatically as part of the migration process.

To successfully migrate Netshare directories and environment, on the Migration Parameters page you must choose to use your old document root. Otherwise your Netshare data is not carried forward.

Migrating Search
You need to choose which search collections, if any, you want to migrate. The Migration Parameters page has checkboxes for you to select the collections you want to migrate. If you don't migrate a collection when you migrate the server, you cannot go back and migrate it in the future.

If you choose to use your old document root, the search collections you migrated work automatically. If you choose to use a new document root instead of your old one, you may need to recreate some of your collections before they will work.

Document Filters
Some past releases of Enterprise Server included filters that converted files of many formats to HTML so that they could be included in collections, indexed, searched, and used for web publishing. Beginning with Enterprise Server 3.6 SP1, these filters were no longer included as part of Enterprise Server.

To use this capability in 4.0, most people must purchase and install filters from Verity. To use the filters, follow these steps:

  1. Download the filters from Verity at http://www.verity.com/netscapefilters.

  2. Uncompress them and install them into the server_root/plugins/search directory.

  3. For each instance of the server for which you want to enable document conversion, open the server_root/https-server-id/config/webpub.conf file for editing.

  4. Within the [NS-loader] section of this file, add the following line:

    5. NS-enable-conversion=Y

  5. Go to the Server Manager for the server instance.

  6. Click Apply to apply the changes you made to the webpub.conf file for that server instance. The server automatically restarts.

  7. Reindex any multi-format collections.
If you bought Enterprise Server 3.6 before SP1, or if you already have the filters in your system and do not need to get them from Verity, complete the following steps for each instance of the server for which you are enabling document conversion:

  1. Open the server_root/https-server-id/config/webpub.conf file for editing.

  2. Within the [NS-loader] section of this file, add the following line:

    3. NS-enable-conversion=Y

  3. Go to the Server Manager for the server instance.

  4. Click Apply to apply the changes you made to the webpub.conf file for that server instance. The server automatically restarts.

  5. Reindex your multiformat collections.
If you are migrating from a previous version of Enterprise Server, and you do not get the new filters, you may experience problems with non-HTML documents converted to HTML for search or web publishing. Without the new filters, if you reindex or update a multi-format collection, documents won't be converted to HTML and your search results will be incorrect. For non-HTML files converted to HTML for web publishing, any existing files that have been converted to HTML will remain available in HTML. However, any new non-HTML files, or any new versions of exiting non-HTML files will not be available in HTML.

If you do not want to have HTML renditions of any of your documents, reindex them using the Index and Update Properties page in the Web Publishing tab.


Migrating Applications
After migrating your server settings and data, you may also need to make changes to your applications so that they run on Enterprise Server 4.0.

Migrating Server-Side JavaScript Applications
Enterprise Server 4.0 supports JavaScript 1.4. For information about the changes between JavaScript 1.2 and 1.4, see the "New Features" section in the document Core JavaScript Reference v1.4 at:

http://developer.netscape.com/docs/manuals/js/core/jsref/index.htm

You must recompile and reregister server-side JavaScript applications before running them in 4.0.

Migrating NSAPI Applications
Most NSAPI programs you used with Enterprise Server 3.6 will work in Enterprise Server 4.0 without being recompiled.Some undocumented data structures have been moved out of nsapi.h and are no longer public. Going forward, if your plugins use any of these data structures, you should re-write them to use accessor functions. The data structures that are now private are defined in nsapi_pvt.h, which is shipped with the build for informational purposes only.

For more information on these data structures and the new accessor functions, see the Programmer's Guide to Enterprise Server 4.0.

Migrating Java Servlets
After you've migrated your server, Java servlets that ran in Enterprise Server 3.6 should run in 4.0 without being recompiled. The migration leaves 3.6 servlets in their original directory. The migrated servlets run in compatibility mode, which may make them a little slower than other 4.0 servlets.

Also, if your 3.6 servlet referenced any additional files, you need to add the path to these files to your JVM classpath. To update the classpath, use the Configure JVM Attributes page, which you can find in the Server Manager on the Servlets tab.

HTTP Java Applets
HTTP Java applets are no longer supported. Instead, use Java servlets.

Web Application Interface
Enterprise Server 3.0 provided an API, called the Web Application Interface (WAI), to extend server functionality. With Enterprise Server 4.0, developers are encouraged to use industry-standard Java servlets for any future applications they develop. WAI is still supported, but Enterprise Server 4.0 focuses on supporting Java servlet development.

By default, the WAI component is not installed when you install the server. You must manually select it for installation. If you did not select WAI when you installed Enterprise Server 4.0, you can run the installer again and install just the WAI component.

In addition, Enterprise Server no longer includes an Object Request Broker (ORB) as part of the release. If you want to continue using WAI, you must obtain the ORB yourself. Visibroker 3.3 is available from Inprise at http://www.inprise.com. If you are migrating from a previous version of Enterprise Server, you must still get an updated version of the ORB. The ORB shipped with the 3.6 Enterprise Server is an earlier version which is no longer supported.

Warning. You must install the ORB before migrating your Enterprise Server. If you do not, you will get an error message when you try to start your migrated server instance.

 

© Copyright © 1999 Sun Microsystems, Inc. Some preexisting portions Copyright © 1999 Netscape Communications Corp. All rights reserved.