One other thing I should mention is this installation is for the -console install only. I would rather not deal with a GUI on a Linux server.  That’s why we have the DS-User!

This is process is unsupported but in my experience it works brilliantly! I hope you find this step-by-step helpful!

UPDATE: It should be known this process is for a 32bit Ubuntu installation. There seem to be some issues with the 64bit install.  Hopefully I can come up with a solution.  If anyone else has one – please share!

This installation process was done on a completely fresh install of Ubuntu Server 10.04 LTS.

Software Used
DS-Client 10
PostgreSQL 8.4
Ubuntu Server 10.04 LTS

Normal house cleaning stuff
# aptitude update
# aptitude upgrade
# reboot
# aptitude dist-upgrade
# reboot

Install postgresql 8.4
# aptitude install postgresql

Now setup PostgreSQL as you normally would with any Linux DS-Client setup.

Install other required library
I’ve had issues with other versions. So, what I did was skip over this and attempt to start dsc service.  It was unsuccessful and it told me it specifically wanted this version, so I gave it to it.
Download the right one for your architecture: http://packages.debian.org/stable/base/libstdc++5
Install library:
# dpkg -i libstdc++5_3.3.6-18_i386.deb

Install java
Uncomment the following in /etc/apt/sources.list

Ø deb http://us.archive.ubuntu.com/ubuntu/ lucid-backports main restricted universe multiverse
Ø deb-src http://us.archive.ubuntu.com/ubuntu/ lucid-backports main restricted universe multiverse
Ø deb http://archive.canonical.com/ubuntu lucid partner
Ø deb-src http://archive.canonical.com/ubuntu lucid partner

# aptitude install sun-java6-jre

Installing the ds-client
Install the bin file using the -console switch. Run through first few steps and after the legal mumbo jumbo get to the following:
——————————————————————————-
Setup needs to know the location where DS-Client will be installed.
DS-Client (i386) Install Location
Please specify a directory or press Enter to accept the default directory.
Directory Name: [$D(install)/CloudBackup/DS-Client]
——————————————————————————-

Notice it is mis-reading the PATH. This is very common with software that was not build for a particular Linux flavor You must put in the proper one (this issue did not exist in pre-v.10)
/usr/local/CloudBackup/DS-Client

Keep going through the normal stuff, eventually it will ask for the PostgreSQL home directory, I don’t remember it doing this pre v9.2, so here it is with this setup, trailing slash needed:
/usr/lib/postgresql/8.4/

….continue with DS-Client setup as normal.

You’ll notice when you (re)start the dsclient service manually it shows some mumbo jumbo. That actually means its working.  If it fails it will say FAILED.

root@ubuntu10:/usr/src# /etc/init.d/dsclient start
Starting DS-Client: -en 033[60G
[  -en 033[1;32m
$OK-en 033[0;39m
]

You now have a working DS-Client on Ubuntu 10.04 LTS.  This process is the same for Ubuntu 8.04.  I’m pretty sure the same libstdc is needed as well. If not, /var/log/messages should tell you which one it wants after an unsuccessful service start.

Happy installing!

An error occurred during configuration of the HA agent on the Host
Enable firewall failed: vim.fault.HostConfigFault

Strange.  Looks like neither ESX hosts are talking to each other.  VMWare communities suggest i run:

[root@syr-nav-esx-03 root]# esxcfg-firewall -q aamclient

And it gave me:

Can’t locate XML/DOM.pm in @INC (@INC contains: /usr/lib/vmware/esx-perl/perl5/site_perl/5.8.0 /opt/ActivePerl-5.8/site/lib /opt/ActivePerl-5.8/lib .) at /usr/sbin/esxcfg-firewall line 21.
BEGIN failed–compilation aborted at /usr/sbin/esxcfg-firewall line 21.


Turns out the problem is from the changes Asigra Televaulting DS-Client wanted me to make to each ESX host in order to get host based backups working.  The DS-Client requires Perl to be upgraded to at least 5.8.1. And in order to make sure ESX continues to function after the Perl upgrade they states on page 419 of dsuser.pdf:

After the Perl upgrade, the vmware-cmd command may no longer work since it is not compatible
with the new Perl. You will, however, need this command in order to register restored virtual
machines. To fix this problem, go to the /usr/bin/ directory and edit the vmware-cmd file as well as
the vmware*.pl files in this directory; change the first line in each file to refer to the old Perl
installation (replace #!/usr/bin/perl with #!/usr/bin/perl.old). Run vmware-cmd without
parameters to verify that it works.

So i guess they forget to mention /usr/bin/esxcfg-firewall also needs it’s perl path changed to /usr/sbin/perl.old.  This makes me wonder what else migth brake from the Perl upgrade.