1. If you are using a compiled PMDF configuration, recompile using the following command:

   # pmdf cnbuild

2. The format of the Berkeley DB (formerly known as SleepyCat) environment files has changed since the previous version of PMDF. You must do the following. 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. 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:
   • Chapters 6 and 7 (PMDF-LAN)
   • Chapters 8 and 9 (PMDF-MB400)
   • Chapters 10 and 11 (PMDF-X400)
   • Chapters 12 through 15 (PMDF-XGS)

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

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

   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.
   • envelope
   • fileinto
   • reject
   • vacation

1. The format of the PMDF queue cache database has changed as of PMDF V6.1 from the format used in PMDF V6.0. 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 to PMDF V6.1 or later, the following files can be safely deleted. They will not be deleted automatically.

   __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

   # 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 to PMDF V6.1 or later. This command will scan the profile directory tree and build a user database.

3. The format of all PMDF Berkeley DB (formerly known as SleepyCat) databases has changed as of PMDF V6.1 from the format used in PMDF V6.0. You must convert all of these databases to the new format by using the db_upgrade utility. Note that db_upgrade changes the database in-place, so it is recommended to make 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 V6.0 Berkeley DB databases into the current format in the script /pmdf/bin/convertdb.sh which you can then check and run to do the db_upgrade commands.
   Following is a list of possible Berkeley DB database files in /pmdf directories with .db extensions:

   • /pmdf/table/aliasesdb.db
   • /pmdf/table/domaindb.db
   • /pmdf/table/from_x400.db
   • /pmdf/table/generaldb.db
   • /pmdf/table/profiledb.db
   • /pmdf/table/reversedb.db
   • /pmdf/table/to_x400.db
   • /pmdf/user/forwarddb.db
   • ~/aliasesdb.db
   • ~/.pmdf_profile.db

   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, however, 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 aliasesdb.db file in place.

1.5.3 Additional Post-Installation Tasks for Sites Upgrading From PMDF V5.2

1. 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

   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.

2. 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 commands 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:
   • /pmdf/table/aliasesdb.*
   • /pmdf/table/domaindb.*
   • /pmdf/table/from_x400.*
   • /pmdf/table/generaldb.*
   • /pmdf/table/profiledb.*
   • /pmdf/table/reversedb.*
   • /pmdf/table/to_x400.*
   • ~/aliasesdb.*
   • ~/.pmdf_profile.*

   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. Please 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 site uses the PMDF password database (not all sites do) be sure to use the new name when you are converting the password database.

1.5.4 Additional Post-Installation Tasks for Sites Upgrading From PMDF V5.1 or V5.0

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