LANDesk cores are getting more stable all the time, and I'm just not seeing the need to check that everything's working every 10 minutes any more. I've taken the service checking routines from ldms_status and put them into ldms_core 3.1.2 so that it can check and restart services once, when it runs, instead of all the time. I'll leave ldms_status online of course, but I don't see a lot of future for it at this time and will mark it obsolete real soon now.

Here's some roadmap for ldms_core, with discussion of the items:

• It's been 7 days or more since you downloaded content -- I still need to find the best way to filter this. The publishdate column in vulnerabilities is one option, but could false positive. select count(*) from vulnerability where publishdate > getdate()-7; if that value is 0, complain.Maybe even run vaminer.exe instead of just complaining?
• List uninstallable patches? This will probably not be possible, at least without introducing a lot of bugs. XML blobs need to be extracted from the database and parsed, which seems like a lot of work for a little gain.
• More progress indications, for instance after clicking Authorization button in setup. Not exciting.
• Group patches by vendor? Probably not something I can do in this context.
• Topology map. Gateways become nodes, devices sharing gateways are grouped in clouds around them, subnet masks decide size of circle. Core's gateway is in the center and traceroute hops to the other gateways are used to define the map. Use Perl::Graph to generate HTML? This is the one I want to work on next. select defgtwyaddr,count(address) from tcp where nullif(address,'') is not null group by defgtwyaddr
• Kick out a Google Earth file to plot non-RFC1918 addresses on a map. The topology map and this map would both be dumped into the LANDesk reports file share, I suppose.
• Check scheduled tasks and policies for status, alert if lots of jobs have bad status
• Switch to MIME email so I can send multipart messages with attachments, such as those maps. That would also allow reworking of some of the log messages into a table format, using HTML. I prefer the retro look of Text::Table, but it probably can't be displayed properly by the average LANDesk admin's email program.
• The new alerting system might be a better way to look for sync scan issues than using event viewer. If it ain't broke, don't fix it, but it's possible that database lookup would be faster.
• Keep old information and show trend lines on a purty chart, http://search.cpan.org/src/CHARTGRP/Chart-2.4.1/README. This is going to involve storing data and managing time and I'm just not in a big hurry to reinvent that wheel.
• Find a way to detect stuck LPM Event Listeners. Not even sure if this is a database or filesystem issue, but it needs to be found and fixed.
• Convert into a long-running service? Probably not going to happen, I just can't come up with enough justifications to explain why I'd want to go through the hassle.
• Cull Automatically Gathered software definitions with no installations. This is going to be hard, and may not be compatible with the changes planned for LDMS 9.0, but it also would be a lot of bang for console performance. Tempting.

I'm considering a re-write of ldms_status to get off of the ActiveState perltray framework and just use native Win32::GUI to display in the system tray instead. I'm having Timer problems (that's why Stop all services only works half the time), the tooltip function is buggy, and every now and then the fool thing will just stop with no error. That's tough to troubleshoot (though it's probably the tooltip function, since ActiveState recommends that you locally suppress errors in that function to make it work at all).

Doing this would have the benefit of abstracting the functions that check, stop, and start services into a module so that they'd be easier to use from other programs... someday, I hope to have ldms_core and ldms_status sharing more functions... status acting as a long-running service, core launching from time to time to do cleanup and stats gathering.

The first step in that direction is probably to put all of the status logic into a shared module, then to strip ldms_status down to a more open "Monkeynoodle services" tray icon that calls the ldms_status module to do things, but also displays balloon tips for ldms_status and ldms_core.

version 1.9.6, download from: http://www.droppedpackets.org/scripts/ldms_status

Most message boxes have been replaced with bubble tips, making it more responsive when it has a lot to do (e.g. restarting all your services after an upgrade).