<[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
