Arch Linux User Repository

Well, I'll be effing damned..! @chapatt, I don't know if you've read that comment I posted earlier (I've actually pinned it) about a nasty bug I was out hunting all morning? Well, turns out it's not a bug after all - the erroneous URL I've been seeing is just a useless Ajax call of no concern whose only downside is that it consumes CPU cycles for no good reason; I guess it's just a remnant from older ZoneMinder versions that no one ever bothered to remove.

That missing camera stream in the Edit Zone view though, which I thought was the result of this "bug"? Yeah, turns out that's because the camera stream used in the Edit Zone view is (obviously..!) the same as the one used in the View Zone view, which is still active while editing one of the zones; and it's also the same stream used in the Monitor view, which is why I had no image in the otherwise perfectly working Monitor view while viewing or editing the zones! And here I was, chasing bugs and butterflies, when it was simply a matter of that damn fcgiwrap process blocking requests when receiving more than one at the same time!

/facepalm

The good news is that spawn-fcgi + multiwatch solved the issue completely, and now I can have the camera feed streaming through all 3 views at the same time. So, many thanks for mentioning them ;)

The "bad" news is that now spawn-fcgi and multiwatch have been promoted to mandatory dependencies (when using nginx+fcgiwrap) because without them ZM cannot function properly, which means a simple note at the end of the install procedure or an edit in the Arch wiki entry will simply not cut it. I will add them in the next update, and will also add a new systemd service that will be used instead of the fcgiwrap one.

Thanks again!

@Nocifer, yes, that's the one--you need at least as many fcgiwrap threads as you want to view streams. Well, the wiki is mostly just a guide on how to configure the aur package, so it seems apt to at least augment it with a mention of the other optional dependencies, etc. available. I'll try to get around to it too, once the package and my system are stable.

The 1.32.2-1 update broke ZoneMinder's cgi scripts because my "elegant" dirty fix for the hardcoded links, mentioned in the other pinned comment, turned out to not be a fix after all. I instead tried the hack that @Kubax described (creating a /zm/ link inside the /www/ folder that points back to /www/) and that one managed to fix pretty much all errors with hardcoded links, to the point that upstream may not even have to bother.

The 1.32.2-2 update I just pushed contains that fix.

Besides that, I've been trying to eliminate a particularly nasty bug that results in a specific request constructing a false URL like http://localhost/index.php/index.php?view=request&request=stream&connkey=752041&command=99, which fails for obvious reasons. This URL is the one that loads the camera image when editing zones, so I'd say it's important enough to warranty immediate attention.

As soon as I manage to find a solution I'll push a final, third update.

@chapatt

Hey, and thanks. Regarding fcgiwrap, I guess you mean this tweak in particular?

https://wiki.archlinux.org/index.php/nginx#Multiple_worker_threads

I don't know if I'll ever get to edit the Arch wiki itself (you think I should?) but at the very least we could have the install script print a note about this at the end of the install procedure, alongside the "ZoneMinder is listening at localhost:8095" message.

@Nocifer thanks again for keeping up the effort with this! I got around to actually using the installation and had to go through a little fcgiwrap configuration in order to view multiple streams simultaneously (or on multiple clients). See https://wiki.archlinux.org/index.php/nginx#CGI_implementation. If you overhaul the wiki page for your package you might want to reference it in a section regarding nginx.

@Kubax

Lol, that's a lot of errors... But actually, the latter half of your list is just duplicates due to that /zm/ link you've created inside the /www/ folder, and the first four entries are from the cache, which makes them redundant. So the real files with issues are only 7 (going by your list), but 2 of them only have the /zm/ reference inside a comment, so the real files with actual issues are only 5; one of which is responsible for the error in Montage Review, 2 others have something to do with the API, one is a CSS file producing wrong paths for a couple of icons, and the last one... I would have to know how ZM works internally to know what that one does.

I've reported all 7 files to upstream's issue tracker. In the meantime, when I update the package with the recently released 1.32.2 version (probably tomorrow) I will include a quick fix for at least the Montage Review.

Actually i wasn#t 100%sure about the count of files, but i was sure it was multiple lines. but seems like there a a number of calls to /zm/ inside multiple file(s|types).

cache/skins_classic_views_js_montagereview-dark-1539447937.js:          '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+Frame.FrameId +
cache/skins_classic_views_js_montagereview-dark-1539447937.js:    return '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+frame_id + "&width=" + monitorCanvasObj[monId].width + "&height=" + monitorCanvasObj[monId].height;
cache/skins_classic_css_base_views_zone-dark-1539447937.css:    background-image: url(/zm/skins/classic/graphics/point-g.png);
cache/skins_classic_css_base_views_zone-dark-1539447937.css:    background-image: url(/zm/skins/classic/graphics/point-o.png);
includes/Event.php:      $url = $Server->Url() . '/zm/api/events/'.$this->{'Id'}.'.json';
includes/Event.php:      $url = $Server->Url() . '/zm/api/events/'.$this->{'Id'}.'.json';
includes/Monitor.php:      $url = $Server->Url() . '/zm/api/monitors/'.$this->{'Id'}.'.json';
skins/classic/css/base/views/zone.css:    background-image: url(/zm/skins/classic/graphics/point-g.png);
skins/classic/css/base/views/zone.css:    background-image: url(/zm/skins/classic/graphics/point-o.png);
skins/classic/includes/export_functions.php:            echo "<div><a href=\"javascript:switchevent('$eids/zm/EventImages.html');\"> $eids </div>";
skins/classic/views/js/montagereview.js:          '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+Frame.FrameId +
skins/classic/views/js/montagereview.js:    return '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+frame_id + "&width=" + monitorCanvasObj[monId].width + "&height=" + monitorCanvasObj[monId].height;
views/image.php:// Calling sequence:   ... /zm/index.php?view=image&path=/monid/path/image.jpg&scale=nnn&width=wwww&height=hhhhh
views/view_video.php:// Calling sequence:   ... /zm/index.php?view=video&event_id=123
grep: zm/api/app/tmp: Datei oder Verzeichnis nicht gefunden
zm/api/lib/Cake/Config/cacert.pem:HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mERdEr/VxqHD3VI
zm/cache/skins_classic_views_js_montagereview-dark-1539447937.js:          '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+Frame.FrameId +
zm/cache/skins_classic_views_js_montagereview-dark-1539447937.js:    return '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+frame_id + "&width=" + monitorCanvasObj[monId].width + "&height=" + monitorCanvasObj[monId].height;
zm/cache/skins_classic_css_base_views_zone-dark-1539447937.css:    background-image: url(/zm/skins/classic/graphics/point-g.png);
zm/cache/skins_classic_css_base_views_zone-dark-1539447937.css:    background-image: url(/zm/skins/classic/graphics/point-o.png);
zm/includes/Event.php:      $url = $Server->Url() . '/zm/api/events/'.$this->{'Id'}.'.json';
zm/includes/Event.php:      $url = $Server->Url() . '/zm/api/events/'.$this->{'Id'}.'.json';
zm/includes/Monitor.php:      $url = $Server->Url() . '/zm/api/monitors/'.$this->{'Id'}.'.json';
zm/skins/classic/css/base/views/zone.css:    background-image: url(/zm/skins/classic/graphics/point-g.png);
zm/skins/classic/css/base/views/zone.css:    background-image: url(/zm/skins/classic/graphics/point-o.png);
zm/skins/classic/includes/export_functions.php:         echo "<div><a href=\"javascript:switchevent('$eids/zm/EventImages.html');\"> $eids </div>";
zm/skins/classic/views/js/montagereview.js:          '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+Frame.FrameId +
zm/skins/classic/views/js/montagereview.js:    return '/zm/index.php?view=image&eid=' + Frame.EventId + '&fid='+frame_id + "&width=" + monitorCanvasObj[monId].width + "&height=" + monitorCanvasObj[monId].height;
zm/views/image.php:// Calling sequence:   ... /zm/index.php?view=image&path=/monid/path/image.jpg&scale=nnn&width=wwww&height=hhhhh
zm/views/view_video.php:// Calling sequence:   ... /zm/index.php?view=video&event_id=123

@Kubax

Yup, I can confirm the issue, thanks for reporting it. So far I've managed to isolate the hardcoded references inside the file '/srv/zoneminder/www/skins/classic/views/js/montagereview.js', lines 127 & 135. If you can confirm this is the file you meant (I'm asking because you said 'php files', as in PHP and plural, whereas I only found a single JS file) I will inform upstream to fix it.

I had to put a silly symbolic link in /srv/zoneminder/www to link from /srv/zoneminder/www/zm to /srv/zoneminder/www/ this solved a issue with Montage Review where the images were not rendered because zoneminder tried to call hostname:8095/zm/index.php?xxxx but it should call hostname:8095/index.php?xxxxx

I couldn't find a option to change the path, and later found that it's hardcoded inside the php files from zoneminder.

@Synthead

this is not the Arch Way (TM)

I can't say I agree with that. As I see it, the Arch Way simply says "keep things simple enough to avoid most issues, and arm yourself with enough knowledge to solve the issues that do arise". Arch does not "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" because its principles call for bare-bones packages, it merely provides whatever is released by upstream. That's why, for example, Nginx and Apache do not use the arguably very convenient system of sites-available/sites-enabled used in Debian, even though it is explicitly mentioned in the Arch wiki as good practice. But even if it weren't mentioned, if some day upstream decides to implement this system officially, then Arch will simply provide it with no questions asked.

Also, packages vary in their level of required expertise. Some need extensive user intervention, others come ready to run out of the box, with most settling somewhere between. Again as an example, both Nginx and Apache come already preconfigured and set to listen on port 80, and also provide a sample webpage. Going by your rationale that's a no-go, and we should rather have them install their binaries and then provide the user with instructions (or links to the Arch wiki) detailing how they can go about creating a main conf file from scratch. That could be done, sure, but I don't think it should be done.

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.

Well, I'm an Arch user and I can tell you right now that this is exactly what I'm looking for in a PKGBUILD. I love Linux and I love tinkering with my system and doing every little thing by myself, but that doesn't mean I like doing every little thing by hand - I use scripts to do it for me. That's the whole point of using a computer; if I wanted to do everything by hand I'd use an abacus, or maybe even Gentoo.

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

These are upstream's assumptions, not mine. For the record I personally use Nginx. As for this package, not only did it never assume that the user is using Apache, but I originally had it do the exact opposite and depend only on Nginx. And even now that it does support both, it still doesn't assume anything, but rather checks to see what web servers are installed and/or running and acts accordingly. Do you wish for more web servers as optional dependencies? I'd be more than happy to include them, but I would first need you (or someone else) to provide me with a working configuration for ZM to run on them. Otherwise, what's the point of including them if they won't work?

Regarding php-fpm, I'd again be happy to consider other options, so I'd love to know what you use to run ZM's PHP parts with. Unless I'm mistaken, even its API requires PHP so, even if you don't want to use the Web UI, you still can't simply use a third-party GUI like zmNinja and forget all about it.

MariaDB is the only one out of the three that I can accept as a solid argument, because of PerconaDB or even MySQL itself (and possibly others, I just did a quick Google search and found a couple). I'll probably add at least Percona as an optional dependency in the next update.

so this package adds a lot of dependencies and noise

Don't want Nginx installed? Simply edit the PKGBUILD and remove 'nginx-mainline' and possibly 'fcgiwrap' from the list of dependencies.

Don't want PHP installed? Simply edit the PKGBUILD and remove 'php-apcu', 'php-fpm' and 'php-gd' from the list of dependencies.

Don't want MariaDB installed? Simply edit the PKGBUILD and remove 'mariadb' from the list of dependencies.

Don't want the script to do anything else but build the package? Simply edit the PKGBUILD and remove the 'install' line.

with great potential to bring down my database

You mentioned this in your previous comment as well. I asked you then, so I ask you again now: how will your database go down by installing this package? All it does is a) initialize the default 'mysql' database if it's not already initialized, and b) create ZM's database and user if they're not already created. Simple, clean and efficient. If you already have a working database server (which means the default database is already initialized) it won't even try to restart it. So really, I can't see the issue here.

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?

You've already answered your question: "cater" roughly means "provide something that fits someone else's needs". If that's your aim (and it's certainly mine to a large extent) then it only makes sense to wait for that "someone" to actually voice their concerns before acting upon them; otherwise you're not really acting on their concerns, you're acting on what you assume to be their concerns, based on your concerns. So far, with the exception of @ImNtReal (whose request I already had on my to-do list), no one has really voiced any concerns about the PKGBUILD being dangerous, or problematic, or full of mysterious scripts or noise or dependencies or whatever.

That said, I certainly am not vain enough to assume that I've created the best thing since sliced bread and that no one but you will ever come forward to disagree with my point of view or my package building efforts. As far as I know, there might be hordes of already disgruntled users out there that simply don't care enough to leave a comment here, or there might be users that haven't yet taken notice that the package has been updated (it's been more than a year since the last update) and that when they do will disagree just like you do. I mean to say only what I said: I'm willing to wait for them to voice their concerns before I change my ways in order to cater to them.

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.

The install script is already a script, and any user savvy enough to know how to run a separate script after install, should also know how to not run the install script during the install. And as I've already explained, there is nothing "mysterious" about these scripts. If we were talking about spaghetti branching or weird command calls or even some extreme deviation from what upstream dictates, then I would certainly agree with you, not so much out of fear that something bad as in malicious might happen, but out of fear that something bad as in stupid might happen - i.e., I don't trust the quality of third-party scripts any more than you do. But we're not talking about that here, we're talking about a couple of basic mysql commands copied directly from upstream's instructions, some easily decipherable stuff like sed'ing a couple of files with a clearly-written string, and a few elementary if-else blocks to keep it all under control.

Extending your argument, and setting aside the install script for a moment; how can "most users" trust me that I've even built the PKGBUILD itself correctly? Yeah, ZM may build without errors, but how do they know I've applied the correct permissions, or put things in their proper places, or written a proper systemd service, or a proper Nginx conf, or a proper Apache conf... etc? Short answer: they can't. Not to mention that, even if I've implemented everything correctly, advanced users are still likely to modify some of that stuff anyway. Maybe I should consider making the PKGBUILD itself optional, in order to cater to those users as well..?

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

I guess you mean untrusted/untested scripts only, right? Not scripts in general? By the way, the specific example you mention is already checked against in the install script.

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

NextCloud doesn't setup anything itself because a) the maintainer has chosen to do it this way and b) the setup procedure itself is too complicated, with too many variables depending on user choice. Still, nowhere is it mentioned that doing otherwise "might result in downtime or data loss" - that's your own assumption. And it goes without saying that Nextcloud's setup could be performed via a script.

MySQL, PostgreSQL and database servers in general don't create their databases beforehand because it makes no sense to do so due to size constraints, system-specific tuning, etc; not because "you might have data on the server". The database we're talking about is the default 'mysql' schema, there is no sensitive data in there.

I understand your desire for a "fire and forget" install script

And I understand your desire for a simple, bare-bones PKGBUILD. What I don't understand is why you need a PKGBUILD in the first place. You obviously have very specific needs that contradict upstream's choices and/or assumptions, and you obviously consider anything more than a build script as "noise". This means that regardless of what I do, no matter how lean a package I may create, you're bound to check the files manually and decide for yourself what to use and what not to, because that's simply how you do things. And FYI that's exactly how I do things as well, so I can sympathize.

This of course begs the question, why not build the package yourself directly from the source and then install it locally? What's the use of automation if you're gonna bypass it and do everything by hand? But since you'd like to use this package, then it's as I've been saying from the start:

This package is comprised of two separate things: a PKGBUILD script and an install script. Running the former will give you an installable package, and running the latter will install that package for you along with all the bells and whistles that come with a typical install procedure. So all you have to do is comment out the 'install' line along with whatever dependencies you may not need for your special use case, and you're all set - no one will mess with your databases or your web servers, and nothing extraneous will get installed.

Doing this should be a very easy task for you; and as we've already established, you're probably gonna be doing it anyway no matter how I may build the package. And at the same time, this has the advantage of the Average Joe kind of user also being able to have an easy time. While if I do it the other way around, like you describe, you will again have an easy task before you (you'll mostly be doing the exact same thing) but the Average Joe will simply try, then fail, then try again, then fail again, then complain, then get annoyed and go look for another solution that fits their needs better. That's exactly what I've seen happening too many times already, both with ZM and other software and also with Linux in general, and is something I don't wish to happen with this package.

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

As of this new version, upstream recommends that zm.conf stays unmodified and any required changes go into separate *.conf files inside the '/etc/zoneminder/conf.d' folder. And since these files are to be created by the user, they don't need to (nor can they) be included in the backup array because they're not part of the package.

Congratulations to anyone who bothered to read the whole thing ;)