Thursday, June 22, 2006
The Linux Big But!
“I love Linux, I support Linux, I would love to use Linux but….” You wont hear this just from me. The problem is a frustrating one. I for one have a number of Linux TSM servers and they have become somewhat of a problem. For example we had a situation where we decided to deploy a Linux TSM server and proceeded to setup the site. Problems arose when we attempted to connect the Library. As it turned out the version of SUSE was down level and the driver would not work. So we upgraded Linux and the library worked fine, but (there it is again) the RAID controller for the server would not longer work and there was no updated one. This has been and continues to be the problem with Linux. Sure companies beat their chests and yell, “We support Linux!” The problem is that it’s limited support and we the users who implement get left with what turns out to be a patchwork solution. I’m sure many will say, “But I have Linux working and it works fine.” Great! The problem is in the choices available to you hardware wise when architecting the solution. I can be pretty sure that I wont run into to many problems when solutioning for AIX, HP/UX, Solaris, or Windows. With Linux you have to do twice the homework and hope the hardware company keeps its drivers up to date. Just to risky for the data. Don’t get me wrong it has gotten better but there is a long way to go before I would commit to using Linux again.
Sunday, June 18, 2006
Unofficial TSM Clients for Linux - Debian
Hi all,
time-to-time I see on various forums questions about TSM client for Debian. IBM itself do not consider Debian being a supported platform, so they do not even plan to create the package. You can find several HOWTO's (mostly created using "alien" package converter) on the web, or you can install rpm and try to solve dependencies on your own.
As our environment is 95%+ Debian based, we created our own .deb package(s). We unpacked the rpm's (both API and BA), created new postinst scripts, sample configs etc. and packed it up in a single package.
Originaly we intended to use them for internal purposes only, but we think someone might find it usefull.
You can find the packages on http://www.adsm.org website - download section
Rules:
1) Package is not an official IBM release, Debian is not supported - use at your own risk
2) read the README ... really .....
3) if you have comment/suggestion/improvement - let me know
Harry
time-to-time I see on various forums questions about TSM client for Debian. IBM itself do not consider Debian being a supported platform, so they do not even plan to create the package. You can find several HOWTO's (mostly created using "alien" package converter) on the web, or you can install rpm and try to solve dependencies on your own.
As our environment is 95%+ Debian based, we created our own .deb package(s). We unpacked the rpm's (both API and BA), created new postinst scripts, sample configs etc. and packed it up in a single package.
Originaly we intended to use them for internal purposes only, but we think someone might find it usefull.
You can find the packages on http://www.adsm.org website - download section
Rules:
1) Package is not an official IBM release, Debian is not supported - use at your own risk
2) read the README ... really .....
3) if you have comment/suggestion/improvement - let me know
Harry
Wednesday, June 14, 2006
System State & Services Backup Issue
I had a problem recently with McAfee and TSM not playing nice together. Jared Annes (co-worker) figured out the problem and this is his finding. What happened was that changes to the default scanning and file protection procedures were made to McAfee to “lock down” the servers from viruses. Unfortunately the SA’s inadvertently caused TSM to fail every system state and system services backup. The culprit was one file, TFTP.EXE in the System32 folder due to McAfee locking the file from being read. What I didn’t expect was that a failure of one file would cause TSM to fail on the whole system state and system services backup. I forgot the system state and services are looked at as one object instead of multiple files. The fix was to disable McAfee, then delete TFTP.EXE from the hidden dllcache folder, also from the System32 folder, and then re-enable McAfee. Since then I have had no more troubles with the system state and services backups.
NOTE: If you don’t delete the file from the dllcache folder Windows will copy it back over to the System32 folder recreating the problem you were trying to fix.
NOTE: If you don’t delete the file from the dllcache folder Windows will copy it back over to the System32 folder recreating the problem you were trying to fix.
Subscribe to:
Posts (Atom)