An unreasonable request...

... it is, as well, it really is - especially in a large Enterprise that has grown rather organically.

What I'd really like [big grin] is the network to be segmented for my convenience - Windows servers on one segment, UNIX on another, network kit on another and so on. It'd be so much easier for setting probe ranges and making sure jobs like Host Connection by SSH don't try and connect to Windows machines. My error logs would decrease in size dramatically!

Of course it'd be a complete pain in the nether regions for the people actually managing the network and the things that go on inside it, but that's .. well, that's someone else innit ;-) ?

So today I am working on checking over ranges to see where I have Windows kit being scanned by SSH jobs and so on and so forth. It'll be an ongoing job but best to get it started (again - I've been here before) - and this time I'll document the way I do it so that someone else can do it next time. Probably.

Foiled, but in a positive way

Curses. And yet not. The Company's ESX servers are seen by uCMDB but both as Linux servers and as the VMware physical devices they are. Trouble is, that is as two separate CIs with the physical attributes related to one CI - along with the installed software and so one, but the virtual pool and it's connections are associated with the other CI. I shall have to Spend some more of the time I don't have a lot of getting into the depths of why.

Nevertheless, it's jolly good to see that they are properly discovered :)

And so it begins ...

"Are you using Content Pack 10?" asks the support agent "because I think this issue that we haven't been able to resolve for some months will be resolved by CP10."

CP10 needs CUP7, which needs an oracle upgrade that I'm simply not going to get the resources to do.

I can see this getting somewhat tiring (even if it will sometimes be fair and justified) :(

ESX servers

And so they are discovered, which is nice. For a long time they weren't.

Not a lot of details though. I don't know what's usual for discovered ESX servers, so I shall do some rooting through comms logs. I do a lot of that.

uCMDB Browser (again)

Version 1.0 works a treat - except I need to get Tomcat running as a service on the app server. Every time I log off, uCMDB browser dies... So I've taken to just closing RDC, keeping my session running. Must look into sorting it out soon - time, always it's time...

I still think the browser's a major enhancement to usability - not for me but for people like sys admins, incident managers, change admin staff - easy to use & easy to run. No messing about with Java, no learning to use the client. Brilliant.

Example - I am pushing data from uCMDB into Atrium. The Atrium admin can use the uCMDB Browser to look at CIs in uCMDB, check they've come over properly in the push or look up records (e.g. a server) to request new related CIs be included in the integration. They never need a login to uCMDB (I use the guest login for everyone) and they don't need to know how to use the client.

Another example of browser usage - OpSec can browse the data and notice that an account which should have been closed some times ago is still on some machines. They get that closed down and that's one security issue resolved thanks to uCMDB browser. Brilliant :)

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.