Bug#654388: automysqlbackup: Script fails with error when DBNAMES="all"
Package: automysqlbackup
Version: 2.5-6
Severity: important
Tags: patch
I found that the automysqlbackup script (Debian version) fails to run as
expected when setting specific options in the /etc/default/automysqlbackup
configuration file.
Setting 'DBEXCLUDE' with a list of DB names that wish to be excluded.
The documentation states that for this to work you MUST set DBNAMES="all"
This combination will produce an access rights error. This is due to
MySQL being called without the debian.cnf defaults-file.
In the /usr/sbin/automysqlbackup there are already Debian customisations
checking for a configured USERNAME and PASSWORD. If these are not set
then a Debian specific override is used with a reference to the debian.cnf
MySQL config file.
In the case that DBNAMES="all" is set, there was no check and the
variables USERNAME and PASSWORD are expected to exist and be correct.
The attached patch uses the same type of check to override the call to
mysql calling it with the 'defaults-file' option.
A further check through the script did not reveal, to me, any further
issues of this nature.
Regards
Chris
-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- /usr/sbin/automysqlbackup Sun May 16 18:17:52 2010
+++ /tmp/automysqlbackupTue Dec 27 11:00:55 2011
@@ -484,7 +484,11 @@
# If backing up all DBs on the server
if [ "$DBNAMES" = "all" ]; then
+ if [ -z "${USERNAME}" -o -z "${PASSWORD}" ] ; then
+DBNAMES="`mysql --defaults-file=/etc/mysql/debian.cnf --batch
--skip-column-names -e "show databases"| sed 's/ /%/g'`"
+ else
DBNAMES="`mysql --user=$USERNAME --password=$PASSWORD --host=$DBHOST
--batch --skip-column-names -e "show databases"| sed 's/ /%/g'`"
+ fi
# If DBs are excluded
for exclude in $DBEXCLUDE
Bug#652807: Upgrade problem from 0.0.20101107a-1 to 0.0.20110525a-2. Missing files in /etc/dokuwiki.
On 20/12/11 18:00, Tanguy Ortolo wrote: > Chris Moules, 2011-12-20 17:39+0100: >> Recently finding this issue after updating part of the wiki I started >> looking for similar cases. I found this on the dokuwiki >> bug tracker: >> >> http://bugs.dokuwiki.org/index.php?do=details&task_id=2319 >> >> This seemed to point to an old, unrelated, Debian bug, but the report was >> form this year. It looked to, at least in part, mirror >> my issue. > > In fact it is has a completely different cause, only the effect is the > same: in your case, missing conffiles, in the other case, an undefined > function. Yes, I understood that. Certainly the referenced Debian bug. It helped me find my problem however. I believe the original dokuwiki bug report was different however as it is referencing the 2011-05-25 "Rincewind" release and not the 0.0.20080505-4+lenny3 release from that old Debian bug. >> This server has also had '/etc/' restored due to some config file damage. >> That was prior to this upgrade. It is possible that >> the dokuwiki config files were affected by this and therefore the update >> problems. I will need to check on that. > > That sounds like a possible cause indeed, I hope that you will be able > to check it (and I secretely hope that it is really the cause of your > problem ;-) ). I am not able to prove this 100% conclusively, but looking at the evidence to hand, this is probably the root cause. I believe that the dokuwiki config directory was replaced with a incomplete copy (only modified files). I have performed a clean install of dokuwiki on stable with the upgrade path (0.0.20091225c-10+squeeze2) -> dokuwiki_0.0.20101107a-1 -> dokuwiki_0.0.20110525a-2 This was fine and all files were there from the beginning. >> Sorry if this was just noise, I just found and fixed this porblem today and >> so I wanted to 'document' it too before it got >> forgotten. > > Do not be sorry: in doubt, problems should be reported, so this is fine. OK, but I apologise for wasting some of your time. Regards Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652807: Upgrade problem from 0.0.20101107a-1 to 0.0.20110525a-2. Missing files in /etc/dokuwiki.
On 20/12/11 17:05, Tanguy Ortolo wrote: > ... It looks like all the packaged conffiles were > missing after the upgrade. > > These files are managed by dpkg as conffiles. In this case, I think this > means that dpkg does not install them if and only if they were deleted > before the upgrade (in other words, dpkg respects the will of the > administrator, so if he deleted them, it does not install them back, > that is all). > > I have just tried your upgrade path (0.0.20101107a-1 [1] → > 0.0.20110525a-2 [2]), and I could not reproduce that problem, so I have > to assume there was something very wrong with your installation… > > [1] http://snapshot.debian.org/package/dokuwiki/0.0.20101107a-1/ > [2] http://snapshot.debian.org/package/dokuwiki/0.0.20110525a-2/ > This was originally a 'stable' install of 0.0.20091225c-10+squeeze2. Recently finding this issue after updating part of the wiki I started looking for similar cases. I found this on the dokuwiki bug tracker: http://bugs.dokuwiki.org/index.php?do=details&task_id=2319 This seemed to point to an old, unrelated, Debian bug, but the report was form this year. It looked to, at least in part, mirror my issue. Following up on this I did a little digging in the source and found the reference to the configuration file that seemed to be missing. I performed a non-clean 'reinstall' via a 'dpkg -i dokuwiki_0.0.20110525a-2_all.deb' and this also did not prompt or replace the conf files. As the upgrade was not that long ago, plus the dokuwiki bug report, I assumed this to be a packaging bug. This server has also had '/etc/' restored due to some config file damage. That was prior to this upgrade. It is possible that the dokuwiki config files were affected by this and therefore the update problems. I will need to check on that. The wiki is not modified that often and so the cache files might have made this appear a more recent issue than is in fact the case. I will do a little more digging and get back to you. I will also perform a 20091225c-10+squeeze2 -> 0.0.20101107a-1 -> 0.0.20110525a-2 install and upgarde on a test box to check. Sorry if this was just noise, I just found and fixed this porblem today and so I wanted to 'document' it too before it got forgotten. Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652807: Upgrade problem from 0.0.20101107a-1 to 0.0.20110525a-2. Missing files in /etc/dokuwiki.
Package: dokuwiki Version: 0.0.20110525a-2 Severity: important I have performed a manual update/backport of Dokuwiki 0.0.20110525a-2 downloaded from packages.debian.org (dokuwiki_0.0.20110525a-2_all.deb) from the Wheezy repository and installed it into a Debian Squeeze system. # dpkg -i dokuwiki_0.0.20110525a-2_all.deb After doing this, I had noticed that all external links, both automagic and with '[[URL|Link Text]]' format no longer displayed as links in the wiki. Upon editing the relevent part of the page, the URL was seen in the 'source'. I eventually found that additional configuration files that were not in the previous 0.0.20101107a-1 release were missing: /etc/dokuwiki/ entities.conf mediameta.php scheme.conf userstyle.css Extracting these files from the .deb and installing them resolved the issue with the links. This was, probably, exclusively the missing scheme.conf. I have not checked further for additional missing files anywhere else in the package. It seems that these files are not automatically installed upon a package upgrade. The previous package was a older Testing package (0.0.20101107a-1). The 'stable' 0.0.20091225c package is far too old for a system release in 2011. I have not performed a 'clean' test to confirm this. Regards Chris References: http://bugs.dokuwiki.org/index.php?do=details&task_id=2319 -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dokuwiki depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii libphp-simplepie1.2-1RSS and Atom feed parsing in PHP ii php-geshi 1.0.8.4-1Generic Syntax Highlighter ii php55.3.3-7+squeeze3 server-side, HTML-embedded scripti ii ucf 3.0025+nmu1 Update Configuration File: preserv Versions of packages dokuwiki recommends: pn imagemagick | php5-gd (no description available) ii php5-cli5.3.3-7+squeeze3 command-line interpreter for the p Versions of packages dokuwiki suggests: pn libapache2-mod-xsendfile (no description available) -- Configuration Files: /etc/dokuwiki/acl.auth.php.dist [Errno 2] No such file or directory: u'/etc/dokuwiki/acl.auth.php.dist' /etc/dokuwiki/local.php.dist [Errno 2] No such file or directory: u'/etc/dokuwiki/local.php.dist' /etc/dokuwiki/mysql.conf.php.example [Errno 2] No such file or directory: u'/etc/dokuwiki/mysql.conf.php.example' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600908: Improvement to clamav-milter init script
Package: clamav-milter
Version: 0.96.3+dfsg-2~volatile1
We have recently experienced the case that clamav-milter was 'running' but the
socket file was missing. This caused our mail
system (postfix) to reject mail with a temporary error.
Monitoring the service by checking the return code from
'/etc/init.d/clamav-milter status' did not catch this situation.
I have updated the 'status' check to include a check for the sockets existence
and an alternate error code (LSB correct, I
believe). See attached patch.
The patch also fixes the call to 'status_of_proc' with the variable $BASENAME
in place of $NAME (which does not exist).
It also moves the 'local' copy of the function 'status_of_proc' below the
sourcing of '/lib/lsb/init-functions' so that this
version of the function gets called. Before, this local copy of the function
was just unused code in the init script. This local
copy of the LSB function now checks the existence of the clamav-milter socket
as defined in '$SOCKET_PATH'.
Regards
Chris
--- /etc/init.d/clamav-milter 2010-09-23 13:42:48.0 +0200
+++ /tmp/clamav-milter 2010-10-21 10:21:00.892392574 +0200
@@ -23,35 +23,6 @@
[ -x "$DAEMON" ] || exit 0
-status_of_proc () {
-local pidfile daemon name status
-
-pidfile=
-OPTIND=1
-while getopts p: opt ; do
-case "$opt" in
-p) pidfile="$OPTARG";;
-esac
-done
-shift $(($OPTIND - 1))
-
-if [ -n "$pidfile" ]; then
-pidfile="-p $pidfile"
-fi
-daemon="$1"
-name="$2"
-
-status="0"
-pidofproc $pidfile $daemon >/dev/null || status="$?"
-if [ "$status" = 0 ]; then
-log_success_msg "$name is running"
-return 0
-else
-log_failure_msg "$name is not running"
-return $status
-fi
-}
-
to_lower()
{
word="$1"
@@ -276,6 +247,38 @@
SOCKET="$MilterSocket"
fi
+status_of_proc () {
+local pidfile daemon name status
+
+pidfile=
+OPTIND=1
+while getopts p: opt ; do
+case "$opt" in
+p) pidfile="$OPTARG";;
+esac
+done
+shift $(($OPTIND - 1))
+
+if [ -n "$pidfile" ]; then
+pidfile="-p $pidfile"
+fi
+daemon="$1"
+name="$2"
+
+status="0"
+pidofproc $pidfile $daemon >/dev/null || status="$?"
+if ( [ "$status" = 0 ] && [ -S $SOCKET_PATH ] ); then
+log_success_msg "$name is running"
+return 0
+elif ( [ "$status" = 0 ] && [ ! -S $SOCKET_PATH ] ); then
+log_failure_msg "$name socket missing"
+return 4
+else
+log_failure_msg "$name is not running"
+return $status
+fi
+}
+
wait_for_socket()
{
local socket; socket="$1"
@@ -431,7 +434,7 @@
$0 start
;;
status)
- status_of_proc "$DAEMON" "$NAME"
+ status_of_proc "$DAEMON" "$BASENAME"
exit $?
;;
*)
