Admins

Loïc suggère de faire un nettoyage via la commande occ.

Sur la liste Nextcloudfr, le 07/04/2020, Thomas MICHEL <thomas@lydra.fr> a écris :

j'espère que tu as accès en console au serveur, sinon ça risque d'être
difficile...

1. tu mets ton serveur en maintenance :
# sudo -u www-data php -f ./occ maintenance:mode --on

2. tu vides la table de cache :
# mysql
MariaDB [(none)]> use cloudDatase;
MariaDB [(none)]> delete from oc_file_locks where 1;
MariaDB [(none)]> exit

3. tu quittes le mode maintenance
# sudo -u www-data php -f ./occ maintenance:mode --off

4. tu lances un scan des fichiers (attention ! c'est long. Lances le
dans un screen ou tmux)
# sudo -u www-data php -f ./occ files:scan --all

5. tu lances un nettoyage de la base
# sudo -u www-data php -f ./occ files:cleanup

6. tu forces la resynchronisation chez tes abonnés
# sudo -u www-data php -f ./occ maintenance:data-fingerprint

Je ne sais pas si toutes ces étapes sont essentielles, mais en cas de
gros pépins, c'est ceinture et bretelles 

J'ignore si cette procédure est bonne. Peut-être voir dans la documentation officielle.

L'avis de LaurentP sur cette procédure :

cette procédure sert essentiellement à remettre le cache fichiers d'équerre, ce qui peut se faire avec occ scan simplement.

Test avec le fichier https://media.april.org/audio/radio-cause-commune/libre-a-vous/emissions/20200428/libre-a-vous-20200428.ogg (89 Mo) :

- fichier récupéré sur mon laptop

- upload sur https://valise.april.org/libre-a-vous via le navigateur web (en mode non connecté, donc sans compte)

- upload ok

- download du fichier, fichier identique à celui uploadé

Test ok.

Test fait avec un fichier de 240 Mo, test ok aussi.

Test fait avec un fichier de 900 Mo (correspondant à la taille d'un fichier audio Libre à vous ! enregistré par le serveur de la régie). Erreur à la fin et fichier non téléversé, message d'erreur « Expected filesize of 952769860 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 897744896 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. ».

Question donc : quelle est la limite de taille pour le téléversement d'un fichier ?

Au vu de https://agir.april.org/issues/4153#note-5 la config nginx avait été passé à 512Mo pour client_max_body_size. Mais sur bastion@ dans /etc/nginx/conf.d/local.conf il y a client_max_body_size 1024m;

Donc, la limite serait 1Go, mais je n'ai pas pu téléversé un fichier de 900 Mo. Une limitation sur lamp ?

Frédéric Couchet a écrit :

Au vu de https://agir.april.org/issues/4153#note-5 la config nginx avait été passé à 512Mo
pour client_max_body_size. Mais sur bastion@ dans /etc/nginx/conf.d/local.conf il y a client_max_body_size 1024m;
Donc, la limite serait 1Go, mais je n'ai pas pu téléversé un fichier de 900 Mo. Une limitation sur lamp ?

Alors oui, mais non :D La stratégie de téléversement a changé dans Nextcloud au cours des dernières versions.
Le ticket #4153 concernait l'ancienne stratégie qui consistait à téléverser les fichiers en une seule requête, d'où d'éventuels problèmes de timeout ou de dépassement de limites.
À l'époque, la solution avait été d'augmenter la taille maximale de téléversement dans une requête.

Depuis, Nextcloud utilise une nouvelle stratégie qui consiste à, côté client en Javascript, découper le fichier en morceaux de ~10 Mo et à faire une requête de téléversement par morceau.
Une fois tous les morceaux envoyés, une requête donne l'ordre de tout réassembler puis de déplacer dans le bon dossier.

Dans les logs sur la vm lamp, ça donne ça avec un fichier de 47 Mo :

91.160.XX.XX - - [07/May/2020:23:51:43 +0200] "MKCOL /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120 HTTP/1.0" 201 605 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:44 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/0 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:46 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/10485760 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:48 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/20971520 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:51 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/31457280 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:54 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/41943040 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:51:59 +0200] "MOVE /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/.file HTTP/1.0" 201 747 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "GET /index.php/apps/files/ajax/getstoragestats.php HTTP/1.0" 200 983 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "PROPFIND /remote.php/dav/files/cpm/Tests/Stratium-FranceInter-20190509-ITEMA_22057169-1.mp3 HTTP/1.0" 207 1924 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 
91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "GET /index.php/core/preview?fileId=5975&c=08d2830c827806ece81783cb40374ad8&x=250&y=250&forceIcon=0 HTTP/1.0" 200 24750 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 

On voit bien la suite de « PUT » dans un dossier temporaire et le « MOVE » qui déclenche la reconstitution et le déplacement dans le dossier cible.

Avec cette nouvelle stratégie, plus de problème de timeout ou de dépassement de limite puisque 10 Mo vont plutôt vite à téléverser et que c'est bien en dessous de toute limite raisonnable.

Frédéric Couchet a écrit :

Test fait avec un fichier de 900 Mo (correspondant à la taille d'un fichier audio Libre à vous ! enregistré par le serveur de la régie).
Erreur à la fin et fichier non téléversé, message d'erreur « Expected filesize of 952769860 bytes but read (from Nextcloud client)
and wrote (to Nextcloud storage) 897744896 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. ».

Question donc : quelle est la limite de taille pour le téléversement d'un fichier ?

Vu le commentaire précédent, il n'y a plus de limite de taille :D

Par contre, dans les logs, lors de tes tests, les requêtes semblent très différentes :

86.XX.XX.XX - - [06/May/2020:17:34:56 +0200] "PUT /public.php/webdav/libre-a-vous-20200428.ogg HTTP/1.0" 201 1052 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 
86.XX.XX.XX - - [06/May/2020:17:42:52 +0200] "PUT /public.php/webdav/libre-a-vous-20180529.ogg HTTP/1.0" 201 1052 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 
86.XX.XX.XX - - [06/May/2020:17:54:52 +0200] "PUT /public.php/webdav/rec_20190702-153000.wav HTTP/1.0" 400 1324 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 
86.XX.XX.XX - - [06/May/2020:18:05:18 +0200] "PUT /public.php/webdav/rec_20190702-153000.wav HTTP/1.0" 400 1324 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 

Rien à voir avec le téléversement par morceau décrit ci-dessus.

Quelle méthode utilises-tu pour le téléversement lors de tes tests ?!! Navigateur web (Javascript activé ?), client GNU/Linux, montage webdav… ? (Réponse Fred: tests avec Firefox et Chromium)

• 1,1 Go : ~8 min, sans erreur ;
• 1,4 Go : ~12 min avec erreur « Erreur lors de l'assemblage des blocs, code d'état 504 » mais fichier correct à l'arrivée ;
• 2,3 Go : ~28 min avec erreur « Erreur lors de l'assemblage des blocs, code d'état 504 » mais fichier correct à l'arrivée.

L'erreur 504 survient pour les gros fichiers lors de la phase d'assemblage des morceaux, au bout d'environ 1 minute. Cela peut s'expliquer par le fait que plus il y a de morceaux, plus l'assemblage prend du temps, et donc peut dépasser le timeout du Nginx de bastion :

==> lamp:valise-new.april.org-access.log <==
91.160.XX.XX - - [07/May/2020:23:33:09 +0200] "MOVE /remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file HTTP/1.0" 201 747 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 

==> bastion:valise-new.april.org.error_log <==
2020/05/07 23:34:09 [error] 11717#11717: *10105899 upstream timed out (110: Connection timed out) while reading response header from upstream,
client: 91.160.XX.XX server: valise-new.april.org, request: "MOVE /remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file HTTP/1.1",
upstream: "http://172.16.0.11:80/remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file", host: "valise.april.org" 

==> bastion:/etc/nginx/nginx.conf <==
  keepalive_timeout 65;

Une solution serait d'augmenter le timeout du Nginx de bastion, de façon à ce que les fichiers audio de « Libre à vous ! » passent sans erreur.

TODO : Cpm

• le téléversement vers un dossier se fait en mode multi-requêtes ;
• le téléversement vers le même dossier via un lien public se fait en mode mono-requêtes .

Donc le téléversement via un lien public est soumis aux limites de timeout et taille de fichier.

Le ticket #4463 pose la question de pourquoi cette différence et comment la supprimer.

Suite à la mise à jour en version 21.0.4 (#5540), reprise des actions.

Pour commencer, le protocole de téléversement est toujours différent suivant qu'on est connecté (multi-requêtes) où que l'on passe par un lien de partage (mono-requête).

Mode lien de partage (mono-requête)

Sur le bastion, configuration de nginx client_max_body_size de 1024M à 2048M.
Constat d'erreur de téléversement au delà d'une taille approximative de 850Mo.
Des lignes d'erreurs apparaissent dans les logs Nextcloud :

Expected filesize of 1488351239 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 897761280 bytes.
Could either be a network problem on the sending side or a problem writing to the storage on the server side.

En vérifiant, on voit que le Nextcloud est correctement paramétré :

(April) root@lamp:/var/www/valise.april.org/config# grep temp config.php
  'tempdirectory' => '/var/www/valise-data/tmp',

Par contre, une note de ticket Nextcloud éclaire la situation : https://github.com/nextcloud/server/issues/19682#issuecomment-654812559

Uploads are processed by PHP before handed to Nextcloud. We are unable to change the location PHP uses to store temporary files used for uploads.

Avec un lien vers la variable à configurer : https://www.php.net/manual/en/ini.core.php#ini.upload-tmp-dir

 upload_tmp_dir string

    The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. 

Il est préconisé de définir un dossier temporaire pour le module PHP d'Apache. Cela a du sens.
Traité dans #5548 pour prendre en compte les directives open_basedir des autres sites web hébergés sur la vm lamp.

Après reconfiguration, des tests confirment l'absence d'erreur.