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.