[03:40:06]
<ungloved> ```
error: png: bit depth must be 8 or 16.
error: file "/splash.png" not found.
error: png: bit depth must be 8 or 16.
Press any key to continue..._
```
Is this a known error when trying to boot the **yunohost-bullseye-11.0.9-amd64-stable** iso? It's passable by pressing any key, just wondering.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I straight **dd** it to the stick but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I straight **dd** it to the stick but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost iso is corrupt. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
[03:46:29]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
[04:03:40]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
edit2: A different usb stick didn't help. The ISO did install in GNOME Boxes. I'm throwing in the towel on this project 😅
[04:03:41]
<ungloved> I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
edit2: A different usb stick didn't help. The ISO did install in GNOME Boxes. I'm throwing in the towel on this project for now😅
[04:03:48]
<ungloved> ```
error: png: bit depth must be 8 or 16.
error: file "/splash.png" not found.
error: png: bit depth must be 8 or 16.
Press any key to continue..._
```
Is this a known error when trying to boot the **yunohost-bullseye-11.0.9-amd64-stable** iso? It's passable by pressing any key, just wondering.
I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
Edit: Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
edit2: A different usb stick didn't help. The ISO did install in GNOME Boxes. I'm throwing in the towel on this project for now😅
[04:17:36]
<ungloved> ```
error: png: bit depth must be 8 or 16.
error: file "/splash.png" not found.
error: png: bit depth must be 8 or 16.
Press any key to continue..._
```
Is this a known error when trying to boot the **yunohost-bullseye-11.0.9-amd64-stable** iso? It's passable by pressing any key, just wondering.
I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
****Edi**t:** Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
**edit2:** A different usb stick didn't help. The ISO did install in GNOME Boxes. I'm throwing in the towel on this project for now😅
[04:23:11]
<ungloved> ```
error: png: bit depth must be 8 or 16.
error: file "/splash.png" not found.
error: png: bit depth must be 8 or 16.
Press any key to continue..._
```
Is this a known error when trying to boot the **yunohost-bullseye-11.0.9-amd64-stable** iso? It's passable by pressing any key, just wondering.
I've having all kinds of issues but I'm not sure if it's the hardware. I couldn't get the USB stick to be seen by the BIOS when I used **dd** but it did show up when using **Ventoy**. Now it keeps failing to partition the drive with the error "**The ext4 file system creation in partition #1 of /dev/nvme0n1 failed.**".
I'm thinking maybe the Debian 11 kernel just might not be new enough for Ryzen 5000. I guess the next logical testing step is trying to install vanilla Debian 11 on this hardware.
**Edit:** Debian 11 installs successfully. Maybe my Yunohost iso got corrupted. It passed a sha256 check before copying to the USB stick but I'll try again with a new stick.
**edit2:** A different usb stick didn't help. The ISO did install in GNOME Boxes. I'm throwing in the towel on this project for now😅
[06:16:49]
<Ilario> Bonjour, svp pour ma lime2 quelle version de armbian dois je décharger?
https://armbian.systemonachip.net/archive/lime2/archive/
Merci.
[07:39:38]
<phinero> I got error **400** after trying to update the system
_You cannot do this right now because dpkg/APT (the system package managers) seems to be in a broken state... You can try to solve this issue by connecting through SSH and running `sudo apt install --fix-broken` and/or `sudo dpkg --configure -a` and/or `sudo dpkg --audit`._
Both my servers got the same error. Is it on my side or something wrong with yuno? Should I solve it on my own?
[07:54:47]
<Séβαστιεν 🐧> Same error this morning at home.
[08:08:38]
<hook> > Bonjour, svp pour ma lime2 quelle version de armbian dois je décharger?
> https://armbian.systemonachip.net/archive/lime2/archive/
(attention, mauvais français en marche!)
YunoHost 11 est basé à Debian 11 (Bullseye), ergo la dernière version de Armbian Bullseye. Alors, je dirai:
https://armbian.systemonachip.net/archive/lime2/archive/Armbian_23.02.2_Lime2_bullseye_current_5.15.93.img.xz
ou
https://armbian.systemonachip.net/archive/lime2/archive/Armbian_23.02.2_Lime2_bullseye_current_5.15.93_minimal.img.xz
[08:09:19]
<hook> (ou le torrent pour les mêmes)
[08:15:58]
<hook> Ilario, 👆
[08:21:58]
<Ilario> > Ilario, 👆
Merci, désolé pour le mauvais français. J'ai fais des fautes d'orthographe ?
[08:30:15]
<hook> Non, c’est moi avec le mauvais français 😹
[09:01:45]
<Ilario> > Non, c’est moi avec le mauvais français 😹
On est à deux!
[09:19:57]
<hook> /o/ \o\
[09:27:17]
<Aleks (he/him/il/lui)> hmkay, what if you run `ls -ld /var/mail/prenom/`, does it shows the folder existing ?
[10:18:56]
<Chatpitaine Caverne> En même temps, "bon français" c'est pas top 😸
[12:47:47]
<Chatpitaine Caverne> Hello,
My nextcloud update didn't pass, but it is not a yunohost issue.
I have database corruption in the nextcloud ldap users management.
Does anybody know where to find the nextcloud database schema to help me in the de-corruption process ?
[13:33:39]
<Chatpitaine Caverne> For information, my nextcloud issue looks like that : https://github.com/nextcloud/server/issues/42232
[13:37:51]
<Chatpitaine Caverne> And I think it comes from a very old issue, (that I perfectly ignored until it breaks all, always a bad idea, I know that).
Where suddenly my LDAP configuration got a blank ID insteed of S01 and I thought it was a good idea to reconnect by adding a configuration with CLI.
Well, letting things going is always a bad idea.
[13:38:07]
<Ilario> https://linuxtrent.it/upload/0179bf71e1172931f335bce2a0db2bcd94cda68e/0YWefrSJiwdOzIclwkMHLUIu0runuXh3anXn1AtH/MWfeF4T0QVWS6rUgHECO_Q.jpg
[13:39:03]
<Ilario> Désolé pour la photo, que dois je faire pour résoudre les problèmes, sauf celui ipv6?
Merci
[13:41:58]
<hook> T’as essayé mettre YunoHost à jour?
[13:45:14]
<Ilario> Oui, si je ouvre /etc/resolv.conf j'ai un IP qui est celui de mon router. Est ce normal ?
[13:46:02]
<hook> Je croix que c’est possible que il y a des repos Armbian en `/etc/apt/sources.list.d/` que YunoHost n’aime pas.
[13:48:04]
<hook> > Oui, si je ouvre /etc/resolv.conf j'ai un IP qui est celui de mon router. Est ce normal ?
Chez moi c’est:
https://paste.yunohost.org/raw/ejeyasujew
[13:49:32]
<Chatpitaine Caverne> Ilario même resol.conf que hook
[13:50:17]
<hook> > Je croix que c’est possible que il y a des repos Armbian en `/etc/apt/sources.list.d/` que YunoHost n’aime pas.
je _croix_ …je ne sais pas
[13:52:07]
<Ilario> > Je croix que c’est possible que il y a des repos Armbian en `/etc/apt/sources.list.d/` que YunoHost n’aime pas.
Je dois résoudre un problème à la fois. Je vais commencer par les repos
[13:52:20]
<Ilario> > Ilario même resol.conf que hook
C'est quoi?
[13:55:22]
<Ilario> > Je croix que c’est possible que il y a des repos Armbian en `/etc/apt/sources.list.d/` que YunoHost n’aime pas.
Résolu
[13:59:07]
<Ilario> >> Oui, si je ouvre /etc/resolv.conf j'ai un IP qui est celui de mon router. Est ce normal ?
> Chez moi c’est:
> https://paste.yunohost.org/raw/ejeyasujew
Moi j'ai
search ynh.fr
nameserver 192.168.1.1
Ça devait être 127.0.0.1?
[14:00:21]
<Ilario> >> Chez moi c’est:
>> https://paste.yunohost.org/raw/ejeyasujew
> Moi j'ai
> search ynh.fr
> nameserver 192.168.1.1
>
> Ça devait être 127.0.0.1?
Résolu
[14:01:01]
<hook> 👍
[14:01:51]
<Ilario> Merci a tout le monde.
[14:04:46]
<Chatpitaine Caverne> Ilario: can you give us the content of `ls -al /etc/apt/sources.list.d/`
[14:05:18]
<Chatpitaine Caverne> https://paste.yunohost.org/raw/ejeyasujew
[14:05:28]
<Klorydryk> Bonjour ! J'ai eu une erreur de base de donnée aussi à la mise à jour de Nextcloud en v28 : collision d'index entre 2 tables apparemment. j'ai ouvert le ticket 646 sur le github de YNH/NC. Quelqu'un saurait comment corriger ce souci ?
[14:05:29]
<Chatpitaine Caverne> and a `cat /etc/apt/sources.list.d/yunohost.list`
[14:06:00]
<Ilario> https://linuxtrent.it/upload/0179bf71e1172931f335bce2a0db2bcd94cda68e/1G296BF5uItrW9klg46XBN7rBRAN97LAAAjCQjQ8/C9zk2M3RT-u0ZIdkQ36fPQ.jpg
[14:08:23]
<Ilario> https://linuxtrent.it/upload/0179bf71e1172931f335bce2a0db2bcd94cda68e/6xyUkoDRQ6ICaDikP6tOZptlLWoPPC3KFLj3gGeO/5ULC2XFOTQGLJ_3nYK2FeQ.jpg
[14:11:00]
<Ilario> > https://paste.yunohost.org/raw/ejeyasujew
C'est çà, inséré 127.0.0.1 problème résolu. Merci.
[14:12:52]
<Chatpitaine Caverne> Ilario: Et tu n'as plus l'erreur commençant par Sembra che apt non plus ?
C'est tout bon ?
[14:13:14]
<Ilario> J'ai eu quelques soucis de certificat après restauration depuis un backup, mai j'ai réussi enfin.
[14:13:34]
<Ilario> > Ilario: Et tu n'as plus l'erreur commençant par Sembra che apt non plus ?
> C'est tout bon ?
C'est bon!
[14:21:22]
<Ilario> > Ilario: Et tu n'as plus l'erreur commençant par Sembra che apt non plus ?
> C'est tout bon ?
Merci bcp
[15:07:31]
<Klorydryk> > <@klorydryk:matrix.org> Bonjour ! J'ai eu une erreur de base de donnée aussi à la mise à jour de Nextcloud en v28 : collision d'index entre 2 tables apparemment. j'ai ouvert le ticket 646 sur le github de YNH/NC. Quelqu'un saurait comment corriger ce souci ?
https://github.com/YunoHost-Apps/nextcloud_ynh/issues/646
L'erreur :
Info : DEBUG - Updating database schema
Info : DEBUG - Exception: Database error when running migration 28000Date20230906104802 for app core
Info : DEBUG - Index name "nid" for table "oc_social_3_stream" collides with the constraint on table "oc_social_3_cache_actor".
Info : DEBUG - Update failed
Info : DEBUG - Maintenance mode is kept active
Info : DEBUG - Resetting log level
Info : DEBUG - + '[' 5 -eq 3 ']'
Info : DEBUG - + ynh_die '--message=Unable to upgrade Nextcloud'
Info : DEBUG - + ynh_exit_properly
Attention : Upgrade failed ... attempting to restore the safety backup (Yunohost first need to remove the app for this) ...
[15:32:57]
<Klorydryk> Ok, il semble que ce soit lié à l'application Social et qu'on puisse supprimer ces tables : https://github.com/nextcloud/server/issues/41253
[16:36:46]
<hook> XMPP me tojours donne des problèmes…
[16:40:07]
<hook> Si je essaye télécharger un image ou qqch, je reçois l’erreur: « The certificate does not match the expected identity of the site »
[16:40:35]
<Chatpitaine Caverne> > <hook> XMPP me tojours donne des problèmes…
Quel genre de problèmes ? As-tu des logs ? Plus de détail ?
[17:00:06]
<hook> ⬆
[17:27:12]
<hook> Chatpitaine Caverne, pas erreurs dans les logs.
[17:33:39]
<hook> Il me semble que c’est pareil comme https://forum.yunohost.org/t/images-upload-with-xmpp-metronome/6795/ …mais ce probème est résolu par https://github.com/YunoHost/issues/issues/1278 , non?
[17:41:27]
<Chatpitaine Caverne> hook: I'm sorry, I'm far from being an expert. I don't know about this one.
[17:41:40]
<hook> No worries :)
[17:42:13]
<hook> I’m just flabbergasted it’s supposed to work out of the box for a few years now already XD
[17:44:14]
<Chatpitaine Caverne> This command can't do bad things (hopefully) :
`sudo yunohost service regen-conf metronome --force`
[17:44:17]
<Aleks (he/him/il/lui)> well it's not really like the XMPP integration is really super-maintained and i don't think it's going to improve, XMPP kind of fell out of fashion
[17:45:08]
<hook> From where I’m standing it seems it’s becoming interesting again.
[17:45:29]
<Aleks (he/him/il/lui)> how so ?
[17:45:39]
<hook> Some young’uns here started using it too.
[17:47:07]
<hook> They use it insstead of SMS and even phone calls, and people are writing bridges (transports) for it.
[17:48:02]
<hook> Might help if XMPP was better explained and advertised, sine it already comes enabled by default on Yuno
[17:52:16]
<hook> People seem to be getting sick of all the different chat protocols, and with the popularity of Mastodon, federation is becoming cool (again).
[17:54:08]
<hook> And XMPP is a much easier on the resources as has very well documented and stable specificaitons.
[17:54:40]
<hook> Apparently its modern spam filtering is much better than Matrix etc. too, but I haven’t given that a try yet.
[18:37:07]
<clawfire> > <@clawfire:matrix.org> oh! le log de nginx me montre ca :
>
> ```
> 2024/01/11 20:58:57 [alert] 54102#54102: worker process 54104 exited on signal 11
> 2024/01/11 20:58:57 [alert] 54102#54102: worker process 54103 exited on signal 11
> 2024/01/11 20:58:58 [alert] 54102#54102: worker process 54124 exited on signal 11
> ```
>
> Juste avant de planter et de fermer la connexion.
Hey all. I'm still stuck with my nginx server crash but service still up when I log in sucessufuly. I'm running out of ideas right now. I found out when I login successfully NGINX got this error. And I don't know why. Online search got me nothing in particular. Did someone saw this before ?
[18:39:37]
<hook> Got a better error message from Conversations:
> Hostname xmpp-upload.campfire.wheremymonkeyis.at not verified:
> certificate: sha256/KQlCfXFF/PpqhM4+7f1nLeYtQ9fOHcmWQX2v74PvOYE=
> DN: CN=campfire.wheremymonkeyis.at
> subjectAltNames: [campfire.wheremymonkeyis.at]
[18:44:15]
<Aleks (he/him/il/lui)> > <@clawfire:matrix.org> Hey all. I'm still stuck with my nginx server crash but service still up when I log in sucessufuly. I'm running out of ideas right now. I found out when I login successfully NGINX got this error. And I don't know why. Online search got me nothing in particular. Did someone saw this before ?
the error message you quoted is unrelated i think ... Could it be that the connection_closed thing happens after failing to enter a valid passwor on your interface ? x_x
[18:44:24]
<Aleks (he/him/il/lui)> like fail2ban kicking you out
[18:46:45]
<clawfire> > <@Alekswag:matrix.org> the error message you quoted is unrelated i think ... Could it be that the connection_closed thing happens after failing to enter a valid passwor on your interface ? x_x
Nope. Because if I enter the wrong password, I go back to the login page with a "wrong password" error massage. Only when the password is correct it crash. Admin isn't reachable, all publicly available frontend of other apps like my mastodon aren't available either.
If I ssh to my machine and restart nginx, they are back to being available
[18:48:18]
<Aleks (he/him/il/lui)> An error massage ? I'd like to try one of those these days (sorry)
[18:49:48]
<clawfire> The web browser just has the server closing the connection. Got nothing before that. And I only found the one I mentioned just before. Don't have any PHP-FPM error in the logs :/
[18:50:34]
<Aleks (he/him/il/lui)> so if i understand correctly : you enter the correct credentials in yunohost's user portal, and then it immediately crashes ? Or do you somehow get redirected to a specific app first ..?
[18:50:36]
<clawfire> Got a `ERR_CONNECTION_RESET` then `ERR_CONNECTION_CLOSED`
[18:50:54]
<clawfire> > <@Alekswag:matrix.org> so if i understand correctly : you enter the correct credentials in yunohost's user portal, and then it immediately crashes ? Or do you somehow get redirected to a specific app first ..?
That's correct.
[18:51:48]
<Aleks (he/him/il/lui)> so like you don't browse to any app, you just expect to see the app tiles first ..?
[18:51:52]
<clawfire> yep
[18:52:20]
<clawfire> That happen to any app / area behind the user login. Admin login is fine.
[18:52:55]
<clawfire> Accessing any app restricted to users like https://dolibarr.bears.lu/ leads to the user login page and same behavior.
[18:53:26]
<clawfire> But apps that handle their own auth like my mastodon instance works just fine for login operation
[18:54:02]
<hook> I think I found the culprit … the certificat i actually not generated anymore (it used to be though)
[18:55:31]
<hook> It used to be generated here:
https://github.com/pitchum/yunohost/blob/f52eef4bc2db4398841e0475a6ce9e13d24e917b/src/yunohost/certificate.py#L645
[18:55:56]
<hook> But in the current version that’s gone:
https://github.com/pitchum/yunohost/blob/experiments-by-pitchum/src/yunohost/certificate.py
[18:56:56]
<hook> (wait a minute …that’s not the official repo)
[19:00:06]
<Aleks (he/him/il/lui)> > <@clawfire:matrix.org> That happen to any app / area behind the user login. Admin login is fine.
naively i would look at `top` activity right when the bug happens to see if there's any obvious process eating resources
[19:00:06]
<Aleks (he/him/il/lui)> > <hook> I think I found the culprit … the certificat i actually not generated anymore (it used to be though)
you mean for muc or xmpp-upload maybe ?
[19:00:52]
<hook> OK, found the official repos. It’s still there.
[19:00:53]
<Aleks (he/him/il/lui)> certificate for muc and xmpp-upload are generated if the DNS are configured appropriately + diagnosis did check they are at the time of the cert generation
[19:01:01]
<Aleks (he/him/il/lui)> otherwise it's supposed to display a warning saying you might need to regen the cert manually once it's fixed
[19:01:17]
<Aleks (he/him/il/lui)> or maybe XMPP was enabled after cert generation for that domain
[19:01:52]
<hook> > or maybe XMPP was enabled after cert generation for that domain
Aleks (he/him/il/lui), that might have been it, because I used a separate domain than the main one for XMPP.
[19:02:51]
<Aleks (he/him/il/lui)> then just trigger a manual regen of the certificate in Domain > yourdomain.tld > Certificate
[19:03:20]
<clawfire> > <@Alekswag:matrix.org> naively i would look at `top` activity right when the bug happens to see if there's any obvious process eating resources
openldap but like for a short blip
[19:03:25]
<Aleks (he/him/il/lui)> yeah that's not the culprit
[19:06:22]
<hook> Aleks (he/him/il/lui):
> Subdomain 'xmpp-upload.campfire.wheremymonkeyis.at' does not resolve to the same IP address as 'campfire.wheremymonkeyis.at'. Some features will not be available until you fix this and regenerate the certificate.
> Subdomain 'muc.campfire.wheremymonkeyis.at' does not resolve to the same IP address as 'campfire.wheremymonkeyis.at'. Some features will not be available until you fix this and regenerate the certificate.
[19:06:31]
<clawfire> I even try with a brand new user, same issue.
[19:08:56]
<Aleks (he/him/il/lui)> yes
[19:10:16]
<Aleks (he/him/il/lui)> is this reported in the diagnosis as well ?
[19:11:57]
<hook> > is this reported in the diagnosis as well ?
That gets reported if I try to renew LE cert.
Diagnosis says that domain is perfectly fine.
[19:21:10]
<Aleks (he/him/il/lui)> let's have a look at : `yunohost diagnosis get dnsrecords --output-as json | jq ".items" | grep "campfire.wheremymonkeyis.at" -C10 | grep "CNAME:xmpp-upload"`
[19:21:25]
<Aleks (he/him/il/lui)> does it says "OK" ?
[19:23:49]
<hook> Aleks (he/him/il/lui), Yes, it’s says OK
[19:24:16]
<Aleks (he/him/il/lui)> :|
[19:26:45]
<Aleks (he/him/il/lui)> ¯\\\_(ツ)\_/¯ i dunno how this warning can happen if the diagnosis result are ok
[19:27:09]
<hook> Dunno, but it also does not work 🤷♂️
[19:58:46]
<hook> Is it possible that `yunohost` properly triggered the LetsEncrypt certificate, but because it’s only a few days old, LetsEncrypt simply did not change it?
[20:00:10]
<Aleks (he/him/il/lui)> not sure to understand ... is the log you just shared about the domain "oes not resolve to the same IP address as " ... is it when you just clicked the button to manually renew the cert moments ago, or is it from an X-days old log ..?
[20:03:19]
<hook> I clicked the button to renew the LE certificate in the YNH WebAdmin and that warrning popped up.
[20:03:49]
<Aleks (he/him/il/lui)> yeah so idk maybe some bug or cache issue, naively i'd try to see if running from CLI is any better
[20:05:20]
<hook> Slightly off-topic, but is there a way to generate `yunohost` auto-completion for Fish Shell?
[20:05:24]
<nightbronze> > <@Alekswag:matrix.org> Docker obviously
What reverse proxy do you use with Docker? What is the reverse proxy that is closest to that of yunohost?
[20:05:57]
<Aleks (he/him/il/lui)> yunohost uses nginx
[20:06:15]
<Aleks (he/him/il/lui)> > <hook> Slightly off-topic, but is there a way to generate `yunohost` auto-completion for Fish Shell?
maybe, but then maybe somebody that actually knows fish shell gotta implement it
[20:06:58]
<hook> I use it, might be a good first contribution …if no-one beats me to it
[20:08:33]
<nightbronze> > <@Alekswag:matrix.org> yunohost uses nginx
yunohost automates DNS redirections and offers diagnostics to add DNS records to the host, it also allows you to create subdomains with great ease. What is the reverse proxy in web-ui that does the same thing?
[20:08:40]
<Aleks (he/him/il/lui)> > <hook> I use it, might be a good first contribution …if no-one beats me to it
there's one for zsh still pending it's like uuh idk 90% complete https://github.com/YunoHost/yunohost/pull/1712
[20:09:53]
<Aleks (he/him/il/lui)> i don't know man, yunohost exists for a reason, if other tools were already simplify stuff so much we wouldn't exist, this is the yunohost support room, not the "i-want-to-learn-general-system-administration" roomt ...
[20:11:22]
<nightbronze> > <@Alekswag:matrix.org> i don't know man, yunohost exists for a reason, if other tools were already simplify stuff so much we wouldn't exist, this is the yunohost support room, not the "i-want-to-learn-general-system-administration" roomt ...
Why do you use docker if you have yunohost?
[20:12:02]
<Aleks (he/him/il/lui)> because docker is more fitting for development
[20:14:03]
<hook> Bah, even `sudo yunohost domain cert-renew campfire.wheremymonkeyis.at --force` produces the same “does not resolve the same IP address” warnings as before :/
[20:14:58]
<Aleks (he/him/il/lui)> :|
[20:15:37]
<hook> Ah, I think I got it.
[20:16:11]
<hook> Perhaps the remainder from the domain I tried to run XMPP on before is still has DNS entries and it’s messing things up.
[20:17:44]
<hook> I’ve got another XMPP server running on tinybridge.wheremymonkeyis.at (which I don’t use. I tried using it as a dedicated domain for Biboumi)
[20:21:13]
<hook> Nope, removing those did not help either.
[20:22:37]
<Aleks (he/him/il/lui)> If you really want to debug it you should open /usr/lib/python3/dist-packages/yunohost/certificate.py and add a print around here https://github.com/YunoHost/yunohost/blob/dev/src/certificate.py#L582
[20:22:45]
<Aleks (he/him/il/lui)> maybe printing the content of `xmpp_records`
[20:24:17]
<hook> Like this?
```
if xmpp_records.get("CNAME:" + sub) == "OK":
sanlist.append(("DNS:" + subdomain))
print(xmpp_records)
else:
```
[20:28:39]
<Aleks (he/him/il/lui)> before the if rather
[20:30:23]
<hook> Aleks (he/him/il/lui), https://paste.yunohost.org/dexadeqari.coffeescript
[20:31:28]
<Aleks (he/him/il/lui)> ah
[20:31:29]
<Aleks (he/him/il/lui)> hmm
[20:32:17]
<Aleks (he/him/il/lui)> ah yes i see
[20:32:43]
<Aleks (he/him/il/lui)> so `sub` is `xmpp-upload`, but the id of the diagnosis result is actually `xmpp-upload.campfire`
[20:32:51]
<Aleks (he/him/il/lui)> because of all the domains / prefix etc shenanigans
[20:33:17]
<Aleks (he/him/il/lui)> *thinking intensifies*
[20:35:05]
<Aleks (he/him/il/lui)> hmf yeah it should probably be calling `_get_relative_name_for_dns_zone` or something
[20:35:14]
<Aleks (he/him/il/lui)> trying to design a patch
[20:36:12]
<hook> Yay, I helped ? 😕
[20:40:34]
<Aleks (he/him/il/lui)> so let's try something like this:
```python
from yunohost.dns import _get_relative_name_for_dns_zone, _get_dns_zone_for_domain
base_dns_zone = _get_dns_zone_for_domain(domain)
basename = _get_relative_name_for_dns_zone(domain, base_dns_zone)
suffix = f".{basename}" if basename != "@" else ""
sub = sub + suffix
```
[20:40:47]
<Aleks (he/him/il/lui)> to be copypasted same place as the `print(...)` you did, and indented too
[20:41:09]
<Aleks (he/him/il/lui)> next line after this should be `if xmpp_records.get("CNAME:" + sub) == "OK":`
[20:47:05]
<hook> Aleks (he/him/il/lui), Progress, but new issue:
https://paste.yunohost.org/joguzazede.coffeescript
[20:48:09]
<Aleks (he/him/il/lui)> @_@
[20:48:40]
<Aleks (he/him/il/lui)> i would try adding `127.0.0.1 muc.campfire.wheremymonkeyis.at` inside /etc/hosts ...
[20:50:50]
<hook> same for `xmpp-upload`, I suppose?
[20:51:56]
<hook> I’ll add just muc and see if that was fine. One step at a time
[20:53:44]
<hook> https://xmpp-upload.campfire.wheremymonkeyis.at/upload/dZEARzucWtmJ2823/78RPMJellaby.jpg
[20:53:52]
<hook> It worked!
[20:55:35]
<hook> Aleks (he/him/il/lui), sweet! Can I help with anything to get it included?
[20:56:06]
<Aleks (he/him/il/lui)> well you tested it so that's good
[20:56:18]
<Aleks (he/him/il/lui)> and then at some point i guess we really need to dig how to handle the damn /etc/hosts @_@
[20:56:27]
<hook> Also, if I keep the modified `certificate.py` and `/etc/hosts` will it be properly overriden when the update comes, or should I clean things up?
[20:59:18]
<Aleks (he/him/il/lui)> /etc/hosts won't be overwritten
[20:59:37]
<Aleks (he/him/il/lui)> certificate.py will be but the patch probably will be in the next upgrade anyway
[21:00:26]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/pull/1763
[21:00:51]
<hook> So, nothing I need to clean up?
[21:01:10]
<Aleks (he/him/il/lui)> nope
[21:02:11]
<hook> 👍
[21:32:18]
<hook> Aleks (he/him/il/lui), BTW, are these warnings something I can do about, or just ignore them?
```
Warning: The configuration file '/var/www/.well-known/{$domain}/autoconfig/mail/config-v1.1.xml' has been manually modified and will not be updated
```
[21:33:32]
<Aleks (he/him/il/lui)> mh
[21:33:43]
<Aleks (he/him/il/lui)> yeah classic, don't worry too much about those
[21:34:03]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/issues/issues/2300
[21:34:31]
<Aleks (he/him/il/lui)> that's a glitch in the regenconf system, gotta dig it at some point but it's not really like creating actual problems
[21:35:58]
<hook> Got it.
[21:41:44]
<hook> There’s also a warning about DNS hairpining. I have a local DNS pointing to the local IP instead. I know I can simply ignore that warning, but is that something YunoHost could detect and take into account, or does it have any downsides that would be better to avoid anyway?
[21:57:51]
<Aleks (he/him/il/lui)> it's something to do with your router, it's not something yunohost can magically fix (and i doubt there's a setting to magically fix things in your router either)
[21:58:10]
<Aleks (he/him/il/lui)> it's really just a warning like "don't be super surprised if you have trouble contacting your server from inside the local network"
[21:58:35]
<hook> I know it’s a router thing and Yuno can’t do anything about it.
[21:58:43]
<Aleks (he/him/il/lui)> like "your router is crap" idk, never understood why they implement / dont implement hairpinning
[21:59:50]
<hook> Just saying that instead of setting up hairpining on my (Mikrotik) router, I used static DNS rules on it instead.
[22:00:49]
<hook> Is there any downside of that?
[22:01:23]
<hook> I imagine I could not use PiHole (or similar) on the YunoHost server then. But anything else?
[22:03:55]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯ dunno, network is hell of a drug