Configure the TEPS. To Support

Size: px

Start display at page:

Download "Configure the TEPS. To Support"

Pierce Chambers
6 years ago
Views:

Interface Cards/Firewalls Document version 1.

1 Configure TEPS to support Multiple NICS-Firewalls.doc Mar 2012 Configure the TEPS To Support Multiple Network Interface Cards/Firewalls Document version 1.2 John Harris Copyright International Business Machines Corporation All rights reserved

2 SPECIAL NOTICES This document is presented As-Is and IBM does not assume responsibility for the statements expressed herein. It reflects the opinions of the IBM Tivoli organization and these opinions are based solely on the authors experiences. If you have questions about the contents of this document, please contact the author at Trademarks The following are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. IBM, the IBM logo, Candle, DB2, developerworks, iseries, Passport Advantage, pseries, Redbooks, Tivoli Enterprise Console, WebSphere, z/os, xseries, zseries, System z, z/vm, AIX. A full list of U.S. trademarks owned by IBM may be found at NetView, Tivoli and TME are registered trademarks and TME Enterprise is a trademark of Tivoli Systems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, Internet Explorer, and the Windows logo are registered trademarks of Microsoft Corporation in the United States and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. Intel and Pentium are registered trademarks and MMX, Pentium II Xeon and Pentium III Xeon are trademarks of Intel Corporation in the United States and/or other countries. Other company, product and service names may be trademarks or service marks of others. Copyright IBM Corporation, 2012

3 CONTENTS Special Notices...2 Revision History...1 Acknowledgments...2 Introduction...3 Linux/Unix...5 Windows...6 Client Connections...8 Desktop Client Connections...8 Browser Client Connection...10 Java WebStart Client Connection...11 Addendum...12 How to configure the TEPS and TEP to work through firewall rules and with SSL encryption enabled...13 Copyright IBM Corporation, 2012 iii

4 REVISION HISTORY Date Version Revised By Comments 17 March JH Completed final draft for review 19 March JH Added additional reference information 21 March JH Added information due to port no/file name changes Copyright IBM Corporation,

5 ACKNOWLEDGMENTS Thanks to the following person(s) for their invaluable assistance. Robert Proffitt and Ronald Fain 2

6 Introduction The following document describes the process of configuring the Tivoli Enterprise Portal Server (TEPS) on Linux/Unix and Windows in order to support client (TEP) connections across multiple network interface cards (NICS). This will provide a level of QOS and/or load balancing across the network whereby client connections can be divided among the installed interfaces either logically based upon a particular network segment or location. Another case would be a server that has a NIC that allows communication with the public internet. Someone outside the company network running portal client must only use a network interface and all responses must go through that particular NIC. Another example would be an outsourcing company providing services for several other companies. Each company could want to have its own protected communications. The following variables are required in order to add support for additional NICs. KFW_INTERFACE_<interface_name>_HOST= The above variable is used when there is more than one NIC on the server running the TEPS and you need to restrict Portal client connections to a specific network interface. It is typically given as a numeric TCPIP address. KFW_INTERFACE_<interface_name>_PORT= The following variable defines the port number for incoming IIOP [CORBA] communications traffic at the TEPS. The values are typically set to 15001, 15002, 15003, etc. KFW_INTERFACE_<interface_name>_SSL=N/Y If the value is N, no security is used. If it is Y, then the initial communication takes place using the https communications protocol. The second stage CORBA communications uses a certificate which is built-in to one of the jar files which is transmitted across during the initial connection. If you are using nondefault security certificate, the documentation shows how to accomplish that. The TEP to TEPS communication uses two different methods. At startup, the TEP uses HTTP to an internal or external web server. If no firewall is involved and the default port numbers are in use, this would be the hostname which resolves to that address and port After startup, the portal client uses CORBA IIOP communications. During the startup phase, the client retrieves an Interoperable Object Reference [IOR] file from the TEPS. The IOR contains the IP address and port number to be used to connect to the server. This is the IP address and port number which the portal client will use to contact the TEPS and will be the IP address of the machine running the portal server and port The IOR file(s) can be found in the following locations respectively Linux/Unix <installdir>/<arch>/cw Windows <installdir>\cnb 3

7 If you experience any connection problems, here is a URL that can be used to parse the IOR record. Use it to verify that the ior record is presenting the correct ip address and port number. 4

8 Linux/Unix Perform the following steps in order to add multiple NICs to the TEPS configurations for a TEPS server that has 2 NICs with the following IP addresses, namely and 9.9.l On the TEPS server modify the file [<install-dir>/<arch-dir>/cq/bin/lnxenv] <installdir>/config/cq.ini file as follows: Locate the KFW_INTERFACES= variable and add the one-word name of the new interface, separating it from the preceding name by a space. For example: KFW_INTERFACES=cnps cnps2 2. To avoid any communication issues, add the standard interface section for the above default entry (cnps) if it does not already exist KFW_INTERFACE_cnps_HOST= Define he interface for second NIC or different IP address on this computer, specify the TCP/IP host address. KFW_INTERFACE_cnps2_HOST= Type a port number for the TEPS, the values are typically set to 15001, 15002, 15003, etc.. The default is for the server host address, so a second host IP address requires a different port number. KFW_INTERFACE_cnps2_PORT= If you are using secured connections across the infrastructure ensure that SSL is turned on by setting that value to Y, otherwise make it N KFW_INTERFACE_cnps2_SSL=N After performing the above steps for the sample IP addresses the resultant the file should look something like this: KFW_INTERFACES=cnps cnps2 KFW_INTERFACE_cnps_HOST= KFW_INTERFACE_cnps_PORT=15001 KFW_INTERFACE_cnps_SSL=N KFW_INTERFACE_cnps2_HOST=9.9.l KFW_INTERFACE_cnps2_PORT=15002 KFW_INTERFACE_cnps2_SSL=N 5

Windows Perform the following steps in order to add multiple NICs to the TEPS configurations for a TEPS server that has 2 NICs with the following IP addresses, namely 192.168.0.1 and 9.9.l48.

9 Windows Perform the following steps in order to add multiple NICs to the TEPS configurations for a TEPS server that has 2 NICs with the following IP addresses, namely and 9.9.l From the Tivoli Management Service applet, right click on the Tivoli Enterprise Portal Server and select Advanced--->Configure TEPS Interfaces as shown in Figure 1 below. Figure 1. 6

$Press OK in order to save the above information which will result in the following variable definitions applied the file <install-dir>\cnps\kfwenv KFW_INTERFACES=cnps cnps2$

10 2. The add/edit the IP Addresses and Port numbers as shown in Figure 2 below Figure 2. Press OK in order to save the above information which will result in the following variable definitions applied the file <install-dir>\cnps\kfwenv KFW_INTERFACES=cnps cnps2 KFW_INTERFACE_cnps_HOST= KFW_INTERFACE_cnps_PORT=15001 KFW_INTERFACE_cnps_SSL=N KFW_INTERFACE_cnps2_HOST=9.9.l KFW_INTERFACE_cnps2_PORT=15002 KFW_INTERFACE_cnps2_SSL=N The above procedure will also create the following file cnp2s.ior in the <install-dir>/cnb directory for you with no further actions required. 7

Client Connections Desktop Client Connections After applying the above configuration, use the following URLs to connect to the TEPS on either of the Networks Interface Cards by configuring the TEP

11 Client Connections Desktop Client Connections After applying the above configuration, use the following URLs to connect to the TEPS on either of the Networks Interface Cards by configuring the TEP client with the applicable IP address as shown in Figure 3 below. Figure 3. Additional client connections can be configure by creating a new instance as shown in Figure 4 below and supplying the applicable IP address for that connection as shown above. 8

12 Figure 4 9

Browser Client Connection After applying the above configuration, use the following URLs to connect to the TEPS on either of the Networks Interface Cards, with the results displayed in Figure 5 below.

13 Browser Client Connection After applying the above configuration, use the following URLs to connect to the TEPS on either of the Networks Interface Cards, with the results displayed in Figure 5 below. or Figure 5. The Browser client sets up the access entirely in the URL. For a non-firewall environment it would look like For a firewall connection it would look like 10

14 Java WebStart Client Connection The Java Web Start process is configured using a jnlp file. In ITM 6.2x the default is tep.jnlp. Using the above configuration examples begin by cloning tep.jnlp file into cnps2.jnlp, which can be found in the following locations Linux/Unix <installdir>/<arch>/cw Windows <installdir>\cnb Edit the copied cnps2.jnlp file and make the following changes 1.Change the line containing the href reference to point to the new jnlp file as follows href="tep.jnlp" to href="cnps2.jnlp" 2.Add a Databus property in last <resources> tag section just before the  tag section as follows. <property name="cnp.http.url.databus" value=" ///cnp/kdh/lib/cnps2.ior"/> Note Perform the above configuration steps every time the TEPS is updated with any new application support files. Create a separate jnlp file for each network interface The identification of ports 15001, 15002, etc as the CORBA port is included in the xxxx.ior files that will be downloaded by the client from above URLs. You can create multiple shortcuts to launch Portal Client via Java Web Start identifying the applicable NIC and jnlp file by specifying the following commands: "C:\Program Files\IBM\Java50\jre\bin\javaws.exe" :1920///cnp/kdh/lib/tep.jnlp or "C:\Program Files\IBM\Java50\jre\bin\javaws.exe" 11

15 Addendum The following link describes configuring the TEP client to the TEPS communication through firewalls and SSL which is similar to the above process. A local copy of the techdoc link below is included on the next page. The tep.jnlp is constructed from the tep.jnlpt template file located in the following directories: Windows : <install_dir>\config\tep.jnlpt Linux/Windows : <install_dir>/config/tep.jnlpt 12

16 How to configure the TEPS and TEP to work through firewall rules and with SSL encryption enabled The ITM Portal server default configuration defines access to any Portal Client in the local network. For simple firewall cases, you need rules to allow access to/from ports 1920 and and everything will work fine. For more complex environments, you need Tivoli Enterprise Portal Server Interfaces [TEPSI]. TEPSI are software definitions of how the TEPS can be accessed. One TEPSI is needed for every environment a portal client might be deployed into. Start by seeing how an interface is defined first from Linux/Unix since the presentation is easier to explain. The same rules apply to Windows. The Linux/Unix case is presented in a section of the ITM Installation and Setup Guide quoted below. Afterwards, a series of notes follow that further explain details. Please review all the material before proceeding to the configuration. m#wq698 The instructions work with all versions of ITM 6.x <Begin quote from manual> "Defining a Tivoli Enterprise Portal Server interface on Linux or UNIX To define an additional Tivoli Enterprise Portal interface on Linux or UNIX, edit the <install_dir>/<platform_dir>/cq/bin/lnxenv file as follows: 1. Locate the KFW_INTERFACES= variable and add the one-word name of the new interface, separating it from the preceding name by a space. For example: KFW_INTERFACES=cnps <interface_name> 2. Following the entries for the default cnps interface, add the following variables as needed, specifying the appropriate values: KFW_INTERFACE_<interface_name>_HOST= If you are defining an interface for a specific NIC or different IP address on this computer, specify the TCP/IP host address. KFW_INTERFACE_<interface_name>_PORT= Type a port number for the Tivoli Enterprise Portal Server. The default is for the server host address, so a second host IP address or a NATed address requires a different port number. KFW_INTERFACE_<interface_name>_PROXY_HOST= If you are using address translation (NAT), type the TCP/IP address used outside the firewall. This is the NATed address. KFW_INTERFACE_<interface_name>_PROXY_PORT= If the port outside the firewall will be translated to something different than what is specified for Port, set that value here. KFW_INTERFACE_<interface_name>_SSL=Y If you want clients to use secure communications between clients and the portal server." <End quote from manual> NOTES: 13

17 1. The TEP to TEPS communication uses two different methods. At startup, the TEP uses HTTP to an internal or external web server. If no firewall is involved and the default port numbers are in use, this would be the hostname which resolves to that address and port If Network Address Translation [NAT] is present, this will be the ip address and the port number connected to the portal server and port This is true when there are many firewalls between the portal client and server or just one. The initial portal client URL contains the proxy address and port number and there is no other configuration required for that aspect. [See below for the differences between browser client, desktop client and Java Web Start cases.] After startup, the portal client uses CORBA IIOP communications. During the startup phase, the client retrieves an Interoperable Object Reference [ior], The ior contains the ip address and port number to be used to connect to the server. The proxy_host and proxy_port variables are stored in the IOR and used here. This is the ip address and port number which the portal client will use to contact the TEPS. In a non-firewall environment, this will be the IP address of the machine running the portal server and port In a firewall environment, this will be the ip_address and port number in the client environment that connects to the defined TEPS server and port number. In Unix/Linux this will be in <installdir>/<arch>/cw and in Windows this will be in <installdir>\cnb. There can be multiple firewalls and proxies between the TEP and the TEPS. The only thing that matters is the address/port seen in the client environment. If you are experiencing connection problems, here is a URL to parse the ior record. Use it to verify that the ior record is presenting the correct ip address and port number The following variable defines the port number for incoming IIOP [Corba] communications traffic at the TEPS. The values are typically set to 15001, 15002, 15003, etc. KFW_INTERFACE_<interface_name>_PORT= 3. The following variable is used when there is more than one Network interface [NIC] on the server running TEPS and you wish to restrict Portal Client communications to a single specific network interface. It is typically given as a numeric ip address. KFW_INTERFACE_<interface_name>_HOST= One case would be a server that has a NIC that allows communication with the public internet. Someone outside the company network running portal client must use only that network interface and all responses must go through that NIC. Another example would be an outsourcing company providing services for several other companies. Each company could want to have its own protected communications. 4. The following two definitions are used when the portal client is beyond a NAT firewall(s). In this case the client will see different ip address and port number than what the Portal server is actually running on. KFW_INTERFACE_<interface_name>_PROXY_HOST= KFW_INTERFACE_<interface_name>_PROXY_PORT= This PROXY_HOST is a numeric address, encoded into the ior record. 14

18 PROXY_HOST/PROXY_PORT are connected to the IIOP connected address seen at TEPS. If that address ever changes, the TEPS Interface must be reconfigured and the TEPS restarted. Each TEPS interface is given a representative name <interface_name> and a port number KFW_INTERFACE_<interface_name>_PORT which is usually 15002/15003/etc. KFW_INTERFACE_<interface_name>_HOST is needed if there is a special NIC needed for the communications. 5. Communications security is defined by KFW_INTERFACE_<interface_name>_SSL=N/Y If the value is N, no security is used. If it is Y, then the initial communication takes place using https communications. The second stage CORBA communications uses a certificate which is built-in to one of the jar files which is transmitted across during the initial connection. If you are using non-default security certificate, the documentation shows how to accomplish that. 6. Firewall rules The firewalls must allow usage of port 1920 and 15001/15002/etc on the TEPS side. From the outside, the firewalls must allow use of the http ip_address and port and the IIOP ip_address and port. That is true for every interface defined. 7. Browser Portal client setup The Browser client sets up the access entirely in the URL. For a non-firewall environment, this would look like For a firewall connection it would look like The hostname is the http-proxy hostname or ip_address, and port is the http-proxy port number. That means the ip_address and port which will be forwarded to the server running the portal server and port The IIOP proxy ip_address and port number are encoded in the ior record. The ior is configured as above. 8. Desktop Portal client setup The Desktop portal starts with a cnp.bat file. When a firewall is present, a java property must be defined. On windows this would be from MTEMS, right click on the desktop portal and select Reconfigure 15

The variable involved looks like this cnp.http.url.databus=http://hostname:port///cnp/kdh/lib/outside.ior On Linux/Unix this performed by editing the cnp.sh file. It means adding -Dcnp.http.url.DataBus= http://hostname:port///cnp/kdh/lib/outside.

19 The variable involved looks like this cnp.http.url.databus= On Linux/Unix this performed by editing the cnp.sh file. It means adding -Dcnp.http.url.DataBus= at the proper point. See details at htm#wq692 The Databus value changes when using an external web server. 9. Java Web Start portal client setup The Java Web Start process is configured using a jnlp file. In ITM 622 the default is tep.jnlp. Begin by cloning tep.jnlp file into outside.jnlp. On Windows this will be found in <installdir>\cnb. On Lunix/Unix this will be in <Candlehome>/<arch>/cw. First change href="tep.jnlp" to href="outside.jnlp" Next add a property for Databus. The properties are clustered together and look like <property name="property" value="value"/> Add another property [or update if it already exists] <property name="cnp.http.url.databus" value=" hostname:port is the http proxy ip/port as seen from the client environment. The IIOP proxy host/port is logically in the ior record as explained earlier. Create a separate jnlp file for each portal client environment, with the correct http proxy target and the correct ior record. 16

20 When you create a shortcut to launch Portal Client via Java Web Start, you specify a command to run like this: "C:\Program Files\IBM\Java50\jre\bin\javaws.exe" Make sure this corresponds to the correct http proxy target and revise the.jnlp name for the environment if this is not a default environment. In a typical Java Web Start environment, you do a first step of installing a proper Java runtime [if not already installed]. It looks like that will work OK just giving the http proxy target. Incidentally, ITM 6.2 FP1 and later can be configured to use Sun Java runtime 1.5 or which may simplify things for some clients. [A quick note that until the upcoming APAR IZ41252 fix, Sun Java 6.0 is only supported at level 7 and below.] 10. Java Web Start portal client setup and SSL option. As configured, the ITM Java Web Start supports only http for initial access. The user/password is encrypted but other material is passed in clear text. If this is a concern, JWS can be manually configured to use https for intial access. Here are the steps requried to change the default. A) Configure a TEPSI so KFW_INTERFACE_<interface_name>_SSL=Y or the Windows equivalent. B) use the following shortcut: "C:\Program Files\IBM\Java50\jre\bin\javaws.exe" C) For every jnlp file make the following change codebase=" codebase=" If you need to preserve the default processing, you will need the default TEPSI and another TEPSI. The second TEPSI is identical to the first except for the SSL specification... which basically covers (A) above. Step (B) would be the same. Then take these steps: after making the new TEPSI, called tepssl for example, recycle the TEPS. That will create a new tepssl.ior in the TEPS directory and tepssl.jnlp in the cnb or <arch>/cw directory. D) A JWS consists of a base jnlp file and a collection of other jnlp files which are logically included. Some are standard and some depend on what applications have been installed. You can see exactly what files are included by looking for lines like this <extension href="ka4_resources.jar.jnlp" name="ka4_resources.jar"/> Clone the default included files in some regular way. For instance, copy ka4_resources.jar.jnlp to ka4_resources_ssl.jar.jnlp E) Alter each of the extension lines in tepssl.jnlp to match the cloned files. <extension href="ka4_resources_ssl.jar.jnlp" name="ka4_resources.jar"/> 17

21 F) For all the new jnlp files, tepssl.jnlp and the _ssl.jar.jnlp files make the following change codebase=" codebase=" After these changes, you can use JWS with the following shortcut "C:\Program Files\IBM\Java50\jre\bin\javaws.exe" Some examples as seen in the TEPS environment variables. You would see these after a TEPS Interface change. Simple interface, no firewalls # List of interfaces. KFW_INTERFACES=tep KFW_INTERFACE_tep_PORT=15001 KFW_INTERFACE_tep_SSL=N That is the default NIC, the single port Simple interface, a special NIC for all work # List of interfaces. KFW_INTERFACES=tep KFW_INTERFACE_tep_HOST= KFW_INTERFACE_tep_PORT=15001 KFW_INTERFACE_tep_SSL=N Interface with an added interface outside, a specific NIC used for outside. # List of interfaces. KFW_INTERFACES=tep outside KFW_INTERFACE_tep_PORT=15001 KFW_INTERFACE_tep_SSL=N KFW_INTERFACE_outside_HOST= KFW_INTERFACE_outside_PORT=15002 FW_INTERFACE_outside_PROXY_HOST= KFW_INTERFACE_outside_PROXY_PORT=7070 KFW_INTERFACE_outside_SSL=N You can have any number of these interfaces defined as needed. In a Windows environment, you configure these in a MTEMS dialog. Right click on the Portal Server, Advanced, Configure TEPS Interfaces: 18

12. Caveat #1: The Proxy host is coded as a numeric value since it is encoded into the ior records during portal server startup. If it is blank, then the local TEPS server is used.

22 12. Caveat #1: The Proxy host is coded as a numeric value since it is encoded into the ior records during portal server startup. If it is blank, then the local TEPS server is used. In one memorable case, the server running the Portal Server had an entry in /etc/hosts that specified the host as having ip_address of Initial connection worked fine, the ior record was transferred and then the Java CORBA attempted to communicate to port which was localhost on the client machine. The testing worked fine on the server running the portal server. You can do a ping hostname on both the machine running the portal server and make sure it resolves into the expected address. 13. Caveat #2: Having two or more NICs requires careful evaluation if they are not equal in function. You need to specify the KFW_INTERFACE_<interface_name>_HOST variable if there is a specific interface to be used for the needed communications. In addition, you may need to add KDEB_INTERFACE=ip_address for the TEPS communications with the TEMS in such cases. Usually things work with defaults, but when there are NICs with unequal scope you need to watch carefully. This can also be a problem with virtual NICs as those created with some products. 14. Caveat #3: The tep.jnlp file logically includes other jnlp files. Each such file has an entry like this: codebase= Where hostname is the numeric ip address of the TEPS server and port will usually be The numeric address appears to be created at TEPS install time. If the server running TEPS changes the ip address, then these will be wrong and the Java Web Start process will fail. In my testing, I changed each one of them to have a symbolic host name like this 19

23 codebase= avoiding the problem. If the TEPS server has a constant ip address, this would not be a problem. 15. When the default processing cannot work, you may need to use the KDE_Gateway feature. Typical cases for use would be when there are a collection of ITM processes: remote TEMS, agents, one of several WPAs, and some portal clients and some are more than one firewalls from each other. In this case the KDE_Gateway process can collect all the communications together and define paths for navigating the extended network. Here is a URL to a manual 20

IBM Tivoli Monitoring Agent Management Services Performance Considerations in a Virtualized Environment

IBM Tivoli Monitoring Agent Management Services Performance Considerations in a Virtualized Environment This document can be found on the web at www.ibm.com/support/techdocs Search for author s name under