Internet Services from KKoncepts

Couriersite - The Gory Details

Couriersite is written in perl. It also include Stuart Langridge's Sortable javascript module to sort the column tables, the Tigra Calendar for a javascript calendar (used in selecting the date to stop an autoreply), and Gordon Messmer's amazing courier-pythonfilter, used for calling clamav scanning.

The CSS theme is based on Indigo by Arcsin. There's a link required by his license on the right side of the footer. You can remove it through the "$notice" variable in the couriersite.conf file, but you need to pay him, get his permission, or change the theme before you do.

You can also put whatever you want on the left side of the footer in the "$footer" variable. (We put a copyright notice and a link to our main web site there.) Finally there's a "$branding" variable which prints in the title. It's set to "Courier" by default so the title is "Courier Site Administration", "Courier Domain Administration", etc. But if you change it to "Joe's", then you get "Joe's Site Administration", and so on.

The program needs to run as "daemon", the same user that the courier server itself runs as. So it uses a small wrapper script which is compiled and runs as SUID root. The wrappers are trivially simple. #define REAL_FILE "/usr/lib/courier/couriersite/siteadmin.pl"
main(ac,av)
char **av;
{
setgid(1);
setuid(1);
execv(REAL_FILE,av);
}
So it drops permissions to the GID and UID of the "daemon" user (1) and then runs the appropriate file. The wrappers are compiled statically so we can use them on any distribution. They are HUGE compared to dynamically linked, but it saves having to recompile them for new kernels, new distros, etc.

But having the wrappers with hardcoded values means that if you want to run this from another location or as a different user, you'll need to recompile the wrappers. The .c files are in the "wrapper" directory of the tar ball. You can edit them and then rungcc -o siteadmin.cgi siteadmin.c and you'll have a new wrapper. If you want it static (like we do) add "-static".

Couriersite uses userdb for all User accounts. Eventually we'll need to move it to mysql, but at the moment we don't have any domains which have more than 500 or 600 users, and userdb is plenty fast for that. The installer forces userdb to be the only virtual user authentication method by settingauthmodulelist="authuserdb authpam"every time you run it. I should make it search for userdb in the string and add if it's not there, but that won't happen this time.

We also don't allow changing passwords through sqwebmail; we want users to log into Useradmin to do that since Sqwebmail doesn't have any checks on password length, strength, etc., and Useradmin does. So we remove the password changing option in sqwebmail by setting DEFAULTOPTIONS="wbnochangepass=1" in "authdaemonrc". This is the one other setting in the config files that the installer will overwrite each time. Again, I should make it smarter and just have it add this option if it's not there.

The config file, "/etc/courier/couriersite.conf" has a bunch of variables at the top which let you change the password policy and set some defaults. So you can set a default quota, etc. there and you won't have to set it every time you create a user. The rest of the variables are mostly the courier variables - sysconfdir, bindir, etc. I'm trying to generalize the system a bit more so it will work with more than just debian. But I've got a long ways to go.

The documentation is non-existent. If you understand courier well, you can probably easily tell what the program is doing. (So as was discussed recently, adding an "alias" domain to a hosteddomain creates the "alias domain<TAB>real domain" line in the hosteddomain directory and then runs makehosteddomains.) But if not, you'll have to look at the code or ask me if you want to know *what* it's doing to get where it claims to be going.

If something doesn't work like you expect, the first thing to do is go into the siteadmin.pl file and find the line which says die $@ if $@; Change the "die" to "print" and you'll see the error messages that don't make it to the web server when die exits. (There's a comment in the file about this as well if you can't remember which line to edit when you get there.)

This code has been evolving over the past 6 years, so there's probably a lot of cruft. And up until now it's been very tailored towards our environment. My long-suffering wife let me take a good part of this past week to clean up the code and generalize it, getting rid of all the "unspoken assumptions" that were in it. (At least the ones I could find.) But I'm sure there's still places where someone's situation never occurred to me and something will blow up. Hopefully those will be few and far between, but let me say "SORRY!" now just in case. :-)

Ultimately we're systems administrators, not programmers. So there are probably plenty of ways to do this better. If you can see one, please let me know. And if you find a little bug or a huge security hole, please tell me so I can fix it. Comments, critiques, criticisms, encouragements and bug reports are always welcome. Code to go along with it is even *more* welcome.