Cactiusers.org

It would be great to have the plugin version number on the page of the plugin. It would make it easier to keep of the rev of each plugin without having to ssh into the server and examine the files directly

This would actually take away from the "seamless" look that the Plugin Architecture gives Cacti. Instead there is currently a Plugin Updates plugin that is in the works that will track and list all your Plugins and will pull down the latest version information and let you know when there are any updates, and what changes were made.

If you set it to automatic mode, it will pull the info once a day, and display something like "2 plugins have new updates to install" as a MOTD when specified users log in.

cool, even better.

Thanks

Will this be some kind of "central registry of plugins", or simply a URL specified by the plugin's setup.php that the manager fetches from?

Yes, it will be a specific URL that the plugin will have to support in its version array, or else it can contain a plugin ID, which connects to my repository here. I already have a lightweight script written that will allow it to query certain aspects, just have to finish the actual plugin itself.

Cool. That's one less thing to coordinate in releasing a new version :-) I guess it'd be interesting to see how many users you really have, too.

By the way, I added two new realm IDs in the wiki for weathermap, is that the definitive list? Next version of my weathermap will have at least a view/manage interface within Cacti, with editor (maybe) to follow.

I will be releasing a copy of the script and database required (probably a non-database version also), so that you can basically run the same exact script that I do, without having to guess at what you are suppose to be reporting back to the plugin.

So far its the only realms I know of, and it is what I currently go off from if I create any new plugins. Hopefully any other plugin authors will add theirs if they need it. In the future, this will be moot, as the realms will be "auto" assigned when the plugin registers itself with Cacti, basically on a first come first version basis.

Here is the current screen shot of the Update Plugin. Everything is working perfectly so far. It will automatically poll for updates every 1 day, 2 days, 1 week, or 1 month. It currently lists all plugin versions that contain the proper version functions (most everyone already does), and then there are a few extra variables in the function for allowing for checking versions on any site, and displaying author info.

I won't allow anything less than 1 day to prevent hammering the server. There is a -f option to force it from the command line, but if I notice someone hammering the server, their IP will be banned (only for extreme cases, like 3000 times a day, not for users trying to debug an issue for an hour). I already have this issue with a plugin I wrote for squirrelmail, as I currently get about 2 million hits from it a month, most of them hammering me because they are improperly configured.

The plugin is almost ready for release. All I need to finish is having the plugin display the changelog for any new plugins on the Updates screen.

I have now pretty much finished the plugin, it will now display any changes made to any updated plugin it finds. It also checks for updates to both Cacti and the Plugin Architecture.

I should have a release out sometime soon. I also need to release the scripts that plugin checks against, but that won't take long.

Just thinkin outload again....Do you have any plans to actually do the update from within the updates plugin? Nothing automatic (too dangerous) but a "do update now/undo update now" button would be cool.

cp -R plugins/foo oldplugins/foo0.1
cd plugins
wget $url/foo0.2.tar.gz
tar -xzvf cd plugins
rm foo0.2.tar.gz

Might be a little hairy when there are db changes but I think it's still quite possible esp with the backup plugin installed.

Also I noticed it doesn't detect what plugin arch you are using (maybe add the version to plugins/index.php) --edit nevermind found it in testing :P

Sorry, but the HTTP fetch is *really* cheesy! My server obviously returns more lines (or less) that yours, so the fetch fails (I get the Content-type header as the version). Shouldn't it just scan until a blank line? (like an e-mail header) The next line is the start of the content then. Rather than just complain, here's a replacement suggestion...



Now I've made that change, I think I have a working update :-D Nice one jimmy!

Ya, I didn't notice that, as it worked fine on my 3 different test servers. I will wipe up some code and release a new version.

Jimmy, is there any news on a more standards-compliant version of update? I have 3 plugins out now with update support added, but the update plugin won't actually support them yet

Actually, I have just updated the code and will be releasing a new version shortly. Your example worked perfectly, THANKS!

Cool, thanks! :-) A couple of people have asked why it half-works for Weathermap...

Seems that I have around 50 Weathermap users who are already using the update plugin, just from a quick grep, so that sounds promising for it being a useful and popular plugin! That's about 15% of the downloaded copies.