<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- Installing Orber</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/orber-3.6.24.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>orber</strong><br><strong>User's Guide</strong><br><small>Version 3.6.24</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu">
<li id="no" title="The Orber Application" expanded="false">The Orber Application<ul>
<li><a href="ch_contents.html">
Top of chapter
</a></li>
<li title="Content Overview"><a href="ch_contents.html#id61214">Content Overview</a></li>
<li title="Brief Description of the User's Guide"><a href="ch_contents.html#id62498">Brief Description of the User's Guide</a></li>
</ul>
</li>
<li id="no" title="Introduction to Orber" expanded="false">Introduction to Orber<ul>
<li><a href="ch_introduction.html">
Top of chapter
</a></li>
<li title="Overview"><a href="ch_introduction.html#id64790">Overview</a></li>
</ul>
</li>
<li id="no" title="The Orber Application" expanded="false">The Orber Application<ul>
<li><a href="ch_orber_kernel.html">
Top of chapter
</a></li>
<li title="ORB Kernel and IIOP "><a href="ch_orber_kernel.html#id57197">ORB Kernel and IIOP </a></li>
<li title="The Object Request Broker (ORB)"><a href="ch_orber_kernel.html#id63374">The Object Request Broker (ORB)</a></li>
<li title="Internet Inter-Object Protocol (IIOP)"><a href="ch_orber_kernel.html#id65057">Internet Inter-Object Protocol (IIOP)</a></li>
</ul>
</li>
<li id="no" title="Interface Repository" expanded="false">Interface Repository<ul>
<li><a href="ch_ifr.html">
Top of chapter
</a></li>
<li title="Interface Repository(IFR)"><a href="ch_ifr.html#id64309">Interface Repository(IFR)</a></li>
</ul>
</li>
<li id="loadscrollpos" title="Installing Orber" expanded="true">Installing Orber<ul>
<li><a href="ch_install.html">
Top of chapter
</a></li>
<li title="Installation Process "><a href="ch_install.html#id62824">Installation Process </a></li>
<li title="Configuration"><a href="ch_install.html#id74009">Configuration</a></li>
<li title="Firewall Configuration"><a href="ch_install.html#id76130">Firewall Configuration</a></li>
<li title="Interface Configuration"><a href="ch_install.html#id76571">Interface Configuration</a></li>
</ul>
</li>
<li id="no" title="OMG IDL to Erlang Mapping" expanded="false">OMG IDL to Erlang Mapping<ul>
<li><a href="ch_idl_to_erlang_mapping.html">
Top of chapter
</a></li>
<li title="OMG IDL to Erlang Mapping - Overview"><a href="ch_idl_to_erlang_mapping.html#id76788">OMG IDL to Erlang Mapping - Overview</a></li>
<li title="OMG IDL Mapping Elements"><a href="ch_idl_to_erlang_mapping.html#id76811">OMG IDL Mapping Elements</a></li>
<li title="Getting Started"><a href="ch_idl_to_erlang_mapping.html#id76868">Getting Started</a></li>
<li title="Basic OMG IDL Types"><a href="ch_idl_to_erlang_mapping.html#id76929">Basic OMG IDL Types</a></li>
<li title="Template OMG IDL Types and Complex Declarators"><a href="ch_idl_to_erlang_mapping.html#id77470">Template OMG IDL Types and Complex Declarators</a></li>
<li title="Constructed OMG IDL Types"><a href="ch_idl_to_erlang_mapping.html#id77956">Constructed OMG IDL Types</a></li>
<li title="Scoped Names and Generated Files"><a href="ch_idl_to_erlang_mapping.html#id78395">Scoped Names and Generated Files</a></li>
<li title="Typecode, Identity and Name Access Functions"><a href="ch_idl_to_erlang_mapping.html#id78787">Typecode, Identity and Name Access Functions</a></li>
<li title="References to Constants"><a href="ch_idl_to_erlang_mapping.html#id78931">References to Constants</a></li>
<li title="References to Objects Defined in OMG IDL"><a href="ch_idl_to_erlang_mapping.html#id78990">References to Objects Defined in OMG IDL</a></li>
<li title="Exceptions"><a href="ch_idl_to_erlang_mapping.html#id79013">Exceptions</a></li>
<li title="Access to Attributes"><a href="ch_idl_to_erlang_mapping.html#id79046">Access to Attributes</a></li>
<li title="Invocations of Operations"><a href="ch_idl_to_erlang_mapping.html#id79103">Invocations of Operations</a></li>
<li title="Implementing the DB Application"><a href="ch_idl_to_erlang_mapping.html#id79262">Implementing the DB Application</a></li>
<li title="Reserved Compiler Names and Keywords"><a href="ch_idl_to_erlang_mapping.html#id79480">Reserved Compiler Names and Keywords</a></li>
<li title="Type Code Representation"><a href="ch_idl_to_erlang_mapping.html#id80225">Type Code Representation</a></li>
</ul>
</li>
<li id="no" title="CosNaming Service" expanded="false">CosNaming Service<ul>
<li><a href="ch_naming_service.html">
Top of chapter
</a></li>
<li title="Overview of the CosNaming Service"><a href="ch_naming_service.html#id80888">Overview of the CosNaming Service</a></li>
<li title="The Basic Use-cases of the Naming Service"><a href="ch_naming_service.html#id81031">The Basic Use-cases of the Naming Service</a></li>
<li title="Interoperable Naming Service"><a href="ch_naming_service.html#id81378">Interoperable Naming Service</a></li>
</ul>
</li>
<li id="no" title="How to use security in Orber" expanded="false">How to use security in Orber<ul>
<li><a href="ch_security.html">
Top of chapter
</a></li>
<li title="Security in Orber"><a href="ch_security.html#id82238">Security in Orber</a></li>
</ul>
</li>
<li id="no" title="Orber Stubs/Skeletons" expanded="false">Orber Stubs/Skeletons<ul>
<li><a href="ch_stubs.html">
Top of chapter
</a></li>
<li title="Orber Stubs and Skeletons Description"><a href="ch_stubs.html#id82459">Orber Stubs and Skeletons Description</a></li>
</ul>
</li>
<li id="no" title="CORBA System and User Defined Exceptions" expanded="false">CORBA System and User Defined Exceptions<ul>
<li><a href="ch_exceptions.html">
Top of chapter
</a></li>
<li title="System Exceptions"><a href="ch_exceptions.html#id83036">System Exceptions</a></li>
<li title="User Defined Exceptions"><a href="ch_exceptions.html#id83473">User Defined Exceptions</a></li>
<li title="Throwing Exceptions"><a href="ch_exceptions.html#id83493">Throwing Exceptions</a></li>
<li title="Catching Exceptions"><a href="ch_exceptions.html#id83525">Catching Exceptions</a></li>
</ul>
</li>
<li id="no" title="Orber Interceptors" expanded="false">Orber Interceptors<ul>
<li><a href="ch_interceptors.html">
Top of chapter
</a></li>
<li title="Using Interceptors"><a href="ch_interceptors.html#id83634">Using Interceptors</a></li>
<li title="Interceptor Example"><a href="ch_interceptors.html#id83850">Interceptor Example</a></li>
</ul>
</li>
<li id="no" title="OrberWeb" expanded="false">OrberWeb<ul>
<li><a href="ch_orberweb.html">
Top of chapter
</a></li>
<li title="Using OrberWeb"><a href="ch_orberweb.html#id84111">Using OrberWeb</a></li>
<li title="Starting OrberWeb"><a href="ch_orberweb.html#id84699">Starting OrberWeb</a></li>
</ul>
</li>
<li id="no" title="Debugging" expanded="false">Debugging<ul>
<li><a href="ch_debugging.html">
Top of chapter
</a></li>
<li title="Tools and FAQ"><a href="ch_debugging.html#id84785">Tools and FAQ</a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>5 Installing Orber</h1>
<h3><a name="id62824">5.1
Installation Process </a></h3>
<p>This chapter describes how to install Orber in an Erlang
Environment.</p>
<h4>Preparation</h4>
<p>To begin with, you must decide if you want to run Orber as a:</p>
<ul>
<li>
<strong>Single node (non-distributed)</strong> - all communication with other
Orber instances and ORB's supplied by other vendors use the OMG
GIOP protocol.</li>
<li>
<strong>Multi node (distributed)</strong> - all Orber nodes, within the same
<span class="code">domain</span>, communicate via the Erlang distribution protocol.
For all other Orber instances, i.e. not part of the same <span class="code">domain</span>,
and ORB's supplied by other vendors, the OMG GIOP protocol
is used.</li>
</ul>
<p>Which approach to use is highly implementation specific, but a few
things you should consider:</p>
<ul>
<li>All nodes within an Orber domain should have the same
security level.</li>
<li>If the capacity is greater than load (volume of traffic)
a single-node Orber might be a good solution.</li>
<li>In some cases the distributed system architecture requires a
single-node Orber installation.</li>
<li>A multi-node Orber makes it possible to load balance
and create a more fault tolerant system. The Objects
can also have a uniform view if you use distributed
Mnesia tables.</li>
<li>Since the GIOP protocol creates a larger overhead than the
Erlang distribution protocol, the performance will be better
when communicating with Objects within the same Orber domain
compared with inter ORB communication (GIOP).</li>
</ul>
<p>You also have to decide if you want Orber to store internal data using
<span class="code">disc_copies</span> and/or <span class="code">ram_copies</span>. Which storage type you should
depends if/how you intend to use Mnesia in your application. If you
intend to use <span class="code">disc_copies</span> you must start with creating a Mnesia
schema, which contain information about the location of the Erlang nodes
where Orber is planned to be run. For more background information,
see the Mnesia documentation.</p>
<p>In some cases it is absolutely necessary to change the default configuration
of Orber. For example, if two Orber-ORB's shall be able to communicate
via GIOP, they must have a unique <span class="code">domain</span> domain. Consult the
<span class="bold_code"><a href="ch_install.html#config">configuration settings</a></span>
section. If you encounter any problems; see the chapter about
<strong>Debugging</strong> in this User's Guide.</p>
<h4>Jump Start Orber</h4>
<p>The easiest way to start Orber is to use <span class="code">orber:jump_start(Port)</span>,
which start a single-node ORB with (most likely) a unique
domain (i.e. "IP-number:Port"). This function may only be used
during development and testing. For any other situation, install and
start Orber as described in the following sections.
The listen port, i.e. iiop_port configuration parameter, is set to
the supplied Port.</p>
<div class="warning">
<div class="label">Warning</div>
<div class="content"><p>
<p>How Orber is configured when using <span class="code">orber:jump_start(Port)</span>
may change at any time without warning. Hence, this operation must
not be used in systems delivered to a customer.</p>
</p></div>
</div>
<h4>Install Single Node Orber</h4>
<p>Since a single node Orber communicate via the OMG GIOP protocol it is not
necessary to start the Erlang distribution (i.e. using <span class="code">-name/-sname</span>).</p>
<p>If we use <span class="code">ram_copies</span> there is no need for creating a disk based
schema. Simply use:</p>
<div class="example"><pre>
erl> mnesia:start().
erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]).
erl> orber:install([node()], [{ifr_storage_type, ram_copies}]).
erl> orber:start().
</pre></div>
<p>If you installation requires <span class="code">disc_copies</span> you must begin with
creating a Mnesia schema. Otherwise, the installation is similar
to a RAM installation:</p>
<div class="example"><pre>
erl> mnesia:create_schema([node()]).
erl> mnesia:start().
erl> corba:orb_init([{domain, "MyDiskSingleNodeORB"}]).
erl> orber:install([node()], [{ifr_storage_type, disc_copies},
{nameservice_storage_type, disc_copies}]).
erl> orber:start().
</pre></div>
<p>You can still choose to store the IFR data as ram_copies, but then
the data must be re-installed (i.e. invoke <span class="code">orber:install/2</span>)
if the node is restarted. Hence, since the IFR data is rather static
you should use <span class="code">disc_copies</span>. For more information see the
<span class="code">orber</span> section in the reference manual.</p>
<p>If you do not need to change Orber's configuration you can skip
<span class="bold_code"><a href="corba.html">orb_init/1</a></span>.
But, you <strong>should</strong> at least set the IIOP timeout parameters.</p>
<h4>Install RAM Based Multi Node Orber</h4>
<p>Within a domain Orber uses the Erlang distribution protocol. Hence, you
<strong>must</strong> start it first by, for example, using:</p>
<div class="example"><pre>
hostA> erl -sname nodeA
</pre></div>
<p>In this example, we assume that we want to use two nodes; <span class="code">nodeA</span> and
<span class="code">nodeB</span>. Since Mnesia must know which other nodes should a part
of the distribution we either need to add the Mnesia configuration
parameter <span class="code">extra_db_nodes</span> or use <span class="code">mnesia:change_config/2</span>. To
begin with, Mnesia must be started on all nodes before we can install
Orber:</p>
<div class="example"><pre>
nodeA@hostA> mnesia:start().
nodeA@hostA> mnesia:change_config(extra_db_nodes,
[nodeA@hostA, nodeB@hostB]).
</pre></div>
<p>After that the above have been repeated on <span class="code">nodeB</span> we must
first make sure that both nodes will use the same domain name, then
we can install Orber:</p>
<div class="example"><pre>
nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
[{ifr_storage_type, ram_copies}]).
nodeA@hostA> orber:start().
</pre></div>
<p>Note that you can only invoke <span class="code">orber:install/1/2</span> on one of the
nodes. Now we can start Orber on the other node:</p>
<div class="example"><pre>
nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
nodeB@hostB> orber:start().
</pre></div>
<h4>Install Disk Based Multi Node Orber</h4>
<p>As for RAM based multi-node Orber installations, the Erlang distribution
must be started (e.g. erl -sname nodeA). The major difference is that
when it is disk based a Mnesia schema must be created:</p>
<div class="example"><pre>
nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]).
nodeA@hostA> mnesia:start().
</pre></div>
<p>In this example, we assume that we want to use two nodes; <span class="code">nodeA</span> and
<span class="code">nodeB</span>. Since it is not possible to create a schema on more than
one node. Hence, all we have to do is to start Mnesia (i.e. invoke
<span class="code">mnesia:start()</span>) on <span class="code">nodeB</span>.</p>
<p>After Mnesia have been started on all nodes, you must confirm that all
nodes have the same domain name, then Orber is ready to be installed:</p>
<div class="example"><pre>
nodeA@hostA> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
[{ifr_storage_type, disc_copies}]).
nodeA@hostA> orber:start().
</pre></div>
<p>Note that you can only invoke <span class="code">orber:install/1/2</span> on one of the
nodes. Now we can start Orber on the other node:</p>
<div class="example"><pre>
nodeB@hostB> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
nodeB@hostB> orber:start().
</pre></div>
<h3><a name="id74009">5.2
Configuration</a></h3>
<a name="config"></a>
<p>It is essential that one configure Orber properly, to avoid, for example,
malicious attacks and automatically terminate IIOP connections no longer
in use. An easy way to extract information about Orber's configuration
parameters is to invoke the operation
<span class="bold_code"><a href="orber.html">orber:info/1/2</a></span>.
Orber offer the following configuration parameters:</p>
<table border="1" cellpadding="2" cellspacing="0">
<tr>
<td align="left" valign="middle"><strong>Key</strong></td>
<td align="left" valign="middle"><strong>Range</strong></td>
<td align="left" valign="middle"><strong>Default</strong></td>
</tr>
<tr>
<td align="left" valign="middle">domain</td>
<td align="left" valign="middle">string()</td>
<td align="left" valign="middle">"ORBER"</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_port</td>
<td align="left" valign="middle">integer() >= 0</td>
<td align="left" valign="middle">4001</td>
</tr>
<tr>
<td align="left" valign="middle">nat_iiop_port</td>
<td align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</td>
<td align="left" valign="middle">The same as <span class="code">iiop_port</span>
</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_out_ports</td>
<td align="left" valign="middle">0 | {integer(),integer()}</td>
<td align="left" valign="middle">0</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_out_ports_attempts</td>
<td align="left" valign="middle">integer() > 0</td>
<td align="left" valign="middle">1</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_out_ports_random</td>
<td align="left" valign="middle">true | false</td>
<td align="left" valign="middle">false</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_max_fragments</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_max_in_requests</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_max_in_connections</td>
<td align="left" valign="middle">integer() > 0</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_backlog</td>
<td align="left" valign="middle">integer() > 0</td>
<td align="left" valign="middle">5</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_packet_size</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">ip_address</td>
<td align="left" valign="middle">string() | {multiple, [string()]}</td>
<td align="left" valign="middle">All interfaces</td>
</tr>
<tr>
<td align="left" valign="middle">ip_address_local</td>
<td align="left" valign="middle">string()</td>
<td align="left" valign="middle">Defined by the underlying system</td>
</tr>
<tr>
<td align="left" valign="middle">nat_ip_address</td>
<td align="left" valign="middle">string() | {multiple, [string()]} | {local, string(), [{string(), string()}]}</td>
<td align="left" valign="middle">The same as <span class="code">ip_address</span>
</td>
</tr>
<tr>
<td align="left" valign="middle">objectkeys_gc_time</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">giop_version</td>
<td align="left" valign="middle">{1,0} | {1,1} | {1,2}</td>
<td align="left" valign="middle">{1,1}</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_setup_connection_timeout</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_connection_timeout</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_in_connection_timeout</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_out_keepalive</td>
<td align="left" valign="middle">true | false</td>
<td align="left" valign="middle">false</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_in_keepalive</td>
<td align="left" valign="middle">true | false</td>
<td align="left" valign="middle">false</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_timeout</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">interceptors</td>
<td align="left" valign="middle">{native, [atom()]}</td>
<td align="left" valign="middle">-</td>
</tr>
<tr>
<td align="left" valign="middle">local_interceptors</td>
<td align="left" valign="middle">{native, [atom()]}</td>
<td align="left" valign="middle">-</td>
</tr>
<tr>
<td align="left" valign="middle">orbInitRef</td>
<td align="left" valign="middle">[string()] | undefined</td>
<td align="left" valign="middle">undefined</td>
</tr>
<tr>
<td align="left" valign="middle">orbDefaultInitRef</td>
<td align="left" valign="middle">string() | undefined</td>
<td align="left" valign="middle">undefined</td>
</tr>
<tr>
<td align="left" valign="middle">orber_debug_level</td>
<td align="left" valign="middle">0 - 10</td>
<td align="left" valign="middle">0</td>
</tr>
<tr>
<td align="left" valign="middle">flags</td>
<td align="left" valign="middle">integer() >= 0</td>
<td align="left" valign="middle">0</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_acl</td>
<td align="left" valign="middle">[{atom(), string()}] | [{atom(), string(), [string()]}]</td>
<td align="left" valign="middle">[]</td>
</tr>
<tr>
<td align="left" valign="middle">secure</td>
<td align="left" valign="middle">no | ssl</td>
<td align="left" valign="middle">no</td>
</tr>
<tr>
<td align="left" valign="middle">ssl_generation</td>
<td align="left" valign="middle">2 | 3</td>
<td align="left" valign="middle">2</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_port</td>
<td align="left" valign="middle">integer() >= 0</td>
<td align="left" valign="middle">4002</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_accept_timeout</td>
<td align="left" valign="middle">integer() > 0 | infinity</td>
<td align="left" valign="middle">infinity</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_backlog</td>
<td align="left" valign="middle">integer() > 0</td>
<td align="left" valign="middle">5</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_ip_address_local</td>
<td align="left" valign="middle">string()</td>
<td align="left" valign="middle">Defined by the underlying system</td>
</tr>
<tr>
<td align="left" valign="middle">nat_iiop_ssl_port</td>
<td align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</td>
<td align="left" valign="middle">The same as <span class="code">iiop_ssl_port</span>
</td>
</tr>
<tr>
<td align="left" valign="middle">ssl_server_options</td>
<td align="left" valign="middle">list()</td>
<td align="left" valign="middle">See the <span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','ssl','ssl.html');">SSL application</a></span>
for valid options.</td>
</tr>
<tr>
<td align="left" valign="middle">ssl_client_options</td>
<td align="left" valign="middle">list()</td>
<td align="left" valign="middle">See the <span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','ssl','ssl.html');">SSL application</a></span>
for valid options.</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_out_keepalive</td>
<td align="left" valign="middle">true | false</td>
<td align="left" valign="middle">false</td>
</tr>
<tr>
<td align="left" valign="middle">iiop_ssl_in_keepalive</td>
<td align="left" valign="middle">true | false</td>
<td align="left" valign="middle">false</td>
</tr>
</table>
<em>Table
5.1:
Orber Configuration Parameters</em>
<br>
<br>
<p><strong>Comments on the table 'Orber Configuration Parameters':</strong></p>
<dl>
<dt><strong><strong>domain</strong></strong></dt>
<dd>Since Orber domains, they are supposed to communicate via IIOP,
<strong>MUST</strong> have unique names, communication will
fail if two domains have the same name. The domain name <strong>MAY NOT</strong>
contain <span class="code">^G</span> (i.e. <span class="code">\007</span>).</dd>
<dt><strong><strong>iiop_port</strong></strong></dt>
<dd>If set to 0 the OS will pick any vacant port.
<br>
<strong>Note:</strong>On a UNIX system it is preferable to
have a IIOP port higher than 1023, since it is not recommended to
run Erlang as a root user.</dd>
<dt><strong><strong>nat_iiop_port</strong></strong></dt>
<dd>The value is either an integer or <span class="code">{local, DefaultNATPort, [{Port, NATPort}]}</span>. See also
<span class="bold_code"><a href="ch_install.html#firewall">Firewall Configuration</a></span>.</dd>
<dt><strong><strong>iiop_out_ports</strong></strong></dt>
<dd>When set to 0 any available port will be used.
If a range is specified, Orber will only
use the local ports within the interval when trying to connect to
another ORB (Orber acts as a client ORB). If all ports are in use
communication will fail. Hence, it is <strong>absolutely necessary</strong> to
set <span class="code">iiop_connection_timeout</span> as well. Otherwise, connections
no longer in use will block further communication. If one use, for
example, <span class="code">erl -orber iiop_out_ports "{5000,5020}"</span>, Orber
will only use port 5000 to 5020 when connecting.
If communicating via SSL, make sure you use a version that supports
the local <span class="code">{port, Port}</span> option. See also
<span class="bold_code"><a href="ch_install.html#firewall">Firewall Configuration</a></span>.</dd>
<dt><strong><strong>iiop_out_ports_random</strong></strong></dt>
<dd>Requires that <span class="code">iiop_out_ports</span> define a port range. If that is the
case Orber will select a port randomly from that sequence.</dd>
<dt><strong><strong>iiop_out_ports_attempts</strong></strong></dt>
<dd>Requires that <span class="code">iiop_out_ports</span> define a port range. If so Orber will
accept a number of timeouts, defined by this parameter, when trying to connect
to another ORB.</dd>
<dt><strong><strong>iiop_max_fragments</strong></strong></dt>
<dd>Limits the number of IIOP fragments allowed per request.</dd>
<dt><strong><strong>iiop_max_in_requests</strong></strong></dt>
<dd>Limits the number of concurrent incoming requests per incoming connection.</dd>
<dt><strong><strong>iiop_max_in_connections</strong></strong></dt>
<dd>Limits the number of concurrent incoming connections.</dd>
<dt><strong><strong>iiop_backlog</strong></strong></dt>
<dd>Defines the maximum length the queue of pending incoming
connections may grow to.</dd>
<dt><strong><strong>iiop_packet_size</strong></strong></dt>
<dd>Defines the maximum size of incoming requests.
If this limit is exceeded, the connection is closed.</dd>
<dt><strong><strong>ip_address</strong></strong></dt>
<dd>This option is used if orber only should
listen on a specific ip interface on a multi-interface host or if
exported IOR:s should contain multiple components. The value is
the IPv4 or IPv6 address as a string or <span class="code">{multiple, IPList}</span>.
The latter requires that the object is available via the all IP addresses
found in the list.</dd>
<dt><strong><strong>ip_address_local</strong></strong></dt>
<dd>This option defines the default local interface Orber will
use when connecting to another ORB via IIOP, i.e., Orber act as the
client side ORB. The value is a IPv4 or IPv6 address as a string.
It is possible to override <span class="code">ip_address_local</span> by defining
<span class="code">iiop_acl</span> or passing the Orber generic <span class="code">interface</span> Context.
If this option is not used, the underlying OS will choose which interface to
use. For more information, see the
<span class="bold_code"><a href="ch_install.html#interfaces">Interface Configuration</a></span>
section.</dd>
<dt><strong><strong>nat_ip_address</strong></strong></dt>
<dd>The value is the ip address as
a string (IPv4 or IPv6), <span class="code">{multiple, IPList}</span> or
<span class="code">{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</span>. See also
<span class="bold_code"><a href="ch_install.html#firewall">Firewall Configuration</a></span>.</dd>
<dt><strong><strong>objectkeys_gc_time</strong></strong></dt>
<dd>This option should be set if objects are started
using the option <span class="code">{persistent, true}</span>.
The value is <span class="code">integer()</span> seconds.</dd>
<dt><strong><strong>giop_version</strong></strong></dt>
<dd>Defines the default GIOP protocol version.</dd>
<dt><strong><strong>iiop_setup_connection_timeout</strong></strong></dt>
<dd>The value is an integer (seconds) or the atom infinity.
This option is only valid for client-side
connections. If this option is set, attempts to connect to other ORB's
will timeout after the given time limit. Note, if the time limit is large
the TCP protocol may timeout before the supplied value.</dd>
<dt><strong><strong>iiop_connection_timeout</strong></strong></dt>
<dd>The value is an integer (timeout in seconds between 0 and 1000000)
or the atom infinity. This option is only valid for client object
connections, i.e., will have no effect on server connections. Setting this
option will cause client connections to be terminated, if and only if,
there are no pending requests. If there are a client still waiting for
a reply, Orber will try again after the given seconds have passed. The main
purpose for this option is to reduce the number of open connections; it is,
for example, not necessary to keep a connection, only used once a day,
open at all time.</dd>
<dt><strong><strong>iiop_in_connection_timeout</strong></strong></dt>
<dd>The same as for <span class="code">iiop_connection_timeout</span>. The only difference is
that this option only affects incoming connections (i.e. Orber act as
server-side ORB).</dd>
<dt><strong><strong>iiop_out_keepalive</strong></strong></dt>
<dd>Enables periodic transmission on a connected socket, when no other
data is being exchanged. If the other end does not respond, the
connection is considered broken and will be terminated.
When enabled the SO_KEEPALIVE socket level option is set.</dd>
<dt><strong><strong>iiop_in_keepalive</strong></strong></dt>
<dd>The same as for <span class="code">iiop_out_keepalive</span>. The only difference is
that this option only affects incoming connections.</dd>
<dt><strong><strong>iiop_timeout</strong></strong></dt>
<dd>The value is an integer (timeout in seconds between 0 and 1000000)
or the atom infinity. This option is only valid on the client side.
Setting this option, cause all intra-ORB requests to timeout and
raise a system exception, e.g. <span class="code">TIMEOUT</span>, if no replies are delivered
within the given time limit.</dd>
<dt><strong><strong>interceptors</strong></strong></dt>
<dd>If one set this parameter, e.g.,
<span class="code">erl -orber interceptors "{native, ['myInterceptor']}"</span>,
Orber will use the supplied interceptor(s) for all inter-ORB
communication. <span class="code">'myInterceptor'</span> is the module name of the
interceptor. For more information, see the interceptor chapter
in the User's Guide and the Reference Manual.</dd>
<dt><strong><strong>local_interceptors</strong></strong></dt>
<dd>If defined, its value will be
used when activating local interceptors via
<span class="bold_code"><a href="ch_install.html#flags">Orber Environment Flags</a></span>.
If not defined, but the flag is set, Orber will use the value of
the <span class="code">interceptors</span> parameter.</dd>
<dt><strong><strong>orbInitRef</strong></strong></dt>
<dd>Setting this option, e.g.,
<span class="code">erl -orber orbInitRef [\"NameService=corbaloc::host.com/NameService\"]</span>,
will alter the location from where <span class="code">corba:resolve_initial_references(Key)</span>
tries to find an object matching the given Key. The keys will also appear when
invoking <span class="code">corba:list_initial_services()</span>. This variable overrides
<span class="code">orbDefaultInitRef</span>
</dd>
<dt><strong><strong>orbDefaultInitRef</strong></strong></dt>
<dd>If a matching Key for <span class="code">orbInitRef</span> is not
found, and this variable is set, it determines the location from where
<span class="code">orber:resolve_initial_references(Key)</span> tries to find an object
matching the given Key. Usage:
<span class="code">erl -orber orbDefaultInitRef \"corbaloc::host.com\"</span>.</dd>
<dt><strong><strong>orber_debug_level</strong></strong></dt>
<dd>The range is 0 to 10.
Using level 10 is the most verbose configuration.
This option will generate reports, using the <span class="code">error_logger</span>,
for abnormal situations. It is not recommended to use this option
for delivered systems since some of the reports is not to be considered
as errors. The main purpose is to assist during development.</dd>
<dt><strong><strong>flags</strong></strong></dt>
<dd>No flags are activated in the default case.
The available configuration settings are described in
<span class="bold_code"><a href="ch_install.html#flags">Orber Environment Flags</a></span>.</dd>
<dt><strong><strong>iiop_acl</strong></strong></dt>
<dd>This option must be activated by setting
<span class="bold_code"><a href="ch_install.html#flags">Orber Environment Flags</a></span> parameter.
The value of this parameter shall be a list of <span class="code">[{Direction, Filter}]</span>
and/or <span class="code">[{Direction, Filter, [Interfaces]}]</span>. The <span class="code">Direction</span>,
<span class="code">tcp_in</span>, <span class="code">ssl_in</span>, <span class="code">tcp_out</span> or <span class="code">ssl_out</span>, determines if
the Access Control List (ACL) applies to incoming or outgoing connections
and IIOP or IIOP over SSL. The <span class="code">Filter</span> uses a extended format of
Classless Inter Domain Routing (CIDR). For example, <span class="code">"123.123.123.10"</span> limits
the connection to that particular host, while <span class="code">"123.123.123.10/17"</span> allows
connections to or from any host equal to the 17 most significant bits. Orber
also allow the user to specify a certain port or port range, for example,
<span class="code">"123.123.123.10/17#4001"</span> and <span class="code">"123.123.123.10/17#4001/5001"</span>
respectively. IPv4 or none compressed IPv6 strings are accepted. <br>
The list of <span class="code">Interfaces</span>, IPv4 or IPv6 strings, may only contain
<strong>one</strong> address for outgoing connections. For incoming connections,
the <span class="code">Interfaces</span> list may contain several IP strings. If set for
outgoing connections, and access is granted, Orber will use that local
interface when connecting to the server-side ORB. For incoming connections,
the client-side ORB is required to use one of the listed interfaces locally.
If it fail to do so, access will be denied. The module
<span class="bold_code"><a href="orber_acl.html">orber_acl</a></span> provides operations for
evaluating the access control for filters and addresses. See also the
<span class="bold_code"><a href="ch_install.html#interfaces">Interface Configuration</a></span>
and
<span class="bold_code"><a href="ch_install.html#firewall">Firewall Configuration</a></span>
chapters.</dd>
<dt><strong><strong>secure</strong></strong></dt>
<dd>Determines the security mode Orber will use, which is either
<span class="code">no</span> if it is an insecure domain or the type of security
mechanism used. Currently, per default, Orber is compliant with
<span class="code">CSIv1</span> level 0, which means IIOP via SSL/TLS.
The security chapter later in this manual describes how to get security
in Orber and how the options are used.</dd>
<dt><strong><strong>ssl_generation</strong></strong></dt>
<dd>Defines which SSL version, i.e. available API, is installed. The
default value, <span class="code">2</span>, refers to SSL-3.1 or later, but earlier than SSL-4.0.
If set to <span class="code">3</span> SSL-4.0, or later, must be available. Currently it not possible
to use <span class="code">1</span>, it is only reserved for future use.</dd>
<dt><strong><strong>iiop_ssl_port</strong></strong></dt>
<dd>If set, the value must be an
integer greater than zero and not equal to <strong>iiop_port</strong>.</dd>
<dt><strong><strong>iiop_ssl_accept_timeout</strong></strong></dt>
<dd>The value is an integer (timeout in seconds) or the atom infinity and
determine how long the SSL handshake may take. This option should
be set to avoid if a client never initiate the handshake.</dd>
<dt><strong><strong>iiop_ssl_backlog</strong></strong></dt>
<dd>Defines the maximum length the queue of pending incoming
connections may grow to.</dd>
<dt><strong><strong>iiop_ssl_ip_address_local</strong></strong></dt>
<dd>This option defines the default local interface Orber will
use when connecting to another ORB via IIOP SSL, i.e., Orber act as the
client side ORB. The value is a IPv4 or IPv6 address as a string.
It is possible to override <span class="code">iiop_ssl_ip_address_local</span> by defining
<span class="code">iiop_acl</span> or passing the Orber generic <span class="code">interface</span> Context.
If this option is not used, the underlying OS will choose which interface to
use. For more information, see the
<span class="bold_code"><a href="ch_install.html#interfaces">Interface Configuration</a></span>
section.</dd>
<dt><strong><strong>nat_iiop_ssl_port</strong></strong></dt>
<dd>If set, the value must be an integer greater than zero or
<span class="code">{local, DefaultNATPort, [{Port, NATPort}]}</span>. See also
<span class="bold_code"><a href="ch_install.html#firewall">Firewall Configuration</a></span>.</dd>
<dt><strong><strong>ssl_server_options</strong></strong></dt>
<dd>A list of the SSL options when Orber is the server.
In general it's just to remove the 'ssl_server_' prefix from the old options,
i.e. <span class="code">ssl_server_verify</span> will just be <span class="code">verify</span> in this option list.
See the <span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','ssl','ssl.html');">SSL application</a></span> for the correct list of possible
options and their values.
</dd>
<dt><strong><strong>ssl_client_options</strong></strong></dt>
<dd>A list of the SSL options when Orber is the client.
In general it's just to remove the <span class="code">ssl_client_</span> prefix from the old options,
i.e. <span class="code">ssl_client_depth</span> will just be <span class="code">depth</span> in this option list.
See the <span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','ssl','ssl.html');">SSL application</a></span> for the correct list of possible
options and their values.
</dd>
<dt><strong><strong>iiop_ssl_out_keepalive</strong></strong></dt>
<dd>Enables periodic transmission on a connected socket, when no other
data is being exchanged. If the other end does not respond, the
connection is considered broken and will be terminated.
When enabled the SO_KEEPALIVE socket level option is set. Requires that
the installed SSL version support the <strong>keepalive</strong> option
and that the <strong>ssl_generation</strong> points to this version.</dd>
<dt><strong><strong>iiop_ssl_in_keepalive</strong></strong></dt>
<dd>The same as for <span class="code">iiop_ssl_out_keepalive</span>. The only difference is
that this option only affects incoming connections.</dd>
</dl>
<p>It is possible to invoke operations using the extra timeout parameter:</p>
<div class="example"><pre>
erl> module_interface:function(ObjRef, Timeout, ..Arguments..).
erl> module_interface:function(ObjRef, [{timeout, Timeout}], ..Arguments..).
erl> module_interface:function(ObjRef, ..Arguments..). </pre></div>
<p>The extra Timeout argument will override the configuration parameter
<span class="code">iiop_timeout</span>. It is, however, not possible to use <span class="code">infinity</span>
to override the Timeout parameter. The Timeout option is also valid for
objects which resides within the same Orber domain.</p>
<p>The <span class="code">iiop_setup_connection_timeout</span>, <span class="code">iiop_timeout</span>,
<span class="code">iiop_connection_timeout</span> and <span class="code">iiop_in_connection_timeout</span>
variables should be used. The specified values is implementation specific,
i.e., WAN or LAN, but they should range from
<span class="code">iiop_setup_connection_timeout</span> to <span class="code">iiop_connection_timeout</span>.</p>
<p>To change these settings in the configuration file, the
<span class="code">-config</span> flag must be added to the erl command. See the
Reference Manual
<strong>config(4)</strong> for further information. The values can also
be sent separately as
options to the Erlang node when it is started, see the Reference
Manual
<strong>erl(1)</strong> for further information. </p>
<h4>Orber Environment Flags</h4>
<a name="flags"></a>
<p>The <span class="code">Environment Flags</span> allows the user to activate debugging
facilities or change Orber's behavior. The latter may result in that
Orber is no longer compliant with the OMG standard, which may be necessary
when communicating with a non-compliant ORB.</p>
<table border="1" cellpadding="2" cellspacing="0">
<tr>
<td align="left" valign="middle"><strong>Hexadecimal Value</strong></td>
<td align="left" valign="middle"><strong>OMG Compliant</strong></td>
<td align="left" valign="middle"><strong>Description</strong></td>
</tr>
<tr>
<td align="left" valign="middle">0001</td>
<td align="left" valign="middle">no</td>
<td align="left" valign="middle">Exclude CodeSet Component</td>
</tr>
<tr>
<td align="left" valign="middle">0002</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Local Typechecking</td>
</tr>
<tr>
<td align="left" valign="middle">0004</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Use Host Name in IOR</td>
</tr>
<tr>
<td align="left" valign="middle">0008</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Enable NAT</td>
</tr>
<tr>
<td align="left" valign="middle">0020</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Local Interceptors</td>
</tr>
<tr>
<td align="left" valign="middle">0080</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Light IFR</td>
</tr>
<tr>
<td align="left" valign="middle">0100</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Use IPv6</td>
</tr>
<tr>
<td align="left" valign="middle">0200</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">EXIT Tolerance</td>
</tr>
<tr>
<td align="left" valign="middle">0400</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Enable Incoming ACL</td>
</tr>
<tr>
<td align="left" valign="middle">0800</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Enable Outgoing ACL</td>
</tr>
<tr>
<td align="left" valign="middle">1000</td>
<td align="left" valign="middle">yes</td>
<td align="left" valign="middle">Use Current Interface in IOR</td>
</tr>
</table>
<em>Table
5.2:
Orber Environment Flags</em>
<p>Any combination of the flags above may be used and changes the
behavior as follows:</p>
<ul>
<li>
<strong>Exclude CodeSet Component</strong> - instruct Orber to exclude
the CodeSet component in exported IOR:s. When activated, no
negotiating regarding character and wide character conversions
between the client and the server will occur. This flag will,
most likely, cause problems if your IDL specification contains
the data types wchar and/or wstring.</li>
<li>
<strong>Local Typechecking</strong> -
If activated, parameters, replies and raised exceptions
will be checked to ensure that the data is correct. If an error
occurs, the <span class="code">error_logger</span> is used to generate reports.
One <strong>MAY NOT</strong> use this option for delivered systems due
to the extra overhead. Since this option activates typechecking
for all objects generated on the target node, it is also possible
to use the option <span class="code">{local_typecheck, boolean()}</span>, when
invoking <span class="code">oe_create/2</span>, <span class="code">oe_create_link/2</span>,
<span class="code">corba:create/4</span> or <span class="code">corba:create_link/4</span>, to override
the configuration parameter.</li>
<li>
<strong>Use Host Name in IOR</strong> - normally Orber inserts the IP-number
in IOR:s when they are exported. In some cases, this will cause
the clients to open two connections instead of one.</li>
<li>
<strong>Enable NAT</strong> - if this flag is set, it is possible to use
the NAT (Network Address Translation) configuration parameters
(<span class="code">nat_iiop_port</span>, <span class="code">nat_iiop_ssl_port</span> and
<span class="code">nat_ip_address</span>).</li>
<li>
<strong>Local Interceptors</strong> - use interceptors for local
invocations.</li>
<li>
<strong>Light IFR</strong> - if the IFR is not explicitly used and this
flag is set, Orber will use a minimal IFR to reduce memory usage
and installation time.</li>
<li>
<strong>Use IPv6</strong> - when this option is activated, Orber will use
<span class="code">IPv6</span> for inter-ORB communication.</li>
<li>
<strong>EXIT Tolerance</strong> - servers will survive even though the
call-back module caused an EXIT.</li>
<li>
<strong>Enable Incoming ACL</strong> - activates access control for incoming
connections.</li>
<li>
<strong>Enable Outgoing ACL</strong> - activates access control for outgoing
connections.</li>
<li>
<strong>Use Current Interface in IOR</strong> - when set, Orber will add
the interface the request came via to exported local IOR:s.</li>
</ul>
<p>Invoking the operation
<span class="bold_code"><a href="orber.html">orber:info/1/2</a></span> will display the currently
set flags in a readable way.</p>
<h3><a name="id76130">5.3
Firewall Configuration</a></h3>
<a name="firewall"></a>
<p>Firewalls are used to protect objects from clients in other networks or
sub-networks, but also to restrict which hosts internal objects may connect to
(i.e. <span class="code">inbound protection</span> and <span class="code">outbound protection</span>). A firewall
can limit access based on:</p>
<ul>
<li>
<strong>Transport Level</strong> - performs access control decisions based on
address information in TCP headers.</li>
<li>
<strong>Application Level</strong> - understands GIOP messages and the specific
transport level inter-ORB Protocol supported e.g. IIOP.</li>
</ul>
<p>This section describes how to configure a <span class="code">Transport Level</span> firewall. It
must have prior knowledge of the source to destination mappings, and
conceptually has a configuration table containing tuples of the form:
<span class="code">({inhost:inport}, {outhost:outport})</span>. If there are no port restrictions
it is rather easy to configure the firewall. Otherwise, we must consider the
following alternatives:</p>
<ul>
<li>
<strong>Incoming Requests</strong> - Orber only uses the port-numbers specified
by the configuration parameters <strong>iiop_port</strong> and
<strong>iiop_ssl_port</strong>. Other ORB's may use several ports but it should
be possible to change this behavior. Consult the other ORBs
documentation.</li>
<li>
<strong>Outgoing Requests</strong> - Most ORB's, Orber included,
ask the OS to supply a vacant local port when connecting to the
server-side ORB. It is possible to change this behavior when using
Orber (i.e. set the configuration parameter <strong>iiop_out_ports</strong>).</li>
</ul>
<div class="warning">
<div class="label">Warning</div>
<div class="content"><p>
<p>Using the option <span class="code">iiop_out_ports</span> may result in that Orber runs out of
valid ports numbers. For example, other applications may steal some of the
ports or the number of concurrent outgoing connections to other ORBs may be
higher than expected. To reduce, but not eliminate, the risk you should use
<span class="code">iiop_connection_timeout</span>.</p>
</p></div>
</div>
<p>Firewall configuration example:</p>
<div class="example"><pre>
# "Plain" IIOP
To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X
To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port)
# IIOP via SSL
To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X
To: Orber-IPNo:(iiop_ssl_port) From: ORB-IPNo:Y
To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port)
</pre></div>
<p>If the communication take place via a
<span class="bold_code"><a href="ch_install.html#firewall_nat">TCP Firewall with NAT</a></span>
(Network Address Translation), we must activate this behavior and define
the external address and/or ports.</p>
<a name="firewall_nat"></a>
<img alt="IMAGE MISSING" src="firewall_nat.gif"><br>
<em>Figure
5.1:
TCP Firewall With NAT</em>
<p>Using NAT makes it possible to use different host data for different network
domains. This way we can share Internet Protocol address resources or
obscure resources. To enable this feature the
<span class="bold_code"><a href="ch_install.html#flags">Enable NAT</a></span> flag must be set and
<span class="code">nat_iiop_port</span>, <span class="code">nat_iiop_ssl_port</span> and <span class="code">nat_ip_address</span>
configured, which maps to <span class="code">iiop_port</span>, <span class="code">iiop_ssl_port</span> and
<span class="code">ip_address</span> respectively. Hence, the firewall must be configured to
translate the external to the internal representation correctly. If these NAT parameters
are assigned a single port number or IP address, only those will be used when
an IOR is exported to another ORB. When <span class="code">ip_address</span> is set to
<span class="code">{multiple, [IPAddress]}</span>, <span class="code">nat_ip_address</span> should be configured in the same
way, so that each NAT IP address can be translated to a valid address by the firewall.
If objects are supposed to be accessible via different interfaces and port, see also
<span class="bold_code"><a href="ch_install.html#interfaces">Interface Configuration</a></span>,
the options <span class="code">{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</span> and/or
<span class="code">{local, DefaultNATPort, [{Port, NATPort}]}</span> shall be used. The default NAT IP address
and port, should be translated to the value of <span class="code">ip_address_local</span> and the default
listen port by the firewall. If the IP address and/or port is not found in the list,
the default values will be inserted in the IOR. The firewall must be able to translate
these correctly.</p>
<p>If it is necessary to limit the access to an ORB within a secure network,
but other applications running on the same host may not be blocked out,
one can use a <strong>Application Level</strong> firewall or Orber Access Control
List (ACL). The latter makes it possible for the user to define which hosts
may communicate, either as server or client, with Orber. This is achieved by
defining the configuration parameter
<span class="bold_code"><a href="ch_install.html#config">iiop_acl</a></span>. The Classless Inter
Domain Routing (CIDR) <span class="code">Filter</span> determines which peer interfaces and
ports the other ORB may use.</p>
<table border="1" cellpadding="2" cellspacing="0">
<tr>
<td align="left" valign="middle"><strong>Filter</strong></td>
<td align="left" valign="middle"><strong>Peer Interface(s)</strong></td>
<td align="left" valign="middle"><strong>Peer Port(s)</strong></td>
</tr>
<tr>
<td align="left" valign="middle">"10.1.1.1"</td>
<td align="left" valign="middle">10.1.1.1</td>
<td align="left" valign="middle">any</td>
</tr>
<tr>
<td align="left" valign="middle">"10.1.1.1/8"</td>
<td align="left" valign="middle">10.0.0.0-10.255.255.255</td>
<td align="left" valign="middle">any</td>
</tr>
<tr>
<td align="left" valign="middle">"10.1.1.1/8#4001"</td>
<td align="left" valign="middle">10.0.0.0-10.255.255.255</td>
<td align="left" valign="middle">4001</td>
</tr>
<tr>
<td align="left" valign="middle">"10.1.1.1/8#4001/5001"</td>
<td align="left" valign="middle">10.0.0.0-10.255.255.255</td>
<td align="left" valign="middle">4001-5001</td>
</tr>
</table>
<em>Table
5.3:
Orber ACL Filters</em>
<p>Orber ACL, also allows the user to define which local interface(s) may be used,
but will not detect <span class="code">spoofing</span>. The operation
<span class="bold_code"><a href="orber_acl.html">orber_acl:match/2/3</a></span> makes it easy to
verify whether access would be granted or not. For example, if Orber would
be started with the ACL <span class="code">[{tcp_out, "10.1.1.1/8#4001/5001"}]</span>, then
<span class="code">orber_acl:match/2</span> would behave as follows:</p>
<div class="example"><pre>
erl> orber_acl:match({11,1,1,1}, tcp_out).
false
erl> orber_acl:match({10,1,1,1}, tcp_out).
true
erl> orber_acl:match({11,1,1,1}, tcp_out, true).
{false,[],0}
erl> orber_acl:match({10,1,1,1}, tcp_out, true).
{true,[],{4001,5001}}
</pre></div>
<p>Only if the returned boolean is true the extra return values makes a
difference. In the example above, <span class="code">{true,[],{4001,5001}}</span> means that
Orber may connect to <span class="code">"10.1.1.1"</span>, using any local interface,
if the server-side ORB listens for incoming connect requests on a port
within the range 4001-5001. Note, invoking the <span class="code">orber_acl:match/2/3</span>
operation, will not result in a connect attempt by Orber. The reason for
this, is that this function may be used on a live node as well as in test
environment. Hence, if a local interface is currently not available or no
server-side ORB available via the given host/port(s), will not be detected
by Orber.</p>
<h3><a name="id76571">5.4
Interface Configuration</a></h3>
<a name="interfaces"></a>
<p>In many cases it is sufficient to simply configure the underlying OS which
local interfaces shall be used for all applications. But, in some cases
it is required, due to, for example, the firewall configuration, that different
local interfaces are used for different applications. Some times, it is even
necessary to use a specific interface for a single CORBA object. This section
describe how one can alter this in different ways.</p>
<p>The default behavior is that Orber lets the OS configuration decide which interface
will be added in IOR:s exported to another ORB and the local interface used
when connecting to another ORB (Orber act as client side ORB). The latter can be
overridden by setting the configuration parameters <span class="code">iiop_ssl_ip_address_local</span>
and/or <span class="code">ip_address_local</span>, which will affect IIOP via SSL and IIOP
respectively. These parameters can be overridden by using the Orber generic
<span class="code">interface</span> Context or defining an ACL (Access Control List). The latter
always takes precedence if a local interface is included (e.g.
<span class="code">[{tcp_out, "10.0.0.0/8", ["10.0.0.1"]}]</span>). If the interface is excluded
(e.g. <span class="code">[{tcp_out, "10.0.0.0/8"}]</span>), the interface chosen will, in the following
order, be determined by
<span class="code">#'IOP_ServiceContext'{}</span>, <span class="code">ip_address_local/iiop_ssl_ip_address_local</span> or
the configuration of the underlying system.</p>
<p>Adding the interface context, for generated stubs/skeletons, is done in the
following way:</p>
<div class="example"><pre>
Ctx = #'IOP_ServiceContext'{context_id = ?ORBER_GENERIC_CTX_ID,
context_data = {interface, "10.0.0.1"}},
'CosNaming_NamingContext':resolve(NS, [{context, [Ctx]}], Name),
</pre></div>
<p>It is also possible to add the context to
<span class="code">corba:string_to_object/2, corba:resolve_initial_references/2, corba:resolve_initial_references_remote/3, corba:list_initial_services_remote/2, corba_object:not_existent/2, corba_object:non_existent/2</span> and <span class="code">corba_object:is_a/3</span>.
The operations exported by <span class="code">corba_object</span> are affected
if the supplied IOR is external. The function <span class="code">corba:string_to_object/2</span>
might require the interface context if a <span class="code">corbaloc</span> or a <span class="code">corbaloc</span>
string is passed (See the
<span class="bold_code"><a href="ch_naming_service.html#interop_ns">INS</a></span> chapter),
while <span class="code">corba:resolve_initial_references_remote/3</span> and
<span class="code">corba:list_initial_services_remote/2</span> always connect to another ORB and
it might be necessary to add the context.
The remaining <span class="code">corba</span> operations are affected if calls are re-directed
by setting the <span class="code">orbInitRef</span> and/or <span class="code">orbDefaultInitRef</span> configuration
parameters. For more information, see the Reference Manual for each module.</p>
<p>Configuring which interface(s) that shall be used when exporting an IOR to
another ORB, is determined by <span class="code">nat_ip_address</span>, setting the flag
<span class="bold_code"><a href="ch_install.html#flags">16#1000</a></span>
and <span class="code">ip_address</span>, in that order. Orber listens for incoming connections
either via all interfaces or the interface defined by <span class="code">ip_address</span>. It is
also possible to add and remove extra listen interfaces by using
<span class="code">orber:add_listen_interface/2/3</span> and <span class="code">orber:remove_listen_interface/1</span>.
In this case one should set the 16#1000 flag and, if necessary, set the
configuration parameters
<span class="code">{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</span> and/or
<span class="code">{local, DefaultNATPort, [{Port, NATPort}]}</span>.</p>
</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
1083
