The R13B03 release.OTP_R13B03

1 files changed, 1071 insertions, 0 deletions

diff --git a/lib/orber/doc/src/ch_install.xml b/lib/orber/doc/src/ch_install.xml
new file mode 100644
index 0000000000..eee2b99c92
--- /dev/null
+++ b/lib/orber/doc/src/ch_install.xml
@@ -0,0 +1,1071 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>1997</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Installing Orber</title>
+    <prepared></prepared>
+    <responsible></responsible>
+    <docno></docno>
+    <approved></approved>
+    <checked></checked>
+    <date>1998-09-28</date>
+    <rev></rev>
+    <file>ch_install.xml</file>
+  </header>
+
+  <section>
+    <title>Installation Process </title>
+    <p>This chapter describes how to install Orber in an Erlang
+      Environment.</p>
+
+    <section>
+      <title>Preparation</title>
+      <p>To begin with, you must decide if you want to run Orber as a:</p>
+      <list type="bulleted">
+        <item><em>Single node (non-distributed)</em> - all communication with other
+         Orber instances and ORB's supplied by other vendors use the OMG
+         GIOP protocol.</item>
+        <item><em>Multi node (distributed)</em> - all Orber nodes, within the same
+        <c>domain</c>, communicate via the Erlang distribution protocol.
+         For all other Orber instances, i.e. not part of the same <c>domain</c>,
+         and ORB's supplied by other vendors, the OMG GIOP protocol
+         is used.</item>
+      </list>
+      <p>Which approach to use is highly implementation specific, but a few
+        things you should consider:</p>
+      <list type="bulleted">
+        <item>All nodes within an Orber domain should have the same
+         security level.</item>
+        <item>If the capacity is greater than load (volume of traffic)
+         a single-node Orber might be a good solution.</item>
+        <item>In some cases the distributed system architecture requires a
+         single-node <term id="Orber installation"><termdef>is the structure of the ORB or ORBs as defined during the install process is called the "installation".</termdef></term>.</item>
+        <item>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.</item>
+        <item>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).</item>
+      </list>
+      <p>You also have to decide if you want Orber to store internal data using
+        <c>disc_copies</c> and/or <c>ram_copies</c>. Which storage type you should
+        depends if/how you intend to use Mnesia in your application. If you
+        intend to use <c>disc_copies</c> 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 <c>domain</c> domain. Consult the
+        <seealso marker="ch_install#config">configuration settings</seealso>
+        section. If  you encounter any problems; see the chapter about 
+        <em>Debugging</em> in this User's Guide.</p>
+    </section>
+
+    <section>
+      <title>Jump Start Orber</title>
+      <p>The easiest way to start Orber is to use <c>orber:jump_start(Port)</c>,
+        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>
+      <warning>
+        <p>How Orber is configured when using <c>orber:jump_start(Port)</c>
+          may change at any time without warning. Hence, this operation must
+          not be used in systems delivered to a customer.</p>
+      </warning>
+    </section>
+
+    <section>
+      <title>Install Single Node Orber</title>
+      <p>Since a single node Orber communicate via the OMG GIOP protocol it is not
+        necessary to start the Erlang distribution (i.e. using <c>-name/-sname</c>).</p>
+      <p>If we use <c>ram_copies</c> there is no need for creating a disk based
+        schema. Simply use:</p>
+      <code type="none">
+erl> mnesia:start().
+erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]).
+erl> orber:install([node()], [{ifr_storage_type, ram_copies}]).
+erl> orber:start().
+      </code>
+      <p>If you installation requires <c>disc_copies</c> you must begin with
+        creating a Mnesia schema. Otherwise, the installation is similar
+        to a RAM installation:</p>
+      <code type="none">
+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().
+      </code>
+      <p>You can still choose to store the IFR data as ram_copies, but then
+        the data must be re-installed (i.e. invoke <c>orber:install/2</c>)
+        if the node is restarted. Hence, since the IFR data is rather static
+        you should use <c>disc_copies</c>. For more information see the
+        <c>orber</c> section in the reference manual.</p>
+      <p>If you do not need to change Orber's configuration you can skip
+        <seealso marker="corba">orb_init/1</seealso>. 
+        But, you <em>should</em> at least set the IIOP timeout parameters.</p>
+    </section>
+
+    <section>
+      <title>Install RAM Based Multi Node Orber</title>
+      <p>Within a domain Orber uses the Erlang distribution protocol. Hence, you
+        <em>must</em> start it first by, for example, using:</p>
+      <code type="none">
+hostA> erl -sname nodeA
+      </code>
+      <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
+        <c>nodeB</c>. Since Mnesia must know which other nodes should a part
+        of the distribution we either need to add the Mnesia configuration
+        parameter <c>extra_db_nodes</c> or use <c>mnesia:change_config/2</c>. To 
+        begin with, Mnesia must be started on all nodes before we can install
+        Orber:</p>
+      <code type="none">
+nodeA@hostA> mnesia:start().
+nodeA@hostA> mnesia:change_config(extra_db_nodes, 
+                                  [nodeA@hostA, nodeB@hostB]).
+      </code>
+      <p>After that the above have been repeated on <c>nodeB</c> we must
+        first make sure that both nodes will use the same domain name, then
+        we can install Orber:</p>
+      <code type="none">
+nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
+nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
+                           [{ifr_storage_type, ram_copies}]).
+nodeA@hostA> orber:start().
+      </code>
+      <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
+        nodes. Now we can start Orber on the other node:</p>
+      <code type="none">
+nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
+nodeB@hostB> orber:start().
+      </code>
+    </section>
+
+    <section>
+      <title>Install Disk Based Multi Node Orber</title>
+      <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>
+      <code type="none">
+nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]).
+nodeA@hostA> mnesia:start().
+      </code>
+      <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
+        <c>nodeB</c>. 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 
+        <c>mnesia:start()</c>) on <c>nodeB</c>.</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>
+      <code type="none">
+nodeA@hostA> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
+nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
+                           [{ifr_storage_type, disc_copies}]).
+nodeA@hostA> orber:start().
+      </code>
+      <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
+        nodes. Now we can start Orber on the other node:</p>
+      <code type="none">
+nodeB@hostB> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
+nodeB@hostB> orber:start().
+      </code>
+    </section>
+
+  </section>
+
+  <section>
+    <title>Configuration</title>
+    <marker id="config"></marker>
+    <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
+      <seealso marker="orber">orber:info/1/2</seealso>.
+      Orber offer the following configuration parameters:</p>
+    <table>
+      <row>
+        <cell align="center" valign="middle"><em>Key</em></cell>
+        <cell align="center" valign="middle"><em>Range</em></cell>
+        <cell align="center" valign="middle"><em>Default</em></cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">domain</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">"ORBER"</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_port</cell>
+        <cell align="left" valign="middle">integer() >= 0</cell>
+        <cell align="left" valign="middle">4001</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">nat_iiop_port</cell>
+        <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
+        <cell align="left" valign="middle">The same as <c>iiop_port</c></cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_out_ports</cell>
+        <cell align="left" valign="middle">0 | {integer(),integer()}</cell>
+        <cell align="left" valign="middle">0</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_max_fragments</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_max_in_requests</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_max_in_connections</cell>
+        <cell align="left" valign="middle">integer() > 0</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_backlog</cell>
+        <cell align="left" valign="middle">integer() > 0</cell>
+        <cell align="left" valign="middle">5</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_packet_size</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ip_address</cell>
+        <cell align="left" valign="middle">string() | {multiple, [string()]}</cell>
+        <cell align="left" valign="middle">All interfaces</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ip_address_local</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">Defined by the underlying system</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">nat_ip_address</cell>
+        <cell align="left" valign="middle">string() | {multiple, [string()]} |  {local, string(), [{string(), string()}]}</cell>
+        <cell align="left" valign="middle">The same as <c>ip_address</c></cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">objectkeys_gc_time</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">giop_version</cell>
+        <cell align="left" valign="middle">{1,0} | {1,1} | {1,2}</cell>
+        <cell align="left" valign="middle">{1,1}</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_setup_connection_timeout</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_connection_timeout</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_in_connection_timeout</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_out_keepalive</cell>
+        <cell align="left" valign="middle">true | false</cell>
+        <cell align="left" valign="middle">false</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_in_keepalive</cell>
+        <cell align="left" valign="middle">true | false</cell>
+        <cell align="left" valign="middle">false</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_timeout</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">interceptors</cell>
+        <cell align="left" valign="middle">{native, [atom()]}</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">local_interceptors</cell>
+        <cell align="left" valign="middle">{native, [atom()]}</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">orbInitRef</cell>
+        <cell align="left" valign="middle">[string()] | undefined</cell>
+        <cell align="left" valign="middle">undefined</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">orbDefaultInitRef</cell>
+        <cell align="left" valign="middle">string() | undefined</cell>
+        <cell align="left" valign="middle">undefined</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">orber_debug_level</cell>
+        <cell align="left" valign="middle">0 - 10</cell>
+        <cell align="left" valign="middle">0</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">flags</cell>
+        <cell align="left" valign="middle">integer() >= 0</cell>
+        <cell align="left" valign="middle">0</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_acl</cell>
+        <cell align="left" valign="middle">[{atom(), string()}] | [{atom(), string(), [string()]}]</cell>
+        <cell align="left" valign="middle">[]</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">secure</cell>
+        <cell align="left" valign="middle">no | ssl</cell>
+        <cell align="left" valign="middle">no</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_generation</cell>
+        <cell align="left" valign="middle">2 | 3</cell>
+        <cell align="left" valign="middle">2</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_port</cell>
+        <cell align="left" valign="middle">integer() >= 0</cell>
+        <cell align="left" valign="middle">4002</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_accept_timeout</cell>
+        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_backlog</cell>
+        <cell align="left" valign="middle">integer() > 0</cell>
+        <cell align="left" valign="middle">5</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_ip_address_local</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">Defined by the underlying system</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">nat_iiop_ssl_port</cell>
+        <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
+        <cell align="left" valign="middle">The same as <c>iiop_ssl_port</c></cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_cacertfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_certfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_verify</cell>
+        <cell align="left" valign="middle">0 | 1 | 2</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_depth</cell>
+        <cell align="left" valign="middle">integer()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_password</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_keyfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_ciphers</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_server_cachetimeout</cell>
+        <cell align="left" valign="middle">integer() | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_cacertfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_certfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_verify</cell>
+        <cell align="left" valign="middle">0 | 1 | 2</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_depth</cell>
+        <cell align="left" valign="middle">integer()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_password</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_keyfile</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_ciphers</cell>
+        <cell align="left" valign="middle">string()</cell>
+        <cell align="left" valign="middle">-</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">ssl_client_cachetimeout</cell>
+        <cell align="left" valign="middle">integer() | infinity</cell>
+        <cell align="left" valign="middle">infinity</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_out_keepalive</cell>
+        <cell align="left" valign="middle">true | false</cell>
+        <cell align="left" valign="middle">false</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">iiop_ssl_in_keepalive</cell>
+        <cell align="left" valign="middle">true | false</cell>
+        <cell align="left" valign="middle">false</cell>
+      </row>
+      <tcaption>Orber Configuration Parameters</tcaption>
+    </table>
+    <br></br>
+    <br></br>
+    <p><em>Comments on the table 'Orber Configuration Parameters':</em></p>
+    <taglist>
+      <tag><em>domain</em></tag>
+      <item>Since Orber domains, they are supposed to communicate via IIOP,
+      <em>MUST</em> have unique names, communication will
+       fail if two domains have the same name. The domain name <em>MAY NOT</em>
+       contain <c>^G</c> (i.e. <c>\\007</c>).</item>
+      <tag><em>iiop_port</em></tag>
+      <item>If set to 0 the OS will pick any vacant port. 
+            <br></br>
+<em>Note:</em>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.</item>
+      <tag><em>nat_iiop_port</em></tag>
+      <item>The value is either an integer or <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
+      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
+      <tag><em>iiop_out_ports</em></tag>
+      <item>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 <em>absolutely necessary</em> to
+       set <c>iiop_connection_timeout</c> as well. Otherwise, connections
+       no longer in use will block further communication. If one use, for
+       example, <c>erl -orber iiop_out_ports "{5000,5020}"</c>, Orber
+       will only use port 5000 to 5020 when connecting.
+       If communicating via SSL, make sure you use a version that supports
+       the local <c>{port, Port}</c> option. See also
+      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
+      <tag><em>iiop_max_fragments</em></tag>
+      <item>Limits the number of IIOP fragments allowed per request.</item>
+      <tag><em>iiop_max_in_requests</em></tag>
+      <item>Limits the number of concurrent incoming requests per incoming connection.</item>
+      <tag><em>iiop_max_in_connections</em></tag>
+      <item>Limits the number of concurrent incoming connections.</item>
+      <tag><em>iiop_backlog</em></tag>
+      <item>Defines  the maximum length the queue of pending incoming
+       connections may grow to.</item>
+      <tag><em>iiop_packet_size</em></tag>
+      <item>Defines the maximum size of incoming requests.
+       If this limit is exceeded, the connection is closed.</item>
+      <tag><em>ip_address</em></tag>
+      <item>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 <c>{multiple, IPList}</c>.
+       The latter requires that the object is available via the all IP addresses
+       found in the list.</item>
+      <tag><em>ip_address_local</em></tag>
+      <item>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 <c>ip_address_local</c> by defining
+      <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
+       If this option is not used, the underlying OS will choose which interface to
+       use. For more information, see the
+      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
+       section.</item>
+      <tag><em>nat_ip_address</em></tag>
+      <item>The value is the ip address as
+       a string (IPv4 or IPv6), <c>{multiple, IPList}</c> or 
+      <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c>. See also
+      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
+      <tag><em>objectkeys_gc_time</em></tag>
+      <item>This option should be set if objects are started
+       using the option <c>{persistent, true}</c>.
+       The value is <c>integer()</c> seconds.</item>
+      <tag><em>giop_version</em></tag>
+      <item>Defines the default GIOP protocol version.</item>
+      <tag><em>iiop_setup_connection_timeout</em></tag>
+      <item>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.</item>
+      <tag><em>iiop_connection_timeout</em></tag>
+      <item>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.</item>
+      <tag><em>iiop_in_connection_timeout</em></tag>
+      <item>The same as for <c>iiop_connection_timeout</c>. The only difference is
+       that this option only affects incoming connections (i.e. Orber act as
+       server-side ORB).</item>
+      <tag><em>iiop_out_keepalive</em></tag>
+      <item>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.</item>
+      <tag><em>iiop_in_keepalive</em></tag>
+      <item>The same as for <c>iiop_out_keepalive</c>. The only difference is
+       that this option only affects incoming connections.</item>
+      <tag><em>iiop_timeout</em></tag>
+      <item>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. <c>TIMEOUT</c>, if no replies are delivered
+       within the given time limit.</item>
+      <tag><em>interceptors</em></tag>
+      <item>If one set this parameter, e.g.,
+      <c>erl -orber interceptors "{native, ['myInterceptor']}"</c>,
+       Orber will use the supplied interceptor(s) for all inter-ORB 
+       communication. <c>'myInterceptor'</c> is the module name of the
+       interceptor. For more information, see the interceptor chapter
+       in the User's Guide and the Reference Manual.</item>
+      <tag><em>local_interceptors</em></tag>
+      <item>If defined, its value will be
+       used when activating local interceptors via
+      <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.
+       If not defined, but the flag is set, Orber will use the value of
+       the <c>interceptors</c> parameter.</item>
+      <tag><em>orbInitRef</em></tag>
+      <item>Setting this option, e.g., 
+      <c>erl -orber orbInitRef [\\"NameService=corbaloc::host.com/NameService\\"]</c>, 
+       will alter the location from where <c>corba:resolve_initial_references(Key)</c> 
+       tries to find an object matching the given Key. The keys will also appear when
+       invoking <c>corba:list_initial_services()</c>. This variable overrides
+      <c>orbDefaultInitRef</c></item>
+      <tag><em>orbDefaultInitRef</em></tag>
+      <item>If a matching Key for <c>orbInitRef</c> is not
+       found, and this variable is set, it determines the location from where 
+      <c>orber:resolve_initial_references(Key)</c> tries to find an object 
+       matching the given Key. Usage:
+      <c>erl -orber orbDefaultInitRef \\"corbaloc::host.com\\"</c>.</item>
+      <tag><em>orber_debug_level</em></tag>
+      <item>The range is 0 to 10.
+       Using level 10 is the most verbose configuration.
+       This option will generate reports, using the <c>error_logger</c>,
+       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.</item>
+      <tag><em>flags</em></tag>
+      <item>No flags are activated in the default case.
+       The available configuration settings are described in
+      <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.</item>
+      <tag><em>iiop_acl</em></tag>
+      <item>This option must be activated by setting 
+      <seealso marker="ch_install#flags">Orber Environment Flags</seealso> parameter.
+       The value of this parameter shall be a list of <c>[{Direction, Filter}]</c> 
+       and/or <c>[{Direction, Filter, [Interfaces]}]</c>. The <c>Direction</c>, 
+      <c>tcp_in</c>, <c>ssl_in</c>, <c>tcp_out</c> or <c>ssl_out</c>, determines if
+       the Access Control List (ACL) applies to incoming or outgoing connections
+       and IIOP or IIOP over SSL. The <c>Filter</c> uses a extended format of 
+       Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits
+       the connection to that particular host, while <c>"123.123.123.10/17"</c> 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,
+      <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
+       respectively. IPv4 or none compressed IPv6 strings are accepted.      <br></br>
+
+       The list of <c>Interfaces</c>, IPv4 or IPv6 strings, may only contain 
+      <em>one</em> address for outgoing connections. For incoming connections,
+       the <c>Interfaces</c> 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 
+      <seealso marker="orber_acl">orber_acl</seealso> provides operations for
+       evaluating the access control for filters and addresses. See also the
+      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
+       and
+      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>
+       chapters.</item>
+      <tag><em>secure</em></tag>
+      <item>Determines the security mode Orber will use, which is either 
+      <c>no</c> if it is an insecure domain or the type of security 
+       mechanism used. Currently, per default, Orber is compliant with
+      <c>CSIv1</c> 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.</item>
+      <tag><em>ssl_generation</em></tag>
+      <item>Defines which SSL version, i.e. available API, is installed. The
+      default value, <c>2</c>, refers to SSL-3.1 or later, but earlier than SSL-4.0.
+      If set to <c>3</c> SSL-4.0, or later, must be available. Currently it not possible
+      to use <c>1</c>, it is only reserved for future use.</item>
+      <tag><em>iiop_ssl_port</em></tag>
+      <item>If set, the value must be an
+       integer greater than zero and not equal to <em>iiop_port</em>.</item>
+      <tag><em>iiop_ssl_accept_timeout</em></tag>
+      <item>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.</item>
+      <tag><em>iiop_ssl_backlog</em></tag>
+      <item>Defines  the maximum length the queue of pending incoming
+       connections may grow to.</item>
+      <tag><em>iiop_ssl_ip_address_local</em></tag>
+      <item>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 <c>iiop_ssl_ip_address_local</c> by defining
+      <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
+       If this option is not used, the underlying OS will choose which interface to
+       use. For more information, see the
+      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
+       section.</item>
+      <tag><em>nat_iiop_ssl_port</em></tag>
+      <item>If set, the value must be an integer greater than zero or 
+      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
+      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
+      <tag><em>ssl_server_cacertfile</em></tag>
+      <item>the file path to a server side CA certificate.</item>
+      <tag><em>ssl_server_certfile</em></tag>
+      <item>The path to a file containing a chain of PEM encoded certificates.</item>
+      <tag><em>ssl_server_verify</em></tag>
+      <item>The type of verification used by SSL during authentication of the
+       other peer for incoming calls.</item>
+      <tag><em>ssl_server_depth</em></tag>
+      <item>The SSL verification depth for outgoing calls.</item>
+      <tag><em>ssl_server_password</em></tag>
+      <item>The server side key string.</item>
+      <tag><em>ssl_server_keyfile</em></tag>
+      <item>The file path to a server side key.</item>
+      <tag><em>ssl_server_ciphers</em></tag>
+      <item>The server side cipher string.</item>
+      <tag><em>ssl_server_cachetimeout</em></tag>
+      <item>The server side cache timeout.</item>
+      <tag><em>ssl_client_cacertfile</em></tag>
+      <item>The file path to a client side CA certificate.</item>
+      <tag><em>ssl_client_certfile</em></tag>
+      <item>The path to a file containing a chain of PEM encoded certificates.</item>
+      <tag><em>ssl_client_verify</em></tag>
+      <item>The type of verification used by SSL during authentication of the
+       other peer for outgoing calls.</item>
+      <tag><em>ssl_client_depth</em></tag>
+      <item>The SSL verification depth for incoming calls.</item>
+      <tag><em>ssl_client_password</em></tag>
+      <item>The client side key string.</item>
+      <tag><em>ssl_client_keyfile</em></tag>
+      <item>The file path to a client side key.</item>
+      <tag><em>ssl_client_ciphers</em></tag>
+      <item>The client side cipher string.</item>
+      <tag><em>ssl_client_cachetimeout</em></tag>
+      <item>The client side cache timeout.</item>
+      <tag><em>iiop_ssl_out_keepalive</em></tag>
+      <item>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 <em>keepalive</em> option
+       and that the <em>ssl_generation</em> points to this version.</item>
+      <tag><em>iiop_ssl_in_keepalive</em></tag>
+      <item>The same as for <c>iiop_ssl_out_keepalive</c>. The only difference is
+       that this option only affects incoming connections.</item>
+    </taglist>
+    <p>It is possible to invoke operations using the extra timeout parameter:</p>
+    <pre>
+erl> module_interface:function(ObjRef, Timeout, ..Arguments..).
+erl> module_interface:function(ObjRef, [{timeout, Timeout}], ..Arguments..).
+erl> module_interface:function(ObjRef, ..Arguments..).    </pre>
+    <p>The extra Timeout argument will override the configuration parameter 
+      <c>iiop_timeout</c>. It is, however, not possible to use <c>infinity</c>
+      to override the Timeout parameter. The Timeout option is also valid for 
+      objects which resides within the same <term id="Orber domain"><termdef>A domain containing several Erlang nodes, which are communicating  by using the Erlang internal format. An Orber domain looks as one ORB from the environment.</termdef></term>.</p>
+    <p>The <c>iiop_setup_connection_timeout</c>, <c>iiop_timeout</c>,
+      <c>iiop_connection_timeout</c> and <c>iiop_in_connection_timeout</c>
+      variables should be used. The specified values is implementation specific, 
+      i.e., WAN or LAN, but they should range from 
+      <c>iiop_setup_connection_timeout</c> to <c>iiop_connection_timeout</c>.</p>
+    <p>To change these settings in the configuration file, the
+      <c>-config</c> flag must be added to the erl command. See the
+      Reference Manual 
+      <em>config(4)</em> for further information. The values can also
+      be sent separately as
+      options  to the Erlang node when it is started, see the Reference
+      Manual 
+      <em>erl(1)</em> for further information. </p>
+
+    <section>
+      <marker id="flags"></marker>
+      <title>Orber Environment Flags</title>
+      <p>The <c>Environment Flags</c> 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>
+        <row>
+          <cell align="left" valign="middle"><em>Hexadecimal Value</em></cell>
+          <cell align="left" valign="middle"><em>OMG Compliant</em></cell>
+          <cell align="left" valign="middle"><em>Description</em></cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0001</cell>
+          <cell align="left" valign="middle">no</cell>
+          <cell align="left" valign="middle">Exclude CodeSet Component</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0002</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Local Typechecking</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0004</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Use Host Name in IOR</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0008</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Enable NAT</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0020</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Local Interceptors</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0080</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Light IFR</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0100</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Use IPv6</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0200</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">EXIT Tolerance</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0400</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Enable Incoming ACL</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">0800</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Enable Outgoing ACL</cell>
+        </row>
+        <row>
+          <cell align="left" valign="middle">1000</cell>
+          <cell align="left" valign="middle">yes</cell>
+          <cell align="left" valign="middle">Use Current Interface in IOR</cell>
+        </row>
+        <tcaption>Orber Environment Flags</tcaption>
+      </table>
+      <p>Any combination of the flags above may be used and changes the
+        behavior as follows:</p>
+      <list type="bulleted">
+        <item><em>Exclude CodeSet Component</em> - 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.</item>
+        <item><em>Local Typechecking</em> -
+         If activated, parameters, replies and raised exceptions
+         will be checked to ensure that the data is correct. If an error
+         occurs, the <c>error_logger</c> is used to generate reports.
+         One <em>MAY NOT</em> 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 <c>{local_typecheck, boolean()}</c>, when
+         invoking <c>oe_create/2</c>, <c>oe_create_link/2</c>,
+        <c>corba:create/4</c> or <c>corba:create_link/4</c>, to override
+         the configuration parameter.</item>
+        <item><em>Use Host Name in IOR</em> - 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.</item>
+        <item><em>Enable NAT</em> - if this flag is set, it is possible to use
+         the NAT (Network Address Translation) configuration parameters
+         (<c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and 
+        <c>nat_ip_address</c>).</item>
+        <item><em>Local Interceptors</em> - use interceptors for local
+         invocations.</item>
+        <item><em>Light IFR</em> - 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.</item>
+        <item><em>Use IPv6</em> - when this option is activated, Orber will use
+        <c>IPv6</c> for inter-ORB communication.</item>
+        <item><em>EXIT Tolerance</em> - servers will survive even though the
+         call-back module caused an EXIT.</item>
+        <item><em>Enable Incoming ACL</em> - activates access control for incoming
+         connections.</item>
+        <item><em>Enable Outgoing ACL</em> - activates access control for outgoing
+         connections.</item>
+        <item><em>Use Current Interface in IOR</em> - when set, Orber will add
+         the interface the request came via to exported local IOR:s.</item>
+      </list>
+      <p>Invoking the operation
+        <seealso marker="orber">orber:info/1/2</seealso> will display the currently
+        set flags in a readable way.</p>
+    </section>
+  </section>
+
+  <section>
+    <title>Firewall Configuration</title>
+    <marker id="firewall"></marker>
+    <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. <c>inbound protection</c> and <c>outbound protection</c>). A firewall
+      can limit access based on:</p>
+    <list type="bulleted">
+      <item><em>Transport Level</em> - performs access control decisions based on
+       address information in TCP headers.</item>
+      <item><em>Application Level</em> - understands GIOP messages and the specific
+       transport level inter-ORB Protocol supported e.g. IIOP.</item>
+    </list>
+    <p>This section describes how to configure a <c>Transport Level</c> firewall. It
+      must have prior knowledge of the source to destination mappings, and
+      conceptually has a configuration table containing tuples of the form: 
+      <c>({inhost:inport}, {outhost:outport})</c>. If there are no port restrictions
+      it is rather easy to configure the firewall. Otherwise, we must consider the
+      following alternatives:</p>
+    <list type="bulleted">
+      <item><em>Incoming Requests</em> - Orber only uses the port-numbers specified 
+       by the configuration parameters <em>iiop_port</em> and 
+      <em>iiop_ssl_port</em>. Other ORB's may use several ports but it should
+       be possible to change this behavior. Consult the other ORBs 
+       documentation.</item>
+      <item><em>Outgoing Requests</em> - 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 <em>iiop_out_ports</em>).</item>
+    </list>
+    <warning>
+      <p>Using the option <c>iiop_out_ports</c> 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 
+        <c>iiop_connection_timeout</c>.</p>
+    </warning>
+    <p>Firewall configuration example:</p>
+    <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>
+    <p>If the communication take place via a
+      <seealso marker="ch_install#firewall_nat">TCP Firewall with NAT</seealso>
+      (Network Address Translation), we must activate this behavior and define
+      the external address and/or ports.</p>
+    <marker id="firewall_nat"></marker>
+    <image file="firewall_nat.gif">
+      <icaption>
+TCP Firewall With NAT</icaption>
+    </image>
+    <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 
+      <seealso marker="ch_install#flags">Enable NAT</seealso> flag must be set and
+      <c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and <c>nat_ip_address</c>
+      configured, which maps to <c>iiop_port</c>, <c>iiop_ssl_port</c> and 
+      <c>ip_address</c> 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 <c>ip_address</c> is set to 
+      <c>{multiple, [IPAddress]}</c>, <c>nat_ip_address</c> 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
+      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>, 
+      the options <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
+      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c> shall be used. The default NAT IP address
+      and port, should be translated to the value of <c>ip_address_local</c> 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 <em>Application Level</em> 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
+      <seealso marker="ch_install#config">iiop_acl</seealso>. The Classless Inter
+      Domain Routing (CIDR) <c>Filter</c> determines which peer interfaces and 
+      ports the other ORB may use.</p>
+    <table>
+      <row>
+        <cell align="left" valign="middle"><em>Filter</em></cell>
+        <cell align="left" valign="middle"><em>Peer Interface(s)</em></cell>
+        <cell align="left" valign="middle"><em>Peer Port(s)</em></cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">"10.1.1.1"</cell>
+        <cell align="left" valign="middle">10.1.1.1</cell>
+        <cell align="left" valign="middle">any</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">"10.1.1.1/8"</cell>
+        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
+        <cell align="left" valign="middle">any</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">"10.1.1.1/8#4001"</cell>
+        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
+        <cell align="left" valign="middle">4001</cell>
+      </row>
+      <row>
+        <cell align="left" valign="middle">"10.1.1.1/8#4001/5001"</cell>
+        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
+        <cell align="left" valign="middle">4001-5001</cell>
+      </row>
+      <tcaption>Orber ACL Filters</tcaption>
+    </table>
+    <p>Orber ACL, also allows the user to define which local interface(s) may be used,
+      but will not detect <c>spoofing</c>. The operation
+      <seealso marker="orber_acl">orber_acl:match/2/3</seealso> makes it easy to
+      verify whether access would be granted or not. For example, if Orber would
+      be started with the ACL <c>[{tcp_out, "10.1.1.1/8#4001/5001"}]</c>, then 
+      <c>orber_acl:match/2</c> would behave as follows:</p>
+    <code type="none">
+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}}
+    </code>
+    <p>Only if the returned boolean is true the extra return values makes a 
+      difference. In the example above, <c>{true,[],{4001,5001}}</c> means that
+      Orber may connect to <c>"10.1.1.1"</c>, 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 <c>orber_acl:match/2/3</c>
+      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>
+  </section>
+
+  <section>
+    <title>Interface Configuration</title>
+    <marker id="interfaces"></marker>
+    <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 <c>iiop_ssl_ip_address_local</c>
+      and/or <c>ip_address_local</c>, which will affect IIOP via SSL and IIOP 
+      respectively. These parameters can be overridden by using the Orber generic 
+      <c>interface</c> Context or defining an ACL (Access Control List). The latter
+      always takes precedence if a local interface is included (e.g. 
+      <c>[{tcp_out, "10.0.0.0/8", ["10.0.0.1"]}]</c>). If the interface is excluded
+      (e.g. <c>[{tcp_out, "10.0.0.0/8"}]</c>), the interface chosen will, in the following
+      order, be determined by
+      <c>#'IOP_ServiceContext'{}</c>, <c>ip_address_local/iiop_ssl_ip_address_local</c> or
+      the configuration of the underlying system.</p>
+    <p>Adding the interface context, for generated stubs/skeletons, is done in the 
+      following way:</p>
+    <code type="none">
+Ctx = #'IOP_ServiceContext'{context_id = ?ORBER_GENERIC_CTX_ID, 
+                            context_data = {interface, "10.0.0.1"}},
+'CosNaming_NamingContext':resolve(NS, [{context, [Ctx]}], Name),
+    </code>
+    <p>It is also possible to add the context to 
+      <c>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</c> and <c>corba_object:is_a/3</c>. 
+      The operations exported by <c>corba_object</c> are affected
+      if the supplied IOR is external. The function <c>corba:string_to_object/2</c>
+      might require the interface context if a <c>corbaloc</c> or a <c>corbaloc</c>
+      string is passed (See the
+      <seealso marker="ch_naming_service#interop_ns">INS</seealso> chapter),
+      while <c>corba:resolve_initial_references_remote/3</c> and
+      <c>corba:list_initial_services_remote/2</c> always connect to another ORB and
+      it might be necessary to add the context.
+      The remaining <c>corba</c> operations are affected if calls are re-directed
+      by setting the <c>orbInitRef</c> and/or <c>orbDefaultInitRef</c> 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 <c>nat_ip_address</c>, setting the flag 
+      <seealso marker="ch_install#flags">16#1000</seealso>
+      and <c>ip_address</c>, in that order. Orber listens for incoming connections
+      either via all interfaces or the interface defined by <c>ip_address</c>. It is
+      also possible to add and remove extra listen interfaces by using
+      <c>orber:add_listen_interface/2/3</c> and <c>orber:remove_listen_interface/1</c>.
+      In this case one should set the 16#1000 flag and, if necessary, set the
+      configuration parameters
+      <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
+      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>.</p>
+  </section>
+</chapter>
+