UCMDB browser

Deployed this into test a couple of weeks ago. One or three minor issues with the package but it works ok.

Deployed v0.9 into Live this morning. Apart from finding that my 64-bit server doesn't have 64-bit java installed, it went pretty well. The only minor issue is that Tomcat isn't running as a service so if I log off the Tomcat instance for uCMDB browser stops :-/

Nevermind, it is still an excellent lightweight method for making data available. Here's a sample of what it shows:

I hear it's just gone to v1.0 so I shall have a look to see what the changes made are.

Scattergun

Association of probes to network areas (and so to number of related nodes) has varied rather over the year that this instance has been up - and it's based on the v8.04 (FX: spit) instance that was up before that (and that was rather spectacularly failing to do the job it was installed for). The ranges are a bit badly specified too.

That means I need to spend some time going over the IP ranges associated with the probes and see if I can rationalise the way they are entered to reduce the number of exceptions, as well as balancing the number of actual to-be-discovered nodes per probe.

A bit of underlying coherence around this should improve quality and performance.

Solaris zones

Crikey, getting Solaris zone discovery to work is awkward. I have spent two hours working with an excellent Solaris sys admin (also a Mike) and have encountered an interesting problem. It looks like it may be a script error in the content pack.

The account has permission to use sudo on the appropriate commands on the container. The proper paths and binaries are specified in the credentials set. When the account uses zlogin to access a zone, it appears not to be prefixing all appropriate commands with 'sudo'. This means that they fail on the container (dladm and netstat) when the script runs, while they can be run properly if one logs in as the discovery user. Oddly, if I substitute the specified binaries in the credential set with the wild card * then the failing commands now work but - of course - others not specified in the sudoers file then fail. What is it that the wild card does for e.g. netstat that specifying its correct path, that of sudo and adding it to the sudoers file does not?

Hmm. I may have to mention this today if I get time to dial into the practitioner's call and I might also have to log a support call with HP.

In the meantime I have learned an awful lot (for me) about the way sudoers is set up on Solaris 10, with especial reference to enabling zlogin activities. Excellent :)

Model and serial on Red Hat

Puzzled.

Why would dmidecode work fine on some servers and on others time out, when the machines have identically set up accounts and have sudo permissions set the same?

By the way..

I have spent the last 2 years managing an instance of uCMDB in a company with a pretty large server estate (servers numbered in the thousands). Much of my activity over the last two years has been around extending coverage and functionality. I've spent a lot of time figuring out why this or that server isn't seen - or is seen but DDMA doesn't get the detail it should. The server estate I'm dealing with has just about everything except mainframes and VMS.

I have spent the last 10 years doing Config Mgt of one sort or another. am a convert to discovery. Not that long ago I remembering saying to someone with a 150 server estate that they shouldn't bother with discovery. At that time I'd never seen an example that could give useful data in a way that was easily human usable. I wouldn't say the same thing these days. Even a small estate like that needs good quality discovery to make sure it's properly managed and properly licensed.

And as for "why have Configuration Management" - well, how can you change or fix anything if you don't know how it was or how it should be? Config Mgt is the one truth - if it's based on intelligent processes, good discovery and a generous dose of willingness to go to all the other info sources that can be found, utilised, incorporated, federated.

My colours are firmly nailed to the HP uCMDB & DDMA mast now. It drives me mad sometimes but I find it (now v9.x exists) very, very usable.

Ownership

A chap that used to work in the company wrote a pair of patterns (one for WMI, one for SSH) to retrieve server 'owners' from  the servers. These patterns faithfully run once a week and update the Organisation to Node relationship.

It's very handy and wildly under-used information and I have spent a fair amount of time publicising it inside the company. I think some people even find it useful :)

A new Owner appeared the other week. Same name as one of the 'old' Owner teams but with a # on the end. Took a bit of figuring out but then I noticed that they were all UNIX servers and had a chat with a very helpful sys admin. Turns out you can't comment out the old Owner and replace it with a new value... D'oh!

He ran an editing script, I re-ran the SSH pattern; job done, data neatly tidied up.

D'oh! Rerunning Host Connection and Host Resources & Applications sorts many of the duplicates :)

SAN discoverability

And so the SAN connectivity is done and (mostly) working.

I shall declare it a resounding success in a few weeks when the job has run more than just the once and when the server has had the opportunity to really chew through all the reconciliation rules. At the moment I am finding servers not found before (which is nice) but also finding duplicates of previously discovered servers.

I shall have to look carefully into how I resolve these things so I have One Reliable Truth in the instance.

So it's not often quite as easy as it seems when you're trying to get something working, is it?

This morning my probe has filled it's virtual HDD and no SAN related CIs have been created. Oooh that's annoying - but also interesting as now I get to figure out why..

Pardon me while I plunge into things :)

Yes, I know there actually is a progress bar, but I also know it isn't the winner of the Mr Accurate 2011 Award for Spot-On Accuracy.

Java keystores, the SAN database and all that

'In Progress' - brilliant! Beats the heck out of 'Failed'.

Connecting discovery to the company's SAN controller's database has been a goal for quite some time. This will let the CMDB show SAN attached drives as well as the supporting architecture behind the LUNs.

It's been a long trip for me, has getting to this point. I've been to see the chap that looks after the SANs. I've puzzled over embedded Help files that don't Help. I've worried, wondered, given up (temporarily) and gone back again.

The HP documentation didn't immediately help, leaving me using the little grey cells, Prof. Google and the help of several colleagues to get a java keystore created in the right place and with the right credentials. Remembering how to refer to a file on one Windows server from another took a little doing too. Been quite a while... I also got a sneak preview of the next copy of the instructions, which are rather more comprehensive than the older ones... thanks HP!

Now I have to wait. Possibly for quite some time as this is the first time that it's connected successfully.

...

...

Still waiting. I may request HP add in a progress meter.. not that I'm impatient or anything :)

The background and all that

So I have spent the last 10 years working in Config Mgt and really the whole of that time has been one long learning exercise.

I've learned how to admin Red Box (those were the days) when no one else was there to do it
I've learned how to do extensive data analysis when everything had to be kept in spreadsheets
I've learned about setting up an instance of BMC Remedy when a trial system was needed as a PoC

But most of all I've found the HP Universal CMDB & DDMA discovery. With no one to admin that for the last >year, I've had to do it myself. In that time I've also extended the system's coverage and capabilities.

I've also learned to love uCMDB & DDMA.