Here is a list of things I have done in the past three years. I have written for the sake of personal record.
As a member of Delta : Created a “PC Based Oscilloscope“ in IIT Bombay, as a summer project. Used java servlets on the server side and a java applet on the client side. Was responsible for the whole of the software side - 2006 Summers Worked in Pragyan CMS V1, which finally got implemented in our college website - 2005-2007 Made Dalal Street, a stock market simulator using java servlets on the server side and using eclipse to make a java based ui compiled using gcj to eliminate the need of jvm to run the final executable - 2006 Dec - 2007 Jan Used CVS for the development of Dalal Street, understood the importance of a code versioning system.
As being a part of Delta Core (Technology Changes) : Implemented LDAP using openldap, in Delta, allowing everyone to have a central authentication server, with a common login everywhere, where everywhere includes : system login in Sun Lab comps Implemented NFS on Delta, which gets mounted on all Sun Lab comps, using the default nfs service provided by default on fedora, so everyone has the same home irrespective of the comp they login to, which they do through their ldap accounts. Implemented pure-ftpd on Delta, configured it to work through ldap, allowing everyone to access their home drives even from “outside” (the user labs). Setup, and advocated use of Doku for information keeping, made it work through LDAP. Implemented and introduced SVN on Delta, setup three repositories : pragyan, delta and dalal, delta for the use of all delta projects. Implemented and introduced trac on delta, setup three repositories : pragyan, delta and dalal. Customized all of these three. Learned how to customize through .egg files. Made svn and trac work through httpd authentication, which used LDAP to get authentication details. (this was hell) Revived delta as a student group - meaning, made sure many meetings were held, made sure everyone knew each other, everyone contributed something to delta and felt a part of the group, made sure many treats were held, and chucked a few inactive members out of delta. Created Pragyan CMS V2, from scratch.
As being Pragyan’08 Systems head : Implemented mail system through postfix, made its authentication work through ldap. Implemented mailman like features using contact attribute in ldap and aliases in postfix. Made dovecot work through ldap too. Learned what SSL certificates are, how they work, created a self signed ssl certificate for pragyan.org, using tinyCA2 provided in Fedora, and made it use it. (basically, allowed the use of https://pragyan.org/…) Implemented FDS (Fedora Directory Server) as a much better alternative to LDAP on Pragyan Server.
Apache can be used as an access method for things like svn, trac, and even a whole file system through webdav. And apache also supports authentication through LDAP. Hence Apache can be used to authenticate the services that it provides through LDAP.
What I needed for mailman like functioning while making postfix work with ldap was an attribute that stores content of type DN (Distinguished Name) i.e. a node address, or holding a data type that stores nothing but data of type that can hold address of the data type itself.
In openldap, I used a schemas called evolutionPerson and evolutionPersonList (available with my fedora openldap distribution by moving evolutionperson.schema in /usr/share/evolution-data-server-1.12/ to /etc/opanldap/schemas/). evolutionPerson is very similar to inetOrgPerson class, which stores basically everything that could ever be used to describe a person. The reason I chose evolutionPerson over inetOrgPerson was the availablity of the evolutionPersonList class. Its attributes are : mail, contact and listnName, where both mail and contact can contain more than one values. mail and listName attribute type is text, and contact attribute type is DN. contact’s were used to create groups, and mail’s were used to forward the email to a third party server. Here is a screenshot of the same in action :
The contact attribute worked like charm. If any contact attribute turns out to be another evolutionPersonList, it repeats the whole process again for it, collecting new mails from it, and if it turns out to be evolutionPerson, it takes its mail attribute. The whole process repeats itself, taking care that infinite loops do not get created. In the end, what we get a list of mail ids to which the mail has to be sent.
Now, I haven’t yet figured out how to add evolutionperson.schema to schema. So, what did I do for delta?? I simply created my own schema. For a user, I already had whatever I needed in inetOrgPerson. All I need was some sort of an inetOrgPersonList. So, here are the steps :
I am assuming you have already setup fedora directory server through the wonderful install scripts provided. (/usr/sbin/setup-ds-admin.pl and then /usr/sbin/setup-ds.pl)
Open Fedora Directory Server admin console : /usr/bin/fedora-idm-console
Under the server groups entry in the default view tree, select your directory server and open it, using the DN and password you provided earlier during the directory server setup.
Under the to configuration tab, select schema. Select Attributes in the right hand pane.
Create a new attribute by clicking on the new attribute button at the bottom of the right pane.
I needed two new attributes for my purpose :
contact : of type DN, multi valued.
listName : of type String, single valued.
The third multivalued attribute I needed, mail, already exists.
Now, under the Object Classes pane, create any number of Objects you nees, using the attributes you just now created, or the preexisting ones.
The one created was inetorgpersonlist having Required Attributes listName and objectClass, and Allowed Attributes contact and mail. That’s it!!
MDA : Mail delivery agent : A Mail Delivery Agent (MDA) is software that delivers e-mail messages right after they’ve been accepted on a server, distributing them to recipients’ individual mailboxes. (Eg: dovecot)
The local_transport parameter corresponds to the mail delivery agent used.
The default with postfix is local. The problem with local is that is requires local users and hence, a posixAccount schema to be an objectClass of every mail account. Rejected. Btw local also has to ability of mail forwarding to a user. i.e. if mailbox of user user1 is firstname.lastname@example.org (user forwarding), then local will also forward to email@example.com. By default, it assumes the uid of the user it is delivering mail to while delvering mail.
Next is virtual. This is the one used. Virtual accepts users who are system users. But virtual (for security purposes) does not forward to hosts other than the localhost. So how do we forward to external hosts? virtual forwards in case the mails are aliases. So we simply put the gmail address as the entry of one of the aliases of the mail. If virtual MDA is used then whose uid does it use? (because the uid of the user himself doesn’t exist on the system). Another parameter value has to be used :
mbox is a format for storing mails. It is the default format used in postfix and dovecot. This is a line from dovecot conf : mail_location = mbox:/var/spool/mail/virtual/PragyanMail/%u:INBOX=/var/spool/mail/virtual/%u
The first part (mbox:/var/spool/mail/virtual/PragyanMail/%u:INBOX=/var/spool/mail/virtual/%u) refers to the user’s mail folder, which contains all his mail folders (Trash, drafts, sent mail.. ) (the user’s mail folders are files in mbox format)
The second part (mbox:/var/spool/mail/virtual/PragyanMail/%u:INBOX=/var/spool/mail/virtual/%u) refers to the one specific user folder (i.e. server file) which postfix writes to, that is his INBOX. (All other folders are written to and handled by the IMAP client - dovecot.) Other variables which could have been used for specifying this are : %u - username, %n - user part in user@domain, same as %u if there’s no domain, %d - domain part in user@domain, %h - home directory etc.
A virtual user can specify his mail folder to be anywhere. So, the following is a security config for postfix INBOX files :
virtual_mailbox_base = /var/spool/mail/virtual
Also chmod g+s /usr/bin/procmail for it to be able to create mail directories
User mailboxes virtual_mailbox_maps - mapping between mailaddress (firstname.lastname@example.org) and mailbox location (/var/spool/mail/virtual/user1). A confirmation that the mail address corresponds to a real virtual user. For mail to be delivered, this entry needs to be there, which contains the mailbox address. This is but only a one to one mapping. (Ignores all following values) local_recipient_maps = $virtual_mailbox_maps This line is required whenever the local_transport is changed to something else. (in this case to virtual)
The final main.cf entry that fits it all : virtual_mailbox_base = /var/spool/mail/virtual . A file with the name that is a result of the previous query (uid), gets created in this directory as the inbox of the user. Workflow is mailid → getaliases → Use alias result to get mail ids → deliver. That is, first alaises get processed, then accountsmap.
Uninstalled openldap-server, openldap-client, db4utils rpm -e --nodeps openldap-server openldap-client db4utils etc... Reinstalled all of these from yum yum install openldap-server openldap-client db4utils etc... Reconfigured slapd.conf **invalid credentials (49)**
I started making strange sounds, started laughing without reason.
Opened a website listing down installation steps, followed them line by line **invalid credentials (49)**
Thats when I remembered Fedora Directory Server. (It wasn’t fully developed when I was implementing LDAP in Fedora 7, so didn’t use it then).
To my pleasant surprise they have the concept of “install scripts”. I felt like a king when the script asked me, “What would you like your domain root to be? Usually, you should keep it the same as your fully qualified domain name”. A smile appeared on my face. I knew the meaning of true happiness then.