Andreas Metzler schrieb:
On 2009-01-08 em...@t-online.de wrote:
Package: exim4-base
Version: 4.63-17
Severity: normal
This is probably not a problem for "normal" usage of the package, but there is
an error in the way exim4_refresh_gnutls-params handles input parameters. When
specifying a configuration file as argument it will be correctly processed
CONF_FILE=/etc/exim4/configure
if [ $# -gt 0 ] ; then
CONF_FILE=$1
fi
but later on the line
TIMEOUT=${1:-1800}
will also evaluate to the configuration file's full path. As a consequence
/usr/share/exim4/timeout.pl "$TIMEOUT" /usr/bin/openssl gendh 1024 \
> "$tempgnutls" 2> /dev/null
will silently fail and no update of the TLS parameters ever happens.
An easy fix for my case is below, but my patch might be inappropriate as this
will produce an error for all invocations of using exim4_refresh_gnutls-params
specifying only a timeout.
--- exim4_refresh_gnutls-params.orig 2009-01-07 00:10:19.639332073 +0100
+++ exim4_refresh_gnutls-params 2009-01-07 00:10:46.172990323 +0100
@@ -9,6 +9,7 @@
CONF_FILE=/etc/exim4/configure
if [ $# -gt 0 ] ; then
CONF_FILE=$1
+ shift
fi
# regenerate $EXIM4_SPOOLDIR/gnutls-params
[...]
As the machine running the exim installation is a production box and has no
reportbug installed I tried to manually create the proper format for the bug
report, so please excuse me if it is important details.
Hello,
I somehow have got the feeling that either I am looking at the wrong
file or that the script on the respective machine is locally
customized. :-( I cannot find similar code in either the package
version you reported it against
http://svn.debian.org/wsvn/pkg-exim4/exim/tags/4.63-17/debian/exim4_refresh_gnutls-params?op=file&rev=0&sc=0
or the current one
http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/exim4_refresh_gnutls-params?op=file&rev=0&sc=0
Hi,
sorry for the noise. Your are right in that the file was (badly!) locally
modified even though I've no clue how this has happend (absolutely no
recollection I've ever touched or read this script nor was a backup of original
version lying around what I always do, but apparently...).
Any ideas?
Thanks, cu andreas
Sorry for not checking against SVN first and waisting your time
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
