The need of a new objectclass: "virtualDomain"

[Bruno Negrão]

Hi all, I work in an Internet Provider and I'm trying to implement qmail-ldap in a server hosting multiple virtual domains. Some of these domains will be divided into clusters, so this is a complicated installation. For this environment the tasks of adding and removing a virtual domain are not trivial. Using qmail-ldap, whenever I add one new domain to my environment I have to: 1 - edit the 'rcpthosts' and 'locals' control files of all machines in the cluster of that particular domain 2 - add the entries for the e-mails accounts pertaining to that domain according to the mailhost attribute. The maildirs can be installed in different machines - the ones making the cluster. When I want delete a virtual domain I have to: 1 - remove this domains from the 'rcpthosts' and 'locals' file of every host in the cluster 2 - remove all the Maildirs of the accounts from the deleted domain. 3 - remove the entries from the LDAP directory The challenge is to accomplish these steps above in an automated fashion. It is not easy. Trying to solve this, i'm elaborating a new objectClass to the qmail.schema, called "virtualDomain". It could help in solving this problem as it could propitiate room for new features in qmail-ldap and still improve the organization of the DIT's. When used in conjunction with auxiliary programs running locally in each mailserver in the cluster, the created virtualDomain entry can provide the information enough to automate those difficult tasks.   This objectClass could be like this: objectclass ( 1.3.6.1.4.1.7914.1.5.2.1 NAME 'virtualDomain'         DESC 'QMail-LDAP Virtual Domain'         SUP top         AUXILIARY         MUST ( domainStatus $ clusterHost )         MAY ( addedTo $ removedFrom ) See bellow a typical 'virtualDomain' entry in the ldif format: (observe the proposed attributes: domainStatus, clusterHost, addedTo) dn: ou=acme.com, ou=QMAIL-LDAP objectclass: organizationalUnit objectclass: virtualDomain ou: acme.com domainStatus: active clusterHost: brasilia.mynet.com clusterHost: saopaulo.mynet.com addedTo: brasilia.mynet.com addedTo: saopaulo.mynet.com Now I going to explain the reason for these attributes and the functionalities they could provide: ( some of these new functionalities  would require development in qmail-ldap, let's see what Claudio and Andre say about it...) domainStatus: The status for this domain. Values:  active: no restrictions. This means this domain is fully configured in every host in the cluster (they already added this domain to the files 'rcpthosts' and 'locals'). If the domain is not configured in a cluster, this means that the unique server where it is installed is already configured for this domain. noaccess: only mail delivery but no pop/imap access disabled: bounce incoming messages. If this domain is in a cluster, every machine in the cluster will bounce the messages to this domain. new: Serves as a flag to indicate that this domain have just been added to the DIT but wasn't configured in all machines in the cluster yet. While in the 'new' status, the server will bounce incoming messages like in the status 'disabled'. When the same hostnames listed in the 'clusterHost' attribute are set in the 'addedTo' attribute, the domainStatus must be changed to 'active' deleted: Serves as a flag to indicate that this domain is to be removed. While in the 'deleted' status, the server will bounce incoming messages like in the status 'disabled'. When the same hostnames listed in the 'clusterHost' attribute are set in the 'removedFrom' attribute, the entry for this domain can be removed from the Directory.   clusterHost: the hostname(s) of the machine(s) in the cluster. Value: 1 hostname. Default: the same name in the ~control/me file Note: Repeat this attribute for each host in the cluster.   addedTo: hostname of the server that is already configured to receive e-mails for this domain, that is to say, this domain is already setup in its ~control/rcpthosts and ~control/locals files. Value: 1 hostname. Note: repeat this attribute for each configured server.   removedFrom: hostname of the server that had removed this domain from its control files and removed all its Maildirs from the filesystem. Value: 1 hostname. Note: repeat this attribute for each hostname   So, let�s see an example of how to add the domain �acme.com� to the hosts �brasilia.mynet.com� and �saopaulo.mynet.com� using the virtualDomain entry.   1 � Add to the Directory the entry for the new virtual domain. The ldif would be:   dn: ou=acme.com, ou=QMAIL-LDAP objectclass: organizationalUnit objectclass: virtualDomain ou: acme.com domainStatus: new clusterHost: brasilia.mynet.com clusterHost: saopaulo.mynet.com   2 � Now, an auxiliary program running in each machine in the cluster should notice the new domain in the Directory. This auxiliary program will: check it the new virtualDomain entry has its �domainStatus� attribute set to �new�. if it has, check the �clusterHost� attribute to see if this machine is listed there as making part of the cluster. This check can be done by comparing the name in its ~control/me file against the values of the �clusterHost� attribute If this hostname is listed there, the program will add this virtual domain to ~control/rcpthosts and ~control/locals files. It will add to the virtual domain entry the �addedTo� attribute with its hostname. It will check if every �clusterHost� machines already put a �addedTo� field there. If yes, it will change the �domainStatus� to �active� and finish its execution, if no, it will just stop executing.   In an analogous manner the domains and Maildirs can be deleted with this auxiliary program.   I think this can organize qmail-ldap installation. Every time in the list we see someone asking: �How can I set up virtual domains with qmail-ldap?�. Disabling/enabling the deliveries in a domain level(actually, in a cluster level) is a good feature from the administrative point of view. Adding a nice virtual-domains support to qmail-ldap will give it a chance to grow where Inter7�s Vpopmail package is strong. Also, qmail-ldap would go one step further since it provides a means to divide domains amongst different machines.   So, what do you think about this? Could you at least understand what I tried to explain? Can you see some drawbacks/mistakes in this configuration? Would you like to add more ideas?   Thank you for the attention, ------------------------------------------------- Bruno Negrao - Network Manager Engepel Teleinform�tica. 55-31-34812311