problems creating and deleting accounts

Mon May 21 22:00:04 CEST 2007

OPS: I remember I got a problem because the clock of my computer was wrong.
look on of my previous post, title is : mailboxes not created until
kolabd restart or kolabconf run : solution

On 5/21/07, Nik777 <kolab at babel.homelinux.net> wrote:
> 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(

I'm happy for you

> 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.

The imap log are in /kolab/var/imapd/log/, look them all carefully.
Look also the kolabd log. These files are defined in /kolab/etc/rc.d/rc.kolabd

You can use tcpdump to see the interaction between kolabd and the
imap server when creating the account. (webadmin just modify ldap, then ldap
raise a event that kolabd will catch and then check the "last" modification and
synchronize the imap config and all other service)

# tcpdump  -n -i lo -l -s 4096 -x  port 143

HOPE .....
> >
> > # 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
> >>
> >
> >
>
>

-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you