[jitsi-users] Need Tutoring


#1

Good morning everyone,

I'm looking for some assistance to get Jitsi-Meet up and running
**consistently** using the Google Compute Engine platform. Thus far, I've
gotten the latest stable build running, but frequently crashes after users
have been video chatting anywhere from 1 to 10 minutes. After many issues
on that instance I thought I would try using Debian.

To prevent mailing list spam, I would prefer using some sort of IM or IRC.
I'm on freenode as 'kneeki'. I can pay $50 BTC for some tutoring and help
getting it running well as I doubt this will take more than an hour.

If this kind of post to the mailing list is frowned upon, please let me
know.


#2

50BTC? Are u sure man? Do you really know exchange rate from BTC to USD?

···

El 3/06/2017 4:22 p. m., "David Tacker" <dave@betterlivingpractitioners.com> escribió:

Good morning everyone,

I'm looking for some assistance to get Jitsi-Meet up and running
**consistently** using the Google Compute Engine platform. Thus far, I've
gotten the latest stable build running, but frequently crashes after users
have been video chatting anywhere from 1 to 10 minutes. After many issues
on that instance I thought I would try using Debian.

To prevent mailing list spam, I would prefer using some sort of IM or IRC.
I'm on freenode as 'kneeki'. I can pay $50 BTC for some tutoring and help
getting it running well as I doubt this will take more than an hour.

If this kind of post to the mailing list is frowned upon, please let me
know.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Your best bet is describing your problem on this list.

Boris

···

On 03/06/2017 16:21, David Tacker wrote:

Good morning everyone,

I'm looking for some assistance to get Jitsi-Meet up and running **consistently** using the Google Compute Engine platform. Thus far, I've gotten the latest stable build running, but frequently crashes after users have been video chatting anywhere from 1 to 10 minutes. After many issues on that instance I thought I would try using Debian.

To prevent mailing list spam, I would prefer using some sort of IM or IRC.


#4

Fair enough Boris, here goes!

Currently, I'm running Jitsi-Meet (nightly) on a Debian Jesse Google Cloud
Instance. I am using a wildcard SSL certificate which I pointed the
installer to during setup. When attempting to access the machine
<https://video.betterlivingpractitioners.com/> from the web browser, I'm
given the error: 'This site cannot be reached. Destination unreachable.'.
Checking the logs:

root@jitsi:~# cat /var/log/jitsi/jicofo.log | grep SEVEREJicofo 2017-06-03
20:28:33.432 SEVERE: [15]
org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to
connect/login: XMPPError connecting to localhost:5222.Jicofo 2017-06-03
20:28:33.608 SEVERE: [29] org.jitsi.meet.ComponentMain.call().278
java.net.ConnectException: Connection refused (Connection refused),
host:localhost, port:5347

That error may have occured when I initially installed and ran Jitsi-Meet,
because it seems as though everything is up and running now. Here's the
netstat:

root@jitsi:~# sudo netstat -nptl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN 10473/lua5.1
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 452/sshd
tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 10473/lua5.1
tcp 0 0 127.0.0.1:5347 0.0.0.0:* LISTEN 10473/lua5.1
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 10473/lua5.1
tcp6 0 0 :::5269 :::* LISTEN 10473/lua5.1
tcp6 0 0 :::22 :::* LISTEN 452/sshd
tcp6 0 0 :::8888 :::* LISTEN 10502/java
tcp6 0 0 10.128.0.3:4443 :::* LISTEN 10541/java
tcp6 0 0 :::5280 :::* LISTEN 10473/lua5.1
tcp6 0 0 ::1:5347 :::* LISTEN 10473/lua5.1
tcp6 0 0 :::5222 :::* LISTEN 10473/lua5.1

One thing I find odd however, is that *443* is not listed in the netstat.
Maybe that's no big deal, because tcpdump does report traffic when I try to
load the page:

root@jitsi:~# sudo tcpdump -nnnn port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:43:46.709658 IP 98.151.170.221.47718 > 10.128.0.3.443: Flags [S], seq
367712550, win 29200, options [mss 1460,sackOK,TS
val 3688847323 ecr 0,nop,wscale 7], length 0
02:43:46.709691 IP 10.128.0.3.443 > 98.151.170.221.47718: Flags [R.], seq
0, ack 367712551, win 0, length 0
02:43:49.169856 IP 98.151.170.221.47744 > 10.128.0.3.443: Flags [S], seq
2271559040, win 29200, options [mss 1460,sackOK,TS
val 491254413 ecr 0,nop,wscale 7], length 0

···

On Sat, Jun 3, 2017 at 4:01 PM, Boris Grozev <boris@jitsi.org> wrote:

On 03/06/2017 16:21, David Tacker wrote:

Good morning everyone,

I'm looking for some assistance to get Jitsi-Meet up and running
**consistently** using the Google Compute Engine platform. Thus far, I've
gotten the latest stable build running, but frequently crashes after users
have been video chatting anywhere from 1 to 10 minutes. After many issues
on that instance I thought I would try using Debian.

To prevent mailing list spam, I would prefer using some sort of IM or IRC.

Your best bet is describing your problem on this list.

Boris


#5

That's the first problem to solve. The tcpdump output is consistent with nothing listening on 443, the OS rejects the connection with a RST immediately.

If you're running with nginx restart that and check its logs. Perhaps the configuration is corrupted.

Boris

···

On 03/06/2017 21:47, David Tacker wrote:

Fair enough Boris, here goes!

Currently, I'm running Jitsi-Meet (nightly) on a Debian Jesse Google Cloud Instance. I am using a wildcard SSL certificate which I pointed the installer to during setup. When attempting to access the machine <https://video.betterlivingpractitioners.com/> from the web browser, I'm given the error: 'This site cannot be reached. Destination unreachable.'. Checking the logs:

    root@jitsi:~# cat /var/log/jitsi/jicofo.log | grep SEVEREJicofo
    2017-06-03 20:28:33.432 SEVERE: [15]
    org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to
    connect/login: XMPPError connecting to localhost:5222.Jicofo
    2017-06-03 20:28:33.608 SEVERE: [29]
    org.jitsi.meet.ComponentMain.call().278 java.net.ConnectException:
    Connection refused (Connection refused), host:localhost, port:5347

That error may have occured when I initially installed and ran Jitsi-Meet, because it seems as though everything is up and running now. Here's the netstat:

    root@jitsi:~# sudo netstat -nptl
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 0 0 0.0.0.0:5269 <http://0.0.0.0:5269> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 0.0.0.0:22 <http://0.0.0.0:22> 0.0.0.0:* LISTEN 452/sshd
    tcp 0 0 0.0.0.0:5280 <http://0.0.0.0:5280> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 127.0.0.1:5347 <http://127.0.0.1:5347> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 0.0.0.0:5222 <http://0.0.0.0:5222> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp6 0 0 :::5269 :::* LISTEN 10473/lua5.1
    tcp6 0 0 :::22 :::* LISTEN 452/sshd
    tcp6 0 0 :::8888 :::* LISTEN 10502/java
    tcp6 0 0 10.128.0.3:4443 <http://10.128.0.3:4443> :::* LISTEN
    10541/java
    tcp6 0 0 :::5280 :::* LISTEN 10473/lua5.1
    tcp6 0 0 ::1:5347 :::* LISTEN 10473/lua5.1
    tcp6 0 0 :::5222 :::* LISTEN 10473/lua5.1

One thing I find odd however, is that *443* is not listed in the netstat. Maybe that's no big deal, because tcpdump does report traffic when I try to load the page:


#6

Checked the nginx logs, looks like the SSL certificate required a
passphrase and nginx didn't know where to look for it. I stripped the
password from the .key (for now), and nginx started up without any issues.
Jitsi-meet is now running as well. I'll do some further testing in the
morning to determine if the crashing occurs on the Debian Jessie instance
like it did on the Ubuntu 14.x instance.

···

On Sat, Jun 3, 2017 at 5:21 PM, Boris Grozev <boris@jitsi.org> wrote:

On 03/06/2017 21:47, David Tacker wrote:

Fair enough Boris, here goes!

Currently, I'm running Jitsi-Meet (nightly) on a Debian Jesse Google
Cloud Instance. I am using a wildcard SSL certificate which I pointed the
installer to during setup. When attempting to access the machine <
https://video.betterlivingpractitioners.com/> from the web browser, I'm
given the error: 'This site cannot be reached. Destination unreachable.'.
Checking the logs:

    root@jitsi:~# cat /var/log/jitsi/jicofo.log | grep SEVEREJicofo
    2017-06-03 20:28:33.432 SEVERE: [15]
    org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to
    connect/login: XMPPError connecting to localhost:5222.Jicofo
    2017-06-03 20:28:33.608 SEVERE: [29]
    org.jitsi.meet.ComponentMain.call().278 java.net.ConnectException:
    Connection refused (Connection refused), host:localhost, port:5347

That error may have occured when I initially installed and ran
Jitsi-Meet, because it seems as though everything is up and running now.
Here's the netstat:

    root@jitsi:~# sudo netstat -nptl
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
name
    tcp 0 0 0.0.0.0:5269 <http://0.0.0.0:5269> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 0.0.0.0:22 <http://0.0.0.0:22> 0.0.0.0:* LISTEN 452/sshd
    tcp 0 0 0.0.0.0:5280 <http://0.0.0.0:5280> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 127.0.0.1:5347 <http://127.0.0.1:5347> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp 0 0 0.0.0.0:5222 <http://0.0.0.0:5222> 0.0.0.0:* LISTEN
    10473/lua5.1
    tcp6 0 0 :::5269 :::* LISTEN 10473/lua5.1
    tcp6 0 0 :::22 :::* LISTEN 452/sshd
    tcp6 0 0 :::8888 :::* LISTEN 10502/java
    tcp6 0 0 10.128.0.3:4443 <http://10.128.0.3:4443> :::* LISTEN
    10541/java
    tcp6 0 0 :::5280 :::* LISTEN 10473/lua5.1
    tcp6 0 0 ::1:5347 :::* LISTEN 10473/lua5.1
    tcp6 0 0 :::5222 :::* LISTEN 10473/lua5.1

One thing I find odd however, is that *443* is not listed in the netstat.
Maybe that's no big deal, because tcpdump does report traffic when I try to
load the page:

That's the first problem to solve. The tcpdump output is consistent with
nothing listening on 443, the OS rejects the connection with a RST
immediately.

If you're running with nginx restart that and check its logs. Perhaps the
configuration is corrupted.

Boris