Bug#858373: help needed to complete regression fix for apache2 Bug#858373

[Brian Kroth]

Hi, sorry for the delay. Gmail filed this one into spam :-(

Unfortunately, I don't have access to that environment anymore to confirm.
I'll pass this on to the folks that do so hopefully they can.

My recollection from this issue was that I'd tested it against different
package versions and the 400 ErrorDocuments had worked beforehand (we used
them for ModSec types of things primarily, and I'm confident that mode was
working well before hand and after), though possibly not in that particular
protocol error context. I vaguely recall having issues reproducing a
working ErrorDocument with non-cgi methods in that protocol error mode
style test as well, but I don't recall if rhat was only in the newer
versions of the software that I had been testing with or true before that
update as well.

Anyways, thanks much for following up. Sorry I don't have more info to
offer at the moment.

Cheers,
Brian

On Fri, Jul 21, 2017, 08:44 Antoine Beaupré <anar...@orangeseeds.org> wrote:

> TL;DR: New proposed package (deb7u11) doesn't ctually show a new
> regression, please test:
>
>
> https://people.debian.org/~anarcat/debian/wheezy-lts/apache2_2.2.22-13+deb7u11_amd64.changes
>
> In particular, Brian Kroth: are you *sure* you had that ErrorDocument
> 400 working in apache2_2.2.22-13+deb7u7 (ie. before the DLA-841-1
> upload)? In my tests, it didn't actually work at all. It wouldn't
> trigger a segfault, but the CGI script wouldn't get called either. In
> the above package, we don't segfault anymore, but we yield a 400 + 500
> error message (because the ErrorDocument fails). The solution, here, is
> obviously to update to a later Apache version (e.g. update to jessie,
> really) to get that functionality working, from my perspective.
>
> More technical details follow.
>
> On 2017-07-21 09:24:00, Stefan Fritsch wrote:
> > Hi Antoine,
> >
> > On Wednesday, 19 July 2017 15:45:20 CEST Antoine Beaupre wrote:
> >> As I mentioned in the #858373 bug report, I started looking at fixing
> >> the regression introduced by the 2.2.22-13+deb7u8 upload, part of
> >> DLA-841-1. The problem occurs when a CGI(d) ErrorDocument is configured
> >> to handle 400 error messages that can be triggered with a simple "GET /
> >> HTTP/1.0\n\n". Such a request segfaults Apache in Wheezy right now.
> >
> >> Unfortunately, re-introducing the protocol initialization code isn't
> >> sufficient: it does fix the segfaults, but the ErrorDocument handling is
> >> not quite working yet. Instead of seeing the output of the
> >> ErrorDocument, after 10 seconds, I get the raw 400 message, doubled with
> >> a 500 error document warning:
> >
> >> Note that I have also tried to see if sending "\r\n" instead of just
> >> "\n" in my "hello world" example would work around the issue: it
> >> doesn't, unfortunately.
> >>
> >> I am at a loss as where to go from here, to be honest. The patch
> >> (attached) at least fixes the segfault, which resolves the primary issue
> >> at hand here (DoS by crashing processes!) but it would be nice to
> >> actually fix the ErrorDocument as well..
> >
> > This sounds familiar. Maybe it's simply broken in 2.2.22. Can you
> compare with
> > 2.2.22-13+deb7u7 if that bug has been there already?
>
> Well, the problem is - how do I reproduce this? I can't generate the
> same 400 error message in deb7u7 (I tried!) with the previous techniques
> because the new request handling code isn't there. That is, the
> following query just works:
>
> # printf "GET / HTTP/1.0\n\n" | nc localhost 80 | head -1
> HTTP/1.1 200 OK
>
>
> Furthermore, generating a 400 error, when it works in deb7u7, doesn't
> trigger the ErrorDocument - not sure why:
>
> # printf "G ET / HTTP/1.0\r\n\r\n" | nc localhost 80
> HTTP/1.1 400 Bad Request
> Date: Fri, 21 Jul 2017 13:40:48 GMT
> Server: Apache/2.2.22 (Debian)
> Vary: Accept-Encoding
> Content-Length: 302
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> 
> 
> Apache/2.2.22 (Debian) Server at wheezy.raw Port 80
> 
>
> Logs show the following:
>
> [Fri Jul 21 13:40:48 2017] [error] [client 127.0.0.1] Invalid URI in
> request G ET / HTTP/1.0
>
> ... whether or not the 400 ErrorDocument directive is present. Notice
> how the ErrorDocument isn't triggered at all here.
>
> Of course, a 404 ErrorDocument still works correctly:
>
> # printf "GET /wtf HTTP/1.0\r\n\r\n" | nc localhost 80
> HTTP/1.1 404 Not Found
> Date: Fri, 21 Ju

Bug#858373: apache2: segfaults upon recieving bad request when using worker/event mpm and cgid errordoc

[Brian Kroth]

Package: apache2.2-common
Version: 2.2.22-13+deb7u8
Severity: normal
Tags: security

Dear Maintainer,

We have some websites running on Debian Wheezy, so still using Apache 
2.2.22, that are configured either in Worker or Event MPM (so are using 
mod_cgid in what follows), and have a custom "ErrorDocument 400" 
directive that points at a perl script for providing custom ModSecurity 
error.


I haven't dug up an older version of the package from snapshots to 
confirm this, but I think that since the recently backported 
HttpProtocolOptions directive to that version (BTW, where was that 
announced - I had to run strings on the binary to find it), I've been 
seeing a lot of segfault/coredumps registered in the Apache error logs.


After some analysis, I've found that I can reproduce the error with a 
fairly trivial shell command:


# echo -ne "GET / HTTP/1.0\n" | nc $some_website 80

From the coredump, I was able to find that this line (1371) in the 
cgid_handler() code in the modules/generators/mod_cgid.c source file has 
a null pointer issue on the r->protocol field:


is_included = !strcmp(r->protocol, "INCLUDED");

Seems like a bit of a security issue to me.

No combination of adjustments to the HttpProtocolOptions directive 
seemed to help from what I could see.


I also haven't been able to reproduce this issue on a Prefork MPM 
backend webserver.


Varying the details of the perl ErrorDocument script's implementation 
don't appear to help either (eg: it still occurs even with a simple 
hello world script).


The error still occurs if I disable ModSecurity, but leave the 
ErrorDocument for 400 messages.


Let me know if you need any more details or have any questions.

Thanks,
Brian

-- Package-specific info:
List of /etc/apache2/mods-enabled/*.load:
 alias auth_basic authn_file authz_default authz_groupfile
 authz_host authz_user autoindex cgid deflate dir env expires
 headers include info mime mod-security negotiation reqtimeout
 rewrite rpaf setenvif shib2 ssl status unique_id userdir*
 (A * means that the .conf file for that module is not enabled in
  /etc/apache2/mods-enabled/)

-- System Information:
Debian Release: 7.11
 APT prefers oldstable
 APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2 depends on:
ii  apache2-mpm-worker  2.2.22-13+deb7u8
ii  apache2.2-common2.2.22-13+deb7u8

apache2 recommends no packages.

apache2 suggests no packages.

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.22-13+deb7u8
ii  apache2.2-bin  2.2.22-13+deb7u8
ii  lsb-base   4.1+Debian8+deb7u1
ii  mime-support   3.52-1+deb7u1
ii  perl   5.14.2-21+deb7u4
ii  procps 1:3.3.3-3

Versions of packages apache2.2-common recommends:
pn  ssl-cert  

Versions of packages apache2.2-common suggests:
pn  apache2-doc 
pn  apache2-suexec | apache2-suexec-custom  
ii  lynx-cur [www-browser]  2.8.8dev.12-2+deb7u1

-- no debconf information

Bug#844666: libpam-ldap-186: regression: reads from the wrong conf file

[Brian Kroth]

Brian Kroth <bpkr...@gmail.com> 2016-11-23 15:44:
FYI, the patch I had attached last time is wrong.  I'd just copied and 
pasted from the old one, but that used cdbs, whereas this doesn't.  I 
think this one should be better, though I'm no packaging expert.


Let me know if you have any comments or questions.

Thanks,
Brian


Ack, also missed a build depends on dh-exec in that one.

Brian

Bug#845681: wishlist: libpam-ldap-standalone: a libpam-ldap package copy that can be used with libpam-ldapd

[Brian Kroth]

Package: libpam-ldap
Version: 186-1+caejessie4
Severity: wishlist

Dear Maintainer,

As described in [1] and elsewhere, the nslcd variant of libpam-ldap, 
libpam-ldapd, doesn't currently provide the ability to specify per 
service pam stack ldap configs in order to override on on a per service 
basis various authentication/authorization ldap filters, search bases, 
etc.  libpam-ldap does provide such functionality via the config= 
parameter to its pam_ldap.so module within each pam server stack config.


However, aside from a library naming conflict, the two packages could be 
compatible.  That is, one can mix libpam-ldapd's pam_ldap.so and 
libpam-ldap's pam_ldap.so in the same stack, so long as they're 
named/referenced differently so that they're each loaded separately.


Attached is a patch which adjusts the libpam-ldap package to also 
produce a copy of itself under a different library install location and 
package name, libpam-ldap-standalone, in order to facilitate just that 
ability.  Note, it also includes the patches for reading from the usual 
config file that I submitted in bug #844666.


There are comments within the patch to hopefully help flush out the 
details of the expected use cases and configs.


In my example I've disabled most debconf control of the 
pam_ldap_standalone.so module into the various /etc/pam.d/common-* 
stacks, as it's not intended to be a replacement for those, but rather a 
tack on for specific services.  Instead, libpam-ldapd is supposed to 
handle the brunt of the /etc/pam.d/common-* work.


Let me know if you have any questions/comments.

Thanks,
Brian

[1] <https://lists.arthurdejong.org/nss-pam-ldapd-users/2016/msg00114.html>


-- System Information:
Debian Release: 8.6
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpam-ldap-standalone depends on:
ii  libc6   2.19-18+deb8u6
ii  libldap-2.4-2   2.4.40+dfsg-1+deb8u2
ii  libpam-runtime  1.1.8-3.1+deb8u1
ii  libpam0g1.1.8-3.1+deb8u1+b1

libpam-ldap-standalone recommends no packages.

Versions of packages libpam-ldap-standalone suggests:
ii  libnss-ldapd  0.9.4-3+deb8u1
ii  libpam-ldapd  0.9.4-3+deb8u1

-- no debconf information
diff -u -ruN libpam-ldap-186/debian/changelog libpam-ldap-186.cae.standalone/debian/changelog
--- libpam-ldap-186/debian/changelog	2016-04-09 16:14:51.0 -0500
+++ libpam-ldap-186.cae.standalone/debian/changelog	2016-11-25 13:17:12.663261899 -0600
@@ -1,3 +1,16 @@
+libpam-ldap (186-1+caejessie4) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backporting for jessie (RT #430785).
+  * Also update debian/rules to use the old /etc/pam_ldap.conf file by default
+instead of /etc/ldap.conf
+  * Fixup build rules for pure dh instead of cdbs.
+  * Don't let it copy the /etc/ldap.conf file in - let debconf handle that as
+before.
+  * Add a libpam-ldap-standalone package.
+
+ -- Brian Kroth <bpkr...@gmail.com>  Fri, 28 Oct 2016 17:13:57 -0500
+
 libpam-ldap (186-1) unstable; urgency=medium
 
   * New upstream release
diff -u -ruN libpam-ldap-186/debian/control libpam-ldap-186.cae.standalone/debian/control
--- libpam-ldap-186/debian/control	2016-04-04 07:26:09.0 -0500
+++ libpam-ldap-186.cae.standalone/debian/control	2016-11-25 13:45:23.258026883 -0600
@@ -6,6 +6,7 @@
 Standards-Version: 3.9.7
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
+   dh-exec (>= 0.3),
libldap2-dev,
libpam0g-dev,
libsasl2-dev,
@@ -22,3 +23,27 @@
  user authentication system. Using it along with libnss-ldapd or libnss-ldap
  allows LDAP to entirely replace other lookup methods (such as NIS or
  flat-file) for system account tables.
+
+Package: libpam-ldap-standalone
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}, libpam-runtime (>= 1.0.1-6), libpam0g (>= 1.1.3-2)
+Suggests: libnss-ldapd, libpam-ldapd
+# libpam-ldap-standalone is only intended to be used in combination with
+# libpam-ldapd.  It doesn't make sense to combine it with itself.
+# NOTE: We have to include a version in the match, else libpam-ldapd (which
+# Provides libpam-ldap) will also be matched by the Conflicts rule.
+Conflicts: libpam-ldap (>= 0)
+Description: Pluggable Authentication Module for LDAP
+ This package provides an interface between an LDAP server and the PAM
+ user authentication system. Using it along with libnss-ldapd or libnss-ldap
+ allows LDAP to entirely replace other lookup methods (such as NIS or
+ flat-file) for system account tables.
+ .
+ NOTE: This is essentially a copy of the libpam-ldap package that's intended to
+ coeexist with the libpam-ldapd package (which conflicts w

Bug#844666: libpam-ldap-186: regression: reads from the wrong conf file

[Brian Kroth]

FYI, the patch I had attached last time is wrong.  I'd just copied and 
pasted from the old one, but that used cdbs, whereas this doesn't.  I 
think this one should be better, though I'm no packaging expert.


Let me know if you have any comments or questions.

Thanks,
Brian
diff -u -ruN pam-ldap.bak/libpam-ldap-186/debian/changelog pam-ldap/libpam-ldap-186.cae/debian/changelog
--- pam-ldap.bak/libpam-ldap-186/debian/changelog	2016-04-09 16:14:51.0 -0500
+++ pam-ldap/libpam-ldap-186.cae/debian/changelog	2016-11-23 14:42:06.996563643 -0600
@@ -1,3 +1,15 @@
+libpam-ldap (186-1+caejessie3) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backporting for jessie (RT #430785).
+  * Also update debian/rules to use the old /etc/pam_ldap.conf file by default
+instead of /etc/ldap.conf
+  * Fixup build rules for pure dh instead of cdbs.
+  * Don't let it copy the /etc/ldap.conf file in - let debconf handle that as
+before.
+
+ -- Brian Kroth <bpkr...@gmail.com>  Fri, 28 Oct 2016 17:13:57 -0500
+
 libpam-ldap (186-1) unstable; urgency=medium
 
   * New upstream release
diff -u -ruN pam-ldap.bak/libpam-ldap-186/debian/rules pam-ldap/libpam-ldap-186.cae/debian/rules
--- pam-ldap.bak/libpam-ldap-186/debian/rules	2016-04-04 00:47:35.0 -0500
+++ pam-ldap/libpam-ldap-186.cae/debian/rules	2016-11-23 14:42:29.804817626 -0600
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+#export DH_VERBOSE=1
+
 export DEB_BUILD_MAINT_OPTIONS= hardening=+bindnow
 
 %:
@@ -7,4 +9,30 @@
 
 override_dh_auto_configure:
 	dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH) \
-	--with-ldap-lib=openldap
+	--with-ldap-lib=openldap \
+	--with-ldap-conf-file=/etc/pam_ldap.conf \
+	--with-ldap-secret-file=/etc/pam_ldap.secret
+
+override_dh_install:
+	dh_install
+	
+	# remove the provided ldap.conf file from /etc
+	# (the old debian package didn't provide one directly either)
+	rm -f debian/libpam-ldap/etc/ldap.conf
+	rm -f debian/libpam-ldap/etc/pam_ldap.conf
+	# same goes for the ldap.secret file
+	rm -f debian/libpam-ldap/etc/ldap.secret
+	rm -f debian/libpam-ldap/etc/pam_ldap.secret
+	# rename man page
+	mv debian/libpam-ldap/usr/share/man/man5/pam_ldap.5 \
+		debian/libpam-ldap/usr/share/man/man5/pam_ldap.conf.5
+	# change all references from /etc/ldap.{conf,secret} to /etc/pam_ldap.{conf,secret}
+	for file in debian/libpam-ldap/usr/share/man/man5/pam_ldap.conf.5 \
+	debian/libpam-ldap/usr/share/libpam-ldap/ldap.conf \
+	debian/libpam-ldap/usr/share/doc/libpam-ldap/examples/chfn \
+	debian/libpam-ldap/usr/share/doc/libpam-ldap/examples/chsh ; do \
+		sed	-e 's,ldap.conf,pam_ldap.conf,' \
+			-e 's,ldap.secret,pam_ldap.secret,' \
+			< $$file > $$file-sed; \
+		mv $$file-sed $$file; \
+	done

Bug#844666: libpam-ldap-186: regression: reads from the wrong conf file

[Brian Kroth]

Package: libpam-ldap
Version: 186-1
Severity: important

Dear Maintainer,

FYI, I was working on backporting libpam-ldap-186 for our local 
jessie/wheezy machines to address the issues described in bug #844665 
and found that the new package organization dropped the Debian tweaks 
that cause it to read from /etc/pam_ldap.conf by default, instead it 
reads from /etc/ldap.conf, thus breaking existing installs.  I didn't 
see any mention of a config file location redirection or warning on 
upgrade.  This could cause a lot of problems for folks on upgrade once 
stretch is released.


Attached is a small tweak to the debian/rules file to reinstate the old 
behavior.


Let me know if you have any questions.

Thanks,
Brian

-- System Information:
Debian Release: 8.6
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpam-ldap depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u6
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2
ii  libpam-runtime 1.1.8-3.1+deb8u1
ii  libpam0g   1.1.8-3.1+deb8u1+b1

libpam-ldap recommends no packages.

Versions of packages libpam-ldap suggests:
ii  libnss-ldap  265-3+b1

-- debconf information excluded
diff -u -ru libpam-ldap-186/debian/changelog libpam-ldap-186.cae/debian/changelog
--- libpam-ldap-186/debian/changelog	2016-04-09 16:14:51.0 -0500
+++ libpam-ldap-186.cae/debian/changelog	2016-11-17 15:47:12.175824737 -0600
@@ -1,3 +1,12 @@
+libpam-ldap (186-1+caejessie1) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backporting for jessie.
+  * Also update debian/rules to use the old /etc/pam_ldap.conf file by default
+instead of /etc/ldap.conf
+
+ -- Brian Kroth <bpkr...@gmail.com>  Fri, 28 Oct 2016 17:13:57 -0500
+
 libpam-ldap (186-1) unstable; urgency=medium
 
   * New upstream release
diff -u -ru libpam-ldap-186/debian/rules libpam-ldap-186.cae/debian/rules
--- libpam-ldap-186/debian/rules	2016-04-04 00:47:35.0 -0500
+++ libpam-ldap-186.cae/debian/rules	2016-11-17 15:04:38.363947140 -0600
@@ -7,4 +7,21 @@
 
 override_dh_auto_configure:
 	dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH) \
-	--with-ldap-lib=openldap
+	--with-ldap-lib=openldap \
+	--with-ldap-conf-file=/etc/pam_ldap.conf \
+	--with-ldap-secret-file=/etc/pam_ldap.secret
+
+binary-post-install/libpam-ldap::
+	# rename man page
+	mv $(MY_INSTR_DIR)/usr/share/man/man5/pam_ldap.5 \
+		$(MY_INSTR_DIR)/usr/share/man/man5/pam_ldap.conf.5
+	# change all references from /etc/ldap.{conf,secret} to /etc/pam_ldap.{conf,secret}
+	for file in $(MY_INSTR_DIR)/usr/share/man/man5/pam_ldap.conf.5 \
+	$(MY_INSTR_DIR)/usr/share/libpam-ldap/ldap.conf \
+	$(MY_INSTR_DIR)/usr/share/doc/libpam-ldap/examples/chfn \
+	$(MY_INSTR_DIR)/usr/share/doc/libpam-ldap/examples/chsh ; do \
+		sed	-e 's,ldap.conf,pam_ldap.conf,' \
+			-e 's,ldap.secret,pam_ldap.secret,' \
+			< $$file > $$file-sed; \
+		mv $$file-sed $$file; \
+	done

Bug#844665: libpam-ldap returns user provided case sensitive data instead of server provided data

[Brian Kroth]

Package: libpam-ldap
Version: 184-8.7+b1
Severity: normal

Dear Maintainer,

This is a related follow up to bug #842202, in which I reported that 
lightdm exhibited issues when users logged in, via pam_ldap stack, using 
mixed case usernames (eg: Bkroth instead of bkroth).


As noted there, the LDAP schemas allow for the uid attribute to match 
via case insensitive "equality" matches.


However, the issue is that pam_ldap then (somewhat naturally) returns 
the user provided data (it did successfully return a search after all) 
to the application rather than the server provided uid ldap attribute 
response.


Some applications perform their own NSS based lookup and ignore the data 
provided by pam, but others (eg: lightdm) just use the data returned by 
pam.


The following patch basically backports the fixed behavior from 
libpam-ldap-186 to have pam return the authoritative server data 
instead.  Additionally, it includes the optimization of only fetching 
the necessary attributes in the ldap call rather than all of them 
associated with the user.



Alternatively, one could just backport 186 for jessie/wheezy, but that 
package as it stands in stretch currently has an issue with the default 
ldap conf file location (which I'll get to in a moment).


Let me know if you have any questions.

Thanks,
Brian


-- System Information:
Debian Release: 8.6
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpam-ldap depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u6
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2
ii  libpam-runtime 1.1.8-3.1+deb8u1
ii  libpam0g   1.1.8-3.1+deb8u1+b1

libpam-ldap recommends no packages.

Versions of packages libpam-ldap suggests:
ii  libnss-ldap  265-3+b1

-- debconf information excluded
diff -u -ruN libpam-ldap-184/debian/changelog libpam-ldap-184.cae/debian/changelog
--- libpam-ldap-184/debian/changelog	2016-11-17 15:42:41.0 -0600
+++ libpam-ldap-184.cae/debian/changelog	2016-11-17 15:47:30.976030991 -0600
@@ -1,3 +1,13 @@
+libpam-ldap (184-8.7+b1+caejessie1) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport a few features from libpam-ldap-186:
+  * Noramlize username by returning server provided attribute instead of user
+provided attribute.
+  * Also limit the attributes fetched from the LDAP server.
+
+ -- Brian Kroth <bpkr...@gmail.com>  Thu, 17 Nov 2016 15:32:37 -0600
+
 libpam-ldap (184-8.7) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u -ruN libpam-ldap-184/debian/patches/limit_fetched_attrs libpam-ldap-184.cae/debian/patches/limit_fetched_attrs
--- libpam-ldap-184/debian/patches/limit_fetched_attrs	1969-12-31 18:00:00.0 -0600
+++ libpam-ldap-184.cae/debian/patches/limit_fetched_attrs	2016-11-17 15:31:19.997366146 -0600
@@ -0,0 +1,32 @@
+--- a/pam_ldap.c
 b/pam_ldap.c
+@@ -2560,6 +2560,20 @@
+   return ret;
+ }
+ 
++static char *_pam_ldap_attrs[] = {
++  "host",
++  "authorizedService",
++  "shadowExpire",
++  "shadowFlag",
++  "shadowInactive",
++  "shadowLastChange",
++  "shadowMax",
++  "shadowMin",
++  "shadowWarning",
++  "uidNumber",
++  NULL
++};
++
+ static int
+ _get_user_info (pam_ldap_session_t * session, const char *user)
+ {
+@@ -2618,7 +2632,7 @@
+ }
+ 
+   rc = ldap_search_s (session->ld, ssd->base, ssd->scope,
+-		  filter, NULL, 0, );
++		  filter, _pam_ldap_attrs, 0, );
+ 
+   if (rc != LDAP_SUCCESS &&
+   rc != LDAP_TIMELIMIT_EXCEEDED && rc != LDAP_SIZELIMIT_EXCEEDED)
diff -u -ruN libpam-ldap-184/debian/patches/normalize_username libpam-ldap-184.cae/debian/patches/normalize_username
--- libpam-ldap-184/debian/patches/normalize_username	1969-12-31 18:00:00.0 -0600
+++ libpam-ldap-184.cae/debian/patches/normalize_username	2016-11-17 15:29:58.724472042 -0600
@@ -0,0 +1,45 @@
+--- a/pam_ldap.c
 b/pam_ldap.c
+@@ -2652,7 +2652,13 @@
+   return PAM_BUF_ERR;
+ }
+ 
+-  session->info->username = strdup (user);
++  rc = _get_string_value (session->ld, msg, session->conf->userattr,
++>info->username);
++  if (rc != PAM_SUCCESS)
++{
++  session->info->username = strdup (user);
++}
++
+   if (session->info->username == NULL)
+ {
+   ldap_msgfree (res);
+@@ -,6 +3339,13 @@
+ 		pam_set_item (pamh, PAM_USER,
+ 			  (void *) session->info->tmpluser);
+ 	}
++  else if (rc == PAM_SUCCESS && session->info->username != NULL)
++{
++  (void) pam_set_data (pamh, PADL_LDAP_AUTH

Bug#842202: [Pkg-xfce-devel] Bug#842202: lightdm combined with pam_ldap and mixed case usernames results in broken group enumeration, etc.

[Brian Kroth]

Hi, took me a while to get around to, but for the record I finally filed
one upstream here:
https://bugs.launchpad.net/lightdm/+bug/1642725

Thanks,
Brian

On Fri, Oct 28, 2016 at 3:11 AM, Yves-Alexis Perez <cor...@debian.org>
wrote:

> On Wed, 2016-10-26 at 15:51 -0500, Brian Kroth wrote:
> > The attached patch essentially just adjusts lightdm's behavior to
> > perform the same sort of NSS lookup to get the true username.
>
> Thanks for the report. This is not really Debian related, can you push the
> bug
> report and the patch upstream in launchpad for discussion? Thanks in
> advance.
>
> Regards,
> --
> Yves-Alexis

Bug#590998: ldap-utils: centralize LDAP parameters

[Brian Kroth]

reassign 590998 libpam-ldap
thanks

On Fri, Jul 30, 2010 at 04:10:36PM -0400, Patricio Rojo wrote:
I apologize if this is the wrong package in which to file this wishlist. 
I'll appreciate forwarding in that case.


I manage users in one machine with LDAP.  I'm very suprised that I need 
to change the address of my ldap server, I had to edit each of



/etc/ldap/ldap.conf
/etc/pam_ldap.conf
/etc/libnss-ldap.conf


Wouldn't make more sense to have only one line with such information, 
and maybe that file can be specified from the others?


/etc/ldap/ldap.conf is a configuration file for the LDAP library. 
/etc/pam_ldap.conf and /etc/libnss-ldap.conf are configuration files for

specific applications that use this library.  The two should not be
conflated; there are a number of reasons why you may use different values
for each (and the syntax between the config files isn't even the same).

However, the nss_ldap and pam_ldap config files *could* be merged; this has
already been done in Ubuntu.  So this is something that the maintainer of
these packages could at least consider doing in Debian, I think. 
Reassigning to libpam-ldap.


--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


Hi, I know this is ages ago, but as I'm currently digging into related 
issues and about submit other bugs so ran across this one, I figured I 
should comment my own opinion on this issue.


I get the desire to have reduced complexity and fewer places to change 
the same thing where possible, but given that much of that can be 
automated via debconf for simple setups now, please don't unnecessarily 
combine /etc/libnss-ldap.conf and /etc/pam_ldap.conf.


Having naming services be separate from authentication/authorization is 
a very flexible and powerful feature that other systems like nslcd and 
sssd can't do.  It allows overall machine control vs per service control 
in very nice and complex ways.


For instance, on an NFS server, one may wish all uid/gids to show up 
(possibly with different homeDirectory attribute maps), but only select 
certain ones to be able to authenticate to certain services.  This is 
easy to do when libnss-ldap.conf is separate from pam_ldap.conf and 
pam_ldap.so can target different config= files for different pam service 
stacks.


I know that one could continue to specify those config= parameters 
manually in order to keep them separate if desired, but that'd break age 
old defaults for existing long term setups.




Thanks,
Brian

Bug#842202: lightdm combined with pam_ldap and mixed case usernames results in broken group enumeration, etc.

[Brian Kroth]

Package: lightdm
Version: 1.10.3-3
Severity: normal

Dear Maintainer,

We have an environment that uses pam_ldap to authenticate most of our 
users.


Due to some nuances of the core (open)LDAP schema, the uid attribute 
will return success on "equality" matches even if the requested query 
includes spaces or mixed case.  See Also:

http://www.openldap.org/lists/openldap-software/200204/msg00337.html

So, if you attempt to login as " Bkroth" instead of "bkroth", the LDAP 
server will respond successfully.


Unfortunately, pam_ldap (probably reasonably) just takes that to mean 
that the provided username is valid and passes it through (it did ask 
for an equality match after all).  A better thing to do at that stage 
would probably be to hand back the value in the uid attribute that the 
LDAP server responded with, but I'll leave that for a separate pam_ldap 
bug report.  Somewhat related:

https://forums.opensuse.org/showthread.php/445925-pam_ldap-username-case-sensitivity-on-OpenSuSE-11-2

The trouble is that lightdm, takes the user provided value and 
1) assigns it to the USER and LOGNAME environment variables, and
2) uses it to try and initgroups(), which then fails (group memberships 
in LDAP are usually done with fully qualified DNs which don't do the 
loose equality matching described above).


The combination of incorrect USER environment variables and missing 
supplementary groups causes lots of other problems.


Note that programs like su, login, ssh, etc. don't exhibit this behavior 
since they turn around and perform a lookup of the "true" username 
against the NSS database again when populating the environment 
variables.  Here's a few examples:

https://github.com/shadow-maint/shadow/blob/master/src/su.c#L928
https://github.com/openssh/openssh-portable/blob/V_6_7/session.c#L1179

The attached patch essentially just adjusts lightdm's behavior to 
perform the same sort of NSS lookup to get the true username.


I also have a dumbed down sample test program to illustrate the issue 
outside of lightdm in case it helps.


Let me know if you have any questions or comments.

Thanks,
Brian

-- System Information:
Debian Release: 8.6
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lightdm depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.20-0+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u6
ii  libgcrypt201.6.3-2+deb8u2
ii  libglib2.0-0   2.42.1-1+b1
ii  libpam-systemd 215-17+deb8u5
ii  libpam0g   1.1.8-3.1+deb8u1+b1
ii  libxcb11.10-3+b1
ii  libxdmcp6  1:1.1.1-1+b1
ii  lightdm-gtk-greeter [lightdm-greeter]  1.8.5-2

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+7

Versions of packages lightdm suggests:
ii  accountsservice  0.6.37-3+b1
ii  upower   0.99.1-3.2

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information excluded
diff -u -ruN orig/lightdm-1.10.3/debian/changelog patched/lightdm-1.10.3/debian/changelog
--- orig/lightdm-1.10.3/debian/changelog	2014-11-04 14:58:17.0 -0600
+++ patched/lightdm-1.10.3/debian/changelog	2016-10-26 14:53:31.191071134 -0500
@@ -1,3 +1,10 @@
+lightdm (1.10.3-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * With a patch to normalize the username returned by PAM via an NSS lookup.
+
+ -- Brian Kroth <bpkr...@gmail.com>  Wed, 26 Oct 2016 13:40:56 -0500
+
 lightdm (1.10.3-3) unstable; urgency=medium
 
   * debian/patches:
diff -u -ruN orig/lightdm-1.10.3/debian/patches/normalize_username.patch patched/lightdm-1.10.3/debian/patches/normalize_username.patch
--- orig/lightdm-1.10.3/debian/patches/normalize_username.patch	1969-12-31 18:00:00.0 -0600
+++ patched/lightdm-1.10.3/debian/patches/normalize_username.patch	2016-10-26 15:15:16.560403085 -0500
@@ -0,0 +1,52 @@
+Description: normalize the provided username by performing an nss lookup
+ Some passwd/shadow NSS database providers (eg: LDAP) may accept a username
+ with mixed case and/or spaces in it when performing lookups.  For instance, 
+ " Bkroth" instead of "bkroth".  In such environments, we should use the actual
+ value returned by the NSS database lookup, when performing operations like
+ initgroups and pam_putenv.  NOTE: Ultimately, this is really working around a
+ bug in the core LDAP schema's uid attribute which accepts case insensitive and
+ substring matches and pam_ldap(d) which simply pass the

Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked

[Brian Kroth]

Felipe Sateler  2016-09-10 12:45:

Control: forwarded -1 https://github.com/systemd/systemd/issues/4122

On 9 September 2016 at 19:36, Michael Biebl  wrote:

Am 10.09.2016 um 00:26 schrieb Michael Biebl:

So, you'll also need to mask that name, i.e
dbus-org.freedesktop.resolve1.service


https://github.com/systemd/systemd/issues/1873
is somewhat related.
Upstream's position on this is, that masks apply only on that particular
name and not for any existing aliases (symlinks)


Thanks for the backstory.


I interpret upstream's comment differently. They say "any alias
pointed to it is masked", which (applied to this case) should mean
that masking dbus-org.freedesktop.resolve1.service should not cause
systemd-resolved.service to be masked. I would expect the other way
around to work though: all aliases *should* resolve to the same unit,
and if that final unit is masked it should not be started.


Right, that's what I was expecting too.


Side complaint: /usr/share/dbus-1/system-services/ is not listed as one 
of the directories searched for units in systemd.unit or systemd.service 
or any other man page I've been able to find.


I sort of guessed at dbus activation, but didn't see where that would 
have been configured since I was expecting all units to live in either 
/lib/systemd/, /run/systemd/ or /etc/systemd/ (excluding user units for 
this case which make sense to live in /usr/lib/systemd/ to me).


Thanks,
Brian

Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked

[Brian Kroth]

Oh, I guess I have an idea what's happening.
systemd-resolve triggers the start via D-Bus activation.


Yeah, that was my guess as well.  Just seemed wrong to me given that the 
unit providing that service is masked.



/usr/share/dbus-1/system-services/org.freedesktop.resolve1.service


For the record, masking org.freedesktop.resolve1.service didn't help.


has
SystemdService=dbus-org.freedesktop.resolve1.service

dbus-org.freedesktop.resolve1.service is a symlink to
systemd-resolved.service

So, you'll also need to mask that name, i.e
dbus-org.freedesktop.resolve1.service


But masking that one did.

# systemd-resolve debian.org
debian.org: resolve call failed: Unit dbus-org.freedesktop.resolve1.service is 
masked.

Thanks,
Brian

Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked

[Brian Kroth]

Michael Biebl <bi...@debian.org> 2016-09-09 23:33:

Am 09.09.2016 um 22:47 schrieb Brian Kroth:

Package: systemd
Version: 230-7~bpo8+2
Severity: normal
Tags: security

Dear Maintainer,

systemd appears to start systemd-resolved, even when it's been masked,
in the background even when an unprivileged user calls systemd-resolve.

However, calls to start the service manually via systemctl are rejected
(correctly).

This seems like an error and a potential security issue.

Details on my test and setup are as follows.  Let me know if you have
any questions or need any other information.


I assume you have libnss-resolve installed and enabled (in /etc/nsswitch)?


No:

# grep '^[^#]' /etc/nsswitch.conf 
passwd: files ldap

group:  files ldap
shadow: files 
hosts:  files dns

networks:   files
protocols:  db files
services:   db files
ethers: db files
rpc:db files
netgroup:   files

Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked

[Brian Kroth]

Package: systemd
Version: 230-7~bpo8+2
Severity: normal
Tags: security

Dear Maintainer,

systemd appears to start systemd-resolved, even when it's been masked, 
in the background even when an unprivileged user calls systemd-resolve.


However, calls to start the service manually via systemctl are rejected 
(correctly).


This seems like an error and a potential security issue.

Details on my test and setup are as follows.  Let me know if you have 
any questions or need any other information.


Thanks,
Brian

# readlink -f /etc/systemd/system/systemd-resolved.service 
/dev/null


# systemctl status systemd-resolved.service | head -n3
Failed to dump process list, ignoring: Unit systemd-resolved.service is masked.
● systemd-resolved.service
  Loaded: masked (/dev/null; bad)
  Active: inactive (dead)

# systemctl start systemd-resolved.service
Failed to start systemd-resolved.service: Unit systemd-resolved.service is 
masked.

# systemctl status systemd-resolved.service | head -n3
Failed to dump process list, ignoring: Unit systemd-resolved.service is masked.
? systemd-resolved.service
  Loaded: masked (/dev/null; bad)
  Active: inactive (dead)

# pgrep -l -f systemd-resolved || echo "no systemd-resolved process found"
no systemd-resolved process found

# netstat -lnp | grep :53 || echo "nothing listening on port 53"
nothing listening on port 53


$ systemd-resolve debian.org
debian.org: 2001:41c8:1000:21::21:4
   2001:4f8:8:36::1deb:22
   2001:610:1908:b000::148:14
   140.211.15.34
   149.20.20.22
   5.153.231.4
   128.31.0.62
   130.89.148.14

-- Information acquired via protocol DNS in 214.8ms.
-- Data is authenticated: yes


# systemctl status systemd-resolved.service 
● systemd-resolved.service - Network Name Resolution

  Loaded: loaded (/lib/systemd/system/systemd-resolved.service; masked; vendor 
preset: enabled)
 Drop-In: /lib/systemd/system/systemd-resolved.service.d
  └─resolvconf.conf
  Active: active (running) since Thu 2016-08-25 09:23:51 CDT; 28s ago
Docs: man:systemd-resolved.service(8)
  http://www.freedesktop.org/wiki/Software/systemd/resolved
  
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
  
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
 Process: 8468 ExecStartPost=/bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || echo 
"nameserver 127.0.0.53" | /sbin/resolvconf -a systemd-resolved (code=exited, 
status=0/SUCCESS)
Main PID: 8465 (systemd-resolve)
  Status: "Processing requests..."
   Tasks: 1
 CPU: 18ms
  CGroup: /system.slice/systemd-resolved.service
  └─8465 /lib/systemd/systemd-resolved

# pgrep -l -f systemd-resolved || echo "no systemd-resolved process found"
8465 systemd-resolve

# sudo netstat -lnp | grep :53 || echo "nothing listening on port 53"
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN  
8465/systemd-resolv
udp0  0 127.0.0.53:53   0.0.0.0:*   
8465/systemd-resolv


# systemd-delta

[MASKED] /etc/systemd/system/systemd-timesyncd.service -> 
/lib/systemd/system/systemd-timesyncd.service
[EXTENDED]   /etc/systemd/system/systemd-timesyncd.service -> 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[EXTENDED]   /lib/systemd/system/watchdog.service -> 
/etc/systemd/system/watchdog.service.d/01-fixup-syslog-messages-file.conf
[MASKED] /etc/systemd/system/systemd-resolved.service -> 
/lib/systemd/system/systemd-resolved.service
[EXTENDED]   /etc/systemd/system/systemd-resolved.service -> 
/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf
[EXTENDED]   /lib/systemd/system/syslog.socket -> 
/etc/systemd/system/syslog.socket.d/more-receive-buffer.conf
[EXTENDED]   /lib/systemd/system/systemd-journald.service -> 
/etc/systemd/system/systemd-journald.service.d/syslog-deps.conf
[EXTENDED]   /lib/systemd/system/rc-local.service -> 
/lib/systemd/system/rc-local.service.d/debian.conf
[MASKED] /etc/systemd/system/dev-hugepages.mount -> 
/lib/systemd/system/dev-hugepages.mount
[MASKED] /etc/systemd/system/dev-mqueue.mount -> 
/lib/systemd/system/dev-mqueue.mount
[MASKED] /etc/systemd/system/systemd-networkd.service -> 
/lib/systemd/system/systemd-networkd.service
[OVERRIDDEN] /etc/udev/rules.d/80-net-setup-link.rules -> 
/lib/udev/rules.d/80-net-setup-link.rules


-- Package-specific info:

-- System Information:
Debian Release: 8.5
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10.95-4~bpo8+2
ii  

Bug#832117: cfengine2: lock name collision with slow preceeding actions results in some rules not being performed

[Brian Kroth]

Package: cfengine2
Version: 2.2.10-5
Severity: normal

Hi,

So, first let me preface this with the understanding that cfengine2 is 
very old code and not being maintained anymore, so I'll understand if 
you don't accept the patches I'm proposing.  However, since it isn't 
changing much, cfengine2 is more more or less stable and works as 
expected.  Also, we have *a lot* cfinputs rules and it would be far more 
costly to switch to another system right now than to simply fix this 
bug.  The fact that Debian still has a package for cfengine2 makes me 
think that enough other folks are in this boat that I thought it might 
be worth posting a bug on our experiences.



Ok, so the bug:

1) A long series of preceeding actionsequences.

In our case, just a long set of copy rules.

For instance:

control:
actionsequence = ( copy links )
copy:
somehost::
		# stuff that takes at least 1 minute 



Turns out that the main reason they're slow is due to poor bdb based 
lock implementation that causes an fdatasync() for every 
GetLock()/ReleaseLock(), which may be in the thousands.


There's also some time spent waiting for TCP buffers to fill before 
exchanging small stat info for already up to date files.



2) A colliding lock name for certain actions.

In our case it was for several long symlink rules:

links:
somehost::
/usr/share/wordpress/wp-content/plugins/advanced-custom-fields 
-> /home/vhosts-wp/plugins.dev/advanced-custom-fields
/usr/share/wordpress/wp-content/plugins/advanced-custom-fields-pro 
-> /home/vhosts-wp/plugins.dev/advanced-custom-fields-pro
...

These all get the following lock name:
_usr_share_wordpress_wp_content_plugins_advanced_c__home_vhosts_wp_plugins_dev_advanced_custom_fields

Turns out that MakeLinks() in do.c, when attempting to compose a unique 
lock name for the rule, truncates both the LHS and RHS and combines 
them, before handing it off to GetLock() in locks.c.


Well, GetLock() does it's own quasi checksum based lock name 
deduplication, so the initial lock name truncation in MakeLinks() 
actually prevents GetLock() from doing the right thing.


Turns out that the copy action processes is also affected by this same 
lock name truncation issue.



3) Since the copy action (in our example) takes more than 1 minute, the 
check to GetLastLock() in GetLock() fails due to comparing the timestamp 
of the first completed colliding link action with the start of the full 
DoTree() cfagent run, rather than the first time any link action 
actually took place.




To address these things (and document them further), I've made a github 
repo here:

https://github.com/bpkroth/cfengine2/issues/1 (correctness)
https://github.com/bpkroth/cfengine2/issues/2 (performance optimizations)


Addressing the performance of the locking by batching up fdatasync() 
calls to the cfengine_lock_db [1] helps with all of these issues (in our 
situation) and reduces the runtime of cfagent by 50% (in our situation), 
however it's ultimately just a workaround.


Adding the TCP_NODELAY flag also helps a bit with the stat delays, but 
it's a relatively minor optimization compared with the fdatasyncs [2].


Changing the timestamp checking to be based on the action sequence also 
mitigates the issue, though the changes were too invasive to be 
complete [3].


Simply not truncating the lock name (at least as much) and filling the 
available lock name buffer size to allow GetLock() to do its own 
checksum uniquifying also solves this particular issue more directly 
[4].


[1] 
https://github.com/bpkroth/cfengine2/commit/5543c87f5fb102cecbe60b3d2d6b258c9d8f0baa
[2] 
https://github.com/bpkroth/cfengine2/commit/a2807337e37ecad20f6cf65a4b3bdc0ac1b29651
[3] 
https://github.com/bpkroth/cfengine2/commit/f346e8153bbe325924d751bd3ccdd830b88f2671
[4] 
https://github.com/bpkroth/cfengine2/commit/f6658d41c7d0df76088adace1760aa9d9743403f


Anyways, here are two other branches that also turn these patches into 
quilt patches for Debian packaging:

https://github.com/bpkroth/cfengine2/tree/debian/wheezy/cfengine2_2.2.10-5+patches
https://github.com/bpkroth/cfengine2/tree/debian/jessie/cfengine2_2.2.10-5+patches
(they're actually the same given that jessie and wheezy have identical 
source packages for cfengine2)



We've been running with them widespread for about a week without any issues.


Let me know if you have any questions or comment.

Thanks for your time.

Cheers,
Brian


*** Reporter, please consider answering these questions, where appropriate ***

  * What led up to the situation?
  * What exactly did you do (or not do) that was effective (or
ineffective)?
  * What was the outcome of this action?
  * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.5
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 

Bug#831894: systemd: "Out of memory" timing error when calling systemctl in pipeline

[Brian Kroth]

Package: systemd
Version: 215-17+deb8u4
Severity: normal

Dear Maintainer,

Hi, I was trying to do some simple systemctl scripting for some service change 
rollouts and discovered what looks to be a timing bug related to calling 
systemctl in a pipeline.

When called like this we get an "Out of memory." error on most of our VMs, 
though they certainly have enough free memory available on the system.

I have not yet observed the issue on a physical machine yet.

# systemctl list-unit-files | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | 
xargs -r -t systemctl stop
systemctl stop inetd.service openbsd-inetd.service 
Out of memory.



If on the other hand I do the same thing with either a slightly different (and 
less heavy weight) systemctl call at the beginning, or else add a short splay 
before the xargs call, then it works without the error:

# systemctl list-units | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | xargs 
-r -t systemctl stop
systemctl stop inetd.service 
(no memory error reported)


# systemctl list-unit-files | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | ( 
sleep .05; xargs -r -t systemctl stop )
systemctl stop inetd.service openbsd-inetd.service
(no memory error reported)


In case it helps, below is the output of running the first command with the 
SYSTEMD_LOG_LEVEL=debug environment variable set.

I've tried to strace it to see where exactly the error turns up, but that seems 
to disrupt the timing enough that the error message does not appear.

Let me know if you need any other info.

Thanks,
Brian


# systemctl list-unit-files | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | 
SYSTEMD_LOG_LEVEL=debug xargs -r -t systemctl stop
systemctl stop inetd.service openbsd-inetd.service 
Calling manager for StopUnit on inetd.service, replace

Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=StopUnit cookie=1 reply_cookie=0 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=GetUnit cookie=2 reply_cookie=0 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/inetd_2eservice 
interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0 
error=n/a
Adding /org/freedesktop/systemd1/job/8238541 to the set
Calling manager for StopUnit on openbsd-inetd.service, replace
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=StopUnit cookie=4 reply_cookie=0 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=GetUnit cookie=5 reply_cookie=0 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/inetd_2eservice 
interface=org.freedesktop.DBus.Properties member=Get cookie=6 reply_cookie=0 
error=n/a
Adding /org/freedesktop/systemd1/job/8238541 to the set
Out of memory.
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=UnitNew cookie=2 reply_cookie=0 error=n/a
Got D-Bus request: org.freedesktop.systemd1.Manager.UnitNew() on 
/org/freedesktop/systemd1
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobNew cookie=3 reply_cookie=0 error=n/a
Got D-Bus request: org.freedesktop.systemd1.Manager.JobNew() on 
/org/freedesktop/systemd1
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1/unit/inetd_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 
reply_cookie=0 error=n/a
Got D-Bus request: org.freedesktop.DBus.Properties.PropertiesChanged() on 
/org/freedesktop/systemd1/unit/inetd_2eservice
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1/unit/inetd_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 
reply_cookie=0 error=n/a
Got D-Bus request: org.freedesktop.DBus.Properties.PropertiesChanged() on 
/org/freedesktop/systemd1/unit/inetd_2eservice
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1/job/8238541 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=9 
reply_cookie=0 error=n/a
Got D-Bus request: org.freedesktop.DBus.Properties.PropertiesChanged() on 
/org/freedesktop/systemd1/job/8238541
Got message type=signal sender=n/a destination=n/a 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoved cookie=12 reply_cookie=0 error=n/a
Got D-Bus request: 

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Awesome, thanks!

On Tue, Jun 28, 2016, 15:15 Michael Biebl <bi...@debian.org> wrote:

> Control: tags -1 = patch
>
> Hi Brian,
>
> Am 28.06.2016 um 03:09 schrieb Brian Kroth:
> > Hi, I've done a little bit of testing with the patch and it does indeed
> > appear to fix the issue.  Here's the resulting diff for the package I
> > built.  Let me know if you need anything else.
>
> Thanks for that. This should be sufficient, I guess. I've marked your
> bug report as patch available and tagged it so it shows up at [1]
> I'll plan to cherry-pick this patch for the next Debian stable release
> (8.6)
>
> Regards,
> Michael
> [1]
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=jessie-backport
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Brian Kroth <bpkr...@gmail.com> 2016-06-24 13:21:

Michael Biebl <bi...@debian.org> 2016-06-23 23:41:

Control: tags -1 + moreinfo

Hi Brian

Am 23.06.2016 um 19:09 schrieb Brian Kroth:

Per [1], the current version of systemd in Debian Jessie (v215) has an
issue that makes the "quiet" kernel boot parameter override values of
LogLevel= in the /etc/systemd/system.conf file (mine has LogLevel=info
explicitly set) and explicitly sets it to "notice" instead of the
documented default of "info".

There's a simple patch [2] that fixes this that I'd like to suggest
backporting.



That commit seem okayish for a jessie backport



[2]
<https://cgit.freedesktop.org/systemd/systemd/commit/?id=5e07a79e84ab8b045b9df1a2719f14fc84471a1d>


A simple cherry-pick of 5e07a79e on top of v215 fails.
Have you backported this commit for v215 and given it some testing?
If so, can you attach the (tested) patch to this bug report.

Regards,
Michael


Hi, sorry, I ran out of time before the weekend.  I'll try and finish 
testing that and get back to you sometime on Monday.


I'll note that I had to use the following to cherrypick the patch from 
git since the changes to src/shared/log.c (just comments) failed to 
match anything nearby:


# git format-patch -1 5e07a79e84ab8b045b9df1a2719f14fc84471a1d -- 
src/core/main.c

Cheers,
Brian


Hi, I've done a little bit of testing with the patch and it does indeed 
appear to fix the issue.  Here's the resulting diff for the package I 
built.  Let me know if you need anything else.


Thanks,
Brian
diff -u -ruN systemd_215-17+deb8u4.debian/debian/changelog systemd_215-17+deb8u4.1.debian/debian/changelog
--- systemd_215-17+deb8u4.debian/debian/changelog	2016-03-03 12:51:40.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/changelog	2016-06-24 13:08:05.0 -0500
@@ -1,3 +1,10 @@
+systemd (215-17+deb8u4.1) UNRELEASED; urgency=medium
+
+  * Backport systemd patch to not overwrite the LogLevel set in
+    /etc/systemd/system.conf (Bug #828006).
+
+ -- Brian Kroth <bpkr...@gmail.com>  Fri, 24 Jun 2016 13:03:25 -0500
+
 systemd (215-17+deb8u4) stable; urgency=medium
 
   [ Martin Pitt ]
diff -u -ruN systemd_215-17+deb8u4.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch systemd_215-17+deb8u4.1.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch
--- systemd_215-17+deb8u4.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch	1969-12-31 18:00:00.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch	2016-06-24 13:18:43.0 -0500
@@ -0,0 +1,42 @@
+From 5e07a79e84ab8b045b9df1a2719f14fc84471a1d Mon Sep 17 00:00:00 2001
+From: Lennart Poettering <lenn...@poettering.net>
+Date: Wed, 4 Feb 2015 01:42:49 +0100
+Subject: [PATCH] core: don't reset log level to NOTICE if we get quiet on the
+ kernel cmdline
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+quiet should really just have an effect on the stuff we dump on the
+console, not what we log elsewhere.
+
+Hence:
+
+debug on kernel cmdline → interpreted by every tool, turns up
+log levels to "debug" everywhere.
+
+quiet on kernel cmdline → interpreted only by PID 1 (and
+obviously the kernel) no alteration of the max log level, but
+turns off status output.
+
+http://lists.freedesktop.org/archives/systemd-devel/2014-December/026271.html
+---
+ src/core/main.c |2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/src/core/main.c b/src/core/main.c
+index 0480bc8..0749f04 100644
+--- a/src/core/main.c
 b/src/core/main.c
+@@ -367,8 +367,6 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
+ 
+ } else if (streq(key, "quiet") && !value) {
+ 
+-log_set_max_level(LOG_NOTICE);
+-
+ if (arg_show_status == _SHOW_STATUS_UNSET)
+ arg_show_status = SHOW_STATUS_AUTO;
+ 
+-- 
+1.7.10.4
+
diff -u -ruN systemd_215-17+deb8u4.debian/debian/patches/series systemd_215-17+deb8u4.1.debian/debian/patches/series
--- systemd_215-17+deb8u4.debian/debian/patches/series	2016-03-03 12:51:40.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/patches/series	2016-06-24 13:12:57.0 -0500
@@ -95,6 +95,7 @@
 timesyncd-allow-two-missed-replies-before-reselectin.patch
 timesyncd-don-t-reset-polling-interval-when-reselect.patch
 backlight-Avoid-error-when-state-restore-is-disabled.patch
+core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch
 
 ## Cherry-picked patches:
 util-avoid-considering-dpkg-temporary-files-relevant.patch


signature.asc
Description: Digital signature

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Michael Biebl <bi...@debian.org> 2016-06-23 23:41:

Control: tags -1 + moreinfo

Hi Brian

Am 23.06.2016 um 19:09 schrieb Brian Kroth:
> Per [1], the current version of systemd in Debian Jessie (v215) has an

issue that makes the "quiet" kernel boot parameter override values of
LogLevel= in the /etc/systemd/system.conf file (mine has LogLevel=info
explicitly set) and explicitly sets it to "notice" instead of the
documented default of "info".

There's a simple patch [2] that fixes this that I'd like to suggest
backporting.



That commit seem okayish for a jessie backport



[2]
<https://cgit.freedesktop.org/systemd/systemd/commit/?id=5e07a79e84ab8b045b9df1a2719f14fc84471a1d>


A simple cherry-pick of 5e07a79e on top of v215 fails.
Have you backported this commit for v215 and given it some testing?
If so, can you attach the (tested) patch to this bug report.

Regards,
Michael


Hi, sorry, I ran out of time before the weekend.  I'll try and finish 
testing that and get back to you sometime on Monday.


I'll note that I had to use the following to cherrypick the patch from 
git since the changes to src/shared/log.c (just comments) failed to 
match anything nearby:


# git format-patch -1 5e07a79e84ab8b045b9df1a2719f14fc84471a1d -- 
src/core/main.c

Cheers,
Brian


signature.asc
Description: Digital signature

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Package: systemd
Version: 215-17+deb8u4
Severity: normal

Dear Maintainer,

Per [1], the current version of systemd in Debian Jessie (v215) has an 
issue that makes the "quiet" kernel boot parameter override values of 
LogLevel= in the /etc/systemd/system.conf file (mine has LogLevel=info 
explicitly set) and explicitly sets it to "notice" instead of the 
documented default of "info".


There's a simple patch [2] that fixes this that I'd like to suggest 
backporting.


Short of that, it'd be nice if it were documented somewhere (here?) that 
an alternative workaround (aside from just removing "quiet") is to also 
list "systemd.log_level=info" somewhere after quiet in the kernel boot 
parameters (eg: in /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT 
variable).


Without that, lots of things end up not getting logged (eg: service 
start/stops, socket connections, etc.), even though the 
systemd man page and other documentation would appear to imply that the 
default LogLevel should be "info".


Let me know if you need any other info.

Thanks,
Brian

[1] 
[2] 



-- Package-specific info:

-- System Information:
Debian Release: 8.5
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u4
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u1+b1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u4
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u4
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u4

Versions of packages systemd suggests:
pn  systemd-ui  

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]
/etc/systemd/system.conf changed [not included]

-- no debconf information

Bug#756062: arpwatch fails with bad interface vlan14: vlan14: no IPv4 address assigned

[Brian Kroth]

Package: arpwatch
Version: 2.1a15-1.2
Severity: important

Dear Maintainer,

This is very similar to an old bug reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240399

   * What led up to the situation?

I upgraded my arpwatch machine from squeeze to wheezy.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I have a machine with a trunk port on it whose sole purpose is to listen 
for arpwatch and ndpmon data on various vlans.  It has no addresses 
assigned and that is intentional.

   * What was the outcome of this action?

arpwatch under squeeze works on vlan interfaces without addresses 
assigned, it does not any more, but instead fails with the following 
message:

arpwatch: bad interface vlan14: vlan14: no IPv4 address assigned - assuming 
unconfigured interface

   * What outcome did you expect instead?

If I reinstall the squeeze package via dpkg -i I do not have this issue.

Let me know if you need any more details.

Thanks,
Brian

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-0.bpo.4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages arpwatch depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.13-38+deb7u3
ii  libpcap0.8  1.3.0-1

arpwatch recommends no packages.

arpwatch suggests no packages.

-- Configuration Files:
/etc/arpwatch.conf changed [not included]
/etc/default/arpwatch changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743436: liblog4cpp5: long lines can lead to a segfault

[Brian Kroth]

Package: liblog4cpp5
Version: 1.0-4
Severity: important

Dear Maintainer,

   * What led up to the situation?

Long URLs fed to a 64-bit Apache using libapache2-mod-shib2 that talks 
to a shibd that has DEBUG logging enabled would result in segfaults.  
This amounts to a possible DoS.


A backtrace from a core dump gathered returned the following:

#0  0x7f823172bcba in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f82317526a2 in vsnprintf () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7f82298785c6 in log4cpp::StringUtil::vform(char const*, 
__va_list_tag*) () from /usr/lib/liblog4cpp.so.5
#3  0x7f822986b166 in log4cpp::Category::_logUnconditionally(int, char 
const*, __va_list_tag*) () from /usr/lib/liblog4cpp.so.5
#4  0x7f822986a0ce in log4cpp::Category::debug(char const*, ...) () from 
/usr/lib/liblog4cpp.so.5
#5  0x7f822a098724 in shibsp::AbstractSPRequest::getRequestSettings() const 
() from /usr/lib/x86_64-linux-gnu/libshibsp-lite.so.5
#6  0x7f822a0a0832 in 
shibsp::ServiceProvider::doAuthentication(shibsp::SPRequest, bool) const () 
from /usr/lib/x86_64-linux-gnu/libshibsp-lite.so.5
#7  0x7f822a62bf56 in shib_check_user () from 
/usr/lib/apache2/modules/mod_shib_22.so
#8  0x7f8232583090 in ap_run_check_user_id (r=0x7f822baed0a0) at 
request.c:71
#9  0x7f8232585346 in ap_process_request_internal 
(r=r@entry=0x7f822baed0a0) at request.c:214
#10 0x7f8232598ff8 in ap_process_request (r=r@entry=0x7f822baed0a0) at 
http_request.c:280
#11 0x7f8232595f38 in ap_process_http_connection (c=0x7f822dfa4290) at 
http_core.c:190
#12 0x7f823258f510 in ap_run_process_connection (c=0x7f822dfa4290) at 
connection.c:43
#13 0x7f823258f8f8 in ap_process_connection (c=c@entry=0x7f822dfa4290, 
csd=optimized out) at connection.c:190
#14 0x7f823259dc2e in child_main (child_num_arg=child_num_arg@entry=2) at 
prefork.c:667
#15 0x7f823259e382 in make_child (slot=2, s=0x7f8232528818) at prefork.c:768
#16 make_child (s=0x7f8232528818, slot=2) at prefork.c:696
#17 0x7f823259eee6 in perform_idle_server_maintenance (p=optimized out) 
at prefork.c:903
#18 ap_mpm_run (_pconf=_pconf@entry=0x7f823252e028, plog=optimized out, 
s=s@entry=0x7f8232528818) at prefork.c:1107
#19 0x7f8232573826 in main (argc=7, argv=0x7fffcc9f4478) at main.c:755

That led me to the following issue reported by the shib sp:
https://issues.shibboleth.net/jira/browse/SSPCPP-432

Which refers to a fix in log4shib (revision 84) that was backported from 
log4cpp (git revs 602dd07..21d4a52).


http://svn.shibboleth.net/view/utilities?view=revisionrevision=84
http://sourceforge.net/p/log4cpp/patches/search/?q=2083274

As Debian still uses log4cpp with it's squeeze-backports and wheezy 
builds for libapache2-mod-shib2, the fix requires rebuilding log4cpp 
with the attached patch.



   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Turning logging down from DEBUG to INFO works around the problem.

The attached patch fixes the issue even with DEBUG logging enabled.


Let me know if you need any other details.

Thanks,
Brian


-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages liblog4cpp5 depends on:
ii  libc6   2.13-38+deb7u1
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5

Also installed:

ii  libapache2-mod-shib22.4.3+dfsg-5+b1
ii  apache2-mpm-prefork 2.2.22-13+deb7u1

liblog4cpp5 recommends no packages.

liblog4cpp5 suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#743436: forgot to attach the patch

[Brian Kroth]

--- a/src/StringUtil.cpp
+++ b/src/StringUtil.cpp
@@ -35,27 +35,37 @@
 namespace log4cpp {
 
 std::string StringUtil::vform(const char* format, va_list args) {
-	size_t size = 1024;
-	char* buffer = new char[size];
+size_t size = 1024;
+char* buffer = new char[size];
 
-	while (1) {
-	int n = VSNPRINTF(buffer, size, format, args);
+while (1) {
+va_list args_copy;
+
+#if defined(_MSC_VER) || defined(__BORLANDC__)
+args_copy = args;
+#else
+va_copy(args_copy, args);
+#endif
+
+int n = VSNPRINTF(buffer, size, format, args_copy);
+
+va_end(args_copy);
 
-	// If that worked, return a string.
-	if ((n  -1)  (static_castsize_t(n)  size)) {
-		std::string s(buffer);
-		delete [] buffer;
-		return s;
-	}
+// If that worked, return a string.
+if ((n  -1)  (static_castsize_t(n)  size)) {
+std::string s(buffer);
+delete [] buffer;
+return s;
+}
 
-	// Else try again with more space.
+// Else try again with more space.
 size = (n  -1) ?
 n + 1 :   // ISO/IEC 9899:1999
 size * 2; // twice the old size
 
-	delete [] buffer;
-	buffer = new char[size];
-	}
+delete [] buffer;
+buffer = new char[size];
+}
 }
 
 std::string StringUtil::trim(const std::string s) {
@@ -78,8 +88,8 @@
 }
 
 unsigned int StringUtil::split(std::vectorstd::string v,
-   const std::string s,
-   char delimiter, unsigned int maxSegments) {
+   const std::string s,
+   char delimiter, unsigned int maxSegments) {
 v.clear();
 std::back_insert_iteratorstd::vectorstd::string  it(v);
 return split(it, s, delimiter, maxSegments);


signature.asc
Description: Digital signature

Bug#724872: libmemcached sasl support broken in wheezy as well

[Brian Kroth]

I'm running on a wheezy system and I'll note that SASL authentication in 
memcached clients is broken/non-existent there as well.


I started with trying to get it working in php5-memcached.

That's not build with --enable-memcached-sasl, so that's the issue 
there.


However, that doesn't completely work because although libmemcached is 
supposed to be built with SASL by default, its not in the wheezy build 
(1.0.8) due to the bug described here:

http://serverfault.com/a/433113

The attached patch fixes that, but then requires rebuilding dependent 
packages, like php5-memcached, against that new library.



Additionally, I'll note that it'd be nice if memcached were build with 
--enable-sasl-pwdb so that a few simple environment variables 
(SASL_CONF_PATH and MEMCACHED_SASL_PWDB) could be exported in 
/etc/default/memcached in order to use flat password files easily.



Let me know if you need any other details from me.

Thanks,
Brian
Description: Fix SASL build support
 See Also: http://serverfault.com/questions/431552/configuring-sasl-support-in-libmemcached
Author: Brian Kroth bpkr...@gmail.com
Last-Update: 2014-03-27
Forwarded: no

--- a/m4/ax_sasl.m4
+++ b/m4/ax_sasl.m4
@@ -46,9 +46,9 @@
 
 AX_CHECK_LIBRARY([LIBSASL], [sasl/sasl.h], [sasl2],[
   LIBSASL_LDFLAGS=-lsasl2
-  ax_cv_sasl=yes
+  ac_enable_sasl=yes
   ], [
-  ax_cv_sasl=no 
+  ac_enable_sasl=no 
   ])
 
 AM_CONDITIONAL(HAVE_SASL, test x${ac_enable_sasl} = xyes)


signature.asc
Description: Digital signature

Bug#734798: libapache2-mod-rpaf: failure to work with authz allow/deny

[Brian Kroth]

Sergey B Kirpichev skirpic...@gmail.com 2014-01-22 16:21:

On Tue, Jan 21, 2014 at 12:00:45PM -0600, Brian Kroth wrote:

Please try an update package (attached).  Updated patch attached as well.


That does appear to work


Ok.  Vincent, could you test this as well?  If
so, I will merge two bugreports and prepare an update for stable.


however, I think it's incomplete.


Can you elaborate this?  E.g. provide some tests.


I haven't dug into the code to find any tests that this would cause 
problems with yet, I was just noting that the way it's coded currently 
leaves an internal memory structure in a meaningless state.


If the proxy to backend connection is IPv6 (as in our case), then the 
default code for rpaf_cleanup() will attempt to overwrite the 
connection-remote_addr as an IPv4 address:  sa.sin, instead of sa.sin6, 
is assigned the result of apr_inet_addr(connection-remote_ip) which is 
just inet_addr() which doesn't handle AF_INET6 addresses, also never 
correcting the family portion of the apr_sockaddr_t struct.


That data structure is returned to the connection pool and anything that 
might need it after that will have garbage data.


It just seemed to me that both ends of this should be fixed if we're in 
the business of patching it anyways.


Thanks,
Brian


If you look at rpaf_cleanup() (~line 149), there is code very
similar to the main code in change_remote_ip() that undoes the
operation for keepalive connections, however as it stands in the
original code it has the same issue - namely it only handles IPv4.


I don't see issues with keepalive right now:

root@wheezy:~# curl -I -H 'X-Forwarded-For: 192.168.1.40' -v http://localhost/ 
http://localhost/two
* About to connect() to localhost port 80 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 80 (#0)

HEAD / HTTP/1.1
User-Agent: curl/7.26.0
Host: localhost
Accept: */*
X-Forwarded-For: 192.168.1.40


* HTTP 1.1 or later with persistent connection, pipelining supported
 HTTP/1.1 200 OK
HTTP/1.1 200 OK
 Date: Wed, 22 Jan 2014 12:17:57 GMT
Date: Wed, 22 Jan 2014 12:17:57 GMT
 Server: Apache/2.2.22 (Debian)
Server: Apache/2.2.22 (Debian)
 Last-Modified: Mon, 20 Jan 2014 09:16:02 GMT
Last-Modified: Mon, 20 Jan 2014 09:16:02 GMT
 ETag: 16-b1-4f063572f7880
ETag: 16-b1-4f063572f7880
 Accept-Ranges: bytes
Accept-Ranges: bytes
 Content-Length: 177
Content-Length: 177
 Vary: Accept-Encoding
Vary: Accept-Encoding
 Content-Type: text/html
Content-Type: text/html


* Connection #0 to host localhost left intact
* Re-using existing connection! (#0) with host (nil)
* Connected to (nil) (::1) port 80 (#0)

HEAD /two HTTP/1.1
User-Agent: curl/7.26.0
Host: localhost
Accept: */*
X-Forwarded-For: 192.168.1.40


* HTTP 1.1 or later with persistent connection, pipelining supported
 HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
 Date: Wed, 22 Jan 2014 12:17:57 GMT
Date: Wed, 22 Jan 2014 12:17:57 GMT
 Server: Apache/2.2.22 (Debian)
Server: Apache/2.2.22 (Debian)
 Vary: Accept-Encoding
Vary: Accept-Encoding
 Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end


* Closing connection #0


The patch I provided previously attempts to apply the same style fix
to the rpaf_cleanup() code as well.


Thus, I'm not sure we need this part.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734798: libapache2-mod-rpaf: failure to work with authz allow/deny

[Brian Kroth]

Sergey B Kirpichev skirpic...@gmail.com 2014-01-20 18:11:

On Sun, Jan 19, 2014 at 07:27:32PM -0600, Brian Kroth wrote:

Perhaps try the wget command I gave earlier to force it over IPv6
instead.  Then vary the X-Forwarded-For with either IPv4 or IPv6
addresses.


Ok, I see.  It seems this is a duplicate of #726529.


But you are using ipv4, isn't?


No, I'm using both IPv4 and IPv6 on the proxy, but the
communications between proxy and backend are IPv6 only.


Please try an update package (attached).  Updated patch attached as well.


That does appear to work, however, I think it's incomplete.

If you look at rpaf_cleanup() (~line 149), there is code very similar to 
the main code in change_remote_ip() that undoes the operation for 
keepalive connections, however as it stands in the original code it has 
the same issue - namely it only handles IPv4.


The patch I provided previously attempts to apply the same style fix to 
the rpaf_cleanup() code as well.


Let me know if you have any questions.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#734798: libapache2-mod-rpaf: failure to work with authz allow/deny

[Brian Kroth]

Sergey B Kirpichev skirpic...@gmail.com 2014-01-20 00:43:

tags 734798 +moreinfo
thanks

I can't reproduce the problem for apache2-mpm-worker nor for
apache2-mpm-prefork.  See below.

On Thu, Jan 09, 2014 at 10:48:20PM +0100, Vincent CARON wrote:

this is a follow up of bug #697644. I could reproduce the problem today on
two up-to-date Wheezys, and here are the instructions to encounter the bug.

Setup a single default Apache vhost, which we thus may reach with any name.
Eg:

VirtualHost *:80
ServerName rpaf-bug

DocumentRoot /var/www
CustomLog /var/log/apache2/access.log combined

Location /
Order deny,allow
Deny from all
Allow from 1.2.3.4
/Location
/VirtualHost

... where 1.2.3.4 is an IP address of your host. Then on this same host,
try :

$ curl http://localhost/
(denied with Apache default 403 page)
$ curl http://1.2.3.4/
(granted, serves /var/www/default/index.html happily)

So everything's fine till there. Then install libapache2-mod-rpaf and keep
its default config (which trusts 127.0.0.1), and try :

$ curl -H 'X-Forwarded-For: 1.2.3.4' http://localhost/
(denied with Apache default 403 page)
$ tail /var/log/apache2/access.log
...
1.2.3.4 - - [09/Jan/2014:22:15:53 +0100] GET / HTTP/1.1 403 461 - 
curl/7.26.0

... where obviously mod_rpaf works fine (seeing the log) but auth is wrongfully 
denied.
CGIs also get 1.2.3.4 in REMOTE_ADDR. I made several tests, and it's clear that 
Apache
authz against the real client IP (127.0.0.1 above), and not the one in 
X-Forwarded-For.


I still can't reproduce this:

$ sed 's/\#.*$//;s/[[:space:]]\+/ /g;/^ *$/d' 
/etc/apache2/mods-enabled/rpaf.conf
IfModule rpaf_module
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 ::1
/IfModule
$ cat /etc/apache2/sites-enabled/000-default
VirtualHost *:60080
...
Location /files
Order deny,allow
Deny from all
Allow from 1.2.3.4
/Location
...
/VirtualHost

$ HEAD -d http://localhost:60080/files
403 Forbidden
$ HEAD -d -H 'X-Forwarded-For: 1.2.3.4' http://localhost:60080/files
200 OK


Perhaps try the wget command I gave earlier to force it over IPv6 
instead.  Then vary the X-Forwarded-For with either IPv4 or IPv6 
addresses.



$ tail -2 /var/log/apache2/access.log
127.0.0.1 - - [20/Jan/2014:00:20:39 +0400] HEAD /files HTTP/1.1 403 - - 
lwp-request/6.03 libwww-perl/6.04
1.2.3.4 - - [20/Jan/2014:00:20:53 +0400] HEAD /files HTTP/1.1 200 - - 
lwp-request/6.03 libwww-perl/6.04


Without the patch the log's reported client address is correct in my 
case, but the return status is not.  That's because the logs use the 
string form of the client address (remote_addr) whereas mod_authz_host 
uses the binary format (remote_ip).



FYI, I think the patch described in [1], fixes this issue as well.


Which one?  030_ipv6.patch?  


Yes, that's the main one of importance to this ticket.  The others were 
build fixups (as the comments in series tried to explain).



But you are using ipv4, isn't?


No, I'm using both IPv4 and IPv6 on the proxy, but the communications 
between proxy and backend are IPv6 only.


If you look at the original code directly above the patch, for the 
binary format (the part that's checked by things like mod_authz_host) 
it's only overwriting the request's address when treated as an IPv4 
address, so when the X-Forwarded-For address is IPv6 the result is 
incomplete, incorrect, a buffer overflow, or some other sorts of 
badness.


Additionally, since our backend addresses are IPv6 only, the socket 
family (AF_INET6) won't match even if the X-Forwareded-For client is 
IPv4 (AF_INET).


Mind you, I'm not saying a blind memcpy() is necessarily the right 
answer, but that's what Debian was doing before, and it does fix the 
problem.


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#726529: libapache2-mod-rpaf: fails on ipv6 address - bug details and fix

[Brian Kroth]

affects 734798

Hi, I was also running into this after working on some wheezy replacement hosts.

The setup is as follows:

Frontend Proxy (Apache) listens on IPv4 and IPv6 addresses.

It passes requests to backend Apache processes over non-routed IPv6 addresses 
(one per VirtualHost).

mod_rpaf on the backend Apache servers is supposed to fixup REMOTE_ADDR so that 
applications and things like mod_authz_host can be used to restrict access to 
the original source client (eg: /server-status).

However, whenever there was a mod_authz_host directive in place, all requests 
would be rejected with 403 responses.

In looking at the mod_rpaf-2.0.c source code, it appears that it only 
references r.remote_addr.sin, never any r.remote_addr.sin6.  As a result, it 
was not properly rewriting the binary form of the client addresses in the 
request structure, so any checks like mod_authz_host which have to compare 
against that, and not the string form of the address (r.remote_ip) which was 
being copied correctly which is why the logs reflected the right address, even 
though the behavior did not.

This used to work in squeeze (in other words, this bug is a regression), so I 
started examining the code there.  It turns out that Debian was previously 
applying an ipv6 patch for this behavior [1].

I adapted and applied the patch for the new version, and it fixes the issue.  
It is attached along with a few other build fixes found at [2] and [3].  Note 
that the bulk of the patch in [3] doesn't work for the same reason as before - 
it incorrectly assumes that the backend is accessed via IPv4 (AF_INET).

Please let me know if you need any more details (some basic example confs and 
commands are below).

Thanks,
Brian

[1] 
http://sources.debian.net/src/libapache2-mod-rpaf/0.5-3+squeeze1/debian/patches/030_ipv6.patch

[2] 
https://github.com/ttkzw/mod_rpaf-0.6/commit/f96f67ce4b6e3588e7a22394f22d8fb7c3feb242

[3] 
https://github.com/ttkzw/mod_rpaf-0.6/commit/3848870bc419e46b9c49bf4d3403993bab9d1bf6


The details of the confs should look something like this:

fded:1::/64 Frontend server subnet
10.0.1.0/24 Frontend server subnet

fded:ff::/64Backend network.

fded:2::/64 Privileged client subnet
10.0.2.0/24 Privileged client subnet

10.0.3.0/24 Unprivileged client subnet
fded:3::/64 Unprivileged client subnet


- Frontend (also has fded:ff::1 assigned to it so that it can communicate with 
the backends):

Listen [fded:1::1]:80
NameVirtualHost [fded:1::1]:80
VirtualHost fded:1::1:80
ServerName something.domain
ProxyPass / http://[fded:ff::2]:80/ keepalive=on
/VirtualHost

Listen 10.0.1.1:80
NameVirtualHost 10.0.1.1:80
VirtualHost 10.0.1.1:80
ServerName something.domain
ProxyPass / http://[fded:ff::2]:80/ keepalive=on
/VirtualHost


- Backend (only accessible via fded:ff::2):

IfModule rpaf_module
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips fded:ff::1
/IfModule

IfModule mod_status.c
Location /server-status
SetHandler server-status
# Only allow access from some privileged client subnets.
Order Deny,Allow
Deny from All
Allow from 10.0.2.0/24
Allow from fded:2::/64
/Location
/IfModule

Listen [fded:ff::2]:80
NameVirtualHost [fded:ff::2]:80

VirtualHost fded:ff::2:80
ServerName something.domain
/VirtualHost


- Now, attempt to retrieve /server-status

1) From a privileged client (should work, but doesn't without the supplied 
patch):
# wget -4 -O- http://something.domain/server-status
# wget -6 -O- http://something.domain/server-status
(without the patch, only received 403 responses)
(with the patch, received the full output)

2) Bypassing the proxy (this worked, without the patch):
# wget --header 'Host: something.domain' -6 -O- 
http://[fded:ff::2]/server-status
(receive the full output)

3) From an unprivileged client (should not work in either case):
# wget -4 -O- http://something.domain/server-status
# wget -6 -O- http://something.domain/server-status
(receive only 403 responses)
diff -u -ruN libapache2-mod-rpaf_0.6-7-debian/debian/changelog libapache2-mod-rpaf_0.6-7.3-debian/debian/changelog
--- libapache2-mod-rpaf_0.6-7-debian/debian/changelog	2012-06-21 02:40:30.0 -0500
+++ libapache2-mod-rpaf_0.6-7.3-debian/debian/changelog	2014-01-15 14:26:12.0 -0600
@@ -1,3 +1,10 @@
+libapache2-mod-rpaf (0.6-7.3) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Fixes for use with mod_authz_host per #734798, #726529.
+
+ -- Brian Kroth bpkr...@gmail.com  Wed, 15 Jan 2014 12:20:41 -0600
+
 libapache2-mod-rpaf (0.6-7) unstable; urgency=low
 
   * Fix FTBS on a number of archs: add -D_LARGEFILE64_SOURCE to CFLAGS
diff -u -ruN libapache2-mod-rpaf_0.6-7-debian/debian/patches/012_Add-missing-header-for-inet_addr.patch libapache2-mod-rpaf_0.6-7.3-debian/debian/patches/012_Add-missing-header-for-inet_addr.patch

Bug#734798: possible patch

[Brian Kroth]

FYI, I think the patch described in [1], fixes this issue as well.

Cheers,
Brian

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726529#25


signature.asc
Description: Digital signature

Bug#729965: libcurl3 7.21.0-2.1+squeeze5 --insecure regression

[Brian Kroth]

Package: libcurl3
Version: 7.21.0-2.1+squeeze5
Severity: important


Hi, I believe I've found a regression in the recent libcurl3 DSA update.  
Basically, it doesn't seem to be respecting the --insecure option in all 
cases.

This now fails:

# aptitude -PV install libcurl3=7.21.0-2.1+squeeze5
# curl -s -S --insecure https://backend-host-that-does-not-match-service-name  
/dev/null
curl: (51) SSL peer certificate or SSH remote key was not OK

But this succeeds:

# aptitude -PV install libcurl3=7.21.0-2.1+squeeze4
# curl -s -S --insecure https://backend-host-that-does-not-match-service-name  
/dev/null


Unfortunately, I haven't found a good test case for it at publicly 
accessible internet sites.  For instance, these still work as expected:

# curl -s -S --insecure https://74.125.225.40  /dev/null
# curl -s -S https://74.125.225.40  /dev/null
curl: (51) SSL: certificate subject name '*.google.com' does not match target 
host name '74.125.225.40'

So, I guess poke me offline if you need some extra details to help track 
this down.

I'll also note that wheezy versions don't seem to have this issue.

Thanks,
Brian

-- System Information:
Debian Release: 6.0.8
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcurl3 depends on:
ii  ca-certificates20090814+nmu3squeeze1 Common CA certificates
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libgssapi-krb5-2   1.8.3+dfsg-4squeeze7  MIT Kerberos runtime libraries - k
ii  libidn11   1.15-2GNU Libidn library, implementation
ii  libldap-2.4-2  2.4.23-7.3OpenLDAP libraries
ii  libssh2-1  1.2.6-1   SSH2 client-side library
ii  libssl0.9.80.9.8o-4squeeze14 SSL shared libraries
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

libcurl3 recommends no packages.

libcurl3 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729965: better example

[Brian Kroth]

Apparently I didn't look hard enough the first time.  This appears to have the 
same issue:

# curl -s -S --insecure https://www.example.com  /dev/null
curl: (51) SSL peer certificate or SSH remote key was not OK

Let me know if you need anything else.

Thanks,
Brian


smime.p7s
Description: S/MIME cryptographic signature

Bug#685407: updates for squeeze-backports?

[Brian Kroth]

FYI, I'm still seeing this problem in the following kernel from 
squeeze-backports:


Linux version 3.2.0-0.bpo.4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.4.5 (Debian 4.4.5-8) ) #1 SMP Debian 3.2.41-2+deb7u2~bpo60+1

Is the fix going to be backported there too?  We're currently waiting on 
another bug before we can seriously consider rolling with wheezy [1].


Thanks,
Brian

[1] 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658739


signature.asc
Description: Digital signature

Bug#685407: updates for squeeze-backports?

[Brian Kroth]

Ben Hutchings b...@decadent.org.uk 2013-06-17 17:27:

On Mon, Jun 17, 2013 at 09:19:20AM -0500, Brian Kroth wrote:

FYI, I'm still seeing this problem in the following kernel from
squeeze-backports:

Linux version 3.2.0-0.bpo.4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.4.5 (Debian 4.4.5-8) ) #1 SMP Debian 3.2.41-2+deb7u2~bpo60+1

Is the fix going to be backported there too?

[...]

Yes, now that 3.2.46-1 is in stable.


Cool.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#643708: closed by Carsten Schoenert c.schoen...@t-online.de (Re: Bug#643708: icedove does not respect spellchecker.dictionary language settings)

[Brian Kroth]

Sorry for the lack of response.  I was on leave and none of my 
colleagues responded like I'd asked.


I tested this just now and the problem seems to have gone away.  We're 
currently running with icedove from the mozilla squeeze-backports 
(version 17.0.4-1~bpo60+1).


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#658896: not fixed - please don't ignore this bug for wheezy

[Brian Kroth]

Sorry for the late reply, I've been out on leave and for some reason 
wasn't getting the responses to these bugs even though I've subscribed.


I hate to dredge this up again given the release announcement, but 
there's been a lot of confusion about this and related bugs and I think 
our particular problem was lost.


There are two separate issues as I see them:

When using starttls or ldaps:// in a pam_ldap.conf* file, then

1) If I try to do a su non-root-user, then I get a setgid error:

# /bin/su - bkroth
Password:
setgid: Operation not permitted

As was correctly reported, this was an error in squeeze as well, and is 
not our primary concern (though if it were fixed as well, I wouldn't be 
upset :).


2) If I try to sudo (not sudo-ldap), it fails with a setresuid error:

# sudo -s
bpkroth@faitest64's sudo password:
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/bpkroth/1: Operation not permitted
sudo: unable to set supplementary group IDs: Operation not permitted
sudo: unable to execute /bin/bash: Operation not permitted

This *was* working in squeeze just fine.

This is part of the bug that I'm very concerned about.  We depend upon 
it for a number of different things, including automated monitoring and 
repair, authenticating users to specific services such as dovecot, etc.


Also, libpam-ldapd does *not* solve this problem, for two reasons:

a) It doesn't actually fix the setresuid problem (2)!  I've tested this.
edit
Actually, I take that back.  It seems one of the recent updates fixed 
this part at least.

/edit


b) libpam-ldapd can only use a single global configuration file.  We 
need libpam-ldap's (no d) ability to reference different pam_ldap.conf 
files from different /etc/pam.d/service files in order to specify 
different ldap filters, base ou lookups, etc. settings for service 
specific authentications.


For instance, dovecot is configured to only accept users with filter 
custom_acl_attr=mail, whereas sudo (on that same machine) is configured 
to only authenticate users in an ou=Sudo,ou=People part of the ldap 
tree.  There are several other examples of this such as cron, ssh, and 
others.  Note, we also make use of pam_access for certain restrictions, 
but this is an incomplete solution since it doesn't allow attribute or 
ou ldap filters.


On my my colleagues (Simon Fondrie-Teitler) tells me that one or more 
patches were able to fix problem (2), though I've been out on leave and 
don't recall which ones exactly so I'll let him comment with specific 
details on that.


Please let us know what we can help to do to fix this.  We really can't 
move forward on wheezy in our environment without it.


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#682007: [squeeze-backports] NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Raoul Bhatia [IPAX] r.bha...@ipax.at 2013-01-29 11:01:

On 2012-10-12 20:52, Brian Kroth wrote:

Brian Paul Kroth bpkr...@gmail.com 2012-10-11 14:06:

Jonathan Nieder jrnie...@gmail.com 2012-10-01 01:25:

snip/

Once again very sorry for the delay :(

I forgot to disable the DEBUG_INFO and kept filling up my build 
VMs disk during compile.  Then realized I had grabbed the 3.7 rc 
code, which these patches don't apply against.  git checkout 
remotes/stable/linux-3.2.y (results in head 
c74a5e1fe4d0672936c8fb63d7484dfeaa30669c and 3.2.28), seemed to 
fix that.

snip/
Anyways, I just started running that on a machine, so I'll let 
you know if I noticed anything there first before I think about 
pushing it to further places.


Thanks,
Brian


Got another panic using this kernel/set of patches.  The dump is 
attached.


Let me know if you need anything else.


Hi!


Hello!


Has there been any progress regarding this issue?


Not really.  At least not that I'm aware of.


Brian, are you right now using the fsc facility or not?


Yes, with 54 mounts each on about 100 hosts.


If yes, which patches / configure options are you currently using
and how often do you see kernel panics?


Currently we're running this kernel most places:
ii linux-image-3.2.0-0.bpo.2-amd64 3.2.20-1~bpo60+1 Linux 3.2 for 64-bit PCs

With a few hosts gradually moving over to this:
ii linux-image-3.2.0-0.bpo.4-amd64 3.2.35-2~bpo60+1 Linux 3.2 for 64-bit PCs

And one host running 3.2.28 with the set of patches from here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682007#47

We've seen the panic on all of those kernels.  Since it's fairly recent, 
I've attached another dump from the bpo.4 3.2.35 kernel's panic.



Frequency and cause is a little difficult to tease out precisely.  These 
are lab machines and the workload may vary quite substantially based on 
what classes and compute jobs (eg: from condor) happen to be running on 
them at any given time.


Recently (as of the students returning a week and a half ago) we've seen 
this on 6 machines.


Past I see 37 other events in the last 90 days (our log rotation 
period).  Usually their clustered together, so probably tied to a 
particular job's workload.  Unfortunately, those jobs are usually gone 
by the time I see it.



Are there any workarounds to this issue besides disabling fsc?


Not that I'm aware of.

Let me know if you need anything else.

Thanks,
Brian
Jan 19 02:08:44 tux-116 [120882.927408] BUG: unable to handle kernel 
Jan 19 02:08:44 tux-116 NULL pointer dereference
Jan 19 02:08:44 tux-116 at 0040
Jan 19 02:08:44 tux-116 [120882.927421] IP:
Jan 19 02:08:44 tux-116 [a103c5f7] 
__fscache_read_or_alloc_pages+0x194/0x262 [fscache]
Jan 19 02:08:44 tux-116 [120882.927432] PGD 22120c067 
Jan 19 02:08:44 tux-116 PUD 22157d067 
Jan 19 02:08:44 tux-116 PMD 0 
Jan 19 02:08:44 tux-116 
Jan 19 02:08:44 tux-116 [120882.927440] Oops:  [#1] 
Jan 19 02:08:44 tux-116 SMP 
Jan 19 02:08:44 tux-116 
Jan 19 02:08:44 tux-116 [120882.927446] CPU 0 
Jan 19 02:08:44 tux-116 
Jan 19 02:08:44 tux-116 [120882.927449] Modules linked in:
Jan 19 02:08:44 tux-116 btrfs
Jan 19 02:08:44 tux-116 zlib_deflate
Jan 19 02:08:44 tux-116 libcrc32c
Jan 19 02:08:44 tux-116 ufs
Jan 19 02:08:44 tux-116 qnx4
Jan 19 02:08:44 tux-116 hfsplus
Jan 19 02:08:44 tux-116 hfs
Jan 19 02:08:44 tux-116 minix
Jan 19 02:08:44 tux-116 ntfs
Jan 19 02:08:44 tux-116 vfat
Jan 19 02:08:44 tux-116 msdos
Jan 19 02:08:44 tux-116 fat
Jan 19 02:08:44 tux-116 jfs
Jan 19 02:08:44 tux-116 xfs
Jan 19 02:08:44 tux-116 reiserfs
Jan 19 02:08:44 tux-116 ext2
Jan 19 02:08:44 tux-116 cpufreq_userspace
Jan 19 02:08:44 tux-116 cpufreq_powersave
Jan 19 02:08:44 tux-116 cpufreq_conservative
Jan 19 02:08:44 tux-116 cpufreq_stats
Jan 19 02:08:44 tux-116 autofs4
Jan 19 02:08:44 tux-116 cachefiles
Jan 19 02:08:44 tux-116 binfmt_misc
Jan 19 02:08:44 tux-116 kvm_intel
Jan 19 02:08:44 tux-116 kvm
Jan 19 02:08:44 tux-116 nfsd
Jan 19 02:08:44 tux-116 nfs
Jan 19 02:08:44 tux-116 lockd
Jan 19 02:08:44 tux-116 fscache
Jan 19 02:08:44 tux-116 auth_rpcgss
Jan 19 02:08:44 tux-116 nfs_acl
Jan 19 02:08:44 tux-116 sunrpc
Jan 19 02:08:44 tux-116 netconsole
Jan 19 02:08:44 tux-116 configfs
Jan 19 02:08:44 tux-116 ext3
Jan 19 02:08:44 tux-116 jbd
Jan 19 02:08:44 tux-116 dm_crypt
Jan 19 02:08:44 tux-116 sbs
Jan 19 02:08:44 tux-116 power_supply
Jan 19 02:08:44 tux-116 sbshc
Jan 19 02:08:44 tux-116 adt7475
Jan 19 02:08:44 tux-116 hwmon_vid
Jan 19 02:08:44 tux-116 ipmi_watchdog
Jan 19 02:08:44 tux-116 ipmi_devintf
Jan 19 02:08:44 tux-116 ipmi_si
Jan 19 02:08:44 tux-116 ipmi_msghandler
Jan 19 02:08:44 tux-116 fuse
Jan 19 02:08:44 tux-116 uhci_hcd
Jan 19 02:08:44 tux-116 ohci_hcd
Jan 19 02:08:44 tux-116 snd_hda_codec_realtek
Jan 19 02:08:44 tux-116 snd_hda_intel
Jan 19 02:08:44 tux-116 snd_hda_codec
Jan 19 02:08:44 tux-116 snd_hwdep
Jan 19 02:08:44 tux-116 snd_pcm_oss
Jan 19 02:08:44 tux-116 snd_mixer_oss
Jan 19 02:08:44 tux-116 tpm_infineon
Jan 19 02:08

Bug#658739: please try to downgrade libgcrypt11 to 1.4.6

[Brian Kroth]

Trek tre...@inbox.ru 2013-01-21 07:13:

Hi,

can you try to downgrade libgcrypt11 to the version 1.4.6-9?
You can download it from:

http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/


this resolved a bug using claws-mail and midori with libgcrypt 1.5,
that seems to have problems with its memory management:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640123


If this is the case, may be that libgcrypt11 should be downgraded
before wheezy is released.


Ciao!


Hello, here's what I tried (for amd64 and i386):

# wget 
http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/libgcrypt11_1.4.6-9_amd64.deb
# /bin/su -
# dpkg -i libgcrypt11_1.4.6-9_amd64.deb
# reboot (just for good measure in case /etc/init.d/nscd restart didn't do the 
trick)

# sudo -s
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/bpkroth/2: Operation not permitted
sudo: unable to set supplementary group IDs: Operation not permitted
sudo: unable to execute /bin/bash: Operation not permitted

So, still no luck.  Let me know if you need anything else (eg: various 
packages rebuilt against that version?).


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#658739: status?

[Brian Kroth]

On 2012-11-30 Martijn van Brummelen mart...@brumit.nl wrote:

Hello,
The patch from Ubuntu breaks other stuff. See
https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798
and duplicates. Note that although this (LP 1013798) was fixed in
1.5.0-3ubuntu2 the patch had to be pulled again in 1.5.0-3ubuntu2.1
because of
https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906

How about suggestion nr 22 suggested on
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/926350


We cannot switch to a GPLv2-incompatible gnutls stack on Debian
currently.[1]

cu andreas

[1] We will need to do this for wheezy + 1, because Debian
does not have the manpower to fork GnuTLS 2.x. But that is a different
discussion.


May I ask what the proposed/potential solutions for this is then?  This 
is a major problem holding us up from serious wheezy consideration where 
I work.


Please let me know if you'd like help testing something.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#658739: status?

[Brian Kroth]

Andreas Metzler ametz...@downhill.at.eu.org 2013-01-09 19:17:

On 2013-01-09 Brian Kroth bpkr...@gmail.com wrote:
[...]

May I ask what the proposed/potential solutions for this is then?
This is a major problem holding us up from serious wheezy
consideration where I work.



Please let me know if you'd like help testing something.


Hello,

sadly I have not got a plan. The Ubuntu change did not work out, it
fixed one issue but opened others. The only obvious workaround is to
use libnss-ldapd instead of libnss-ldap.

cu andreas


Hi, unfortunately, as I outlined here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896
libnss-ldapd (or rather libpam-ldapd) is not an option for us, nor does 
it solve the problem (I've tested it).


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#658739: status?

[Brian Kroth]

Brian Paul Kroth bpkr...@gmail.com 2013-01-09 12:32:

Andreas Metzler ametz...@downhill.at.eu.org 2013-01-09 19:17:

On 2013-01-09 Brian Kroth bpkr...@gmail.com wrote:
[...]

May I ask what the proposed/potential solutions for this is then?
This is a major problem holding us up from serious wheezy
consideration where I work.



Please let me know if you'd like help testing something.


Hello,

sadly I have not got a plan. The Ubuntu change did not work out, it
fixed one issue but opened others. The only obvious workaround is to
use libnss-ldapd instead of libnss-ldap.

cu andreas


Hi, unfortunately, as I outlined here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896
libnss-ldapd (or rather libpam-ldapd) is not an option for us, nor 
does it solve the problem (I've tested it).


Thanks,
Brian


Sorry, that should have been here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896#23

We use that pam_ldap config= trick for all sorts of things/services.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#693701: setup-storage fails to partition the discs if LVM volume is present

[Brian Kroth]

Package: fai-setup-storage
Version: 4.0.4
Followup-For: Bug #693701

So, the good news is that live-boot seems to work nicely now.

However, something like this bug is still occurring with 
fai-setup-storage 4.0.4.

If I install a machine with an LVM disk_config and then go to reinstall 
it (with preserve_reinstall) and the FAI_FLAG=inital set (so that it 
gets wiped), then it fails with the same Cannot satisfy pre-depends for 
true message as before.

I'll attach full debug log details in a moment.

Let me know if you need anything else.

Thanks,
Brian


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (120, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fai-setup-storage depends on:
ii  liblinux-lvm-perl 0.16-1
ii  libparse-recdescent-perl  1.967009+dfsg-1
ii  parted2.3-11
ii  perl  5.14.2-15

Versions of packages fai-setup-storage recommends:
ii  lvm2   2.02.95-4
ii  mdadm  3.2.5-3

Versions of packages fai-setup-storage suggests:
pn  cryptsetup none
ii  dmsetup2:1.02.74-4
pn  dosfstools none
pn  jfsutils   none
pn  ntfsprogs  none
pn  reiserfsprogs  none
pn  xfsprogs   none

-- no debconf information
Starting setup-storage 1.4
Using config file: /var/lib/fai/config/disk_config/TESTGROUP_FAI
W: mdadm: using ARRAYs defined in existing mdadm.conf.
Executing: parted -s /dev/sda unit TiB print
Executing: parted -s /dev/sda unit B print free
Executing: parted -s /dev/sda unit chs print free
File descriptor 3 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
File descriptor 4 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
Finding all volume groups
Finding volume group vg
File descriptor 3 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
File descriptor 4 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
Finding all volume groups
Finding volume group vg
File descriptor 3 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
File descriptor 4 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
Finding all volume groups
Finding volume group vg
File descriptor 3 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
File descriptor 4 (/usr/share/bash-completion/completions) leaked on vgdisplay 
invocation. Parent PID 1915: /usr/bin/perl
Finding all volume groups
Finding volume group vg
Executing: mdadm --examine --scan --verbose -c partitions
Cannot satisfy pre-depends for true: 
vgchange_a_n_VG_vg,pv_sigs_removed_vg,self_cleared_fscache,self_cleared_local.hd,self_cleared_root,self_cleared_swap,self_cleared_var
 -- system left untouched.
Starting setup-storage 1.4
disklist: sda
sdb
Using config file: /var/lib/fai/config/disk_config/TESTGROUP_FAI
Input was:
# TESTGROUP_FAI
# 2009-06-01
# bpkroth
#
# This file is a disk_config file uses the setup-storage syntax to create an
# LVM'd lab machine disk layout that preserves partitions.  It is expected to
# be at least 30G.
#
# We could set tuneopts=-c 0 -i 0 to disable periodic fsck's but that doesn't
# seem like a great idea to me.
#
# We also used to set -O dir_index,filetype,resize_inode in the createopts,
# but since those are contained in /etc/mke2fs.conf's defaults, we don't bother
# anymore.

# type mountpoint size   fs type mount options misc options

# Setup the first disk to use an msdos partition table and two partitions, one
# for /boot and the rest for LVM.
disk_config disk1 disklabel:msdos bootable:1 fstabkey:uuid align-at:1M
primary /boot   224Mext3
defaults,rw,errors=panic createopts=-L boot tuneopts=-c 90 -i 90d
primary -   15G--   -

# Setup LVM to contain all the system partitions.
# Make sure that all partitions can be resized, /local.hd is preserved unless
# it doesn't exist and gets to claim almost all of whatever's left.  It leaves
# a little bit in case we need to resize later.
 
vg vg disk1.2
disk_config lvm fstabkey:device preserve_reinstall:vg-local.hd
vg-swap swap2G-4G   swapsw 
createopts=-L swap
vg-root /   8G-12G  ext4
defaults,rw,errors=panic,relatime createopts=-L root tuneopts=-c 90 -i 90d
vg-var  /var2G-3G   ext4
defaults,rw,errors=panic,relatime createopts=-L var tuneopts=-c 90 -i 90d
vg-fscache  /var/cache/fscache  2G-3G   ext4

Bug#356187: 2 ldap servers - possibly better solution

[Brian Kroth]

Johannes Knauf johannes.kn...@physik.uni-erlangen.de 2012-10-16 08:10:

If you are administrating at least 1 of the 2 LDAP servers, you can
use pass-through authentication as an alternative. It is described in
http://www.openldap.org/doc/admin24/security.html

Then, pam_ldap authenticates to LDAP server 1 only, which holds
information about all users. For local users on server 1 it holds a
hash, for remote users on server 2, it holds a string
{SASL}username@server2 instead of the hash. If a user from server 2
tries to bind against server 1, authentication is delegated to
server 2.

A tutorial can be found in http://wiki.debian.org/LDAP/PAM


In my case they aren't actually separate servers, so to set yet another 
pair up just to do this would be overly complex.


Brian


signature.asc
Description: Digital signature

Bug#682007: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Brian Paul Kroth bpkr...@gmail.com 2012-10-11 14:06:

Jonathan Nieder jrnie...@gmail.com 2012-10-01 01:25:

snip/

Once again very sorry for the delay :(

I forgot to disable the DEBUG_INFO and kept filling up my build VMs 
disk during compile.  Then realized I had grabbed the 3.7 rc code, 
which these patches don't apply against.  git checkout 
remotes/stable/linux-3.2.y (results in head 
c74a5e1fe4d0672936c8fb63d7484dfeaa30669c and 3.2.28), seemed to fix 
that.

snip/
Anyways, I just started running that on a machine, so I'll let you 
know if I noticed anything there first before I think about pushing 
it to further places.


Thanks,
Brian


Got another panic using this kernel/set of patches.  The dump is 
attached.


Let me know if you need anything else.

Thanks,
Brian
Oct 12 13:43:01 kefka [14595.129262] FS-Cache: Unsupported event 2 [44/7] in 
state OBJECT_DEAD
Oct 12 13:43:01 kefka [14595.129317] [ cut here ]
Oct 12 13:43:01 kefka [14595.129338] kernel BUG at fs/fscache/object.c:357!
Oct 12 13:43:01 kefka [14595.129358] invalid opcode:  [#1] 
Oct 12 13:43:01 kefka SMP 
Oct 12 13:43:01 kefka 
Oct 12 13:43:01 kefka [14595.129390] CPU 1 
Oct 12 13:43:01 kefka 
Oct 12 13:43:01 kefka [14595.129395] Modules linked in:
Oct 12 13:43:01 kefka acpi_cpufreq
Oct 12 13:43:01 kefka mperf
Oct 12 13:43:01 kefka cpufreq_stats
Oct 12 13:43:01 kefka cpufreq_userspace
Oct 12 13:43:01 kefka cpufreq_powersave
Oct 12 13:43:01 kefka cpufreq_conservative
Oct 12 13:43:01 kefka autofs4
Oct 12 13:43:01 kefka kvm_intel
Oct 12 13:43:01 kefka kvm
Oct 12 13:43:01 kefka cachefiles
Oct 12 13:43:01 kefka binfmt_misc
Oct 12 13:43:01 kefka nfsd
Oct 12 13:43:01 kefka nfs
Oct 12 13:43:01 kefka lockd
Oct 12 13:43:01 kefka fscache
Oct 12 13:43:01 kefka auth_rpcgss
Oct 12 13:43:01 kefka nfs_acl
Oct 12 13:43:01 kefka sunrpc
Oct 12 13:43:01 kefka netconsole
Oct 12 13:43:01 kefka configfs
Oct 12 13:43:01 kefka ext3
Oct 12 13:43:01 kefka jbd
Oct 12 13:43:01 kefka coretemp
Oct 12 13:43:01 kefka ipmi_watchdog
Oct 12 13:43:01 kefka ipmi_devintf
Oct 12 13:43:01 kefka ipmi_si
Oct 12 13:43:01 kefka ipmi_msghandler
Oct 12 13:43:01 kefka fuse
Oct 12 13:43:01 kefka uhci_hcd
Oct 12 13:43:01 kefka ohci_hcd
Oct 12 13:43:01 kefka tpm_infineon
Oct 12 13:43:01 kefka snd_hda_codec_realtek
Oct 12 13:43:01 kefka snd_hda_intel
Oct 12 13:43:01 kefka snd_hda_codec
Oct 12 13:43:01 kefka snd_hwdep
Oct 12 13:43:01 kefka snd_pcm_oss
Oct 12 13:43:01 kefka snd_mixer_oss
Oct 12 13:43:01 kefka snd_pcm
Oct 12 13:43:01 kefka snd_seq_midi
Oct 12 13:43:01 kefka button
Oct 12 13:43:01 kefka hp_wmi
Oct 12 13:43:01 kefka snd_rawmidi
Oct 12 13:43:01 kefka snd_seq_midi_event
Oct 12 13:43:01 kefka processor
Oct 12 13:43:01 kefka sparse_keymap
Oct 12 13:43:01 kefka rfkill
Oct 12 13:43:01 kefka snd_seq
Oct 12 13:43:01 kefka psmouse
Oct 12 13:43:01 kefka thermal_sys
Oct 12 13:43:01 kefka serio_raw
Oct 12 13:43:01 kefka joydev
Oct 12 13:43:01 kefka evdev
Oct 12 13:43:01 kefka tpm_tis
Oct 12 13:43:01 kefka tpm
Oct 12 13:43:01 kefka i2c_i801
Oct 12 13:43:01 kefka tpm_bios
Oct 12 13:43:01 kefka i2c_core
Oct 12 13:43:01 kefka wmi
Oct 12 13:43:01 kefka snd_timer
Oct 12 13:43:01 kefka snd_seq_device
Oct 12 13:43:01 kefka snd
Oct 12 13:43:01 kefka soundcore
Oct 12 13:43:01 kefka snd_page_alloc
Oct 12 13:43:01 kefka ext4
Oct 12 13:43:01 kefka mbcache
Oct 12 13:43:01 kefka jbd2
Oct 12 13:43:01 kefka crc16
Oct 12 13:43:01 kefka dm_mod
Oct 12 13:43:01 kefka raid10
Oct 12 13:43:01 kefka raid456
Oct 12 13:43:01 kefka async_raid6_recov
Oct 12 13:43:01 kefka async_pq
Oct 12 13:43:01 kefka raid6_pq
Oct 12 13:43:01 kefka async_xor
Oct 12 13:43:01 kefka xor
Oct 12 13:43:01 kefka async_memcpy
Oct 12 13:43:01 kefka async_tx
Oct 12 13:43:01 kefka raid1
Oct 12 13:43:01 kefka raid0
Oct 12 13:43:01 kefka multipath
Oct 12 13:43:01 kefka linear
Oct 12 13:43:01 kefka md_mod
Oct 12 13:43:01 kefka hid_microsoft
Oct 12 13:43:01 kefka usbhid
Oct 12 13:43:01 kefka hid
Oct 12 13:43:01 kefka sg
Oct 12 13:43:01 kefka sr_mod
Oct 12 13:43:01 kefka sd_mod
Oct 12 13:43:01 kefka cdrom
Oct 12 13:43:01 kefka crc_t10dif
Oct 12 13:43:01 kefka ahci
Oct 12 13:43:01 kefka libahci
Oct 12 13:43:01 kefka libata
Oct 12 13:43:01 kefka scsi_mod
Oct 12 13:43:01 kefka ehci_hcd
Oct 12 13:43:01 kefka usbcore
Oct 12 13:43:01 kefka e1000e
Oct 12 13:43:01 kefka usb_common
Oct 12 13:43:01 kefka [last unloaded: microcode]
Oct 12 13:43:01 kefka 
Oct 12 13:43:01 kefka [14595.130083] 
Oct 12 13:43:01 kefka [14595.130101] Pid: 25732, comm: kworker/u:0 Not tainted 
3.2.28+ #8
Oct 12 13:43:01 kefka Hewlett-Packard HP Compaq 8200 Elite CMT PC
Oct 12 13:43:01 kefka /1494
Oct 12 13:43:01 kefka 
Oct 12 13:43:01 kefka [14595.130149] RIP: 0010:[a0411fe5] 
Oct 12 13:43:01 kefka [a0411fe5] fscache_object_work_func+0x79c/0x7db 
[fscache]
Oct 12 13:43:01 kefka [14595.130192] RSP: 0018:88021ed15e20  EFLAGS: 
00010286
Oct 12 13:43:01 kefka [14595.130217] RAX: 004f RBX: 
88021f6406c0 RCX: 

Bug#682007: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-10-01 01:25:

Brian Kroth wrote:


Sorry, the labs went into their dormant period and all of my test cases ran
away for the rest of the summer (the find cmd didn't seem to trigger the
__fscache problem), so I hadn't moved any further on this.

Now that they're back, I'm definitely seeing it again (about 20 different
machines in two days last week), so I've started the process of hunting down
a trigger cause again.  I'll let you know if I find something.


Thanks for the update.

The human test cases can work fine for vetting a fix.  I'd also be
interested to hear whether the series I sent was completely borked, so
I'd recommend trying on a test machine for a day or two before putting
such a patched kernel into production, though.

Jonathan


Once again very sorry for the delay :(

I forgot to disable the DEBUG_INFO and kept filling up my build VMs disk 
during compile.  Then realized I had grabbed the 3.7 rc code, which 
these patches don't apply against.  git checkout 
remotes/stable/linux-3.2.y (results in head 
c74a5e1fe4d0672936c8fb63d7484dfeaa30669c and 3.2.28), seemed to fix 
that.


Here's what I got when applying the patches.

# git am -3sc $(ls -1 ../patches/fscache_read/[01]*.patch)
Applying: CacheFiles: Fix the marking of cached pages
Applying: CacheFiles: Downgrade the requirements passed to the allocator
Applying: FS-Cache: Check that there are no read ops when cookie relinquished
Applying: CacheFiles: Make some debugging statements conditional
Applying: FS-Cache: Make cookie relinquishment wait for outstanding reads
Applying: FS-Cache: Fix operation state management and accounting
Applying: FS-Cache: Provide proper invalidation
Applying: VFS: Make more complete truncate operation available to CacheFiles
Applying: CacheFiles: Implement invalidation
Applying: NFS: Use FS-Cache invalidation
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging fs/nfs/fscache.h
Auto-merging fs/nfs/inode.c
Auto-merging fs/nfs/nfs4proc.c
Applying: CacheFiles: Add missing retrieval completions
Applying: FS-Cache: Convert the object event ID #defines into an enum
Applying: FS-Cache: Initialise the object event mask with the calculated mask
Applying: FS-Cache: Don't mask off the object event mask when printing it
Applying: FS-Cache: Limit the number of I/O error reports for a cache
Applying: FS-Cache: Exclusive op submission can BUG if there's been an I/O error
Applying: NFS: nfs_migrate_page() does not wait for FS-Cache to finish with a 
page

Anyways, I just started running that on a machine, so I'll let you know 
if I noticed anything there first before I think about pushing it to 
further places.


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#685407: ext4 dir_index + nfs duplicate cookies problem with large dovecot maildirs

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-10-08 21:09:

Hi again,

Jonathan Nieder wrote:


Hi kernel team,

[...]

Please consider the attached patch for the sid branch of the packaging
repo.  It applies the five aforementioned patches from upstream:

  6a8a13e03861 fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash
  d1f5273e9adb ext4: return 32/64-bit dir name hash according to usage type
  999448a8c020 nfsd: rename 'int access' to 'int may_flags' in nfsd_open
  06effdbb49af nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)
  d7dab39b6e16 ext3: return 32/64-bit dir name hash according to usage
   type

which make NFSv3/4 use 64-bit hashes as readdir cookies instead of
crippling itself for the sake of NFSv2 which only supports 32-bit
cookies.  The most interesting of these (patches #2 and #5) are
unfortunately a bit too big for the letter of the upstream stable
rules, but the patches are straightforward, make sense, and are well
tested.


Ping.  Do you think these could work for stable@?  If not, could they
make sense for wheezy anyway?

Even if I cheat by stripping out some comments and such, patch #2 is
257 lines including context and diff headers, but semantically the
patches are very clear and seem safe and sensible.

Thanks,
Jonathan


I think these are a must for wheezy.  It's a fairly major flaw in my 
opinion.


I would also really like to see this in stable, since wheezy felt a long 
way off the last time I tried it, and there's some nice benefits from 
the backports kernel that we like, though we can probably continue to 
limp along on the original 2.6.32 kernel on those affected machines for 
a bit.


/cent/cent

Brian


signature.asc
Description: Digital signature

Bug#685069: Fwd: End of Life date for Shibboleth SP V2.4.3

[Brian Kroth]

FYI

If no one else has started on this I might take a stab since I'm hoping 
it will solve some pretty awful memory leaks I've run into when using 
this with unixodbc and libmyodbc.


Brian

- Forwarded message from Cantor, Scott canto...@osu.edu -

Date: Fri, 5 Oct 2012 18:33:14 +
From: Cantor, Scott canto...@osu.edu
To: annou...@shibboleth.net annou...@shibboleth.net
Subject: End of Life date for Shibboleth SP V2.4.3
Reply-To: us...@shibboleth.net
Return-Path: announce-boun...@shibboleth.net
List-Id: Shib Announce announce.shibboleth.net
List-Unsubscribe: http://shibboleth.net/mailman/listinfo/announce, 
mailto:announce-requ...@shibboleth.net?subject=unsubscribe
List-Archive: http://shibboleth.net/pipermail/announce
List-Post: mailto:annou...@shibboleth.net
List-Help: mailto:announce-requ...@shibboleth.net?subject=help
List-Subscribe: http://shibboleth.net/mailman/listinfo/announce, 
mailto:announce-requ...@shibboleth.net?subject=subscribe
X-Spam-Level: 
X-Virus-Status: Clean


The previous stable release of the Service Provider will be moved to the
unsupported category on November 30th, 2012. There have been no
regressions reported in V2.5.0, so I'm setting that date to close
maintenance on the previous branch.

If any security issues arise between now and that date, we will provide a
patch release to both V2.4.3 and V2.5.0 (as necessary), but after that
date, there will be further official patch support from the project.

Our documentation will be updated to reflect this date and I will add a
news item to the web site at my earliest convenience.

-- Scott


--
To unsubscribe from this list send an email to 
announce-unsubscr...@shibboleth.net


- End forwarded message -


signature.asc
Description: Digital signature

Bug#685069: Fwd: End of Life date for Shibboleth SP V2.4.3

[Brian Kroth]

Russ Allbery r...@debian.org 2012-10-05 13:48:

Brian Kroth bpkr...@gmail.com writes:


If no one else has started on this I might take a stab since I'm hoping
it will solve some pretty awful memory leaks I've run into when using
this with unixodbc and libmyodbc.


I have, sadly, not had time to start on it.


No worries, I completely understand how it goes.

Like I said, the memory leak is biting me right now, so I'll take a stab 
at packaging the new version probably sometime next week and post my 
results here.  I don't do those that often (usually just use debbuild to 
backport existing package updates for my systems), so I'm sure there 
will be problems, but maybe it can at least be a starting point for 
someone who does really know what they're doing.  Or you guys can just 
point out what I'm doing wrong :)


Cheers,
Brian


signature.asc
Description: Digital signature

Bug#682007: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-09-29 15:22:

Hi again,

In July, 2012, Brian Kroth wrote:

Jonathan Nieder jrnie...@gmail.com 2012-07-21 12:04:



Please test the attached patches, for example following the instructions
below:

[...]

Anyways, I'll wait on the results of my previous test first to see if we
have a reliable test case from it before moving forward.

At this point the grep -r abc ... test is just hitting the cache over and
over again, so it's not showing a whole lot.

One other thing I'd tried before was something like this run a couple of
times in a row (hmm, I suppose I could try them in parallel too):

find /fsc_mounted_nfs -type f -exec cat {}  /dev/null \;

A couple of them paniced, but with inconsistent messages, so I had left them
out for now.  Perhaps that's worth another shot ...


So, how did it go?  Did some test case prove reliable?  Any other
new observations?


Sorry, the labs went into their dormant period and all of my test cases 
ran away for the rest of the summer (the find cmd didn't seem to trigger 
the __fscache problem), so I hadn't moved any further on this.


Now that they're back, I'm definitely seeing it again (about 20 
different machines in two days last week), so I've started the process 
of hunting down a trigger cause again.  I'll let you know if I find 
something.


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#685069: shib-sp 2.5 fixes some bugs and adds ipv6 support

[Brian Kroth]

FYI, the 2.5 version also fixes some bugs and adds better IPv6 support.  
For example:

https://issues.shibboleth.net/jira/browse/SSPCPP-392
https://issues.shibboleth.net/jira/browse/SSPCPP-326

I will definitely be willing to help test this out once it's available.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#356187: related upstream bug

[Brian Kroth]

This looks to also be related:
http://bugzilla.padl.com/show_bug.cgi?id=191


signature.asc
Description: Digital signature

Bug#356187: libpam-ldap: pam_ldap.so is not stackable

[Brian Kroth]

I know this is years and years later, but we recently ran into this as 
well.


In our case, I'm not connecting to different servers, but we do want to 
stack different pam_filters.


The relevant bits from pam.d/common-account look like this:
account [success=1 default=ignore] pam_unix.so
account required pam_ldap.so config=/etc/pam_ldap.conf
account required pam_permit.so

For instance, we'd like to be able to stack our pam.d/sudo file (or 
whatever) like so, so that the stuff above is executed first, then the 
stuff below:


# Include the typical unix and ldap rules from common-account
@include common-account
# Then a subset of them that uses a different pam_filter in it's conf.
# Still skip ldap if unix auth succeeds:
account [success=1 default=ignore] pam_unix.so
account required pam_ldap.so config=/etc/pam_ldap.conf.sudo
account required pam_permit.so

The relevant difference in pam_ldap.conf's look like this:

# pam_ldap.conf
pam_filter acl=unix-server

# pam_ldap.conf.sudo
pam_filter acl=sudo


Now, why not just make an (...) filter in a single pam_ldap.conf, you 
ask?  Well, we have at least a dozen different kinds of default 
pam_ldap.conf files for various service hosts (mail, labs, etc.), and we 
may wish to tack on extra requirements for multiple different services 
for each of these (eg: cron, sudo, etc.).  Combining all of those 
together with various other constraints could lead to hundreds of 
combinations.  So, we'd prefer to stack them, as pam intended :)


The trouble is that currently the second set is just ignored since pam 
caches the config file details.  From the pam_ldap.conf man page:


config=path
	Specifies that pam_ldap should use the configuration file in 
	path  instead  of  pam_ldap.conf  to retrieve  its  global 
	configuration. Configuring multiple instances of pam_ldap for 
	the same service with different configuration files is not 
	supported, because the  configuration  information is cached.


I've tested the attached hackish patch and it seems to correctly work 
around this issue by forcing a reload of the config when the previously 
cached value doesn't match.  I think it should also work for different 
ldap servers, though I haven't tested it.


I'd love to see something like this pulled in by Debian or even 
upstream.


Let me know if you have any questions.

Thanks,
Brian
--- pam_ldap.c.orig	2012-08-27 11:16:31.934119687 -0500
+++ pam_ldap.c	2012-08-27 11:46:22.956091908 -0500
@@ -2771,6 +2771,39 @@
 	  (strcmp (configFile, session-conf-configFile) != 0))
 	{
 	  _release_user_info (session-info);
+	  /* 
+	   * Release all cached data and reread the conf if the user
+	   * requested a different config file. 
+	   * This allows stacking different ldap filters together.
+	   * 2012-08-27
+	   * bpkroth
+	   */
+	  if (strcmp (configFile, session-conf-configFile) != 0) {
+		if (session-ld != NULL)
+		{
+		  ldap_unbind (session-ld);
+		  session-ld = NULL;
+		}
+	_release_config (session-conf);
+	session-conf = NULL;
+	/* Reread the conf file (copied and pasted from down below) */
+#ifdef YPLDAPD
+  rc = _ypldapd_read_config (session-conf);
+  if (rc != PAM_SUCCESS)
+{
+  _release_config (session-conf);
+#endif /* YPLDAPD */
+  rc = _read_config (configFile, session-conf);
+  if (rc != PAM_SUCCESS)
+	{
+	  _release_config (session-conf);
+	  free (session);
+	  return rc;
+	}
+#ifdef YPLDAPD
+}
+#endif /* YPLDAPD */
+  }
 	}
 	}
 


signature.asc
Description: Digital signature

Bug#685407: [wheezy] ext4 dir_index + nfs duplicate cookies problem with large dovecot maildirs

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-08-20 17:33:

reassign 685407 src:linux 3.2.20-1
fixed 685407 linux/3.5-1~experimental.1
tags 685407 + upstream patch moreinfo
quit

Hi again,

Brian Kroth wrote:


linux-image-3.5-trunk-amd64 (3.5-1~experimental.1) on the server
does indeed appear to fix this.

[...]

Attached is a simple script I used to create a test dir for this.
The ext4 volume was 3G.


Very nice to hear.

Please test the attached patches together against a 3.2.y kernel,
for example using the following instructions.

0. prerequisites:

apt-get install git build-essential

1. get the kernel history, if you don't already have it:

git clone \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2. fetch point releases:

cd linux
git remote add stable \
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable

3. configure, build, test:

git checkout stable/linux-3.2.y


3.2.28


cp /boot/config-$(uname -r) .config; # current configuration
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -jnum for parallel build
dpkg -i ../name of package; # as root
reboot
... test test test ...

   Hopefully it reproduces the bug.  So:


It does reproduce the bug.


4. try the patches:

cd linux
git am -3sc $(ls -1 /path/to/patches/0*)
make deb-pkg; # maybe with -j4
dpkg -i ../name of package; # as root
reboot
... test test test ...


It does *not* reproduce the bug.

Looks to have worked.


If it works, someone on the kernel team will probably apply the
patches to wheezy (meaning they would automatically flow into
squeeze-backports as well).


Good news.

Let me know if you need anything else.

Thanks for the help and good instructions,
Brian


(An alternative set of instructions is at [1].)

Hope that helps,
Jonathan

[1] 
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
or the corresponding page in the debian-kernel-handbook package


signature.asc
Description: Digital signature

Bug#658896: ldapd not a good workaround

[Brian Kroth]

FYI, this is affecting our systems as well.  So far as I can tell, we 
can't use the nslcd stuff as a workaround because that prevents using 
separate ldap confs for auth in pam (eg: pam_ldap.so 
config=/etc/pam_ldap.conf.special) which allows us to construct 
different ldap filters, base searches, proxy configs, ssl vs. tls, etc.  
for authenticating users for different services separately.


In particular we like to use that to allow sudo to authenticate against 
a shadow object of the usual user so that they can have a separate 
password for their sudo access and to filter the users that it will even 
authenticate to those with a particular ldap acl attribute before it 
even consults the sudoers file.


If you need help testing out other ldap/ssl/tls fixes let me know.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#685407: [wheezy] ext4 dir_index + nfs duplicate cookies problem with large dovecot maildirs

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-08-20 09:39:

Hi,

Brian Paul Kroth wrote:


- multiple ext4 filesystems with dir_index enabled for maildir account storage
- serves these over nfs (v3 or v4, doesn't matter) to server clients
running dovecot to serve imap to real clients
- ls -l | wc -l or readdir() in directories with many entries
(I've   seen it with as few as ~7000) results in the duplicate
cookie or   too many levels of symbolic links error being
returned and the   directory listing will be cut short.


Some patches intended to address this on the server side were
merged during the 3.4 merge window[*].  Could you try 3.5.2 or
newer from experimental and let us know how it goes?

Curious,
Jonathan

[*] http://thread.gmane.org/gmane.linux.file-systems/60157


linux-image-3.5-trunk-amd64 (3.5-1~experimental.1) on the server does 
indeed appear to fix this.  NFSv3 and NFSv4 tested from the following 
client kernels:

- linux-image-3.2.0-0.bpo.2-amd64 (3.2.20-1~bpo60+1)
- linux-image-2.6.39-bpo.2-amd64 (2.6.39-3~bpo60+1)
- linux-image-2.6.32-5-amd64 (2.6.32-45)

Attached is a simple script I used to create a test dir for this.  The 
ext4 volume was 3G.


Any chance this will be backported to squeeze as well?

Thanks,
Brian
#!/usr/bin/perl -w

use strict;

my $top = 305388;	# starts to cause symbolic link loop warnings here
my $dir = './test';

if (! -d $dir) {
	mkdir($dir) or die($!);
}

for my $i (1..$top) {
	my $file = $dir/test-$i;
	
	if ($i % 1000 == 0) {	# show some progress
		print $file, \n;
	}

	next if (-f $file);

	open(FILE, '', $file) or die($!);
	print FILE test-$i;
	close(FILE) or die($!);
}

# Now NFS export it, mount it elsewhere, and ls -l | wc -l or readdir() from
# that elsewhere to see if it complains.


signature.asc
Description: Digital signature

Bug#682007: [squeeze-backports] NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-07-20 11:25:

merge 682116 682007
quit

Hi,

Ben Hutchings b...@decadent.org.uk 2012-07-19 13:32:

On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:



We don't support proprietary stuff. Please remove and try again.


To be clear, Bastian is referring to the proprietary kernel module
(nvidia).


I think this stance is too aggressive.  Testing without the modules we
do not support can certainly help, but in cases like this where the
proprietary module is not likely to be related, I'd rather hear about
problems earlier than have submitters wait until they have time to
reproduce without.

Luckily this has been reproduced without the nvidia module, so
merging.

Rhaoul writes:

This is reproducable using grep -r abc * inside a directory with
   9541 files (no sym- or hardlinks, no block or character special 
files) in
   1524 directories
(PHP MODX installation)


I downloaded the couple of files from that site [1] and unzipped them to 
hopefully create a similar test setup.  I had to make two copies of it 
to get that many files/dirs.


Right now I'm running this to see what happens:
# for i in {1..100}; do grep -r abc /cae/apps/data/testapp-1/tmp*  /dev/null; 
done

So far nothing much, but I just started.  


Some other points for comparison:
- does the cache need to be fresh?  I have a cron job that does this 
  from time to time (about once a month with some random splay between 
  machines) on these machines anyways (basically stop cachefilesd  rm 
  -rf the_cache_dir_contents  start cachefilesd)

- anything else in particular about the test I should look for?


I've also noticed that I can usually get cachefilesd to spin to 100% cpu 
if I do something like this:


# grep pattern /home/logs/some_multi_gb_large_readonly_logfile

I recall seeing patches for large file support, but wasn't sure on their 
status.  Anyways, that's digressing, so I'll leave that as a separate 
item for later.


Thanks,
Brian

[1] http://modx.com/download/


signature.asc
Description: Digital signature

Bug#682007: [squeeze-backports] NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-07-21 12:04:

tags 682007 + upstream patch moreinfo
quit

Hi,

Brian Kroth wrote:


kernel BUG at 
/build/buildd-linux_3.2.20-1~bpo60+1-amd64-tQMw4f/linux-3.2.20/fs/buffer.c:3088!


This is

BUG_ON(!PagePrivate(page)); \

in

static int
drop_buffers(struct page *page, struct buffer_head **buffers_to_free)
{
struct buffer_head *head = page_buffers(page);

I suspect it's the same underlying problem, but maybe not.

Please test the attached patches, for example following the instructions
below:

0. prerequisites:

apt-get install git build-essential

1. get the kernel history, if you don't already have it:

git clone \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


I take it then that this is a patch against the latest greatest kernel, 
not against the source for the backports kernel I'm currently running?



2. configure, build, test:

cd linux
git fetch origin
git checkout origin/master

cp /boot/config-$(uname -r) .config; # current configuration
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -jnum for parallel build
dpkg -i ../name of package; # as root
reboot
... test test test ...

  Hopefully it reproduces the bug.  So


Oh, I see you want to compare two nearly identical kernels (both fairly 
recent) to isolate if just the patches are helpful rather than some mix 
between the two.



3. try the patches:

cd linux
git am -3sc $(ls -1 /path/to/patches/[01]*)
make deb-pkg; # maybe with -j4
dpkg -i ../name of package; # as root
reboot
... test test test ...

Thanks and hope that helps,
Jonathan


I can try and build/install this on one of our machines (I'd prefer not 
to push it everywhere yet), but without a reliably reproducible 
(on-demand that is) test case I'm not sure what it will show except that 
it perhaps doesn't introduce further blatant bugs.


Anyways, I'll wait on the results of my previous test first to see if we 
have a reliable test case from it before moving forward.


At this point the grep -r abc ... test is just hitting the cache over 
and over again, so it's not showing a whole lot.


One other thing I'd tried before was something like this run a couple of 
times in a row (hmm, I suppose I could try them in parallel too):


find /fsc_mounted_nfs -type f -exec cat {}  /dev/null \;

A couple of them paniced, but with inconsistent messages, so I had left 
them out for now.  Perhaps that's worth another shot ...


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Ben Hutchings b...@decadent.org.uk 2012-07-19 16:21:

On Thu, Jul 19, 2012 at 09:03:26AM -0500, Brian Kroth wrote:

Ben Hutchings b...@decadent.org.uk 2012-07-19 13:32:
 On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:
 On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
 ** Tainted: PO (4097)
  * Proprietary module has been loaded.
  * Out-of-tree module has been loaded.

 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
 O 3.2.0-0.bpo.2-amd64 #1

 We don't support proprietary stuff. Please remove and try again.

 To be clear, Bastian is referring to the proprietary kernel module
 (nvidia).

Ok.  The driver is required for some third party engineering
software we have to run, but I can rig a spare machine to run some
of these other jobs without it for a bit.  I'll report back if/when
I have a new panic.

I will note though that the driver comes from the debian provided
packages (albeit from backports instead of stable).


I realise that, but it's not part of Debian proper and none of us
signed up to debug drivers that don't come with source.


Fair enough.

I've attached a new set of kernel messages captured from some runs 
without the nvidia driver loaded, but with the rest of the setup the 
same.  It doesn't quite seem to be tickling the same code path - this 
time it's an invalid opcode message instead of a NULL pointer 
dereference.  I'll let it go for a while more to see if I can get the 
same style message to back.  Unfortunately I don't exactly know how to 
reproduce it.


Thanks,
Brian
Jul 19 15:45:53 kefka [ 4289.632673] [ cut here ]
Jul 19 15:45:53 kefka [ 4289.632711] kernel BUG at 
/build/buildd-linux_3.2.20-1~bpo60+1-amd64-tQMw4f/linux-3.2.20/fs/buffer.c:3088!
Jul 19 15:45:53 kefka [ 4289.632756] invalid opcode:  [#1] 
Jul 19 15:45:53 kefka SMP 
Jul 19 15:45:53 kefka 
Jul 19 15:45:53 kefka [ 4289.632784] CPU 3 
Jul 19 15:45:53 kefka 
Jul 19 15:45:53 kefka [ 4289.632792] Modules linked in:
Jul 19 15:45:53 kefka acpi_cpufreq
Jul 19 15:45:53 kefka mperf
Jul 19 15:45:53 kefka cpufreq_userspace
Jul 19 15:45:53 kefka cpufreq_powersave
Jul 19 15:45:53 kefka cpufreq_conservative
Jul 19 15:45:53 kefka cpufreq_stats
Jul 19 15:45:53 kefka autofs4
Jul 19 15:45:53 kefka cachefiles
Jul 19 15:45:53 kefka kvm_intel
Jul 19 15:45:53 kefka kvm
Jul 19 15:45:53 kefka binfmt_misc
Jul 19 15:45:53 kefka nfsd
Jul 19 15:45:53 kefka nfs
Jul 19 15:45:53 kefka lockd
Jul 19 15:45:53 kefka fscache
Jul 19 15:45:53 kefka auth_rpcgss
Jul 19 15:45:53 kefka nfs_acl
Jul 19 15:45:53 kefka sunrpc
Jul 19 15:45:53 kefka netconsole
Jul 19 15:45:53 kefka configfs
Jul 19 15:45:53 kefka ext3
Jul 19 15:45:53 kefka jbd
Jul 19 15:45:53 kefka coretemp
Jul 19 15:45:53 kefka ipmi_watchdog
Jul 19 15:45:53 kefka ipmi_devintf
Jul 19 15:45:53 kefka ipmi_si
Jul 19 15:45:53 kefka ipmi_msghandler
Jul 19 15:45:53 kefka fuse
Jul 19 15:45:53 kefka uhci_hcd
Jul 19 15:45:53 kefka ohci_hcd
Jul 19 15:45:53 kefka tpm_infineon
Jul 19 15:45:53 kefka snd_hda_codec_realtek
Jul 19 15:45:53 kefka snd_hda_intel
Jul 19 15:45:53 kefka snd_hda_codec
Jul 19 15:45:53 kefka snd_hwdep
Jul 19 15:45:53 kefka snd_pcm_oss
Jul 19 15:45:53 kefka snd_mixer_oss
Jul 19 15:45:53 kefka snd_pcm
Jul 19 15:45:53 kefka snd_seq_midi
Jul 19 15:45:53 kefka snd_rawmidi
Jul 19 15:45:53 kefka snd_seq_midi_event
Jul 19 15:45:53 kefka snd_seq
Jul 19 15:45:53 kefka snd_timer
Jul 19 15:45:53 kefka snd_seq_device
Jul 19 15:45:53 kefka snd
Jul 19 15:45:53 kefka i2c_i801
Jul 19 15:45:53 kefka tpm_tis
Jul 19 15:45:53 kefka tpm
Jul 19 15:45:53 kefka processor
Jul 19 15:45:53 kefka soundcore
Jul 19 15:45:53 kefka hp_wmi
Jul 19 15:45:53 kefka sparse_keymap
Jul 19 15:45:53 kefka rfkill
Jul 19 15:45:53 kefka tpm_bios
Jul 19 15:45:53 kefka snd_page_alloc
Jul 19 15:45:53 kefka thermal_sys
Jul 19 15:45:53 kefka i2c_core
Jul 19 15:45:53 kefka psmouse
Jul 19 15:45:53 kefka wmi
Jul 19 15:45:53 kefka serio_raw
Jul 19 15:45:53 kefka evdev
Jul 19 15:45:53 kefka joydev
Jul 19 15:45:53 kefka button
Jul 19 15:45:53 kefka ext4
Jul 19 15:45:53 kefka mbcache
Jul 19 15:45:53 kefka jbd2
Jul 19 15:45:53 kefka crc16
Jul 19 15:45:53 kefka dm_mod
Jul 19 15:45:53 kefka raid10
Jul 19 15:45:53 kefka raid456
Jul 19 15:45:53 kefka async_raid6_recov
Jul 19 15:45:53 kefka async_pq
Jul 19 15:45:53 kefka raid6_pq
Jul 19 15:45:53 kefka async_xor
Jul 19 15:45:53 kefka xor
Jul 19 15:45:53 kefka async_memcpy
Jul 19 15:45:53 kefka async_tx
Jul 19 15:45:53 kefka raid1
Jul 19 15:45:53 kefka raid0
Jul 19 15:45:53 kefka multipath
Jul 19 15:45:53 kefka linear
Jul 19 15:45:53 kefka md_mod
Jul 19 15:45:53 kefka hid_microsoft
Jul 19 15:45:53 kefka usbhid
Jul 19 15:45:53 kefka hid
Jul 19 15:45:53 kefka sg
Jul 19 15:45:53 kefka sr_mod
Jul 19 15:45:53 kefka sd_mod
Jul 19 15:45:53 kefka cdrom
Jul 19 15:45:53 kefka crc_t10dif
Jul 19 15:45:53 kefka ahci
Jul 19 15:45:53 kefka libahci
Jul 19 15:45:53 kefka libata
Jul 19 15:45:53 kefka scsi_mod
Jul 19 15:45:53 kefka ehci_hcd
Jul 19 15:45:53

Bug#682007: [squeeze-backports] NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Jonathan Nieder jrnie...@gmail.com 2012-07-20 11:25:

merge 682116 682007
quit

Hi,

Ben Hutchings b...@decadent.org.uk 2012-07-19 13:32:

On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:



We don't support proprietary stuff. Please remove and try again.


To be clear, Bastian is referring to the proprietary kernel module
(nvidia).


I think this stance is too aggressive.  Testing without the modules we
do not support can certainly help, but in cases like this where the
proprietary module is not likely to be related, I'd rather hear about
problems earlier than have submitters wait until they have time to
reproduce without.

Luckily this has been reproduced without the nvidia module, so
merging.

Rhaoul writes:

This is reproducable using grep -r abc * inside a directory with
   9541 files (no sym- or hardlinks, no block or character special 
files) in
   1524 directories
(PHP MODX installation)

Brian, is it reproducible for you, too?  


Thanks for the test.  Unfortunately, I'm on my way out of town for a 
couple of days and didn't have time to look at this closely.  I'll get 
back to you with some proper results on this sometime next week.



What is the newest kernel you tried that did not have this problem?


I don't recall having this level of problems with 3.2.1-2~bpo60+1, but 
maybe it was just less frequent and I didn't notice it.


Cheers,
Brian


signature.asc
Description: Digital signature

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Ben Hutchings b...@decadent.org.uk 2012-07-19 13:32:

On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:

On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
 ** Tainted: PO (4097)
  * Proprietary module has been loaded.
  * Out-of-tree module has been loaded.

 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
 O 3.2.0-0.bpo.2-amd64 #1

We don't support proprietary stuff. Please remove and try again.


To be clear, Bastian is referring to the proprietary kernel module
(nvidia).


Ok.  The driver is required for some third party engineering software we 
have to run, but I can rig a spare machine to run some of these other 
jobs without it for a bit.  I'll report back if/when I have a new panic.


I will note though that the driver comes from the debian provided 
packages (albeit from backports instead of stable).


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Subject: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in 
__fscache_read_or_alloc_pages
Package: src:linux
Version: 3.2.20-1~bpo60+1
Severity: important

** Please type your report below this line ***

I have a number of machines running linux-image-3.2.0-0.bpo.2-amd64 from 
squeeze-backports that are experiencing a NULL pointer dereference bug 
in __fscache_read_or_alloc_pages fairly consistently.  Out of ~120 
machines at least 10 of them seem to experience a panic once a day.  The 
full details of a typical panic as captured via netconsole are included 
below.


The relevant setup details are as follows:

Third party applications (eg: matlab) are installed on an NFS server.  
Clients mount the exports (one fs/export per application) via nfsv4's 
root exports traversal mechanism (I forget what it's really called off 
hand).  In the options they include ro and fsc and run cachefilesd 
(0.10.4 since 0.9-3 had an excessive debug logging bug - #620732) so 
that the mostly static and read-only application data can be cached 
locally.


The mount point for the cachefilesd looks like this:
/dev/mapper/vg-fscache /var/cache/fscache ext4 
rw,relatime,errors=panic,user_xattr,acl,barrier=1,data=ordered 0 0

The cachefilesd.conf file is also included below in case it matters.

From all of the detailed panic reports I've looked at the bug seems to 
be triggered on a MATLAB comm, but that might just be that this is our 
less busy time of the year so there's more condor compute jobs running 
while the machines are otherwise idle.  Since many of those jobs need 
the third party apps they'll tend to be using the fscache more 
frequently.


What that also means is that I haven't seen any of these bugs show up 
referencing data that's on one of our other nfsv3 mounts yet.  They also 
all have fsc turned on.  Not sure if that's relevant or just a red 
herring though.


Let me know if you need any more details.

Thanks,
Brian

-- Package-specific info:
** Version:
Linux version 3.2.0-0.bpo.2-amd64 (Debian 3.2.20-1~bpo60+1) 
(debian-ker...@lists.debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP 
Fri Jun 29 20:42:29 UTC 2012

** Command line:
BOOT_IMAGE=/vmlinuz-3.2.0-0.bpo.2-amd64 root=/dev/mapper/vg-root ro panic=30 
rootdelay=10 quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[   28.191814] ACPI: Power Button [PWRB]
[   28.191852] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[   28.191874] ACPI: Power Button [PWRF]
[   28.200722] wmi: Mapper loaded
[   28.658193] i801_smbus :00:1f.3: PCI INT C - GSI 18 (level, low) - IRQ 
18
[   28.888998] tpm_tis 00:0b: 1.2 TPM (device-id 0xB, rev-id 16)
[   28.949523] input: HP WMI hotkeys as /devices/virtual/input/input5
[   29.264980] nvidia: module license 'NVIDIA' taints kernel.
[   29.264983] Disabling lock debugging due to kernel taint
[   29.346355] nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[   29.346362] nvidia :01:00.0: setting latency timer to 64
[   29.346366] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[   29.346425] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  295.59  Wed Jun  
6 21:19:40 PDT 2012
[   29.610240] snd_hda_intel :00:1b.0: PCI INT A - GSI 22 (level, low) - 
IRQ 22
[   29.610287] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[   29.610308] snd_hda_intel :00:1b.0: setting latency timer to 64
[   29.668854] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input6
[   30.548826] EXT4-fs (dm-0): re-mounted. Opts: (null)
[   30.726930] EXT4-fs (dm-0): re-mounted. Opts: errors=panic
[   30.864134] scsi_verify_blk_ioctl: 14 callbacks suppressed
[   30.864136] mdadm: sending ioctl 1261 to a partition!
[   30.864138] mdadm: sending ioctl 1261 to a partition!
[   30.871044] mdadm: sending ioctl 1261 to a partition!
[   30.871055] mdadm: sending ioctl 1261 to a partition!
[   30.879765] mdadm: sending ioctl 1261 to a partition!
[   30.879776] mdadm: sending ioctl 1261 to a partition!
[   30.888659] mdadm: sending ioctl 1261 to a partition!
[   30.888663] mdadm: sending ioctl 1261 to a partition!
[   30.889120] mdadm: sending ioctl 800c0910 to a partition!
[   30.889122] mdadm: sending ioctl 800c0910 to a partition!
[   30.910763] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   30.912552] uhci_hcd: USB Universal Host Controller Interface driver
[   30.941330] fuse init (API version 7.17)
[   30.957496] ipmi message handler version 39.2
[   30.968837] IPMI System Interface driver.
[   30.968859] ipmi_si: probing via SMBIOS
[   30.968860] ipmi_si: SMBIOS: mem 0x0 regsize 1 spacing 1 irq 0
[   30.968862] ipmi_si: Adding SMBIOS-specified kcs state machine
[   30.968864] ipmi_si: Trying SMBIOS-specified kcs state machine at mem 
address 0x0, slave address 0x20, irq 0
[   30.968866] ipmi_si: Could not set up I/O space
[   30.990363] 

Bug#620732: new version of cachefilesd available

[Brian Kroth]

I'll also note that there's a new version available that includes this 
fix as well as some others:


http://people.redhat.com/~dhowells/fscache/


signature.asc
Description: Digital signature

Bug#602933: even newer upstream release: 5.0.6

[Brian Kroth]

http://changelogs.ubuntu.com/changelogs/pool/main/a/autofs5/autofs5_5.0.6-0ubuntu2/changelog

Contains some IPv6 support fixes, among others:

http://fossies.org/linux/misc/autofs-5.0.6.tar.gz:a/autofs-5.0.6/CHANGELOG

Brian



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#641867: screen version bump (4.1.0 20101110git066b098)

[Brian Kroth]

Axel Beckert a...@debian.org 2011-10-05 14:02:

Hi again,

Axel Beckert wrote:

There is a package available here: http://noone.org/debian/

It's not yet 100% finished, but should be already close to what I
would upload.


I did some more testing myself and found quite a showstopper:

Reattaching to a running 4.0.3 screen does not work, it just hangs.
killhupping the attaching screen, downgrading and then trying to
reattach helps. :-/

As of now I have no idea where this comes from as I found nothing
obviously related in the upstream changelog.


I also found this.  I figured it was somewhat to be expected due to a 
fairly major version change.  Though I also don't know what else to do 
about it.



You can check out the package source here:
http://anonscm.debian.org/gitweb/?p=collab-maint/screen.git


Additionally I noticed in the upstream changelog that upstream fixed
even more bugs reported in Debian and Ubuntu than I already mentioned
in the changelog. :-)

Regards, Axel
--
,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
 `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


signature.asc
Description: Digital signature

Bug#644444: pkpgcounter does not properly handle all postscript documents with copies or n-up options

[Brian Kroth]

a...@librelogiciel.com a...@librelogiciel.com 2011-10-06 01:20:

Hi,

On Wed, Oct 05, 2011 at 06:05:48PM -0500, Brian Paul Kroth wrote:


I attempted to pass this info to the original dev, but haven't gotten
any response.


I'm sorry for this.

I'm slowly recovering from an accident and I'll try to be back at work
on this and several other issues in this software and other related
projects as soon as possible.

bye

Jerome Alet


No problem.  I was able to find a solution in the meantime.

Best wishes in a speedy recovery,
Brian


signature.asc
Description: Digital signature

Bug#641867: screen version bump (4.1.0 20101110git066b098)

[Brian Kroth]

Excellent.  Let me know when it's there and I'll do some testing.

Thanks,
Brian

Axel Beckert a...@debian.org 2011-10-04 23:14:

Hi Brian,

just a short thumbs up that I'm working on an updated screen package
which I'll upload to either Unstable or Experimental (not yet sure,
not much tested yet).


signature.asc
Description: Digital signature

Bug#641867: screen version bump (4.1.0 20101110git066b098)

[Brian Kroth]

Axel Beckert a...@debian.org 2011-09-17 12:02:

Hi Brian,

Brian Kroth wrote:

Package: screen
Version: 4.1.0-20101110git066b098
Severity: wishlist

The screen developers have been working on new features for screen for a
while, though an official release keeps getting put off.


Yeah. When I saw your mail, I first thought Yay! 4.1.0 is out! --
and then noticed that you're talking about snapshots... ;-)


Yeah, I wish.  I would look into tmux more since I hear it has a bit 
more active momentum and features behind it, but I know screen well at 
this point and don't really have time to learn new tricks just yet.


Really, I justed wanted searchable window lists so I don't end up with 
more windows for the same host when I can't find it right away.  Too 
many VMs :}



I noticed the other day that Fedora 15 is shipping with a git
snapshotted version of screen, which seems to work fairly well.
Included in it are increased MAXWIN sizes, the ability to group
windows and search for them in the window list by name, as well as
many other very helpful features.


Well, if you take a newer snapshot, some more bugs reported in Debian
(like the crash when resizing to one row height with having a caption)
would be fixed, too, see http://bugs.debian.org/532240)...

But the stability is of course also an argument, at least on the long
run.


Yeah, that was my take as well.  In fact the main reason I grabbed this 
one and not a newer one is because that's what Fedora was using, so I 
figured 1) they already vetted it to a certain degree, 2) there's some 
other community backing behind it and consistency might be good there, 
3) I have no idea how I'd find another stable snapshot from screen's 
git repo.  Anyways, there may be a better option out there.



Attached (shortly) is a first crack attempt at packaging that version
for Debian.  I went through the slew of Debian patches and kept/fixed
the ones that worked and still looked to be needed, and weeded out the
ones that have been applied upstream.


One small remark after a first look: If you use the upcoming version
number als base, you should use a tilde (~) directly after it
otherwise finally uploading the released 4.1.0 would be quite
complicated:

 4.1.0~20101110git066b098

Additionally the dash which was included at that point before would
have marked 20101110git066b098 as Debian revision which should just
indicate packaging changes. And at least the part git066b098 wouldn't
be packaging changes. And dates for revisions are very uncommon. So
the right version number for the package would be

 4.1.0~20101110git066b098-1


Thanks for the tips.  I thought something like that or + was probably 
more appropriate, but couldn't remember the exact details.



Please consider including support for it.


Since the current maintainer of screen in Debian is quite busy in real
life at the moment, I'm thinking about doing an Non-Maintainer Upload
(NMU) for screen. Your packaging work comes in quite handy there,
thanks! :-)


No problem.  I just happened to have a free day from work and school for 
once and decided I would tackle a wish list project of my own and pass 
the work along.  Unfortunately, I doubt I'd be able to handle full time 
support of this either.  I'd certainly try and lend a hand where 
possible though.



BTW, any idea when 4.1.0 will be out finally?


Unfortunately no, I just lurk on their mailing list waiting for news of 
a release, but I think the main dev there is also fairly busy with real 
life.


Brian


signature.asc
Description: Digital signature

Bug#641867: screen version bump (4.1.0 20101110git066b098)

[Brian Kroth]

Package: screen
Version: 4.1.0-20101110git066b098
Severity: wishlist


The screen developers have been working on new features for screen for a 
while, though an official release keeps getting put off.

I noticed the other day that Fedora 15 is shipping with a git 
snapshotted version of screen, which seems to work fairly well.  
Included in it are increased MAXWIN sizes, the ability to group windows 
and search for them in the window list by name, as well as many other 
very helpful features.

Attached (shortly) is a first crack attempt at packaging that version 
for Debian.  I went through the slew of Debian patches and kept/fixed 
the ones that worked and still looked to be needed, and weeded out the 
ones that have been applied upstream.

Please consider including support for it.

Let me know if there are any questions.

Thanks,
Brian

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages screen depends on:
ii  dpkg  1.15.8.11  Debian package management system
ii  install-info  4.13a.dfsg.1-6 Manage installed documentation in 
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libncurses5   5.7+20100313-5 shared libraries for terminal hand
ii  libpam0g  1.1.1-6.1  Pluggable Authentication Modules l

screen recommends no packages.

screen suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628032: gdm3: Disabling restart buttons via /apps/gdm/simple-greeter/disable_restart_buttons value does not take effect

[Brian Kroth]

I can also confirm this behavior, the fact that it's undesirable in a 
lab environment, and that the patch provided fixes it.


Brian


signature.asc
Description: Digital signature

Bug#632350: fai-client: exporting boot cmdline arguments with dashes (eg: live-netdev=eth0) results in an error

[Brian Kroth]

Package: fai-client
Version: 3.4.8
Severity: normal


I recently discovered that booting machines with multiple NICs would 
periodically result in a hang during the boot process.  Some digging 
through the live-boot-initramfs-tools (2.0.15-1) scripts (specifically 
/usr/share/initramfs-tools/scripts/live-premount/select_eth_device) 
informed me that I could skip the auto-detection of the which interface 
was alive and usable by adding the following to my pxe kernel's boot 
line: live-netdev=eth0 ip=eth0:dhcp (instead of just ip=dhcp).  
However, now this results in a bash error since you can't export 
variables with a dash in them.  For example:


Kernel currently running: Linux 2.6.38-grml64 x86_64 GNU/Linux
Kernel parameters: initrd=initrd.img-2.6.38-grml64 live-netdev=eth0 ip=eth0:dhcp root=/dev/nfs nfsroot=10.12.12.92:/install/fai/nfsroot/amd64/squeeze boot=live FAI_FLAGS=sshd,verbose FAI_ACTION=sysinfo -- squeeze amd64_squeeze squeeze_amd64 BOOT_IMAGE=vmlinuz-2.6.38-grml64

/usr/lib/fai/subroutines: line 674: export: `live-netdev=eth0': not a valid 
identifier

I'm guessing the simple fix to this is to just sed those variable names 
from - to _.  Something like this:


--- 
/install/fai/nfsroot/i386/squeeze/live/filesystem.dir//usr/lib/fai/subroutines  
2011-05-10 11:38:00.0 -0500
+++ 
/install/fai/nfsroot/amd64/squeeze/live/filesystem.dir//usr/lib/fai/subroutines 
2011-07-01 11:21:11.0 -0500
@@ -671,7 +671,10 @@
;;
 
[a-zA-Z]*=*)

-   eval export $word
+   #eval export $word
+   key=`echo $word | sed -r -e 's/^([^=]+)=.*/\1/' -e 's/-/_/g'`
+   value=`echo $word | sed -r -e 's/^[^=]+=(.*)/\1/'`
+   eval export $key=$value
;;
esac
 done

Thanks,
Brian

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-grml64 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages fai-client depends on:
ii  file  5.04-5 Determines file type using magic
ii  iproute   20100519-3 networking and traffic control too
ii  libapt-pkg-perl   0.1.24+b1  Perl interface to libapt-pkg
ii  perl  5.10.1-17  Larry Wall's Practical Extraction 


Versions of packages fai-client recommends:
ii  cfengine2 2.2.10-2   Tool for configuring and maintaini
ii  debconf-utils 1.5.36.1   debconf utilities

fai-client suggests no packages.

-- Configuration Files:
/etc/fai/fai.conf changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

Bug#619408: apache2.2-common: mod_authnz_ldap require directives unrecognized if loaded after mod_authnz_default

[Brian Kroth]

Stefan Fritsch s...@sfritsch.de 2011-03-23 23:01:
 On Wed, 23 Mar 2011, Brian P Kroth wrote:
 In the default configuration mod_authnz_ldap.load is symlinked from
 mods-available to mods-enabled but that orders it (lexicographically)
 after the symlink to load mod_authnz_default.  This causes a number of
 ldap specific arguments to the Require definition to be unrecognized and
 logged as follows:
 
 [Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to
 /auth failed, reason: unknown require directive:ldap-user bpktest
 bpkroth
 
 This message is not produced by apache2's core or any of the default
 modules. Therefore I expect that the bug is in a third party module.
 To find out which module may be the culprit, enter as root:
 
 grep require: $(cat /proc/XXX/maps |fgrep .so|awk '{print $6}'|sort -u)
 
 Replace XXX with the pid of a running apache process.

Fixed your grep up and did this instead:

# for pid in `pgrep apache2`; do for so in `cat /proc/$pid/maps | fgrep .so | 
awk '{ print $6 }' | sort -u`; do strings $so | grep -qi 'unknown require 
directive:'  echo $so; done; done

Which turned up this:
/usr/lib/apache2/modules/mod_auth_plain.so

This is in this package:
# dpkg -S /usr/lib/apache2/modules/mod_auth_plain.so
libapache2-mod-auth-plain: /usr/lib/apache2/modules/mod_auth_plain.so

Anything else?

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#616172: clamav-daemon doesn't listen on ipv6 [::]

[Brian Kroth]

Török Edwin ed...@clamav.net 2011-03-03 12:45:
 BTW you can set clamd to listen to 127.0.0.1, and tunnel a connection to
 it using ssh, which supports IPv6.

stunnel would probably be even better, but in either case ... yuck.

Brian


signature.asc
Description: Digital signature

Bug#616172: clamav-daemon doesn't listen on ipv6 [::]

[Brian Kroth]

Török Edwin ed...@clamav.net 2011-03-03 12:35:
 On 2011-03-03 00:15, Brian P Kroth wrote:
  Package: clamav-daemon
  Version: 0.96.5+dfsg-1.1
  Severity: normal
  Tags: ipv6
  
  
  I'm trying to get clamd to listen over ipv6 (eg ::) but no options I've
  fed TCPAddr seem to allow for this - they just error out and clamd won't
  start.
  
  If I just specify TCPSocket it will only listen on 0.0.0.0.
  
  Let me know if you need anything else.
 
 freshclam supports IPv6, but could you please explain why clamd would
 need IPv6 support?

Sure.  It basically has to do with IPv4 exhaustion.

 You can only safely use clamd inside a LAN, and the LAN has IPv4 anyway.

It was not my intention to make this accessible outside our LAN, though
I could conceive of someone providing a nice load balanced pool for
something like this to at least a larger group.

 Also with IPv6 clamd would be routable from the outside world (because
 your machine would be), and anyone could issue commands to your clamd,
 unless explicitly firewall its port, so listening on IPv6 would be a
 security risk.

I perhaps should have explained that the logs I posted are sanitized for
public consumption.  We don't actually have RFC 1918s and even if we did
that seems like a step backwards.

For our main server subnet, we currently have a /23 of which only about
50 are left.  Like our IPv6 space, they are globally routable, but also
like our IPv6 space they are not publicly accessible.  There are
firewalls in the way, so that's not actually a risk.

Besides, due to the way IPv6 operates, everything on that LAN has
already given itself an IPv6 address (so long as it listens to RAs).
That doesn't necessarily mean that we've associated a  with it.

Given that we have so few addresses left (and with VMs and SSL they are
likely to disappear quickly) and with ARIN's recent announcement aren't
likely to get any more at our level or above us, I have been making an
effort to make all new services we roll out be IPv6 enabled.  That way,
in a pinch, or hopefully before that, we can just yank their IPv4
addresses.  Much of our internal management traffic already flows over
IPv6 (dns, ldap, ntp, imap, smtp, syslog, etc.).

Further, if you really wanted to make them only locally available, you
could setup unique local addressing in IPv6 space.

The point is that the network protocol being used should not imply any
sort of globally accessible service, nor I think should applications
make assumptions about what is a permissible means of establishing a
connection between two hosts.

Hope that makes the case clearly enough for you.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#607685: configs

[Brian Kroth]

Attached are the configs I'd mentioned.


pxelinux.cfg.tar.bz2
Description: Binary data


signature.asc
Description: Digital signature

Bug#607685: syslinux-common: can't pxeboot with several *.c32 files in version 2:4.02+dfsg-7

[Brian Kroth]

Daniel Baumann dan...@debian.org 2010-12-21 07:14:
 Hi,
 
 can you please try with 4.03+dfsg-3 from experimental? the problem
 in pxelinux is supposedly fixed there.
 
 Regards,
 Daniel

That seems to have solved it.

Thanks very much,
Brian


signature.asc
Description: Digital signature

Bug#586888: patch results

[Brian Kroth]

FYI, I've tested your patch against the 2.8.1 package from backports and
it seems to work.  It wouldn't apply against the 2.7.4 package in lenny.

Thanks for catching this and supplying the patch.  It's been an oddity
we couldn't nail down for a while.

Brian


signature.asc
Description: Digital signature

Bug#583319: [Pkg-openldap-devel] Bug#583319: slapd: built-in schema for uidNumber/gidNumber does not have ordering directive

[Brian Kroth]

Arthur de Jong adej...@debian.org 2010-07-29 22:53:
 On Tue, 2010-07-27 at 18:17 -0700, Quanah Gibson-Mount wrote: 
  In any case, adding an ORDERING rule for them breaks the RFC's, and 
  OpenLDAP does its best to remain RFC compliant in core features.  I would 
  suggest filing a new RFC that updates the rules for these attributes.
 
 You may be interested in this:
 http://tools.ietf.org/html/draft-howard-rfc2307bis-02
 
 Though it has not seen much activity lately and the status is somewhat
 unclear.
 
 -- 
 -- arthur - adej...@debian.org - http://people.debian.org/~adejong --

Goodie, I was wondering how I would go about starting an RFC.  Seemed a
bit intimidating for such a simple thing as allowing an ordering
constraint :)

In the meantime I've hacked up a solution for us that adds locally
defined attributes that do include the ORDERING constraint to all local
account and groups objects which are generated from a database.  Now
people can put filters like this in their libnss-ldap.conf:
nss_base_group  ou=Group,o=Local?one?localGID=1000

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#583319: slapd: built-in schema for uidNumber/gidNumber does not have ordering directive

[Brian Kroth]

  Package: slapd
  Version: 2.4.11-1+lenny1
  Severity: normal
 
  Hello,
 
  It is frequently useful to be able to do searches like
  (uidNumber=1).  This used to be possible by munging the NIS
  schema to include:
  ORDERING integerOrderingMatch
 
  on the uidNumber and gidNumber attributes.  Now that the attributes
  are built in, this is not possible.
 
  Please consider adding an ORDERING directive to the attribute
  definition.

+1

 Why don't you just modify it, using ldapmodify against the cn=config 
 database?

Do you have an example of how to do this?  I converted my confs from
slapd.conf to slapd.d, updated the cn=schema.ldif file and still have
the same problem.

 I don't see anything here for Debian to do.  I would suggest, of course, 
 using a current release, given the antiquity of 2.4.11 at this point.

That's all Debian Lenny has at the moment.  Though the same problem
exists with Squeeze (slapd version 2.4.17-2.1).

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#583319: slapd: built-in schema for uidNumber/gidNumber does not have ordering directive

[Brian Kroth]

Brian Kroth bpkr...@gmail.com 2010-07-27 16:52:
   Package: slapd
   Version: 2.4.11-1+lenny1
   Severity: normal
  
   Hello,
  
   It is frequently useful to be able to do searches like
   (uidNumber=1).  This used to be possible by munging the NIS
   schema to include:
   ORDERING integerOrderingMatch
  
   on the uidNumber and gidNumber attributes.  Now that the attributes
   are built in, this is not possible.
  
   Please consider adding an ORDERING directive to the attribute
   definition.
 
 +1
 
  Why don't you just modify it, using ldapmodify against the cn=config 
  database?
 
 Do you have an example of how to do this?  I converted my confs from
 slapd.conf to slapd.d, updated the cn=schema.ldif file and still have
 the same problem.

Actually, according to [1] I don't think this is possible with direct
ldapmodify commands against cn=schema,cn=config either.  I've hacked at
it for a good long while now and I just get back this message:
ldap_modify: Other (e.g., implementation specific) error (80)

The slapd debug logs show a whole bunch of these:
...
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #34 
olcAttributeTypes: 1.3.6.1.4.1.1466.101.120.16 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #35 
olcAttributeTypes: Duplicate attributeType: 2.5.4.1 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #36 
olcAttributeTypes: 2.16.840.1.113730.3.1.34 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #37 
olcAttributeTypes: 1.3.6.1.4.1.4203.1.3.1 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #38 
olcAttributeTypes: 1.3.6.1.4.1.4203.1.3.2 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #39 
olcAttributeTypes: 1.3.6.1.4.1.4203.666.1.8 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #40 
olcAttributeTypes: 1.3.6.1.4.1.4203.666.1.9 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #41 
olcAttributeTypes: 1.3.6.1.4.1.1466.101.119.3 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #42 
olcAttributeTypes: 1.3.6.1.4.1.1466.101.119.4 is operational 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #43 
olcAttributeTypes: Duplicate attributeType: 2.5.4.49 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #44 
olcAttributeTypes: Duplicate attributeType: 2.5.4.41 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #45 
olcAttributeTypes: Duplicate attributeType: 2.5.4.3 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #46 
olcAttributeTypes: Duplicate attributeType: 0.9.2342.19200300.100.1.1 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #47 
olcAttributeTypes: Duplicate attributeType: 1.3.6.1.1.1.1.0 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #48 
olcAttributeTypes: Duplicate attributeType: 1.3.6.1.1.1.1.1 
Jul 27 18:00:26 gummo slapd[11673]: olcAttributeTypes: value #49 
olcAttributeTypes: Duplicate attributeType: 2.5.4.35 
...

A diff of a dump of the cn=schema,cn=config object doesn't show any
changes before or after the ldapmodify.

I've attached my ldif for your review.

Thanks,
Brian

[1] 
http://www.openldap.org/doc/admin24/appendix-changes.html#Better%20{{B:cn=schema}}%20functionality
version: 1
# to apply these changes using ldapvi, run:
#   ldapvi --ldapmodify -h unixauth-master-dev 
idNumber-schema-ordering-changes.ldif

dn: cn=schema,cn=config
changetype: modify
replace: olcAttributeTypes
olcAttributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 
'RFC4519: user identifier' EQUALITY caseIgnoreMatch SUBSTR 
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
olcAttributeTypes: ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'RFC2307: An integer 
uniquely identifying a user in an administrative domain' EQUALITY integerMatch 
ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE 
)
olcAttributeTypes: ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'RFC2307: An integer 
uniquely identifying a group in an administrative domain' EQUALITY integerMatch 
ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE 
)
olcAttributeTypes: ( 1.3.6.1.1.16.4 NAME 'entryUUID' DESC 'UUID of the entry' 
EQUALITY UUIDMatch ORDERING UUIDOrderingMatch SYNTAX 1.3.6.1.1.16.1 
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
olcAttributeTypes: ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' 
EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
olcAttributeTypes: ( 1.3.6.1.1.4 NAME 'vendorName' DESC 'RFC3045: name of 
implementation vendor' EQUALITY caseExactMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE 
dSAOperation )
olcAttributeTypes: ( 1.3.6.1.1.5 NAME 'vendorVersion' DESC 'RFC3045: version of 
implementation' EQUALITY

Bug#590491: virt-manager 0.8.4-4~bpo50+2 error on new virtual machine dialog for usermode sessions

[Brian Kroth]

Package: virt-manager
Version: 0.8.4-4~bpo50+2

When attempting to create a new VM using the virt-manager dialogs
attached to a a usermode session (eg: virt-manager -c qemu:///session)
the following error is returned:

2010-07-26 14:00:36,800 (create:314): Error setting create wizard conn state.
Traceback (most recent call last):
  File /usr/share/virt-manager/virtManager/create.py, line 312, in reset_state
self.set_conn(activeconn, force_validate=True)
  File /usr/share/virt-manager/virtManager/create.py, line 184, in set_conn
self.set_conn_state()
  File /usr/share/virt-manager/virtManager/create.py, line 538, in 
set_conn_state
do_warn = uihelpers.populate_network_list(net_list, self.conn)
  File /usr/share/virt-manager/virtManager/uihelpers.py, line 287, in 
populate_network_list
add_row(nettype, None, pretty_network_desc(nettype), True)
  File /usr/share/virt-manager/virtManager/uihelpers.py, line 268, in add_row
model.append(build_row(*args))
TypeError: build_row() takes at least 5 arguments (4 given)

Attached is a screenshot.  This did not occur with 0.8.3-2~bpo50+1.

Please let me know if you need any more info.

Thanks,
Brian
attachment: gkrellShoot_2010-07-26_133821.png

signature.asc
Description: Digital signature

Bug#585756: mysql-server: debian-sys-maint user missing SHOW VIEW privilege

[Brian Kroth]

Package: mysql-server-5.0
Version: 5.0.51a-24+lenny4

The debian-sys-maint mysql user created in the postinst scripts of the
mysql-server package is missing the SHOW VIEW privilege.  This prevents
the user from performing certain dump operations which are useful for
scripting cronned mysql backups from replication slaves.

Let me know if you need more details.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#579249: package request: rt-extension-commandbymail

[Brian Kroth]

Package: rt-extension-commandbymail
Severity: wishlist


To someone more experienced in package maintenance than myself, please
consider adding a package for the RT (Request Tracker) extension
CommandByMail.

http://search.cpan.org/~falcone/RT-Extension-CommandByMail/lib/RT/Extension/CommandByMail.pm

I've attached my initial attempt at doing so.  It's not very good.  I
had originally attempted to use dh-make-perl, then based the build off
of the rt-extension-emailcompletion package.

Thanks,
Brian
Format: 1.0
Source: rt-extension-commandbymail
Binary: rt3.8-extension-commandbymail
Architecture: all
Version: 0.08-01-4
Maintainer: Brian P Kroth bpkr...@cae.wisc.edu
Homepage: http://search.cpan.org/dist/RT-Extension-CommandByMail/
Standards-Version: 3.8.0
Build-Depends: debhelper (= 5)
Build-Depends-Indep: perl (= 5.6.10-12), quilt
Checksums-Sha1: 
 41fa2d1ad108c9790769ee481fe5a06a6dc1b691 56327 
rt-extension-commandbymail_0.08-01.orig.tar.gz
 634b1375f98d49985d63cb1d89dcda6c8e4d5485 7448 
rt-extension-commandbymail_0.08-01-4.diff.gz
Checksums-Sha256: 
 b7c2d54d8a8f8a31cd035dc3985113f50cc672375e30cea2d42e11d04b168314 56327 
rt-extension-commandbymail_0.08-01.orig.tar.gz
 ed60f71e34f205781d8d7033e7248eeb74da0105f77d843695181e7482982cef 7448 
rt-extension-commandbymail_0.08-01-4.diff.gz
Files: 
 c5c530f64208350187a87502855e0883 56327 
rt-extension-commandbymail_0.08-01.orig.tar.gz
 071d60dbba2af128a58ef868f3dbe160 7448 
rt-extension-commandbymail_0.08-01-4.diff.gz


rt-extension-commandbymail_0.08-01-4.diff.gz
Description: Binary data


signature.asc
Description: Digital signature

Bug#575628: [Pkg-libvirt-maintainers] Bug#575628: pxe not working with libvirt 0.7.7 + qemu-kvm 0.12

[Brian Kroth]

Guido Günther a...@sigxcpu.org 2010-03-28 14:53:
 On Sat, Mar 27, 2010 at 02:15:45PM -0500, Brian Kroth wrote:
  Package: libvirt-bin, qemu-kvm
  Severity: important
  
  Attempts to PXE boot with these two versions give the following error 
  message:
  
  # virsh start faitest32
  error: Failed to start domain faitest32
  error: internal error Process exited while reading console log output: char 
  device redirected to /dev/pts/1
  Cannot boot from non-existent NIC
  
  From /var/log/libvirt/qemu/faitest32.log:
  
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
  HOME=/local.hd/users/bpkroth USER=root LOGNAME=root QEMU_AUDIO_DRV=none 
  /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 
  1,sockets=1,cores=1,threads=1 -name faitest32 -uuid 
  2b09b863-c3ca-a819-8580-4763a3fdd61d -nodefaults -chardev 
  socket,id=monitor,path=/var/lib/libvirt/qemu/faitest32.monitor,server,nowait
   -mon chardev=monitor,mode=readline -rtc base=utc -boot dnc -drive 
  if=none,media=cdrom,id=drive-ide0-1-0,format=raw -device 
  ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive 
  file=/home/vms/images/faitest32/faitest32.img,if=none,id=drive-virtio-disk0,boot=on,format=raw
   -device 
  virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 
  -drive 
  file=/home/vms/images/faitest32/faitest32-2.img,if=none,id=drive-virtio-disk1,format=raw
   -device 
  virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 
  -device 
  virtio-net-pci,vlan=0,id=net0,mac=52:54:00:a1:90:92,bus=pci.0,addr=0x4 
  -net tap,fd=56,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device 
  isa-serial,chardev=serial0 -usb -vnc 
  0.0.0.0:0,password,tls,x509=/etc/pki/libvirt-vnc -k en-us -vga vmware 
  -device i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset 
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
  char device redirected to /dev/pts/1
  Cannot boot from non-existent NIC
 Could you try to add execute this by hand and find the offending
 option?
  -- Guido

Yeah, I did that.  It's as the other bug I linked said.  Basically,
libvirt changed the way it arranges the command lines from the XML so
that what was this in =0.7.5:

-net nic,macaddr=52:54:00:a1:90:92,vlan=0,model=virtio,name=virtio.0 -net 
tap,fd=22,vlan=0,name=tap.0

became this in 0.7.7 (possibly also 0.7.6):

-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:a1:90:92,bus=pci.0,addr=0x4 
-net tap,fd=23,vlan=0,name=hostnet0

The problem appears to be that qemu 0.12.3 (possibly for earlier
versions as well) doesn't parse the -device virtio-net... option as
being a NIC, so it fails to boot from it.  I have tried this with other
NIC models as well and they all result in the same problem - if the NIC
definition is given as a -device instead of a -net nic, then qemu
refuses to boot from it.

Luckily I had a previous version of libvirt and company lying around on
a mirror server at work so I was able to revert that and get back to my
PXE booting.  I couldn't find previous versions (0.11.1+dfsg-1 is where
I was) for the qemu-kvm package to see if this still happened there.

I'll also note that libvirt 0.7.7 rearranges the XML so that the
address... blocks always appear, so I don't think it's possible to
convince it to go back to using the -net nic style of arguments.

Brian


signature.asc
Description: Digital signature

Bug#575614: timer-entropyd -- feed the /dev/random device with entropy data read from timer statistics

[Brian Kroth]

Package: timer-entropyd
Severity: wishlist

Please consider adding a package for timer-entropyd.  This program
provides a mechanism for gathering entropy on devices that have no
hardware to do so (eg: virtual machines).

Details about the package can be found here:
http://www.vanheusden.com/te/

See Also:
audio-entropyd
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526470

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#575615: entropy-broker -- distribute entropy data to remote hosts

[Brian Kroth]

Package: entropy-broker
Severity: wishlist

Please consider providing a package for entropy-broker.  This program
provides a mechanism for distributing entropy gathered from various
hardware and software sources to clients such as virtual machines which
may not have good sources to gather their own entropy from.

More details are available here:
http://www.vanheusden.com/entropybroker/

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#575628: pxe not working with libvirt 0.7.7 + qemu-kvm 0.12

[Brian Kroth]

Package: libvirt-bin, qemu-kvm
Severity: important

Attempts to PXE boot with these two versions give the following error message:

# virsh start faitest32
error: Failed to start domain faitest32
error: internal error Process exited while reading console log output: char 
device redirected to /dev/pts/1
Cannot boot from non-existent NIC

From /var/log/libvirt/qemu/faitest32.log:

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
HOME=/local.hd/users/bpkroth USER=root LOGNAME=root QEMU_AUDIO_DRV=none 
/usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 
1,sockets=1,cores=1,threads=1 -name faitest32 -uuid 
2b09b863-c3ca-a819-8580-4763a3fdd61d -nodefaults -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/faitest32.monitor,server,nowait 
-mon chardev=monitor,mode=readline -rtc base=utc -boot dnc -drive 
if=none,media=cdrom,id=drive-ide0-1-0,format=raw -device 
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive 
file=/home/vms/images/faitest32/faitest32.img,if=none,id=drive-virtio-disk0,boot=on,format=raw
 -device 
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 
-drive 
file=/home/vms/images/faitest32/faitest32-2.img,if=none,id=drive-virtio-disk1,format=raw
 -device 
virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 
-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:a1:90:92,bus=pci.0,addr=0x4 
-net tap,fd=56,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device 
isa-serial,chardev=serial0 -usb -vnc 
0.0.0.0:0,password,tls,x509=/etc/pki/libvirt-vnc -k en-us -vga vmware -device 
i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
char device redirected to /dev/pts/1
Cannot boot from non-existent NIC

# virsh dumpxml faitest32
domain type='kvm'
  namefaitest32/name
  uuid2b09b863-c3ca-a819-8580-4763a3fdd61d/uuid
  memory524288/memory
  currentMemory524288/currentMemory
  vcpu1/vcpu
  os
type arch='i686' machine='pc-0.12'hvm/type
boot dev='cdrom'/
boot dev='network'/
boot dev='hd'/
  /os
  features
acpi/
apic/
pae/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashrestart/on_crash
  devices
emulator/usr/bin/kvm/emulator
disk type='file' device='cdrom'
  driver name='qemu' type='raw'/
  target dev='hdc' bus='ide'/
  readonly/
  address type='drive' controller='0' bus='1' unit='0'/
/disk
disk type='file' device='disk'
  driver name='qemu' type='raw'/
  source file='/home/vms/images/faitest32/faitest32.img'/
  target dev='vda' bus='virtio'/
  address type='pci' domain='0x' bus='0x00' slot='0x05' 
function='0x0'/
/disk
disk type='file' device='disk'
  driver name='qemu' type='raw'/
  source file='/home/vms/images/faitest32/faitest32-2.img'/
  target dev='vdb' bus='virtio'/
  address type='pci' domain='0x' bus='0x00' slot='0x06' 
function='0x0'/
/disk
controller type='ide' index='0'
  address type='pci' domain='0x' bus='0x00' slot='0x01' 
function='0x1'/
/controller
interface type='bridge'
  mac address='52:54:00:a1:90:92'/
  source bridge='br2'/
  model type='virtio'/
  address type='pci' domain='0x' bus='0x00' slot='0x04' 
function='0x0'/
/interface
serial type='pty'
  target port='0'/
/serial
console type='pty'
  target port='0'/
/console
input type='mouse' bus='ps2'/
graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' 
keymap='en-us'/
video
  model type='vmvga' vram='9216' heads='1'/
  address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
/video
watchdog model='i6300esb' action='reset'
  address type='pci' domain='0x' bus='0x00' slot='0x07' 
function='0x0'/
/watchdog
  /devices
/domain

This is similar to the following report:
http://www.mail-archive.com/libvir-l...@redhat.com/msg21531.html

# dpkg -l | egrep -i 'qemu-kvm|libvirt-bin'
ii  libvirt-bin 0.7.7-1 the 
programs for the libvirt library
ii  qemu-kvm0.12.3+dfsg-4   Full 
virtualization on x86 hardware

Let me know if you need any other info.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#575628: Acknowledgement (pxe not working with libvirt 0.7.7 + qemu-kvm 0.12)

[Brian Kroth]

Here's another probably related bug:
https://bugzilla.redhat.com/show_bug.cgi?id=572495

I was able to revert libvirt-bin and company back to 0.7.5-6 and now
pxe boot is working again.

Here's the new command that was used by libvirt to start the vm:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
HOME=/local.hd/users/bpkroth USER=root LOGNAME=root QEMU_AUDIO_DRV=none 
/usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 1 -name 
faitest32 -uuid 2b09b863-c3ca-a819-8580-4763a3fdd61d -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/faitest32.monitor,server,nowait 
-monitor chardev:monitor -boot ndc -drive if=ide,media=cdrom,index=2,format=raw 
-drive 
file=/home/vms/images/faitest32/faitest32.img,if=virtio,index=0,boot=on,format=raw
 -drive 
file=/home/vms/images/faitest32/faitest32-2.img,if=virtio,index=1,format=raw 
-net nic,macaddr=52:54:00:a1:90:92,vlan=0,model=virtio,name=virtio.0 -net 
tap,fd=21,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 
-parallel none -usb -vnc 0.0.0.0:0,tls,x509=/etc/pki/libvirt-vnc,sasl -k en-us 
-vga vmware -watchdog i6300esb -watchdog-action reset 
char device redirected to /dev/pts/7

Here's the current set of packages:

$ dpkg -l | egrep -i 'libvirt|qemu|kvm'
ii  libvirt-bin 0.7.5-6 the 
programs for the libvirt library
ii  libvirt-doc 0.7.5-6 
documentation for the libvirt library
ii  libvirt00.7.5-6 library for 
interfacing with different virtualization systems
ii  python-libvirt  0.7.5-6 libvirt 
Python bindings
ii  qemu0.11.1-2fast 
processor emulator
ii  qemu-kvm0.12.3+dfsg-4   Full 
virtualization on x86 hardware
ii  qemu-system 0.11.1-2QEMU full 
system emulation binaries
ii  qemu-user   0.11.1-2QEMU user 
mode emulation binaries
ii  qemu-utils  0.11.1-2QEMU 
utilities
ii  vgabios 0.6c-2  VGA BIOS 
software for the Bochs and Qemu emulated VGA card

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#568794: fai-client 3.3.3: setup-storage fails to match some squeeze programs output

[Brian Kroth]

Package: fai-client
Version: 3.3.3

There are actually two problems in this bug report.  Both are
essentially problems with regex matching of program output that has
changed slightly with squeeze.  I have supplied a patch for both.

1) squeeze's mdadm reports arrays using the path /dev/md/0 instead of
/dev/md0 which results in the following error:
mdadm ARRAY line not yet seen

2) squeeze's parted reports sizes using GiB instead of GB which results
in the following error (for example):
convert_unit 3.75GiB

Attached is a very minor patch that should allow matching of updated
programs' outputs as well as remain backwards compatible with the old
style.

Thanks,
Brian
diff -Nur fai-client_3.3.3_all/usr/share/fai/setup-storage/Parser.pm 
fai-client_3.3.3_all.patched/usr/share/fai/setup-storage/Parser.pm
--- fai-client_3.3.3_all/usr/share/fai/setup-storage/Parser.pm  2010-02-03 
04:52:51.0 -0600
+++ fai-client_3.3.3_all.patched/usr/share/fai/setup-storage/Parser.pm  
2010-02-07 13:05:13.0 -0600
@@ -298,7 +298,12 @@
 sub convert_unit
 {
   my ($val) = @_;
-  ($val =~ /^(\d+(\.\d+)?)([kMGTP%]?)(B)?\s*$/) or
+  # Making the match work for squeeze machines too.
+  # The display units in terms of GiB, where the 'i' is new.
+  # 2010-02-07
+  # bpkroth
+  #($val =~ /^(\d+(\.\d+)?)([kMGTP%]?)(B)?\s*$/) or
+  ($val =~ /^(\d+(\.\d+)?)([kMGTP%]?)[i]?(B)?\s*$/) or
 FAI::internal_error(convert_unit $val);
   $val = $1 * (1 / 1024) * (1 / 1024) if ($3 eq   defined ($4)  $4 eq 
B);
   $val = $1 * (1 / 1024) if ($3 eq k);
diff -Nur fai-client_3.3.3_all/usr/share/fai/setup-storage/Volumes.pm 
fai-client_3.3.3_all.patched/usr/share/fai/setup-storage/Volumes.pm
--- fai-client_3.3.3_all/usr/share/fai/setup-storage/Volumes.pm 2010-02-03 
04:52:51.0 -0600
+++ fai-client_3.3.3_all.patched/usr/share/fai/setup-storage/Volumes.pm 
2010-02-07 13:05:13.0 -0600
@@ -372,7 +372,12 @@
 
   # parse the output line by line
   foreach my $line (@mdadm_print) {
-if ($line =~ /^ARRAY \/dev\/md(\d+) level=(\S+) num-devices=\d+(\s+|$)/) {
+# Making the match work for squeeze machines as well.
+# They display arrays in terms of /dev/md/0 where the '/' is new.
+# 2010-02-07
+# bpkroth
+#if ($line =~ /^ARRAY \/dev\/md(\d+) level=(\S+) num-devices=\d+(\s+|$)/) {
+if ($line =~ /^ARRAY \/dev\/md[\/]?(\d+) level=(\S+) 
num-devices=\d+(\s+|$)/) {
   $id = $1;
   $FAI::current_raid_config{$id}{mode} = $2;
   FAI::push_command( true, , exist_/dev/md$id );


pgpbmZg582caF.pgp
Description: PGP signature

Bug#568203: fai-client 3.3.2: device2grub does not match qemu/kvm virtio devices (eg: /dev/vda)

[Brian Kroth]

Package: fai-client
Version: 3.3.2, 3.3.3

As the subject says, device2grub fails to match devices of the form
/dev/vda which appear from the use of virtio disks in qemu/kvm guests.

Basically a 'v' needs to be added in line 20.  eg:

$device=~ m#^(/dev/(?:[sh]d\D

becomes

$device=~ m#^(/dev/(?:[shv]d\D

Without this device2grub complains No match in devicemap for /dev/vda.

Thanks,
Brian


pgpBRNkSg5r3m.pgp
Description: PGP signature

Bug#566727: linux-image-2.6.32 missing memory cgroup controllers

[Brian Kroth]

maximilian attems m...@stro.at 2010-01-25 11:51:

snip

 see ongoing discussions about lxc flavour, you might want to jump in.

Sure, where can I find it?

 current conclusion is that we might enable aboves,
 but disable it on boot with modprobe.conf to not get overheads
 for the generic linux images.

That would be great.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#566727: linux-image-2.6.32 missing memory cgroup controllers

[Brian Kroth]

Package: linux-image-2.6.32-trunk-amd64
Version: 2.6.32-5
Severity: wishlist

Support for memory cgroups controllers are not included in the new
2.6.32 kernel.  This would be nice say for putting limits on a how much
memory a group of VMs can use.

I believe the following two options need to be enabled in the kernel:
CONFIG_RESOURCE_COUNTERS
CONFIG_CGROUP_MEM_RES_CTLR

Here's some more info:

# dpkg -l | grep linux-image-2.6.32
ii  linux-image-2.6.32-trunk-amd64  2.6.32-5 Linux 2.6.32 for 64-bit PCs

# uname -a
Linux oberon 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 
GNU/Linux

# cat /proc/cgroups 
#subsys_namehierarchy   num_cgroups enabled
cpuset  0   1   1
ns  0   1   1
cpu 11  8   1
cpuacct 11  8   1
devices 11  8   1
freezer 0   1   1
net_cls 0   1   1

# cat /etc/debian_version 
squeeze/sid

See Also:
http://berrange.com/personal/diary/2009/12/using-cgroups-with-libvirt-and-lxckvm

Let me know if you need any more info.

Thanks,
Brian


signature.asc
Description: Digital signature

Bug#535475: open-vm-tools: new version (2009.06.18-172495) available

[Brian Kroth]

vmtoolsd also exits immediately.  Seems to be missing something.
Attached is an strace.

Brian
execve(/usr/bin/vmtoolsd, [vmtoolsd], [/* 21 vars */]) = 0
brk(0)  = 0x9d93000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7fa1000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=38668, ...}) = 0
mmap2(NULL, 38668, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f97000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libvmtools.so.0, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2603\1\0004\0\0\0\314..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=406828, ...}) = 0
mmap2(NULL, 413012, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7f32000
mmap2(0xb7f87000, 61440, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x54) = 0xb7f87000
mmap2(0xb7f96000, 3412, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f96000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0H..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9680, ...}) = 0
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7f2e000
mmap2(0xb7f3, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7f3
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libdumbnet.so.1, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320+\0\0004\0\0\0$..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=37092, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7f2d000
mmap2(NULL, 44200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7f22000
mmap2(0xb7f2a000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0xb7f2a000
mmap2(0xb7f2b000, 7336, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f2b000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libcrypt.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 
\7\0\0004\0\0\0008..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=38296, ...}) = 0
mmap2(NULL, 201052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7ef
mmap2(0xb7ef9000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0xb7ef9000
mmap2(0xb7efb000, 155996, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7efb000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libpthread.so.0, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\H\0\0004\0\0\0\330..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=116414, ...}) = 0
mmap2(NULL, 98784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7ed7000
mmap2(0xb7eec000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7eec000
mmap2(0xb7eee000, 4576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eee000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libgmodule-2.0.so.0, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\16\0\0004\0\0\0\200..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=10128, ...}) = 0
mmap2(NULL, 13080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7ed3000
mmap2(0xb7ed6000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7ed6000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libgobject-2.0.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0Pz\0\0004\0\0\0 ..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=245296, ...}) = 0
mmap2(NULL, 245516, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7e97000
mmap2(0xb7ed2000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b) = 0xb7ed2000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libgthread-2.0.so.0, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\20\0\0004\0\0\0\220..., 
512) = 512
fstat64(3, 

Bug#535471: ocfs2-tools: new version (1.4.2) available

[Brian Kroth]

Package: ocfs2-tools
Version: 1.4.2-1
Severity: wishlist

A new version of ocfs2-tools is available and includes a number of nice
features including: inline-data (data-in-inode), relatime, xattr, acls,
jbd2, etc.  Some of these were supported by previous kernels, but the
tools support necessary to take advantage of them was lacking.

http://oss.oracle.com/pipermail/ocfs2-announce/2009-June/28.html
http://oss.oracle.com/projects/ocfs2-tools/news/article_7.html

I'm looking to upgrade a cluster of mine relatively soon and would like
to make use of this.  Mostly just wondering if an updated package was
already planned, or if I should roll my own.

Thanks,
Brian



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#535475: open-vm-tools: new version (2009.06.18-172495) available

[Brian Kroth]

Package: open-vm-tools
Version: 2009.06.18-172495
Severity: wishlist

A new version of open-vm-tools is available [1] which may help with the
following bugs as well as building modules for 2.6.30 kernels: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525816
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531936
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532293

Thanks,
Brian

[1] 
http://sourceforge.net/project/shownotes.php?group_id=204462release_id=690876



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#535475: open-vm-tools: new version (2009.06.18-172495) available

[Brian Kroth]

Excellent :)  

Thank you very much,
Brian

Daniel Baumann dan...@debian.org 2009-07-02 16:14:
 Brian Kroth wrote:
  A new version of open-vm-tools is available [1] which may help with the
  following bugs as well as building modules for 2.6.30 kernels: 
 
 i know.. i've already commited it in git.. will upload it on the weekend
 after testing.
 
 -- 
 Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
 Email:  daniel.baum...@panthera-systems.net
 Internet:   http://people.panthera-systems.net/~daniel-baumann/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532321: fai-client 3.2.20: setup-storage with preserve_reinstall and lvm fails

[Brian Kroth]

Package: fai-client
Version: 3.2.17~lenny1, 3.2.20

So the basic problem is that the setup-storage script doesn't properly
find the logical volumes it's supposed to preserve when they exist.

Here's a full example:

- First, a disk_config

# TEST
# 2009-06-01
# bpkroth
#
# This file is a disk_config file uses the setup-storage syntax to create an
# LVM'd vm server disk layout that preserves partitions.  It is expected to
# be at least 12G.
#

# Setup the first disk to use an msdos partition table and two partitions, one
# for /boot and the rest for LVM.

disk_config disk1 bootable:1 fstabkey:label
# preserve_reinstall:2
primary /boot   256Mext3defaults,rw 
createopts=-L boot
primary -   10G--   -

# Setup LVM to contain all the system partitions.
# Make sure that /local.hd is preserved unless it doesn't exist and gets
# to claim almost all of whatever's left.  It leaves a little bit in
# case we need to resize later.
 
vg vg disk1.2

disk_config lvm fstabkey:label preserve_reinstall:vg-localhd
vg-swap swap512M-1G swapsw 
createopts=-L swap
vg-root /   4G-8G   ext3
defaults,rw,errors=remount-ro createopts=-L root
vg-var  /var1G-2G   ext3defaults,rw 
createopts=-L var
vg-localhd  /local.hd   1-90%   ext3
defaults,rw,nosuid,nodev createopts=-L local.hd -m 1


- Next, run the config:

# parted /dev/sda mklabel msdos # necessary for fresh VMDKs.
# flag_initial=1 disklist=sda setup-storage -X -f /tmp/TEST

- Next, remove a logical volume:
# lvremove -f vg/root

- Run setup storage again (without flag_initial) to reinstall the
  partition.  Dies with this message:
Preserved volume vg/localhd does not exist.

Now, the problem happens to be that in Commands.pm two hashes are used,
FAI::config{volumes}{lv} and FAI::current_lvm_config{vg}{volumes}{lv},
except their keys are lv and /dev/vg/lv respectively.

Also, while testing that one I discovered that in Volumes.pm a bad
concatenation error occurs if the volume group exists but is empty.

Here's the error message for that one:
Use of uninitialized value in concatenation (.) or string at 
/usr/share/fai/setup-storage//Volumes.pm line 313.
Use of uninitialized value in concatenation (.) or string at 
/usr/share/fai/setup-storage//Volumes.pm line 313.
INTERNAL ERROR in setup-storage:
convert_unit
Please report this error to the Debian Bug Tracking System.

Attached is a patch to deal with both of these problems.

Brian
diff -rubB lib/setup-storage/Commands.pm 
/pong/usr5/b/bpkroth/tmp/setup-storage/Commands.pm
--- lib/setup-storage/Commands.pm   2009-06-08 08:00:59.0 -0500
+++ /pong/usr5/b/bpkroth/tmp/setup-storage/Commands.pm  2009-06-08 
08:19:42.0 -0500
@@ -374,7 +374,21 @@
   my $lv_resize_pre = ;
   # remove, resize, create the logical volumes
   # remove all volumes that do not exist anymore or need not be preserved
-  foreach my $lv (keys %{ $FAI::current_lvm_config{$vg}{volumes} }) {
+
+  # FIXME:
+  # There's a problem with this code since the
+  # FAI::current_lvm_config{vg}{volumes} hash has keys of the form /dev/vg/lv,
+  # but the FAI::configs{config}{volumes} hash has keys of the form lv.  I've
+  # tried to fix this in the few places I caught it so far as preserving
+  # partitions was concerned, but that's all.  I imagine this causes problems
+  # elsewhere as well.
+  # 2009-06-07
+  # bpkroth
+
+  foreach my $lv_path (keys %{ $FAI::current_lvm_config{$vg}{volumes} }) {
+my $lv = $lv_path;
+$lv =~ s#/dev/$vg/##;
+print STDERR lv: $lv\n;
 # skip preserved/resized volumes
 if (defined ( $FAI::configs{$config}{volumes}{$lv})
($FAI::configs{$config}{volumes}{$lv}{size}{preserve} == 1)) {
@@ -391,24 +405,25 @@
 
   # now create or resize the configured logical volumes
   foreach my $lv (keys %{ $FAI::configs{$config}{volumes} }) {
+my $lv_path = /dev/$vg/$lv;
 # reference to the size of the current logical volume
 my $lv_size = (\%FAI::configs)-{$config}-{volumes}-{$lv}-{size};
 # skip preserved partitions, but ensure that they exist
 if ($lv_size-{preserve}) {
-  defined ($FAI::current_lvm_config{$vg}{volumes}{$lv})
-or die Preserved volume $vg/$lv does not exist\n;
+  defined ($FAI::current_lvm_config{$vg}{volumes}{$lv_path}) or
+die Preserved volume $vg/$lv does not exist\n;
   warn $vg/$lv will be preserved\n;
   next;
 }
 
 # resize the volume
 if ($lv_size-{resize}) {
-  defined ($FAI::current_lvm_config{$vg}{volumes}{$lv})
+  defined ($FAI::current_lvm_config{$vg}{volumes}{$lv_path})
 or die Resized volume $vg/$lv does not exist\n;
   warn $vg/$lv will be resized\n;
 
   if ($lv_size-{eff_size} 
-$FAI::current_lvm_config{$vg}{volumes}{$lv}{size})
+