search

bigbluebutton / bbb-install

BASH script to install BigBlueButton in 30 minutes.
GNU Lesser General Public License v3.0
618 stars 542 forks source link

Add option for to specify external IP address #289

Open ffdixon opened 4 years ago

ffdixon commented 4 years ago

For some installations behind the firewall, such as on a LXC container, bbb-install.sh can't determine the external IP address of the VM.

Add a parameter -x <external_IP> to allow the administrator to specify the external IP address.

EmmyGraugans commented 4 years ago

That could be a good idea and would also solve problem #304 (setting wrong/internal network IP-address as first)

ibrahim-quraishi commented 4 years ago

Let me try an install with this option -x although my installation is giving ICE error
The issue described on this link https://github.com/bigbluebutton/bbb-install/issues/304

Davka commented 4 years ago

According to the document -x means "Use Let's Encrypt certbot with manual dns challenges (optional)"

cpimentel25 commented 3 years ago

hello @ffdixon, in AWS EC2 instance the external ip is known as "Public IPv4 addresses and external DNS hostnames".

Being the case where we have bigbluebutton installed in the serious instance, example: - x ec2-203-0-113-25.compute-1.amazonaws.com

EmmyGraugans commented 3 years ago

Wouldn't the absolute easiest way be, to use EXTERNAL_IP4=$(curl -s http://ipv4.icanhazip.com) EXTERNAL_IP6=$(curl -s http://ipv6.icanhazip.com)

(And if one doesn't want to rely on an external website, set up an own "get-ipv4.bigbluebutton.org" that reflects only a single line with the asking IP-Adress...)

agrimpelhuber commented 3 years ago

I second this motion (no, not another "have this issue, too") only to point out that the algorithm for IP detection seems to be broken in bbb-install.sh for the "venet0:0" case under Ubuntu 18.04.5 LTS. My BBB runs on a hosted virtual machine (Virtuozzo), but nevertheless has a static, dedicated IPv4 address.

The following expression from bbb-install.sh, even fixed from #304 (?), returns "inet" instead of "111.111.9.23" as the IP address. This ends up in all sorts of configuration files, and breaks the installation. Changing the expression to awk '{ print $2}' in a local copy of bbb-install.sh returns the correct IP, but the install still ends up with a few occurrences of 'inet' in the configuration files, probably due to the fact that bbb-conf suffers from the same flaw.

https://github.com/bigbluebutton/bbb-install/blob/856c5da3e62552fe218f0fb4cd23c0bd7eb65b25/bbb-install.sh#L457

and the same in bbb-conf

Sorry that I cannot go deeper into details, because after having spent a day with manually fixing this, I ran out of time to document each and every occurrence of "inet". Best way IMHO is to fix this at the source - best with a better IP detection and a manual override option, which would have to make it into bbb-conf, too.

In case somebody wants to test this, this is the output of ifconfig (almost ... 111.111 has been changed to disguise the real IP). The rest is generic docker stuff after the install.

root@vXXXXX:~# ifconfig
br-1065ebe2f9fc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.24.0.1  netmask 255.255.0.0  broadcast 172.24.255.255
        inet6 fe80::42:54ff:fe81:f798  prefixlen 64  scopeid 0x20<link>
        ether 02:42:54:81:f7:98  txqueuelen 0  (Ethernet)
        RX packets 2311  bytes 7338541 (7.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2184  bytes 700393 (700.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:6fff:fed0:5d63  prefixlen 64  scopeid 0x20<link>
        ether 02:42:6f:d0:5d:63  txqueuelen 0  (Ethernet)
        RX packets 36067  bytes 2133742 (2.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 334476  bytes 498306495 (498.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2286063  bytes 429544346 (429.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2286063  bytes 429544346 (429.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
        inet 127.0.0.1  netmask 255.255.255.255  broadcast 0.0.0.0  destination 127.0.0.1
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)
        RX packets 1873059  bytes 2136534357 (2.1 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1085447  bytes 151928450 (151.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
        inet 111.111.9.23  netmask 255.255.255.0  broadcast 111.111.9.255  destination 111.111.9.23
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)

veth60644ad: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5c20:d8ff:fe02:debc  prefixlen 64  scopeid 0x20<link>
        ether 5e:20:d8:02:de:bc  txqueuelen 0  (Ethernet)
        RX packets 1211  bytes 787567 (787.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1470  bytes 202173 (202.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethf6a44fa: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::1c2f:afff:fe04:df69  prefixlen 64  scopeid 0x20<link>
        ether 1e:2f:af:04:df:69  txqueuelen 0  (Ethernet)
        RX packets 3733  bytes 7570496 (7.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3398  bytes 1488170 (1.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
ffdixon commented 3 years ago

Thanks @agrimpelhuber for sharing your analysis.

michi-80337 commented 3 years ago

Issue #379 goes into the same direction. Please drop me a note if You need help for clean IP address syntax checking and adding the code to parse some new option in the main routine of bbb-install.sh ...

michi-80337 commented 3 years ago

In regard to the ifconfig parsing problem: It looks like the output of ifconfig has changed between Ubuntu 16.04.7 LTS and more recent distributions. This might be caused by a replacement of the original net-tools package by wrappers that use the iproute2 package. I looked at an Ubuntu 20.04.2 LTS with net-tools package installed and everything is fine there. If I look at an current openSUSE Distribution, I get an output similar to the one cited above while everything is like the bbb-install.sh expects on older openSUSE installations. So, there was a change in ifconfig output some time ago, ...

michi-80337 commented 3 years ago

@agrimpelhuber could you please check, if following code snippet retrieves the correct IP address at your system?

(INTERFACE=$(ip r s | grep -e "^default " | sed -e "s/\(.* dev \)\([^ ]*\)\(.*\)/\2/"); ip a s $INTERFACE | grep -w -e "inet" | grep -e " $INTERFACE$" | sed -e "s/\(.*inet \)\([^ /]*\)\(.*\)/\2/")

The snippet lists the routes, filters out anything but the default route and pulls the interface name from the result. In a second step it lists all IPv4 addresses assigned with the interface, throws away any secondary IP addresses and pulls out the address from the result. Yes, it's awful. ...

agrimpelhuber commented 3 years ago

@michi-80337, yes and no. It returns 127.0.0.1, the loopback address. In case that's not what you want, I'll try to break it down expression by expression:

ip r s | grep -e "^default " | sed -e "s/\(.* dev \)\([^ ]*\)\(.*\)/\2/")

returns the "venet" interface, fair enough. The second expression

ip a s $INTERFACE

returns

2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 111.111.9.23/24 brd 111.111.9.255 scope global venet0:0
       valid_lft forever preferred_lft forever

I'm not sure what we want from this - the 127.0.0.1 loopback ip, or the 111.111.9.23 global scope?

michi-80337 commented 3 years ago

The code in the bbb-install script assumes, that the default route directs the data over the interface with the external IP address the script is looking for. The original code uses grep -v 127.0.0.1 to remove the loopback address, and the following tail command retrieves the last secondary address assigned to the venet0 interface.

The primary address of the device venet0 is 127.0.0.1 in your case but the default route was assigned to the secondary ip address (venet0:0) in 111.111.9.0/24, I suppose.

My hope was to get an output like default via 111.111.9.xyz dev venet0:0 from the ip route show command on your system. I think, this was a little bit naive. ...

While it is possible to match the IP address from the ip route show command to the expression in the inet lines in the ip address show command, it is some effort to do so with a shell script.

EmmyGraugans commented 3 years ago 
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 111.111.9.23/24 brd 111.111.9.255 scope global venet0:0
       valid_lft forever preferred_lft forever

Well, in that case it would be easy enough to add a few characters to the command of @michi-80337 : Instead of grep -w -e "inet" write grep -w -e "inet.*scope global". I am not entirely sure why you want to have another grep -e $INTERFACE though. Both on my computer and according to the output from @agrimpelhuber that doesn't seem to be necessary.

Complete line again:

(INTERFACE=$(ip r s | grep -e "^default " | sed -e "s/\(.* dev \)\([^ ]*\)\(.*\)/\2/"); ip a s $INTERFACE | grep -w -e "inet.*scope global" | sed -e "s/\(.*inet \)\([^ /]*\)\(.*\)/\2/")

(I personally would still vote for curl -s http://ipv4.icanhazip.com, but anything is better than the current state!)

agrimpelhuber commented 3 years ago

to maybe simplify (or maybe complicate) your effort (thanks btw!), I want to point out one thing from my original remark that may have been lost:

Changing the expression to awk '{ print $2}' in a local copy of bbb-install.sh returns the correct IP

That means the original expression misses the "venet0:0" IP by just a fraction. I don't know what the ifconfig output looked like when the expression was originally written, and whether that original ifconfig output is still around (considering that BBB is very strict on the supported distro), but couldn't this be a fix?

Alternatively, couldn't you just grab the first IP (regardless of it's position in the line) with a "[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*" regex? That would both replace the 'awk { print $2}' suggested above as well as any other situations where 'awk { print $1}' might still be valid.

michi-80337 commented 3 years ago

I'm currently testing the two patches, you find in the comments above. The first patch will add an option to manually set the IP adress, and the second one will rework the automatic IP adress detection. If they work as expected, I will create a pull request here.

EmmyGraugans commented 3 years ago

The following expression from bbb-install.sh, even fixed from #304 (?), returns "inet" instead of "111.111.9.23" as the IP address. This ends up in all sorts of configuration files, and breaks the installation. Changing the expression to awk '{ print $2}' in a local copy of bbb-install.sh returns the correct IP, but the install still ends up with a few occurrences of 'inet' in the configuration files, probably due to the fact that bbb-conf suffers from the same flaw.

The problem (and a big part of it) is, that there are THREE places (one of which with many sub-places) in which the external IP-address gets determined.

  1. bbb-install.sh
  2. bbb-conf
  3. Debian-Packaging, see bigbluebutton/bigbluebutton#12262

In all of these instances, there are two lines of IP=...., depending on the presence of a "venet" or not.

So, to summarise, there are at least six(!) places for determining the IP-Address and only two of these are fixed (in #286 and in bigbluebutton/bigbluebutton#10900)... Worse, two of these can be fixed not by a pull-request but only by the packaging-team, since unfortunately the packaging is still not public (though there is apparently an effort under way to get the packaging public).

Edit: had a wrong issue fpr the debian-packaging linked)

asim-quadri commented 3 years ago

Hi all, Can anyone please help me, I am facing this error since three days.

Iam getting below error when iam running "sudo bbb-conf --restart"

Potential problems described below

................................................................................ curl: (7) Failed to connect to 123.136.94.11(My ip) port 80: Connection timed out

Error: Could not connect to the configured hostname/IP address

#

http://123.136.94.11/

#

If your BigBlueButton server is behind a firewall, see FAQ.

curl: (7) Failed to connect to 123.136.94.11 port 80: Connection timed out

Error: Unable to reach default URL for presentation:

#

http://123.136.94.11/default.pdf

#

Check value for beans.presentationService.defaultUploadedPresentation in

/usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties and /etc/bigbluebutton/bbb-web.properties