[Plug-In] Community Applications

[zzkazu]

Ok thanks,  changed setting to allow for install.

 

thanks for a great product and the support.

[Squid]

5 minutes ago, zzkazu said:

Ok thanks,  changed setting to allow for install.

 

thanks for a great product and the support.

Gotta ask:  What setting?  Your screen shot showed you could install no problems

[zzkazu]

I believe I may of consumed too my 'beverages' last night.  I was fixated on seeing the 'Add' button without realizing the install option was ever present.

I set "Docker Hub Searching" to yes and thought that enabled that option.  Gone back to default settings now.

 

Sorry for the curve ball.

[Squid]

docker Hub searches  still show the Add button, but only to really differentiate where you exactly are in the program.  You should always if at all possible install the "regular" apps 

[ThePhotraveller]

some help please  

 

[wgstarks]

Sure it is.

 

 

If you hover your cursor over it you'll see the tool tip.

[ThePhotraveller]

On 5/30/2015 at 4:17 AM, Squid said:

On 5/30/2015 at 1:55 AM, archedraft said:

wow.... fancy

 

 

Will be even better once all the maintainers categorize all the apps.

Hei squid looking for an app that can show me all the people who are connected or transferring files . Like status of the unraid.

[Squid]

Hei squid looking for an app that can show me all the people who are connected or transferring files . Like status of the unraid.

Dynamix active streams

[BillClinton]

updated this great plugin today to 2017.12.26a? and it disappeared. this was using the update all button from Advanced Buttons. Went in to the plugins folder on my flash drive and deleted the plugin to reinstall from the web link in the first post. Now I am getting a 'xml parse error' and it won't install. any help would be appreciated.

 

Here is an extract from my syslog;

 

Dec 30 12:48:10 Tower php: /usr/local/emhttp/plugins/advanced.buttons/script/plugin 'update' 'unassigned.devices.plg' 'community.applications.plg' 'ca.docker.autostart.plg' 'ca.backup2.plg' &>/dev/null &
Dec 30 12:48:10 Tower root: plugin: running: anonymous
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/unassigned.devices-2017.12.26a.tgz already exists
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/ntfs-3g-2013.1.13-x86_64-1.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: anonymous
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/nmap-7.12-x86_64-1.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: anonymous
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/exfat-utils-1.2.7-x86_64-1_slonly.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/exfat-utils-1.2.7-x86_64-1_slonly.txz
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/fuse-exfat-1.2.7-x86_64-1_slonly.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/fuse-exfat-1.2.7-x86_64-1_slonly.txz
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/hfsprogs-332.25-x86_64-2sl.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/hfsprogs-332.25-x86_64-2sl.txz
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/libbsd-0.8.6-x86_64-1_slonly.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/libbsd-0.8.6-x86_64-1_slonly.txz
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/parted-3.1-x86_64-1.txz already exists
Dec 30 12:48:10 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/parted-3.2-x86_64-2.txz already exists
Dec 30 12:48:10 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/parted-3.2-x86_64-2.txz
Dec 30 12:48:11 Tower root: plugin: skipping: /boot/config/plugins/unassigned.devices/packages/libnl-1.1.4-x86_64-1.txz already exists
Dec 30 12:48:11 Tower root: plugin: running: /boot/config/plugins/unassigned.devices/packages/libnl-1.1.4-x86_64-1.txz
Dec 30 12:48:11 Tower root: plugin: creating: /tmp/start_unassigned_devices - from INLINE content
Dec 30 12:48:11 Tower root: plugin: setting: /tmp/start_unassigned_devices - mode to 0770
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: skipping: /boot/config/plugins/community.applications/community.applications-2017.12.20.txz already exists
Dec 30 12:48:11 Tower root: plugin: running: /boot/config/plugins/community.applications/community.applications-2017.12.20.txz
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower unassigned.devices: Disk with serial 'ST2000DM001-1ER164_Z4Z03SG1', mountpoint 'ST2000DM001-1ER164_Z4Z03SG1' is not set to auto mount and will not be mounted...
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: creating: /boot/config/plugins/ca.docker.autostart/ca.docker.autostart-2017.12.19-x86_64-1.txz - downloading from URL https://raw.github.com/Squidly271/ca.docker.autostart/master/archive/ca.docker.autostart-2017.12.19-x86_64-1.txz
Dec 30 12:48:11 Tower unassigned.devices: Disk with serial 'ST32000542AS_6XW16NJY', mountpoint 'ST32000542AS_6XW16NJY' is not set to auto mount and will not be mounted...
Dec 30 12:48:11 Tower unassigned.devices: Adding disk '/dev/sdl1'...
Dec 30 12:48:11 Tower unassigned.devices: Drive '/dev/sdl1' already mounted...
Dec 30 12:48:11 Tower unassigned.devices: Partition 'WDC_WD7500AAKS-00RBA0_WD-WCAPT0571282' could not be mounted...
Dec 30 12:48:11 Tower root: plugin: checking: /boot/config/plugins/ca.docker.autostart/ca.docker.autostart-2017.12.19-x86_64-1.txz - MD5
Dec 30 12:48:11 Tower root: plugin: running: /boot/config/plugins/ca.docker.autostart/ca.docker.autostart-2017.12.19-x86_64-1.txz
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: running: anonymous
Dec 30 12:48:11 Tower root: plugin: creating: /boot/config/plugins/ca.backup2/ca.backup2-2017.12.22-x86_64-1.txz - downloading from URL https://raw.github.com/Squidly271/ca.backup2/master/archive/ca.backup2-2017.12.22-x86_64-1.txz
Dec 30 12:48:12 Tower root: plugin: checking: /boot/config/plugins/ca.backup2/ca.backup2-2017.12.22-x86_64-1.txz - MD5
Dec 30 12:48:12 Tower root: plugin: running: /boot/config/plugins/ca.backup2/ca.backup2-2017.12.22-x86_64-1.txz
Dec 30 12:48:12 Tower root: plugin: running: anonymous
Dec 30 12:55:48 Tower php: /usr/local/emhttp/plugins/advanced.buttons/script/plugin 'install' 'https://raw.githubusercontent.com/Squidly271/community.applications/master/plugins/community.applications.plg' &>/dev/null &
Dec 30 12:56:45 Tower php: /usr/local/emhttp/plugins/advanced.buttons/script/plugin 'install' 'https://raw.githubusercontent.com/Squidly271/community.applications/master/plugins/community.applications.plg' &>/dev/null &
Dec 30 12:58:48 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog
Dec 30 13:08:40 Tower php: /usr/local/emhttp/plugins/advanced.buttons/script/plugin 'install' 'https://raw.githubusercontent.com/Squidly271/community.applications/master/plugins/community.applications.plg' &>/dev/null &
Dec 30 13:12:44 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog

Thanks in advance.

 

if you need anymore info let me know.

 

 

Edited December 30, 2017 by BillClinton

[Squid]

10 hours ago, BillClinton said:

updated this great plugin today to 2017.12.26a? and it disappeared. this was using the update all button from Advanced Buttons.

I just did a reinstall from scratch of CA, and 2017.12.20 installs no problems  (I don't use advanced buttons, but rather have CA AutoUpdate set to just keep all plugins up to date)

 

11 hours ago, BillClinton said:

Went in to the plugins folder on my flash drive and deleted the plugin

If you do this, without rebooting and then attempt to reinstall, you will see the behaviour above (ie: the apps tab will disappear).  This is because the install package is still installed, and reinstalling over itself trashes everything.  You're going to have to reboot to fix this now.

[BillClinton]

@Squid

Got it fixed with a reboot.

 

(tried the delete procedure because it has fixed other plugins with similar issues in the past. Didn't take into consideration the higher integration of this plugin )

 

Thanks for the help over the holiday.

 

all the best for the forthcoming year.

[Squid]

Probably won't affect anyone, but as of Jan 1, the minimum unRaid OS required for CA is now 6.1.8

[Gog]

Hi there

 

Is there a way to get the release notes in the notification when a plugin is auto updated?

[Squid]

22 minutes ago, Gog said:

Hi there

 

Is there a way to get the release notes in the notification when a plugin is auto updated?

I suppose I can add that in.

[Gog]

1 hour ago, Squid said:

I suppose I can add that in.

 

Thanks.  It's not a big need I just read the notification email about CA right before I read your update about 6.1.8 support and it clicked.  I used to read the release notes before upgrading but with auto upgrade that stopped.  

[Squid]

8 minutes ago, Gog said:

 

Thanks.  It's not a big need I just read the notification email about CA right before I read your update about 6.1.8 support and it clicked.  I used to read the release notes before upgrading but with auto upgrade that stopped.  

Let me put it this way.  CA Auto Update exists for one reason and one reason only -> to keep CA itself up to date (although a side benefit is the ability to use it to update other plugins / docker apps).  It's an annoyance to me when I look at logs and see old versions of CA running, and I know that due to changes in the feed / mistakes made by the app maintainers that the version will no longer operate correctly.

[pwm]

I did an attempted update on jan 1st from version 2017.12.20 to 2017.12.31.

 

I didn't notice exactly what it was writing on the first update attempt but it didn't perform any update.

What it did was uninstall the previous version - I have no directory /usr/local/emhttp/plugins/community.applications

 

 

The file /boot/config/plugins/community.applications.plg is for version 2017.12.20.

 

If trying to press the update button again, it fails with:

plugin: updating: community.applications.plg


Cleaning Up Old Versions


plugin: downloading: https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz ... failed (Invalid URL / Server error response)
plugin: wget: https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz download failure (Invalid URL / Server error response)

I didn't immediately noticed that I missed the application - I thought it was just a temporary issue with the repository. Then I noticed I no longer had the extra tab for applications.

 

The log from my update attempt doesn't show anything special - I did try twice, and I'm pretty sure the popup dialog did show extra text the first time.

Jan  1 05:45:21 n54l-3 emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update community.applications.plg
Jan  1 05:45:21 n54l-3 root: plugin: running: anonymous
Jan  1 05:45:21 n54l-3 root: plugin: running: anonymous
Jan  1 05:45:21 n54l-3 root: plugin: creating: /boot/config/plugins/community.applications/community.applications-2017.12.31.txz - downloading from URL https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz
Jan  1 05:45:34 n54l-3 emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update community.applications.plg
Jan  1 05:45:34 n54l-3 root: plugin: running: anonymous
Jan  1 05:45:34 n54l-3 root: plugin: running: anonymous
Jan  1 05:45:34 n54l-3 root: plugin: creating: /boot/config/plugins/community.applications/community.applications-2017.12.31.txz - downloading from URL https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2017.12.31.txz

Edit: Forgot to mention that I run 6.3.5.

Edited January 5, 2018 by pwm
Missing version

[Squid]

The current version is 2018.01.01.  One semi-recurring problem with unRaid's plugin manager is that it doesn't check for updates immediately prior to installing, in which case the previous version may or may not still exist on github.  In this case when unRaid checked for updates, the last version was 2017.12.31.  However there also existed a 12.31a  Most of the time in that case, I stop 12.31 from deleting itself from the server, but obviously I missed it this time.  Either way, a new install should work for you.

[pwm]

Yes, after I had made my error report, I did pick up the git link from the first post of this thread and did a normal install.

 

I just wanted to report that the app was able to uninstall before verifiying that it could download the newer version.

 

But from what you are saying, this is a bug in unRAID itself that should be fixed - the new version should be downloaded with a temporary file name, and no uninstall should be allowed to happen until the new file has been downloaded ok.

[Squid]

19 hours ago, pwm said:

this is a bug in unRAID itself that should be fixed - the new version should be downloaded with a temporary file name, and no uninstall should be allowed to happen until the new file has been downloaded ok

Not a bug per se, Its simply that the reference within the .plg file refers to an (at the time) outdated install package.  Generally its a rare ocurrence.  I thought about issuing a PR to have the plugin system always check for updates to a plg before updating the plugin, but decided against it as I can see where people want to install version X because that's the changelog that they saw, and not version Y because it happened to be done later.

 

As an aside, the auto update plugin doesn't suffer from this because it always checks for updates immediately prior to installing because you've already given it permission to install the latest and greatest.

[pwm]

3 hours ago, Squid said:

Not a bug per se, Its simply that the reference within the .plg file refers to an (at the time) outdated install package.  Generally its a rare ocurrence.  I thought about issuing a PR to have the plugin system always check for updates to a plg before updating the plugin, but decided against it as I can see where people want to install version X because that's the changelog that they saw, and not version Y because it happened to be done later.

 

As an aside, the auto update plugin doesn't suffer from this because it always checks for updates immediately prior to installing because you've already given it permission to install the latest and greatest.

It may not be a bug in CA, but it is a bug for an update manager to uninstall a previous version before having successfully retrieved the new version. Your app should never have to bother if specifically version x exists on github. If it does, then the update should work. If it doesn't then the update should stop before the uninstall step, in which case there should be a chance for the system to continue to monitor github for yet newer versions.

 

Your mobile phone would never uninstall the previous version before it has retrieved and validated a new version.

[bonienl]

Eh no, the plugin manager does not uninstall a previous version before installing the new version.

 

The plugin creator defines in his/her plugin file how the upgrade needs to be done. The plugin manager makes use of the installpkg script of slackware and several options are available to define how to perform the upgrade, but once again it is up to the plugin owner how to do the actual upgrade.

 

One common problem we had in earlier unRAID versions is that the new version information on the plugin page may be outdated when the plugin creator had issued intermediate updates of which unRAID wasn't aware. This resulted in an installation failure since the reported new version and actual new version didn't match.

 

unRAID 6.4 resolves this issue by performing an update when opening the plugins page, which ensures that all version information is always up-to-date and sync'd.

 

[pwm]

8 minutes ago, bonienl said:

unRAID 6.4 resolves this issue by performing an update when opening the plugins page, which ensures that all version information is always up-to-date and sync'd.

That mitigates the problem but doesn't solve it.

 

A user may have that page open for quite some time before deciding to update plugins, in which case the version displayed may still differ from the latest version available on the server.

 

Somewhere down-the-line, whatever script is used needs to verify that the new version is available before the uninstall happens. That's the only correct way of doing an update.

 

I don't normally use slackware since a huge many years, but correct usage would be that the installpkg script is called with a package file as parameter - and that file is expected to exist.

If installpkg is called without an existing script then it will exit.

 

It's just that when updating a plugin, then installpkg is expected to be called from another script - updatepkg - that is responsible for removing unused code. And updatepkg itself verifies that it receives two package names - the old and the new.

 

It really is irrelevant who have written the code - but down the line, installpkg should only be called if the package exists. And the contents of the previous package version should not be removed unless the system has the files for the new package.

 

Does unRAID have a document showing the exact steps performed when a plugin is updated?

[bonienl]

9 minutes ago, pwm said:

A user may have that page open for quite some time before deciding to update plugins, in which case the version displayed may still differ from the latest version available on the server

 

Yeah, that is a corner case not covered, but really how many people leave the GUI opened on the plugins page? Clicking on the plugins button will instantly update the page and I would advice people to do that when they intend to keep the plugins page opened all the time (not recommended).

 

13 minutes ago, pwm said:

Somewhere down-the-line, whatever script is used needs to verify that the new version is available before the uninstall happens. That's the only correct way of doing an update.

 

The plugin manager uses a detection method to check whether a plugin is updated or not. Once a newer version is detected the plugin manager makes a update button available which basically executes the .plg file of the plugin owner. It is up to the plugin owner to perform a correct update of his plugin.

 

20 minutes ago, pwm said:

It really is irrelevant who have written the code - but down the line, installpkg should only be called if the package exists. And the contents of the previous package version should not be removed unless the system has the files for the new package

 

Currently .plg files are not really scrutinized and it depends upon the descretion of the plugin creator how well a plugin 'behaves'.

 

21 minutes ago, pwm said:

Does unRAID have a document showing the exact steps performed when a plugin is updated?

 

No official guide. @dlandon started a topic to explain more about the plugin system. It is a good starting point but not complete. Most plugin writers look at existing plugins and do a bit of reverse engineering to create their own. Agreed this is far from perfect, but the outcome of the best effort system we currently have.

 

[pwm]

It sounds like you are saying that /sbin/upgradepkg is generally not used when updating plugins.