Package Details: zoneminder 1.36.33-2

Git Clone URL: https://aur.archlinux.org/zoneminder.git (read-only, click to copy)
Package Base: zoneminder
Description: A full-featured, open source, state-of-the-art video surveillance software system
Upstream URL: https://www.zoneminder.com/
Keywords: camera cctv monitor record security surveillance video zoneminder
Licenses: GPL-2.0-only
Conflicts: zoneminder-git
Submitter: None
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 72
Popularity: 1.48
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2024-02-12 12:50 (UTC)

Dependencies (46)

Sources (8)

Latest Comments

« First ‹ Previous 1 .. 18 19 20 21 22 23 24 25 26 27 28 .. 62 Next › Last »

pgkool commented on 2019-01-14 00:55 (UTC) (edited on 2019-01-14 00:56 (UTC) by pgkool)

30+ pages of comments, and outdated documents, I must say I am very in need of help. I installed from scratch, got all the dependencies (did no configuration changes from wiki, as it looks like its all self contained now) and then started 4 services below"

nginx.service zoneminder.service fcgiwrap-multiwatch php-fpm.service

All the services look like they are successful in starting, no errors all active.

I do not see any logs in /var/log/zoneminder/*

I AM able to (from a remote machine) get to the ngnix served page (http://<my ip>) however when I navigate to zoneminders page (http://<my ip>/zoneminder/), I get a 404 error.

I am new to this, and I see a comment about "had to edit the ZM nginx conf to access remotely" by @DaMadOne, but could not find the information for this change.

Any ideas?

Nocifer commented on 2018-12-20 12:14 (UTC)

@DaMadOne Hmm, no, that was the whole point of the new privileges, to avoid precisely this issue. Do you remember what kind of error you got? Was it perhaps a db root password error? Also, could you check if the 'zm' user has the new privileges as listed in the install script? If not, could you do me a favor and manually run the commands in the install script's post_upgrade function? For convenience, this is the interesting part:

# Temporary solution to apply new privileges on preexisting user & database
# Check for database root password
if [[ "$(mysql -uroot -e "select * from mysql.user;" 2>&1)" = *"Access denied"* ]]
then
    # If a database root password is set
    echo
    echo "* Secure MariaDB installation found, please enter the database root password."
    echo
    mysql -uroot -p -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"
else
    # If a database root password is not set
    mysql -uroot -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"
fi

This should have performed the same checks performed in the equivalent block in post_install, and seeing as you have created a db root password, it should have ended up running the first command (with the -p option). So, I'd like you to run:

if [[ "$(mysql -uroot -e "select * from mysql.user;" 2>&1)" = *"Access denied"* ]]; then echo "true"; fi

...which should print "true". If it doesn't print "true", then we have a faulty check. If it does print "true", next up would be to run:

mysql -uroot -p -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"

...which should ask you for your db root password, and then perform the upgrade without errors. If any errors whatsoever are produced, then we have a faulty db command.

DaMadOne commented on 2018-12-19 02:51 (UTC) (edited on 2018-12-19 02:57 (UTC) by DaMadOne)

Had problems updating to 1.32.3 from 1.32.2

had to mysql -u root -p and then set global log_bin_trust_function_creators=1; before running zmupdate.pl to upgrade database, Then ran mysql -hlocalhost -u zmuser zm < /usr/share/zoneminder/db/zm_update-1.32.3.sql in order run zoneminder.

was this intended behavior after "Gave 'zmuser' some new privileges on database 'zm' that are needed to perform the 1.32.3 update." Nocifer?

Nocifer commented on 2018-12-10 19:28 (UTC)

@a36233 weird, it should have been installed along with the rest of the modules, it's a dependency after all. Why would it be the only one missing? You could try reinstalling the perl-sys-mmap package, maybe something went wrong. Or maybe you're trying to install it on ARM..? But that would mean you bypassed this package's architecture field.

Other than that I can't really think of anything else.

a36233 commented on 2018-12-10 11:19 (UTC)

-- Checking for perl module Sys::Mmap -- Checking for perl module Sys::Mmap - failed -- Could NOT find PerlModules (missing: PERLMODULES_SYS_MMAP_MODULE) CMake Error at CMakeLists.txt:764 (message): Not all required perl modules were found on your system

Nocifer commented on 2018-12-09 17:30 (UTC) (edited on 2018-12-09 17:37 (UTC) by Nocifer)

@DaMadOne: Thanks, I'm glad it worked out so well for you :)

@Kubax: Just a heads up, while I was testing this new update I hit your bug. I was only using makepkg at the time so it's definitely not a trizen bug, it's something to do with ZM itself (maybe the missing database privileges?) but I couldn't bother to properly debug it. In any case, I added the --nointeractive flag to the zmupdater.pl call so now it won't try to ask you nothing ever again, it will just do its job in obedient silence. So problem "solved" :P

DaMadOne commented on 2018-12-04 01:07 (UTC) (edited on 2018-12-04 01:08 (UTC) by DaMadOne)

I just wanted to say thank you to Nocifer for the time spent on this PKGBUILD. It looks like this is much more in line with what it should be. I had not upgraded my home server in probably 6 months because it got to the point where I felt that every time I did I had to fiddle with ZM.

I came to see what if anything had happened with it the other day and saw all of the work you have put into it and decided to nuke my old ZM install and upgrade the system and then reinstall ZM from scratch... I was not disappointed. After removing everything associated with ZM in the past and issuing yay -S zoneminder it just worked as far as your end is concerned(had to edit the ZM nginx conf to access remotely, but you have already stated that is fixed on your end for a future PKGBUILD update)

If anyone else runs into issues using remote RTSP feeds as I did it seems(as far as i have read in the ZM forums) they are deprecating remote RSTP in favor of using FFMPEG or libVLC. Personally I have lower CPU usage using FFMPEG but YMMV.

Not related to ZM on Arch.. but maybe one day I'll dive into using containers for the different things I use my home server for.. one day.

khvalera commented on 2018-11-23 07:53 (UTC)

add configuration file: backup=("etc/zoneminder/zm.conf"

Nocifer commented on 2018-11-21 13:28 (UTC) (edited on 2018-11-21 13:50 (UTC) by Nocifer)

@antoined I've already encountered the issue with remote access and have actually completely removed server_name in my current conf (it was only there in the first place because of my directly translating upstream's Apache conf, which contains an equivalent directive, but it's not actually needed for Nginx) and I have also changed the listen directive to '*', because it also causes similar issues if one tries to access a ZM instance from a different PC running on the same LAN (because it won't accept non-local connections). I haven't uploaded the new conf file yet (along with some other fixes for minor oversights like this) because I'm waiting for the next upstream update before I force a new update down your throats - thanks for reporting it though :)

@khvalera Regarding your first comment, my conf file has it correctly as '$pkgdir/etc/httpd/conf/extra/$pkgname.conf', so this is probably an oversight that I've already corrected at some point, so it will be included in the next update.

(EDIT: Actually, scratch that. I just checked the AUR repo and as far as I can see, there never was an erroneous $pkgdir/etc/httpd/conf/extra/httpd-$pkgname.conf reference in the PKGBUILD, it's always been $pkgname.conf as it should be; which also makes sense because otherwise the install script wouldn't have been working correctly and I would have caught the error. Are you sure this line is from my own PKGBUILD?)

Regarding your second comment, this is just a harmless warning from Pacman. I know which part of the PKGBUILD is causing it, so I may look for a way to "fix" it in the future, but it's really not a thing to worry over.

EDIT 2: Also, please try to use English in your comments. I would have no clue of what you said if it weren't for the fact that you referenced an error message that I recognized.

« First ‹ Previous 1 .. 18 19 20 21 22 23 24 25 26 27 28 .. 62 Next › Last »