I just posted ldms_core 3.4.7, which integrates some of the feedback and discoveries of the last few weeks... thanks for all the help, folks. Debugging help and feature suggestions from LANDesk admins around the world are making this utility into a very useful tool indeed.

Here's a few notes about where it might (or might not) go next:

• Scheduled Tasks
•   
   
  •  
   
  • Check scheduled tasks and policies for RRD stats -- jobs without start times, jobs in success-level buckets, duplicated jobs...   
        
   
  •  
   
  • Delete ghost devices from scheduled tasks (stuck in active because they reported status). If they were from a query they should be deleted from the list, but if they were from a static targeting they should be moved to pending. http://community.landesk.com/support/message/17222#17222   
        
   
  •  
• Import   ldms_delete_users, auto-reassign to single user or delete objects, give the user an option to decide what should be done. Alternatively, rewrite ldms_delete_users as a standalone tool...
• NMAP as an XDD client add-on instead of a core-side piece... this implies some command-channel use and data-passing which are non-trivial, but entirely possible. On the plus side, it will also produce a much higher level of accuracy in OS fingerprinting.
• Email
•   
   
  •  
   
  • Be smart about hysteresis... maybe it could not send another email within a day unless the new email it wants to send is more urgent than the last email that it had to send? Users going from daily runs to hourly runs are having challenges sorting the important emails from the repetitive info.
   
  •  
   
  • Maybe it's email worthy that unmanaged nodes isn't fresh...   
        
   
  •  
• Web pages and reports
•   
   
  •  
   
  • In RRD pages, give textual data supporting the graph. That'll probably push it over the edge to needing templated data instead of straight html.   
        
   
  •  
   
  • Support proxy servers (nice to have for update check, will need for geo-location)   
        
   
  •  
   
  • Give links to non-RFC1918 addresses on maps: GeoIP2Location   
        
   
  •  
   
  • Drill-down from topology map with per subnet listings of computers, including inventory and remote control links for them   
        
   
  •  
• Auto-import email from domain controller into ConsoleUser table. If UserName is like Directory and Email is blank, then import from AD. Requires AD credential input in UI.
  
• Count duplicate serial number records and show a count before the number... e.g. "34 machines with serial number SystemSerialNumb, 2 machines with LYAC12"
• More options, more smarts, more feedback, more efficiency...
  
• Find why McAfee silently stops it from working properly when it's run as a scheduled task (error 0x9 in Windows scheduled task, immediate "success" as a LANDesk scheduled task, works great when run interactively from the start menu).

Version 3.2.6 is now uploaded to http://www.droppedpackets.org/scripts/ldms_core.

As the next step in its ongoing quest to delete data that was automatically gathered and then left to rot, ldms_core will now delete automatically gathered SLM products that have no installations (note that this is not USAGE, but INSTALLS).

It is possible that this can produce churn in situations where products are being installed and uninstalled in rapid succession; this should be a minor problem compared to the database performance degradation that results from thousands of junk product definitions.

As is usual with new features, this needs testing; please give it a whirl on your test server before trying it on production. At the very least, have a database backup handy.

I've posted a new ldms_core which has a lot of changes (good, bad, and otherwise).

• added ability to report on stale vuln data (greater than 7 days will produce a warning)

• installation directory changes -- NullSoft Installer System uninstallation routine actually assumes a separate directory per program, and was deleting things that shouldn't be deleted when users would remove a program. To correct this, uninstall all Monkeynoodle programs and delete Program Files\Monkeynoodle before installing ldms_core.

• detect dual boot systems via serial number

• fixed &CullIPs again -- I had a function which seemed to do the right thing, but was actually deleting the oldest IP -- the downfall of using a small test set is that the expected result might happen for the wrong reasons.

• Always check that what's supposed to be an IP is one -- failure to do so was causing spurious calls to DoNMAP and CullIPs

• LDMS statistics graphing and trending via RRD. This is pretty cool; I'm just generating the graphics and putting them into ldmain\reports\ldms_core for now, but I'll throw together a nice index.html for it in a bit. LDSS stats are not being gathered yet.

• hourglass cursor when setup is doing things

• Unmanaged nodes culling (&CullUDD) failed when the discovered node was a WAP; skipping the attempt for now.

I'm still trying to decide if I want to spend time on a more formalized test procedure and/or beta period... if anyone has thoughts or would like to volunteer as a tester, please let me know.

I'm also having some difficulty with the Right Way(TM) to schedule repeated runs... in the past, I've asked the user to create a Windows scheduled task, but those quit working when the service account password changes. Currently I'm creating a LANDesk scheduled task, but those are finicky and are least likely to work on the cores which most need an automatic maintenance program. I could go to a long-running service, but memory consumption is high and that introduces a whole new set of potential problems. Ideas are welcome.

ldms_core home page

The new alert system in version 8.8 can get stacked up on low-performance cores, and it doesn't purge records unless you tell it to. ldms_core will now check that queue and purge records older than X days. There's also an email test button in the setup window, so you can make sure you've got email right.

I've also updated the manual.

Today I enhanced debug mode and provided for a debug logfile. I also did a bunch of refactoring and bug fixes... maybe half of what Perl Critic suggested. This isn't an urgent release unless you're having trouble, might as well wait for 3.0.

http://www.droppedpackets.org/scripts/ldms_core/ldms_core_2-0.zip/view

I've got some reports of problems with NMAP... it crashes and takes ldms_core.exe with it. That's not supposed to happen, so if it's happening to you, please let me know and send a debug file.

UPDATE: Talk about relentless... Arnold Garcia tested with the new debug stuff and helped me find a problem, along with some more debugging suggestions. I did some more refactoring as well, so I've posted again and let's call it 2.9.8. This is worth upgrading to if you've had trouble with NMAP.

The TODO list:

1. TODO -- Test email button in the GUI

2. TODO -- Setup should install a LANDesk LOCALEXEC script to run it

3. TODO -- Provide visual feedback of activity stage, level

4. TODO -- Check scheduled tasks and policies

5. TODO -- plot non-RFC1918 addresses on a map

6. TODO -- keep old information and show a trend.

7. TODO -- purty Charts, http://search.cpan.org/src/CHARTGRP/Chart-2.4.1/README

8. TODO -- when you find duplicate IP addresses, wipe out the one that has the

9. older update date.

10. TODO -- If the database isn't busy, reindex it? Detecting a need to reindex

11. the database seems to be just as intrusive as actually reindexing the

12. database. More research required before this can be done safely.

I've posted a beta release of ldms_core at http://www.droppedpackets.org/scripts/ldms_core/ldms_core_2-9-5beta.zip which attempts to support email authentication. If you'd like to try it out, please let me know of any errors.

17 days without a complaint, it must be working. 2.9.5 is published.

I've done a few installs of ldms_core on servers where XDD or scheduled UDD has been running for a good long while in a 5,000 to 10,000 node environment, and I've found a bit of a performance issue. Eventually it all works itself out, but that first run takes a day or two to complete. Gradually it gets faster and faster, and within a week it works the way it does for a fresh LANDesk core. This post is not to announce a fix, just acknowledging that I see the problem and know what needs to be done.

This is what's happening: If NMAP's binary is found in the configured place, then ldms_core goes to the database and looks for targets with no OS Name, sorted by lastscantime desc for a LIFO scan order. So far so good, except a few months ago I realized that some NMAP scans finish in a few seconds, while others take several minutes. In order to get the most success up front, I first send a single ping packet to each target and see if it responds. If it answers ping, it goes to the front of the list, and if it doesn't, it goes to the back of the list.

That works really well when the list of targets is a few dozen machines, but when it's a few hundred machines the performance is terrible. As NMAP updates the OS Names, the target list becomes smaller, the pings go faster, and less time is taken. I'm not parallelizing any of this traffic, so a long time spent on step 1 means step 2 can cool its heels in the corner. This all fits with my design goal of "low and slow", under-the-radar information gathering, but no one can tell that it's doing anything -- there's an icon in the system tray and a couple of entries in event viewer, but no CPU, no network, no nothing.

I've considering batching targets into small groups, which I could then do in parallel, but decided it was too complex and wasteful of resources. So, the planned fix is a two parter:

1. First, I'm going to log and balloon tip what's happening so that the end user knows that it's okay to leave it alone... killing the program and starting it over just makes it take longer, and all the statistics that they installed it for happen at the end.

2. Second, I'm going to radically decrease the ping timeout -- if the node doesn't ICMP REPLY in a second or two, I know what I came for. Better still, if the machine responds to ping I'll do NMAP right away, but if it doesn't respond to ping I'll push it to the end of the line.

If you really care a lot, the source is installed with the binary, and this is the DoNMAP subroutine beginning at line 1119.