T+1 Year with PostfixAdmin...
Almost a year after talking about this project...I'm finally posting about it.

Been working on a new schema for postfix, I'll say that I did learn a few things about database design from someone before they left (or where asked to leave or were fired...whatever). I found that the current postfix admin schema is horribly incomplete. Sure it's a step up from using flat file configs, but it doesn't scale much further from it. The initial design we proposed was a multi-home domain with sub-domains defining user location on the multi-homed scope. Although very flexible, some serious custom work had to go into making the postfix admin schema work with this layout. Mix in some MySQL Master/Slaves, and the added complexity makes things interesting.

From what we found, the postfix admin schema is designed for a single homed server or cluster to only look at the data one way. We immediately blew that up once we added a second server taking an alternate look at the data. The quick solution was to add unique identifier to each domain row to give it a "home" locale.

"Great now the servers know how to differentiate between hosts in their home locale", we all thought.

Although this was technically true, the servers could then differentiate between locations it added duplicate data into the domain tables. Making PostfixAdmin interface completely unusable for domain management. Additionally, user management then became near impossible. The work flow was thus:

1. Log-in to the parent server hosting the maildir and create the maildir
2. Log-in to PostfixAdmin and create the mail user account on a child domain
3. Create an alias in PostfixAdmin from the parent alias domain to the child domain user account
4. Do anything extra like add to mailing lists etc...
   

...And then do that for every new account you need to create. Sure you can batch up the creation process for the existing users that you're porting over from whatever mail system you already have, but for new users it's sorta a pain in the ass. And don't even get me started on access control or transaction tracking for any of that.

The idea of PostfixAdmin is a nice one. Centralize the configs for a server somewhere that all the servers can reach (say in the same location as the mail server cluster). But anything outside of that scope and the tower comes crumbling down. Change a domain name somewhere and you have to update most of an entire table. Scaling...not such a high point.

Some solutions to the problem that I cobbled together are Perl and Bash scripts to help automate some of the process of user and maildir creation. But there in lies the problem. Some admins aren't so versed in *nix and require a fluffy hand holding interface. With the primary interface a little borked from the addition of the locales, I started work on a new schema that would allow better scaling, real transaction accounting, granular message ACLs (Getting a crap load of mail to only one locale or domain and not another? *bzzzz* Done; Don't like getting email from x92mS212-s.com? Great! Have the user add a rule to permanently block that email from their box and after a threshold from everyone else's too).

With the new schema complete, and +80% of stored functions and procedures in the can, I'll be able to start working on the new UI soon and deploying the transaction tracking triggers to all the dependent tables.

An Open Letter to an Employer

Something that some of us have noticed is there seems be a problem. Where and exactly what the problem is we are not exactly sure, but here is what we've noticed.

* Information provided to us seems to be a second though and/or reactionary
* We feel that our requests for equipment are viewed as unsubstantial or are re-reviewed and second guessed
* Commonly used company wide communications tools contact is standard, but has been wiped out in only one location. This break down of commonly used communication tool for the entire company has made it extraordinarily difficult to ask a simple 5 word question. Out of five offices, four use Secure-IM and communicate freely. Why not try it with Encrypted-IM support enabled.
* Usage of the IS wiki for a central point of information has not been utilized by others other than Don, Chris or myself
* Usage of the IS Support ticketing system for tracking issues not been utilized by others other than Don, Chris or myself
* Usage of the IS Order tracking system not being utilized by others
* Attempts to increase communication intra-department needs to be supported by all users in a department
* A lack of a defined process for communication (doesn't matter what the process is as long as we all stick to it).

As of now the developers group has the their own trac wiki, regular wiki, and SVN for managing communication and is keeping things rolling. But the support group seems to be mostly in disarray and dysfunctional. Questions that could be answered by looking at the pre-defined points of contact (wikis and ticketing systems).

What are we going to do? With out proper leadership and strong communication we cannot and will continue to not be able to function. The issue with communication is sitting and glaring in the eyes of other departments and divisions. We need to know whats going on with each other and know where we're going. There must be trust between the offices, the ability to know that something is going to be done and that the choice we're making are thought out. Understanding needs to be there that we have needs here that are more than hardware and that hardware is critical to maintaining daily use. Without it we are sunk.

We frustrated and tired and over worked. Each day we wonder what thing will be second guessed next. Each day wondering what change has happened that directly affects how we do business here that we won't find out about until we trip over it. The cohesion that we lack drags down our credibility, and in turn destroys our ability to have sound ideas and concepts taken seriously here.