From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009
Description of problem:
Error Message: "saslpasswd2: error deleting entry from sasldb: DB_NOTFOUND: No
matching key/data pair found"
This occurs on all machines including this client which is a clean install of RH9.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. saslpasswd2 -c [remainder of input line]
Actual Results: "saslpasswd2: error deleting entry from sasldb: DB_NOTFOUND: No
matching key/data pair found"
sasldb2 produces (actual output):
Expected Results: sasldb2 username/password file, presumably with secrets.
I am no longer able to authenticate from Postfix which HAD been working. This
has resulted in having to revoke privileges to roaming users in order not to
create an open relay.
This problem continues with a clean (new) Fedora install.
What does the remainder of the input line look like? Running
'saslpasswd2 -c nalin' here produces no errors, and sasldblistusers2
lists the user and associated secret.
saslpasswd2 -c hart:
"Nov 10 14:31:34 dchws saslpasswd2: error deleting entry from sasldb:
DB_NOTFOUND: No matching key/data pair found
Nov 10 14:31:35 dchws last message repeated 2 times"
Fedora Core 1
Again, no errors on my test system. Is the system an i686 system or
something else? Which kernel/glibc versions do you have installed?
Kernel = 2.4.22-1.2115.nptl
glibc = glibc-2.3.2-101
Again, this was a CLEAN, new install of Fedora. I am continuing to
have the same problem on the server running KORG
2.4.22/glibc-2.3.2-27.9. I was able to work around this for Postfix by
changing auxprop to saslauthd.
I'm pretty sure this started when the SSL package was updated in
response to a potential exploit but I'm not certain.
Which version of openssl is this? I'm seeing the messages you're
mentioning in syslog, but not in my terminal, which explains that, but
they don't appear to be adversely affecting anything....
Since I started receiving these error messages I cannot use auxprop to
authenticate roaming users with Postfix. The reason that I am vague is
because we did not have any roaming users for several months.
Therefore, I cannot be more precise about what and when.
At LEAST I know that we both get the same error messages in the
syslog. I'm sorry that I was not specific about where I was seeing them.
Can you run one of the simple tests which fail with strace and attach
I had some problem like this which turned out to be wrong access
I would if I knew how ;-)
I have not upgraded the server to Fedora yet. I was simply testing the
SASLPASSWD2 problem on a client machine to see if Fedora cleared it up.
The only testing that I have done in the past is to telnet into 25 and
try to authenticate. That is followed with a remote mail relay
attempt. To be sure, when I was trying to get auxprop to work I had
sasldb2 permissioned to the world - no dice.
I DON'T want to burden RH with my Postfix problems. In contrast, I was
hoping that resolution of the error message might resolve the problem.
As an aside, Fedora comes with a Postfix distribution with SMTP
authentication compiled in. Unfortunately, our setup requires a custom
compilation of a newer version. However, I am going to try to RH RPM
and see if that fares any better.
By the weekend I'll do the upgrade and re-test auxprop to see what
happens. Thanks for your courteous attention to this matter.
Upon closer examination, the messages in your log appear to be
harmless -- they're the result of saslpasswd2 attempting to remove
secrets which might have been placed there by dbconverter-2, and
getting a non-fatal error when those secrets don't exist.
It does this to clean up after sasl1->sasl2 migrations.
dbconverter-2, which converts a sasl1 sasldb to a sasl2 sasldb, can't
retrieve a user's plaintext password when it is run because sasl1
didn't store plaintext passwords in the sasldb. As an interim, for
migration purposes, dbconverter-2 creates cmusaslsecret<MECH> secrets
which can be used by the non-plaintext mechanisms. The plugins
included with sasl2 can also use the plaintext userPassword to create
the needed secrets at run-time, so saslpasswd2 removes the
cmusaslsecret<MECH> secrets when it is run because they are no longer
needed for that user once a userPasswd has been set.
Since the messages are harmless I'm downgrading this to no longer be a
security severity bug and moving it to NEEDINFO to see if the auxprop
issue is still happening.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
If this issue is still present in a current Fedora Core release, please
open a new bug with the relevant information.
Closing as CANTFIX.