Menu
▾
▴
Re: [webmin-devel] Virtualmin Mail Server requirements
|
From: John G. <gr...@ag...> - 2008-02-27 22:17:44
|
Ok, I'm going to take a crack at that tonight. And I just did some
research on exim virtual domains, and it turns the way we did it is
pretty standard. We have per domain alias files in /etc/exim4/aliases,
some call the directory virtual, some virtualhosts. But other the name
of the directory everything seems to be pretty much the same.
And I already have code to everything below, its mostly a matter of
integrating it into the right places. And the fact that used my own
perl module to manipulate the aliases file. I might need to remove the
reference to it. Though you're quite welcome to have it.
How should I go about this? I assume I should work against the latest
code in cvs (or whatever you use). And sent you diffs?
John
Jamie Cameron wrote:
> Hi John,
>
> My suggestion would be to make the paths to exim that Virtualmin uses
> configurable (via the Module Config page), and to default them to whatever
> a standard Exim install from source uses. Then you can set them to match
> your site, and the defaults should work for everyone else.
>
> The basic level of Exim support that Virtualmin would need is :
>
> 1) Ability to create, delete and rename mail domains.
> 2) Ability to associate Unix users with Exim virtusers, so that
> email to fo...@ba... goes to the user foo.bar
> 3) Mail alias management
>
> If you get this much working, I could probably implement the rest.
>
> - Jamie
>
> On 27/Feb/2008 13:57 John Gray wrote ..
>
>> Jamie,
>>
>> You may remember that I suggested moving to a modular approach in the
>> past, and asked about adding exim support. Small world? Well, sort of,
>> Bill works for me. I *might* attempt to graft in support for exim.
>> There are a couple of caveats though. The first being that I'm not
>> quite sure what the standard exim setup is, but I'm quite sure my config
>> isn't it. I'm not necessarily against moving towards something more
>> standard though (as long as doesn't cause me a lot of pain). The second
>> caveats is that I'm unlikely to do a complete job of it. For the most
>> part, all we really need is for the virtual aliases to be maintained.
>> And the accounts to be added/removed. Right now we are running a hacked
>> system with postfix on the box runs virtualmin, but I added code to get
>> my exim aliases written to a place where the real mail servers will get
>> them (cfengine does the actually distribution).
>>
>> My real goal, in the end, is to not be running a hacked version, but to
>> get what we need into the standard distribution. So I guess my real
>> question boils down to exactly what constitutes exim support that'll
>> make its way into the standard distribution?
>>
>> Btw, my hacked version just added few apis to our own virtualmin module
>> and hacked into the mail feature file to call out to them. Its a weak
>> start on generic support.
>>
>> Thanks,
>> John
>>
>> Jamie Cameron wrote:
>>
>>> On 27/Feb/2008 09:23 Bill Moyers wrote ..
>>>
>>>
>>>> Hi, currently we have virtualmin installed on a machine that should be
>>>> running exim for mail. Since exim is not supported by virtualmin we also
>>>> have postfix running but with hooks to inform exim when changes (to alias
>>>> files, etc.) need to be made. Two questions:
>>>>
>>>> 1) How hard do you think it would be for us to add exim support to
>>>> virtualmin?
>>>>
>>>>
>>> Not too hard, assuming that it supports the same concepts the other
>>> mail servers, like virtusers and aliases, and that it's aliases can run
>>> programs and deliver to mail files. The only hard part is that the code
>>> which deals with mail servers in scattered throughout Virtualmin - basically,
>>> any place you see references to $config{'mail_system'}
>>>
>>>
>>>
>>>> 2) Failing that, how hard would it be to add a sort of generic mail server
>>>> option? The generic mail server could make calls to an external plugin
>>>> which could be different for various types of mail servers. Seems like it
>>>> might be a bit simpler since we already sort of have this for exim
>>>> (although it's very ugly).
>>>>
>>>>
>>> What I should really do is allow plugins to implement a new mail server type,
>>> just as how they can currently create a new database type. But I'm not sure if
>>> this would be worth it, as it would require major changes to the Virtualmin core
>>>
>> ..
>>
>>> and there aren't really that many different mail servers out there :-)
>>>
>>> - Jamie
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> -
>>> Forwarded by the Webmin development list at web...@we...
>>> To remove yourself from this list, go to
>>> http://lists.sourceforge.net/lists/listinfo/webadmin-devel
>>>
>>>
>> --
>> John Gray gr...@ag...
>> AgoraNet, Inc. (302) 224-2475
>> 314 E. Main Street, Suite 1 (302) 224-2552 (fax)
>> Newark, De 19711 http://www.agora-net.com
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> -
>> Forwarded by the Webmin development list at web...@we...
>> To remove yourself from this list, go to
>> http://lists.sourceforge.net/lists/listinfo/webadmin-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> -
> Forwarded by the Webmin development list at web...@we...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-devel
>
--
John Gray gr...@ag...
AgoraNet, Inc. (302) 224-2475
314 E. Main Street, Suite 1 (302) 224-2552 (fax)
Newark, De 19711 http://www.agora-net.com
|
