Bug#524982: [Pkg-openssl-devel] Bug#524982: Integrate compatibility patches for Cisco VPN client DTLS
On Wednesday, June 17, 2009 at 19:23:54 (+0200), Kurt Roeckx wrote: > I've first want to reorganize the openssl source package a little. > I hate my current workflow to apply patches. I will try to make > an upload with those patches applied soon. Hi Kurt, is there any progress? 0.9.8l is available upstream and contains all patches mentioned in this bugreport, so a "simple" update to upstreams current version will suffice. Regards, Marc -- _ _Marc A. Donges +49 721 6904-2130 'v'Klosterweg 28 / E110 / \ 76131 Karlsruhe W W -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100215130922.ga26...@defiant.hadiko.de
Bug#563699: tomcat6: not listening on IPv4 socket by default
Package: tomcat6 Version: 6.0.20-9 Severity: important In current versions of squeeze, the default value of IPV6_V6ONLY is true: ganymede:~# cat /etc/sysctl.d/bindv6only.conf | egrep -e '^([^#])' net.ipv6.bindv6only = 1 This causes tomcat6 to not accept IPv4 connections by default, as it only binds to an IPv6 socket and apparently doesn't change the IPV6_V6ONLY socket option from its new default value. ganymede:~# uname -a Linux ganymede 2.6.30-2-kirkwood #1 Sun Sep 27 22:57:55 UTC 2009 armv5tel GNU/Linux ganymede:~# nc -v localhost 8080 Connection to localhost 8080 port [tcp/http-alt] succeeded! ganymede:~# nc -v -4 localhost 8080 nc: connect to localhost port 8080 (tcp) failed: Connection refused -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565212: suggests gtodo-applet which is no longer in the archive
Package: gtodo Version: 0.16.0~rc2-1.1 Severity: minor gtodo suggests gtodo-applet, however, that package no longer exists in the archive (for squeeze). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (400, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.31-trunk-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gtodo depends on: ii gconf2 2.28.0-1 GNOME configuration database syste ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libgconf2-4 2.28.0-1 GNOME configuration database syste ii libglib2.0-02.22.3-1 The GLib library of C routines ii libgnomevfs2-0 1:2.24.2-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.18.3-1 The GTK+ graphical user interface ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libx11-62:1.3.2-1X11 client-side library ii libxml2 2.7.6.dfsg-1 GNOME XML library ii libxslt1.1 1.1.26-1 XSLT processing library - runtime gtodo recommends no packages. Versions of packages gtodo suggests: ii gtodo-applet 0.1-5+b1 GTodo applet for the GNOME panel -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#471849: openssh-client: drops connections with "Corrupted MAC on input." errors when loads of data get transferred
On Wednesday, April 30, 2008 at 19:48:37 (+0200), Folkert van Heusden wrote: > Ok, you're right: I swapped the networkcard for another and now all > problems are gone. Funny thing is that both cards were broken. It could be a systematic problem (hardware design bug/kernel bug). What network card did you use? Marc -- _ _ Marc A. Donges +49 721 6904-2130 'v'Klosterweg 28 / E110 / \ 76131 Karlsruhe W W -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683653: keepalived: Add option to inhibit GARP
Package: keepalived Version: 1:1.1.20-1+squeeze1 Severity: wishlist Please add an option, preferably in the context of vrrp_instance, to inhibit any generation of GARP packets upon becoming MASTER of that vrrp_instance. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683653: keepalived: Add option to inhibit GARP (Patch)
Attached patch to implement the functionality.
It is supposed to be applied to version 1.2.2-3.
Kind regards
Marc
diff -r -u keepalived-1.2.2/doc/man/man5/keepalived.conf.5 keepalived-1.2.2.new/doc/man/man5/keepalived.conf.5
--- keepalived-1.2.2/doc/man/man5/keepalived.conf.5 2011-05-29 10:19:59.0 +
+++ keepalived-1.2.2.new/doc/man/man5/keepalived.conf.5 2012-08-09 09:32:29.548371841 +
@@ -172,6 +172,13 @@
# Binding interface for lvs syncd
lvs_sync_daemon_interface eth1
+# keepalived will normally send GARP (gratuitous ARP)
+# packets to the network for every IP address it
+# takes over on transition to the MASTER state.
+# "nogarp" inhibits creation of GARP packets for this
+# VRRP instance.
+nogarp
+
# delay for gratuitous ARP after transition to MASTER
garp_master_delay 10 # secs, default 5
diff -r -u keepalived-1.2.2/keepalived/include/vrrp.h keepalived-1.2.2.new/keepalived/include/vrrp.h
--- keepalived-1.2.2/keepalived/include/vrrp.h 2011-05-29 10:19:59.0 +
+++ keepalived-1.2.2.new/keepalived/include/vrrp.h 2012-08-08 12:21:17.833015722 +
@@ -111,6 +111,9 @@
list vroutes; /* list of virtual routes */
int adver_int; /* delay between advertisements(in sec) */
int nopreempt; /* true if higher prio does not preempt lower */
+ int nogarp; /* true if creation of GARP packets
+ * is not desired
+ */
long preempt_delay; /* Seconds*TIMER_HZ after startup until
* preemption based on higher prio over lower
* prio is allowed. 0 means no delay.
diff -r -u keepalived-1.2.2/keepalived/vrrp/vrrp.c keepalived-1.2.2.new/keepalived/vrrp/vrrp.c
--- keepalived-1.2.2/keepalived/vrrp/vrrp.c 2011-05-29 10:19:59.0 +
+++ keepalived-1.2.2.new/keepalived/vrrp/vrrp.c 2012-08-09 09:32:07.560366984 +
@@ -660,6 +660,10 @@
char *msg;
char addr_str[41];
+ /* do not send GARP if configured not to */
+ if (vrrp->nogarp)
+ return;
+
if (!IP_IS6(ipaddress)) {
msg = "gratuitous ARPs";
inet_ntop(AF_INET, &ipaddress->u.sin.sin_addr, addr_str, 41);
@@ -683,6 +687,10 @@
ip_address *ipaddress;
element e;
+ /* do not send GARP if configured not to */
+ if (vrrp->nogarp)
+ return;
+
/* Only send gratuitous ARP if VIP are set */
if (!VRRP_VIP_ISSET(vrrp))
return;
diff -r -u keepalived-1.2.2/keepalived/vrrp/vrrp_parser.c keepalived-1.2.2.new/keepalived/vrrp/vrrp_parser.c
--- keepalived-1.2.2/keepalived/vrrp/vrrp_parser.c 2011-05-29 10:19:59.0 +
+++ keepalived-1.2.2.new/keepalived/vrrp/vrrp_parser.c 2012-08-08 12:19:30.289013755 +
@@ -289,6 +289,12 @@
vrrp->garp_delay = atoi(VECTOR_SLOT(strvec, 1)) * TIMER_HZ;
}
static void
+vrrp_nogarp_handler(vector strvec)
+{
+ vrrp_rt *vrrp = LIST_TAIL_DATA(vrrp_data->vrrp);
+ vrrp->nogarp = 1;
+}
+static void
vrrp_auth_type_handler(vector strvec)
{
vrrp_rt *vrrp = LIST_TAIL_DATA(vrrp_data->vrrp);
@@ -446,6 +452,7 @@
install_keyword("smtp_alert", &vrrp_smtp_handler);
install_keyword("lvs_sync_daemon_interface", &vrrp_lvs_syncd_handler);
install_keyword("garp_master_delay", &vrrp_garp_delay_handler);
+ install_keyword("nogarp", &vrrp_nogarp_handler);
install_keyword("authentication", NULL);
install_sublevel();
install_keyword("auth_type", &vrrp_auth_type_handler);
Bug#428319: spamassassin: sa-update started from cron.daily is probably a DoS attack
Package: spamassassin Version: 3.2.0-2 Severity: important sa-update being started from cron.daily is probably a DoS attack against Spamassassin update servers. Although it is not the default configuration, many users will activate automatic rule updates via sa-update with the mechanism provided in /etc/cron.daily/spamassassin in the latest Debian package, downloading new rules from Spamassassin update servers (starting from updates.spamassassin.org). cron.daily is executed at 06:25 local time on a standard Debian system, so all installations within the same timezone will hit the update servers at about the 25th minute of an hour, deviating only by the execution time of other scripts in cron.daily. This might not be noticeable during Testing, but it will wreak havoc on those servers once this version of Spamassassin enters a Stable version of Debian. The current behaviour should be changed so that the time of download of updates is spread evenly over at least one full hour for all systems in the same timezone. The time chosen for download could be either random for each execution, or it could be random but fixed per machine (in which case the time would be determined once during package configuration and then saved and reused). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (745, 'testing'), (500, 'stable'), (367, 'unstable'), (234, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20 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 spamassassin depends on: ii libarchive-tar-perl 1.31-1 Archive::Tar - manipulate tar file ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii libhtml-parser-perl 3.56-1 A collection of modules that parse ii libio-zlib-perl 1.04-1 IO:: style interface to Compress:: ii libnet-dns-perl 0.59-1 Perform DNS queries from a Perl sc ii libsocket6-perl 0.19-1 Perl extensions for IPv6 ii libsys-hostname-long-perl 1.4-1 Figure out the long (fully-qualifi ii libwww-perl 5.805-1WWW client/server library for Perl ii perl 5.8.8-7Larry Wall's Practical Extraction Versions of packages spamassassin recommends: ii gnupg 1.4.6-2GNU privacy guard - a free PGP rep pn libmail-spf-query-perl (no description available) pn libsys-syslog-perl (no description available) pn re2c (no description available) ii spamc 3.2.0-2Client for SpamAssassin spam filte -- debconf information: * spamassassin/upgrade/2.40: spamassassin/upgrade/2.40w: * spamassassin/upgrade/cancel: Continue spamassassin/upgrade/2.42m: No * spamassassin/upgrade/2.42u: No -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435315: irssi sends C1 control characters received from the network to the terminal
Package: irssi Version: 0.8.10-2 Severity: important Irssi – at least when configured for output on a UTF-8-terminal – will pass through C1 control characters received from the network unaltered. This at least messes up the display and might even be a security risk. The problem has been fixed upstream in irssi 0.8.11. This problem has been reported as irssi bug #460: http://bugs.irssi.org/?do=details&task_id=460 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (745, 'testing'), (500, 'stable'), (367, 'unstable'), (234, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20 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 irssi depends on: ii libc6 2.6-2 GNU C Library: Shared libraries ii libglib2.0-0 2.12.12-1+b1 The GLib library of C routines ii libncurses5 5.6+20070716-1 Shared libraries for terminal hand ii libperl5.85.8.8-7Shared Perl library ii libssl0.9.8 0.9.8e-5 SSL shared libraries ii perl 5.8.8-7Larry Wall's Practical Extraction ii perl-base [perlapi-5.8.8] 5.8.8-7The Pathologically Eclectic Rubbis irssi recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426040: tangerine-icon-theme: Contains Ubuntu logo instead of Debian logo
Package: tangerine-icon-theme Version: 0.20-1 Severity: normal tangerine-icon-theme contains the Ubuntu logo in several places where the Debian logo should be, notably: /usr/share/icons/Tangerine/24x24/places/start-here.png /usr/share/icons/Tangerine/32x32/places/start-here.png The correct logo is already in the package for other resolutions: /usr/share/icons/Tangerine/16x16/places/start-here.png /usr/share/icons/Tangerine/22x22/places/start-here.png /usr/share/icons/Tangerine/48x48/places/start-here.png /usr/share/icons/Tangerine/scalable/places/start-here.svg -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (745, 'testing'), (500, 'stable'), (367, 'unstable'), (234, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20 Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tangerine-icon-theme depends on: ii gnome-icon-theme 2.18.0-3GNOME Desktop icon theme ii tango-icon-theme 0.7.2+cvs07.02.06-1 Tango Icon theme tangerine-icon-theme recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437127: xen-utils-common: vif-common fails to identify ip address of ethernet device
ip -4 -o addr show primary dev eth0 | awk '$3 == "inet"
{match($4,"([0-9.]*)",i); print i[1]; exit}'
HTH, Marc
--
_ _Marc A. Donges +49 721 6904-2130
'v'Klosterweg 28 / E110
/ \ 76131 Karlsruhe
W W http://www.hadiko.de/~marc/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437127: xen-utils-common: vif-common fails to identify ip address of ethernet device
I must apologize, those semantics of match() are a peculiarity of
GNU awk. The following should work portably, I tested it with an old mawk:
ip -4 -o addr show primary dev eth0 | awk '$3 == "inet" {split($4,i,"/"); print
i[1]; exit}'
Marc
--
_ _Marc A. Donges +49 721 6904-2130
'v'Klosterweg 28 / E110
/ \ 76131 Karlsruhe
W W http://www.hadiko.de/~marc/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#48323: gpg can't sign a gpg key with a pgp key.
I can successfully sign key 8BD4A489 with an RSA-sign-key using the current version of GnuPG in Lenny, version 1.4.9-2. Marc -- _ _Marc A. Donges +49 721 6904-2130 'v'Klosterweg 28 / E110 / \ 76131 Karlsruhe W W http://www.hadiko.de/~marc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494194: gnupg: Choice of algorithms for --symmetric is obscure
Package: gnupg Version: 1.4.9-2 Severity: normal Hi! The choice of algorithms used for conventional encryption of messages (--symmetric) is quite obscure. The user must provide a passphrase which is hashed, the result of which is used as an encryption key. Now, the hash is selected by "s2k-digest-algo", not "digest-algo", while the symmetric cipher is selected by "cipher-algo" (or the first cipher in "personal-cipher-preferences"), not "s2k-cipher-algo". This is surprising, as in the case of existing personal-cipher-preferences (in a configuration file), in order to explicitly set the cipher and digest, one has to use --cipher-algo and --s2k-digest-algo. There should be explicit options for the choice of cipher and digest algorithm used for --symmetric encryption. That way, one could set sane defaults in a configuration file. Marc -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (745, 'testing'), (367, 'unstable'), (234, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26 Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg depends on: ii gpgv 1.4.9-2 GNU privacy guard - signature veri ii libbz2-1.0 1.0.5-0.1 high-quality block-sorting file co ii libc6 2.7-10GNU C Library: Shared libraries ii libreadline5 5.2-3 GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-12 userspace USB programming library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages gnupg recommends: ii libldap-2.4-22.4.10-2+lenny1 OpenLDAP libraries Versions of packages gnupg suggests: ii eog 2.22.3-1 Eye of GNOME graphics viewer progr pn gnupg-doc (no description available) ii imagemagick 7:6.3.7.9.dfsg1-2+b2 image manipulation programs pn libpcsclite1 (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487617: Apache configuration file for phpldapadmin assumes use of obsolete PHP4
Package: phpldapadmin Version: 1.1.0.5-2 Severity: normal Tags: patch The Apache configuration file for phpldapadmin sets options required in case PHP is used as a CGI handler instead of as an Apache module. Those options are incorrectly depending on the non-use of mod_php4, while they should depend on th non-use of mod_php5 (PHP4 is obsolete and phpldapadmin already depends on and uses PHP5). Also, they set /cgi-bin/php4 as CGI handler, while this should be /cgi-bin/php5. Additionally, those options depend on the availability of mod_cgi. In threaded implementations of Apache, mod_cgid is preferred over mod_cgi and the relevant configuration options should also be set if mod_cgid is used. A trivial patch correcting apache.conf is attached to this bug report. Marc A. Donges -- System Information: (Report submitted from different machine, see manual list of relevant packages below.) Distribution: Lenny, spiced with Sid apache2-mpm-event 2.2.8-4Event driven model for Apache HTTPD php5-cgi5.2.5-3+lenny1 server-side, HTML-embedded scripting language (CGI binary) -- _ _Marc A. Donges +49 721 6904-2130 'v'Klosterweg 28 / E110 / \ 76131 Karlsruhe W W http://www.hadiko.de/~marc/ --- apache.conf.dpkg-dist 2008-06-03 09:59:51.0 +0200 +++ apache.conf 2008-06-23 06:30:53.0 +0200 @@ -32,12 +32,17 @@ php_value include_path . - + AddType application/x-httpd-php .php -Action application/x-httpd-php /cgi-bin/php4 +Action application/x-httpd-php /cgi-bin/php5 + + +AddType application/x-httpd-php .php + +Action application/x-httpd-php /cgi-bin/php5
Bug#792665: python-yubico-tools: yubikey-totp output depends on local time (timezone)
Package: python-yubico-tools Version: 1.1.0-2 Severity: normal Dear Maintainer, when using TOTP (time based), the PIN output by yubikey-totp depends on the timezone the tool is running in: kosh@cindy:~$ echo $TZ; yubikey-totp; TZ=UTC yubikey-totp; yubikey-totp Europe/Berlin 050816 934513 050816 (the first and last should be the same as the one in the middle) I think this is in violation of RFC6238. I suspect the cause can be seen in the output of --help, as the tool clearly doesn't calculate "seconds since the epoch" correctly: kosh@cindy:~$ echo $TZ; yubikey-totp --help; TZ=UTC yubikey-totp --help; yubikey-totp --help; date +%s Europe/Berlin usage: yubikey-totp [-h] [-v] [--debug] [--time TIME] [--step STEP] [--digits DIGITS] [--slot SLOT] Generate OATH TOTP codes using a YubiKey optional arguments: -h, --help show this help message and exit -v, --verboseEnable verbose operation (default: False) --debug Enable debug operation (default: False) --time TIME Time to use as number of seconds since epoch (default: 1437119455) --step STEP Time step in use (in seconds) (default: 30) --digits DIGITS Length of OTP in decimal digits (default: 6) --slot SLOT YubiKey slot configured for Challenge-Response (default: 2) usage: yubikey-totp [-h] [-v] [--debug] [--time TIME] [--step STEP] [--digits DIGITS] [--slot SLOT] Generate OATH TOTP codes using a YubiKey optional arguments: -h, --help show this help message and exit -v, --verboseEnable verbose operation (default: False) --debug Enable debug operation (default: False) --time TIME Time to use as number of seconds since epoch (default: 1437123055) --step STEP Time step in use (in seconds) (default: 30) --digits DIGITS Length of OTP in decimal digits (default: 6) --slot SLOT YubiKey slot configured for Challenge-Response (default: 2) usage: yubikey-totp [-h] [-v] [--debug] [--time TIME] [--step STEP] [--digits DIGITS] [--slot SLOT] Generate OATH TOTP codes using a YubiKey optional arguments: -h, --help show this help message and exit -v, --verboseEnable verbose operation (default: False) --debug Enable debug operation (default: False) --time TIME Time to use as number of seconds since epoch (default: 1437119455) --step STEP Time step in use (in seconds) (default: 30) --digits DIGITS Length of OTP in decimal digits (default: 6) --slot SLOT YubiKey slot configured for Challenge-Response (default: 2) 1437123055 The "default" for "number of seconds since epoch" in the description of the --time parameter clearly changes with TZ, which is wrong. Compare the output of "date +%s" which returns the same value "TZ=UTC yubikey-totp --help" returns. The fix is rather trivial: --- yubikey-totp.old2012-06-08 14:21:39.0 +0200 +++ yubikey-totp2015-07-17 11:06:39.265867405 +0200 @@ -41,7 +41,7 @@ import argparse default_slot=2 -default_time=int(time.mktime(time.gmtime())) +default_time=int(time.time()) default_step=30 default_digits=6 Cheers, Marc -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable'), (255, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-yubico-tools depends on: ii libpython2.7-stdlib [python-argparse] 2.7.9-2 ii python 2.7.9-1 ii python-yubico 1.1.0-2 python-yubico-tools recommends no packages. python-yubico-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732149: munin outputs malformed XHTML
Package: munin Version: 2.1.2-1 Severity: normal Dear Maintainer, munin’s XHTML output is malformed XML in several places. This causes at least chromium to not render the output. Please consider fixing the errors, or preferably consider not producing XHTML output. There is no point in producing XHTML if you are not planning to use an XML parser for further processing, and you can’t do that if the XHTML is broken. Merely using it as a style, as is the case in munin, is pointless. There are at least two problems: * In the view of a single host, the headings of each plugin start with a a line: "Apache accesses" is never closed, which is not well-formed. * In the view of a single plugin for a single host, the URIs in the links to the zoomable graphs contain ampersand characters. As ampersand characters have special meaning in XML, those in the URIs need to be represented with character entity references in XML (&). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (745, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin depends on: ii adduser 3.113+nmu3 ii cron 3.0pl1-124 ii libdate-manip-perl 6.41-1 pn libdigest-md5-perl ii libfile-copy-recursive-perl 0.38-1 ii libhtml-template-perl2.95-1 ii libio-socket-inet6-perl 2.71-1 ii liblog-log4perl-perl 1.41-1.1 ii librrds-perl 1.4.7-2+b1 pn libstorable-perl ii liburi-perl 1.60-1 ii munin-common 2.1.2-1 ii perl [libtime-hires-perl]5.18.1-5 ii perl-modules 5.18.1-5 ii rrdtool 1.4.7-2+b1 ii ttf-dejavu 2.33+svn2514-3 Versions of packages munin recommends: pn munin-doc ii munin-node 2.1.2-1 Versions of packages munin suggests: ii apache2-bin [httpd] 2.4.6-3 ii elinks [www-browser]0.12~pre6-4 pn libapache2-mod-fcgid ii libnet-ssleay-perl 1.55-1+b2 ii lynx-cur [www-browser] 2.8.8pre1-1 ii w3m [www-browser] 0.5.3-12 -- Configuration Files: /etc/munin/apache.conf changed [not included] /etc/munin/munin.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732228: rsync: fails to remove files with --remove-source when used with --copy-links
Package: rsync Version: 3.1.0-2 Severity: normal Dear Maintainer, rsync fails to remove source files with --remove-source when those are symlinks whose referents are transferred with the --copy-links (-L) option. rsync returns the error: ERROR: Skipping sender remove for changed file: […] Steps to reproduce: 1. Create a set of files, some of which are symlinks with valid referents. marc@defiant:~$ cd $(mktemp -d) marc@defiant:/tmp/tmp.L4VQqyIk11$ mkdir -p orig/src dst marc@defiant:/tmp/tmp.L4VQqyIk11$ date > orig/src/A marc@defiant:/tmp/tmp.L4VQqyIk11$ date > orig/B marc@defiant:/tmp/tmp.L4VQqyIk11$ ln -s /tmp/tmp.L4VQqyIk11/orig/B orig/src/ marc@defiant:/tmp/tmp.L4VQqyIk11$ ls -l orig/src/ total 4 -rw-rw-r-- 1 marc marc 29 Dec 15 21:17 A lrwxrwxrwx 1 marc marc 26 Dec 15 21:17 B -> /tmp/tmp.L4VQqyIk11/orig/B marc@defiant:/tmp/tmp.L4VQqyIk11$ ls -lL orig/src/ total 8 -rw-rw-r-- 1 marc marc 29 Dec 15 21:17 A -rw-rw-r-- 1 marc marc 29 Dec 15 21:17 B 2. Copy those files with rsync, using the option --remove-source to remove the successfully transferred source files and --copy-links (-L) to copy the symlink referent instead of the symlink. marc@defiant:/tmp/tmp.L4VQqyIk11$ rsync -aL --remove-source-files orig/src/ dst/ ERROR: Skipping sender remove for changed file: B Actual result: rsync throws an error and does not remove the source if it is a symlink. Expected result: rsync should delete the symlink. The mtime of the destination file matches the mtime of the source file (the symlink referent). It does not match the mtime of the symlink. I think the rsync error message hints at the symlink mtime. Symlink mtimes are irrelevant and should probably not be used here. marc@defiant:/tmp/tmp.L4VQqyIk11$ stat orig/src/B File: ‘orig/src/B’ -> ‘/tmp/tmp.L4VQqyIk11/orig/B’ Size: 26 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 394555 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 1000/marc) Gid: ( 1000/marc) Access: 2013-12-15 21:17:17.364125558 +0100 Modify: 2013-12-15 21:17:17.364125558 +0100 Change: 2013-12-15 21:17:17.364125558 +0100 Birth: - marc@defiant:/tmp/tmp.L4VQqyIk11$ stat -L orig/src/B File: ‘orig/src/B’ Size: 29 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 393240 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/marc) Gid: ( 1000/marc) Access: 2013-12-15 21:17:04.420631451 +0100 Modify: 2013-12-15 21:17:04.424631295 +0100 Change: 2013-12-15 21:17:04.424631295 +0100 Birth: - marc@defiant:/tmp/tmp.L4VQqyIk11$ stat dst/B File: ‘dst/B’ Size: 29 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 394557 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/marc) Gid: ( 1000/marc) Access: 2013-12-15 21:18:03.110337502 +0100 Modify: 2013-12-15 21:17:04.424631295 +0100 Change: 2013-12-15 21:18:03.110337502 +0100 Birth: - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (745, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rsync depends on: ii base-files 7.2 ii libacl1 2.2.52-1 ii libc6 2.17-97 ii libpopt01.16-8 ii lsb-base4.1+Debian12 ii zlib1g 1:1.2.8.dfsg-1 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:6.4p1-1 ii openssh-server 1:6.4p1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754294: Regression: While routing Kernel chokes on spurious "too big" IP packets
Package: linux
Version: 3.2.60-1+deb7u1
Severity: important
Dear Maintainer,
the Kernel upgrade via Debian Security on Friday 2014-07-04 made routing
service (in this case with NAT) somewhat broken.
*High level description*
This is experienced by users as "very slow network access" to some servers, and
only by some client computers.
*Setup*
A gateway using Linux for routing and NAT running Debian stable (amd64) was
updated from linux-image-3.2.0-4-amd64:amd64 version 3.2.57-3+deb7u2 to version
3.2.60-1+deb7u1
The gateway is supposed to route and NAT traffic from a private network to the
public internet, translating RFC1918 client source addresses to public
addresses.
In the following tcpdumps I have replaced the RFC1918 address of a client with
"CLIENT", the public IP address of the relevant gateway with "NAT" and the
public IP address of a server in the Internet with "SERVER" for reasons of
privacy, as they were gathered in a LIVE environment.
*Problem description*
After the update the Kernel chokes on apparently "too big" IP packets that
don't fit the MTU:
17:11:00.917355 IP SERVER.80 > NAT.44991: Flags [.], seq 1:2921, ack 98, win
5840, length 2920
17:11:00.917384 IP NAT > SERVER: ICMP NAT unreachable - need to frag (mtu
1500), length 556
Note the large IP packet (2960 > MTU of 1500). It has the DF bit set. The
packet cannot have arrived via the network, though, as it is an Ethernet with
an MTU of 1500, so this is odd. *1
*Workaround*
The problem disappears when GRO is deactivated:
ethtool -K eth0 gro off
The kernel then receives only valid packets of up to MTU in size:
17:14:53.288712 IP SERVER.80 > NAT.44996: Flags [.], seq 1:1461, ack 98, win
5840, length 1460
17:14:53.288730 IP SERVER.80 > CLIENT.44996: Flags [.], seq 1:1461, ack 98, win
5840, length 1460
17:14:53.288735 IP SERVER.80 > NAT.44996: Flags [.], seq 1461:2921, ack 98, win
5840, length 1460
17:14:53.27 IP SERVER.80 > CLIENT.44996: Flags [.], seq 1461:2921, ack 98,
win 5840, length 1460
GRO is a performance optimization where the NIC assembles packets into larger
packets for smaller processing/interrupt overhead. GRO defaults to on (on this
hardware).
*Regression*
The problem did not exist in 3.2.57-3+deb7u2. In that version the Kernel
forwards those big packets as many smaller packets of up to MTU size:
16:23:01.394351 IP SERVER.80 > NAT.44943: Flags [.], seq 1:2921, ack 98, win
5840, length 2920
16:23:01.394375 IP SERVER.80 > CLIENT.44943: Flags [.], seq 1:1461, ack 98, win
5840, length 1460
16:23:01.394525 IP SERVER.80 > CLIENT.44943: Flags [.], seq 1461:2921, ack 98,
win 5840, length 1460
Note this is not IP fragmentation, as the smaller packets contain one TCP
segment each.
*Possible causes*
I suspect the reason for how the error manifests to end users ("very slow
network access" to some servers, and only by some client computers) is that the
actual operation of GRO is influenced by the NIC/driver, timing of packet flow,
and IP/TCP options used (which depend on client OS and configuration and server
OS and configuration). Then, the server's retransmit behaviour may cause single
packets to be transmitted, which are then not mangled by GRO and can be
successfully forwarded to clients, although that is very slow.
There are two changes between 3.2.57-3+deb7u2 and 3.2.60-1+deb7u1 that look
related, because they were supposed to fix a similar issue with IP packets that
arrive fragmented but have the DF bit set:
In the Debian specific patch set
patches/bugfix/all/netfilter-ipv4-defrag-set-local_df-flag-on-defragmen.patch:
[quote]
From: Florian Westphal
Date: Fri, 2 May 2014 15:32:16 +0200
Subject: netfilter: ipv4: defrag: set local_df flag on defragmented skb
Origin: https://git.kernel.org/linus/895162b1101b3ea5db08ca6822ae9672717efec0
else we may fail to forward skb even if original fragments do fit
outgoing link mtu:
1. remote sends 2k packets in two 1000 byte frags, DF set
2. we want to forward but only see '2k > mtu and DF set'
3. we then send icmp error saying that outgoing link is 1500
But original sender never sent a packet that would not fit
the outgoing link.
Setting local_df makes outgoing path test size vs.
IPCB(skb)->frag_max_size, so we will still send the correct
error in case the largest original size did not fit
outgoing link mtu.
Reported-by: Maxime Bizon
Suggested-by: Maxime Bizon
Fixes: 5f2d04f1f9 (ipv4: fix path MTU discovery with connection tracking)
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
---
net/ipv4/netfilter/nf_defrag_ipv4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/nf_defrag_ipv4.c
b/net/ipv4/netfilter/nf_defrag_ipv4.c
index 12e13bd..f40f321 100644
--- a/net/ipv4/netfilter/nf_defrag_ipv4.c
+++ b/net/ipv4/netfilter/nf_defrag_ipv4.c
@@ -22,7 +22,6 @@
#endif
#include
-/* Returns new sk_buff, or NULL */
static int nf_ct_ipv4_gather_frags(struct sk_buff *skb, u_int32_t us
Bug#754294: Regression: While routing Kernel chokes on spurious "too big" IP packets
The problem has been reported on hardware with two similar Broadcom Ethernet chipsets using the same bnx2 kernel driver: NIC 1: 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) Subsystem: Hewlett-Packard Company NC382i Integrated Multi-port PCI Express Gigabit Server Adapter Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at f400 (64-bit, non-prefetchable) [size=32M] [virtual] Expansion ROM at e710 [disabled] [size=64K] Capabilities: [48] Power Management version 3 Capabilities: [50] Vital Product Data Capabilities: [58] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [a0] MSI-X: Enable+ Count=9 Masked- Capabilities: [ac] Express Endpoint, MSI 00 Capabilities: [100] Device Serial Number [removed] Capabilities: [110] Advanced Error Reporting Capabilities: [150] Power Budgeting Capabilities: [160] Virtual Channel Kernel driver in use: bnx2 With the following default features: Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-unneeded: off [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: on tx-tcp6-segmentation: on udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: on loopback: off [fixed] 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) Subsystem: Dell Device 01b3 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 47 Memory at f800 (64-bit, non-prefetchable) [size=32M] Capabilities: [40] PCI-X non-bridge device Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: bnx2 With the following default features: Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-unneeded: off [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: on tx-tcp6-segmentation: off [fixed] udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: on loopback: off [fixed] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753506: munin-plugins-core: Plugin http_loadtime uses incorrect shell escaping
Package: munin-plugins-core
Version: 2.0.21-2
Severity: normal
Dear Maintainer,
the munin plugin http_loadtime uses incorrect shell escaping of parameters.
I noticed odd requests in my BIND log:
error (unexpected RCODE SERVFAIL) resolving
'http_loadtime\".$searchlist//IN': ...
(where I replaced my default domain with $searchlist and the DNS server address
with ...)
I traced those requests to the munin plugin http_loadtime, which sets an
environment variable for wget options like this:
wget_opt="--user-agent \"Munin - http_loadtime\" --no-cache -q --delete-after"
and expands them in this expression:
loadtime=$(cd $TEMPO_DIR && $time_bin --quiet -f "%e" wget $wget_opt $target
2>&1)
Apparently that doesn't work, as the double quote ends up in the arguments of
wget.
For comparison, equivalent commands in an interactive shell show what happens:
kosh@cindy:/tmp$ export target=${target:-"http://localhost/"}
kosh@cindy:/tmp$ export wget_opt="--user-agent \"Munin - http_loadtime\"
--no-cache --delete-after"
kosh@cindy:/tmp$ wget $wget_opt $target
--2014-07-02 17:05:12-- http://-/
Resolving - (-)... failed: Name or service not known.
wget: unable to resolve host address ‘-’
--2014-07-02 17:05:12-- http://http_loadtime%22/
Resolving http_loadtime" (http_loadtime")... failed: Name or service not known.
wget: unable to resolve host address ‘http_loadtime"’
--2014-07-02 17:05:12-- http://localhost/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 550 [text/html]
Saving to: ‘index.html’
100%[=>]
550 --.-K/s in 0s
2014-07-02 17:05:12 (140 MB/s) - ‘index.html’ saved [550/550]
Removing index.html.
FINISHED --2014-07-02 17:05:12--
Total wall clock time: 0.1s
Downloaded: 1 files, 550 in 0s (140 MB/s)
Cheers,
Marc
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (745, 'testing'), (255, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.21-2
ii perl 5.18.2-4
Versions of packages munin-plugins-core recommends:
pn libnet-snmp-perl
Versions of packages munin-plugins-core suggests:
ii conntrack 1:1.4.1-1
pn libnet-netmask-perl
pn libnet-telnet-perl
ii libxml-parser-perl2.41-1+b2
ii python2.7.6-2
ii ruby 1:2.1.0.1
ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2
ii ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii ruby2.1 [ruby-interpreter]2.1.2-2
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768941: libaudio2: File conflict breaks multi-arch installation
Package: libaudio2 Version: 1.9.4-1+b1 Severity: important Dear Maintainer, in Debian testing, libaudio2 is currently broken due to a file difference in /usr/share/doc/libaudio2/changelog.Debian.gz between i384 and amd64: root@cindy:~# dpkg -i /var/cache/apt/archives/libaudio2_1.9.4-1+b1_* Selecting previously unselected package libaudio2:amd64. (Reading database ... 228670 files and directories currently installed.) Preparing to unpack .../libaudio2_1.9.4-1+b1_amd64.deb ... Unpacking libaudio2:amd64 (1.9.4-1+b1) ... Selecting previously unselected package libaudio2:i386. Preparing to unpack .../libaudio2_1.9.4-1+b1_i386.deb ... Unpacking libaudio2:i386 (1.9.4-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/libaudio2_1.9.4-1+b1_i386.deb (--install): trying to overwrite shared '/usr/share/doc/libaudio2/changelog.Debian.gz', which is different from other instances of package libaudio2:i386 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Setting up libaudio2:amd64 (1.9.4-1+b1) ... Processing triggers for libc-bin (2.19-12) ... Errors were encountered while processing: /var/cache/apt/archives/libaudio2_1.9.4-1+b1_i386.deb I expected this to work, as it did in the previous version of the package, 1.9.4-1. Cheers, Marc -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (745, 'testing'), (255, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
