we have an environment with quite old sw (like AIX 6.1, MQ 6.0, DB2 9.1 and so forth) scanned by ILMT 7.5.
IBM urges us to switch over to ILMT 9.2 (which we already have running for other platforms), but looks like some of the old products (detected correctly by ILMT 7.5) cannot be detected by ILMT 9.2 because of other technique used by ILMT 9.2 (like swtag files and XML).
I know that ILMT 9.2 uses the BESClient and we attached a test AIX 6.1 client to the new ILMT 9.2 and some things get detected. But e.g. WebSphere MQ 6.0 does not and MQ 6.0 does not even support swtag files.
As a matter of fact, I donāt know much about ILMT 7.5, so I ask:
where do I find ILMT 7.5 documentation
does anyone know if I can have it both ways, AIX client scanned by ILMT 7.5 AND ILMT 9.2 at the same time, any conflict someone knows about?
The process /opt/itlm/tlmagent.bin does not LISTEN to any port.
The ports defined in configuration file /etc/tlmagent.ini are those on wich the client contacts the ILMT server.
So there seems not to be any problem having both ILMT server scan the same client.
Cheers, Igor
Hi there, @ssakunala , I have to get back to this question.
No problem for the BigFix client, but there seems to be a problem for the ILMT sw scanner:
ILMT sw scanner is installed in /opt/tivoli/cit. Although BigFix task has an option for alternate path of installation of the 9.2 sw scanner, chosing that option does not work, goes into FAIL and does not install the scanner.
Do you know for any way to have it both ways, ILMT 7.5 sw scanner installed in /opt/tivoli/cit and ILMT 9.2 sw scanner installed in alternate path (which as of the option in the BigFix task) is /etc/opt/BESClient/CITBin ?
A question - why do you want to use an out of support software compliance tool (LMT 7.x), to detect and report on out of support software?
Regarding WebSphere MQ 6.x - you will have to check via IBM documentation, but I believe this is long out of support. So thereās no compelling reason to still āscanā it for the purpose of software compliance because thereās no support anyway. Same goes for DB2 9.x (DB2 10.x just went EOL this year, so 9.x is definitely out of support).
The environment is a turnkey project set up in 2012. There has not been any plan or advice on how to update/upgrade in the years, and afaik the provider of the application provider has none. They should be developing a new version, but I have no concrete information on where they are in terms of ETA.
This application is core business to my company. We have to scan it, of course, because we use licensed software.
As of a recent license audit IBM urged us to migrate to ILMT 9.2 and this is fully understandable. But as ILMT 9.2 does not even detect most of the sw installed, we think it is best to yes, scan with ILMT 9.2, but continue to scan with ILMT 7.5 to integrate the mostly empty and useless reports ILMT 9.2 produces with an āannexā of ILMT 7.5 reports. This is where the question comes in to scan in parallel. Does this make sense?
Do you have any documentation at hand that enlists what components actually make up the ILMT scanner (like all dir involved -install, log, config dir-, config files, binaries, ports listening)?
Regards, Igor
PS: And, yes, I am new to ILMT in the sense that ILMT 7.5 has been set up by a consultant, we set ILMT 9.2 up by ourselves but did not have to dig anyway deeper into it until now when this problem arouse on how to scan both ways.
The only reason to scan, is to comply with software licencing, for S&S and renewals. This typically only applies if the software is in maintenance. If itās EOL thereās unlikely a License compliance implication unless you are paying the vendor for e.g. extended security updates to ensure that at least the software does not have vulnerabilities.
IBM may advocate the use of the latest ILMT version, which would be relevant for in-support/in-maintenance software compliance as they state in their PA agreement.
For your older technologies, I would not imagine thereās a reason to collect software license info if thereās no software maintenance, and I canāt see why there would be a license compliance risk because your arenāt paying the vendor for it any more. There could be some specific caveat in the license document, so I would ask for the vendor for clarification and on what grounds they could enforce a license compliance penalty for software thatās EOL.
Thank you very much for your comment.
The company is paying. I agree that looks like that does not even make sense. I will speak with my superiors about it.
Nevertheless, we might still have to pay something, maybe less, as we are still using it - EOL or not ā¦ donāt know the agreement details.