PMDF Installation Guide
Tru64 UNIX Edition


Previous Next Contents Index

1.5 Post-Installation Tasks for Upgrades

  1. Run the script /pmdf/bin/upgrade_all_dbs.sh to convert databases to the V6.5 format, and perform other post-installation tasks. Note 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 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. The popstore/MessageStore user database is rebuilt with the command:


      # pmdf msgstore x-build-user-db
      

    3. All other databases in the /pmdf tree are found and converted to V6.5 format using 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.

    4. The Berkeley DB (SleepyCat) environment files are no longer used, so they are deleted, using the commands:


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

  2. Rebuild or convert all remaining databases.
    All databases must be rebuilt or converted in order for PMDF V6.5 to be able to read them. PMDF V6.5 cannot read any databases in V6.4 or earlier formats.
    Note that PMDF V6.5 uses PBL as its database software. PMDF V6.5'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. 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.
  3. 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.
  4. If you are using the pmdfcyrus program to deliver to the Cyrus message store, 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 correctly when it updates the image. However, if the permissions are not correct, you will need to reset them manually with the following commands


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

  5. 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).
  6. Use the following command to start up the PMDF Job Controller and PMDF Service Dispatcher:


    # pmdf startup
    

  7. Configure all PMDF layered products that you installed or updated (for example, PMDF-DIRSYNC, PMDF-LAN, PMDF-MB400, PMDF-X400, or PMDF-XGS). See the following chapters for configuration instructions and examples for a particular layered product:

1.5.1 Additional Post-Installation Tasks for Sites Upgrading from PMDF V6.1 or 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 V6.1-1 or earlier. The HTTP configuration file is usually /pmdf/table/http.cnf on UNIX. 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.2 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.3 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 V6.5 format. If you are upgrading directly from PMDF V5.2 or earlier to V6.5, 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.4 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-DIRSYNC, PMDF-LAN, PMDF-MB400, or PMDF-X400. Sites upgrading from PMDF V5.2 or later should skip this section.
  1. Update configuration:
    1. The MIME-CONTENT-TYPES-TO-X400 mapping table (used in V5.1 PMDF-X400 and PMDF-MB400 to control the mapping of MIME attachments to X.400 attachments) became obsolete as of PMDF V5.2. It has been superseded by the new, more general MIME-TO-X400-CONTENT-TYPES mapping table. Sites using the old (now obsolete) mapping table must convert the name of the old table to the new name. They must also include the new channel name argument on the left hand (pattern) side. For a useful sample starting point, see the file /pmdf/table/x400_mappings.sample.
    2. If you are using PMDF POP or IMAP servers, be aware that some password handling changed as of PMDF V5.2. The new, configurable authentication source control that is being used as of PMDF V5.2 by the POP and IMAP servers, has default behavior that is intended to operate naturally. This usually means that there is no visible change to users. However, users who have less natural setups (for example, non-popstore users who have PMDF password database entries that are different from their system password) can see a change in behavior.
      To achieve the previous behavior (before PMDF V5.2), a PORT_ACCESS mapping needs to segregate POP and IMAP connections into different rulesets. For example,


      PORT_ACCESS 
       
       TCP|*|110|*|*        $YPOP-RULES 
       TCP|*|143|*|*        $YIMAP-RULES 
       
      
      Also, the security configuration file (security.cnf) needs 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 that is used to control logging of connection information is no longer an on/off setting, as it was in PMDF V5.0 and PMDF V5.1. Rather, it is bit-encoded for more specific controls.
  2. If you are upgrading from PMDF V5.1 using the PMDF Lotus Notes channel, and you have not already switched to using the two independent Server Add-ins PNGATECIN and PNGATECOUT in place of the single PNGATEC Add-in, now is the time to make the switch. To do this, change the line in the Lotus Notes initialization file (notes.ini) that defines server tasks from


    ServerTasks=...,PNGATEC 
    
    to


    ServerTasks=...,PNGATECIN,PNGATECOUT 
    

  3. If you are upgrading from PMDF V5.0 (which used the image /pmdf/bin/pmdfsend to replace sendmail, rather than the new image /pmdf/bin/sendmail), then you must replace sendmail with PMDF's /pmdf/bin/sendmail. Use the following command to change the symbolic link for sendmail to /pmdf/bin/sendmail:


    # ln -s /pmdf/bin/sendmail /usr/sbin/sendmail
    

  4. If you are upgrading from PMDF V5.0 and use the SMTP server, be aware that this service is now handled by the PMDF Service Dispatcher. You must configure the PMDF Service Dispatcher to handle the SMTP server, or any other servers under its control. Dispatcher configuration is normally performed as part of the initial web-based PMDF-MTA configuration. (See Chapters 3, 5, for instructions and sample configurations.) The multithreaded POP3 and IMAP servers are handled by the PMDF Service Dispatcher. If you were previously using non-PMDF servers, or older PMDF singlethreaded servers that were 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. Dispatcher configuration is normally performed as part of the initial web-based PMDF-MTA configuration. (See Chapters 3 and 5 for instructions and sample configurations of the Dispatcher. See Chapter 4 for instructions and 5 for an example of configuring the POP and IMAP servers.)
  5. If you are upgrading from PMDF V5.0, be aware that the PMDF periodic post shell script and the PMDF return shell script (which used to be named /pmdf/bin/post and /pmdf/bin/return respectively in PMDF V5.0) are now called /pmdf/bin/post.sh and /pmdf/bin/return.sh respectively in PMDF V5.1. So, if you are upgrading from PMDF V5.0, you must change the crontab entries for these jobs to use the new names. Do this by using the following commands:


    # su pmdf
    $ crontab /pmdf/table/cronjobs
    $ exit
    

    Note

    If you want to set up site-specific cron entries manually, perform the following steps: Become the pmdf user:


    # su pmdf
    
    Edit the crontab entries by using the following command:


    $ crontab -e
    
    Use the editor to add entries similar to the following:


    30 0 * * * /pmdf/bin/return.sh >/pmdf/log/return.log-`/pmdf/bin/unique_id` 2>&1 
    0  0,4,8,12,16,20 * * * /pmdf/bin/post.sh >/pmdf/log/post.log-`/pmdf/bin/unique_id` 2>&1 
     
    
    The first value in the second line, shown as 0 in the above example, is the minutes-after-the-hour offset. If you have multiple PMDF nodes, then this is a value that you might want to stagger between different nodes. For example, 0 on one node, 10 on a second node, 20 on a third node, etc. Also note the use of log files in the above. These log files can be useful in tracking down problems with the operation of return.sh and post.sh. Make sure to exit from the pmdf user shell when you have finished adding these entries. For example,


    $ exit
    



Previous Next Contents Index