Bonjour,
Ces jours-ci les Nextcloud installés proposent la mise à jour vers vers la version 14.0.1.
Je l’ai fait pour 4 installations, sans problème jusqu’à présent.
À noter que la version précédente de “Talk” (alias “Spreed”) n’est pas compatible. Elle est donc désinstallée. Il faut réinstaller l’application après la mise à jour.
Bonjour,
Après mise à jour, j’ai plusieurs avertissements :
/dev/urandom n'est pas lisible par PHP, ce qui est fortement déconseillé pour des raisons de sécurité. Vous trouverez plus d'informations dans la documentation.
La fonction PHP "set_time_limit" n'est pas disponible. Cela pourrait entraîner l'arrêt des scripts à mi-exécution en bloquant votre installation. Nous vous recommandons vivement d'activer cette fonction.
L'utilisation de la fonctionnalité d'envoi d'e-mails native de PHP n'est plus supportée. Merci de mettre à jour les paramètres d'envoi d'e-mails de votre serveur
La configuration du serveur web ne permet pas d'atteindre "/.well-known/caldav". Vous trouverez plus d'informations dans la documentation.
La configuration du serveur web ne permet pas d'atteindre "/.well-known/carddav". Vous trouverez plus d'informations dans la documentation.
Aucun cache mémoire n'est configuré. Si possible, configurez un "memcache" pour améliorer les performances. Pour plus d'informations consultez la documentation.
Le PHP OPcache n'est pas correctement configuré. Pour de meilleure performance nous recommandons d'utiliser les paramètres suivant dans le php.ini :
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
La base de données a quelques index manquant. L'ajout d'index dans de grandes tables peut prendre un certain temps. Elles ne sont donc pas ajoutées automatiquement. En exécutant "occ db:add-missing-indices", ces index manquants pourront être ajoutés manuellement pendant que l'instance continue de tourner. Une fois les index ajoutés, les requêtes sur ces tables sont généralement beaucoup plus rapides.
Index "share_with_index" manquant dans la table "oc_share".
Index "parent_index" manquant dans la table "oc_share".
Index "fs_mtime" manquant dans la table "oc_filecache".
L'en-tête HTTP "Referrer-Policy" n'est pas défini sur "no-referrer", "no-referrer-when-downgrade", "strict-origin" ou "strict-origin-when-cross-origin". Cela peut entraîner une fuite d'informations. Veuillez voir les recommandations du W3C.
Le tutorial d’installation Nextcloud d’Ouvaton demande d’ignorer les messages concernant le cache et la fonction set_time_limit. Qu’en est-il des autres avertissements ?
Merci.
Bonjour,
Pour /dev/urandom, c’est signalé, nous attendons l’intervention de notre infogérant.
Pour l’envoi de mails, il faut configurer Nextcloud pour qu’il utilise une véritable adresse mail avec un serveur SMTP. C’est à faire dans Paramètres / Paramètres de base / Serveur e-mail.
Pour les deux lignes “/.well-known/…”, vous pouvez ajouter ceci dans votre fichier .htaccess à la racine (/httpdocs/.htaccess) :
Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav
Selon la page https://docs.nextcloud.com/server/14/admin_manual/issues/general_troubleshooting.html#service-discovery, ça devrait permettre d’utiliser directement l’adresse https://votrenuage.votredomaine.tld pour les synchronisations DAV.
Pour les index manquant, vous ne pouvez pas le faire via la commande occ sur notre plateforme mutualisée. Vous pouvez le faire dans PHPMyAdmin avec les requêtes ci-dessous (voir https://github.com/nextcloud/server/issues/11491) :
ALTER TABLE `oc_share` ADD KEY `share_with_index` (`share_with`) USING BTREE;
ALTER TABLE `oc_share` ADD KEY `parent_index` (`parent`) USING BTREE;
ALTER TABLE `oc_filecache` ADD KEY `fs_mtime` (`mtime`) USING BTREE;
Et pour l’en-tête HTTP “Referrer-Policy”, vous pouvez ajouter la ligne suivante dans votre fichier .htaccess :
Header always set Referrer-Policy "no-referrer"
Merci beaucoup, tout est résolu sauf les messages concernant CalDAV et CardDAV, qui persistent malgré l’ajout des redirections dans /httpdocs/.htaccess. Mais comme nous n’utilisons pour l’instant ni CalDAV ni CardDAV, je n’ai pas fouillé plus loin.
Bonjour,
Je me sentais pourtant capable d’effectuer la mise à jour de nextcloud, mais j’ai dû me tromper quelque part car je reste depuis 5 ou 6 heures sur la page “Cette instance de Nextcloud est en cours de maintenance, cela peut prendre du temps. […] Merci de votre patience.” A la dernière question j’ai répondu “yes” je n’aurais peut-être pas du ? Sauriez-vous comment me dépêtrer ?
Et j’ai aussi explosé l’espace disque qui m’est attribué, mais je ne sais pas comment (j’ai vidé les files_trashbin et autres files_versions).
Merci,
Elise
Bonjour,
Dans /httpdocs/nextcloud_donnees/updater-ocnorf24gkq5 supprimer le .step et reprendre la mise à jour.
Bonjour,
J’ai supprimé le fichier, mais comment reprendre la maj ? J’ai rafraichi la page mais rien ne se passe.
Merci,
Elise
Retry update, je crois.
Dans le fichier de config, mettre Maintenance sur false.
Pour le volume c’est redescendu à 1.6 Go. Vous avez dû trouver la solution.
Nickel, ça a marché avec « false ». Pas eu besoin de « Retry update » qui reste très énigmatique pour moi.
Merci pour tout.
Elise
Bonjour,
Nextcloud ne me propose pas la mise à jour vers 14.X et reste sur la 13.0.7.
Que puis-je faire ?
Merci à vous,
Florian
Bonjour,
Mon Nextcloud m’affichait la même chose (13.0.7) mais lorsqu’on lance la mise à jour c’est bien vers la 14.0.3.
Cordialement,
Grégory
Merci,
Je me réponds : j’en suis encore à PHP 5.X installé, et pour la 14 il faut PHP 7.X.
Florian
Bonsoir,
J’espérais que, pour une fois, la migration se passerait bien. Hélas !
Une première erreur, puis c’est reparti avec “Retry update”, mais ensuite, nouvelle erreur et impossible de m’en sortir.
Je n’ai plus accès qu’à une seule page avec le simple texte “Update in process.”
Le fichier .step n’existe pas. Il y a un .step-previous-update dont la suppression n’améliore rien.
Le passage à “false” du paramètre maintenance dans config.php ne donne rien de plus.
Je pense - j’espère ! - qu’il y a un moyen de restaurer la version qui marchait bien. Mais comment faire ?
Merci à l’âme charitable qui me viendra en aide
Bonjour,
Là je pense qu’il faudrait ouvrir un ticket pour demander de l’aide personnalisée.
Bonjour,
Merci à Philippe pour son intervention.
Bon, finalement, je ne sais pas ce qu’il s’est passé. C’est de ma faute, je n’ai pas noté le message d’erreur avant de tenter le “Retry” !
J’ai cependant pu régler le problème assez simplement. Je donne l’info si ça peut servir :
Je n’ai pas encore tout vérifié mais il semblerait que toutes les configurations aient été récupérées (personnalisation, utilisateurs…). La mise à jour vers la 14.0.4 s’est bien passée !
Moralité, la sauvegarde régulière de la base de données est vitale !
Bonjour,
Je suis décidément maudit !
Je n’ai jamais eu droit à une mise à jour sans accroc !
Échaudé par cette dernière expérience, je n’avais plus fait de mise à jour depuis la première V15 et, aujourd’hui, la migration vers la 16.0.1 s’est soldée par le même problème… et la même solution !
J’ai un peu amélioré la procédure, en particulier pour le “vidage” de httpdocs : j’ai exécuté un php qui détruit récursivement tout le contenu (y compris lui-même). C’est un peu stressant… mais c’est fait en quelques secondes au lieu de plusieurs heures en FTP !
Une remarque : l’installation nouvelle par dessus l’ancienne crée forcément un premier compte qui sera administrateur. Puisque la base de données est conservée, l’administrateur précédent existe toujours et il est refusé pour l’installation : “Ce nom d’utilisateur existe déjà”. Il suffit de donner un nom quelconque puis de supprimer le compte créé, à la fin de l’opération. Quand on est sûr que l’accès des administrateurs précédents est possible !
Bonjour,
Par curiosité
