Arch Linux User Repository

@jlanzobr what is the exact error you're getting? Is anything relevant printed out in the service logs of fcgiwrap-multiwatch, php-fpm or nginx/apache, or in Zoneminder itself (all its logs are located at /var/log/zoneminder)?

The only really breaking change in this new package release is the switch of the webroot from /srv to /usr/share/webapps, but this apparently is not the cause of your issue, since the web interface is otherwise functioning properly. Other than that, nothing has changed as regards to PHP or any other part of the package. So the issue is either something caused by an upstream change, or it's a bug I've introduced by e.g. forgetting to properly edit some part of the configuration files to reflect the webroot switch.

Unfortunately, I currently don't have a camera to test this myself, so until I get one, the only thing I can do is try to interpret any errors you find. So, again, the best thing to do at this point is to check if there are any concrete errors printed in any of the logs I mentioned.

After the update, I can't see my streams despite ZoneMinder saying they're running. I changed the WEB_H_STREAM_METHOD between mpeg and jpeg and there doesn't seem to be a difference. I can't view any events either. Am I missing some magic in open_basedir or what else could it be?

@Nocifer, I am thrilled to report that the problems I was having have been resolved with the 1.34 package. This version also has a much nicer event viewer than previous ones. Thank you for the fixes and updated packaging, much appreciated!

@eshep alright, seeing as it's been more than a year since the previous ZM release and there's a whole bunch of stuff that's been fixed or tweaked upstream in the meantime, I'll upload the new version and if any of your issues persist even after the update, I will look into it.

@Nocifer, The issue I'm talking about happens when clicking on any non-alarm frame from the frames view. It produces a "502 Bad Gateway" but works fine if it's an alarmed frame. I have verified that the "capture" images are actually in the directory alongside all the "analyse" ones. This also happens when trying to view an event which I'm assuming is due to the same issue.

However I'm currently unable to use it at all due to he following two errors: 'zma -m 1' exited abnormally, exit status 127 'zmc -m 1' exited abnormally, exit status 127

A fair warning to everyone:

From 1.34 onwards the webroot will be moved from /srv/zoneminder to /usr/share/webapps/zoneminder.

The configuration files for Apache & Nginx provided by this package have been adjusted accordingly, but, as per pacman's packaging standards, they will only overwrite your existing configuration files if those have been left in their default state.

This means that, if you've ever manually edited the Apache/Nginx configuration files that come with this package, be prepared to experience a broken setup after updating to ZoneMinder 1.34, because your configuration files will not be automatically adjusted and thus will keep pointing to /srv/zoneminder, which will now be invalid.

Sorry for the very late reply.

@eshep what kind of issue are you having exactly? There shouldn't be any issues left with Nginx at this point, but if there are I could check and fix them before I do the package update for 1.34 (which finally came out yesterday, hooray). All I need is for you to tell me exactly where and how I can reproduce the broken links.

@wuestengecko I've actually had a complete change of heart (the key was reminding me about Gnome's WebDAV service installing Apache, which I hated with a passion way back when I still used Gnome) and so from this release onwards (which I'll hopefully do later today) I'll be removing all hard dependencies on Apache, Nginx & MariaDB and will be providing a separate script for anyone who, like me, may wish to automate the configuration process. Otherwise, this package will now only install ZoneMinder and its hard dependencies (perl stuff, php stuff & ffmpeg stuff) and leave it to the user to figure things out, with the help of the Arch Wiki and possibly the upstream documentation (which is why these things exist in the first place).

I understand that there are problems with zm links when using nginx but I don't get why alarmed frames display in the popup and regular ones don't. I'm also assuming the playback of events is a related/similar problem.

adding them as individual optdepends would result in this, uhm, not so pretty piece of text

Fair point, it does look quite ugly this way. The main advantage would be not having to edit the PKGBUILD and rebuilding the package in order to switch between the two. The major disadvantage would be that you cannot expect a web server to be installed at the time post_install runs.

Could you please provide me with a source other than the Arch wiki that confirms this?

All official packages providing web applications, like Nextcloud or phpMyAdmin, use that path. Both packages provide wiki articles with instructions for three web servers (Nextcloud, PMA). Gentoo does something very similar (install them there, link them into place).

This also requires the provided httpd/nginx config files to be changed, so that they provide an Alias (as detailed in the above Wiki articles).

feature complete, with all the bells and whistles needed to run ZoneMinder after the installation is complete

Let me quote from Arch's principles:

Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.

In a similar fashion, Arch ships the configuration files provided by upstream with changes limited to distribution-specific issues like adjusting the system file paths. It does not add automation features such as enabling a service simply because the package was installed.

I see no reason not to write a script which automates tedious setup/upgrade steps, as long as it doesn't run automatically by default. Coming from Debian, where literally everything is always automatically running as soon as the installation is done (even if it's just Apache providing on-demand WebDAV server capabilities for Gnome, and not at all needed as system-wide service), this is in my opinion a very sensible choice.

However:

Arch is a pragmatic distribution rather than an ideological one. The principles here are only useful guidelines. Ultimately, design decisions are made on a case-by-case basis through developer consensus.

the ones that don't bother to read PKGBUILDs or the Arch wiki for instructions

Arch has never been for the ones that just want stuff to magically happen without caring about why or how. That's why the ArchWiki exists in the first place. IMO if someone can't be bothered to read an article to set something up, then Arch is not the right distro for them.

Additionally, no other package (that I know of) provides automatic setup and start scripts like this one, making zoneminder the one sticking out from all the others.

But... that IS a separate install script. That's why it comes as a separate file, instead of residing inside the PKGBUILD itself.

With "separate" I meant a script file which does not run as part of the installation procedure itself, but rather one that is installed, say, as /usr/bin/zmsetup.sh and can then be called manually by the user. That way, one could use e.g. zmsetup.sh --force-nginx to use nginx even though Apache is running (perhaps on a different port/interface).

@raqua just indent every line you wish to be shown in a green box by 4 spaces.

@wuestengecko thanks for the feedback!

Why not make all of these optional in the first place, like: [...]

Because they must come as a package deal, because I need to configure them (e.g. fcgi-multiwatch which uses a custom systemd service file), and also because adding them as individual optdepends would result in this, uhm, not so pretty piece of text you produced (aka multiple "nginx web server" or some such entries required). For sure, I could instead leave that line as is but remake these packages into opt-in dependencies instead of opt-out (aka have the line already commented out and require the user to manually uncomment it if they want to install nginx) but that would mean that on a fresh system, installing this package would leave ZoneMinder non-functional as no web server would be present by default. Granted, a web server is not a hard dependency per se as the perl scripts can run on their own, but using ZM without a web server belongs on a whole other level of technical prowess and as far as I know is not even supported by upstream. It's like asking me not to include the zoneminder.service because a user can write their own system service script. Yes, they could, but it's not really relevant as a use case.

So, if not having a web server installed by default is off the table, the only real question is whether this package should come with Apache or with Nginx as the default. Apache is tightly paired with many old-ish, cgi-based web apps and ZoneMinder is no exception, so most people use it by default and have it already installed on their system. But, for reasons well-known and not really relevant here, nginx is actually a more robust web server - and seeing as ZM upstream officially supports it as a valid alternative, I see no reason (other than backwards compatibility) not to have it as the default and instead have Apache as the optional, alternative one. Call it "promoting better web standards" if you like :)

I believe these fall under the Web application package guidelines and should live below /usr/share/webapps/$pkgname.

That's a valid request. But tbh, this is the first time I've even heard about /usr/share/webapps, I've always known and used /srv for cgi-based web apps. It's even condoned by the very same FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html. Could you please provide me with a source other than the Arch wiki that confirms this?

No. Just no. Which service is stopped / (re)started when is my choice and my choice alone. This whole script has no business in post_install/post_upgrade, but should rather be made a standalone script file which can be manually executed. Post-upgrade automation should happen in the form of the admin writing a pacman hook.

I've explained my rationale on this a few months back. I want this package to be more or less feature complete, with all the bells and whistles needed to run ZoneMinder after the installation is complete. In order to accomodate the more technical users (this is Arch after all) I've made it so everything not absolutely needed is properly laid out in the PKGBUILD so it can be identified and commented out by said users. This goes for the nginx dependencies, the database dependencies and the install script.

If you wish for this package to simply install ZM and let you do everything else on your own, all you need to do is comment out three lines in the PKGBUILD. For the other users, the ones that don't bother to read PKGBUILDs or the Arch wiki for instructions, the solution I have implemented is imho a nice compromise between customization and convenience.

Also, and I don't mean this as a "my way or the highway" kind of remark but simply as a friendly suggestion: if you still believe this is inexcusably tedious (or simply inexcusable), you also have the option of using the zoneminder-git package, which I just noticed has been recently adopted and updated by a new maintainer and which includes a much more lean install script file with only the essentials performed automatically and the rest included as suggestions to the user.

On a more serious note, if you go for a separate install script, you can make it much more interactive (even if just with command line switches) and let the user select between Apache and Nginx if both are present, or skipping web server setup altogether without an error message.

But... that IS a separate install script. That's why it comes as a separate file, instead of residing inside the PKGBUILD itself. It's merely configured by default to run automatically after install, thanks to pacman's capability to do so; but that behavior can easily be changed by a user who knows what they're doing.

Regarding changes to the script itself, I'm not opposed to them in theory, but these PKGBUILDs are commonly run from within AUR wrappers, not to mention stuff like pamac, and I fear they're not really designed to do stuff like that and an interactive script would break them.

Same as above, post_remove is not responsible for stopping uninstalled services. It might be a sensible thought, but as long as no official Arch packages do things like that, I see no reason why AUR packages should.

I believe post_remove() is merely a method called after the main install process is complete, nothing more and nothing less. If some services need to be restarted as part of the post install procedure (e.g. systemd-tmpfiles), I don't see how that is something to be concerned about.

That's the way!

Thanks, but do note that this part comes after I've already tried and failed to do the things I notify the user about, so it's kind of a FUBAR fail-safe, just like that "WARNING: ZoneMinder is running, but no web server has been configured." line earlier in the script. So even then, trying to do things automagically remains my method of choice :-)

Were you perhaps looking for systemctl restart?

I wrote it this way for uniformity's sake, even though a systemctl restart would indeed have sufficed.