Bug#867311: Fixed upstream?
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
* 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
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...
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
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
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
* 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
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
* 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
* 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
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
* 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
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
* 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
* 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
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
* 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
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
* 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
* 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
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
* 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
* 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
* 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
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)
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
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]