ZoneMinder Forums

Hi all:
I've configured all without problem, but when I try to login into zone minder, the login page is loaded again, and again...
I'm using 1.20.1 version in a Suse 9.1.
I've checked the code in zm_funcs.php, but I can't find where is the problem...
What I can check to solve the problem?

Thanks.

Any errors in the error logs???
Did you check to see if the database was created?

the zmdc.log show me the next:
Starting pending process, zmfilter.pl
'zmfilter.pl' started at 05/02/08 17:59:17
'zmfilter.pl' starting at 05/02/08 17:59:17, pid = 8829
Can't locate LWP/UserAgent.pm in @INC (@INC contains: /usr/lib/perl5/5.8.3/i586-linux
BEGIN failed--compilation aborted at /usr/local/bin/zmupdate.pl line 185.
'zmupdate.pl -c' crashed at 05/02/08 17:59:17, exit status 2
Can't locate MIME/Entity.pm in @INC (@INC contains: /usr/lib/perl5/5.8.3/i586-linux-t
BEGIN failed--compilation aborted at /usr/local/bin/zmfilter.pl line 101.
'zmfilter.pl ' crashed at 05/02/08 17:59:17, exit status 2

The other things seem to be ok...

If you go through the README there is great detail on the error.
You are missing perl modules.
Follow the details in the README and you will be up and running in no time.
Cheers,
Cordel

Hi all,
I've been lurking for awhile hoping to see more reports of success or failure with this login issue.
While the errors in zmdc.log are certainly perl module related, I am skeptical that they are connected to the login issue.
The login issue appeared with v.1.20.0 on Mandrake 10.0. It continues thru v1.20.1. This thread indicates Suse 9.1 is also affected.
The problem has also been reported on Suse 9.2. In this thread:
http://www.zoneminder.com/forums/viewto ... c&start=15
There seems to be a clue here in unclerichy's report:

However, $_SESSION['user'] seems to be vanishing between then and zm_html_view_postlogin.php, resulting in being thrown back to the login screen.

EDIT: Hmmm. I've just installed an evaluation version of the Zend debugger and all of a sudden I can log on

According to this thread Debian unstable is also affected.
http://www.zoneminder.com/forums/viewto ... ight=login

Reports indicate that FC3, Mandrake 10.1, and Gentoo are not affected by this problem.
Is this an accurate picture, or are some have no trouble with the "older" distros? More reports, either "Works fine on DistroXXX", or "Broken on DistroYYY" would help fill in the picture. Anyone having success with FC2?
The big question for me is, is this a configuration problem, or is backward compatability with all the LiveCD installations broken?
Some guidance in debugging this would be welcome.

Best regards,

Ross

Hi Ross,

Replied in pm, but feel free to post the results to this thread. FYI I can login and out etc on FC1 and FC2 without any problems. I suspect this is php session related but until I can get to a machine to try things out I can't be sure.

Phil

CANNOT LOGIN - 100% reliably, since upgrading from 1.19.4 to 1.20.1

Debian "unstable", uname reports: Linux dvrhc 2.6.7-1-686 #1 Thu Jul 8 05:36:53 EDT 2004 i686 GNU/Linux

System worked fine with authentication as 1.19.4, but WILL NOT
accept login now that it's upgraded to 1.20.1. I cannot let this
go out in the field this way, I have to keep some users from messing
about with settings, so I NEED logins to work.

Fortunately I only upgraded a backup system, so the lack of
logins on THIS box is not a killer. But it would be good to get
a version that didn't have the "creates too many zmc processes"
bug. To workaround that, I restart ZM every night in the cron.

I can provide an ssh login to the system if Philip would like to debug
that way.

Bill Dudley

Hi Bill,

Mail me the details and I'll have a dig around. I've been waiting to get access to a system where this glitch manifests itself so this should hopefully be useful.

Phil

OK, following these instructions:

One thing to try, to get a handle on this, is to get to the login screen then edit zm.php and set $debug to true, also uncomment the error_reporting( E_ALL ) line. Then continue the login process one more step.

This is the output I get:
**************************************************************************************
PHP Variables
Variable Value
PHP_SELF /zm/index.php
_REQUEST["bandwidth"] high
_REQUEST["ZMSESSID"] 48078a5f75e9a56e75f36eb244d93375
_COOKIE["bandwidth"] high
_COOKIE["ZMSESSID"] 48078a5f75e9a56e75f36eb244d93375
_SERVER["HTTP_HOST"] 127.0.0.1
_SERVER["HTTP_USER_AGENT"] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040301 Firefox/0.8
_SERVER["HTTP_ACCEPT"] text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
_SERVER["HTTP_ACCEPT_LANGUAGE"] en-us,en;q=0.5
_SERVER["HTTP_ACCEPT_ENCODING"] gzip,deflate
_SERVER["HTTP_ACCEPT_CHARSET"] ISO-8859-1,utf-8;q=0.7,*;q=0.7
_SERVER["HTTP_KEEP_ALIVE"] 300
_SERVER["HTTP_CONNECTION"] keep-alive
_SERVER["HTTP_REFERER"] http://127.0.0.1/zm/index.php
_SERVER["HTTP_COOKIE"] bandwidth=high; ZMSESSID=48078a5f75e9a56e75f36eb244d93375
_SERVER["PATH"] /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
_SERVER["SERVER_SIGNATURE"] <address>Apache-AdvancedExtranetServer/2.0.48 (Mandrake Linux/6.3.100mdk) PHP/4.3.4 Server at videoserver.local.domain Port 80</address>
_SERVER["SERVER_SOFTWARE"] Apache-AdvancedExtranetServer/2.0.48 (Mandrake Linux/6.3.100mdk) PHP/4.3.4
_SERVER["SERVER_NAME"] videoserver.local.domain
_SERVER["SERVER_ADDR"] 127.0.0.1
_SERVER["SERVER_PORT"] 80
_SERVER["REMOTE_ADDR"] 127.0.0.1
_SERVER["DOCUMENT_ROOT"] /var/www/html
_SERVER["SERVER_ADMIN"] root@localhost
_SERVER["SCRIPT_FILENAME"] /usr/lib/zm/html/index.php
_SERVER["REMOTE_PORT"] 32829
_SERVER["GATEWAY_INTERFACE"] CGI/1.1
_SERVER["SERVER_PROTOCOL"] HTTP/1.1
_SERVER["REQUEST_METHOD"] GET
_SERVER["QUERY_STRING"] no value
_SERVER["REQUEST_URI"] /zm/index.php
_SERVER["SCRIPT_NAME"] /zm/index.php
_SERVER["PHP_SELF"] /zm/index.php
_SERVER["PATH_TRANSLATED"] /usr/lib/zm/html/index.php
_SERVER["argv"]

Array
(
)

_SERVER["argc"] 0
_ENV["LESSKEY"] /etc/.less
_ENV["LC_PAPER"] en_US
_ENV["KDE_MULTIHEAD"] false
_ENV["LC_ADDRESS"] en_US
_ENV["LC_MONETARY"] en_US
_ENV["HOSTNAME"] videoserver.local.domain
_ENV["SHELL"] /bin/bash
_ENV["LC_SOURCED"] 1
_ENV["HISTSIZE"] 1000
_ENV["XDM_MANAGED"] /var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,rsvd
_ENV["GTK2_RC_FILES"] /usr/share/themes/Galaxy/gtk-2.0/gtkrc:/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/.kde/share/config/gtkrc
_ENV["GS_LIB"] /home/user/.fonts
_ENV["WINDOWID"] 27262983
_ENV["LC_NUMERIC"] en_US
_ENV["QTDIR"] /usr/lib/qt3/
_ENV["LOCPATH"] /etc/locale
_ENV["KDE_FULL_SESSION"] true
_ENV["XCURSOR_SIZE"] no value
_ENV["LC_TELEPHONE"] en_US
_ENV["SUDO_USER"] user
_ENV["SUDO_UID"] 501
_ENV["KONSOLE_DCOP"] DCOPRef(konsole-4261,konsole)
_ENV["DESKTOP_SESSION"] default
_ENV["PATH"] /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
_ENV["LC_MESSAGES"] en_US
_ENV["LC_IDENTIFICATION"] en_US
_ENV["LC_COLLATE"] en_US
_ENV["KONSOLE_DCOP_SESSION"] DCOPRef(konsole-4261,session-1)
_ENV["INPUTRC"] /etc/inputrc
_ENV["EDITOR"] vi
_ENV["LANG"] C
_ENV["LC_MEASUREMENT"] en_US
_ENV["SHLVL"] 4
_ENV["SUDO_COMMAND"] /sbin/service httpd restart
_ENV["LANGUAGE"] en_US:en
_ENV["XCURSOR_THEME"] handhelds
_ENV["GCONF_TMPDIR"] /tmp
_ENV["LESS"] -MM
_ENV["LC_CTYPE"] en_US
_ENV["DESKTOP"] kde
_ENV["SUDO_GID"] 501
_ENV["LC_TIME"] en_US
_ENV["TEXTDOMAINDIR"] /etc/locale
_ENV["G_BROKEN_FILENAMES"] 1
_ENV["XAUTHORITY"] /home/user/.Xauthority
_ENV["LC_NAME"] en_US
_ENV["_"] /sbin/initlog


Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /usr/lib/zm/html/zm.php:28) in /usr/lib/zm/html/zm.php on line 148

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /usr/lib/zm/html/zm.php:28) in /usr/lib/zm/html/zm.php on line 148

Notice: Use of undefined constant STATE_IDLE - assumed 'STATE_IDLE' in /usr/lib/zm/html/zm_config.php on line 54

Notice: Use of undefined constant STATE_PREALARM - assumed 'STATE_PREALARM' in /usr/lib/zm/html/zm_config.php on line 55

Notice: Use of undefined constant STATE_ALARM - assumed 'STATE_ALARM' in /usr/lib/zm/html/zm_config.php on line 56

Notice: Use of undefined constant STATE_ALERT - assumed 'STATE_ALERT' in /usr/lib/zm/html/zm_config.php on line 57

Notice: Use of undefined constant STATE_TAPE - assumed 'STATE_TAPE' in /usr/lib/zm/html/zm_config.php on line 58

Notice: A session had already been started - ignoring session_start() in /usr/lib/zm/html/zm_html.php on line 32

***************************************************************************************

Ross

I've finally cracked this issue and it was a right bugger!

The problem appears to be that in certain versions of php if you declare a superglobal variable (e.g. $_SESSION) as a 'global' in a function it effectively only modifies a local copy.

There are several functions that do this in zm_funcs.php (and possibly elsewhere), for backwards compatibility with versions of php < 4.1.0. This all works fine and dandy in 4.3.8 which I have but on Bill's machine which has 4.3.4 it doesn't work and so breaks logins. The only change from 1.19.x to 1.20.x in this regard was that I went from using the old style $HTTP_SESSION_VARS to the new style $_SESSION. Using the old style names appears to still work but the news ones don't.

I don't know what is supposed to happen if you declare a superglobal as a gloabl but I would guess that it should just ignore the declaration (as it appears to in 4.3. so I suspect this is a bug in php 4.3.4 (and possibly other versions).

I don't have a fully kosher workaround yet as I don't want to break anything else but for now you can edit zm_funcs.php and remove any global declarations of superglobals, so you can delete lines that look like
and changes lines that look like
to Do this where you see 'global' on the same line as $_SESSION or $_SERVER to be on the safe side, though I suspect it only affects a handful of functions that actual write to the variables.

I hope that's helpful to everyone, this bugger has taken me hours to find.

Phil

zoneminder wrote:I've finally cracked this issue and it was a right bugger!

The problem appears to be that in certain versions of php if you declare a superglobal variable (e.g. $_SESSION) as a 'global' in a function it effectively only modifies a local copy.
I don't have a fully kosher workaround yet as I don't want to break anything else but for now you can edit zm_funcs.php and remove any global declarations of superglobals, so you can delete lines that look like

Code: Select all

global $_SESSION;

and changes lines that look like

Code: Select all

global $user, $_SESSION;

to

Code: Select all

global $user;

Do this where you see 'global' on the same line as $_SESSION or $_SERVER to be on the safe side, though I suspect it only affects a handful of functions that actual write to the variables.

I hope that's helpful to everyone, this bugger has taken me hours to find.

Phil

When I made these changes to my system, I could log in just fine, but none of the images or movies would come up properly. They all showed with broken links. When I turned security back off, they then worked properly. I removed the _session and _server global entries.


Zoneminder 1.20.x, Redhat 9, Apache 2, PHP 4.2.2

Actually you're probably safe leaving the $_SERVER ones in there. Any functions that just read $_SESSION can probably be left as well. It's only the ones that write to it that seem to have a problem.

I'll probably have a proper workaround for this in a few days time.

Phil

zoneminder wrote:Actually you're probably safe leaving the $_SERVER ones in there. Any functions that just read $_SESSION can probably be left as well. It's only the ones that write to it that seem to have a problem.

I'll probably have a proper workaround for this in a few days time.

Phil

I'll take a gander with it later this afternoon, adding the _server back in.
My wife loves configurability of the system.
I placed one of the new DCS-900s on a window sill, and setup a basic zone, ruling out the neighbors drive, but allowing ours. She was impressed that the neighbors car moving didnt set it off, but walking up our drive did.

Will take some time to tweak the zones and levels, but the prognosis is good.
Just need to build some custom enclosures to protect the cameras.