Bug#1032346: dropbear-initramfs: long delay when no network is attached
Package: dropbear-initramfs
Version: 2020.81-3
I am using dropbear-initramfs on a laptop (running debian 11 / stable
with encrypted rootfs). The intention is that most of the time I will
be entering the cryptsetup password from the laptop keyboard, but
occasionally I might connect the laptop to a local network and unlock
it through the dropbear shell. I think this is similar to the b/964187
use case.
In that bug, you noted difficulties with killing ipconfig with
SIGTERM; the resolution (introducing DROPBEAR_SHUTDOWN_TIMEOUT) left a
race when the cryptsetup password is entered on the console while
there is no attached network cable. By default wait_for_dropbear()
will wait 60 seconds for dropbear to start, while
configure_networking() will try for up to
2+3+4+6+9+16+25+36+64+100=265 seconds to initialize the unconnected
interface. That means an undesired 60 second wait, and the race is
still present.
I was wondering why ipconfig did not respond to SIGTERM, and I can not
reproduce this issue (again, using debian 11 here, so this is with
klibc-utils version 2.0.8-6.1).
The diff below seems to avoid the wait and resolve the race as far as I can see:
--- /usr/share/initramfs-tools/scripts/init-bottom/dropbear.orig
2021-01-14 12:14:26.0 -0800
+++ /usr/share/initramfs-tools/scripts/init-bottom/dropbear
2023-03-04 04:18:18.365776747 -0800
@@ -23,25 +23,34 @@
IFDOWN="*"
DROPBEAR_SHUTDOWN_TIMEOUT=60
if [ -e /etc/dropbear/config ]; then
. /etc/dropbear/config
fi
wait_for_dropbear() {
local pid exe timer="$DROPBEAR_SHUTDOWN_TIMEOUT"
pid="$(cat "$PIDFILE" 2>/dev/null)" || return 1
+# XXX tell configure_networking to stop
+touch /run/net-dummy.conf
+
# when configure_networking() is run asynchronously dropbear might
# not have started yet; ipconfig doesn't react to SIGTERM so we wait
# for the network stack to be configured (and dropbear to start)
# rather than terminating the shell and its children
while [ $timer -gt 0 ] && exe="$(readlink -f "/proc/$pid/exe"
2>/dev/null)"; do
+
+# XXX kill ipconfig children
+sed -nr "s/^([0-9]+) \\(ipconfig\\) \\S $pid [0-9]+ .*/\\1/p" \
+/proc/[0-9]*/stat 2>/dev/null | \
+while read pidxxx; do kill -TERM "$pidxxx"; done
+
if [ "$exe" = "$EXE" ]; then
echo "$pid"
return 0
fi
sleep 1
timer=$(( timer - 1 ))
done
return 1
}
Hope this helps,
--
Michel Lespinasse
Bug#987238: bind9: inline signed zone config breaks during package upgrade
On Tue, Apr 20, 2021 at 11:43:12AM +0200, Ondřej Surý wrote: > Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/-/issues/2623 > > Hi Michel, > > the issue will be fixed in the next upstream release (due to next week). > > The overwrite should happen only once on the upgrade to 9.16.12 or 9.16.13, > so you should be safe to restore the symlinks meanwhile. Thanks, and the forwarded isc bug does seem to match my issue. Just one note though, my config does not use the ixfr-from-differences statement; my understanding is that inline signing indirectly triggers the same condition ?
Bug#987238: bind9: inline signed zone config breaks during package upgrade
Package: bind9
Version: 1:9.16.13-1~bpo10+1
I'm running a debian buster system, with a small number of packages
installed from buster-backports, one of them being bind9 (for the
dnssec inline signing / policy enhancements).
I'm using inline dnssec signing for some of my zones:
zone "lespinasse.org" {
type master;
file "/var/lib/bind/db.lespinasse";
dnssec-policy "secure";
};
I have a /etc/bind/db.lespinasse zone file which I manually edit
(with regular, non-dnssec signed entries); within /var/lib/bind9
there is a db.lespinasse symlink pointing to /etc/bind/db.lespinasse,
and there are also db.lespinasse.{jkb,jnl,signed,signed.jnl} files that
are owned and updated by bind9. Overall, this setup lets me edit the
zone as a regular, non-dnssec text file; bind9 then picks it up and updates
it with signed dnssec entries as required.
This worked fine with bind9 version 1:9.16.11-2~bpo10+1, but when
upgrading to 1:9.16.13-1~bpo10+1 the /var/lib/bind9/db.lespinasse
symlink got overwritten and replaced with a bind-written text zone
file. By this, I mean that the file had the same entries as the ones I
configured in the original /etc/bind/db.lespinasse, but with different
formatting and comments removed, as bind9 would normally do when
dealing with dynamic dns zones.
The creation time for the rewritten /var/lib/bind9/db.lespinasse file
matches the package update time in /var/log/dpkg.log, so I know the issue
happened during the update.
In the end, no zone data was lost as I simply had to remove the
rewritten file, restore the desired symlink, and reload bind.
I would like to confirm wether my inline signing setup is supposed to
be a supported configuration, and if so, suggest that a test should be
added to package release scripts so that future package upgrades won't
trigger this issue again ?
-- System Information:
Debian Release: 10.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#981449: dehydrated: certificate specific settings may affect other certificates
Got the fix upstream as commit 527933db2434cc103428e04cf72fdd04c13a06a9 On Mon, Feb 1, 2021 at 6:27 AM Mattia Rizzolo wrote: > > Hi! > > On Sun, Jan 31, 2021 at 05:48:25AM -0800, Michel Lespinasse wrote: > > Dehydrated supports two locations for config settings: > > - The main config file, /etc/dehydrated/config by default > > - Per-certificate config files, i.e. certs/*/config > > > > Settings defined in the per-certificate config files are expected to > > only affect that particular certificate. But, this doesn't seem to be > > the case - in particular, I noticed that PRIVATE_KEY_ROLLOVER was also > > affecting certificates that are processed later in the run. > > > > Looking at the code, I think I found the root cause. > > Could I ask if you'd be willing to forward this issue directly upstream > at https://github.com/dehydrated-io/dehydrated/issues ? > > > The store_configvars() and reset_configvars() are expected to save the > > canonical (as per the global config file) settings and restore them > > before processing each certificate. But, the set of variables that are > > saved by these functions is only a subset of those that can be set in > > per-certificate config files; in particular the OCSP_FETCH, OCSP_DAYS, > > and PRIVATE_KEY_ROLLOVER settings are missing. > > So, only from reading your report, this might be as trivial as you say. > If you tried to patch it and it works you might as well also propose > this in the form of a merge request in the above github repository :) > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#981548: bind9: undesired dnssec KSK key rotation
As suggested here, I filed the issue with ISC as https://gitlab.isc.org/isc-projects/bind9/-/issues/2463
Bug#981548: bind9: undesired dnssec KSK key rotation
Package: bind9
Version: 1:9.16.11-2~bpo10+1
I'm running a debian buster system, with a small number of packages
installed from buster-backports, one of them being bind9 (for the
dnssec inline signing / policy enhancements).
My setup seemed to work fine with bind9 version 1:9.16.8-1~bpo10+1 ,
but as I updated to version 1:9.16.11-2~bpo10+1 today, something went
wrong and one of my zones kept being assigned a new KSK every time
bind9 gets restarted or reloaded. That is quite a bummer because
KSK rotations are not fully automated, and my dnssec policy specifically
asks for the KSK not to be rotated.
After some investigation I was able to make a guess that the issue seems to
be triggered by having two zones with identical names in separate views:
- in my "public" view, the "lespinasse.org" zone is loaded from
/var/lib/bind/db.lespinasse.public, and has the "secure" dnssec-policy
applied to it.
- in my "internal" view, the "lespinasse.org" zone is loaded from
/etc/bind/db.lespinasse, and has not dnssec applied to it.
The view also includes a "public.lespinasse.org" zone which loads
the same db.lespinasse.public file as in the public view, but does
not apply any dnssec policy to it.
Simplified configuration (I can provide more details on private request):
options {
directory "/var/cache/bind";
dnssec-validation auto;
// Default settings, may be overriden for specific views or zones.
recursion no;
allow-query { any; };
allow-transfer { none; };
allow-update { none; };
serial-update-method date;
key-directory "/var/lib/bind/keys";
};
dnssec-policy "secure" {
// quite similar to the default policy, but I was put off by
// the note that ksk might get rotated if the default dnssec
// policy changes signing algorithms in the future
// so I was trying to avoid that
dnskey-ttl 3h;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 4w algorithm ecdsap256sha256;
};
publish-safety 12h;
retire-safety 12h;
signatures-refresh 2w;
signatures-validity 4w;
signatures-validity-dnskey 4w;
};
view "public" {
match-clients {
// requests from 192.168.1.1 with the axfr-key
!{ !key "axfr-key"; any; }; 192.168.1.1;
};
notify explicit;
also-notify { 192.168.1.1; };
allow-transfer { 192.168.1.1; };
zone "lespinasse.org" {
type master;
file "/var/lib/bind/db.lespinasse.public";
dnssec-policy "secure";
};
zone "test.lespinasse.org" {
type master;
file "/var/lib/bind/db.lespinasse.test";
dnssec-policy "secure";
};
};
view "internal" {
match-clients { 127.0.0.1; 10.0.0.0/8; };
recursion yes;
include "/etc/bind/named.conf.default-zones";
zone "lespinasse.org" {
type master;
file "/etc/bind/db.lespinasse";
};
zone "public.lespinasse.org" {
type master;
file "/etc/bind/db.lespinasse.public";
};
zone "test.lespinasse.org" { in-view "public"; };
};
During server reload or restart, I am seeing logs as below. The big
hint for me was the complain about not being to create
/etc/bind/db.lespinasse.jnl - db.lespinasse is only loaded in a zone
that doesn't allow updates or use any dnssec policy, so there is no
reason for it to require a journal...
/var/log/daemon.log extracts:
all zones loaded
running
zone lespinasse.org/IN/internal: reconfiguring zone keys
zone test.lespinasse.org/IN/public (signed): receive_secure_serial: unchanged
zone public.lespinasse.org/IN/internal: sending notifies (serial 2021013101)
zone lespinasse.org/IN/public (signed): receive_secure_serial: unchanged
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/58127 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/3104 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/5499 (ZSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/61198 (KSK)
zone test.lespinasse.org/IN/public (signed): sending notifies (serial
2021013101)
zone test.lespinasse.org/IN/public (signed): reconfiguring zone keys
Fetching lespinasse.org/ECDSAP256SHA256/34562 (KSK) from key repository.
DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) is now published
Fetching lespinasse.org/ECDSAP256SHA256/6553 (ZSK) from key repository.
DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now published
DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now active
CDNSKEY (DELETE) for zone lespinasse.org is now published
CDS (DELETE) for zone lespinasse.org is now published
zone
Bug#981449: dehydrated: certificate specific settings may affect other certificates
Package: dehydrated Version: 0.7.0-1~bpo10+1 Severity: normal Dear Maintainer, Dehydrated supports two locations for config settings: - The main config file, /etc/dehydrated/config by default - Per-certificate config files, i.e. certs/*/config Settings defined in the per-certificate config files are expected to only affect that particular certificate. But, this doesn't seem to be the case - in particular, I noticed that PRIVATE_KEY_ROLLOVER was also affecting certificates that are processed later in the run. Looking at the code, I think I found the root cause. The per-certificate config files are loaded in command_sign_domains(); there is a case statement filtering the settings that are allowed in a per-certificate config file and transfering those settings into global shell variables. In my dehydrated installation, the supported per-certificate config settings are: KEY_ALGO|OCSP_MUST_STAPLE|OCSP_FETCH|OCSP_DAYS|PRIVATE_KEY_RENEW|PRIVATE_KEY_ROLLOVER|KEYSIZE|CHALLENGETYPE|HOOK|PREFERRED_CHAIN|WELLKNOWN|HOOK_CHAIN|OPENSSL_CNF|RENEW_DAYS) The store_configvars() and reset_configvars() are expected to save the canonical (as per the global config file) settings and restore them before processing each certificate. But, the set of variables that are saved by these functions is only a subset of those that can be set in per-certificate config files; in particular the OCSP_FETCH, OCSP_DAYS, and PRIVATE_KEY_ROLLOVER settings are missing. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dehydrated depends on: ii ca-certificates 20200601~deb10u2 ii curl 7.64.0-4+deb10u1 ii openssl 1.1.1d-0+deb10u4 dehydrated recommends no packages. dehydrated suggests no packages. -- no debconf information
Bug#981157: dkimpy-milter: get_identities_sign() does not reset the i= signature identity
Package: dkimpy-milter Version: 1.2.1-1~bpo10+1 Severity: normal This is a tiny thing I noticed while checking the dkimpy-milter code for another issue I was looking at: dkimMilter.get_identities_sign() initially sets iequals = None; from context it seems that it should set self.iequals = None instead. I have no idea if there are any consequences to that, but I also noticed that envfrom() does not reset self.iequals, so there is at least a risk that the value could be incorrectly propagated from one email to the next if they are received on the same connection. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkimpy-milter depends on: ii adduser3.118 ii python33.7.3-1 ii python3-authres1.1.1-1 ii python3-dkim 1.0.3-1~bpo10+1 ii python3-dns3.2.0-2 ii python3-dnspython 1.16.0-1 ii python3-milter 1.0.3-3 ii python3-nacl 1.3.0-2 ii python3-pkg-resources 40.8.0-1 dkimpy-milter recommends no packages. Versions of packages dkimpy-milter suggests: ii lsb-base 10.2019051400 ii postfix 3.4.14-0+deb10u1 -- no debconf information
Bug#981156: dkimpy-milter: issues in sign-vs-verify logic (and documentation)
Package: dkimpy-milter Version: 1.2.1-1~bpo10+1 Severity: normal I have been encountering issues trying to configure the sign-vs-verify logic in dkimpy-milter. Some of it comes down to confusing documentation, but it also appears that the behavior I want can not be configured. I would like the sign-vs-verify logic to behave similarly to the smtpd_relay_restrictions rules in my postfix configuration: - any email coming from local networks (local sendmail, localhost smtpd, or 10.0.0.0/8 smtpd) should be signed, - any email coming from other sources should be verified. Reading the documentation, it seems that setting InternalHosts should work, but this doesn't seem to be the case: In dkimMilter.connect(), - self.internal_connection is set if the connection comes from an address matching InternalHosts, or if the milter macros match MacroList. - self.external_connection is set if the milter macros match MacroListVerify In dkimMilter.eom(): - self.external_connection disables signing - self.internal_connection disables verifying Therefore, MacroListVerify ends up controllinjg signing (despite what the name implies!), and MacroList ends up controlling verifying (despite what the documentation says about it). Additionally, for a smtpd milter receiving mail from both internal and external connections, it is not possible to control signing based on the InternalHosts value. My wishes for resolving this bug are: 1- There should be a way to control signing based on the originating connection's IP address; 2- It would be nice for the documentation to explain how the MacroList, MacroListVerify and InternalHosts values interact to determine wether we are dealing with an internal/trusted or external/untrusted connection (right now the values are only described separately and the interactions are not documented in any way); 3- I am not sure if there are any reasons for connections to be marked as both internal and external at once, or to have neither markings - if there are valid reasons for that, the documentation should explain them; if not maybe the milter should emit a warning when incorrectly configured... 4- The interaction between Mode and internal vs external connections should be documented (i.e. that Mode=s still only signs internal connections, and Mode=v still only verifies external connections). Sorry for the long winded report, hope it is at least clear enough :) Thanks, -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkimpy-milter depends on: ii adduser3.118 ii python33.7.3-1 ii python3-authres1.1.1-1 ii python3-dkim 1.0.3-1~bpo10+1 ii python3-dns3.2.0-2 ii python3-dnspython 1.16.0-1 ii python3-milter 1.0.3-3 ii python3-nacl 1.3.0-2 ii python3-pkg-resources 40.8.0-1 dkimpy-milter recommends no packages. Versions of packages dkimpy-milter suggests: ii lsb-base 10.2019051400 ii postfix 3.4.14-0+deb10u1 -- no debconf information
Bug#509089: dhcp lease negotiation takes longer than necessary
Package: dhcp3-client Version: 3.1.1-5 Tags: patch While trying to figure out why it takes so long to up an interface using dhcp, I had a look at the source code. It seemed to me that a lot of the delays were unnecessary. After fixing what I saw, it now takes about a quarter second to up an interface on my wired network - I thought I should send the patches here, in case there is an interest. dhcp3-client-1.diff fixes the delays between consecutive requests (the backoff algorithm). This algorithm is best explained in the following code comment: /* If we're supposed to increase the interval, do so. If it's currently zero (i.e., we haven't sent any packets yet), set it to initial_interval; otherwise, add to it a random number between zero and two times itself. On average, this means that it will double with every transmission. */ However contrary to what the comment indicates, client-interval has been initialised, before the first request is sent, to the initial_interval value rather than to 0. Because of that, the delay between the first two requests is, on average, double of the initial_interval value, instead of being equal to the initial_interval value. I'm proposing to change the initialization value to zero, in order to match the programmers expectations as documented in that comment, and to have the initial-interval option in dhclient.conf work as per the documented behavior. Additionally, I'm proposing to enforce that the delay between consecutive requests is always at least one second - this was already the case when using the default values, but could be messed with if setting an initial-interval of 0 or a backoff-cutoff of 1. Some people (see for example http://syn.theti.ca/ ) have been suggesting to use a backoff-cutoff of 1, so such configurations do exist in the wild. dhcp3-client-2.diff fixes a separate issue: the dhcp client was waiting a random delay, between 0 and 4 seconds, before sending the first dhcp request. The maximum delay was hardcoded and this behavior was not documented anywhere, but my guess is that this may have been intended to reduce dhcp floods when a large number of machines boot at the same time, following a power failure for example. It seems to me however, that such a delay is not necessary in many common situations, such as when running on a laptop with its own battery... I don't feel bold enough to just remove that random delay, but I think adding a new dhclient.conf option named initial-random-delay, which would default to 4 but be user-settable to any desired maximum random delay value, including 0 for no delay, is a reasonable proposal. Laptop users could then be encouraged to use initial-random-delay = 0. The third delay I identified was in the dhclient-script. The packaged script sleeps for one second after upping the interface with an ip address of 0 (this is, in the PREINIT stage before sending out the first dhcp request). A comment there says this is because the kernel needs some time to get the interface up. I believe this is not true of current kernels. In some situations, I can imagine that link negotiation could take a little time and cause packets to be lost during that interval, but this does not happen for the most common situations of using ifplugd or wpa-supplicant roaming, for example. Also even if it does happen in some wired situations, it seems that the worst case would be that the first request would get dropped and that a subsequent retransmit would work. So, I would propose to drop that one second delay as well. After implementing these proposed changes (as well as an additional change in ifplugd, as documented in bug 509015) I can get a wired dhcp connection within a quarter second of plugging in the ethernet cable. The only configuration parameter I need to apply is initial-random-delay=0 - the other parameters governing the backoff algorithm do not even have to be modified. Without these changes the dhcp connection would take anywhere from 2 to 7 seconds to negociate. Hope this helps, -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. diff -ru dhcp3-3.1.1.orig/client/dhclient.c dhcp3-3.1.1/client/dhclient.c --- dhcp3-3.1.1.orig/client/dhclient.c 2008-12-16 22:06:57.0 -0800 +++ dhcp3-3.1.1/client/dhclient.c 2008-12-16 23:44:39.0 -0800 @@ -578,7 +579,7 @@ make_request (client, client - active); client - destination = iaddr_broadcast; client - first_sending = cur_time; - client - interval = client - config - initial_interval; + client - interval = 0; /* Zap the medium list... */ client - medium = (struct string_list *)0; @@ -604,7 +605,7 @@ client - destination = iaddr_broadcast; client - state = S_SELECTING; client - first_sending = cur_time; - client - interval = client - config - initial_interval; + client - interval = 0; /* Add an immediate timeout to cause the first DHCPDISCOVER packet to go
Bug#509015: ifplugd waits more than the specified delays
Package: ifplugd
Version: 0.28-12
Tags: patch
According to ifplugd's manual, when passed the options -u0 and -d0,
ifplugd should up and down the interface as soon as it detects the cable
was connected or disconnected. For example, if running with options
-t10 -u0 -d0, one would expect the interface to get up or down at any time
within 10 seconds of the cable being connected or disconnected.
However, ifplugd actually defers this for an extra polling cycle - in my
example, any time between 10 and 20 seconds after the cable is (dis)connected.
This is easily fixed by replacing 't time(NULL)' with 't = time(NULL)'
in the test for the action processing, thus allowing the action to be
processed if the target time t is equal to time(NULL), which is the case
for a newly detected event with -u and -d options equal to 0.
Also, I'm proposing to shorten the polling delay when an action is scheduled
to happen before the delay expires: for example if we just detected that
the cable was unplugged, and we want to down the interface in two seconds,
but the usual polling delay is 10 seconds, we should use a select timeout
of two seconds just for the current polling cycle.
The attached patch implements these two suggestions. I've been running it
with options -M -t300 -u0 -d2. The long poll cycle allows my CPU to go sleep.
The monitoring option allows ifplugd to be notified of plug and unplug events
right when they happen. ifplugd ups the interface right away (within a
quarter of a second) when the cable is connected, and waits two seconds
before downing the interface when the cable is disconnected. Works very
well for me !
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
diff -ru ifplugd-0.28.orig/src/ifplugd.c ifplugd-0.28/src/ifplugd.c
--- ifplugd-0.28.orig/src/ifplugd.c 2008-12-17 03:27:34.0 -0800
+++ ifplugd-0.28/src/ifplugd.c 2008-12-17 04:26:00.0 -0800
@@ -468,6 +468,14 @@
tv.tv_sec = polltime;
tv.tv_usec = 0;
+if (t) {
+int delay = t - time(NULL);
+if (delay 0)
+tv.tv_sec = 0;
+else if (delay tv.tv_sec)
+tv.tv_sec = delay;
+}
+
if (select(FD_SETSIZE, qfds, NULL, NULL, tv) 0) {
if (errno == EINTR)
continue;
@@ -573,7 +581,7 @@
}
}
-if (t t time(NULL)) {
+if (t t = time(NULL)) {
t = 0;
if (action(status) 0)
Bug#488924: Proposed apache2-suexec dependency
I'm learning only today of the proposed dependancy on apache2-suexec. I think it's a bad idea: the dspam web frontend runs just fine with other web servers, and it is very unusual to have a packaged cgi-bin script depend on any particular web server. I have been running dspam's web frontend with several alternative web servers such as thttpd or mathopd. The only requirements seem to be that the server must support some form of HTTP authorization (basic authorization is just fine though) and that the user id can be set to dspam (mathopd lets me do that for just dspam's cgi scripts, thttpd had to be configured with an instance running on a separate port with dspam's UID). Maybe you could suggest or even recommend apache2-suexec, and possibly conflict on the versions that were limited to UID = 1000 ? -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496998: Descriptor leak in subprocess module exception path
Package: python2.4-minimal Version: 2.4.4-3+etch1 Tags: patch I'm observing a descriptor leak issue using python 2.4 as distributed in etch. This is on an amd64 architecture system. The following code leaks two file descriptors when 'jpegexiforient' is not installed: try: get_orient = subprocess.Popen (['jpegexiforient', '-n', pathfull], stdin = subprocess.PIPE, stdout = subprocess.PIPE) orient = get_orient.communicate ()[0] except: orient = None If executed in a loop, the process soon runs out of file descriptors. Looking at the issue, I believe this will happen on any posix system when subprocess.Popen is invoked with stdin or stdout equal to subprocess.PIPE and the desired executable can't be executed. The attached patch seems to solve the issue for me. -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. --- /usr/lib/python2.4/subprocess.py 2008-04-16 10:59:00.0 -0700 +++ subprocess.py 2008-08-28 13:09:50.0 -0700 @@ -970,6 +970,12 @@ data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB os.close(errpipe_read) if data != : + if p2cwrite: + os.close(p2cwrite) + if c2pread and c2pread not in (p2cwrite,): + os.close(c2pread) + if errread and errread not in (p2cwrite, c2pread): + os.close(errread) os.waitpid(self.pid, 0) child_exception = pickle.loads(data) raise child_exception
Bug#495550: Issues crash with CGI script issuing Location: header
Package: cherokee
Version: 0.5.5.dfsg-2
First day I use cherokee, so it's possible I did something wrong...
I have a cgi-bin script I've been working on - it generates thumbnail
galleries from some picture directory on my hard drive. Sometimes the CGI
script generates a Location: header for a client redirect response,
as per section 6.2.3 of RFC 3875.
The script is currently in /var/www/pygall/devel/gen2/pygall.py.
cherokee.conf includes this:
Request ^/pygall/.*\.cgi$ {
Handler cgi
}
I generated a request as follows:
cherokee% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET http://localhost/pygall/devel/gen2/pygall.cgi HTTP/1.1
HTTP/1.1 200 OK
Connection: Close
Date: Mon, 18 Aug 2008 06:22:06 GMT--8
Server: Cherokee
Location: http://localhost/pygall/devel/gen2/pygall.cgi/
Connection closed by foreign host.
Cherokee's answer is wrong here - it should have used the 302 status code,
not 200. Because cherokee did not follow the RFC here, web clients do not
redirect to the desired location.
(The output of my CGI script was the Location line with two final newlines).
Trying to see if I could figure out a workaround, I modified my script so that
it adds an additional line 'Status: 302 Found' after the location header.
But now cherokee crashes when processing this request:
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET http://localhost/pygall/devel/gen2/pygall.cgi HTTP/1.1
Connection closed by foreign host.
% ps auxw|grep -i cherokee
walken 28997 0.0 0.0 2736 564 pts/4S+ 06:27 0:00 grep -i
cherokee
This seems to happen reproduceably here.
Hope this helps. I can send the full contents of my /etc/cherokee and my
pygall.py script if desired.
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495550: Minimal test case
I thought I should send out a minimal test case for this.
I started with a fresh cherokee installation from etch
(on amd64 architecture) and kept the default config files.
I created /usr/lib/cgi-bin and added the following script as
/usr/lib/cgi-bin/crashme.cgi:
#!/usr/bin/python
import sys
sys.stdout.write ('Location: http://localhost/abc/def/\n'
'Status: 302 Found\n'
'\n')
I took my usual browser (iceweasel from etch) and typed
http://localhost/cgi-bin/crashme.cgi into the URL bar
The resulting access does crash cherokee.
In cherokee's defense, the output of the script does not comply with RFC 3875 -
the Status line should not be present normally. When this line is removed,
cherokee does not crash, but the web client does not redirect to
http://localhost/abc/def/ either as desired, because cherokee returns
a status of 200 for the request instead of 302 as required by RFC 3875.
Hope this helps,
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494954: udev from debian etch breaks with recent kernels
Package: udev Version: 0.105-4 I'm using debian etch on a couple systems, but with a custom compiled 2.6.26 kernel. The systems have SATA DVD drives which are correctly recognized by my kernel. udev does create an scd0 device for them, but for some reason it does not create any dvd and cdrom links to it. This happens on two systems with very different hardware (an HP ML350 and an ASUS P1-AH2), but both share the property of having a SATA drive and a recent kernel. I do realize that etch does not support 2.6.26 kernels yet, however someone suggested I should report the bug anyway, if only to avoid issues for people upgrading from etch to lenny. Cheers, -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410954: Tabs preference New pages should be opened in 'a new tab' doesn't seem to work
I was hitting this as well, on all of my debian machines at several sites, most of them running etch. Today I found a fix: in the preferences menu, selecting new pages should be opened in a new window, then again new pages should be opened in a new tab fixes the issue. This worked on all of my debian machines. Yay :) After doing this workaround, in about:config I can see that browser.link.open_newwindow is user-set to integer 3. Before that, it was showing the default value, which IIRC was integer 2. Could it be that debian provides these defaults and that the initial values cause the inconsistency between what's displayed in the preferences menu and what actually happens when clicking on a link ??? Hope this helps, -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469441: feature request: xosview.cpuFormat support for linux
Package: xosview
Version: 1.8.2-10
Severity: wishlist
Tags: patch, upstream
xosview currently only supports the xosview.cpuFormat resource only when
running on IRIX systems. Linux support seemed unnecessary for a long time
since 1-2 CPU systems were the norm, but this now becomes an issue now
that 8 core systems are not uncommon anymore.
The attached change adds support for xosview.cpuFormat in Linux:
diff -ru xosview-1.8.2/linux/MeterMaker.cc
xosview-1.8.2.patched/linux/MeterMaker.cc
--- xosview-1.8.2.orig/linux/MeterMaker.cc 2004-05-21 22:10:35.0
-0700
+++ xosview-1.8.2.patched/linux/MeterMaker.cc 2008-03-05 00:29:23.0
-0800
@@ -37,9 +37,15 @@
// Standard meters (usually added, but users could turn them off)
if (_xos-isResourceTrue(cpu)){
-int cpuCount = CPUMeter::countCPUs();
-int start = (cpuCount == 0) ? 0 : 1;
-for (int i = start ; i = cpuCount ; i++)
+int start, end;
+if (strncmp (_xos-getResource(cpuFormat),single,2) == 0)
+ start = end = 0;
+else {
+ end = CPUMeter::countCPUs();
+ start = (end == 0 ||
+ strncmp (_xos-getResource(cpuFormat),both,2) == 0) ? 0 : 1;
+}
+for (int i = start ; i = end ; i++)
push(new CPUMeter(_xos, CPUMeter::cpuStr(i)));
}
if (_xos-isResourceTrue(mem))
diff -ru xosview-1.8.2/xosview.1 xosview-1.8.2.patched/xosview.1
--- xosview-1.8.2.orig/xosview.12008-03-05 00:33:08.0 -0800
+++ xosview-1.8.2.patched/xosview.1 2008-03-04 04:51:17.0 -0800
@@ -514,9 +514,6 @@
xosview*cpuFormat: (single, all, both or auto)
.RS
-IRIX only.
-.RE
-.RS
If single, only a cumulative meter for all CPU is created. All creates a
meter for each CPU, but no cumulative meter. Both creates one cumulative
meter and one per cpu. auto behaves like single on uniprocessor system,
Hope this helps,
--
Michel Lespinasse
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449244: Checkarray sends email on DST time change
Package: mdadm Version: 2.5.6-9 Severity: minor Last night I received this message from the checkarray script: Subject: Cron [EMAIL PROTECTED] [ -x /usr/share/mdadm/checkarray ] [ $(date +%d) -le 7 ] /usr/share/mdadm/checkarray --cron --all --quiet checkarray: W: array md1 not idle, skipping... checkarray: W: array md2 not idle, skipping... After being puzzled for a while, I figured out that this is because of the DST time change. The clock rolled back 1 hour tonight, from 2AM to 1AM. This caused the checkarray script to run twice, and the second time the arrays were not idle as they take more than 1 hour to check. I classified this as minor since nothing wrong happened other than an email being sent and me getting puzzled about it. But this could easily be avoided by scheduling the cron job at any time other than a sunday from 1am to 2am. Maybe sunday 3am might work fine ??? (I'm not sure when the DST time change occurs in other countries/locations...) -- Michel Lespinasse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441377: 'burst' server option broken in etch (upstream bug 741)
Package: ntp Version: 1:4.2.2.p4+dfsg-2 The ntp package as included in etch does not properly support the 'burst' option in ntp.conf. If a local client tries to synchronize with time.example.net using a line such as 'server time.example.net burst iburst' in its ntp.conf file, the burst option will be ignored. This is known in upstream (https://support.ntp.org/bugs/show_bug.cgi?id=741) and has been fixed, just not in the version shipped in etch. While this will have a low impact for most people, some network configurations can make this worse. I found out about the issue because I have machines on an internal subnet with the gateway providing proxy arp in a supposedly transparent fashion. Linux by default delays proxy arp replies for about 100 ms to avoid any potential issues with looped networks. This delay has been messing up the ntp time synchronization for machines on that subnet, an issue that was previously worked around by using the 'burst' keyword (only the first packet in the burst was delayed by the proxy arp issue). The fix as described in the upstream bugtracker is a one-liner. I'm not sure if a backport in the next etch update (if any) would be justified or not. -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438123: nfsmount broken on mipsel - wrong SOCK_* definitions
Package: klibc-utils Version: 1.4.34-1 Trying to run nfsmount, I get the following errors: nfsmount -o ro,nolock server:/foo /mnt socket: Protocol not supported socket: Protocol not supported NFS over TCP not available from server Using strace, I see the following: execve(nfsmount, [nfsmount, -o, ro,nolock, server:/foo, /mnt], [/* 13 vars */]) = 0 svr4_syscall() = 4078 svr4_syscall() = -1 ERRNO_4210 (Unknown error 4210) stat64(0x7ff0fee7, 0x7ff0fd08) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_TCP) = -1 EPROTONOSUPPORT (Protocol not supported) write(2, socket: Protocol not supported\n, 31) = 31 socket(PF_INET, SOCK_STREAM, IPPROTO_UDP) = -1 EPROTONOSUPPORT (Protocol not supported) write(2, socket: Protocol not supported\n, 31) = 31 write(2, NFS over TCP not available from ..., 41) = 41 exit(1) = ? These two calls got my attention: socket(PF_INET, SOCK_DGRAM, IPPROTO_TCP) socket(PF_INET, SOCK_STREAM, IPPROTO_UDP) /usr/include on a mipsel box shows the following: /usr/include/asm/socket.h: * @SOCK_DGRAM - datagram (conn.less) socket /usr/include/asm/socket.h: SOCK_DGRAM = 1, /usr/include/linux/net.h: * @SOCK_DGRAM: datagram (conn.less) socket /usr/include/linux/net.h: SOCK_DGRAM = 2, /usr/include/linux/irda.h:/* Protocol types to be used for SOCK_DGRAM */ /usr/include/bits/socket.h: SOCK_DGRAM = 1,/* Connectionless, unreliable datagrams /usr/include/bits/socket.h:#define SOCK_DGRAM SOCK_DGRAM the klibc source package also defines SOCK_DGRAM as 2 in usr/include/sys/socket.h I am using unmodified packages from etch. I'm not sure what's wrong, it looks like linux-kernel-headers on mipsel has inconsistent definitions for the socket types, but somehow this does not seem to affect non-klibc-based applications... Probably the issue is that klibc's usr/include/sys/socket.h needs to present different values on mipsel (i.e. SOCK_DGRAM = 1 in that case). -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438123: nfsmount broken on mipsel - wrong SOCK_* definitions
On Wed, Aug 15, 2007 at 05:56:51PM +0200, maximilian attems wrote: urrgs indeed that got fixed postetch ok i've build tested the attached git patch. Thanks for the patch and for the corresponding build instructions (I had never used debuild before). I can confirm that this builds fine on mipsel and solves my nfsmount issue. Thanks ! -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434995: clamav-milter: incomplete postfix usage instructions
Package: clamav-milter Version: 0.91.1-1~volatile1 Severity: normal I've been following the instructions from /usr/share/doc/clamav-base.README.Debian.gz to interface clamav-milter with postfix using a setgid directory. However this does not work out of the box - as shown in the instructions, the created socket is not postfix group writeable, so postfix can not communicate with the milter. As a crude workaround, I've added 'umask 007' in /etc/default/clamav-milter. This works fine for me, however I suspect this is not the best solution (i.e. it might be better to set umask only when starting the daemon ???) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.14 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages clamav-milter depends on: ii clamav-base 0.91.1-1~volatile1 base package for clamav, an anti-v ii clamav-freshclam [cla 0.91.1-1~volatile1 downloads clamav virus databases f ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libclamav20.91.1-1~volatile1 virus scanner library ii libmilter08.13.8-3 Sendmail Mail Filter API (Milter) ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages clamav-milter recommends: pn clamav-daemon none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434072: clamav-base: No support for tmpfs /var/run mount
Package: clamav-base Version: 0.90.1-3etch3 Severity: important In debian etch one can set RAMRUN=yes in /etc/default/rcS and get a tmpfs mounted over /var/run. This works fine with most packages, but not with clamav. On startup I get a message 'ERROR: Socket file /var/run/clamav/clamd.ctl could not be bound: no such file or directory'. When freshclam updates the signatures it also complains about not being able to connect to clamav thru that socket file either. Also freshclam complains about 'ERROR: Can't safe PID to file /var/run/clamav/freshclam.pid: no such file or directory'. I suggest the clamav-daemon and clamav-freshclam init scripts should make sure to recreate the /var/run/clamav directory structure on startup in order to work for setups that use the RAMRUN=yes setting in /etc/default/rcS Thanks, -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.52 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages clamav-base depends on: ii adduser 3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii logrotate 3.7.1-3Log rotation utility ii ucf 2.0020 Update Configuration File: preserv Versions of packages clamav-base recommends: ii clamav 0.90.1-3etch3 antivirus scanner for Unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223487: Bind9 dies silently
I've been having this issue as well. I was running bind9 (the final etch version) on a small mipsel router, and it died about once a week. Today I transferred my name server to an amd64 box (still running etch). I dont know yet if this will help. Maybe not, as I see Philippe's report is on i386. I also noticed that bind left behind core files in /var/cache/bind/core.* gdb indicates that these core files were due to a SIGBUS; also gdb does not give any backtrace information (but that may be because /usr/sbin/named is stripped ?) Philippe, do you have any core files in /var/cache/bind/core.* and if so, do they give out any interesting information ? Thanks, -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418736: [Pkg-dspam-misc] New Dspam out
On Fri, Apr 20, 2007 at 01:52:52AM -0400, Daniel Kahn Gillmor wrote: Please weigh in there if you have any thoughts about the issues we'll face during the upgrade. The more folks who speak up about what they need for 3.8.0, the better our package will be. I'm using dspam as a delivery agent proxy (actually my setup is a bit more complex, my account has a .forward that directs to a delivery script, messages are sent to dspam only if they dont come from localnet and have a non-null sender, null sender messages go thru a RCPT-tag based bounce filter instead) I've been using the hash driver, I like it as it's more lightweight than the database based schemes. I think this (delivery agent with hash driver) would be a reasonable default configuration for small systems. It's quite flexible as different users can choose to go thru dspam - or not - by just changing their .forward. I dont know why it's not advertised more - after all, it's the unix way :) -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400952: rc order of portmap,nis,autofs
I did hit the same issue at work - autofs worked fine as I just installed the packages, then broke at soon as I rebooted. Yuck! As noted earlier the main issue is that nis and autofs are both at priority 19 currently. Seems like we should at least start by moving nis to priority 18, since that will be required either way. Moving portmap to priority 17 seems like a good thing too but I would not mind as stongly about it getting done for etch or not. In my installation I just moved portmap to 17 and nis to 18 and got things working. This is what seemed the most natural fix to me (before I found out about this bug and even heard about portmap being started in rcS). Either way, I hope etch will at least move nis to priority 18. Thanks, -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409145: bind9 assertion failure (mem.c:628)
I had reported this bug a week ago running on my mipsel based router. Today I hit it again. Same assertion failure shown in syslog. I'm still running version 1:9.3.2-P1.0-1. If you can tell me how to configure things so that bind9 generates a core file when it dies, I'll do that to help the investigation. Otherwise, I'll try to upgrade to 1:9.3.4-2 and see if it helps. I know there has been DOS vulnerabilities published recently, but the details have been sparse so I dont know if they apply here. Thanks, -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409145: bind9 assertion failure (mem.c:628)
Package: bind9
Version: 1:9.3.2-P1.0-1
Bind9 (running on my mipsel based router) died today. Trying to investigate
the issue, I found the following lines in my syslog and daemon.log files:
Jan 30 19:17:59 Trieuse named[650]: mem.c:628: INSIST(((unsigned char
*)mem)[size] == 0xbe) failed
Jan 30 19:17:59 Trieuse named[650]: exiting (due to assertion failure)
I did not find any core files, sorry...
The bind9 package had been freshly installed less than a week ago, probably
at the same version number. I only changed the named.conf.options file
as follows:
named.conf.options
options {
directory /var/cache/bind;
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no;# conform to RFC1035
listen-on {
127.0.0.1;
10.0.0.1;
};
listen-on-v6 { any; };
};
// Reduce log verbosity on issues outside our control.
logging {
category lame-servers { null; };
};
Installed package versions:
bind9, libbind9-0, libdns21, libisc11, libisccc0, libisccfg1, liblwres9:
1:9.3.2-P1.0-1
libc6: 2.3.6.ds1-8
libssl0.9.8: 0.9.8c-4
netbase: 4.28
adduser: 3.101
Kernel: Linux Trieuse 2.6.16.35 #5 Sun Jan 21 04:28:12 PST 2007 mips GNU/Linux
(compiled from pristine kernel.org source, for mipsel architecture)
I use bind9 as a caching name server, it does not serve any domains other than
localhost and 0/127/255.in-addr-arpa as configured in the default named.conf,
and the firewall blocks outside connections to TCP and UDP ports 53.
Hope this helps - sorry I could not find a core file :/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406181: linux-2.6: RAID1 repair is broken
Package: linux-2.6 Version: 2.6.18-8 Severity: normal This is a followup to an issue initially reported to the mdadm package as bug 405919. As there is really a separate kernel issue, Martin asked me to file a separate bug. The RAID1 repair process is currently a no-op. The upstream maintainer for the kernel MD driver sent a patch which worked for me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919;msg=17 Regarding the other kernel issue I had reported under bug 405919 (inverted cmd_match(page, repair) condition), note that it's already fixed in debian's kernel version. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.36 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405919: mdadm: checkarray does not report or fix mismatch_cnt issues
Package: mdadm Version: 2.5.6-7 Severity: normal My RAID1 arrays get checked by checkarray the first sunday of every month (default mdadm configuration, I think). I have noticed that /sys/block/md1/md/mismatch_cnt reports a count of 128 unsynchronized blocks. checkarray does not report or fix this issue. Doing the same manually (echo check /sys/block/md1/md/sync_action) does not fix the issue either - mismatch_cnt is reset to 0 at the start of the resync, and goes up to 128 somewhere between 40% and 50% of the resync. I believe checkarray should be made to report this issue, as my understanding was that the point of checkarray was to help with unsynchronized arrays ??? smartctl -a does not report any issues on either devices the RAID1 is based on. I just noticed today that mdadm.conf only lists 3 of my 5 RAID1 volumes, I do not know why (I did not edit the file after it was auto-generated). -- Package-specific info: --- mount output /dev/md0 on / type ext2 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) tmpfs on /tmp type tmpfs (rw) tmpfs on /var/tmp type tmpfs (rw,size=1g) /dev/md1 on /home type ext2 (rw,nosuid,nodev,errors=remount-ro) /dev/md3 on /mnt/extra0 type ext2 (rw,noexec,nosuid,nodev,errors=remount-ro) /dev/md4 on /mnt/extra1 type ext2 (rw,noexec,nosuid,nodev,errors=remount-ro) automount(pid1430) on /mnt/autofs type autofs (rw,fd=4,pgrp=1430,minproto=2,maxproto=4) --- mdadm.conf # Autogenerated by mdcfg. See mdadm.conf(5) for more details on this file. DEVICE partitions ARRAY /dev/md0 level=raid1 num-devices=2 devices=/dev/hde1,/dev/hdg1 UUID=436d1e33:5613bb60:73401891:847eb5d1 ARRAY /dev/md1 level=raid1 num-devices=2 devices=/dev/hde2,/dev/hdg2 UUID=096310d2:3269c085:7757eec1:62d16352 ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/hde3,/dev/hdg3 UUID=0b80a931:d5aa8c2c:bd233b49:f4b6d4ab MAILADDR root --- /proc/mdstat: Personalities : [raid1] md4 : active raid1 hde3[1] hdc2[0] 9783488 blocks [2/2] [UU] md1 : active raid1 hdg2[1] hde2[0] 126953536 blocks [2/2] [UU] [===.] resync = 56.0% (71133440/126953536) finish=27.1min speed=34242K/sec md3 : active raid1 hdg3[1] hdc1[0] 48827904 blocks [2/2] [UU] md2 : active raid1 hdg4[1] hde4[0] 1975104 blocks [2/2] [UU] md0 : active raid1 hdg1[1] hde1[0] 17574976 blocks [2/2] [UU] unused devices: none --- /proc/partitions: major minor #blocks name 22 0 58615704 hdc 22 1 48827992 hdc1 22 29787680 hdc2 33 0 156290904 hde 33 1 17575078 hde1 33 2 126953662 hde2 33 39783585 hde3 33 41975995 hde4 34 0 195360984 hdg 34 1 17575078 hdg1 34 2 126953662 hdg2 34 3 48853665 hdg3 34 41975995 hdg4 9 0 17574976 md0 9 21975104 md2 9 3 48827904 md3 9 1 126953536 md1 9 49783488 md4 --- initrd.img-2.6.16.36: --- /proc/modules: -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.36 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mdadm depends on: ii debconf [debconf-2.0]1.5.11 Debian configuration management sy ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip ii makedev 2.3.1-83creates device files in /dev Versions of packages mdadm recommends: ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo ii postfix [mail-transport-agent 2.3.4-3A high-performance mail transport -- debconf information: * mdadm/autostart: true * mdadm/initrdstart: /dev/md0 mdadm/initrdstart_notinconf: false mdadm/initrdstart_msg_errexist: mdadm/initrdstart_msg_intro: mdadm/initrdstart_msg_errblock: * mdadm/warning: * mdadm/start_daemon: true * mdadm/mail_to: root mdadm/initrdstart_msg_errmd: mdadm/initrdstart_msg_errconf: * mdadm/autocheck: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397121: unnecessary dpkg accesses to the available file
Package: dpkg
Version: 1.13.24
Severity: normal
As reported under bug 395140, dpkg/dselect takes a lot of memory and
can easily push low-memory systems to swap. Most of this memory usage
is related to parsing the available file into an in-memory database.
I mentionned this issue to Matt Zimmerman and he made the following
observation:
The fact that dpkg pays attention to the available file at all is a bug;
it should only care about the state of the system and not about external
repositories. Only higher level package managers like apt and dselect
should do that.
I think he's correct, in that dpkg only needs to consider dependencies or
conflicts with the installed packages on the system, and can safely ignore
anything that has not been installed. Any other behaviour is at best
undocumented, and most likely, a bug.
In detail, here is what I suggest:
dpkg --install / --unpack / --configure / --remove / --purge currently read
and write the available file, they need not touch it at all.
dpkg --get-selections / --set-selections / --clear-selections / --audit /
--yet-to-unpack should not need to touch the available file either, I think.
dpkg-query should never read or write the available file except for the
--print-avail command.
The commands that write to the available file should be limited to:
dpkg --record-avail
dpkg --update-avail / --merge-avail / --clear-avail
(any writes to the available file will be lost at the next dselect update
anyway, but dpkg --update-avail needs to work for dselect update to work).
The commands that read the available file should be limited to:
dselect select (reads and rewrites today)
dpkg-query --print-avail (already done readonly today)
dpkg --forget-old-unavail (reads and rewrites today)
dpkg --predep-package (already done readonly today)
The attached patch implements this suggestion.
--
Michel Walken Lespinasse
Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie. -- Dennis Miller
diff -ru dpkg-1.13.24.patch123/dselect/main.cc dpkg-1.13.24/dselect/main.cc
--- dpkg-1.13.24.patch123/dselect/main.cc 2006-10-28 00:53:05.0
-0700
+++ dpkg-1.13.24/dselect/main.cc2006-11-05 02:27:31.0 -0800
@@ -348,7 +348,8 @@
}
urqresult urq_list(void) {
- readwrite= modstatdb_init(admindir,msdbrw_writeifposs);
+ readwrite= modstatdb_init(admindir,(modstatdb_rw)(msdbrw_writeifposs|
+msdbrw_readonlyavail));
curseson();
diff -ru dpkg-1.13.24.patch123/lib/dbmodify.c dpkg-1.13.24/lib/dbmodify.c
--- dpkg-1.13.24.patch123/lib/dbmodify.c2006-10-28 00:53:20.0
-0700
+++ dpkg-1.13.24/lib/dbmodify.c 2006-11-04 23:01:11.0 -0800
@@ -177,9 +177,9 @@
if (cstatus != msdbrw_needsuperuserlockonly) {
cleanupdates();
if(!(cflags msdbrw_noavail))
-parsedb(availablefile,
-pdb_recordavailable|pdb_rejectstatus,
-NULL,NULL,NULL);
+ parsedb(availablefile,
+ pdb_recordavailable|pdb_rejectstatus,
+ NULL,NULL,NULL);
}
if (cstatus = msdbrw_write) {
@@ -212,7 +212,8 @@
switch (cstatus) {
case msdbrw_write:
checkpoint();
-writedb(availablefile,1,0);
+if(!(cflags (msdbrw_noavail | msdbrw_readonlyavail)))
+ writedb(availablefile,1,0);
/* tidy up a bit, but don't worry too much about failure */
fclose(importanttmp);
strcpy(updatefnrest, IMPORTANTTMP); unlink(updatefnbuf);
diff -ru dpkg-1.13.24.patch123/lib/dpkg-db.h dpkg-1.13.24/lib/dpkg-db.h
--- dpkg-1.13.24.patch123/lib/dpkg-db.h 2006-10-28 00:54:46.0 -0700
+++ dpkg-1.13.24/lib/dpkg-db.h 2006-11-05 02:26:58.0 -0800
@@ -160,6 +160,7 @@
msdbrw_flagsmask= ~077,
/* flags start at 0100 */
msdbrw_noavail= 0100,
+ msdbrw_readonlyavail= 0200,
};
struct pipef {
diff -ru dpkg-1.13.24.patch123/src/archives.c dpkg-1.13.24/src/archives.c
--- dpkg-1.13.24.patch123/src/archives.c2006-10-28 00:53:31.0
-0700
+++ dpkg-1.13.24/src/archives.c 2006-11-01 02:02:05.0 -0800
@@ -945,10 +945,10 @@
char *p;
modstatdb_init(admindir,
- f_noact ? msdbrw_readonly
+ f_noact ? (msdbrw_readonly |
msdbrw_noavail)
: cipaction-arg == act_avail ? msdbrw_write
- : fc_nonroot ? msdbrw_write
- : msdbrw_needsuperuser);
+ : fc_nonroot ? (msdbrw_write | msdbrw_noavail)
+ : (msdbrw_needsuperuser |
msdbrw_noavail));
checkpath();
diff -ru dpkg-1.13.24.patch123/src/enquiry.c dpkg-1.13.24/src/enquiry.c
--- dpkg-1.13.24.patch123/src/enquiry.c 2006-10-28 00:53:31.0 -0700
+++ dpkg-1.13.24/src/enquiry.c 2006-11-05 01:40:34.0 -0800
@@ -120,7 +120,7 @@
if (*argv) badusage(_(--audit does not take any arguments));
Bug#395140: parse.c: avoid mmaping the entire file
This change reworks parse.c to avoid mmapping the entire file, which reduces
memory usage by up to 20MB when parsing the available file.
The file is now read in 64KB chunks. A new chunk is loaded whenever we
get to the end of the previous chunk. Because fields can cross over
chunk boundaries (or even be larger than 64KB themselves, theorically)
they are copied to a separate storage buffer while parsing, which can
be reallocated as needed. Note that because the storage buffer can get
reallocated, 'fieldstart' and 'valuestart' can not be preserved accross
getc invocations - instead we must preserve their positions as integer
offsets from the start of the (reallocatable) storage buffer.
This helps a little more, but not as much as the previous two patches.
I think I'll stop here as we're hitting a point of diminishing returns.
One could probably do better by using proper database techniques to handle
the package information, but this is probably overkill.
--
Michel Walken Lespinasse
Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie. -- Dennis Miller
diff -ru dpkg-1.13.24.patch12/lib/parse.c dpkg-1.13.24/lib/parse.c
--- dpkg-1.13.24.patch12/lib/parse.c2006-10-27 21:21:25.0 -0700
+++ dpkg-1.13.24/lib/parse.c2006-10-28 00:33:10.0 -0700
@@ -76,7 +76,35 @@
#define NFIELDS (sizeof(fieldinfos)/sizeof(struct fieldinfo))
const int nfields= NFIELDS;
-static void cu_parsedb(int argc, void **argv) { close(*(int *)argv); }
+#define READ_SIZE 65536
+static int fbuf_fd;
+static char fbuf_readbuf[READ_SIZE];
+static int fbuf_readpos, fbuf_readfilled;
+static char *fbuf_storebuf;
+static int fbuf_storepos= 0, fbuf_storealloc= 0;
+
+static void cu_parsedb(int argc, void **argv) { close(fbuf_fd); }
+
+static int fbuf_readblock(void) {
+ fbuf_readfilled= read(fbuf_fd, fbuf_readbuf, READ_SIZE);
+ if (fbuf_readfilled 0) ohshite(_(error reading package file));
+ fbuf_readpos= 0;
+}
+
+static inline int fbuf_EOF(void) {
+ return fbuf_readfilled == 0;
+}
+
+static inline int fbuf_getc(void) {
+ int c = fbuf_readbuf[fbuf_readpos++];
+ if (fbuf_readpos = fbuf_readfilled) fbuf_readblock();
+ if (fbuf_storepos = fbuf_storealloc) {
+fbuf_storealloc++;
+fbuf_storebuf = realloc(fbuf_storebuf, fbuf_storealloc);
+ }
+ fbuf_storebuf[fbuf_storepos++] = c;
+ return c;
+}
int parsedb(const char *filename, enum parsedbflags flags,
struct pkginfo **donep, FILE *warnto, int *warncount) {
@@ -84,7 +112,6 @@
* If donep is not null only one package's information is expected.
*/
- int fd;
struct pkginfo newpig, *pigp;
struct pkginfoperfile *newpifp, *pifp;
struct arbitraryfield *arp, **larpp;
@@ -93,63 +120,43 @@
int fieldencountered[NFIELDS];
const struct fieldinfo *fip;
const struct nickname *nick;
- char *data, *dataptr, *endptr;
const char *fieldstart, *valuestart;
char *value= NULL;
int valuealloc= 0;
- int fieldlen= 0, valuelen= 0;
+ int fieldpos= 0, valuepos= 0, fieldlen= 0, valuelen= 0;
int *ip, c;
- struct stat stat;
if (warncount) *warncount= 0;
newpifp= (flags pdb_recordavailable) ? newpig.available :
newpig.installed;
- fd= open(filename, O_RDONLY);
- if (fd == -1) ohshite(_(failed to open package info file `%.255s' for
reading),filename);
-
- push_cleanup(cu_parsedb,~0, NULL,0, 1,fd);
+ fbuf_fd= open(filename, O_RDONLY);
+ if (fbuf_fd == -1) ohshite(_(failed to open package info file `%.255s' for
reading),filename);
- if (fstat(fd, stat) == -1)
-ohshite(_(can't stat package info file `%.255s'),filename);
+ push_cleanup(cu_parsedb,~0, NULL,0, 0);
- if (stat.st_size 0) {
-#ifdef HAVE_MMAP
-if ((dataptr= (char *)mmap(NULL, stat.st_size, PROT_READ, MAP_SHARED, fd,
0)) == MAP_FAILED)
- ohshite(_(can't mmap package info file `%.255s'),filename);
-#else
-if ((dataptr= malloc(stat.st_size)) == NULL)
- ohshite(_(failed to malloc for info file `%.255s'),filename);
-
-fd_buf_copy(fd, dataptr, stat.st_size, _(copy info file
`%.255s'),filename);
-#endif
-data= dataptr;
-endptr= dataptr + stat.st_size;
- } else {
-data= dataptr= endptr= NULL;
- }
+ fbuf_readblock();
lno= 1;
pdone= 0;
-#define EOF_mmap(dataptr, endptr) (dataptr = endptr)
-#define getc_mmap(dataptr) *dataptr++;
-#define ungetc_mmap(c, dataptr, data) dataptr--;
for (;;) { /* loop per package */
+fbuf_storepos= 0;
memset(fieldencountered, 0, sizeof(fieldencountered));
blankpackage(newpig);
blankpackageperfile(newpifp);
/* Skip adjacent new lines */
-while(!EOF_mmap(dataptr, endptr)) {
- c= getc_mmap(dataptr); if (c!='\n' c!=MSDOS_EOF_CHAR ) break;
+while(!fbuf_EOF()) {
+ c= fbuf_getc(); if (c!='\n' c!=MSDOS_EOF_CHAR ) break;
lno++;
}
-if (EOF_mmap(dataptr, endptr)) break;
+if (fbuf_EOF()) break;
for (;;) { /* loop per field */
- fieldstart= dataptr - 1;
- while
Bug#395140: Actually things are still slower than I'd like
Hmmm - let me take back my previous comment about interactive performance being OK again on a 32MB box. I had edited /var/lib/dpkg/available on my box to remove all lines starting with a space - i.e., in practice, the multiline package descriptions. With *that* change plus my ncurses patch, dselect was useable. With my ncurses patch alone, dselect still just takes too much memory. I'll be working on follow-up changes to make dselect really useable again. -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395140: Segregated storage for the in-memory package database
The attached patch helps with low-memory performance by implementing
segregated memory storage. A separate obstack is used for allocating
information related to the Installed-Size, Origin, Maintainer, Bugs,
Architecture, Source, Filename, Size, MD5sum, MSDOS-Filename and
Description fields, as well as any arbitrary field contents
(which these days seems to include SHA1, SHA256, Tag and Task fields).
Using a separate obstack does not reduce memory usage, but it helps cope
with memory pressure. Operations such as dependency computations or
package sorting do not depend on anything that's stored in the secondary
obstack, so the segregation greatly reduces the working set size.
As a practical result, starting 'dselect select' with a non-trimmed
available package set (my sources.list lists just etch main) used to take
5 minutes and 25 seconds before it got to the dselect screen, much of
it being spent in the package quicksort, it now takes about 42 seconds
(most of which seems to be spent parsing the available file).
There is still some swapping while reading the available file, my next
step will be to try to reduce this by avoiding mmap'ing the whole file.
--
Michel Walken Lespinasse
Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie. -- Dennis Miller
diff -ru dpkg-1.13.24.orig/lib/dpkg-db.h dpkg-1.13.24/lib/dpkg-db.h
--- dpkg-1.13.24.orig/lib/dpkg-db.h 2006-06-28 17:15:10.0 -0700
+++ dpkg-1.13.24/lib/dpkg-db.h 2006-10-27 05:16:21.0 -0700
@@ -303,8 +303,11 @@
/*** from nfmalloc.c ***/
extern void *nfmalloc(size_t);
+extern void *nfmalloc_secondary(size_t);
char *nfstrsave(const char*);
+char *nfstrsave_secondary(const char*);
char *nfstrnsave(const char*, int);
+char *nfstrnsave_secondary(const char*, int);
void nffreeall(void);
/*** from showpkg.c ***/
diff -ru dpkg-1.13.24.orig/lib/fields.c dpkg-1.13.24/lib/fields.c
--- dpkg-1.13.24.orig/lib/fields.c 2006-06-28 17:13:45.0 -0700
+++ dpkg-1.13.24/lib/fields.c 2006-10-27 05:14:47.0 -0700
@@ -94,7 +94,7 @@
_(file details field `%s' not allowed in status
file),fip-name);
allowextend= !pigp-files;
fdpp= pigp-files;
- cpos= nfstrsave(value);
+ cpos= nfstrsave_secondary(value);
while (*cpos) {
space= cpos; while (*space !isspace(*space)) space++;
if (*space) *space++= 0;
@@ -103,7 +103,7 @@
if (!allowextend)
parseerr(NULL,filename,lno, warnto,warncount,pigp,0, _(too many
values
in file details field `%s' (compared to others)),fip-name);
- fdp= nfmalloc(sizeof(struct filedetails));
+ fdp= nfmalloc_secondary(sizeof(struct filedetails));
fdp-next= NULL;
fdp-name= fdp-msdosname= fdp-size= fdp-md5sum= NULL;
*fdpp= fdp;
@@ -122,7 +122,7 @@
enum parsedbflags flags,
const char *filename, int lno, FILE *warnto, int *warncount,
const char *value, const struct fieldinfo *fip) {
- if (*value) PKGPFIELD(pifp,fip-integer,char*)= nfstrsave(value);
+ if (*value) PKGPFIELD(pifp,fip-integer,char*)= nfstrsave_secondary(value);
}
void f_boolean(struct pkginfo *pigp, struct pkginfoperfile *pifp,
diff -ru dpkg-1.13.24.orig/lib/nfmalloc.c dpkg-1.13.24/lib/nfmalloc.c
--- dpkg-1.13.24.orig/lib/nfmalloc.c2006-06-21 06:41:12.0 -0700
+++ dpkg-1.13.24/lib/nfmalloc.c 2006-10-27 05:15:34.0 -0700
@@ -31,18 +31,20 @@
#define obstack_chunk_alloc m_malloc
#define obstack_chunk_free free
-static struct obstack db_obs;
+static struct obstack db_obs, db_obs_secondary;
static int dbobs_init = 0;
/* We use lots of mem, so use a large chunk */
-#define CHUNK_SIZE 8192
+#define CHUNK_SIZE 65536
#define OBSTACK_INIT if (!dbobs_init) { nfobstack_init(); }
static void nfobstack_init(void) {
obstack_init(db_obs);
+ obstack_init(db_obs_secondary);
dbobs_init = 1;
obstack_chunk_size(db_obs) = CHUNK_SIZE;
+ obstack_chunk_size(db_obs_secondary) = CHUNK_SIZE;
}
inline void *nfmalloc(size_t size)
@@ -51,19 +53,36 @@
return obstack_alloc(db_obs, size);
}
+inline void *nfmalloc_secondary(size_t size)
+{
+ OBSTACK_INIT;
+ return obstack_alloc(db_obs_secondary, size);
+}
+
char *nfstrsave(const char *string) {
OBSTACK_INIT;
return obstack_copy0 (db_obs, string, strlen(string));
}
+char *nfstrsave_secondary(const char *string) {
+ OBSTACK_INIT;
+ return obstack_copy0 (db_obs_secondary, string, strlen(string));
+}
+
char *nfstrnsave(const char *string, int l) {
OBSTACK_INIT;
return obstack_copy0 (db_obs, string, l);
}
+char *nfstrnsave_secondary(const char *string, int l) {
+ OBSTACK_INIT;
+ return obstack_copy0 (db_obs_secondary, string, l);
+}
+
void nffreeall(void) {
if (dbobs_init) {
obstack_free(db_obs, NULL);
+obstack_free(db_obs_secondary, NULL);
dbobs_init = 0;
}
}
diff -ru dpkg-1.13.24.orig/lib/parse.c dpkg-1.13.24/lib/parse.c
---
Bug#395140: Patch to reduce memory usage by ncurses
tags 395140 patch
thanks
The following patch seems to reduce dselect memory usage by using a
smaller ncurses buffer size. Interactive performance is useable again
on my 32MB test box.
Thanks,
--
Michel Walken Lespinasse
Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie. -- Dennis Miller
diff -ru dpkg-1.13.24.orig/dselect/baselist.cc dpkg-1.13.24/dselect/baselist.cc
--- dpkg-1.13.24.orig/dselect/baselist.cc 2006-06-21 06:41:12.0
-0700
+++ dpkg-1.13.24/dselect/baselist.cc2006-10-25 04:08:19.0 -0700
@@ -170,7 +170,7 @@
if (!whatinfowin) ohshite(_(failed to create whatinfo window));
wattrset(whatinfowin,whatinfo_attr);
- listpad= newpad(nitems+1, total_width);
+ listpad= newpad(ymax, total_width);
if (!listpad) ohshite(_(failed to create baselist pad));
colheadspad= newpad(1, total_width);
diff -ru dpkg-1.13.24.orig/dselect/basetop.cc dpkg-1.13.24/dselect/basetop.cc
--- dpkg-1.13.24.orig/dselect/basetop.cc2006-06-21 06:41:12.0
-0700
+++ dpkg-1.13.24/dselect/basetop.cc 2006-10-25 04:23:55.0 -0700
@@ -39,7 +39,7 @@
list_row + nitems - topofscreen - 1);
x= lesserint(total_width - leftofscreen - 1,
xmax - 1);
- pnoutrefresh(listpad, topofscreen,leftofscreen, list_row,0, y,x);
+ pnoutrefresh(listpad, 0,leftofscreen, list_row,0, y,x);
getmaxyx(listpad,maxy,maxx);
y++;
while (y list_row + list_height - 1) {
@@ -49,9 +49,10 @@
}
void baselist::redrawitemsrange(int start, int end) {
- if (ldrawnstart==-1) { ldrawnstart= ldrawnend= end; }
- while (ldrawnstart start) { ldrawnstart--; redraw1item(ldrawnstart); }
- while (ldrawnend end) { redraw1item(ldrawnend); ldrawnend++; }
+ int i;
+ for (i = start; i end; i++) {
+redraw1item(i);
+ }
}
void baselist::refreshcolheads() {
diff -ru dpkg-1.13.24.orig/dselect/pkglist.cc dpkg-1.13.24/dselect/pkglist.cc
--- dpkg-1.13.24.orig/dselect/pkglist.cc2006-06-21 06:41:12.0
-0700
+++ dpkg-1.13.24/dselect/pkglist.cc 2006-10-25 04:24:09.0 -0700
@@ -340,15 +340,7 @@
}
if (listpad) {
-int maxx, maxy;
-getmaxyx(listpad,maxx,maxy);
-if (nitems maxy) {
- delwin(listpad);
- listpad= newpad(nitems+1, total_width);
- if (!listpad) ohshite(failed to create larger baselist pad);
-} else if (nitems maxy) {
- werase(listpad);
-}
+werase(listpad);
}
sortinplace();
diff -ru dpkg-1.13.24.orig/dselect/pkgtop.cc dpkg-1.13.24/dselect/pkgtop.cc
--- dpkg-1.13.24.orig/dselect/pkgtop.cc 2006-06-21 06:41:12.0 -0700
+++ dpkg-1.13.24/dselect/pkgtop.cc 2006-10-25 03:47:51.0 -0700
@@ -139,6 +139,7 @@
const char *p;
const struct pkginfo *pkg= table[index]-pkg;
const struct pkginfoperfile *info= pkg-available;
+ int screenline = index - topofscreen;
wattrset(listpad, selected ? listsel_attr : list_attr);
@@ -146,7 +147,7 @@
if (verbose) {
- mvwprintw(listpad,index,0, %-*.*s ,
+ mvwprintw(listpad,screenline,0, %-*.*s ,
status_hold_width, status_hold_width,
gettext(eflagstrings[pkg-eflag]));
wprintw(listpad, %-*.*s ,
@@ -164,14 +165,14 @@
wattrset(listpad, selected ? listsel_attr : list_attr);
waddch(listpad, ' ');
- mvwprintw(listpad,index,priority_column-1, %-*.*s,
+ mvwprintw(listpad,screenline,priority_column-1, %-*.*s,
priority_width, priority_width,
pkg-priority == pkginfo::pri_other ? pkg-otherpriority :
gettext(prioritystrings[pkg-priority]));
} else {
- mvwaddch(listpad,index,0, eflagchars[pkg-eflag]);
+ mvwaddch(listpad,screenline,0, eflagchars[pkg-eflag]);
waddch(listpad, statuschars[pkg-status]);
waddch(listpad,
/* fixme: keep this feature? */
@@ -182,7 +183,7 @@
waddch(listpad, wantchars[table[index]-selected]);
wattrset(listpad, selected ? listsel_attr : list_attr);
- wmove(listpad,index,priority_column-1); waddch(listpad,' ');
+ wmove(listpad,screenline,priority_column-1); waddch(listpad,' ');
if (pkg-priority == pkginfo::pri_other) {
int i;
const char *p;
@@ -198,22 +199,22 @@
}
-mvwprintw(listpad,index,section_column-1, %-*.*s,
+mvwprintw(listpad,screenline,section_column-1, %-*.*s,
section_width, section_width,
pkg-section ? pkg-section : ?);
-mvwprintw(listpad,index,package_column-1, %-*.*s ,
+mvwprintw(listpad,screenline,package_column-1, %-*.*s ,
package_width, package_width, pkg-name);
if (versioninstalled_width)
- mvwprintw(listpad,index,versioninstalled_column, %-*.*s ,
+ mvwprintw(listpad,screenline,versioninstalled_column, %-*.*s ,
versioninstalled_width, versioninstalled_width,
Bug#395140: dselect memory usage is high
Package: dselect Version: 1.13.22 Severity: normal dselect select seems to take about 48 MB while displaying the packages, this causes a small-memory system (32MB) to go heavily into swap. A quick run with valgrind --tool=massif reveals that about 15MB are allocated by 'newpad'. Apparently dselect creates a 2-line ncursed pad to hold the package list. Since the same information is also present as part of the in-memory package database, it might be possible to save the memory by generating a smaller pad for just the part of the list that's being shown at any given time. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.33 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages dselect depends on: ii dpkg 1.13.22 package maintenance system for Deb ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-13 GCC support library ii libncurses5 5.5-3 Shared libraries for terminal hand ii libstdc++6 4.1.1-13The GNU Standard C++ Library v3 dselect recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387863: util-linux: Small issue with clockless systems
Package: util-linux Version: 2.12r-10 Severity: normal I'm having a minor issue with a small mipsel system which does not have any hardware clock (so it can not keep track of time accross reboots). I set up the system's clock using ntpdate, but that can only happen once the network is up, which only happens after various partitions are mounted. In the mean time I'd like the system to have an approximate idea of time, if only just to have periodic fsck checks work as expected. My proposal would be to add the following in /etc/init.d/hwclockfirst.sh, before the first HWCLOCKACCESS test: if [ $FIRST = yes ] [ -f /var/log/wtmp ] \ [ `date +%s` -lt `date +%s -r /var/log/wtmp` ]; then date -s `date -r /var/log/wtmp` fi The idea is that the date should not be earlier than the last reboot date as taken from /var/log/wtmp, and that we can use that as a good-enough estimate for the purposes of running fsck checks at boot time. It'd be fine too if this was under an additional configuration setting which could be set under /etc/defaults. Versions of packages util-linux depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libncurses5 5.5-3 Shared libraries for terminal hand ii libslang22.0.6-3 The S-Lang programming library - r ii libuuid1 1.39-1 universally unique id library ii lsb-base 3.1-15 Linux Standard Base 3.1 init scrip ii zlib1g 1:1.2.3-13 compression library - runtime Thanks, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387861: initscripts: hwclockfirst.sh should run before checkroot.sh
Package: initscripts Version: 2.86.ds1-15 Severity: normal I'm having some minor time issues at boot time on a small mipsel system. I made the following observations about the system: /etc/init.d/checkroot.sh has a small header indicating hwclockfirst should be started. However in /etc/rcS.d, S10checkroot.sh is before S18hwclockfirst.sh. As a result the root filesystem is checked before the clock is first adjusted. Versions of packages initscripts depends on: ii debianutils 2.17Miscellaneous utilities specific t ii e2fsprogs1.39-1 ext2 file system utilities and lib ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii lsb-base 3.1-15 Linux Standard Base 3.1 init scrip ii mount2.12r-10Tools for mounting and manipulatin I should also indicate that hwclockfirst.sh is provided by the util-linux package which is currently at version 2.12r-10. This is a recently installed system (used the etch beta3 installer). Thanks, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386976: Patch might make it into upstream release
I've been talking with upstream maintainer Matt Johnston and it looks like a version of this patch should make it into the next upstream release. Hope this helps, -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386976: dropbear does not work on low entropy systems
Package: dropbear
Version: 0.48.1-1
I'm hitting the same problem as in bugs #310732 and #355414 - trying to
run dropbear on a small mipsel system, but /dev/random does not have
enough entropy. This makes dropbear unreliable on this system without
a recompile.
The attached patch adds a -u runtime option for using urandom.
Would this be an acceptable solution ?
Thanks,
--
Michel Walken Lespinasse
Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie. -- Dennis Miller
diff -ru dropbear-0.48.1.orig/Makefile.in dropbear-0.48.1.urandom/Makefile.in
--- dropbear-0.48.1.orig/Makefile.in2006-03-11 20:52:51.0 -0800
+++ dropbear-0.48.1.urandom/Makefile.in 2006-09-11 05:14:42.0 -0700
@@ -20,7 +20,8 @@
dss.o bignum.o \
signkey.o rsa.o random.o \
queue.o \
- atomicio.o compat.o fake-rfc2553.o
+ atomicio.o compat.o fake-rfc2553.o \
+ common-runopts.o
SVROBJS=svr-kex.o svr-algo.o svr-auth.o sshpty.o \
svr-authpasswd.o svr-authpubkey.o svr-session.o svr-service.o \
@@ -34,7 +35,7 @@
CLISVROBJS=common-session.o packet.o common-algo.o common-kex.o \
common-channel.o common-chansession.o termcodes.o
loginrec.o \
tcp-accept.o listener.o process-packet.o \
- common-runopts.o circbuffer.o
+ circbuffer.o
KEYOBJS=dropbearkey.o gendss.o genrsa.o
diff -ru dropbear-0.48.1.orig/cli-runopts.c
dropbear-0.48.1.urandom/cli-runopts.c
--- dropbear-0.48.1.orig/cli-runopts.c 2006-03-11 20:52:52.0 -0800
+++ dropbear-0.48.1.urandom/cli-runopts.c 2006-09-11 04:54:00.0
-0700
@@ -63,6 +63,9 @@
#ifdef DEBUG_TRACE
-vverbose\n
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ -uuse urandom device\n
+#endif
,DROPBEAR_VERSION, cli_opts.progname);
}
@@ -99,6 +102,9 @@
#ifdef ENABLE_CLI_REMOTETCPFWD
cli_opts.remotefwds = NULL;
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ opts.use_urandom_dev = 0;
+#endif
/* not yet
opts.ipv4 = 1;
opts.ipv6 = 1;
@@ -188,6 +194,11 @@
debug_trace = 1;
break;
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ case 'u':
+ opts.use_urandom_dev = 1;
+ break;
+#endif
case 'F':
case 'e':
case 'c':
diff -ru dropbear-0.48.1.orig/dropbearconvert.c
dropbear-0.48.1.urandom/dropbearconvert.c
--- dropbear-0.48.1.orig/dropbearconvert.c 2006-03-11 20:52:51.0
-0800
+++ dropbear-0.48.1.urandom/dropbearconvert.c 2006-09-11 05:22:26.0
-0700
@@ -24,6 +24,7 @@
/* This program converts to/from Dropbear and OpenSSH private-key formats */
#include includes.h
+#include runopts.h
#include signkey.h
#include buffer.h
#include dbutil.h
@@ -66,6 +67,9 @@
/* It's hard for it to get in the way _too_ much */
debug_trace = 1;
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ opts.use_urandom_dev = 0;
+#endif
/* get the commandline options */
if (argc != 5) {
diff -ru dropbear-0.48.1.orig/dropbearkey.c
dropbear-0.48.1.urandom/dropbearkey.c
--- dropbear-0.48.1.orig/dropbearkey.c 2006-03-11 20:52:51.0 -0800
+++ dropbear-0.48.1.urandom/dropbearkey.c 2006-09-11 05:20:45.0
-0700
@@ -45,6 +45,7 @@
*
*/
#include includes.h
+#include runopts.h
#include signkey.h
#include buffer.h
#include dbutil.h
@@ -79,6 +80,9 @@
#ifdef DEBUG_TRACE
-v verbose\n
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ -u use urandom device\n
+#endif
,progname);
}
@@ -101,6 +105,10 @@
unsigned int keysize;
int printpub = 0;
+#ifdef DROPBEAR_URANDOM_DEV
+ opts.use_urandom_dev = 0;
+#endif
+
/* get the commandline options */
for (i = 1; i argc; i++) {
if (argv[i] == NULL) {
@@ -135,6 +143,11 @@
debug_trace = 1;
break;
#endif
+#ifdef DROPBEAR_URANDOM_DEV
+ case 'u':
+ opts.use_urandom_dev = 1;
+ break;
+#endif
default:
fprintf(stderr, Unknown argument
%s\n, argv[i]);
printhelp(argv[0]);
diff -ru dropbear-0.48.1.orig/options.h dropbear-0.48.1.urandom/options.h
--- dropbear-0.48.1.orig/options.h 2006-03-11
Bug#385100: Etch beta3 failure on mipsel (emulated)
Package: installation-reports Boot method: CD Image version: etch beta3 mipsel netinst. Also tried daily built image (aug 28) Date: August 28, 2006 Machine: DECstation 5000/200, simulated using gxemul (gxemul -e3max) Comments: I did not succeed with the install. I was trying to follow gxemul installation instructions from http://gavare.se/gxemul/gxemul-stable/doc/guestoses.html#declinux I've been successful following these instructions to install Sarge 31r2, but not so with the Etch installer. Before executing 'load installer components from CD' I can execute a shell and run /bin/archdetect; it returns mipsel/r3k-kn02 which is proper. I also make a copy of /bin/archdetect into /bin/archdetect.orig at this point. When executing 'load installer components from CD', the installer first complains about the lack of modules for my kernel. This is expected since I'm using a different kernel than the one provided by debian. Shortly after that the installer tries to unpack the archdetect module and fails while trying to run it. The error message is Loading archdetect failed for unknown reasons. Aborting. If I execute a shell again, I see that /bin/archdetect has been overwriten when pool/main/h/hw-detect/archdetect_1.40_mipsel.udeb was installed. When running the new /bin/archdetect executable I get: /bin/archdetect: /lib/libdebian-installer.so.4: version `LIBDI_4.5' not found (required by /bin/archdetect) I can still run /bin/archdetect.orig and see mipsel/r3k-kn02 as expected. I believe the pool/main/h/hw-detect/archdetect_1.40_mipsel.udeb file on the etch beta3 mipsel CDrom is not at the correct version. This seems similar to bug #320916 which happened a year ago, but I did not figure out from that how I can work around the issue. Thanks, -- Michel Walken Lespinasse Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie. -- Dennis Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327442: hdparm package misses acpi support
Package: hdparm Version: 6.1-2 Severity: wishlist The hdparm package has support for setting drive parameters depending on APM power events. However, there is no such support for ACPI power events. Maybe this could be added ? Or is there a nicer way to make ACPI backwards compatible with APM event handlers ? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.31 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages hdparm depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an hdparm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311480: hotplug: size of CF cards is not rescanned when reloading usb-storage
Package: hotplug Version: 0.0.20040329-22 Severity: wishlist I have a digital camera (nikon coolpix) that stores pictures on CF cards. The camera has an usb interface, with the usb-storage driver I can mount the camera's CF card as my /dev/sda1 drive. This works fine with hotplug. There is one small issue when using multiple CF cards with different sizes though: if I power off the camera, change the CF card and power it back on, the kernel does not figure out that the /dev/sda drive size has changed, and this leads to errors when trying to mount /dev/sda1 again. As a workaround, I came up with the following script in /etc/hotplug/usb/usb-storage: #! /bin/sh # Local script - re-detect USB storage card capacity. echo scsi remove-single-device 0 0 0 0 /proc/scsi/scsi echo scsi add-single-device 0 0 0 0 /proc/scsi/scsi This works fine for my setup - however, I'll agree that the 0 0 0 0 parameters are really specific and should ideally be auto-detected in some way (this is probably doable by parsing some files in /proc). Is there an architectural reason why such functionality should not be integrated in the default hotplug scripts ? Cheers, -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.30 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages hotplug depends on: ii bash 2.05b-26The GNU Bourne Again SHell ii debconf 1.4.30.13 Debian configuration management sy ii grep 2.5.1.ds1-4 GNU grep, egrep and fgrep ii modutils 2.4.26-1.2 Linux module utilities ii procps 1:3.2.1-2 The /proc file system utilities ii sed 4.1.2-8 The GNU sed stream editor -- debconf information: hotplug/ignore_pci_class_display: true hotplug/net_agent_policy: hotplug * hotplug/usb_keyboard: hotplug/static_module_list: hotplug/x11_usbmice_hack: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
