[Plugin] CA Application Auto Update

[pwm]

6 hours ago, Squid said:

Something we didn't consider.  4.x.x is greater than 2018.  Plugin manager does a simple string comparision.  Guess you'll have to go back to the way things were.

Best would be to do a version compare. That's a compare where each field is split at the '.' and compared as numbers. A version compare would then treat 2018.01.10 the same as 2018.1.10. And a version compare would also correctly handle 1.2.3 compared to 1.10.19, ie. traditional version numbers. The only thing to think twice about for a traditional version compare is potential suffix characters after the last numbers. They have to be compared as normal string so 1.10.1 is sorted lower than 1.10.1a.

 

See for example:

http://php.net/manual/en/function.version-compare.php

[jbrodriguez]

Ok, I'm reverting to the previous versioning.

 

If this get sorted, I'll go back to date-based versions.

 

pwm, I think php's version_compare handles suffix characters, at least it does with unRAID's versions (6.4.0-rc20f, 6.4.0-rc21b, etc).

 

[pwm]

27 minutes ago, jbrodriguez said:

Ok, I'm reverting to the previous versioning.

 

If this get sorted, I'll go back to date-based versions.

 

pwm, I think php's version_compare handles suffix characters, at least it does with unRAID's versions (6.4.0-rc20f, 6.4.0-rc21b, etc).

 

Yes, PHP's version_compare is quite flexible and will properly handle most common ways of writing version numbers in the proper way. So I very much recommend that this function is used instead of a strict string-compare.

[bonienl]

The plugin manager uses PHPs built-in function "version_compare" for comparing unRAID versions since these follow the major.minor.point version notation with optional alpha, beta or rc suffixes.

 

Plugins follow the year-month-day notation with optional letter suffixes. This notation doesn't compare well when using the PHP function. E.g. it will not see that version 2018.01.11b is newer than 2018.01.11a, hence the string compare for plugin versions.

 

A workaround for jbrodriguez could be to place a letter in front of the version number, for example: v2018.01.11

 

[pwm]

5 minutes ago, bonienl said:

The plugin manager uses PHPs built-in function "version_compare" for comparing unRAID versions since these follow the major.minor.point version notation with optional alpha, beta or rc suffixes.

 

Plugins follow the year-month-day notation with optional letter suffixes. This notation doesn't compare well when using the PHP function. E.g. it will not see that version 2018.01.11b is newer than 2018.01.11a, hence the string compare for plugin versions.

 

A workaround for jbrodriguez could be to place a letter in front of the version number, for example: v2018.01.11

 

Have you actually tested?

<?php

function test_ver($v1,$v2) {
    echo "version 1 [$v1]\n";
    echo "version 2 [$v2]\n";
    echo "Compare: ".version_compare($v1,$v2)."\n";
}

test_ver("2018.01.11a","2018.01.11b");
test_ver("1.2.3","1.12.1");
?>

Result:

version 1 [2018.01.11a]
version 2 [2018.01.11b]
Compare: -1
version 1 [1.2.3]
version 2 [1.12.1]
Compare: -1

So it did understand that 2018.01.11a is less than 2018.01.11b.

And it did understand that 1.2.3 is less than 1.12.1.

[Squid]

In retrospect, I thought that pluginman  (at least on 6.3.5) used str_compare.  We've had so many discussions on this @bonienl that I can't remember.  But you've also got to remember here that we're trying to switch from a version 4.x.x to 2018.x.x  version_compare should figure that out (2018 > 4), but str_compare will fail (4 > 2)

 

Net result either way is that only using Check For Updates from plugins works fine either way.  Its CA Auto Update that can't make head or tails of a version called 4.x.x because it's extracting a date from the version  so that it can automatically delay installing updates for so many days (using date_diff)

Edited January 12, 2018 by Squid

[bonienl]

1 hour ago, pwm said:

So it did understand that 2018.01.11a is less than 2018.01.11b.

 

I gave the wrong example. The problem arises when comparing versions with and without letter suffixes. E.g 2018.01.11 vs 2018.01.11a

 

Sure it was tested with "version_compare" (this is already a long running story).

 

unRAID versions 6.3 and earlier use the "str_compare" function. These earlier versions do not distinguish between user and OS plugins, hence the same compare method is used for both.

 

From unRAID 6.4 user plugins and OS plugins (=updates) are separated. This gives the ability to do version_compare on OS updates which follow a different/standard notation and it was decided to keep str_compare to not break the plugin version notation system.

 

A bit unfortunate that not every plugin developer is using the recommended date notation.

 

[pwm]

version_compare() will:

- correctly handle compare of two versions a.b.c[optional prefix]

- correctly handle compare of two versions yyyy.mm.dd[optional prefix]

- correctly handle compare from a.b.c[optional prefix] moving to yyyy.mm.dd[optional prefix] as long as a is lower than current year.

- fail to handle compare from yyyy.mm.dd[optional prefix] to a.b.c[optional prefix] unless a is larger than current year.

 

In the end, version_compare() is the expected function to use, because the problematic variants for version_compare() are just as problematic for string-comparisons because it represents a comparison that are not actually defined. Not even a human can compare a 1.2.3 with 2017.12.10 and know which is newer, without access to the history log for the software.

 

A pure string compare can't understand that 2017.10.12rc10 is > 2017.10.12rc2.

[pwm]

5 minutes ago, bonienl said:

The problem arises when comparing versions with and without letter suffixes. E.g 2018.01.11 vs 2018.01.11a

Yes that is a relevant issue - I normally use a workaround on the version_compare() to handle that case, since string-compare fails so very badly unless you whip everyone to use a very narrow definition of version numbers.

[bonienl]

I can't remember all the details, and surely we wanted to use the "version_compare" function, but it broke the plugin version checking.

 

The recommended plugin version is

yyyy-mm-dd

and if more updates on the same date are needed then letters a-z are appended.

 

With plugin versions we don't talk alpha, beta or rc releases.

 

[jbrodriguez]

Ok, so I'll eventually switch to the suggested workaround: v2018.01.11 or v2018-01-11 to be more compliant with the recommended plugin version.

 

Thanks !

[Squid]

On 1/12/2018 at 1:03 PM, jbrodriguez said:

Ok, so I'll eventually switch to the suggested workaround: v2018.01.11 or v2018-01-11 to be more compliant with the recommended plugin version.

 

Thanks !

I'll test CA with that format and update if necessary.  

 

EDIT:  Tested with plugin Manager and CA autoupdate, and there's no problems with that.

Edited January 13, 2018 by Squid

[cheesemarathon]

Hi there

I'm having an issue where the docker update tab is showing containers that no longer exist. The containers in the image below that say "Unknown" for the image name no longer exist. They are not in the main docker list either. How does the plugin get its info on installed containers?

[Ecsport108]

On 3/29/2018 at 5:43 AM, cheesemarathon said:

Hi there

I'm having an issue where the docker update tab is showing containers that no longer exist. The containers in the image below that say "Unknown" for the image name no longer exist. They are not in the main docker list either. How does the plugin get its info on installed containers?

 

I am also experiencing this issue, specifically with Docker containers that were not installed through Community Applications, but rather manually through commands. I am unsure if this last part is related or just coincidental. Any ideas on how to get these 'ghost' plugins to be properly removed?

Unraid Version: 6.5.1-rc2

Plugin Version: 2018.03.02

 

EDIT: I realized after initially posting that pihole is also a 'ghost' Docker that I removed, I installed that Docker using Community Applications, therefore disproving my initial hypothesis.

Edited April 18, 2018 by Ecsport108

[Squid]

Epic nobel is a container you installed, and didn't give it a name.  Starbound you probably named it as such.

 

The plugin gets its info directly from docker, and doesn't worry about how its been installed.

[Ecsport108]

1 hour ago, Squid said:

Epic nobel is a container you installed, and didn't give it a name.  Starbound you probably named it as such.

 

The plugin gets its info directly from docker, and doesn't worry about how its been installed.

 

Okay, thank you for the info! However, I am still struggling to get these Dockers to go away. They are no longer installed and the images have been removed, I have also run a prune command so there shouldn't be any remaining files/plugin info and yet the Auto-Updater still thinks they are installed and tries to update them every night (unless I manually deselect them). Why are these plugins showing up in the first place and what can I do to prevent them from showing up in the Auto-Updater?

[IamSpartacus]

What's the best way to maintain multiple copies of appdata backups?  I currently have my plugin set to autobackup every Saturday morning at 6am.  To a /mnt/user/Data/Backups/docker.  However, as it stands this deletes the previous backup(s).  I'd like to maintain 4 weeks of appdata backups.

[Squid]

Set the # of days to keep backups, and have the frequency shorter than that.  Running every 7 days and keep for 28 will always have 4 backup sets available.

[IamSpartacus]

8 minutes ago, Squid said:

Set the # of days to keep backups, and have the frequency shorter than that.  Running every 7 days and keep for 28 will always have 4 backup sets available.

 

Got it.  Thanks!

[Ecsport108]

2 hours ago, Ecsport108 said:

 

Okay, thank you for the info! However, I am still struggling to get these Dockers to go away. They are no longer installed and the images have been removed, I have also run a prune command so there shouldn't be any remaining files/plugin info and yet the Auto-Updater still thinks they are installed and tries to update them every night (unless I manually deselect them). Why are these plugins showing up in the first place and what can I do to prevent them from showing up in the Auto-Updater?

 

The 'ghost' Dockers disappeared from the Auto-Updater plugin after an update to Unraid version 6.5.1-rc6 and a subsequent system reboot. I don't know which of these prompted their removal but I assume it was simply a reboot the whole time. Sorry for the trouble.

[cheesemarathon]

17 hours ago, Ecsport108 said:

 

The 'ghost' Dockers disappeared from the Auto-Updater plugin after an update to Unraid version 6.5.1-rc6 and a subsequent system reboot. I don't know which of these prompted their removal but I assume it was simply a reboot the whole time. Sorry for the trouble.

 I'm assuming it's a restart that fixed it as well as I have just checked mine and the "ghost" images have gone.

[wgstarks]

I've noticed that even though i have auto update plugin set to update dockers at 7 am i also have dockers updating at 3 am. Checked the system log and it shows that CA Auto Backup is running at 3 am. Does Auto Backup also update dockers? Just wondering if I really need both plugins running daily updates?

 

brunnhilde-diagnostics-20180825-0837.zip

[Squid]

Doesn't hurt, but the Backup settings has the option to not update the containers after a backup is done

[Higgins12]

I'm a bit lost here. I installed the plugin and configured it. Well but it just does nothing. In fact now not a single cronjob does work anymore. Neither the mover which I set to 12am kicks in and either Fix Common Problems doesn't do any scans anymore.

crontab -l only lists 

# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

but the file /etc/cron.d/root has everything in it

# Generated docker monitoring schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
0 0 * * * /usr/local/sbin/mover &> /dev/null

# Generated parity check schedule:
0 0 1 * * /usr/local/sbin/mdcmd check  &> /dev/null || :

# Generated plugins version check schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated Unraid OS update check schedule:
11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated cron settings for docker autoupdates
30 23 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
# Generated cron settings for plugin autoupdates
0 23 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1
# Generated ssd trim schedule:
0 23 * * * /sbin/fstrim -a -v | logger &> /dev/null

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null

tried to uninstall the plugin but still the same. Not a single cronjob is running. Looked thru the log files and can't even find a single instance for crontab. What am I doing wrong here?

[trurl]

6 minutes ago, Higgins12 said:

What am I doing wrong here?

Upgrade to 6.6.5 to fix scheduler.