Scénario #37137
Nextcloud : certains modules ne sont pas installés derrière un Amon avec proxy authentifié
0%
Description
Par exemple l'application "calendar" n'est pas installé.
Si je le fais à la main :
# sudo -u www-data php /var/www/html/nextcloud/occ app:install calendar Error: Could not download app calendar
Dans les logs d'Amon :
2025-10-22T14:38:42.117949+02:00 xxx squid[203623]: 1761136722.117 1 172.16.0.3 TCP_DENIED/407 3922 CONNECT apps.nextcloud.com:443 - HIER_NONE/- text/html
Le problème c'est qu'il faudrait autoriser apps.nextcloud.com mais aussi github, githubusercontent, ... Donc trop de chose
Sous-tâches
Historique
#1 Mis à jour par Joël Cuissinat il y a 4 mois
- Tracker changé de Demande à Scénario
- Sujet changé de nextcloud : certains modules ne sont pas installés derrière un Amon avec proxy authentifié à Nextcloud : certains modules ne sont pas installés derrière un Amon avec proxy authentifié
- Début
22/10/2025supprimé - Release mis à Carnet de produit Cadoles - MEN
- Points de scénarios mis à 2.0
Laurent Gourvénec :
si on ne veut pas tout ouvrir, je ne vois que 2 solutions :
- mettre à disposition les modules (dans un paquet séparé)
- fournir les modules dans le paquet - Mettre dans le même paquet risque d'alourdir un paquet déjà bien plein
#2 Mis à jour par Benjamin Bohard il y a 4 mois
J’indique une troisième possibilité, qui n’est sans pas plus simple à mettre en œuvre : l’utilisation d’un dépôt d’application personnalisé en proxy (https://docs.nextcloud.com/server/20/admin_manual/apps_management.html#using-a-self-hosted-apps-store)
Ça nécessiterait les choses suivantes :
- déclarer le dépôt dans la configuration à l’aide des variables appstoreenabled et appstoreurl (trivial) ;
- avoir un service qui renvoie les fichiers apps.json et categories.json quand on fait un HTTP GET sur l’URL définie (pas trop compliqué non plus) ;
- construire les fichiers json (sans doute en repartant des json du store officiel et modifiant l’url de download et les certificats si ceux-ci correspondent au site hébergeant les archives à télécharcher => la partie la moins évidente a priori) ;
- héberger les archives à une unique adresse qu’il serait raisonnable d’autoriser dans le proxy.
#3 Mis à jour par Klaas TJEBBES il y a 3 mois
Est-ce possible d'avoir la liste complète des domaines utilisés (et bloqués 407) ?
#4 Mis à jour par Gilles Grandgérard il y a 3 mois
Une autre idée :
un conteneur Nextcloud hébergé sur hub.eole.education avec toutes les applications prévues pour Scribe.
#5 Mis à jour par Benjamin Bohard il y a 2 mois
La diffusion en conteneur répond à la problématique de la taille du paquet deb.
Si je comprends bien la proposition, il faudrait que ce soit un conteneur avec des données uniquement pour que ce soit raisonnable. Sinon, quel point d’entrée utiliser ? Un service web supplémentaire, un service php-fpm embarqué ?
Une précédente itération côté envole avait envisagé de fournir les applications en mode conteneur mais la solution finalement retenue s’est révélée la plus simple à mettre en œuvre. La gestion des templates, notamment, nécessite pas mal de développement.
#6 Mis à jour par Benjamin Bohard il y a 2 mois
Pour répondre à la question de la liste exhaustive des domaines à autoriser, il me semble que ce n’est pas le problème posé : il me semble possible d’avoir la liste exhaustive des domaines à autoriser mais ces mêmes domaines ne sont pas spécifiques à Nextcloud.
En clair, on peut mettre des exceptions pour les domaines concernés mais, vu ces domaines, autant ne pas mettre de proxy : ces domaines donnent accès à tout et n’importe quoi et pas seulement à Nextcloud.
#7 Mis à jour par Joël Cuissinat il y a 9 jours
- Release changé de Carnet de produit Cadoles - MEN à EOLE 2.9.0