problems creating and deleting accounts

[Nik777]

Hi,

I'm running Kolab 2.0.4 on Fedora Core 5. The installation has been 
running (very well) since March 2007. But it seems that I am now unable 
to successfully create or delete user accounts.

The first sign of a problem was that a new account I created didn't 
work. In an attempt at using brute force, I tried deleting the account 
in order to recreate it. Now I have a zombie account, permanently 
awaiting cleanup. After some further research, I have found that a 
number of other recently-created accounts appear to have been only 
half-created, and I am beginning to think the create and delete errors 
are caused by the same problem.

The situation has not been fixed by rebooting kolabd, nor by restarting 
all kolab services.

A bit more detail:
Some time ago I was surprised to find that a newly-created account 
seemed not to work. If I sent mail to this account I got a delivery 
failure message. However looking at the logs, the mail was originally 
accepted by the kolab postfix, succesfully passed through the various 
delivery stages (SPAM and virus checking), only to be bounced when 
delivery to the mailbox was attempted. The delivery failure looks like 
this:

============ start of message  ===============

This is the Postfix program at host kolab.internal.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

            The Postfix program

<xxx at kolab.internal>: service unavailable. Command output: Failed to set
   recipient: Mailbox unknown.  Either there is no mailbox associated with
   this name or you do not have authorization to see it. 5.1.1 User 
unknown,
   code 550

------------------------------------------------------------------------

Reporting-MTA: dns; kolab.internal
X-Postfix-Queue-ID: BB396868046
X-Postfix-Sender: rfc822; yyy at babel.homelinux.net
Arrival-Date: Mon, 21 May 2007 12:10:49 +1000 (EST)

Final-Recipient: rfc822; xxx at kolab.internal
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; service unavailable. Command output: Failed 
to set
   recipient: Mailbox unknown.  Either there is no mailbox associated with
   this name or you do not have authorization to see it. 5.1.1 User 
unknown,
   code 550

==============  end of message =============


After I attempted to delete the user, the delivery failure has changed 
to this:

==============  start of message  ==============

The original message was received at Mon, 21 May 2007 12:20:32 +1000
from localhost [127.0.0.1]

  ----- The following addresses had permanent fatal errors -----
xxx at kolab.internal    (reason: 550 <xxx at kolab.internal>: Recipient 
address rejected: User unknown in local recipient table)
   (expanded from: <xxx at internal>)

  ----- Transcript of session follows -----
... while talking to kolab.internal.:

>>> >>> DATA
>>>       
<<< 550 <xxx at kolab.internal>: Recipient address rejected: User unknown 
in local recipient table
550 5.1.1 xxx at kolab.internal ... User unknown
<<< 554 Error: no valid recipients

------------------------------------------------------------------------

Reporting-MTA: dns; gate.internal
Received-From-MTA: dns; localhost
Arrival-Date: Mon, 21 May 2007 12:20:32 +1000

Final-Recipient: rfc822; xxx at internal
X-Actual-Recipient: RFC822; xxx at kolab.internal
Action: failed
Status: 5.1.1
Remote-MTA: DNS; kolab.internal
Diagnostic-Code: SMTP; 550 <xxx at kolab.internal>: Recipient address 
rejected: User unknown in local recipient table
Last-Attempt-Date: Mon, 21 May 2007 12:20:32 +1000


------------------------------------------------------------------------
===========  end of message  =========

What is fairly clear from this is that originally, mail could not be 
delivered to this user even though postfix believed the account existed; 
and that the attempted delete has changed the state such that postfix 
now believes that the user does not exist, even though the user's 
details are still stuck in the LDAP database.

Looking in the Kolab webinterface, I can see all accounts I have 
attempted to create, including the account awaiting cleanup. Looking in 
LDAP with either ldapsearch or phpldapadmin I cannot see a number of 
recently-created accounts, and yet I *can* see the partially deleted 
account.

Looking in /kolab/var/imapd/spool/domain/kolab.internal/user/ is can see 
that the user I attempted to delete has no entry here. I am not sure if 
this is a result of the delete operation, or a symptom of the problem 
which is creating lame user accounts. I can tell you that a number of 
other recently-created accounts have no entry in here either, and I have 
*not* tried deleting any of these (although I have modified some details 
in an attempt to make them work).

It seems that Kolab account information is stored in at least 3 places:

1. as a mailbox
in the IMAP system

2. as an entry in the LDAP database

3. At least 1 other place as well?
(i) in some IMAP account database?
(ii) in some Kolab account database?

Given that a number of recently-created accounts aren't showing up in 
LDAP (as far as I can see - I am no expert), and that Kolab is also 
having trouble deleting accounts, I am wondering if something has 
broken, either in LDAP, or in Kolab's interface to LDAP?

I am having trouble debugging this at the LDAP level due to permissions.
When I try deleting the limbo entry with ldapdelete, I get an error 
saying 'Invalid credentials'. I am supplying what I believe is the 
password for slapd, but I'm not really sure which password I am supposed 
to be providing for this operation. I can login to phpldapadmin under my 
own email account, but that doesn't have permissions to delete another 
user. I cannot login to phpldapadmin as the kolab admin user, but this 
may be normal - I don't know.

Can anyone suggest how I should proceed from here to debug this? I will 
try rebuilding the LDAP indexes (hopefully this evening), but I really 
need to know how to avoid having this happen in the future if possible, 
as taking kolab offline to rebuild things is not really practical in a 
live environment.

All suggestions most welcome.

Cheers!
Nik