DB2 LUW: ILMT experience

Peter Suhner

DB2 LUW: ILMT experience
Dear listers,

IBM ask us to deploy ILMT for our Solaris environment if we want to continue making advantage of subcapacity licensing. So I've set up this tool in an engineering environment and things seem to run fairly smoothly.

Nevertheless, there's one fact that makes me (and our Unix guys) slightly unhappy: The ILMT agent (some piece of Tivoli software which is responsible for scanning the systems for installed IBM software) needs to be deployed not only to the local zones/virtual servers where DB2 is installed, but also to the global zone/host server. My primary concerns are:
- Security/Compliance as the agent is required to run under "root" authority and we have little knowledge about the agent's activities
- Operations risk as any process running as "root" on the global zone can do a lot of damage to the whole server
- Limiting the flexibility of virtualization as we basically have to
- either deploy the agent to all potential global zones to which we might want to recover a DB2 zone
- or not being allowed to recover/move a DB2 zone to any physical server as long as the agent is not deployed on it's global zone

What are your experiences with ILMT and how do you deal with the above situation? Is ILMT stable/trustworthy to be deployed across all servers? Any idea and thought is highly appreciated!

Thanks,
Peter

_______________________
Peter Suhner
[login to unmask email]

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
_____________________________________________________________________
http://www.IDUG.org/mentor
How can you expand your staff or do succession planning in this economy?
Mentoring is a proven, economical, way to train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Jim Tonchick

Re: DB2 LUW: ILMT experience
(in response to Peter Suhner)

The ILMT is not a requirement. You can also maintain your license my providing manual reports. This is what we have done in out environment. It's tediuos, but does not violate network security standards.

Security was also an issue in our environment. The ILMT server/agent architecture violated our firewall security standards with the need to for the agent on servers in the "web facing" zone to initiate a connection to the main ILMT server in our "protected" zone.

We have decided to use the ILMT only for servers inside the firewall. It covers 90% or our i570 and AIX servers.

BTW, in discussion with the ILMT support folks, it seems that this code was "outsourced" to a small group of developers undoubtedly without any idea of corporate enterprise requirements.

Jim Tonchick





-----Original Message-----
From: Peter Suhner <[login to unmask email]>
To: DB2-L <[login to unmask email]>
Sent: Fri, Jan 14, 2011 5:01 pm
Subject: [DB2-L] DB2 LUW: ILMT experience


Dear listers,
IBM ask us to deploy ILMT for our Solaris environment if we want to continue
aking advantage of subcapacity licensing. So I've set up this tool in an
ngineering environment and things seem to run fairly smoothly.
Nevertheless, there's one fact that makes me (and our Unix guys) slightly
nhappy: The ILMT agent (some piece of Tivoli software which is responsible for
canning the systems for installed IBM software) needs to be deployed not only
o the local zones/virtual servers where DB2 is installed, but also to the
lobal zone/host server. My primary concerns are:
Security/Compliance as the agent is required to run under "root" authority and
e have little knowledge about the agent's activities
Operations risk as any process running as "root" on the global zone can do a
ot of damage to the whole server
Limiting the flexibility of virtualization as we basically have to
- either deploy the agent to all potential global zones to which we might
ant to recover a DB2 zone
- or not being allowed to recover/move a DB2 zone to any physical server as
ong as the agent is not deployed on it's global zone
What are your experiences with ILMT and how do you deal with the above
ituation? Is ILMT stable/trustworthy to be deployed across all servers? Any
dea and thought is highly appreciated!
Thanks,
eter
_______________________
eter Suhner
[login to unmask email]
_____________________________________________________________________
IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA

Your only source for independent, unbiased, and trusted DB2 information. *
____________________________________________________________________
ttp://www.IDUG.org/mentor
ow can you expand your staff or do succession planning in this economy?
entoring is a proven, economical, way to train the next generation of DB2
sers!
____________________________________________________________________
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the
ome of IDUG's Listserv


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Peter Suhner

Re: DB2 LUW: ILMT experience
(in response to Jim Tonchick)

Hi Jim,

thanks for sharing your experience. Unfortunately, ILMT *is* a requirement with our environment. The contract addendum for subcapacity licensing defines exactly three exceptions to using ILMT and unfortunately we qualify for none of them.

Luckily, all of our DB2 servers are behind the firewalls, so there's no major issue with this topic. Still, we'll have to drill a few more holes between some of the backend VRF compartments.

It looks like the ILMT folks have realized the need for some improvement and they seem to be interested in learning more about customer's problems. Not that this would solve any of my current problems... ;-)

Peter



Date: Sun, 16 Jan 2011 13:00:57 -0500
From: [login to unmask email]
Subject: Re: [DB2-L] DB2 LUW: ILMT experience
To: [login to unmask email]


The ILMT is not a requirement. You can also maintain your license my providing manual reports. This is what we have done in out environment. It's tediuos, but does not violate network security standards.





Security was also an issue in our environment. The ILMT server/agent architecture violated our firewall security standards with the need to for the agent on servers in the "web facing" zone to initiate a connection to the main ILMT server in our "protected" zone.





We have decided to use the ILMT only for servers inside the firewall. It covers 90% or our i570 and AIX servers.




BTW, in discussion with the ILMT support folks, it seems that this code was "outsourced" to a small group of developers undoubtedly without any idea of corporate enterprise requirements.





Jim Tonchick











-----Original Message-----

From: Peter Suhner <[login to unmask email]>

To: DB2-L <[login to unmask email]>

Sent: Fri, Jan 14, 2011 5:01 pm

Subject: [DB2-L] DB2 LUW: ILMT experience





Dear listers,

IBM ask us to deploy ILMT for our Solaris environment if we want to continue
making advantage of subcapacity licensing. So I've set up this tool in an
engineering environment and things seem to run fairly smoothly.

Nevertheless, there's one fact that makes me (and our Unix guys) slightly
unhappy: The ILMT agent (some piece of Tivoli software which is responsible for
scanning the systems for installed IBM software) needs to be deployed not only
to the local zones/virtual servers where DB2 is installed, but also to the
global zone/host server. My primary concerns are:
- Security/Compliance as the agent is required to run under "root" authority and
we have little knowledge about the agent's activities
- Operations risk as any process running as "root" on the global zone can do a
lot of damage to the whole server
- Limiting the flexibility of virtualization as we basically have to
- either deploy the agent to all potential global zones to which we might
want to recover a DB2 zone
- or not being allowed to recover/move a DB2 zone to any physical server as
long as the agent is not deployed on it's global zone

What are your experiences with ILMT and how do you deal with the above
situation? Is ILMT stable/trustworthy to be deployed across all servers? Any
idea and thought is highly appreciated!

Thanks,
Peter

_______________________
Peter Suhner
[login to unmask email]

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA
*
* Your only source for independent, unbiased, and trusted DB2 information. *
_____________________________________________________________________
http://www.IDUG.org/mentor
How can you expand your staff or do succession planning in this economy?
Mentoring is a proven, economical, way to train the next generation of DB2
Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the
home of IDUG's Listserv








The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv