Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Fri, 2011-01-14 at 14:28 -0800, Vagrant Cascadian wrote: On Fri, Jan 07, 2011 at 09:49:49AM +1100, Peter Howard wrote: On Tue, 2011-01-04 at 14:44 -0800, Vagrant Cascadian wrote: zoneminder could detect non-default/unknown symlink locations in the preinst script, and fail to upgrade in those cases; not pretty, but maybe better than loosing the database data. In the short term, I don't think there's a neater solution than that. I think we should go with the bail out update with warning approach. here's a preinst which i think should accomplish this safely: #!/bin/sh set -e abort=false if [ -L /usr/share/zoneminder/events ]; then l=$(readlink /usr/share/zoneminder/events) if [ $l != /var/cache/zoneminder/events ]; then abort=true fi fi if [ -L /usr/share/zoneminder/images ]; then l=$(readlink /usr/share/zoneminder/images ) if [ $l != /var/cache/zoneminder/images ]; then abort=true fi fi if [ $abort = true ]; then cat 2 EOF Aborting installation of zoneminder due to non-default symlinks in /usr/share/zoneminder for the images and/or events directory, which could result in loss of data. Please move your data in each of these directories to /var/cache/zoneminder before installing zoneminder from the package. EOF exit 1 fi #DEBHELPER# exit 0 though the warning could use some improvement. looking at the fast approaching squeeze release, and the possibility of data-loss for people switching from manual/source installs to the package, i think it might be worth including this now. long-term, something more sophisticated and intelligent will definitely be needed. One possible addition. Even though it wasn't part of the problem for this bug, what about checking that /usr/share/zoneminder itself is a directory. I could imagine someone putting a link at that level as well. Also, the warning could add reference to /usr/share/doc/zoneminder/README.Debian - I'll add the alternate mount instructions with additional explanation to that file. -- Peter Howard p...@coastal.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Sun, Jan 16, 2011 at 12:02:02PM +1100, Peter Howard wrote: On Fri, 2011-01-14 at 14:28 -0800, Vagrant Cascadian wrote: On Fri, Jan 07, 2011 at 09:49:49AM +1100, Peter Howard wrote: On Tue, 2011-01-04 at 14:44 -0800, Vagrant Cascadian wrote: here's a preinst which i think should accomplish this safely: ... One possible addition. Even though it wasn't part of the problem for this bug, what about checking that /usr/share/zoneminder itself is a directory. I could imagine someone putting a link at that level as well. shouldn't be necessary, since our package doesn't ship /usr/share/zoneminder as a symlink, it would leave the symlink alone and not break anything. Also, the warning could add reference to /usr/share/doc/zoneminder/README.Debian - I'll add the alternate mount instructions with additional explanation to that file. thanks for adding that. this would only be of limited use, since the preinst will fail before the README.Debian is unpacked. it might just be confusing. i'll upload with those changes shortly. live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Fri, Jan 07, 2011 at 09:49:49AM +1100, Peter Howard wrote: On Tue, 2011-01-04 at 14:44 -0800, Vagrant Cascadian wrote: zoneminder could detect non-default/unknown symlink locations in the preinst script, and fail to upgrade in those cases; not pretty, but maybe better than loosing the database data. In the short term, I don't think there's a neater solution than that. I think we should go with the bail out update with warning approach. here's a preinst which i think should accomplish this safely: #!/bin/sh set -e abort=false if [ -L /usr/share/zoneminder/events ]; then l=$(readlink /usr/share/zoneminder/events) if [ $l != /var/cache/zoneminder/events ]; then abort=true fi fi if [ -L /usr/share/zoneminder/images ]; then l=$(readlink /usr/share/zoneminder/images ) if [ $l != /var/cache/zoneminder/images ]; then abort=true fi fi if [ $abort = true ]; then cat 2 EOF Aborting installation of zoneminder due to non-default symlinks in /usr/share/zoneminder for the images and/or events directory, which could result in loss of data. Please move your data in each of these directories to /var/cache/zoneminder before installing zoneminder from the package. EOF exit 1 fi #DEBHELPER# exit 0 though the warning could use some improvement. looking at the fast approaching squeeze release, and the possibility of data-loss for people switching from manual/source installs to the package, i think it might be worth including this now. long-term, something more sophisticated and intelligent will definitely be needed. live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Tue, 2011-01-04 at 14:44 -0800, Vagrant Cascadian wrote: On Tue, Jan 04, 2011 at 06:55:50AM +, Simon Avery wrote: Thanks for the reply! of course! And sorry for my slow reply . . . my mailserver has been broken for some days, only got the flood of correspondence this morning. Like many zoneminder users wanting to use a dedicated mount for cctv storage, I replace /usr/share/zoneminder/events and images with symlinks to the right place (ie, a bigger drive not in /usr) /usr/share/zoneminder/events is a symlink to /var/cache/zoneminder/events in the package, though the same issue could come up for /var. what about mounting /var/cache/zoneminder/events directly (either on it's own filesystem, or using bind mounts), rather than mucking around with symlinks? Perhaps a better way would indeed be to set the path in config, but zoneminder's path config is relative to its home dir, so ../../ to ascend to root and then to your mount of choice might get complicated (unless I've misunderstood it) it doesn't look easily supportable that way, at least to me. It's not. I looked at that in 2006, and it needs significant changes upstream to make that work. I don't think the main developer is against it, it's just never been a high priority. these lines in fstab could allow you to bind-mount an alternate location: /dev/sdX1 /otherdrive ext3 defaults 0 2 /otherdrive/zoneminder/images /var/cache/zoneminder/images bind defaults 0 2 /otherdrive/zoneminder/events /var/cache/zoneminder/events bind defaults 0 2 or if you have a separate partition for each: /dev/sdX1 /var/cache/zoneminder/images ext3 defaults 0 2 /dev/sdX2 /var/cache/zoneminder/events ext3 defaults 0 2 If it is more of a case of changing mounts in a different way, and if it's going to be hard to fix in the upgrade, then I'm happy to change my ways and update zoneminder's wiki on the subject over at http://www.zoneminder.com/wiki/ index.php/Using_a_dedicated_Hard_Drive i can confirm that the symlinks got replaced on upgrading from 1.24.2-6 to 1.24.2-7, as well as on re-install of 1.24.2-7 the package. given your bug report, that wiki page does seem like a dangerous recommendation; please update it! i think directly mounting or bind-mounting would be a much safer approach. i don't think zoneminder is doing anything unusual with those symlinks, they're just part of the package. zoneminder could detect non-default/unknown symlink locations in the preinst script, and fail to upgrade in those cases; not pretty, but maybe better than loosing the database data. In the short term, I don't think there's a neater solution than that. I think we should go with the bail out update with warning approach. We should also add the above mount info to README.Debian someone else noted on this bug report that /var/cache/zoneminder isn't really the right place either... which i also remember thinking when i started helping with zoneminder maintenance, but that will probably have to wait till squeeze+1 (unless that too is deemed RC). I'll raise a separate bug for that. live well, vagrant -- Peter Howard p...@northern-ridge.com.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Tue, Jan 04, 2011 at 06:55:50AM +, Simon Avery wrote: Thanks for the reply! of course! Like many zoneminder users wanting to use a dedicated mount for cctv storage, I replace /usr/share/zoneminder/events and images with symlinks to the right place (ie, a bigger drive not in /usr) /usr/share/zoneminder/events is a symlink to /var/cache/zoneminder/events in the package, though the same issue could come up for /var. what about mounting /var/cache/zoneminder/events directly (either on it's own filesystem, or using bind mounts), rather than mucking around with symlinks? Perhaps a better way would indeed be to set the path in config, but zoneminder's path config is relative to its home dir, so ../../ to ascend to root and then to your mount of choice might get complicated (unless I've misunderstood it) it doesn't look easily supportable that way, at least to me. these lines in fstab could allow you to bind-mount an alternate location: /dev/sdX1 /otherdrive ext3 defaults 0 2 /otherdrive/zoneminder/images /var/cache/zoneminder/images bind defaults 0 2 /otherdrive/zoneminder/events /var/cache/zoneminder/events bind defaults 0 2 or if you have a separate partition for each: /dev/sdX1 /var/cache/zoneminder/images ext3 defaults 0 2 /dev/sdX2 /var/cache/zoneminder/events ext3 defaults 0 2 If it is more of a case of changing mounts in a different way, and if it's going to be hard to fix in the upgrade, then I'm happy to change my ways and update zoneminder's wiki on the subject over at http://www.zoneminder.com/wiki/ index.php/Using_a_dedicated_Hard_Drive i can confirm that the symlinks got replaced on upgrading from 1.24.2-6 to 1.24.2-7, as well as on re-install of 1.24.2-7 the package. given your bug report, that wiki page does seem like a dangerous recommendation; please update it! i think directly mounting or bind-mounting would be a much safer approach. i don't think zoneminder is doing anything unusual with those symlinks, they're just part of the package. zoneminder could detect non-default/unknown symlink locations in the preinst script, and fail to upgrade in those cases; not pretty, but maybe better than loosing the database data. someone else noted on this bug report that /var/cache/zoneminder isn't really the right place either... which i also remember thinking when i started helping with zoneminder maintenance, but that will probably have to wait till squeeze+1 (unless that too is deemed RC). live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
Thank you for the advice on alternatively mounting it. I've updated the wiki and will change my four zoneminder servers over so I don't get bitten again! On Tue, Jan 4, 2011 at 10:44 PM, Vagrant Cascadian vagr...@freegeek.orgwrote: On Tue, Jan 04, 2011 at 06:55:50AM +, Simon Avery wrote: Thanks for the reply! of course! Like many zoneminder users wanting to use a dedicated mount for cctv storage, I replace /usr/share/zoneminder/events and images with symlinks to the right place (ie, a bigger drive not in /usr) /usr/share/zoneminder/events is a symlink to /var/cache/zoneminder/events in the package, though the same issue could come up for /var. what about mounting /var/cache/zoneminder/events directly (either on it's own filesystem, or using bind mounts), rather than mucking around with symlinks? Perhaps a better way would indeed be to set the path in config, but zoneminder's path config is relative to its home dir, so ../../ to ascend to root and then to your mount of choice might get complicated (unless I've misunderstood it) it doesn't look easily supportable that way, at least to me. these lines in fstab could allow you to bind-mount an alternate location: /dev/sdX1 /otherdrive ext3 defaults 0 2 /otherdrive/zoneminder/images /var/cache/zoneminder/images bind defaults 0 2 /otherdrive/zoneminder/events /var/cache/zoneminder/events bind defaults 0 2 or if you have a separate partition for each: /dev/sdX1 /var/cache/zoneminder/images ext3 defaults 0 2 /dev/sdX2 /var/cache/zoneminder/events ext3 defaults 0 2 If it is more of a case of changing mounts in a different way, and if it's going to be hard to fix in the upgrade, then I'm happy to change my ways and update zoneminder's wiki on the subject over at http://www.zoneminder.com/wiki/ index.php/Using_a_dedicated_Hard_Drive i can confirm that the symlinks got replaced on upgrading from 1.24.2-6 to 1.24.2-7, as well as on re-install of 1.24.2-7 the package. given your bug report, that wiki page does seem like a dangerous recommendation; please update it! i think directly mounting or bind-mounting would be a much safer approach. i don't think zoneminder is doing anything unusual with those symlinks, they're just part of the package. zoneminder could detect non-default/unknown symlink locations in the preinst script, and fail to upgrade in those cases; not pretty, but maybe better than loosing the database data. someone else noted on this bug report that /var/cache/zoneminder isn't really the right place either... which i also remember thinking when i started helping with zoneminder maintenance, but that will probably have to wait till squeeze+1 (unless that too is deemed RC). live well, vagrant
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
Package: zoneminder Version: 1.24.2-7 Severity: grave Justification: causes non-serious data loss Like many zoneminder users wanting to use a dedicated mount for cctv storage, I replace /usr/share/zoneminder/events and images with symlinks to the right place (ie, a bigger drive not in /usr) zoneminder upgrade silently deletes these symlinks and recreates the original hard directories there. zoneminder then restarts and zmaudit can no longer find the associated files so kills the events database entries. Result - total emptying of zoneminder database and non-recovery of sorted events, including those archived. Lost three weeks recordings (2tb) data from an entire site, plus archives going back for a year. :( Please include tests for symlinks and leave in place if found. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zoneminder depends on: ii apache22.2.9-10+lenny7 Apache HTTP Server metapackage ii apache2-mpm-prefork [a 2.2.9-10+lenny7 Apache HTTP Server - traditional n ii ffmpeg 4:0.5.2-6 multimedia player, server and enco ii libapache2-mod-php55.3.3-6 server-side, HTML-embedded scripti pn libarchive-tar-perlnone(no description available) ii libarchive-zip-perl1.30-3Perl module for manipulation of ZI ii libavcodec52 4:0.5.2-6 ffmpeg codec library ii libavformat52 4:0.5.2-6 ffmpeg file format library ii libavutil494:0.5.2-6 ffmpeg utility library ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libdate-manip-perl 6.11-1module for manipulating dates ii libdevice-serialport-p 1.04-2+b1 emulation of Win32::SerialPort for ii libdirac-encoder0 1.0.2-3 open and royalty free high quality ii libgcc11:4.4.5-8 GCC support library ii libgnutls262.8.6-1 the GNU TLS library - runtime libr ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libjs-mootools 1.2.4.0~debian1-1 compact JavaScript framework ii libmime-lite-perl 3.027-1 module for convenient MIME message ii libmime-tools-perl 5.428-1 Perl5 modules for MIME-compliant m ii libmysqlclient16 5.1.49-3 MySQL database client library ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expressi ii libphp-serialization-p 0.34-1Perl module to manipulate serializ ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libswscale04:0.5.2-6 ffmpeg video scaling library ii libwww-perl5.836-1 Perl HTTP/WWW client/server librar ii mysql-client-5.0 [mysq 5.0.51a-24+lenny3 MySQL database client binaries ii mysql-server 5.0.51a-24+lenny3 MySQL database server (metapackage ii mysql-server-5.0 [mysq 5.0.51a-24+lenny3 MySQL database server binaries ii perl-modules [libmodul 5.10.1-16 Core Perl modules ii php5 5.3.3-6 server-side, HTML-embedded scripti ii php5-mysql 5.3.3-6 MySQL module for php5 ii rsyslog [system-log-da 4.6.4-2 enhanced multi-threaded syslogd ii zip3.0-3 Archiver for .zip files ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime zoneminder recommends no packages. zoneminder suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608793: Upgrade deletes symlinks /usr/share/zoneminder/events and ../images, replacing with hard dirs.
On Mon, Jan 03, 2011 at 01:15:17PM +, Simon Avery wrote: Like many zoneminder users wanting to use a dedicated mount for cctv storage, I replace /usr/share/zoneminder/events and images with symlinks to the right place (ie, a bigger drive not in /usr) /usr/share/zoneminder/events is a symlink to /var/cache/zoneminder/events in the package, though the same issue could come up for /var. what about mounting /var/cache/zoneminder/events directly (either on it's own filesystem, or using bind mounts), rather than mucking around with symlinks? zoneminder upgrade silently deletes these symlinks and recreates the original hard directories there. i believe this happens at the dpkg level, so might be hard or inappropriate to fix in zoneminder. zoneminder then restarts and zmaudit can no longer find the associated files so kills the events database entries. Result - total emptying of zoneminder database and non-recovery of sorted events, including those archived. Lost three weeks recordings (2tb) data from an entire site, plus archives going back for a year. :( ouch! this seems like a pretty severe way to handle all the files disappearing. will try and reproduce and see if there's a way to detect and avert this situation. just to be clear, it deleted the database entries for the recordings, and not the actual files? Please include tests for symlinks and leave in place if found. while it certainly shouldn't purge cached data so unconditionally, i'm not sure what zoneminder can do when dpkg-managed symlinks and directories are changed manually. so i think we'd have to come up with some alternate method. live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
