Building Elastix 4 via RPM Repo
-
@scottalanmiller said:
@Dashrender said:
lack of Linux knowledge here - why would you use the ISO as a repo instead of just installing from the ISO?
Exactly as Jared said here. No enterprise hosting servers (that I know of) lets you bring your own ISO for stability and performance reasons. They need hooks into your system that that would break. So installing onto generic is pretty important.
What kinds of hooks do they get into the system?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
lack of Linux knowledge here - why would you use the ISO as a repo instead of just installing from the ISO?
Exactly as Jared said here. No enterprise hosting servers (that I know of) lets you bring your own ISO for stability and performance reasons. They need hooks into your system that that would break. So installing onto generic is pretty important.
What kinds of hooks do they get into the system?
Well in some cases, a PV kernel. In many it is things like the ability to reset the root password, insert keys, check for memory utilization, determine if the CPU is hung, etc.
-
How, that is a lot of power for your provider.
-
@Dashrender said:
How, that is a lot of power for your provider.
how is it not? People expect certain functionalities, not having them puts a provider at a big disadvantage. And having rapidly built systems is huge. And reliable performance. If you let people install from ISO you get a performance mess.
-
Not how.wow... Damn autocorrect
-
@scottalanmiller said:
@Dashrender said:
How, that is a lot of power for your provider.
how is it not? People expect certain functionalities, not having them puts a provider at a big disadvantage. And having rapidly built systems is huge. And reliable performance. If you let people install from ISO you get a performance mess.
I understand not allowing own ISO, but allowing the hosted root reset, that seems crazy.
-
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
How, that is a lot of power for your provider.
how is it not? People expect certain functionalities, not having them puts a provider at a big disadvantage. And having rapidly built systems is huge. And reliable performance. If you let people install from ISO you get a performance mess.
I understand not allowing own ISO, but allowing the hosted root reset, that seems crazy.
Physical access ALWAYS means the ability to reset. No exception. But this allows it to be easy, automated and available to the customer. It's a pretty important feature. Imagine a hosted system where you are barred from doing a password reset like you would on a local one. That would be almost impossible for anyone not in a pure DevOps world to manage.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
How, that is a lot of power for your provider.
how is it not? People expect certain functionalities, not having them puts a provider at a big disadvantage. And having rapidly built systems is huge. And reliable performance. If you let people install from ISO you get a performance mess.
I understand not allowing own ISO, but allowing the hosted root reset, that seems crazy.
Physical access ALWAYS means the ability to reset. No exception. But this allows it to be easy, automated and available to the customer. It's a pretty important feature. Imagine a hosted system where you are barred from doing a password reset like you would on a local one. That would be almost impossible for anyone not in a pure DevOps world to manage.
Physical sure, where you not implying they could do it with some kernal mod? Maybe I misunderstood.
-
@Dashrender said:
Physical sure, where you not implying they could do it with some kernal mod? Maybe I misunderstood.
Kernel mod is pretty dramatic. It's just an app normally.
-
@Dashrender said:
Physical sure, where you not implying they could do it with some kernal mod? Maybe I misunderstood.
So the important thing is that you have given up no security, just enabled a feature that benefits you.
-
Hi There.
Not sure if this is entirely related but I've installed Elastix 4 onto a Centos 7 Digital Ocean droplet.
I've got to the point where I need to start the elastix-firstboot. but I can't find how to do it?
Any ideas?
If I need to create a new thread, let me know.
thanks -
@BigfootNetworks said:
Hi There.
Not sure if this is entirely related but I've installed Elastix 4 onto a Centos 7 Digital Ocean droplet.
I've got to the point where I need to start the elastix-firstboot. but I can't find how to do it?
Any ideas?
If I need to create a new thread, let me know.
thanksWe are using Digital Ocean, too. The script at the top specifically worked on DO and installs elastix-firstboot as it goes, there shouldn't be any manual intervention.
Did you get any errors? What version of the ISO are you working from?
-
So I just used your script to install on Centos 7 on Azure. I do get the prompt for MySQL and Freepbx passwords at the end. However after the reboot my sudoers file has been overwritten (WTF?) essentially locking me out as a root user. Now I can't open the httpd ports or even start httpd. Bummer. Anyone else experiencing this on other VM services. I use azure because I have a free account and its just for testing. Maybe if I start fresh and open the ports before the install -will that work? But still left with the problem of root access blown away!
-
@dom I don't see anything in that script that would make changes to the /etc/sudoers file. Could it be something wacky with Azure?
-
@travisdh1 said:
@dom I don't see anything in that script that would make changes to the /etc/sudoers file. Could it be something wacky with Azure?
It's not my script, it doesn't touch that. However, Elastix has a track record of modifying /etc/sudoers with their RPM packages. So if you rely on /etc/sudoers, you must keep it updated after any yum run. Just part of the nature of Elastix.
-
@dom said:
Maybe if I start fresh and open the ports before the install -will that work? But still left with the problem of root access blown away!
Yes, open ports and enable root access directly prior to installation. CentOS is root on by default, you'll need to run that way for Elastix or make custom accommodations for their RPMs.
-
BTW Im quite new to linux.
I tried another install a few days back and it was after installing this /root/rpmbuild/RPMS/noarch/elastix-firstboot-3.0.0-6.noarch.rpm
is when my sudoers files was overwritten - its not your script.So how do I do this? "So if you rely on /etc/sudoers, you must keep it updated after any yum run". LINUX noob...sorry guys
-
-
@dom said:
So how do I do this? "So if you rely on /etc/sudoers, you must keep it updated after any yum run". LINUX noob...sorry guys
If you are new to Linux, I would not use sudoers for this one specific workload. Generally, yes, sudoers is great. This will cause you no end of pain on Elastix, it's worth skipping.
If you want to be reasonably secure without sudoers you can do this...
- Set a password (long and complex) for the root user.
- Create non-root users for you to log in as.
- Always log in as your non-root user.
- Access root with this command:
- su - which will ask you for that root password before letting you access root
- You can also block root access via SSH and only allow your user(s) accounts to access over SSH
Ideal? No, not at all. Does it work? Yes, and it is more secure that tons of normal installs and more secure than CentOS / RHEL defaults.
