Bug#484974: The requested harmfull behavior
Hi, Today I upgraded -- till today I created my own security fixes for the Sarge packages -- one of my servers and have been badly bitten by this bug. The system has five virtual aliases which resulted in: hoefnix2:~# grep -E 'ntp' /var/log/syslog Dec 19 10:07:05 hoefnix2 ntpdate[3801]: step time server 85.214.111.97 offset -3600.199028 sec Dec 19 09:07:05 hoefnix2 ntpdate[3772]: step time server 81.169.180.23 offset -3600.193623 sec Dec 19 08:07:06 hoefnix2 ntpdate[3736]: step time server 131.234.137.24 offset -3600.191320 sec Dec 19 07:07:07 hoefnix2 ntpdate[3760]: step time server 131.234.137.24 offset -3600.189649 sec Dec 19 06:07:09 hoefnix2 ntpdate[3748]: step time server 85.214.111.97 offset -3600.198522 sec Dec 19 05:07:09 hoefnix2 ntpdate[3816]: step time server 88.198.46.111 offset -3600.190780 sec I suspect that every instance didn't realize that another had already corrected the summer/winter time conversion. Yes I do'nt want to run my servers in the confusing UTC time. I'm human, not a computer :). So the time has to be the time I see on the clocks at my desk. Also customers report events at that time and I don't want to think about adding or substracting one or two hours in logs. Henk van de Kamer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481755: Still a problem with a remotre MySQL server
Package: libdspam7-drv-mysql Version: 3.6.8-5etch1 Severity: important In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388140 a patch was proposed to solve the problem with a remote MySQL server. In 3.6.8-5etch1 the script has become more complex and introduced the problem again, although with a different message: ve45:/etc/cron.daily# ./libdspam7-drv-mysql ERROR 1046 (3D000) at line 5: No database selected The reason is that in the newer script the $MYSQL_DB in the above proposed patch has disappeared in the second case. The following patch corrects that: ve45:/etc/cron.daily# diff -u libdspam7-drv-mysql.old libdspam7-drv-mysql --- libdspam7-drv-mysql.old 2008-05-18 13:46:26.0 +0200 +++ libdspam7-drv-mysql 2008-05-18 13:47:33.0 +0200 @@ -28,9 +28,9 @@ else if echo $MYSQL_HOST | grep ^/ /dev/null 21 ; then # Assume it is a socket: -/usr/bin/mysql --defaults-extra-file=$MYSQLCONF_PASSWD --socket=$MYSQL_HOST --user=$MYSQL_USER $PURGE +/usr/bin/mysql --defaults-extra-file=$MYSQLCONF_PASSWD --socket=$MYSQL_HOST --user=$MYSQL_USER $MYSQL_DB $PURGE else -/usr/bin/mysql --defaults-extra-file=$MYSQLCONF_PASSWD --host=$MYSQL_HOST --user=$MYSQL_USER $PURGE +/usr/bin/mysql --defaults-extra-file=$MYSQLCONF_PASSWD --host=$MYSQL_HOST --user=$MYSQL_USER $MYSQL_DB $PURGE fi fi -- Henk van de Kamer http://www.vandekamer.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422224: building with libmysqlclient12-dev doesn't work
Package: php5 Version: 5.2.0-8+etch3 I'm building my own version (don't need LDAP for example) and got the following error: checking whether to enable embedded MySQLi support... no checking for mysql_set_server_option in -lmysqlclient... no configure: error: wrong mysql library version or lib not found. Check config.log for more information. make: *** [configure-apache2-stamp] Error 1 The reason is that the build-dependancies read: libmysqlclient15-dev | libmysqlclient12-dev and when you use the latter it goes wrong. Installing the first resolves the build error. This one is needed for the mysqli extension which is now default packaged in php5-mysql. That one needs libmysqlclient15 so depending on libmysqlclient12-dev seems odd? Henk van de Kamer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421315: debian-udeb/gpgv is packaged in .deb?
Package: gnupg Version: 1.4.6-2 I'm building my own version and don't need the udeb packages. That's why I discoverd the following: : # gpgv -rm -rf debian/gpgv $(install_dir) debian/gpgv/DEBIAN/ $(install_dir) debian/gpgv/usr/bin/ $(install_binary) build-udeb/g10/gpgv debian/gpgv/usr/bin/ $(STRIP) debian/gpgv/usr/bin/gpgv In the 6th line there is a build-udeb and if I understand this correctly the version build for udeb is packaged in the .deb? Not a problem if both are the same, but if not... Henk van de Kamer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419992: logrotate gives defunct process
Package: lighttpd Version: 1.4.13-4 When Lighttpd is used in combination with PHP trough fast-CGI (probably also others?) the logrotate raises the following defunct proces: 12087 ?S 0:00 /USR/SBIN/CRON 12088 ?Ss 0:00 /bin/sh -c test -x /usr/sbin/anacron || run-parts --r 12089 ?S 0:00 run-parts --report /etc/cron.daily 12108 ?Zs 0:00 [logrotate] defunct After a lot of trial and error it seems that the addition of 21 to both lines in the /etc/logrotate.d/lighttpd solves this problem: postrotate if [ -f /var/run/lighttpd.pid ]; then \ if [ -x /usr/sbin/invoke-rc.d ]; then \ invoke-rc.d lighttpd force-reload /dev/null 21; \ else \ /etc/init.d/lighttpd force-reload /dev/null 21; \ fi; \ fi; Henk van de kamer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380080: Logrotate hangs
Hi, The following check was introduced in version 1.4.13-4 of the force-reload | restart section in /etc/init.d/lighttpd: [ -r $PIDFILE ] while pidof lighttpd |\ grep -q `cat $PIDFILE 2/dev/null` 2/dev/null ; do sleep 1; done With this check the logrotate hangs as follows: 21891 ?S 0:00 /USR/SBIN/CRON 21892 ?Ss 0:00 /bin/sh -c test -x /usr/sbin/anacron || run-parts --r 21893 ?S 0:00 run-parts --report /etc/cron.daily 21912 ?Zs 0:00 [logrotate] defunct I don't exactly understand this new check. I think that the number in PIDFILE after restart is again the same as pidof? In the past the sleep 1 was enough on my machines to restart, so probably the new check is always true, even as the PID has changed... I think a better check is first get the old PID and then check this one with pidoff until both are different. Henk van de Kamer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
