[08:51:10]
<cptcurk> @·☽•Nameless☆•777 · ± ça voudrait dire qu'avec deux Yunohost, et garage installé dessus, je pourrais avoir une redondance des données et donc un double de bande passante aussi (par exemple pour offrir un service de vente d'image stock.)
Je recherche un système similaire, pour éventuellement faire un second peertube également et pour aider avec la bande passante et les calcules là aussi !!!
[09:32:33]
<@err404:matrix.numericore.com> Pour peertube il existe les ''remote runner'' pour le transcodage
[10:39:11]
<·☽•Nameless☆•777 · ±> Si tu veux plus d'infos, je te conseille de poser tes questions ici #garage:deuxfleurs.fr, ils sauront mieux te renseigner que moi je pense =)
[10:39:24]
<·☽•Nameless☆•777 · ±> Garage sert uniquement pour avoir des sauvegardes sur plusieurs sites,
Genre avoir une copie de tes données chez toi,
chez des amis et une autre sur un vps par exemple.
( il lui faut au moins 3 nodes* pour faire un cluster )
[10:39:45]
<·☽•Nameless☆•777 · ±> Garage sert uniquement pour avoir des sauvegardes sur plusieurs sites,
Genre avoir une copie de tes données chez toi,
chez des amis et une autre sur un vps par exemple.
( il lui faut au moins 3 nodes* pour faire un cluster , donc 3 yunohost avec garageHQ)
[14:04:33]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, everything else seems to be in `/etc/yunohost/apps/conduit`
Looking at the forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (MISSING_MATRIX_RTC_FOCUS). I could make a post about it there.
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why this error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
[14:05:18]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
Looking at the forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (MISSING_MATRIX_RTC_FOCUS). I could make a post about it there.
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why this error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
[14:05:52]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why this error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
Looking at the YunoHost forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (`MISSING_MATRIX_RTC_FOCUS`). I could make a post about it there.
[14:07:53]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why the `MISSING_MATRIX_RTC_FOCUS` error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
Looking at the YunoHost forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (`MISSING_MATRIX_RTC_FOCUS`). I could make a post about it there.
[14:11:08]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why the `MISSING_MATRIX_RTC_FOCUS` error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
Looking at the YunoHost forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (`MISSING_MATRIX_RTC_FOCUS`). I could make a post about it there.
More Information that may be helpful: I initially set up this server by downloading Conduit via the YunoHost panel on a subdomain, then I configured the TURN server that is required for VOIP. I have not messed around with the configuration files much, until recently (to figure this issue out). Regular chatting works, just not VOIP. There is a chance that .well-known isn't the issue, exactly, but I highly suspect that it is due to the results I got back from testmatrix.
[14:11:52]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why the `MISSING_MATRIX_RTC_FOCUS` error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
Looking at the YunoHost forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (`MISSING_MATRIX_RTC_FOCUS`). I could make a post about it there.
More Information that may be helpful: I initially set up this server by downloading Conduit via the YunoHost panel on a subdomain, then I configured the TURN server that is required for VOIP. I have not messed around with the configuration files much until recently (to figure this issue out). Regular chatting and other features work as intended, just not VOIP. There is a chance that .well-known isn't the issue, exactly, but I highly suspect that it is due to the results I got back from testmatrix.
[14:14:35]
<colm> https://aria.im/_bifrost/v1/media/download/AQpwL3eskV2ApONKnYxywNrsRgLxvqufRnHDjotjHs7jwyyxrpdQ-D6lG6HnSFTUs6sUGB0MuXH0pE6ak2cw1DJCea9AO3NQAG1hdHJpeC5vcmcvV0FKRkd1bVd3dUdhWFpKa0JSeU5JSlph
[14:18:16]
<dragon> Thank you for your assistance. I took a look at this, I am wondering... with strings such as `"m.homeserver": { "base_url": "https://__DOMAIN__" },` do you modify `__DOMAIN__` with your own URL? I am unsure if I should or not.
I also poked around within the filesystem and saw:
./nginx/conf.d/domain-name.d:
. .. conduit_server_name.conf my_webapp.d my_webapp.conf
^ (removed server name for the sake of privacy)
I am unsure if this is what you meant by something else lurking, but I also found this in the nginx folder in relation to Conduit (Matrix). everything else seems to be in `/etc/yunohost/apps/conduit`
From what I know from seeing other posts (unrelated to YunoHost) about Matrix servers, .well-known configuration seems to be a part of why the `MISSING_MATRIX_RTC_FOCUS` error occurs, and using testmatrix (even after trying to modify and fiddle around with the configuration) tells me that it can't detect a .well-known configuration...
Looking at the YunoHost forums, I couldn't find anyone talking about my specific issues with Matrix voice/video calls (`MISSING_MATRIX_RTC_FOCUS`). I could make a post about it there.
More Information that may be helpful:
I initially set up this server by downloading Conduit via the YunoHost panel on a subdomain (but the display name is just the base domain), then I configured the TURN server that is required for VOIP. I have not messed around with the configuration files much until recently (to figure this issue out). Regular chatting and other features work as intended, just not VOIP. There is a chance that .well-known isn't the issue, exactly, but I highly suspect that it is due to the results I got back from testmatrix.
[14:24:16]
<paranodal> Hello, sorry for posting an image like that, it was a mistake. I was writing to ask if anybody here could speak to the state of the Ghost ynh package? There seems to be a conflict between the MySQL and MariaDB systems, but the app installs and seems to run fine. Searching the issues does not seem to reveal any problems, am I missing anything? Any reason why I shouldn't use ghost on ynh?
[14:25:28]
<paranodal> I also don't know why I got banned, it was a mistake, I apologies, engaging with Mjolnir Archon in DM was hostile and resulted in deleted messages and no reply...
[14:59:03]
<Aleks (he/him/il/lui)> the message states "incompatibilities may arises", there's not much that can be said. It may work perfectly fine. Or it may suddently burst into fire upon using a specific feature or during a future upgrade. You can read the linked thread for more info or anything that shows up when searching "ghost mysql mariadb" on Google or whatev
[14:59:55]
<Aleks (he/him/il/lui)> MariaDB and Mysql are very similar (since MariaDB is initially a drop-in replacement for MySQL) but there are subtle different that may grow up over time and in specific cases
[15:02:39]
<Aleks (he/him/il/lui)> imho choosing MySQL instead or MariaDB is a shitty choice from the Ghost project. Debian ships MariaDB. It's technically possible to install MySQL specifically but that involves an extra apt repo, and running an additional SQL engine whereas MariaDB already does the job and, in the context of YunoHost, is mutualized with other apps needing a MySQL db so *big urghgh*
[17:11:10]
<netzfetz> 🇩🇪 So Freunde, nachdem ich gestern auch noch meinen conduit zerstört habe, hab ichs dann bleiben lassen. Jetzt also wieder zurück zu meiner Frage: Wie bringe ich meinen Server dazu, die IPv6 vom Provider in seiner Konfiguration zu berücksichtigen? Die Diagnose sagt: Keine funktionierende IPv6. Allerdings habe ich eine, die dem VPS zugewiesen ist. Leider habe ich einfach nichts unter /etc/network/interfaces wie es das tutorial vorschlägt. Kann mir jemand auf die Sprünge helfen?
🇬🇧 So Fellas, after I also destroyed my conduit yesterday, I gave up for the day. Now back to my question: How do I get my server to take the IPv6 from the provider into account in its configuration? The diagnosis says: No working IPv6. However, I do have one assigned to the VPS. Unfortunately, I just don't have anything under /etc/network/interfaces as the tutorial suggests. Can someone help me out?
🇫🇷 Alors les amis, après avoir également détruit mon conduit hier, j'ai laissé tomber. Maintenant, revenons à ma question : comment faire en sorte que mon serveur prenne en compte l'IPv6 du fournisseur dans sa configuration ? Le diagnostic indique : pas d'IPv6 fonctionnelle. Cependant, j'en ai une qui est attribuée au VPS. Malheureusement, je n'ai tout simplement rien sous /etc/network/interfaces comme le suggère le tutoriel. Quelqu'un peut-il m'aider ?
[17:41:15]
<dragon> Ah, I figured it out. I was using testmatrix on the subdomain it was installed on, but the display domain for the matrix server is different (base domain)... it tells me now (properly) that there is no `MatrixRTC SFU` enabled on the server.
I feel silly for making this mistake and overthinking it excessively 'u_u but it's all a learning experience.
[18:09:26]
<netzfetz> I think my brain just stopped working. Theres no interfaces. It doesnt exist.
[18:12:32]
<tituspijean> What's your provider and the output of `ip -br a`? (you may anonymize your IP addresses)
[18:13:46]
<tituspijean> @netzfetz:netzventil.de check your VPS provider's documentation, it might give you some instructions. (example with OVH:https://help.ovhcloud.com/csm/en-gb-vps-configuring-ipv6?id=kb_article_view&sysparm_article=KB0047569, use the "interfaces" method, not "netplan")
[18:16:05]
<netzfetz> Provider is ionos and the command gives me:
guy@server:~$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens6 UP XXX.XXX.XXX.XXX/32 metric 100 XXXX::X:XXXX:XXXX:XXXX/64
ventilator@netzventil:~$
[18:17:57]
<netzfetz> and thanks for your help.
[18:21:41]
<tituspijean> Check this out: https://www.ionos.fr/assistance/infrastructures-serveurs-et-cloud/adresses-ip/ajouter-une-adresse-ipv4-publique-sur-un-serveur/ajouter-une-adresse-ipv4-ou-ipv6-publique-sur-un-serveur-cloud-ubuntu-1804-ubuntu-2004-debian-10-11-et-12/
You may ignore the DNS stuff
[18:25:18]
<netzfetz> Interfaces is just empty. Nothing there.
[18:26:47]
<tituspijean> Is your VPS in their Cloud product line?
[18:30:31]
<tituspijean> if so, I guess you may simply create the file (and add the IPv4 config too)
[18:32:06]
<netzfetz> Yes, exactly. So, just create the interfaces file?
[18:49:19]
<netzfetz> I thing something is just wrong with something between Yunohost and Ionos and im too fixated on that to solve it. I really apriciate your help though. @tituspijean:matrix.org
[18:50:50]
<netzfetz> I got into all this hosting because of YunoHost. Its really awesome and so important to have something that workes very visually and give you some gratification. Thats the spirit of democraticing hosting. Love it. But now I think I might need to get to learn some basics.