Broke my APIs on Upgrade

[Nocifer]

Don't worry, we've all been through that stage at some point, it's a necessary part of the process

The logs are optional, yes. Nginx probably complained because there is no /var/log/zoneminder folder (it's what I use in my own setup). Since it's good practice to keep some kind of logs, you could simply change the two entries to somewhere that's a valid location for Nginx to write into, a good place being your webroot, i.e. /usr/share/zoneminder/www. Like so:

Code: Select all

access_log /usr/share/zoneminder/www/http_access.log;
error_log /usr/share/zoneminder/www/http_error.log;

Now, about that 404... well, of course you'll get a 404 since there is no /usr/share/zoneminder/www/zm folder... *facepalm*

You must change

Code: Select all

location /zm {
    try_files $uri $uri/ /index.php?$args =404;    
}

to

Code: Select all

location /zm {
    alias /usr/share/zoneminder/www;
    try_files $uri $uri/ /index.php?$args =404;    
}

Sorry about that.

[databoy2k]

I'm not sure that was the issue; remember that you had me define /usr/share/zoneminder/www as the root at the start of the file. Adding the alias to the /zm didn't help, though; still getting 404 not found.

I'm no longer having the access_log or error_log issues, though. nginx -t says that everything's fine.

I did at one point change the "include /etc/nginx/sites-available/" from "*" to "*.*" just in case the issue was the "zoneminder.conf" file that we've been using. That broke all NGINX serves. Both [ip]:80 and [ip]/zm/index.php returned "connection refused" so I reverted that. Does that tidbit help?

[Nocifer]

Well, having the root defined as

Code: Select all

/usr/share/zoneminder/www

and given a location block (without an alias)

Code: Select all

location /zm

a URL like localhost/zm would result in the erroneous path

Code: Select all

/usr/share/zoneminder/www/zm

which eventually *would be* a problem. The alias solves this by pointing localhost/zm to /usr/share/zoneminder/www, just like localhost/cgi-bin is pointed to /usr/lib/zoneminder/cgi-bin through its own alias.

Bus since you still get the 404, do you by any chance still have default.conf activated (i.e. linked inside sites-enabled)? If yes, then that's probably your culprit. Because both it and zoneminder.conf contain server blocks with equivalent parameters (basically, they both are listening on port 80), and since Ubuntu's default.conf (if I remember correctly) also contains a "default_server" directive, on a potential conflict it gets served with higher priority than zoneminder.conf. So if it's still active, try disabling it and see if ZM works then.

If it doesn't, then I'll install Ubuntu on a VM and personally test this conf file to make sure the damn thing works with a default ZM installation

[databoy2k]

Deleting the default symlink in sites-enabledgot me to Connection Refused. I can still see the default page on [ip]:80.

I've poked around the /var/log/nginx/error.log and found that we were getting warnings of "conflicting server name "localhost" on 127.0.0.1:80, ignored" but those stopped after I deleted "default". I think your theory was right; now is this a permissions issue?

For what it's worth, I figured out where I got the whole "zoneminder.conf in the root spot" idea: it's in the Wiki. I had a chat with BBunge almost a year ago on this system (back when it was still on 17.10) and he (or she) got me up and running on nginx then (I think) updated the wiki with this page: https://wiki.zoneminder.com/Ubuntu_Serv ... e_easy_way

--Edit--
Ok, going to add to what is making me pull my hair out. So I'm at the same status as last time (the Zondeminder.conf is my only listing in Sites-Enabled, it's what we've created, etc.). When I try to connect there via my local network, I'm getting "err_connection_refused" in the client browser. I should note that this is a headless server that used to serve Zoneminder fine before the upgrade (and even afterwards, just not the APIs), but just for giggles I gave a quick "ufw allow 80" followed by a reload to see if that fixed it. Spoiler: it didn't.

Pondering listening issues further, I ran a quick netstat | grep 80. Nothing is listening on port 80. So the next hit was on the server - I ran a curl localhost. Wouldn't you know it, but I get a bunch of HTML that looks an awful lot like Zoneminder's page. So it seems that I'm able to get access to the actual page from the headless server - not sure if it's puking on the php calls, but at least Nginx is listening and serving.

Not sure what this means, though.

[Nocifer]

It's very simple really: it means that between my being tired and my being hasty, I accidentally borked the php block. Which means that your "Connection Refused" was most probably Nginx complaining that it couldn't find anyone to render the 'index.php' file it found; and that "bunch of HTML that looks an awful lot like Zoneminder's page" is the actual ZoneMinder page that curl correctly found (like Nginx did) and simply returns it as unrendered html+php text.

Here is the conf again, corrected. Just overwrite the previous one. Disclaimer: today has also been a long day...

https://pastebin.com/pUSDWiFM

[databoy2k]

I feel like i've blasted past your generosity, but it's still not getting there. I've tried the latest version, nginx -t passes, even checking the status of php7.2-fpm and fcgiwrap (and nginx) via systemctl all passes (all active and running). I'm still getting the ERR_CONNECTION_REFUSED message.

Is there a log I should be pulling?

I should add that curl on the localhost now pulls much more php-looking script (rather than HTML), so we're closer.

[Nocifer]

Nah, don't worry, it's more like a game of whack-a-mole to me at this point. The thing is, it really should be working... I tested that conf myself before I sent it to you - in fact I'm still using it as we speak to access my own ZM setup, and it's working flawlessly, so I know it's functionally valid and without any PHP errors or ERR_CONNECTION_REFUSED or whatever else (minus one small oversight which I've already corrected, but it's merely cosmetic in nature so it's of no concern). The only thing that's different in my conf from the one I gave you is the paths I used. So, first thing to do is check if I've made a mistake somewhere when transliterating. If the paths are good, then... yes, the logs could certainly be helpful. I would need the /usr/share/zoneminder/http_error.log for starters.

In the meantime, I'm installing Ubuntu server myself. Nothing beats hands-on experience. I hope you don't use a docker image but rather iconnor's ppa?

https://launchpad.net/~iconnor/+archive ... inder-1.32

I need to know so I can make sure we've installed the same thing and we use the same paths (God knows how many variations I have seen while reading these forums...).

[databoy2k]

Yes, that's correct. I'm using iConnor's PPA as listed. It just pushed out an update here to 1.32.2.

Nothing in http_error.log. I've also checked Nginx's error and access logs - they're both empty.

The only thing that I can get from the logs is under the http_access.log for zoneminder, a hit last night when I last ran curl; "GET / HTTP/1.1" 200 8635 "-" "curl/7.58.0"

...200 is a success, isn't it?

[Nocifer]

Just tested on a fresh install of Ubuntu 18.04 with ZM installed from iconnor's ppa, and it works great. Just a minor caveat... you're running this from a virtual machine through the network, right? Not from your local machine? So I suppose it would only make sense that the "listen" directive in the conf file should be "listen *:80" rather that "listen localhost:80"...

Can you please make that change and test again? I.e.:

Code: Select all

server {
    listen localhost:80;
    server_name localhost;
    
    // etc

should become

Code: Select all

server {
    listen *:80;
    server_name localhost;

    // etc

[databoy2k]

Yay! Got the index.php to load with that change. It's running on a physical server, but yes I'm accessing it from various other computers around the house. It's not a VM, but removing the "localhost:80" for "*:80" worked.

We're back on topic now. Going to [ip]/zm/api initially pulled up a whole new error, though. CakePHP's default page complains that "URL Rewriting is not properly configured on your server."

I rewrote the /api block to be what I used to have. You'll see that I've commented out your version for mine. Here's the text of the block now:

Code: Select all

        location /zm/api {
#            rewrite ^/zm/api(.+)$ /zm/api/app/webroot/index.php?p=$1 last;
                rewrite ^/zm/api(.+)$ /zm/api/index.php?p=$1 last;
        }

Doing that gets me back to my original issue - a CakePHP error page that reads as follows:

Warning (2): Use of undefined constant ZM_OPT_USE_API - assumed 'ZM_OPT_USE_API' (this will throw an Error in a future version of PHP) [APP/Controller/AppController.php, line 63]
Warning (2): ini_set() [<a href='http://php.net/function.ini-set'>function.ini-set</a>]: Headers already sent. You cannot change the session module's ini settings at this time [CORE/Cake/Model/Datasource/CakeSession.php, line 581]
CakePHP: the rapid development php framework
Warning (2): ini_set() [<a href='http://php.net/function.ini-set'>function.ini-set</a>]: Headers already sent. You cannot change the session module's ini settings at this time [CORE/Cake/Model/Datasource/CakeSession.php, line 581]
Fatal error: Uncaught FatalErrorException: [CakeSessionException] Unable to configure the session, setting session.use_trans_sid failed. #0 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(732): CakeSession::_configureSession() #1 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(219): CakeSession::_startSession() #2 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(248): CakeSession::start() #3 /usr/share/zoneminder/www/api/lib/Cake/View/Helper/SessionHelper.php(134): CakeSession::check('Message.flash') #4 /usr/share/zoneminder/www/api/app/View/Layouts/error.ctp(46): SessionHelper->flash() #5 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(971): include('/usr/share/zone...') #6 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(933): View->_evaluate('/usr/share/zone...', Array) #7 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(546): View->_render('/usr/share/zone...') #8 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(481): View->renderL in /usr/share/zoneminder/www/api/lib/Cake/Error/ErrorHandler.php on line 138

Here's my /var/log/zm/cake_error.log:

Code: Select all

2018-10-19 12:29:14 Error: Fatal Error (256): [CakeSessionException] Unable to configure the session, setting session.use_trans_sid failed.
#0 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(732): CakeSession::_configureSession()
#1 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(219): CakeSession::_startSession()
#2 /usr/share/zoneminder/www/api/lib/Cake/Model/Datasource/CakeSession.php(248): CakeSession::start()
#3 /usr/share/zoneminder/www/api/lib/Cake/View/Helper/SessionHelper.php(134): CakeSession::check('Message.flash')
#4 /usr/share/zoneminder/www/api/app/View/Layouts/error.ctp(46): SessionHelper->flash()
#5 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(971): include('/usr/share/zone...')
#6 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(933): View->_evaluate('/usr/share/zone...', Array)
#7 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(546): View->_render('/usr/share/zone...')
#8 /usr/share/zoneminder/www/api/lib/Cake/View/View.php(481): View->renderLayout('<h2>require_onc...', 'error')
#9 /usr/share/zoneminder/www/api/lib/Cake/Error/ExceptionRenderer.php(328): View->render('error500', 'error')
#10 /usr/share/zoneminder/www/api/lib/Cake/Error/ExceptionRenderer.php(309): ExceptionRenderer->_outputMessageSafe('error500')
#11 /usr/share/zoneminder/www/api/lib/Cake/Error/ExceptionRenderer.php(213): ExceptionRenderer->_outputMessage('fatalError')
#12 /usr/share/zoneminder/www/api/lib/Cake/Error/ExceptionRenderer.php(190): ExceptionRenderer->_cakeError(Object(FatalErrorException))
#13 /usr/share/zoneminder/www/api/lib/Cake/Error/ErrorHandler.php(127): ExceptionRenderer->render()
#14 /usr/share/zoneminder/www/api/lib/Cake/Error/ErrorHandler.php(269): ErrorHandler::handleException(Object(FatalErrorException))
#15 /usr/share/zoneminder/www/api/lib/Cake/Error/ErrorHandler.php(212): ErrorHandler::handleFatalError(64, 'require_once() ...', '/usr/share/zone...', 123)
#16 /usr/share/zoneminder/www/api/lib/Cake/Core/App.php(970): ErrorHandler::handleError(64, 'require_once() ...', '/usr/share/zone...', 123, Array)
#17 /usr/share/zoneminder/www/api/lib/Cake/Core/App.php(943): App::_checkFatalError()
#18 [internal function]: App::shutdown()
#19 {main} in [/usr/share/zoneminder/www/api/lib/Cake/Error/ErrorHandler.php, line 138]

[Nocifer]

See? Because I wouldn't sit down to test things properly, so much time was wasted chasing weird "bugs", and it took me a mere 10 seconds after I fired up Ubuntu's setup to realize that, since it's Ubuntu Server we're talking about, you'd obviously be accessing ZM's Web UI from a browser running on a different system, with a GUI. Lesson learned for next time

Now, that "URL Rewriting" thing you're seeing is the "cosmetic" error I mentioned in the previous post. It's not a major issue because the API can function properly without its static files (css, icons, etc), but as I said I've already fixed it, so you can just download the conf again and overwrite. But make sure to leave the rewrite in the /zm/api block as it was, though, because that other one you used to have is completely wrong - so wrong that it's what actually prompted me to write my own Nginx conf for ZM in the first place. It's also what's producing those other errors.

Just overwrite with a fresh conf and you'll see everything on /zm/api/ turn green. Also, to make sure the API itself is working, visit /zm/api/host/getversion.json and you should get a pretty JSON response saying [ version: "1.32.2", apiversion: "1.0" ] in blue and pink letters.

Edit: Just out of curiosity - those curl commands that actually got through and retrieved the pages, you were running them on the server's console, right?

[databoy2k]

your generosity knows no bounds. You are clearly descended from royalty. Thank you very much for all of your help. Yes, the curl command was coming from within an SSH session into the actual server.

maybe your config file should be added to the wiki.

Take care.

[Nocifer]

Heh, thanks

By the way, I'll leave this here in case someone gets bitten: when running ZM through Nginx, one needs to find a way to run fcgiwrap in multiple instances (e.g. via a little gem called 'multiwatch') in order to be able to view more than one CGI stream simultaneously. This not only affects cases with multiple cameras but it also makes it so that, for example, when editing a zone there is no image from the camera in order to adjust it properly.

Credit goes to user @chapatt for letting me in on the secret.

[databoy2k]

Hm... hadn't noticed in my eagerness that I can't actually view the cameras from the web console. ZM's still accessing them fine (I get alarms by e-mail) but the actual page isn't working. I get the Zoneminder headers, the controls, a list of the events, but where the video should be I just get the broken image icon.

Getting a 404 not found error in the console of Chrome at the same time (http://[ip]/zm/cgi-bin/nph-zms and a bunch of scale, width, etc. info). After the 404 is a strange lookup where (remember: from my remote system) Chrome is apparently trying to pull http://locahost/zm/index.php/zm/index.php?view=request (etc.). My windows 10 client is not running zoneminder, so no surprise that that command is puking out.

I did find in the logs the link pointing me to the FAQ (https://zoneminder.readthedocs.io/en/la ... window-etc), but of course the paths option is gone from the options. Do I need to edit /etc/zm/conf.d/01-system-paths.conf manually to refer to /usr/lib/zoneminder/cgi-bin/nph-zms?

I did up the FCGIWRAP connections as explained in the wiki, but is this part of what you were talking about?

[Nocifer]

Does that "strange call" look like this?

Code: Select all

http://localhost/zm/index.php/zm/index.php?view=request&request=stream&connkey=476597&command=99

If so, it's a known issue already reported upstream and being looked into.

Also, yeah, I forgot that there is a Wiki for ZM where the info about multiwatch and fcgiwrap is probably already included.

That 404 you're getting though is weird. The link to the camera stream should be something like this:

Code: Select all

http://localhost/cgi-bin/nph-zms?...

Not like this:

Code: Select all

http://localhost/zm/cgi-bin/nph-zms?...

I just checked in both Firefox and Chrome and, with the config I gave you, everything is working properly. I really don't understand how it is you could be getting that kind of link...

Do something for me: right-click on that broken image link and choose "Open image in new tab". It will probably still be broken. Then manually edit the address bar and remove /zm from the address and hit Enter, and then check to see if that will get you the image. If yes, we can at least be sure that ZM itself is working.