Silent update

[lcsfox]

Hi,
As far as I understand, currently the update process for the LXCs is to run a command within the lxc's shell.
All good, working as exptected. But is there a way to automate this and possibly run the update command silenty without user interaction?
The problem is that when you have a lot of lxc container, you'll need to manually connect to each one, run the script, do some interaction etc.

[MickLesk]

It is not intended that containers and scripts update themselves, so you can open a back door for anyone at any time.

Scripts should only be updated by themselves, with interaction, to avoid any security problems.

If you want, build a script using the CT/LXC.sh and put it on the respective LXC, and create a crontab.

Please note that we do not provide support for such actions if scripts or updates are defective.

[lcsfox]

I think you misunderstood me.
I don't want the containers to update themselves.
Let me explain. For example I have vaultwarden lxc. If I want to update to the next version I need to log in to the container and execute the following (as for the VW example bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/vaultwarden.sh)")
Which is fine. All good.
I want to be able to push this command via ansible or cron or whatever, but when I do I get a user interaction

My question is whether is possible to run the update silenly and avoid clicking Yes, then select either vaultwarden or web-vault or a ny other option.

[MickLesk]

Not at the moment, but I'm also not a fan of big silent updates. We are also currently building in some error handling, which makes this almost impossible. (Memory check, RAM check, CPU check, and so on).

@havardthom @judeibe @Mellowlynx @remz1337 or what do you say?

[havardthom]

Some LXCs also have optional installs which you have to choose, hence the wording in Support/Update functions. I don't think we will be able to provide silent updates. Maybe you can simulate keypresses in your automation somehow.

[MickLesk]

Or maybe DEBIAN_FRONTEND=noninteractive

But not tested

[Mellowlynx]

You should not just auto-update.
Something can break and if you did not plan a backup right, or something fails when making one, you have no or old backup.
Sure, some services my not be critical, but I made it a habit to backup followed by the updates with me there.
To automate that, I made an Ansible playbook, that I will run, node by node. (Only after running a separate (pre-update-backup))

If you want to automate it, be my guest, but I don't think we should enable/support it in any way.

[lcsfox]

Updates can break no matter how you perform them - manual or automatic. I'm not saying auto-patch everything all the time, but
when you decide to patch and have a lot of lxcs you'll probably want to do it using some form of automation.

Currently the community-scripts site containts more than 100 lxc containers.They are growing rapidly. Consider majority of the users have around 5-10 lxc running, that means 5-10 lxc have to be pached manually. (I'm not referring to the OS patching, but the application running in the lxc - ex. gitea,vaultwarden etc, which cannot be patched using apt update or equivalent) - Ok. Not a big deal.
Now consider if a users has 100. How long do you need to patch all of them manually? Or you'll probably want to start a playbook and monitor if any errors occur?

Myself, personally I have a regular backup jobs of all VMs/LXCs and OS patching is done via ansible. I decide when to patch. When I do I just start a playbook and keep an eye on the progress. That beats manual labor every time. If something breaks, I log in, fix it or restore it and continue with my day.
But, as you all say, one can't apply that method currently, which I think will be a problem in the future.
Just food for thought.

[Mellowlynx]

That's also the point of a home-lab, tinker and find a solution that works for you.
The update and backup subject, is something you are responsible for and think about.
It's helper-script to get you started, but you should know a bit of what you are doing. (Especially if you have 100 LXC's running)
If we made something like this, I'm 1000% sure, people will blame us for providing a script that did not tell them X, so they lost Y.

It's like what I see at my work.
People that have a WordPress site, update is after like 4 years, and blame us, that it's not working anymore. (I did not change anything!)
Dude, it was running PHP 5.2, and you broke it because you did not think in what order to update, and also did not make a backup before starting.
Kicker is, they expect us to fix and update everything for... free.

It will be a hassle, but it's probably possible. But is something somewhere changes, or is switched to a different system whatever, it will most likely require us to update the script so it can update again. I don't think we should want that.

[danbayliss]

It's not silent or automated but you can run one command to update all LXC's
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/update-lxcs.sh)"

[MickLesk]

update-lxcs update only the OS (apt-get update/upgrade)

[JcMinarro]

I just received a GitHub email marking it as solved.
Do we have any alternative @MickLesk ??

[MickLesk]

There is something that I have roughly implemented - but it is not supported by us.

BassT23/Proxmox#191

[nz2o]

I would note that there are also risks of forgetting/not updating. The security risk of a compromised app from old code, and resulting data leakage, might outweigh accidentally breaking the actual app/service.

I certainly see the use case for automated scheduled updates. I have rationale.
A home lab is not an enterprise shop. You won't necessarily have a separate ops and change management team, nor would most individuals have the time to review each update/patch. Most people just run the update and when something happens, they then regress it.

On the other side of that coin, a home lab has to also be adequately secured. Maybe even more secure than enterprise, because in a home lab you've got varying security standards in each app, and most of them you do NOT want accessible from public. Thus, VPN, zero trust, tunnel being a real need, along with public facing things being closely managed/protected as well.

[MickLesk]

You have to look at it this way, 500,000 scripts were installed in 2 months. If we take half of the updates, that's 250,000 updates. I would say 60-70% of these have no backups or backup routine / snapshots.

What kind of hell do you think will break loose here if breaking changes to scripts are simply carried out automatically? It's like when you upgrade from Windows 10 to 11.

[nz2o]

Not here to pick a fight on this. I appreciate the fact that tteck's work was picked up for the community, and the help / legacy that this provided the home lab community.

What I'm saying here is simply a security-based opinion suggesting that it is sometimes better to have a breaking change, than to have a security breach. Key example: Vaultwarden. Not everyone configures that to best practices, from their VPN/proxy/auth layers

I get what you're saying, about functionality breaking changes. However it's not always the script's fault, it's sometimes upstream. You can't feasibly police the upstream app's maintainers/developers for breaking changes.... unless that's what's going on here. If it is, I appreciate the work you're doing on that front.

I would expect that the branch protections and code review would catch shenanigans, except if something is upstream going on.

What I'm proposing, is an option, nothing mandatory. An option for those of us who are confident in the specific LXC's / Software being installed, to call the script from elsewhere (such as from Cronicle), to execute an upgrade on a schedule.