Mark,
Based on what you describe below I thought of perhaps another alternative to this problem.
Since there is a process in Apple's Server Admin application that keeps changing Mailman's mm_cfg.py file I think it is safe to assume it expects to find this file there to keep it updated and its removal may likely cause a conflict.
Would it be possible to have a copy of this file moved to a different location and have Mailman look at the different location for this file while leaving the old one behind as a "dummy" file so that Apple's System Admin application finds the file it expects to find ? The changes would not impact Mailman as the mm_cfg.py it is using for its configuration is the one in the new location.
Do you think this would work ?
Thanks,
Joe
On 4/16/11 4:06 PM, "Mark Sapiro" mark@msapiro.net wrote:
It doesn't matter what the owner is. Normally, the group is the mailman group (_mailman in Mac OS X/Darwin) and the file is group writable. In the case of mm_cfg.py, it doesn't need to be writable because Mailman doesn't change it, only you do, but it must be readable by the Mailman group (_mailman).
I think it won't work because what ever process keeps reverting it is probably running as root and can write the file even without explicit permission. But, you could try. Presumably, when permissions were rw-r--r--, the owner was _mailman, so if the 'reversion' process is running as _mailman, changing the permissions to r--r--r-- may work if it doesn't cause any harmful side effects to the process doing the reversion.
If it were me, the first thing I would do is look in all the directories
~_mailman/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons /System/Library/LaunchAgents /System/Library/LaunchDaemons
for any .plist files with mailman in their names (or any files in the first directory) to see if I could figure out what process is reverting mm_cfg.py and then maybe edit the file to remove the process.