Arch Linux User Repository

@Nocifer, thanks for making the PKGBUILD more accessible for different platforms. This will work much better for me.

Thanks @jlanzobr for providing the Apache conf, but I'm happy to report that now I can also provide an "official" one, along with a new one for Nginx which fixes a small issue with the API's static content (@alanking: no matter how hard I looked, the broken CSS was the only issue with the API I could find; everything else seems to be working correctly, so if you're still having problems I will need more details).

• Apache conf: --Link removed--
• Nginx conf: --Link removed--

To use the Apache conf, you will have to include it in httpd.conf and also enable the following modules: mod_proxy, mod_proxy_fcgi, mod_rewrite and mod_proxy_cgid.

To use the Nginx conf, just overwrite the original one that came with the package.

If people would kindly test these conf files and verify them to be battle-ready, I will include them in the next release which will also have the following changes:

1. Nginx will stay as a hard dependency (in order to facilitate the "fire-and-forget" type of install).
2. Apache will be added as an optional dependency.
3. Regarding Apache vs Nginx, during install:
   • If both of them are installed and Apache is already active, then it's preferred and Nginx is ignored.
   • If both of them are installed and Nginx is already active, then it's preferred and Apache is ignored.
   • If both of them are installed but neither one is active, then Apache is preferred because it's an optional dependency, which means the user has made a conscious choice to install and use it either during ZoneMinder's setup or as part of an already established setup (like in @ImNtReal's case).
   • If only one of them is installed, it's preferred (duh :P).
   • Systemd service no longer requires either of them, so will happily start as long as MariaDB is running and will leave it to the user to decide which (if any) web server they want to use.

Would such a solution be acceptable?

To make this work under Apache HTTP as of Oct 4, 2018:

1. Ensure you have Apache and php-fpm setup correctly (see ArchWiki)
2. Symlink: sudo ln -s /srv/zoneminder/www /srv/http/zoneminder && sudo ln -s /srv/zoneminder/cgi-bin /srv/http/cgi-bin
3. Ensure you've created the ZoneMinder database (see Arch Wiki)
4. Edit /usr/lib/systemd/system/zoneminder.service to replace nginx references with httpd
5. Create /etc/httpd/conf/extra/httpd-zoneminder.conf with contents:

<Directory "/srv/zoneminder/www">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory> 

Alias "/zoneminder" "/srv/zoneminder/www"

@alanking What exactly is the issue you're having? When I first ran zmNinja a couple of days ago to test it against the "official" package release, the first time I tried to add the ZM server configuration it complained it can't access the API. This actually prompted me to test the Nginx conf file for errors but the weird thing is, while I ended up changing nothing in the conf file, from the second time onward zmNinja never complained again and it's been working properly, meaning I have a live view from the camera etc.

Now granted, I've never used zmNinja productively before and I haven't tested it extensively, so the broken API might well have to do not with the camera's live feed but with its other functions (e.g. motion detection). So me seeing a live feed might not mean much. Also, I've noticed that the API seems indeed to be somewhat broken currently in some places, but I'm not sure if that's due to me messing up the Apache -> Nginx translation or something else. I'll test later today with Apache and the official conf file for ZM and see if I get the same errors (which I probably should have done already but... yeah).

So, again: what is currently not working for you in zmNinja? (so I know what to check for)

seems zmninja api died in update to first release. Anyone else? it was working fine on the previous pkgbuild.

edit : extra info as follows. It now complains that API access error (API access failed, check config etc), can't use live view or anything else since i can't get into it.

@ImNtReal

OK, having a pre-existing setup is a very valid reason for not wanting a hard dependency on software you don't currently use, and it's what originally prompted me to want to make the PKGBUILD web server agnostic. But I have a couple of counterpoints:

• The PKGBUILD is already largely web server agnostic. If you don't count the 'nginx-mainline' dependency, neither the systemd service nor the install process actually need Nginx installed. The former merely "wants" the Web UI components (Nginx, PHP, fcgiwrap) while the latter specifically checks if Nginx is installed (by checking for the existence of nginx.conf) and only then does it take it into account.

• My "vision" for this PKGBUILD (in contrast to @Synthead's opinion stated below) is to be a "fire and forget" solution. Which means that while I agree that the install process should be as modular as it can possibly be in order to be useful in most if not all scenarios, it also shouldn't be so modular that it can't be useful to the Average Joe out there that simply wants to install/update the package and setup their cameras all in an hour's work, without having to manually fiddle with web servers and databases. And I know from personal experience that for every Linux-savvy, headless server owning Arch user out there, there is at least one other that fits the description of Average Joe I just gave.

What I'm trying to say is that, at least regarding Nginx vs Apache, all it takes is to manually remove that 'nginx-mainline' dependency and you already have a web server agnostic PKGBUILD. And you don't have to do even that - we can always make it so that the Nginx service only activates during the install process if it was already activated before the install, so you can just have Nginx installed once, deactivate its service once, and then never bother with it again but still be able to use this PKGBUILD without modifying it. For a user like you, that is an infinitely easier task than it is for the Average Joe to fiddle with conf files in a terminal or manually install Nginx (or Apache for that matter) and produce a working setup.

IMHO, the only thing missing as of now is a conf file for Apache, which I already intend to add, and which for the time being (until the next package update) you can easily get either from the source archive or from ZM's GitHub repo.

I'm certainly open to discussing this further but I have to say, unless I'm seriously mistaken in one or more of the assumptions I made above, I really don't see the issue here...

@Synthead

Can't say I agree with that sentiment. Whenever I wish to install something by hand and manually edit its configuration files or modify its dependencies or alter its setup procedure, I just build from source or from released binaries without resorting to a PKGBUILD. Then, when I have tailored the procedure to my taste, I create a PKGBUILD that performs it for me. That's IMHO the whole purpose of a PKGBUILD: to automate the setup as much as it can without resorting to hacks and/or potentially dangerous behavior; which means that yeah, if I can automate ZoneMinder's setup to the point that it installs completely without any user input, then why not do so?

As for the "mysterious SQL", all it does is initialize MariaDB's database if it isn't already initialized (i.e. it's a fresh install) and then create ZoneMinder's database and user using the instructions and database schemas that upstream provides, again only if they don't already exist. Why would you want to do that by hand and not by a simple script? And of course, I'm not asking you to trust me or my simple scripts, I'm asking you to just read the INSTALL file (as you have obviously done already) and decide for yourself if it does its work as it should. And restarting databases or web servers? Yeah, well, as I said you're not manually building a package, you're installing one, which means that some things are bound to happen automatically. And if it's a matter of not being a convenient time for you to restart your web or database server, then simply postpone the package upgrade for when it's more convenient.

I'll repeat what I just said to @ImNtReal: a PKGBUILD should IMHO be as modular as it can possibly be in order to encompass every possible scenario thrown at it, but only on the condition that it's not getting in the way of the simple user who merely wants to install the software and go about their business. So, for example, I would never adopt a setup process where I would have the user go read the Arch wiki in order to learn how to use my PKGBUILD. I myself have already read the very informative Arch wiki (I'm speaking in general terms here, so substitute the Arch wiki with upstream's instructions, or Linux Hacking 101, or whatever else) and I have put that knowledge to good use by creating this PKGBUILD. And I have done so exactly so I can spare you the "pain" of having to go read the wiki yourself. That's the whole point of a PKGBUILD, at least IMHO. It's not built for you or me or ImNtReal - we are all able to create our own PKGBUILDs if we so wish.

Again, I'm open to discussing this further, but I think this debate is more a matter of different principles than real practicality.

@Nocifer, I currently run Zoneminder on a server I've had running on Arch for years with Apache running a small website, and operating as a reverse proxy for several different applications. It certainly wouldn't be impossible for me to move to Nginx, but it would be a lot faster for me to create a PKGBUILD that is web server agnostic at this point.

I think we should pull out most of the stuff in zoneminder.install. We don't want mysterious SQL to run, databases to restart, webservers to go offline, etc. This kind of thing should always be in the hands of the user. We should print commands that the user should run to the console, or better, refer them to a page in the Arch Linux Wiki.

@ImNtReal

The comments have been flooded a bit by my conversation with @whata-mess, so I will quote here part of a comment a wrote just a couple of days ago as a reply to @chapatt:

"Now that I know everything works fine, If and when I adopt this package (I've filed an orphan request since a couple weeks ago) I aim to change the install procedure into a saner (and safer) one, i.e. provide the needed files and detailed instructions and leave it to the user to setup Nginx, Apache, MariaDB et al as they see fit. And I also want to include a conf file for Apache besides Nginx, and make both of them into optional dependencies with separate instructions for each."

As you see I agree with you, at least in principle. On the other hand Apache is in my eyes an obsolete piece of crap that should really only be deployed when there's no other alternative, e.g. in cases where one has to deal with old software created back in the days when Perl and Apache were reigning supreme - in other words, software like ZoneMinder. But here's the thing: if one can, with a little effort, adapt that old software to work with something else besides Apache, then in my opinion one should make that effort and adapt that software to work with something else, and so get rid of Apache. Which is what I did in this case.

So the real question is: with Apache out of the question, what other web server besides Nginx could one possibly use to run ZoneMinder, that would then justify Nginx becoming an optional dependency along with this new option? The only one I can think of is lighttpd. The problem is, there is no conf file for lighttpd to run ZoneMinder with, which means that adding it to the list of optional web servers would be useless to the majority of the userbase. But I'm willing to do it as long as someone can provide a working conf file for it.

That said, and despite my opinion of Apache, the same goes for Apache: if enough people ask for it (or fewer people but with good reason) then I'm willing to also add it back as a supported web server. But for the time being I think a working Nginx setup is more than enough.

P.S. - For anyone that may be wondering: what I am looking forward to implement is a scenario for a remote MariaDB server. But that will take some work.

Edit: @ImNtReal Forgot to ask you - is there a specific reason you'd prefer Apache instead of Nginx? E.g. an existing setup or something like that?