Building Elastix 4 via RPM Repo
-
So https://100.78.250.75/ is bringing up the 500 error?
-
Tried both and yes 500 error
-
Do a telnet on the local box and see if it connects.
telnet localhost 80You might need telnet...
yum -y install telnet -
yep it connects
-
@dom said:
yep it connects
Webserver is definitely up. Chrome loaded your IP and complained about the certificate. I then got this result after accepting the certificate
-
Also http://40.121.19.1 redirects to https://40.121.19.1
-
Did you add an HTTP to HTTPS redirect before getting things working?
-
@scottalanmiller said:
Did you add an HTTP to HTTPS redirect before getting things working?
Elastix does that by default. Always has.
-
@JaredBusch said:
@scottalanmiller said:
Did you add an HTTP to HTTPS redirect before getting things working?
Elastix does that by default. Always has.
Doh. That's right.
-
Azure provides the following:
DNS NAME
pbx77.cloudapp.net
HOST NAME
pbx77
PUBLIC VIRTUAL IP (VIP) ADDRESS
40.121.19.1
INTERNAL IP ADDRESS
100.78.254.76
I access the site and I ssh in using the public vip. When Elastix setup it says:
To access your Elastix System, using a separate workstation (PC/MAC/Linux)
Open the Internet Browser using the following URL:
http://100.78.254.76After the install I did'nt change anything - which files (conf? host?) can I look at to trouble shoot this?
-
Viewing the page source shows your site returning blank.
As this is connecting the ports must be open. But just double check that you've opened the right ports on Azure for this as you have two separate firewalls to deal with here. Azure's firewall is unrelated to the VM's firewall.
-
I opened up the standard ports on azure 80 443 and 22 and the same on centos
firewall-cmd --zone=public --query-port=443/tcp
yes
firewall-cmd --zone=public --query-port=80/tcp
yes -
Okay, just wanted to be sure. I assumed from the error, but better safe than sorry.
-
said:
Open the Internet Browser using the following URL:
http://100.78.254.76Correct me if Im wrong but shouldnt Elastix be configured to use the public vip instead of internal ip - (for example I setup a lamp stack on pbx66.cloudapp.net - no issues.
To access your Elastix System, using a separate workstation (PC/MAC/Linux)
Open the Internet Browser using the following URL:
http://40.121.19.1Do you know which file I can modify to change and test this theory? don't you just hate noobs lol!
-
@dom said:
said:
Open the Internet Browser using the following URL:
http://100.78.254.76Correct me if Im wrong but shouldnt Elastix be configured to use the public vip instead of internal ip - (for example I setup a lamp stack on pbx66.cloudapp.net - no issues.
To access your Elastix System, using a separate workstation (PC/MAC/Linux)
Open the Internet Browser using the following URL:
http://40.121.19.1Do you know which file I can modify to change and test this theory? don't you just hate noobs lol!
No, it should not. Or it is already, depending on how you look at it. Elastix' public IP is the 100.x.x.x number. Then there is another firewall that it knows nothing about and has no interaction with that has the 40.x.x.x. Elastix has nothing to do with that extra router. It doesn't know about it, it can't find out about it and it should not.
Under normal circumstances (normally meaning nothing more than more often than not) you don't expose your PBX to the world, only to your LAN. That's what Elastix is doing. It's telling you how to access it from itself or another machine on your LAN, which could easily be another Azure box.
So it IS configured to use either IP address and it is using its public one. The 100.x.x.x isn't private, like it seems. You are thinking of this like NAT, but that's not what it is.
-
@dom said:
Do you know which file I can modify to change and test this theory? don't you just hate noobs lol!
You cannot, it's theoretically not something to be done nor would it have a purpose, the only person who would ever see that message is someone in a situation for which it is not useful.
-
What errors do you have in the Apache logs?
-
er name
[Thu Mar 10 19:24:23.180141 2016] [ssl:warn] [pid 1304] AH01909: RSA certificate configured for 100.78.250.75:443 does NOT include an ID which matches the server name
[Thu Mar 10 19:30:56.357463 2016] [:error] [pid 1940] [client 38.88.176.226:50122] PHP Fatal error: Uncaught --> Smarty: unable to write file /var/www/html/var/templates_c/wrt56e1cb705739b3_29122777 <-- \n thrown in /usr/share/php/Smarty/sysplugins/smarty_internal_write_file.php on line 46 -
[Thu Mar 10 21:16:37.675087 2016] [suexec:notice] [pid 1292] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using pbx77.cloudapp.net. Set the 'ServerName' directive globally to suppress this message
[Thu Mar 10 21:16:38.036481 2016] [auth_digest:notice] [pid 1292] AH01757: generating secret for digest authentication ...
[Thu Mar 10 21:16:38.037723 2016] [lbmethod_heartbeat:notice] [pid 1292] AH02282: No slotmem from mod_heartmonitor
[Thu Mar 10 21:16:43.374554 2016] [mpm_prefork:notice] [pid 1292] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Thu Mar 10 21:16:43.374606 2016] [core:notice] [pid 1292] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' -
System is certainly working at a basic level.
