Bug#479169: Bug #479169: update-grub suddenly outputs double / with separate /boot partition
This change was introduced in version 0.97-37, with the make_system_path_relative_to_its_root() function. The attached patch restores the old behavior. --MR diff -urN grub-0.97/debian/update-grub grub-0.97.rm_double_slash/debian/update-grub --- grub-0.97/debian/update-grub 2008-05-04 10:48:22.0 -0400 +++ grub-0.97.rm_double_slash/debian/update-grub 2008-05-04 11:21:53.0 -0400 @@ -94,7 +94,7 @@ dir=$parent done - echo $path | sed -e s,^$dir,/,g -e s,//,/,g + echo $path | sed -e s,^$dir,/,g -e s,//,/,g -e 's,^/*$,,' } # The grub installation directory
Bug#470852: postfix: Wildcard virtual alias maps cause unwanted bounces
Package: postfix Version: 2.5.1-1 Severity: important After upgrading to postfix 2.5.1-1, I started seeing many bounces sent back to bogus (spam) addresses. I have a number of virtual_alias_domains on my server, and some of the virtual_alias_maps use wildcard addresses. For example: @virtdomain.net @realdomain.net Mail sent from [EMAIL PROTECTED] to [EMAIL PROTECTED] doesn't cause a bounce message to be sent to [EMAIL PROTECTED], but the same message sent to [EMAIL PROTECTED] causes postfix 2.5.1-1 to try to deliver a bounce to [EMAIL PROTECTED], causing my mail queue to fill up with undeliverable bounces, and possibly resulting in my server getting on some black lists. Reverting to postfix 2.4.6-3 fixes this problem. Further investigation reveals that if there are no wildcard virtual alias maps, these bounces are not sent, but I don't want to put dozens of entries in each of several virtual alias map file (one for each domain), when what I really want is to map the whole domain. --MR -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages postfix depends on: ii adduser 3.106 add and remove users and groups ii debconf [debconf-2.0]1.5.19 Debian configuration management sy ii dpkg 1.14.16.6 package maintenance system for Deb ii libc62.7-6 GNU C Library: Shared libraries ii libdb4.6 4.6.21-6Berkeley v4.6 Database Libraries [ ii libsasl2-2 2.1.22.dfsg1-18 Cyrus SASL - authentication abstra ii libssl0.9.8 0.9.8g-4SSL shared libraries ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip ii netbase 4.30Basic TCP/IP networking system ii ssl-cert 1.0.16 simple debconf wrapper for OpenSSL postfix recommends no packages. -- debconf information: postfix/master_upgrade_warning: postfix/db_upgrade_warning: true * postfix/mailname: geomancer.gedankenlabs.org postfix/tlsmgr_upgrade_warning: postfix/dynamicmaps_upgrade_warning: * postfix/recipient_delim: + * postfix/main_mailer_type: Internet Site postfix/transport_map_warning: * postfix/retry_upgrade_warning: true postfix/kernel_version_warning: postfix/relayhost: * postfix/procmail: true postfix/bad_recipient_delimiter: * postfix/chattr: false * postfix/root_address: NONE postfix/rfc1035_violation: false * postfix/mydomain_warning: true * postfix/mynetworks: 127.0.0.0/8 * postfix/destinations: $myhostname, localhost, nutwerk.org postfix/nqmgr_upgrade_warning: postfix/not_configured: * postfix/mailbox_limit: 0 * postfix/protocols: all -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455821: dlocate: dlocate needs to depend on 'locate'
Package: dlocate Version: 0.5-0.3 Severity: normal /usr/lib/locate/frcode is no longer in the 'findutils' package (as of 4.2.31-3), so dlocate should now depend on the 'locate' package (for /usr/sbin/update-dlocatedb). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages dlocate depends on: ii dctrl-tools [grep-dctrl] 2.12 Command-line tools to process Debi ii dpkg 1.14.7 package maintenance system for Deb ii perl 5.8.8-12 Larry Wall's Practical Extraction dlocate recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445263: apache2.2-common: 'apache2ctl graceful-stop' fails to kill processes
Package: apache2.2-common
Version: 2.2.6-1
Severity: important
Running 'apache2ctl graceful-stop' results in the removal of the pid file
(/var/run/apache2.pid), but does not actually kill all of the apache2
processes. Using 'apache2ctl stop' seems to work, however. This means that
the init script ('/etc/init.d/apache2 stop') fails to shut down the web
server.
I'm using apache2-mpm-prefork 2.2.6-1. The behavior is the same for the
commands 'apache2 -k command' ('graceful-stop' fails, 'stop' succeeds).
--Mike
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash
Versions of packages apache2.2-common depends on:
ii apache2-utils 2.2.6-1 utility programs for webservers
ii libapr1 1.2.11-1 The Apache Portable Runtime Librar
ii libaprutil1 1.2.7+dfsg-2+b1 The Apache Portable Runtime Utilit
ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries
ii libdb4.44.4.20-8 Berkeley v4.4 Database Libraries [
ii libexpat1 1.95.8-4 XML parsing C library - runtime li
ii libldap22.1.30.dfsg-13.5 OpenLDAP libraries
ii libmagic1 4.21-3 File type determination library us
ii libpcre36.7-1Perl 5 Compatible Regular Expressi
ii libpq5 8.2.4-2 PostgreSQL C client library
ii libsqlite3-03.4.2-1 SQLite 3 shared library
ii libssl0.9.8 0.9.8e-9 SSL shared libraries
ii libuuid11.40.2-1 universally unique id library
ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip
ii mime-support3.39-1 MIME files 'mime.types' 'mailcap
ii net-tools 1.60-17 The NET-3 networking toolkit
ii procps 1:3.2.7-4.1 /proc file system utilities
ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime
apache2.2-common recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444740: libpam-krb5: can't log in with expired password via openssh
Package: libpam-krb5 Version: 3.6-1 Severity: serious Version 3.6-1 of libpam-krb5 prevents login via openssh if the user's password has expired (i.e. 'REQUIRES_PWCHANGE'). With openssh configured for ChallengeResponseAuthentication, I get a prompt to set a new password with libpam-krb5 version 3.5-1, but authentication simply fails with version 3.6-1. I suspect the changes made to address bug #437171 are the cause. --Mike -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages libpam-krb5 depends on: ii krb5-config 1.17 Configuration files for Kerberos V ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libcomerr2 1.40.2-1 common error description library ii libkrb531.6.dfsg.1-7 MIT Kerberos runtime libraries ii libpam0g0.99.7.1-4 Pluggable Authentication Modules l libpam-krb5 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432569: debian-goodies: /usr/sbin/checkrestart still falsely reports apache2
I have also observed this bug. I have apache2-mpm-prefork running, with mod_ssl, and I believe this is the problem. The deleted file in question is /var/run/apache2/ssl_mutex. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421622: libsasl2-modules-gssapi-mit: GSSAPI keytabs not working
It is possible to use a separate keytab for each service with libsasl2-modules-gssapi-mit. One way is by setting the environment variable KRB5_KTNAME. For example, in order to get cyrus-imapd-2.2 to use its own keytab, add the following line to /etc/default/cyrus-2.2: export KRB5_KTNAME=/etc/imapd.keytab --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414821: bash: [bash_completion] _known_hosts() fails if there are spaces in homedir path
Package: bash
Version: 3.1dfsg-8
Severity: normal
The _known_hosts() function in bash_completion fails if there are
spaces in the path of one of the ssh config files (i.e. in the homedir
of the user). This causes completion to fail (and error messages from
sed to appear) when completing an argument to rsync. This problem can
be fixed by more rigorous quoting. I have a patch (attached).
--Mike
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages bash depends on:
ii base-files 4Debian base system miscellaneous f
ii debianutils 2.17 Miscellaneous utilities specific t
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libncurses5 5.5-5Shared libraries for terminal hand
bash recommends no packages.
-- no debconf information
--- bash_completion.old 2007-03-13 13:30:51.0 -0400
+++ bash_completion 2007-03-13 17:43:22.0 -0400
@@ -2423,17 +2423,17 @@
# ssh config files
[ -r /etc/ssh/ssh_config ]
- config=( [EMAIL PROTECTED] /etc/ssh/ssh_config )
- [ -r ~/.ssh/config ]
- config=( [EMAIL PROTECTED] ~/.ssh/config )
- [ -r ~/.ssh2/config ]
- config=( [EMAIL PROTECTED] ~/.ssh2/config )
+ config=( [EMAIL PROTECTED] /etc/ssh/ssh_config )
+ [ -r ${HOME}/.ssh/config ]
+ config=( [EMAIL PROTECTED] ${HOME}/.ssh/config )
+ [ -r ${HOME}/.ssh2/config ]
+ config=( [EMAIL PROTECTED] ${HOME}/.ssh2/config )
if [ [EMAIL PROTECTED] -gt 0 ]; then
# expand path (if present) to global known hosts file
- global_kh=$( eval echo $( sed -ne 's/^[Gg][Ll][Oo][Bb][Aa][Ll][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' [EMAIL PROTECTED] ) )
+ global_kh=$( eval echo $( sed -ne 's/^[Gg][Ll][Oo][Bb][Aa][Ll][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' [EMAIL PROTECTED] ) )
# expand path (if present) to user known hosts file
- user_kh=$( eval echo $( sed -ne 's/^[Uu][Ss][Ee][Rr][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' [EMAIL PROTECTED] ) )
+ user_kh=$( eval echo $( sed -ne 's/^[Uu][Ss][Ee][Rr][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' [EMAIL PROTECTED] ) )
fi
# choose which global known hosts file to use
@@ -2509,7 +2509,8 @@
fi
# append any available aliases from config files
if [ [EMAIL PROTECTED] -gt 0 ] [ -n $aliases ]; then
- hosts=$( compgen -W $( sed -ne 's/^[Hh][Oo][Ss][Tt]['$'\t '']*\([^*?]*\)$/\1/p' [EMAIL PROTECTED] ) -- $ocur )
+ local host_aliases=$( sed -ne 's/^[Hh][Oo][Ss][Tt]['$'\t '']*\([^*?]*\)$/\1/p' [EMAIL PROTECTED] )
+ hosts=$( compgen -W $host_aliases -- $ocur )
COMPREPLY=( [EMAIL PROTECTED] $hosts )
fi
Bug#411816: libpam-krb5: Expired passwords cannot be changed via ssh
On Tue, Feb 20, 2007 at 10:24:55PM -0800, Russ Allbery wrote: You have to enable ChallengeResponseAuthentication in sshd_config for sshd to do a full PAM dialog. Otherwise, it fakes the PAM dialog enough to provide a password and if the PAM module has to prompt for any more data than that, it fails. Thank you. That does work, though it is far from obvious, since pam_unix does not require ChallengeResponseAuthentication in order to provide almost the same functionality (it forces the user to log in again after changing the password). I submit that this is a minor documentation bug. At the least, a brief note (such as the above paragraph) in /usr/share/doc/libpam-krb5 would suffice, in my opinion. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411816: libpam-krb5: Expired passwords cannot be changed via ssh
On Wed, Feb 21, 2007 at 10:28:48AM -0800, Russ Allbery wrote: Michael Richters [EMAIL PROTECTED] writes: On Tue, Feb 20, 2007 at 10:24:55PM -0800, Russ Allbery wrote: You have to enable ChallengeResponseAuthentication in sshd_config for sshd to do a full PAM dialog. Otherwise, it fakes the PAM dialog enough to provide a password and if the PAM module has to prompt for any more data than that, it fails. Thank you. That does work, though it is far from obvious, since pam_unix does not require ChallengeResponseAuthentication in order to provide almost the same functionality (it forces the user to log in again after changing the password). I don't see how pam_unix would avoid needing to have this enabled to provide this functionality. Unless ChallengeResponseAuthentication is enabled, there is no way for a PAM module to do supplemental prompts through sshd since sshd's conversation function simply doesn't pay any attention to them. Are you sure that, for Unix passwords, sshd doesn't just take care of the password expiration and change itself? If not, I'd love to know how pam_unix manages to do it. My guess is that it doesn't do it through sshd. When logging in using pam_unix with an expired password, my process tree shows a 'passwd' child of sshd. I'm guessing this means that authentication succeeded, as far as sshd is concerned, but the 'login' program (or whatever, I'm not that familiar with the process) knows that the account is expired, so it runs 'passwd', which prompts for the user's (old) password again, then for the new password (same as running 'passwd' manually). Once 'passwd' exits, the ssh connection is gone (because sshd exits), and the user has to log in again (this doesn't happen on the console, though -- I'm not sure why). In fact, the same thing happens if I'm using pam_krb5 to log in, but I've just run `passwd -e username`. Therefore, I'm pretty sure pam_unix has nothing to do with it. I submit that this is a minor documentation bug. At the least, a brief note (such as the above paragraph) in /usr/share/doc/libpam-krb5 would suffice, in my opinion. Agreed. I'll add that in the next release. Thank you. And thanks again for your help. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
I have now successfully tested sasl-sample-client sasl-sample-server (and imtest) with GSSAPI authentication. Once my kerberos config files were corrected, everything worked. The error messages could certainly have been more helpful, but I know of no reason why this bug should not be closed now. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
While constructing a reply to your message, I believe I have found the
error. I had the wrong hostname for the kdc in the [realms] section
of /etc/krb5.conf. I'm a bit confused about why I was able to get
tickets at all with kinit, but now both the kerberos clients and
sasl-sample-{client,server} authentication are working properly.
My thanks and apologies to all those who helped me with this. When I
get GSSAPI authentication fully functional with imapd on my system, I
will attempt to write it up as an example so that others might benefit
from these tribulations.
--Mike
My original reply, with the error messages that I saw before I
corrected the kdc's hostname in /etc/krb5.conf:
On Tue, Dec 19, 2006 at 10:52:13AM -0500, Sam Hartman wrote:
OK, so we basically know it is a client side problem.
* check the domain_realm mappings in krb5.conf
I don't have any that apply to my domain/realm. As I understand it,
the domain nutwerk.org should get mapped to the realm NUTWERK.ORG
without an entry there.
* confirm that you can get krb5-rsh-server and the rlogin -x hostname
fromkrb5-clients working. They tend to produce better error
reporting.
In fact, I cannot, though I can get it to work on another machine
(with a different domain realm, but very nearly identical config
files). The error messages in this case are less than enlightening,
however:
[EMAIL PROTECTED]:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
12/23/06 16:25:21 12/24/06 02:25:21 krbtgt/[EMAIL PROTECTED]
renew until 12/30/06 16:25:17
Kerberos 4 ticket cache: /tmp/tkt1001
klist: You have no tickets cached
[EMAIL PROTECTED]:~$ rlogin -x geomancer.nutwerk.org
error getting credentials: Generic error (see e-text)
Trying krb4 rlogin...
krb_sendauth failed: You have no tickets cached
[EMAIL PROTECTED]:~$ krb5-rsh geomancer.nutwerk.org ls
error getting credentials: Generic error (see e-text)
Trying krb4 rsh...
krb_sendauth failed: You have no tickets cached
trying normal rsh (/usr/bin/netkit-rsh)
exec: No such file or directory
* Run kvno host/[EMAIL PROTECTED] after using kinit.
[EMAIL PROTECTED]:~$ kvno host/[EMAIL PROTECTED]
host/[EMAIL PROTECTED]: Generic error (see e-text) while getting credentials
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402823: linux-image-2.6.18-3-686: Can't access /dev/rtc
On Fri, Dec 22, 2006 at 03:23:44PM +0100, Norbert Tretkowski wrote: * Michael Richters wrote: I have a Dell PowerEdge 860, and the current stock Debian kernels cannot access /dev/rtc: [EMAIL PROTECTED]:~] # hwclock --show select() to /dev/rtc to wait for clock tick timed out This same error occurs when the system is booting. Could you please retry the above command using the --directisa option? That works: [EMAIL PROTECTED]:~] # hwclock --directisa --show Fri Dec 22 09:52:27 2006 -0.565819 seconds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Mon, Dec 18, 2006 at 12:00:41AM -0500, Sam Hartman wrote:
Interesting. Do you end up getting tickets for the host service or
just a tgt?
After sasl-sample-client exits, I still only have a tgt.
Is any error logged on the Kerberos KDC?
None that I see, but I might be looking in the wrong place. The only
messages I see are in /var/log/auth.log when I call kinit:
Dec 18 16:04:11 geomancer krb5kdc[2359]: AS_REQ (7 etypes {18 17 16 23 1 3 2})
172.16.0.107: NE
Dec 18 16:04:17 geomancer krb5kdc[2359]: AS_REQ (7 etypes {18 17 16 23 1 3 2})
172.16.0.107: IS
--Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Sat, Dec 16, 2006 at 10:34:53AM +0200, Fabian Fagerholm wrote: One thing which sticks out to me is that you have sasl_pwcheck_method: saslauthd in /etc/imapd.conf, but then you have MECHANISMS=pam in /etc/default/saslauthd. I'm not too familiar with GSSAPI, but it seems to me that something should be different here, as Kerberos will handle how authentication data is stored, and saslauthd should simply ask it to authenticate the user (or fail). I'd be surprised if saslauthd had anything to do with it, because GSSAPI is not a plaintext authentication mechanism (like CRAM-MD5 and DIGEST-MD5, which can succeed even when saslauthd isn't running). Could it be that GSSAPI authentication is failing because I have an entry for the user in /etc/sasldb? --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
On Wed, Dec 13, 2006 at 11:51:02PM -0200, Henrique de Moraes Holschuh wrote:
On Wed, 13 Dec 2006, Michael Richters wrote:
FYI: the string sasl_minimum_layer appears in the cyrus-imapd-2.2
source package, but not in the cyrus-sasl2 package:
Strip the sasl_ prefix when grepping SASL code and docs.
I did. Take a look at the arguments to 'grep' in my previous message.
I don't think it's reasonable to expect someone to grep through the
source in order to determine that sasl_minimum_layer in one package
translates to min_ssf in another. Not to mention the fact that this
information still doesn't lead me to an answer to my original
question.
It should not translate to min_ssf at all, unless SASL is renaming options,
in which case whomever is doing the translation needs to document it (either
cyrus imap or sasl).
Unless I'm reading this wrong, cyrus-imapd is responsible for the
translation. Mind you, I haven't taken the time to really read and
understand the code from which this is excerpted.
cyrus-imapd-2.2-2.2.13/lib/imapopts.c:162: { IMAPOPT_SASL_MINIMUM_LAYER,
sasl_minimum_layer, 0, {(void*)0}, OPT_INT, { { NULL, IMAP_ENUM_ZERO } } },
cyrus-imapd-2.2-2.2.13/imap/global.c:297:ret.min_ssf =
config_getint(IMAPOPT_SASL_MINIMUM_LAYER);
--Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
On Wed, Dec 13, 2006 at 11:38:19PM -0200, Henrique de Moraes Holschuh wrote: /usr/share/doc/libsasl2/ somewhere, grep for options. I didn't check the new SASL, though. None of the libsasl2* packages seems to contain any documentation in /usr/share/doc: just changelogs, copyrights, and one list of options passed to 'configure'. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
On Thu, Dec 14, 2006 at 08:23:58AM +0200, Fabian Fagerholm wrote: Could you please try the following: On the client: $ kinit $ sasl-sample-client -m gssapi -n geomancer.nutwerk.org On the server: $ sasl-sample-server Then manually copy and paste the server output (the whole line, starting with and including S: or C:) to stdin on the client and vice versa, until you either get success or failure. That's what I did, and included in the original report, except that I specified the service name (host). The results are the same if I leave out the -s host: [EMAIL PROTECTED]:~$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED]:~$ /usr/sbin/sasl-sample-server Generating client mechanism list... Sending list of 7 mechanism(s) S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= Waiting for client mechanism... [EMAIL PROTECTED]:~$ sasl-sample-client -m gssapi -n geomancer.nutwerk.org Waiting for mechanism list from server... S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= recieved 53 byte message Forcing use of mechanism gssapi Choosing best mechanism from: gssapi sasl-sample-client: SASL Other: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) error was SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) sasl-sample-client: Starting SASL negotiation: generic failure [EMAIL PROTECTED]:~$ echo $? 1 [EMAIL PROTECTED]:~$ Any idea what I might be doing wrong? --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
On Thu, Dec 14, 2006 at 05:45:45PM +0100, Sven Mueller wrote: Regarding the Documentation: sasl_minimum_layer really translates into min_ssf in libsasl2, sasl_maximum_layer into max_ssf of the same structure. What they do is documented in: /usr/share/doc/libsasl2/programming.html What package does that file belong to? It doesn't exist in libsasl2 version 2.1.22.dfsg1-7, or any other sasl package installed on my system: [EMAIL PROTECTED]:~] # aptitude -F %p%25v search ~isasl cyrus-sasl2-doc 2.1.22.dfsg1-7 libsasl2 2.1.22.dfsg1-7 libsasl2-2 2.1.22.dfsg1-7 libsasl2-dev 2.1.22.dfsg1-7 libsasl2-modules 2.1.22.dfsg1-7 libsasl2-modules-gssapi-mit 2.1.22.dfsg1-7 sasl2-bin 2.1.22.dfsg1-7 [EMAIL PROTECTED]:~] # ls -l /usr/share/doc/libsasl2 total 48 -rw-r--r-- 1 root root 9346 Dec 8 03:23 changelog.Debian.gz -rw-r--r-- 1 root root 28789 May 19 2006 changelog.gz -rw-r--r-- 1 root root 2069 Dec 8 03:23 copyright Actually, the documentation available in cyrus-imapd is almost all there is to know: a layer of 0 doesn't ensure anything a layer of 1 provides integrity protection any higher level ensures some sort of encryption. The example given in sasl documentation is 56-bit DES encryption providing an SSF (security strength factor) of 56. Perhaps someone else can put this in more documentation-like words and add it to our manpages, READMEs or so. In my frustration, I may have exaggerated the deficiency of this bit of documentation, but I still maintain that it is inadequate (and that there is no such example in the documentation). First, I'm not sure what is meant by integrity protection. Second, some sort of encryption is far too vague. Not all sorts of encryption are equivalent, and since no values are translated into meanings, I have no idea what number to use in my config file if I do want to allow some sorts of encryption, but not others. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
On Wed, Dec 13, 2006 at 12:01:11PM -0200, Henrique de Moraes Holschuh wrote: On Tue, 12 Dec 2006, Michael Richters wrote: The manpage for imapd.conf is missing many things, including a description of the possible values for 'sasl_minimum_layer'. I have spent hours searching, and cannot find any translation of these arbitrary values to real-world meanings, nor can I even find a list of allowed values for this option. It sure would be nice if somebody would share their knowledge... All sasl_* are passed as-is to SASL for processing, so we cannot do much more than: 1. Say exactly that in the cyrus imap manpage and docs and point to the relevant sasl manpages and docs 2. Write the relevant SASL manpages and send it upstream, AFAIK all the docs on that stuff are in a single html file in the sasl documentation. It is definately NOT the job of cyrus imapd to documet any sasl_ stuff in manpages. Why should the manpage for imapd.conf not document all of the options that can appear in /etc/imapd.conf? At the very least, it should provide a pointer to a document that does contain the relevant information. And, yes, this is really a problem for upstream, but since I actually got a response from you, do you suppose you could tell me where to find this sasl documentation? I have spent many hours searching for it in Debian packages and on the web in general without any luck. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
FYI: the string sasl_minimum_layer appears in the cyrus-imapd-2.2
source package, but not in the cyrus-sasl2 package:
--
[EMAIL PROTECTED]:~/deb]
$ grep -r -i minimum_layer cyrus-sasl2-2.1.22.dfsg1/
[EMAIL PROTECTED]:~/deb]
$ grep -r -i minimum_layer cyrus-imapd-2.2-2.2.13/
cyrus-imapd-2.2-2.2.13/imap/global.c:ret.min_ssf =
config_getint(IMAPOPT_SASL_MINIMUM_LAYER);
cyrus-imapd-2.2-2.2.13/imap/mupdate-client.c: ret-min_ssf =
config_getint(IMAPOPT_SASL_MINIMUM_LAYER);
cyrus-imapd-2.2-2.2.13/man/imapd.conf.5:.IP \fBsasl_minimum_layer:\fR 0 5
cyrus-imapd-2.2-2.2.13/lib/imapopts.h: IMAPOPT_SASL_MINIMUM_LAYER,
cyrus-imapd-2.2-2.2.13/lib/imapoptions:{ sasl_minimum_layer, 0, INT }
cyrus-imapd-2.2-2.2.13/lib/imapopts.c: { IMAPOPT_SASL_MINIMUM_LAYER,
sasl_minimum_layer, 0, {(void*)0}, OPT_INT, { { NULL, IMAP_ENUM_ZERO } } },
cyrus-imapd-2.2-2.2.13/doc/man/imapd.conf.5.html:pbsasl_minimum_layer:/b
0/p/td
cyrus-imapd-2.2-2.2.13/debian/README.Debian: sasl_minimum_layer, and see bug
#151925 for more details
cyrus-imapd-2.2-2.2.13/debian/README.Debian.simpleinstall:
sasl_minimum_layer: 0
cyrus-imapd-2.2-2.2.13/debian/README.Debian.simpleinstall:
sasl_minimum_layer: 0
cyrus-imapd-2.2-2.2.13/debian/imapd.conf:# sasl_minimum_layer and allowapop
below, too.
cyrus-imapd-2.2-2.2.13/debian/imapd.conf:#sasl_minimum_layer: 0
--
I don't think it's reasonable to expect someone to grep through the
source in order to determine that sasl_minimum_layer in one package
translates to min_ssf in another. Not to mention the fact that this
information still doesn't lead me to an answer to my original
question.
I don't mean to be argumentative here. I really just want to
understand how my imap server is configured (and why it doesn't work
as advertised, but that's another story).
--Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402814: cyrus-imapd-2.2: Inadequate documentation of 'sasl_minimum_layer'
Package: cyrus-imapd-2.2 Version: 2.2.13-10 Severity: minor The manpage for imapd.conf is missing many things, including a description of the possible values for 'sasl_minimum_layer'. I have spent hours searching, and cannot find any translation of these arbitrary values to real-world meanings, nor can I even find a list of allowed values for this option. It sure would be nice if somebody would share their knowledge... --Mike -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402823: linux-image-2.6.18-3-686: Can't access /dev/rtc
Package: linux-image-2.6.18-3-686 Version: 2.6.18-8 Severity: normal I have a Dell PowerEdge 860, and the current stock Debian kernels cannot access /dev/rtc: [EMAIL PROTECTED]:~] # hwclock --show select() to /dev/rtc to wait for clock tick timed out This same error occurs when the system is booting. I successfully used the Ubuntu 6.10 (desktop) kernel, booted from CD, to set the system clock, so I know that it is not simply malfunctioning hardware. --Mike -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Package: libsasl2-modules-gssapi-mit Version: 2.1.22.dfsg1-7 Severity: important GSSAPI authentication does not appear to work for the SASL sample client and server. Of course, it is possible that I'm not doing something wrong, given the lack of examples in the documentation. Here's a transcript from the client: -- [EMAIL PROTECTED]:~$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED]:~$ klist Ticket cache: FILE:/tmp/krb5cc_1001 Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 12/12/06 18:41:57 12/13/06 04:41:57 krbtgt/[EMAIL PROTECTED] renew until 12/19/06 18:41:51 Kerberos 4 ticket cache: /tmp/tkt1001 klist: You have no tickets cached [EMAIL PROTECTED]:~$ sasl-sample-client -s host -m gssapi -n geomancer.nutwerk.org service=host Waiting for mechanism list from server... S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= recieved 53 byte message Forcing use of mechanism gssapi Choosing best mechanism from: gssapi sasl-sample-client: SASL Other: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) error was SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Generic error (see e-text)) sasl-sample-client: Starting SASL negotiation: generic failure -- Here's the corresponding transcript from the server: -- geomancer:~# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 3 host/[EMAIL PROTECTED] 3 host/[EMAIL PROTECTED] geomancer:~# sasl-sample-server -s host Generating client mechanism list... Sending list of 7 mechanism(s) S: TE9HSU4gQ1JBTS1NRDUgR1NTQVBJIFBMQUlOIEFOT05ZTU9VUyBOVExNIERJR0VTVC1NRDU= Waiting for client mechanism... -- The error message is too vague for me to guess the cause of the problem. --Mike -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351269: fragroute: fragroute won't start
Package: fragroute Version: 1.2-7 Severity: grave I'm using the default fragroute config file. My local subnet is 172.16.0.0/24. Here is a transcript of a shell session: [EMAIL PROTECTED]:~] # uname -a Linux ghostwheel 2.6.12-1-686 #1 Tue Sep 27 12:52:50 JST 2005 i686 GNU/Linux [EMAIL PROTECTED]:~] # cat /etc/fragroute.conf tcp_seg 1 new ip_frag 24 ip_chaff dup order random print [EMAIL PROTECTED]:~] # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 172.16.0.0 0.0.0.0 255.255.255.0 U 0 00 eth0 0.0.0.0 172.16.0.1 0.0.0.0 UG0 00 eth0 [EMAIL PROTECTED]:~] # arp -n Address HWtype HWaddress Flags MaskIface 172.16.0.1 ether 00:04:5A:DD:4B:1F C eth0 [EMAIL PROTECTED]:~] # fragroute 172.16.0.1 fragroute: couldn't delete loopback route fragroute: couldn't initialize tunnel interface: Invalid argument [EMAIL PROTECTED]:~] # fragroute 172.16.0.2 fragroute: no route to 172.16.0.2: No such process [EMAIL PROTECTED]:~] # fragroute 18.72.0.3 fragroute: couldn't delete loopback route fragroute: couldn't initialize tunnel interface: Invalid argument Note that I'm not familiar with fragroute, and I have never seen a working copy of it. It's possible that I just don't know what I'm doing, but since the source doesn't look like it's been updated since 2002, maybe it just doesn't work with a 2.6 kernel. (I've also tried it on 2.4.27, with similar results.) --Michael Richters -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages fragroute depends on: ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libdumbnet1 1.8-1.3A dumb, portable networking librar ii libevent1 1.1a-1 An asynchronous event notification ii libpcap0.70.7.2-7System interface for user-level pa fragroute recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329673: kamera: depends on obsolete package libexif10
Package: kamera Version: 4:3.3.2-2 Severity: grave Justification: renders package unusable Version 4:3.3.2-2 of the kamera package depends on the obsolete (and therefore unavailable) package libexif10. This makes the 'kde' package uninstallable because of dependency problems. This problem affects only the testing distribution, and it will be corrected automatically when the KDE 3.4 packages currently in unstable enter the testing distribution. If that is likely to take a long time, either libexif10 should be put back in testing or a new version of kamera 4:3.3.2 should be created that doesn't depend on libexif10 (maybe libexif12 will work). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.26-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
