TBH, it's primary function is to monitor active installations. So whatever you do with this, make sure it does still serve this primary function. :-)

Right now, collecting information abut active installation is kind of awkward and very cumbersome. If you decide to work and improve on this, you can make it more straightforward. Maybe, we could redirect all these calls to some kind of HTTP API?

The new version could have improved code which would directly call the HTTP API method and for all other versions we could make some sort of call forwarding with rewrite rule to point to the HTTP API method.

However, it is not really that important. What is important and critical is, that we continue to collect information about active installations.

There were a couple of problems:

• the domain has changed (but there was a redirect)

• the files gone missing (I've re-added them and fixed redirections [for the time being while working on solution])

• but more importantly - installUpdatesChecker - was not executed since the switch to kernel/DSL (so almost all nightly since a couple of months were not generating request)

• I also think that the new version XMPP notifications send to admin users stopped working a while back (lack of xmlns hence messages being dropped).

What I've done:

• analysed how it worked before and what data was collected previously;

• created Version helper class to ease handling version parsing and comparison;

• created "update" http-api endpoints backed by the repository implementation:

  • /check endpoint is the basic one - returns latest stable version information and stores information about request in the repository (tries to resolve hostname and obtain VHost like the previous one did)

  • /set (requires admin credentials) - at the beginning I've went with idea of manual setting latest version, but then it occured to me, that getting it from redmine would make way more sense (unfortunately "files" rest API was introduced in next version so I ended up parsing the page with the defined period - currently on a daily basis);

  • /view (requires admin credentials, http://update.tigase.net/view ) - allows to browse statistics: allows to set time frame (from/to parameters, if "from" is omitted then by default 1 week range (I've opted for such range because by default UpdateChecker was and is configured to check on weekly basis so 1 week window should show us all installations) prior to "to" parameter, if "to" is omitted then today will be used); it lists all the requests and associated data, marks new items (i.e. items that report new vhost, and by new it's understand that it didn't occur before "from" date) and group the same requests; it also lists all the resolved VHosts with the same "newness" marking as described before (previously there was a distinction with "old" and "new" but those weren't installations but rather reference to version based on the uri accessed [which was a bit confusing...] - I've left that and "old" uri will report version 5.1.0 and "new" will report version 7.1.0 as those versions were matching, newer version will report versions based on actually used one).

• configured cron to send daily summary in text format (following more or less the same format as described above) with time range of 1 week (could be changed to 1 day);

• reworked UpdateChecker - (fixed notifications being missing, scheduling it's execution, etc…)

• deployed the rest package to our tigase.org installation; %Eric - there is an "update-checker…" archive on both machines containing all necessary files and their appropriate paths so it's enough to extract it over tigase-server installation (you can create such package from the repository: https://projects.tigase.org/projects/tigase-update-checker-handler); update-checker handler require additional dataSource {} configuration:

'update-stats-upload-data-source' () {
    uri = 'jdbc:mysql://t2.tigase.org/tigase_org?user=t2drupal&password=treeswood'
}

• updated redirections and created DNS entry update.tigase.net to make handling it easier in the future.

%kobit - currently notifications are enabled and working, which may make people more aware about the mechanism and thus more prone to disable it (especially that it would generate notification on a weekly basis if it would detect new version) -- maybe tweaking the mechanism to generate notification only once for each new version or decreasing the notification frequency - let's say to 1/4th or 1/8th of the check frequency - would be better?

Yes, good point to the last paragraph. I think the best would be for the Tigase to generate a notification only once when a new version is discovered, with the current weekly checking. I can be simple implementation, that it last notification/version data in memory only. So, every time it is restarted and discovers a new version of the server (after 1 week of running), it would send a notification to the admin about new version available.

It would be ideal if a single notification is sent from a cluster installation, instead of a separate notification from each cluster node.

I've added the implementation as above: the notification will be send only once per new version for the whole cluster. I've left original delay of 7 days so only "longer running" installations will check for newer version - should this be adjusted?

I've also left checking on each nodes so we will get "pings" from all machines within cluster, so if they are behind LB of sorts we will get the count of the machines within cluster.

All is good now.