Ok, this makes sence then. So I should just move all my TMDA stuff into the .tmda director and remove the DATADIR from the .tmdarc-tmda file. I take it I will have to make the apropriate adjustments to the other directives in the file and all should be well.
Has anyone considered making a script that would add a virtual user by running the vadduser and then creating the .tmda dir and copying template files into the proper places so the user is ready to go? From what little I know of perl it seems like it would be good at doing this. Thanks Bryan > <[EMAIL PROTECTED]> writes: > >> Well if you follow the original TMDA vpopmail howto at: >> http://www.visca.com/tmda/tmda_vpop.html then no there is never a >> .tmda directory > > Well, that was well before we had virtual domain support, which meant > that you couldn't have a per-virtual user home directory. Since I added > the support to tmda-ofmipd, you should become accustomed to > thinking that it now works much more like a system user install of TMDA. > > Specifically, tmda-ofmipd sets the $HOME environment variable to the > virtual user's home directory, /var/vpop.../.../techropolis.com/tmda. > This means that os.expanduser('~/.tmda') now works in your config file > like it should, rather than referring to > /var/vpop.../.../techropolis.com like it used to. > > I highly recommend that you give each user a .tmda subdirectory and get > rid of your DATADIR setting. Then the virtual domain support > works pretty much the same as a non-virtual install. For now, you'll > still need to give the -c <config_file> parameter to tmda-filter. > That should get fixed soon, but there are a couple of other virtual > domain related things I'm still working onl. > >> so if ofmipd is properly reading the DATADIR variable it shouldnt >> matter. > > Oddly, tmda-ofmipd doesn't read or use any of your configuration > variables. It just runs the tmda-inject program, which does read your > config. Again, I recommend losing the DATADIR variable and just > keeping a standard .tmda directory (logs/, filters/, crypt_key). > > In my test environment, I have created a global /etc/tmdarc with my > three LOGFILE_XXX variables, like this: > > import os # don't remove > import time > > localtime = time.localtime(time.time()) > YYYYmm = time.strftime('%Y-%m', localtime) > > LOGFILE_DEBUG = os.path.expanduser("~/.tmda/debuglog." + YYYYmm) > LOGFILE_INCOMING = os.path.expanduser("~/.tmda/inlog." + YYYYmm) > LOGFILE_OUTGOING = os.path.expanduser("~/.tmda/outlog." + YYYYmm) > > My test user has no config file, because all the defaults now work > (FILTER_INCOMING, FILTER_OUTGOING, etc.) In other words, all users on > the system, virtual or otherwise, get private logs in their .tmda > directory and there are literally no other configuration variables set. > > I think this is a much easier system to maintain. > >> However that HOWTO is very out of date and focuses around 0.57 If I do >> symlink the crypt_key it woks fine. It would appear that ofmipd is >> actualy looking in {$DATADIR}/.tmda and not just {$DATADIR}. I havnet >> looked at the code but it just seems that way. > > Well, it's actually tmda-inject that seems to be having the problem. I'm > not sure why, though. The code that sets CRYPT_KEY_FILE is at the very > end of Defaults.py and it says os.path.join(DATADIR, 'crypt_key'), which > shouldn't put .tmda in there unless you have it as part of your DATADIR. > I'd just lose DATADIR and create a .tmda directory. > > > Tim > _____________________________________________ > tmda-users mailing list ([EMAIL PROTECTED]) > http://tmda.net/lists/listinfo/tmda-users _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
