Arch Linux User Repository

@ImNtReal & @Cordeaux

Thanks for your comments! That said, I also have to issue a warning:

Unfortunately, I've failed to account for the not so uncommon case of someone having both Apache and Nginx installed and active at the same time, i.e. listening on different ports. Currently, the install script always alters the configuration of both with a directive to listen on port 8095, regardless of the fact that if it sees both of them active it will properly avoid (re)starting them; but this simply means that, on the next manual server or system restart, one of the web servers will fail to start complaining that there is already something else listening on port 8095.

This will be fixed in the next update, most likely by having the script consciously choose Nginx (because modern standards) and have it listen on 8095 while leaving Apache untouched, on the premise that Nginx being installed and active side by side with Apache means that a) there are currently no conflicts between them (i.e. the user has already configured them properly) and b) the user actively uses Nginx in their setup, despite the fact that Apache is also present, so ZoneMinder can run through either of them.

I will not push the updated PKGBUILD just yet, because ZoneMinder's install procedure is long and annoying enough to make me not want to force users to go through it for the fourth time in a couple of weeks just for the sake of this; so unless something changes, I will wait for the next time upstream releases an update of their own and push all the changes at once. In the meantime, just please be aware of this issue.

Ok, This is the least fiddly time I've installed this on a dedicated odroid-xu3/4. I didn't mind using nginx as I've used that in the bsd version years ago. Apart from some packages as usual not having the armv7h architecture set it was relatively painless. Please leave it as it is and not purify to an ideal as Sythhead has commented below. Nice work adding apache for those who have to use that. Thanks for the great work @Nocifer

@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.