Bug#709872: libzfs1: missing development package
Package: libzfs1 Version: 9.0-3 Severity: important I looked for a packaged named libzfs1-dev or libzfs-dev and couldn't find any for Debian GNU/kFreeBSD Wheezy. It seems like the only way to get the ZFS headers, like libzfs.h, is to download the source of libzfs1 or zfsutils. We should have a proper development package with the libzfs headers, just like any other library. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 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 libzfs1 depends on: ii libbsd0 0.4.2-1 ii libc0.1 2.13-38 ii libgeom19.0+ds1-4 ii libnvpair1 9.0-3 ii libumem19.0-3 ii libuutil1 9.0-3 libzfs1 recommends no packages. libzfs1 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#707262: zfsutils: zdb fails with error message zdb: can't open 'pool name': Value too large for defined data type
Package: zfsutils Version: 9.0-3 Severity: important Whenever I run zdb as root on Debian GNU/kFreeBSD Wheezy, it fails with the following error message: # zdb tank zdb: can't open 'tank': Value too large for defined data type I'm trying to use zdb to determine the ashift value of my pool, but this bug prevents me from accessing that property of the pool. I found other reports of this bug on a Google Groups discussion for the ZFS on Linux project: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups=#!topic/zfs-discuss/2w2GgKjEyhk According to that discussion: A fix for this error was recently committed to the zfs git repo, so you may want to give the latest code a try. I'm not sure which git repo the author had in mind though. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 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 zfsutils depends on: ii libbsd0 0.4.2-1 ii libc0.1 2.13-38 ii libgeom19.0+ds1-4 ii libnvpair1 9.0-3 ii libumem19.0-3 ii libuutil1 9.0-3 ii libzfs1 9.0-3 ii libzpool1 9.0-3 Versions of packages zfsutils recommends: ii cron 3.0pl1-124 zfsutils suggests no packages. -- Configuration Files: /etc/init.d/zfs changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#149452: libc: Need OpenBSD's bcrypt password hashing support for dovecot
I would like to use bcrypt (BLF-CRYPT) for my password scheme in Dovecot, but I can't because bcrypt support doesn't seem to have been integrated into the Debian libc. Here's the list of supported password schemes by Dovecot on my Debian Wheezy machine: # doveadm pw -l CRYPT MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN CLEARTEXT PLAIN-TRUNC CRAM-MD5 HMAC-MD5 DIGEST-MD5 PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY RPA SHA256-CRYPT SHA512-CRYPT As you can see, BLF-CRYPT is missing from that list. Correct me if I'm wrong, but I don't think that installing libpam-unix2 would give me support for bcrypt with Dovecot. See the Dovecot wiki page on password scheme support for more information: http://wiki2.dovecot.org/Authentication/PasswordSchemes -- Joel Lopes Da Silva
Bug#699121: dovecot-core: Cannot iterate through users list on Debian GNU/kFreeBSD AMD64 Wheezy
On Feb 19, 2013, at 12:19 AM, Timo Sirainen t...@iki.fi wrote: On Sun, 2013-01-27 at 12:21 -0800, Joel Lopes Da Silva wrote: # doveadm fetch -A user ALL doveadm(root): Error: userdb list: Disconnected unexpectedly doveadm: Error: Failed to iterate through some users zsh: exit 75doveadm fetch -A user ALL .. Jan 27 11:47:18 orange dovecot: auth: Error: userdb connection: Failed to get peer's credentials As you noticed, apparently getsockopt(SO_PEERCRED) doesn't work with kFreeBSD. You can anyway work around the problem by giving everyone access to the userdb socket: service auth { unix_listener userdb { mode = 0777 } } This workaround works for me. Thanks Timo. Do you think there might be an equivalent API we could use on kFreeBSD to accomplish the same behavior as the one available on Linux? -- Joel Lopes Da Silva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699121: dovecot-core: Cannot iterate through users list on Debian GNU/kFreeBSD AMD64 Wheezy
Package: dovecot-core Version: 1:2.1.7-6 Severity: normal Problem description --- I was trying to setup dovecot SASL authentication for my postfix server, using a postgresql database as the back end for authentication. I was able to get this to work and tested it using the following technique: http://qmail.jms1.net/test-auth.shtml However, part of the SQL configuration of dovecot is defining the iterate_query, and I could not get that to work. I have a valid SQL query, and I'm using valid credentials for the database, but I get the following error every time: # doveadm fetch -A user ALL doveadm(root): Error: userdb list: Disconnected unexpectedly doveadm: Error: Failed to iterate through some users zsh: exit 75doveadm fetch -A user ALL After enabling debug logs in both dovecot (cf. output of doveconf -n below) and postgresql, here's what I see in /var/log/syslog when I issue that command: Jan 27 11:47:18 orange dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth Jan 27 11:47:18 orange dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_pgsql.so Jan 27 11:47:18 orange dovecot: auth: Error: userdb connection: Failed to get peer's credentials Jan 27 11:47:18 orange postgres[3177]: [2-1] 2013-01-27 11:47:18 PST LOG: 0: connection received: host=::1 port=35751 Jan 27 11:47:18 orange postgres[3177]: [2-2] 2013-01-27 11:47:18 PST LOCATION: BackendInitialize, postmaster.c:3474 Jan 27 11:47:18 orange postgres[3177]: [3-1] 2013-01-27 11:47:18 PST LOG: 0: connection authorized: user=dovecot database=mail Jan 27 11:47:18 orange postgres[3177]: [3-2] 2013-01-27 11:47:18 PST LOCATION: PerformAuthentication, postinit.c:230 Jan 27 11:47:18 orange dovecot: auth: pgsql(localhost): Connected to database mail Personal research - I did some digging around the only useful log: userdb connection: Failed to get peer's credentials I found that it's generated by the following piece of code: 691 if (net_getunixcred(conn-fd, cred) 0) { 692 i_error(userdb connection: Failed to get peer's credentials); 693 return -1; 694 } in auth-master-connection.c's auth_master_connection_set_permissions function. (cf. http://fossies.org/dox/dovecot-2.1.13/auth-master-connection_8c_source.html) So I looked at net_getunixcred and I found that my version of dovecot-core could not possibly be running the following code: 697 #if defined(HAVE_GETPEEREID) 698 /* OSX 10.4+, FreeBSD 4.6+, OpenBSD 3.0+, NetBSD 5.0+ */ 699 if (getpeereid(fd, cred_r-uid, cred_r-gid) 0) { 700 i_error(getpeereid() failed: %m); 701 return -1; 702 } 703 return 0; otherwise I would have seen this log like I did the other: getpeereid() failed: %m Similarly, we cannot possibly be running the Linux branch starting with: 704 #elif defined(SO_PEERCRED) 705 /* Linux */ So we must be going through: 716 #elif defined(HAVE_GETPEERUCRED) 717 /* Solaris */ 718 ucred_t *ucred = NULL; 719 720 if (getpeerucred(fd, ucred) 0) { 721 i_error(getpeerucred() failed: %m); 722 return -1; 723 } 724 cred_r-uid = ucred_geteuid(ucred); 725 cred_r-gid = ucred_getrgid(ucred); 726 ucred_free(ucred); 727 728 if (cred_r-uid == (uid_t)-1 || 729 cred_r-gid == (gid_t)-1) { 730 errno = EINVAL; 731 return -1; 732 } 733 return 0; 734 #else 735 errno = EINVAL; 736 return -1; 737 #endif (cf. http://fossies.org/dox/dovecot-2.1.13/network_8c_source.html#l00695) Looking at the comment, I'd easily speculate that we're probably not even running the Solaris branch, so I suspect dovecot-core is being built for kfreebsd-amd64 with neither of the following definitions: HAVE_GETPEEREID SO_PEERCRED HAVE_GETPEERUCRED If I am right, then there's no chance this could ever work on this architecture; in that case, fixing the bug might be a matter of making sure one of these libraries/APIs is used for compiling dovecot-core. Additional debugging information Here's the content of my /etc/dovecot/dovecot-sql.conf.ext with my postgresql user password redacted: driver = pgsql connect = host=localhost dbname=mail user=dovecot password=REDACTED default_pass_scheme = SHA512-CRYPT password_query = \ SELECT address AS user, password \ FROM mailboxes \ INNER JOIN domains \ ON domains.domain = '%L{domain}' AND domains.active = true AND domains.mailboxes = true \ WHERE address = '%L{user}' AND mailboxes.active = true user_query = \ SELECT concat_ws('/', '%d', '%u', '') AS home, 114 AS uid, 114 AS gid \ FROM mailboxes \ INNER JOIN domains \ ON domains.domain = '%d' AND domains.active = true AND domains.mailboxes = true \ WHERE address = '%s' AND mailboxes.active = true
Bug#687246: Debian GNU/kFreeBSD: Missing man page: device.hints(5)
Package: freebsd-utils Version: 9.0+ds1-7 Debian GNU/kFreeBSD: Missing man page: device.hints(5) I just saw that GRUB 2 can do the right thing with a /boot/device.hints file. But I couldn't find the device.hints(5) man page anywhere on Debian. Cf. http://www.freebsd.org/cgi/man.cgi?query=device.hintssektion=5manpath=FreeBSD+9-current I suggest it be added to the freebsd-utils package, since that file is helpful for both GRUB 2 and the standard FreeBSD boot loader. I am currently using Debian GNU/kFreeBSD 7.0 Wheezy. -- Joel Lopes Da Silva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499161: Same problem: HTTP-access via SVN-client stops working after upgrade from etch
Hi, I have the exact same problem. SVN-client stops working under those circumstances, but DAV-access via web browser is indeed still available. However, it's not 100 % reproducible, as some of my repositories stopped working with the upgrade to Debian, and some others still work. Besides, the configuration for those different repositories is exactly the same. I think it is pretty urgent. Thank you very much for your efforts. Cheers, -- Joel Lopes Da Silva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org