Re: [Jamm-devel] Cleaner broke domain in LDAP

On Fri 2004-04-30 at 17.18 Keith T. Garner wrote:
> Did you manually edit this test domain in LDAP at all?  It looks like
> either the postmaster entry isn't in LDAP (that's a special entry in
> LDAP that is hidden from the jamm user) or that the postmaster's
> roleOccupant attribute is empty.
No, I didn't edit this or any domain manually, I hardly know how to do
to go about it.

> > The WUI shows [...] an exception
> > (only pasting top rows of root cause):
> 
> [stack trace removed]
> 
> > When I run jammCleaner I get the same exception:
> 
> I'm not surprised, its the same code path more-or-less at the end.
> 
> [other stack trace removed]
Yes, I made sure to myself that it didn't have anything with the Cleaner to do, but with what's in the LDAP's register. Just wanted you to know what little I knew.

> Can you share with us a dump of the LDAP structure from that domain
> down?  A command something like this should fit the bill:
>     ldapsearch -b "jvd=test.test,o=hosting,dc=ttt,dc=intranet" -x

Here it is, straight up:
[begin]
root@apache:~# ldapsearch -b "jvd=test.test,o=hosting,dc=ttt,dc=intranet" -x 
# extended LDIF
#
# LDAPv3
# base <jvd=test.test,o=hosting,dc=ttt,dc=intranet> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# test.test, hosting, ttt.intranet
dn: jvd=test.test,o=hosting,dc=ttt,dc=intranet
objectClass: top
objectClass: JammVirtualDomain
postfixTransport: virtual:
jvd: test.test
editAccounts: TRUE
editPostmasters: FALSE
accountActive: TRUE
lastChange: 1069951107
delete: FALSE

# [email protected], test.test, hosting, ttt.intranet
dn: [email protected],jvd=test.test,o=hosting,dc=ttt,dc=intranet
objectClass: top
objectClass: JammMailAlias
mail: [email protected]
maildrop: postmaster
accountActive: TRUE
lastChange: 1069951107

# [email protected], test.test, hosting, ttt.intranet
dn: [email protected],jvd=test.test,o=hosting,dc=ttt,dc=intranet
objectClass: top
objectClass: JammMailAccount
mail: [email protected]
homeDirectory: /home/vmail/domains
mailbox: test.test/postmaster/
cn: postmaster
accountActive: FALSE
lastChange: 1069761461
delete: TRUE

# [email protected], test.test, hosting, ttt.intranet
dn: [email protected],jvd=test.test,o=hosting,dc=ttt,dc=intranet
objectClass: top
objectClass: JammMailAccount
mail: [email protected]
lastChange: 1069761202
homeDirectory: /home/vmail/domains
mailbox: test.test/dumb.as.user/
delete: FALSE
accountActive: TRUE
cn: Dumb Ass

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 4
[end]

> The answer to your problem is probably just to go into LDAP and clean
> it up.  However, that doesn't fix Jamm's problem if its Jamm related.
> Jamm *shouldn't* leave a mess like this behind, but what's an
> application without bugs?

Thanks for your help so far. As I said above, I'm not confident with
LDAP and I can't tell what's (if anything) wrong from reading the search
dump above - I'm not familiar with the jamm schema to start with ... :)

On the side, I see that one of my co-workers have been playing 'round
adding the Dumb ***-user account (pardon for his language). However, he
has only had access to the WUI, and only for a limited time, so whatever
he's done it's been issued through the web application.

So, any help in resolving the postmaster-NPE matter is greatly
appreciated. ("Cleaning up" my co-worker I'll handle myself. :)


Thanks again,

	Fredrik Wendt



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click