problems creating and deleting accounts

[Nik777]

Greetings Alain!

Many thanks for your quick reply. With your help I've managed to create 
the new kolab accounts that I need at the moment. However, the Kolab web 
interface is still not creating the IMAP accounts. :o(

Alain Spineux wrote:
> At first it looks your imap server don't create the mailbox !
Yes, initial results indicate this is indeed what is happening.
> You should looks into /kola/var/imapd for any error messages.
I haven't been able to find any error associated with the creation of 
these mail accounts. I see the HTTP access in the webserver when I am 
creating them (using the webadmin interface), and then the next log 
entry I find is an error when postfix tries to deliver to this account.

I searched the logs with:

find /kolab/var -name "*.log" -exec grep -H <username> {} \;
> You can use cyradm to manage the imap mailbox
I had been trying that already, but it's not the easiest tool to use, 
particularly since Kolab's setup is somewhat different to the standard 
used in the documentation. However, with your help, I managed to 
connect. In the process I have a created a few more half-and-half email 
accounts for this user, but I finally succeeded in creating a useable 
account. I had to use a variation on their name, and then alias incoming 
mail to that new account name. But it works. :o)

However, I still need to find out why the IMAP account is not being 
created when I create a user in the webadmin pages. This is a big 
problem for me, since the company receptionist is in charge of creating 
email accounts for new users, and I can't get them to use cyradm.
>
> # cyradm -u manager --password password localhost
Thanks! That got me started very quickly!
> Hope this help
Yes indeed! Your expert advice helped a lot. :o)
>
>
> On 5/21/07, Nik777 <kolab at babel.homelinux.net> wrote:
>> 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
>>
>> _______________________________________________
>> Kolab-users mailing list
>> Kolab-users at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-users
>>
>
>