README_VCS for Cluster Server 3.5 Update 3 for HP-UX 11i

Problem

README_VCS for Cluster Server 3.5 Update 3 for HP-UX 11i

Solution


* * * READ ME - VERITAS Cluster Server 3.5 - Patch 2 (HP-UX) * * *

                   Patch Date: October 2004
                   

  This document provides information for:

  * FIXES AND ENHANCEMENTS INCLUDED IN THIS VCS PATCH
  * FILES AFFECTED BY THIS VCS PATCH
  * INSTALLING THE VCS PATCH ON AN INACTIVE VCS 3.5 SYSTEM
  * INSTALLING THE VCS PATCH ON A RUNNING VCS 3.5 CLUSTER
  * REMOVING THIS PATCH
  * TROUBLESHOOTING
  * INSTALLING THE JAVA CONSOLE ON WINDOWS CLIENTS
  * CHANGES TO THE VCS 3.5 DOCUMENTATION


BEFORE GETTING STARTED
----------------------

This VCS Patch 2 (3.5 Update 3) is for HP-UX. You must upgrade to VCS 3.5
before applying the patch. If you are upgrading from VCS 1.3.1 Patch 3 or
lower, see the note, "AFTER UPGRADES FROM VCS 1.3.1 Patch 3 OR LOWER"
before applying the 3.5 patch.

If you are applying this patch to a VERITAS product that includes VCS as
a component, refer to the patch installation procedures for that product.

The 3.5 Update 3 release does not support a rolling upgrade in a VERITAS
clustered environment. You cannot upgrade a cluster to use the 3.5
Update 3 patches while the cluster is in operation.

The patch set includes the following:

PVKL_03618 for LLT 3.5 Patch 2
PVKL_03620 for GAB 3.5 Patch 2
PVCO_03621 for VCS and Bundled Agents 3.5 Patch 2
PVCO_03622 for Cluster Manager--Java Console Patch 2
PVCO_03623 for Cluster Manager--Web Console 3.5 Patch 2



FIXES AND ENHANCEMENTS INCLUDED IN THIS VCS PATCH
-------------------------------------------------

59018 Mount resource supports VxFS forced unmount feature. Dup. 53154.
89988 At service group level, alert on fault attribute added.
96999 Disable MyVCS in Web Console if CmdServer is not running.
103844 Application agent: clean script changed to terminate all instances
      of the process specified in MonitorProcess attribute.
102665 Change in behavior of VCS when resource faults (RFE 2 enhancement).
102680 CurrentLimit for system gets decremented when a service group with
      a persistent resource recovers from a FAULT.
105155 Check for valid owner in notifier is correct. (Dup. 115340)
105721 GAB uses same starting generation number across ports.
106237 Mount agent: VxFS VCS 3.5 now uses offline and clean.
106490 Fibre reset prevents Mount agent from getting fstyp, so unmount -f
      not run.
107846 Notifier can send mail when mail server specified is localhost.
108310 If child resource goes offline after parents fail over, VCS takes
      parents offline in correct order.
108320 Some group dependency and timing issues give consistent failover
      results.
108872 On receiving an iofence, GAB continually retries to reopen the LLT
      port.
109546 MyVCS retains users settings after log out.
111520 The Mount agent's clean script was re-organized to account for
      loopback mounts.
112243 Set default timeout for SMTP send and receive in notifier to 10
      seconds.
112673 DiskGroup agent: makes use of the vxdg noreonline option.
113094 Diskgroup agent: removed dependency on rootdg.
113318 Java GUI does not show error message when trying to offline a
      child resource.
113528 The unable_to_restart_had trigger functionality behaves as expected.
113674 GAB uses another signal instead of SIGQUIT to kill client before
      SIGKILL.
114287 Group dependencies offline local works as expected. Dup 109293.
115340 Notifier no longer tries to send mail to ResourceOwner=NULL.
115664 Engine performs dlopen call on libgab once.
116304 The modinfo command displays the full version, release, and patch
      information.
116584 Mount agent clean script includes vxumount -o force. See 106274.
116714 Agent processes show an open SIGUSR1.
118367 Mount agent offline and clean can handle exported NFS snapshots.
118831 Fix for LLT error message.
119215 IPMultiNIC no longer reports concurrency violation when cable is
      pulled.
119226 The resident size of HAD does not keep on increasing.
120806 HAD now has better equivalent priority and scheduling classes.
121584 The nfs_restart trigger now runs cleanly.
123730 HAD restart no longer leads to broken RSM and possible concurrency
      violation.
123826 Fast path works on GigE cards.
124484 Cluster Manager consoles correctly display the state of a partially
      faulted service group as faulted.
124927 Parent group comes online with an online global firm dependency.
125288 The vcsqs-nfs-wizard script detects running nfsd.
125976 Parent group with OnlineRetryLimit set as online local firm depend-
      ency comes online when parent restarts for faulted child group.
127935 A node doing REMOTE BUILD queues messages for notifier during
      broadcast queue replay.
128583 When setting some nodes for read-only and others for write
      activation with cfsdgadm, errors are reported correctly.
129884 A parent with an online global firm dependency does not come online
      after child migrates.
130991 By not using the df or bdf commands, agent scripts no longer hang
      if a disk is lost.
130362 SNMP traps get sent when the number of interfaces exceeds 16.
133629 In the cfscluster, the cfs_lib.sh now acknowledges SIGCHLD.
134725 VCS service group fails over when node loses all paths to disk.
136493 The halog trim_log_param function does not append a character array
      to a vlist.
137863 Checksum added to LLT protocol.
138178 RTT computation and reporting added to lltping.
138200 Configuring LLT over UDP with broadcast address no longer disables
      core dumps.
139069 Nservers attribute works in NFS clean.
139205 Code cleaned up for the llt_lrsrv_port.
139216 Fast path probe fixed.
139941 CurrentLimits increments correctly for preonline and autostart.
140369 Used sleep1() and wakeup1() to improve performance.
140370 LLT lock contention improvement.
140725 In some scenarios, when HAD reboots specific nodes it no longer
      dump core.
142169 A unidirectional traffic with LLT issue now performs normally.
142236 In some scenarios, FromQ and TargetCount are properly cleaned.
143716 Resolved LLT connect issues when bcasthb disabled.
143806 To keep vrfy configurable with VCS 3.5, some backporting was
      performed.
143829 For LLT over UDP, behavior is normal when disconnecting a single
      link when arp and bcast are active.
144769 The NotifierMngr agent has received some optional attributes.
145458 Improved LLT fastpath code with gigE.
145719 The lltstat -t option allows you to print out all kernel tunables.
145832 Improved LLT performance reduces the chance of delivery threads to
      miss wakeups due to a race condition.
145960 To avoid heartbeat failures, syslog() writes to the admin_msg() API.
146319 Potentially confusing message: VCS:10442:Initiating auto-start
      online of group removed.
146370 When the Share agent's Loglevel is debug, it no longer dumps core.
146722 LLT statistics are now collected per CPU.
147000 With set-arp 1 and set-bcasthb 0, cluster nodes can see each other.
147167 LLT tracking is configurable.
147240 LLT checksum level 2 is repaired.
147247 Init script now checks compatible kernel versions.
147547 Addressed a potential security flaw.
148680 Regulated number of "V-16-1-11002 Insecure Channel, please provide
      valid username and password," messages.
148737 Improved authentication for IpmServer class.



FILES AFFECTED BY THIS VCS PATCH
--------------------------------

   VRTScscm

        The entire VRTScscm package is included with the patch.

   VRTSgab

        The entire VRTSgab package is included with the patch.
   
   VRTSllt
 
        The entire VRTSllt package is included with the patch.

   VRTSvcsag

        The entire VRTSvcsag package is included with the patch.

   VRTSvcs

        The entire VRTSvcs package is included with the patch.

   WindowsClusterManager

        The entire WindowsClusterManager is included with this patch.



NOTE: AFTER UPGRADES FROM VCS 1.3.1 Patch 3 OR LOWER
----------------------------------------------------

After upgrading from VCS 1.3.1 Patch 3 or lower, you must verify the
state of GAB and LLT before installing the 3.5 patch.

To ensure that GAB and LLT are configured, do the following on each system:

1. Check the state of GAB and LLT:

# swlist -v VRTSllt | grep ^state
  # swlist -v VRTSgab | grep ^state
 
   If the system reports the states as "configured", proceed with the
   patch installation. If the system reports any state as "corrupt",
   perform steps 2 - 4 below before proceeding with the patch
   installation.
 
2. Clear "corrupt" states using the commands:

# swconfig -u VRTSllt
# swconfig -u VRTSgab
# swconfig VRTSllt
# swconfig VRTSgab
 
3. Verify that GAB and LLT report "configured" states:
 
# swlist -v VRTSllt | grep ^state
# swlist -v VRTSgab | grep ^state

4. Reboot the system.


   
INSTALLING THE VCS PATCH ON AN INACTIVE VCS 3.5 SYSTEM
------------------------------------------------------

If VCS is not running, use the following commands for the cluster:

1.  Stop GAB. On each system, type:

       # gabconfig -U

2.  Check that GAB has shut down. On each system, type:

       # gabconfig -a
 
   If the system returns no ports, GAB has stopped.

3.  Stop LLT. On each system, type:

       # lltconfig -U -o
   
4.  Check that LLT has shut down. On each system, type:

       # lltstat -n

  If the system returns no nodes, LLT has stopped.

5.  Unload GAB. On each system, type:

       # kmadmin -U gab

6.  Unload LLT. On each system, type:

       # kmadmin -U llt

7.  To confirm that GAB and LLT have unloaded, type:

       # kmadmin -s | egrep -i "gab|llt"

       The system displays UNLOADED status, e.g.:

       llt        1    UNLOADED        STREAMS Driver
       gab        2    UNLOADED        WSIO

   If GAB or LLT do not unload, see the "TROUBLESHOOTING" section
   and repeat steps 5 - 7.
   
8.  Change directory to the patch location.
   
       # cd <patch_location>

9.  Start the installation. On each system, type:

       # swinstall -s `pwd` PVKL_03618 PVKL_03620

   Since you unloaded the kernel modules (in steps 3 - 4), the
   installation of the kernel patches do not cause a reboot.

10. Continue the installation. On each system, type:

       # swinstall -s `pwd` PVCO_03621 PVCO_03622 PVCO_03623
 
11. Update the types.cf file to the new version.

       # cp -p /etc/VRTSvcs/conf/config/types.cf \
        /etc/VRTSvcs/conf/config/types.cf.orig
       # cp -p /etc/VRTSvcs/conf/types.cf /etc/VRTSvcs/conf/config/types.cf

Note: If you modified the file /etc/VRTSvcs/conf/config/types.cf, you have
to apply the same changes to the new types.cf file.  
   


INSTALLING THE VCS PATCH ON A RUNNING VCS 3.5 CLUSTER
-----------------------------------------------------

The 3.5 Update 3 release does not support a rolling upgrade in a VERITAS
clustered environment. You cannot upgrade a cluster to use the 3.5
Update 3 patches while the cluster is in operation.

1. Prepare the cluster.

  On any system, do the following:

  a. List the service groups in your cluster and their status.
   
    # hagrp -state

  b. Take the ClusterService service group offline if it is running.      

       # hagrp -offline ClusterService -sys <system>

  c. Make the VCS configuration writable.

       # haconf -makerw

  d. Freeze all service groups.

       # hagrp -freeze <service_group> -persistent

  e. Verify that service groups are frozen. On any system, type:

       # hastatus -sum

     The output of this command should show that service groups are
     frozen.

  f. Save the main.cf file with the groups frozen.

       # haconf -dump -makero

3. Stop VCS, GAB, and LLT.

  On each individual system, perform the following steps.

  a. Shut down VCS. On each system, type:

       # hastop -local
       
     If the system returns an error message and fails to shut down VCS,
     type:

       # hastop -all -force
       
  b. Check that VCS has shut down. On each system, type:

# ps -ef | grep had

     If the output indicates that HAD is not running, VCS has shut down.
       
  c. Stop GAB. On each system, type:

# gabconfig -U

  d. Check that GAB has shut down. On each system, type:

# gabconfig -a

     If the system returns no ports, GAB has stopped.

  e. Stop LLT. On each system, type:

# lltconfig -U -o

  f. Check that LLT has shut down. On each system, type:

# lltstat -n

     If the system returns no nodes, LLT has stopped.
     
  g. Unload GAB. On each system, type:

# kmadmin -U gab

  h. Unload LLT. On each system, type:

# kmadmin -U llt

  i. Check that GAB and LLT have unloaded. On each system, type:


# kmadmin -s | egrep -i "gab|llt"

      The system displays "UNLOADED" status, e.g.:

       llt        1    UNLOADED        STREAMS Driver
       gab        2    UNLOADED        WSIO

     If GAB or LLT do not unload, see the "TROUBLESHOOTING" section
     and repeat steps g - i.

4. Install the patch.

  On each system, perform the following steps.

  a. Change directory to the patch location.

# cd <patch_location>

  b. Install the patch. On each system, type:

       # swinstall -s `pwd` PVKL_03618 PVKL_03620
       # swinstall -s `pwd` PVCO_03621 PVCO_03622 PVCO_03623
 
  c. Update the types.cf file to the new version.

       # cp -p /etc/VRTSvcs/conf/config/types.cf \
         /etc/VRTSvcs/conf/config/types.cf.orig
       # cp -p /etc/VRTSvcs/conf/types.cf /etc/VRTSvcs/conf/config/types.cf

     Note: If you modified the file /etc/VRTSvcs/conf/config/types.cf, you
     have to apply the same changes to the new types.cf file.
   
5. Verify installation.

  After installation is complete, you can verify that the patch has been
  installed using two different commands on any system.
   
  a. To verify installation using swlist:
   
       # swlist | grep PV

     The following information is displayed after successful patch
     installation:

     PVCO_03621 3.5.2  Veritas Cluster Server 3.5 Patch 2
     PVCO_03622 3.5.2  Veritas Cluster Server Cluster Manager-Java Console
     3.5 Patch 2
     PVCO_03623 3.5.2  Veritas Cluster Manager 3.5 Patch 2 (Web Console)
     PVKL_03618 3.5.2  VERITAS LLT 3.5 Patch 2
     PVKL_03620 3.5.2  VERITAS GAB 3.5 Patch 2

  b. To verify installation using the swverify command.
     When using it, use the -x autoselect_dependencies=false
     flag for clean results.
   
      For example:
   
       # swverify <-x mount_all_filesystems=false>
         -x autoselect_dependencies=false <PVCO_03621>

6. Restart the cluster.

  On each system, do the following:

  a. Restart LLT. On each system in the cluster, type:

       # lltconfig -c

  b. Restart GAB. On each system in the cluster, type:

       # gabconfig -cx

  c. Verify that llt and gab are configured on all the systems and there
     is no membership jeopardy. On each system in the cluster, type:
 
       # gabconfig -a
 
  d. Restart VCS. On each system in the cluster, type:

       # hastart

  On any system, do the following:

  a. Verify all resources have been probed. On any system, type:

       # hastatus -summary

  b. Unfreeze all service groups. On any system, type:

       # haconf -makerw

       # hagrp -unfreeze <service_group> -persistent

       # haconf -dump -makero

  c. Bring the ClusterService service group online, if necessary.  
     On any system type:

       # hagrp -online ClusterService -sys <system>



REMOVING THIS PATCH
-------------------

a. Complete all the steps in "1. Prepare the cluster" and "2. Stop VCS,
  GAB, and LLT."

b. Remove VCS, GAB, and LLT patches in the following order from each
  system using the swremove command:

       # swremove PVCO_03621
       # swremove PVCO_03622
       # swremove PVCO_03623
       # swremove PVKL_03620
       # swremove PVKL_03618
 
c. Restore the original types.cf file.
       
       # cp -p /etc/VRTSvcs/conf/config/types.cf.orig \
         /etc/VRTSvcs/conf/config/types.cf

d.  Verify that the patch has been removed. On each system type:

       # swlist | grep PV

   You should not see PVCO_03621, PVCO_03622, PVCO_03623, PVKL_03620, and
   PVKL_03618 after entering the swlist command.
   
e.  Complete all the steps in "5. Restart the cluster."



TROUBLESHOOTING
---------------

When the system cannot unload LLT or GAB modules, the kmadmin command might
issue a "Device busy" message. This happens when another module is using
the LLT or GAB modules. You must unload those modules before unloading GAB
and LLT.

To see registered or loaded modules, type:

   # kmadmin -s

If the Status field displays "LOADED" for a module such as vxglm, first
unload the module using the relevant instructions in the README from that
module, and then unload LLT and GAB.



INSTALLING THE JAVA CONSOLE ON WINDOWS CLIENTS
----------------------------------------------

This patch includes an update to WindowsClusterManager, the Java Console on
Windows clients.

To upgrade the Java Console, follow the instructions in the VCS 3.5
Installation Guide. In the "Upgrading to the VCS 3.5 Java Console" on
page 86 section, follow the instructions for Windows.

To uninstall the Java Console, follow step one of the upgrade procedure.



CHANGES TO VCS 3.5 RELEASE NOTES
--------------------------------

NOTE: Page numbers cited below refer to the printed document.

     
 - New Features (page 10 to 19)

     Add the following section:
   
    Change to Default Scheduling Priority of HAD
   
    Change in Behavior: The HAD process now uses the POSIX RealTime
    priority and the SCHED_FIFO scheduling policy. Previously, the
    HAD process used the HP-UX RealTime priority and SCHED_RTPRIO
    scheduling policy. If no priority is specified, the priority
    is set by default to two less than the strongest.
   
     Add the following section:
   
The resadminwait Event Trigger
   
The resadminwait event trigger is invoked when a resource enters
ADMIN_WAIT state. See the VCS 3.5 User's Guide for more information.
     
 - New Attributes (page 17)  
 
To the list of Service Group Attributes, add:
   
FaultPropagation
       ManageFaults


 - Bundled Agents (page 18)

     To the list of Bundled Agents, add:

VRTSWebApp

   
 - Known Issues in VCS 3.5 (pages 22 to 23)
 
     Add the following sections:
     
       Configuration May Not Update with hacf -cmdtocf Command
     
       The command hacf -cmdtocf may not properly update configuration
       files with keylist attributes that are added using Configuration
       Editor. If you are modifying keylist attributes in your
       configuration files, do not use Configuration Editor. Rather, use
       Cluster Manager or the command line interface to modify the
       configuration files. If VCS is not running, use a text editor to
       modify the files.
         
     
       Monitor File May Log Warnings About Perl Locale
     
       If the locale setting for a Perl script is invalid for the system
       on which it runs, Perl generates a warning message about the
       setting. To suppress the warning, set the environment variable
       PERL_BADLANG to 0.

       VCS Oracle Agent Uses pfile for Initialization
       
       The VCS Enterprise Agent for Oracle obtains its initialization
       parameters from the pfile. If an Oracle instance is created from the
       spfile, VCS cannot monitor the instance. To obtain initialization
       parameters from the spfile, specify the path to the spfile in your
       pfile entry.

       Systems in a Cluster Must Have Same System Locale Setting
       
       VCS 3.5 does not support clustering of systems with different system
       locales. All systems in a cluster must be set to the same locale.
       
 - Software Fixes and Enhancements (page 31)
       
     For a list of software fixes and enhancements made with this patch,
     see this readme file.


CHANGES TO VCS 3.5 USER'S GUIDE
-------------------------------    
     
NOTE: Page numbers cited below refer to the printed document.


 - Service Group Attributes (pages 376 to 385)

    The following service group attributes are present in VCS 3.5 but
    not documented. They are for system use only:
ExtMonApp
ExtMonArgs
   
   
    Two new service group attributes are added with this patch.
    These are user-defined attributes:
       
       ManageFaults
               
               Type: string
          Dimension: scalar
              Scope: global
         Definition: Specifies if VCS manages resource faults for the
                     service group and if VCS calls the clean script
                     when a resource faults. This attribute value can
                     be set to ALL or NONE. Default = ALL
                     
                     If ManageFaults is set to NONE, VCS does not declare
                     the resource to be faulted or call the clean script.
                     The resource enters the ADMIN_WAIT state and the
                     administrator must intervene.
                     
       FaultPropagation
               
               Type: boolean
          Dimension: scalar
              Scope: global
         Definition: Specifies if VCS should propagate the fault up to
                     parent resources and offline the entire service group
                     when a resource faults, or if VCS should not offline
                     the group but should fail the group over only when
                     the system faults. This attribute value can be set
                     to 0 or 1. Default = 1
                     
                     If FaultPropagation is set to 1, then when a resource
                     in the service group faults:
                      - the service group is offlined if the Critical
                        attribute for the resource (or for some parent
                        resources) is set to 1
                      - the service group is failed over if the attribute
                        AutoFailover for the service group is set to 1
                       
                     If FaultPropagation is set to 0, then when a resource
                     in the service group faults, no other resources are
                     offlined, nor is the parent group offlined,
                     regardless of the value set for the attribute
                     Critical. With the attribute FaultPropagation set to
                     0, the service group does not fail over
                     
                     
 - Event Triggers (page 301)

    The following event trigger is added with this patch:
   
       resadminwait
             
           Location: /opt/VRTSvcs/bin/sample_triggers/resadminwait
              Usage: -resadminwait <system> <resource> <adminwaitreason>
                     The variable <system> is the name of the system.
                     The variable <resource> is the name of the resource
                       that has entered ADMIN_WAIT state.
                     The variable <adminwaitreason> is the reason the
                       resource entered the ADMIN_WAIT state. This
                       variable can have a value from 0 to 5, as follows:
                       0 - The offline entry point did not complete within
                           the expected time.
                       1 - The offline entry point was ineffective.
                       2 - The online entry point did not complete within
                           the expected time.
                       3 - The online entry point was ineffective.
                       4 - The resource was taken offline unexpectedly.
                       5 - The monitor entry point consistently failed to
                           complete within the expected time.
        Description: The trigger is invoked when a resource enters
                     ADMIN_WAIT state. A resource enters this state when,
                     for the service group to which it belongs, the
                     ManageFaults attribute is set to NONE and one of the
                     ADMIN_WAIT reasons described above in Usage has
                     occurred.


    Add the following section:
   
      Administrator Intervention for Resources in ADMIN_WAIT State
     
      When VCS sets a resource in the ADMIN_WAIT state, it invokes the
      resadminwait trigger with the reason the resource has entered this
      state. VERITAS recommends the following steps for resources in the
      ADMIN_WAIT state:
     
      1. Take the necessary actions outside VCS to bring all resources
         into the required state.
      2. Check if resources are in the required state by issuing the
         command
           # hagrp -clearadminwait <group> -sys <system>
         This command clears the ADMIN_WAIT state for all resources. In
         subsequent monitors, if VCS detects resources that are not in the
         required state, VCS again sets the resources in ADMIN_WAIT state.  
      3. Do one of the following:
         a. Repeat steps 1 and 2 as needed.
         b. Decide that VCS should not set the resource in ADMIN_WAIT
            state, and issue the command
              # hagrp -clearadminwait -fault <group> -sys <system>
            This command has the following result:
            - If the resource is in the OFFLINE state, then the group is
              declared to be FAULTED.
            - If the resource is in the ONLINE state, then it is declared
              as UNABLE TO OFFLINE if resadminwait was called for reason
              0, 1, 4, or 5. If resadminwait was called for reason 2 or 3,
              then the resource is declared as ONLINE.
             
 - InJeopardy Event Trigger (page 302)
 
    The InJeopardy event trigger's location path and name should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/injeopardy

 - LoadWarning Event Trigger (page 303)
 
    Remove the LoadWarning event trigger section.
   
 - PostOffline Event Trigger (page 304)
 
    The PostOffline event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/postoffline

 - PostOnline Event Trigger (page 305)
 
    The PostOnline event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/postonline

 - ResFault Event Trigger (page 305)
 
    The ResFault event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/resfault

 - ResNotOff Event Trigger (page 306)
 
    The ResNotOff event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/resnotoff
       
 - Preonline Event Trigger (page 308)
 
    The Preonline event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/preonline

 - UnableToRestartHad Event Trigger (page 309)
 
    The UnableToRestartHad event trigger's location path should read:
   
       Location: /opt/VRTSvcs/bin/sample_triggers/unable_to_restart_had



CHANGES FOR VCS 3.5 BUNDLED AGENTS REFERENCE GUIDE
--------------------------------------------------

NOTE: Page numbers cited below refer to the printed document.

 - NotifierMngr Agent (pages 37 to 40)

     On page 38, additional optional attributes should appear. These are:
     
     SmtpServerVrfyOff  boolean Setting this value to 1 results in
                                notifier not sending a SMTP VRFY request
                                to the mail server specified in SmtpServer
                                attribute, while sending emails. Set this
                                value to 1 if your mail server does not
                                support SMTP VRFY command.
                                Default is 0.
     
     SmtpServerTimeout  integer This attribute represents the time in
                                seconds notifier waits for a response from
                                the mail server for the SMTP commands it
                                has sent to the mail server. This value
                                can be increased if it is noticed that the
                                mail server is taking a longer duration to
                                reply back to the SMTP commands sent by
                                notifier.
                                Default is 10.
     
     SmtpReturnPath      string This attribute should be set to a valid
                                email address, if a custom email address
                                is desired for the Return-Path: <> field
                                in the email sent by notifier.
                                Note: If the mail server specified in
                                SmtpServer does not support VRFY, then you
                                need to set the SmtpVrfyOff to 1 in order
                                for the SmtpReturnPath value to take
                                effect.
     
     SmtpFromPath        string This attribute should be set to a valid
                                email address, if a custom email address
                                is desired for the FROM: field in the
                                email sent by notifier.

     On page 39, the type definition has changed. It is now:
     
     type NotifierMngr (
             static int RestartLimit = 3
             static str ArgList[] = { EngineListeningPort, MessagesQueue,
                                       NotifierListeningPort, SnmpdTrapPort,
                                       SnmpCommunity, SnmpConsoles,
                                       SmtpServer, SmtpServerVrfyOff,
                                       SmtpServerTimeout, SmtpReturnPath,
                                       SmtpFromPath, SmtpRecipients }
             NameRule = resource.PathName
             int EngineListeningPort = 14141
             int MessagesQueue = 30
             int NotifierListeningPort = 14144
             int SnmpdTrapPort = 162
             str SnmpCommunity = "public"
             str SnmpConsoles{}
             str SmtpServer
             boolean SmtpServerVrfyOff = 0
             int SmtpServerTimeout = 10
             str SmtpReturnPath
             str SmtpFromPath
             str SmtpRecipients{}
     )


Terms of use for this information are found in Legal Notices.

Search

Survey

Did this article answer your question or resolve your issue?

No
Yes

Did this article save you the trouble of contacting technical support?

No
Yes

How can we make this article more helpful?

Email Address (Optional)