Nextclount 29.0.2 update - /etc/webapps/nextcloud/.htaccess.pacnew missing Arch webapp config?
Devs, Nextcloud 29.0.2 update was released today and the /etc/webapps/.htaccess.pacnew config file is missing the entire config for the Archlinux webapp install. Applying the .htaccess.pacnew results in not being able to access the server with a forbidden error: [Thu Jun 06 20:58:10.130910 2024] [autoindex:error] [pid 17794] [client 192.168.6.104:52498] AH01276: Cannot serve directory /usr/share/webapps/nextcloud/apps/dashboard/: No matching DirectoryIndex (index.php,index.html) found, and server-generated directory index forbidden by Options directive The upper part is the same, but the lines from the bottom are removed: --- .htaccess.20240523 2024-06-06 20:55:04.132401657 -0500 +++ .htaccess.20240606 2024-06-06 08:57:25.000000000 -0500 @@ -108,29 +108,3 @@ AddDefaultCharset utf-8 Options -Indexes -#### 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|flac|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} !/(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> Restoring the .htaccess from the 5/23 update to 29.0.1 fixes the issue. Is this intended and are we supposed to reconfigure for this point release in some other way? https://wiki.archlinux.org/title/Nextcloud is silent and there was no install notice during the pacman update? If I'm supposed to reconfigure something and put the webapp config for Arch somewhere else, just let me know where. The nextcould forum isn't useful for the webapp install approach. -- David C. Rankin, J.D.,P.E.
Hi David, On 2024-06-06 21:18:14 (-0500), David C. Rankin wrote:
The upper part is the same, but the lines from the bottom are removed:
--- .htaccess.20240523 2024-06-06 20:55:04.132401657 -0500 +++ .htaccess.20240606 2024-06-06 08:57:25.000000000 -0500 @@ -108,29 +108,3 @@
AddDefaultCharset utf-8 Options -Indexes -#### 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|flac|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} !/(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>
IIRC, the above changes are something that nextcloud itself adds to the file during initial configuration. If you want to continue running nextcloud as before you will want to keep those lines. The `DO NOT CHANGE ANYTHING ABOVE THIS LINE` comment implies that anything above that line is vendor provided (coming from nextcloud upstream) though and should always be kept in sync with changes provided by updates. As an aside: This is why the /etc/webapps/nextcloud/.htaccess file is owned by the nextcloud user and /usr/share/webapps/nextcloud/.htaccess is a symlink to it. Similar to other files that are tracked in the context of the backup array [1] of a package you are expected to adapt the file accordingly (this has been the case for many nextcloud versions already) and not necessarily apply all changes provided by the updated file (this is also the case for other packages FWIW, as you often want to keep your specific modifications). I hope this clears things up. Best, David [1] https://wiki.archlinux.org/title/PKGBUILD#backup -- https://sleepmap.de
On 6/7/24 03:44, David Runge wrote:
IIRC, the above changes are something that nextcloud itself adds to the file during initial configuration. If you want to continue running nextcloud as before you will want to keep those lines. The `DO NOT CHANGE ANYTHING ABOVE THIS LINE` comment implies that anything above that line is vendor provided (coming from nextcloud upstream) though and should always be kept in sync with changes provided by updates.
As an aside: This is why the/etc/webapps/nextcloud/.htaccess file is owned by the nextcloud user and/usr/share/webapps/nextcloud/.htaccess is a symlink to it.
Similar to other files that are tracked in the context of the backup array [1] of a package you are expected to adapt the file accordingly (this has been the case for many nextcloud versions already) and not necessarily apply all changes provided by the updated file (this is also the case for other packages FWIW, as you often want to keep your specific modifications).
I hope this clears things up.
It does and that it kind of what I thought. The diff output shows the top (upstream provided) part of .htaccess is still identical. What was strange is that the Arch config seems to come and go at times in the .htaccess.pacnew file. The way I do it when I get a nextclound .htaccess.pacnew is I rename it .htaccess.yyyymmdd with the current date and then use a symlink to switch to the new once after I compare changes. But this time I noticed the .htaccess had lost about 1K of text. It had done that before as well, e.g.: lrwxrwxrwx 1 root root 18 Jun 6 20:58 .htaccess -> .htaccess.20240523 -rw-r--r-- 1 nextcloud nextcloud 4367 Oct 5 2023 .htaccess.20231005 -rw-r--r-- 1 nextcloud nextcloud 4391 Feb 1 20:23 .htaccess.20231027 -rw-r--r-- 1 nextcloud nextcloud 3993 Feb 29 11:20 .htaccess.20240301 -rw-r--r-- 1 nextcloud nextcloud 5188 May 20 14:22 .htaccess.20240520 -rw-r--r-- 1 nextcloud nextcloud 5149 Jun 6 21:32 .htaccess.20240523 -rw-r--r-- 1 nextcloud nextcloud 5188 May 20 14:22 .htaccess.20240523.old -rw-r--r-- 1 nextcloud nextcloud 3954 Jun 6 08:57 .htaccess.20240606 Above you can see the March 1 .htaccess had lost about the same ~1K bytes as the June 6 .htaccess did. I know I've scratched my head on this before, but I don't know if I ever got to the bottom of the atavistic text. Either way, the text not being in the new .htaccess kills the server dead when installed to /docroot/nextcloud I'll investigate further. -- David C. Rankin, J.D.,P.E.
On 2024-06-07 04:07:00 (-0500), David C. Rankin wrote:
It does and that it kind of what I thought. The diff output shows the top (upstream provided) part of .htaccess is still identical. What was strange is that the Arch config seems to come and go at times in the .htaccess.pacnew file.
The way I do it when I get a nextclound .htaccess.pacnew is I rename it .htaccess.yyyymmdd with the current date and then use a symlink to switch to the new once after I compare changes. But this time I noticed the .htaccess had lost about 1K of text. It had done that before as well, e.g.:
That might already be part of the problem (assuming that you are referring to /etc/webapps/nextcloud/.htaccess) as that file is owned by the nextcloud package. Why not just use pacdiff (pacman-contrib) after upgrade and then remove the .pacnew file? Your setup (to me) sounds quite confusing and potentially error-prone. Best, David -- https://sleepmap.de
participants (2)
-
David C. Rankin
-
David Runge