How to handle .htaccess Invalid Hash on each Nextcloud Upgrade?
Devs, David, All, I've now gone though 3 Nextcloud updates since a fresh install 27.0.2* and having resolved all config notices/warnings in the "Administrator settings" "Overview" check. Every update there are a few changes to the /etc/webapps/nextcloud/.htaccess file that are provided in the .htaccess.pacnew file. Each time to remain current you incorporate anything new in the .htaccess.pacnew file with the config changes necessary for the Arch install detailed in the wiki. Additional changes are needed if you server your nextcloud install from a /nextcloud subdirectory. The problem is each time you modify /etc/webapps/nextcloud/.htaccess, nextcloud will flag the file with an Invalid Hash due to the changes. There is no simple occ command to tell nextcloud "Yes, I changed the .htaccess file it's fine". Instead, you have to go through an elaborate process to have nextcloud update the stored hash with: 1. upgrade as normal with pacman, 2. check and update /etc/webapps/nexcloud/.htaccess with additions in .htaccess.pacnew 3. occ upgrade 4. login and go to "Administrator settings". The "Overview" check will fail complaining about an Invalid Hash for the .htaccess file. 5. Edit /etc/webapps/nexcloud/config/config.php and add "'integrity.check.disabled' => true,", invoke the "Overview" check again, let it fail, choose the "Rescan" link. That will rescan the files updating the integrity hash for the .htaccess. 6. Log out/in and remove the "'integrity.check.disabled' => true," additiong to config.php (I haven't confirmed whether log in/out before removing the "'integrity.check.disabled' => true," is necessary. Rescan with the line set and then removing should be sufficient) Where should this config issue be handled, or is this just the routine you have to go through each there is a nextcloud update? It's not a nextcloud issue, the additions to the .htaccess that prevent using the .htaccess supplied are Arch specific. It's not a one-size-fits-all Arch issue either because the server can either be installed in the document root (as your only served app) or served out of the /nextcloud subdirectory existing alongside your other web offerings. But, the changes to .htaccess and the resulting [Invalid Hash] issue on upgrade are specifically Arch unique. Is this something that Arch could patch the "occ upgrade" script to handle? Or is this a "just the way it is" issue? Other than this one little nit, the nextcloud server upgrades are flawless. Thoughts? -- David C. Rankin, J.D.,P.E.
I use nextcloud with nginx rather than Apache, but is there something
preventing you from using the default htaccess and configuring what you
need on the webserver side instead?
Martin
On Fri, Oct 27, 2023, 22:30 David C. Rankin
Devs, David, All,
I've now gone though 3 Nextcloud updates since a fresh install 27.0.2* and having resolved all config notices/warnings in the "Administrator settings" "Overview" check.
Every update there are a few changes to the /etc/webapps/nextcloud/.htaccess file that are provided in the .htaccess.pacnew file. Each time to remain current you incorporate anything new in the .htaccess.pacnew file with the config changes necessary for the Arch install detailed in the wiki. Additional changes are needed if you server your nextcloud install from a /nextcloud subdirectory.
The problem is each time you modify /etc/webapps/nextcloud/.htaccess, nextcloud will flag the file with an Invalid Hash due to the changes. There is no simple occ command to tell nextcloud "Yes, I changed the .htaccess file it's fine". Instead, you have to go through an elaborate process to have nextcloud update the stored hash with:
1. upgrade as normal with pacman, 2. check and update /etc/webapps/nexcloud/.htaccess with additions in .htaccess.pacnew 3. occ upgrade 4. login and go to "Administrator settings". The "Overview" check will fail complaining about an Invalid Hash for the .htaccess file. 5. Edit /etc/webapps/nexcloud/config/config.php and add "'integrity.check.disabled' => true,", invoke the "Overview" check again, let it fail, choose the "Rescan" link. That will rescan the files updating the integrity hash for the .htaccess. 6. Log out/in and remove the "'integrity.check.disabled' => true," additiong to config.php
(I haven't confirmed whether log in/out before removing the "'integrity.check.disabled' => true," is necessary. Rescan with the line set and then removing should be sufficient)
Where should this config issue be handled, or is this just the routine you have to go through each there is a nextcloud update?
It's not a nextcloud issue, the additions to the .htaccess that prevent using the .htaccess supplied are Arch specific. It's not a one-size-fits-all Arch issue either because the server can either be installed in the document root (as your only served app) or served out of the /nextcloud subdirectory existing alongside your other web offerings. But, the changes to .htaccess and the resulting [Invalid Hash] issue on upgrade are specifically Arch unique.
Is this something that Arch could patch the "occ upgrade" script to handle? Or is this a "just the way it is" issue?
Other than this one little nit, the nextcloud server upgrades are flawless. Thoughts?
-- David C. Rankin, J.D.,P.E.
On 10/27/23 15:35, Martin Rys wrote:
I use nextcloud with nginx rather than Apache, but is there something preventing you from using the default htaccess and configuring what you need on the webserver side instead?
Yes, You customize the .htaccess as part of the install if you install to the /nextcloud subdirectory, e.g. RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav/ [R=301,L] RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav/ [R=301,L] And then arch includes the following at the end: #### DO NOT CHANGE ANYTHING ABOVE THIS LINE #### ErrorDocument 403 /nextcloud/index.php/error/403 ErrorDocument 404 /nextcloud/index.php/error/404 <IfModule mod_rewrite.c> Options -MultiViews RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1] RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1] RewriteCond %{REQUEST_FILENAME} !\.(css|js|mjs|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg|map|webm|mp4|mp3|ogg|wav|wasm|tflite)$ RewriteCond %{REQUEST_FILENAME} !/core/ajax/update\.php RewriteCond %{REQUEST_FILENAME} !/core/img/(favicon\.ico|manifest\.json)$ RewriteCond %{REQUEST_FILENAME} !/(cron|public|remote|status)\.php RewriteCond %{REQUEST_FILENAME} !/ocs/v(1|2)\.php RewriteCond %{REQUEST_FILENAME} !/robots\.txt RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/ RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.* RewriteCond %{REQUEST_FILENAME} !/richdocumentscode(_arm64)?/proxy.php$ RewriteRule . index.php [PT,E=PATH_INFO:$1] RewriteBase /nextcloud <IfModule mod_env.c> SetEnv front_controller_active true <IfModule mod_dir.c> DirectorySlash off </IfModule> </IfModule> </IfModule> Of course with install to /nextcloud, you have to change the entries above the line. -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C. Rankin
-
Martin Rys