[Plugin] CA Application Auto Update


Squid

Recommended Posts

  • 4 weeks later...

I've noticed when the update notification pop up (and in my email), the version of the app isn't displayed. Is this something I can enable on my end?

 

The notice/email will come up with something like: Version update 24cd..b6da (I'm assuming it's the container it's referencing?)

Link to comment
5 hours ago, God_TM said:

I've noticed when the update notification pop up (and in my email), the version of the app isn't displayed. Is this something I can enable on my end?

 

The notice/email will come up with something like: Version update 24cd..b6da (I'm assuming it's the container it's referencing?)

I'll add it to a todo list

  • Like 1
Link to comment
  • 2 weeks later...

Hi there,

 

I'm having trouble finding out why my Dockers are updated. I have the auto-update app installed but I disable the Update Check Frequency. The strange thing tho is that the notification has Community Applications in its title. Is there some Community Applications update function I missed to disable?

Screenshot 2021-10-24 at 16.41.39.png

Link to comment
On 11/6/2021 at 4:53 PM, Squid said:

What's the contents of /config/plugins/ca.update.applications/DockerUpdateSettings.json on the flash drive?

{
    "cron": {
        "dockerCronFrequency": "Monthly",
        "dockerCronDay": "0",
        "dockerCronDayOfMonth": "1",
        "dockerCronHour": "0",
        "dockerCronMinute": "0",
        "dockerCronCustom": ""
    },
    "containers": {
        "AdGuard-Home": {
            "name": "AdGuard-Home",
            "update": true
        },
        "ClamAV": {
            "name": "ClamAV",
            "update": true
        },
        "CloudBerryBackup": {
            "name": "CloudBerryBackup",
            "update": true
        },
        "DiskSpeed": {
            "name": "DiskSpeed",
            "update": true
        },
        "HDDTemp": {
            "name": "HDDTemp",
            "update": true
        },
        "phpmyadmin": {
            "name": "phpmyadmin",
            "update": true
        },
        "Unraid-API": {
            "name": "Unraid-API",
            "update": true
        },
        "vm_custom_icons": {
            "name": "vm_custom_icons",
            "update": true
        },
        "FileBrowser": {
            "name": "FileBrowser",
            "update": true
        },
        "QDirStat": {
            "name": "QDirStat",
            "update": true
        },
        "NginxProxyManager": {
            "name": "NginxProxyManager",
            "update": true
        },
        "organizrv2": {
            "name": "organizrv2",
            "update": true
        },
        "Portainer-CE": {
            "name": "Portainer-CE",
            "update": true
        },
        "bazarr": {
            "name": "bazarr",
            "update": true
        },
        "ombi": {
            "name": "ombi",
            "update": true
        },
        "prowlarr": {
            "name": "prowlarr",
            "update": true
        },
        "overseerr": {
            "name": "overseerr",
            "update": true
        },
        "plex": {
            "name": "plex",
            "update": true
        },
        "sonarr": {
            "name": "sonarr",
            "update": true
        },
        "vaultwarden": {
            "name": "vaultwarden",
            "update": true
        },
        "grocy": {
            "name": "grocy",
            "update": true
        },
        "nzbget": {
            "name": "nzbget",
            "update": true
        },
        "pgadmin4": {
            "name": "pgadmin4",
            "update": true
        },
        "calibre": {
            "name": "calibre",
            "update": true
        },
        "Minio": {
            "name": "Minio",
            "update": true
        },
        "radarr": {
            "name": "radarr",
            "update": true
        },
        "readarr": {
            "name": "readarr",
            "update": true
        }
    },
    "global": {
        "dockerNotify": "yes",
        "dockerStopDelay": "10",
        "dockerUpdateAll": "no"
    }
}

 

Link to comment
  • 2 weeks later...

Hi @Squid/Community,

 

I have a few questions regarding both CA Update and CA Backup. Apologies if these are answered elsewhere;

 

For CA Update, how does the delay work? If I have the "check" set to every Monday morning at 4am, and a delay of, lets say 3 days, does it then update Thursday morning at 4am? Would that mean that if I wanted everything to stay 1 week behind, I would set the delay to 7? Meaning every Monday at 4am, it installs last weeks updates that were delayed by 7 days?

 

I know that CA Backup can tell CA Update to run after a backup. If I only want to update my Dockers after a backup, would I look to disable "update check frequency" within docker update settings? Or will this disable the plugin entirely? What about for plugin updates? If I have the delay set but "update check frequency" disabled, does that mean that it will check for updates ONLY after set in motion by CA Backup, and delay accordingly?

 

When does "Delete backups if they are this many days old" occur? If I have it set to 30 days, does it delete as soon as the age of the file hits 30 days, or does it delete the next time CA Backup runs and sees the file is 30 days or older?

 

My end goal here is that I would like CA Backup to run every Monday morning at 4am. After the backup, I want plugins to update the 7 day delayed updates from last week, and want all dockers updated. Does this make sense and am I understanding everything correctly?

 

Thanks for your help!

 

-Ryan

 

Edited by Bulletoverload
Wording
Link to comment

A quick query.  I have a number of dockers that use the network of a Privoxy VPN container using the '--net=container' extra parameter.  When CA Auto Update updates the VPN container, this knocks out all the dependant containers which then need a manual restart.  Is there any way of configuring CA Auto Update to restart specific other containers when a container is updated.  So, if container A is updated, also restart containers B, C & D?

 

Thanks.

Link to comment
  • 4 weeks later...

Hi,

 

I have a script creating temporary containers (docker --rm), and as expected they show in unraid while they run then they go away.

 

Somehow the plug-in remembers them, they keep showing in the auto update tab for containers even though they're not in the docker tab, and not in the output of docker ps -a.

 

Is there a way to clean that up ? Without rebooting, of course, I don't want to reboot every day.

Not causing any issues but I imagine this means they stay stored somewhere indefinitely, and over years I'll be creating thousands of those automatically so I'd like to have that working cleanly.

 

Thanks

Link to comment
20 hours ago, Squid said:

are they there in advanced view?

 Hadn't thought of that, but no they are not

 

EDIT: they're gone from the auto update plug-in view as well this morning, nevermind. I had a power cut yesterday so this all got reset.

 

I'll update back in a few days once some more containers have run.

Edited by Ulrar
Link to comment
  • 3 weeks later...

My dockers don't seem to have been auto-updated for a while, on the docker list, they're all showing "apply update". 

I went into the auto-update docker settings, and "update all docker applications" is set to yes.

 

I set that to no, then the dockers are shown, and they're all set to dont update. 

 

Does the "update all docker applications" over-ride the individual settings when set to 'yes'?  It doesn't appear to.

 

 

Edited by jj_uk
Link to comment

The logs show this, which suggests it updated last night, but it didn't. I updated PiHole eariler today manually, and the other 2 dockers are still showing updates avaliable.

 

Quote

Jan 2 00:15:10 microserver1 Docker Auto Update: Stopping pihole-template
Jan 2 00:15:14 microserver1 kernel: device br0 left promiscuous mode
Jan 2 00:15:14 microserver1 kernel: veth69c1078: renamed from eth0
Jan 2 00:15:16 microserver1 Docker Auto Update: Installing Updates for duplicati Minio pihole-template
Jan 2 00:15:56 microserver1 Docker Auto Update: Restarting Minio
Jan 2 00:15:56 microserver1 kernel: docker0: port 1(veth5960ab5) entered blocking state
Jan 2 00:15:56 microserver1 kernel: docker0: port 1(veth5960ab5) entered disabled state
Jan 2 00:15:56 microserver1 kernel: device veth5960ab5 entered promiscuous mode
Jan 2 00:15:59 microserver1 kernel: eth0: renamed from vethc9a3248
Jan 2 00:15:59 microserver1 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth5960ab5: link becomes ready
Jan 2 00:15:59 microserver1 kernel: docker0: port 1(veth5960ab5) entered blocking state
Jan 2 00:15:59 microserver1 kernel: docker0: port 1(veth5960ab5) entered forwarding state
Jan 2 00:16:01 microserver1 avahi-daemon[4270]: Joining mDNS multicast group on interface veth5960ab5.IPv6 with address fe80::e4de:52ff:feee:716d.
Jan 2 00:16:01 microserver1 avahi-daemon[4270]: New relevant interface veth5960ab5.IPv6 for mDNS.
Jan 2 00:16:01 microserver1 avahi-daemon[4270]: Registering new address record for fe80::e4de:52ff:feee:716d on veth5960ab5.*.
Jan 2 00:16:02 microserver1 Docker Auto Update: Restarting pihole-template
Jan 2 00:16:05 microserver1 kernel: eth0: renamed from veth5c3ad1e
Jan 2 00:16:05 microserver1 kernel: device br0 entered promiscuous mode
Jan 2 00:16:08 microserver1 Docker Auto Update: Community Applications Docker Autoupdate finished

 

 

image.thumb.png.6a7c487dd1623656bfe590614337c754.png

Link to comment
  • 2 weeks later...

EDIT: This was a Gluetun template issue which has now been fixed, please ignore.

CA Auto Update broke my setup a bit today. I had a VPN docker (GluetunVPN) set up that a couple other dockers run through (--net=container:GluetunVPN) , and when the VPN was auto-updated this morning it broke/removed the Gluetun install, which left a few other dockers stuck in a perpetual "rebuilding" stage looking for the VPN to route through.

 

This has never been an issue manually clicking update on Gluetun, but this was the first time it auto updated via the plugin. I've attached diagnostics file.

 

Edited by Seltonu
Solved
Link to comment

A CA auto-update problem I've found that I actually noted in my previous comment, is when a container is updated that other dockers rely on for networking, the reliant containers stay down until manually visiting the docker tab which triggers a rebuild.

Example / Steps to reproduce:

  1. GluetunVPN is a frequently updated VPN docker to router other dockers through. Setup with VPN info.
  2. qbittorrent is an example docker to route through GluetunVPN (Extra parameters: --net=container:GluetunVPN)
  3. Using CA auto-update, wait for GluetunVPN to update (every ~2-3 days).
  4. After update, qbittorrent docker is down until manually visiting the docker tab. When at docker tab, any routed containers will automatically trigger a "rebuilding" state and go back up.

Expected behavior:

  • Any "child" docker containers routing their network through a "parent" docker container will automatically trigger rebuilds after the "parent" is auto-updated from CA auto update.

This is especially frustrating because of how often some "parent" containers like GluetunVPN push updates, thus needing to manually visit the docker tab every 2-3 days to trigger the rebuild CA auto update didn't.

Link to comment
9 hours ago, Seltonu said:

Any "child" docker containers routing their network through a "parent" docker container will automatically trigger rebuilds after the "parent" is auto-updated from CA auto update.

A bit much to expect this plugin to detect and compensate for.  Setting those particular apps to not auto update and manually doing it is what you'd want to do.

Link to comment
22 hours ago, Squid said:

A bit much to expect this plugin to detect and compensate for.  Setting those particular apps to not auto update and manually doing it is what you'd want to do.

Ah my bad, this is my first time using dockers for anything so I didn't realize it may not be a simple fix/implementation. I've set it to not auto-update as you and wgstarks suggested, this is an easy compromise for one docker. Thank you!

Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.