Building Elastix 4 via RPM Repo
-
[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=20.1 msYes, this is why I don't understand what is going on!
-
Okay, so you have networking, that is fine.
Now do this: nslookup google.com
-
@scottalanmiller
[root@localhost ~]# nslookup google.com
-bash: nslookup: command not found -
That'll be a problem to fix if yum isn't working, I suppose.
What is the output of:
cat /etc/resolv.conf
-
This post is deleted! -
I fixed the typo in seconds, as fast as my broken touchpad would allow me, but you tested it before I could fix it.
There is no trailing e.
-
@scottalanmiller
Whoops! I didn't notice either!I'll attempt to fix this now, can't understand how/why the install would break this
# Generated by NetworkManager search cloudatcost.com # No nameservers found; try putting DNS servers into your # ifcfg files in /etc/sysconfig/network-scripts like so: # # DNS1=xxx.xxx.xxx.xxx # DNS2=xxx.xxx.xxx.xxx # DOMAIN=lab.foo.com bar.foo.com
-
That would do it, it's blank. No idea why it would break it, but it hasn't broken it other places so it might be something specific to the CloudatCost setup.
FYI: CloudatCost is not viable for a PBX outside of just testing in a lab. Performance issues will cause audio problems and reliability problems will be an issue for a phone system.
You can add the DNS servers directly to this file OR you can use the nmtui command to do so though a text user interface.
-
You can fix this with...
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
-
@scottalanmiller Yep thanks, done that and yes, issues with c@c noted, it's an OK sandbox (or that's the idea) tis all.
Anyway, so still have the 500 issue: 45.62.240.149This seems to have got me in:
sed -i 's/(^SELINUX=).*/\SELINUX=disabled/' /etc/selinux/config
-
@3Mu36 said:
@scottalanmiller Yep thanks, done that and yes, issues with c@c noted, it's an OK sandbox (or that's the idea) tis all.
Anyway, so still have the 500 issue: 45.62.240.149This seems to have got me in:
sed -i 's/(^SELINUX=).*/\SELINUX=disabled/' /etc/selinux/config
That's just disabling SELinux. So that tells us that SELinux is misconfigured here, but why is an important question. You don't generally want to be disabling your security systems.
-
@scottalanmiller said:
@3Mu36 said:
@scottalanmiller Yep thanks, done that and yes, issues with c@c noted, it's an OK sandbox (or that's the idea) tis all.
Anyway, so still have the 500 issue: 45.62.240.149This seems to have got me in:
sed -i 's/(^SELINUX=).*/\SELINUX=disabled/' /etc/selinux/config
That's just disabling SELinux. So that tells us that SELinux is misconfigured here, but why is an important question. You don't generally want to be disabling your security systems.
Because Elastix is crap anymore and they never planned to correctly implement.
-
@JaredBusch said:
@scottalanmiller said:
@3Mu36 said:
@scottalanmiller Yep thanks, done that and yes, issues with c@c noted, it's an OK sandbox (or that's the idea) tis all.
Anyway, so still have the 500 issue: 45.62.240.149This seems to have got me in:
sed -i 's/(^SELINUX=).*/\SELINUX=disabled/' /etc/selinux/config
That's just disabling SELinux. So that tells us that SELinux is misconfigured here, but why is an important question. You don't generally want to be disabling your security systems.
Because Elastix is crap anymore and they never planned to correctly implement.
But we didn't have this SELinux problem with any other install. So I'm not convinced that that is the problem. We certainly did not disable SELinux on our Elastix 4 system and it works just fine.
-
@scottalanmiller said:
@3Mu36 Sounds like you've lost networking. If you cannot reach the outside world then definitely nothing here is going to work. The machine is offline and cannot respond. That would make your issue very different than the other one that we are discussing because the one is online and responding. That SSH keeps working is very odd. So networking is not 100% broken, but something major is.
What is the output of ping 8.8.8.8?
When I ping 8.8.8.8 it just hangs.
Here is the output of my log
Mar 15 16:03:40 pbx77 systemd: Starting Session 2315 of user dom.
Mar 15 16:03:41 pbx77 dbus[643]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Mar 15 16:03:41 pbx77 dbus-daemon: dbus[643]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Mar 15 16:03:41 pbx77 dbus[643]: [system] Successfully activated service 'org.freedesktop.problems'
Mar 15 16:03:41 pbx77 dbus-daemon: dbus[643]: [system] Successfully activated service 'org.freedesktop.problems'
Mar 15 16:03:49 pbx77 su: (to root) dom on pts/1
Mar 15 16:03:54 pbx77 systemd: Stopping The Apache HTTP Server...
Mar 15 16:03:55 pbx77 systemd: Starting The Apache HTTP Server...
Mar 15 16:03:55 pbx77 httpd: 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
Mar 15 16:03:55 pbx77 systemd: Started The Apache HTTP Server.and google lookup
nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53Non-authoritative answer:
Name: google.com
Address: 74.125.22.113
Name: google.com
Address: 74.125.22.100
Name: google.com
Address: 74.125.22.102
Name: google.com
Address: 74.125.22.101
Name: google.com
Address: 74.125.22.139
Name: google.com
Address: 74.125.22.138 -
So pinging hangs but nslookup to 8.8.8.8 works? Sounds to be like you have a networking issue at your firewall. Not the only possibility, of course, but I think that you have something mangling your packets. You know that traffic is getting to 8.8.8.8 as it is responding on on UDP 53. But PING traffic is not making it back. So something is messing with your traffic.
-
@3Mu36 said:
ping fqdn
Weird
ping pbx77.cloudapp.net
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.063 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.098 mswhen I install a standard lamp stack on azure its fine its just this Elastix installation thats a problem
-
@dom said:
@3Mu36 said:
ping fqdn
Weird
ping pbx77.cloudapp.net
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.063 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.098 mswhen I install a standard lamp stack on azure its fine its just this Elastix installation thats a problem
Try another Elastix install on Azure. Right now, Azure is partially down (we have several VMs not responding, the console is regionally down and some Exchange customers are having issues.) But once Azure recovers, see if a fresh build has the same issues.
-
Does anybody knows why does the elastix installation changes the root password of the machine? I'm trying to install Elastix 4 on Amazon Web Services.
Thanks
Thiago Lima -
@thiagolima said:
Does anybody knows why does the elastix installation changes the root password of the machine? I'm trying to install Elastix 4 on Amazon Web Services.
I have not experienced this. But we use keys so might not notice. Are you sure that it is doing so and not something else doing it?
Just set up an SSH Key for root before installing and this will not be a problem.
-
@scottalanmiller Yes, I always use the keys and never the passwords. And that's the root of all my issues. After the install, when I try to run commands as sudo (or try 'sudo su' or even 'su -'), it is asked for a root password that I've never set. Thus, I'm locked outside my own box.
I still don't know why it is happening, but I could manage to get this working by doing the following workaround (not a very elegant solution, but at least worked):
- I've opened two ssh sessions and became root with 'su -' on one of them;
- On the other one, I've installed the elastix with your script but I've commented the 'reboot' command;
- Before rebooting the system, at the session that I'm root, I've manually changed the root and centos passwords for ones of my acknowledge;
- Rebooted the system and everythning runs like clockwork! (hey mom, look! I'm smart! =P).
Again, it is nothing that I'm really proud of. But at least I'm still logging with keys and not using passwords and I've set some pretty secure passwords, so I can't see any danger here.
And this is a problem affecting just the CentOS provided by CentOS itself for Amazon Web Services. I have Elastix MT running on Digital Ocean and I don't really think it would happen there for Elastix 4.
So here's my testimonial. If you can think on a better sollution, I'd really happy to hear! If I think on anything better than this, I'm posting here. Your assistance with this installing guide in a form of a script was very very helpful and I'm really thankful already.