problems creating and deleting accounts

Tue May 22 14:55:12 CEST 2007

On 5/22/07, Nik777 <kolab at babel.homelinux.net> wrote:
> Hi Alain,
>
> Once again, thanks again for your quick input.
>
> Just to keep everyone informed, I've discovered the following things:
>
> 1. When I checked today, the kolabd process was dead. I restarted it
> with rc, and it started OK
> 1.1 When I checked the webmin pages, the limbo user has now been deleted
> 1.2 Creating a new mailbox from the webmin page now works.
>
> 2. I had restarted kolabd twice testerday, once specifically, and once
> (presumably) with 'all' restart, yet apparently kolabd did not start up,
> or died almost immediately (certainly before deleting the user awaiting
> cleanup).
>
> 3. I can find no log of kolabd activity. The kolabd rc file lists a
> resmgr log, a freebusy log and a fbview log. These appear to have been
> showing activity even while the kolabd process was dead.

Yes they are used by some kolab filter used by postfix (look master.cf
files for more)

> The directory /kolab/var/kolab/log is empty. I'll look through all the
> config files, but if anyone can give me any tips on tracing kolabd
> activity and errors, I would really appreciate it.

I cannot help you more!

>If the post you
> directed me to below has tips on this, then that is my next port of
> call. :o)

Only if your clock is not accurate.

>
> 4. The kolab clamd server keeps shutting itself down, apparently every
> Sunday. I have no idea why. I re-started it last week when I noticed it
> had been shutdown, and now I discover it shut down in the early hours of
> Sunday morning again.
>
> At the moment, I can live with kolabd dying occasionally. The only real
> use we make of it (as far as I understand it) is when we create new user
> accounts.

You are right, and for some other chnage into the webadmin

>However, I will need to find out why these processes are
> shutting down, and figure out a way to keep them alive.
>
> I am less happy about clamd shutting down, although we do have an
> upstream email server running clamd at the moment, so we are not
> completely unprotected. However, I did want to decomission that server
> (hence the migration to Kolab).
>
> The server computer is not short of disk space (the kolab area has about
> 400Gb free), and the system clock appears correct (within a few minutes).
>
> Alain Spineux wrote:
> > 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
> Thanks. I'll read that post. However, the server's clock seems to be
> correct.
> I'll try running kolabconf this evening.
>
> Thanks again for all your help.
>
> Cheers!
> Nik
> >
> >
> > 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