Building Elastix 4 via RPM Repo
-
@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. -
@3Mu36 +1 on this solution. Not that I'm planning to leave like that but at least it is a good test if you're facing error 500.
-
@thiagolima said:
@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.
This is not the same as what you had asked (it is not changing any passwords) and is a well known issue with Elastix: it has always changed the sudoers file.
We talked about this issue somewhere above. Sadly, this is simply how Elastix works and you've always needed to deal with this when working with Elastix. There are a few decent choices but you need keys for root and this won't be a problem. You mentioned that you had the root password change, but that's not what changed.
Just set a root key and you are fine. It's trying to use the non-standard sudoers mechanism that Elastix does not intend you to use that causes an issue. Sudoers is awesome and we always use it so I totally feel your pain, but it's just something you have to know with Elastix.
Somewhere in the thread I showed to someone who was facing this, as we all do, that you can make your sudoers file something like /etc/sudoers.master and run a cronjob to copy that file to the /etc/sudoers file every fifteen minutes or whatever. Cheesy but effective. That's all that is needed. No passwords or keys are changed by Elastix.
-
@thiagolima said:
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.
Unless something is modifying the sudoers behaviour, it will happen everywhere. It is one of the RPMs for Elastix overwrites that file whenever it updates. So be prepared, it happens over and over. Digital Ocean you probably don't notice because as a standard install step they set up root, not user, keys without sudoers. So the issue is bypassed by Digital Ocean doing what I said to do on their own
-
I installed Elastix using your script, hasn't worked out for me. Any tips on how to uninstall?
-
@yonniz said in Building Elastix 4 via RPM Repo:
I installed Elastix using your script, hasn't worked out for me. Any tips on how to uninstall?
You would never uninstall Elastix, you would just create a new VM in its place.
-
What is your end goal now; what are you trying to install?
-
@yonniz how is your project going?
-
I added a disclaimer and warning to the original post to let people know that FreePBX is the better way to go at this point.
-
also forked out the most recent topic so that we could address it on its own.
-
@scottalanmiller said in Building Elastix 4 via RPM Repo:
ested as working for
Hello
Where can i get your script ? please
