Clean out one account
So I was playing around with my FreeIPA connected Kopano, - and messed up content in my test mailstore. So I decíded to zap the content:
sudo kopano-admin --unhook-store klaus sudo kopano-admin --list-orphans sudo kopano-admin --remove-store BLABLA
After the next kopano-admin --sync I thought that I would be able to login to a fresh empty account. But no such luck, i got the MAPI_E_NOT_FOUND error. I first had to do a
kopano-admin --create-store klaus
What pussels me is that when I create en new user in FreeIPA I dont have to manually create a store. So I am wondering. Did I use the wrong procedure to clean out the postbox. And is there possible leftovers from the previus account.
Hi @mrmanor ,
what your’re describing is the expected behaviour. If you create a new user the server triggers the scripts in createuser.d, which ultimately create the store for you. Just because you unhook a store from a user no new store is create for him/her, since you for example could unhook with the intention to hook another existing store.
Thanks @fbartels, I am just trying to understand the inner working of the LDAP - kopano connection. I makes perfect sense to me, that a unhook should not create a new store for the user. But I was sort of guessing that, kopano-admin --sync would see the account as new, now that there is no longer a Kopano account associated with the LDAP account.
So there must be some information left after the removal, preventing createuser.d to create a new user store (- at next login attempt?)?
Hi @mrmanor ,
what kopano-admin --sync does is checking the internal user table (check
usersin your database) against your external auth. more specifically it checks the externid colum if all those ids are present in your ldap (your configured unique user id). If an id is missing locally a user is created, if an id us missing externally (in the ldap) the user will be deleted.
If you unhook a store the user still exists internally, thats why executing
kopano-admin --syncwon’t make a difference.
OK, Thanks for explaining @fbartels.