[07:17:13]
<artlog> from the code it look like upnp.refresh(firewall) can be called even if upnp is deactivated ... and there is something like router_forwarding_upnp in configuration...
[07:17:13]
<artlog> there is seomthing here : upnp is activated globally but over ports too, refresh() does not care it is disabled globally, if called.
[07:17:17]
<artlog> Melchisedech: what does return `sudo ls -la /etc/cron.d/ `
[07:17:26]
<artlog> `yunohost firewall upnp disable`
enabled: False
[07:17:59]
<artlog> what does it return in your case ?
[07:18:16]
<artlog> ok i see : removing the cron is done only the first time `yunohost firewall upnp disable`is done, since it checks if already disabled.
[07:18:29]
<artlog> so fix is just to remove cron : `rm /etc/cron.d/yunohost-firewall-upnp`
[07:18:48]
<boipisigre> Bonjour,
Je viens de réinstaller mon yunohost .
Merci borg 👍
Je constate que le site est accessible à partir de l'IP.
Est il possible de bloquer ?
[08:23:15]
<Moté> boipisigre: tu as redémarré après la réinstallation ? (Ça peut toujours être bien). Essaye de lancer un diagnostic, aussi.
[08:23:37]
<Moté> Il me semble que la conf nginx ne devrait pas permettre de se connecter par l'ip
[08:43:23]
<artlog> De bloquer l'accès public ? Cela se fait depuis la box. Si tu supprimes l'adresse ip de ton yunohost : tu perds son accès...
[08:43:24]
<artlog> est-ce une adresse ipv4 ? si oui alors l'accès depuis l'extérieur ne fonctionne que si la box a de la redirection NAT : as tu un UPNP d'actif ? si oui alors c'est le yunohost qui a demandé l'ouverture du prot et sa redirection.
[08:43:29]
<artlog> si c'est une adresse ipv6 : il faut regarder le parefeu ipv6 de la box.
[08:43:46]
<artlog> en fait ton yunhost a besoin d'une adresse pour accéder au net, au moins pur accéder aux mises à jour. Donc il faut une conenctivité. CE qu'il faut contrôler ce sont les connexions entratnes, et cela c'est la box qui le fait. A moins qu'il y a un VPN ... dans ce cas c'est encore différent
[08:43:56]
<artlog> https://doc.yunohost.org/fr/admin/get_started/post_install/port_forwarding/
[08:44:06]
<artlog> à l'intérieur de ton réseau, derrière la box chez toi, l'équipement est forcément accessible pour toutes les machines connectées.
[08:44:23]
<artlog> boipisigre: Comment as tu vérifié que ton site était accessible ? l'est t'il depuis l'intérieur, ce qui est normal, ou depuis l'extérieur ?
[08:44:41]
<artlog> il est encore possible d'ajouter des règles de firewalling ... mais était-ce la question ?
[08:44:48]
<otm33> boipisigre:
> Je constate que le site est accessible à partir de l'IP.
Tu veux dire que le portail admin est accessible sur ton ipv4 publique ?
[09:09:59]
<boipisigre> C'est bien ma question , est il normal que le site soit accessible sur l'IP depuis le net.
[09:10:15]
<boipisigre> Oui
[09:12:10]
<otm33> Tu peux restreindre les ip/réseaux capables d'atteindre la page d'admin dans outils>paramètres de ynh>sécurité
[10:01:02]
<Melchisedech[m]> It also returns False
[10:03:51]
<Melchisedech[m]> Ok, I did that. We’ll see.
[10:03:51]
<artlog> just remove cron : rm /etc/cron.d/yunohost-firewall-upnp
[10:16:36]
<Moté> C'est la configuration de nginx qui ne devrait pas accepter l'accès par l'IP. Je viens de tester, c'est autorisé également chez moi. C'est utile pour l'installation ou pour intervenir sur l'interface admin si le domaine ne fonctionne plus, mais à mon sens ça pourrait être désactivé. Après, c'est non plus dangereux, ça ne pose pas plus de problèmes de sécurité.
[12:58:12]
<Melchisedech[m]> It seems to work! I don’t receive the emails anymore. Thank you.
[13:54:37]
<ex> Hello, is this the room for Yunohost support?
[14:05:05]
<FbIN> yes
[14:09:28]
<ex> Ah good. I'm moving to a new apartment and so I have to move my Yunohost server (just a laptop I use with the free DynDNS from Yunohost). It's just a hobby server but I was curious what changes I need to make when I move it to the new place because the network config is going to be different. Basically, what needs to happen in order for it get back up and working with the DNS as soon as possible?
[14:14:07]
<FbIN> not much. first check your current router settings, the current local & external IP/domain. make a note of them. Update your port forwarding as necessary in the new place/router. check the local IP is reachable first and then run the dydns update: sudo yunohost dyndns update && verify sudo yunohost domain info yourdomain.tld
[14:14:27]
<FbIN> then check from a different IP/ISP check the domain is rechanble.
[14:15:22]
<FbIN> renew certificate only if needed btw: sudo yunohost domain cert-renew yourdomain.tld, as the certs make take time to display properly at times.
[14:17:34]
<ex> Thank you, I will try that and come back here if there is an issue.
[14:18:55]
<FbIN> sure
[14:26:17]
<artlog> this is the shortest path. If you want to known beforehand what will go wrong, this more complex ...
[14:26:17]
<artlog> If you are using a yunohost provided domain, it will be smooth, the only part you have to take care is to open ports.
[14:26:18]
<artlog> to find address see : https://doc.yunohost.org/en/admin/get_started/post_install/find_ip/?persistLocale=true ; just start with yunohost.local, it might just work ...
[14:26:19]
<boipisigre> NextCloud : Erreur Interne du serveur
Où trouver de l'aide ?
[14:26:19]
<artlog> ex: people who did https://labriqueinter.net/ have even a nicer setup using a VPN : it is just a mobile system : you plug it everywhere and it just works ! But that's the magic of VPN, and comes with fees.
[14:26:19]
<artlog> One thing that can go wrong is if you have multipe yunohost running behind the same box, but it does not look like your case.
[14:26:19]
<artlog> you are far from being the first to do it , same happens when changing of internet provider, some hint can be found in forum too.
[14:28:07]
<artlog> C'est nouveau ?
[14:28:07]
<artlog> ici ;-)
[14:28:08]
<boipisigre> suite à une restauration
[14:28:08]
<artlog> Suite à une mise à jour ?
[14:31:59]
<artlog> alors il faut nous fournir un yunopaste de l'activité de restauration
[14:31:59]
<artlog> Est-ce que le backup d'origine est complet ? Cette restauration fait suite à un problème ?
[14:31:59]
<artlog> la restauration est une des activités les plus risquées...
[14:31:59]
<artlog> nextcloud est servi par nginx via php-fpm et a des logs dans nextloud.log sous le répertoire de données.
[14:31:59]
<boipisigre> https://paste.yunohost.org/raw/amezajowez
[14:33:04]
<boipisigre> la c'est le dernier restaure suite à une erreur d'upgrade ...
[14:37:05]
<artlog> les backups de pre-upgrade sont un peu différents des backups complets...
[14:37:05]
<artlog> Ok, on ne verra pas grand chose ici puisque 'success: true'
[14:37:06]
<boipisigre> Je ne vois pas de service Nextcloud
[14:37:06]
<artlog> dans les services : quel est l'état du service pour nextcloud ?
[14:37:06]
<artlog> le backup s'est bien passé, est que le service nextcloud a été relancé ?
[14:38:23]
<artlog> le service est un php8.x-fpm
[14:38:23]
<artlog> php8.4-fpm pour ^tre précis dans ton cas
[14:38:24]
<boipisigre> Oui,
l'errer est intermittente
[14:39:19]
<boipisigre> j'aimerai
[14:39:19]
<artlog> alors il faut la desintermiter ! ;-)
[14:42:42]
<artlog> ma boule de cristal ...
[14:42:42]
<artlog> https://aria.im/_bifrost/v1/media/download/AXtUbqRoHSoRoXz2qSMf3xXamMliNaVXbN13MmVZ5ftZ3rLzRM2m3By_0LhGqc1i0bkdtvFfGxDmM62FMPubYwBCee-hVUbAAGxpYnJlem8uZnIvb3JGd2hYVXlTWVpCS0txaWxKUnlhamdk
[14:42:42]
<artlog> boipisigre: peux-tu partager le log de ton service php8.4-fpm ?
[14:42:43]
<boipisigre> https://paste.yunohost.org/pufaxopeti
[14:46:55]
<artlog> les esprits ne sont pas là, je ne vois rien du tout !
[14:46:55]
<artlog> et côté nginx ?
[14:46:59]
<boipisigre> https://paste.yunohost.org/rumofegevo
[14:52:42]
<artlog> depuis une ligne de commadne `yunohost app shell nextcloud` puis `tail -f /var/log/nextcloud/nextcloud.log` : se conencter avec le navigateur sur le serrvice nextcloud et regarder ce qui se passe côté nextcloud , comment ça évolue les traces ...
[14:52:42]
<boipisigre> https://aria.im/_bifrost/v1/media/download/Ae-jECePefG9Cmht54P2pNSToAQjxnKQ2260V_2hqDGRxAODnNXfC4zZgb0uqujGL0nSm8fr29kNH8VJ3pdYfqtCee-h584QAG1hdHJpeC5vcmcvZG9ESm5sdGdsQnFaSVVzd3diT1dxZ1RB
[14:53:03]
<boipisigre> J'ai un grep sur l'ID
[14:58:35]
<artlog> il doit y a voir à lire dans nextloud.log ...
[14:58:35]
<boipisigre> https://pastbin.galicien.me/p/snail-crow-whale
[15:00:08]
<boipisigre> Depuis que je tente de résoudre le incident plus de message d'erreur
[15:06:15]
<artlog> L'erreur interne arrive systématiquement ?
[15:06:16]
<boipisigre> Action possible ?
[15:06:16]
<artlog> cela correspond à ce bug : https://github.com/nextcloud/notifications/issues/3035
[15:11:57]
<artlog> c'est bien le problème : le site est focntionnel sion ?
[15:11:57]
<artlog> aucune idée je n'ai pas compris l'étendue du bug
[15:11:57]
<artlog> boipisigre: tu peux tenter un relancement du php8.4-fpm, ça ne mange pas de pain ...
[15:11:57]
<boipisigre> J'ai deux clients OK
l'accès web avec des erreurs intermittentes
Je vais vivre avec ;-)
[15:13:05]
<rodinux> Tu peux aussi tenter de réparer en te connectant en shell ?
```
yunohost app shell nextcloud
php occ maintenance:mode --on
php occ maintenance:repair
php occ maintenance:mode --off
```
[15:14:47]
<artlog> en fait oui : il semble que le bug consomme des connexions php-fpm, alros on peu les augmenter ... il y a une proposition dans ce sens dans le bug et la personne semble avoir résolu son problème.
[15:16:18]
<artlog> ah zut je ne retrouve plus le lien que j'ai suvi, ce n'est peut ^tre pas dans le bug parent ...
[15:16:25]
<boipisigre> appliqué
[15:20:40]
<rodinux> C'est curieux car dans les logs il parle aussi de firstrunwizrad ?? Si tu désactive firstrunwizard ??
[15:23:30]
<artlog> à lire ce bug il semble que la version 33.0.5 le corrige ...
[15:23:38]
<boipisigre> je vous quitte
merci pour vos aides
[15:27:22]
<artlog> j'ai du mal à comprendre ce milestone : https://github.com/nextcloud/notifications/milestone/331
[15:27:45]
<rodinux> c'est an rapport avec ce commit ? https://github.com/nextcloud/notifications/pull/3039
[15:34:07]
<artlog> oui ça m'a l'air. Je dirais donc d'attendre la 33.0.5 et de ne pas upgrader len 33.0.4 ...
[15:34:20]
<artlog> le notifications push c'éait une fonctioanilité pour la 34, ils les ont backporté visiblement, mais ça a son prix ...
[15:34:32]
<artlog> a mon avis on va avoir des bug dans le forum à ce sujet ...
[15:34:46]
<artlog> en fait cela doit dépendre de l'utilisation de clients nextcloud, si tout est en web peut être que le cas est différent ...
[15:35:10]
<rodinux> aïe... j'ai passer pas mal de serveur dernièrement en 33.0.4 et certains avec les notifications push... mais si on désactive l'app IA (ce que je fait) peut-être qu'il ny a pas de conséqueeces ??
[15:37:01]
<artlog> aucune idée, je viens de passer un serveur en 33.0.4, je vais bien voir ...
[15:37:09]
<artlog> https://aria.im/_bifrost/v1/media/download/AcRlttnKV3nzARCeCMW37lUZPKSCB9a_RNm_oLE3PA-Pl81bLow7LSueykcCUPuNuVtPJME84BZPoCsAo5FTGy5Cee-kcudwAGxpYnJlem8uZnIvRGZOV3RWbW53ZXdoQUxRUGdUVVpQU2pD
[15:37:23]
<rodinux> ah oui, je vois des erreurs du style `ErrorCall to a member function getAppValueString() on null`
[15:37:35]
<artlog> sans client push , c'est peut être cela le problème
[15:37:36]
<artlog> est-ce activé/installé de ton côté ?
[15:37:36]
<rodinux> toutes les 10 minutes !
[15:39:11]
<artlog> https://aria.im/_bifrost/v1/media/download/AQKxES8DhbueAN6DNLUzKUi5RGS6A1cVbeEtiBpFeZGPLGYwcGq0sbme0i4B3djFhnbmJiVWEoblTYhGMJ-7fnVCee-kkMQAAGxpYnJlem8uZnIvR3V4VmxyUUN4QkNhaUdYZU9hZmdacmlz
[15:39:15]
<artlog> dans ma vue d'ensemble
[15:39:31]
<artlog> je pense qu'il ne faut pas l'activer tant que la version n'est pas passée en 34
[15:39:39]
<rodinux> je pense que je vais désactiver le client-push en attendant la 33.0.5
[15:39:59]
<artlog> je connais un des développeurs de notifiy push et il m'a dit que cela fonctionne depuis la 34, donc avant ce sont des backports ...
[15:40:14]
<rodinux> ou attendre la version 34 dans ce cas !
[15:44:35]
<artlog> de ton côté le client Push est là ? ( ou bien je confonds le client Push et le Notify Push, ce qui est une possiblité aussi )
[15:44:42]
<rodinux> peut-être je confonds aussi... je parle de la fonction dans le config_panel pour activer notify-push ou la notification push
[15:45:02]
<rodinux> *
[15:45:32]
<artlog> uhm c'est vraiment un truc, l'application 'Client Push' est en fait nommée 'notify_push' dans github
[15:45:43]
<artlog> https://github.com/nextcloud/notify_push
[15:46:02]
<rodinux> ils sont fortiches pour le nommage
[15:46:17]
<artlog> il y a une confusion entre le protocole fourni et un de ses buts
[15:46:32]
<rodinux> Du coup je vais désactiver depuis le config_panel je crois
[15:48:14]
<artlog> le notify_push envoi des notifications depuis le serveur, et donc cela peut servir pour les fichiers mais aussi pour les ntofication Talk, ce qui n'est pas précisé ...
[15:48:23]
<artlog> pic ?
[15:48:37]
<rodinux> https://aria.im/_bifrost/v1/media/download/AXISVeSp1npNXBzwATc-tXvCRv-wlA8YSuw3OoYqgmk1FS6AMJb7SbYxaC25DwYgpLgwdHh7wdu3KFtBLw6iDEZCee-lGtFwAG1hdHJpeC5vcmcvQ3p3bXhFbmZLWUNMQmtGZFZlcmFBVVdP
[15:49:40]
<artlog> Ah côté yunohost ?
[15:50:02]
<artlog> https://aria.im/_bifrost/v1/media/download/AYWNKqfI-qpOIdveQ-0NPGA-OgII3CC7sh_2x3xiQJkimQ7ohonN8hTmM8a4YcTfii2AnqkMAPhYh1hthDgs2spCee-lL6wgAGxpYnJlem8uZnIvZ3FJQ0NqV3BvR2JQaW94QnFiTE52bGxL
[15:50:19]
<rodinux> oui, mais c'est la même app...
[15:50:38]
<artlog> ok je regardais dans le configuration nextcloud...
[15:50:48]
<artlog> c'ets depuis quand ?
[15:50:53]
<artlog> allez, je regarde l'app nextcloud yunohost ...
[15:50:56]
<rodinux> depuis la version 30 ? sais plus
[15:54:55]
<artlog> ok donc la version 34 doit supporter le notify_push **appliqué à Talk**
[15:55:05]
<artlog> il existait avant, mais c'est la fonctionnalité d'application à tlak qui a du causer la régression
[15:55:07]
<artlog> je vais finir par comprendre, c'ets un processus assez long chez moi
[15:55:15]
<artlog> ok notify_push c'est depuis NC 29
[15:55:23]
<artlog> l'app associée c'est Client Push
[15:55:36]
<rodinux> ou notify_push
[15:55:47]
<rodinux> kif-kif
[15:59:35]
<artlog> ok donc desactiver l'app client push doit résoudre le problème des traces mais il va y avoir une perte sur la notification des changements dans la nextcloud app qui va devoir mouliner plus pour demander les changements...
[15:59:35]
<artlog> oui il y a le nom interne notify_push et le nom textuel Client Push
[15:59:36]
<artlog> je n'ai pas le souci dans mon cas sur le serveur : il n'est pratiquement pas utilisé et il n'a jamais eu notify_push ...
[15:59:36]
<rodinux> je l'ai activé sur des instances avec beaucoup d'utilisateurs
[15:59:36]
<artlog> c'est comme spreed et Talk
[16:16:41]
<artlog> je n'ai pas de traces d'erreur en tout cas dans mon nextcloud.log sur ma 33.0.4 sans notify_push
[16:16:42]
<rodinux> Peu-être que l'on devrait signaler sur le forum qu'il vaut mieux désactiver le Clien push avec la version 33.0.4 ??
[16:20:51]
<artlog> tu as auussi les erreurs 500 ou bien juste les traces ?
[16:20:51]
<artlog> ah ... c'est toute la question... je ne susi pas sûr d'avoir fait le tour du problème pour statuer dessus, mais on peut toujours le suggérer...
[16:20:52]
<rodinux> Je regarde, car je gère plusieurs serveurs, si tous les serveurs avec Nexcloud et le Client Push activé on le même soucis, c'est une piste...
[16:26:23]
<rodinux> Bon, c'est pas toujours le cas déjà... Et celui qui vait l'erreur
```
ErrorCall to a member function getAppValueString() on null
```
l'a toujours après avoir désactiver le Clien Push... j'ai des doutes du coup. Un autre serveur avec aussi le Client Push activé n'a pas ces erreurs ??
[16:30:00]
<rodinux> oui
[16:30:00]
<artlog> ils sont tous en 33.0.4 ?
[16:30:00]
<rodinux> sauf un en 32.0.6 qui n'a pas ce soucis
[16:30:00]
<artlog> après redémarrage du php-fpm ?
[16:43:00]
<rodinux> Zut ! sur le serbveur avec ces erreurs récurrentes, désactiver l'app Client Push n'a pas résolu les messages d'erreurs, même en redémarrant le serveur ( par erreur ) !
[16:45:29]
<rodinux> https://aria.im/_bifrost/v1/media/download/AS6FBxu4zvHXTvPE6qAqPh0VdrR8Ps06W-4a0-aS7LXR42_nCJfOmEWtMv_tpgtEjkx1OrbTT-nw-9iRn4OSQkFCee-oW8rwAG1hdHJpeC5vcmcvellKUVZTYVh3SmhDeGx3UUpGV0RhYWVz
[16:59:28]
<artlog> elle dépendent peut être de l'utilisation d'application clientes... Je pense juste que la 33.0.4 est moisie
[16:59:28]
<artlog> l'erreur est encore plus générique alors ...
[16:59:29]
<artlog> avec ou sans l'app notify_push donc, même si l'erreur est vraiment liée au push.
[16:59:29]
<rodinux> ça continue toute les 10 minutes... Je vois bien en cherchant les mêmes origines... https://help.nextcloud.com/t/fehler-webdav-error-call-to-a-member-function-getappvaluestring-on-null/245189/3
[17:01:29]
<rodinux> Je comprnds que le soucis est pour les notifications en général, qu'il y ai le client push ou pas en réalité...
[17:13:16]
<artlog> oui ça a l'air d'un souci général, je suis donc parti dans une mauvaise directin, c'est juste que mon serveur ne fait quasi rien alors ...
[17:13:48]
<rodinux> Bon en fait je n'ai qu'un serveur qui a cette erreur et activer ou pas notify-push ne change rien, donc je la met pas en cause... après d'autres dans les logs, jamais fatales non plus, apparaîssent avec des applications suivant les serveurs variés qui en ony différentes...
[17:14:09]
<rodinux> Bon en fait je n'ai qu'un serveur qui a cette erreur et activer ou pas notify-push ne change rien, donc je la met pas en cause... après d'autres dans les logs, jamais fatales non plus, apparaîssent avec des applications suivant les serveurs variés qui en onytdifférentes...
[17:14:21]
<rodinux> Bon en fait je n'ai qu'un serveur qui a cette erreur et activer ou pas notify-push ne change rien, donc je la met pas en cause... après d'autres dans les logs, jamais fatales non plus, apparaîssent avec des applications suivant les serveurs variés qui en ont différentes... XP
[17:28:37]
<otm33> Il est question d'un patch: quelqu'un l'a testé?
[21:23:09]
<artlog> je ne l'ai pas testé.
[21:23:09]
<artlog> mais je ne suis pas quelqu'un ;-)
[21:28:07]
<Mar_Thym> Hello tout le monde
Est ce que c'est possible de réinitialiser sa raspberry pour refaire la manip yunohost avec la création d'un nouveau compte admin etc ? J'ai foiré la sauvegarde de mon mot de passe admin
J'ai essayé plusieurs tentatives qui ont bloqué mon adresse IP et j'ai essayé d'y aller par ssh avec droits mais sans succès donc je comptais repartir du début
J'ai reflashé yuno sur la carte sd mais ça a rien changé, il me demande quand même le code admin
J'aurais bien aimé recréer tout (compte, MDP admin, nom de domaine etc)
Est ce que vous auriez des idées s'il vous plaît ?
Merci
Marthym