|
|
The MultiSite store-and-forward facility cannot operate through a firewall unless you configure MultiSite differently. Passing through a firewall is usually accomplished by granting access via specific ports and IP addresses. Because store-and-forward picks any available port number on each end to make the connection, there is no single port number (or even small range of port numbers) to which special access can be granted.
This section describes several ways to use MultiSite through a firewall:
Use an existing electronic mail mechanism as the transport.
Use the standard ftp utility to transport packets.
Use a custom TCP application.
(UNIX) Install the store-and-forward software on a host that can communicate through the firewall.
You can use an existing electronic mail mechanism as the transport. On the sending end, compress and encode the update packet; then send the resulting data to a specific mail alias at the receiving site. On the receiving end, redirect the mail alias to a script that decodes and decompresses the incoming information. To ensure that a mail message is not too large to be delivered, you can generate packets no larger than a specific size by using the -maxsize option, the shipping.conf file (UNIX), or the MultiSite Control Panel (Windows).
Transport mechanism is well understood and widely available.
Little effort is required from the system administrator.
No control over routing of data.
Possibility that messages can be lost without notification.
Messages can be intercepted easily.
Less efficient than ftp or store-and-forward.
You can write scripts to automate e-mail transport. The sending script creates the update packets, compresses and encodes them, and divides them into multiple small packets so they are not too big for the e-mail process. The script must mark the multiple packets with the correct sequencing. The script then sends the packets to an address at the target replica.
At the target replica, the account that receives the packets redirects or pipes the packets to a process that reassembles, decodes, and uncompresses the packets, and then places them in the replica's storage bay.
MultiSite import commands handle out-of-sequence and missing packet problems, so your scripts do not have to address these issues.
Using ssh and scp (secure shell and secure copy) provides a secure way to move files through firewalls.
For security, you must encrypt the packets.
The ftp utility can transport packets. On the sending end, the MultiSite administrator or a script creates and compresses the packet, and uses ftp to transfer the file to a location outside the firewall. This location, or dropsite, must be accessible by MultiSite administrators at other sites. Receiving sites poll the dropsite, looking for any new files. When new files arrive, the receiving sites retrieve them via ftp, decompress them, and process them as usual.
Transport mechanism is well understood and widely available.
More reliable and efficient than electronic mail.
Use of a dropsite is required.
Polling of the dropsite is required.
More complicated to implement, due to the interactive nature of the ftp utility.
More administration is required because a third system (the dropsite) is used.
A custom TCP application can accept data and send it from one site to a waiting application at another site. Guidelines for simple applications that send data are often described in the network programming documentation provided by the vendor. If the sending and receiving applications use a fixed port number, the administrator can configure the firewall to permit access.
Efficient and reliable.
No dropsites required.
Electronic mail-capable network is not required.
Data interception is more difficult.
Custom coding is required.
Not as flexible as electronic mail or FTP solutions.
NOTE: Because of security concerns, we recommend that you use this method only if other methods are unsuitable for your site. This method is not available for Windows firewall hosts.
An alternative to using mail, ftp, or custom software is to install the store-and-forward software on a "firewall host," a host that can communicate through the firewall. MultiSite synchronization commands can forward data intended for systems on the other side of the firewall to this host. The software on this host then forwards packets through the firewall to the next hop. To specify the range of port numbers to be used on the host, you can use the environment variables CLEARCASE_MIN_PORT and CLEARCASE_MAX_PORT. In Figure 24, the hosts that communicate through the firewall are the firewall hosts; they have the MultiSite store-and-forward software installed on them, but not ClearCase software. The replica server hosts have Rational ClearCase and MultiSite installed on them.
Figure 24 Store-and-Forward Configuration
This section describes issues you must consider before installing MultiSite on a firewall host and gives instructions for installation.
Before enabling shipping_server on a firewall host, consider the following issues:
Shipping bays can be overfilled.
Using shipping_server on a firewall host enables anyone coming in from the network to fill shipping bays on the local network, on any machine where a shipping_server is available. To avoid full disks and the related problems:
Ensure that all shipping bays in the local network are on partitions of their own, so that filling the bays does not degrade system performance.
Install shipping_server only on machines that need it: servers with replicated VOBs and machines used by administrators.
Packets are susceptible to snooping.
In normal update packets, version information is not encoded. Therefore, anyone shipping packets across an unsecured network must encrypt the packets. Also, the format of a update packet is not very complicated; a dedicated programmer could figure out the format and create a packet with operations that damage a VOB. Encrypting the data makes this kind of attack much more difficult.
Other servers can be accessible.
Allowing shipping_server access also allows access to all servers created by the albd_server. Because the albd_server assigns port numbers in the allowed range to other servers running locally, programs from the outside network can connect to all of those servers. Therefore, the firewall host that runs the shipping_server must not run other ClearCase servers.
If you can specify the ports to which programs can connect and the IP addresses that are allowed to connect, we recommend that you do so. It further limits the possibility that unauthorized machines can breach the firewall. (You specify ports during the firewall configuration process.)
On UNIX, the ClearCase Product Family installation includes an option to install only the shipping_server software. Follow the instructions in the Installation Guide for the ClearCase Product Family and select only the shipping_server-only option. Do not install ClearCase on the firewall host.
On Windows, there is no installation option for installing only the shipping_server software.
The environment variables CLEARCASE_MIN_PORT and CLEARCASE_MAX_PORT specify the range of port numbers that the albd_server and shipping_server can allocate for communication purposes. When the server needs to assign a port number, it starts with the value of CLEARCASE_MIN_PORT and continues through the range until it reaches CLEARCASE_MAX_PORT. If a port in the range cannot be allocated, the server sleeps and then tries the ports again.
When shipping_server detects that the port environment variables are set, it tries to use TCP to make the connection with the albd_server on the receiving host. If this connection fails, shipping_server tries UDP. Therefore, if you have TCP connectivity, you do not have to enable UDP or open UDP ports on the firewall host.
Running an individual shipping_server does not require more than two ports at a time. When there are multiple requests to be sent, shipping_server forks. Child processes handle individual requests. The shipping_server starts no more than 10 child processes (and starts that many only if there are 10 requests to process simultaneously), so the maximum range is 20 ports. If the range is smaller, it may result in failed attempts, which can be retried later.
The value range for CLEARCASE_MIN_PORT is 1024 through 65534, and the value range for CLEARCASE_MAX_PORT is 1025 through 65535. The value of CLEARCASE_MAX_PORT must be greater than the value of CLEARCASE_MIN_PORT.
NOTE: We recommend that you use the range 49152 through 65535, which is the Dynamic/Private Port Range. If you use a value within the Registered Ports range (1024 through 49151), the shipping.conf parser prints an informational message.
To specify minimum and maximum port values, set the CLEARCASE_MIN_PORT and CLEARCASE_MAX_PORT environment variables in the following places:
The shipping.conf file on the firewall host. For more information, see the shipping.conf reference page.
The atria_start script:
On the firewall host, edit the file ccase-home-dir/etc/atria_start.
Add the following lines, replacing min-port and max-port with your minimum and maximum port values. These lines must precede the section that starts the albd_server.
#
# Set values for minimum and maximum port numbers
#
CLEARCASE_MIN_PORT=min-port
CLEARCASE_MAX_PORT=max-port
export CLEARCASE_MIN_PORT
export CLEARCASE_MAX_PORT
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
