Simon Butcher

Those who know my Linux admin style know that I'm a little old-fashioned. I will happily use Gentoo or Debian here and there, but for a rock-solid server that needs to keep on ticking I will use Slackware. I'll only use the base sets though, in order to get the operating system installed to a minimum level with a compiler, and then hand-tweak the kernel (entirely monolithic with no module support) and each particular piece of software necessary for the machine, with carefully built chroot gaols designed for each service.

Here are instructions on how to install ARCserve, verified on a simple Slackware 12.1 base (along with several other versions once it was deployed), and also confirmed to work on a Gentoo 2009.1 base. We're running ARCserve 12.5 on the backup server, but the latest Linux agent is still version 11.5. Unlike the windows counterparts, it's still compatible with the 12.5 server, fortunately.

If the following steps don't work for you, it should at the very least get you very close, but don't expect any support from Computer Associates on this one. If you're not running Red Hat or a derivative, it's likely you actually know something about Linux anyway.

These steps are for the Linux agent with the version 11.5, and Computer Associates had nothing to do with this (since they said it was impossible and then became very rude), so everything here has been put together from lots of strace monitoring, analysing the installation scripts, along with trial and error.

These instructions are rough (by my standards) and simplistic, so I'm sorry about that in advance. I probably can't help you if you get stuck.

Step 1: Ignore the install scripts, and install rpm2tgz

Ignore the installation scripts that come with the installation package for Linux. They will either make a mess of things or just won't work at all. You don't need them anyway.

What you do need is rpm2tgz, which is available for most distributions now since so many companies only package files in RPM format. It's a necessary evil in this case. You'll need to convert these files to TGZ (.tar.gz):

• cmagent/babcmagt.rpm — This is the “common agent” (caagent).
• babagent/babagtux.rpm — This contains the “universal agent” (uagent) and the “browser” (cabr), etc.
• license/ca-lic-01.0062-0014.i386.rpm (32-bit) or
  license/ca-lic-01.0062-014.ia64.rpm (64-bit Itanium) — This contains the license server, but choose the one appropriate to your system's architecture.

Step 2: Prepare the folder structure

Ordinarily the installer will do this, but you'll need to do a bit of preparation within the folder hierarchy. Un-tar the three converted RPM files in the system root, for example:

pushd . && cd / && tar zxvf ‹filename›.tgz && popd

You will now have the following folder structure (you may want to play with the permissions if you're security conscious):

• /opt — This may already exist on your distribution as a part of the FHS standard.
• /opt/CA — The base directory for the Computer Associates software.
• /opt/CA/BABcmagt — The “certificate” (licensing) manager.
• /opt/CA/BABuagent — The “universal agent”.
• /opt/CA/SharedComponents — Shared components for the installation, mostly licensing related.

There is a lot hard-coded in the software, especially paths. Notably, you'll need to create a soft-link outside of the /opt hierarchy for the universal agent (yes, this is a breach of FHS) so it can be called as /usr/bin/uagent:

ln -s /opt/CA/BABuagent/uagent /usr/bin/uagent

Step 3: Open ports in your firewall

You have a firewall, right? Well, if you're worth spit as a system administrator, I'm going to assume you said “yes” there and you stopped reading this paragraph.

You'll need to open these ports to any machine operating as a backup server, or any machine that is running the console software. Since the agents all need to run as root and you cannot effectively gaol them (obviously), this is potentially a gigantic security hole so be very careful here (I really don't trust this software). This depends on your distribution, so I'll just detail the ports here:

• TCP port 6051 for the agent.
• UDP port 6051 for the agent.
• UDP port 41524 for discovery, and it seems also for license verification.

You can put connection count over time style limiting on the discovery port if you're paranoid, but be reasonable and let your backup operators know so they understand why it may disappear.

Because of the security implications, I would recommend operating a secondary network for management and maintenance (such as these back-up jobs), but watch your firewall configuration because the agents will bind to all adapters (0.0.0.0).

Step 4: Configuration

You're going to need two basic configuration files for the universal agent. Create /opt/CA/BABuagent/uag.cfg in your favourite text editor, and fill it with these exciting parameters:

-s 65536
-b 16384
-c 50

Where these values seem to be:

• -s — Socket buffer size.
• -b — File system buffer size.
• -c — Timeout delay?

You can also add commands to this file for pre-backup and post-backup shell scripts to execute, if for example you wanted to fire off a mysqldump or similar, but I don't have a working example.

You'll need to also create /opt/CA/BABcmagt/agent.cfg with your text editor and populate it with the following:

[0]
#[LinuxAgent]
NAME      LinuxAgent
VERSION   11.5.0
HOME      /opt/CA/BABuagent
#ENV      CA_ENV_DEBUG_LEVEL=4
ENV       UAGENT_HOME=/opt/CA/BABuagent
ENV       LD_LIBRARY_PATH=/opt/CA/BABcmagt:$LD_LIBRARY_PATH:$CALIB:/opt/CA/BABuagent/lib
ENV       SHLIB_PATH=/opt/CA/BABcmagt:$SHLIB_PATH:$CALIB:/opt/CA/BABuagent/lib
ENV       LIBPATH=/opt/CA/BABcmagt:$LIBPATH:$CALIB:/opt/CA/BABuagent/lib
BROWSER   cabr
AGENT     uagentd
MERGE     umrgd
VERIFY    umrgd

[36]
#[BABcmagt]
NAME      BABcmagt
HOME      /opt/CA/BABcmagt
TCP_PORT  6051
UDP_PORT  6051
UDP_BCAST_PORT  41524

Obviously you can play with that CA_ENV_DEBUG_LEVEL variable if you want more detailed logging during testing, but it's quite verbose. If you have problem (i.e. you took the configuration from elsewhere), make sure you don't a line like the following:

ENV LD_ASSUME_KERNEL=2.4.18

Step 5: Create a start-up script

The ARCserve agent uses a lot of environment declarations, again hard-coded into the binaries. To make your life easier, you can make a little wrapper script to ensure all of the appropriate environment variables are ready and waiting prior to the binary starting up. It seems all of the environment variables defined in the configuration above are only handed down to child processes, so you need to do the hard part. Do not use the /opt/CA/BABcmagt/caagent script, as tempting as it may be.

The following script should get you started:

#! /bin/sh

echo "Starting ARCserve caagentd..."

# Configure environment variables prior to running the agent
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/CA/BABcmagt:/opt/CA/BABuagent/lib
export CAAGENT_HOME=/opt/CA/BABcmagt
export UAGENT_HOME=/opt/CA/BABuagent
export NLS_UTILITY_FILE=/opt/CA/BABcmagt/nls_utility

# Run the backup agent binary
/opt/CA/BABcmagt/caagentd

Start the agent using your new script.

You'll want to run this script as the system starts into a multiuser run-level. This will depend on your distribution, but it's an obvious point that is sometimes forgotten for systems that have uptimes measured in years.

Step 6: Prepare a shell profile for the agent's children

The child processes from the agent apparently want even more environment variables to be set, so with your text editor create /etc/profile.CA with the following:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/CA/BABcmagt:/opt/CA/BABuagent/lib
export CAAGENT_HOME=/opt/CA/BABcmagt
export UAGENT_HOME=/opt/CA/BABuagent
export NLS_UTILITY_FILE=/opt/CA/BABcmagt/nls_utility
export CASHCOMP=/opt/CA/SharedComponents

Step 7: Configure licensing

With everything prepared, you'll need to configure your license key for the agent. You can use the following command (where AAAAA-BBBBB-CCCCC-DDDDD-EEEEE is your license key):

/opt/CA/SharedComponents/ca_lic/CALicense AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

You should be told that the key is valid. If you run the command again, it will tell you the key is already in use, which is a good sign that things are nearly ready!

Step 8: Basic testing

Check that the agent is listening using netstat -lnp |grep caagentd. You should see something similar to the following:

tcp        0      0 0.0.0.0:6051            0.0.0.0:*               LISTEN      814/caagentd
udp        0      0 0.0.0.0:6051            0.0.0.0:*                           814/caagentd
udp        0      0 0.0.0.0:41524           0.0.0.0:*                           814/caagentd

If not, rerun the script created in step 5.

You should also be able to navigate the file-system from the backup console. Depending on your network infrastructure, discovery may not work automatically (very likely it won't) and you may need to enter an IP address or hostname. If you can't, but the agent is listening, check your firewall and so forth. If you're prompted for a password, use the root username and password (unfortunately).

At this point you may want to configure a little backup job and give it a go. ARCserve is clever enough to ignore /proc but not particularly smart when it comes to /sys or either of these when mounted inside a chroot gaol. Backing these up will only cause failures. I would recommend configuring jobs based on mount points, so run mount and base it on that list, ignoring anything provided by the kernel (devfs, sysfs, procfs, etc). ARCserve also doesn't handle hard-links efficiently, so look out for this if you use them (i.e. between gaols).

While performing your test backup, you can monitor these log files:

• /opt/CA/BABcmagt/logs/caagentd.log — Shows general information about the agent, such as child processes being spawned.
• /opt/CA/BABuagent/logs/cabr.log — Shows browser requests from the backup console.
• /opt/CA/BABuagent/logs/uag.log — Shows backup requests.

If you're lazy (like me) and want to see everything, monitor them all at once using this command:

tail -f /opt/CA/{BABcmagt/logs/caagentd.log,BABuagent/logs/{cabr.log,uag.log}}

Hopefully by now you have functioning backups!

Step 9: Perform a recovery test

If you're a real backup guy, you're going to want to perform a recovery test. This will work as per the ARCserve documentation, but it'll probably fail. This is no fault of the way the agent is configured, but because ARCserve is just that unreliable. For your more important bits and pieces, I would recommend a cron job to tar up your most valuable files before the backup server picks it up, and if you need to do a restore you can deal with the tar file instead.

Step 10: Perform regular tests

Make sure you test the backup on a regular basis. If you reboot, test it. If you change the kernel, test it. If you change libraries, test it. If you add software, update the backup job, and test it. It's easy to forget about your backups.

Good luck!