Hello,

I have added some post arguments to my Nextcloud-Docker.

&& docker exec -u 0 Nextcloud /bin/sh -c 'echo "umask 000" >> /etc/apache2/envvars' && docker exec -u 0 Nextcloud /bin/bash -c "apt update && apt install -y libmagickcore-6.q16-6-extra && apt install -y smbclient libsmbclient-dev && pecl install smbclient && docker-php-ext-enable smbclient".

 

When the container is updated manually, the post arguments are applied.
But when the container updates automatically with the "CA Auto Update Applications" plugin, the post arguments are not applied.

 

What is the reason for this and how can I ensure that the post arguments are reliably executed?

That would be a challenge since those aren't aren't post arguments but rather additional commands you're executing via the docker run command when it's being created initially

 

I would add a custom start script as /boot/config/plugins/ca.update.applications/scripts/starting/Nextcloud

 

Where Nextcloud is the name of the container exactly.

Thanks for all your work on this essential plugin (and your many others)! Just a few questions...

On 3/18/2017 at 1:41 PM, Squid said:

Added.  Details in the CA manual (Auto Update Applications / Docker Advanced Control)

Advanced Docker Control
Optionally, CA Auto Update supports running custom stop and start scripts for docker applications. These scripts will be executed prior to stopping an application and after starting an application.

To use this feature, create the following file(s) on your flash drive: (They are executed in order if they exist)


/boot/config/plugins/ca.update.applications/scripts/stopping/stop_all	This script will be executed whenever any docker application is being updated (prior to updating)
/boot/config/plugins/ca.update.applications/scripts/stopping/{nameOfContainer}	This script will be executed whenever {nameOfContainer} is being updated (prior to updating)
/boot/config/plugins/ca.update.applications/scripts/starting/{nameOfContainer}	This script will be executed whenever {nameOfContainer} has been updated
/boot/config/plugins/ca.update.applications/scripts/starting/start_all	This script will be executed whenever any container has been updated

What user are the start and stop scripts executed as? Based on the source code, it looks like they must be invoked as root since the /boot/config/plugins/ca.update.applications/scripts directory has mode 600 and is owned by root.

  if ( is_file("/boot/config/plugins/ca.update.applications/scripts/starting/$containerScript") ) {
    logger("Executing custom start script /boot/config/plugins/ca.update.applications/scripts/starting/$containerScript");
    exec("/bin/bash /boot/config/plugins/ca.update.applications/scripts/starting/$containerScript");
  }

Also, could you provide a link to the CA manual referenced in the quote above?

6 minutes ago, pants said:

What user are the start and stop scripts executed as? Based on the source code, it looks like they must be invoked as root since the /boot/config/plugins/ca.update.applications/scripts directory has mode 600 and is owned by root.

Everything in Unraid always executes as root

 

6 minutes ago, pants said:

Also, could you provide a link to the CA manual referenced in the quote above?

That quote is the documentation.  The "CA Manual" was originally included as part of CA itself, but due to changes in CA's skin it was no longer particularly feasible to accomplish

This is how my time is synced

 

 

But the updates happens at 4am and not at 1 am

 

 

Any idea why?

Plugin updates are happening at 1AM according to that snip.  Docker updates are happening at 4am.  There's a separate setting for them under Docker Auto Update Setting.

What causes this?

 

Message sent by email:

Subject: cron for user root /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >dev/null 2>&1 /bin/sh: line 1: dev/null: No such file or directory

 

Should that be '/dev/null'?

Edited November 3, 20223 yr by PeterB

That was a bug from years ago.  Make a change to to plugin update settings and reapply.

45 minutes ago, Squid said:

That was a bug from years ago.

 

Strange that this is the first time I've seen it!

 

Version 2021.09.24  running.

On 9/1/2022 at 11:51 PM, kizer said:

 

Easy go into your Dockers tab for this plugin. Disable auto updates for all and then manually check each docker and not Homeassistant so you can update that particular one when you want, but all others will be updated. 

 

Its the same thing I do. I have a VPN running with a killswitch to some of my dockers. When it updates it sometimes wrecks my connections to my other dockers. So I update all my other dockers and I manually update my VPN so I know to gracefully shut everything else down, update and restart my other dockers.  Same with the MyServer Plugin. I have that disabled as well because I've lost all outside connections before. So now I only update that one when I'm home. 

 

You just have to remember to enable/disable future Dockers or Plugins if you turn off the all update feature. This solution isn't perfect for HomeAssistant, but at least you have more control.

 

Funny to get a reply to this so many months later. That's what I was doing, but I wanted to get minor revisions automatically because I spent way too much time flipping through the webgui of my server looking for routine maintenance to do. I want to tinker with the services I'm running, not the server they're running on.

 

No one really seemed to care as the immediate reply was from a user who clearly didn't read what I wrote, and I got nothing else until this. Which (no offense) isn't what I asked either.

 

I've since solved the problem on my own, in a way that I will not specify as multiple users will undoubtedly descend to tell me how wrong I'm using Unraid even though I paid for it and I can do what I like.

 

Cheers!

18 hours ago, Renegade605 said:

 

Funny to get a reply to this so many months later. That's what I was doing, but I wanted to get minor revisions automatically because I spent way too much time flipping through the webgui of my server looking for routine maintenance to do. I want to tinker with the services I'm running, not the server they're running on.

 

No one really seemed to care as the immediate reply was from a user who clearly didn't read what I wrote, and I got nothing else until this. Which (no offense) isn't what I asked either.

 

I've since solved the problem on my own, in a way that I will not specify as multiple users will undoubtedly descend to tell me how wrong I'm using Unraid even though I paid for it and I can do what I like.

 

Cheers!

 

AMEN!!!! It's yours and I would do like you want no matter what anybody tells you.

I often just give in sometimes and take the path of least resistance.  I don't want my VPN to update and crash all my stuff so I make sure I check it now and then and let the rest do its thing, but I totally get your doing something a tad different. 

Hello,

 

thank you for this great plugin. Currently I have in the settings the possibility to select all or selectively which plugin or docker container should be updated, only I would like if there would be a kind of blacklist.
Then you could select only those that should not be updated, so which should be excluded.

 

greetings

Edited December 14, 20223 yr by DjSni

Isn't that the same thing?

1 hour ago, Squid said:

Isn't that the same thing?

 

Hello, not quite so you can more easily exclude only a few from autoupdate mechanism and all new ones are also updated automatically.
Greetings

I'm having a problem where an old Docker container comes back after the auto update is done.

I had a "boinc" container (lower case B) but was having problems with it so I deleted and added a different one called "Boinc" (upper case B).

I see a single container called "Boinc" until the updater runs on Wednesday's, then I see the other older "boinc" container has returned. I delete the "boinc" instance again, and I'm good until the following Wednesday. I also tried deleting them both and loading back the new one, Boinc.

In looking at the settings of this plugin, if I change the option to update all to No, I can see a list of containers with a toggle to turn on autoupdate. I can see the old "boinc" container in this list.

 

Is this a Docker problem I'm having or a plugin issue? Any ideas on how to make the deletion of the old "boinc" container permanent?

I can't see it OTOH being plugin issue as it simply reports what the OS says is installed...  Maybe recreate the docker image?

I think I got it.

I deleted the container again, deleted its appdata, then deleted its template.

I had it run again this morning and the old "boinc" container didn't come back this time.

I put the updater's settings back to the normal day for the backup(Wed) so we'll see what happens.

Oh well, so much for that idea. The extra boinc container came back again after this morning's run of the backup.

I'll research and try recreating the Docker image. Hope I don't screw it up.

Hi everyone. I have a weird problem with this plugin. I’ll receive notifications that many containers have been updated. Shortly thereafter I receive a notification from the Fix Common Problems plugin that those same containers need updated. Then if I bring up the dashboard none of the containers were actually updated. The plug-in is definitely running as I see that many of the containers were restarted.
 

If I manually updated each one via the dashboard they update without a problem. 
 

Any idea what could be happening?

On 12/28/2022 at 10:00 AM, nraygun said:

Oh well, so much for that idea. The extra boinc container came back again after this morning's run of the backup.

I'll research and try recreating the Docker image. Hope I don't screw it up.

I recreated the Docker image and this morning's run of the auto update made the other "boinc" come back. And neither boinc was updated in the process - only 2 other containers were updated.

Any other ideas on where to look to find why this container keeps coming back?

Edited January 4, 20233 yr by nraygun

On 11/20/2022 at 4:16 PM, Renegade605 said:

 

Funny to get a reply to this so many months later. That's what I was doing, but I wanted to get minor revisions automatically because I spent way too much time flipping through the webgui of my server looking for routine maintenance to do. I want to tinker with the services I'm running, not the server they're running on.

 

No one really seemed to care as the immediate reply was from a user who clearly didn't read what I wrote, and I got nothing else until this. Which (no offense) isn't what I asked either.

 

I've since solved the problem on my own, in a way that I will not specify as multiple users will undoubtedly descend to tell me how wrong I'm using Unraid even though I paid for it and I can do what I like.

 

Cheers!

Found your posts while searching for a method to do, literally, the exact same thing. Recently had one update cripple my smart plugs, and another render my 3D printer unusable. If you won't share how you solved the same issue, can you at least give me a hint where I should start looking?

I could not give any less of a shit as to whether your method is the "intended" way to use Unraid. If it works, and does not open a gaping security vulnerability, who tf cares.

Thanks in advance for any help you can offer.

On 1/4/2023 at 9:14 AM, nraygun said:

I recreated the Docker image and this morning's run of the auto update made the other "boinc" come back. And neither boinc was updated in the process - only 2 other containers were updated.

Any other ideas on where to look to find why this container keeps coming back?

Could swear I had posted an update. Anyway...

I deleted both Boinc and boinc containers, deleted their appdata, and deleted their template. The updater ran a few times without either Boinc/boinc's coming back.

I then re-added Boinc and the updated ran without adding back boinc. So far, so good.

I just want to see what happens when there is a Boinc update. If it goes through without adding boinc, I think I'll be good to go.

 

 

I have a custom Backup script running that stops all docker containers before backing up appdata. 
May it be possible to trigger the auto update from this script right before I start docker again?

On 1/9/2023 at 8:08 AM, greenmojo said:

Found your posts while searching for a method to do, literally, the exact same thing. Recently had one update cripple my smart plugs, and another render my 3D printer unusable. If you won't share how you solved the same issue, can you at least give me a hint where I should start looking?

I could not give any less of a shit as to whether your method is the "intended" way to use Unraid. If it works, and does not open a gaping security vulnerability, who tf cares.

Thanks in advance for any help you can offer.

I've sent you a direct message.

Been receiving these " Plugin run failed" entries in my system log. Everything seems to be working, but seems to be related to auto update? It shows for every plugin, every time it runs. Not sure what to do?

 

Quote

Jan 17 05:00:04 Backup Plugin Auto Update: plugin: updating: dynamix.file.manager.plg
Jan 17 05:00:04 Backup Plugin Auto Update: Executing hook script: pre_plugin_checks
Jan 17 05:00:04 Backup Plugin Auto Update: plugin: run failed: /bin/bash
Jan 17 05:00:04 Backup Plugin Auto Update: Executing hook script: post_plugin_checks