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.

In calculating the amount of time that an eventually patched patch remains unpatched (say that three times fast), I was not CASTING to a BIGINT, but rather leaving it at the default SQL INT. Ergo, if you patch patches after 90 days or so, you'd get a non-fatal SQL error from ldms_core. You'll want to upgrade, from here: http://www.droppedpackets.org/scripts/ldms_core

For everyone else, nothing to see here, move along. I did some code clean up but haven't really started on the big stuff for the 3.0 release.

Fixed some stupid bugs, nothing spectacular. http://www.droppedpackets.org/scripts/ldms_core/ldms_core/view for download.

ldms_core does have an exciting roadmap, though... now that I've got statistics flowing into the event viewer and event viewer reading code written, the next step is  to use a graphics module to generate trend lines. That'll be the 3.0 release.

After that, I'm thinking to leverage all sorts of nifty modules from CPAN. Geolocation looks like fun, for instance -- how about a Google Earth file that shows the last reported locations of any node that doesn't have an RFC1918 IP Address?

The memory impact of  renaming errorscan files is still impressive on heavily used cores, and I haven't come up with anything elegant for avoiding that, so I'm also thinking of ways to reduce the frequency that it's done at. For instance, I might select to run NMAP or ErrorScan renaming based on time of day, but not both at the same time...Using a big chunk of memory to build a fast lookup table is not something I'm really concerned about...until NMAP scanning keeps my program in memory for a couple of hours. User input on this decision is very welcome, as always.