WebSysAdmin/DomainAdmin 2.1

Transcription

1 WebSysAdmin/DomainAdmin WebSysAdmin/DomainAdmin 2.1 System Administration within a Domain Redakteur Fujitsu Siemens Computers GmbH Paderborn Paderborn manuals@fujitsu-siemens.com Tel.: (05251) Fax: (++49) 700 / U41232-J-Z Sprachen: En Edition October 2002

2 Comments Suggestions Corrections The User Documentation Department would like to know your opinion of this manual. Your feedback helps us optimize our documentation to suit your individual needs. Fax forms for sending us your comments are included in the back of the manual. There you will also find the addresses of the relevant User Documentation Department. Certified documentation according DIN EN ISO 9001:2000 To ensure a consistently high quality standard and user-friendliness, this documentation was created to meet the regulations of a quality management system which complies with the requirements of the standard DIN EN ISO 9001:2000. cognitas. Gesellschaft für Technik-Dokumentation mbh Copyright and Trademarks Copyright 2002 Fujitsu Siemens Computers GmbH. All rights reserved. Delivery subject to availability; right of technical modifications reserved. All hardware and software names used are trademarks of their respective manufacturers. This manual is printed on paper treated with chlorine-free bleach.

3 Preface What is an administration domain? Domain administration with WebSysAdmin Standard actions Application-specific actions Integration in CA Unicenter TND Integration in Tivoli Reliant UNIX specifics Solving problems Appendix I Continued

4

5 Appendix II Abbreviations Index

6

7 Contents 1 Preface Target groups Notational conventions What is an administration domain? Advantages of administration domains The domain-wide administration system Installing WebSysAdmin/DomainAdmin Installation from the console (desktop) Installation at command level Installation on LINUX systems Secure Sockets Layer (SSL) Installing public and private keys Login procedure Failure of secure communication Creating a secure domain for WebSysAdmin Creating a self-signed user certificate for WSA The administration desktop Administration desktop requirements Windows PC with web browser Windows PC with Windows application Solaris system with VGA screen or LAN console Restrictions Domain administration with WebSysAdmin Features of WebSysAdmin Starting WebSysAdmin Starting WebSysAdmin as a local Windows application Starting WebSysAdmin under Solaris Starting WebSysAdmin using Java Web Start Troubleshooting Require dialog language Elements of WebSysAdmin Menubar and toolbar Setting preferences Selection configurator Hierarchical browser Object table Standard actions Create U41232-J-Z

8 Contents 4.2 Modify Delete Clone Application-specific actions "Domain" application Modifying the communication name of the management server Creating a general domain Creating enterprise server type domains Moving nodes or management servers Creating nodes or management servers Creating CF cluster SNMP Setting up the communication structure Use MIB browser on SNMP nodes "VConfig" application Domain-wide file system access Importing an NFS file system Dynamic Reconfiguration (DR) Boards tab Hardware presentation tab DR actions Restrictions Hardware presentation Changing the position of a cabinet in the rack Identifying the cabling between a SCSI controller and the disk addon "RMS" application Troubleshooting "Diagnostics" application System diagnosis General troubleshooting Event and reaction definitions "Software" application Checking software versions Checking the packages for consistency Integration in CA Unicenter TND Overview Splitting the functionality for integration purposes Integration in the CA Unicenter TND framework version Functionality of the World View 2D map Functionality of the World View 3D map Functionality of the Enterprise Manager console U41232-J-Z

9 Contents 6.3 Integration in the full version of CA Unicenter TND Displaying the status of components in the system Object View View Node MIB Browser Properties View Agent Event Browser SNMP information: Interpretation, implementation and special features System object ID Handling SNMP traps in a framework installation Handling SNMP traps in a full version of CA Unicenter TND Integration in Tivoli WebSysAdmin for Tivoli Overview Software requirements Installation Dependencies on other Tivoli products Installation from the command line Installation via the Tivoli desktop Deinstallation Configuration WebSysAdmin collection for Tivoli The Setup_TEC_for_WSA job The Config_SNMP job The Unconfig_SNMP job The Config_SNMP_local job The Unconfig_SNMP_local job TEC classes for WebSysAdmin TEC rules for WebSysAdmin Testing aids What to do if...? WebSysAdmin for Tivoli NetView Overview Software requirements Installation Dependencies on other Tivoli products Installation on Windows NT Installation on Sun Solaris Deinstallation on Windows NT Deinstallation on Sun Solaris Configuration U41232-J-Z

10 Contents Integration in the NetView IP map MIB and event integration Further WebSysAdmin menu calls Definition of a WebSysAdmin collection WSA event configuration for Tivoli NetView TEC class for WSA events from Tivoli NetView Testing aids What to do if Reliant UNIX specifics Virtual disks (Vdisks) Creating virtual disks (vdisks) Creating local vdisks on a node Configuring vdisks on shared resources Solving problems Problems with the browser or WSA Performance problems Appendix I MIB file wsatrap.mib Events/SNMP traps Appendix II Configuring the SNMP EMANATE master agent SNMP agent architecture within WebSysAdmin Security mechanisms for SNMP Extended security mechanisms in SNMPv Configuration steps Configuration file snmpd.cnf Definition of access to the agent via SNMPv1 requests Definition of access to agent via SNMPv3 requests Definition of access to an agent via HTTP requests Definition of the trap targets Example Configuring the EMANATE master agent for WebSysAdmin Configuring the EMANATE agent for CA Unicenter integration. 256 Abbreviations Index U41232-J-Z

11 1 Preface This manual describes how several nodes can be bundled in an administration domain and thus managed jointly. This is possible using a domain administration system, in this case the DomainAdmin 2.0 product. Users are given access to the essential functions of this administration system by means of the WebSysAdmin (WSA = Web based System Administration) user interface. This manual deals less with DomainAdmin itself, than with using DomainAdmin via the WSA user interface for managing the systems in an administration domain. 1.1 Target groups This manual is written primarily for system administrators and field engineering staff. Sound operating system and hardware knowledge is required as well as familiarity with the basics of the WebSysAdmin graphical user interface. 1.2 Notational conventions The following notational conventions are used in this manual. italics Denote names of commands, system calls, functions, files, procedures, programs etc. as well as menu options and input/output fields from figures in the main body of text. Name (extension) Commands, system calls, functions, files, interfaces etc., are given an extension in brackets if manual pages are available for them. The extension indicates the chapter in which the manual page is described. You can show the manual pages on the screen with the man [see man(1)] command. See the manual command for man itself for information about using this command. To do this, enter man man. fixed-pitch font Indicates system output, such as error messages, messages, notes, file excerpts and program examples. fixed-pitch semi-bold font Denotes user input in examples. U41232-J-Z

12 Notational conventions Preface Ê Indicates activities to be carried out by the user. I Highlights additional information that should be noted to assist understanding of the surrounding text passages. V Indicates the possible risk of data loss. 2 U41232-J-Z

13 What is an administration domain? Advantages of administration domains 2 What is an administration domain? An administration domain is a group of nodes that are linked via a network and managed jointly. This chapter provides more detailed information about: The advantages of an administration domain. The administration system on which this administration domain is based (operating system and administration domain database). The advantage of a single administration desktop from which the entire administration domain can be managed. Specific requirements for operating an administration desktop within a domain. 2.1 Advantages of administration domains The setting up of an administration domain offers improvements in many respects: Single point of administration All nodes in a domain are supported jointly from a single administration desktop and need no longer be operated individually from the respective system console. Extensibility An active node including all its resources can be inserted in or removed from the administration domain at any time. Transparency Because an administration domain appears to a user like a single system (single system view), a cluster of nodes can be administered in the same way as a single operating system. Regardless of the node on which the system administrator has started the user interface, he or she can access the disk storage and other peripherals anywhere in the administration domain at any time for the purpose of administration and configuration. U41232-J-Z

14 Advantages of administration domains What is an administration domain? Maintenance/troubleshooting The logbooks for all nodes in the administration domain can be evaluated from a central desktop. Furthermore, the Logging diagnostics system can be configured specifically for each node from a central desktop. The diagram below attempts to clarify the advantages of an administration domain Figure 1: Example of an administration domain with an administration desktop (WSA client) This administration domain comprises five nodes. The five nodes are connected to one another via TCP/IP (Ethernet). Communication is enabled on this basis for administration purposes. The entire computer network is managed from a single administration desktop (single point of administration) via the WebSysAdmin (WSA) user interface. There must be at least one management server within the administration domain (it is better to have two available for reasons of failsafe performance), which contains the domain information (Node No. 2 and No. 4 in the example). If WebSysAdmin is started on a management server, all nodes in the administration domain can be administered from one point. The five nodes appear to the system administrator like a single system (single system view). 4 U41232-J-Z

15 What is an administration domain? Advantages of administration domains A new feature compared with older versions of WebSysAdmin is the possibility to structure and manage not just one but a number of domains using WebSysAdmin 2.1 in conjunction with the licensed DomainAdmin 2.1 product. This administration structure is referred to as a hierarchical administration domain. As with UNIX file systems, a hierarchical structure of sub-domains can be created starting from a root domain. The root domain corresponds here to the root directory, the individual domains to the directories and the nodes to the files in a UNIX directory structure. The next figure shows this type of hierarchical domain structure: Figure 2: Example of a hierarchical domain structure Two general domains Domain1 and Domain2 are mounted below the root domain. Domain1 contains two nodes ("Node1" and "ManagementServer1") as well as a further sub-domain of the type EnterpriseServer with the two nodes ("Partition1" and "Partition2"). Domain2 contains three nodes ("Node3", "Node4" and "ManagementServer3") as well as a further sub-domain of the type High Availability (HA) with the three nodes ("Node2", "ManagementServer2" and "SNMPagent"). Further domains can be added, deleted, unmounted or renamed based on this hierarchical principle. U41232-J-Z

16 The domain-wide administration system What is an administration domain? 2.2 The domain-wide administration system The WebSysAdmin 2.1 graphical user interface can be used to administer individual nodes. However, if there are several systems to be administered at the same time in one or more domains, the licensed DomainAdmin V2.1 product must be installed on all nodes in the administration domains being set up. Cross-system administration can then be started if LAN connections exist to other systems, however a WebSysAdmin installation must be available on every system Installing WebSysAdmin/DomainAdmin WebSysAdmin 2.1 can be installed on PRIMEPOWER systems in two ways: 1. from the graphical console (desktop) 2. at command level In addition, the installation procedure for LINUX systems is slightly different Installation from the console (desktop) Proceed as follows to install WebSysAdmin 2.1 (see end of section for information on Reliant UNIX): Ê Insert the CD-ROM in the drive of the PRIMEPOWER system. The File Manager window opens automatically showing the contents of the CD-ROM: Figure 3: File Manager window of the CD-ROM Control CD 6 U41232-J-Z

17 What is an administration domain? The domain-wide administration system Ê I You will find further details about the individual components on the CD-ROM by clicking the icon for the README documents. Double-click Installer and then click the Next button until the following screen appears: Figure 4: Installation screen for the CD-ROM Control CD The WebSysAdmin 2.1 component is installed by default. If you want to administer a number of systems in a domain, you have to select the licensed DomainAdmin 2.1 component for installation. If you also want to perform a CA Unicenter or Tivoli integration, you have to select the EMANATE Master agent component for installation as well. I Only DomainAdmin need be installed under Reliant UNIX. The licensed DomainAdmin product is contained on the current system CD and is called CD-SYS-MI_1; it is a component of the Reliant UNIX 5.45 CD set. The product is installed with SYSADM. The Reliant UNIX Operation manual describes how to install an add-on product with SYSADM. To install the components, keep clicking the Next button until the installation is complete. U41232-J-Z

18 The domain-wide administration system What is an administration domain? Ê Once the installation is complete, remove the CD-ROM by choosing File Eject in the menubar of the File Manager window. Once you have installed the necessary components from the Control CD system CD, you can use the domain-wide administration system via the graphical user interface. I All Solaris systems with ADDON-CDs 1.5 and higher and all Reliant UNIX systems with V5.45 B00 and higher are supported as administered systems under WebSysAdmin 2.1. Domain Admin 2.1 must be installed on these systems for this purpose Installation at command level Ê Ê Ê Ê Ê Ê Ê Insert the CD-ROM in the drive on the PRIMEPOWER system. Log on as user root. Execute the following command: # cd /cdrom Now change to the root directory, generally cdrom0: # cd cdrom0 Start the Installer program by executing the following command: #./installer -nodisplay The following text appears: Welcome! Trying to launch the CLI. Please wait... Now simply follow the next instructions. When the installation is complete, use the following command to open the drive again: # eject Installation on LINUX systems Ê Ê Ê Insert the CD-ROM in the drive on the PRIMERGY system. Log on as user root. Execute the following command: # mount /cdrom 8 U41232-J-Z

19 What is an administration domain? The domain-wide administration system Ê Now execute the following command: # cd /cdrom Ê Start the Installer program by executing the following command: #./installer -nodisplay The following text appears: Welcome! Trying to launch the CLI. Please wait... Ê Now simply follow the next instructions. Ê When the installation is complete, cancel the mount operation: # umount /cdrom Ê Open the drive again using the following command: # eject U41232-J-Z

20 The domain-wide administration system What is an administration domain? Secure Sockets Layer (SSL) WebSysAdmin uses the SSL protocol to provide a secure enhancement to the standard TCP/IP protocol. The secure socket layer is added between the transport layer and the application layer of the standard TCP/IP protocol stack. SSL-based communication between all components uses public/private key based authentication on the basis of X509 certificates. Communication using SSL begins with an exchange of information between the client and the server. This exchange of information is called the SSL handshake Installing public and private keys Only one public/private key pair must be installed for each user who wishes to log on to WebSysAdmin. The public and private keys have to be installed on the different types of systems involved in the WebSysAdmin communication as follows: 1. Managed nodes These nodes only need the public key of the WebSysAdmin login user to be installed in a dedicated directory, which is only accessible by privileged users (e.g. root). This directory only contains a file with the public key in the form of a certificate in X509 format. I In this way, the corresponding WebSysAdmin user, i.e. the owner of the public key, is assigned root access rights on this node as required to perform system administration and configuration tasks with WebSysAdmin. It must therefore be guaranteed that the public key's installation directory has restrictive access rights (e.g. like the system's /etc directory). The installation base directory is /opt/smaw/.cert. I This must be performed manually for existing domain configurations during the upgrade to the secure WebSysAdmin version. 2. Management servers These nodes need both keys: the public key to be installed as indicated above and the private key to be installed in the subdirectory.cert_private of the home directory of the WebSysAdmin login user. The latter is only readable by privileged users (e.g. root) or the respective user. Furthermore, the private key file is password-protected. The management server needs the private key files, since it must authenticate itself to managed nodes during DomainAdmin communication. 10 U41232-J-Z

21 What is an administration domain? The domain-wide administration system 3. Management station The user s private and public key has to be installed on the management station (i.e. the requesting node). The installation directory is predefined: the relevant path under Windows is C:\wsa_certs\$USERNAME and under UNIX is /opt/smaw/wsa_certs/$username. It is only readable by a privileged user or the respective user and is password-protected. Java accepts so-called keystore files that contain both the certificate and the private key. The keystore files are password-protected and may be stored in standard PKCS#12 format Login procedure The previous login procedure in WebSysAdmin prompts the user name and the password of the user who wants to login in to WebSysAdmin. The user name and password supplied must be the same as the UNIX ID of the management server that the user wants to log on to. The login procedure is now enhanced such that the user additionally supplies the PEM password of the private key file: Figure 5: Dialog box for login with SSL The GUI uses this password to read the private key file of the given user from the local management station. This private key file is used to authenticate the user of this management station to the management server using the SSL handshake protocol mentioned above. When the connection has been established, the GUI sends the private key password to the management server so that the private key file can be opened on the management server side. I The private key file on the management server side is used to authenticate the management server to the managed nodes. U41232-J-Z

22 The domain-wide administration system What is an administration domain? Since communication between the management station and the managed node uses SSL, the private key password is sent via a secure connection. This only works if the private key files on the management server and on the management station match. Following the login procedure, communication between the management station and the management server is safe and the management server has all the information it needs to establish SSL-based communication with the managed node, when requested. This can be seen from the icon to the lower left that now shows a closed lock: Figure 6: Icon for SSL connection If the connection is not secure, the lock will be open Failure of secure communication This section describes some cases in which secure communication is not possible. This means that no communication is established between the WebSysAdmin components involved. 1. The managed node does not contain the public key in the dedicated user's directory If this node is already part of a DomainAdmin domain (for example as a result of using older WebSysAdmin versions), this node will be grayed out (inactive) in the user interface. Communication with this node is not established. 2. The management server has no private key This means the management server is not able to authenticate itself to the managed node. Such a management server cannot be used. A login to this management server using WebSysAdmin over an SSL connection is not possible. 3. The management server has no public key for the login user The user is not able to log on to the management server. This user must not use this server for managing the domain. 12 U41232-J-Z

23 What is an administration domain? The domain-wide administration system 4. The user interface tries to connect to a management server without using SSL If the respective management server has SSL software installed, this login is rejected Creating a secure domain for WebSysAdmin The system administrator has to perform a number of steps on the relevant systems in order to create a secure administration domain. These steps are as follows: 1. Consider the number of clients, servers and agents in your domain. 2. Consider the number of users who are to be granted access rights. 3. Create the necessary certificates and keys for every user on one of the management servers. Every user should receive his/her own certificate, PEM certificate and key. This can be done step by step (see section Creating a self-signed user certificate for WSA on page 14) or by executing the command /opt/smaw/smawssl/bin/mk_key -i. 4. Distribute the WSA_cert.pem certificate and the "*.0" hash file over a secure path to all agent systems (including the management server) that are to be administered (/opt/smaw/.cert/$user directory). 5. Distribute the WSA_key.pem private key, certificate and hash files on a secure path to all other server systems that are to be allowed to administer the domain ($HOME/.cert_private directory). 6. Distribute the wsa_cert.p12 client certificate on a secure path to all clients that are to be given authorization to access these domains (opt/smaw/wsa_certs/$user or C:\wsa_certs\$USER directory). 7. Start WebSysAdmin and create the administration domain. Consider the following restrictions: Keys and certificates must be distributed manually and required root authorization on all systems. The domain should then be created in WebSysAdmin. It is not permitted to mix secure and non-secure agents. Non-secure clients can no longer access domains once they have become secure. U41232-J-Z

24 The domain-wide administration system What is an administration domain? Creating a self-signed user certificate for WSA The openssl program is a command interface tool for using the different cryptography functions of OpenSSL s crypto library from the shell level. It can be used for: Creating RSA, DH and DSA key parameters Creating X.509 certificates, CSRs and CRLs Note: The next procedure uses the $HOME shell variable. It should therefore be executed in the user s environment if possible. 1. Create the private key: If /dev/urandom is available, the private key should be created using the following command: /opt/smaw/smawssl/bin/openssl genrsa -des3 -out \ $HOME/.cert_private/WSA_key.pem 2048 If /dev/urandom is not available, the private key should be created using the following command: /opt/smaw/smawssl/bin/openssl genrsa -des3 -out \ $HOME/.cert_private/WSA_key.pem -rand \ /opt/smaw/smawwsas/conf/prngsock 2048 /opt/smaw/smawwsas/conf/prngsock is an alternative random generator, which is installed as long as /dev/urandom is not available. 2. Creating the self-signed root certificate: Enter the following command: /opt/smaw/smawssl/bin/openssl req -new -x509 -days 730 \ -key $HOME/.cert_private/WSA_key.pem -out \ $HOME/.cert_private/WSA_cert.pem The -days option describes the number of days until the certificate expires. The root certificate also has to be copied to /opt/smaw/.cert/$user. 3. Indexing the certificate subject name: The subject names of the certificates are used in OpenSSL to form an index in which all certificates can be searched for by their subject names. Execute the following commands: cd /opt/smaw/.cert/$user 14 U41232-J-Z

25 What is an administration domain? The administration desktop ln -s WSA_cert.pem `openssl x509 -hash -noout -in \ WSA_cert.pem`.0 4. Create a PKCS12 file for the GUI: The pkcs12 command allows PKCS#12 files (sometimes also referred to as PFX files) to be created and parsed. PKCS#12 files are used by a number of programs, including Netscape, MS Internet Explorer and MS Outlook. Execute the following commands: cd /opt/smaw/.cert/$user /opt/smaw/smawssl/bin/openssl pkcs12 -export -in \ WSA_cert.pem -inkey WSA_key.pem -out wsa_cert.p12 The following files must be created finally: $HOME/.cert_private/WSA_key.pem $HOME/.cert_private/WSA_cert.pem /opt/smaw/.cert/$user/wsa_cert.pem /opt/smaw/.cert/$user/[hash.0] -> WSA_cert.pem /opt/smaw/.cert/$user/wsa_cert.p The administration desktop Each operating system has a system console. Apart from system configuration, this console is used to report events that affect the node administration. In general, these are system messages that require intervention by a system administrator. It is not necessary for the system administrator in an administration domain to monitor several nodes at the same time. There is just one single administration desktop in an administration domain for monitoring and configuration purposes. From the user s perspective, an administration domain is like a single uniform system. The administration desktop is not logically assigned to any particular node, rather always physically to one node. When we speak of central administration, this does not simply mean displaying and reacting to messages, rather the entire administration of this domain is carried out on one desktop. U41232-J-Z

26 The administration desktop What is an administration domain? The WebSysAdmin user interface The WebsysAdmin graphical user interface is the user interface on the administration desktop. This user interface is supplied as standard with the operating system. Following installation of DomainAdmin, not only is it possible to have a local view of the system, but also a domain-wide view of all systems. The WebsysAdmin management desktop offers several advantages for operating domains: Quick overview of the entire administration domain Possibility to perform the same activities on several nodes with one single action Secure access to shared resources Easy access to operations that would otherwise only be feasible with complex commands Administration desktop requirements Specific requirements must be fulfilled in order to operate the administration desktop or the WebSysAdmin client. It is important here to determine whether the desktop is a Windows PC or a VGA console on a Solaris system. If the desktop is a Windows PC, a further distinction must be made as to whether you want to work with a web browser or with a Windows application. The prerequisite for this is a Java runtime system JRE Windows PC with web browser The administration desktop should be a PC system with a 500-MHz Pentium III processor and 256 MB RAM, which is connected to the LAN. A minimum screen resolution of 1024x768 is required for the Windows PC in order to represent all of the information displayed legibly. The operating systems supported are Windows 95, 98, ME, 2000 and Windows NT 4.0. The supported browsers are Netscape Communicator from version 4.6 to version 4.75 or Internet Explorer U41232-J-Z

27 What is an administration domain? The administration desktop A virtual Java machine (JRE 1.4 or JVM 2 as it is also known) is required on the client. If such a machine is not available, an installable version can be downloaded into a selected directory from the server when WebSysAdmin is started by following the instructions given. The virtual Java machine is active once the browser has been installed and restarted Windows PC with Windows application The administration desktop should be a PC system with a 500-MHz Pentium III processor and 256 MB RAM, which is connected to the LAN. A minimum screen resolution of 1024x768 is required for the Windows PC in order to represent all information displayed legibly. The operating systems supported are Windows 95, 98 and Windows NT 4.0 as well as Windows 2000 and Windows ME. The Windows applications can be downloaded from the URL For example: I WebSysAdmin must be installed already on the server hostname. The self-extracting files are installed in the Program menu when they are executed and can be accessed via the Start button in the task bar. A virtual Java machine (JRE 1.4 or JVM 2 as it is also known) is required on the client. If such a machine is not available, an installable version can be downloaded into a selected directory from the server when WebSysAdmin is started by following the instructions given Solaris system with VGA screen or LAN console Assuming you have installed WebSysAdmin 2.1 as described in the section Installing WebSysAdmin/DomainAdmin on page 6, the graphical user interface can be executed directly on a screen on the Solaris system with no further steps necessary. The operating systems supported are Solaris 2.6, Solaris 7, 8 or 9. U41232-J-Z

28 The administration desktop What is an administration domain? Midrange systems (e. g. PRIMEPOWER200) as well as enterprise servers (e. g. PRIMEPOWER2000) are supported as servers. If the graphical interface has to run on a LAN console, you also have to install the LAN console software. The installation is performed as described in the section Installing WebSysAdmin/DomainAdmin on page 6 from the System Management CD, only that in this case the LAN Console component must also be selected for installation (see figure 4 on page 7). I The Java Runtime System 1.4 does not use a color depth of 16 bits on an X server. As a countermeasure, you have to set the X server configuration to a color depth of 24 bits or 8 bits. The main memory requires at least 256 Mbytes of RAM. You will find further details in the X server documentation Restrictions The SNMP manager is not supported for Solaris 2.6. The RCI interface must be initialized, even if no external cabinets are connected. I All hardware errors reported by the system before then should no longer be visible in WebSysAdmin following initialization of the RCI interface. Older PW systems are displayed as PP models. The node name must be changed using the Rename function offered by the Domain application. Otherwise, WebSysAdmin has to be deinstalled and then re-installed. If an enterprise server partition is removed from a domain during a shutdown, the EPMC cluster on this node must be removed with the clos_adm R command. If more than one enterprise server system is connected to the SMC, the FDEs are typically located in a virtual PRIMECENTER rack (because it is not possible to establish which FDEs belong to which hardware). The assignment has to be performed manually following the installation. 18 U41232-J-Z

29 3 Domain administration with WebSysAdmin Domains are administered using the WebSysAdmin user interface. This chapter provides more detailed information about: The user interface in general Starting the user interface The individual elements of the user interface 3.1 Features of WebSysAdmin WebSysAdmin is a web-based user interface for performing system administration. Compared to system administration at command level, this interface is easy to use and allows administration to be performed efficiently even in the case of large system networks. WebSysAdmin currently contains the following standard components: Domain Hierarchical administration domains can be managed with the Domain application. VConfig This component contains functions for configuring and managing the hardware both for a single node as well as for a number of nodes in an administration domain. Furthermore, support is also provided for managing storage devices, multipath device files, file systems and virtual disks. User Management This component offers functions for managing users and groups, for example creating, modifying and deleting user and group definitions or managing user passwords. Diagnostics The Diagnostics component offers functions for domain-wide evaluation of log data, for monitoring as well as for administering the log system itself. U41232-J-Z

30 Features of WebSysAdmin Domain administration with WebSysAdmin Process This component provides an overview of the status of processes currently being executed and allows them to be deleted, if appropriate. Software This component enables management of the installed software packages (Unix packages) and patches on all nodes in a domain or on a local node. Tasks The Tasks component allows the user root to manage task definitions both for a local node as well as for all nodes in a domain. Task definitions correspond to cron jobs and thus entries in the crontab file of the user root. RMS The RMS component provides information on RMS configurations and on the associated cluster nodes and clusters. The view is restricted to the display of available cluster structures. In addition to these standard components, various so-called "third-party" applications, such as ESCoD, Server View or RC Admin can be integrated optionally. These applications will not be described in any greater detail here. Because the user interface is self-explanatory, the components can be used intuitively to a large extent. Should questions arise nevertheless, the integrated help texts provide possible answers. For this reason, the explanations below are purposely kept short and concise and are restricted to the essential elements. 20 U41232-J-Z

31 Domain administration with WebSysAdmin Starting WebSysAdmin 3.2 Starting WebSysAdmin WebSysAdmin can be started in two ways: 1. As a locally installed Windows application (Solaris also) 2. Using Java Web Start The local Windows application has the advantage of local access rights and ServerView integration (recommended). This approach requires that the WebSysAdmin.exe application has first been downloaded from a server. WebSysAdmin as a Java Web Start application has the advantage that each subsequent time WebSysAdmin is called, the latest version is always downloaded from the server. Java Web Start itself offers two other possibilities for starting WebSysAdmin: Via the Web Start application manager Via a link that may have been created beforehand in Web Start For further information, see the section Starting Java Web Start repeatedly on page 25. In addition, WebSysAdmin can be operated in two different access modes: Either for opening an application in write mode or in read mode. There are no complications if you simply open an application in read mode. However, if you try to open an application in write mode and this application is already opened for writing by another user, you are prompted to open the application in read mode instead. This means that an application can only be opened once for writing by one user. This restriction does not apply in read mode. I If you can only open an application in read mode on a management server, this restriction also applies at this time for all other management servers currently in the administration domain. U41232-J-Z

32 Starting WebSysAdmin Domain administration with WebSysAdmin Starting WebSysAdmin as a local Windows application Enter the following in the URL line to download the WebSysAdmin application: e. g.: Once you have downloaded the WebSysAdmin application, you can execute and install it like any Windows application. The user interface is loaded when WebSysAdmin is started and the welcome screen appears on your monitor. Choose the desired dialog language and continue as described in the section Require dialog language on page Starting WebSysAdmin under Solaris To start the user interface in write mode, enter the following at command level: # /opt/smaw/bin/wsa [ snc] hostname e.g.: /opt/smaw/bin/wsa spinlock.pdb.fsc.net I The -snc option suppresses display of the image on the welcome screen and thus speeds up the startup process in the case of slow network connections [cf. wsa(1m)]. To invoke the user interface in read mode only, enter the following: # /opt/smaw/bin/wsa readonly hostname The welcome screen then appears and you continue as described in the section Require dialog language on page 31 (language setting, choice of application component, password). 22 U41232-J-Z

33 Domain administration with WebSysAdmin Starting WebSysAdmin Starting WebSysAdmin using Java Web Start Ê Ê Start your browser. If you want to invoke the user interface via Java Web Start and in write mode, make the following entry in the URL line: e.g.: If you want to invoke the user interface via Java Web Start and in read mode only, enter the following: You can also invoke the user interface via Java Web Start, entering the following: Then click the WebSysAdmin or WebSysAdmin (read only) link on the download page. A splash screen is started first, which shows that Java Web Start has been invoked: Figure 7: Java Web Start: Splash screen U41232-J-Z

34 Starting WebSysAdmin Domain administration with WebSysAdmin The next window informs you about the download procedure: Figure 8: Java Web Start: Download procedure When the download is complete, a window opens with a security warning: Figure 9: Java Web Start: Security warning 24 U41232-J-Z

35 Domain administration with WebSysAdmin Starting WebSysAdmin Now press Install in order to start WebSysAdmin. Starting Java Web Start repeatedly If WebSysAdmin has already been started at least once via Java Web Start, you will find it in the Java Web Start application manager. To display WebSysAdmin click View Downloaded Applications in the menubar: Figure 10: Java Web Start: Application manager You can now start WebSysAdmin from the application manager by clicking Start. U41232-J-Z

36 Starting WebSysAdmin Domain administration with WebSysAdmin If WebSysAdmin is started a second time via Java Web Start (and only then!), a window appears offering the option of creating a shortcut for the WebSysAdmin application on the desktop or in the Start menu: Figure 11: Java Web Start: Desktop integration Once you have created a link in the Start menu or on the desktop, you can use this shortcut in the future to start WebSysAdmin. If possible, Java Web Start always loads the application from the cache and at the same time performs a background check on the server for updates. If there are updates present, the user is informed in a window and the update is loaded automatically at next startup: I If WebSysAdmin has been started with Java Web Start, the text Java Web Start Window appears in the status bar. 26 U41232-J-Z

37 Domain administration with WebSysAdmin Starting WebSysAdmin Troubleshooting If Java Web Start cannot download an application from the server, the following window opens: Figure 12: Java Web Start: Download error Press the Details button for further information: Figure 13: Java Web Start: Download error message containing details This error message can be understood as follows. During installation of WebSysAdmin, the codebase URL is replaced by hostname (e. g. codebase= " are two possibilities for avoiding this problem: 1. Configure your proxy server by navigating to the relevant dialog box in the Java Web Start menubar (cf. figure 10 on page 25) via File Preferences General and set Manual. U41232-J-Z

38 Starting WebSysAdmin Domain administration with WebSysAdmin 2. Replace the localhost parameter for the IP address of the local host in every../smaw/public_html/*.jnlp file on the server side. Java Web Start will be able to function properly once you have performed this configuration. Java Web Start and SSL Because Java Web Start does not provide WebSysAdmin with local access for security reasons, the following actions lead to error messages: Running WebSysAdmin with SSL Printing Starting an administration program for SNMP devices The error messages contain a reference to how you can allow the listed actions. The error messages for the three actions are listed below with possible solutions: Figure 14: Java Web Start: No access to certificate You can resolve the access violation in relation to the certificate as follows: 1. Start the <JREHOME>/bin/policytool.exe program (e. g. in the DOS window or via Start Run in the task bar). You can establish the path name of the Java Runtime System JREHOME by starting Java Web Start and then navigating to the list of Java runtime versions (Command column) in the menubar via File Preferences Java. You can ignore the error message in relation to a missing java.policy file in your profile directory. I If a number of Java runtime systems are listed in the Command column, you have to select the ones that comply with Version U41232-J-Z

39 Domain administration with WebSysAdmin Starting WebSysAdmin 2. Open the java.policy file via File Open in the menubar of the tool (path <JREHOME>/lib/security/java.policy). 3. Double-click the <All> entry in the codebase. 4. Click the Add permission button. 5. Choose FilePermission from the list with access permissions. 6. Enter c:\\wsa_certs\\root\\wsa_cert.p12 (note double backslashes!) as the target name. 7. Choose read from the action list. 8. End the selection by pressing the Ok button. 9. Exit the dialog box by pressing Done. 10.Quit the tool after you have saved the new configuration with File Save in the menubar. 11.Start WebSysAdmin again. Figure 15: Java Web Start: No access to print service You can resolve the access violation in relation to the print service as follows: 1. As above for certificates. 2. As above for certificates. 3. As above for certificates. 4. As above for certificates. 5. Choose RuntimePermission from the list with the access permissions. 6. Enter queueprintjob as the target name. 7. Not applicable here. 8. As above for certificates (Ok). U41232-J-Z

40 Starting WebSysAdmin Domain administration with WebSysAdmin 9. As above for certificates (Done). 10.WAs above for certificates (Save). 11.As above for certificates (Restart). Figure 16: Java Web Start: Security error in administration program You can resolve the access violation in relation to the administration program as follows: 1. As above for certificates. 2. As above for certificates. 3. As above for certificates. 4. As above for certificates. 5. Choose FilePermission from the list with the access permissions. 6. Enter C:\\browser.pth as the target name. 7. Choose read, write from the action list. 8. Enter the path of your web browser as the target name (e. g. C:\\Program Files\\Internet Explorer\\IEXPLORE.EXE). 9. Choose execute from the list of actions. 10.As above for certificates (Ok). 11.As above for certificates (Done). 12.As above for certificates (Save). 30 U41232-J-Z

41 Domain administration with WebSysAdmin Starting WebSysAdmin 13.As above for certificates (Restart) Require dialog language The welcome screen appears on your monitor as soon as you start WebSysAdmin. Choose the required dialog language (default = English) under Language on the menubar and then click one of the application components to the bottom left. A dialog box appears and the welcome screen now looks as follows: Figure 17: Welcome screen for WebSysAdmin in write mode: Domain component selected Enter the root password. You can now start domain administration. U41232-J-Z

42 Elements of WebSysAdmin Domain administration with WebSysAdmin 3.3 Elements of WebSysAdmin The following diagram shows an example of a window for the VConfig component, after you have entered the root password: Figure 18: Example: Window for VConfig component I You will know that the DomainAdmin add-on product is installed, because system information is displayed for several of the nodes below the root domain on the left side of the hierarchical browser (see the section Hierarchical browser on page 35). If DomainAdmin were not installed, only a single system would be displayed and the root domain would be called "root". 32 U41232-J-Z

43 Domain administration with WebSysAdmin Elements of WebSysAdmin The window comprises the following elements: Menubar and toolbar You can execute various functions from the menubar and toolbar. Some of the actions are dependent on the context and cannot always be executed. Actions that cannot be executed in a particular context are grayed out on the screen. Menubar Toolbar Action File Print object list Edit Export object End session Cut object View Copy object to clipboard Insert object from clipboard Set preferences; see section Setting preferences on page 34 Refresh display read in all data again Application Start applications Applicationspecific Create object menu (the selected tab appears each Modify object Delete object time, e.g. Nodes) Clone object Other possible application-specific actions Help Contents and Index About WebSysAdmin Select objects; see section Selection configurator on page 35 Cancel selected object; see section Selection configurator on page 35 Terminal load process U41232-J-Z

44 Elements of WebSysAdmin Domain administration with WebSysAdmin Setting preferences You are offered the Preferences option under Edit in the menubar: Figure 19: Window for setting preferences This action allows you to set a default time for reloading the data and thus updating the display. The next dialog box gives you the option of performing a refresh automatically, after pressing one of the two buttons (update display) or (cancel object selection), or after a short delay. Let us take a practical example of the latter option of the delayed refresh. When you make a multiple selection in the hierarchical browser (see section Hierarchical browser on page 35) it often makes sense not to update the display immediately, rather only when all objects in the list are selected. A delay time of five seconds was therefore set for example in the next dialog box: Figure 20: Example of a dialog box for setting preferences You will find further details in the help text for the Preferences action. 34 U41232-J-Z

45 Domain administration with WebSysAdmin Elements of WebSysAdmin Selection configurator The toolbar also offers a selection configurator, which you can use to find objects using the search algorithm for regular expressions and operators. The search output can be restricted as a result. Figure 21: Example of a selection configurator Hierarchical browser The hierarchical browser serves as a navigation aid, which you can use to select the entire administration domain individual nodes or also individual hardware components (the latter only in the VConfig application). Depending on what you select, the object list (see section Object table on page 39) will show the objects for the entire administration domain, the selected node or the selected hardware component. I You can select several components by also holding down the CTRL or Shift key as you press the left mouse button. U41232-J-Z

46 Elements of WebSysAdmin Domain administration with WebSysAdmin Figure 22: Example of a hierarchical browser in an administration domain: standard view There are four buttons in the lower part of the hierarchical browser that you can use to change the view of the displayed objects. Standard Display of domain structure. I You can only execute actions if you have selected this structure. The other structures are purely for information purposes. Cluster Display of existing HA cluster structures. Shared Display of existing shared group structures. Types Display of type structures. The following types are defined: Enterprise, Linux, Reliant UNIX, SNMP and Solaris. Meaning of the selected icons in the hierarchical browser: Root domain. General domain without type specification. Enterprise server type domain. High availability type domain. CF cluster. SNMP agent. 36 U41232-J-Z

47 Domain administration with WebSysAdmin Elements of WebSysAdmin The node is a management server. Additional status displays: A node in a domain is not available. Object icon is highlighted in green The object is available. Object icon is grayed out The object is not available at present, because it has been powered down, for example. Yellow dot The object is faulty. It can remain in service for the moment but should be replaced at an appropriate time. Red dot The object is defective and must be replaced. Red-black dot The object is defective and must be replaced. It will be deactivated the next time the system starts up (currently only under Reliant UNIX). Black dot The object is deactivated. Black-yellow dot The object is still deactivated. It will be activated again the next time the system is started, but is faulty (currently only under Reliant UNIX). Black-green dot The object is still deactivated. It will be activated again the next time the system is started and is fault-free (currently only under Reliant UNIX). Ochre dot An SNMP agent on this node has sent a message. U41232-J-Z

48 Elements of WebSysAdmin Domain administration with WebSysAdmin Object table The object table comprises the following areas: The upper area comprises the tab bar with the specific objects. The type and number of tabs depends on the application selected. Figure 23: Example of a tab bar ( VConfig application) The object list appears below the tab bar. The type and number of objects displayed depends on the tab or sub-tab selected (see below) as well as on the selections made in the hierarchical browser and selection configurator. Figure 24: Example of an object list ( VConfig application) The first column in the object list shows the same information about the status of the individual objects as in the hierarchical browser (see above). I The lower area may contain a sub-tab bar. Whether or not it is displayed as well as the type and number of sub-tabs offered depends on the tab selected. Figure 25: Example of a sub-tab bar 38 U41232-J-Z

49 4 Standard actions Standard actions in WebSysAdmin refer to repetitive activities in relation to objects, which depending on the tab selected arise in practically all applications. Four actions are involved here Create Modify Delete Clone Because these four standard actions are similar in a technical sense in all applications, they are presented below using the example of the User Mgmt. (User Management) application. Apart from the four standard actions listed, some applications also offer actions that can be described as advanced standard actions. These include actions, which allow more detailed specification of simple standard actions, such as Create. The File systems tab of the VConfig application offers such an advanced standard action: Figure 26: Example of an advanced standard action Special features, such as these advanced standard actions, are considered in the next chapter on page 51 using various examples. Application-specific actions that go beyond the simple standard actions are introduced there. These application-specific actions can be recognized by the fact that they are offered below the separator in addition to the standard actions. The next figure shows the standard actions together with the specific actions of the User Management application, tab bar Users: U41232-J-Z

50 Create Standard actions Figure 27: The four standard actions of WSA with the two specific actions of the User Management application Following on from the four standard application actions, the two specific actions of the User Management application, namely Show logins and Change password are offered. 4.1 Create The first and basic action of any application is the creation of an object. This action creates a new user in the User Management application or adds users to those already created. In order to add a user to an administration domain, click the User Mgmt. icon in the welcome screen (see figure on page 31) after WSA has been started; if you had already started WSA and you are currently accessing a different component, click Application on the menubar and choose the User Mgmt. application in the sub-menu. You are then shown an object list with all users who have been created on the node or in the domain. I When you click the Name column header, you can influence the order in which user names are displayed (in ascending or descending alphabetical order). There are two equally appropriate possibilities for creating a new user. You can either click the User Mgmt. entry in the menubar and choose the Create function in the sub-menu or click the button (create object) in the toolbar. 42 U41232-J-Z

51 Standard actions Create You are then shown a dialog box and can fill in the fields as you require: Figure 28: Example of a dialog box for creating a new user The domain in our example comprises two nodes, i.e. goraiko and zeit, as the Node entry to the top right in the figure indicates. The goraiko node is selected and a new user abraham is to be created on this node. The remaining input fields are blank or the defaults are copied over, such as the user id (107). A short entry has only been made in the comment field. U41232-J-Z

52 Create Standard actions When you have filled in the dialog box and confirmed with Ok, the new user s home directory is prompted: Figure 29: Dialog box querying the home directory when creating a new user You can generally answer Yes to this query. This completes the entire action and an Ok message is issued: Figure 30: Example of an Ok message for creating a new user The new abraham user is created on the system and entered in the object list of users with its attributes: Figure 31: Object list with new user (excerpt) I Only the first 1000 users are ever listed in the object list. If there are more than 1000 users, a relevant warning is issued. A newly created user is also not displayed in an object list with more than 1000 entries, if (as in our example) it would have to appear at the very beginning alphabetically. This new user can only be found in this case by performing a search using the selection configurator (see the figure on page 35) on the toolbar. 44 U41232-J-Z

53 Standard actions Modify I If an action uses several different parameters, these will generally be divided among different tabs. In this example, the parameters of the Create user action are split between the Main and Password tabs (see figure Example of a dialog box for creating a new user on page 43). 4.2 Modify There are two equally appropriate possibilities for changing the attributes of an existing user. You must first select the relevant users in the object list (click with the left mouse button) so that the line appears in blue (inverted). You can then either click the User Mgmt. entry in the menubar and choose the Modify function in the sub-menu; or select and then click the user with the right mouse button and then choose the Modify function in the sub-menu; or simply double-click the user name (without selecting it first). I Double-clicking an object generally invokes the Modify action even if the object cannot be changed in any way (exception: Diagnostic application). The first approach is shown in the next figure: Figure 32: Sub-menu for modifying a user I The Modify function is not represented via a button in the toolbar. U41232-J-Z

54 Modify Standard actions In this example, a secondary group is selected for the user abraham, to which this user can also belong in addition to the primary group. The secondary group sysadmin is selected, which must be moved to the secondary group list on the left using the Add button: Figure 33: Example of a dialog box for modifying a user 46 U41232-J-Z

55 Standard actions Delete You can then look at the result of the change in the object list on the Groups tab. The user abraham is now also a member of the secondary group sysadmin : Figure 34: Object list with modified user (excerpt) 4.3 Delete There are three equally appropriate possibilities for deleting a user from a domain. You first select the relevant user in the object list (click with the left mouse button) so that the line appears in blue (inverted). You can then either click the User Mgmt. entry in the menubar and choose the Delete function in the sub-menu; or click the button (delete object) in the toolbar; or select and then click the user with the right mouse button and then choose the Delete function in the sub-menu. U41232-J-Z

56 Delete Standard actions The second approach is shown in the next figure: Figure 35: Sub-menu for deleting a user Two dialog boxes then follow with confirmation prompts to which you answer Yes each time: Figure 36: First dialog box confirming the deletion of a user Figure 37: Second dialog box confirming the deletion of a user The deleted user is then no longer in the user s object table. I A user cannot be deleted globally from all nodes in a domain rather only individually on the respective node. It is possible, however, to delete several users on a node in one action, assuming the appropriate selection is made. The confirmation prompt prior to deletion then refers to the actual overall selection. 48 U41232-J-Z

57 Standard actions Clone 4.4 Clone Cloning a user means copying a previously created user including his or her attributes to other nodes in a domain. There are two equally appropriate possibilities here. You first select the relevant user in the object list (click with left mouse button), so that the line appears in blue (inverted). You can then either click the User Mgmt. entry in the menubar and choose the Clone function in the sub-menu; or select and then click the user with the right mouse button and then choose the Clone function in the sub-menu. The second approach is shown in the next figure: Figure 38: Sub-menu for cloning a user I The Clone function is not represented via a button in the toolbar. U41232-J-Z

58 Clone Standard actions When you have selected the user to be cloned and the Clone function, you then have to select the other nodes in the domain to which the user is to be copied in the next dialog box: Figure 39: Example of a dialog box for cloning a user When you confirm the dialog box with Ok, the user abraham is copied to the two nodes post and wait. There is no Ok message. You can check if the action was successful in the object list of users in the main window. It is only in the event of an error that a relevant message is issued. I If the user id of a user being cloned is already assigned on a different node, cloning is not possible for this node. An error message is issued to this effect. 50 U41232-J-Z

59 5 Application-specific actions Application-specific actions in WebSysAdmin were described in general in the chapter Standard actions on page 41 as those actions that are offered in any application in addition to the four possible standard actions Create, Modify, Delete and Clone. These specific actions are obviously very different depending on the application and tab and have very little commonality. The next sections therefore only provide examples of some selected actions from individual applications. Of the standard applications, examples were selected from Domain VConfig RMS Diagnostics Software Actions that can be defined as typical for the respective application were chosen largely. 5.1 "Domain" application Hierarchical administration domains can be managed with the Domain application. Hierarchical administration domains are structured the same way as file directories, as are familiar, for example, from UNIX. A hierarchical administration domain comprises a root domain, below which any number of domains and nodes can be mounted. The root domain thus corresponds to the root directory, the individual domains correspond to the directories and the nodes to the files in the UNIX directory structure. There must be at least one management server in hierarchical domains (it is better to have two available for reasons of failsafe performance). Only one management server contains the hierarchical information. I You should note that WebSysAdmin is started on a management server. This is the only way you can manage the entire hierarchical administration domain. U41232-J-Z

60 "Domain" application Application-specific actions The next examples assume a starting position of zero where no nodes are configured and WebSysAdmin is being started for the first time. You will be informed step-by-step of how to do the following: Possibly modify the communication name of the management server Create an initial domain below the root domain Create enterprise server type domain Move a management server within a domain Create a node or a a second management server in a domain I If you are not using SSL, the Domain application creates a wdmadm user with a default password on all participating nodes. This password can be changed with the User Mgmt. application by choosing the Change password action Modifying the communication name of the management server The first time WebSysAdmin is started following installation, the domain is created automatically and a node is created as a management server in this domain. The communication name assigned to this management server (in other words an alias name that can be used to address the node in the network), is the name supplied with the uname command (e. g. "mach1"). If administration is handled via an alternative LAN, the communication name for the node mach1 must be changed before the domain is created. The Modify communication name action is provided for this purpose on the Administration hierarchy tab in the Domain application. This action allows you to change the communication name of the automatically created management server. When you start the Modify communication name action, a dialog box appears with a selection list of all IP addresses configured on the system and their associated communication names. Having selected the desired address and exited the dialog box with Ok, the password must be entered in a second dialog box. If this dialog box is likewise exited with Ok, the system checks whether the password is correct. If it is correct, the communication name and the IP address are changed. All WebSysAdmin communication levels continue to communicate via this IP address. 52 U41232-J-Z

61 Application-specific actions "Domain" application I You can assign the communication name of an alternative LAN in the Create node (cf. figure 49 on page 60) dialog box to create additional nodes. The Communication name input field, which is filled by default with the name supplied with the uname command, can be edited. The system checks whether the communication name entered can be resolved as an IP address and enters this in the Communication address field. Once the node has been created, all WebSysAdmin communication layers then use this IP address to communicate. It is not possible to retrospectively change the communication names of nodes that exist already. If a different communication name is to be used for a node, this node must be deleted and created again with the new communication name Creating a general domain The following examples assume a starting position of zero: You have a number of nodes you want to configure in a hierarchical domain but have not yet started any action (except perhaps you have changed the communication name). Your first step is to start WebSysAdmin (for example on a node called "discover-smc") and invoke the Domain application. The hierarchical browser and the object list appear as follows: Figure 40: Example of a root domain with an automatically created management server The root domain is shown to you in the hierarchical browser with the default name domain. The only node you see is the node "discover-smc", i.e. the node on which you started WebSysAdmin. This node is created automatically as the management server, since there must be at least one management server available with the database for the hierarchical domain. You will find further details about this first node in the object list to the right of the hierarchical browser. U41232-J-Z

62 "Domain" application Application-specific actions Once the root domain is available with a management server as a basis, you can create further domains hierarchically. To do this, start the relevant action by choosing Administration hierarchy Create Domain, as illustrated in the next figure: Figure 41: Sub-menu for creating a general domain The following dialog box opens where you have to enter the name and type of the new domain: Figure 42: Example of a dialog box for creating a domain The new domain below the root domain is called "Headquarters" in our example and is a general type domain. This is the default type; another possible domain type is explained in the next section. 54 U41232-J-Z

63 Application-specific actions "Domain" application I The following restrictions apply for domain and node names in a hierarchical domain: Node names must be unique throughout the domain. Node names may only contain the characters "a-za-z0-9" as well as the minus sign and the underscore. Domain names must be unique within their parent domain. Domain names may include the characters "a-za-z0-9" as well as the minus sign and the underscore; a maximum of 20 characters is permitted Creating enterprise server type domains The type of domain depends on the type of node. If the node is an enterprise server, you have to create a domain specially of this type. To do this, using the left mouse button select the domain in the hierarchical browser under which the new domain is to be created and start the relevant action by choosing Administration hierarchy Create Create Enterprise Server, as illustrated in the next figure: Figure 43: Sub-menu for creating an enterprise server type domain U41232-J-Z

64 "Domain" application Application-specific actions Two related dialog boxes then open. In the first dialog box, you have to enter the name of the system management console (this is the name shown to you with the uname -n command) as well as the corresponding root password: Figure 44: Example of a dialog box for creating an enterprise server type domain (part 1) 56 U41232-J-Z

65 Application-specific actions "Domain" application You access the second dialog box by pressing the Continue button: Figure 45: Example of a dialog box for creating an enterprise server type domain (part 2) In the Machine field in this dialog box, choose the enterprise server whose partitions are displayed in the underlying table. When you have made your choice, press the Finish button. You then have to enter the root password(s) for the enterprise server s partitions in a further dialog box. Figure 46: Example of a dialog box for the root password of a partition for creating an enterprise server type domain U41232-J-Z

66 "Domain" application Application-specific actions The enterprise server has three partitions in our example, called "discover-0", "discover-1" and "discover-3". There is therefore a corresponding dialog box for the root password of the second and third partition. When all dialog boxes have been filled in, the new enterprise server domain with the name "discover" is inserted at the selected position in the hierarchical tree (in our example this is below the "Headquarters" domain) Moving nodes or management servers Once you have created the first general "Headquarters" domain as well as the "discover" enterprise server domain, you can perform a further action and move the "discover-smc" management server created in the very first step from its original position below the root domain to the "Headquarters" sub-domain. This brings the console closer to the monitored system so that a software check can be performed, for example, by clicking the common parent domain. Select the node to be moved in the hierarchical browser or object list with the left mouse button and open the relevant dialog box from the menubar by choosing Administration hierarchy Move or by pressing the right mouse button and choosing the Move option offered to you. When you have selected an action, a dialog box is opened where you can specify a new mountpoint: Figure 47: Example of a dialog box for moving a node The "discover-smc" management server is moved in our example from the "domain" root domain to the "Headquarters" sub-domain. The new position is displayed in the hierarchical browser. 58 U41232-J-Z

67 Application-specific actions "Domain" application Creating nodes or management servers We showed in the previous steps how a general domain was created first in the initially "empty" root domain followed by a domain of the type enterprise server. In a further step, the automatically created management server was moved to a different position. The last example assumes that a second general domain has been created with a node in the same way as the first general domain. This second general domain is called "Office". A second management server is now to be created in this sub-domain. This action is necessitated by the requirement for a hierarchical domain to always contain more than one management server. Because all management servers have equal access to all administration information in the hierarchical domain, the availability of several management servers guarantees that in the event of one failing the hierarchical domain can remain functional on the basis of the other management server(s). I You can define 64 management servers at most for each hierarchical domain. In order to create a node or a management server, left click the required domain in the hierarchical browser and start the relevant action by choosing Administration hierarchy Create Node UNIX: Figure 48: Sub-menu for creating a UNIX node U41232-J-Z

68 "Domain" application Application-specific actions Once you have initiated this action, the following dialog box opens where you can enter the attributes for the new UNIX node: Figure 49: Example of a dialog box for a node or a management server The individual fields have the following meaning: Node name You enter the system name of the UNIX node in this field. This is the name shown to you with the uname -n command. Password You enter the root password of the UNIX node in this field. Communication name You define the alias name in this field under which the node is addressed in the network. This field is assigned the node name itself by default. However, you can specify the name of a different Ethernet controller configured on the node. Mgmt server You define in this field whether the UNIX node is to be a management server. In our example, you have to select Yes. 60 U41232-J-Z

69 Application-specific actions "Domain" application Comment You can enter any comment in this field. When you have terminated the action with Ok, the new management server with the name "OfficeServer" is created in the "Office" sub-domain. You now see the result of your previous steps in the hierarchical browser, thus for example: Figure 50: Example of a hierarchical tree with several domains You have created a hierarchical domain with two general domains, i.e. "Headquarters" and "Office". The "Headquarters" domain contains the enterprise server type domain "discover". There are two management servers in the two general domains called "discover-smc" and "OfficeServer". I Once you have created the domains and nodes, additional one-off configuration steps may be necessary. It is possible for a node to contain pieces of hardware whose location cannot be established by WebSysAdmin, for example a rack cabinet and SCSI devices. No position is shown for these parts, rather the position must be established explicitly with the VConfig application on the Hardware Presentation tab (see section Changing the position of a cabinet in the rack on page 95 and section Identifying the cabling between a SCSI controller and the disk add-on on page 100). I A default password is supplied for the domain administrator. This should be changed immediately for security reasons. U41232-J-Z

70 "Domain" application Application-specific actions Creating CF cluster A CF cluster (Cluster Foundation) is the basic communication layer for RMS (Reliant Monitor Software). The "Create CF Cluster" function can be used to integrate an existing CF cluster in the WebSysAdmin administratin domain. The figure Example of how a local cluster structure is displayed on page 105 shows a CF cluster called MUSICAL with the two cluster nodes "express" and "starlight". We will show below how you can integrate this CF cluster. In order to integrate the CF cluster, select the root domain in the hierarchical browser with the left mouse button and start the relevant action by choosing Administration hierarchy Create CF Cluster, as shown in the next figure: Figure 51: Sub-menu for creating a CF cluster 62 U41232-J-Z

71 Application-specific actions "Domain" application A dialog box then opens containing two pages. First to page one: Figure 52: Dialog box for creating a CF cluster (first page) The fields on the first page should be filled as follows: Node Name Enter the system name of a node in this field, which is part of the cluster being imported. This is the name displayed with the uname -n command. Password Enter the root password for the node in this field. Communication Name Define the alias name in this field under which the node will be addressed in the network. This field is filled by default with the node name itself. However, you can specify the name of a different Ethernet controller configured on the node. U41232-J-Z

72 "Domain" application Application-specific actions Communication Address Ê This field cannot be edited. The IP address is established automatically in accordance with the communication name. Once you have successfully entered the relevant details on this page, you can activate the second page by pressing the Continue button. WebSysAdmin now analyzes the CF cluster and shows you all cluster nodes as well as the cluster consoles in the next dialog box. Figure 53: Dialog box for creating a CF cluster (second page) The fields on the second page should be filled as follows: Cluster Name The name of the cluster to which the specified node belongs is displayed in this field. Domain Name You can specify a name in this field under which the cluster will appear in the hierarchical tree. The cluster name is used here by default. 64 U41232-J-Z

73 Application-specific actions "Domain" application Cluster Nodes The cluster nodes are displayed in this table. System Consoles The system consoles for the cluster are displayed in this table. Having exited the dialog box with Finish, you have to specify the root passwords of the cluster nodes and the system consoles, which are not yet available in the administration domain. You do this in dialog boxes that are automatically opened in succession. In our example, first for the cluster node "express", then for the second cluster node "starlight": Figure 54: Dialog box for creating a CF cluster node After you have filled all dialog boxes, the CF cluster is imported and is displayed in the hierarchical browser. An important message follows, however, in a message window, to the effect that you still have to configure the SNMP agents on all (in the example: two) cluster nodes: Figure 55: Message window after creating a CF cluster node U41232-J-Z

74 "Domain" application Application-specific actions The imported CF cluster is shown as follows in the hierarchical browser: Figure 56: Example of a hierarchical tree when a CF cluster has been created You proceed as follows in order to configure the SNMP agent on the two cluster nodes, as reminded in the message window (figure 55 on page 65). Switch to the VConfig application. Select the first cluster node "express" in the object table, press the right mouse button and choose the action Modify SNMP Agent Configuration: 66 U41232-J-Z

75 Application-specific actions "Domain" application Figure 57: Sub-menu for changing an SNMP agent configuration An edit box opens and you proceed here as described in the section Configuring the EMANATE master agent for WebSysAdmin on page 250. I You can use the edit box to configure all cluster nodes in a single action, assuming the same configuration is to be available on all nodes. U41232-J-Z

76 "Domain" application Application-specific actions SNMP SNMP (Simple Network Management Protocol) is a standard protocol for the management in heterogeneous networks. It is used under WebSysAdmin for monitoring non UNIX nodes that support SNMP. SNMP is a manager/agent-based protocol. The manager can query the status of the agent with a get request or set the status with a set request. The agent uses traps to inform the manager asynchronously of important events. An SNMP agent is represented in the hierarchical browser by a blue icon and a trap by an ochre colored dot (see section Hierarchical browser on page 35) Setting up the communication structure The communication structure between senders and recipients of traps is set up in three steps. There are two variants of the first step depending on whether you 1a) create an entry for an SNMP agent or 1b) have the SNMP node searched for automatically in the LAN. Step 1a In the first step, you create an entry for an SNMP agent in the database of the monitoring node. You then change to the Domain application, select the domain in which the SNMP entry is to be made and choose the Administration hierarchy option to start the action Create Node SNMP: Figure 58: Sub-menu for creating an SNMP entry 68 U41232-J-Z

77 Application-specific actions "Domain" application A dialog box is opened where you enter the attributes for the new SNMP entry: Figure 59: Example of a dialog box for creating an SNMP entry The individual attribute fields have the following meaning: SNMP Manager You specify the node in this field on which the SNMP entry is to be created. The node will always be a management server, other types are not offered for selection. This management server handles communication with the new SNMP node. Agent Name The alias name for the IP address of the SNMP agent can be entered in this field. When you specify an alias name, the system tries to establish the IP address automatically so that no input is required in the Agent Net Address field. If the IP address cannot be established, the specified alias name does not exist. When you have exited the dialog box with Ok, the alias name is assigned the suffix _SNMP. This makes it easier to distinguish between an SNMP entry in the hierarchical browser and a UNIX node. U41232-J-Z

78 "Domain" application Application-specific actions Agent Net Address You can specify the IP address of the SNMP agent in this field. When you specify an IP address, the system tries to establish the alias name automatically so that no input is required in the Agent Name field. If no alias name is found, the IP address is likewise entered in the Agent Name field. URL You can specify a web address in this field, which is to be called when the Start SNMP URL action is invoked. For example, you could specify the web address here for managing the SNMP agent. Agent Type You can specify any search criterion in this field. The search criterion is appended in brackets to the alias name (can be seen in the hierarchical browser). I If the MIB-II variable SysObjID is entered in the Agent Type field, the value of the field is compared with a set of SNMP traps that are preconfigured in WebSysAdmin. If an SNMP type with the identical SysObjID is found, the SNMP node is represented in the interface with an icon that is specific for this type. A specific management application may then also be preconfigured (see URL). Comment You can enter any comment in this field. Quotes are not permitted. When you have created the SNMP entry, you will see the result both in the hierarchical browser and in the object list. In our example, an SNMP agent called viola_snmp can now be found under the discover-smc management server: Figure 60: Example of a hierarchical browser and an object list with SNMP agents 70 U41232-J-Z

79 Application-specific actions "Domain" application A daemon and filter are active on the SNMP manager, which controls the monitoring by receiving and processing traps. The daemon starts and ends the monitoring while the filter receives the incoming traps. Step 1b You can have the SNMP nodes searched for automatically in the LAN in this step. Switch to the Domain application and start the Create Node Discover Snmp Nodes action via the Administration hierarchy menu option. Figure 61: Sub-menu for searching for an SNMP node After the selected menu option has been clicked, a dialog box opens in which the following entries have to be made: An SNMP community that will be used during polling. The domain node (a management server), which will act as an SNMP manager for the identified SNMP nodes. A list of subnet addresses to be searched for, in the form xxx.xxx.xxx.0, where xxx are octal digits in the range 0 to 255. This dialog box works as follows: First, the type of SNMP search must be selected. Two types can be distinguished: 1. Search for subnets where the subnets are searched through on the basis of the SNMP node and 2. Search for ServerView nodes, where the ServerView configuration of the client is read. U41232-J-Z

80 "Domain" application Application-specific actions Figure 62: Dialog box for searching for an SNMP node The subnet identification works as follows: The Add button is activated once a correct subnet address has been entered. The subnet address is added to the list of subnets being sought by clicking the activated Add button. If the list is not blank, the Discover and Remove are activated. Clicking the Remove button deletes the selected subnet from the list of subnets. Clicking the Discover button starts the search. The figure shows the status of the dialog box after clicking the Discover button. Only the Cancel and Help buttons are still active. In addition, a small text appears showing the address areas just examined. The search process is terminated by pressing Cancel. This may take a while because the GUI has to wait until the process has actually ended. If the system has already found nodes, these are displayed for further processing. 72 U41232-J-Z

81 Application-specific actions "Domain" application The selection of the ServerView search deactivates all subnet-related components in the dialog box. The Discover button is activated immediately. The ServerView configuration of the ServerView management software is read by clicking Discover and the list of managed nodes is displayed as located nodes. I This only works if the node on which the GUI is running is also the ServerView manager. If there is no ServerView configuration available locally, an error message is displayed. If the search process ends normally or is terminated and nodes have already been found, the following dialog box is displayed. Figure 63: Dialog box with SNMP parameters This dialog box shows all identified SNMP nodes. The attributes displayed include the IP address, agent name (the IP address is likewise displayed here if the name could not be resolved by the Name Service) and MIB-II variable SysObjID, which contains the SNMP type information for this node. The user can choose whether or not to add (click) the selected node to the domain by ticking the checkbox in the first column. All nodes can be selected by clicking Select All and the selection cancelled by clicking Deselect All. All selected SNMP nodes are added to the domain by pressing Ok. The SysObjID field is used to set the AgentType field of the respective SNMP node. The setting of fields for all SNMP object components is self-explanatory. It may take a while to add the node but the dialog remains displayed until the node is added. The name of the node being added is shown in a short message. The add process is aborted by clicking Cancel after Ok. All nodes added up to this point remain in the domain and the dialog box is closed. By immediately pressing Cancel, the dialog box is deleted from the screen. U41232-J-Z

82 "Domain" application Application-specific actions Step 2 In the second step when setting up the communication structure, you should prepare the filter such that not all traps are received indiscriminately, rather only specific messages that are required by you. In order to prepare an SNMP filter in accordance with your requirements, you have to change first to the VConfig application. You then start the Edit SNMP filters action on the Nodes sub-tab SNMP tab: Figure 64: Sub-menu for editing the SNMP filter A dialog box is then opened where you can change the SNMP filter for the different SNMP managers: 74 U41232-J-Z

83 Application-specific actions "Domain" application Figure 65: Example of a dialog box for changing the SNMP filter To change the SNMP filter, you have to first select a node in the SNMP manager field. All filter entries located for this node are then shown in the table below. When you select a line, the entries are taken over from the table columns to the underlying input fields. You can modify the values here (as in the example) or transfer them to the table using the Add or Modify buttons. A trap filter only permits traps that comply with the filter conditions, where the asterisk (*) stands for all. You can delete the selected entry with the Remove button. If you switch to a different SNMP manager, changes made previously are preserved. The changes only come into effect when you exit the dialog box with the Ok button. U41232-J-Z

84 "Domain" application Application-specific actions Step 3 Finally, in the third step when creating the communication structure, you simply have to start the daemon on the monitoring UNIX node to start (or also stop) the actual monitoring process. You do this using the Modify Status of SNMP Demons action: Figure 66: Sub-menu for changing the SNMP daemon A dialog box then opens where you can influence the behavior of the trap recipient daemon on the different management servers: Figure 67: Example of a dialog box for changing the SNMP daemon 76 U41232-J-Z

85 Application-specific actions "Domain" application All management servers in the domain, on which the SNMP package is installed, are listed with the current daemon attributes in a table in the top half of this dialog box. When you select a line, the entries are taken over from the table columns to the underlying input/output fields. Changes in the last of these two fields are taken over directly to the table. The changes only come into effect, however, when you exit the dialog box by pressing Ok. Demon Auto Start You can define in this field whether (yes) or not (no) the trap receive daemon on the relevant SNMP manager is to be started automatically when the system starts. Teleservice You can define in this field wether (yes) or not (no) the received trap should be passed to Teleservice. Action You can define in this field whether (start) or not (stop) the trap receive daemon is to be started or stopped respectively when you exit the dialog box with Ok, or whether no action is to be taken in this regard when you exit the dialog box (none) Use MIB browser on SNMP nodes The MIB browser is started by selecting an SNMP node in the Vconfig node list and clicking the Start MIB Browser menu option in the sub-menu. Figure 68: Sub-menu for starting the MIB browser U41232-J-Z

86 "Domain" application Application-specific actions The following window is displayed. The MIB structure of the MIBs installed on the SNMP manager of the selected node is shown on the left. The snmpd.dat file of the SNMP manager is read for this purpose and evaluated. The user can navigate through the entire MIB structure. When a node in the structure is selected, the corresponding OID is entered in the text field with the name Oid. The relevant information is displayed for this MIB structure for the selected SNMP node by clicking Read Information. The community name of the Community text field is used for this process. Text can be entered directly in both fields. Figure 69: MIB browser window for a node The values of the MIB variables can continue to be read until the user presses the Ok button. The window then disappears from the screen. 78 U41232-J-Z

87 Application-specific actions "VConfig" application 5.2 "VConfig" application VConfig is the application with the most objects to be administered. A glance at the tab bar shows all components at once: Figure 70: VConfig tab bar Typical examples of the File systems, Dynamic Reconfiguration (can be found on the Boards tab) and Hardware Presentation tabs are presented below Domain-wide file system access WebSysAdmin offers all nodes in the domain the option to access a file system. This section uses an NFS file system to show how this can be managed in a few simple steps. The following tasks are to be performed in this example: An entry should be made on all systems for the file system in the /etc/vfstab file. The file system should be mounted immediately. The system should also be mounted automatically when this system reboots. I In order to enable domain-wide access to an NFS file system, the relevant resource must first be exported on the NFS tab Importing an NFS file system To import an NFS file system, you have to: Ê Ê Ê Change to the File systems tab (VConfig application). Click the File systems option on the menubar. Now choose the Import network file system option, sub-option Nfs. U41232-J-Z

88 "VConfig" application Application-specific actions Figure 71: Example of a selection menu for importing file systems 80 U41232-J-Z

89 Application-specific actions "VConfig" application The following dialog box is displayed: Figure 72: Example of a dialog box for importing an NFS file system Fill in the dialog box as displayed in the diagram above: Ê Ê In the NFS node field, enter the node on which the file system being imported is located (in the example: OfficeServer). In the NFS path field, enter the path of the file system being imported on the specified node (in the example: /export/documents). U41232-J-Z

90 "VConfig" application Application-specific actions Ê Ê Ê Ê I When importing an NFS file system, you can specify both a node name and NFS node path, which do not belong to the domain. In the Nodes list, select all systems that are to receive access to the NFS file system (in the example: Partition1 and Partition2). The options Autom. mount at boot (controlled by the entry in the /etc/vfstab file) and Immediate mount are executed by default and thus lead to the actions required in the example. In the Mountpoint field, you can enter a pathname, which is to be used as the mount point for the NFS file system. The same pathname is used for all selected nodes (in the example: /office_documents). This can subsequently be modified separately for each individual node. All other fields are already assigned default values, which can be copied over here. Click Ok to exit the dialog box. As a result of the previously described actions, the imported NFS file system on the selected node is displayed in the object list on the Usage parameters sub-tab: Figure 73: Example of an object list with imported NFS file system I The search criterion docu was specified with the selection configurator to reduce the number of objects displayed. The NFS file system (in the example: /export/documents) is thus available to all selected NFS clients in the domain with the access rights defined in the dialog box (see figure 72 on page 81). 82 U41232-J-Z

91 Application-specific actions "VConfig" application Dynamic Reconfiguration (DR) Dynamic reconfiguration allows you to add and remove system boards on PRIMEPOWER enterprise servers to and from partitions immediately or at next reboot. System boards are displayed in the VConfig application in the hierarchical browser and in the object table of the Boards tab. Both views display "unused" system boards and their onboard components ("unused" means any DR status other than "configured"). All unused components (available for DR) are marked by black colored dots. In contrast to the red colored dots indicating hardware errors, these black dots are not propagated up the tree to the top (see figure below). System boards available for DR are displayed for each partition to which they can be added. U41232-J-Z

92 "VConfig" application Application-specific actions Figure 74: Hierarchical tree displaying unused system board The figure shows the unused system board Systemboard_4. Note that it is shown for all partitions ("discover-0", "discover-1", "discover-3") and that the CPU type is different for unused CPUs. 84 U41232-J-Z

93 Application-specific actions "VConfig" application Boards tab The Boards tab is extended by an additional sub-tab called Systemboards-DR, in order to list all the DR-relevant system boards together with their DR-related properties and to allow execution of dynamic reconfiguration: Figure 75: Object table of the Systemboards-DR sub-tab The four columns on the right display the settings of the DR-related properties: Kernel Memory Lock Out Kernel Memory IO Deactivation Memory Deactivation I As there is no DR software installed on the discover-0 machine, the columns with the DR-specific parameters are blank. U41232-J-Z

94 "VConfig" application Application-specific actions Hardware presentation tab Any component marked as unused by a black colored dot in the hierarchical tree is displayed in gray on the Hardware presentation tab, see system board #4: Figure 76: Example of an unused system board in the Hardware presentation The figure shows an M800 cabinet with a dual-power-feed option to the left (contains five additional power supplies). 86 U41232-J-Z

95 Application-specific actions "VConfig" application DR actions The DR action is only available on the Systemboards-DR sub-tab. As with other object-specific actions, the DR functions are available in the object-specific menu following selection of the corresponding system board. Because the DR operation takes a number of minutes and is interactive, WebSysAdmin starts the DR operation in a batch job control window, which displays the output of the corresponding DR command and allows the user to answer potential questions. Figure 77: Example of a DR batch job control window U41232-J-Z

96 "VConfig" application Application-specific actions Disconnect system board The Disconnect action is only available for configured or waiting system boards. After starting the action, the following dialog box is displayed where you can specify further options: immediately the system board is disconnected immediately at next reboot the disconnection is delayed until the next reboot next partition specifies to which partition this system board is to belong in the future. It will be added to the new partition the next time the partition reboots. Figure 78: Dialog box for disconnecting system boards The Disconnect action is only available if the system board has no kernel memory. 88 U41232-J-Z

97 Application-specific actions "VConfig" application Connect system board Select the system board to be added to the relevant partition, display the objectspecific menu (e.g. right mouse click) and hit Connect. The user can specify in the next dialog box whether the action should be performed immediately or at the next reboot: immediately the system board is connected immediately at next reboot the connection is delayed until the next reboot Figure 79: Dialog box for connecting system boards U41232-J-Z

98 "VConfig" application Application-specific actions Move system board The Move action allows the user to move a system board directly from one partition to another. The user can specify in the next dialog box whether the action should be performed immediately or at the next reboot: immediately the system board is connected immediately at next reboot the disconnection is executed when the current partition reboots and the connect is executed when the new partition reboots Note that both partitions have to be rebooted in the specified sequence. next partition drop-down list of all partitions to which the system board may be moved Figure 80: Dialog box for moving system boards Two batch job control windows will pop up in sequence after pressing Ok, the first controlling the disconnection and the second controlling the connection. 90 U41232-J-Z

99 Application-specific actions "VConfig" application Restrictions Dynamic reconfiguration is only available on partitions running Solaris 8. The kernel_cage_enable attribute must be set to 1 in /etc/system on every partition. Only system boards without active PCI controllers are available for dynamic reconfiguration. This means that either there is no PCI hardware installed or the noiosb property is set. Only system boards not containing any kernel memory are available for dynamic reconfiguration. Only system boards that are not used for booting (OBP) are available for dynamic reconfiguration. The noobpsb property therefore has to be set for all system boards that are to be used for dynamic reconfiguration. U41232-J-Z

100 "VConfig" application Application-specific actions Hardware presentation The configured hardware is presented graphically on the Hardware Presentation tab of the VConfig application. The type of information displayed depends on what you have selected in the hierarchical browser, i.e. the deeper you go in this hierarchy, the more differentiated the presentation becomes. Two examples should provide an impression of this: Figure 81: Example of the overall hardware presentation for an enterprise server The overall hardware configuration for an enterprise server is shown in this example. The next example shows systemboard 0 of discover-0 node for the same system, i.e. the focussed view of a lower hierarchical level: 92 U41232-J-Z

101 Application-specific actions "VConfig" application Figure 82: Example of the hardware presentation of a node s systemboard You will recognize configured hardware modules by their color highlighting in the presentation, where the different colors represent different hardware states (green = object is not faulty etc; for details see the help text). If you position the cursor on a cabinet or on a hardware module configured in the cabinet, a tooltip informs you of the type of cabinet or hardware module in question. By pressing the left mouse button once on an object selected in this way, the input focus is shown in the form of a dotted frame surrounding the cabinet or the hardware module. When the input focus is displayed, you can execute actions on the relevant object by pressing the right mouse button, for example you can change the configuration parameters (of the "hme1" controller in the example). Once you have selected the relevant piece of hardware and initiated the Modify action, the following dialog box opens in our example: U41232-J-Z

102 "VConfig" application Application-specific actions Figure 83: Example of a dialog box for changing a controller in the hardware presentation Fill in the dialog box in accordance with your requirements and then confirm the changes by pressing Ok. I In the case of hardware modules, which are administered on a different tab (e.g. hard disks), you can execute the same actions under the same conditions at this point as are also possible on the managed tab. 94 U41232-J-Z

103 Application-specific actions "VConfig" application Changing the position of a cabinet in the rack Cabinets (or rack mountable cabinets as is the case under WebSysAdmin) that are installed in racks cannot be located automatically. In order to represent the location of such cabinets in the rack correctly, the position must be manually adjusted, i.e. reported specifically to the system. Standard views or defaults are used so that the position of cabinets in racks can be represented in any case in the hierarchical browser and in the Hardware Presentation before this manual adjustment. The next figure shows an excerpt from the hierarchical browser with two such defaults: Figure 84: Browser excerpt with default racks U41232-J-Z

104 "VConfig" application Application-specific actions The Office domain with the two nodes OfficeServer and WebServer is selected in the excerpt from the hierarchical browser. These two machines are actually located in the same rack. You will see below how this can be displayed in a realistic way. The names of the racks are composed in general according to the following syntax: The (default) rack name appears on the left-hand side before the colon, terminated with a period. This is followed by the (default) position of the cabinet in the rack, which is always 1 for defaults. The name or ID of the cabinet appears on the right-hand side after the colon. All displays are structured on the basis of this convention. One special feature to note is that the first rack, the primary rack, always takes the name of the node itself (in our example OfficeServer). 96 U41232-J-Z

105 Application-specific actions "VConfig" application The overall picture then looks as follows: Figure 85: Sample hardware presentation of two racks with default positioning I The following rule applies for the default representation prior to manual adjustment: The system assumes a separate rack for each installed cabinet. If, for example, you have installed two cabinets in only one rack (as in the example), a second (fictitious) rack is displayed initially as the default in the presentation and in the hierarchical browser. We describe below how to manually adjust the position of the first cabinet in the example. It is assumed that as in the example you are on the Hardware Presentation tab in the VConfig application. Now click the frame of the cabinet (not an installed device, for example like the power supply!), whose position you want to adjust, and choose the Modify action with the right mouse button. Then choose the Position tab: U41232-J-Z

106 "VConfig" application Application-specific actions Figure 86: Dialog box for manually adjusting a cabinet position in the rack In the Rack type and Rack name fields in the next dialog box, enter the (freely definable) name and type of the rack in which the cabinet is actually installed. Finally, establish its actual position in the rack in the Cabinet position field. Some racks contain a bar with a scale with the center as the point of origin (no minus entry on the bar!). The digit identifying the position of the lower edge of the cabinet is critical. The lower edge in our example lies at bar position -5 below the point of origin: This is the entry you have to select in the Cabinet position field (if the lower edge were at bar position 5 above the point of origin, you would have chosen +5). You can check in the graphical view whether the position details are realistic. Once you have made your changes in the fields listed above, you can see these in the graphical view by pressing the Apply button. You can test your input in this way before exiting the dialog box with the Ok button and thus store the values in the system. Proceed in the same way to position the second cabinet as described for the first cabinet. 98 U41232-J-Z

107 Application-specific actions "VConfig" application After all entries have been adjusted to suit the actual situation, the correct values are displayed in the hierarchical browser and in the hardware presentation: Figure 87: Representation of the cabinet position in the rack following manual adjustment (excerpt) The rack name is now represented correctly as OfficeRack and the position of the cabinets in the rack is also correctly represented as -5 and -1. Positioning the FDEs in enterprise servers When positioning the FDEs in enterprise servers, remember that the enterprise server cabinets are to be regarded as racks. The following special features must also be considered: The machine type should be specified for the rack type (e. g. M1000) The only possible cabinet positions are Top, Middle and Bottom The next example of a dialog box for changing an FDE cabinet position in an enterprise server clarifies these peculiarities for the input fields. U41232-J-Z

108 "VConfig" application Application-specific actions Figure 88: Dialog box for manually changing an FDE cabinet position in an enterprise server I In order to establish the name of an FDE cabinet, you simply press the small white button on the rear of the rack below the RCI port and the name or ID will be displayed on the CD panel of the main cabinet for a certain time Identifying the cabling between a SCSI controller and the disk add-on In order to be able to correctly display the location of disks, the cabling to the respective disk tier (cabinet) must be known. This cannot be done automatically in most cases. Instead, a default connection is sometimes displayed. It is easy to check from the hierarchical browser whether cabling is absent because the name of the controller will be missing after the SCSI line. Thus, the name is also missing after the scsi_1 line in the next example (besides the plus sign before the icon), i.e. the cabling information is not available: 100 U41232-J-Z

109 Application-specific actions "VConfig" application Figure 89: Browser excerpt with no cabling information for SCSI lines The proper connection must be entered if the location is to be displayed correctly in the Hardware Presentation. This is the only way to ensure that the connected devices in a cabinet are displayed at the correct position. You therefore have to manually enter the correct connection in this case or change the defaults. In order to define a SCSI connection manually, first select the relevant controller in the VConfig application on the Controller tab: U41232-J-Z

110 "VConfig" application Application-specific actions Figure 90: Sub-menu for manually identifying a SCSI controller connection Right-click with the mouse and choose the Modify action in the sub-menu to open the next dialog box with the Port tab: 102 U41232-J-Z

111 Application-specific actions "VConfig" application Figure 91: Dialog box for manually identifying a controller connection On the Port tab in this dialog box, choose both the cabinet and line to which this controller is connected under Connected to. Finally, notify the system of the adjusted connection by pressing Ok. The result is then displayed in the hierarchical browser and in the object table on the SCSI sub-tab: U41232-J-Z

112 "VConfig" application Application-specific actions Figure 92: Representation in the hierarchical browser and in the object table following manual identification of the controller cabling Having successfully identified the SCSI controller cabling, the controller name glm1 appears in brackets in the hierarchical browser after the scsi_1 line and the name of the cabinet to which the controller is connected is also displayed in the object table in the Connected to column. Finally, the disks are also displayed in the hierarchical browser under their line. 104 U41232-J-Z

113 Application-specific actions "RMS" application 5.3 "RMS" application The RMS application provides you with information on RMS configurations as well as the associated cluster nodes and clusters. The view is restricted to the display of existing cluster structures, i.e. you cannot select the view here as in other WebSysAdmin applications. The RMS and Additional Infos tabs are offered in the object list for the RMS application. Both tabs contain sub-tabs that you can use to access information from a local or cluster-wide view. A cluster is used by way of example below to show some of the display options and actions. The figure shows two clusters each containing a number of cluster nodes. The first cluster with the name MUSICAL is marked and its RMS objects (in other words applications monitored by RMS and the resources needed by these applications) are displayed in the object list: Figure 93: Example of how a local cluster structure is displayed You can show the object list in a tree structure from the menubar by choosing View Tree. The advantage of this is that the individual levels are clearly recognizable: U41232-J-Z

114 "RMS" application Application-specific actions Figure 94: Sub-menu for changing the view Figure 95: Example of displaying a cluster in a tree structure You can choose to display more detailed information for individual RMS objects. For example, you can display additional attributes for an RMS object or its status values on all cluster nodes. In addition, you can display the hardware attributes for RMS objects to which a system resource is assigned, as for example in the VConfig application. 106 U41232-J-Z

115 Application-specific actions "RMS" application Choose an RMS object you want to display with the left mouse button, then press the right mouse button and choose Show System Object: Figure 96: Sub-menu for displaying a system object Alternatively, you could also have selected the RMS Show System Object option from the menubar. In both cases, a dialog box opens with the configuration parameters, as shown for example in the next figure: U41232-J-Z

116 "RMS" application Application-specific actions Figure 97: Dialog box with information on a system object The representation of the object list on the Additional Info tab is different from that on the RMS tab. There are no RMS objects here, rather information on the cluster, the RMS configuration and the RMS agents. You can establish from this view whether RMS is currently active on a node or whether an RMS agent has the status "up" or "down". Depending on requirements, you can then start or stop the RMS agent on the selected cluster node. 108 U41232-J-Z

117 Application-specific actions "RMS" application Figure 98: Example of displaying a local cluster structure on the Additional Info sub-tab Select a node with the left mouse button, then press the right mouse button and choose the Admin RMS Agent action: Figure 99: Sub-menu for administering an RMS agent Alternatively you could also have selected the Additional Info Admin RMS Agent action from the menubar. In both cases, a dialog box opens in which you can start or stop the agent: U41232-J-Z

118 "RMS" application Application-specific actions Figure 100: Dialog box for administering an RMS agent Having executed a start or stop action, a message box pops up showing the SNMP events of the RMS agent. You can see from these results that the RMS agent has executed the action required of it: 110 U41232-J-Z

119 Application-specific actions "RMS" application Figure 101: SNMP event view after starting an RMS agent I The SNMP must be configured correctly for this SNMP event to be displayed; see section Configuring the EMANATE master agent for WebSysAdmin on page Troubleshooting The RMS application is based fully on the PRIMECLUSTER SNMP agent data and its integration via SNMP. If no data is displayed for cluster nodes or if the interface is not updated when a change is made not even after a refresh then you should check the following points: On the cluster node: 1. Are the EMANATE packages installed? SMAWsnmpm SMAWmngrs U41232-J-Z

120 "RMS" application Application-specific actions 2. Are the SNMP agents installed? SMAWRhvsa (PRIMECLUSTER 3.0) SMAWrcmib (PRIMECLUSTER 4.0) 3. Are the SNMP agents running? ema.rmsd (PRIMECLUSTER 3.0) rmsagt (PRIMECLUSTER 4.0) Is there a hvdisp -m zombie process? If yes, kill it. 4. Is the agent MIBs integrated? Not necessary on PRIMECLUSTER 3.0 Happens automatically on PRIMECLUSTER 4.0 when the SMAWrcmib package is installed 5. Is SNMP configured correctly? Does the public or wsa community exist for local get requests? Are the IP addresses of the trap recipients (management servers) entered in snmptargetaddrentry? On the WebSysAdmin trap recipient: 1. Is the traprcv program running? 2. Is the MIB of the SMAWrcmib package integrated? See also section Configuring the EMANATE master agent for WebSysAdmin on page U41232-J-Z

121 Application-specific actions "Diagnostics" application 5.4 "Diagnostics" application System diagnosis The diagnostic system can be configured from the central administration desktop for all nodes in a domain and is used for troubleshooting and diagnostics. Various functions are available for configuration and evaluation purposes. Domain-wide configuration Log administration Among other things, log administration allows the size and number of logbooks to be defined as well as the logbook components to be assigned. Event management Event management allows events and reactions to be defined. All system messages are observed from a monitor. When the defined events occur, the assigned reactions are performed, for example defining a component as defective or information messages for the administration desktop. Monitoring The monitoring function allows error thresholds to be defined for storage and SCSI components, with the result that the components are marked as faulty if these values are exceeded and possibly deconfigured. It is a component of the LAR concept (LAR = Logout Auto Recovery). Domain-wide evaluation Domain-wide evaluation allows all logbooks to be displayed for nodes or their entries. The performance is dependent in this case on the number of nodes and the size and number of logbooks. The system administrator can basically follow two approaches when troubleshooting: 1. General troubleshooting across all nodes in a domain 2. Object-specific troubleshooting for a specific error message The first approach is demonstrated below using an example. U41232-J-Z

122 "Diagnostics" application Application-specific actions General troubleshooting System administrators must be able to analyze and resolve errors quickly when they occur. One method of reducing the particularly large volume of information in the various logbooks in the administration domain is to use search criteria. Two options are available to you in this case: the selection configurator and the filter action. In the selection configurator (see the description on page 35 earlier) as is also the case with the other applications it is only possible to specify a search criterion + operator, in order to search, for example, throughout a domain for all log entries with a specific weighting or for messages from a particular driver. However, the following example uses two criteria (time period and weighting), in order to reduce the result set further. A filter is needed for this purpose. Regardless of the object, the filter action allows serious errors to be sought specifically for a defined period. For example, a system administrator may want to view all errors less than or equal to (<=) 4, which have occurred in a domain within the last 24 hours. The example assumes a single domain, which comprises the two nodes "OfficeServer" and "WebServer". Since you may want to record all serious errors that occur in the domain, select the top item in the hierarchical browser with the name of the root domain. You can then use the LogEvaluation tab and the Filter function to open the dialog box where you can specify the filter: 114 U41232-J-Z

123 Application-specific actions "Diagnostics" application Figure 102: Example of an object-independent filter Only the key data for the time period and the error weighting is shown in this object-independent filter. The period covers 24 hours and the weighting is set to less than or equal to (<=) 4, i.e. all errors that require a reaction soon or immediately. I You are shown the precise format for the date fields by dragging the cursor to the from date entry. When you exit the dialog box with Ok, all hits are shown in the object list: Figure 103: Example of an object list with faulty devices based on a filter In our example, one faulty object was found on one domain node: a defective fan on the node "WebServer". You can now display the detailed log entry by double-clicking one of the objects: U41232-J-Z

124 "Diagnostics" application Application-specific actions Figure 104: Example of a log evaluation for a faulty fan A log entry is shown with an error description in the Log text field. It is advisable at this point to switch to the VConfig application, Hardware Presentation tab, to find additional information about the defective device. The "WebServer" node is highlighted by a red dot in the hierarchical browser of this application to indicate that there is a defective device. If you select this node, you will be shown a graphical representation of the cabinet containing the defective fan. The fan itself is likewise highlighted in red. If you double-click this object, a dialog box opens containing a specification of the error: 116 U41232-J-Z

125 Application-specific actions "Diagnostics" application Figure 105: Example of a cabinet with a defective fan in graphical form as well as a dialog box showing the LAR status Event and reaction definitions Event Management uses messages and the frequency with which they occur to define events and trigger reactions in accordance with these events. For example, if you want to take up the option of receiving all system disruptions or warnings throughout the domain by , you have to proceed as follows: 1. Create an event definition. 2. Clone this event definition. 3. Create a reaction definition. 4. Clone this reaction definition. 5. Activate the modified event and reaction definitions. These steps are now illustrated individually using the following example. Step 1: Create event definition Ê Select a suitable entry in the Unit:Event Name column in the object list (in the example: cmn: Memory Multi Bit Error Reached) and right-click it. U41232-J-Z

126 "Diagnostics" application Application-specific actions The following sub-menu appears: Figure 106: Example of an object list for creating an event definition (excerpt) Ê Click Create Event Definition. The following dialog box is displayed: Figure 107: Example of a dialog box for creating an event definition A combination of unit and event name that does not already exist must now be assigned in this dialog box for the Unit:Event Name entry, in our example user:mail-event. All other fields can be accepted unchanged, modified or 118 U41232-J-Z

127 Application-specific actions "Diagnostics" application Ê deleted. For better clarity, our example shows the entry SMAWlog3:Mail to root in the Reaction 1 field as the unit and reaction name and the flag WARNING: in the Message Text field. Click Ok to exit the dialog box. You will now find the new event definition user:mail-event in the object list. Step 2: Clone event definition You have to clone the event definition to transfer it to other systems in the domain. To do this, proceed as follows: Ê Ê Select the entry you just created in the Unit:Event Name column in the object list (in the example: user:mail-event). Now click the Clone action. A dialog box opens where you have to select the destination nodes: Ê Figure 108: Example of a dialog box for cloning an object After you have selected the required node (in the example: Partition1), click Ok to exit the dialog box. You will then find the new event definition user:mail-event for all required destination nodes in the object list. U41232-J-Z

128 Step 3: Create reaction definition Ê Ê Change to the tab-bar Reactions. Choose a suitable entry in the Unit:Reaction Name column in the object list (in the example: SMAWubft:UBFT Reactions) and right-click it. The following submenu appears: Figure 109: Example of an object list for creating a reaction definition (excerpt) Ê Click Create Reaction Definition. The following dialog box is then displayed: Figure 110: Example of a dialog box for creating a reaction definition The only fields to edit in this case are Unit:Reaction Name and Command. Enter user:react-mail in the Unit:Reaction Name field as the unit and reaction name. Enter the log3mail reaction program in the Command field with the -w and -A options. The -w option causes a mail to be sent to a recipient in the

129 Application-specific actions "Diagnostics" application network without waiting for the transfer program to terminate. The -A option requires the user id of the mail recipient as an argument, in our example this is the user root. Ê Click Ok to exit the dialog box. Step 4: Clone reaction definition The reaction definition must also be cloned if it is to be transferred to other systems in the domain. To do this, proceed as described in Clone event definition on page 119. Step 5: Activate modified event and reaction definitions The following steps are required to activate the newly created event and reaction definitions: Ê Ê Change to the tab-bar Events. Click the Activate action. The following dialog box is displayed: Ê Figure 111: Example of a dialog box for activating event/reaction definitions Click Ok to activate the newly created event and reaction definitions. This completes all necessary steps. The new events will now also be monitored and will trigger the required reactions where necessary. U41232-J-Z

130 "Software" application Application-specific actions 5.5 "Software" application Checking software versions One of the system administrator s main tasks is to maintain the software used. The system administrator therefore has to ensure, for example, that all packages required on the respective systems are available in their current versions. This includes verifying that the same versions are being used on all nodes in a domain to avoid the individual nodes behaving differently. For this purpose, WebSysAdmin offers various options in the Software application to ensure simple administration of the software used. Therefore, if you want to know, for example, whether the same version of a particular package is used on all nodes in the domain, you can establish this as follows: 1. Select the entire domain in the hierarchical browser (click the name of the root domain). 2. Specify the abbreviated form of the required package (see the Pkginst attribute) in the search field of the selection configurator (in the example: SMAWlog3) and click the icon: Figure 112: Example of searching for installed packages As a result, the example shows an object list with ten packages, which are available with identical versions on all systems: Figure 113: Example of targeted selection of installed packages 122 U41232-J-Z

131 Application-specific actions "Software" application Checking the packages for consistency The second step involves selecting six packages and checking them for consistency. This is how you do this: Ê Ê Select the packages to be checked in the object list. In the menubar, click the Software option and choose the Check... action. Figure 114: Example of a menu for checking packages The following dialog box is displayed: U41232-J-Z

132 "Software" application Application-specific actions Figure 115: Example of a dialog box for checking software packages Choose the options you require from those listed. I The two options Check file attributes and Check file contents are already selected by default. Ê Start the checking process by clicking Ok. A progress indicator in the form of an increasing bar as well as a percent figure show how advanced the checking process is. As soon as the checking process is complete, a dialog box is opened containing the result of the checks: 124 U41232-J-Z

133 Application-specific actions "Software" application Ê Figure 116: Example of a dialog box with the result of a package check I If errors are listed here (e. g. incorrect access rights), you can resolve these if appropriate in a further check run by choosing the Correct known inconsistencies option in the dialog box. Click Ok to exit the dialog box. The checking of packages is now complete. U41232-J-Z

134

135 6 Integration in CA Unicenter TND 6.1 Overview The CA Unicenter TND product allows central administration of a worldwide network of different systems (computers, routers, bridges, etc.). The aim of integrating WebSysAdmin functionality in this product was not just to include this functionality but to ensure that if problems arose with computers administered by WebSysAdmin, the respective system or the responsible administrator would be informed automatically. This automatic notification is basically achieved by using different colored system views in the network map or by issuing messages to the console. In addition, the administrator is provided with a convenient means of invoking the WebSysAdmin application. WebSysAdmin integration in CA Unicenter TND is dependent on the product version of CA Unicenter TND. The framework version of CA Unicenter TND is a free version, which does not provide the entire integration functionality. This is only provided with the full version of CA Unicenter TND. The following sections look in greater detail at the differences between the two different product versions. A subagent for the HW diagnosis system (wsaagt of the EMANATE Master Agent, cf. figure EMANATE master agent and subagent on a node on page 222) is required for integrating WebSysAdmin in CA Unicenter. This subagent agent must be installed on every node that is to be monitored by this management tool Splitting the functionality for integration purposes The integration of WebSysAdmin in CA Unicenter TND is divided into two parts. These are: The components responsible for monitoring the systems and transferring the status (SNMP agents, see section SNMP agent architecture within WebSysAdmin on page 222). The files responsible for integrating information transferred by the SNMP agents and displaying it in CA Unicenter TND. U41232-J-Z

136 Integration in CA Unicenter TND These components are only available for certain systems in the first stage of WebSysAdmin CA integration. The SNMP agents are only available initially under UNIX/Solaris and the files for integration only under Windows NT 4.0. The next diagram should clarify how the functionality is divided: The SNMP agents on the UNIX system monitor the status of the hardware and the status of the systems in a domain. The administration system (CA Unicenter TND) informs the user of these states or any changes to them using SNMP traps. General information on each system is likewise transferred to the administration system via the SNMP protocol. Apart from various other information, this data also includes the system object ID. This ID identifies the system within CA Unicenter TND and, if possible, assigns it to a specific system class. Apart from the IP address of the administration system, this system object ID is a parameter that can be configured on the WebSysAdmin SNMP agent. The section SNMP information: Interpretation, implementation and special features on page 143 contains a precise description of this parameter and its meaning. 128 U41232-J-Z

137 Integration in CA Unicenter TND 6.2 Integration in the CA Unicenter TND framework version The following functionality is available to the administrator when integrating WebSysAdmin in the CA Unicenter TND framework version: Display and monitoring of all PRIMEPOWER systems as a separate host class in the World View 2D map and 3D map. Option to invoke the WebSysAdmin application from the popup menu of the selected PRIMEPOWER system directly from the network overview of the World View 2D or 3D map. Display of all SNMP traps received from the monitored PRIMEPOWER systems on the Enterprise Manager console. A discovery function must be successfully executed first for the relevant subnet and the SNMP agent must be installed on the systems being monitored. This functionality is described in greater detail in the next sections. U41232-J-Z

138 Integration in CA Unicenter TND Functionality of the World View 2D map The World View tool offered by CA Unicenter shows the administrator a 2D network map of all components and systems in the network. The systems are represented by the assigned icons. The next diagram shows an extract from such a network map: Figure 117: World View 2D map The following icon was selected for displaying PRIMEPOWER systems in the 2D representation: Figure 118: Example of a 2D representation 130 U41232-J-Z

139 Integration in CA Unicenter TND The current status of the systems is communicated to the administrator based on the color of the icon. The following states and colors are defined: Color of icon black yellow red green light blue gray violet Status of system down warning critical normal minor unknown major As soon as an SMNP trap is received by the administration system from one of the systems depicted in the network map, the status specified or assigned in this trap is transferred to this map. This tool provides the administrator with additional functionality in the form of a call option for WebSysAdmin. The right mouse button provides access to a system-dependent popup menu for every system. The WebSysAdmin menu option was added to this menu for the PRIMEPOWER systems. This menu is shown in the next diagram: Figure 119: PRIMEPOWER popup menu Selecting/activating this menu option invokes the WebSysAdmin application for the system selected in the network map. U41232-J-Z

140 Integration in CA Unicenter TND Functionality of the World View 3D map This view shows the administrator the selected network in 3D. The relevant systems are also represented here with their assigned icons. However, the icons in this case are three-dimensional and can thus be observed from all sides as well as from within. The following icon was assigned to the PRIMEPOWER system for this purpose: Figure 120: Example of a 3D representation If a system does not have the status normal, this is indicated by a flare on the system icon. The colors of these flares correspond to the system states outlined in the section Displaying the status of components in the system on page 134. The remaining functionality is the same as that in the 2D map and was already described in the previous section. 132 U41232-J-Z

141 Integration in CA Unicenter TND Functionality of the Enterprise Manager console Apart from other information, the console displays all SNMP traps received by the administration system. These SNMP traps normally comprise a sequence of digits rather than readable text. The traps sent by the WebSysAdmin SNMP agent are converted to readable text so that they can be more readily understood by the administrator. The next diagram shows an example of this: Figure 121: Example of trap console display The entry labeled Trap 1 is an SNMP trap, which is converted to readable form, while the entry labeled Trap 2 refers to part of an unconverted SNMP trap. All traps received from a WebSysAdmin SNMP agent are shown in converted form. This conversion is described in the section SNMP information: Interpretation, implementation and special features on page 143. U41232-J-Z

142 Integration in CA Unicenter TND 6.3 Integration in the full version of CA Unicenter TND If WebSysAdmin is integrated in a full version of CA Unicenter TND, the administrator has the same access to the functions in the World View tool described in the previous chapter as in a framework installation. The visual presentation of the functions is also the same as described there. However, the scope, the distribution of the CA product and the starting of the tool itself are very different. But because the functions added by WebSysAdmin are not different, they will not be described here again. Additional functionality is provided by the option to check the status of individual components. The next sections contain a short description of this functionality Displaying the status of components in the system The tools for displaying the system components allow closer investigation of the status of the administered systems. While the World View tool only shows the status of the entire system, this option allows a more in-depth look at the system. If a problem arises, therefore, the administrator can more readily determine which component caused the particular problem. Agents must be available for the components being monitored in this case. Such an agent is provided for integrating WebSysAdmin in the full version of CA Unicenter TND. In order to access this component view of a system, the relevant system has to be selected in the World View 2D map. By double-clicking with the left mouse button, you work through two dialogs to find the detailed view of the Unispace. This is shown in the next diagram. 134 U41232-J-Z

143 Integration in CA Unicenter TND Figure 122: Example of a World View 2D map The administrator can also establish the current status of the components in this case by the color of the icons. The assignment is as follows: Color of icon black yellow red green light blue gray violet Status of system down warning critical normal minor unknown major The diagram above therefore shows us the system zeit in the status critical (color of icon = red). This status is caused by the WebSysAdmin component, as this has likewise assumed the status critical. The Ping and Mib-II components, on the other hand, have the status normal (color of icon = green). An option to call WebSysAdmin directly has also been integrated here for this system so that it is easier for the administrator to find out more about the cause of the critical status from this environment. Right-click the WebSysAdmin icon to open the popup menu shown above, which also contains a menu option for starting WebSysAdmin. U41232-J-Z

144 Integration in CA Unicenter TND The following view is entered by double-clicking the WebSysAdmin icon: Figure 123: Example of a World View 2D map showing WebSysAdmin components This view shows the WebSysAdmin components Hardware State and Domain State. The components represent the hardware status and the domain status of the selected system. The administrator can also determine the current status of the components here by the color of the icons. Right-click the WebSysAdmin icon to open the popup menu displayed above. Apart from the already familiar menu option for starting WebSysAdmin, this menu contains other menu options for calling the different tools. The most important of these tools from the point of view of WebSysAdmin integration are described below. You will find more detailed information in the documentation for CA Unicenter TND Object View Object View is a tool that the administrator uses to display the MIB data for the selected object. The data displayed for the selected components depends on how the tool is called. If the call is made from the system view in the 2D map, only the MIB-II data is displayed; if the call is made from the component view, the MIB data for the selected component is also displayed. MIBII data relates to general information about the system, such as: CPU type speed memory operating system 136 U41232-J-Z

145 Integration in CA Unicenter TND etc. If the call is made for a selected WebSysAdmin component, information is also displayed in relation to the system, the WebSysAdmin status, the WebSysAdmin SNMP traps. This tool can also be used to display information for all other MIB files known in CA Unicenter. The information is always up to date for the selected destination system. The next diagram shows how the tool is called via a selected WebSysAdmin component: Figure 124: Example of calling the Object View tool via a selected WebSysAdmin component U41232-J-Z

146 Integration in CA Unicenter TND View Node Further details are available in View Node using the tools that can be called from here. View Node is called from the popup menu for the selected component. The following diagram shows the view that appears next: Figure 125: Example of the View Node tool view The status of the component is highlighted in color here also and the last SNMP information received is displayed. Further details are available via the popup menu (right mouse button). 138 U41232-J-Z

147 Integration in CA Unicenter TND MIB Browser When this option is called, the MIB Browser displays information about the component for which this call was made. This is the same information as is also available in the Object View. However, the view in this case is prepared especially for the components. The next diagram shows information about the WebSysAdmin component. Figure 126: Example of the MIB Browser showing information about the WebSysAdmin component U41232-J-Z

148 Integration in CA Unicenter TND Properties General information about the selected system or the selected component is made available by calling this option. In the case of WebSysAdmin, this includes information about the WebSysAdmin agent such as name, class, poll interval etc., in addition to the system name, IP address, etc. The next diagram contains an example: Figure 127: Example of the Properties menu option showing information about the WebSysAdmin agent 140 U41232-J-Z

149 Integration in CA Unicenter TND View Agent Calling this option in the popup menu invokes a tool, which displays general information about the current system as well as information about the selected component. This can be seen in the next diagram: Figure 128: Example of the View Agent menu option showing information about the current system U41232-J-Z

150 Integration in CA Unicenter TND Event Browser The Event Browser provides information about the WebSysAdmin events received. The next diagram shows an overview of the available functionality: Figure 129: Example of the Event Browser menu option showing information about WebSysAdmin events received For further details on the Event Browser, please refer to section Events/SNMP traps on page U41232-J-Z

151 Integration in CA Unicenter TND 6.4 SNMP information: Interpretation, implementation and special features This section describes the handling of the SNMP traps from the WebSysAdmin SNMP agent by the CA integration module as well as the special features of the system object ID System object ID During installation of WebSysAdmin CA integration functionality in CA Unicenter TND, the PRIMEPOWER class is defined for displaying the PRIMEPOWER systems in the World View. Among other things, this class is assigned the system object ID This results in all systems that log on to CA Unicenter TND with this ID being assigned to the PRIMEPOWER class. They are displayed, for example, with the PRIMEPOWER icon in the World View and are described as PRIMEPOWER systems, etc. However, since some software products assume that they will find these systems in the Host/Solaris class, a second system object ID ( ) has also been defined. This ID is added to the Solaris class during installation of WebSysAdmin CA integration functionality. This second ID allows users determine how the PRIMEPOWER systems will be displayed in their installations. Only the required system object ID must be set for the WebSysAdmin SNMP agent. In the full version of CA Unicenter TND, this type of switch produces a different representation of the systems in the World View and also means that WebSysAdmin can only be called from World View within the Unispace (selection of WebSysAdmin agent icon) for these systems. However, the remaining functionality is fully preserved. In the case of a framework installation of CA Unicenter TND, both system object IDs are assigned to the PRIMEPOWER class. A switch to the second system object ID therefore does not produce a different representation in World View in this case. U41232-J-Z

152 Integration in CA Unicenter TND Handling SNMP traps in a framework installation Two actions are derived from the received SNMP traps in a framework installation: 1. The system status is determined directly from the trap and incorporated in the World View representation. 2. The text to be displayed on the enterprise console is determined based on a conversion. A trap sent by the WebSysAdmin SNMP agent is structured as follows: %CATD_I_060, SNMPTRAP: -c public toronto.pdb.fsc.net :00:15 2 OID: iso.org.dod.internet.private.enterprises VALUE: TORONTO OID: iso.org.dod.internet.private.enterprises VALUE: The highlighted number (6) in the example above indicates the meaning of the trap. This number therefore determines which representation will be selected for the system status in the World View for the system and which text will be displayed on the enterprise console. This interpretation or conversion is shown in the table below: 144 U41232-J-Z

153 Integration in CA Unicenter TND Determining the status of the system in the World View: Trap number/meaning 1/WSA Defect 2/WSA Defect Unset 3/WSA Error Set 4/WSA Error Unset 5/WSA Agent Start 6/WSA Error Repair 7/WSA Defect Repair 24/WSA Integrated 25/WSA not Available 26/WSA not Running New system status Critical Warning Warning Normal No status change No status change No status change No status change No status change No status change Conversion of the message text for the enterprise console: Trap number/meaning 1/WSA Defect 2/WSA Defect Unset 3/WSA Error Set 4/WSA Error Unset 5/WSA Agent Start 6/WSA Error Repair 7/WSA Defect Repair 24/WSA Integrated 25/WSA not Available 26/WSA not Running Message text WSA: Lar Defect Trap sent WSA: Lar Unset Defect Trap sent WSA: Lar Error Set Trap sent WSA: Lar Unset Error Flag sent WSA: Trap Agent started Error Repair Event Received Defect Repair Event Received WSA: Node Integrated WSA: Node not Available WSA: DomainAdmin not running U41232-J-Z

154 Integration in CA Unicenter TND Handling SNMP traps in a full version of CA Unicenter TND If WebSysAdmin CA integration was performed in a full version of CA Unicenter TND, the SNMP traps of the WebSysAdmin SNMP agent are received by an agent of the Distributed State Machine (DSM). This agent presents the status of the system hardware and the DomainAdmin status of the system in the Hardware State and Domain State components. It derives the current system status from the last status of each of these components combined with the new message (the new trap). The following traps are processed here: Hardware traps: Traps wsaagentstart wsalarhardwaredefectset wsalarhardwaredefectunset wsalarhardwareerrorset wsalarhardwareerrorunset wsaerror Repair wsadefect Repair Meaning The WSA SNMP agent was started. Defect flag was set for a component. The last detect flag was unset, but there is at least one error flag. An error flag was set. There is neither a defect nor an error flag. An error was resolved but there is still at least one more. A defect was resolved but there is still at least one more. The wsaerrorrepair and wsadefectrepair traps do not produce a status change because a similar type of problem still exists. They simply provide information for the administrator. 146 U41232-J-Z

155 Integration in CA Unicenter TND DomainAdmin traps: Traps wsanodestatusintegrated wsanodestatusnotavail wsanodestatusnotrunning Meaning The node is integrated in a DomainAdmin domain. The DomainAdmin software is active but the node is not integrated in a domain. The DomainAdmin software is not active on the node. These different traps give rise to the following states that are to be displayed with DSM: Hardware states: Status Unknown NoFlagSet DefectSet ErrorSet Meaning The LAR status of the machine is not known. No defect flag and no error flag set in HW Config. At least one defect flag is set. At least one error flag and no defect flag set. DomainAdmin states: Status Unknown NotRunning NotAvail Integrated Meaning The DomainAdmin status is not known. The DomainAdmin software is not active on the node. The DomainAdmin software is active but the node is not integrated in any domain. The node is integrated in a DomainAdmin domain. The tables below show the status derived from the old status combined with the current trap. The World View status or the World View map is shown in addition to the new status. U41232-J-Z

156 Integration in CA Unicenter TND Hardware State Hardware traps Trap DefectSet Defect Unset ErrorSet ErrorUnset Agent Start Original status Unknown DefectSet ErrorSet ErrorSet NoFlagSet NoFlagSet Critical Warning Warning Normal Normal NoFlagSet DefectSet ErrorSet ErrorSet NoFlagSet NoFlagSet Critical Warning Warning Normal Normal ErrorSet DefectSet ErrorSet ErrorSet NoFlagSet NoFlagSet Critical Warning Warning Normal Normal DefectSet DefectSet ErrorSet ErrorSet NoFlagSet NoFlagSet Critical Warning Critical Normal Normal Domain State DomainAdmin traps Trap Integrated Not avail Not running Agent Start Original status Unknown Integrated Not avail Not running Integrated Normal Warning Critical Normal Integrated Integrated Not avail Not running Integrated Normal Warning Critical Normal Not avail Integrated Not avail Not running Integrated Normal Warning Critical Normal 148 U41232-J-Z

157 Integration in CA Unicenter TND DomainAdmin traps Trap Integrated Not avail Not running Agent Start Original status Not running Integrated Not avail Not running Integrated Normal Warning Critical Normal The next diagram shows how the traps or states described above are shown in the CA Unicenter TND Event Browser: Figure 130: Representation of traps and states in the Event Browser The status listed in the table above is shown in the State column and the reason for the message or trap is shown in the Reason column. The next table contains a listing of all traps and the resulting messages. Trap number/meaning 1/WSA Defect 2/WSA Defect Unset 3/WSA Error Set 4/WSA Error Unset 5/WSA Agent Start 6/WSA Error Repair 7/WSA Defect Repair Message text WSA: LAR defect reported WSA: LAR defect unset WSA: LAR error reported WSA: LAR error unset WSA: Trap agent started WSA: Error repair report received WSA: Defect repair report received U41232-J-Z

158 Integration in CA Unicenter TND Trap number/meaning 24/WSA Integrated 25/WSA not Available 26/WSA not Running Message text WSA: Node integrated WSA: Node not available WSA: DomainAdmin not started 150 U41232-J-Z

159 7 Integration in Tivoli 7.1 WebSysAdmin for Tivoli Overview The WebSysAdmin for Tivoli add-on allows SNMP traps to be integrated in the Tivoli Enterprise Console (TEC). WebSysAdmin SNMP agents have to be set up on the nodes as trap senders for this purpose, which are monitored via the TEC. An administration system is entered with the Tivoli Enterprise Console as the recipient of WebSysAdmin SNMP traps for all WebSysAdmin SNMP agents. The traps sent by the nodes are depicted as Tivoli events on the TEC with the aid of the WebSysAdmin for Tivoli add-on. The WebSysAdmin for Tivoli add-on includes a procedure for configuring the TEC server in addition to various procedures for configuring and deconfiguring the TEC SNMP adapter. WebSysAdmin SNMP traps are included in TEC event processing in this way Software requirements The following software packages are required for using WebSysAdmin for Tivoli: Operating system: Windows NT 4.0 SUN Solaris 2.6 or higher AIX 4.3 or higher Tivoli software: Tivoli Management Framework 3.6 or higher Tivoli Enterprise Console 3.6 or higher Tivoli TEC SNMP Adapter 3.1 or higher U41232-J-Z

160 WebSysAdmin for Tivoli Integration in Tivoli Installation Dependencies on other Tivoli products The Tivoli Management Framework and Tivoli Enterprise Console packages must be installed for WebSysAdmin for Tivoli. Before you install WebSysAdmin for Tivoli, you have to first install the Tivoli Plus Module Support (Link binaries) o module, which you will find on the installation CD. Since this component may also be used by other Tivoli modules, it is not removed when WebSysAdmin is deinstalled. The installation can be performed from the command line or from the Tivoli desktop Installation from the command line WebSysAdmin for Tivoli is installed from the command line using the two following commands: # winstall -c Image-Directory -i LINK TEC-Server # winstall -c Image-Directory -i WEBSYSAD TEC-Server Example: winstall -c /tmp/wsa_image -i LINK ws4711-tec Installation via the Tivoli desktop Step 1 Choose the Install Install Product... option under Desktop to the above right in the window in order to open the Install Product window: 152 U41232-J-Z

161 Integration in Tivoli WebSysAdmin for Tivoli Figure 131: Tivoli desktop The Install Product box is displayed: U41232-J-Z

162 WebSysAdmin for Tivoli Integration in Tivoli Figure 132: Install Product box Step 1a If the two products WebSysAdmin for Tivoli and Plus Module Support do not appear in the list of products that can be installed or if a box is displayed with the error message Something is wrong with the current installation media settings, click Select Media... or OK in the error message box. A box is then displayed for selecting the correct path for the Tivoli image: 154 U41232-J-Z

163 Integration in Tivoli WebSysAdmin for Tivoli Figure 133: Select Media box Step 2 First choose the Plus Module Support product as well as the relevant TEC server as the client on which the installation is to be performed: U41232-J-Z

164 WebSysAdmin for Tivoli Integration in Tivoli Figure 134: Install Product box for installing the File Module Support product Click Install and Continue Install in the next box to install Plus Module Support. Step 3 Now repeat Step 2 to install the WebSysAdmin for Tivoli product: 156 U41232-J-Z

165 Integration in Tivoli WebSysAdmin for Tivoli Figure 135: Install Product box for installing the WebSysAdmin for Tivoli product Click Install or Install & Close and Continue Install in the next box to install WebSysAdmin for Tivoli. This completes installation of WebSysAdmin for Tivoli Deinstallation WebSysAdmin for Tivoli is deinstalled under "root" (on Windows NT as an administrator using the Tivoli bash) by calling the PLUSunconfig.sh script: # UNIX or Windows? if [ x\"$os\" = x\"windows_nt\" ] then. C:/Winnt/system32/drivers/etc/tivoli/setup_env.sh else. /etc/tivoli/setup_env.sh fi $BINDIR/../generic_unix/TME/PLUS/WEBSYSADMIN/PLUSunconfig.sh U41232-J-Z

166 WebSysAdmin for Tivoli Integration in Tivoli The product is then deinstalled and all associated configurations unset in Tivoli. The integration files are not removed in the process however. The Plus Module Support product is likewise not deinstalled because it may also be used by other Tivoli modules Configuration WebSysAdmin collection for Tivoli The WebSysAdmin for Tivoli collection contains the jobs required for integrating WebSysAdmin in Tivoli. Starting from the Tivoli desktop, you access the collection as follows. Double-click the TivoliPlus icon to open the TivoliPlus collection: 158 U41232-J-Z

167 Integration in Tivoli WebSysAdmin for Tivoli Figure 136: Tivoli desktop The following screen appears: U41232-J-Z

168 WebSysAdmin for Tivoli Integration in Tivoli Figure 137: TivoliPlus collection Now double-click the WebSysAdmin for Tivoli icon to access the WebSysAdmin for Tivoli collection: Figure 138: WebSysAdmin for Tivoli collection The WebSysAdmin for Tivoli collection contains five jobs that support the necessary configurations for integrating WebSysAdmin SNMP traps in the TEC: Setup_TEC_for_WSA Definition of event classes and rules on the TEC server Config_SNMP Configuration of any desired TEC SNMP adapter Config_SNMP_local Configuration of the local TEC SNMP adapter 160 U41232-J-Z

169 Integration in Tivoli WebSysAdmin for Tivoli Unconfig_SNMP Resetting of the configuration of any desired TEC SNMP adapter Unconfig_SNMP_local Resetting of the configuration of the local TEC SNMP adapter A local adapter can also be configured by the two general configuration jobs. However, additional input is not required if the local job is used. If only a local TEC SNMP adapter is used, or if adapters on other systems are used exclusively in place of a local adapter, the jobs that are not required can be removed from the collection in order to allow a simpler overview The Setup_TEC_for_WSA job The Setup_TEC_for_WSA job is used to configure the TEC for displaying the Tivoli events generated from WebSysAdmin SNMP traps by the SNMP adapter. The classes required for WebSysAdmin events are defined here, as are TEC rules for the WebSysAdmin events. By double-clicking the icon for the Setup_TEC_for_WSA job, you can start the job and the following dialog box is displayed: Figure 139: Dialog box for the Setup_TEC_for_WSA job In the Setup_TEC_for_WSA dialog box, you must always specify the name of a rule base. A distinction is made here between two cases: 1. If the specified rule base already exists, the classes and rules for WebSysAdmin are added to this rule base. 2. If the specified rule base does not exist, the two fields Rule Base to clone and Path for Rule Base must be filled. In this case, the Rule Base to clone is copied. The classes and rules for WebSysAdmin are now imported into this new rule base. U41232-J-Z

170 WebSysAdmin for Tivoli Integration in Tivoli The optional field Name of Event Console to configure can also be filled, regardless of which of the two possibilities described above is used. If you specify an existing event console, this is assigned the event group WebSysAdmin that contains all the WebSysAdmin events. You are then shown an output box containing either error messages indicating incomplete or invalid details or other errors or documenting the successful configuration of the TEC: Figure 140: Output box of the Setup_TEC_for_WSA job 162 U41232-J-Z

171 Integration in Tivoli WebSysAdmin for Tivoli The Config_SNMP job By double-clicking the icon for the Config_SNMP job, you can configure any desired TEC SNMP adapter. The adapter configuration is hence extended by the entries required for integrating WebSysAdmin SNMP traps. When the job is started, you are shown the following dialog box: Figure 141: Dialog box for the Config_SNMP job In the dialog box for the Config_SNMP job, you must specify where the SNMP adapter to be configured is located. You can define the following Tivoli resources for this: Endpoint Managed Node Profile Manager If you specify a Profile Manager, the SNMP adapter is configured on all subscribers assigned to the Profile Manager. You can also optionally specify the directory of the SNMP adapter. This is particularly essential for most Windows NT endpoints. If you have given invalid details, for example an endpoint that does not exist or incorrect details of the directory for the adapter, then messages to this effect are issued in the outbox box. The figure below shows the output box for the SNMP_Config job for the Profile Manager PM_SNMP_Adapters, to which the three subscribers pce304, ws6520 and atpcq79c are assigned: U41232-J-Z

172 WebSysAdmin for Tivoli Integration in Tivoli Figure 142: Output box of the Config_SNMP job The first of these subscribers, a Tivoli endpoint, could not be reached, since the Tivoli endpoint service has not been started. The TEC SNMP adapter was successfully configured and restarted for the two other subscribers. 164 U41232-J-Z

173 Integration in Tivoli WebSysAdmin for Tivoli The Unconfig_SNMP job By double-clicking the icon for the Unconfig_SNMP job, you can remove any existing configurations for WebSysAdmin SNMP traps for any desired TEC SNMP adapters in the Tivoli environment. The entries for WebSysAdmin traps in the adapter configuration files.cds and.oid are removed. When the job is started, you are shown the following dialog box: Figure 143: Dialog box for the Unconfig_SNMP job The input fields are the same as for the Config_SNMP job, i.e. you can again specify either a Tivoli endpoint, a managed node or a profile manager. If you specify a profile manager, the job is executed for all the assigned subscribers. Once again, the directory of the SNMP adapter can be optionally specified; however, this is also required above all for most Windows NT endpoints. The figure below shows the output box for the SNMP_Unconfig job for the ws6520 endpoint: U41232-J-Z

174 WebSysAdmin for Tivoli Integration in Tivoli Figure 144: Output box of the Unconfig_SNMP job The Config_SNMP_local job By double-clicking the icon for the Config_SNMP_local job, you can configure the local TEC SNMP adapter. You do not need to make any further input. The result of the job is shown in a separate box: 166 U41232-J-Z

175 Integration in Tivoli WebSysAdmin for Tivoli Figure 145: Output box of the Config_SNMP_local job The Unconfig_SNMP_local job By double-clicking the icon for the Unconfig_SNMP_local job, any configurations of the local TEC SNMP adapter that exist for WebSysAdmin SNMP traps are undone. The result of the job is likewise shown in a separate box: U41232-J-Z

176 WebSysAdmin for Tivoli Integration in Tivoli Figure 146: Output box of the Unconfig_SNMP_local job TEC classes for WebSysAdmin The following TEC classes are configured for WebSysAdmin for Tivoli by the baroc file wsa_traps.baroc: Class Leaf Class from Additional slots WSA_Trap Specific_SNMP_Trap WsaLarHardwareDefectSet WSA_Trap wsaservername wsalarcomment wsatraptime wsahwconfaddr WsaLarHardwareDefectUnset WSA_Trap wsaservername wsalarcomment wsatraptime wsahwconfaddr 168 U41232-J-Z

177 Integration in Tivoli WebSysAdmin for Tivoli Class Leaf Class from Additional slots WsaLarHardwareErrorSet WSA_Trap wsaservername wsalarcomment wsatraptimewsahwconfaddr WsaLarHardwareErrorUnset WSA_Trap wsaservername wsalarcomment wsatraptime wsahwconfaddr WsaAgentStart WSA_Trap wsaservername WsaErrorRepair WSA_Trap wsaservername wsalarcomment wsatraptime wsahwconfaddr WsaDefectRepair WSA_Trap wsaservername wsalarcomment wsatraptime wsahwconfaddr The Specific_SNMP_Trap class is defined in the Tivoli baroc file tecad_snmp.baroc, which must be imported in the rule base before wsa_traps.baroc. tecad_snmp.baroc is installed along with the TEC SNMP adapter and must have already been imported into the relevant rule base before the Setup_TEC_for_WSA job is executed TEC rules for WebSysAdmin The following TEC rules for the rule set wsa_rules.rls are configured by WebSysAdmin for Tivoli: Rule name Affected TEC class Action plain_wsa_rule1 WsaErrorRepair Closes the incoming "allclear" event and the associated WsaLarHardwareErrorSet event. plain_wsa_rule2 WsaLarHardwareErrorUnset Closes the incoming "allclear" event and the associated WsaLarHardwareErrorSet event. U41232-J-Z

178 WebSysAdmin for Tivoli Integration in Tivoli Rule name Affected TEC class Action plain_wsa_rule3 WsaDefectRepair Closes the incoming "allclear" event and the associated WsaLarHardwareDefectSet event. plain_wsa_rule4 WsaLarHardwareDefectUnset Closes the incoming "allclear" event and the associated WsaLarHardwareDefectSet event. plain_wsa_rule5 WsaLarHardwareErrorUnset Closes the incoming "allclear" event and the associated WsaLarHardwareDefectSet event Testing aids In order to test the operability of WebSysAdmin for Tivoli, WebSysAdmin SNMP traps must be sent to the TEC SNMP adapter. These traps may also be generated with available test tools from WebSysAdmin or a generic SNMP trap sender program. For example, the NetView snmptrap command can be used to simulate a hardware defect trap: TrapTime=`date +%R` snmptrap -p 1162 pc ws \ OctetString ws4711 \ OctetString "2nd CPU down" \ OctetString "$TrapTime" \ OctetString "x5:4:just a test" The following parameters are used here: -p 1162 Sends the trap to port 1162 pc7398 Name of trap recipient (= system with active TEC SNMP adapter) Enterprise ID under which the WebSysAdmin SNMP traps are sent ws471 Name of trap sender (= WebSysAdmin server) 170 U41232-J-Z

179 Integration in Tivoli WebSysAdmin for Tivoli 6 Generic trap number 1 Specific trap number (1 = "HardwareDefect" trap) 0 Time stamp (not relevant for the test, hence "0") These are followed by the four trap parameters for WebSysAdmin server, error message, trap time and internal error detection if...? This section deals with possible application or operation errors and describes their causes and means of resolution. WebSysAdmin events are not shown in the TEC Situation: The TEC shows no WebSysAdmin SNMP traps sent. Cause: Check the following points: 1. The server with the TEC SNMP adapter must be configured as a trap recipient of the WebSysAdmin agent. By default, the TEC SNMP adapter expects incoming traps on port 162. While this value can be changed, the WebSysAdmin agent must then also send to the modified port. Ê Start the SNMP adapter in debug mode to see whether the WebSysAdmin SNMP traps are received by the adapter. 2. Check the communication between the adapter and TEC server. Ê Execute the Tivoli wtdumprl command on the TEC server to see whether events are received on the TEC server from the adapter. 3. Check the TEC configuration: In order to ensure that incoming WebSysAdmin events are also displayed, the relevant TEC classes must be known on the TEC server. Ê Check whether the wsa_traps.baroc class file for WebSysAdmin SNMP traps is loaded in the current rule base of the TEC server. You can load the configuration using the Setup_TEC_for_WSA procedure. Endpoint:<Endpoint name> not running at the moment! U41232-J-Z

180 WebSysAdmin for Tivoli Integration in Tivoli Situation: The above error message appears when one of the jobs for configuring the SNMP adapter is executed. Cause: The Tivoli endpoint cannot be reached, i.e. the system cannot be reached in general or the endpoint client has not been started or is faulty. "Failed to import d:/tivoli/bin/generic_unix/tme/plus/websysadmin /wsa_traps.baroc to <rulebase_name> rulebase!" Situation: The error message appears in connection with the job Setup_TEC_for_WSA. Cause: wsa_traps.baroc could not be imported into the rule base since it already exists in the rule base. The error message therefore has a purely informal character. "mv: cannot move `<PATH>i/bin/w32-ix86/TME/TEC/adapters/etc/snmp.tmp' to `<PATH>/w32-ix86/TME/TEC/adapters/etc/tecad_snmp.cds': File exists" Situation: Following execution of one of the jobs to undo the configuration of the SNMP adapter on a Windows NT system, there are still no WebSysAdmin entries in the cds adapter file. Cause: It may take longer on Windows NT systems for the associated process to be terminated after the adapter has been stopped. If this is still not the case 30 seconds after the adapter has been stopped, the cds file opened by the adapter cannot be accessed. It may help in this situation to repeat execution of the job. Alternatively, the adapter can also be manually terminated before the job is executed. (Even if the WebSysAdmin entries still remain in the cds file, this does not impact other traps that are passed by the adapter to the TEC.) "Problems while stopping TEC SNMP Adapter!" Situation: The above message is displayed during execution of a job for configuring an SNMP adapter on Sun Solaris. 172 U41232-J-Z

181 Integration in Tivoli WebSysAdmin for Tivoli NetView Cause: The start/stop script init.tecad_snmp for Sun Solaris contains a bug. Replace in the script the line: # pid=`ps -ef grep $1 grep -v grep grep -v $1.cfg \ awk {print $2;} ` by the following line: pid=`ps -ef grep $1 grep -v grep grep -v $1.cfg \ grep -v $0 awk {print $2;} ` 7.2 WebSysAdmin for Tivoli NetView Overview The WebSysAdmin for Tivoli NetView package allows WebSysAdmin to be integrated in Tivoli NetView with the following properties: Unambiguous representation of PRIMEPOWER systems in the NetView map by means of a separate icon. Representation of the WebSysAdmin application in the submap of PRIME- POWER systems by means of a separate icon. Simple configuration of NetView attributes for PRIMEPOWER systems in Tivoli NetView with the aid of a NetView map application for WebSysAdmin. Automatic event integration: support of the WebSysAdmin MIB and display of the traps defined in it as Tivoli NetView events. Optional forwarding of these events to a Tivoli Enterprise Console (TEC). Mapping of the status of WebSysAdmin to the WebSysAdmin icons in the NetView map. Simple display of status information on WebSysAdmin by means of new MIB applications. Calling of WebSysAdmin directly from Tivoli NetView (if the WSA client software has been installed on the NetView server). A subagent for the HW diagnosis system (wsaagt of EMANATE Master Agent, cf. figure EMANATE master agent and subagent on a node on page 222) is required for integrating WebSysAdmin in Tivoli NetView. This subagent agent must be installed on every node that is to be monitored by this management tool. U41232-J-Z

182 WebSysAdmin for Tivoli NetView Integration in Tivoli Software requirements The following software packages are required for using WebSysAdmin for Tivoli: Operating system: Windows NT 4.0 Sun Solaris 2.6 or above Tivoli software: Tivoli NetView 5.1 or 6.0 for NT Tivoli NetView 5.1 or above for Sun Solaris Installation Dependencies on other Tivoli products The WebSysAdmin for Tivoli NetView integration package is installed on the NetView server and requires Tivoli NetView when it is installed. If Tivoli NetView is deinstalled, the integration package remains on the system. Please note the following in order to ensure that WebSysAdmin integration still works when Tivoli NetView is reinstalled without the integration package having to be removed first and then reinstalled: Sun Solaris: Following installation of Tivoli NetView, the configuration of WebSysAdmin for Tivoli NetView must be loaded again using the following call: /opt/smaw/smawtnvs/bin/wsa_load_config.sh. Windows NT: An "Upgrade" installation must be selected in Tivoli NetView installation, otherwise the integration package must also be installed again. Event integration for WebSysAdmin SNMP traps must then be configured again by one of the two calls Configure WSA-Events Forward to TEC or Do not forward to TEC. 174 U41232-J-Z

183 Integration in Tivoli WebSysAdmin for Tivoli NetView Installation on Windows NT Step 1 Start installation of the WebSysAdmin for Tivoli NetView integration package by double-clicking WsaNetViewIntegration.exe. I If the WSA client software has not been installed on the NetView server, you receive the following message: Figure 147: Warning: WSA client software missing This means that you cannot start the WSA GUI from Tivoli NetView. Either click Cancel and abort the installation so that you can install the WSA client and then the integration package, or select OK to continue installation. You can subsequently install the WSA client software at any time. In this case, start the WSACheck.exe program in the <NV_DRIVE>/usr/ov/wsa/bin directory after installing the WSA client. Click Next to continue installation or Cancel to abort installation. U41232-J-Z

184 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 148: Installation on Windows NT Welcome When you click Next, the Ready to Install window opens. This is the last window where you can abort the installation. 176 U41232-J-Z

185 Integration in Tivoli WebSysAdmin for Tivoli NetView Figure 149: Installation on Windows NT Ready to Install The following dialog boxes mark the start and end of event configuration. Click OK in both cases to continue. Figure 150: Start of event configuration Figure 151: End of event configuration Installation is completed when you click Finish in the following dialog box: U41232-J-Z

186 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 152: Installation on Windows NT Completion Step 2 Start Tivoli NetView and select Edit Properties... In the Properties box, select IP Map under Map Application and click Properties. Now tick Exclusively Set the Status for Nodes?, select Verify and press OK. Close the Properties box with OK. I If you configure a system as a WebSysAdmin node, Tivoli NetView represents this with the icon for PRIMEPOWER. However, the IP Map application regularly polls all the systems and defines the icon type on the basis of the received system object identifier. If Should IP Map override user symbol customization? is set to True, the icon for PRIMEPOWER is also replaced by the previous icon. In addition, the status of the WebSysAdmin node, which was set to propagated by the WebSysAdmin Map application in order for the status of the WebSysAdmin agent to be forwarded to the WebSysAdmin node icon, is reset to Set for this node only after the Tivoli NetView GUI is exited and restarted. However, this does not impact the other functions of the integration package. 178 U41232-J-Z

187 Integration in Tivoli WebSysAdmin for Tivoli NetView Installation on Sun Solaris In order to ensure correct functioning of the installation routine for the SMAWtnvS package, the error in the /usr/ov/bin/nvaddtrapdconf script used for installing SMAWtnvS must be corrected if NetView 5.1 is used. This error has already been corrected in NetView and higher. The Tivoli NetView integration package SMAWtnvS is installed on Sun Solaris with the pkgadd command after all the NetView GUIs have been exited. The package installs all the necessary files under /opt/wsaopt/smaw/smawtnvs and then calls the //opt/wsaopt/smaw/smawtnvs/bin/wsa_load_config.sh script. This script copies files to the Tivoli NetView directory structure and enables the installed extensions. This script can also be called on its own after installation. The /opt/wsaopt/smaw/smawtnvs/bin/wsa_unload_config.sh script undoes all the changes to Tivoli NetView made by wsa_load_config.sh. This script is called with pkgrm during deinstallation, but can also be executed on its own. Step 1 Exit all the Tivoli NetView GUIs. Step 2 This step must only be performed if you are using NetView 5.1. This error has been rectified in NetView and higher. Rectification of an error in the Tivoli NetView script //usr/ov/bin/nvaddtrapdconf. Execute the following commands under the root ID: cd /usr/ov/bin cp nvaddtrapdconf nvaddtrapdconf.original Comment out line 290 and replace it with the following: #HIT = match( $0, /["][^\n]+["]/ ) # set RSTART and RLENGTH HIT = match( CAT[i], /["][^\n]+["]/ ) # set RSTART and RLENGTH Step 3 Start installation with the following command: pkgadd -d /opt/smaw/smawtivx/data/smawtnvs The following dialog box is shown: U41232-J-Z

188 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 153: Installation on Solaris Start Enter 1 and press the Return key or simply press the Return key to start installation. Figure 154: Installation on Solaris Checking for Tivoli NetView The installation routine checks that Tivoli NetView exists and specifies the NetView directory found. If Tivoli NetView is not found or you specify n and thus do not confirm the directory found, the installation is aborted. If you enter y or simply press the Return key (y is the default value), you receive the following query: 180 U41232-J-Z

189 Integration in Tivoli WebSysAdmin for Tivoli NetView Figure 155: Installation on Solaris Last chance to abort Commands are executed under the root ID for configuring the integration package. Select y to continue or n to abort installation. This is your last opportunity not to perform installation. Figure 156: Installation on Solaris Completion Installation of the package is completed with configuration for WebSysAdmin integration. U41232-J-Z

190 WebSysAdmin for Tivoli NetView Integration in Tivoli Step 4 Start Tivoli NetView and select File Describe Map... In the Map Description box, select the IP Map application and click Configure for this map. Now set Should IP Map override user symbol customization? to False, select Verify and press OK. Close the Map Description box with OK. I If you configure a system as a WebSysAdmin node, Tivoli NetView represents this with the icon for PRIMEPOWER. However, the IP Map application regularly polls all the systems and defines the icon type on the basis of the received system object identifier. If Should IP Map override user symbol customization? is set to True, the icon for PRIMEPOWER is also replaced by the previous icon. However, this does not impact the further functionality of the integration package Deinstallation on Windows NT Step 1 Undo configuration as a WebSysAdmin node for all PRIMEPOWER systems. To do this, select the PRIMEPOWER systems and then select WebSysAdmin Configure WSA-Node Unconfigure WSA-Node. (You can select several PRIME- POWER systems simultaneously. The best way to do this is to use a separate WSA collection. See section Definition of a WebSysAdmin collection on page 196). The integration package can only be deinstalled in full once the configuration of all PRIMEPOWER systems has been undone in this way. Step 2 Exit all Tivoli NetView GUIs. Step 3 You deinstall the integration package by double-clicking Uninstall.exe in the <NV_DRIVE>/usr/ov/wsa directory: 182 U41232-J-Z

191 Integration in Tivoli WebSysAdmin for Tivoli NetView Figure 157: Deinstallation of the integration package on Windows NT Click the Next button to complete deinstallation of the integration package in Tivoli NetView: U41232-J-Z

192 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 158: Deinstallation on Windows NT Completion Deinstallation on Sun Solaris Before deinstallation, the configuration of all PRIMEPOWER systems must be undone since the deinstallation routine also deinstalls the corresponding icons. If a system with the PRIMEPOWER icon is still in the map after deinstallation, a default icon that can no longer be changed is used to display the system. Following deinstallation with pkgrm or execution of the /opt/wsaopt/smaw/smawtnvs/bin/wsa_unload_config.sh script, the event category WebSysAdmin Events must be deleted manually using the Tivoli NetView GUI. Step 1 Undo configuration as a WebSysAdmin node for all PRIMEPOWER systems. To do this, select the PRIMEPOWER systems and then select WebSysAdmin Configure WSA-Node Unconfigure WSA-Node. (You can select several PRIME- POWER systems simultaneously. The best way to do this is to use a separate WSA collection. See section Definition of a WebSysAdmin collection on page 196). The integration package can only be deinstalled in full with the pkgrm SMAWtnvS command once the configuration of all PRIMEPOWER systems has been undone in this way. 184 U41232-J-Z

193 Integration in Tivoli WebSysAdmin for Tivoli NetView Step 2 Exit all Tivoli NetView GUIs. Step 3 Start deinstallation with the following command: pkgrm SMAWtnvS You are shown the following dialog box: Figure 159: Deinstallation of the Solaris package SMAWtnvS Select y to remove the package or n to abort deinstallation. U41232-J-Z

194 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 160: Deinstallation on Solaris Last chance to abort As during installation, note that commands must be executed under the root ID in order to undo the configuration of the integration package. Select y to continue or n to abort deinstallation. This is your last opportunity to abort deinstallation. Figure 161: Deinstallation on Solaris Undoing the WSA configuration 186 U41232-J-Z

195 Integration in Tivoli WebSysAdmin for Tivoli NetView All the files installed by the package are removed. However, files newly copied into the WebSysAdmin directory, such as the postemsg command required for forwarding, remain. This completes deinstallation of the integration package. Figure 162: Deinstallation on Solaris Completion Step 4 Start Tivoli NetView and delete the event category WebSysAdmin Events, which can only be reset via the GUI: select Options Event Configuration: Trap Customization: SNMP. click Configure Categories, then select WebSysAdmin Events and click Delete. Now close the Configure Event Categories box with Close and the Event Categories box with OK. If the WebSysAdmin Events event category still remains, however, this will not have any further effects on Tivoli NetView or the renewed installation of the integration package. U41232-J-Z

196 WebSysAdmin for Tivoli NetView Integration in Tivoli Configuration The description of WebSysAdmin integration in Tivoli NetView is basically the same regardless of whether Tivoli NetView is used on Windows NT or Solaris. Where there are differences in individual cases, for example in paths or NetView menu paths, these are indicated separately Integration in the NetView IP map PRIMEPOWER systems are represented in the IP map by their own icon. In addition, the WSA agent is also represented by its own icon, which symbolizes the states of the agent that are reported by traps. The status of the icon for the WSA agent is propagated to the PRIMEPOWER icon. If a system is configured as a WSA server by means of a menu call, this is recognized by the WebSysAdmin Map application that runs as a Tivoli NetView process. As a result, the system icon is changed to PRIMEPOWER and the associated NetView attributes. As a consequence, the icon for the WSA agent is also configured and the above-mentioned status propagation is enabled. Configuration of a system as a WSA node Systems with isnode capability can be configured as WSA nodes, i.e. as PRIMEPOWER systems, from the WebSysAdmin Configure WSA-Node Configure as WSA-Node menu. For this purpose, the relevant systems must be selected in the map and the above-mentioned menu item then selected. As a result, the selected systems are given the icon Computer:PRIMEPOWER and the haswebsysadmin capability is set to True. A new icon of the type Software:WebSysAdmin is generated in the submap of these systems. The items from the WebSysAdmin menu are then available for these systems. If this configuration is to be undone, the relevant system is selected in the map and the menu item WebSysAdmin Configure WSA-Node Unconfigure as WSA- Node is selected. If a new system of the type PRIMEPOWER is created manually, it is also configured automatically. 188 U41232-J-Z

197 Integration in Tivoli WebSysAdmin for Tivoli NetView Description of the WebSysAdmin Map application Automatic configuration of the WSA systems is carried out by the map application (/opt/wsaopt/smaw/smawtnvs/bin/websysadminmapapp). This map application is enabled by default. However, it can also be disabled. By calling File Describe Map..., a box opens that, among other things, displays the configurable applications. Select the WebSysAdmin application from the relevant list and press the Configure for this Map...button. This opens a box in which the map application can be enabled or disabled. Under the heading Enable WebSysAdmin for this map, you can select either True or False. You can then accept the selected configuration by pressing Verify and then OK. If the map application is disabled, all the icons of the type Software:WebSysAdmin are removed from the map. In addition, the menu items Configure as WSA-Node and Unconfigure WSA-Node are deactivated if the map application is disabled. If the map application is enabled again, the WebSysAdmin icons are generated again in the submap of all appropriately configured systems and the menu items are activated again. If a map with read-only authorization is opened, the map application is automatically disabled since it also requires write access to the map. In this case, the map application also cannot be enabled from the configuration box. Close the current map and open it again with read-write authorization. Configuration of the IP map application Tivoli NetView periodically polls all the systems and in so doing changes the system icons to suit the current system type. In order to prevent automatic reconversion of the icon type for PRIMEPOWER systems, the Tivoli NetView IP Map application must be configured accordingly. On Windows NT, the status of the WSA node, which is set to propagated by the WebSysAdmin Map application in order for the status of the WSA agent to be forwarded to the WSA node icon, is also reset to Set for this node only after the Tivoli NetView GUI is exited and restarted. Proceed as follows in order to configure the IP Map application correctly: Solaris Open the map description by choosing File Describe Map..., select the IP Map application from the list of Configurable Applications and press the Configure For This Map...button. In this box, select the value False under the heading Should IP Map override user symbol customization?. U41232-J-Z

198 WebSysAdmin for Tivoli NetView Integration in Tivoli Windows NT Open the Properties box by calling the menu Edit Properties..., select IP Map under Map Application and click Properties. Now disable Exclusively Set the Status for Nodes? and then select Verify and press OK. Close the Properties box with OK. Changing the selection name of PRIMEPOWER systems When WebSysAdmin icons are created in the submap of PRIMEPOWER systems, the selection name of the new application icon is created from the selection name of the higher-level PRIMEPOWER system (by appending the string :WebSysAdmin). If status changes are generated for the application icons as a result of WebSysAdmin events, the selection names required for this are established in the same way. If the selection name of a PRIMEPOWER system is changed, the selection name of the associated WebSysAdmin icon is not automatically changed, with the result that status events for the PRIMEPOWER system in question can no longer be executed correctly. However, you can correct the selection name of the WebSysAdmin icon by deleting the icon and creating it again. If this change affects a small number of systems, you can carry out this configuration by selecting the systems in question in the map and then selecting the menu items Unconfigure WSA-Node and Configure as WSA-Node. If the selection names of the WebSysAdmin icons are to be updated for all PRIME- POWER systems, the map application can be disabled and then enabled again MIB and event integration The integration package permits automatic event integration for WebSysAdmin SNMP traps. WebSysAdmin SNMP traps received on the NetView server are displayed with appropriate weighting in the Tivoli NetView Event Browser. The status of the WSA agent icon of the affected system is updated at the same time. The WebSysAdmin event can also be forwarded optionally to a Tivoli Enterprise Console (TEC). MIB integration As a result of integration of the WebSysAdmin MIB in Tivoli NetView, the SNMP variables defined in the MIB can be queried by Tivoli NetView. This can be done either by using the MIB Browser (Tools MIB Browser SNMP ) or by means of MIB applications. The WebSysAdmin integration routines provide two predefined MIB applications (see section Further WebSysAdmin menu calls on page 194). 190 U41232-J-Z

199 Integration in Tivoli WebSysAdmin for Tivoli NetView Event integration As a result of event integration carried out during installation, WebSysAdmin SNMP traps received on the Tivoli NetView server are recognized and shown in the format of Tivoli NetView events. Each of the defined WebSysAdmin events is given a weighting that is indicated by the color in the Event Browser. At the same time, the status of the icon of the sending WSA agent is updated as an automatic response to incoming WebSysAdmin events. This functionality is not performed if the selection name of the affected PRIMEPOWER system has been manually changed, since the name of the underlying WebSysAdmin icon can then no longer be resolved correctly (see section Changing the selection name of PRIMEPOWER systems on page 190). The WebSysAdmin icon for the WSA agent is located in the submap of the associated PRIMEPOWER system, which can also change its status as a result of incoming WebSysAdmin SNMP traps due to propagation of the WebSysAdmin icon status. Forwarding events to a TEC Events can also be forwarded optionally to a TEC in response to incoming WebSysAdmin SNMP traps. To allow this, you must first select the menu item WebSysAdmin Configure TECConfigure WSA-Events Forward to TEC. Forwarding to a TEC is disabled again with WebSysAdmin Configure TECConfigure WSA- Events Do not forward to TEC. Three requirements must be met in order for WebSysAdmin events to be forwarded to a TEC: 1. Definition of a TEC server 2. Availability of the Tivoli NetView command postemsg 3. Definition of the TEC class WSA_NV_Trap on the TEC server The first two points can be queried on the Tivoli NetView server. If they are not fulfilled, an error message is issued to this effect: Figure 163: Warning: No TEC server specified U41232-J-Z

200 WebSysAdmin for Tivoli NetView Integration in Tivoli Figure 164: Tivoli command postemsg not available If these two requirements are met, or if event configuration is initiated without forwarding to a TEC, the start and end of configuration are indicated as follows: Figure 165: Information: Start of event configuration Figure 166: Information: Event configuration with forwarding to a TEC completed Figure 167: Information: Event configuration without forwarding to a TEC completed Definition of a TEC server In order to define a TEC server, you have to open the configuration file Sun Solaris /etc/wsa_tec_foreward.conf Windows NT <NV_DRIVE>/usr/ov/wsa/etc/wsa_tec_foreward.conf 192 U41232-J-Z

201 Integration in Tivoli WebSysAdmin for Tivoli NetView and make the following configuration entries: ServerLocation=TEC-Server ServerPort=5529 ServerLocation defines the TEC server. The ServerPort=5529 entry must be used if the TEC server is a Windows NT system. If not, this line must be deleted from or commented out of the configuration file. (Basically, all the variables that are permitted in a TEC adapter configuration file can be used in the configuration file for defining the TEC server.) Availability of the Tivoli command postemsg The Tivoli postemsg command is used for forwarding WebSysAdmin events to a TEC and must exist in the following directory: Sun Solaris /opt/smaw/smawtnvs/bin/postemsg Windows NT <NV_DRIVE>/usr/ov/wsa/bin/postemsg.exe You can copy the command from the following directory on the TEC server after first setting the Tivoli environment accordingly on the TEC server using the following command: UNIX. /etc/tivoli/setup_env.sh Windows NT C:\WINNT\system32\drivers\etc\Tivoli\setup_env.cmd You can then find the postemsg command in the following directory on the TEC server: UNIX $BINDDIR/../lcf_bundle/bin/solaris2/bin/postemsg $BINDDIR/../lcf_bundle/bin/w32-ix86/bin/postemsg.exe Windows NT %BINDDIR%\..\lcf_bundle\bin\solaris2\bin\postemsg %BINDDIR%\..\lcf_bundle\bin\w32-ix86\bin\postemsg.exe U41232-J-Z

202 WebSysAdmin for Tivoli NetView Integration in Tivoli Definition of the TEC class WSA_NV_Trap on the TEC server Copy the <wsa-path>/wsa/etc/websysadmin.baroc file to the TEC server and then load the Tivoli environment: UNIX. /etc/tivoli/setup_env.sh Windows NT C:\WINNT\system32\drivers\etc\Tivoli\setup_env.cmd You must now import the baroc file to a rule base and then compile and load the rule base. Enter the following commands for this: wimprbclass abs.-path/websysadmin.baroc Rule-Base-Name wcomprules Rule-Base-Name wloadrb -u Rule-Base-Name Stop and then restart the TEC server. As a result, the TEC class WSA_NV_Trap is known on the TEC server and WebSysAdmin events forwarded by Tivoli NetView are displayed in the TEC. The Tivoli baroc file tecad_snmp.baroc must have been loaded so that the rule base can be compiled without any errors using the wcomprules command. This defines the various SNMP classes on which the WSA_NV_Trap class is based. tecad_snmp.baroc is installed with the TEC SNMP adapter in the same way as WebSysAdmin.baroc Further WebSysAdmin menu calls In addition to the WebSysAdmin menu calls described in the previous sections, there is also a call for starting the WebSysAdmin GUI as well as two MIB applications that supply the status of and general information on the WebSysAdmin server. Starting the WebSysAdmin GUI If you select a PRIMEPOWER system, you can start the WebSysAdmin GUI by means of WebSysAdmin Start GUI. However, to allow this, the WSA client software must have been installed on the NetView server. If this is not the case, you receive the following error message: 194 U41232-J-Z

203 Integration in Tivoli WebSysAdmin for Tivoli NetView Figure 168: Warning: WebSysAdmin client not installed If you subsequently install the WSA client software, you must execute the specified program (in the example D:/usr/OV/wsa/bin/WSACheck.exe) once on Windows NT by double-clicking it. On Solaris, it is sufficient for the software to be installed. Summary of the WebSysAdmin menu The table below provides an overview of the entire WebSysAdmin menu: Menu item Submenu Description Start GUI... Starts the WebSysAdmin GUIs WSA Status MIB application, status information for the selected WSA node(s) WSA Info MIB application, status information for the selected WSA node(s) Configure WSA-Node Configure as WSA-Node Configuration of the selected system as a WSA node Unconfigure as WSA-Node Undoing configuration of the selected system as a WSA node Configure WSA-Events Forward to TEC Event configuration for WSA traps with forwarding to a TEC Do not foreward to TEC Event configuration for WSA traps without forwarding to a TEC U41232-J-Z

204 WebSysAdmin for Tivoli NetView Integration in Tivoli Definition of a WebSysAdmin collection In order to get a better overview of all the PRIMEPOWER systems, you can create a collection containing all such systems. This provides you with an overview of the status of all PRIMEPOWER systems and their WebSysAdmin applications at a glance. In addition, you can quickly select several or all of the PRIMEPOWER systems that are distributed in the IP map hierarchy, possibly over several submaps, in order to execute calls from the WebSysAdmin menu for several systems. In particular, you can carry out WebSysAdmin configuration easily for all systems before deinstallation of the integration package by calling the menu WebSysAdmin Configure WSA-Node Unconfigure WSA-Node. You can define such a collection by means of Tools Collection Editor... You should use the following filter condition in this: (haswebsysadmin = True) AND (isnode = True) This provides you with a dynamic overview of all PRIMEPOWER systems, i.e. new PRIMEPOWER systems are automatically added to this group; if you undo the configuration for one of the PRIMEPOWER systems by calling the WebSysAdmin Configure WSA-Node Unconfigure WSA-Node menu, the system is automatically removed from the group WSA event configuration for Tivoli NetView The table below provides an overview of event configuration for WebSysAdmin SNMP traps in Tivoli NetView. The first two columns specify the name and the specific ID of the WebSysAdmin SNMP trap. The columns "NetView message" and "Severity" describe the formatting of the resultant NetView event, i.e. the message text and associated severity. As a response to the trap, the status of the WSA icon for the sending WSA node is changed in accordance with the column "Node status". If events are also forwarded to a TEC, the "TEC severity" in the last column is used for this: WSA trap Trap ID NetView message Severity Node status wsalarhardwaredefectset 1 Hardware defect occurred at <Time>: <Comment> wsalarhardwaredefectunset 2 Hardware defect cleared at <Time>: <Comment> wsalarhardwareerrorset 3 Hardware error occurred at <Time>: <Comment> wsalarhardwareerrorunset 4 Hardware error cleared at <Time>: <Comment> TEC severity Critical Critical CRITICAL Warning Marginal WARNING Critical Critical CRITICAL Cleared Normal HARMLESS 196 U41232-J-Z

205 Integration in Tivoli WebSysAdmin for Tivoli NetView WSA trap Trap ID NetView message Severity Node status Cleared Normal HARMLESS Warning Marginal WARNING Warning Marginal WARNING Cleared Normal HARMLESS Warning Marginal WARNING wsaagentstart 5 WSA Agent started at <Time> wsaerrorrepair 6 Hardware error repaired at <Time>: <Comment> wsadefectrepair 7 Hardware defect repaired at <Time>: <Comment> wsanodestatusintegrated 24 Cluster state changed to INTEGRATED wsanodestatusnotavail 25 Cluster state changed to NOT AVAIL wsanodestatusnotrunning 26 Cluster software not running Indeterminate TEC severity TEC class for WSA events from Tivoli NetView The following TEC class is configured by the baroc file WebSysAdmin.baroc for WebSysAdmin SNMP traps that are forwarded by Tivoli NetView to a TEC: Class Leaf class from Additional slots WSA_NV_Trap Specific_SNMP_Trap None The Specific_SNMP_Trap class is defined in the Tivoli baroc file tecad_snmp.baroc that must be imported into the rule base before WebSysAdmin.baroc. tecad_snmp.baroc is installed along with the TEC SNMP adapter and analogous to WebSysAdmin.baroc (see section Definition of the TEC class WSA_NV_Trap on the TEC server on page 194) Testing aids In order to test the operability of WebSysAdmin for Tivoli, WebSysAdmin SNMP traps must be sent to the NetView server. These traps may also be generated with available test tools from WebSysAdmin or a generic SNMP trap sender program. For example, the following NetView snmptrap command can be used to simulate a hardware defect trap: TrapTime=`date +%R` snmptrap -p 1162 pc ws \ OctetString ws4711 \ U41232-J-Z

206 WebSysAdmin for Tivoli NetView Integration in Tivoli OctetString "2nd CPU down" \ OctetString "$TrapTime" \ OctetString "x5:4:just a test" The following parameters are used here: -p 1162 Sends the trap to port 1162 pc7398 Name of trap recipient (= system with active TEC SNMP adapter) Enterprise ID under which the WebSysAdmin SNMP traps are sent ws471 Name of trap sender (= WebSysAdmin server) 6 Generic trap number 1 Specific trap number (1 = "HardwareDefect" trap) 0 Time stamp (not relevant for the test, hence "0") These are followed by the four trap parameters for WebSysAdmin server, error message, trap time and internal error detection What to do if... This section deals with possible application or operation errors and describes their causes and means of resolution. WebSysAdmin events are not displayed in Tivoli NetView Situation: No WebSysAdmin SNMP traps are received in the NetView Event Browser. Cause: The NetView server must be configured as the trap recipient of the WSA agent. By default, Tivoli NetView expects incoming traps on port 162. WSA events are not displayed in the TEC Situation: WSA events received in the NetView Event Browser are not displayed in the TEC despite event configuration with forwarding to a TEC. 198 U41232-J-Z

207 Integration in Tivoli WebSysAdmin for Tivoli NetView Cause: So that WSA events can be forwarded to a TEC, three requirements must be met in addition to appropriate event configuration (see section Forwarding events to a TEC on page 191). 1. The check to determine if a TEC server has been defined for forwarding is only carried out during event configuration. If the entry for the TEC server is changed later, forwarding may no longer be possible. (Depending on the configuration, the events may be buffered and forwarded as soon as a connection to a TEC server can be established.) Check the configuration entry for the TEC server or simply restart event configuration with forwarding to a TEC server. 2. Check if the postemsg command is available. If it is not, you should find a message in the NetView Event Browser that is similar to the one below: D:/usr/ov/wsa/bin/postemsg.exe not available! Cannot forward WebSysAdmin events to TEC! 3. Check whether the baroc file WebSysAdmin.baroc has been loaded in your current rule base. WSA nodes are not represented by a PRIMEPOWER icon Situation: WSA nodes have been configured correctly, as can be seen from the availability of the WebSysAdmin menu items, but are not represented by a PRIMEPOWER icon. Cause: Check whether the settings for the IP Map application have been made correctly (see section Configuration of the IP map application on page 189). Following correct setting or if the symbol type has been changed manually, you may have to call the WebSysAdmin menu items Configure WSA-Node UnConfigure as WSA-Node and subsequently Configure WSA-Node Configure as WSA-Node for your WSA nodes. The status of a WSA icon is not propagated to the higher-level PRIMEPOWER icon Situation: A WSA node has been configured correctly, but its PRIMEPOWER icon does not reflect the status of the underlying WSA icon. U41232-J-Z

208 WebSysAdmin for Tivoli NetView Integration in Tivoli Cause: Check whether the settings for the IP Map application have been made correctly (see section Configuration of the IP map application on page 189). Also check that the status of the affected system has not been set manually to Symbol or Set for this Symbol only. In this case, you can restore the correct configuration for the affected system by calling the WebSysAdmin menus Configure WSA-Node UnConfigure as WSA-Node and subsequently Configure WSA-Node Configure as WSA-Node. 200 U41232-J-Z

209 8 Reliant UNIX specifics 8.1 Virtual disks (Vdisks) Note that virtual disks (vdisks) can only be configured on systems running the Reliant UNIX operating system Creating virtual disks (vdisks) If you have installed the DomainAdmin add-on product, the configuration of virtual disks is guaranteed to be consistent throughout the domain. This means: Each node in a domain knows the vdisks of the other nodes since this information is stored in the CLODB (Cluster Object Database) database. Each time a system is rebooted, the CLODB is reconciled. As with user management, it is possible to create vdisks simultaneously on several nodes in a domain. This is particularly beneficial when managing identical hardware platforms as well as when setting up a vdisk on shared resources for later use of a high-availability application. Two working examples are provided for these two scenarios. I WebSysAdmin only supports disks created with VDisk Lite and stores these in the CLODB administration domain database Creating local vdisks on a node In order to add a vdisk to an administration domain, click the VConfig icon on the welcome screen after you have started WebSysAdmin; if you had already started WebSysAdmin and you are currently accessing a different component, click Application on the menubar and choose the VConfig application in the sub-menu. Then click the VDisks tab. You are now shown an object list with all vdisks, which have been created on the node or in the domain. In our example, we assume the domain comprises three nodes, i.e. spinlock, timeout and wait. The first step is to create a new group on the wait node, since a vdisk must always be assigned to a group. To create the new group, choose the VDisks entry on the menubar and navigate to the Create a vdisk group action as shown in the next figure: U41232-J-Z

210 Virtual disks (Vdisks) Reliant UNIX specifics Figure 169: Menu sequence for creating a vdisk group When you create a vdisk group, a dialog box of the same name opens, which you can fill in as follows: Figure 170: Example of a dialog box for creating a vdisk group The individual entries in the dialog box have been filled in accordance with our example and have the following meaning: Nodes The wait node, on which the new group is to be created, is selected. I If the local vdisk group 3000 is to be created on all nodes, this can be performed in one step by additionally selecting the nodes timeout and spinlock. 202 U41232-J-Z

211 Reliant UNIX specifics Virtual disks (Vdisks) New group The name of the new group is entered in this field and must comprise a number in the range The name or number must not already be assigned. Statesave This field contains the name of the statesave vdisk, i.e. the virtual disk for administration information. The name comprises the fixed component vdisk and the number of the group, hence in our example vdisk3000 as well as a valid unassigned vdisk number. Type local is selected in the Type field, since the new group is only to be used locally on the wait node. Configure level boot is entered in this field, which indicates that the group is to be configured (activated) automatically when the system boots. Comment You can enter any comment up to a maximum of 64 characters in this field. When you confirm the dialog box with Ok, the new group is created on the wait node. Now click the Vdisk groups sub-tab in the main window. If you created the new group simultaneously for all three nodes, you are shown the following object list as a result of the action: U41232-J-Z

212 Virtual disks (Vdisks) Reliant UNIX specifics Figure 171: Example of an object list after creating a vdisk group The new 3000 group was created on the three nodes spinlock, timeout and wait (Group and Node column). The group is of type local (Group type column) and is thus not shared with other nodes (Shared with column). Since no disks have been imported into this group as yet (the group is still empty so to speak), it also does not contain any statesave pieces (0 in the Statesave pieces column) and is also not yet configured (not-configured in the State column). The VDisk name column contains the pathname of the statesave vdisk. The remaining two columns (Level and Comment) show the respective input in the dialog box. Once the new vdisk group has been created, you have to fill it in the next step with the disks that are to be used. This step is termed importing a disk. Both steps, creating the group and importing the disks, are mandatory. The statesave pieces are created on the first imported disks. A maximum of six statesave pieces are used, with a maximum of two statesave devices being used for each SCSI port to improve the failsafe performance. 204 U41232-J-Z

213 Reliant UNIX specifics Virtual disks (Vdisks) Each virtual disk must be a particular type. There are several vdisk types depending on the usage [for details of the various vdisk types, see the manual page for vdisklite(7)]. To create the simplest base vdisk type, choose the Create base vdisks (import) action in the sub-menu on page 202. The dialog box that then opens may look as follows for example: Figure 172: Example of a dialog box for creating base vdisks The individual entries in the dialog box have the following meaning: Group, type, nodes The vdisk group into which the new vdisks being created are to be imported must be selected in this field. In our example, the 3000 group just created of type local in the wait domain was selected. Name This field contains the name of the first vdisk to be created. The field is preassigned the next valid vdisk name. U41232-J-Z

214 Virtual disks (Vdisks) Reliant UNIX specifics Step This field shows the increment for name generation where several disks are imported simultaneously. Configure This field is selected so that the imported disk is also configured (activated) after it is created. Browse You can use this button to search for the disks that are to be imported. If you click Browse, you switch to the disk browser where you can select a range of suitable disks. The disk browser only proposes disks as suitable if they are recognized as a free local resource on the wait node. Your selection is displayed in the table to the left with the new vdisk name. When you confirm the dialog box with Ok, the selected disks are integrated in the new 3000 vdisk group on the wait node. Now click the Top vdisks sub-tab in the main window. The following object list shows you the result of the action: Figure 173: Example of an object list for vdisks 206 U41232-J-Z

215 Reliant UNIX specifics Virtual disks (Vdisks) It is clear from the object list that a 3000 vdisk group exists on the wait node and contains five vdisks ( vdisk3001 to vdisk3005 ). These vdisks are of type base and since the vdisk group is of type local, the resources are not shared with any other member of the domain. The vdisks have the status configured and can be used immediately on the wait node Configuring vdisks on shared resources We described in the previous section how to create vdisks locally. However, since these vdisks all belong to a group of type local, they can only ever be used on one node. We use an example in this section to show how you can create mirror vdisks that are configured on two nodes in a domain. These vdisks are used as a basis for high-availability configurations. The first step again is to create a vdisk group. The dialog box described in the previous section on page 202 looks as follows for the new example: Figure 174: Example of a dialog box for creating a vdisk group of type rms The new group is created simultaneously on the two nodes spinlock and wait. The type local may not be selected. The selected rms type indicates that this is a vdisk group whose disks can be accessed from several nodes (a socalled multihosted environment). U41232-J-Z

216 Virtual disks (Vdisks) Reliant UNIX specifics The only permitted entry in the Configure level input field is manual. manual means that the vdisk group must be configured by the system administrator or from a high-availability monitor. When you confirm the dialog box with Ok, the new group is created on both nodes. If you now click the Vdisk groups sub-tab in the main window, you will see the result of the action in the following object list: Figure 175: Example of an object list after creating a vdisk group of type rms The new 4000 group has been created on the two nodes spinlock and wait. The main difference compared to the object list in the first example (see figure on page 204) is that the Shared with column now shows the node names spinlock and wait. This indicates that the vdisk definitions for this group refer to resources shared by the two nodes. The systems must share these resources, which means that access must be coordinated. In our previous example of creating local vdisks, the first step after the vdisk group was created was to import the disks. This example now discusses the creation of mirror vdisks. Because all disks are to be mirrored in two multi- 208 U41232-J-Z

217 Reliant UNIX specifics Virtual disks (Vdisks) hosted connected SCSI lines, the Create mirror vdisks for a sport (see figure on page 202) is selected instead of the action Create base vdisks (import). The following dialog box then opens: Figure 176: Example of a dialog box for mirroring a SCSI line The dialog box, which has been filled in accordance with our example, confirms that on node spinlock all disks for SCSI line 3 in cabinet BG66_4 (spinlock:bg66_4:scsi_3) are to be mirrored on SCSI line 4 in the same cabinet (spinlock:bg66_4:scsi_4). When Piece 0 is selected in the left selection box, all available disks including their parameters are listed. Nothing is selected in the status fields to the top right of the dialog box, (i.e Configure, Start catchup and Force online), because shared resources should only be configured on high-availability applications (RMS, Observe, OPS) and not automatically via WebSysAdmin. Warnings are also issued to this effect if you use WebSysAdmin for configuration or deconfiguration. When you confirm the dialog box with Ok, the line is mirrored and can be used on both nodes, i.e. spinlock and wait. If you now click the Top vdisks sub-tab in the main window, you will see the result of the action in the following object list: U41232-J-Z

218 Virtual disks (Vdisks) Reliant UNIX specifics Figure 177: Example of an object list with RMS vdisks The object table shows the result of the action from the view of the wait node. This view is identical with the view of spinlock. The individual vdisks in this group are of type mirror, since the entire SCSI line (vdisk4001 to vdisk4012) was mirrored. The newly created mirror disks are not yet configured (notconfigured). To configure them, you have to use a high-availability monitor, as already mentioned. A warning is issued in the event of a manual configuration via WebSysAdmin. Note that the RMS vdisk group was only configured on one system, as otherwise inconsistencies could arise in relation to the mirror status as well as the data itself. Where the vidsk is used in parallel, consistent mirror states can only be ensured for OPS/OPSRES vdisks. You will find additional information on managing vdisks in the manual Reliant UNIX Configuring Virtual Disks with VDisk Lite. 210 U41232-J-Z

219 9 Solving problems When working with applications under WebSysAdmin, a wide variety of faults and problems may arise. These problems may originate in the browser being used, in the WSA interface itself or in the individual applications (i.e. in the DomainAdmin 2.1 product). Some problems from these three groups that we know may recur from experience are highlighted below. We also illustrate possible workarounds or ways to avoid such problems. Whatever the actual cause of the problems, they always manifest themselves in the user s working environment, i.e. in the interface. If the screen does not respond at all, or only sluggishly or with error messages and if this adversely affects the user s work, the user is not interested in who or what may be the cause rather he or she just wants to be able to continue working as normal. The following problem scenarios and their proposed solutions are thus structured more in terms of their effect, since the same cause (e.g. high storage requirement) may have different effects (irregular interface or performance). We will look in greater detail at Problems using WSA Performance problems Problems managing domain nodes I In general, help texts are available for using WebSysAdmin, which generally also reference problems and constraints with regard to specific actions. If possible, you should consult these help texts when in doubt. 9.1 Problems with the browser or WSA It is a basic necessity when working with WebSysAdmin that you have the best possible hardware and software configuration. Details regarding the relevant technical data can be found in the section Administration desktop requirements on page 16. U41232-J-Z

220 Problems with the browser or WSA Solving problems The following list of problems is structured as follows: First, the problem is described briefly (indicated by ), then a solution is proposed (indicated by Ê). When you start WSA, no connection is established, the plug-in is not loaded. The Apache server may not be running on the node. Ê Enter the command ps ef grep http to check whether the Apache server is running. If the result is negative, start the Apache server using the following commands: 1. cd /etc/rc2.d 2. sh S97SIapache The WSA screen is not correct, applications are missing. Ê Change the browser settings for the cache and proxy. 1. Navigate to Edit Preferences Advanced Cache and manually empty the two caches. Furthermore, under the heading Document in cache is compared to document on network, select the entry Every time. 2. Disable the proxy configuration in the plug-in control panel (the plugin control panel can be found in the Programs menu under the Start button on the task bar). When WSA is started, a message appears to the effect that the selected application is already running and it is only possible to work in read mode, although no other user is working with WSA. Ê Start the following command on all management servers: clos_unlock -CDOMADMIN -f -p WSA_<application> You have to use the name of the relevant application for WSA_<application>, thus for example WSA_vconf, WSA_vdiag etc. See also the clos_unlock(1m) manual page for the command. If WSA is used intensively for several days, there may be a bottleneck in the PC s virtual memory. Ê Use the task manager to check the resource usage and terminate and restart the Web browser if necessary. 212 U41232-J-Z

221 Solving problems Performance problems There are locations on the WSA screen where it appears that buttons cannot be clicked with the mouse. Ê Click various areas of the button or reposition the WSA window. The automatic column width calculation does not always work properly. Ê Manually correct the column width using the mouse. Messages are sometimes truncated in the case of the confirmation and error box with the result that they cannot be read fully. Ê Use the mouse to enlarge the boxes. When an event is confirmed (e.g. node status change) the data is not always automatically reloaded. Ê Perform a Refresh using the View menu option on the menubar. When the Web browser has been terminated, the Windows temp directory (C:\windows\temp) still contains files called jar_cachexxx.jar. This may cause a memory bottleneck on the relevant drive. Ê Delete the files. 9.2 Performance problems In order to exclude the possibility of performance problems, you should make sure initially that hardware requirements are fulfilled optimally. In other words, you should use a PC system with a 500-MHz Pentium III processor and 256 MB RAM as the administration desktop. Furthermore, you should be aware that the performance is not dictated by the number of nodes in a domain rather by the number of objects being managed (number of cabinets, disks and vdisks). A domain is under pressure and the response times are much too slow. WSA always waits until the last node in a domain has supplied its data (rule: the slowest node in the domain determines the overall speed). Ê Resolve the performance problem on the slow node. U41232-J-Z

222 Performance problems Solving problems After you added a node to a domain, the response times are slow. With the increase in the number of objects to be managed, the memory and the performance of the PC are impaired. Ê Increase the performance of the PC (main memory extension, faster processor). After a lengthy session with many actions, the response time behavior deteriorates. The Web browser has a high memory requirement and the output and messages in the WSA interface are not plausible. Ê Quit and then restart both the browser and all its applications as well as WSA. 214 U41232-J-Z

223 10 Appendix I 10.1 MIB file wsatrap.mib The WebSysAdmin SNMP subagent is implemented on the basis of the wsatrap.mib MIB. All information and trap types are defined in this file. The content of this file is outlined below. IMPORTS OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB enterprises FROM RFC1155-SMI; -- OID: SNI Server Management MIB nodes sni OBJECT IDENTIFIER ::= { enterprises 231 } sniproductmibs OBJECT IDENTIFIER ::= { sni 2 } wsaobjects OBJECT IDENTIFIER ::= { sniproductmibs 41 } wsainfo OBJECT IDENTIFIER ::= { wsaobjects 1 } -- OID: wsastate OBJECT IDENTIFIER ::= { wsaobjects 2 } -- OID: wsatrapparams OBJECT IDENTIFIER ::= { wsaobjects 3 } -- OID: The MIB objects wsamachinetype OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Model Name" := { wsainfo 1 } -- OID: wsanumberofcpu OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of CPUs" ::= { wsainfo 2 } -- OID: wsamemory OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Size of Memory in Megabyte" ::= { wsainfo 3 } -- OID: wsacputype OBJECT-TYPE U41232-J-Z

224 MIB file wsatrap.mib Appendix I SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Architecture of CPU" ::= { wsainfo 4 } -- OID: wsacpufrequency OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Frequency of CPU" ::= { wsainfo 5 } -- OID: wsaserveruptime OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Uptime of Server System" ::= { wsainfo 6 } -- OID: wsalarstatus OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Status of LAR events" ::= { wsastate 1 } -- OID: wsanodestatus OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Node is in the cluster or not" ::= { wsastate 2 } -- OID: wsarunning OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "WSA is running/not running" ::= { wsastate 3 } -- OID: wsaservername OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "" ::= { wsatrapparams 1 } -- OID: wsatraptime OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "" 216 U41232-J-Z

225 Appendix I MIB file wsatrap.mib ::= { wsatrapparams 2 } -- OID: wsalarcomment OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Comment item in LAR event" ::= { wsatrapparams 3 } -- OID: wsahwconfaddr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Comment item in LAR event" ::= { wsatrapparams 4 } -- OID: LAR format in file hwerrors -- The LAR format describes the failure or startup of a -- HW component: <node>:<action>:<addr.type>:<address>:<flag>:<value>:<id>:<time>:<comment> -- action := +1 = Defect flag was set = Defect flag was deleted = Error flag was set = Error flag was deleted wsalarhardwaredefectset TRAP-TYPE ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime,wsahwconfaddr } DESCRIPTION "Sent if Hardware Defect Flag is set" ::= 1 wsalarhardwaredefectunset TRAP-TYPE ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime,wsahwconfaddr } DESCRIPTION "Sent if Hardware Defect Flag is deleted" ::= 2 wsalarhardwareerrorset TRAP-TYPE ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime,wsahwconfaddr } DESCRIPTION "Sent if Hardware Error Flag is set" ::= 3 wsalarhardwareerrorunset TRAP-TYPE ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime,wsahwconfaddr } DESCRIPTION "Sent if Hardware Error Flag is deleted" ::= 4 wsaagentstart TRAP-TYPE ENTERPRISE wsaobjects VARIABLES { wsaservername } DESCRIPTION "Sent when agent starts" ::= 5 wsaerrorrepair TRAP-TYPE U41232-J-Z

226 Events/SNMP traps Appendix I ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime,wsahwconfaddr } DESCRIPTION "Sent when some error condition is repaired" ::= 6 wsadefectrepair TRAP-TYPE ENTERPRISE wsaobjects VARIABLES {wsaservername,wsalarcomment,wsatraptime, wsahwconfaddr } DESCRIPTION "Sent when some defect condition is repaired" ::= 7 wsanodestatusintegrated TRAP-TYPE ENTERPRISE wsaobjects VARIABLES { wsaservername, wsatraptime, wsanodestatus } DESCRIPTION "Node is present or not" ::= 24 wsanodestatusnotavail TRAP-TYPE ENTERPRISE wsaobjects VARIABLES { wsaservername, wsatraptime, wsanodestatus } DESCRIPTION "Node is not available" ::= 25 wsanodestatusnotrunning TRAP-TYPE ENTERPRISE wsaobjects VARIABLES { wsaservername, wsatraptime, wsanodestatus } DESCRIPTION "Node is not running" ::= 26 END 10.2 Events/SNMP traps The traps sent by the SNMP agents can be split into two groups. One group contains traps that refer to hardware events in the monitored system, while the other group contains traps that describe the status of the systems in a cluster. The following additional parameters are provided for trap numbers 1 7: server name error comment trap time HW config address The server name is established by the uname function and indicates the name of the machine from which this trap has come. The error comment is made up of the logical or physical (<addr.type>) address of a component (<address>), combined with text describing the cause of the error (see table below). 218 U41232-J-Z

227 Appendix I Events/SNMP traps The trap time, i.e. the time at which the status change occurred, is established from the entry <time>. The HW config address is taken from the entry <address> and contains a character string in the form "hostname:addr-type:address". This represents a unique reference to the source and cause of the hardware error. Error comment tables: addr.type hardware address *) hardware component error comment for error/defect error comment for repair "P" or "K" (on Enterprise Server) E.6.* power supplies in M200 - M600 and M800 - M2000 "Power Supply Failure in Cabinet xxx" "Power Supply Defect in Cabinet xxx" "Power Supply Repair in Cabinet xxx" "Power Supply Defect Repair in Cabinet xxx" E.7.* fan units in M200 -M600 and M800 - M2000 "Fan Failure in Cabinet xxx" "Fan Defect in Cabinet xxx" "Fan Repair in Cabinet xxx" "Fan Defect Repair in Cabinet xxx" other addresses "Hardware Failure in Component xx in Cabinet xxx" "Hardware Failure Repair of Component xx in Cabinet xxx" "Hardware Defect in Component xx in Cabinet xxx" "Hardware Defect Repair of Component in Cabinet xxx" U41232-J-Z

228 Events/SNMP traps Appendix I addr.type logical disk address disk component name "L" valid entry will be established unknown entry will be taken from HWErrors error comment for error/defect "Disk Failure in <name>" "Disk Defect in <name>" "Disk Failure in <log.addr>" "Disk Defect in <log.addr>" error comment for repair "Disk Failure Repair of <name>" "Disk Defect Repair of <name>" "Disk Failure Repair of <log.addr>" "Disk Defect Repair of <log.addr.>" *) Note on hardware address: The letter "E" is a wildcard for a multi-position number for identifying the cabinet. 220 U41232-J-Z

229 11 Appendix II 11.1 Configuring the SNMP EMANATE master agent In order to integrate SNMP in WebSysAdmin, the SNMP and the SNMP agent have to be configured in a certain way to define, for example, where or more precisely to which IP addresses SNMP traps are sent. The configuration of the EMANATE master agent that is required for WebSysAdmin is described below. U41232-J-Z

230 Configuring the SNMP EMANATE master agent Appendix II SNMP agent architecture within WebSysAdmin The next figure shows the EMANATE master agent with the relevant subagents for WebSysAdmin as well as their configuration files. Figure 178: EMANATE master agent and subagent on a node 222 U41232-J-Z

231 Appendix II Configuring the SNMP EMANATE master agent The next figure shows the interaction between the SNMP components within WebSysAdmin. Figure 179: EMANATE master agent, trap events and management stations U41232-J-Z

232 Configuring the SNMP EMANATE master agent Appendix II Security mechanisms for SNMP A type of mutual access code must be agreed in order to access data via get/set requests as well as to exchange traps. Various security protocols are defined for this purpose for SNMP: SNMPv1, SNMPv2c Authorization via a community; communities can define read-only (Get, GetNext, Trap) or read-write access (Get, GetNext, Set, Trap); public and private are co-called standard communities in this model. Party-based SNMPv2 Better authorization mechanism than SNMPv1; now history. SNMPv2* Authorization via users and passwords; forerunner to SNMPv3. SNMPv3 Clearly improved authorization and security mechanisms (via users and passwords with a fine level of access granularity). Each message sent to the agent from the SNMP manager is checked according to the following criteria: Who is sending the message? (who?, authentication) What operation is requested? (what?, authorization) Which objects in the MIB are affected by the operation? (where?, access check) How was the request sent? (how?, security level) The security system compares the message with the security configuration at the agent. Depending on the result of this comparison, the security system then permits execution of the request operation or rejects it. The following figure outlines the security mechanism. 224 U41232-J-Z

233 Appendix II Configuring the SNMP EMANATE master agent Figure 180: Drawing of security mechanism Extended security mechanisms in SNMPv3 The current version of the SNMP management system uses elements of the comprehensive security concept of SNMPv3. It does not matter whether the SNMP manager sends the message as snmpv1 or SNMPv3 requests in this context. Compared to the original SNMPv1 security mechanisms, the security concept now adopted offers the following extensions: Selective assignment of access rights for MIB variables Definition of access rights for a group of management stations U41232-J-Z

234 Configuring the SNMP EMANATE master agent Appendix II Detailed trap reception Authentication of SNMP requests Selective assignment of access rights for MIB variables In earlier version of the SNMP management system for, which were based only on SNMPv1 security mechanisms, only the same access rights could be assigned for all MIB variables. Thus, a community string with defined write access had write access to all MIB objects that were defined as modifiable in its MIB. The same applied analogously for read access: either all MIB objects could be read, or none. The current version of the SNMP management system enables a community string to restrict read and/or write access to a particular MIB branch. For example, you can define a community string with read access for all MIB-Ι Ι Objects, but only write access for objects of the system group defined as modifiable in the MIB-Ι Ι, except for sysname. The access definition can even be defined on the instance level. In this way, you can restrict access to the second instance of the interface table, for example. Defining access rights to a group of management stations In earlier versions, it was also possible to restrict the permission to send request to individual management stations. This entailed entering the community string along with the IP address of the host in the configuration file for each host to be granted the permission. To extend the access rights to a subset of management stations, however, you had to enter " ", which granted access to all hosts. Now, in the current version, it is possible to specify a family of IP addresses via a bit mask, which then have access via the defined community string. Example: You can define a community string to grant access to the agents of systems with the IP addresses Detailed trap reception In earlier security versions, traps were always sent to all the trap destinations defined in the security configuration. In contrast, the current version allows you to define the IP address of the system according to enterprise and trap number. Example You can specify that all traps with enterprises sni.2.34 are to be sent to system U41232-J-Z

235 Appendix II Configuring the SNMP EMANATE master agent Request authentication Management stations that send their request via the SNMPv3 protocol can authenticate their message. This enables the agent to check that the message has neither been changed nor held back in the meantime Configuration steps The security configuration for an agent encompasses the following steps: 1. a) User configuration The user configuration depends on the security model and is carried out for SNMPv1 by a communityentry (currently standard), for SNMPv3 by an usmuserentry, for HTTP by an httpusernameentry. 1. b) Configuration of the access check 1. vacmviewtreefamiliyentry defines an MIB branch. 2. vacmaccessentry defines a security group and this group is assigned the MIB branches defined at 1) for read and write access and for the trap. 3. vacmsecuritytogroupentry assigns the user configured at a) to a security group. 1. c) snmptargetaddressentry performs the access check. U41232-J-Z

236 Configuring the SNMP EMANATE master agent Appendix II 2. a) Definition of trap destinations 1. snmpnotifyentry defines a notify entry. 2. snmptargetaddrentry assigns the notify entry to a target address and a target parameter entry. 3. snmptargetparamsentry defines a target parameter with community string. 2. b) Configuration of the access check 1. vacmviewtreefamiliyentry defines an MIB branch. 2. vacmaccessentry defines a security group and this group is assigned the MIB branches defined at 1) for read and write access and for the trap. 3. vacmsecuritytogroupentry assigns the community string (a3), with which the trap is to be sent, to a security group. 2. c) snmpnotifysourceentry specifies the sender address of the trap Configuration file snmpd.cnf All information relevant for the security configuration is entered in the form of security entries in the configuration file /etc/snmp/agt/snmpd.cnf. Each security entry in snmpd.cnf has the following format: TAG value Meaning: TAG specifies the type of security entry value specifies a valid value for the configuration. Syntax conventions The following conventions are used in the section below to describe the security entries: Items in Bold type must not be changed. Items in italics must be replaced in snmpd.cnf by the current values. The characters [, ], (, ), *, are meta characters and must not be specified in snmpd.cnf. 228 U41232-J-Z

237 Appendix II Configuring the SNMP EMANATE master agent Items enclosed in square brackets "[... ]" must not be specified. Instead, you can specify "-" for these items in snmpd.cnf the default value then applies. Item enclosed in round brackets "(...)" and delimited with " " represent alternatives; exactly one item must be specified. Items marked with an asterisk (*) are keywords, which uniquely define the relevant entry. Entries in snmpd.cnf can extend over several lines, if a backslash (\) is placed at the end of the line to indicate that it continues. Blanks, spaces and carriage returns are ignored. Character strings that contain blanks must be enclosed in double-quotes ("...") Definition of access to the agent via SNMPv1 requests a) Definition of a community string - communityentry The communityentry defines a community string and assigns it a security group and a transport label. Tag: communityentry Value: localsnmpld MyCommunity MyGroup localsnmpld - [MyTransTag] nonvolatile MyCommunity* Community string (String ) to be used for an SNMPv1 request. MyGroup Assigned security group (see b2). The security group defines the scope of authorization. MyTransTag Assigned transport label. The transport label refers to a list of target tags in snmptargetaddrentry see c) and thus defines the systems from which requests are accepted. Default value: no restriction of authorization U41232-J-Z

238 Configuring the SNMP EMANATE master agent Appendix II b) Definition of the access check b1) Definition of the MIB branch - vacmviewtreefamilyentry The definition of the MIB branch consists of one or more vacmviewtreefamily- Entry entries. Each vacmviewtreefamilyentry assigns an OID to the MIB branch or excludes an OID. Tag: Value: vacmviewtreefamilyentry MyMIB MyOID - (included excluded) nonvolatile MyMIB* Name of the MIB branch entry (String 1..32) MyOID* OID or symbolic name of the MIB branch to be included or excluded. included excluded The MIB branch is to be included or excluded. Only objects that result from all included or excluded operations remain in the MIB branch. b2) Definition of the security group - vacmaccessentry The vacmaccessentry defines a security group and assigns it MIB branches for read and write access. Tag: vacmaccessentry Value: MyGroup - snmpv1 noauthnopriv exact [MYRead] [MyWrite] - nonvolatile MyGroup* Name of the security group (String 1..32). The security group defines the scope of authorization. MyRead Assigned MIB branch for read access (see b1) MyWrite Assigned MIB branch for write access (see b1) 230 U41232-J-Z

239 Appendix II Configuring the SNMP EMANATE master agent b3) Definition of the security entry - vacmsecuritytogroupentry The vacmaccessentry defines a security group and assigns it MIB branches for read and write access. Tag: Value: vacmsecuritytogroupentry snmpv1 MyCommunity MyGroup nonvolatile MyCommunity* Community string (String ) to be used for an SNMPv1 request. MyGroup Assigned security group (see b2). The security group defines the scope of authorization. c) Definition of the address check - snmptargetaddrentry snmptargetaddrentry specifies the system from which access may be made. Tag: Value: snmptargetaddrentry MyTarget snmpudpdomain MyTaddr MyTagList - nonvolatile MyAddrMask MyTarget* Name of the target entry (String 1..32) MyTAddr Interne address of the target, i.e. the system which may access, in the form xxx.xxx.xxx.xxx:0 MyTagList List of tags (see a). The list must be enclosed in quotes ("..."); the individual list entries must be delimited by one blank. MyAddrMask Mask in the form xxx.xxx.xxx.xxx:0, analogous to a subnet mask. A sender address is valid if:) (sender address & MyAddrMask) == (MyTAddr & MyAddrMask) U41232-J-Z

240 Configuring the SNMP EMANATE master agent Appendix II Examples Example 1 All systems are to have read access with the community string "public". in SNMPv1 security (earlier versions): community public read 1 in SNMPv3 security (current version): communityentry localsnmpid public READ localsnmpid - - nonvolatile vacmsecuritytogroupentry snmpv1 public READ nonvolatile vacmaccessentry READ - snmpv1 noauthnopriv exact All - -\ nonvolatile vacmviewtreefamiliyentry All dod - included nonvolatile Example 2 System is to have write with the community string "master". in SNMPv1 security (earlier versions): community master write 1 in SNMPv3 security (current version): communityentry localsnmpid master WRITE localsnmpid -\ TarTag1 nonvolatile vacmsecuritytogroupentry snmpv1 master WRITE nonvolatile vacmaccessentry WRITE - snmpv1 noauthnopriv exact All All -\ nonvolatile vacmviewtreefamiliyentry All dod- included nonvolatile snmptargetaddrentry Ta1 snmpudpdomain : \ TarTag1 nonvolatile :0 232 U41232-J-Z

241 Appendix II Configuring the SNMP EMANATE master agent Example 3 The community string "multi" is to have read access from systems with the IP addresses to in SNMPv1 security (earlier versions): not settable in SNMPv3 security (current version): communityentry localsnmpid multi WRITE localsnmpid - TarTag2 \ nonvolatile vacmsecuritytogroupentry snmpv1 multi WRITE nonvolatile vacmaccessentry WRITE - snmpv1 noauthnopriv exact All All - \ nonvolatile vacmviewtreefamiliyentry All dod - included nonvolatile snmptargetaddrentry Ta2 snmpudpdomain \ : TarTag2 - nonvolatile :0 Example 4 All systems are to have read access to the system group only with the community string "sysread". in SNMPv1 security (earlier versions): not settable in SNMPv3 security (current version): communityentry localsnmpid sysread SysAccR localsnmpid - - \ nonvolatile vacmsecuritytogroupentry snmpv1 sysread SysAccR nonvolatile vacmaccessentry SysAccR - snmpv1 noauthnopriv exact SysTreeR - -\ nonvolatile vacmviewtreefamiliyentry SysTreeR system - included nonvolatile U41232-J-Z

242 Configuring the SNMP EMANATE master agent Appendix II Example 5 The community string "syswrite" is to have write access from all systems with Internet addresses The access should only be permitted to the system group, except for sysname. in SNMPv1 security (earlier versions): not settable in SNMPv3 security (current version): communityentry localsnmpid syswrite SysAccW localsnmpid - \ TarTag2 nonvolatile vacmsecuritytogroupentry snmpv1 syswrite SysAccW nonvolatile vacmaccessentry SysAccW - snmpv1 noauthnopriv exact \ SysTreeR SysTreeW - nonvolatile vacmviewtreefamiliyentry SysTreeR system - included nonvolatile vacmviewtreefamiliyentry SysTreeW system - included nonvolatile vacmviewtreefamiliyentry SysTreeW sysname - excluded nonvolatile snmptargetaddrentry Ta2 snmpudpdomain : \ TarTag2 - nonvolatile :0 The procedure for creating entries for the security configuration is outlined in figure 181 on the next page. 234 U41232-J-Z

243 Appendix II Configuring the SNMP EMANATE master agent syswrite communityentry localsnmpid syswrite SysAccW localsnmpid - TarTag2 nonvolatile vacmsecuritytogroupentry snmpv1 syswrite SysAccW nonvolatile vacmaccessentry SysAccW - snmpv1 noauthnopriv exact SysTreeR SysTreeW - \ nonvolatile vacmviewtreefamilyentry SysTreeR system - included nonvolatile vacmviewtreefamilyentry SysTreeW system - included nonvolatile vacmviewtreefamilyentry SysTreeW sysname - excluded nonvolatile snmptragetaddrentry Ta2 snmpudpdomain : TarTag2 - \ nonvolatile :0 Figure 181: Definition of the security string "syswrite" Definition of access to agent via SNMPv3 requests a) Definition of a SNMPv3 user - usmuserentry usmuserentry assigns a security group and a transport label to an SNMPv3 user. Tag: Value: usmuserentry localsnmpid MyUser MyAuthProt usmnoprivprotocol nonvolatile [MyTransTag] [MyAuthKey] U41232-J-Z

244 Configuring the SNMP EMANATE master agent Appendix II MyUser* User name (String 1..32) for which an SNMPv3 request is to be permitted. MyAuthProt Authentication protocol: usmnoauthprotocol (no authentication)) usmhmacmd5authprotocol (authentication) MyTransTag Assigned transport label. The transport label points to a target list (see e) and thus defines the systems from which requests are to be accepted. "-" means that there is no restriction. MyAuthKey Password for authentication.+ "-" means that there is no password. b) Definition of the access check b1) Definition of the MIB branch - vacmviewtreefamilyentry The definition of the MIB branch consists of one or more vacmviewtreefamily- Entry entries. Each vacmviewtreefamilyentry assigns an OID to the MIB branch or excludes an OID. Tag: Value: vacmviewtreefamilyentry MyMIB MyOID - (included excluded) nonvolatile MyMIB* Name of the MIB branch entry (String 1..32) MyOID* OID or symbolic name of the MIB branch to be included or excluded. included excluded The MIB branch is to be included or excluded. Only objects that result from all included or excluded operations in the MIB branch. 236 U41232-J-Z

245 Appendix II Configuring the SNMP EMANATE master agent b2) Definition of the security group - vacmaccessentry vacmaccessentry defines a security group and assigns it MIB branches for read and write access. Tag: vacmaccessentry Value: MyGroup - usm noauthnopriv exact [MyRead] [MyWrite] - nonvolatile MyGroup* Name of the security group (String 1..32). The security group defines the scope of authorization. MyRead Assigned MIB branch for read access (see b1) MyWrite Assigned MIB branch for write access (see b1) b3) Definition of the security entry - vacmsecuritytogroupentry vacmsecuritytogroupentry assigns a security group to the SNMPv3. Tag: Value: vacmsecuritytogroupentry usm MyUser MyGroup nonvolatile MyUser* User ID (Character-String ) that may make an SNMPv3 request. MyGroup Assigned security group (see b2). The security group defines the scope of authorization. U41232-J-Z

246 Configuring the SNMP EMANATE master agent Appendix II c) Definition of the address check - snmptargetaddrentry snmptargetaddrentry specifies the system for which access is to be granted. Tag: snmptargetaddrentry Value: MyTarget snmpudpdomain mytaddr MyTagList - nonvolatile MyAddrMask MyTarget* Name of the target entry (String 1..32) MyTAddr Internet address of the target in the form xxx.xxx.xxx.xxx:0 MyTagList List of tags (see a). This list must be enclosed in double-quotes ("..."); the individual list elements must be delimited by one blank. MyAddrMask Mask in the form xxx.xxx.xxx.xxx:0, analogous to a subnet mask. A sourceaddr is valid if: (sender address & MyAddrMask) == (MyTAddr & MyAddrMask) Example The user "guest" should have access to all objects via password authentication. In SNMPv3 security: usmuserentry localsnmpid guest usmnoauthprotocol \ usmnoprivprotocol nonvolatile - - vacmsecuritytogroupentry usm guest READ nonvolatile vacmaccessentry READ - usm authnopriv exact All - - nonvolatile vacmviewtreefamilyentry All dod - included nonvolatile The procedure for creating entries for the security configuration is outlined in figure 182 on the next page. 238 U41232-J-Z

247 Appendix II Configuring the SNMP EMANATE master agent guest usmuserentry localsnmpid guest usmnoauthprotocol usmnoprivprotocol nonvolatile - - vacmsecuritytogroupentry usm guest READ nonvolatile vacmaccessentry READ - usm authnopriv exact ALL - - nonvolatile vacmviewtreefamilyentry ALL dod - included nonvolatile Figure 182: Definition of SNMPv3 user guest Definition of access to an agent via HTTP requests a) Definition of a DR-Web user ID - httpusernameentry httpusernameentry assigns a security group and a password to a security group. Tag: Value: httpusernameentry MyUserName MyGroup - nonvolatile MyPassword MyUserName* User ID (String 1..32), under which an HTTP request may be made. MyGroup Assigned security group (see b2). The security group defines the scope of authorization. MyPassword Password: "-" means that no password is required for the defined user ID. U41232-J-Z

248 Configuring the SNMP EMANATE master agent Appendix II b) Definition of the access check b1) Definition of the MIB branch - vacmviewtreefamilyentry The definition of the MIB branch consists of one or more vacmviewtreefamily- Entry. Each vacmviewtreefamilyentry assigns an OID to the MIB branch or excludes an OID. Tag: Value: vacmviewtreefamilyentry MyMIB MyOID - (included excluded) nonvolatile MyMIB* Name of the MIB branch entry (String..32) MyOID* OID or symbolic name of the MIB branch (OID) included excluded The MIB branch is to be included or excluded. Only objects that result from all included or excluded operations in MIB branch. b2) Definition of the security group - vacmaccessentry vacmaccessentry defines a security group and assigns it MIB branches for read and write access. Tag: vacmaccessentry Value: MyGroup - http authnopriv exact [MyRead] [MyWrite] - nonvolatile MyGroup* Name of the security group (String 1..32). The security group defines the scope of authorization. MyRead Assigned MIB branch for read access (see b1) MyWrite Assigned MIB branch for write access (see b1) 240 U41232-J-Z

249 Appendix II Configuring the SNMP EMANATE master agent b3) Definition of the security entry - vacmsecuritytogroupentry vacmsecuritytogroupentry assigns a security group to the user ID. Tag: Value: vacmsecuritytogroupentry http MyUserName MyGroup nonvolatile MyUserName* User ID (String 1..32) with which an http request may be made. MyGroup Assigned security group (see b2). The security group defines the scope of authorization. Example The user "guest" is to be granted access to all MIB objects without password authentication. In DR-Web: httpusernameentry guest READ - nonvolatile - vacmsecuritytogroupentry http guest READ nonvolatile vacmaccessentry READ - http authnopriv exact All - - nonvolatile vacmviewtreefamilyentry All dod - included nonvolatile The next figure outlines the procedure for creating the entries in the security configuration. U41232-J-Z

250 Configuring the SNMP EMANATE master agent Appendix II guest httpusernameentry guest READ - nonvolatile - vacmsecuritytogroupentry http guest READ nonvolatile vacmaccessentry READ - http authnopriv exact ALL - - nonvolatile vacmviewtreefamilyentry ALL dod - included nonvolatile Figure 183: Definition of the DR-Web user guest Definition of the trap targets a) Definition of notify entry and target address a1) Definition of the notify entry - snmpnotifyentry Tag: Value: snmpnotifyentry MyNotify MyTransTag trap nonvolatile MyNotify* Name of the notify entry (String 1..32) MyTransTag Assigned transport label. The transport label points to a target list (see a2) and defines the systems to which the traps are to be sent. 242 U41232-J-Z

251 Appendix II Configuring the SNMP EMANATE master agent a2) Definition of the target address - snmptargetaddrentry snmptargetaddrentry assigns the notify entry (see a1) a target address and a target parameter. Tag: snmptargetaddrentry Value: MyTarget snmpudpdomain mytaddr MyTagList - nonvolatile MyAddrMask MyTarget* Name of the target entry (String 1..32) MyTAddr Internet address of the target in the form xxx.xxx.xxx.xxx:p; xxx.xxx.xxx.xxx denotes the IP address; p denotes the port (p=0: default value 162 for traps) MyTagList List of tags (see a). The list must be enclosed in quotes ("..."); the individual list entries must be delimited by one blank. MyTargetParam Assigned parameter entry (see a3) MyAddrMask Mask of the form xxx.xxx.xxx.xxx:0 (analogous to a subnet) A target address is valid if: (target address & MyAddrMask) == (MyTAddr & MyAddrMask) U41232-J-Z

252 Configuring the SNMP EMANATE master agent Appendix II a3) Definition of the Target-Parameter - snmptargetparamsentry A target parameter is defined for each snmptargetparamsentry. Tag: Value: snmptargetparamsentry MyTargetParam 0 snmpv1 MyCommunity noauthnopriv nonvolatile MyTargetParam* Name of the target parameter entry (String 1..32) MyCommunity Community string with which the trap is to be sent. The community string also defines the security entry (see b3). b) Definition of the access check b1) Definition of the MIB branch: vacmviewtreefamilyentry The definition of the MIB branch consists of one or more vacmviewtreefamilyentry. Each vacmviewtreefamilyentry* assigns an OID to the MIB branch or excludes an OID. Tag: vacmviewtreefamilyentry Value: MyTrap MyOID - (included excluded) nonvolatile MyTrap* Name of the MIB branch entry (String 1..32) MyOID* OID or symbolic name of the MIB branch (OID) included excluded The MIB branch is to be included / excluded. Only objects that remain as the result of all included /excluded operations are compared with the Enterprise and the variable bindings of the trap. If the MIB contains Enterprises and variable binding, the trap is sent. 244 U41232-J-Z

253 Appendix II Configuring the SNMP EMANATE master agent b2) Definition of the security group - vacmaccessentry vacmaccessentry defines a security group and assigns it MIB branch for read and write access. Tag: Value: vacmaccessentry MyGroup - snmpv1 noauthnopriv exact - - MyTrap nonvolatile MyGroup* Name of the security group (String 1..32) MyTrap MIB branch assigned to the trap (see b1) b3) Definition of the security entry: vacmsecuritytogroupentry vacmsecuritytogroupentry assigns a security group to the community string. Tag: Value: vacmsecuritytogroupentry snmpv1 MyCommunity MyGroup nonvolatile MyCommunity* Community string (String 1-32) with which the trap is to be sent. MyGroup Assigned security group (see b2). The security group defines whether or not access is granted. c) Definition of the sender address of a trap - snmpnotifysourceentry snmpnotifysourceentry defines which sender addresses are to be used for which trap targets. Definition of the sender address is optional. Tag: Value: snmpnotifysourceentry MyNotifySource MyTagList MySourceAddr nonvolatile MyNotifySource* Name of the notifysource entry (String 1..32) U41232-J-Z

254 Configuring the SNMP EMANATE master agent Appendix II MyTagList List of tags (see a) on page 242). This list must be enclosed in doublequotes ("..."); the individual list elements must be delimited by one blank. MySourceAddr Desired sender address for the trap in the form xxx.xxx.xxx.xxx Examples Example 1 Traps should be sent to host with community string "tcom". in SNMPv1 security: trap tcom in SNMPv3 security: snmpnotifyentry Nf1 TarTag1 trap nonvolatile snmptargetaddrentry Ta1 snmpudpdomain : \ TarTag1 Tp1 nonvolatile snmptargetparamsentry Tp1 0 snmpv1 tcom noauthnopriv \ nonvolatile vacmsecuritytogroupentry snmpv1 tcom TRAP nonvolatile vacmaccessentry TRAP -snmpv1 noauthnopriv exact -- All \ nonvolatile vacmviewtreefamiliyentry All dod - included nonvolatile Example 2 Traps are to be sent to system with the IP addresses to with the community string "tcom". in SNMPv1 security (earlier versions): not settable in SNMPv3 security (current version): snmpnotifyentry Nf2 TarTag2 trap nonvolatile snmptargetaddrentry Ta2 snmpudpdomain : \ TarTag2 Tp1 nonvolatile :0 snmptargetparamsentry Tp1 0 snmpv1 tcom noauthnopriv \ nonvolatile vacmsecuritytogroupentry snmpv1 tcom TRAP nonvolatile vacmaccessentry TRAP - snmpv1 noauthnopriv exact - - All \ nonvolatile vacmviewtreefamiliyentry All dod - included nonvolatile 246 U41232-J-Z

255 Appendix II Configuring the SNMP EMANATE master agent Example 3 Traps with Enterprises sni.2.34 are to be sent to the system with IP addresses with the community string "tent". The traps with the specific trap number 33 should not be considered. in SNMPv1 security (earlier versions): not settable in SNMPv3 security (current version): snmpnotifyentry Nf3 TarTag3 trap nonvolatile snmptargetaddrentry Ta3 snmpudpdomain : \ TarTag3 Tp3 nonvolatile :0 snmptargetparamsentry Tp3 0 snmpv1 tent noauthnopriv nonvolatile vacmsecuritytogroupentry snmpv1 tent EpAcc nonvolatile vacmaccessentry EpAcc - snmpv1 noauthnopriv exact - - EpTreeT \ nonvolatile vacmviewtreefamiliyentry EpTreeT sni included nonvolatile vacmviewtreefamiliyentry EpTreeT sni excluded \ nonvolatile The procedure for creating entries for the security configuration is outlined in figure 184 on the next page. U41232-J-Z

256 Configuring the SNMP EMANATE master agent Appendix II snmpnotifyentry Nf3 TarTag3 trap nonvolatile snmptragetaddrentry Ta3 snmpudpdomain : TarTag3 Tp3 \ nonvolatile :0 snmptargetparamsentry Tp3 0 snmpv1 tent noauthnopriv nonvolatile vacmsecuritytogroupentry snmpv1 tent EpAcc nonvolatile vacmaccessentry EpAcc - snmpv1 - noauthnopriv exact - - EpTreeT nonvolatile vacmviewtreefamilyentry EpTreeT sni included nonvolatile vacmviewtreefamilyentry EpTreeT sni excluded nonvolatile Figure 184: Definition of a trap target Example 4 Traps to host should be sent with the sender address in SNMPv1 security (previous versions): trap public in SNMPv3 security (current version): snmpnotifyentry Nf1 TarTag1 trap nonvolatile snmptargetaddrentry Ta1 snmpudpdomain : \ TarTag1 Tp1 nonvolatile snmptargetparamsentry Tp1 0 snmpv1 tcom noauthnopriv \ nonvolatile snmpnotifysourceentry NfS1 TarTag nonvolatile vacmsecuritytogroupentry snmpv1 tcom TRAP nonvolatile vacmaccessentry TRAP - snmpv1 noauthnopriv exact - - All \ nonvolatile vacmviewtreefamiliyentry All dod - included nonvolatile 248 U41232-J-Z

257 Appendix II Configuring the SNMP EMANATE master agent Example # User configuration communityentry localsnmpid public READ localsnmpid - - nonvolatile communityentry localsnmpid master WRITE localsnmpid - TarTag1 nonvolatile communityentry localsnmpid multi WRITE localsnmpid - TarTag2 nonvolatile communityentry localsnmpid sysread SysAccR localsnmpid - - nonvolatile communityentry localsnmpid syswrite SysAccW localsnmpid - - nonvolatile usmuserentry localsnmpid gast usmnoauthprotocol usmnoprivprotocol nonvolatile - - httpusernameentry guest READ - nonvolatile - snmpnotifyentry Nf1 TarTag1 trap nonvolatile snmpnotifyentry Nf2 TarTag2 trap nonvolatile snmpnotifyentry Nf3 TarTag3 trap nonvolatile # Configuration of the access check vacmviewtreefamilyentry All dod - included nonvolatile vacmviewtreefamilyentry SysTreeR system - included nonvolatile vacmviewtreefamilyentry SysTreeW system - included nonvolatile vacmviewtreefamilyentry SysTreeW sysname - excluded nonvolatile vacmviewtreefamilyentry EpTreeT sni included nonvolatile vacmviewtreefamilyentry EpTreeT sni excluded nonvolatile vacmaccessentry READ - snmpv1 noauthnopriv exact All - - nonvolatile vacmaccessentry WRITE - snmpv1 noauthnopriv exact All All - nonvolatile vacmaccessentry SysAccR - snmpv1 noauthnopriv exact SysTreeR - - nonvolatile vacmaccessentry SysAccW - snmpv1 noauthnopriv exact SysTreeR SysTreeW - nonvolatile vacmaccessentry TRAP - snmpv1 noauthnopriv exact - - All nonvolatile vacmaccessentry EpAcc - snmpv1 noauthnopriv exact - - EpTreeT nonvolatile vacmaccessentry READ - usm noauthnopriv exact All - - nonvolatile vacmaccessentry READ - http AuthNoPriv exact All - - nonvolatile vacmsecuritytogroupentry snmpv1 public READ nonvolatile vacmsecuritytogroupentry snmpv1 master WRITE nonvolatile vacmsecuritytogroupentry snmpv1 multi WRITE nonvolatile vacmsecuritytogroupentry snmpv1 sysread SysAccR nonvolatile vacmsecuritytogroupentry snmpv1 tcom TRAP nonvolatile vacmsecuritytogroupentry snmpv1 tent EpAcc nonvolatile vacmsecuritytogroupentry usm guest READ nonvolatile vacmsecuritytogroupentry http guest READ nonvolatile # Configuration of the address check snmptargetaddrentry Ta1 snmpudpdomain : TarTag1 Tp1 nonvolatile :0 snmptargetaddrentry Ta2 snmpudpdomain : TarTag2 Tp1 nonvolatile :0 snmptargetaddrentry Ta3 snmpudpdomain : TarTag3 Tp3 nonvolatile :0 snmptargetparamsentry Tp1 0 snmpv1 tcom noauthnopriv nonvolatile snmptargetparamsentry Tp3 0 snmpv1 tent noauthnopriv # Sender address snmpnotifysourceentry NfS1 TarTag nonvolatile U41232-J-Z

258 Configuring the SNMP EMANATE master agent Appendix II Configuring the EMANATE master agent for WebSysAdmin You can edit the snmpd.cnf configuration file in two ways: either in the traditional way using a editor (vi) or from the edit box in WebSysAdmin. There are two steps involved here as we can see from the next figure. Switch to the VConfig application and select a node using the left mouse button. Then press the right mouse button and choose the Modify SNMP Agent Configuration action: Figure 185: Sub-menu for changing an SNMP agent configuration 250 U41232-J-Z

259 Appendix II Configuring the SNMP EMANATE master agent The following edit box opens: Figure 186: Edit box for changing an SNMP agent configuration Two additional nodes were selected as trap recipients in our example from the Node Selection field. In addition, a second destination address (entry tag snmptargetaddrentry) was added in the edit box with pick and put (marked in blue), the MyTarget parameter incremented and the MyTAddr parameter assigned the IP address of the trap recipient (for details see section Definition of the trap targets on page 242). Following editing, close the box by clicking Ok. For further details, please refer to the help text. U41232-J-Z

260 Configuring the SNMP EMANATE master agent Appendix II The /etc/snmp/agt/snmpd.cnf file The EMANATE master agent has to be configured as follows in WebSysAdmin: 1. Get requests A public or wsa community is required on every cluster node in order to integrate RMS. Read access must be defined locally for this community to all OIDs under iso, enterprises.231 or at least to the PRIMECLUSTER-specific data under enterprises and enterprises Sending/receiving traps No special community is required to send traps to the WSAtraprcv process. The WSAtraprcv process accepts traps in the format SNMPv1 or SNMPv2c. The set of traps relevant for WebSysAdmin must be defined via an appropriate entry in vacmviewtreefamilyentry. It can contain all OIDs under iso, all OIDs under enterprises.231 (sni) or simply the OIDs used by the SNMP agent integrated in WebSysAdmin. These trap sets are as follows: rmsagt all OIDs under enterprises and enterprises wsaagt all OIDs under enterprises The IP addresses of the trap recipients (management servers) must be entered in snmptargetaddrentry. These two actions are implemented as follows in the configuration file of the EMANATE master (snmpd.cnf): 252 U41232-J-Z

261 Appendix II Configuring the SNMP EMANATE master agent Get requests Read access is enabled via the wsa (SNMPv1) community from all systems to all OIDs under enterprises (sniproductmibs). Traps Traps are sent with the wsa (SNMPv1) community in SNMPv1 format for all OIDs under enterprises (except for wsaobjects) to the system with the IP address (default port 162: WSAtraprcv). U41232-J-Z

262 Configuring the SNMP EMANATE master agent Appendix II In addition, traps in SNMPv1 format are sent with the wsaagt community for OIDs under enterprises (wsaobjects) to the system with the IP address (different system, but likewise default port 162). 254 U41232-J-Z

263 Appendix II Configuring the SNMP EMANATE master agent The overall entries look as follows and can be used directly if the IP address is replaced in the snmptargetaddrentry entry by the address of the current WebSysAdmin trap recipient or management station (if there are several trap recipients, the relevant lines can be simply copied, the serial number increased and the IP address replaced): snmpcommunityentry cwsa wsa Wsaadm localsnmpid - - nonvolatile snmpcommunityentry cwsaagt wsaagt Wsaagt localsnmpid - - \ nonvolatile vacmsecuritytogroupentry snmpv1 wsa Wsaadm nonvolatile vacmsecuritytogroupentry snmpv1 wsaagt Wsaagt nonvolatile vacmsecuritytogroupentry snmpv2c wsa Wsaadm nonvolatile vacmsecuritytogroupentry snmpv2c wsaagt Wsaagt nonvolatile snmptargetparamsentry WsaMgmtParams 0 snmpv1 wsaagt \ noauthnopriv nonvolatile snmptargetparamsentry WsaTraprcvParams 0 snmpv1 wsa \ noauthnopriv nonvolatile vacmaccessentry Wsaadm - snmpv1 noauthnopriv exact FscAll - \ FscAll nonvolatile vacmaccessentry Wsaadm - snmpv2c noauthnopriv exact FscAll - \ FscAll nonvolatile vacmaccessentry Wsaagt - snmpv1 noauthnopriv exact WsaObj - \ WsaObj nonvolatile vacmaccessentry Wsaagt - snmpv2c noauthnopriv exact WsaObj - \ WsaObj nonvolatile vacmviewtreefamilyentry FscAll enterprises \ included nonvolatile vacmviewtreefamilyentry FscAll enterprises \ excluded nonvolatile vacmviewtreefamilyentry WsaObj enterprises \ included nonvolatile snmpnotifyentry 33 WsaTraprcv trap nonvolatile snmpnotifyentry 34 WsaMgmt trap nonvolatile snmptargetaddrentry 41 snmpudpdomain : \ WsaTraprcv WsaTraprcvParams nonvolatile :0 snmptargetaddrentry 42 snmpudpdomain : \ WsaMgmt WsaMgmtParams nonvolatile :0 snmptargetparamsentry WsaMgmtParams 0 snmpv1 wsaagt \ noauthnopriv nonvolatile snmptargetparamsentry WsaTraprcvParams 0 snmpv1 wsa \ noauthnopriv nonvolatile U41232-J-Z

264 Configuring the SNMP EMANATE master agent Appendix II I In order for changes to become effective, the EMANATE master agent must be stopped with the /etc/rc2.d/k38snmpdm stop command and restarted with /etc/rc2.d/k38snmpdm start after changing the configuration data. The /etc/snmp/mgr/snmpinfo.dat file The WebSysAdmin management servers that act as trap recipients must recognize the MIBs of the integrated SNMP agent in order to be able to display the relevant traps for reading. The WSAtraprcv process used by WSA trap recipients is based on the traprcv program from the company "SNMP Research" and uses the snmpinfo.dat file for performing mapping between OIDs and their MIB variable names. The MIB of the rmsagt subagent must be entered in the snmpinfo.dat file with the mergeinfo command for integrating RMS. This happens automatically when the SMAWrcmib and SMAWvrmS packages are installed Configuring the EMANATE agent for CA Unicenter integration Certain requirements must be fulfilled in order to configure the SNMP agent for CA Unicenter integration. The SNMP agents must be assigned parameters for this purpose via the /etc/snmp/agt/snmpd.cnf file.the requisite system object ID and the trap recipient can be set in this file. You will find further details in the chapter Integration in CA Unicenter TND on page 127. Setting the system object ID The SNMP system object ID is used to identify a system as belonging to a defined class. This ID is unique for every system class in a company. Before the agent is started, the UNIX administrator can set the system class. The system object ID (sysobjectid) must be set in the /etc/snmp/agt/snmpd.cnf file for this purpose: # Use of sysobjectid for CA-Integration: # yields proprietary PRIMEPOWER class # yields generic Solaris Host class sysobjectid The default is PRIMEPOWER. Use of the system object ID has the following impact on integration in CA Unicenter TND: 256 U41232-J-Z

265 Appendix II Configuring the SNMP EMANATE master agent The value is : The system registers itself as PRIMEPOWER hardware with CA Unicenter TND and is depicted accordingly. The value is : The system is depicted in CA Unicenter TND as a generic Solaris host. Setting the trap recipients The TCP/IP addresses of the system or systems that are to receive the SNMP traps must be configured. The IP addresses must be set in the /etc/snmp/agt/snmpd.cnf file for this purpose (see section Configuring the SNMP EMANATE master agent on page 221). U41232-J-Z

266

267 Abbreviations CD-ROM Compact Disk-Read Only Memory CA Computer Associates CDS++ C++ Development System CF CLI Cluster Foundation Command Line Interface CLODB Cluster Object Database CLOS Cluster Operating System COD CR CRL CSR DH DSA Cluster Object Database (archival file) Carriage Return Certificat Revocation List Certificate Signing Request Diffie Hellmann Digital Signature Algorithm U41232-J-Z

268 Abbreviations DSM Distributed State Machine EPMC Entertprise Management Cluster FDE HA HW ID IP File Device Equipment High Availability Hardware Identifier Internet Protocol JENV Java Runtime Environment JRE JVM LAN LAR MIB MS Java Runtime Environment Java Virtual Machine Local Area Network Lockout Auto Recovery Management Information Base Microsoft 260 U41232-J-Z

269 Abbreviations NFS OBP OID OPS Network File System Open Boot Program Object Identifier Oracle Parallel Server OPS-RES Oracle Parallel Server Resilvering PEM PFX PW RCI Privacy Enhanced Mail Personal Information Exchange Format PRIMEPOWER Remote Cabinet Interface RCS II Reliant Cluster Server II RMS RSA SCSI SMC Reliant Monitor Software Rivest Shamir Adlemann Small Computer Systems Interface Sytem Management Console U41232-J-Z

270 Abbreviations SPS Siemens Parallel Server TCP/IP Transmission Control Protocol/Internet Protocol TEC TND URL vdisk VGA WSA Tivoli Enterprise Console The Next Dimension Uniform Resource Locator virtual disk Video Graphics Adapter Web-based System Administration 262 U41232-J-Z

271 Index A activating event definition 121 reaction definition 121 administration desktop 4, 16 requirements 16 administration domain advantages 3 definition 3 hierarchical 5 authentication of requests 227 C checking packages for consistency 123 CLODB domain administration database 201 cloning event definition 119 reaction definition 121 user 49 communication name, changing the 52 consistency checking of packages 123 control CD installation 6 creating event definition 117 reaction definition 120 user 42 vdisk 201 D deleting user 47 detailed trap reception 226 diagnostics 113 domain creating (enterprise server) 55 creating (general) 53 name 55 DomainAdmin add-on product 1 installation 6 domain-wide configuring events 117 creating events 117 E event definition activating 121 cloning 119 creating 117 F FDE, positioning the cabinet 99 H hierarchical administration domain 5 hierarchical browser (WebSysAdmin) 35 I installation control CD 6 DomainAdmin 6 WebSysAdmin 6 L LAN, alternative 52 M management server 51 menubar (WebSysAdmin) 33 MIB browser (SNMP) 77 N NFS access, domain-wide 79 node name, rename 18 nodes creating 59 U41232-J-Z

272 Index maximum number 59 moving 58 name 55 O object list (WebSysAdmin) 39 object table (WebSysAdmin) 39 P preferences setting 34 problems Netscape or WSA 211 performance 213 R reaction definition activating 121 cloning 121 creating 120 read mode 21 request, authentication 227 S security mechanisms for SNMP 224 selection configurator (WebSysAdmin) 35 SNMP configuring the agent 256 SNMP request authentication 227 snmpd.cnf, configuration file 228, 252, 256 software versions checking 122 displaying 122 starting WebSysAdmin 21 sub-tab bar (WebSysAdmin) 39 detailed 226 troubleshooting general 114 U user cloning 49 creating 42 deleting 47 V vdisk configuring on shared resources 207 creating (local) 201 W WebSysAdmin client 4 elements 32 hierarchical browser 35 installation 6 menubar 33 object list 39 object table 39 selection configurator 35 server 4 starting 21 sub-tab bar 39 tab bar 39 toolbar 33 write mode 21 T tab bar (WebSysAdmin) 39 toolbar (WebSysAdmin) 33 trap reception 264 U41232-J-Z

273 Fujitsu Siemens Computers GmbH User Documentation Paderborn Germany Fax: (++49) 700 / Comments Suggestions Corrections manuals@fujitsu-siemens.com Submitted by Comments on WebSysAdmin/DomainAdmin 2.1 System Administration within a Domain U41232-J-Z

274

275 Fujitsu Siemens Computers GmbH User Documentation Paderborn Germany Fax: (++49) 700 / Comments Suggestions Corrections manuals@fujitsu-siemens.com Submitted by Comments on WebSysAdmin/DomainAdmin 2.1 System Administration within a Domain U41232-J-Z

276

277 Information on this document On April 1, 2009, Fujitsu became the sole owner of Fujitsu Siemens Computers. This new subsidiary of Fujitsu has been renamed Fujitsu Technology Solutions. This document from the document archive refers to a product version which was released a considerable time ago or which is no longer marketed. Please note that all company references and copyrights in this document have been legally transferred to Fujitsu Technology Solutions. Contact and support addresses will now be offered by Fujitsu Technology Solutions and have the The Internet pages of Fujitsu Technology Solutions are available at and the user documentation at Copyright Fujitsu Technology Solutions, 2009 Hinweise zum vorliegenden Dokument Zum 1. April 2009 ist Fujitsu Siemens Computers in den alleinigen Besitz von Fujitsu übergegangen. Diese neue Tochtergesellschaft von Fujitsu trägt seitdem den Namen Fujitsu Technology Solutions. Das vorliegende Dokument aus dem Dokumentenarchiv bezieht sich auf eine bereits vor längerer Zeit freigegebene oder nicht mehr im Vertrieb befindliche Produktversion. Bitte beachten Sie, dass alle Firmenbezüge und Copyrights im vorliegenden Dokument rechtlich auf Fujitsu Technology Solutions übergegangen sind. Kontakt- und Supportadressen werden nun von Fujitsu Technology Solutions angeboten und haben die Die Internetseiten von Fujitsu Technology Solutions finden Sie unter und unter finden Sie die Benutzerdokumentation. Copyright Fujitsu Technology Solutions, 2009