problems creating and deleting accounts

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

<xxxkolab.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; yyybabel.homelinux.net
Arrival-Date: Mon, 21 May 2007 12:10:49 +1000 (EST)

Final-Recipient: rfc822; xxxkolab.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
-----
xxxkolab.internal    (reason: 550 <xxxkolab.internal>: Recipient 
address rejected: User unknown in local recipient table)
   (expanded from: <xxxinternal>)

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

>>> >>> DATA
>>>       
<<< 550 <xxxkolab.internal>:
Recipient address rejected: User unknown 
in local recipient table
550 5.1.1 xxxkolab.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; xxxinternal
X-Actual-Recipient: RFC822; xxxkolab.internal
Action: failed
Status: 5.1.1
Remote-MTA: DNS; kolab.internal
Diagnostic-Code: SMTP; 550 <xxxkolab.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-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

At first it looks your imap server don't create the mailbox
!
But your ldap looks to know the newly created user because
postfix accept
the email for him and then reject it after its deletion.

You should looks into /kola/var/imapd for any error
messages.
You can use cyradm to manage the imap mailbox

# cyradm -u manager --password password localhost

Dont forget to use the "opa /kolab" to initialize
your shell for kolab
management (look the wiki)

Here is the credential I use for ldap commands:

# ldapsearch -D
"cn=manager,cn=internal,dc=asxnet,dc=loc" -w
"password" -s sub -b "dc=asxnet,dc=loc"
"(objectClass=*)"

Hope this help


On 5/21/07, Nik777 <kolabbabel.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
>
> <xxxkolab.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; yyybabel.homelinux.net
> Arrival-Date: Mon, 21 May 2007 12:10:49 +1000 (EST)
>
> Final-Recipient: rfc822; xxxkolab.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 -----
> xxxkolab.internal    (reason: 550 <xxxkolab.internal>: Recipient
> address rejected: User unknown in local recipient
table)
>    (expanded from: <xxxinternal>)
>
>   ----- Transcript of session follows -----
> ... while talking to kolab.internal.:
>
> >>> >>> DATA
> >>>
> <<< 550 <xxxkolab.internal>:
Recipient address rejected: User unknown
> in local recipient table
> 550 5.1.1 xxxkolab.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; xxxinternal
> X-Actual-Recipient: RFC822; xxxkolab.internal
> Action: failed
> Status: 5.1.1
> Remote-MTA: DNS; kolab.internal
> Diagnostic-Code: SMTP; 550 <xxxkolab.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-userskolab.org
> https:
//kolab.org/mailman/listinfo/kolab-users
>


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

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

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. 

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. 
>
>
> On 5/21/07, Nik777 <kolabbabel.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
>>
>> <xxxkolab.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; yyybabel.homelinux.net
>> Arrival-Date: Mon, 21 May 2007 12:10:49 +1000
(EST)
>>
>> Final-Recipient: rfc822; xxxkolab.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 -----
>> xxxkolab.internal    (reason: 550 <xxxkolab.internal>: Recipient
>> address rejected: User unknown in local recipient
table)
>>    (expanded from: <xxxinternal>)
>>
>>   ----- Transcript of session follows -----
>> ... while talking to kolab.internal.:
>>
>> >>> >>> DATA
>> >>>
>> <<< 550 <xxxkolab.internal>:
Recipient address rejected: User unknown
>> in local recipient table
>> 550 5.1.1 xxxkolab.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; xxxinternal
>> X-Actual-Recipient: RFC822; xxxkolab.internal
>> Action: failed
>> Status: 5.1.1
>> Remote-MTA: DNS; kolab.internal
>> Diagnostic-Code: SMTP; 550 <xxxkolab.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-userskolab.org
>> https:
//kolab.org/mailman/listinfo/kolab-users
>>
>
>

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

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 <kolabbabel.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. 
> >
> >
> > On 5/21/07, Nik777 <kolabbabel.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
> >>
> >> <xxxkolab.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; yyybabel.homelinux.net
> >> Arrival-Date: Mon, 21 May 2007 12:10:49 +1000
(EST)
> >>
> >> Final-Recipient: rfc822; xxxkolab.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 -----
> >> xxxkolab.internal    (reason: 550 <xxxkolab.internal>: Recipient
> >> address rejected: User unknown in local
recipient table)
> >>    (expanded from: <xxxinternal>)
> >>
> >>   ----- Transcript of session follows -----
> >> ... while talking to kolab.internal.:
> >>
> >> >>> >>> DATA
> >> >>>
> >> <<< 550 <xxxkolab.internal>:
Recipient address rejected: User unknown
> >> in local recipient table
> >> 550 5.1.1 xxxkolab.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; xxxinternal
> >> X-Actual-Recipient: RFC822; xxxkolab.internal
> >> Action: failed
> >> Status: 5.1.1
> >> Remote-MTA: DNS; kolab.internal
> >> Diagnostic-Code: SMTP; 550 <xxxkolab.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-userskolab.org
> >> https:
//kolab.org/mailman/listinfo/kolab-users
> >>
> >
> >
>
>


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

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

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. 

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 <kolabbabel.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. 
>> >
>> >
>> > On 5/21/07, Nik777 <kolabbabel.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
>> >>
>> >> <xxxkolab.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; yyybabel.homelinux.net
>> >> Arrival-Date: Mon, 21 May 2007 12:10:49
+1000 (EST)
>> >>
>> >> Final-Recipient: rfc822; xxxkolab.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 -----
>> >> xxxkolab.internal    (reason: 550 <xxxkolab.internal>: Recipient
>> >> address rejected: User unknown in local
recipient table)
>> >>    (expanded from: <xxxinternal>)
>> >>
>> >>   ----- Transcript of session follows
-----
>> >> ... while talking to kolab.internal.:
>> >>
>> >> >>> >>> DATA
>> >> >>>
>> >> <<< 550 <xxxkolab.internal>: Recipient address rejected: User

>> unknown
>> >> in local recipient table
>> >> 550 5.1.1 xxxkolab.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; xxxinternal
>> >> X-Actual-Recipient: RFC822; xxxkolab.internal
>> >> Action: failed
>> >> Status: 5.1.1
>> >> Remote-MTA: DNS; kolab.internal
>> >> Diagnostic-Code: SMTP; 550 <xxxkolab.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-userskolab.org
>> >> https:
//kolab.org/mailman/listinfo/kolab-users
>> >>
>> >
>> >
>>
>>
>
>

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On 5/22/07, Nik777 <kolabbabel.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. 

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

> >> >
> >> >
> >> > On 5/21/07, Nik777 <kolabbabel.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
> >> >>
> >> >> <xxxkolab.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; yyybabel.homelinux.net
> >> >> Arrival-Date: Mon, 21 May 2007
12:10:49 +1000 (EST)
> >> >>
> >> >> Final-Recipient: rfc822; xxxkolab.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 -----
> >> >> xxxkolab.internal    (reason:
550 <xxxkolab.internal>: Recipient
> >> >> address rejected: User unknown in
local recipient table)
> >> >>    (expanded from: <xxxinternal>)
> >> >>
> >> >>   ----- Transcript of session follows
-----
> >> >> ... while talking to
kolab.internal.:
> >> >>
> >> >> >>> >>> DATA
> >> >> >>>
> >> >> <<< 550 <xxxkolab.internal>: Recipient address rejected: User
> >> unknown
> >> >> in local recipient table
> >> >> 550 5.1.1 xxxkolab.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; xxxinternal
> >> >> X-Actual-Recipient: RFC822; xxxkolab.internal
> >> >> Action: failed
> >> >> Status: 5.1.1
> >> >> Remote-MTA: DNS; kolab.internal
> >> >> Diagnostic-Code: SMTP; 550
<xxxkolab.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-userskolab.org
> >> >> https:
//kolab.org/mailman/listinfo/kolab-users
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>


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

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Tuesday 22 May 2007 06:55, Nik777 wrote:
> 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. 

kolabd logs to the host system syslog, thus under Debian you
will find
its logs under /var/log/syslog
(Yes, this is inconsistent.)

To get more debug out raise
log_level : 2
to : 100
in /kolab/etc/kolab/kolab.globals and restart kolabd.

-- 
Managing Director - Owner: www.intevation.net       (Free
Software Company)
Germany Coordinator: fsfeurope.org. Coordinator:
www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB
18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr.
Jan-Oliver Wagner

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users