Arch Linux User Repository

Developer said he would help if I paid him $100 an hour. I guess I will have to look elsewhere for cctv software.

Please add etc/zoneminder/zm.conf to $backup. As of the current version, upgrades reset the configuration to the default. Thanks!

@Nocifer: I understand your desire for a "fire and forget" install script, but this is not the Arch Way (TM). Packages should install the data for programs to run, include a base configuration (although some packages don't even do that), and perhaps add users and groups as necessary (i.e. deluge, minecraft, etc.). The hands-off behavior the install script provides is similar to a distro like Ubuntu, where a user would possibly install a package from a GUI and expect things to be configured and running after the install, but this isn't what most Arch users are used to or looking for.

This package assumes that the user is using Apache, php-fpm, and Maria DB, but since this is simply a PHP app that requires a MySQL-compatible database, these assumptions are fairly broad. Personally, I've never used ZoneMinder with Apache or php-fpm, so this package adds a lot of dependencies and noise with great potential to bring down my database that I use for other apps. If circumstances made more people report downtime and issues from this package much earlier, we'd want to cater to their concerns, so why wait until then?

If you wanted, you could add a script in your package that accomplishes what's in the install script and instruct users to run it after install. However, most users don't want to run mysterious scripts without knowing what they will do, so they'll likely view the script in an editor. While they're there, they will likely find at least one or two things they'll want to do differently. In addition, it's a bad idea to run a script in its entirety in case something happens (what if the database user doesn't have permissions to a database?), so it's a good idea to run commands individually. Because of this, it's better to show users what commands to run upfront, hence the existing plethora of wiki pages with installation procedures.

For comparison, see these packages:

• Nextcloud doesn't setup anything itself because it might result in downtime or data loss: https://wiki.archlinux.org/index.php/Nextcloud#Setup
• MySQL doesn't create a database on install because you might have data on a server: https://wiki.archlinux.org/index.php/MySQL#Installation
• PostgreSQL also doesn't create a database for the same reasons: https://wiki.archlinux.org/index.php/PostgreSQL#Initial_configuration

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