On Tue, 2 Dec 1997, Eric Gustafson wrote:
> it appears that I'll simply have to start from the ground up again.
> using majordom.majordom (not majordomo).
I've been watching majordomo-owner's mail and haven't noticed these errors
lately. Still, it was being generated... and could be generated again.
I think I'm going to adopt a similar procedure and start all over again.
I don't like unexplainable errors... or... errors that are explained
to the point that they should not be a problem, but still are! I mean, as
you have done, I've triple-checked all permissions/Makefile
options/majordomo.cf options/etc...
> What I'm a bit confused on is when (during compile/setup) to change from
> root to majordom (or another user) to finish the majordomo setup.
You mean when you have to change to an unprivileged user to run
config-test? I thought that was just to ensure permissions were set
correctly from a users environment... that is, to ensure users can't gain
access to config files, etc. and can access files/dirs essential to
Majordomo's operation. My understanding was that this would all be a
moot point if ran as root or the majordom user since root has no
restrictions and majordom owns the files/dirs.
> Mike, the listname.new and L.listname files are the filelocking and
Thanks for the info... :)
---
Mike Hoskins
SEI Data Network Services, Inc.
mike@seidata.com
|
|
