Arch Linux User Repository

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

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