2008

catch-all account per domain

qmail-ldap control patch

I'm curious if anyone is using the control patch in a clustered setup, and
if so have you changed the tree layout at all?

The default configuration is one cn for each host.  In a clustered setup
with 50+ servers each sharing some common info there is a lot duplicated
entries.  Has anyone considered an option to store shared data in a common
portion of the tree? 

From the patch:
+The 'cn=' entry is the FQDN  (Fully Qualified Domain Name, ie the full
+hostname+domainname)  of the  host qmail  is running  on. We  sort the
+entries under each 'cn=<FQDN>,<controldn>'  in our database so that we
+can  have multiple configurations  for multiple  qmail servers  in the
+same database under the same branch.

Maybe something like instead:

   dn: cn=clusterinfo,ou=qmailldap,o=org,c=us
   cn: clusterinfo
   objectClass: top
   objectClass: qmailControl
   locals: domain.com
   locals: example.com
   rcpthosts: domain.com
   rcpthosts: example.com
   dirMaker: /usr/local/bin/mkhome
   ldapBaseDN: ou=users,o=org,c=us

   dn: cn=mail1.domain.com,ou=qmailldap,o=org,c=us
   objectClass: top
   objectClass: qmailControl
   clusterDN: cn=clusterinfo,ou=qmailldap,o=org,c=us
   ....

I understand this would require a schema change and all.  The clusterDN
would be present in hosts that are members of the qmail cluster.  Otherwise
the entry for that mail server simply has the normal control entries.

I could be way off with this, so please correct me if I'm insane!  ;)

Frank Clements

Re: qmail-ldap control patch

Quoting "Frank Clements" <fclements <at> inetu.net>:

> The default configuration is one cn for each host.  In a clustered setup
> with 50+ servers each sharing some common info there is a lot duplicated
> entries.  Has anyone considered an option to store shared data in a common
> portion of the tree? 

I have not, but it's a extreamly good idea.

> I understand this would require a schema change and all.  The clusterDN
> would be present in hosts that are members of the qmail cluster.  Otherwise
> the entry for that mail server simply has the normal control entries.
>
> I could be way off with this, so please correct me if I'm insane!  ;)

The schema change is the simple part. It would take 20 seconds to do :).

The code change is a little more difficult (not much, but with error
checks etc it's a little more complicated).

One question (to all that is interessted in this idea/patch): If a
value exists both in the FQDN object and in the clusterinfo object,
which takes precedence?

First thought would be the FQDN value, which means that the code would
have to get the 'clusterDN' attribute first, load all that information
and THEN continue with the FQDN object... But do anyone have any other
opinion?

This idea is a good one even outside the Qmail-LDAP/Controls patch.
In this case, the clusterinfo object/DN would be a directory within
the control directory (and have be synced in any fasion needed).

RE: qmail-ldap control patch

With regard to which entry taking preference.  I would say the more specific
(the fqdn entry) would take priority over any clusterconfig container.
There may be those obscure cases where one host out of a cluster of hosts
handles a few extra domains.  Maybe it would be better to attempt to merge
them?  That just seems like it might get ugly.

-Frank

-----Original Message-----
From: Turbo Fredriksson [mailto:turbo <at> pumba] On Behalf Of Turbo Fredriksson
Sent: Thursday, January 10, 2008 8:22 AM
To: qmail-ldap <at> qmail-ldap.org
Subject: Re: qmail-ldap control patch

Quoting "Frank Clements" <fclements <at> inetu.net>:

> The default configuration is one cn for each host.  In a clustered setup
> with 50+ servers each sharing some common info there is a lot duplicated
> entries.  Has anyone considered an option to store shared data in a common
> portion of the tree? 

I have not, but it's a extreamly good idea.

> I understand this would require a schema change and all.  The clusterDN
> would be present in hosts that are members of the qmail cluster.
Otherwise
> the entry for that mail server simply has the normal control entries.
>
> I could be way off with this, so please correct me if I'm insane!  ;)

The schema change is the simple part. It would take 20 seconds to do :).

The code change is a little more difficult (not much, but with error
checks etc it's a little more complicated).

One question (to all that is interessted in this idea/patch): If a
value exists both in the FQDN object and in the clusterinfo object,
which takes precedence?

First thought would be the FQDN value, which means that the code would
have to get the 'clusterDN' attribute first, load all that information
and THEN continue with the FQDN object... But do anyone have any other
opinion?

This idea is a good one even outside the Qmail-LDAP/Controls patch.
In this case, the clusterinfo object/DN would be a directory within
the control directory (and have be synced in any fasion needed).

strange basedn in ldaplookup

Hi, all!

I have installed and set up qmail-ldap-control patch(es) successfully
and communication with ldap is going god, but the strangest string is
added to ldapbasedn, witch have right dn in the ldap database.

I have compiled qmail-1.03 with qmail-ldap-1.03-20060201.patch and
qmail-ldap-1.03-20060201-controls20060327 "by book" and as LDAP server
I am using Fedora Directory Server 1.0.4.

Qmail is running in virtual debian etch (using openVZ) and FDS is in
another virtual environment. On qmail host I have installed ldap
libraries to be able to compile qmail.
Both these are running on my Pentium4 laptop.

The basedn is returned by function call in qldap.c as I can remember.
Any help? Thanks in advance

Bellow is output of qmail-ldaplookup commmand:
(Note the last part "dc=baZZl1ZZZZZZZ!ZailCon" that should be just "dc=ba".)

root <at> mail1:/var/qmail/bin# ./qmail-ldaplookup -d 4 -m f13o <at> l.pletisan.rs.ba
Searching LDAP for:
  (&(objectClass=qmailUser)(|
(mail=f13o <at> l.pletisan.rs.ba)(mailAlternateAddress=f13o <at> l.pletisan.rs.ba)))
  below dn: ou=People,dc=pletisan,dc=rs,dc=baZZl1ZZZZZZZ!ZailCon) <at> Z
qmail-ldaplookup: fatal: qldap_filter: no such object

--

-- 
Igor Milovanović
http://www.linkedin.com/in/igormilovanovic

http://www.flickr.com/photos/f13o
http://f13o.blogspot.com/

"The greatest inefficiencies come from solving problems you will never
have." -- Rasmus Lerdorf

Re: [OT] Anti-SPAM alternatives

Re: [OT] Anti-SPAM alternatives