PMDF Installation Guide
Solaris Edition


Previous Next Contents Index

1.4 Post-Installation Tasks for Upgrades

Note

If you are upgrading from PMDF v5.2 or higher, Process Software recommends using the script /pmdf/bin/upgrade_all_dbs.sh which simplifies the post-installation tasks. As in the past, you can perform these steps individually.

The script /pmdf/bin/upgrade_all_dbs.sh replaces steps 1 and 2.

  1. If you are using a compiled configuration, you must recompile it after an upgrade of PMDF with the command:


    # pmdf cnbuild
    

  2. The format of the SleepyCat environment files has changed as of PMDF V6.2-1. The old files must be removed from the /pmdf/table, /pmdf/table/queue_cache, and /var/tmp directories. In each directory run


    # rm __db.0*
    

  3. If you are using the pmdfcyrus program to deliver to store, you should check the permission settings for the /pmdf/bin/pmdfcyrus image to make sure that they are still correct. The PMDF installation attempts to set the permissions properly when it updates the image. But if the permissions are not correct, you will need to reset them manually with the commands:


    # chown cyrus-user /pmdf/bin/pmdfcyrus
    # chmod 4755 /pmdf/bin/pmdfcyrus
    
    where cyrus-user is whatever username was selected when installing Cyrus, typically cyrus.

  4. If you are using the PMDF-LAN Lotus Notes channel or PMDF-XGS, be sure to upgrade the PMDF images used on the Lotus Notes server or XGS transport bridge system. These are OS/2 or NT PMDF images, available under the /pmdf/other/ directory on the PMDF system, or available directly off the PMDF distribution CD-ROM under the other directory. Note that this is an ISO 9660 with Rockridge extensions CD-ROM, readable from many different platforms including OS/2 and NT.
    1. For PMDF-XGS, shutdown all the PMDF-XGS processes on the transport bridge and then copy the respective files to the transport bridge system. Then restart the PMDF-XGS processes on the transport bridge system.
    2. For a PMDF-LAN Lotus Notes channel, shut down the PMDF Lotus Notes Server Add-ins, using Lotus Notes server console commands such as TELL PNGATECIN QUIT, and TELL PNGATECOUT QUIT (or just TELL PNGATEC QUIT if you were using just the one Server Add-in). Then copy the new server Add-ins to the Lotus Notes server, and start them back up (e.g., LOADPNGATECIN and LOAD PNGATECOUT).

  5. Start up the PMDF Job Controller and PMDF Service Dispatcher using the command:


    # pmdf startup
    

  6. If you also installed PMDF-DIRSYNC, PMDF-LAN, PMDF-MB400, PMDF-X400, or PMDF-XGS for the first time, then you should configure them now. Configuration instructions for PMDF-LAN may be found in Chapters 6 and 7; configuration instructions for PMDF-X400 may be found in Chapters 8 and 9; configuration instructions for PMDF-XGS may be found in Chapters 10 through 13.

1.4.1 Additional Post-Installation Tasks for Sites Upgrading from PMDF V6.1 or V6.1-1

  1. The HTTP configuration file must be updated upon upgrading to PMDF V6.2 or later from 6.1-1 or earlier. The HTTP configuration file is usually /pmdf/table/http.cnf on Solaris. This file can be updated by running the pmdf configure dispatcher utility, or by editing the http.cnf file manually. The manual steps are as follows. Add the following three lines:


    [PATH=/images/] 
    GET=PMDF_HTTP_GET 
    HIDDEN=1 
    
    Find the following lines and replace them as follows:

  2. As of PMDF V6.2, the global pmdf filter file (pmdf.filter in the table directory) requires the require command, the same way that the channel and user filter files always have. If you have a global filter file that contains any of the following commands, you must add a require statement to the top of your filter file, which lists the commands that the filter file uses.

1.4.2 Additional Post-Installation Tasks for Sites Upgrading from PMDF V6.0

Note

The script /pmdf/bin/upgrade_all_dbs.sh automates the following steps:
  1. The format of the PMDF queue cache database has changed as of PMDF V6.1. from the formats used in PMDF V6.0 and earlier. Therefore, the PMDF queue cache database must be rebuilt, via the commands:


    # rm /pmdf/table/queue_cache/*
    # pmdf cache -synchronize
    
    Note that it is a good idea to rebuild the PMDF queue cache database with the above commands after any upgrade of PMDF, including after minor interim releases.

    Note

    After an upgrade from PMDF V6.0, the following files can be safely deleted.


    __db_lock.share
    __db_mpool.share
    
    They may be located in /pmdf/table, /pmdf/tmp, /tmp, /var/tmp, or /usr/tmp.


  2. UNIX sites which were using the popstore or MessageStore under PMDF V6.0 or earlier and which are upgrading to PMDF V6.1 or later must rebuild (or should build for the first time) the PMDF popstore/MessageStore user database since its format has changed. As of PMDF V5.2, in order to accelerate certain management functions such as generating listings of user accounts, using wild cards in conjunction with account management commands, etc., a database of user accounts is used by the popstore and MessageStore. This database, referred to as the popstore or MessageStore user database, is located in the /pmdf/user directory on UNIX systems. This database is only used for management functions and does not in any way impact the performance of the popstore or MessageStore. The PMDF popstore/MessageStore user database is located via the PMDF_POPSTORE_USER_DATABASE PMDF tailor file option, and is usually /pmdf/user/userdb. Sites upgrading from PMDF V5.2 or V6.0 must rebuild their existing popstore/MessageStore user database using the commands:


    # rm /pmdf/user/userdb.*
    # pmdf msgstore x-build-user-db
    
    or


    # rm /pmdf/user/userdb.*
    # pmdf popstore x-build-user-db
    
    Sites which were using the PMDF popstore under PMDF V5.1 and which are upgrading to PMDF V6.1 or later should create a popstore user database using the command:


    # pmdf popstore x-build-user-db
    
    after upgrading. This command will scan the profile directory tree and build a user database.

  3. The format of all PMDF SleepyCat databases has changed as of PMDF V6.1. You must convert all of these databases to the current format by using the db_upgrade utility. Note that db_upgrade changes the database in-place, so Process Software recommends making a backup copy first. For example:


    # cd /pmdf/user
    # cp forwarddb.db forwarddb.db.old
    # /pmdf/bin/db_upgrade -s forwarddb.db
    
    Note that the -s is required.

    The /pmdf/bin/finddb.sh shell script may be used to attempt to detect the major PMDF databases. This utility constructs the appropriate db_upgrade commands to transform the old SleepyCat databases into the new format in the script /pmdf/bin/convertdb.sh which you can then check and run to do the db_upgrade commands.
    Following is a partial list of possible SleepyCat database files in /pmdf directories with .db extensions:

    Note

    This ends the steps that are automated by upgrade_all_dbs.sh.

    After successful completion of the /pmdf/bin/upgrade_all_dbs.sh procedure, you will need to complete the following post_installation steps as appropriate for your site. Note that if you have additional PMDF databases on your system (for instance, users' own personal alias databases), then you will also need to convert those databases. Users wanting to convert their own personal alias database may do so with the commands:


    % cp aliasesdb.db aliasesdb.db.old
    % /pmdf/bin/db_upgrade -s aliasesdb.db
    
    which will convert the aliasesdb.db file in place.

1.4.3 Additional Post-Installation Tasks for Sites Upgrading from PMDF V5.2

The following is a list of additional post-installation tasks that must be completed following an upgrade from V5.2 of PMDF. Sites upgrading from PMDF V6.0 or later should skip this section.

Note

The following step is performed as part of the /pmdf/bin/upgrade_all_dbs.sh procedure. You can, of course, perform this step manually as in the past.

  1. The underlying storage of all PMDF databases changed as of PMDF V6.0 from the format used in PMDF V5.2 and earlier. In particular, you must rebuild all PMDF crdb databases using the pmdf crdb command with any appropriate qualifiers to recreate the database from an input text file or convert the databases using the pmdf convertdb utility. The /pmdf/bin/finddb.sh shell script may be used to attempt to detect the major PMDF databases. This utility constructs the appropriate 'pmdf convertdb' command to transform the old crdb databases into the current format in the script /pmdf/bin/convertdb.sh which you can then check and run to do the convertdb command. Following is a list of the possible crdb database files in /pmdf directories with .dat, .idx, .pag, and .dir extensions:

    Note

    This ends the steps that are automated by upgrade_all_dbs.sh.
    Note that if you have additional PMDF databases on your system (for instance, users' own personal alias databases), then you will also need to convert those databases. Users wanting to convert their own personal alias database may do so with the command:


    % pmdf convertdb aliasesdb aliasesdb
    
    which will create a new file aliasesdb.db that will replace in functionality the previous files aliasesdb.dat and aliasesdb.idx. Also note that the base name (name sans file extension) of the PMDF password database has been changed from pauth to passworddb, so if your sites use the PMDF password database (not all sites do) be sure to use the new name when you are converting the password database.

1.4.4 Additional Post-Installation Tasks for Sites Upgrading from PMDF V5.1

The following is a list of additional post-installation tasks that must be completed following an upgrade from V5.1 of PMDF-MTA, PMDF-LAN, or PMDF-X400. Sites upgrading from PMDF V5.2 or later should skip this section.
  1. Update configuration:
    1. V5.1 PMDF-X400 sites that were using the former MIME-CONTENT-TYPES-TO-X400 mapping table to control the mapping of MIME attachments to X.400 attachments should note that that mapping table became obsolete as of PMDF V5.2, having been superseded by the more general, MIME-TO-X400-CONTENT-TYPES mapping table. You must convert the name of the mapping table to the new name, and also include the new channel name argument on the left hand (pattern) side; the file /pmdf/table/x400_mappings.sample may provide a useful sample starting point.
    2. If you are using PMDF POP or IMAP servers, be aware that some password handling changed between PMDF V5.1 and PMDF V5.2. The new, configurable authentication source control used as of PMDF V5.2 by, for instance, the POP and IMAP servers has default behavior that is intended to operate "naturally" and usually means no visible change to users. But a few users with less natural setups (for instance, non-popstore users who have PMDF password database entries different from their system password) can see a change in behavior.
      To achieve the PMDF 5.1 behavior, a PORT_ACCESS mapping would need to segregate POP and IMAP connections into different rulesets, e.g.,


      PORT_ACCESS 
       
       TCP|*|110|*|*        $YPOP-RULES 
       TCP|*|143|*|*        $YIMAP-RULES 
       
      
      and the security configuration file security.cnf would need corresponding ruleset definitions of:


      [RULESET=DEFAULT] 
      ENABLE=MSGSTORE/*,PASSDB/*,SYSTEM/* 
      ! 
      [RULESET=POP-RULES] 
      ENABLE=MSGSTORE/*,PASSDB/CRAM-MD5,PASSDB/APOP,SYSTEM/* 
      ! 
      [RULESET=IMAP-RULES] 
      ENABLE=SYSTEM/* 
      

    3. The LOG_CONNECTION option for controlling logging of connection information is now not simply an on/off setting as in PMDF V5.1, but rather as of PMDF V5.2 is bit-encoded for more specific controls.
  2. For sites upgrading from PMDF V5.1 using the PMDF Lotus Notes channel, if you have not already done so you must now switch to using the two independent Server Add-ins PNGATECIN and PNGATECOUT in place of the single PNGATEC Add-in originally released in PMDF V5.1: change the line in the Lotus Notes initialization file, notes.ini, defining server tasks from


    ServerTasks=...,PNGATEC 
    
    to


    ServerTasks=...,PNGATECIN,PNGATECOUT 
    

  3. The multithreaded PMDF POP3 and IMAP servers are handled by the PMDF Service Dispatcher. If you were previously using non-PMDF servers, or older PMDF singlethreaded servers running under the inetd daemon, then you must shut down your old servers before you can use the PMDF multithreaded servers. Before you can use the multithreaded POP3 or IMAP servers, you must also configure the Dispatcher to run the desired service. If you will be reconfiguring PMDF-MTA using the web-based configuration utility, the Dispatcher will be configured automatically. Otherwise, you may use the command line pmdf configure dispatcher utility (on a PMDF-MTA system) to configure the Dispatcher.


Previous Next Contents Index