Here's a useful little tool that aggregates the various logfiles that LANDesk produces: http://www.droppedpackets.org/scripts/ldms_log

You'll find core and client programs, no installer necessary.

http://www.droppedpackets.org/management-gateway-and-remote-control/ldms_auto_gateway for details, but at version 1.0.8 it is successfully deployed at several customers of greater than 1,000 nodes.

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).

Any member may post articles anywhere, within the guidelines set on the main page.

Member accounts without associated email addresses have been deleted... you may be affected if you haven't used it in the last few months.

Aside from the usual bugfixes and cleanup, this release adds configurable control over how hard ldms_client will look for email folders, and a report of the machine's FQDN.

Code and instructions can be found here: http://www.droppedpackets.org/inventory-and-slm/ldms_client

The conversations around future release ideas for ldms_core have proven interesting and useful, so here's an attempt to gather some of the loose notes:

• TODO -- Firewall status is enabled /disabled. We do this in custom defs, but don’t put the status anywhere.
• TODO -- It would be interesting to see the firewall specifics broken down a bit by port and app, but that could be a ton of work and difficult to format in a useful way.
• TODO -- Capture the connected SSID. Something Perlish? WMI? netsh? All have problems.
• TODO -- Custom vulnerability to install/update Produkey? Is there a better way to use Produkey, or do the same thing without it?
• TODO -- Find a way to identify Adobe licenses... even if it's not decrypted, an identifiable GUID would be useful.
  
• TODO -- Report system crashes from event log.
• TODO -- The ongoing search for greater efficiency.

There'll be rejoicing in the alleyways tonight! http://www.droppedpackets.org/

If you'd like to see the gory details, read on.

Firstly, I wouldn't feel comfortable telling customers to test thoroughly and carefully if I wasn't personally inclined toward shooting from the hip. Backups were taken, but this upgrade was not really tested meaningfully. That's why it took about 15 hours of work instead of 5.

• Hardware -- It's more fun to compute like it's 1999. Don't go changing!
• OS Upgrade -- smooth and well-played. Moving from the execrable OpenSuSE 10.0 to Xubuntu 8.04 was a good idea.
• Zope/Plone Upgrade -- and this is where the trouble begins. To use the package manager, or to use source? The Ubuntu packages for Zope and Plone are less than perfect; they're old, they're goofily designed, and they're a bit buggy. But, the install from source method is difficult and unpleasant to maintain... so when it didn't work and consumed a bit of troubleshooting time, I went back to the packages. That settled things on Zope 2.3 > Zope 2.9 and Plone 2.1.1 > Plone 2.5.1, and older revisions of some other packages that I wanted upgraded (such as Kupu, which is now at 1.3.9).
• Site Restoration -- You simply restore the Data.fs file and restart, right? Well, it references products which may or may not exist, and it also does a bunch of magic which may or may not work. I must have wiped the machine back to a zope-free state and started over 6 or 7 times. I can tell you from memory that line 81 of the post-install for Ubuntu's plone-site package has a typo, for instance (setuser zope:zope, not setuser zope).
• Site Upgrade -- You simply go to product_migration in the ZMI and click migrate. Except you also need to do that on portal_atct (undocumented), and if you do it without deleting your cookie_authentication object you'll be locked out of the site, and the dry-run option doesn't really dry run, and don't forget to delete your customizations from the old school days because they'll make things break. It wasn't as bad as installing Oracle, but it wasn't fun.

There was more, and there's still more to do, but it'll wait. I'm outta here for the weekend.

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.

http://www.droppedpackets.org/scripts/ldms_status

I was at a customer Friday, and discovered that when I hovered over ldms_status, it would turn red, flail madly, and keel over dead, sort of like Bowker holding a ball at first and trying to decide what to do with it. Turns out, their server had 1 Inventory Service thread and 4500 clients, so LDSCAN contained a backlog of 4300 inventory scans, and growing. Whenever CountPendingScans ran, ldms_status was correctly deciding to restart the inventory service. It was incorrectly ignoring several instructions to wait a few seconds, and it was incorrectly doing this over and over as long as I hovered over the icon, causing a flickering stream of balloon tips and event viewer messages and doing nothing for the backlog of scans.

Partially, this is a discovery of unexpected behavior from the poorly documented perltray... I'm discovering that the Tooltip subroutine runs repeatedly as long as you're hovering on the icon, and I suspect that it sets the Timer too, overriding my timer settings. But the other part is that I was sloppy about the tooltip in the first place, and was calling code on demand. So, I decoupled the CountPendingScans subroutine from ToolTip. I'd been meaning to do that anyway as a matter of good practice, so finding a bug is just good impetus to do it right.