Zoneminder and FreePBX User problem

[vogiatzis]

Dear all,

I know that for somebody this question might be more or less the same with previous posts but I still did not manage to get a clear answer.
How can i make work, the Zoneminder and the Freepbx at the same apache server?
I have just installed the Zoneminder successfully and when I install the Freepbx the problem with the "cannot load config file" appears. It is well-known that it is a problem with the users of the apache server. The Zoneminder uses the www-data user and the FreePBX uses the user asterisk.
In case I install the Zoneminder first I have to change the user from www-data to asterisk to make it work with Freepbx.
And the question is clear:

How can I change the user to "asterisk" before I start the installation of the FreePBX ??

Thanks for your time.

[knight-of-ni]

The short answer is you can't. There is no non-problematic way to do what you are doing. The Zoneminder packages have to be run as the web account user.

The best thing to do would be to run zoneminder in a virtual machine, a container, or just use a separate machine.

[mocho]

yes you can!
I have that setup
What I have done is change user in

/etc/zm/zm.conf

Code: Select all

# Username and group that web daemon (httpd/apache) runs as
ZM_WEB_USER=asterisk
ZM_WEB_GROUP=asterisk

change /etc/init.d/zoneminder to

Code: Select all

	mkdir -p "$RUNDIR" && chown asterisk:asterisk "$RUNDIR"
	mkdir -p "$TMPDIR" && chown asterisk:asterisk "$TMPDIR"

And change the directories wich zoneminder uses to asterisk user and group

[knight-of-ni]

yes you can!
I have that setup
What I have done is change user in

/etc/zm/zm.conf

Code: Select all

# Username and group that web daemon (httpd/apache) runs as
ZM_WEB_USER=asterisk
ZM_WEB_GROUP=asterisk

change /etc/init.d/zoneminder to

Code: Select all

	mkdir -p "$RUNDIR" && chown asterisk:asterisk "$RUNDIR"
	mkdir -p "$TMPDIR" && chown asterisk:asterisk "$TMPDIR"

And change the directories wich zoneminder uses to asterisk user and group

No, don't do this. This is a good way to wreck your system after a package upgrade.

I had this specific method in mind, when I stated previously there was no non-problematic way to get zoneminder to run as a different user account, using an existing zoneminder package.

As soon as the next package update comes through, guess what happens? The package will set everything back to the way it was. ...and what follows is the end user creates a post in our user forum claiming ZoneMinder mysteriously broke after a package update, lost all his events (zmaudit will purge your event table), and asks if this is a bug (naturally, w/o telling us he previously screwed up his configuration). Think I'm kidding? Just hang around here long enough.

The best, least labor intensive, way to get Asterisk and ZoneMinder to run on the same physical machine is to run them in separate environments through a vm or a container. If you do it this way, you can follow the normal documentation and won't have to worry about catastrophic failure after a package update. The same can't be said if you go off on your own.

Alternatively, you can build your own package, with the desired user account set at build time, following the instructions on our readthedocs site. This method, however, requires more work on your part, but if you stick with a popular distro then documentation exists to do it this way. Anytime you wish to upgrade, you will have to build a new package yourself. You won't be able to use the packages from any repo.

Incidentally, you should ask in an Asterisk forum why that software needs to be run under its own user account. It is Asterisk, not ZoneMinder, that is deviating from the standard. ....and if there happened to be a non-problematic way to run Asterisk as the web account user, then that certainly would be a way to get ZoneMinder and Asterisk to play nice together.

[knight-of-ni]

Guys,
While there have been some creative ideas on how to hack your system to get zoneminder & astrisk to sort-of play nice together, they all make changes to what the system packages have put in place. This is always dangerous because the system has no idea what you've done, and it will indiscriminately set things back to the way it was after a package upgrade, without telling you. Doing this is a terrible idea, especially when there are far better, and well documented, solutions to avoid this kind of problem.

You are, of course, quite welcome to disagree with me. However, one thing I won't allow is to let these suggestions propagate in this forum. Not only is it certain to guide others down the wrong path, but the one who ends up giving their free time to dig them out is me, not you. Consequently, I'm locking this thread for further conversation and deleting recent posts. Feel free to post your instructions elsewhere.