Bug 973067

Hmm, this definitely isn't something I've seen before.  There was an update pushed to adapt the .conf file for apache 2.4 but it looks to me as if it's correct.  I'll set up a fresh install and take a look.

I found the workaround here:

http://forums.fedoraforum.org/showthread.php?t=288585

It seems to be a known problem documented on the zoneminder site, but if you don't follow their guide, you're not going to notice anything until you run into the problem.

I would like to add in that I'm coming up to 1.25.0-13.fc19.x86_64 via fedup and am hitting this issue as well. I had a working config under F17, but upon upgrading I'm no longer able to stream the monitors or view past events as a stream. If I switch an event to frames and load an individual frame, they're there, so it *is* capturing, but the streams are failing.

If you try and load a stream, the log file will report many of the following (or similar):

socket_sendto( /var/lib/zoneminder/sock/zms-292196s.sock ) failed: No such file or directory

If you watch the /var/lib/zoneminder/sock directory when it's trying to work with that socket, it creates and removes a file similarly named, but with a "w" instead of "s", i.e zms-292196w.sock

Not sure if that's the normal behavior or not, but that's the only thing I'm noticing.

(In reply to Adam DiFrischia from comment #3)
> I would like to add in that I'm coming up to 1.25.0-13.fc19.x86_64 via fedup
> and am hitting this issue as well. I had a working config under F17, but
> upon upgrading I'm no longer able to stream the monitors or view past events
> as a stream. If I switch an event to frames and load an individual frame,
> they're there, so it *is* capturing, but the streams are failing.
> 
> If you try and load a stream, the log file will report many of the following
> (or similar):
> 
> socket_sendto( /var/lib/zoneminder/sock/zms-292196s.sock ) failed: No such
> file or directory
> 
> If you watch the /var/lib/zoneminder/sock directory when it's trying to work
> with that socket, it creates and removes a file similarly named, but with a
> "w" instead of "s", i.e zms-292196w.sock
> 
> Not sure if that's the normal behavior or not, but that's the only thing I'm
> noticing.

Hi Adam,

During trouble-shooting of numerous bugs in Zoneminder package just wondered if
you have the warning below in your journal logs.

If you check the journal log with:
 
journalctl _SYSTEMD_UNIT=zoneminder.service or with httpd.service

do you have this warning message:

: The ScriptAlias  directive in /etc/httpd/conf.d/zoneminder.conf at line 32 will probably never match because it overlaps an earlier ScriptAlias.

Not sure if its related to the socket problem above at the moment just looking at the ScriptAlias problem.

This message was set with selinux permissive, httpd and mysqld started before starting the zmpkg.pl start with sudo.

Regards

Tim

Some of the issues seen during trouble-shooting on Fedora 19 32 Bit.


1) With Selinux in enforcing mode numerous alerts are created which have not all been addressed to date. 

2) Zoneminder.service fails to start due to the zmpkg.pl perl script failing 
to start correctly due to a su issue or several su issues.

3) An alias issue in httpd config setup which seems to be intermittent in nature.

4) A socket problem refer above

5) set date.timmezone in /etc/php.ini config for display dates not set correctly

6) Random shutdownn of Zonealarm demons for no apparent cause that has been found
   to date.

7) Out of date info in readme file for Fedora - relating to item 5.
   should Reference http://php.net/date.timezone not /etc/sysconfig/clock

(In reply to Timothy Ward from comment #4)
> (In reply to Adam DiFrischia from comment #3)
> do you have this warning message:
> 
> : The ScriptAlias  directive in /etc/httpd/conf.d/zoneminder.conf at line 32
> will probably never match because it overlaps an earlier ScriptAlias.

I do have that message showing up, for the httpd.service journal logs.

The ones I seem to have the most are:
* web_php: PNC [Unknown error type: [2] gettimeofday(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning[...]

* httpd: AH00557: httpd: apr_sockaddr_info_get() failed for zoneminder 

* ScriptAlias message as above.

(In reply to Adam DiFrischia from comment #6)
> > 
> > : The ScriptAlias  directive in /etc/httpd/conf.d/zoneminder.conf at line 32
> > will probably never match because it overlaps an earlier ScriptAlias.
> 
> I do have that message showing up, for the httpd.service journal logs.
> 
> The ones I seem to have the most are:
> * web_php: PNC [Unknown error type: [2] gettimeofday(): It is not safe to
> rely on the system's timezone settings. You are *required* to use the
> date.timezone setting or the date_default_timezone_set() function. In case
> you used any of those methods and you are still getting this warning[...]
> 
> * httpd: AH00557: httpd: apr_sockaddr_info_get() failed for zoneminder 
> 
> * ScriptAlias message as above.

Thanks for feedback.

For the gettimeofday function set /etc/php.ini config file in the date.timezone section to your local date timezone using this link as reference:
http://php.net/date.timezone

Please provide feedback if this fixes the issue.

Others bugs are still being trouble-shooted at this time.

Changing that value in the /etc/php.ini does seem to have resolved the issue with the PHP gettimeofday() function.

(In reply to Adam DiFrischia from comment #8)
> Changing that value in the /etc/php.ini does seem to have resolved the issue
> with the PHP gettimeofday() function.

Thanks for the feedback on the date.timezone.

when I have more time I will have a in depth look at the other errors.

(In reply to Adam DiFrischia from comment #6)
> (In reply to Timothy Ward from comment #4)
> > (In reply to Adam DiFrischia from comment #3)
> > : The ScriptAlias  directive in /etc/httpd/conf.d/zoneminder.conf at line 32
> > will probably never match because it overlaps an earlier ScriptAlias.
> 
> * httpd: AH00557: httpd: apr_sockaddr_info_get() failed for zoneminder 
> 

Did some more looking at this. Based on various reports on the web (including https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1159361), and the error in journald from above, I guess the "earlier ScriptAlias" it's indicating is referring to the line "ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" in /etc/httpd/conf/httpd.conf. When commenting that out, the video comes back.

Looking at the same files (httpd/conf.d/zoneminder.conf, and the main httpd .conf) from a working Fedora 17 test VM, both lines co-exist just fine without either needing commenting out. There may have been some kind of other change within Apache which now causes those ScriptAlias' to overlap, I don't know. But I've tested this simple comment workaround both on a vanilla testing VM, and on our production server and it appears to work. The question now is why?

I just installed zoneminder on a fully patched F19 and got this problem.

The "fix" to comment out the ScriptAlias in the /etc/httpd/conf/httpd.conf file solved the problem, but I wonder what effect that will have on something else.

Just wanted to report that this work around is sound.

(In reply to Bill Gradwohl from comment #11)
> I just installed zoneminder on a fully patched F19 and got this problem.
> 
> The "fix" to comment out the ScriptAlias in the /etc/httpd/conf/httpd.conf
> file solved the problem, but I wonder what effect that will have on
> something else.
> 
> Just wanted to report that this work around is sound.

Thanks for the feedback - still have not had a look at why this has to be done
in detail or is just another bug and work around.

There's a lot of discussion going on here.  Would any of the folks here like to have permissions to actually fix the issues you're discussion in the Fedora package?  I can make that happen if you're willing.  I have privileges to work on the package and have tried in the past to keep things going but I really haven't the ability to test it properly or the time to give it the attention it needs.

The single largest problem with zoneminder is its relationship with selinux. It's other issues amount to "how much are you willing to spend to repair that old clunker"?

I've tried to wrap my brain around selinux, but its one thing to understand the concept and quite another to follow Dan's already existing structure. Simply reading what's there doesn't impart why it's the way it is and what led to certain decisions. Only Dan knows those things in detail and that's what's needed to fix the selinux issues.

The fact that zoneminder is perl based, using apache and php is also part of the problem. It's the old way of doing things. IMHO zoneminder needs a rewrite from the ground up using node.js, sqlite3 || MariaDB, and a pure JavaScript client side as a chrome App, not a web page. Expending effort repairing zoneminder could be better spent rewriting it. I don't know perl. I don't want to know perl as it's best days are behind it. Same thing for PHP. Apache is too bloated.

I'm self employed - meaning no one pays me to spend time on anything that doesn't produce an income. I've been a professional programmer my entire life and I'm now semi retired running side businesses on the island I'm on. Those businesses have me writing a Point of Sale system to support them using node.js, sqlite3, and JavaScript as a chrome App. Those technologies are the future.

If there was an income stream attached to a rewrite I'd be interested. I'm simply not in a financial position to volunteer my time and I'm not inclined to become expert on perl/php/apache to use them to keep the existing system breathing a bit longer as I believe zoneminders days are numbered due to technological obsolescence.

I kind of think you missed the point; I can't grant any access to zoneminder upstream but if anyone wants to work on the Fedora package I'm happy to give them access.  Otherwise I think I'm going to have it pulled from Fedora before F20 comes out, because it's essentially unmaintained now.

Selinux issues shouldn't really be something the packager has to do; there were at one time a couple of selinux experts working on the problem, and I largely massaged the package to store things in such a way that they could write a reasonable policy.  It may have bugs and such but those can be reported against the policy.

As for a rewrite, that's not remotely within the scope of what maintenance of the Fedora package would entail.  Just getting the new version building and tested would be nice, I guess.

I've got my notes on how to get zoneminder installed on a brand new F19 system. I'd be willing to post them somewhere because they work. I've nuked my test box several times and I can get zm up each time talking to 2 IP cameras. The manual patching I do to various parts is explained and can be automated to some extent. I even take care of buffer issues related to cpu speed and video streaming.

Pulling zoneminder may not be a bad idea as that might send a signal to the developers that what they have is no longer reasonable. They either fix it or forget it. If Fedora pulls it then Ubuntu, etc may shortly follow the lead. As it is, zm is a pile of spare parts tied together to work using too many unreliable interconnections to other systems. As those other systems evolve, zm is being left behind. This is especially true of its relationship to selinux.

If zm were properly rewritten, selinux wouldn't be a problem at all. There would be no need for su this and su that, no need for Apache, php, and the other parts that glue it together.

I've got one last issue to resolve on my setup having to do with mounting a 4TB drive @ /var/lib/zonemaster to hold all the .jpg files. See: http://forums.fedoraforum.org/showthread.php?p=1669197#post1669197

Once that's resolved, I'll put my box into production at my business and forget about zm for at least 3 years.

(In reply to Bill Gradwohl from comment #16)
> Pulling zoneminder may not be a bad idea as that might send a signal to the
> developers that what they have is no longer reasonable. They either fix it
> or forget it. If Fedora pulls it then Ubuntu, etc may shortly follow the
> lead. As it is, zm is a pile of spare parts tied together to work using too
> many unreliable interconnections to other systems. As those other systems
> evolve, zm is being left behind. This is especially true of its relationship
> to selinux.
> 
> If zm were properly rewritten, selinux wouldn't be a problem at all. There
> would be no need for su this and su that, no need for Apache, php, and the
> other parts that glue it together.
Bill, in order to get Zoneminder rewritten, you'd have to go upstream and discuss your ideas with the Zoneminder project itself; they may welcome some of that, but I doubt you'd get paid. Fedora, as a project, doesn't do the coding for Zoneminder so complaining about it's architecture on a bug report won't do much. The packager's role is to take what is upstream and test and package it for easy end user distribution. And pulling the project probably won't have any results upstream either (complaints would probably just generate a response of "Sorry your distribution doesn't package it, but you can always build from source.").
> I've got one last issue to resolve on my setup having to do with mounting a
> 4TB drive @ /var/lib/zonemaster to hold all the .jpg files. See:
> http://forums.fedoraforum.org/showthread.php?p=1669197#post1669197
I replied to your forum post with some suggestions; please keep the discussion there regarding that issue.

(In reply to Jason Tibbitts from comment #13)
> Would any of the folks here like
> to have permissions to actually fix the issues you're discussion in the
> Fedora package?  I can make that happen if you're willing.  I have
> privileges to work on the package and have tried in the past to keep things
> going but I really haven't the ability to test it properly or the time to
> give it the attention it needs.

Does this mean we'd be taking over the role of package maintainer for Zoneminder? I'm somewhat interested in getting involved, but I'd like to know what your experience with it has been so far, what kind of knowledge is needed, etc. Or is this just a request to be able to edit the files used for building for Fedora?

I would have agreed with the comment to pull it from fedora as the work to keep it going in its present form is time consuming BUT

The latest upstream version 1.26 is now community based and is on github for 
everyone to see, contribute and comment on, this IMHO should result in an outcome
along the same lines as Fedora, as long as the community are willing to help out
and not leave the work to several of the lead contributors and developers. This should also result in packagers concentrating on doing that job, especially for people who have limited time available. For those with the experience but not the time then add your comments to the git as tickets and explain why you believe
they are required. 

I agree a rewrite would be a good start upline but the time factor involved for most contributor and developers would be the stumbling block I would think.

Jason,
I have little experience in packaging for Fedora, but if you could mentor me or sponsor me in this I would be willing to give it a go, if this is not possible maybe someone else is willing to help me out.

I think that Zoneminder evolved to do to much in its present form with the present code base hard for everyone to modify, install, use, package etc. The KISS principle seems to work at the end of the day.

(In reply to Adam DiFrischia from comment #17)
> Does this mean we'd be taking over the role of package maintainer for
> Zoneminder?

To some degree, yes.  I'm still around, I just don't have the time to do the full deal, mainly because I can't really do any useful testing at this point. 

> I'm somewhat interested in getting involved, but I'd like to
> know what your experience with it has been so far, what kind of knowledge is
> needed, etc.

Well, there are some patches that Martin originally added that need to be carried forward to the new version because they're Fedora specific.  Other patches may not be needed with the new version; I'm not sure, but they all need to be checked and moved forward if necessary.

Then there's the matter of updating documentation and fixing the existing bugs that are floating around.  Basically all of the open bugzilla tickets need to be addressed in some way.

Then there's just the matter of dealing with the various packaging systems in order to get an updated release into the wild, get it tested, and get it pushed to stable.

And yes, I can offer sponsorship (as I have the necessary privileges) and mentoring, though if you can come on IRC sometime you would plenty of people in #fedora-devel who could help you out in case I'm not around.

After consideration and doing some digging into past maintenance logs and the processes involved, I don't think maintenance of this package (especially one of this size) is right for me as a beginner packager. That said, since we're currently using it onsite at my place of employment, so I'll be keeping my hands on the application and will be around for bug hunting, testing, troubleshooting, etc. I was also not aware of the move of the source project to GitHub, so I'll also be keeping an eye on that as well; it looks like they may go after something of a rewrite after a bit of housecleaning and UI updates.

I've recently added the fedora rpm development files to the zoneminder source tree on github here: https://github.com/ZoneMinder/ZoneMinder/tree/master/distros/fedora

Your contributions are welcome.  If we can get these files fairly accurate upstream, I'm sure that will make things easier for everyone.

On my to-do list are a few refinements that are mostly described in this bug report.  I fixed them for a Fedora forum user last night and just need to take the time to implement the changes into the spec file.

UPDATE:
After reading a bit through the Apache documentation, I realized what was causing the zoneminder SciptAlias issue.

With this latest version, the following line has been moved to the end of the httpd.conf file:

IncludeOptional conf.d/*.conf

Previously, the conf.d folder was processed before the default ScriptAlias directive, which according to the Apache documentation is the correct way to do this.

http://httpd.apache.org/docs/2.4/mod/mod_alias.html#order

(In reply to Andrew Bauer from comment #22)
> UPDATE:
> After reading a bit through the Apache documentation, I realized what was
> causing the zoneminder SciptAlias issue.
> 
> With this latest version, the following line has been moved to the end of
> the httpd.conf file:
> 
> IncludeOptional conf.d/*.conf
> 
> Previously, the conf.d folder was processed before the default ScriptAlias
> directive, which according to the Apache documentation is the correct way to
> do this.
> 
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#order

Great work, This should put this issue to rest.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.