PMDF Installation Guide
Solaris Edition


Previous Next Contents Index

1.5 Post-Installation Tasks for Upgrades

  1. Run the script /pmdf/bin/upgrade_all_dbs.sh. This script performs the following actions (which can also be performed by hand if desired):
    1. If you are using a compiled configuration, it is recompiled with the command:


      # pmdf cnbuild
      

    2. If necessary, the utility performs database conversions and other activities as required based on the version of PMDF that you are upgrading from. See the sections below.
  2. Check the contents of the PMDF tailor file /etc/pmdf_tailor that was supplied by this installation. Merge in any changes that you made to the file, using the copy that you saved before you started the upgrade.
  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, make sure you upgrade the PMDF images that are used on the Lotus Notes server, or XGS transport bridge system. These are OS/2 or NT PMDF images. The images are located in the /pmdf/other/ directory on the PMDF system. They are also available on the PMDF distribution CD-ROM in the other directory. (The CD-ROM is an ISO 9660 with Rockridge extensions CD-ROM, which is readable from many different platforms, including OS/2 and NT.)
    1. For PMDF-XGS, shutdown all the PMDF-XGS processes on the transport bridge, copy the respective files to the transport bridge system, and 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 startup them back up (e.g., LOAD PNGATECIN 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.5.1 Additional Post-Installation Tasks for Sites Upgrading from PMDF V6.4 or Earlier

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

As of PMDF V6.5, the format of PMDF databases has changed from Berkeley DB (SleepyCat) to PBL. All databases must be rebuilt or converted in order for PMDF V6.5 or later to be able to read them. PMDF V6.5 or later cannot read any databases in V6.4 or earlier formats.

Note that PMDF's PBL databases consist of three files: database.pbl which contains the data, database.idx which contains the index, and database.lck which is used for locking the database.

  1. As listed in Section 1.5, you should run the script /pmdf/bin/upgrade_all_dbs.sh.
    Note however that if you are upgrading from V5.2 or earlier, this script cannot be used since pre-V6.0 formatted databases cannot be converted but must instead be rebuilt.
    This utility will:
    1. Rebuild the popstore/MessageStore user database, with the command:


      # pmdf msgstore x-build-user-db
      

    2. Find and convert all other databases in the /pmdf tree, with the command:


      # pmdf convertdb <old-database> <new-database>
      
      Note that the defragment database /pmdf/table/defragment_cache.* is excluded from this process. It does not need to be converted as the defragment channel will rebuild the database from the messages in the /pmdf/queue/defragment directory the first time it runs. Also note that databases outside the /pmdf tree, such as personal alias databases in users' home directories, are not found and converted by upgrade_all_dbs.sh.

    3. Delete the now unused Berkeley DB (SleepyCat) environment files, with the commands:


      # rm /var/tmp/__db.0*
      # rm /pmdf/table/__db.0*
      # rm /pmdf/table/queue_cache/__db.0*
      

  2. You must rebuild or convert all remaining databases.
    All databases that are not converted by /pmdf/bin/upgrade_all_dbs.sh should be rebuilt or converted by hand.
    1. All databases for which you have sources (including those sources you created before the upgrade using the pmdf dumpdb command) can be rebuilt using the pmdf crdb command.
    2. All databases created by pmdf db should be rebuilt. This includes the personal alias databases located in users' home directories (which are not converted by upgrade_all_dbs.sh). Before doing the upgrade, you should have generated source files for these databases by using the pmdf db write command. At this time, you should rebuild these databases from those source files using the pmdf db run command. If you do not have a source file, the database can be recreated by using the pmdf db utility and adding each entry back in by hand. If you cannot rebuild these databases, they can be converted using the pmdf convertdb command if necessary.
    3. Databases created by utilities such as pmdf profile or pmdf password, and the databases created by MessageStore/popstore such as the forward database and the group names database must either be converted using pmdf convertdb or recreated by running the corresponding utility and adding each entry back in by hand.

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

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

  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:
    1. Add the following three lines:


      [PATH=/images/] 
      GET=PMDF_HTTP_GET 
      HIDDEN=1 
      

    2. Find the following lines and replace them as follows:
      • replace [PATH=/popstore_user/] with [PATH=/msps_user/]
      • replace [PATH=/popstore_pwd/] with [PATH=/chng_pwd/]
  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.5.3 Additional Post-Installation Tasks for Sites Upgrading from PMDF V6.0

The following is a list of additional post-installation tasks that should be completed following an upgrade from V6.0 of PMDF. Sites upgrading from PMDF V6.1 or later should skip this section.
  1. The following Berkeley DB (SleepyCat) environment files can be safely deleted. They may be located in /pmdf/table, /pmdf/tmp, /tmp, /var/tmp, or /usr/tmp.


    __db_lock.share
    __db_mpool.share
    

1.5.4 Additional Post-Installation Tasks for Sites Upgrading from PMDF V5.2 or Earlier

The following is a list of additional post-installation tasks that must be completed following an upgrade from V5.2 or earlier of PMDF. Sites upgrading from PMDF V6.0 or later should skip this section.
  1. The underlying storage of all PMDF databases changed as of PMDF V6.5. The database formats used in PMDF V5.2 and earlier cannot be converted directly to PMDF the current format. If you are upgrading directly from PMDF V5.2 or earlier to V6.5 or later, your only choice is to rebuild all databases from sources. Most databases can be rebuilt using the pmdf crdb command or the pmdf db utility. Databases such as the password database must be recreated using their corresponding utility, such as the pmdf password utility.
  2. As of PMDF V6.0, there is a new PMDF periodic job that you need to schedule cron to run periodically. If you have not customized your pmdf crontab entries, then you may simply issue the commands:


    # su pmdf
    # crontab /pmdf/table/cronjobs
    # exit
    
    Otherwise, if you prefer to add the new crontab entry manually so as not to overwrite your existing, possibly customized, pmdf crontab entries, then issue the commands:


    # su pmdf
    # crontab -e
    
    and use the editor thus invoked to add an entry such as the following:


    0  0,10,20,30,40,50 * * * * /pmdf/bin/return_sh >/dev/null 2>&1 
    
    Make sure to exit from the pmdf user shell when you have finished adding this entry; i.e.:


    $ exit
    

1.5.5 Additional Post-Installation Tasks for Sites Upgrading from PMDF V5.1 or Earlier

The following is a list of additional post-installation tasks that must be completed following an upgrade from V5.1 or earlier 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