problems creating and deleting accounts
Nik777
kolab at babel.homelinux.net
Tue May 22 06:55:15 CEST 2007
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.
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. If the post you
directed me to below has tips on this, then that is my next port of
call. :o)
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. 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
>> >>
>> >
>> >
>>
>>
>
>
More information about the users
mailing list