From owner-freebsd-current@FreeBSD.ORG Tue Jun 29 15:41:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9530516A4CE; Tue, 29 Jun 2004 15:41:33 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE2B43D1D; Tue, 29 Jun 2004 15:41:33 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from hawkwind.Chelsea-Ct.Org (pool-151-199-92-118.roa.east.verizon.net [151.199.92.118]) by gromit.dlib.vt.edu (8.12.11/8.12.11) with ESMTP id i5TFfIFg063006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Jun 2004 11:41:31 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from [192.168.1.25] (zappa [192.168.1.25])i5TFf6FI011563; Tue, 29 Jun 2004 11:41:07 -0400 (EDT) From: Paul Mather To: freebsd-current@freebsd.org In-Reply-To: <20040629075337.81BEF16A4CF@hub.freebsd.org> References: <20040629075337.81BEF16A4CF@hub.freebsd.org> Content-Type: text/plain Message-Id: <1088523665.67002.60.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 29 Jun 2004 11:41:06 -0400 Content-Transfer-Encoding: 7bit cc: Carl Makin cc: Paul Seniura Subject: Re: Q's about IBM TSM (was Re: HEADSUP: ibcs2 and svr4 compat headed for history) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 15:41:33 -0000 "Paul Seniura" wrote: (I get freebsd-current in digest form; I'm replying to several of your messages in one reply.) > Message: 2 > Date: Mon, 28 Jun 2004 14:25:27 -0500 (CDT) > From: "Paul Seniura" > Subject: Q's about IBM TSM (was Re: HEADSUP: ibcs2 and svr4 compat > headed for history) > To: "Carl Makin" > Cc: freebsd-current@freebsd.org > Message-ID: <20040628192527.1C2755C29@techpc04.okladot.state.ok.us> > > It will cause us a lot of grief unless we can find an alternative way to > > run IBM's Tivoli Storage Manager. We currently use the SCO v2 client > > which has huge warts, but runs. > > Could you take time or point me to something that would > explain how to use the SCO client, please? The SCO V2 client *does not run* under 5.x. It does run under 4.x, still. If you are using 5.x, the SCO V2 client is not a viable option until someone fixes iBCS2 emulation, which is largely broken there. (I did get the example iBCS2 "Hello World" program to run, but nothing else.) > We'd be another bunch to add to the ibcs/svr group if it > actually works here, too. ;) Even if it did, it is not pleasant to use under a contemporary TSM server because of the huge versioning gap. (For instance, our 5.1.8.3 TSM server would always report the scheduled backup had failed, even though the V2 client logs and test restores indicated it was successful.) Many current features and options are not supported, and current IBM TSM servers do not officially support such an old client (although it does appear to work). > > The linux client trips over the whole filesystem overlay thing badly and > > I'm not sure disabling that to run just the TSM client is a good idea. > > (Plus I hate the idea of maintaining custom kernel patches.) > > I've had no luck, likewise, with the Linux TSM client. > I had never considered another compatible client until > seeing your msg just now. I'm using the Linux 5.1.5.15 TSM client on a FreeBSD 5.2.1-RELEASE-p8 system. (See previous message in this thread.) It was a bit finicky to get going. I found I had better luck using emulators/linux_base-8 than emulators/linux_base, though I did get it running under both. One hurdle for most people is that the client aborts with an out of memory error during file activities. I discovered that this is caused by having an empty or missing /compat/linux/etc/mtab file. Creating a proper mtab file solves these problems. One way to do this is via something like the following: sed 's/ufs/ext2/' < /etc/fstab > /compat/linux/etc/mtab That way, the Linux TSM "sees" your UFS partitions and will backup/restore to them. > FWIW, our support contract with IBM does cover TSM clients, > but IBM won't consider a FreeBSD-native client despite > their supporting their MacOSX client very well & officially. > IBM says they need more "user base" to even consider a BSD > flavor... go figure... When I had our TSM administrator enquire about a native FreeBSD client, they reported back they had one. However, like Daniel Lang's experience, the price we were quoted was exorbitantly high for our purposes, so we passed. > Message: 15 > Date: Mon, 28 Jun 2004 16:56:40 -0500 (CDT) > From: "Paul Seniura" > Subject: Re: Q's about IBM TSM (was Re: HEADSUP: ibcs2 and svr4 compat > headedfor history) > To: "Lukas Ertl" > Cc: Carl Makin > Message-ID: <20040628215640.C14935C29@techpc04.okladot.state.ok.us> > > I'm using the Linux client with the nullfs hack. Works rather well. > > At least the Linux client isn't as awful as the ancient SCO client. > > I google'd and didn't like what I saw. Stuff about > nullfs not being too kosher on -Current. :( I successfully used the nullfs hack for months and didn't notice any problems. I didn't do many heavy restores, although the test restores I did do worked without error. One disadvantage of the nullfs hack is that you also need something like a nightly rsync cron job to mirror over the stragglers (because you can't nullfs remount the root partition under the root partition). My current approach (using mounted snapshots, as described in a previous message in this thread) does away with that requirement, and also has the advantage of providing a read-only filesystem for TSM to back up, meaning no objects will rebound. (The snapshot approach will only work under 5.x onwards.) > My krak about "go figure" was a slam on the number of > OSX users that would need TSM while IBM supports _it_. In terms of users, there are probably a *lot* of MacOS X desktops out there. I'm guessing MacOS X support was required because of prior client support for the Mac. I'm using their TSM client on a MacOS X 10.3.4 Server system I use. > Probably will do my own backups > on this FreeBSD box the same way. End-users, tho, > will be a different matter -- they won't know what > to do without a GUI. ;) Any of this would > be possible nowadays with custom bootable CDs. Another option would be to use some kind of rsync mirroring to a machine that did have a supported TSM client and let back up the files. Alternatively, you could NFS mount your FreeBSD partitions on such a supported client machine and add the network filesystems to the backup domain. (That's assuming you were apprehensive about running the Linux client on your FreeBSD system.) There are quite a few backup options in the ports. Try "make search key=backup" in /usr/ports to list some. > I wonder what it would entail with your nullfs hack > and having to _restore_ a user's system from TSM? You just restore in-place and the files automagically appear in the correct place, sans your chosen prefix (/backup, in my case). You do have to do some manual copying restoring files in /, because those aren't nullfs-mounted. With the snapshot approach I'm using, all restores require some moving to get them into the correct place. E.g., you'd have to restore /backup/usr/... to, e.g., /usr/backup/... and then mv to /usr/... afterwards to get the files into the correct logical place. As for disaster-recovery (i.e., complete system recreation), you'd probably have to do some kind of minimal install and setup of TSM, or else have made some kind of custom TSM FreeSBIE bootable CD system from which you can run dsmc et al. I've never tried that. I've only done standard restores on a working system. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa