Converting cluster resources for OES 2 services from NetWare to Linux might require more than a simple cluster migration from a NetWare node to a Linux node. For example, the service might require that you use migration tools to convert the service to Linux. Some services require post-conversion configuration to finalize the conversion. A few services on NetWare are not available on OES 2 Linux, so you must use the standard Linux service instead.
See Table 6-1 for information about converting cluster resources for NetWare 6.5 SP8 services:
Table 6-1 Guidelines for Converting Service Cluster Resources from NetWare to Linux
|
Service on NetWare 6.5 SP8 |
Cluster Migrate the Resource |
Converting the Service to OES 2 Linux |
|---|---|---|
|
Apache Web Server |
Requires special handling |
|
|
Apple Filing Protocol (AFP) |
Requires special handling |
|
|
Archive and Version Services |
No |
On Linux, you must configure a new cluster resource on a shared Linux POSIX file system. On NetWare, Archive and Versioning Services uses a MySQL database. On Linux, it uses a PostgreSQL database. The load script commands are also different. |
|
CIFS (Windows File Services) |
Requires special handling |
See Section 6.3.5, CIFS. |
|
DFS VLDB (Distributed File Services volume location database) |
Requires special handling |
|
|
DHCP Server |
Requires special handling |
|
|
DNS Server |
Requires special handling |
|
|
eDirectory |
Not clustered |
See Section 6.1.7, Converting Nodes that Contain the eDirectory Master Replica. |
|
eDirectory Certificate Server |
Requires special handling |
The Certificate Authority (CA) service is not cluster-enabled for NetWare or OES 2 Linux. There are no cluster-specific tasks for the CA itself. The Server Certificate service issues Server Certificate objects that might need to reside on each node in a cluster, depending on the service that is clustered. NetWare and Linux generate certificates differently, so the NetWare server’s certificate is not reused for the OES 2 Linux server. See Section 6.3.9, eDirectory Server Certificates. |
|
exteNd Application Server and MySQL |
Not applicable |
The exteNd Application Server was discontinued as an install option for NetWare 6.5 SP3. See MySQL. |
|
FTP |
Not applicable |
Use the standard FTP service for Linux. |
|
iFolder |
Requires special handling |
Novell iFolder 2.1x is not available on OES 2 Linux. You must upgrade to Novell iFolder 3.x. After you add a Novell iFolder 3.x server to the NetWare cluster and before you finalize the cluster conversion, use iFolder migration procedures to migrate the iFolder 2.1x server configuration and user data from the source NetWare node to the target Linux node. For information, see |
|
iPrint |
Requires special handling |
|
|
MySQL |
Not applicable |
Use the MySQL 5.0.x software on OES2 Linux that is offered under the GPL. Configure the OES service to use MySQL 5.0.x on OES 2 Linux before setting up clustering for the related MySQL database. For Linux, use a procedure similar to the one on NetWare to set up a new cluster resource. Use the Linux commands for MySQL in the load and unload scripts. Use a Linux path on a shared Linux POSIX file system for the MySQL database. As a general reference, see |
|
NetStorage |
Yes |
Clustering the NetStorage service is supported for OES 2 SP1 Linux and later. For information, see |
|
NFS |
Not applicable |
Use standard NFS service for Linux. |
|
QuickFinder (Server Synchronization Feature) |
No |
You must create a new cluster resource. QuickFinder 5.0.x is supported only on OES 2 Linux. NetWare uses QuickFinder 4.2.0. QuickFinder does not support any automated procedure or scripts for a rolling upgrade from Netware to Linux. For information, see |
|
Tomcat |
Not applicable |
Use the standard Tomcat service for Linux. |
On NetWare, offline the NSS pool cluster resource, then modify its load and unload scripts to remove the Apache start and stop commands.
On NetWare, online the cluster resource, then cluster migrate it to a Linux node.
After the cluster conversion is finished, use the standard Apache Web Server for Linux to set up the Apache service on the OES 2 Linux servers.
Use a procedure similar to the one on NetWare to set up the Apache configuration file, and copy it to every Linux node in the cluster. Point the service to the virtual IP address of the NSS pool cluster resource that contains the Web content.
On Linux, offline the cluster resource, then modify its load and unload scripts to add the Apache service start and stop commands for Linux.
Online the cluster resource.
Novell AFP for Linux is available beginning in OES 2 SP1 Linux. After you set up Novell AFP on the Linux node and before you finalize the NetWare-to-Linux conversion, use the AFP migration tool to convert the configuration. For information, see Migrating AFP from NetWare to OES 2 SP2 Linux
in the OES 2 SP2: Migration Tool Administration Guide.
The commands in the scripts are also different. After the migration, modify the load and unload scripts on the Linux server. For information, see Section 6.6.4, Comparing File Access Protocol Resource Script Commands.
AFP on Linux supports NCP cross-protocol file locking, which allows NCP, AFP, and CIFS users to access files on an NSS volume concurrently without data corruption by locking the files across protocols. Beginning in OES 2 SP2 Linux, the cross-protocol file locking parameter for NCP Server is enabled by default. It must be enabled on each node in the cluster if you plan to give both NCP users and AFP users access to NSS volume in the cluster. See Configuring Cross-Protocol File Locks for NCP Server
in the OES 2 SP2: NCP Server for Linux Administration Guide.
Mixed-node cluster configurations are not supported by Novell Archive and Version Services.
Before you begin the conversion, make sure that Archive and Version Services is not running on the NetWare servers in the cluster.
Install Archive and Version Services on an OES 2 Linux node in the cluster.
Install Archive and Version Services on a a second OES 2 Linux node in the cluster.
Using the database migration tools, migrate the data in the MySQL database on NetWare to the PostgreSQL database on of the Linux nodes.
Cluster migrate the shared NSS pool resource that contains the volumes that were being archived from the NetWare server to a Linux node.
Remove the NetWare nodes from the cluster and finish the cluster conversion process.
On the Linux node where the primary NSS pool resources are active, use the plug-in in iManager to create an Archive Versioning cluster resource.
Other preparatory tasks are involved in the setup. Follow the procedure as described in Configuring Archive and Version Service for Novell Cluster Services
in the OES 2 SP2: Novell Archive and Version Services 2.1 for Linux Administration Guide.
Copy the database files from the single-server location (/var/opt/novell/arkmanager/data) to the shared Linux POSIX volume that you created when you set up Archive and Version Services for clustering in Step 6.
Use the cp -a command at a terminal console prompt to copy all files and retain the permissions.
Change the ownership of the new database location on the shared volume by entering the following at a terminal console prompt:
chown -R arkuser:arkuser_prggrp /shared/datapath
Edit the /etc/opt/novell/arkmanager/conf/arkdatadir.conf file to change the database location to new shared path.
Edit the /opt/novell/arkmanger/bin/pg_restart.sh file to change the line that starts the PostgreSQL database to the following:
su arkuser -c "postmaster -D /shared/datapath -h 127.0.0.1 -p 5432 -i"
Start Archive and Version Services by entering
rcnovell-ark start
You should see Archive and Version Services and the PostgreSQL database starting.
Novell CIFS for Linux is available beginning in OES 2 SP1 Linux.
After you set up Novell CIFS on the Linux node and before you finalize the NetWare-to-Linux conversion, use the CIFS migration tool to convert the configuration. For information, see Migrating CIFS from NetWare to OES 2 SP2 Linux
in the OES 2 SP2: Migration Tool Administration Guide.
The commands in the scripts are also different. After the migration, modify the load and unload scripts on the Linux server. For information, see Section 6.6.4, Comparing File Access Protocol Resource Script Commands.
CIFS on OES 2 SP1 Linux does not support NCP cross-protocol file locking.
Beginning in OES 2 SP2 Linux, CIFS supports NCP cross-protocol file locking, which allows NCP, AFP, and CIFS users to access files on an NSS volume concurrently without data corruption by locking the files across protocols. Beginning in OES 2 SP2 Linux, the cross-protocol file locking parameter for NCP Server is enabled by default. It must be enabled on each node in the cluster if you plan to give both NCP users and CIFS users access to an NSS volume in the cluster. See Configuring Cross-Protocol File Locks for NCP Server
in the OES 2 SP2: NCP Server for Linux Administration Guide.
The Novell Distributed File Services volume location database (VLDB) .dat file format is the same on both NetWare and Linux. The shared NSS volume that contains the .dat file can be cluster migrated to the Linux server.
Use one of these two methods for migrating the VLDB from NetWare to Linux:
Use this method if you want to use the same shared disk where the VLDB is currently stored.
Install Novell Storage Services and any dependent services on the Linux node, then add it to the mixed cluster that you are converting.
Cluster migrate the DFS cluster resource from NetWare to Linux.
On the Linux node where the VLDB is active, offline the DFS cluster resource.
Remove the NetWare clusters from the cluster by using the cluster leave command, then finish the cluster conversion.
This automatically updates the basic cluster commands in the cluster resource scripts.
Using the plug-in in iManager, modify the load script of the DFS cluster resource to change the vldb command to the Linux format. For example, change it from
vldb /dir=vldbpath
to
vldb -dir /vldbpath
Online the cluster resource.
Run a VLDB repair to ensure that the database is correct.
Use this method if you want to use a different shared disk for the VLDB on Linux. You can do this by adding a DFS replica site on Linux.
Install OES 2 Linux on the server that you want to add to the cluster. Make sure Novell Storage Services and any dependent services are installed.
Create a shared NSS pool and volume on the OES 2 Linux server, or create a shared Linux POSIX volume.
In iManager, add the Linux server as the second VLDB replica site for the DFS management context, and point to the shared NSS volume as the VLDB location.
Allow the VLDB data to synchronize between the NetWare replica and the Linux replica.
In iManager, remove the NetWare instance of the replica site.
Add the Linux server to the mixed-node NetWare cluster.
Continue with the cluster conversion as described in Section 6.4, Converting NetWare Cluster Nodes to OES 2 Linux (Rolling Cluster Conversion).
The Novell DHCP Server for Linux is a standards compliant implementation that is based on the bind protocol. DHCP uses a different schema on Linux to store the configuration in eDirectory.
Novell DHCP Server for Linux supports using a shared Linux POSIX file system or a shared NSS file system for the cluster resource. For information, see Configuring DHCP with Novell Cluster Services for the NSS File System
and Configuring DHCP with Novell Cluster Services for the Linux File System
in the OES 2 SP2: Novell DNS/DHCP Administration Guide for Linux.
After you set up Novell DHCP Server on the Linux server, you can use the DHCP Migration utility to convert the configuration from NetWare to Linux. You cannot directly reuse the data. Use one of the following scenarios to migrate your DNS server data, then perform the post-migration tasks to set up clustering.
For information about prerequisites, see Migrating DHCP from NetWare to OES 2 SP2 Linux
in the OES 2 SP2: Migration Tool Administration Guide.
In this scenario, both the NetWare server and the OES 2 SP1 Linux server are in the same eDirectory tree. The NetWare source server must be running NetWare 5.1 or later versions. The Linux target server must be running OES 2 SP1 Linux on either 32-bit or 64-bit hardware.
Run the DHCP migration tool from one of the Linux nodes. Perform the Tree Level Migration with the same Source server (tree to which NetWare clustered nodes are attached) and Target server (tree to which the Linux clustered nodes are attached). This ensures that the entire NetWare DHCP configuration data is available for Linux DHCP. For information see NetWare and Linux Clusters Attached to the Same Tree
in the OES 2 SP2: Migration Tool Administration Guide.
IMPORTANT:Before starting the DHCP server on the Linux cluster, stop the DHCP server on the Netware cluster.
In this scenario, the NetWare server and the OES 2 SP1 Linux server are on different eDirectory trees. The NetWare source server must be running NetWare 5.1 or later versions. The Linux target server must be running OES 2 SP1 Linux on either 32-bit or 64-bit hardware.
Run the DHCP migration tool from one of the Linux nodes. Perform the Tree Level Migration with a different Source server (tree to which NetWare clustered nodes are attached) and Target server (tree to which the Linux clustered nodes are attached). This ensures that the entire NetWare DHCP configuration data is available for Linux DHCP. For information, see NetWare and Linux Clusters Attached to Different Trees
in the OES 2 SP2: Migration Tool Administration Guide.
IMPORTANT:Before starting the DHCP server on the Linux cluster, stop the DHCP server on the Netware cluster.
On the Linux node where you ran the migration, configure the DHCP service for clustering by using one of the following methods described in OES 2 SP2: Novell DNS/DHCP Administration Guide for Linux:
Online the DHCP service cluster resource.
On the Linux node where you ran the migration:
Open the /mountpath/etc/dhcpd.conf file in a text editor.
Replace /mountpath with the Linux path to the directory in the shared volume where DHCP-specific directories are created.
In the /mountpath/etc/dhcpd.conf file, change the value for the ldap-dhcp-server-cn parameter to the cn needed for the migrated server, then save your changes.
Copy the migrated_server.leases file from /var/lib.dhcp/bd directory to the /mountpath/var/lib/dhcp/db/ directory, then rename it here to dhcpd.leases.
Stop the DHCP server on the NetWare cluster.
Start the DHCP server on the Linux cluster.
You can migrate the data from the Novell DNS Server on NetWare to a Novell DNS Server on Linux after you have installed and set up DNS services on an OES 2 SP1 Linux node in the cluster. You cannot directly reuse the data. Use one of the following scenarios to migrate your DNS server data, then perform the post-migration tasks.
For information about prerequisites, see Migrating DNS from NetWare to OES 2 SP2 Linux
in the OES 2 SP2: Migration Tool Administration Guide.
In this scenario, both the NetWare server and the OES 2 SP1 Linux server are in the same eDirectory tree. The NetWare source server must be running NetWare 5.1 or later versions. The Linux target server must be running OES 2 SP1 Linux on either 32-bit or 64-bit hardware. Use iManager to move the DNS server from a NetWare NCP server to an OES 2 SP1 Linux NCP server.
Run the DNS migration tool from one of the Linux nodes.Perform the Tree Level migration with the same Source server (tree to which NetWare clustered nodes are attached) and Target server (tree to which the Linux clustered nodes are attached). This ensures that the entire NetWare DNS configuration data is available for Linux DNS. For information see Using iManager to Migrate Servers within the Same eDirectory Tree
in the OES 2 SP2: Migration Tool Administration Guide.
IMPORTANT:Before starting the DNS server on the Linux cluster, stop the DNS server on the Netware cluster.
In this scenario, the NetWare server and the OES 2 SP1 Linux server are on different eDirectory trees. The NetWare source server must be running NetWare 5.1 or later versions. The Linux target server must be running OES 2 SP1 Linux on either 32-bit or 64-bit hardware.
Run the DNS migration tool from one of the Linux nodes.Perform the Tree Level Migration with a different Source server (tree to which NetWare clustered nodes are attached) and Target server (tree to which the Linux clustered nodes are attached). This ensures that the entire NetWare DNS configuration data is available for Linux DNS. For information see Using iManager to Migrate Servers across eDirectory Trees
in the OES 2 SP2: Migration Tool Administration Guide.
IMPORTANT:Before starting the DNS server on the Linux cluster, stop the DNS server on the Netware cluster.
See Post-Migration Procedure
in the OES 2 SP2: Migration Tool Administration Guide.
Novell Certificate Server provides two categories of services: Certificate Authority (CA) and Server Certificates. The Certificate Authority services include the Enterprise CA and CRL (Certificate Revocation List). Only one server can host the CA, and normally that same server hosts the CRLs if they are enabled (although if you move the CA to a different server, the CRLs usually stay on the old server). The CA and CRL services are not cluster-enabled in either NetWare or OES 2 Linux, and therefore, there are no cluster-specific tasks for them.
Novell Certificate Server provides a Server Certificates service for NetWare and Linux. The service is not clustered. However, clustered applications that use the server certificates must be able to use the same server certificates on whichever cluster node they happen to be running. Use the instructions in the following sections to set up Server Certificate objects in a clustered environment to ensure that your cryptography-enabled applications that use Server Certificate objects always have access to them.
The eDirectory Server Certificate objects are created differently in OES 2 Linux and cannot be directly reused from the NetWare server. The differences and alternatives for setting up certificates on Linux are described in the following sections:
When you install NetWare or OES 2 Linux in an eDirectory environment, the Server Certificate service can create certificates for eDirectory services to use. In addition, custom certificates can be created after the install by using iManager or command line commands.
For NetWare, all applications are integrated with eDirectory. This allows applications to automatically use the server certificates created by Novell Certificate Server directly from eDirectory. In a NetWare cluster, you might have copied the Server Certificate objects to all nodes in the cluster using backup and restore functions as described in Server Certificate Objects and Clustering
in the Novell Certificate Server 3.3.2 Administration Guide.
For OES 2 Linux, many applications (such as Apache and Tomcat) are not integrated with eDirectory and therefore, cannot automatically use the certificates created by Novell Certificate Server directly from eDirectory. By default, these services use self-signed certificates, which are not in compliance with the X.509 requirements as specified in RFC 2459 and RFC 3280.
To address the difference, Novell Certificate Server offers an install option for OES 2 Linux called that automatically exports the default eDirectory certificate and its key pair to the local file system in the following files:
Recent versions of Novell Certificate Server create default certificates that allow you to specify an alternative IP address or DNS address by adding it in the Subject Alternative Name extension. This requires that your DNS service be configured to reflect the cluster IP/DNS address as the default (or first) address. If the DNS service is set up correctly, the cluster applications can use the default certificates without needing any administration.
IMPORTANT:If the DNS service is not set up correctly, then you must use the process described for external certificates in Using External Certificates in a Cluster.
For OES 2 Linux clusters using the internal certificate method, make sure the DNS service is configured to use the cluster IP/DNS address. During the OES 2 Linux install, select the option so that Novell Certificate Server automatically creates the certificate with the correct IP/DNS address. By selecting the Use eDirectory Certificates option during the install and using the cluster IP/DNS address, clustered applications should be able to access the certficates without needing further configuration for the Server Certificate object.
External (third-party) certificates create a Server Certificate object that includes the cluster's IP and/or DNS address. Create a backup of this certificate. For each server in the cluster, create a Server Certificate object with the same name by importing the previously created backup certificate and key pair to a location on that server. This allows all of the servers in the cluster to use and share the same certificate and key pair. After all cluster nodes have the certificate, configure the cluster applications to use the server certificate.
IMPORTANT:This cluster task can also be used for sharing internal certificates on the cluster nodes. In early versions of Novell Certificate Server, this was the only option available.
For information about exporting and using eDirectory Server Certificates for External Services, see Using eDirectory Certificates with External Applications
in the Novell Certificate Server 3.3.2 Administration Guide.
For OES 2 Linux clusters using the external certificate method, the solution is more complicated than for internal certificates. You must create the certificate for each server in the cluster just as you did for NetWare. You must also create a configuration on the SAS:Service object for each server so that the common certificate is automatically exported to the file system where the non-eDirectory enabled applications can use it.
After adding the OES 2 Linux node to the NetWare cluster, you must use the following procedure to set up clustering for iPrint on Linux, then migrate the iPrint information from a NetWare shared NSS pool resource to a newly created Linux shared NSS pool resource on the Linux node.
On a Linux node, create a new shared NSS pool and volume.
Log in as the root user to the Linux node where the shared pool resource is active, go to the /opt/novell/iprint/bin directory, then run the iprint_nss_relocate script by entering
./iprint_nss_relocate -a admin_fdn -p password -n nss_volume_path -l cluster
Replace admin_fdn with the comma-delimited fully distinguished name of the iPrint administrator user (such as cn=admin,o=mycompany). Replace password with the actual password of the iPrint administrator user. Replace nss_volume_path with the Linux path (such as /media/nss/NSSVOL1) to the shared NSS volume where you want to relocate the iPrint configuration data.
Review the messages displayed on the screen to confirm the data migration from the local Linux path to the shared NSS path is completed.
For example, enter
./iprint_nss_relocate -a cn=admin,o=mycompany -p pass -n /media/nss/NSSVOL1 ‑l cluster
For information, see Executing the Script
in the OES 2 SP2: iPrint for Linux Administration Guide.
For each Linux node in the cluster where iPrint is installed, set up clustering for iPrint.
In iManager, select , then cluster migrate the shared NSS pool resource from the active Linux node to another Linux node.
Log in to the Linux node as the root user, then run the iprint_nss_relocate script as described in Step 2, using the same values.
In iManager, click , then select the Linux node where the shared NSS pool is currently active.
Select the Linux shared NSS pool, then go to the tab and move all of the remaining NetWare nodes from the to column to prevent an inadvertent failback of the resource to a NetWare server.
In iManager, select , then create a Driver Store ( > ) and a Print Manager ( > ) on the Linux node with the IP or DNS name of the shared NSS pool resource.
IMPORTANT:Do not modify the load and unload scripts for the Linux shared NSS pool resource at this time.
Use the Migration tool to migrate data from the NetWare shared NSS pool to the Linux shared NSS pool.
For information about using the Migration tool for iPrint migration, see Migrating iPrint from NetWare to OES 2 Linux
in the OES 2 SP2: Migration Tool Administration Guide.
Start the migration tool from the target server, then authenticate by using the IP address or DNS name of the NetWare shared NSS pool resource.
For the target server, authenticate by using the IP address or DNS name of the Linux shared NSS pool resource.
Configure the Migration tool for migrating iPrint information, then proceed with the migration as described in Migrating iPrint from NetWare to OES 2 Linux
.
Edit the load and unload scripts for the Linux shared NSS pool resource. For information, see Prerequisites
in the OES 2 SP2: iPrint for Linux Administration Guide.
In a Novell Cluster Services cluster, you must install QuickFinder on each node in the cluster. This registers QuickFinder Server with each of the Web servers and application servers running on each server. On OES 2 Linux, QuickFinder is installed by default in the /var/lib/qfsearch directory. We recommend that you use the default path. After the installation, you must set up one or more virtual search servers to enable QuickFinder Server to work in a cluster.
When the Linux setup is completed, you are ready to manually migrate settings from the NetWare cluster to the Linux cluster. Set up QuickFinder on the OES 2 Linux cluster nodes, then manually migrate QuickFinder data from a NetWare node to an OES 2 Linux node.
For information about using the QuickFinder Server Manager and other procedures for QuickFinder, see the OES 2: Novell QuickFinder Server 5.0 Administration Guide.
Before you begin:
On one Linux node, create a Linux POSIX cluster resource where all of the indexes and virtual search server settings are to be stored.
For information, see Section 11.0, Configuring Cluster Resources for Shared Linux POSIX Volumes.
On each OES 2 Linux node, do the following to set up QuickFinder for Linux:
Cluster migrate the Linux POSIX cluster resource to the OES 2 Linux node where you want to install QuickFinder
Install QuickFinder on the active cluster node.
Create a virtual search server to enable QuickFinder Server to work in a cluster.
Give each virtual search server the same name and location. After the first server is set up, any settings that you create on the shared volume are automatically displayed.
On the active cluster node, open the QuickFinder Server Manager.
Click , then click .
In , specify the DNS name of the cluster.
In , specify the Linux path on the Linux POSIX cluster resource where all of the indexes and virtual search server settings will be located.
Click .
Repeat Step 1 to Step 3 for each of the nodes in the cluster.
Use the following steps to migrate QuickFinder Server data from a NetWare server to a corresponding Linux server. You must repeat the tasks for each NetWare server in the cluster. It assumes a one-to-one server replacement in the cluster.
WARNING:Migrating indexes and virtual search server settings from a QuickFinder Server running on NetWare to QuickFinder Server running on OES 2 Linux replaces the existing settings on the Linux server. If you want to merge your NetWare settings with the existing Linux settings, you must manually re-create the NetWare settings by using the QuickFinder Server Manager.
Open a Web browser, the access the QuickFinder Server Manager on the NetWare server.
http://servername/qfsearch/admin
Click in the top toolbar.
Write down the paths for each virtual search server displayed in the column.
On the OES 2 Linux server where the shared volume is active, mount the NetWare server by using the ncpmount command.
Make a backup of the /var/lib/qfsearch/SiteList.properties file.
Make sure that you don't have a file with this name as a backup on the NetWare server.
Copy all .properties and Cron.jobs files from the root directory sys:/qfsearch on the NetWare server to /var/lib/qfsearch on the Linux server.
Copy sys:/qfsearch/Sites and all of its subdirectories to /var/lib/qfsearch/Sites.
Copy sys:/qfsearch/Templates and all of its subdirectories to /var/lib/qfsearch/Templates.
If any of the paths listed in Step 3 are not under sys:/qfsearch (for example, if you installed a virtual search server somewhere other than the default location), you must also copy those paths to Linux.
For example, if you have the path sys:/SearchSites/PartnerSite, you must copy it to the Linux server. You could copy it to /var/opt/SearchSites/PartnerSite or /var/lib/qfsearch/Sites/PartnerSite.
Edit all NetWare paths in /var/lib/qfsearch/SiteList.properties to reflect the new Linux paths.
For example, change sys:/qfsearch to /var/lib/qfsearch.
Or, as in the example in Step 9, change sys:/SearchSites/PartnerSite to /var/opt/SearchSites/PartnerSite.
Some paths might have one or two backslashes (\) that must be replaced with one forward slash (/). For example, sys:\\qfsearch\\docs needs to be changed to /var/lib/qfsearch/docs.
Update all NetWare paths in the properties and configuration files copied in the steps above to the Linux paths, and update any DNS names.
The following files must be updated:
For each of the virtual search servers, modify the following:
qfind.cfg
Any of the above .properties files, if they exist.
IMPORTANT:Linux filenames are case sensitive.
The names of most properties files are mixed case, so make sure the files copied from NetWare are the correct case. You can compare them to the .properties.sample files on Linux.
You might also need to update paths in templates. If you have problems such as a template not being found or some properties not being set properly, check the case of the filename.
If you modified any file
index paths to index directories on the Linux server, that index must be regenerated.
After all the files have been modified, run the following commands to set the access rights and the owner and groups so that the QuickFinder engine has rights to access the files.
As the root user, enter
chown -R root:www /var/lib/qfsearch
chmod -R 770 /var/lib/qfsearch
Repeat Step 1 to Step 12 for each NetWare and Linux pair of nodes.
QuickFinder Server 5.0 indexes are not compatible with previous versions of QuickFinder Server. The indexes must be regenerated, and you cannot synchronize QuickFinder Server 5.0 indexes with indexes from a previous version of QuickFinder Server (and vice-versa).
To perform a search on the shared volume after the NetWare migration is complete:
Open a Web browser, then enter
http://DNS_CLUSTER/qfsearch/search
QuickFinder Server sees the DNS and sends the request to the appropriate virtual search server.