Provide a supportable Ubuntu configuration of TSM

[wdc]

Alexp has done the work of figuring out how to get TSM 5.4 working under Intrepid (including the dsmj GUI by utilizing the sun-java-6 JRE.)

Temporary documentation on getting this to work is pointed to by Hermes at:
 https://web.mit.edu/sgi-desktop1/tsmdoc/article.html

There are several opportunities for improvement here:

1. Put the documentation in a more "real" place.
2. Refine the package to be a bona fide .deb instead of an alien.

IBM is coming out with a new version of TSM and this represents an opportunity to lobby for some important improvements:

1, Get rid of use of ksh since bash is canon nowadays, and the ksh EULA is really nasty.

2. Get TSM fully functional on the platform's NATIVE java runtime environment (preferably OpenJava?-6), rather than requiring TSM users to to go to www.sun.com, download a jre, click on a messy EULA, and then fiddle with the PATH.
3. Embrace Ubuntu as a supported platform.
4. Provide a simple installer akin to what is on offer for Windows or Mac.
5. Eliminate the need to hand-create the dsm.sys and dsm.opt files. (The installer should offer a gui setup for those.)
6. Create sensible interfaces to upstart that are appropriately installed by the installer.
7. Provide a "dry run" option that would help people see what files would or would not be backed up with a particular command or scheduled run.
8. Oh yes, I almost forgot, The TSM command line program should

use that ioctl to learn with the erase character is rather than hard coding the delete
key. The erase character should be the upstream default, not requiring hand-tooling to specially fix for TSM.

[jdreed]

Outreach to davek/pwhitney regarding starting a dialogue with IBM.

[jdreed]

Aaron Ucko points out  http://blog.bofh.it/debian/id_318. A Debian maintainer, Marco d'Itri ( http://people.debian.org/~md/) has created Debian packages for TSM.

Can we use his packaging to create a debathena-tsm package?

[broder]

I haven't actually looked at the packaging yet, but if I'm reading his blog post right, the resulting binary .debs will include the non-redistributable binaries from TSM. We can't put non-redistributable stuff in the apt repository, at least not the way things are setup currently, because you have to work to make apt repositories require any authentication.

[jdreed]

We're apparently also doomed because Karmic and hgher have dropped libstdc++5. So we need to tell IBM to rebuild their software for the 21st century.

In particular, while 32-bit users can steal libstdc++5 from Jaunty, 64-bit users are doomed.

[alexp]

The temporary docs have moved (though I've temporarily left a copy at the URL above, it could go away at any time). New URL:  https://web.mit.edu/acs/www/article.html

We should work through Dave Kalenderian (davek), unless someone else has high-level contacts with the IBM TSM people.

[jdreed]

We're making progress with IBM. It's going to be slow, though.

[geofft]

I'm looking at the current package on the software download grid at  http://ist.mit.edu/services/backup/tsm and I'm kind of not really happy with the packaging. A couple of things:

• Even if it's binaries, it's easy to make a Debian package that just installs a bunch of binary files. If the software is being distributed as a tarball that unpacks over the root directory, instead of being a fancier installer / requiring a postinstallation script or anything, we should just stuff it in a Debian package.
• Most of the files are in /opt, but some are in /usr/local/ibm, and some are just in /usr or /lib or /bin. For the sake of not risking TSM overwriting shared libraries, etc. from the system (which is the classic way that you end up in DLL hell), can we move as much as possible to /opt or /usr/local/ibm or something? If you create a file in /etc/ld.so.conf.d, you can point the dynamic linker at /usr/local/ibm/lib and not have to use the global /lib. (This is less of a problem if the software ends up packaged, since the package manager will warn you if the TSM package is about to overwrite a file owned by another package, but tar will not.)

[alexp]

As I did the packaging, my thoughts on this:

If someone wants to put it in a deb that's fine with me. At the moment I don't know how to build them.

I almost without exception kept things where IBM puts them from an rpm install. In unpacking the archive again and reviewing locations, it looks like /bin just has 2 symlinks to IBM binaries in /usr/local/ibm, there's nothing in /lib, /usr/bin has a bunch of links to dsm* binaries, /usr/lib has a bunch of links to IBM libraries, /usr/lib64 has one link to an IBM library and then there's just /usr/local/ibm, so I think what's of most concern about overwriting is the stuff in /usr/lib, though it looks pretty IBM-specific.

[jdreed]

The future of TSM at MIT is uncertain.

[jdreed]

Crashplan's Linux install is far less terrible than TSM's was.