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.

Every now and then someone will question the support terms of one of my open source projects, such as ldms_client. (To refresh those terms, they are: email me and I'll see if there's something I can do when I've got time to work on it.) Users who are unhappy with such terms will occasionally then go to the trouble of implementing their own custom solution to their inventory extension problem.

Chances are good that such a solution will not be supported either. Bearing in mind that I don't work in LANDesk support and am only guessing at what a given engineer will do on the day you call for help, my opinion is that LANDesk's support will center around successfully running the command and transferring the data.

ldms_client uses supported methods to do that, and so do the vast majority of the homegrown scripts that I've seen. But if either your script or ldms_client quit working properly, LANDesk support is within their rights to quit troubleshooting when they determine that LDMS can still execute programs and upload custom data. If the framework is working but your AV client is blocking your VBscript from copying a value out of HKCU into HKLM so that LDAPPL3.INI can pick it up, that's not really LANDesk's problem.

ldms_client exists because someday you'll come across another need for some goofy inventory extension, and someday they'll quit asking for this one... When you start trying to turn extensions on and off without its framework, you'll probably wish you had it.