Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a not found answer is returned. um, i think i know what a plain name, without dots or domain parts is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name \x03com\x00 (presentation format: com.) because it has only a single label? that is beyond broken. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a not found answer is returned. um, i think i know what a plain name, without dots or domain parts is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name \x03com\x00 (presentation format: com.) because it has only a single label? that is beyond broken. ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: Some implementations of gethostbyname, given the name com or mycomputer will attempt to look it up in the DNS with just such a query, thus wasting upstream bandwidth and leaking internal network information. hm, so? a heuristic based solely on the number of labels in the qname is a rather blunt tool here. far better to fix the misconfigured client than to guess at what the stub resolver might have meant. It's sometimes useful to pre-empt that, so there's a configuration option. It's not the default behaviour. NXDOMAIN is wrong here, NODATA would be better, but historically dnsmasq was fielding queries from stub resolvers, so nobody every noticed the difference. i disagree. the existence of an option that pre-empts queries for one-label qnames (and the comment at the top of the example config file encouraging one to turn it on) harms interoperability. i'd recommend deprecating and removing the domain-needed option altogether but if you're not going to do that i'd at least make the filtering logic conditional. from looking at the source it appears qtype=NS is exempted from the filter, maybe you could invert the logic and make it apply only to qtype=A and perhaps qtype=. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582864: uWSGI ITP: version 0.9.8-1 is available for review
Leonid Borisenko wrote: I've finally completed with all planned changes to uWSGI package and, at the same time, update it to current upstream version (v0.9.8). Would you like to review and sponsor package? thanks, i'll look at this shortly. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#582864: uWSGI ITP: version 0.9.8-1 is available for review
/i386/server N: N: Processing binary package uwsgi-plugin-greenlet-python (version 0.9.8-1) ... N: N: Processing binary package uwsgi-plugin-erlang (version 0.9.8-1) ... N: N: Processing binary package uwsgi-plugin-echo (version 0.9.8-1) ... N: N: Processing binary package uwsgi-plugins-all (version 0.9.8-1) ... N: N: Processing binary package uwsgi-dbg (version 0.9.8-1) ... N: Removing /tmp/PbCZzxDIC3 ... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629260: [WANTED] ns_initparse(3), ns_msg_count(3), etc (please document resolver library routines)
Jonathan Nieder wrote: Package: manpages-dev Version: 3.27-1 Severity: wishlist Tags: upstream Martin Ferrari wrote[1]: I'm using functions defined in arpa/nameser.h, undocumented in libc, but explained in chapter 12 of O'Reilly's DNS BIND (ISBN: 0-596-00158-4). I do think that this lack of documentation is also a bug. He's right --- these functions are useful and a longstanding API, and it is not very rare to find programs that use them. They became part of the libresolv ABI in glibc 2.9, which provides us with a convenient list[2]: ns_msg_getflag ns_get16, ns_get32, ns_put16, ns_put32 ns_initparse, ns_skiprr, ns_parserr ns_sprintrr, ns_sprintrrf ns_format_ttl, ns_parse_ttl ns_datetosecs ns_name_ntol, ns_name_ntop, ns_name_pton ns_name_unpack, ns_name_pack ns_name_uncompress, ns_name_compress ns_name_skip, ns_name_rollback ns_samedomain, ns_subdomain, ns_makecanon, ns_samename the only documentation i know of for some of these functions is in the DNS BIND book starting around p. 447 (5th edition). it would probably be best if documentation for these functions were not readily available in order to discourage their use in new projects, as there are much better modern DNS message parsing libraries available. The code comes from Bind 8.2.2-P5 originally. The BIND documentation says[3]: [3] http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch09.html#id2609111 the BIND9 9.8 documentation is totally irrelevant in this case, as BIND9 9.8 lacks the BIND4/BIND8 resolver library. the relevant ISC product would be libbind, but i don't believe those functions are documented in libbind either. (side note: i will probably request the removal of the libbind package from debian before the next stable release, now that glibc's libresolv has finally been fixed.) -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627342: libpcap: crash in bpf interpreter with ip6 protochain filter
Package: libpcap0.8
Version: 1.1.1-5
Severity: important
it's possible to crash libpcap in the bpf interpreter with an ip6
protochain filter. a test packet is attached; it is an ICMPv6 message
with an IPv6 hop-by-hop extension header. i was not able to reproduce
this with the latest version of libpcap from upstream git.
edmonds@chase{0}:~/packets$ tcpdump -nr ip6-hopbyhop-icmp.pcap
reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet)
18:43:07.098489 IP6 fe80::208:7dff:feb7:2cca ff02::1: HBH ICMP6,
multicast listener queryv2 [gaddr ::], length 28
edmonds@chase{0}:~/packets$ tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6
protochain 1'
reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet)
zsh: segmentation fault tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain
1'
edmonds@chase{139}:~/packets$ valgrind tcpdump -nr ip6-hopbyhop-icmp.pcap
'ip6 protochain 1'
==24937== Memcheck, a memory error detector
==24937== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==24937== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==24937== Command: tcpdump -nr ip6-hopbyhop-icmp.pcap ip6\ protochain\ 1
==24937==
reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet)
==24937== Invalid read of size 2
==24937==at 0x5212EB8: bpf_filter (bpf_filter.c:242)
==24937==by 0x520D268: pcap_offline_read (savefile.c:379)
==24937==by 0x51FF60E: pcap_loop (pcap.c:423)
==24937==by 0x187644: main (in /usr/sbin/tcpdump)
==24937== Address 0x805bcc7d0 is not stack'd, malloc'd or (recently) free'd
==24937==
==24937==
==24937== Process terminating with default action of signal 11 (SIGSEGV)
==24937== Access not within mapped region at address 0x805BCC7D0
==24937==at 0x5212EB8: bpf_filter (bpf_filter.c:242)
==24937==by 0x520D268: pcap_offline_read (savefile.c:379)
==24937==by 0x51FF60E: pcap_loop (pcap.c:423)
==24937==by 0x187644: main (in /usr/sbin/tcpdump)
==24937== If you believe this happened as a result of a stack
==24937== overflow in your program's main thread (unlikely but
==24937== possible), you can try to increase the size of the
==24937== main thread stack using the --main-stacksize= flag.
==24937== The main thread stack size used in this run was 8388608.
==24937==
==24937== HEAP SUMMARY:
==24937== in use at exit: 3,473 bytes in 7 blocks
==24937== total heap usage: 23 allocs, 16 frees, 12,949 bytes allocated
==24937==
==24937== LEAK SUMMARY:
==24937==definitely lost: 0 bytes in 0 blocks
==24937==indirectly lost: 0 bytes in 0 blocks
==24937== possibly lost: 0 bytes in 0 blocks
==24937==still reachable: 3,473 bytes in 7 blocks
==24937== suppressed: 0 bytes in 0 blocks
==24937== Rerun with --leak-check=full to see details of leaked memory
==24937==
==24937== For counts of detected and suppressed errors, rerun with: -v
==24937== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
zsh: segmentation fault valgrind tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6
protochain 1'
edmonds@chase{139}:~/packets$
--
Robert Edmonds
edmo...@debian.org
ip6-hopbyhop-icmp.pcap
Description: application/cap
signature.asc
Description: Digital signature
Bug#627342: Acknowledgement (libpcap: crash in bpf interpreter with ip6 protochain filter)
see also: http://sourceforge.net/tracker/?func=detailaid=3082386group_id=53067atid=469577 http://permalink.gmane.org/gmane.network.tcpdump.devel/4703 the upstream fix is commit ecdc5c0a7f7591a7cd4aff696e42757c677fbbf7, attached. it applies cleanly to 1.1.1 and appears to fix the issue. -- Robert Edmonds edmo...@debian.org From ecdc5c0a7f7591a7cd4aff696e42757c677fbbf7 Mon Sep 17 00:00:00 2001 From: Guy Harris g...@alum.mit.edu Date: Wed, 4 May 2011 22:28:53 -0700 Subject: [PATCH] In userland, sign extend the offset for JA instructions. We currently use that to implement ip6 protochain, and pc might be wider than pc-k, in which case we need to arrange that pc-k be sign-extended, by casting it to bpf_int32. --- bpf/net/bpf_filter.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/bpf/net/bpf_filter.c b/bpf/net/bpf_filter.c index 22aff79..0c4fb00 100644 --- a/bpf/net/bpf_filter.c +++ b/bpf/net/bpf_filter.c @@ -405,7 +405,18 @@ bpf_filter(pc, p, wirelen, buflen) continue; case BPF_JMP|BPF_JA: +#if defined(KERNEL) || defined(_KERNEL) + /* + * No backward jumps allowed. + */ pc += pc-k; +#else + /* + * XXX - we currently implement ip6 protochain + * with backward jumps, so sign-extend pc-k. + */ + pc += (bpf_int32)pc-k; +#endif continue; case BPF_JMP|BPF_JGT|BPF_K: -- 1.7.5.1 signature.asc Description: Digital signature
Bug#623868: snapshot length corruption on live captures
Romain Francoise wrote: Robert Edmonds edmo...@debian.org writes: for instance, a snapshot length of 1514 actually results in only a maximum of 1498 bytes being captured, so those who think they are doing full packet capture actually are not, thus breaking TCP stream reassembly and IP defragmentation, potentially blinding sensors that depend on libpcap. Sure it's possible, but quite unlikely. People who want to do full packet capture usually set snaplen to 65535, which is the default for tcpdump, ngrep, tcpflow, etc. no, we don't. setting the snaplen to ~64K means the MMAP'd packet capture ring needs to allocate ~64K of unswappable kernel memory for each frame in the ring buffer. the default ring buffer size used in libpcap is 2 megabytes, which means only a tiny number of frames can be buffered with a 64K snaplen. generally 2 MB is a quite small buffer to use on a busy network even with a correctly tuned snapshot length, so one needs to increase the ring buffer size as well. snort sets the default snapshot length to 1514, so it is quite broken by this bug. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623868: snapshot length corruption on live captures
Romain Francoise wrote: Robert Edmonds edmo...@debian.org writes: attached is a backport of this commit to 1.1.1, and a patch to the debian package containing the fix. Thanks, I'll merge this for the next upload. However, I don't think this issue is really grave. It doesn't cause data loss, it just results in less data than requested being captured. true, it doesn't result in loss of _existing_ data, but i think this bug is certainly serious enough to warrant a stable or security update. for instance, a snapshot length of 1514 actually results in only a maximum of 1498 bytes being captured, so those who think they are doing full packet capture actually are not, thus breaking TCP stream reassembly and IP defragmentation, potentially blinding sensors that depend on libpcap. in fact, we could go all the way up to critical :) makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#623868: snapshot length corruption on live captures
Package: libpcap0.8
Version: 1.1.1-2
Severity: grave
Tags: squeeze sid
Justification: causes data loss
see: http://thread.gmane.org/gmane.network.tcpdump.devel/5018
this can be trivially reproduced on squeeze or sid:
edmonds@zappa{0}:~$ tcpdump --version
tcpdump version 4.1.1
libpcap version 1.1.1
Usage: tcpdump [-aAbdDefIKlLnNOpqRStuUvxX] [ -B size ] [ -c count ]
[ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ]
[ -i interface ] [ -M secret ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ]
[ -y datalinktype ] [ -z command ] [ -Z user ]
[ expression ]
edmonds@zappa{1}:~$ sudo tcpdump -s 128 -c 2 -pni lo -w /tmp/lo.pcap
1/dev/null 21
[1] 22573
edmonds@zappa{1}:~$ ping -c 1 -s 512 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 512(540) bytes of data.
520 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.034 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.034/0.034/0.034/0.000 ms
edmonds@zappa{0}:~$
[1] + done sudo tcpdump -s 128 -c 2 -pni lo -w /tmp/lo.pcap
/dev/null 21
edmonds@zappa{0}:~$ tshark -r /tmp/lo.pcap -V -T text -n | grep '^Frame '
Frame 1 (554 bytes on wire, 122 bytes captured)
Frame 2 (554 bytes on wire, 122 bytes captured)
edmonds@zappa{0}:~$
with the latest git tip of libpcap:
sql1rd2:~# tcpdump --version
tcpdump version 4.3.0-PRE-GIT_2011_04_23
libpcap version 1.3.0-PRE-GIT_2011_04_23
Usage: tcpdump [-aAbdDefhIJKlLnNOpqRStuUvxX] [ -B size ] [ -c count ]
[ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ]
[ -i interface ] [ -j tstamptype ] [ -M secret ]
[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ] [ -y datalinktype ] [ -z command ]
[ -Z user ] [ expression ]
sql1rd2:~# tcpdump -s 128 -c 2 -pni lo -w /tmp/lo.pcap
[1] 15377
sql1rd2:~# tcpdump: listening on lo, link-type EN10MB (Ethernet), capture
size 128 bytes
sql1rd2:~# ping -c 1 -s 512 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 512(540) bytes of data.
2 packets captured
4 packets received by filter
0 packets dropped by kernel
520 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.023 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.023/0.023/0.023/0.000 ms
sql1rd2:~# tshark -r /tmp/lo.pcap -V -T text -n | grep '^Frame '
Running as user root and group root. This could be dangerous.
Frame 1 (554 bytes on wire, 128 bytes captured)
Frame 2 (554 bytes on wire, 128 bytes captured)
[1]+ Donetcpdump -s 128 -c 2 -pni lo -w /tmp/lo.pcap
sql1rd2:~#
note 122 bytes captured in the first listing versus 128 bytes
captured in the second.
this is fixed in upstream commit ea9432fabdf4b33cbc76d9437200e028f1c47c93,
Fix the calculation of the frame size in memory-mapped captures.
there has not yet been a release on the 1.1 branch (or, well, any
release) since 1.1.1 that contains this fix. but the fix should most
likely be backported to the version in squeeze anyway.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (900, 'unstable'), (800, 'testing'), (700, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libpcap0.8 depends on:
ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib
libpcap0.8 recommends no packages.
libpcap0.8 suggests no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#623868: snapshot length corruption on live captures
tag 623868 + patch
thanks
Robert Edmonds wrote:
this is fixed in upstream commit ea9432fabdf4b33cbc76d9437200e028f1c47c93,
Fix the calculation of the frame size in memory-mapped captures.
attached is a backport of this commit to 1.1.1, and a patch to the
debian package containing the fix.
--
Robert Edmonds
edmo...@debian.org
From cc4298babe767e394dc673c87ef3dbabe3fdb7c9 Mon Sep 17 00:00:00 2001
From: Julien Moutinho j...@savines.alpes.fr.eu.org
Date: Tue, 22 Mar 2011 23:53:15 -0700
Subject: [PATCH] Fix the calculation of the frame size in memory-mapped
captures.
The old calculation truncated packets to a smaller value than the
snapshot length.
---
pcap-linux.c | 49 ++---
1 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/pcap-linux.c b/pcap-linux.c
index af12543..74ac21f 100644
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -3057,15 +3057,58 @@ create_ring(pcap_t *handle)
{
unsigned i, j, frames_per_block;
struct tpacket_req req;
+ socklen_t len;
+ unsigned int sk_type, tp_reserve, maclen, tp_hdrlen, netoff, macoff;
/* Note that with large snapshot (say 64K) only a few frames
* will be available in the ring even with pretty large ring size
* (and a lot of memory will be unused).
* The snap len should be carefully chosen to achive best
* performance */
- req.tp_frame_size = TPACKET_ALIGN(handle-snapshot +
- TPACKET_ALIGN(handle-md.tp_hdrlen) +
- sizeof(struct sockaddr_ll));
+
+ /* NOTE: calculus matching those in tpacket_rcv()
+ * in linux-2.6/net/packet/af_packet.c
+ */
+ len = sizeof(sk_type);
+ if (getsockopt(handle-fd, SOL_SOCKET, SO_TYPE, sk_type, len) 0) {
+ snprintf(handle-errbuf, PCAP_ERRBUF_SIZE, getsockopt: %s, pcap_strerror(errno));
+ return -1;
+ }
+ len = sizeof(tp_reserve);
+ if (getsockopt(handle-fd, SOL_PACKET, PACKET_RESERVE, tp_reserve, len) 0) {
+ snprintf(handle-errbuf, PCAP_ERRBUF_SIZE, getsockopt: %s, pcap_strerror(errno));
+ return -1;
+ }
+ maclen = (sk_type == SOCK_DGRAM) ? 0 : MAX_LINKHEADER_SIZE;
+ /* XXX: in the kernel maclen is calculated from
+ * LL_ALLOCATED_SPACE(dev) and vnet_hdr.hdr_len
+ * in: packet_snd() in linux-2.6/net/packet/af_packet.c
+ * then packet_alloc_skb() in linux-2.6/net/packet/af_packet.c
+ * then sock_alloc_send_pskb() in linux-2.6/net/core/sock.c
+ * but I see no way to get those sizes in userspace,
+ * like for instance with an ifreq ioctl();
+ * the best thing I've found so far is MAX_HEADER in the kernel
+ * part of linux-2.6/include/linux/netdevice.h
+ * which goes up to 128+48=176; since pcap-linux.c defines
+ * a MAX_LINKHEADER_SIZE of 256 which is greater than that,
+ * let's use it.. maybe is it even large enough to directly
+ * replace macoff..
+ */
+ tp_hdrlen = TPACKET_ALIGN(handle-md.tp_hdrlen) + sizeof(struct sockaddr_ll) ;
+ netoff = TPACKET_ALIGN(tp_hdrlen + (maclen 16 ? 16 : maclen)) + tp_reserve;
+ /* NOTE: AFAICS tp_reserve may break the TPACKET_ALIGN of
+ * netoff, which contradicts
+ * linux-2.6/Documentation/networking/packet_mmap.txt
+ * documenting that:
+ * - Gap, chosen so that packet data (Start+tp_net)
+ * aligns to TPACKET_ALIGNMENT=16
+ */
+ /* NOTE: in linux-2.6/include/linux/skbuff.h:
+ * CPUs often take a performance hit
+ * when accessing unaligned memory locations
+ */
+ macoff = netoff - maclen;
+ req.tp_frame_size = TPACKET_ALIGN(macoff + handle-snapshot);
req.tp_frame_nr = handle-opt.buffer_size/req.tp_frame_size;
/* compute the minumum block size that will handle this frame.
--
1.7.4.4
From 3e977e81063366e5634695f99afdd7a85f63a287 Mon Sep 17 00:00:00 2001
From: Robert S. Edmonds edmo...@debian.org
Date: Sat, 23 Apr 2011 22:37:01 -0400
Subject: [PATCH] backport commit ea9432fabd from upstream for #623868
---
debian/changelog |4 ++
debian/patches/60_tpacket_alignment.diff | 81 ++
debian/patches/series|1 +
3 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 debian/patches/60_tpacket_alignment.diff
diff --git a/debian/changelog b/debian/changelog
index f99c8d1..dcd4fe5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,10 @@ libpcap (1.1.1-4) UNRELEASED; urgency=low
when the bonding module is loaded (closes: #612803).
* debian/patches/50_kfreebsd.diff: Enable zerocopy BPF again.
+ [ Robert S. Edmonds ]
+ * Backport commit ea9432fabd from upstream to fix corruption of snapshot
+length on live captures (closes: #623868).
+
-- Romain Francoise rfranco...@debian.org Sat, 16 Apr 2011 15:49:38 +0200
libpcap (1.1.1-3) unstable; urgency=low
diff --git a/debian/patches/60_tpacket_alignment.diff b/debian/patches/60_tpacket_alignment.diff
new file mode 100644
index 000..e68e2e6
--- /dev/null
+++ b/debian/patches/60_tpacket_alignment.diff
@@ -0,0 +1,81 @@
+From cc4298babe767e394dc673c87ef3dbabe3fdb7c9 Mon Sep 17
Bug#582864: status of uwsgi ITP?
Leonid Borisenko wrote: Are you interested in sponsorship? If so, I think, I can upload new package (based on current 0.9.7.x release) for review in a two weeks or so. yes, i would be happy to sponsor the package. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622921: ITP: msgpack-python -- Python implementation of MessagePack format
Package: wnpp Severity: wishlist Owner: Robert S. Edmonds edmo...@debian.org * Package name: msgpack-python Version : 0.1.9 Upstream Author : INADA Naoki * URL : http://pypi.python.org/pypi/msgpack-python/ * License : Apache 2.0 Programming Lang: Python, Cython Description : Python implementation of MessagePack format MessagePack is a binary-based efficient object serialization format. It enables the exchange of structured objects between many languages like JSON. But unlike JSON, it is very fast and small. . This package contains a Python extension module implementing the MessagePack format. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#582864: status of uwsgi ITP?
hi, what's the status of this ITP? i don't see anything that needs fixing before uploading to the archive, except perhaps for an update to the latest upstream release. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#620598: GOST support?
Package: ldns Version: 1.6.9-1 Severity: wishlist now that libssl1.0.0 is in sid and (i believe) supports GOST, it would be interesting to build ldns with GOST support (i.e., removing --disable-gost from the configure args). currently i am building unbound with --disable-gost as well, since unbound's GOST support requires an ldns built with GOST. i rebuilt ldns 1.6.9-1 without --disable-gost and got these new symbols: --- debian/libldns1.symbols (libldns1_1.6.9-1_amd64) +++ dpkg-gensymbols_e2yzM 2011-04-02 20:16:54.600567036 -0400 @@ -170,6 +170,8 @@ ldns_get_rr_type_by_name@Base 1.4.0 ldns_get_signing_algorithm_by_name@Base 1.6.7 ldns_getaddrinfo@Base 1.4.0 + ldns_gost2pkey_raw@Base 1.6.9-1 + ldns_gost_engine@Base 1.6.9-1 ldns_hexdigit_to_int@Base 1.4.0 ldns_hexstring_to_data@Base 1.4.0 ldns_init_random@Base 1.4.0 @@ -178,6 +180,8 @@ ldns_key2buffer_str@Base 1.4.0 ldns_key2rr@Base 1.4.0 ldns_key2str@Base 1.4.0 + ldns_key_EVP_load_gost_id@Base 1.6.9-1 + ldns_key_EVP_unload_gost@Base 1.6.9-1 ldns_key_algo_supported@Base 1.6.1 ldns_key_algorithm@Base 1.4.0 ldns_key_buf2dsa@Base 1.4.0 dh_shlibdeps -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#619309: mirror submission for mirror.mycre.ws
Package: mirrors Severity: wishlist Submission-Type: new Site: mirror.mycre.ws Type: leaf Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ Backports-ftp: /debian-backports/ Backports-http: /debian-backports/ Backports-rsync: debian-backports/ IPv6: yes Archive-upstream: syncproxy.wna.debian.org Backports-upstream: backports-master.debian.org Updates: push Maintainer: Robert Edmonds edmo...@debian.org Country: US United States Location: Atlanta, GA, US Sponsor: Internet Systems Consortium, Inc. http://www.isc.org/ Comment: this mirror submission obsoletes my previous one, #619180. thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619180: mirror submission for mirror.mycre.ws
Package: mirrors Severity: wishlist Submission-Type: new Site: mirror.mycre.ws Type: leaf Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc Backports-ftp: /debian-backports/ Backports-http: /debian-backports/ Backports-rsync: debian-backports/ IPv6: yes Backports-upstream: debian.cs.binghamton.edu Updates: once Maintainer: Robert Edmonds edmo...@debian.org Country: US United States Location: Atlanta, GA, US Sponsor: Internet Systems Consortium, Inc. http://www.isc.org/ Comment: hi, i'd like to upgrade this backports mirror to be a push-triggered primary mirror for the backports service. we have a fair amount of bandwidth and i think this would be the only IPv6-enabled backports mirror in the US :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595717: closed by Ben Hutchings b...@decadent.org.uk (Re: please enable PPS_CLIENT_LDISC and PPS_CLIENT_KTIMER)
Debian Bug Tracking System wrote: config PPS_CLIENT_KTIMER tristate Kernel timer client (Testing client, use for debug) help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. This driver can also be built as a module. If so, the module will be called pps-ktimer. I have not enabled this as it's a debug option only. my understanding is that this option is for debugging userspace applications which use the kernel PPS interface. not for debugging the kernel PPS implementation. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: netcfg: new version of gateway reachability patch
Christian PERRIER wrote: Quoting Robert Edmonds (edmo...@debian.org): Christian PERRIER wrote: To Robert: thanks for the patches and the finally fruitful discussion with Matthew (it started a little bit hot but you guys managed to handle it. That deserves applauses). here is a new version of the patch. this one makes the reachability test conditional on !is_wireless_iface(), since wireless interfaces don't have the 802.1d forwarding delay problem. What is the current status of this change. It seems to me that the later discussion was more about choosing a decent timeout value than the real involved change. So, would it be possible to commit the proposed change? actually, the later discussion was about the value of NETCFG_LINK_WAIT_TIME (which i think is too short) and is unrelated to this patch. i've tested this patch (the gateway reachability test) on real and virtual hardware and it works fine for me. i don't know of any outstanding issues; IMO it can be merged. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#599273: extlinux scripts not run after kernel install/remove because of wrong permissions
reopen 599273
thanks
Daniel Baumann wrote:
Robert Edmonds edmo...@debian.org wrote:
the squeeze version of extlinux installs the /etc/kernel/*.d/zz-
extlinux files mode 0644
no, it doesn't. i just, again, re-checked it.
did you check more than just i386? the extlinux package on
squeeze/amd64 does not install its kernel post-hooks with the correct
permissions.
root@zappa{0}:~# schroot -c debian-6.0-i386
(debian-6.0-i386)root@zappa:~# cat /etc/debian_version
6.0
(debian-6.0-i386)root@zappa:~# apt-cache policy extlinux
extlinux:
Installed: (none)
Candidate: 2:4.02+dfsg-7
Version table:
2:4.02+dfsg-7 0
500 http://mirrors.kernel.org/debian/ stable/main i386 Packages
(debian-6.0-i386)root@zappa:~# ls -l /etc/kernel/*.d/zz-extlinux
ls: cannot access /etc/kernel/*.d/zz-extlinux: No such file or directory
(debian-6.0-i386)root@zappa:~# apt-get install extlinux
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
syslinux-common syslinux-themes-debian
The following NEW packages will be installed:
extlinux
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 84.7 kB of archives.
After this operation, 229 kB of additional disk space will be used.
Get:1 http://mirrors.kernel.org/debian/ stable/main extlinux i386
2:4.02+dfsg-7 [84.7 kB]
Fetched 84.7 kB in 0s (232 kB/s)
Preconfiguring packages ...
Selecting previously deselected package extlinux.
(Reading database ... 10282 files and directories currently installed.)
Unpacking extlinux (from .../extlinux_2%3a4.02+dfsg-7_i386.deb) ...
Setting up extlinux (2:4.02+dfsg-7) ...
P: Checking for EXTLINUX directory... found.
ls: cannot access vmlinuz-*: No such file or directory
(debian-6.0-i386)root@zappa:~# ls -l /etc/kernel/*.d/zz-extlinux
vv
-rwxr-xr-x 1 root root 156 Aug 3 2010 /etc/kernel/postinst.d/zz-extlinux
-rwxr-xr-x 1 root root 156 Aug 3 2010 /etc/kernel/postrm.d/zz-extlinux
^^
note correct permissions
(debian-6.0-i386)root@zappa:~#
root@zappa{0}:~# schroot -c debian-6.0-amd64
(debian-6.0-amd64)root@zappa:~# cat /etc/debian_version
6.0
(debian-6.0-amd64)root@zappa:~# apt-cache policy extlinux
extlinux:
Installed: (none)
Candidate: 2:4.02+dfsg-7
Version table:
2:4.02+dfsg-7 0
500 http://mirrors.kernel.org/debian/ stable/main amd64 Packages
(debian-6.0-amd64)root@zappa:~# ls -l /etc/kernel/*.d/zz-extlinux
ls: cannot access /etc/kernel/*.d/zz-extlinux: No such file or directory
(debian-6.0-amd64)root@zappa:~# apt-get install extlinux
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
syslinux-common syslinux-themes-debian
The following NEW packages will be installed:
extlinux
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 85.4 kB of archives.
After this operation, 233 kB of additional disk space will be used.
Get:1 http://mirrors.kernel.org/debian/ stable/main extlinux amd64
2:4.02+dfsg-7 [85.4 kB]
Fetched 85.4 kB in 0s (0 B/s)
Preconfiguring packages ...
Selecting previously deselected package extlinux.
(Reading database ... 54706 files and directories currently installed.)
Unpacking extlinux (from .../extlinux_2%3a4.02+dfsg-7_amd64.deb) ...
Processing triggers for man-db ...
Setting up extlinux (2:4.02+dfsg-7) ...
(debian-6.0-amd64)root@zappa:~# ls -l /etc/kernel/*.d/zz-extlinux
vv
-rw-r--r-- 1 root root 156 Oct 14 23:37 /etc/kernel/postinst.d/zz-extlinux
-rw-r--r-- 1 root root 156 Oct 14 23:37 /etc/kernel/postrm.d/zz-extlinux
^^
note incorrect permissions
(debian-6.0-amd64)root@zappa:~#
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567879: Please add resolvconf integration
Phil Vandry wrote:
Hello again Martin,
On Mon, Feb 01, 2010 at 11:48:30AM +1300, martin f. krafft wrote:
+if ! echo $MD5SUM | md5sum -c 21; then
+ invoke-rc.d unbound force-reload
+fi
For unbound, force-reload is actually the same as restart, so
you are forcing it to restart (including discarding the contents
of its cache) every time the nameserver information changes.
Unbound supports dynamically setting the upstream resolvers
using unbound-control. I believe that's both cleaner (no messy
files in /var/cache) and less disruptive.
I have attached a script /etc/resolvconf/update.d/unbound
that does it the unbound-control way, in case you're interested.
note that the stock unbound package does not set up unbound-control:
root@bst:~# unbound-control status
[1297895369] unbound-control[336:0] warning: control-enable is 'no' in the
config file.
error: Error setting up SSL_CTX client key and cert
336:error:02001002:system library:fopen:No such file or
directory:bss_file.c:356:fopen('/etc/unbound/unbound_control.pem','r')
336:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:358:
336:error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system
lib:ssl_rsa.c:470:
root@bst:~#
the BIND9 equivalent to unbound-control is rndc, and i believe the bind9
package automatically sets up the necessary rndc shared secret.
should the unbound package automatically set up the necessary key
material and configuration for unbound-control?
also note that rndc is available in a separate package (bind9utils).
should unbound-control{,-setup} go in a separate unbound-utils package
as well, so that one can control a remote unbound server without
installing the unbound package?
--
Robert Edmonds
edmo...@debian.org
signature.asc
Description: Digital signature
Bug#599273: extlinux scripts not run after kernel install/remove because of wrong permissions
reopen 599273 found 599273 2:4.02+dfsg-7 thanks the squeeze version of extlinux installs the /etc/kernel/*.d/zz-extlinux files mode 0644, so while the permissions may have been fixed in 4.01+dfsg-4 the bug re-appeared in the version in squeeze. so this bug affects new squeeze installations and squeeze - wheezy upgrades. IMO this bug needs a more robust fix (chmod +x in maintainer script). /var/cache/apt/archives# dpkg-deb -I extlinux_2%3a4.02+dfsg-7_amd64.deb new debian package, version 2.0. size 85412 bytes: control archive= 3997 bytes. 68 bytes, 2 lines conffiles 105 bytes,10 lines * config #!/bin/sh 718 bytes,19 lines control 731 bytes,11 lines md5sums 1059 bytes,65 lines * postinst #!/bin/sh 206 bytes, 8 lines * postrm #!/bin/sh 4922 bytes,60 lines templates Package: extlinux Source: syslinux Version: 2:4.02+dfsg-7 Architecture: amd64 Maintainer: Debian Syslinux Maintainers sysli...@lists.debian-maintainers.org Installed-Size: 228 Depends: debconf (= 0.5) | debconf-2.0, libc6 (= 2.3) Recommends: syslinux-common, syslinux-themes-debian Conflicts: syslinux ( 2:4.00) Replaces: syslinux Section: utils Priority: optional Homepage: http://syslinux.zytor.com/ Description: collection of boot loaders (ext2/3/4 and btrfs bootloader) SYSLINUX is a collection of boot loaders which operates off Linux ext2/3/4 or btrfs filesystems, MS-DOS FAT filesystems, network servers using PXE firmware, or from CD-ROMs. . This package contains the ext2/3/4 and btrfs bootloader. /var/cache/apt/archives# dpkg-deb -c extlinux_2%3a4.02+dfsg-7_amd64.deb | grep zz-extlinux -rw-r--r-- root/root 156 2010-10-14 23:37 ./etc/kernel/postinst.d/zz-extlinux -rw-r--r-- root/root 156 2010-10-14 23:37 ./etc/kernel/postrm.d/zz-extlinux /var/cache/apt/archives# -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#612846: extlinux: unable to boot md raid devices with version 1.2 metadata
Package: extlinux Version: 2:4.02+dfsg-7 Tags: upstream extlinux is unable to boot off of filesystems on md raid devices created with version 1.2 metadata. this has apparently been considered upstream and seems possible, but is not yet implemented: http://syslinux.zytor.com/archives/2010-June/014470.html in particular the squeeze d-i creates md raid devices with version 1.2 metadata and there is no way to select any other type of metadata, which makes it somewhat difficult to use extlinux on new squeeze installations with software raid. (the best i have been able to do is to create a dedicated md array for /boot and recreate it with version 0.90 metadata post-install.) -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#612697: syslinux-themes-debian-squeeze: grey console background
Package: syslinux-themes-debian-squeeze Version: 5-1 Severity: wishlist with the syslinux-themes-debian-squeeze package installed i get a nice graphical boot screen with extlinux. however, when the system starts to boot the console has a grey background, with console text in the traditional grey-on-black which overwrites the grey background. eventually all of the grey background scrolls off the screen as messages are written to the console. would look better if the system booted with the traditional black background. attached is an IPKVM screenshot. -- Robert Edmonds edmo...@debian.org attachment: grey-background.png signature.asc Description: Digital signature
Bug#537271: netcfg: new version of gateway reachability patch
Christian PERRIER wrote:
To Robert: thanks for the patches and the finally fruitful discussion
with Matthew (it started a little bit hot but you guys managed to
handle it. That deserves applauses).
here is a new version of the patch. this one makes the reachability
test conditional on !is_wireless_iface(), since wireless interfaces
don't have the 802.1d forwarding delay problem.
--
Robert Edmonds
edmo...@debian.org
diff -Npru netcfg-1.60.orig/netcfg-common.c netcfg-1.60/netcfg-common.c
--- netcfg-1.60.orig/netcfg-common.c 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg-common.c 2011-02-08 21:14:29.855940300 -0500
@@ -1035,23 +1035,40 @@ void netcfg_update_entropy (void)
*/
int netcfg_detect_link(struct debconfclient *client, const char *if_name)
{
-int wait_count, rv = 0;
+char arping[256];
+char s_gateway[INET_ADDRSTRLEN];
+int count, rv = 0;
+int link_waits = NETCFG_LINK_WAIT_TIME * 4;
+int gw_tries = NETCFG_GATEWAY_REACHABILITY_TRIES;
+
+if (gateway.s_addr) {
+inet_ntop(AF_INET, gateway, s_gateway, sizeof(s_gateway));
+sprintf(arping, arping -c 1 -w 1 -f -I %s %s, if_name, s_gateway);
+}
debconf_capb(client, progresscancel);
debconf_subst(client, netcfg/link_detect_progress, interface, if_name);
-debconf_progress_start(client, 0, NETCFG_LINK_WAIT_TIME * 4, netcfg/link_detect_progress);
-for (wait_count = 0; wait_count NETCFG_LINK_WAIT_TIME * 4; wait_count++) {
+debconf_progress_start(client, 0, 100, netcfg/link_detect_progress);
+for (count = 0; count link_waits; count++) {
usleep(25);
-if (debconf_progress_step(client, 1) == 30) {
+if (debconf_progress_set(client, 50 * count / link_waits) == 30) {
/* User cancelled on us... bugger */
rv = 0;
break;
}
-if (ethtool_lite (if_name) == 1) /* ethtool-lite's CONNECTED */ {
-debconf_progress_set(client, NETCFG_LINK_WAIT_TIME * 4);
+if (ethtool_lite(if_name) == 1) /* ethtool-lite's CONNECTED */ {
+if (gateway.s_addr !is_wireless_iface(if_name)) {
+for (count = 0; count gw_tries; count++) {
+if (di_exec_shell_log(arping) == 0)
+break;
+if (debconf_progress_set(client, 50 + 50 * count / gw_tries) == 30)
+break;
+}
+}
rv = 1;
break;
}
+debconf_progress_set(client, 100);
}
debconf_progress_stop(client);
diff -Npru netcfg-1.60.orig/netcfg.h netcfg-1.60/netcfg.h
--- netcfg-1.60.orig/netcfg.h 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg.h 2011-02-07 01:32:02.895935476 -0500
@@ -47,6 +47,11 @@
*/
#define NETCFG_LINK_WAIT_TIME 3
+/* The number of times to attempt to verify gateway reachability.
+ * Each try invokes arping with a one second timeout.
+ */
+#define NETCFG_GATEWAY_REACHABILITY_TRIES 50
+
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 63
#endif
Bug#537271: netcfg: new version of gateway reachability patch
Robert Edmonds wrote: here is a new version of the patch. this one makes the reachability test conditional on !is_wireless_iface(), since wireless interfaces don't have the 802.1d forwarding delay problem. i have now built a test d-i which includes busybox arping and the netcfg arping patch: http://people.debian.org/~edmonds/d-i-arping/mini-arping.iso i have tested this in three different ways in virtualbox: #1 - with a reachable gateway. the arping is performed, link detection succeeds instantly. in syslog is: Feb 9 02:46:19 main-menu[261]: INFO: Menu item 'netcfg' selected Feb 9 02:46:19 netcfg[1368]: INFO: Starting netcfg v.1:1.60~rse0 (built 20110208-2136) Feb 9 02:46:59 kernel: [ 83.783523] ADDRCONF(NETDEV_UP): eth0: link is not ready Feb 9 02:46:59 kernel: [ 83.784553] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Feb 9 02:46:59 netcfg[1368]: INFO: executing: ip addr add 172.16.0.42/24 broadcast 172.16.0.255 dev eth0 Feb 9 02:46:59 kernel: [ 83.784989] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Feb 9 02:46:59 netcfg[1368]: INFO: ethtool-lite: eth0 is connected. Feb 9 02:46:59 netcfg[1368]: ARPING to 172.16.0.1 from 172.16.0.42 via eth0 Feb 9 02:46:59 netcfg[1368]: Unicast reply from 172.16.0.1 [0:8:9b:bf:a4:3] 0.438ms Feb 9 02:46:59 netcfg[1368]: Sent 1 probe(s) (1 broadcast(s)) Feb 9 02:46:59 netcfg[1368]: Received 1 replies (0 request(s), 0 broadcast(s)) Feb 9 02:47:11 netcfg[1368]: INFO: Detected eth0 as a hotpluggable device #2 - with an unreachable gateway. ARPs are sent once a second, the progress bar smoothly advances from 50% to 100% at 1%/second for 50 seconds, then the installation proceeds. (note that we could have arping failure result in failure being returned from netcfg_detect_link() but it is currently conservatively coded to only delay until the gateway is reachable and not to modify the return value.) #3 - with a gateway that becomes reachable sometime after the arping loop starts. as soon as the gateway becomes reachable the arping loop terminates and the progress bar advances to 100%, then the installation proceeds. i have also tested this on a physical server with both DHCP and static network configs and everything worked as expected. the potential for breakage seems quite low. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#537271: netcfg: new version of gateway reachability patch
Christian PERRIER wrote: Quoting Robert Edmonds (edmo...@debian.org): Robert Edmonds wrote: here is a new version of the patch. this one makes the reachability test conditional on !is_wireless_iface(), since wireless interfaces don't have the 802.1d forwarding delay problem. i have now built a test d-i which includes busybox arping and the netcfg arping patch: http://people.debian.org/~edmonds/d-i-arping/mini-arping.iso Can you compare the sizes of the busybox udeb with and without the arping patch? i just compiled the busybox udeb with and without the arping applet on amd64. 279344 bytes with arping, 279328 bytes without, only +16 bytes. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: netcfg: new version of gateway reachability patch
btw, (unrelated to #537271), it seems to me that 3 seconds is a fairly short value for NETCFG_LINK_WAIT_TIME. i'm pretty sure i've seen link-up take longer than that on occasion before, depending on NIC chipset, switch, autonegotiation latency, etc. 5 - 10 seconds would be a more conservative default, given that there's no penalty if link-up occurs before the timeout. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515307: gvpe gpl / openssl license incompatibility
gvpe is GPL licensed, without an openssl exception, so afaik it cannot go into debian currently... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515307: gvpe gpl / openssl license incompatibility
Robert Edmonds wrote: gvpe is GPL licensed, without an openssl exception, so afaik it cannot go into debian currently... oh, hm, it seems there are individual openssl exceptions in (some of?) the source files, rather than the top-level COPYING file. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#414117: unmerge 414117 537271
unmerge 414117 537271 reopen 537271 thanks #414117 was closed due to this change in netcfg: * Wait for up to 3 seconds (in 0.25s increments) looking for the link on an interface. Add a progress bar to show the progress of this operation. Closes: #414117. #537271 concerns the situation where the link is up but not yet usable: the debian-installer seems to assume that the network is usable as soon as the link comes up, which may not be the case if the 802.1d spanning tree protocol is in use, in which case it can be up to ~30 seconds before the switch port will forward ethernet frames. please don't merge unrelated bugs. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org (This is done, regardless of the reason)
reopen 537271 thanks Debian Bug Tracking System wrote: Given that there is no possible way to detect that the network link is up but unuseable, did you even read #537271? the simple, 100% effective fix for the situation where your port has link up but the bridge port has not entered the forwarding state is to send ARP requests for the default gateway's IP address until they are answered. an IPv4 router must answer ARP requests or it cannot route packets. the improved DHCP configuration, whereby DHCP DISCOVER packets are sent every second, is the best possible fix for this (coupled with the ability to preseed whatever length of DHCP timeout you want). irrelevant for statically configured networks. i.e., servers. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org
tag 537271 +patch
thanks
Matthew Palmer wrote:
the simple, 100% effective fix for the
situation where your port has link up but the bridge port has not
entered the forwarding state is to send ARP requests for the default
gateway's IP address until they are answered. an IPv4 router must
answer ARP requests or it cannot route packets.
Emphasis on IPv4 and router, neither of which are required items.
then the fix would be made conditional on an IPv4 router being configured.
the improved DHCP configuration, whereby DHCP DISCOVER packets are
sent every second, is the best possible fix for this (coupled with the
ability to preseed whatever length of DHCP timeout you want).
irrelevant for statically configured networks. i.e., servers.
You are correct. I'm not exactly in a mood to fix this for you, though, so
patches welcome.
537271_busybox_arping.patch
enables arping in the busybox udeb.
537271_netcfg_arping.patch
modifies netcfg_detect_link() to wait invoke busybox's arping with
the '-f' flag (quit on first ARP reply). waits up to 45 seconds for
an ARP reply from the default gateway. (this should probably
actually be a loop that repeatedly invokes arping with a short
timeout in order to update the progress bar.)
severity 537271 wishlist
thanks
I'd say that for any bugs that are very difficult to fix due to major
design considerations where the major design consideration is STP
doesn't signal link availability applies nicely here.
yes, it would be very difficult to fix this if the proposed solution
were to modify STP, a protocol baked into millions of switches...
fortunately polling for layer 2/3 connectivity to the gateway is
far easier.
on cisco switches there is a per-port mode called spanning-tree
portfast, and on every cisco switch i've ever used this mode defaults
to off. when you turn it on, a warning message like this is printed:
Warning: portfast should only be enabled on ports connected to a
single host. Connecting hubs, concentrators, switches, bridges, etc.
to this interface when portfast is enabled, can cause temporary
bridging loops. Use with CAUTION
consequently it's frequently left off in many environments, so the usual
sequence of events ends up going something like:
* start up a preseeded installation on a new server.
* installer fails when trying to download something.
* realize the failure is due to portfast not being enabled.
* call up the networking guy and get him to enable portfast on this
server's switch port.
* power cycle the server and start the preseeded installation again.
--
Robert Edmonds
edmo...@debian.org
diff -Npru busybox-1.17.1.orig/debian/config/pkg/udeb busybox-1.17.1/debian/config/pkg/udeb
--- busybox-1.17.1.orig/debian/config/pkg/udeb 2010-11-09 05:37:10.0 -0500
+++ busybox-1.17.1/debian/config/pkg/udeb 2011-02-06 21:13:04.455899401 -0500
@@ -697,7 +697,7 @@ CONFIG_NC_EXTRA=y
# CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set
# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
# CONFIG_ARP is not set
-# CONFIG_ARPING is not set
+CONFIG_ARPING=y
# CONFIG_BRCTL is not set
# CONFIG_FEATURE_BRCTL_FANCY is not set
# CONFIG_FEATURE_BRCTL_SHOW is not set
diff -Npru netcfg-1.60.orig/netcfg-common.c netcfg-1.60/netcfg-common.c
--- netcfg-1.60.orig/netcfg-common.c 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg-common.c 2011-02-06 21:44:10.611927865 -0500
@@ -1048,6 +1048,14 @@ int netcfg_detect_link(struct debconfcli
break;
}
if (ethtool_lite (if_name) == 1) /* ethtool-lite's CONNECTED */ {
+if (gateway.s_addr) {
+char arping[256];
+char s_gateway[INET_ADDRSTRLEN];
+
+inet_ntop (AF_INET, gateway, s_gateway, sizeof(s_gateway));
+sprintf(arping, arping -w 45 -f -I %s %s, if_name, s_gateway);
+di_exec_shell_log(arping);
+}
debconf_progress_set(client, NETCFG_LINK_WAIT_TIME * 4);
rv = 1;
break;
Bug#612249: please add arping to busybox udeb
Package: busybox Version: 1:1.17.1-8 please add arping to the busybox udeb. arping is needed in order to implement gateway reachability detection in netcfg, see #537271. the attached patch ought to do it. -- Robert Edmonds edmo...@debian.org diff -Npru busybox-1.17.1.orig/debian/config/pkg/udeb busybox-1.17.1/debian/config/pkg/udeb --- busybox-1.17.1.orig/debian/config/pkg/udeb 2010-11-09 05:37:10.0 -0500 +++ busybox-1.17.1/debian/config/pkg/udeb 2011-02-06 21:13:04.455899401 -0500 @@ -697,7 +697,7 @@ CONFIG_NC_EXTRA=y # CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set # CONFIG_VERBOSE_RESOLUTION_ERRORS is not set # CONFIG_ARP is not set -# CONFIG_ARPING is not set +CONFIG_ARPING=y # CONFIG_BRCTL is not set # CONFIG_FEATURE_BRCTL_FANCY is not set # CONFIG_FEATURE_BRCTL_SHOW is not set
Bug#537271: closed by Matthew Palmer mpal...@debian.org
Matthew Palmer wrote:
On Sun, Feb 06, 2011 at 10:15:48PM -0500, Robert Edmonds wrote:
(this should probably
actually be a loop that repeatedly invokes arping with a short
timeout in order to update the progress bar.)
This really needs to be implemented. Leaving users hanging with no clue as
to what's happening for 45 seconds isn't right.
I've left the patch tag on the bug for now, on the assumption that this can
be fixed RSN.
ok, i've rewritten the patch such that the first 50% of the progress bar
is waiting for the link to come up and the second 50% of the progress
bar is the gateway reachability test. the reachability test now
repeatedly invokes arping with a one second timeout (up to 50 times)
until arping exits with a status of 0. (arping exits with a status of 1
if the time expired.)
in cases where the gateway is reachable as soon as the link is up or no
gateway is configured there will be an instantaneous jump from 50% to
100%.
in cases where the gateway takes 30 seconds to become reachable the
progress bar will increment by 1%/second until instantaneously jumping
from ~80% to 100%.
Also, busybox patches should be put into a separate bug report which blocks
this one, to keep things clear.
#612249
--
Robert Edmonds
edmo...@debian.org
diff -Npru netcfg-1.60.orig/netcfg-common.c netcfg-1.60/netcfg-common.c
--- netcfg-1.60.orig/netcfg-common.c 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg-common.c 2011-02-07 01:36:38.683940125 -0500
@@ -1035,23 +1035,40 @@ void netcfg_update_entropy (void)
*/
int netcfg_detect_link(struct debconfclient *client, const char *if_name)
{
-int wait_count, rv = 0;
+char arping[256];
+char s_gateway[INET_ADDRSTRLEN];
+int count, rv = 0;
+int link_waits = NETCFG_LINK_WAIT_TIME * 4;
+int gw_tries = NETCFG_GATEWAY_REACHABILITY_TRIES;
+
+if (gateway.s_addr) {
+inet_ntop(AF_INET, gateway, s_gateway, sizeof(s_gateway));
+sprintf(arping, arping -c 1 -w 1 -f -I %s %s, if_name, s_gateway);
+}
debconf_capb(client, progresscancel);
debconf_subst(client, netcfg/link_detect_progress, interface, if_name);
-debconf_progress_start(client, 0, NETCFG_LINK_WAIT_TIME * 4, netcfg/link_detect_progress);
-for (wait_count = 0; wait_count NETCFG_LINK_WAIT_TIME * 4; wait_count++) {
+debconf_progress_start(client, 0, 100, netcfg/link_detect_progress);
+for (count = 0; count link_waits; count++) {
usleep(25);
-if (debconf_progress_step(client, 1) == 30) {
+if (debconf_progress_set(client, 50 * count / link_waits) == 30) {
/* User cancelled on us... bugger */
rv = 0;
break;
}
-if (ethtool_lite (if_name) == 1) /* ethtool-lite's CONNECTED */ {
-debconf_progress_set(client, NETCFG_LINK_WAIT_TIME * 4);
+if (ethtool_lite(if_name) == 1) /* ethtool-lite's CONNECTED */ {
+if (gateway.s_addr) {
+for (count = 0; count gw_tries; count++) {
+if (di_exec_shell_log(arping) == 0)
+break;
+if (debconf_progress_set(client, 50 + 50 * count / gw_tries) == 30)
+break;
+}
+}
rv = 1;
break;
}
+debconf_progress_set(client, 100);
}
debconf_progress_stop(client);
diff -Npru netcfg-1.60.orig/netcfg.h netcfg-1.60/netcfg.h
--- netcfg-1.60.orig/netcfg.h 2011-02-05 20:42:06.0 -0500
+++ netcfg-1.60/netcfg.h 2011-02-07 01:32:02.895935476 -0500
@@ -47,6 +47,11 @@
*/
#define NETCFG_LINK_WAIT_TIME 3
+/* The number of times to attempt to verify gateway reachability.
+ * Each try invokes arping with a one second timeout.
+ */
+#define NETCFG_GATEWAY_REACHABILITY_TRIES 50
+
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 63
#endif
Bug#600261: protobuf: [patch] remove explicit #!/usr/bin/python2.4 usage
Michael Vogt wrote:
In Ubuntu, we've applied the attached patch to achieve the following:
* Merge from debian unstable. Remaining changes:
- Don't use #!/usr/bin/python2.4 but use #!/usr/bin/python instead
We thought you might be interested in doing the same.
+Index: protobuf-2.1.0/python/mox.py
+Index: protobuf-2.1.0/python/stubout.py
as far as i can tell, mox and stubout are not used anywhere in the
debian protobuf packages nor the build system or tests. (the Makefile
matches below are solely in the EXTRA_DIST variable.)
what exactly is the point of your patch?
edmo...@chase{0}:~/debian/protobuf/protobuf-2.3.0$ dpkg -L python-protobuf
| egrep (mox|stubout)
edmo...@chase{1}:~/debian/protobuf/protobuf-2.3.0$ grep -lri mox *
Makefile.am
Makefile.in
debian/copyright
python/mox.py
python/stubout.py
edmo...@chase{0}:~/debian/protobuf/protobuf-2.3.0$ grep -lri stubout *
Makefile.am
Makefile.in
debian/copyright
python/mox.py
python/stubout.py
edmo...@chase{0}:~/debian/protobuf/protobuf-2.3.0$
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595717: please enable PPS_CLIENT_LDISC and PPS_CLIENT_KTIMER
Package: linux-2.6 Version: 2.6.35-1~experimental.2 Severity: wishlist hi, i'd like to request that the PPS client modules be enabled: $ grep CONFIG_PPS_CLIENT /boot/config-2.6.35-trunk-amd64 # CONFIG_PPS_CLIENT_KTIMER is not set # CONFIG_PPS_CLIENT_LDISC is not set $ the current linux-image packages ship with CONFIG_PPS=m set, but unfortunately this is a bit useless without the client modules as well: config PPS_CLIENT_KTIMER tristate Kernel timer client (Testing client, use for debug) help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. This driver can also be built as a module. If so, the module will be called pps-ktimer. config PPS_CLIENT_LDISC tristate PPS line discipline depends on PPS help If you say yes here you get support for a PPS source connected with the CD (Carrier Detect) pin of your serial port. PPS_CLIENT_LDISC in particular is needed if you want to attach a stratum-0 NTP time source (GPS with pulse-per-second line attached to the CD pin) to a debian host, e.g.: http://time.qnan.org/ http://wiki.enneenne.com/index.php/LinuxPPS_installation an almost identical bug was reported in the fedora bugzilla, btw: https://bugzilla.redhat.com/show_bug.cgi?id=619392 thanks! -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#521857: not fixed in current version
reopen 521857 found 1:0.7.3-1.3 thanks this bug is not fixed in the current version. -- Robert Edmonds edmo...@debian.org debian bug #521857 --- ettercap-0.7.3.orig/src/protocols/ec_tcp.c +++ ettercap-0.7.3/src/protocols/ec_tcp.c @@ -116,7 +116,7 @@ tcp = (struct tcp_header *)DECODE_DATA; opt_start = (u_char *)(tcp + 1); - opt_end = (u_char *)((int)tcp + tcp-off * 4); + opt_end = (u_char *)(((u_char *) tcp) + tcp-off * 4); DECODED_LEN = (u_int32)(tcp-off * 4);
Bug#592437: ldns: please include upstream changelog file
Package: libldns-dev Version: 1.6.5-1 it'd be nice if one of the ldns packages would include the upstream changelog file. thanks. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#433779: asterisk doesn't retry SIP registrations if DNS is not available
found 433779 asterisk/1:1.6.2.7-1 user initscripts-ng-de...@lists.alioth.debian.org usertag 433779 + missing-dependency thanks hi, it appears that asterisk is incorrectly treating DNS resolution failure during SIP registration as a 404 not found SIP response. when my system boots, asterisk is started after my recursive DNS server, and i see this in /var/log/asterisk/messages: [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'inbound23.vitelity.net' [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'outbound.vitelity.net' [May 31 17:36:41] WARNING[1704] acl.c: Unable to lookup 'inbound23.vitelity.net' [May 31 17:36:41] NOTICE[1704] chan_sip.c: Registration from 'sip:edmond...@inbound23.vitelity.net' failed for '127.0.0.1' - No matching peer found [May 31 17:36:41] WARNING[1704] chan_sip.c: Got 404 Not found on SIP register to service edmond...@inbound23.vitelity.net, giving up it seems to be impossible for asterisk to have received a 404 not found response from the SIP peer if DNS is not available, and indeed i verified with a packet sniffer that no SIP packets were sent or received. it looks like there are two bugs here: 1) asterisk should treat DNS resolution failures as transient network failures, not SIP failures, and be subject to retrying the registration. asterisk made no attempt to retry the registration after the initial DNS failure. 2) /etc/init.d/asterisk contains the following LSB header: ### BEGIN INIT INFO # Provides: asterisk # Required-Start:$remote_fs # Required-Stop: $remote_fs # Should-Start: dahdi mysql postgresql # Should-Stop: mysql postgresql # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Asterisk PBX # Description: Controls the Asterisk PBX ### END INIT INFO if i'm not mistaken, on systems with parallel booting enabled this means it would be possible for asterisk to start before the network is up or name resolution is available. i believe that $named and $network should be added to Should-Start. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#582755: modifying files from another package
Holger Levsen wrote: during a test with piuparts I noticed your package modifies files from another package in /usr. This is so wrong, I'm not even bothered to look up the part of policy this violates ;-P 0m18.4s ERROR: FAIL: After purging files have been modified: /etc/resolv.conf not owned hi, holger: technically, /etc/resolv.conf is in /etc, not /usr :) and afaict, no package owns /etc/resolv.conf; i believe, like /etc/hosts, that it's written by debian-installer? so there may not be an explicit policy against this behavior. there's a lot of software in debian that rewrites /etc/resolv.conf (resolvconf, DHCP clients, etc) but i think this is the only package that rewrites /etc/resolv.conf without asking or through some action that the user takes. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#578129: please apply skip sense logging for some ATA PASS-THROUGH cdbs from 2.6.33
Package: linux-2.6
Version: 2.6.32-11
Severity: normal
Tags: patch
hi,
when SATA drives are attached to SAS controllers and used in ATA
pass-through mode, many operations cause alarming but harmless messages
(though it may not be immediately obvious to the user that they are
harmless) to be written to the kernel log, e.g.:
[1381579.095459] sd 8:0:23:0: [sdx] Sense Key : Recovered Error [current]
[descriptor]
[1381579.095518] Descriptor sense data with sense descriptors (in hex):
[1381579.095549] 72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
[1381579.095614] 00 4f 00 c2 00 50
[1381579.095654] sd 8:0:23:0: [sdx] Add. Sense: ATA pass through information
available
i see these types of messages at boot as well as periodically due to the
use of smartmontools. if you have a lot of disks your kernel log will
be spammed.
can you apply commit e7efe5932b1d3916c79326a4221693ea90a900e2 from
2.6.33 to suppress these messages?
thanks.
--
Robert Edmonds
edmo...@debian.org
From e7efe5932b1d3916c79326a4221693ea90a900e2 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Sun, 3 Jan 2010 13:51:15 -0500
Subject: [PATCH] [SCSI] skip sense logging for some ATA PASS-THROUGH cdbs
Further to the lsml thread titled:
does scsi_io_completion need to dump sense data for ata pass through (ck_cond =
1) ?
This is a patch to skip logging when the sense data is
associated with a SENSE_KEY of RECOVERED_ERROR and the
additional sense code is ATA PASS-THROUGH INFORMATION
AVAILABLE. This only occurs with the SAT ATA PASS-THROUGH
commands when CK_COND=1 (in the cdb). It indicates that
the sense data contains ATA registers.
Smartmontools uses such commands on ATA disks connected via
SAT. Periodic checks such as those done by smartd cause
nuisance entries into logs that are:
- neither errors nor warnings
- pointless unless the cdb that caused them are also logged
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
Signed-off-by: James Bottomley james.bottom...@suse.de
---
drivers/scsi/scsi_lib.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c664242..5697709 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -773,8 +773,14 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
* we already took a copy of the original into rq-errors which
* is what gets returned to the user
*/
- if (sense_valid sshdr.sense_key == RECOVERED_ERROR) {
- if (!(req-cmd_flags REQ_QUIET))
+ if (sense_valid (sshdr.sense_key == RECOVERED_ERROR)) {
+ /* if ATA PASS-THROUGH INFORMATION AVAILABLE skip
+ * print since caller wants ATA registers. Only occurs on
+ * SCSI ATA PASS_THROUGH commands when CK_COND=1
+ */
+ if ((sshdr.asc == 0x0) (sshdr.ascq == 0x1d))
+ ;
+ else if (!(req-cmd_flags REQ_QUIET))
scsi_print_sense(, cmd);
result = 0;
/* BLOCK_PC may have set error */
--
1.7.0.4
signature.asc
Description: Digital signature
Bug#567879: Please add resolvconf integration
martin f. krafft wrote: Package: unbound Severity: wishlist Tags: patch Signed-off-by: martin f. krafft madd...@debian.org --- contrib/resolvconf-update-script.sh | 42 + debian/patches/30_example_conf_resolvconf_include | 14 +++ debian/patches/series |1 + debian/rules |2 + debian/unbound.dirs |2 + 5 files changed, 61 insertions(+), 0 deletions(-) create mode 100755 contrib/resolvconf-update-script.sh create mode 100644 debian/patches/30_example_conf_resolvconf_include can you please explain exactly what this does and how it relates to #562031? +# Script to inform unbound about upstream resolvers. by upstream resolver do you mean a recursive nameserver? ++# Resolvconf integration ++# If you have the resolvconf package installed, you can uncomment the ++# following to let unbound forward queries to the DNS resolvers discovered by ++# resolvconf (e.g. from DHCP or static entries in /etc/network/interfaces). ++# include: /var/cache/unbound/resolvconf_resolvers.conf i'm confused. unbound is already a full service resolver. doesn't this configure unbound to just act like a stub resolver by forwarding all its queries to another full service resolver? why not just set that resolver address in /etc/resolv.conf? is there some use case that this solves, e.g. something to do with DNSSEC validation (since there is no DNSSEC support in the glibc stub resolver) or maybe operation on hostile networks that block / intercept port 53 traffic? diff --git a/debian/rules b/debian/rules index ad1025f..f36201c 100755 --- a/debian/rules +++ b/debian/rules @@ -26,6 +26,8 @@ install: build dh_installinit --error-handler=true --restart-after-upgrade dh install --after dh_installinit install -m 0644 doc/example.conf debian/unbound/etc/unbound/unbound.conf + install -m 0755 contrib/resolvconf-update-script.sh \ + debian/unbount/etc/resolvconf/update.d/unbound s/unbount/unbound/ -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#567879: Please add resolvconf integration
martin f krafft wrote: also sprach Robert Edmonds edmo...@debian.org [2010.02.01.1207 +1300]: can you please explain exactly what this does and how it relates to #562031? My script supplements #562031, which talks only about how to teach the system to ask localhost (or whereever unbound listens). The way I do this is by adding dns-nameservers ::1 to the 'lo' stanza in /etc/network/interfaces. My script then simply makes sure that unbound knows what the DNS IPs obtained by e.g. DHCP are, so that it can forward queries recursively, rather than iteratively resolving them. hm, i see. ++# Resolvconf integration ++# If you have the resolvconf package installed, you can uncomment the ++# following to let unbound forward queries to the DNS resolvers discovered by ++# resolvconf (e.g. from DHCP or static entries in /etc/network/interfaces). ++# include: /var/cache/unbound/resolvconf_resolvers.conf i'm confused. unbound is already a full service resolver. doesn't this configure unbound to just act like a stub resolver by forwarding all its queries to another full service resolver? why not just set that resolver address in /etc/resolv.conf? I want to use unbound locally to be able to use e.g. local-data, and to stub some zones. ah, so you have some sort of split horizon DNS setup? in the past i've seen this done with dnscache, dnsmasq, and i believe it's in fact built into the macosx stub resolver. of course unbound and bind can do it too. Obviously I don't need to tell it about the resolvers because it can do it itself (using the root zones), but that's not really how DNS was designed: it should ask the resolvers rather than the root servers. well, no, in fact this is just one possible configuration. see RFC 1035, section 2.2. especially, Information flow can also be tailored so that a group of hosts act together to optimize activities. Sometimes this is done to offload less capable hosts so that they do not have to implement a full resolver. This can be appropriate for PCs or hosts which want to minimize the amount of new network code which is required. This scheme can also allow a group of hosts can share a small number of caches rather than maintaining a large number of separate caches, on the premise that the centralized caches will have a higher hit ratio. In either case, resolvers are replaced with stub resolvers which act as front ends to resolvers located in a recursive server in one or more name servers known to perform that service: (by root servers, i think you meant content servers, btw.) in principle if everyone switched to the first diagram in 1035 2.2 there would be global DNS scalability issues, but i don't see any harm in debian users running unbound in full service mode. they may even prefer it to avoid censorship and NXDOMAIN rewriting by ISP resolvers which is unfortunately becoming quite common. Normally, you just put the ISP NSs from DHCP into /etc/resolv.conf, which will then cause the following (libc is just one possible resolver library): localhost → libc → ISP → … → root-servers If instead you plug in unbound like suggested in #562031, you get localhost → libc → unbound → root-servers My patch allows the admin to turn that into localhost → libc → unbound → ISP → … → root-servers by uncommenting the include directive. well, i am philosophically opposed to the latter configuration. but i will merge this patch anyway since it seems like useful functionality to have. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#567879: Please add resolvconf integration
martin f krafft wrote: Of course it works the other way, but if everyone out there hammered the root-servers, then they'd have a huge problem. (by root servers, i think you meant content servers, btw.) No, I meant the root-servers, i.e. the servers responsible for the '.' zone. i think you are mistaken. in practice, unbound (or bind or any other reasonably compliant full service DNS resolver / cache) only sends occasional queries to the root; running unbound in normal recursive full service mode doesn't hammer the roots. delegations and glue from the root zone have quite long TTLs (2 days). the only way you could see unbound hammering the roots would be if your clients looked up a large number of domain names under nonexistent TLDs. because query rcode 3 (name error / NXDOMAIN) only specifies the nonexistence of a domain name it cannot tell the querier about the nonexistence of a zone cut between that domain name and the root. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566790: build python-tre package
Package: tre Version: 0.8.0-2 Severity: wishlist hi, it'd be nice if the tre source package could build and install the python bindings for libtre in a 'python-tre' binary package. the tre debian package doesn't use debhelper so this might be a bit tricky. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#563033: avoid stopping daemon in prerm upgrade
Joey Hess wrote: During an upgrade, unbound may be stopped for a rather long time for something as crucial as a network's DNS server. Please see if you can make it use dh_installinit --restart-after-upgrade to close this window of downtime. afaict there shouldn't be any problem doing this. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#562031: unbound: Add support resolvconf for
Rick Moen wrote:
When the nameserver is ready to serve it should
do the equivalent of this sh script:
NAME=unbound
echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.$NAME
and when it is no longer ready to serve it should do:
/sbin/resolvconf -d lo.$NAME
hm, as resolvconf is Priority: optional, i suppose the hypothetical sh
script should instead do something like:
NAME=unbound
if [ -x /sbin/resolvconf ]; then
echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.$NAME
fi
but unbound is not necessarily listening on 127.0.0.1; it's not
necessarily even listening on a single IP address.
to take my desktop as an example:
unbound3024 unbound3u IPv4 1099831 0t0 UDP 216.27.162.2:53
unbound3024 unbound4u IPv4 1099833 0t0 TCP 216.27.162.2:53
(LISTEN)
unbound3024 unbound5u IPv6 1099835 0t0 UDP
[2001:470:7:208::2]:53
unbound3024 unbound6u IPv6 1099837 0t0 TCP
[2001:470:7:208::2]:53 (LISTEN)
it appears resolvconf wants both an interface name and an IP address.
it looks like i'd have to do something like:
NAME=unbound
PID=$(cat /var/run/unbound.pid)
# get the first IPv4 listening address
ADDR=$(ss -f inet -pnl | grep \unbound\,$PID | awk '{print$3}' | head
-1 | cut -f1 -d:)
# get the interface name
IFACE=$(ip addr show to $ADDR | head -1 | cut -f2 -d' ' | cut -f1 -d:)
if [ -x /usr/sbin/resolvconf ]; then
echo nameserver $ADDR | /sbin/resolvconf -a $IFACE.$NAME
fi
perhaps with a bit more error handling and correctly handling IPv6-only
configurations. (and should we send more than one listening address to
resolvconf or just one?) this is starting to look a bit complicated.
should i just cop-out and only do the resolvconf thing if unbound
happens to be listening on 127.0.0.1?
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560954: generates incorrect paths in kernel.cfg when /boot not on root filesystem
Package: extlinux Version: 2:3.83+dfsg-5 Severity: important i have /boot on a separate filesystem. update-extlinux generated a kernel.cfg file that referenced kernel /boot/vmlinux-... and initrd=/boot/initrd.img-... when it should have omitted the leading /boot path component. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#560432: turn on enclosure LEDs when a component device fails
Package: mdadm Version: 3.0.3-2 Severity: wishlist according to http://lkml.org/lkml/2008/2/3/193, You can flash the various blinky lights by echoing to the fault and locate files. my SAS/SES-2 based array appears to support this: .../sys/block/sda/device/enclosure_device:000$ grep . * active:0 fault:0 locate:0 status:OK type:array device it would be nice if mdadm could automatically turn on the fault light of an underlying block device when a component device fails. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#559960: FTBFS [hppa] - google/protobuf/wire_format_inl.h: No such file or directory
dann frazier wrote: protobuf-c reliably fails to build on hppa: https://buildd.debian.org/build.php?pkg=protobuf-cver=0.11-3arch=hppafile=log it's not just hppa, apparently a header file was renamed in the latest libprotobuf-dev and the other buildd's built protobuf-c with the older version. i've patched the protobuf-c includes and added a versioned build-dep in 0.11-4. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556563: protobuf and mumble
Kenton Varda wrote: I've created a 2.2.0a release: SVN: http://protobuf.googlecode.com/svn/tags/2.2.0a/ tarball: http://groups.google.com/group/protobuf/web/protobuf-2.2.0a.tar.bz2 Diff from 2.2.0: http://code.google.com/p/protobuf/source/detail?r=246 I will make it live on the official site as soon as you confirm that it fixes the problem. i haven't tested it, but i can confirm that it is the change i would have made :) -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556563: protobuf and mumble
Dirk Eddelbuettel wrote: On 18 November 2009 at 18:55, Robert Edmonds wrote: | since the changes from 2.1.0 to 2.2.0 have demonstrably broken ABI | compatibility, the SONAME really should be bumped, regardless of NEW | delays, etc. because it is the correct thing to do, rather than breaking | unrelated software. ideally it should be coordinated with upstream so | that we don't break binary compatibility with other linux distributions | (to the extent that this is possible with the C++ ABI, which i am not | especially familiar with). That is correct if you narrowly play by the book, but in the grand scheme of things it is still somewhat silly that among 8k or 9k source packages we do these dances for packages whose 'dependency graph' has one edge and one further package. narrowness doesn't enter into it; package renames due to SONAME bumps are required by policy. Debian Policy Manual Chapter 8 - Shared libraries 8.1 Run-time shared libraries The run-time shared library needs to be placed in a package whose name changes whenever the shared object version changes. in this case it was an upstream bug that the SONAME was not increased, and three packages (mumble, mumble-server, protobuf-c-compiler), not one, were affected. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#556563: protobuf and mumble
Dirk Eddelbuettel wrote: Still just one package: mumble (as mumble and mumble-server come from the same source package, hence count as one, and protobuf-c-compiler comes from protobuf itself and counts as zero leaving exactly one package -- mumble). protobuf-c-compiler is built from the protobuf-c source package, which build-depends on the binary packages libprotobuf-dev, libprotoc-dev, protobuf-compiler, which are built from the protobuf source package. protobuf-c-compiler has runtime dependencies on libprotobufN and libprotocN. iustin pop is the protobuf package maintainer and i am the protobuf-c package maintainer. two source packages and three binary packages are affected by #556563. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#556785: ncap: installs files into /usr/local for Python = 2.6
Jakub Wilk wrote: Starting from Python 2.6, the installation paths for distutils have changed. /usr/local is now used by default. huh, ok. that sounds like it will break a lot of packages. The attached patch fixes this problem. However, please consider also switching from python-central to python-support: http://wiki.debian.org/DebianPython/central2support wow, i wonder if debian will ever have a stable method of building python packages. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491537: RM: vmware-package -- RoQA: May contain undistributable files
Mark Hymers wrote: Could you please clarify the debian/copyright file or confirm that the package should be removed if you're no longer interested. i would prefer that vmware-package be removed from the archive. newer versions of vmware products are more difficult to package, and i don't have much incentive to spend time on packaging non-free software as i now use kvm for my virtualization needs. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547956: libgoogle-perftools0 library package includes command line utility
Package: libgoogle-perftools0 Version: 1.4-1 Severity: serious libgoogle-perftools0 contains the command line profiling utility, /usr/bin/google-pprof: $ dpkg-deb -c libgoogle-perftools0_1.4-1_amd64.deb | grep usr/bin/ drwxr-xr-x root/root 0 2009-09-18 11:25 ./usr/bin/ -rwxr-xr-x root/root128341 2009-09-18 11:25 ./usr/bin/google-pprof $ per debian policy 8.2, this is not allowed: 8.2 Shared library support files If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#547546: kernel BUG at net/ipv6/ip6_output.c:699
Package: linux-image-2.6.18-6-mckinley Version: 2.6.18.dfsg.1-24etch3 hi, i've encountered a problem with BIND9 running on oldstable. we're running native IPv6 and serving DNSSEC-signed zones, so the problem appears to be related to IPv6/UDP fragmentation. when the problem manifests itself the named process stops serving DNS requests and the process becomes unkillable. i am fairly certain that this is the same bug: http://www.mail-archive.com/net...@vger.kernel.org/msg21249.html in particular, see: http://www.mail-archive.com/net...@vger.kernel.org/msg23619.html the bug fix (132a55f3c5c0b1a364d32f65595ad8838c30a60e) was merged to 2.6.19 but never added to 2.6.18. it would probably be a good idea to add this fix in an oldstable kernel update. here is the BUG() dmesg output: kernel BUG at net/ipv6/ip6_output.c:699! named[1992]: bugcheck! 0 [1] Modules linked in: button xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables dm_snapshot dm_mirror dm_mod ipv6 loop shpchp pci_hotplug ext3 jbd mbcache ide_cd cdrom generic mptspi mptscsih ohci_hcd ehci_hcd mptbase cmd64x cciss scsi_transport_spi usbcore ide_core scsi_mod e1000 thermal processor fan Pid: 1992, CPU 0, comm:named psr : 101008526030 ifs : 8916 ip : [a00204195ee0]Not tainted ip is at ip6_output+0x5e0/0x1400 [ipv6] unat: pfs : 0916 rsc : 0003 rnat: bsps: pr : 00569959 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a00204195ee0 b6 : a001000b30a0 b7 : a00100283c40 f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf f8 : 1003e04e2 f9 : 1003e0fa0 f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db r1 : a001008db0e0 r2 : 41c8 r3 : a0010068cf38 r8 : 002c r9 : r10 : a001006f3350 r11 : 4000 r12 : e040f9117aa0 r13 : e040f911 r14 : 4000 r15 : a0010068cf38 r16 : a0010068cf40 r17 : 4000 r18 : e040f9110fd4 r19 : r20 : r21 : r22 : 0004 r23 : r24 : e040f9110fd4 r25 : 0750 r26 : 0730 r27 : 0073 r28 : 0073 r29 : 0027ffd8 r30 : 0027ffd8 r31 : 27d8 Call Trace: [a00100012f20] show_stack+0x40/0xa0 sp=e040f9117630 bsp=e040f9111608 [a00100013820] show_regs+0x840/0x880 sp=e040f9117800 bsp=e040f91115a8 [a00100034420] die+0x1c0/0x2c0 sp=e040f9117800 bsp=e040f9111560 [a00100034570] die_if_kernel+0x50/0x80 sp=e040f9117820 bsp=e040f9111530 [a00100035cb0] ia64_bad_break+0x270/0x4a0 sp=e040f9117820 bsp=e040f9111508 [a001bc40] ia64_leave_kernel+0x0/0x280 sp=e040f91178d0 bsp=e040f9111508 [a00204195ee0] ip6_output+0x5e0/0x1400 [ipv6] sp=e040f9117aa0 bsp=e040f9111458 [a002041979c0] ip6_push_pending_frames+0x940/0xb80 [ipv6] sp=e040f9117ab0 bsp=e040f9111408 [a002041c59e0] udp_v6_push_pending_frames+0x6a0/0x700 [ipv6] sp=e040f9117ae0 bsp=e040f91113b8 [a002041c8ad0] udpv6_sendmsg+0xed0/0x14a0 [ipv6] sp=e040f9117ae0 bsp=e040f9111330 [a0010047b810] inet_sendmsg+0xd0/0x100 sp=e040f9117b60 bsp=e040f91112f8 [a001003add70] sock_sendmsg+0x1f0/0x240 sp=e040f9117b60 bsp=e040f91112c0 [a001003b2960] sys_sendmsg+0x4a0/0x5a0 sp=e040f9117cc0 bsp=e040f9111228 [a001baa0] ia64_ret_from_syscall+0x0/0x20 sp=e040f9117e30 bsp=e040f9111228 [a0010620] __start_ivt_text+0x00010620/0x400 sp=e040f9118000 bsp=e040f9111228 -- Robert Edmonds edmo...@debian.org From 132a55f3c5c0b1a364d32f65595ad8838c30a60e Mon Sep 17 00:00:00 2001 From: Herbert Xu herb...@gondor.apana.org.au Date: Tue, 3 Oct 2006 14:34:00 -0700 Subject: [PATCH] [UDP6]: Fix flowi clobbering The udp6_sendmsg function uses a shared buffer to store the flow without taking any locks. This leads to races with SMP. This patch moves the flowi object onto the stack. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au Acked-by: James Morris jmor...@namei.org Signed-off-by: David S. Miller da...@davemloft.net --- net/ipv6/udp.c | 62 1 files changed, 31
Bug#547612: ITP: nmsg -- network message encapsulation library and toolkit
Package: wnpp Owner: Robert S. Edmonds edmo...@debian.org Severity: wishlist * Package name: nmsg Version : 0.3.1 Upstream Author : Internet Systems Consortium, Inc. * URL : https://sie.isc.org/ * License : ISC Programming Lang: C Description : network message encapsulation library and toolkit i'll write a long description later. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#545791: ITP: ncap -- Network Capture Library and Tools
hello, ondrej: as the upstream maintainer for ncap i'd prefer to package this myself. i have packages that are almost ready (and have been tested internally) except for filling out the package descriptions and copyright file. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#508053: please provide 'host'
martin f krafft wrote: I completely agree, unbound-host should replace/conflict host (which is being removed) and bind9-host, or there should be an alternatives entry coordinated between the various maintainers. unbound-host isn't an alternative or replacement for bind9-host, IMO. one is a command line interface to a recursive DNS lookup library and one is a command line interface to an iterative DNS lookup library. i use both of them for different purposes, so i don't think unbound packages will ever conflict with bind9 packages. what exactly would be the use case for an alternatives entry for 'host'? if the use case is 'query a recursive DNS server for a record' then bind9-host and dnsqr from the djbdns package fit that description. if the use case is 'lookup a DNS record and print it like bind9-host does' then bind9-host and unbound-host fit that description. and 'reimplementation' probably isn't the right word to use in the package description. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: debian-installer: network may not be usable as soon as link is up
Package: debian-installer Version: 20090123lenny1 hi, the debian-installer seems to assume that the network is usable as soon as the link comes up, which may not be the case if the 802.1d spanning tree protocol is in use, in which case it can be up to ~30 seconds before the switch port will forward ethernet frames. i've noticed that trying to preseed a network install on a machine attached to an STP-enabled switch usually fails since as soon as the network link is up, d-i attempts to perform a reverse DNS lookup and fetch the preseed.cfg file via HTTP, both of which timeout and fail before the switch port the machine is attached to enters the forwarding state. a nice strategy to detect if the network is usable might be to send ARP requests for the default gateway's IP address and consider the network up only after the default gateway is reachable. it looks like there is a busybox version of the arping utility that could help accomplish this. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#537271: debian-installer: network may not be usable as soon as link is up
Christian Perrier wrote: Quoting Robert Edmonds (edmo...@debian.org): a nice strategy to detect if the network is usable might be to send ARP requests for the default gateway's IP address and consider the network up only after the default gateway is reachable. it looks like there is a busybox version of the arping utility that could help accomplish this. Ready to implement this in netcfg? :-) maybe. it's python, right? where is the trunk? PS: that would probably need some debconf stuff to implement a dialog saying something like Waiting for the network link and some sort of error message if the default gateway doesn't respond after a long time. and it would have to be conditional on a default gateway being configured. i guess there is a pathological case where you could do a net install with servers that are all on the local network. I'd suggest to add such a detection *after* the first attempt to use the network fails... why? it's not optional for the gateway router to ignore ARP (unlike ICMP echo), or else it couldn't function as a router, so the check must succeed 100% of the time. and the attempts to use the network could fail for other reasons. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#535396: ITP: wrapsrv -- DNS SRV record command line wrapper
Package: wnpp Owner: Robert S. Edmonds edmo...@debian.org Severity: wishlist * Package name: wrapsrv Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : ftp://ftp.isc.org/isc/toolmakers/wrapsrv/ * License : ISC Programming Lang: C Description : DNS SRV record command line wrapper wrapsrv adds support for connecting to a network service based on DNS SRV record lookups to commands that do not support the DNS SRV record. wrapsrv implements the weighted priority client connection algorithm in RFC 2782. The specified command line will be invoked one or more times with %h and %p sequences in the command line substituted for the hostname and port elements of the selected SRV record. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#515307: ITP: gvpe
hi, what's the status of this ITP? -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#417136: openssh-server: nothing logged for failed pubkey auth for valid users at default loglevel
Package: openssh-server Version: 1:5.1p1-6 sshd now appears to log absolutely nothing at all when pubkey authentication fails for a valid user. only when LogLevel is increased from the default INFO to VERBOSE level does sshd log the failure, e.g.: Jun 18 01:36:51 xxx sshd[9811]: Connection from [ip] port 38189 Jun 18 01:36:52 xxx sshd[9811]: Failed publickey for [valid username] from [ip] port 38189 ssh2 this seems rather important after DSA 1576. i would think that the Failed publickey for [valid username] message would at least be logged at default LogLevel. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#527985: ITP: libbind -- DNS resolver and message parsing library
Florian Weimer wrote: * Robert Edmonds: libbind contains the standard resolver library that was distributed in BIND9 prior to version 9.6. Included are functions that communicate with domain name servers, AFAICT, libbind doesn't use source port randomization. The PRNG for transaction IDs is rather curious (but does work around the fork problem to some extent). libbind and glibc's stub resolver are descended from the same code base, so a fix to one could likely be ported to the other. if a fix were coded and BSD licensed it could probably be applied upstream. (e.g., we have arc4random available through libbsd.) however, the kernels in lenny and sid should be randomizing UDP source ports anyway, right? i mainly intended to package libbind for its message parsing functions, though. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#528147: ITP: protobuf-c -- protocol buffers C compiler
Package: wnpp Owner: Robert S. Edmonds edmo...@debian.org Severity: wishlist * Package name: protobuf-c Version : 0.10 Upstream Author : Dave Benson * URL : http://protobuf-c.googlecode.com/ * License : Apache 2.0 Programming Lang: C, C++ Description : protocol buffers C compiler Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the old format. . This is the C implementation of protocol buffers. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#527985: ITP: libbind -- DNS resolver and message parsing library
Package: wnpp Owner: Robert S. Edmonds edmo...@debian.org Severity: wishlist * Package name: libbind Version : 6.0 Upstream Author : Internet Systems Consortium, Inc. * URL : https://www.isc.org/software/libbind * License : ISC Programming Lang: C Description : DNS resolver and message parsing library libbind contains the standard resolver library that was distributed in BIND9 prior to version 9.6. Included are functions that communicate with domain name servers, parse DNS messages, retrieve network host entries from /etc/hosts or via DNS, convert CIDR network addresses, perform Hesiod information lookups, retrieve network entries from /etc/networks, implement TSIG transaction/request security of DNS messages, perform name-to-address and address-to-name translations, and use /etc/resolv.conf for resolver configuration. . note that the bind9 source package already ships a libbind-dev package which is unrelated to libbind. i will probably embed the SONAME version in the -dev package name for libbind to avoid conflicting with the bind9 package. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#423458: ITP: dnscap -- DNS traffic capture utility
Runa Sandvik wrote: What is the status on this ITP? hi, dnscap depends on libbind (not libbind9) to produce meaningful output. this was included in BIND9 up until the 9.5 release, but not enabled in the debian bind9 package, and anyway unstable now has BIND9 9.6 which removed libbind entirely. libbind is now available as a separate product from ISC, which i plan to file an ITP for if the BIND9 maintainer (Cc'd) is not interested in packaging it. (and unfortunately the bind9 source package ships a binary package called libbind-dev which will need to be worked around somehow.) additionally, glibc 2.7's libresolv.so as shipped in lenny does not allow linking against the symbols dnscap needs (ns_initparse() et al), but as of (i believe) glibc 2.9-2, i think this was relaxed: glibc (2.9-2) unstable; urgency=low [...] * debhelper.in/*symbols*, rules.d/debhelper.mk: allow linking against private symbols again, but with a strict dependency on the upstream version. [...] -- Aurelien Jarno aure...@debian.org Fri, 20 Feb 2009 22:25:19 +0100 (see also #291609) i need to do some more testing to see how stable this is (and it would certainly seem to make backports much more difficult) but i'll probably have to use libbind, as i have in mind packaging other software which may depend on newer versions of libbind. (the glibc libresolv.so is a fork of a much earlier version of the code now available in libbind.) also note that my employer (ISC) is the upstream for the software (dnscap, libbind, BIND9) mentioned in this email. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#523992: libprotobuf3 is packaged incorrectly
Package: protobuf
Severity: normal
the protobuf package should not do this:
Package: libprotobuf3
Conflicts: libprotobuf0, libprotobuf2
Replaces: libprotobuf0, libprotobuf2
libprotobuf3 cannot conflict with libprotobuf2 as they share no files in
common.
edmo...@chase{0}:~$ dpkg -L libprotobuf3 | sort
/.
/usr
/usr/lib
/usr/lib/libprotobuf.so.3
/usr/lib/libprotobuf.so.3.0.0
/usr/lib/libprotoc.so.3
/usr/lib/libprotoc.so.3.0.0
/usr/share
/usr/share/doc
/usr/share/doc/libprotobuf3
/usr/share/doc/libprotobuf3/changelog.Debian.gz
/usr/share/doc/libprotobuf3/changelog.gz
/usr/share/doc/libprotobuf3/copyright
edmo...@chase{0}:~$ apt-file show libprotobuf2
libprotobuf2: /usr/lib/libprotobuf.so.2
libprotobuf2: /usr/lib/libprotobuf.so.2.0.0
libprotobuf2: /usr/lib/libprotoc.so.0
libprotobuf2: /usr/lib/libprotoc.so.0.0.0
libprotobuf2: /usr/share/doc/libprotobuf2/changelog.Debian.gz
libprotobuf2: /usr/share/doc/libprotobuf2/changelog.gz
libprotobuf2: /usr/share/doc/libprotobuf2/copyright
edmo...@chase{0}:~$
and libprotobuf3 cannot replace libprotobuf2 as the libraries have
different SONAMEs. this is the whole point of a SONAME.
furthermore, conflicting and replacing with old versions of your library
package completely breaks orderly transitions. fortunately, there are
no reverse dependencies on libprotobufN outside of the protobuf source
package.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Robert Edmonds
edmo...@debian.org
signature.asc
Description: Digital signature
Bug#523992: libprotobuf3 is packaged incorrectly
your M-F-T is broken, followups to an existing bug report should not also be sent to sub...@. Mail-Followup-To: Robert Edmonds edmo...@debian.org, 523...@bugs.debian.org, Debian Bug Tracking System sub...@bugs.debian.org Iustin Pop wrote: Unless upstream is not consistent in bumping the SONAME, see below. I agree that libprotobuf3/libprotobuf2 have no files in common, however this was not the case for the libprotobuf2/libprotobuf0 case, where they had in common libprotoc.so.0/libprotoc.so.0.0.0; upstream has not been very consistent in declaring the SONAME. i see nothing inconsistent in upstream's SONAMEs. the history of upstream's -version-info parameters is as follows: * in r2, libprotobuf and libprotoc were imported with -version-info 0:0:0. * in r46, libprotobuf was bumped from 0:0:0 to 2:0:0. * in r79, libprotobuf was bumped from 2:0:0 to 3:0:0. * in r79, libprotoc was bumped from 0:0:0 to 3:0:0. * in tags/release-2.0.1, libprotobuf and libprotoc were set to -version-info 0:0:0. * in tags/release-2.0.2, libprotobuf was set to 2:0:0. * in tags/release-2.0.2, libprotoc was set to 0:0:0. * in tags/2.0.3, libprotobuf was set to 3:0:0. * in tags/2.0.3, libprotoc was set to 3:0:0. i haven't checked to see if the libprotoc 0:0:0 in the 2.0.2 release is really compatible with the libprotoc 0:0:0 in the 2.0.1. the only strange thing is perhaps that the ABIs are being broken on almost every release. perhaps this is because the libraries are written in C++. For libprotobuf3, just removing the conflicts (no files in common) and replaces (not same SONAME) will be OK, but if upstream ever does a mixed (libprotobuf bumped SONAME, libprotoc same SONAME) release again, these two libraries will have to be split, right? libprotobuf and libprotoc are separate libraries and should be in separate packages. you should read the debian library packaging guide. in particular, it says: There are packages like libc6, which contain multiple shared libraries in one package. This is not encouraged. [2] It becomes more complex and more difficult to handle complex upgrade patterns. bug#141275, omniorb package contained several different libraries with different SONAME version numbering policies. There has been a history of packages which were named with the source package name, but it is better practice to name the package according to the library name, for consistency. Some old packages are not named this way, such as aalib-dev, but new packages should follow the scheme of using the library SONAME. For an example of a package which migrated from single-package library file, see xlibs. xlibs in Debian 3.0 was one package containing many shared libraries, and it is split into multiple packages in later releases of Debian. [2] This is the case unless it is confident that shared libraries will not change interfaces independently, or compatibility issues are carefully handled. In general, when shared libraries are split, there is no reason upstream will keep changes to interfaces synchronised. based on the fact that upstream skipped a few current interface numbers (0-2 and 0-3) they may be trying to somehow synchronize the current number with the release (2.0.2, 2.0.3). but this is not guaranteed to always be the case and they will probably stop if they release a version = 2.1. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#523992: libprotobuf3 is packaged incorrectly
Iustin Pop wrote: The main reason I chosed to have a single library package was to not have too many small packages, and per the above thread, upstream intends to keep them in sync. Also, libprotoc is/should only be used by the protobuf compiler, and not by external users, so I thought shipping it in the libprotobufX package is fine. libprotoc is used by the protobuf-c compiler, protoc-c. protobuf-c is not (yet) in debian. As far as I can understand, your point is that upstream is never guaranteed to do so, and in order to prevent future problems it's better to split the packages? I also see other library packages providing multiple libraries (e.g. libssl0.9.8), so how hard is this rule? it is not a particularly hard rule but the trend in debian has been towards less aggregation in library packages, not more. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523992: how did libprotobuf3 make it past NEW?
Vincent Bernat wrote: I don't see exactly what point you try to make here. From a technical point of view, I see some advantages to handle this minor upgrade in the same way as an ABI transition (the strongest one being to ensure that the old packages do not lie around). this is not exactly the same as an ABI transition because the new library package cannot be simultaneously installed with the previous SONAME of the library package, potentially breaking locally compiled binaries that link against the old SONAME or making packages that depend on libprotobuf2 or libprotobuf3 mutually uninstallable. one of the strengths of debian is that multiple SONAMEs of the same library can be simultaneously installed, effecting smooth upgrades. This can be of course discussed but I don't see exactly the point to discuss it outside of the bug report, with the sponsor and ftpmasters. And I don't see what exactly is the contribution of saying that it is severely brain-damaged. Will you yell at ftpmasters/mentors each time you see that a package is not perfect? i said severely brain-damaged (perhaps this is too strong a phrase given the paucity of rdeps; if e.g. protobuf-c-compiler were in the archive this change would have made it uninstallable simultaneously with protobuf-compiler) because it defeats the entire point of adding the SONAME major version to binary library package names. i hope this is merely an oversight caused by overwork / haste rather than a trend. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509966: x11-xserver-utils: iceauth fails with non-ASCII characters in hostname
Package: x11-xserver-utils Version: 7.3+5 Tags: patch, upstream if the system's hostname contains non-ASCII characters, iceauth will fail, typically with something like 'bad add command line'. please apply the attached patch, which removes the extraneous isascii() check in the skip_nonspace() function. -- Robert Edmonds edmo...@debian.org --- x11-xserver-utils-7.3+5/iceauth/process.c.orig 2008-12-27 21:07:51.376933195 -0500 +++ x11-xserver-utils-7.3+5/iceauth/process.c 2008-12-27 21:09:49.660932536 -0500 @@ -269,7 +269,7 @@ static char *skip_nonspace (register cha if (!s) return NULL; /* put quoting into loop if need be */ -for ( ; *s isascii(*s) !isspace(*s); s++) +for ( ; *s !isspace(*s); s++) ; return s; } signature.asc Description: Digital signature
Bug#509060: unbound: fix lintian warning and tweak watch file to easy update
Hideki Yamane (Debian-JP) wrote: Here's a patch to fix lintian warning and update watch file. Could you apply it, please? what specific problems does this patch fix? -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#500176: Going to NMU (#500176: other daemons prevent successful installation)
Ondřej Surý wrote: Here is the patch used for NMU. please upload -1.2 fixing #508884. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#500176: Going to NMU (#500176: other daemons prevent successful installation)
Hideki Yamane wrote: Here is updated (and missing $UNBOUND_CONFIG_FILE is fixed) version patch. NAME=unbound +UNBOUND_CONFIG_FILE=/etc/$NAME.conf the unbound config file is /etc/unbound/unbound.conf. did you even test this? -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#500176: Going to NMU (#500176: other daemons prevent successful installation)
Ondřej Surý wrote: since you are obviously online now... do you want to make regular release or you are just fine with my NMU? i am fine with NMUs so long as they don't break anything. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#508053: Any reason for not providing host?
Michal Čihař wrote: is there any particular reason why unbound-host does not provide host binary in a same way that bind9-host? why should it? -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500176: closed by Robert Edmonds [EMAIL PROTECTED] (Re: Bug#500176: It does not conflicts with bind and other ns daemons)
Francesco P. Lovergine wrote: At least in three cases (ftpd, httpd, radius, telnetd) currently is used a virtual package. So probably it is the most appropriate choice in respect with current policy. there are two protocol speaking over 53/udp; the recursive service (rd==1) offered by recursors to stub resolvers, and the authoritative service (rd==0) offered by authorities to recursors. bind provides both implementations in a single process image in a single package. stub clients (dig, nslookup, etc) are provided in a separate 'dnsutils' package. powerdns provides both implementations in separate process images in separate packages. powerdns does not provide any stub clients. djbdns provides both implementations in separate process images in a single package. stub clients (dnsip, dnsname, etc) are provided in the same package. unbound only provides an implementation of the rd==1 service. a stub client (unbound-host) is provided in a separate package. nsd/nsd3 only provides an implementation of the rd==0 service. this diversity is approximately comparable to the diversity of packages providing the httpd virtual package. and no packages providing httpd conflict with httpd. as there are no packages in the archive which have a requirement for a locally installed authoritative or recursive dns server, there is no need for a virtual package. The point is that with the *default* configuration unbound does not complete the installation when another name server is installed. And this could be considered a serious bug. ok. you would prefer that the unbound postinst script ignore invoke-rc.d errors? -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#492243: unbound: fails to install/configure
severity 492243 serious thanks Teodor wrote: On Wed, Jul 30, 2008 at 9:37 AM, Robert Edmonds [EMAIL PROTECTED] wrote: please send contents of /etc/unbound/* and /etc/default/unbound. did you newly install unbound or upgrade? This is a fresh install: piti:~# dpkg --configure -a Setting up unbound (1.0.1-1) ... Starting recursive DNS server: unbound[1217412804] unbound[5618:0] warning: IPv6 protocol not available [1217412804] unbound[5618:0] fatal error: Could not chdir to /etc/unbound: No such file or directory failed! invoke-rc.d: initscript unbound, action start failed. dpkg: error processing unbound (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: unbound ok, i've reproduced this. i will have it fixed shortly. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492243: unbound: fails to install/configure
Paul Walker wrote: I just tried to install unbound, and it fails to complete configuration, complaining that /etc/unbound doesn't exist (even though it appears to). The package info says unbound is installed in a chroot; possibly the directory isn't created in the chroot? please send contents of /etc/unbound/* and /etc/default/unbound. did you newly install unbound or upgrade? -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447
Ian Jackson wrote: [snip] this seems mostly reasonable to me and this mirrors the recommendation in DSA-1605-1. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#492465: python-dnspython: appears to be vulnerable to cache poisoning attack CVE-2008-1447
[ i am CC'ing the upstream author, Bob Halley. Bob, are you planning a fix to bring dnspython in line with forgery-resilience? ] Thijs Kinkhorst wrote: severity 492465 important thanks Hi Robert, On Monday 28 July 2008 07:27, Robert Edmonds wrote: python-dnspython isn't a dns cache. it may be susceptible to forgery resilience issues though. the qid field is explicitly randomized (but with the standard library rng). Yes - as I understand it, a caching server makes forgery much more worthwhile but given that it's a lot easier to forge a response, even stub resolvers could be targeted successfully. right. For reference, DSA 1605 is about the (unfixed) glibc stub resolver: http://www.debian.org/security/2008/dsa-1605 i saw that, and the same mitigation technique will work. Could you please look into this and see whether updated packages can and should be created for etch/lenny/sid? from my testing (by repeatedly calling dns.resolver.query), dnspython opens a new socket for each query. on my kernel (2.6.25) the source port numbers appear to be random, but maybe this is a kernel feature introduced since 2.6.18. Yes, that's probably the kernel feature. do you know when the linux kernel added ephemeral port randomization? i looked, but could not find it. does the 'etchnhalf' kernel support it? dnspython is a stub resolver, and not a general purpose one at that; i would prefer to wait for upstream to provide an updated version. Surely a solution from upstream is preferable. Given that: (a) this lib is very specialised and is a stub resolver; (b) kernels in lenny/sid already randomise ports and (c) it reopens a port for each query, I've downgraded it to important. Still, I believe that it's very much desirable to make sure an updated version enters lenny. It is my understanding that fixes for 'important' bugs can get a freeze exception. If we have a clear fix for etch I think we should release it to be safe rather than sorry. btw, i have another specialized dns package in the archive (adns). do you know if it needs forgery resilience? From checking the source code I think it has the same issue as here. I'll file an important bug there too. cheers, Thijs -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447
[ CC'ing Ian. ] Ian, are you planning a fix for this? the relevant recommendations, btw, are available in an ietf draft rfc: http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience Thijs Kinkhorst wrote: Package: adns Version: 1.4-0.1 Severity: important Tags: security Hi, From inspecting the code of ands, it seems that it is not using the recommended source port randomisation for countering the cache poisoning attack as discovered by Dan Kaminski and referenced as CVE-2008-1447. Since this is a stub resolver the risk is lesser than for caching nameservers, but nonetheless this is an issue which we really should be fixing in lenny. Can you please look into that? As it seems a fix for important bugs can still be granted a freeze exception. If a straghtforward fix is available for etch, it would be released by the security team. thanks, Thijs -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#492465: python-dnspython: appears to be vulnerable to cache poisoning attack CVE-2008-1447
Thijs Kinkhorst wrote: Package: python-dnspython Version: 1.3.5-3.1 1.6.0-1 Severity: grave Tags: security Hi, From inspecting the code of dnspython, it seems that it is not using the recommended source port randomisation for countering the cache poisoning attack as discovered by Dan Kaminski and referenced as CVE-2008-1447. python-dnspython isn't a dns cache. it may be susceptible to forgery resilience issues though. the qid field is explicitly randomized (but with the standard library rng). Could you please look into this and see whether updated packages can and should be created for etch/lenny/sid? from my testing (by repeatedly calling dns.resolver.query), dnspython opens a new socket for each query. on my kernel (2.6.25) the source port numbers appear to be random, but maybe this is a kernel feature introduced since 2.6.18. dnspython is a stub resolver, and not a general purpose one at that; i would prefer to wait for upstream to provide an updated version. btw, i have another specialized dns package in the archive (adns). do you know if it needs forgery resilience? -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#492145: Bug#490764: adns-tools should provide compatibility
Ian Jackson wrote: I would like ideally to improve both packages. So with the adns maintainer's and release managers' permission I would like to push a new version of adns which also `Provides: libadns1-bin'. please NMU if necessary. i am completely tied up with (other) dns issues right now. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#491488: autopkgtest-xenlvm: depends on libadns1-bin
Package: autopkgtest-xenlvm Version: 1.0.8 hi, Ian: this package is preventing adns 1.4-1 from migrating to testing since it depends on libadns1-bin. it should instead depend on adns-tools. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#491489: sauce: depends on libadns1-bin
Package: sauce Version: 0.9.0 hi, Ian: this package is preventing adns 1.4-1 from migrating to testing since it depends on libadns1-bin. it should instead depend on adns-tools. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#491509: vmware-package: please keep it out of lenny
Package: vmware-package Severity: grave thanks. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#489297: valgrind: the 'impossible' happened: VG_(arena_memalign)
Package: valgrind
Version: 1:3.3.1-2
Severity: important
valgrind is incapable of debugging programs which use memalign(3) to
allocate aligned memory blocks = 2 MB in size:
[EMAIL PROTECTED]:~/code/test$ cat memalign.c
#include stdlib.h
#define size (1 21)
int main(void) {
void *ptr;
posix_memalign(ptr, size, size);
free(ptr);
return 0;
}
[EMAIL PROTECTED]:~/code/test$ gcc -O0 -ggdb -Wall -o memalign memalign.c
[EMAIL PROTECTED]:~/code/test$ valgrind ./memalign
==31507== Memcheck, a memory error detector.
==31507== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==31507== Using LibVEX rev 1854, a library for dynamic binary translation.
==31507== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==31507== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==31507== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==31507== For more details, rerun with: -v
==31507==
VG_(arena_memalign)(0x3879AB60, 2097152, 2097152)
bad alignment
valgrind: the 'impossible' happened:
VG_(arena_memalign)
==31507==at 0x380194CC: report_and_quit (m_libcassert.c:140)
==31507==by 0x380195E4: panic (m_libcassert.c:210)
==31507==by 0x38019652: vgPlain_core_panic_at (m_libcassert.c:215)
==31507==by 0x38019671: vgPlain_core_panic (m_libcassert.c:220)
==31507==by 0x380228BE: vgPlain_arena_memalign (m_mallocfree.c:1392)
==31507==by 0x38002909: vgMemCheck_new_block (mc_malloc_wrappers.c:195)
==31507==by 0x38002BEA: vgMemCheck_memalign (mc_malloc_wrappers.c:259)
==31507==by 0x38033F08: vgPlain_scheduler (scheduler.c:1277)
==31507==by 0x380448D3: run_a_thread_NORETURN (syswrap-linux.c:89)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==31507==at 0x4C1FFCF: memalign (vg_replace_malloc.c:460)
==31507==by 0x4C20068: posix_memalign (vg_replace_malloc.c:569)
==31507==by 0x400536: main (memalign.c:7)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
[EMAIL PROTECTED]:~/code/test$
there is a check in coregrind/m_mallocfree.c:1385 which reads,
// Check that the requested alignment seems reasonable; that is, is
// a power of 2.
if (req_alignB VG_MIN_MALLOC_SZB
|| req_alignB 1048576
|| VG_(log2)( req_alignB ) == -1 /* not a power of 2 */) {
VG_(printf)(VG_(arena_memalign)(%p, %lu, %lu)\nbad alignment,
a, req_alignB, req_pszB );
VG_(core_panic)(VG_(arena_memalign));
/*NOTREACHED*/
}
the comment or the code is wrong, as there are certainly powers of 2
larger than 1048576.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages valgrind depends on:
ii libc6 2.7-12 GNU C Library: Shared libraries
Versions of packages valgrind recommends:
ii gdb 6.8-3 The GNU Debugger
-- no debconf information
--
Robert Edmonds
[EMAIL PROTECTED]
signature.asc
Description: Digital signature
Bug#486303: unbound stops syslogging after logfile rotation
Craig Sanders wrote:
Package: unbound
Version: 1.0.0-2
when unbound is configured to log stats to syslog, it stops logging
whenever the logfile is rotated.
hi, Craig,
thanks for the excellent bug report.
my guess is that this is probably due to the chroot jail that unbound is
running in. specifically, something to do with the syslog daemon being
reloaded (and closing/re-opening all files) rather than the specific log
file being rotated, because both /var/log/syslog and /var/log/daemon.log
were affected (i.e. no unbound entries after rsyslog reload). syslog is
rotated daily, daemon.log is rotated weekely.
note: i am using rsyslog rather than sysklogd, but i doubt if that is a
relevant factor...i've been running rsyslog for many months now and it
has proven to be 100% backwards compatible with sysklogd. unbound is the
only program that exhibits this behaviour. unfortunately, i don't have
any sysklogd machines left to test unbound on.
I can reproduce the problem with sysklogd... I based the debian init
script on the redhat one provided in the unbound tarball, which
bindmounts /dev/log to /var/lib/unbound/dev/log. unfortunately since
/dev/log is a unix socket, it disappears and is recreated when the
syslog daemon is restarted, and the bindmount follows the inode rather
than the directory path.
just to verify, could you send the output of `stat /dev/log
/var/lib/unbound/dev/log | grep Inode` before and after a restart of
unbound? it probably looks something like this:
[EMAIL PROTECTED]:~# stat /dev/log /var/lib/unbound/dev/log | grep Inode
Device: eh/14d Inode: 7916330 Links: 1
Device: eh/14d Inode: 2945675 Links: 0
[EMAIL PROTECTED]:~# /etc/init.d/unbound restart
Restarting recursive DNS server: unbound.
[EMAIL PROTECTED]:~# stat /dev/log /var/lib/unbound/dev/log | grep Inode
Device: eh/14d Inode: 7916330 Links: 1
Device: eh/14d Inode: 7916330 Links: 1
[EMAIL PROTECTED]:~#
now, could you please test this solution?
1) /etc/init.d/unbound stop
2) echo $AddUnixListenSocket /var/lib/unbound/dev/log
/etc/rsyslog.d/unbound.conf
3) /etc/init.d/rsyslog restart
4) replace /etc/init.d/unbound with the copy attached to this mail
5) /etc/init.d/unbound start
--
Robert Edmonds
[EMAIL PROTECTED]
#!/bin/sh
NAME=unbound
DESC=recursive DNS server
DAEMON=/usr/sbin/unbound
CHROOT_DIR=/var/lib/unbound
PIDFILE=$CHROOT_DIR/unbound.pid
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
test -f /etc/default/$NAME . /etc/default/$NAME
install_chroot() {
if [ $CHROOT != no ]; then
[ -d $CHROOT_DIR/etc ] || mkdir -p $CHROOT_DIR/etc
[ -d $CHROOT_DIR/dev ] || mkdir -p $CHROOT_DIR/dev
[ -c $CHROOT_DIR/dev/random ] || ( cd $CHROOT_DIR/dev MAKEDEV random
)
[ -c $CHROOT_DIR/dev/urandom ] || ( cd $CHROOT_DIR/dev MAKEDEV
urandom )
#if ! egrep -q '^/[^[:space:]]+[[:space:]]+'$CHROOT_DIR'/dev/log'
/proc/mounts; then
#[ -e $CHROOT_DIR/dev/log ] || touch $CHROOT_DIR/dev/log
#mount --bind -n /dev/log $CHROOT_DIR/dev/log /dev/null 21
#fi
test -f /etc/localtime cp -fp /etc/localtime $CHROOT_DIR/etc
install_chroot_conf
fi
}
install_chroot_conf() {
test -d $CHROOT_DIR/etc/unbound rm -rf $CHROOT_DIR/etc/unbound
cp -a /etc/unbound $CHROOT_DIR/etc
}
uninstall_chroot() {
test -d $CHROOT_DIR/etc/unbound rm -rf $CHROOT_DIR/etc/unbound
#if [ $CHROOT != no ]; then
#while egrep -q '^[^[:space:]]+[[:space:]]+'$CHROOT_DIR'/dev/log'
/proc/mounts; do
#umount $CHROOT_DIR/dev/log /dev/null 21
#done
#fi
}
already_running() {
return start-stop-daemon --start --pidfile $PIDFILE \
--startas $DAEMON --test /dev/null 21
}
case $1 in
start)
log_daemon_msg Starting $DESC $NAME
if ! already_running; then
install_chroot
fi
if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name
$NAME --startas $DAEMON -- $DAEMON_OPTS; then
log_end_msg 0
else
log_end_msg 1
fi
;;
stop)
log_daemon_msg Stopping $DESC $NAME
if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name
$NAME; then
log_end_msg 0
else
log_end_msg 1
fi
uninstall_chroot
;;
restart|force-reload)
log_daemon_msg Restarting $DESC $NAME
start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME
--retry 5
uninstall_chroot
install_chroot
if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name
$NAME --startas $DAEMON -- $DAEMON_OPTS; then
log_end_msg 0
else
log_end_msg 1
fi
;;
*)
N=/etc/init.d/$NAME
echo Usage: $N {start|stop|restart|force-reload} 2
exit 1
;;
esac
### BEGIN INIT INFO
# Provides: unbound
Bug#486004: ITA: net-tools -- The NET-3 networking toolkit
retitle 486004 ITA: net-tools -- The NET-3 networking toolkit owner 486004 [EMAIL PROTECTED] thanks Hi, Bernd: I would like to adopt this package. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#485995: ITA: adns -- Asynchronous-capable DNS client library and utilities
retitle 485995 ITA: adns -- Asynchronous-capable DNS client library and utilities owner 485995 [EMAIL PROTECTED] thanks Hi, Bernd: I would like to adopt this package. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#485999: ITA: mmv -- Move/Copy/Append/Link multiple files
retitle 485999 ITA: mmv -- Move/Copy/Append/Link multiple files owner 485999 [EMAIL PROTECTED] thanks Hi, Bernd: I would like to adopt this package. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#484491: CVE-2008-2098: buffer overflow allows arbitrary code execution
severity 484491 normal thanks Steffen Joeris wrote: Package: vmware-package Severity: grave Tags: security Justification: user security hole Hi The following CVE[0] has been issued against vmware products. hi, vmware-package is a script which builds .debs from vmware tarballs; even if vmware-package is updated in the debian archive, it is incumbent upon individual sysadmins to download new tarballs from vmware.com and update their installations, since the vmware-package package does not do any automatic downloading/installation (indeed, one can install the generated debs on systems which don't even have vmware-package installed). I will upload a vmware-package with updated hashes for these new point releases shortly; in the mean time, the '-s' option to make-vmpkg will (probably, I haven't tested; but all vmware point releases so far have not introduced changes requiring more advanced updates than updating the hashes at the beginning of the make-vmpkg script) build .debs from the new vmware tarballs. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#482277: ITP: unbound -- validating, recursive, caching DNS resolver
hi,
Pierre Habouzit wrote:
On Wed, May 21, 2008 at 02:58:04PM +, Robert Edmonds wrote:
Package: wnpp
Owner: Robert S. Edmonds [EMAIL PROTECTED]
Severity: wishlist
* Package name: unbound
Version : 1.0.0
Upstream Author : NLnet Labs
* URL : http://libev.schmorp.de/
whoops, looks like I fat fingered the URL when copying from a previous
ITP. that should be http://unbound.net/ of course.
* License : BSD
Programming Lang: C
Description : validating, recursive, caching DNS resolver
Unbound is a validating, recursive, and caching DNS resolver.
.
The C implementation of Unbound is developed and maintained by NLnet
Labs. It is based on ideas and algorithms taken from a java prototype
developed by Verisign labs, Nominet, Kirei and ep.net.
.
Unbound is designed as a set of modular components, so that also DNSSEC
(secure DNS) validation and stub-resolvers (that do not run as a
server, but are linked into an application) are easily possible.
Err I missed that and I happened to just file the same ITP. I'm
already packaging nsd3 from the same authors FWIW, and am really
interested into {co-,}maintaining unbound.
well, I've written a bit of research-quality DNS code (including some
that uses ldns, very nice library) and run a few production recursive /
authoritative DNS servers; I don't think a package team is necessary for
unbound.
--
Robert Edmonds
[EMAIL PROTECTED]
signature.asc
Description: Digital signature
Bug#482277: ITP: unbound -- validating, recursive, caching DNS resolver
Package: wnpp Owner: Robert S. Edmonds [EMAIL PROTECTED] Severity: wishlist * Package name: unbound Version : 1.0.0 Upstream Author : NLnet Labs * URL : http://libev.schmorp.de/ * License : BSD Programming Lang: C Description : validating, recursive, caching DNS resolver Unbound is a validating, recursive, and caching DNS resolver. . The C implementation of Unbound is developed and maintained by NLnet Labs. It is based on ideas and algorithms taken from a java prototype developed by Verisign labs, Nominet, Kirei and ep.net. . Unbound is designed as a set of modular components, so that also DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
