Previously, I described the pain and heartache that is the Tivoli Access Manager for e-business SMS Server installer routine when another administrator has installed the WebSphere component [see http://blog.stephen-swann.co.uk/2011/03/tameb-naughty-installer-sms-part-1.html].
The title of that blog post claimed that it was merely Part 1 of the saga. Here's part 2.
It's not unusual for customers to want to install software somewhere other than the suggested location. In a Windows environment, it seems quite normal for the base operating system to occupy the C: drive and for additional components to be deployed on the D: drive. When an installer gives you the option to change the destination for your application, it's reasonable to assume that it is safe to do so.
With the TAMeb SMS installer, however, this assumption would be incorrect. While the PDSMS package can be deployed on to the D: drive, running the smscfg utility to configure the SMS product will fail claiming that c:\Program Files\Tivoli\PDSMS cannot be found on the system!
The simple way to resolve this issue is as you would expect. Temporarily copy the contents of your PDSMS directory from wherever you deployed it to the location above and smscfg will get you further. In fact, you should now be in a state where you can successfully deploy and configure the SMS Server and associated components.
For a comprehensive set of instructions on how to do that, follow the guide at IBM Tivoli Access Manager Session Management Server Deployment Architectures.
In a world where technology is supposed to make things simpler, why is it that the world seems to be more complicated? This blog is made up of the ramblings of an IT Security Consultant specialising in IBM Security software with a heavy focus on IGI, ITIM/ISIM, ITAM/ISAM and ITDI/ISDI. All opinions expressed are my own and have nothing to do with any employer past or present. I hope you find them useful.
Tuesday, March 29, 2011
Sunday, March 27, 2011
TAMeb Naughty Installer - SMS Part 1
I've long been an admirer of IBM Tivoli security software. The components mostly do exactly what you would expect.
However, I've always been a bit confused by the means and mechanisms used to install the software. This week, I had a brilliant example of pure laziness on the part of the developer within IBM who had responsibility for coding the installer for the Tivoli Access Manager for e-business SMS component!
Consider the following facts:
Installing the SMS component should be as simple as running the installer from the TAMeb Base package and following the on-screen instructions. Unfortunately, on my system, the installer failed to recognise that WebSphere was installed and insisted on installing its own version of WebSphere.
And the reason for this failure to detect the WebSphere installation? I could plainly see that it was deployed at d:\IBM\WebSphere\AppServer. I could plainly see that WebSphere was running by checking the list of Windows Services. The installer, however, could not.
It was time for some code-hacking to determine what was going on and after a little bit of digging around the installer, I found that it was checking for a WebSphere installer by looking through the Windows registry.
Interesting, I thought. Surely there must be a reference in the registry for WebSphere? Well, that may indeed have been the case, but it certainly wasn't where the installer was looking for it!
A colleague of mine had installed WebSphere using his credentials. I was installing SMS using my credentials. The SMS installer was looking for WebSphere registry keys under LOCAL USER in the registry. And they didn't exist there because I didn't install WebSphere!
The addition of the following registry keys (under my session) allowed the installer to recognise the WebSphere instance:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\IBM]
[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment]
[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment\7.0.0.0]
"BinPath"="D:\\IBM\\WebSphere\\AppServer\\bin"
"InstallLocation"="D:\\IBM\\WebSphere\\AppServer"
"LibPath"="D:\\IBM\\WebSphere\\AppServer\\lib"
"MajorVersion"="7"
That said, I wanted to install the SMS components on to my D: drive. Do you think that would work? Do you think if I installed the software there that the smscfg routine would work? If you think positively about these questions, then it's time to think again! Check back for the next thrilling episode in the SMS Installation Series!
However, I've always been a bit confused by the means and mechanisms used to install the software. This week, I had a brilliant example of pure laziness on the part of the developer within IBM who had responsibility for coding the installer for the Tivoli Access Manager for e-business SMS component!
Consider the following facts:
- Windows 2008 Server (64-bit) platform
- WebSphere 7 already deployed
- Tivoli Access Manager for e-business Policy Server already deployed and configured
Installing the SMS component should be as simple as running the installer from the TAMeb Base package and following the on-screen instructions. Unfortunately, on my system, the installer failed to recognise that WebSphere was installed and insisted on installing its own version of WebSphere.
And the reason for this failure to detect the WebSphere installation? I could plainly see that it was deployed at d:\IBM\WebSphere\AppServer. I could plainly see that WebSphere was running by checking the list of Windows Services. The installer, however, could not.
It was time for some code-hacking to determine what was going on and after a little bit of digging around the installer, I found that it was checking for a WebSphere installer by looking through the Windows registry.
Interesting, I thought. Surely there must be a reference in the registry for WebSphere? Well, that may indeed have been the case, but it certainly wasn't where the installer was looking for it!
A colleague of mine had installed WebSphere using his credentials. I was installing SMS using my credentials. The SMS installer was looking for WebSphere registry keys under LOCAL USER in the registry. And they didn't exist there because I didn't install WebSphere!
The addition of the following registry keys (under my session) allowed the installer to recognise the WebSphere instance:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\IBM]
[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment]
[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment\7.0.0.0]
"BinPath"="D:\\IBM\\WebSphere\\AppServer\\bin"
"InstallLocation"="D:\\IBM\\WebSphere\\AppServer"
"LibPath"="D:\\IBM\\WebSphere\\AppServer\\lib"
"MajorVersion"="7"
That said, I wanted to install the SMS components on to my D: drive. Do you think that would work? Do you think if I installed the software there that the smscfg routine would work? If you think positively about these questions, then it's time to think again! Check back for the next thrilling episode in the SMS Installation Series!
Wednesday, March 23, 2011
A Proxy For Google
I was recently asked why I write down my thoughts on Identity and Access Management in a blog. In fact, I was recently asked why I give away all our secrets and didn't I know that my actions were damaging to my long-term job prospects. In effect, educating others means more competition in the job pool.
I have some answers to these questions:
1) I enjoy writing down my thoughts and it helps solidify the concepts in my own head. It also allows me to refer back to past experiences
2) I like the idea that others read my blog and are maybe inspired to take the thoughts and improve them
3) Educating others relieves me of the responsibility of being the custodian of a certain piece of information and allows me to concentrate on learning new things. After all, we should always aspire to learn new things and stretch our imaginations
Having said all that, my time is precious. When viewers of my blog request help, I will try my best to provide guidance and pointers but I may not respond immediately. I don't actually provide this as a service and therefore there is no SLA! Requests should also be thought through - I don't like being a proxy for Google, for example. (You may get a response including a Let Me Google That For You link!)
In short, I enjoy writing my blog and I enjoy helping people but I prefer to help people who have demonstrated that they have already made a good attempt at addressing their problem.
I have some answers to these questions:
1) I enjoy writing down my thoughts and it helps solidify the concepts in my own head. It also allows me to refer back to past experiences
2) I like the idea that others read my blog and are maybe inspired to take the thoughts and improve them
3) Educating others relieves me of the responsibility of being the custodian of a certain piece of information and allows me to concentrate on learning new things. After all, we should always aspire to learn new things and stretch our imaginations
Having said all that, my time is precious. When viewers of my blog request help, I will try my best to provide guidance and pointers but I may not respond immediately. I don't actually provide this as a service and therefore there is no SLA! Requests should also be thought through - I don't like being a proxy for Google, for example. (You may get a response including a Let Me Google That For You link!)
In short, I enjoy writing my blog and I enjoy helping people but I prefer to help people who have demonstrated that they have already made a good attempt at addressing their problem.
Wednesday, March 09, 2011
How To Externalise JavaScript in ITIM Workflow
Every now and again, I seem to hit on a problem which requires that my JavaScript seems to be veering towards being environment specific. As we all know, we want our ITIM workflows to be consistent between our development, test and production environments and workflow which contains environment specific code has got to be a bad thing.
But, it happens.
What if, however, we could maintain the same workflow between the environments but externalise the JavaScript to a file. The pain point of altering the workflow between environments would just go away!
Achieving this is really quite simple and has been alluded to in other forums - though rarely in a way that gives the reader all the information they require to complete the task. The following method works with ITIM v5.1.
JavaScript Node
To read an external JavaScript file, we require the following code:
Our external JavaScript file can contain any JavaScript code we require for our node:
scriptframework.properties
Of course, to expose the java.io methods to our JavaScript, we need to configure this ability in our scriptframework.properties file (and restart ITIM). Adding the following property to scriptframework.properties will do the trick:
And there you go... from within our script nodes, we have access to the java.io classes. We can externalise our scripts. We can read files. We can write files. Why not let me know how you put your java.io capability to use in the script nodes.
But, it happens.
What if, however, we could maintain the same workflow between the environments but externalise the JavaScript to a file. The pain point of altering the workflow between environments would just go away!
Achieving this is really quite simple and has been alluded to in other forums - though rarely in a way that gives the reader all the information they require to complete the task. The following method works with ITIM v5.1.
JavaScript Node
To read an external JavaScript file, we require the following code:
// Open the external JavaScript file
var myScriptFile = new java.io.BufferedReader(new java.io.FileReader("/path/to/file");
var myLineOfCode = null;
var myCode = "";
// Read the file and add each line of code we find to a variable
while ((myLineOfCode = myScriptFile.readLine()) != null) {
myCode += myLineOfCode;
}
// Close the file
myScriptFile.close();
// Execute the code that we have gathered together
eval(myCode);
Our external JavaScript file can contain any JavaScript code we require for our node:
Enrole.log("external", "Hello world - I'm an external script!");
scriptframework.properties
Of course, to expose the java.io methods to our JavaScript, we need to configure this ability in our scriptframework.properties file (and restart ITIM). Adding the following property to scriptframework.properties will do the trick:
ITIM.java.access.io=java.io.*
And there you go... from within our script nodes, we have access to the java.io classes. We can externalise our scripts. We can read files. We can write files. Why not let me know how you put your java.io capability to use in the script nodes.
Subscribe to:
Posts (Atom)