[14:01:11]
<trendx> Hi, I'm trying to install metronome after trying jitsi meet but it won't install anymore. Probably because port 5222 is in use by another app. How to solve this?
[14:02:29]
<trendx> I did remove jitsi meet before trying to install metronome
[14:24:58]
<yunohelper> Hi! To help us volunteers help you, read about <a href="https://yunohost.org/en/community/help#how-to-ask-for-help">how to ask for help</a>.<br />Notably, if you are getting an error, share its <em>full</em> log by pasting here the link to the page created by the YunoPaste buttons.<br />Thank you for you patience, and thank you for using YunoHost!
[14:27:13]
<anubis> hello trendx, could you share you logs of the failing Metronome installation?
[14:28:40]
<trendx> https://paste.yunohost.org/raw/nepowiyaya
[14:30:14]
<anubis> can you check what returns `netstat -apn | grep ":5222"` ?
[14:31:54]
<trendx> `tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 1777/lua5.4`
`tcp6 0 0 :::5222 :::* LISTEN 1777/lua5.4`
[14:33:48]
<anubis> `ps aux |grep lua5.4`
[14:34:49]
<trendx> `prosody 1777 0.0 0.1 51640 15472 ? Ss 13:53 0:00 lua5.4 /usr/bin/prosody -F`
`root 19189 0.0 0.0 6344 2220 pts/1 S+ 14:34 0:00 grep lua5.4`
[14:36:29]
<Salamandar> so you got your answer
[14:36:48]
<trendx> no I have no clue as to what this all means
[14:37:13]
<Salamandar> you have prosody installed
[14:37:24]
<anubis> you have already prosody running on your server; both cannot coexist, you have to choose 🙂
[14:38:05]
<trendx> I don'have that anymore
[14:39:49]
<trendx> After upgrading to yh 12 I tried using prosody but it didn't work for me. So I installed metronome (which did work) But I also wanted to use jitsi but that doesn't work with metronome. So now I am back without jitsi but unable to install metronome
[14:40:06]
<anubis> (if you don't know, Metronome was the official/default app in Yunohost; we are now pushing back Prosody as providing a better support; you can try the last version from https://github.com/YunoHost-Apps/prosody_ynh/tree/testing here; which was reported to work with Jitsi)
[14:41:50]
<trendx> Yes I read that but I don't know how to install the testing branch. Is that done through the command line?
[14:43:38]
<trendx> In the instructions it has the `--debug` flag --> I don't know what that does/means
[14:45:01]
<anubis> I would suggest first to remove remains of your current prosody `yunohost app remove prosody`; then install the testing version with `sudo yunohost app install https://github.com/YunoHost-Apps/prosody_ynh/tree/testing --debug` ; the `debug` flag just provides more informations in case of issue.
[14:45:48]
<trendx> ah ok I am going to try that out, thanks a lot for helping me out!
[14:47:14]
<trendx> removing doesn't work because it can't find the app in list of installed apps
[14:48:38]
<trendx> should I try to install the tree/testing version anyway?
[14:50:38]
<anubis> no, first remove the remains; if it was not install via yunohost, try to remove the Debian package `apt remove prosody`
[14:52:43]
<trendx> ok that worked
[14:54:44]
<trendx> yunohost app install https://github.com/YunoHost-Apps/prosody_ynh/tree/testing --debug
152 DEBUG acquiring lock...
164 DEBUG lock has been acquired
175 DEBUG loading python module yunohost.app took 0.010s
175 DEBUG processing action 'yunohost.app.install'
646 DEBUG Using selector: EpollSelector
DANGER! This app is not part of YunoHost's app catalog. Installing third-party apps may compromise the integrity and security of
your system. You should probably NOT install it unless you know what you are doing. NO SUPPORT will be provided if this app doe
sn't work or breaks your system… If you are willing to take that risk anyway, type 'Yes, I understand': Yes
9367 DEBUG action executed in 9.192s
9368 DEBUG lock has been released
9368 ERROR Aborting.
[14:54:44]
<trendx> this is the output result of the install command
[14:56:40]
<anubis> you shall type "Yes, I understand" as requested !
[14:57:07]
<trendx> Oow I'm sorry I see it now.
[14:58:53]
<trendx> should I try to import data from a previous metronome install ?
[14:58:56]
<trendx> or better not?
[15:01:53]
<anubis> If you have relevant datas from Metronome yes, if not, no 🙂
[15:03:10]
<trendx> ah it didn't work
[15:03:26]
<trendx> https://paste.yunohost.org/raw/degicavimu
[15:04:20]
<anubis> run the same firsts commands with 5223 instead of 5222
[15:04:49]
<trendx> tcp6 0 0 :::5223 :::* LISTEN 919/smp-server
tcp6 0 0 188.245.37.166:5223 82.174.66.42:38220 ESTABLISHED 919/smp-server
[15:05:50]
<trendx> 31837 0.0 0.0 6344 2096 pts/1 S+ 15:05 0:00 grep lua5.4
[15:07:13]
<trendx> why does it need port 5223? and not 5222? it is in use by simplex
[15:08:23]
<trendx> because it is a testing branche?
[15:11:23]
<anubis> it looks like a port conflict 😕 5223 is also needed for Prosody for some secured communications
[15:12:26]
<trendx> I will try to remove simplex and try again, see if that works
[15:16:55]
<trendx> Ok prosody is installed, I will take a look and check out if everything works correctly. For now thank you so much for you taking the time to help me out.
[15:25:41]
<anubis> you're welcome, if there is anything, feel free to ask on the dedicated room xmpp:yunohost-xmpp@muc.chapril.org?join or create a topic in the forum.
[15:26:14]
<trendx> will do tjnx again
[15:53:53]
<Facundo> tituspijean Thanks for answering. When I try to access the user dashboard (virtual-IP-of-the-server/yunohost/sso) from the admin dashboard (virtual-IP/yunohost/admin), it redirects to the admin dashboard. When I go directly in the browser to the virtual-IP/yunohost/sso (either using HTTP or HTTPS), the browser communicates an error message: "Error code: NS\_ERROR\_OFFLINE".
I suspect that it is a problem related to DNS and the virtual IP addresses of Zerotier.
[15:57:22]
<Facundo> Hello. I have a problem to remotely enter my YunoHost x86 server from a Android device using a ZeroTier network (previously installed these official apps: ZeroTier and ZeroUI). I can access the admin dashboard with my admin user, but not the user panel. When I enter YunoHost with a standard user without privileges, I cannot access the admin dashboard (which is expected) or the user dashboard (which leaves me perplexed). Does anyone know what is happening?
[16:12:50]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the Yunohost server using a Zerotier network is general (as can be seen here: https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025). I think it is due to a server security mechanism; however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around dnsmasq or SSOwat or NGINX configuration files.
(I do not know where the template is in the forum to correctly publish this problem, if I must do it that way.)
[16:13:09]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the Yunohost server using a Zerotier network is general (as can be seen here: https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025). I think it is due to a server security mechanism; however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around dnsmasq or SSOwat or NGINX configuration files.
[16:15:50]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the Yunohost server using a Zerotier network is general (as can be seen here: https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025). I think it is due to a server security mechanism; however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around dnsmasq or SSOwat or NGINX configuration files.
[16:21:52]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the Yunohost server using a Zerotier network is general (as can be seen here: [https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025]). I think it is due to a server security mechanism (preventing it addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around dnsmasq or SSOwat or NGINX configuration files.
[16:22:25]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the Yunohost server using a Zerotier network is general (as can be seen here: \[https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025\]). I think it is due to a server security mechanism (preventing it addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:23:46]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen here: \[https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025\]).
I think it is due to a server security mechanism (preventing it addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:23:56]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen here: \[https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025\]).
I think it is due to a server security mechanism (preventing it addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:24:45]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing it addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:25:34]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:26:31]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files.
[16:26:41]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
[16:29:27]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN. If someone has solved this problem, I would thank you for sharing it.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions.
[16:29:54]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around **dnsmasq** or **SSOwat** or **NGINX** configuration files. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions. If someone has solved this problem, I would thank you for sharing it.
[16:46:42]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohohost.org/t/how-to-access-applications-on-local-domain-throw-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around `dnsmasq` or `ssowat` or `nginx` configuration files. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions. If someone has solved this problem, I would thank you for sharing it.
[16:51:50]
<Facundo> Hi all. It seems that the difficulty of remotely connecting a client to the user dashboard (seamlessly connection to admin dashboard) of a local domain on the **Yunohost** server using a **Zerotier** network is general (as can be seen [here](https://forum.yunohost.org/t/how-to-access-applications-on-local-domain-through-vpn/31025)).
I think it is due to a server security mechanism (preventing addressing to server via IP); however, the nodes of my Zerotier network are reliable and should access without problems, selectively, as if they were part of the real LAN.
I suspect that the solution is around `dnsmasq` or `ssowat` or `nginx` configuration files. Solving this is equivalent to establishing the only solid route to avoid certain NAT and ISP restrictions. If someone has solved this problem, I would thank you for sharing it.
[22:02:57]
<Klorydryk> https://aria.im/_bifrost/v1/media/download/AWfK8vcsU1U3CkJJ6xyVRyPh4yKpbNAIMbGrKvJ-TxggWOvQMQfjgmwl4kejMRH4bE2_xWvrZwfgDGt-LbbgM8tCeV7jqsnwAG1hdHJpeC5vcmcvanhFV2t0WnhyR0FwQkJ2TnZHdkxXU1dy
[22:03:09]
<Klorydryk> I think something's missing :)
[23:11:15]
<Aleks (he/him/il/lui)> not cat, only flag
[23:28:17]
<Aleks (he/him/il/lui)> Klorydryk: should be fixed in yunohost-admin 12.0.7.1