| Like everything else Net8 related , Connection Manager is configured via an .ora file. In this case, the file is named cman.ora , and it's located in the $ORACLE_HOME /network /admin directory. In cman.ora , you can configure the following: -
Network protocol addresses over which Connection Manager and the Connection Manager Administrator communicate -
Connection Manager profile attributes that control various aspects of Connection Manager's operation -
Net8 access control rules that allowand disallowNet8 connections There are defaults for everything, and if you're willing to accept all the defaults, you can get by without creating the cman.ora file. It's best to create the file though. It's easier to keep track of the protocol addresses and the other settings if you have them recorded where you can see them. Net8 Assistant cannot be used to configure Connection Manager (at least that's true as of the 8.1.6 release). To configure Connection Manager, you have to edit cman.ora manually. 9.3.1 Connection Manager Addresses The first thing you need to do when configuring Connection Manager is to decide which protocols you want to support, and which addresses you want to use. You need to choose protocols and addresses for both CMGW and CMADMIN, and you record these choices in the cman.ora file. The following two entries represent the default values and show the format to use: CMAN = (ADDRESS =(PROTOCOL=tcp)(HOST=localhost)(PORT=1630)) CMAN_ADMIN = (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1830)) The most important of these settings is the one for CMAN. That's the setting that controls the protocols that clients can use when connecting via Connection Manager. To support multiple protocols, use an address list. The following settings will configure Connection Manager to support connections from both TCP/IP and SPX clients : CMAN = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1630)) (ADDRESS=(PROTOCOL=spx)(SERVICE=cman01)) )  | It's not necessary for CMADMIN to support the same protocols as CMAN. | | Once you've settled on the protocols and addresses to use, you can actually start Connection Manager and configure your clients to use it. At least you can use the multi-protocol features. To support connection concentration, you may need to make some changes to the MTS settings for your database instances. 9.3.2 Connection Manager Profile Settings There are a number of settings that you can place into cman.ora to control various aspects of Connection Manager's operations. These settings are known collectively as the Connection Manager Profile, and they are placed in one long cman.ora entry identified by the keyword CMAN_PROFILE. The following example shows the default values for all the profile settings: CMAN_PROFILE = (PARAMETER_LIST = (ANSWER_TIMEOUT = 0) (AUTHENTICATION_LEVEL = 0) (LOG_LEVEL = 0) (MAX_FREELIST_BUFFERS = 0) (MAXIMUM_CONNECT_DATA = 1024) (MAXIMUM_RELAYS = 128) (RELAY_STATISTICS = NO) (REMOTE_ADMIN = NO) (SHOW_TNS_INFO = NO) (TRACE_DIRECTORY = $ORACLE_HOME/network/trace) (TRACE_FILELEN = UNLIMITED) (TRACE_FILENO = 1) (TRACE_TIMESTAMP = NO) (TRACING = NO) (USE_ASYNC_CALL = YES) ) A few of these settings can be changed on the fly using the Connection Manager Control ( cmctl ) utility's SET command. Most, however, can only be changed by editing cman.ora and restarting Connection Manager. Table 9.2 describes each profile setting in more detail. Table 9.2. Connection Manager Profile Settings | Profile Setting | Description | | ANSWER_TIMEOUT | The timeout, in seconds, used for the protocol handshake when a new connection is made. The default value of specifies no timeout. | | AUTHENTICATION_LEVEL | Controls whether or not connect requests not using Secure Network Services (SNS) are rejected. 1 = only accept SNS connections; = accept all connections. Leave this at if you're not using Oracle's Advanced Security Option. | | LOG_LEVEL | Specifies the amount of detail to be written to the Connection Manager log file. Valid values are: 0 = No logging 1 = Log basic operations 2 = Log rule list lookups 3 = Log relay blocking information 4 = Log relay I/O counts | | MAX_FREELIST_BUFFERS | Specifies the number of TNS buffers to retain for reuse when a relay is closed. The valid range is to 10240. | | MAXIMUM_CONNECT_DATA | Sets the maximum length allowed for a Net8 connect string. These can get quite long if you are hopping through two or more Connection Manager instances. The valid range is 257 to 4096. | | MAXIMUM_RELAYS | Specifies the maximum number of connections to support. The valid range is 1 to 2048. | | RELAY_STATISTICS | Controls whether or not Connection Manager maintains statistics about relay I/O. YES enables statistics. NO disables them. [1] | | REMOTE_ADMIN | Enables or disables remote management of a Connection Manager instance. Valid values are YES and NO. | | SHOW_TNS_INFO | Controls whether or not TNS events are written to the log file. Valid values are YES and NO. | | TRACING | Enables or disables tracing for Connection Manager. Valid values are YES and NO. | | TRACE_DIRECTORY | Specifies the directory to which trace files are written. | | TRACE_FILELEN | Specifies the maximum size to use for trace files. If you specify this parameter, then you must also specify TRACE_DIRECTORY. | | TRACE_FILENO | Specifies the number of files to use for trace information. These files are used in a cyclical manner. Use of this parameter requires that you also use TRACE_DIRECTORY. | | TRACE_TIMESTAMP | Controls whether or not a timestamp is included with events written to the trace file. Valid values are YES and NO. | | USE_ASYNC_CALL | Enables or disables the use of asynchronous functions. Valid values are YES and NO. | [1] The values TRUE, ON, and 1 may be used as synonyms for YES. The values FALSE, OFF, and may be used as synonyms for NO. As a general rule, you should accept the defaults unless you have a specific reason to change one. You do not need to include every possible parameter in the parameter list of a CMAN_PROFILE entry. Specify only the parameters that you need to change. Parameters not listed will remain at their defaults. 9.3.3 Access Control Rules Connection Manager allows you to restrict connections based on a set of access rules that you define in the cman.ora file. Access rules are defined in a rule list that is contained within an entry named CMAN_RULES. The following is a short example showing how this entry might look: CMAN_RULES = (RULE_LIST = (RULE = (SRC = donna.gennick.org) (DST = jonathan.gennick.org) (SRV = x) (ACT = ACCEPT) ) ) The rule in this example causes Connection Manager to allow all connections from the node donna.gennick.org that are made to the node jonathan.gennick.org . The x in (SRV = x) is a wildcard, permitting connections to any database service. The default is not to have any rules, in which case no restrictions applyall connections are allowed. Once you place a CMAN_RULES entry in your cman.ora file, Connection Manager's behavior changes somewhat. When rules are used, only connections that are expressly permitted by those rules are allowed by Connection Manager. All other connections are rejected. | | Access control rules can only be defined when the TCP/IP protocol is used. | | 9.3.3.1 Creating a rule Rules control access based on a combination of source node, destination node, and database service name . Each rule associates a combination of these three attributes with an action. There are two actions available: ACCEPT and REJECT. The syntax for creating an access control rule looks like this: (RULE = (SRC = { hostname ip_address }) (DST = { hostname ip_address }) (SRV = database_service ) (ACT = {ACCEPT REJECT}) ) where: - SRC = {hostname ip_address}
-
Specifies the node from which the connection originates. Either a hostname or a numerical IP address may be used. - DST = {hostname ip_address}
-
Specifies the destination node. Either a hostname or a numerical IP address may be used. - SRV = database_service
-
Specifies the name of a database service. - ACT = {ACCEPT REJECT}
-
Specifies the action to take if the connection request matches the conditions specified by the rule. ACCEPT causes a connection to be accepted; REJECT causes a connection to be rejected. For example, if you want to allow connections from the node donna.gennick.org to the node jonathan.gennick.org , but only for the database service name herman .gennick.org , you could define the following rule: CMAN_RULES = (RULE_LIST = (RULE = (SRC = donna.gennick.org) (DST = jonathan.gennick.org) (SRV = herman.gennick.org) (ACT = ACCEPT) ) ) Unlike most cases in Net8 where parentheses are used to nest one set of parameters inside another, you can't omit any attributes when defining an access control rule. You must always specify SRC, DST, SRV, and ACT. If you omit an attribute from a rule, Connection Manager won't start. 9.3.3.2 Wildcarding access control rules It would be a dreary job indeed if you had to specify a separate rule for every possible combination of source node, destination node, and database service available on your network. Fortunately, you don't need to do that. Connection Manager implements a wildcard character that you can use to reduce the number of rules that you need to write. Strangely enough, the wildcard character that Connection Manager recognizes for access control rules is the single character x. It's not case-sensitive, so either x or X is fine. You can use the wildcard character as a replacement for: The following example expands on the rule shown in the previous section. It allows connections from donna.gennick.org to almost any service on jonathan.gennick.org (the one service that is disallowed is the one for the payroll database): CMAN_RULES = (RULE_LIST = (RULE = (SRC = donna.gennick.org) (DST = jonathan.gennick.org) (SRV = payroll.gennick.org) (ACT = REJECT) ) (RULE = (SRC = donna.gennick.org) (DST = jonathan.gennick.org) (SRV = x) (ACT = ACCEPT) ) ) When a connection attempt is made, Connection Manager checks the attributes of the connection against each rule in the rule list in the order in which it appears in that list. With respect to this example, Connection Manager does the following: -
Checks to see if the connection is from donna.gennick.org to the payroll.gennick.org service running on jonathan.gennick.org . If that's the case, the connection is rejected. If that's not the case, Connection Manager moves on to the next rule. -
Checks to see if the connection is from donna.gennick.org to any database service running on jonathan.gennick.org . If that's the case, the connection is accepted. If that's not the case, there are no more rules in the list, so the connection is rejected by default. | | Connections that don't match any rules in the list are always rejected. | | Because Connection Manager works through the rules in order, you want to have your most specific rules appear in the list first. If the order of the rules in the previous list were to be reversed , connections from donna.gennick.org to the payroll.gennick.org service would always be allowed. The first rule would be the one with the wildcard. Connection Manager would accept the connection on that basis, and would never get around to evaluating the second rule. The following example shows a rule list that uses numerical IP addresses and includes wildcards within those addresses: CMAN_RULES = (RULE_LIST = (RULE = (SRC = 10.11.12.17) (DST = 10.11.12.13) (SRV = payroll.gennick.org) (ACT = REJECT) ) (RULE = (SRC = 10.11.12.x) (DST = 10.11.12.13) (SRV = payroll.gennick.org) (ACT = ACCEPT) ) (RULE = (SRC = 10.11.13.x) (DST = 10.11.12.16) (SRV = hr.gennick.org) (ACT = ACCEPT) ) ) This rule allows all clients with an IP address of 10.11.12. something to connect to the payroll database on the node 10.11.12.13. The one exception is for the node 10.11.12.17, which isn't allowed to connect. Connections are also allowed to the human resources database on 10.11.12.16 from all clients with an IP address of 10.11.13. something . All other connections are implicitly rejected. 9.3.3.3 Rules in a multi-protocol environment Access control rules should be defined in an environment where TCP/IP is the only protocol used to carry Net8 connections. The connection both to and from Connection Manager must be TCP/IP. Consider, for example, the environment shown in Figure 9.7. Figure 9.7. A multi-protocol environment with access control rules  At first glance, the access control rule in this environment appears to allow all connections. It will, in fact, allow connections using net service names that have been defined as follows : HERMAN_CM.GENNICK.ORG = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=TCP)(HOST=jonathan.gennick.org)(PORT=1630)) (ADDRESS=(PROTOCOL=TCP)(HOST=jonathan.gennick.org)(PORT=1521)) ) (SOURCE_ROUTE = yes) (CONNECT_DATA = (SERVICE_NAME = herman.gennick.org) ) ) Connections using this net service name will succeed because TCP/IP is used for both hopsthe one to Connection Manager and the one from there to the database service. All bets are off, though, if you mix protocols. Connections made using the following net service name will not work: HERMAN_SPX.GENNICK.ORG = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=TCP)(HOST=jonathan.gennick.org)(PORT=1630)) (ADDRESS=(PROTOCOL=SPX)(SERVICE=jonathan_listener)) ) (SOURCE_ROUTE = yes) (CONNECT_DATA = (SERVICE_NAME = herman.gennick.org) ) ) The reason connections using this net service name fail is that there is no value for the destination node. Remember that only TCP/IP is supported. Because SPX does not specify a hostname, the rule won't match and the connection will fail. The bottom line is that any connection using any protocol other than TCP/IP is guaranteed not to match any of the rules, and thus is guaranteed to fail. 9.3.3.4 Rules interpretation when multiple hops are involved If you're working in an environment where there are multiple hops that occur between the ultimate source and the ultimate destination, it's important that you understand how Connection Manager interprets "source" and "destination" when it comes to enforcing access control rules. For purposes of enforcing access control rules, the "source" and "destination" addresses are always with respect to the current Connection Manager instance. Figure 9.8 shows an environment where connections make three hops involving two Connection Manager instances before reaching the database service. Figure 9.8. Source and destination addresses are always with respect to the Connection Manager instance  Notice that the first rule, which is for the first Connection Manager instance, allows connections from client.gennick.org to cman02.gennick.org . As far as the first Connection Manager instance is concerned , cman02.gennick.org is the destination. In other words, it's not the ultimate destination that counts, it's the address of the next hop. Likewise, the second Connection Manager instance considers the source to be cman01.gennick.org . This can get confusing, but if you are going to have one Connection Manager instance feed into another like this, you have to write your access control rules accordingly . 9.3.4 Database Server Settings (or MTS Settings) To use Connection Manager as a bridge between two network protocols, you don't need to make any configuration changes on your database servers. To use Connection Manager as a connection concentrator, however, you need to do the following: -
Configure your database instances to use multi-threaded server. -
Enable multiplexing of MTS connections. -
Specify the number of sessions to allow over the one physical connection created by Connection Manager. If you aren't already familiar with MTS configuration, read Chapter 5. The following parameter file entry configures one MTS dispatcher for an instance. The dispatcher will support TCP/IP connections, and multiplexing will be enabled: MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=1)(MULTIPLEX=YES)(SESSIONS=50)" The two key things to notice about this entry are the settings for the MULTIPLEX and SESSIONS attributes. (MULTIPLEX = YES) enables the multiplexing of MTS sessions. Connection concentration works by multiplexing several sessions over one connection. The SESSIONS attribute specifies the maximum number of sessions to allow over that one connection. In this case, the upper limit has been set to 50. | 
