Ticket #232 (closed enhancement: wontfix)

Opened 15 years ago

Last modified 10 years ago

Provide a supportable Ubuntu configuration of TSM

Reported by: wdc Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: alexp Fixed in version:
Upstream bug:

Description (last modified by jdreed) (diff)

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:

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.

  1. 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.
  2. Embrace Ubuntu as a supported platform.
  3. Provide a simple installer akin to what is on offer for Windows or Mac.
  4. Eliminate the need to hand-create the dsm.sys and dsm.opt files. (The installer should offer a gui setup for those.)
  5. Create sensible interfaces to upstart that are appropriately installed by the installer.
  6. 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.
  7. 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.

Change History

comment:1 Changed 15 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed

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

comment:2 Changed 15 years ago by jdreed

  • Status changed from accepted to new
  • Owner jdreed deleted

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?

comment:3 Changed 15 years ago by 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.

comment:4 Changed 14 years ago by jdreed

  • Description modified (diff)

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.

comment:5 Changed 14 years ago by alexp

  • Cc alexp added

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.

comment:6 Changed 14 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed
  • Milestone changed from Summer 2010 (Lucid Deploy) to Fall 2010

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

comment:7 Changed 14 years ago by jdreed

  • Milestone changed from Fall 2010 to Natty Alpha

comment:8 Changed 13 years ago by jdreed

  • Milestone changed from Natty Alpha to Fall 2011

comment:9 Changed 13 years ago by 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.)

comment:10 Changed 13 years ago by 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.

comment:11 Changed 11 years ago by jdreed

  • Status changed from accepted to new
  • Owner jdreed deleted
  • Milestone changed from Current Semester to The Distant Future

The future of TSM at MIT is uncertain.

comment:12 Changed 10 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

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

Note: See TracTickets for help on using tickets.