Arch Linux User Repository

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.

I think we should pull out most of the stuff in zoneminder.install. We don't want mysterious SQL to run, databases to restart, webservers to go offline, etc. This kind of thing should always be in the hands of the user. We should print commands that the user should run to the console, or better, refer them to a page in the Arch Linux Wiki.

@ImNtReal

The comments have been flooded a bit by my conversation with @whata-mess, so I will quote here part of a comment a wrote just a couple of days ago as a reply to @chapatt:

"Now that I know everything works fine, If and when I adopt this package (I've filed an orphan request since a couple weeks ago) I aim to change the install procedure into a saner (and safer) one, i.e. provide the needed files and detailed instructions and leave it to the user to setup Nginx, Apache, MariaDB et al as they see fit. And I also want to include a conf file for Apache besides Nginx, and make both of them into optional dependencies with separate instructions for each."

As you see I agree with you, at least in principle. On the other hand Apache is in my eyes an obsolete piece of crap that should really only be deployed when there's no other alternative, e.g. in cases where one has to deal with old software created back in the days when Perl and Apache were reigning supreme - in other words, software like ZoneMinder. But here's the thing: if one can, with a little effort, adapt that old software to work with something else besides Apache, then in my opinion one should make that effort and adapt that software to work with something else, and so get rid of Apache. Which is what I did in this case.

So the real question is: with Apache out of the question, what other web server besides Nginx could one possibly use to run ZoneMinder, that would then justify Nginx becoming an optional dependency along with this new option? The only one I can think of is lighttpd. The problem is, there is no conf file for lighttpd to run ZoneMinder with, which means that adding it to the list of optional web servers would be useless to the majority of the userbase. But I'm willing to do it as long as someone can provide a working conf file for it.

That said, and despite my opinion of Apache, the same goes for Apache: if enough people ask for it (or fewer people but with good reason) then I'm willing to also add it back as a supported web server. But for the time being I think a working Nginx setup is more than enough.

P.S. - For anyone that may be wondering: what I am looking forward to implement is a scenario for a remote MariaDB server. But that will take some work.

Edit: @ImNtReal Forgot to ask you - is there a specific reason you'd prefer Apache instead of Nginx? E.g. an existing setup or something like that?

@Nocifer, it would really make sense to build a package that is http server agnostic if possible. I'll look into doing that for myself.

@ImNtReal

Yup. Just as the previous versions had a hard dependency on Apache. Same situation, much better software.

@alanking

Hmm, for some weird reason I had the installer do the exact opposite, i.e. make sure ZM is running before doing the database upgrade /facepalm

I'll have it fixed for the next release along with some other minor stuff.

Does this really have a hard dependency on nginx, now?

updated here no issues, updated to latest ffmpeg also before the zoneminder upgrade. all running nice, of course i did need to run zmupdate.pl to update database first before starting service after upograde. thanks for all your work!! very happy