It was fine until I installed the turn server to enable WebRTC
Its a google cloud server, under Firefall but I open the ports and test with netcat, just like the tutorial says.
Potential problems described below:
# IP does not match:
# IP from ifconfig: 10.142.0.2
# /etc/nginx/sites-available/bigbluebutton: live.MYSITE.com
# Warning: API URL IPs do not match host:
#
# IP from ifconfig: 10.142.0.2
# /var/lib/tomcat7/webapps/demo/bbb_api_conf.jsp: live.MYSITE.com
# Not running: LibreOffice
....................
# Error: Could not connect to the configured hostname/IP address
#
# https://live.MYSITE.com/
#
# If your BigBlueButton server is behind a firewall, see FAQ.
# Warning: The setting of EXTERNAL-IP for proxy_pass in
#
# /etc/bigbluebutton/nginx/sip.nginx
#
# does not match the local IP address (10.142.0.2).
# (This is OK if you've manually changed the values)
# Warning: The API demos are installed and accessible from:
#
# https://live.MYSITE.com/demo/demo1.jsp
#
# These API demos allow anyone to access your server without authentication
# to create/manage meetings and recordings. They are for testing purposes only.
# If you are running a production system, remove them by running:
#
# sudo apt-get purge bbb-demo
I'm the product manager for BigBlueButton. I think you've already asked this question in our GitHub account and we're responding there
https://github.com/bigbluebutton/bigbluebutton/issues/6459
Rather than have us respond in two places, let's continue the discussion at the above link.
Related
I already have pointed domain's A/AAAA records point to my server's IP address and I do see Caddy home page when I put my server's IP address in the browser but not with domain name.
Not sure if my Caddyfile changes are even getting reloaded.
Hit in browser:
http://10.20.30.40 -- I see Caddy home page when I hit my machine's ip address
http://www.mytekworld.com -- The browser just keeps spinning when I hit the domain name
https://www.mytekworld.com -- The browser just keeps spinning when I hit the domain name
sudo nano /etc/caddy/Caddyfile
# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace the line below with your
# domain name.
www.mytekworld.com
# Set this path to your site's directory.
root * /usr/share/caddy
# Enable the static file server.
file_server
# Another common task is to set up a reverse proxy:
# reverse_proxy localhost:8080
# Or serve a PHP site through php-fpm:
# php_fastcgi localhost:9000
# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile
--Reload caddy
caddy reload
sudo systemctl reload caddy --caddy.service is not active, cannot reload.
Firewall status:
Status: active
To Action From
-- ------ ----
[ 1] 22000 ALLOW IN Anywhere
[ 2] 80,443/tcp ALLOW IN Anywhere
[ 3] 8080 ALLOW IN Anywhere
[ 4] 22786 (v6) ALLOW IN Anywhere (v6)
[ 5] 80,443/tcp (v6) ALLOW IN Anywhere (v6)
[ 6] 8080 (v6) ALLOW IN Anywhere (v6)
This appears to be a DNS issue.
Make sure your A record looks something like this
A 10.20.30.40
If your A record is formatted properly please update your question with the DNS record and your DNS provider (Cloudflare, Netlify, Godaddy, etc.)
I was actually doing some quick labs exercise when I noticed this issue where is ping to an internal IP works but if I ping with machine name it does not work. Here is what I did:
a.) Create a GCP project. Leave all the default firewall rules in place
b.) Create a VM in us-central-1 (any region) call it - mynet-us-vm
c.) Create a VM in eu-west-1 (any region) - call it - mynet-eu-vm
d.) SSH to mynet-us-vm from the console
e.) Run this commands : ping -c 3 <Enter mynet-eu-vm's internal IP here>- It works
f.) Run this command: ping -c 3 mynet-eu-vm - Does not work! Getting below error
Getting Error:
"ping: mynet-eu-vm: Name or service not known"
For Internal DNS resolution to work there are multiple factors that affect this:
On the client Instance running ping the resolv.conf file must have the metadata server (169.254.169.254) as it’s nameserver and the search domains must be set similarly to the example on the documentation, if using a Google provided image this configuration should already be set correctly.
Additionally, verify the hostname registered for the Instance “mynet-eu-vm” this can be done by running curl against the metadata server, the output to this will be the full FQDN which will confirm whether the resolv.conf file should be set to Zonal DNS or Global DNS and if the hostname for the Instance is the same as the one being used with ping.
If running “dig FQDN #169.254.169.254” works but ping still fails this would mean that the Instance is trying to resolve against a different nameserver, or that the search list on resolv.conf is incorrect.
If the above steps fail I suggest raising a support case with Google Cloud Platform or opening a new Public Issue Tracker since following the steps provided does not result in the same behavior and likely it’s something specific to your setup.
I'm following this Adafruit tutorial with the end goal of setting up a portable Tor routed WiFi access point. I did this entire tutorial start to finish yesterday on the same Pi 3 running Raspbian Jessie, and it worked perfectly.
However, due to SD card size restrictions (I'm on a tight budget and I need to make quite a few) and the fact that I don't want a GUI, I decided to start again but with Raspbian Jessie Lite (using the last Jessie release before Stretch), and now I can't seem to get past the HostAPD setup when I'm following the tutorial line for line and using the same Pi 3!
THE PROBLEM:
When I get to the "First Test" part of the tutorial and run HostAPD for the first time I should get an output something like this:
But instead I get this:
user0#raspberrypi:~ $ sudo /usr/sbin/hostapd /etc/hostapd/hostapd.conf
Configuration file: /etc/hostapd/hostapd.conf
Failed to create interface mon.wlan0: -95 (Operation not supported)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr b8:27:eb:41:64:5e and ssid "Extrea-Special-Wifi"
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED
The tutorial (and multiple other sources) says that if I'm using the built-in Wi-Fi module, I don't need to specify a driver for it (It worked yesterday without a driver specified too) but something is not working this time and the only thing I've changed is the OS from Jessie to Jessie Lite.
My laptop and other devices can see and connect to the network but there is no internet. Of course I can ping the Gateway IP but not the DNS 8.8.8.8.
My HostAPD config file is the same as the tutorial's and is as follows:
interface=wlan0
#driver=rtl871xdrv
ssid=Extrea-Special-Wifi
country_code=GB
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=Password123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_group_rekey=86400
ieee80211n=1
wme_enabled=1
note: Password123 is not a password that I use and it will be changed!
My /etc/network/interface file is not quite the same as the tutorial but worked yesterday like this:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.42.1
netmask 255.255.255.0
I realise that the this file says:
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
But it worked fine on the full version of Jessie (Latest release too)
and if this is the cause of the problem I'm really not sure how to make this tutorial work with the /etc/dhcpd.conf file.
My /etc/sysctl.conf is set up as follows:
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
#kernel.domainname = example.com
# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3
##############################################################3
# Functions previously found in netbase
#
# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1
# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1
###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#
net.ipv4.ip_forward=1
The bottom of this file seems to be missing 2 lines that are visible in the screenshot from the tutorial however I didn't add them yesterday because the tutorial doesn't even mention them (as I said, yesterday I managed to get the Pi working perfectly as a Tor Routed access point using exactly the same steps).
Screenshot from the tutorial:
I'm in the process of testing GC DNS and have created zones and records. However, doing nslookup (windows/command line) times out when querying assigned Google NS directly:
> www.some_domain_A_record.com.
Server: ns-cloud1.googledomains.com
Addresses: 2001:4860:4802:32::6e
216.239.32.110
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to ns-cloud-e1.googledomains.com timed-out
Does anyone have any advice/input on this?
Notes:
I am only using Cloud DNS for this project (no GCE/GAE/VM, etc.), essentially "just DNS". I'm looking to migrate from some existing DNS (only) provider to Google cloud DNS
This means resources (A, CNAME, MX, etc.) aren't necessarily related to any GC hosted app or service (some could be - e.g. Google Apps/Work, etc.). In other words "typical" DNS zone/records.
This is for an existing/live domain/zone
I have not made any changes at the registrar level (I'm testing first) and querying the google ns assigned for the zone directly
To SO community:
Completely understood that this isn't a programming question. Its just that this is the "Bronze" level support area for Google.
Update
Using Mac terminal actually succeeds
> server
Default server: ns-cloud1.googledomains.com
Address: 216.239.32.106#53
> gcloud-test.some_domain_I_have.com.
Server: ns-cloud1.googledomains.com
Address: 216.239.32.106#53
gcloud-test.some_domain_I_have.com canonical name = the_right_target.com.
Name: the_right_target.com
Address: 1.2.3.4
Will dig some more, seems something to do with Windows nslookup..weird...it's not some firewall, I can nslookup some other domain using whatever specific (or public) name server.
Update 2
Getting weirder - Windows (10 not that it should matter) on same Mac (vm/parallels) above works fine as well...
Update 3
As of today 9-24-2015 it seems the odd behavior on Windows nslookup (interactive mode) when querying your assigned Google ns directly is resolved.
Bottom line: All's good and running quite smoothly! To the Google Cloud I go :)
On (all*) Windows - it just seems that if you have/want to query your assigned Google NS directly, you have to do nslookup in non-interactive mode (aka "one liner") as shown below. You'll do this if you want to check/query resources before DNS propagation (after which, you don't really need to query your assigned NS directly).
Alternatively, you could nslookup interactive mode if you use the IP address of your assigned Google NS (sample also below).
*"all Windows" - meaning host/pc and OS. As above, Windows on Mac (VM/Parallels) is strangely unaffected by this weirdness - you can use nslookup interactive mode and query your ns directly just fine...Mac/OSX terminal is fine/unaffacted
Partial answer, scoped to Windows:
To make it work,
use nslookup in non-interative mode: nslookup name-of-resource the-google-ns
e.g. nslookup foo.com ns-cloud1.googledomains.com
or
use the IP address of the google ns in interactive mode:
c:\nslookup
> server 216.239.32.106
Default Server: ns-cloud-a1.googledomains.com
Address: 216.239.32.106
> the_resource_to_lookup
As to "why", I'll defer to network folk - haven't worn that hat in years -seems something to do with PTR/reverse lookup, but that's just a guess...
Looking at your inquiries, on your Windows you're using ns-cloud-e1.googledomains.com as the name server, however on your Mac you're using ns-cloud1.googledomains.com which is ns-cloud-a1.googledomains.com.
If both inquiries are for the same zone, then time-out on the first nslookup inquiry makes sense. Your workaround used a correct DNS server for the nslookup inquiry.
The solution is modifing your Windows DNS settings from ns-cloud-e1.googledomains.com to ns-cloud-a1.googledomains.com (same DNS settings of your Mac).
Using the Developers Console, under Cloud DNS you can verify what DNS servers your zone is associated to.
If you deleted a VM on Google Compute Engine on a Centos 6 Cpanel server and then create it with the same disk, you often are assigned a new local IP address even if you kept the static IP. This does not properly update in the NAT configuration on Cpanel/WHM servers.
This stops any sites from working and the only way to fix it is manually edit the http.conf file. Inside Web Host Manager you can fix the public facing IP, but there is no place to edit the local IP. Does anyone know how to edit the nat configuration on centos 6 on Google Compute Engine to fix the local IP so that all new sites created will have the correct local IP in the http.conf?
Here is a pic of the current nat configuration on my Centos 6 server.
Here is a pic showing my correct local IP in Compute Engine, you can see it does not match the one Cpanel has, which causes the http.conf file to generate new virtual hosts with the wrong IP.
Its a configuration issue within WHM/Cpanel that can not be corrected with any configuration settings in the interfaces. I contacted Cpanel Support and they provided me with a command line shell script to run from root to fix the issue. It worked flawlessly:
# /scripts/build_cpnat
This resolved the issue, but they gave this additional info if that does not solve your problem:
If this does not resolve your issue, please review our NAT
documentation and ensure that your server is configured in a supported
1:1 NAT configuration:
http://documentation.cpanel.net/display/ALD/1%3A1+NAT
The Compute Engine does not allow you to create an instance with a specific network IP address. You will have to use a combination of routes and an instance's --can-ip-forward ability to add an IP address as a static network IP address that then maps to your desired virtual machine instance.
For example, if you want to assign 10.1.1.1 specifically as a network IP address to a virtual machine instance, you can create a static route that sends traffic from 10.1.1.1 to your instance, even if the instance's network IP address assigned by Compute Engine doesn't match your desired network IP address.
Take a look at this link: https://cloud.google.com/compute/docs/instances-and-network#staticnetworkaddress
The best and the simplest solution for this is to use the WHM/Cpanel IP Migration Wizard option to change the existing Private IP with the new one and then wait for few hours to make those changes propagate and you will see the new Private IP and Public IP in sync in your WHM platform.
I had the same issue with AWS and CentOS 7 hosting latest WHM/ cPanel. each time the instance restarts then a new private/ local IP address. I deleted cpnat from /var/cpanel/.
So I disabled the NAT, then I created another eth so I can configure it with static IP which is the Public IP, then for the main account only which own the hostname and domain name for WHM I assigned it to the local IP address, but as the local IP address keep changing so I created a script fires up at the start after each boot collecting the new local IP address and assign it automatically to the main account and if there is no new local IP address then the script exit without doing anything.
here are the steps been done:
nano /etc/sysconfig/network-scripts/ifcfg-eth0:cp1
and inside that file put the following: (change IPADDR & DNS)
DEVICE="eth0:cp1"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="13.54.100.XX"
NETMASK="255.255.255.0"
DNS1="172.31.0.2"
TYPE="Ethernet"
IPV6INIT="no"
now we would like this interface to stay upon reboot and start on the reboot so run:
ifup eth0:cp1
then restart the network service by:
service network restart
now disable NAT mode by deleting the file cpnat in /var/cpanel
now check the file /var/cpanel/mainip and make sure our external ip is there 13.54.100.XX
create the following file with nano:
nano /etc/init.d/fixdhcp
add the following to the file and save it:
#!/bin/bash
# # This script assigns available DHCP IP to ACCOUNT-NAME user on Reboot or Restart, please change ACCOUNT-NAME to the main WHM domain account name
# apache service will restart when done.
/scripts/rebuildippool
export mydhcp10=$(cat /etc/ipaddrpool)
echo $mydhcp10
# Exit if no available IPs
if [ "${mydhcp10}" == "" ]; then
echo "ipaddrpool is empty" && exit 1
else
echo "ipaddrpool is not empty"
fi
/usr/local/cpanel/bin/setsiteip -u ACCOUNT-NAME $mydhcp10
chmod +x /etc/rc.d/rc.local
echo finished now restarting services
/scripts/rebuildhttpdconf
/scripts/rebuildippool
/scripts/cleandns
/scripts/fixvaliases
/scripts/modify_accounts --theme=paper_lantern --all-users
/usr/local/cpanel/scripts/updateuserdomains
service httpd restart
make the file excutable:
chmod +x /etc/init.d/fixdhcp
add it to rc.d
nano /etc/rc.local
then add it like this:
/etc/init.d/fixdhcp
save then run:
chmod +x /etc/rc.d/rc.local
If it still won't change, try this:
(i.e. when you List Accounts you see the old internal IP listed for each account)
WHM -> List Accounts expand desired account (+)
=> Change IP Address
=> select the IP address (even if it is the same external IP)
=> click change.
repeat for each affected account.
output:
The remote dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 10.240.0.3.
The current ip in the dns zone is: 104.154.68.68!
104.154.68.68 will be switched to the new ip as well!
The local dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 10.240.0.3.
The current ip in the dns zone is: 10.240.0.2!
10.240.0.2 will be switched to the new ip as well!
Warning, serious database inconsistency. httpd.conf, local dns, and remote dns all
have different ideas about what the ip address of this site really is. They will now all be changed
to the new ip: 10.240.0.2!
Changed all instances of [10.240.0.3,104.154.68.68] -> [104.154.68.68] in dcmetroc.kellen.hosting
Changed all instances of [10.240.0.3,104.154.68.68] -> [104.154.68.68] in dcmetrocollaborative.org
Updating httpd.conf....Done
System has 0 free ips.
if you're using nginx, don't forget to rebuild vhosts in ngnix plugin!
I just needed to change the local IP with the new one in:
/var/cpanel/cpnat
/etc/hosts
/etc/ips.dnsmaster