Bug#867311: Fixed upstream?

2018-04-04 Thread Ben Poliakoff 
It appears that this bug has been fixed upstream... is it likely that that
fix will make it to the stretch release? We won't be able to upgrade any of
our end user facing systems to stretch until this is resolved.

Ben

Bug#632129: Possible cause: GPG Interface

2011-11-03 Thread Ben Poliakoff 
* Nehmer Torben torben.neh...@cancom.de [2003 09:54]:
 Good evening,
 
 try disabling GPG in the configuration via something like this:
 
 Set( %GnuPG,
 Enable = undef,
 OutgoingMessagesFormat = 'RFC', # Inline
 AllowEncryptDataInDB   = 0,
 );
 
 It worked around the problem for me, as I do not want to use GPG. I have not 
 traced it any further, however. What I have here is a pretty standard Debian 
 Squeeze installation, installing RT4 from backports, running with modperl2.
 
 We have a test system available here, so if you want me to further 
 investigate it, please tell me what about you need (I am a developer, so I 
 should be able to manage if you give me a quick howto. ;-)).
 Best regards,
 Torben Nehmer

I can confirm that this has resolved the issue for us as well (running
squeeze with rt4 from backports).

Ben

-- 

PGP (318B6A97):  3F23 EBC8 B73E 92B7 0A67  705A 8219 DCF0 318B 6A97


signature.asc
Description: Digital signature

Bug#626553: cyrus-imapd: pts binaries (ptloader, ptdump, ptexpire) are not compiled

2011-05-12 Thread Ben Poliakoff 
Package: cyrus-imapd
Version: 2.4.8-4
Severity: normal


An LDAP backed pts config isn't possible with the current version of
the cyrus-imapd packages (the ptloader server and pt* utilities) aren't
built as part of the current Debian package.

This is essentially a duplicate of this bug report (which contains 
further details):

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

Which doesn't seem to be attached to the cyrus-imapd-2.2 package in stable
or the 2.4.x packages in testing/unstable.  Maybe it got lost in the shuffle?

Is there a reason not to enable the building of the ptloader and friends?
Without them it's not possible to do LDAP authorization with cyrus imapd.

I'd love to help resolve this issue (as LDAP authz is a critical part 
of my organization's cyrus installation).

Ben

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

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

Versions of packages cyrus-imapd depends on:
ii  cyrus-imapd-2.4   2.4.8-4Cyrus mail system - IMAP support

cyrus-imapd recommends no packages.

cyrus-imapd 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#626553: A patch proposal just to get things started...

2011-05-12 Thread Ben Poliakoff 
Here's a quick stab at a patch (doesn't include a sample config for
imapd.conf).

Ben

-- 

PGP (318B6A97):  3F23 EBC8 B73E 92B7 0A67  705A 8219 DCF0 318B 6A97
--- cyrus-imapd-2.4-2.4.8/debian/control	2011-05-12 02:00:11.0 -0700
+++ ../cyrus-imapd-2.4-2.4.8/debian/control	2011-05-12 14:41:18.0 -0700
@@ -32,7 +32,8 @@
 	   po-debconf,
 	   quilt ( 0.46-7~),
 	   transfig,
-	   xutils-dev
+	   xutils-dev,
+	   libldap2-dev
 Vcs-Git: git://git.debian.org/git/pkg-cyrus-imapd/pkg-cyrus-imapd-2.4.git
 Vcs-Browser: http://git.debian.org/?p=git/pkg-cyrus-imapd/pkg-cyrus-imapd-2.4.git
 Homepage: http://www.cyrusimap.org/
--- cyrus-imapd-2.4-2.4.8/debian/rules	2011-05-12 02:00:11.0 -0700
+++ ../cyrus-imapd-2.4-2.4.8/debian/rules	2011-05-12 14:15:37.0 -0700
@@ -94,7 +94,8 @@
 	 --with-com_err= \
 	 --with-pidfile=/var/run/cyrmaster.pid \
 	 --with-syslogfacility=MAIL \
-	 --with-ucdsnmp=/usr
+	 --with-ucdsnmp=/usr \
+	 --with-ldap=/usr
 	echo 'To build this package, configure was called as follows:' \
 		 debian/README.configure-options
 	grep '^ac_cs_config=' config.status \
--- cyrus-imapd-2.4-2.4.8/debian/cyrus-common-2.4.install	2011-05-12 02:00:11.0 -0700
+++ ../cyrus-imapd-2.4-2.4.8/debian/cyrus-common-2.4.install	2011-05-12 14:26:00.0 -0700
@@ -25,6 +25,9 @@
 usr/lib/cyrus/bin/smmapd
 usr/lib/cyrus/bin/notifyd
 usr/lib/cyrus/bin/fud
+usr/lib/cyrus/bin/ptloader
+usr/lib/cyrus/bin/ptdump
+usr/lib/cyrus/bin/ptexpire
 usr/lib/cyrus/upgrade/
 usr/sbin/cyr_dbtool
 usr/sbin/cyr_df

Bug#598397: libapache2-mod-xsendfile: Upstream versions offer useful new features

2010-09-28 Thread Ben Poliakoff 
Package: libapache2-mod-xsendfile
Version: 0.11.1-1
Severity: normal


Several useful features and bug fixes are available in the upstream
version:

http://tn123.ath.cx/mod_xsendfile/

Version 0.11.1

Fixed some documentation bugs
Built win32 binaries against latest httpd using MSVC9
Updated MSVC Project files

Version 0.11

Fixed large file support

Version 0.10

Won't override Etag/Last-Modified if already set.
New Configuration directive: XSendFileIgnoreEtag
New Configuration directive: XSendFileIgnoreLastModified
New Configuration directive: XSendFilePath
Removed Configuration directive: XSendFileAllowAbove
Use XSendFilePath instead.
Improved header handling for FastCGI/CGI output (removing duplicate 
headers).

It wasn't hard to make an updated version of the debian package based on
your existing work (in fact your work made it easy).

Thanks,

Ben Poliakoff

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

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

Versions of packages libapache2-mod-xsendfile depends on:
ii  apache2.2-common 2.2.9-10+lenny8 Apache HTTP Server common files
ii  libc62.7-18lenny4GNU C Library: Shared libraries

libapache2-mod-xsendfile recommends no packages.

libapache2-mod-xsendfile 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#538296: libauthen-sasl-cyrus-perl: Patches to Authen::SASL::Cyrus::Security have not been applied

2009-07-24 Thread Ben Poliakoff 
Package: libauthen-sasl-cyrus-perl
Version: 0.13-server-4.2
Severity: important
Tags: patch

The source archive for this package contains two patches to the
Authen::SASL::Cyrus::Security module:

correct-write-return-value
encode-no-more-than-MAX_OUTBUF

They aren't actually being applied when the package is built due to a
missing patch statement in the debian/rules file.  I've verified this
issue on my own system (backporting the package to lenny) as well as on
the packages hosted in the official Debian archives

Attached is a very small patch which adds the patch statement to the
build-stamp target, this appears to be the way to trigger quilt patch 
application in the build process.  Builds with this modification result
in these important patches being applied.

Thanks,

Ben

PATCH BEGIN
--- libauthen-sasl-cyrus-perl-0.13-server/debian/rules.orig 2009-07-24 
09:43:41.0 -0700
+++ libauthen-sasl-cyrus-perl-0.13-server/debian/rules  2009-07-24 
09:33:17.0 -0700
@@ -10,7 +10,7 @@
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep:
-build-stamp:
+build-stamp: patch
dh build --before dh_auto_configure
dh_auto_configure -- LIBS=-lsasl2 DEFINE=-DSASL2
dh build --remaining
PATCH END

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

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

Versions of packages libauthen-sasl-cyrus-perl depends on:
ii  libauthen-sasl-pe 2.12-1 Authen::SASL - SASL Authentication
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra
ii  perl  5.10.0-19  Larry Wall's Practical Extraction 
ii  perl-base [perlap 5.10.0-19  minimal Perl system

libauthen-sasl-cyrus-perl recommends no packages.

libauthen-sasl-cyrus-perl 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#516044: rsyslog-gssapi: gssapi input module (imgssapi.so) causes segfault at start up

2009-04-10 Thread Ben Poliakoff 
* Michael Biebl bi...@debian.org [20090403 23:07]:
 Ben Poliakoff wrote:
  Package: rsyslog-gssapi
  Version: 3.20.4-2
  Severity: normal
  
  
  I'm currently using a *backported* version of rsyslog (from Unstable) on a 
  Lenny machine (and also on Etch).  
  
  I was previously using a locally patched version of rsyslog 3.18.6 
  (enabling 
  gssapi input and output plugins).  No problems with that version.
  
  All of my client machines run just fine with version 3.20.4-2 (using the 
  gssapi output module 'omgssapi.so').
  
  But my primary server segfaults, according to 'strace', on startup with 
  the following GSSAPI configs (which work properly with 3.18.6):
 
 I can not reproduce this (on unstable with 3.20.4-3).
 
 Could you try to ge me a backtrace and the output
 of rsyslogd -d
 

I just built 3.20.5-1 for lenny (and etch) and have found that the
problems appear to have been resolved.  As far as I can see this bug can
be resolved.  Thanks for all your work maintaining this package!

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpfQkh1n3Nw4.pgp
Description: PGP signature

Bug#520304: openafs-modules-source: Can't build openafs kernel module with 2.6.28 kernel

2009-03-18 Thread Ben Poliakoff 
Package: openafs-modules-source
Version: 1.4.8.dfsg1-2
Severity: normal


I'm trying to use kernel version 2.6.28.x on a lenny box.  I've built 
the kernel from source (using make-kpkg), and I'm using a backported 
version of the openafs package (from testing).  I grabbed 1.4.8dfsg1-2 
because the changelog mentioned that it should support the 2.6.28 
kernel.

The userland openafs builds fine, but when I try to build the kernel 
module with module-assistant the build fails with the following error:

-
...
  CC [M]  
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.o
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c: 
In function 'xdr_DiskName':
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:351: 
warning: passing argument 2 of 'afs_xdr_opaque' from incompatible 
pointer type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c: 
In function 'xdr_ViceDisk':
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:685: 
warning: passing argument 2 of 'xdr_DiskName' from incompatible pointer 
type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c: 
At top level:
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:1512: 
error: expected declaration specifiers or '...' before 
'ViceStatistics64'
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c: 
In function 'xdr_ViceStatistics64':
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:1514: 
error: 'objp' undeclared (first use in this function)
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:1514: 
error: (Each undeclared identifier is reported only once
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:1514: 
error: for each function it appears in.)
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.c:1514: 
error: 'STATS64_VERSION' undeclared (first use in this function)
make[5]: *** 
[/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP/Kvice.xdr.o] 
Error 1
make[4]: *** 
[_module_/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP] 
Error 2
make[4]: Leaving directory `/usr/local/src/linux/2.6.28/linux-2.6.28'
make[3]: *** [openafs.ko] Error 2
make[3]: Leaving directory 
`/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.28-bp01-MP'
make[2]: *** [linux_compdirs] Error 2
make[2]: Leaving directory `/usr/src/modules/openafs/src/libafs'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/modules/openafs'
make: *** [build-stamp] Error 2
-

I've tried building against linux kernel 2.6.28 and 2.6.28.8; getting 
the same error for both versions.

Is this a known issue?  

I'll try building the kernel module from the openafs 1.4.x stable CVS 
branch to see if that addresses the issue.

Ben

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

Kernel: Linux 2.6.28.8-bp01 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openafs-modules-source depends on:
ii  bison   1:2.3.dfsg-5 A parser generator that is compati
ii  debhelper   7.0.15   helper programs for debian/rules
ii  flex2.5.35-6 A fast lexical analyzer generator.
ii  kernel-package  11.015   A utility for building Linux kerne
ii  module-assistant0.10.11.0tool to make module package creati

openafs-modules-source recommends no packages.

openafs-modules-source 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#520304: openafs-modules-source: Can't build openafs kernel module with 2.6.28 kernel

2009-03-18 Thread Ben Poliakoff 
* Ben Poliakoff b...@reed.edu [20090318 11:12]:
 
 I'll try building the kernel module from the openafs 1.4.x stable CVS 
 branch to see if that addresses the issue.
 

OK, interestingly I can successfully build the module for kernel version
2.6.28.x *without* using module-assistant.  The following steps worked
with both the openafs-1.4.8.dfsg1 source archive and with a checkout of
openafs-stable-1_4_x:

./configure
make only_libafs_tree
cd libafs_tree
make

So is this a module-assistant bug?

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpVqFPqovyuz.pgp
Description: PGP signature

Bug#520304: openafs-modules-source: Can't build openafs kernel module with 2.6.28 kernel

2009-03-18 Thread Ben Poliakoff 
* Russ Allbery r...@debian.org [20090318 13:29]:
 Ben Poliakoff b...@reed.edu writes:
 
  OK, interestingly I can successfully build the module for kernel version
  2.6.28.x *without* using module-assistant.  The following steps worked
  with both the openafs-1.4.8.dfsg1 source archive and with a checkout of
  openafs-stable-1_4_x:
 
  ./configure
  make only_libafs_tree
  cd libafs_tree
  make
 
  So is this a module-assistant bug?
 
 Did you run module-assistant clean immediately before trying the build
 with module-assistant?  This has bitten me before.  Without clean, it just
 unpacks the tarball over top of whatever happens to be there, which means
 that you can end up with files left over from a previous build.

Thanks, you were right on target:

module-assistant clean openafs-modules
module-assistant a-b openafs-modules

worked flawlessly.  Sorry for the false alarm, and thanks for the 'm-a
clean' tip.

I guess this bug can be closed.

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpOqJTBx1v3V.pgp
Description: PGP signature

Bug#516044: rsyslog-gssapi: gssapi input module (imgssapi.so) causes segfault at start up

2009-02-18 Thread Ben Poliakoff 
Package: rsyslog-gssapi
Version: 3.20.4-2
Severity: normal


I'm currently using a *backported* version of rsyslog (from Unstable) on a 
Lenny machine (and also on Etch).  

I was previously using a locally patched version of rsyslog 3.18.6 (enabling 
gssapi input and output plugins).  No problems with that version.

All of my client machines run just fine with version 3.20.4-2 (using the 
gssapi output module 'omgssapi.so').

But my primary server segfaults, according to 'strace', on startup with 
the following GSSAPI configs (which work properly with 3.18.6):

  # GSSAPI rsyslog server configs
  $ModLoad imgssapi.so # provides GSSAPI authenticated/encrypted input
  $InputGSSServerPermitPlainTCP off # forbid non-authenticated connections
  $InputGSSServerRun 10514 # run GSSAPI authenticated connections on this port

Removing these lines allows rsyslogd to start successfully.

The segfault occurs right after rsyslogd binds to its port and issues the 
'listen' system call:

  bind(3, {sa_family=AF_INET, sin_port=htons(10514), 
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
  listen(3, 25) = 0
  --- SIGSEGV (Segmentation fault) @ 0 (0) ---
  rt_sigaction(SIGABRT, {SIG_DFL}, NULL, 8) = 0

I'd love to do whatever I can to help resolve this issue.

Ben

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

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

Versions of packages rsyslog-gssapi depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libkrb53  1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries
ii  rsyslog   3.20.4-2   enhanced multi-threaded syslogd
ii  ucf   3.0016 Update Configuration File: preserv

Versions of packages rsyslog-gssapi recommends:
ii  krb5-user 1.6.dfsg.4~beta1-5 Basic programs to authenticate usi

rsyslog-gssapi 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#499963: [Calendarserver-maintainers] Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-10-01 Thread Ben Poliakoff 
* Guido Günther [EMAIL PROTECTED] [20081001 01:53]:
  Using the XML backend seems to work fine (tested both with the example
  'test' user and with a newly defined user):
 Did you check if the user benp is in the valid uid range
 [firstValidUid-lastValidUid]?

Yes, benp's uid (25022) is in the default range (1000-65533).

Sorry, I guess I only answered this indirectly in my previous note.

Ben
-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpGeZxyfQHkp.pgp
Description: PGP signature

Bug#499963: [Calendarserver-maintainers] Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-10-01 Thread Ben Poliakoff 
Alright I see what's going on.  The NssDirectoryService is required by
the DirectoryService class to support three methods:

recordTypes()
listRecords()
recordWithShortName()

My server is configured to use files and LDAP for NSS calls.  We have
several thousand users in our LDAP directory and implement the default
limit of 500 search results.  As a result 'getent passwd' returns
a subset of all valid accounts (not including the 'benp' account).

'getent passwd benp' returns the entry for the 'benp' account just
fine; and when I manually add the result of 'getent passwd benp'
to /etc/passwd I'm finally able to connect with Lightning via
Kerberos/Negotiate auth as 'benp'.  The principal is autocreated and I'm
able to read and write to the calendar.

But a DirectoryService subclass is required to support a function
(listRecords) that returns *all* valid accounts.  This just isn't
compatible with our NSS environment.

I think I might take a stab at writing a generic LDAPDirectoryService
using your NssDirectoryService as an example.

So in the end this isn't really a bug with NssDirectoryService; but it's
probably worth noting in the documentation that NssDirectoryService will
only work properly within an environment where *all* valid users can be
retrieved via the equivalent of 'getent passwd'.  

Sorry for the trouble, and thanks for your time!

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpf1HSlMbRfU.pgp
Description: PGP signature

Bug#499963: [Calendarserver-maintainers] Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-09-30 Thread Ben Poliakoff 
* Guido Günther [EMAIL PROTECTED] [20080928 01:23]:
 On Fri, Sep 26, 2008 at 10:07:29AM -0700, Ben Poliakoff wrote:
  ..pretty sure you meant /var/spool/caldavd.  Permissions seem fine:
 Sure. Thanks.
  
  [EMAIL PROTECTED] ~]$ sudo su -s /bin/bash caldavd
  [EMAIL PROTECTED]:/home/benp$ touch /var/spool/caldavd/test
  [EMAIL PROTECTED]:/home/benp$ ls -l /var/spool/caldavd/test
  -rw-r--r-- 1 caldavd caldavd 0 2008-09-26 10:01 /var/spool/caldavd/test
  [EMAIL PROTECTED]:/home/benp$ rm /var/spool/caldavd/test
  [EMAIL PROTECTED]:/home/benp$ ls -l /var/spool/caldavd/test
  ls: cannot access /var/spool/caldavd/test: No such file or directory
  [EMAIL PROTECTED]:/home/benp$
 This is getting weird. Did you check if the user benp is in the valid
 uid range [firstValidUid-lastValidUid]? If he is, it might make sense to
 try out the XML backend instead of NSS for testing. 
  -- Guido
 

Using the XML backend seems to work fine (tested both with the example
'test' user and with a newly defined user):

== access.log ==
134.10.15.21 - test [30/Sep/2008:13:24:03 -0700] OPTIONS 
/calendars/users/test/ HTTP/1.1 200 0 - cadaver/0.22.3 neon/0.25.5
[53.9 ms]
134.10.15.21 - test [30/Sep/2008:13:24:03 -0700] PROPFIND
/calendars/users/test/ HTTP/1.1 207 649 - cadaver/0.22.3
neon/0.25.5 [72.5 ms]

== error.log ==
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
OPTIONS /calendars/users/test/ HTTP/1.1
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
PROPFIND /calendars/users/test/ HTTP/1.1
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test [calendar-proxy-read]
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test [calendar-proxy-read]
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Initializing database
/var/spool/caldavd/principals/.db.calendaruserproxy
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test [calendar-proxy-write]
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test
2008-09-30 13:24:03-0700 [-] [caldav-8008]  [-] Provisioning file:
(users) test [calendar-proxy-write]

Switching back to the NSS backend I tried looking at /principals:

== access.log ==
134.10.15.21 - - [30/Sep/2008:13:54:49 -0700] OPTIONS /principals/
HTTP/1.1 401 141 - cadaver/0.22.3 neon/0.25.5 [63.1 ms]

== error.log ==
2008-09-30 13:54:49-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
OPTIONS /principals/ HTTP/1.1
2008-09-30 13:54:49-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
OPTIONS /principals/ HTTP/1.1
2008-09-30 13:54:49-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
Directory service SudoDirectoryService 'reed.edu':
FilePath('/etc/caldavd/sudoers.plist') has no GUID; generating service
GUID from realm name.
2008-09-30 13:54:49-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
'No principal found for UID: benp'
2008-09-30 13:54:49-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.15.21]
Could not find the principal resource for user id: benp

The 'no GUID' messages seem to be pointing at something

'getent passwd benp' returns my account details:

benp:*:25022:506:Ben Poliakoff:/home/benp:/bin/bash

Here's my NssDirectoryService config from /etc/caldavd/caldavd.plist
(trying to keep it as simple as possible):

!-- NSS directory service --
keyDirectoryService/key
dict
keytype/key
stringtwistedcaldav.directory.nss.NssDirectoryService/string
keyparams/key
dict
keyrealmName/key
stringreed.edu/string

keymailDomain/key
stringreed.edu/string
/dict
/dict


-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpkaXHnmgMCC.pgp
Description: PGP signature

Bug#499963: [Calendarserver-maintainers] Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-09-26 Thread Ben Poliakoff 
* Guido Günther [EMAIL PROTECTED] [20080925 23:58]:
 Hi Ben,
 On Thu, Sep 25, 2008 at 11:36:44AM -0700, Ben Poliakoff wrote:
 [..snip..] 
  And /var/spool/caldavd/principals/users/benp is not created (even though
  the caldavd user has full privs on the /var/spool/caladavd directory).
 What filesystem is this? You do have to set user_xattr:
  /usr/share/doc/calendarserver/README.Debian
 but the error should look different then.

Here's the output of 'mount' for the filesystem that houses
/var/spool/caldavd:

/dev/mapper/vg0-root on / type ext3 (rw,acl,user_xattr,errors=remount-ro)

  Trying with another caldav client Thunderbird/Lightning (using the url
  https://host.name.here:8443/calendars/users/benp/calendar/; since
  Lightning doesn't support the /principals stuff yet) my calendar is
  marked as unavailable.  Here are access.log entries from calendarserver
  as I try to an event (*nothing* shows up in the error.log):
  
  134.10.15.21 - - [25/Sep/2008:11:13:02 -0700] PUT \
  /calendars/users/benp/calendar/36cd9363-ffe6-4afd-9de2-0998e3f4f6ed.ics 
  \
  HTTP/1.1 404 186 - Mozilla/5.0 (X11; U; Linux i686; en-US; \
  rv:1.8.1.16)  Gecko/20080707 Lightning/0.9 Thunderbird/2.0.0.16 [190.6 
  \
  ms]
  134.10.15.21 - - [25/Sep/2008:11:14:10 -0700] PROPFIND
  /calendars/users/benp/calendar/ HTTP/1.1 404 146 - Mozilla/5.0 
  (X11; \
  U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080707 Lightning/0.9 Thund \
  erbird/2.0.0.16 [196.0 ms]
  134.10.15.21 - - [25/Sep/2008:11:14:11 -0700] OPTIONS \
  /calendars/users/benp/ HTTP/1.1 404 137 - Mozilla/5.0 (X11; U; 
  Linux \
  i686; en-US; rv:1.8.1.16) Gecko/20080707 Lightning/0.9 Thunderbird/2.0 \
  .0.16 [232.1 ms]
  
  The PROPFIND/OPTIONS lines go on continuously until I quit Thunderbird.
 They show up every second?

Yes (or at least in *some* sort of continuous loop), but honestly I
think that's a Lightning bug when configured to talk to a calendar that
doesn't appear to exist on the server (I just experienced the same
behavior with a client talking to my bedework server calendar server).

 What's displayed if you go to:
  https://host.name.here:8443/calendars/users/benp/calendar/
 with firefox? The calendar should be provisioned then too.

This is what I see in Firefox (after successful kerberos auth):

Not Found
The resource /calendars/users/benp/calendar/ cannot be found.

 Could you doublecheck the permissions on /var/spool/caladvd - maybe by
   su -s /bin/bash caldavd
   touch /var/spool/caldvd/test

..pretty sure you meant /var/spool/caldavd.  Permissions seem fine:

[EMAIL PROTECTED] ~]$ sudo su -s /bin/bash caldavd
[EMAIL PROTECTED]:/home/benp$ touch /var/spool/caldavd/test
[EMAIL PROTECTED]:/home/benp$ ls -l /var/spool/caldavd/test
-rw-r--r-- 1 caldavd caldavd 0 2008-09-26 10:01 /var/spool/caldavd/test
[EMAIL PROTECTED]:/home/benp$ rm /var/spool/caldavd/test
[EMAIL PROTECTED]:/home/benp$ ls -l /var/spool/caldavd/test
ls: cannot access /var/spool/caldavd/test: No such file or directory
[EMAIL PROTECTED]:/home/benp$

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpTHaHk4ebKB.pgp
Description: PGP signature

Bug#498635: [Pkg-shadow-devel] Bug#498635: passwd: useradd -r and groupadd -r don't play nicely with ldap

2008-09-25 Thread Ben Poliakoff 
I've been looking at this a bit more, it seems to be related to bug
#337253:

libc6: getent hangs when called with --service=ldap args
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337253

In that bug Richard Nelson says:

I've moved from libnss-ldap to libnss-ldapd, and am trying to clean
things up for a hopeful hand-off of the package...

I tried switching to libnss-ldapd also and found that my 'groupadd -r'
command now runs successfully (in a little under 4 seconds).

I guess that means *this* bug should now be associated with Bug#337253.

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpBV1jEjsGUL.pgp
Description: PGP signature

Bug#499963: [Calendarserver-maintainers] Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-09-25 Thread Ben Poliakoff 
* Guido Günther [EMAIL PROTECTED] [20080924 00:19]:
 severity 499963 normal
 
 On Tue, Sep 23, 2008 at 04:31:56PM -0700, Ben Poliakoff wrote:
  I'm trying to use calendarserver's NssDirectoryService.  I've configured 
  the service in /etc/caldavd/caldavd.plist, following the comments in the
  module '/usr/share/pyshared/twistedcaldav/directory/nss.py'.  I've also
  configured Kerberos and SSL in /etc/caldavd/caldavd.plist.
 Does this help:
  http://honk.sigxcpu.org/con/tags/groupware/
 
  However Apple's iCal client fails to connect to the calendarserver using 
  Kerberos.  
 Could you try with e.g. firefox to browse the tree directly (need to set
 network.negotiate-auth.trusted-uris for kerberos)? The strange part is
 that you don't even get a ticket, so theres a problem with your kerberos
 setup in caldavd - until then there's no need to look further.
  -- Guido

Thanks, I sorted out the kerberos issues (I can now connect via Firefox
and Thunderbird/Lightning using kerberos auth).  

I should probably mention that 'getent' calls for passwd and group
entries are working just fine, so the nss side if things seems to be in
order.

But I'm still not seeing auto-provisioning of calendars or
principals.  When I connect with iCal (using the bare host url
https://host.name.here:8443; I see this error:

Account information not found

Calendar https://host.name.here:8443/principals/users/benp/ could
not be found.

And I see these log entries from the calendarserver:

== access.log ==
134.10.120.42 - - [25/Sep/2008:11:34:23 -0700] PROPFIND \
/principals/users/benp/ HTTP/1.1 404 138 - DAVKit/3.0.4 (652); \
CalendarStore/3.0.5 (841); iCal/3.0.5 (1270); Mac OS X/10.5.5 (9F33) \
[184.4 ms]

== error.log ==
2008-09-25 11:34:23-0700 [-] [caldav-8008] \
[HTTPChannel,2,134.10.120.42] 'No principal found for UID: benp' \
2008-09-25 11:34:23-0700 [-] [caldav-8008] \
[HTTPChannel,2,134.10.120.42] Attempt to create clone \
'/var/spool/caldavd/principals/users/benp' of resource \
DirectoryPrincipalTypeProvisioningResource: \
/var/spool/caldavd/principals/users

And /var/spool/caldavd/principals/users/benp is not created (even though
the caldavd user has full privs on the /var/spool/caladavd directory).


Trying with another caldav client Thunderbird/Lightning (using the url
https://host.name.here:8443/calendars/users/benp/calendar/; since
Lightning doesn't support the /principals stuff yet) my calendar is
marked as unavailable.  Here are access.log entries from calendarserver
as I try to an event (*nothing* shows up in the error.log):

134.10.15.21 - - [25/Sep/2008:11:13:02 -0700] PUT \
/calendars/users/benp/calendar/36cd9363-ffe6-4afd-9de2-0998e3f4f6ed.ics \
HTTP/1.1 404 186 - Mozilla/5.0 (X11; U; Linux i686; en-US; \
rv:1.8.1.16)  Gecko/20080707 Lightning/0.9 Thunderbird/2.0.0.16 [190.6 \
ms]
134.10.15.21 - - [25/Sep/2008:11:14:10 -0700] PROPFIND
/calendars/users/benp/calendar/ HTTP/1.1 404 146 - Mozilla/5.0 (X11; \
U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080707 Lightning/0.9 Thund \
erbird/2.0.0.16 [196.0 ms]
134.10.15.21 - - [25/Sep/2008:11:14:11 -0700] OPTIONS \
/calendars/users/benp/ HTTP/1.1 404 137 - Mozilla/5.0 (X11; U; Linux \
i686; en-US; rv:1.8.1.16) Gecko/20080707 Lightning/0.9 Thunderbird/2.0 \
.0.16 [232.1 ms]

The PROPFIND/OPTIONS lines go on continuously until I quit Thunderbird.


-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpJhntVINfbp.pgp
Description: PGP signature

Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-09-23 Thread Ben Poliakoff 
Package: calendarserver
Version: 1.2.dfsg-6
Severity: important

I'm trying to use calendarserver's NssDirectoryService.  I've configured 
the service in /etc/caldavd/caldavd.plist, following the comments in the
module '/usr/share/pyshared/twistedcaldav/directory/nss.py'.  I've also
configured Kerberos and SSL in /etc/caldavd/caldavd.plist.

However Apple's iCal client fails to connect to the calendarserver using 
Kerberos.  

iCal then displays this error message:

Account information not found:
Calendar https://host.name.here:8443/principals/user/benp/ could not 
be found.

I find that my kerberos credential cache does not contain a service ticket 
for the service configured in the keytab file and in 'ServicePrincipal'.  
Additionally calendar server logs the following to /var/log/caldavd/error.log:

2008-09-23 16:15:03-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.8.28] \
'No principal found for UID: benp'
2008-09-23 16:15:03-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.8.28] \
Attempt to create clone '/var/spool/caldavd/principals/users/benp' \
of resource DirectoryPrincipalTypeProvisioningResource: \
/var/spool/caldavd/principals/users

If I run strace against caldavd while iCal tries to connect I
see this:

snip...snip...snip...
19052 stat64(/var/spool/caldavd/principals/users, {st_mode=S_IFDIR|0750, 
st_size=4096, ...}) = 0
19052 gettimeofday({109205, 347026}, NULL) = 0
19052 stat64(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
19052 stat64(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
19052 write(1,  [HTTPChannel,0,134.10.8.28] \Att..., 192) = 192
19052 brk(0x8f3d000)= 0x8f3d000
19052 stat64(/usr/lib/python2.5/site-packages/twisted/web2/.svn/format, 
0xbfbbe078) = -1 ENOENT (No such file or directory)
19052 stat64(/usr/lib/python2.5/site-packages/twisted/web2/.svn/format, 
0xbfbbe078) = -1 ENOENT (No such file or directory)
19052 stat64(/usr/lib/python2.5/site-packages/twisted/web2/.svn/format, 
0xbfbbe078) = -1 ENOENT (No such file or directory)
snip...snip...snip...

...and caldavd becomes unresponsive, needing to be killed brutally with
SIGKILL.  

I should note that this is being tested against a full production
kerberos realm (and other kerberos authenticated services (ldap and ssh)
are running properly on the client and the server.

Ben

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

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages calendarserver depends on:
ii  adduser 3.110add and remove users and groups
ii  lsb-base3.2-20   Linux Standard Base 3.2 init scrip
ii  python  2.5.2-2  An interactive high-level object-o
ii  python-central  0.6.8register and build utility for Pyt
ii  python-dateutil 1.4-1powerful extensions to the standar
ii  python-kerberos 1.0+svn2455-1A GSSAPI interface module for Pyth
ii  python-openssl  0.7-2Python wrapper around the OpenSSL 
ii  python-pysqlite22.4.1-1  Python interface to SQLite 3
ii  python-twisted-calendar 0.2.0.svn19773-5 Twisted components for Apple's Cal
ii  python-vobject  0.6.0-1  parse iCalendar and VCards in Pyth
ii  python-xattr0.4-4module for manipulating filesystem
ii  python-xml  0.8.4-10.1   XML tools for Python
ii  ssl-cert1.0.22   simple debconf wrapper for OpenSSL

calendarserver recommends no packages.

Versions of packages calendarserver suggests:
ii  python-pydirector 1.0.0-1pure Python TCP load balancer

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#499963: calendarserver: caldavd fails to authenticate and autocreate principal when running with NssDirectoryService

2008-09-23 Thread Ben Poliakoff 
* Ben Poliakoff [EMAIL PROTECTED] [20080923 16:31]:: Meeting with Marty
 Additionally calendar server logs the following to
 /var/log/caldavd/error.log:
 2008-09-23 16:15:03-0700 [-] [caldav-8008] [HTTPChannel,0,134.10.8.28] \
 'No principal found for UID: benp'
 2008-09-23 16:15:03-0700 [-] [caldav-8008] [HTTPChannel,0,134.10.8.28] \
 Attempt to create clone '/var/spool/caldavd/principals/users/benp' \
 of resource DirectoryPrincipalTypeProvisioningResource: \
 /var/spool/caldavd/principals/users

I omitted a log or two in the bug submission, here are all of the logs
I'm seeing when connecting via iCal:

== access.log ==
134.10.8.28 - - [23/Sep/2008:16:37:47 -0700] PROPFIND
/principals/users/benp/
HTTP/1.1 404 138 - DAVKit/2.0 (10.5.4; wrbt) iCal 3.0.4 [283.3 ms]

== error.log ==
2008-09-23 16:37:47-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.8.28]
Directory service SudoDirectoryService 'reed.edu': Smith imap and ldap
FilePath('/etc/caldavd/sudoers.plist') has no GUID; generating service
GUID
from realm name.
2008-09-23 16:37:47-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.8.28]
'No principal found for UID: benp'
2008-09-23 16:37:47-0700 [-] [caldav-8008]  [HTTPChannel,0,134.10.8.28]
Attemptto create clone '/var/spool/caldavd/principals/users/benp' of
resource
DirectoryPrincipalTypeProvisioningResource:
/var/spool/caldavd/principals/users

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgp7tgteCR1hv.pgp
Description: PGP signature

Bug#498635: [Pkg-shadow-devel] Bug#498635: passwd: useradd -r and groupadd -r don't play nicely with ldap

2008-09-12 Thread Ben Poliakoff 
* Nicolas François [EMAIL PROTECTED] [20080911 18:21]:
 Hello,
 
 On Thu, Sep 11, 2008 at 09:44:36AM -0700, [EMAIL PROTECTED] wrote:
  
  useradd -r and groupadd -r hang forever when run on a system that 
 
 Does forever means a long time ?

I haven't had a chance to try waiting forever (hard to find the time),
but I've never seen the command run to completion.  I've always had to
interrupt it.  I've let it run as long as 15 minutes.

 (I assume you made no changes to /etc/login.defs)

Correct.

 Do you have a group/user ID with an high value?

We've got a sizeable LDAP infrastructure (a couple thousand users, a few
hundred groups) with plenty of users and groups with high id values.  

 Do you have a group/user ID with an high value in the 0-1000 range?

We do have some legacy groups and users in the 0-1000 range.

 Do you have a lot of system groups/users?

Just the default set of system groups and users.

 Could forever mean doing a large number of LDAP requests?

 Does it also take forever when you force the user or group ID?
 Could you strace useradd/groupadd when it takes forever?

It *could* mean that the system is doing a large number of LDAP
requests, but an strace on the process doesn't indicate that.  When
running under strace the command stalls in a 'poll' against one of our
LDAP servers.  I can see it reading hundreds of groups from our LDAP
server, lots of lines like this:

29888 read(7, \cn=admnstf,ou=Group,dc=reed,dc=e..., 74) = 74
29888 read(7, #cn=alifeprj,ou=Group,dc=reed,dc=..., 106) = 106
29888 read(7, !cn=art201,ou=Group,dc=reed,dc=ed..., 98) = 98
29888 read(7, !cn=art318,ou=Group,dc=reed,dc=ed..., 73) = 73
29888 read(7, !cn=art345,ou=Group,dc=reed,dc=ed..., 73) = 73
29888 read(7, !cn=art347,ou=Group,dc=reed,dc=ed..., 73) = 73

Not sure what the initial !, #, and \ characters in the strace
output indicate.

Looking on the LDAP server I see the query logged this way (IP addr
redacted):

Sep 12 08:56:12 ldap slapd[24932]: conn=614205 fd=48 ACCEPT from 
IP=xxx.xxx.xxx.xxx:57265 (IP=0.0.0.0:389)
Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=0 BIND dn= method=128
Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=0 RESULT tag=97 err=0 
text=
Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=1 SRCH 
base=dc=reed,dc=edu scope=2 deref=0 filter=((objectClass=posixGroup))
Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=1 SRCH attr=cn 
userPassword memberUid uniqueMember gidNumber
Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=1 SEARCH RESULT tag=101 
err=0 nentries=364 text=
Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SRCH 
base=dc=reed,dc=edu scope=2 deref=0 filter=((objectClass=posixGroup))
Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SRCH attr=cn 
userPassword memberUid uniqueMember gidNumber
Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SEARCH RESULT tag=101 
err=4 nentries=136 text=
Sep 12 09:07:48 ldap slapd[24932]: conn=614205 fd=48 closed (idletimeout)

i.e. the search found and returned 364 posixgroup entries within 1
second.

But in the end the command stalls at the last poll line in the strace
output below (IP addrs redacted):

29888 read(8, $cn=natsciweb,ou=Group,dc=reed,dc..., 113) = 113
29888 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
29888 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
29888 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 
([{fd=8, revents=POLLIN}])
29888 read(8, 0\f\2\1\3e\7\n..., 8)   = 8
29888 read(8, \1\4\4\0\4\0..., 6) = 6
29888 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
29888 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
29888 stat(/etc/libnss-ldap.conf, {st_mode=S_IFREG|0644, st_size=8385, 
...}) = 0
29888 geteuid() = 0
29888 getsockname(8, {sa_family=AF_INET, sin_port=htons(54239), 
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [16]) = 0
29888 getpeername(8, {sa_family=AF_INET, sin_port=htons(389), 
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [68719476752]) = 0
29888 stat(/etc/libnss-ldap.conf, {st_mode=S_IFREG|0644, st_size=8385, 
...}) = 0
29888 geteuid() = 0
29888 getsockname(8, {sa_family=AF_INET, sin_port=htons(54239), 
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [16]) = 0
29888 getpeername(8, {sa_family=AF_INET, sin_port=htons(389), 
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [68719476752]) = 0
29888 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = ?  
ERESTART_RESTARTBLOCK (To be restarted)
29888 --- SIGINT (Interrupt) @ 0 (0) ---
29888 +++ killed by SIGINT +++

That's me sending the SIGINT at the end, after waiting 15 minutes.

  is configured to use libnss-ldap (with ldap references for passwd and
  group in /etc/nsswitch.conf).  I use the following ldap related
  configs in nsswitch.conf:
  
  passwd_compat: ldap
  group:  files ldap
  netgroup:   files ldap
  
  The impact of this problem

Bug#498635: passwd: useradd -r and groupadd -r don't play nicely with ldap

2008-09-11 Thread Ben Poliakoff 
Package: passwd
Version: 1:4.1.1-3
Severity: important


useradd -r and groupadd -r hang forever when run on a system that 
is configured to use libnss-ldap (with ldap references for passwd and
group in /etc/nsswitch.conf).  I use the following ldap related
configs in nsswitch.conf:

passwd_compat: ldap
group:  files ldap
netgroup:   files ldap

The impact of this problem can be very ugly. In the case of an etch
to lenny upgrade, packages like libuuid1 try to create a system
group necessitates killing the stalled apt-get dist-upgrade process.

It'd be really really nice to resolve this before lenny's released.

Ben

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

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

Versions of packages passwd depends on:
ii  debianutils   2.30   Miscellaneous utilities specific t
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libpam-modules1.0.1-4+b1 Pluggable Authentication Modules f
ii  libpam0g  1.0.1-4+b1 Pluggable Authentication Modules l
ii  libselinux1   2.0.65-4   SELinux shared libraries

passwd recommends no packages.

passwd suggests no packages.

-- debconf information:
  passwd/password-mismatch:
  passwd/username: toor
  passwd/password-empty:
  passwd/make-user: true
  passwd/title:
  passwd/user-uid:
  passwd/shadow: true
  passwd/username-bad:
  passwd/user-fullname:



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493044: rsyslog: enable gssapi-krb5 authentication

2008-08-11 Thread Ben Poliakoff 
* Michael Biebl [EMAIL PROTECTED] [20080807 13:38]:
 Ben Poliakoff wrote:
 * Michael Biebl [EMAIL PROTECTED] [20080731 00:02]:
 GSSAPI is entirely optional (but it's very nice for people who already
 have a kerberos infrastucture), so it seems reasonable to add the option
 for rsyslog.  Perhaps it might be added as an 'rsyslog-gssapi' sub
 package.
 A separate package would probably be necessary, to not drag in any   
 dependency on libkrb53.

 Attached is a first stab at a patch.   The patch does the following:

 - defines the rsyslog-gssapi package in debian/control
 - modifies the debian/rsyslog.install file, removing wildcards to
   avoid inadvertently pulling in the *gss* plugins
 - adds a debian/rsyslog-gssapi.install file, specifying the gssapi
   related plugins for the rsyslog-gssapi package

 I've never submitted a *packaging* related patch before, so I may have
 missed something important or obvious.  Hopefully this will help though.
 Let me know if there's anything I can do to help!

 Hi Ben,

 thanks a lot for the patch. Much appreciated.
 I don't plan any major changes for the rsyslog package before the lenny  
 release. So this feature will probably have to wait until lenny is out.


Oh well, I was hoping this feature could make the cut for lenny.  But I
can understand how enabling new features this close to the release might
make you anxious.

Fortunately it's not too difficult to maintain a custom rsyslog package,
based on the debian one.  I'm planning on rolling out rsyslog with
gssapi auth for my site shortly.

Best wishes,

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpwaFC1igPNR.pgp
Description: PGP signature

Bug#493044: rsyslog: enable gssapi-krb5 authentication

2008-07-31 Thread Ben Poliakoff 
* Michael Biebl [EMAIL PROTECTED] [20080731 00:02]:

 GSSAPI is entirely optional (but it's very nice for people who already
 have a kerberos infrastucture), so it seems reasonable to add the option
 for rsyslog.  Perhaps it might be added as an 'rsyslog-gssapi' sub
 package.

 A separate package would probably be necessary, to not drag in any  
 dependency on libkrb53.


Would it be at all useful for me to submit a patch that adds such a
package?

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019


pgpbBuS2SChpe.pgp
Description: PGP signature

Bug#493044: rsyslog: enable gssapi-krb5 authentication

2008-07-31 Thread Ben Poliakoff 
* Michael Biebl [EMAIL PROTECTED] [20080731 00:02]:

 GSSAPI is entirely optional (but it's very nice for people who already
 have a kerberos infrastucture), so it seems reasonable to add the option
 for rsyslog.  Perhaps it might be added as an 'rsyslog-gssapi' sub
 package.

 A separate package would probably be necessary, to not drag in any  
 dependency on libkrb53.

Attached is a first stab at a patch.   The patch does the following:

- defines the rsyslog-gssapi package in debian/control
- modifies the debian/rsyslog.install file, removing wildcards to
  avoid inadvertently pulling in the *gss* plugins
- adds a debian/rsyslog-gssapi.install file, specifying the gssapi
  related plugins for the rsyslog-gssapi package

I've never submitted a *packaging* related patch before, so I may have
missed something important or obvious.  Hopefully this will help though.
Let me know if there's anything I can do to help!

Ben

-- 

PGP fingerprint:  A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019
--- orig/rsyslog-3.18.1/debian/control  2008-07-31 11:57:28.0 -0700
+++ rsyslog-3.18.1/debian/control   2008-07-31 11:44:44.0 -0700
@@ -2,7 +2,7 @@
 Section: admin
 Priority: important
 Maintainer: Michael Biebl [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5), quilt, autotools-dev, zlib1g-dev, 
libmysqlclient15-dev, libpq-dev
+Build-Depends: debhelper (= 5), quilt, autotools-dev, zlib1g-dev, 
libmysqlclient15-dev, libpq-dev, libkrb5-dev
 Standards-Version: 3.8.0
 Vcs-Git: git://git.debian.org/git/users/biebl/rsyslog.git
 Vcs-Browser: http://git.debian.org/?p=users/biebl/rsyslog.git;a=summary
@@ -63,3 +63,12 @@
 Description: PostgreSQL output plugin for rsyslog
  This plugin allows rsyslog to write the syslog messages into a PostgreSQL 
  database.
+
+Package: rsyslog-gssapi
+Architecture: any
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}, rsyslog (= ${binary:Version}), ucf
+Recommends: krb5-user
+Description: GSSAPI input and output plugins for rsyslog
+ These plugins allow rsyslog to write and/or receive GSSAPI authenticated and
+ encrypted syslog messages.
--- orig/rsyslog-3.18.1/debian/rsyslog.install  2008-07-31 11:57:28.0 
-0700
+++ rsyslog-3.18.1/debian/rsyslog.install   2008-07-31 11:49:43.0 
-0700
@@ -1,6 +1,14 @@
 debian/rsyslog.conf /etc/
 debian/tmp/usr/sbin/
 debian/tmp/usr/share/man/
-debian/tmp/usr/lib/rsyslog/im*.so
-debian/tmp/usr/lib/rsyslog/lm*.so
+debian/tmp/usr/lib/rsyslog/imfile.so
+debian/tmp/usr/lib/rsyslog/imklog.so
+debian/tmp/usr/lib/rsyslog/immark.so
+debian/tmp/usr/lib/rsyslog/imtcp.so
+debian/tmp/usr/lib/rsyslog/imudp.so
+debian/tmp/usr/lib/rsyslog/imuxsock.so
+debian/tmp/usr/lib/rsyslog/lmnet.so
+debian/tmp/usr/lib/rsyslog/lmregexp.so
+debian/tmp/usr/lib/rsyslog/lmtcpclt.so
+debian/tmp/usr/lib/rsyslog/lmtcpsrv.so
 debian/tmp/usr/lib/rsyslog/ommail.so
--- orig/rsyslog-3.18.1/debian/rsyslog-gssapi.install   1969-12-31 
16:00:00.0 -0800
+++ rsyslog-3.18.1/debian/rsyslog-gssapi.install2008-07-31 
11:46:51.0 -0700
@@ -0,0 +1,3 @@
+debian/tmp/usr/lib/rsyslog/imgssapi.so
+debian/tmp/usr/lib/rsyslog/lmgssutil.so
+debian/tmp/usr/lib/rsyslog/omgssapi.so


pgpr8NhFhAHzl.pgp
Description: PGP signature

Bug#493044: rsyslog: enable gssapi-krb5 authentication

2008-07-30 Thread Ben Poliakoff 
Package: rsyslog
Version: 3.18.1-3gss
Severity: wishlist

I haven't filed many Debian bug reports, hope this ends up in the right
place.

Please consider enabling GSSAPI input and output in the rsyslog package.
The upstream package supports it.  Enabling GSSAPI is pretty simple
(adding --enable-gssapi-krb5 to the ./configure line).  

I built a version of the debian package that enables GSSAPI input and
output by doing the following:

- added --enable-gssapi-krb5 to the ./configure line
- adding debian/tmp/usr/lib/rsyslog/omgssapi.so to rsyslog.install

GSSAPI is entirely optional (but it's very nice for people who already
have a kerberos infrastucture), so it seems reasonable to add the option
for rsyslog.  Perhaps it might be added as an 'rsyslog-gssapi' sub
package.

Ben

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages rsyslog depends on:
ii  libc6  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  libkrb53   1.4.4-7etch6  MIT Kerberos runtime libraries
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  zlib1g 1:1.2.3-13compression library - runtime

Versions of packages rsyslog recommends:
ii  logrotate 3.7.1-3Log rotation utility

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493044: Acknowledgement (rsyslog: enable gssapi-krb5 authentication)

2008-07-30 Thread Ben Poliakoff 
It should be pointed out that the version listed in this report,
3.18.1-3gss, is *my* package rebuilt from the debian source package 
using the modifications I mentioned in the bug report.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#389597: /usr/lib/perl5/Cyrus/IMAP/Admin.pm: cyrus-admin tools cannot set mailbox annotations

2006-09-26 Thread Ben Poliakoff 
Package: libcyrus-imap-perl22
Version: 2.2.13-7
Severity: normal
File: /usr/lib/perl5/Cyrus/IMAP/Admin.pm
Tags: patch


This bug seems to be related to the application of a kolab patch.  An 'if'
clause was expanded to include '$entry = $values{$entry};', but the
original '$entry = $values{$entry};' that had been outside of the 'if'
clause wasn't removed.  This results in the inablility to set
annotations on mailboxes.  Here's an illustration...

Without the attached patch the current version of Admin.pm sends this to
the IMAP server:

SETANNOTATION inbox.bar  (value.shared 7)

(the server doesn't like this)

After the attached patch has been applied Admin.pm sends this to
the IMAP server:

SETANNOTATION inbox.foo (/vendor/cmu/cyrus-imapd/expire \
(value.shared 7))

and the server is happy.

Here's the tiny little patch:

-- begin patch -
--- Admin.pm.dist   2006-09-25 16:17:46.0 -0700
+++ Admin.pm2006-09-26 10:17:53.0 -0700
@@ -799,8 +799,6 @@
 $self-{error} = Unknown parameter $entry unless substr($entry,0,1) eq 
/;
   }
 
-  $entry = $values{$entry};
-
   my ($rc, $msg);
 
   $value = undef if($value eq none);
-- end patch -

Ben

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libcyrus-imap-perl22 depends on:
ii  libc6   2.3.6.ds1-4  GNU C Library: Shared libraries
ii  libdb4.24.2.52+dfsg-1Berkeley v4.2 Database Libraries [
ii  libsasl22.1.19.dfsg1-0.5 Authentication abstraction library
ii  libssl0.9.8 0.9.8c-1 SSL shared libraries
ii  perl5.8.8-6.1Larry Wall's Practical Extraction 
ii  perl-base [perlapi-5.8. 5.8.8-6.1The Pathologically Eclectic Rubbis

libcyrus-imap-perl22 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]