Read/Write DB User In Distributed Installation - vs. Upgrades
I have my backoffice running on a different server than my website.
For the backoffice I use a sql user that has read/write permission to the db.
For the public facing website I had been using a sql user that only has read permission on the db.
Today I upgraded from one umbraco version to the next and maybe my unattended upgrade was kicked off by the public site instead of the backoffice instance and I got an error on the public site complaining that my sql user didn't have write access to the "umbracoLock" table.
Maybe my solution should be to disable unattended upgrades on the public website so that the backoffice is the only server that can kick those off. Does that sound like the correct approach?
Yes, disabling unattended upgrades on the public-facing website is indeed the correct approach in this scenario. When your public-facing site uses a SQL user with only read access, it prevents it from performing write operations, such as those required during an upgrade. By default, unattended upgrades are enabled in Umbraco, which could cause issues if triggered by a server or environment with restricted database permissions.
Here’s what you need to do:
Test the Upgrade in a Safe Environment:
Ensure the upgrade won’t break the site by testing it in a local or QA
environment first.
Disable Unattended Upgrades on the Public-Facing Site:
Options for disable in appsettings.{env}.json/Env variables to disable unattended upgrades, please check this doc
Update the DLLs and Dependencies:
Update the DLLs, all associated dependencies, and any required files on both the backoffice and public-facing site instances.
Run the Backoffice Site First:
Start the backoffice site and wait for it to complete booting and apply any database updates.
Restart the Public-Facing Site:
Once the backoffice upgrade is complete, restart the public-facing site to ensure it aligns with the updated codebase and database schema.
Thanks for the detailed reply, Dhanesh. Good to know how it should be done. I'll make those changes and hopefully things will go more smoothly next time.
Hello everyone,
I have a follow-up question: Is there a way to automate the process of ensuring that unattended upgrades only happen on the backoffice server, especially in a multi-server setup? I want to avoid manual intervention every time an upgrade is triggered. Any recommendations?
Just noticed in that document it asks for a configured username/password for the upgrades. I believe my upgrades have been running even without those. Can anyone opine on why that has been working for me?
It’s not mandatory to configure the unattended username, email, or password. These settings are primarily used to create a default admin user in the backend during the unattended setup process. If your upgrades are running without these configurations, it’s because they’re not required for the upgrade itself but only for initializing an admin user when needed.
Read/Write DB User In Distributed Installation - vs. Upgrades
I have my backoffice running on a different server than my website. For the backoffice I use a sql user that has read/write permission to the db. For the public facing website I had been using a sql user that only has read permission on the db.
Today I upgraded from one umbraco version to the next and maybe my unattended upgrade was kicked off by the public site instead of the backoffice instance and I got an error on the public site complaining that my sql user didn't have write access to the "umbracoLock" table.
Maybe my solution should be to disable unattended upgrades on the public website so that the backoffice is the only server that can kick those off. Does that sound like the correct approach?
Hi npack,
Yes, disabling unattended upgrades on the public-facing website is indeed the correct approach in this scenario. When your public-facing site uses a SQL user with only read access, it prevents it from performing write operations, such as those required during an upgrade. By default, unattended upgrades are enabled in Umbraco, which could cause issues if triggered by a server or environment with restricted database permissions.
Here’s what you need to do:
Test the Upgrade in a Safe Environment: Ensure the upgrade won’t break the site by testing it in a local or QA environment first.
Disable Unattended Upgrades on the Public-Facing Site: Options for disable in appsettings.{env}.json/Env variables to disable unattended upgrades, please check this doc
Update the DLLs and Dependencies: Update the DLLs, all associated dependencies, and any required files on both the backoffice and public-facing site instances.
Run the Backoffice Site First: Start the backoffice site and wait for it to complete booting and apply any database updates.
Restart the Public-Facing Site: Once the backoffice upgrade is complete, restart the public-facing site to ensure it aligns with the updated codebase and database schema.
Doc for reference: https://docs.umbraco.com/umbraco-cms/fundamentals/setup/upgrading
Regards,
Dhanesh
Thanks for the detailed reply, Dhanesh. Good to know how it should be done. I'll make those changes and hopefully things will go more smoothly next time.
Cheers
Hello everyone, I have a follow-up question: Is there a way to automate the process of ensuring that unattended upgrades only happen on the backoffice server, especially in a multi-server setup? I want to avoid manual intervention every time an upgrade is triggered. Any recommendations?
Well, I think setting unattended upgrades to true on the appconfig of the backoffice server is what you need to do.
https://docs.umbraco.com/umbraco-cms/reference/configuration/unattendedsettings
Just noticed in that document it asks for a configured username/password for the upgrades. I believe my upgrades have been running even without those. Can anyone opine on why that has been working for me?
Hi npack,
It’s not mandatory to configure the unattended username, email, or password. These settings are primarily used to create a default admin user in the backend during the unattended setup process. If your upgrades are running without these configurations, it’s because they’re not required for the upgrade itself but only for initializing an admin user when needed.
is working on a reply...