Category: FAQ

There are many disaster recovery (DR) and high availability (HA) options for your Eclipse servers, but here are some of the most common solutions that we recommend. If you have any questions, please contact your Epicor account manager.

Filesystem Snapshot Replication

Data replication frequency: typically once per day
Time to recovery: typically less than 15 minutes

The backup script provided for Eclipse customers on Linux has the ability to transfer data to a secondary Linux server (physical or virtual, on-site or at a remote location) using the open-source rsync file copying tool. When the script is configured, the replication runs every time the backup script is executed (i.e. during the nightly backup). To recover, the Eclipse software will need to be started on the secondary server. There is no cost for the open-source replication software.

ABS Failover Hosting

Data replication frequency: typically once per day
Time to recovery: typically less than 4 hours

For Eclipse customers who would like to outsource the responsibility of managing their DR infrastructure without management overhead and capital expenditures, we offer a hosted DR service. Your Eclipse server’s data is backed up to our data center once per day, and we pre-configure your branches to communicate with the backup server. To recover, the ABS team will restore the latest available backup and start the Eclipse software. Please contact your account manager for pricing.

VMware vSphere Replication

Data replication frequency: typically varies from once per our to once per day
Time to recovery: typically less than 15 minutes

Eclipse customers running on VMware can replicate their virtual Eclipse servers to a secondary location using VMware vSphere Replication or similar 3rd party tools (e.g. Veeam, Zerto, etc.) How “fresh” the recovery VMs are depends on how often they are synced, which can be anything from once every few seconds to once a day, depending on the speed of the network. To recover, the recovery VMs need to be powered on, and depending on the customer’s network configuration, the IP address may need to be updated. These advanced features require additional software.

UniVerse Database Replication

Data replication frequency: typically “real time”
Time to recovery: typically a few minutes

Eclipse customers that want “real time” replication can use UniVerse’s native replication functionality. The software is configured to capture writes to the database and replicate them to a secondary server while preserving the integrity of the database. Recovery is also quick, since the Eclipse software is already up and running on the secondary server. This solution is implemented and supported directly by the database vendor, Rocket Software, so please contact your account manager for more details.

Glossary

• RPO: the “recovery point objective” is the maximum tolerable period in which data might be lost from an IT service due to a major incident.
• RTO: the “recovery time objective” is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document.

Executive Summary

Last week, a critical java security vulnerability was announced, and this high-profile security flaw has been widely covered by the media. We want to assure our customers that this vulnerability does not affect your Eclipse software.

Even though Eclipse uses Java technology extensively in both our Solar client and our JBoss application server, this vulnerability does not apply to standalone desktop java applications or servers.

While this security vulnerability does not impact your Eclipse software, we urge you to follow Oracle’s recommendations for securing any workstations that may be running the affected versions of their Java runtime environment.

FAQ

What action do I need to take to secure my workstations that run Solar?

If you have installed JRE 7, the version of Java bundled with Solar in Eclipse 8.7.4.09 or later, you should immediately update Java (Control Panel -> Java -> Update tab -> Update Now).

If you have installed JRE 6, the version of Java bundled with Solar in Eclipse 8.7.4.08 or earlier, no action is necessary.

What action do I need to take to secure my Eclipse server?

No action is necessary. Eclipse does not use JRE 7 on the application server.

What is the danger of this vulnerability?

Here is a summary of the Java security alert, taken from US-CERT Alert (TA13-010A):

A vulnerability in the way Java 7 restricts the permissions of Java applets could allow an attacker to execute arbitrary commands on a vulnerable system.

The impact of this vulnerability is also described in Oracle Security Alert for CVE-2013-0422:

These vulnerabilities are not applicable to Java running on servers, standalone Java desktop applications or embedded Java applications.

To be successfully exploited, an unsuspecting user running an affected release in a browser will need to visit a malicious web page that leverages these vulnerabilities

There are a number of ways to limit the number of simultaneous telnet connections.

This guide is for informational purposes only. The implementation and support of any such limitation is the responsibility of the customer. Eclipse does not implement or provide technical support for such configurations.

Login Script (AIX and Linux)

To limit the number of simultaneous logins for a specific user account, a script can be placed in the user’s login script (i.e. .profile). Here’s an example script:

ME=`who am i | awk '{print $1}'`
case $ME in
	eclipse )
		LOGLMT=10
		;; # Login limit
	* )
		LOGLMT=1
		;; # Login limit
esac
LOGCNT=`who | awk '{print $1}' | grep "^$ME$"| wc -l  | awk '{print $1}'`
if [ $LOGCNT -gt $LOGLMT ] ; then
	print "You are logged in $LOGCNT time(s)."
	print "You are limited to $LOGLMT login(s)."
	print "Please finish current task and try again."
	print "Logging off..."
	sleep 5
	logout
fi

Telnet Service Limiting (Linux)

By default, RHEL limits the number of telnet connections from a single host to 10 simultaneous sessions. To lower the limit:

• Open the /etc/xinetd.conf file for editing

vim /etc/xinetd.conf

• Find the line containing the “per_source” value
• Decrease the integer from 10 to an appropriately-sized value for your environment
• Save the configuration file
• Reload xinetd

service xinetd reload

Using Eterm:

• Launch Eterm
• Connect to your Eclipse server
• Log into the OS
• At the blue Eclipse login screen, take note of the Eclipse release:
  

Using the Web:

• Navigate to your Eclipse server’s Solar web start page (ex. http://192.168.1.100:2080/)
• Scroll to the bottom of the page
• At the bottom, you will see a section entitled Server Information
• The Eclipse release is listed: