>>>>> "SP" == Sean Proske <sean@wwd.org> writes:
SP> Now, if modifying sendmail.cf is beyond the scope of what Majordomo 2
SP> is intended to do (which makes perfect sense since there are so many
SP> MTA's and different versions of those MTA's out there, then I would
SP> suggest strongly that Majordomo make use of only 1 alias file and only
SP> 1 vut file.
Yes, the contortions that sendmail requires are extraordinary, but that's
just a reflection of how completely unsuitable sendmail is for this kind of
thing. Anyway, after some thought I can see how do handle this kind o
thing without breaking down the domain separation. Quickly:
Key is to surround domains with
## Aliases for domain $domain
and
## End Aliases for domain $domain
then, when updating aliases for a domain, scan through until you see the
line for the domain you want, print out the new entries, and print out the
rest of the file. If you hit EOF, add your entries to the end. Simple.
There is already a module (Mj::FileRepl) that handles locking, renaming,
temporary name, regexp searching and copying issues for you.
SP> For the FREE public list, I'd like to be able to have a master fronter
SP> and footer file so I can have the same ad display on all lists, and
SP> change the ad for all the lists by modifying just one file. I
SP> understand that there is to be a rotation feature... this also sounds
SP> GREAT!!!
I'll look into it.
SP> Also, I would like to see a feature that would allow the Majordomo
SP> Owner (the MAIN guy who runs the server) be able to set up a new domain
SP> by sending commands via email if this is not too much of a security
SP> risk.
The only way to add a domain is via rerunning the installation program. I
don't really have plans to change that right now.
SP> I would also like to see majordomo implement the following... first,
SP> whenever a new domain is added, modify the majordomo user's cron file
SP> to include the new entries
There is no way to do this portably. Methods for accessing crontabs differ
rather wildly between systems.
SP> and second, I'd like to see a mechanism in place to run a test to see
SP> if cronjobs are enabled and properly set up/functioning for the
SP> majordomo user.
Same problem.
SP> The createlist command works great, but I'm missing intro files being
SP> sent to the list owner... has this feature not yet been implemented?
Not implemented. Someone needs to write the file that should be sent out.
SP> I also don't see a global policy setting for subscribe, it seems to be
SP> set to open+confirm by default but I don't see the entry for that in
SP> the GLOBAL config file.
The defaults are in the mj_cf_defs.pl file. This is not something you can
modify through majordomo, since it's real live Perl code.
Now, an important note: just the work you have asked for here would occupy
my available time for over a month. That means that if you want _me_ to do
it, you're probably never going to get it. This is just the sad reality of
things right now; everyone makes feature requests and many say that the
software is useless to them unless certain features are added but nobody
contributes code. Even little fixes like the one you sent are useful but
real progress requires real code.
Anyway, unifying the alias and vut files is something that someone who only
knows basic Perl and knows nothing of Majordomo internals could do for me.
It would certainly save me some time to work on other things.
Other useful things that folks could do without learning everything about
the internals:
Make a create_domain command by separating out what the postinstall
script does.
Write support for other MTAs, like Exim.
Help correct unclear config variable descriptions.
Find and mark with some special comment every string anywhere in the code
that needs translation (for i18n purposes).
- J<
References:
|
|
