The following is a list of tasks which must be completed following a new installation of PMDF.

1. For an initial PMDF installation, load the appropriate PMDF license by entering your license information into the appropriate PMDF license file. PMDF license information is stored in files with names of the form product-name.license , located in the PMDF table directory. You will have a separate license file for each PMDF product you have licensed for the system in question. For instance, a PMDF-MTA license would be stored in a file named /pmdf/table/PMDF-MTA-LINUX.license .
   You should have received the correct license information for your system when you licensed PMDF. A PMDF-MTA system will need a PMDF-MTA-LINUX license.
   If you will also be installing any add-on layered product such as PMDF-TLS, then for each such layered product, an additional license will be required, named, e.g., PMDF-TLS-LINUX; note that such layered products can only be licensed and installed on a system already licensed for PMDF-MTA.
   A PMDF license file has the format:

   Issuer:Process Authorization Number:auth-number Product Name:product-name Producer:Innosoft Product Release Date:release-date Product Token:token Checksum:checksum

   where auth-number , token , release-date , and checksum are specific to your PMDF license, and where product-name is a product name such as PMDF-MTA-LINUX, PMDF-MSGSTORE-LINUX, or PMDF-TLS-LINUX.
   Check that the release date for each product, i.e., the value on the fifth line of the file, is later than the release date of the current version of each PMDF product you have installed. PMDF licenses allow operation of PMDF software released before the license release date. New PMDF product licenses are issued when your maintenance contract is renewed, not when new versions of software are released.
   

2. PMDF documentation assumes that your UNIX shell process includes /usr/bin in the shell's search path, thereby making the pmdf command available in the form documented. If this is not the case, then you may either add /usr/bin to your shell's search path, or use the fully qualified command name, /usr/bin/pmdf .
   
3. Create PMDF's site specific configuration files using the automatic configuration generation utility; see Chapter 3. e.g., for a PMDF-MTA system, issue the command:

   # /pmdf/bin/http_server -s

   and then point your web browser, with JavaScript enabled, to:

   http://localhost:7633/

   Refer to Chapters 3 and 5 (PMDF-MTA regular configuration), Chapters 6 and 7 (PMDF-MTA firewall configuration), for information, step-by-step procedures, and an example configuration.
   

4. Once you have generated an initial configuration, you should take whatever additional steps may be required to complete the configuration of PMDF. The automatic configuration generator produces a check list which details any additional steps required to complete the configuration of PMDF. Make sure to look over this checklist file.
   
5. PMDF includes two shell scripts called post.sh and return.sh in the /pmdf/bin directory. You need to use cron to schedule two periodic jobs to run these shell scripts. It is recommended that the shell script post.sh be scheduled to run every four hours and that the shell script return.sh be scheduled to run at 30 minutes after midnight each day; however, you may want to schedule them differently according to the needs of your site. It is also suggested, particularly if your site includes multiple PMDF nodes, that you consider setting the minutes-after-the-hour offset at which the post.sh shell script runs to different values on different nodes to better balance mail flow. Typical scheduling for such cron jobs can be established by issuing the 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

   
   
6. Replace the sendmail system startup script with PMDF's pmdf startup script. This may be performed by issuing the command:

   # /pmdf/bin/symlink install

   Note that the effect of the /pmdf/bin/symlink may be undone by issuing the command:

   # /pmdf/bin/symlink backout

   Note If you need to set up the pmdf startup script by hand, perform the following steps: # systemctl stop sendmail # systemctl disable sendmail # systemctl enable pmdf # systemctl start pmdf

   
   
7. When installing PMDF for the first time, or after an upgrade of the operating system if that upgrade installed a new version of sendmail , you must replace sendmail with PMDF's sendmail . Note that the symlink script that you executed in the previous step will have already performed this operation. But in case you need to do it by hand, for example after an upgrade of the operating system, the steps are as follows. First save the original sendmail by renaming it to sendmail.org , and then create a symbolic link that links sendmail to /pmdf/bin/sendmail as follows:

   # mv /usr/lib/sendmail /usr/lib/sendmail.org # ln -s /pmdf/bin/sendmail /usr/lib/sendmail

   You should also kill any old, pre-PMDF sendmail processes which might exist and be accepting connections. This may also be necessary if an operating system upgrade starts up non-PMDF sendmail processes. (Note that killing such processes is not necessary after an upgrade of PMDF. Even after the first installation of PMDF or after an upgrade of the operating system, there will be no non-PMDF sendmail processes if the system has been rebooted and the previous post-installation tasks have been performed.) To see if there are any such sendmail processes, issue the command:

   # ps -ef | grep sendmail

   If there are any such sendmail processes, you will see something similar to the following:

   root 23913 1 0 Apr 05 ? 0:01 /usr/lib/sendmail -bd -q1h

   You should kill any such processes using the kill command; e.g.,

   # kill 23913

   
   

8. The multithreaded POP3 and IMAP servers are handled by the PMDF Service Dispatcher. If you were previously using non-PMDF servers 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 Chapter 3 for an example of configuring the POP3 and IMAP servers.

   Note If you are using the PMDF legacy POP or IMAP servers to Berkeley BSD mailboxes, you must make sure the protection on the /var/spool/mail directory is set to world=rwt , for example, by using: # chmod 1777 /var/spool/mail

   
   
9. Many Linux distributions are initially configured for security purposes with all ports blocked, except for a select few. In order to use PMDF for services such as SMTP, POP, or IMAP, Linux must be configured to open the related ports. How such configuration is done varies from one Linux distribution to the next. If you do not open the ports, PMDF will still start up, but will not be able to receive connections for those services. You must configure your Linux system to be able to accept connections on the ports for any PMDF services that you wish to use.
   
10. Start up the PMDF Job Controller and PMDF Service Dispatcher using the command:

    # pmdf startup

    
    

11. If you chose to install the PMDF on-line documentation, then the installation will have placed the HTML versions of the PMDF documentation under the /pmdf/doc directory. PMDF provides an HTTP server for serving out this documentation to Web browsers. To start up the PMDF HTTP server, the PMDF Service Dispatcher must be configured to handle the HTTP service, access to the HTTP server must be enabled, and then the Dispatcher must be started up (or restarted, if it was already running). The web-based PMDF-MTA configuration utility, discussed in Chapter 3 and Chapter 5, will automatically configure the PMDF Dispatcher.
    
12. The PMDF installation installs man pages. You should add the PMDF section numbers to the /etc/man.config file. That file will look something like:

    # # Default manual sections (and order) to search if -S is not specified # and the MANSECT environment variable is not set (1x-8x sections are used by # xorg packages). # MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:n:l:p:o:1x:2x:3x:4x:5x:6x:7x:8x

    You should add 1pmdf,8pmdf to the list of MANSECT, so that the file is along the lines of:

    MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:n:l:p:o:1x:2x:3x:4x:5x:6x:7x:8x:1pmdf:8pmdf

    This will enable users to use commands such as man pmdf_convertdb instead of having to specify a section as man 8pmdf pmdf_convertdb .