Which Linux distributions does Eclipse support?

Red Hat Enterprise Linux is the largest, most widely supported enterprise-class Linux operating system in the business. More importantly, Red Hat Enterprise Linux is the only Linux operating system supported by all of the 3rd product vendors used by the Eclipse platform, including the UniVerse database and Esker VSIFAX fax server software.

If you plan on subscribing to our Linux Technical Support service, you are required to use RHEL and have an active support subscription in place with Red Hat for your production server(s).

For non-production servers, you may use CentOS, which is a popular, free derivative or “clone” of RHEL. For Eclipse purposes, it’s functionally identical, but you won’t have access to the OS vendor for technical support.

We have always allowed our customers to run our software on alternate platforms (e.g. HPUX), but in most cases it’s not worth the additional time and energy. Eclipse does not support any hardware or software platform not listed on our Hardware Compatibility List.

Are there any CUPS settings that I can change to keep my Linux print queues from going down?

The default CUPS (Linux print spooler) settings have been shown to be reliable for Eclipse legacy printing at over 100 customer locations. In nearly all instances where print queues are consistently “going down,” a wide area network (WAN) issue has been proven to be the root cause. While working to resolve long-term networking issues, here are a few useful settings that can be adjusted to increase the amount of time allowed by CUPS before disabling a print queue

Timeout

The Timeout directive controls the amount of time CUPS will wait before an active HTTP or IPP request times out. The default timeout is 300 seconds (5 minutes), but this can be increased by modifying the /etc/cups/cupsd.conf configuration file, per the example below (1200 seconds or 20 minutes):

Timeout 1200

Maximum Job Limit

The MaxJobs directive controls the maximum number of jobs that are kept in memory. Once the number of jobs reaches the limit, the oldest completed job is automatically purged from the system to make room for the new one. If all of the known jobs are still pending or active then the new job will be rejected.

In a real-world scenario, if there is a printer down with a very large number of jobs in its queue this setting could cause printing to stop functioning server-wide. For this reason, and to ensure there are no hidden hardware or network issues, it is important to periodically monitor the number of jobs in the print queues (using the lpstat or similar tools).

If you regularly submit more than a few hundred jobs at one time to a print queue, you may wish to increase this setting in /etc/cups/cupsd.conf, taking care not to raise it too high to avoid system crash or spooler filesystem from filling up from an out of control print job.

By default, CUPS limits the number of active jobs at any one time to 500, but this can be increased to a larger value or be disabled entirely by setting the value in /etc/cups/cupsd.conf to 0 per the example below:

MaxJobs 0

Resources

http://www.cups.org/documentation.php/doc-1.3/ref-cupsd-conf.html

How often should I reboot my Linux server?

We recommend that you reboot your Linux server every month to install kernel updates from Red Hat, firmware upgrades from the server’s hardware vendor, and perform low-level system integrity checks. You may certainly reboot as often as your maintenance schedule allows, but it is not required for the stable operation of Eclipse. For more information, see: How often should I update my Red Hat Enterprise Linux server?

Server Move Checklist

From time to time, customers move their servers from one location to another, either physically, on the network, or both. We’ve put together the following lists based on our experience to help customers avoid common problems:

Physical Movement Checklist

For customers on high-end IBM servers (i.e. p570), please call IBM (800-IBM-SERV) to verify that your system can be moved without IBM intervention, because in some cases, moving the server yourself can invalidate your IBM support contract
Before making any changes, please follow best practices by making sure that you’ve completed a full backup (including a full system backup, mksysb, for AIX servers)
Make all of the changes after business hours
Label all of the cables attached to the server and their respective ports and take pictures, so that they can be plugged back into the proper locations after moving the server

Network (IP Address) Change Checklist

Before the move:

Open an SR with the Eclipse networking team ahead of time to inform them of the changes, so that they can update the Eclipse Support Access Router and support VPNs
Record the existing IP address(es), in case you need to roll back the changes or search for references elsewhere

During the move:

Change the Eclipse server’s IP address. For reference, instructions for changing the IP address on the Eclipse server:
- Linux
- AIX
Update the Eclipse server’s hostname and IP address records on your DNS server
Update any references to the Eclipse server’s old IP address on external hosts. For example:
- Workstations:
  - Eterm: Configure -> Communications -> Host
  - Solar: must be re-installed from the new IP address
- Forms:
  - In Eclipse, update the “Eclipse App Server Address” field in F2 -> F -> P -> E -> E
  - On the Forms server, update the “eclipse” entry in C:\windows\System32\drivers\etc\hosts
  - On the Forms server, update the “Hostname” entry in C:\Program Files\VSI-FAX\FaxServer\lib\vsifax.ini
- Credit Card Processor:
  - In Eclipse, update the “CC Processor Server Address” field in F2 -> F -> A -> O ->
- Job Management:
  - In the Job Management Admin page, under the Document Imaging tab, update the “Eclipse Forms XML Directory”
- Web Order Entry/Web Integration:
  - Update the “C:\Eclipse\FastCGI\Eclipse.ecl”
- External Solar/JM Application Servers:
  - Update the “hostname” entry in jboss/eclipse/configuration/solar-account.properties
- BC-XML:
  - On the Windows server, update the “hostname” entry in jboss/eclipse/configuration/solar-account.properties

After the move:

Make sure that the Eclipse server’s hostname is resolving correctly (i.e. ping it, run nslookup and make sure the new IP address is being reported)

Can ABS CrashPlan be configured to run at a specific time?

There are two methods of scheduling when CrashPlan runs:

“Always”

This is default setting. CrashPlan will always run, and will back up at the interval specified under Settings -> Backup tab -> Backup frequency and versioning.

The benefit to running CrashPlan “always” is that the backup will capture data throughout the day, therefore reducing the amount of data lost if a restore is necessary.

The downside to running CrashPlan “always” is that there is a potential for contention with the snapshot script, because both tools use different types of scheduling logic:

The snapshot script is kicked off from crontab at regular intervals based on a static timeline (ex 12:00 AM, 3:00 AM, 6:00 AM, etc.).
The CrashPlan backups are independently kicked off at regular intervals based on a dynamic timeline (ex 3 hours after the last backup to a particular destination completed).

Since the snapshots are kicked off at a regular interval via crontab, it’s possible that the snapshot could “refresh” itself (ie new snapshots are created) or “expire” (ie fill to capacity) during the CrashPlan backup process, thus invalidating the backup. The longer the CrashPlan backup(s) take, the higher the likelihood of the snapshot becoming invalid during the backup process. To prevent the snapshot script from running during an active CrashPlan backup, the snapshot script automatically stops the CrashPlan service during its operation. Upon completion of the snapshot creation process, the CrashPlan service is started, and the backup schedule is resumed.

An example configuration that has proven to work for many customers is the following:

Set CrashPlan to run every 12 hours. The 12-hour interval between backups has shown to allow sufficient time for both local and remote backups to complete in a variety of configurations.
Set the snapshot script to run at 12:00 AM and 12:00 PM. This ensures that a “point-in-time” representation of your data is available for restore at least twice daily.

“Between specified times”

There is an optional setting that can be configured under Settings -> General tab -> Crashplan will run: -> Between specified times.

The benefit to running CrashPlan “between specified times” is that it allows for the concrete definition of a window of time during which the backup should run. This is useful if there are bandwidth or performance constraints to running CrashPlan backups during business hours. The window should be made large enough to allow the completion of backups to each individual backup destination. The snapshot script should be scheduled to directly before the CrashPlan backup window, and the snapshot volume(s) must be large enough to remain active through the end of the backup window.

The downside to running CrashPlan “between specified times” is that the recovery points for data restoration are often reduced in conjunction with the available backup window. Despite this, the CashPlan agent still has many advantages over a traditional daily tape backup, including increased ease of administrator, archive reliability, security and the ability to backup to multiple destinations.

If you choose to modify the time during which CrashPlan operates, please ensure that the Eclipse snapshot backup script is scheduled via crontab to run prior to the CrashPlan backup window. For more information, see: How do filesystem snapshots work on Linux?