andrew at morphoss
May 27, 2011, 9:43 AM
Post #2 of 2
(422 views)
Permalink
|
|
Multiple principal_ids generated for the same user
[In reply to]
|
|
On Sat, 2011-05-21 at 15:29 +0200, Jorge L?pez P?rez wrote:
> Hi all,
>
> I have had this week a rare issue with an user who complained about
> his calendar being shown empty. We're using DAViCal 0.9.9.4 and users
> authenticate against LDAP.
>
> After looking at the logs and enabling debug, I found out that user
> was authenticating OK, but its user entry was trying to be created once
> and again, throwing a 'duplicate key' on 'usr' table.
>
> With debug enabled I saw the following:
>
> --8<--
> ( correct authentication )
> [Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
> always: Query: DBGQ: SELECT *, to_char(updated at time zone 'GMT','Dy,
> DD Mon
> IYYY HH24:MI:SS "GMT"') AS modified, principal.*, 0::BIT(24) AS
> privileges FROM usr LEFT JOIN principal USING(user_no) WHERE
> lower(username) = lower(:
> param)
> [Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
> always: Query: DBGQ: ":param" => "user_with_problems"
> [Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
> always: Query: DBGQ: Took: 0,003533 to find 151 rows.
> [Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: ALL:
> LDAP:user user_with_problems doesn't exist in local DB, we need to create it
> -->8--
>
>
> 151 rows! For me it seems like a bug, user was working all right until
> a new principal was added for him (I don't know under which
> circumstances), and after that every authentication attempt results in
> new usr & principal being created (now we have 152 principals for this
> user, fortunately only one 'usr' because of key duplicity constraint).
> Of course that makes all calendar queries to fail.
>
> I can remove unused principal rows for this user by hand, but did
> anyone suffer this issue too? Could it be a known bug corrected in git
> version? If not, what can I do to help you debug this one?
Yes, this is a known issue, and I believe the LDAP code in Git has a fix
for it. Also, make sure you run the database update, because the latest
database patch adds a constraint on there also.
Cheers,
Andrew.
>
> If that helps, there is no other user with this issue (checked with
> count() on principals table), and these are the first 3 rows for this user:
>
> --8<--
> principal_id | type_id | user_no | displayname |
> default_privileges
>
> 181659 | 1 | 1225 | USER FULL NAME |
> 000000000001111000000000
> 193527 | 1 | 1225 | USER FULL NAME |
> 000000000001111000000000
> 193528 | 1 | 1225 | USER FULL NAME |
> 000000000001111000000000
>
> -->8--
>
> I can provide the full debug log, if you need it.
>
> Thank you very much, regards.
>
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
$3,000,000.
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.davical.org/pipermail/davical-dev/attachments/20110527/e6ae454e/attachment.pgp>
|
