webadmin-devel

[webmin-devel] Virtualmin and mail server support...

[John G. <gr...@ag...>]

I just started using virtualmin, for the most part I really like it.  I
particularly like the plugin support.  I was able to write a plugin for
a few misc things we need when a virtual server is created quite easily.
(I'd post it, but I doubt its useful to anybody but me).

One of the issues I ran into is that we use exim.  Truth by told I don't
really need virtualmin to do much here, but manage some alias file
entries.  But I had to hack into things to get that going.  I hacked the
create_virtuser and its associates to call down the plugins so they
could manage my exim aliases entries.  That worked quite nicely.  Fairly
minimum changes to the  virtualmin code, but it got the info I needed
down to my own code. (btw, virtualmin believes I'm running postfix).

This all got me thinking about cleaner ways to handle the mail server
support.  Something like the plugin model, where support for different
smtp servers is done with a plugin per smtp server (or several in the
case of qmail).  Obviously a particular install would only want to use
one plugin for that matches its mail server.  This would have a couple
of nice upsides.  One the code would be cleaner (each module would only
have code for one smtp model).  And it makes it easier to add smtp
servers (in my case a highly non-standard exim configuration).  Is the
mail server support just to woven in to easily pull this off?

Is there any plans for anything like this? I sincerely doubt the I'm the
first to think of it.

Any plans to support exim?  I suppose one stumbling block is defining
exactly what a standard exim config is?

Thanks,
John

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

Re: [webmin-devel] Virtualmin and mail server support...

[Jamie C. <jca...@we...>]

On 10/Oct/2007 15:43 John Gray wrote ..
> I just started using virtualmin, for the most part I really like it.  I
> particularly like the plugin support.  I was able to write a plugin for
> a few misc things we need when a virtual server is created quite easily.
> (I'd post it, but I doubt its useful to anybody but me).

Hi John,

I'm glad to hear that someone else has used the plugin API successfully ..
hopefully it wasn't too baroque. I write a few plugins myself, but the
real test of an API is how easy it is for others to use :)

> One of the issues I ran into is that we use exim.  Truth by told I don't
> really need virtualmin to do much here, but manage some alias file
> entries.  But I had to hack into things to get that going.  I hacked the
> create_virtuser and its associates to call down the plugins so they
> could manage my exim aliases entries.  That worked quite nicely.  Fairly
> minimum changes to the  virtualmin code, but it got the info I needed
> down to my own code. (btw, virtualmin believes I'm running postfix).

The way the code is structured currently, the only way to implement
exim support would be in the core of Virtualmin - plugins cannot yet
add supported mailservers, as the code for handing email aliases and
virtual domains is scattered throughout the core.

I wouldn't be too hard to add exim support though - all the code
that deals with the mail server is in virtual-server-lib-funcs.pl and
feature-mail.pl . If you look for all references to $config{'mail_system'},
you can see the if statements that trigger different behaviour based
on whether the system is running Sendmail, Postfix or Qmail.

> This all got me thinking about cleaner ways to handle the mail server
> support.  Something like the plugin model, where support for different
> smtp servers is done with a plugin per smtp server (or several in the
> case of qmail).  Obviously a particular install would only want to use
> one plugin for that matches its mail server.  This would have a couple
> of nice upsides.  One the code would be cleaner (each module would only
> have code for one smtp model).  And it makes it easier to add smtp
> servers (in my case a highly non-standard exim configuration).  Is the
> mail server support just to woven in to easily pull this off?

That would be the ideal architecture, but it would be hard to implement
as Virtualmin stands now.. too much code would have to change.

> Is there any plans for anything like this? I sincerely doubt the I'm the
> first to think of it.
> 
> Any plans to support exim?  I suppose one stumbling block is defining
> exactly what a standard exim config is?

It's been discussed, but I haven't done any work on it yet.
I would certainly welcome a patch to add Exim support though..

 - Jamie

Re: [webmin-devel] Virtualmin and mail server support...

[John G. <gr...@ag...>]

Jamie Cameron wrote:
> On 10/Oct/2007 15:43 John Gray wrote ..
>   
>> I just started using virtualmin, for the most part I really like it.  I
>> particularly like the plugin support.  I was able to write a plugin for
>> a few misc things we need when a virtual server is created quite easily.
>> (I'd post it, but I doubt its useful to anybody but me).
>>     
>
> Hi John,
>
> I'm glad to hear that someone else has used the plugin API successfully ..
> hopefully it wasn't too baroque. I write a few plugins myself, but the
> real test of an API is how easy it is for others to use :)
>
>   
Hi Jamie,

I can give you a little feedback on the ups and downs of a newbie
creating his/her first plugin.  First off having a template plugin would
be very nice.  I ended copying a very simple plugin, then replacing the
guts with my own.  The next hurdle was getting it registered.  I ended
up running the create_domain.pl through the perl debugger and noticed it
was getting the plugins form some config option that did not have my
plugin listed.  I'm not sure what I missed when adding it through the
web interface, but I ended up adding it to the config by hand.  The last
thing, would be hints on the debugging.  I eventually figured out figure
how to get into my plugin quickly by running the perl debugger on
create_domain.pl or delete_domain.pl and jumping to just the right lines
(maybe this is short coming on my perl debugger knowledge, I can't seem
to set a break point in another file).  It was also very helpful to
include Data::Dumper in my lib functions file, and dump all the args to
a file when my apis get called.  It wasn't very clear all what data I
was going to receive.

In the end, it works quite nicely.  I'm very happy with how much
virtualmin is doing for me, and that its allowing me to extended it to
handle my servers irregularities easily.

John

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

Re: [webmin-devel] Virtualmin and mail server support...

[Jamie C. <jca...@we...>]

On 11/Oct/2007 05:32 John Gray wrote ..
> Jamie Cameron wrote:
> > On 10/Oct/2007 15:43 John Gray wrote ..
> >   
> >> I just started using virtualmin, for the most part I really like it.  I
> >> particularly like the plugin support.  I was able to write a plugin for
> >> a few misc things we need when a virtual server is created quite easily.
> >> (I'd post it, but I doubt its useful to anybody but me).
> >>     
> >
> > Hi John,
> >
> > I'm glad to hear that someone else has used the plugin API successfully ..
> > hopefully it wasn't too baroque. I write a few plugins myself, but the
> > real test of an API is how easy it is for others to use :)
> >
> >   
> Hi Jamie,
> 
> I can give you a little feedback on the ups and downs of a newbie
> creating his/her first plugin.  First off having a template plugin would
> be very nice.

That's a good idea - I'll create one and link to it from the plugin docs.

> I ended copying a very simple plugin, then replacing the
> guts with my own.  The next hurdle was getting it registered.  I ended
> up running the create_domain.pl through the perl debugger and noticed it
> was getting the plugins form some config option that did not have my
> plugin listed.  I'm not sure what I missed when adding it through the
> web interface, but I ended up adding it to the config by hand.

If you have created a new plugin, to enable it in Virtualmin go to
System Settings -> Features and Plugins, and check the box next to it.
Also, if this is a new Webmin module, you might first have to delete
/etc/webmin/module.infos.cache so that it is detected, and in the Webmin
Users module make it available to 'root' or 'admin'.

> The last
> thing, would be hints on the debugging.  I eventually figured out figure
> how to get into my plugin quickly by running the perl debugger on
> create_domain.pl or delete_domain.pl and jumping to just the right lines
> (maybe this is short coming on my perl debugger knowledge, I can't seem
> to set a break point in another file).  It was also very helpful to
> include Data::Dumper in my lib functions file, and dump all the args to
> a file when my apis get called.  It wasn't very clear all what data I
> was going to receive.

Yeah, I find STDERR debugging with Data::Dumper to the best method in
Webmin, as often you are dealing with CGIs that are hard to attach a
regular debugger to.
 
> In the end, it works quite nicely.  I'm very happy with how much
> virtualmin is doing for me, and that its allowing me to extended it to
> handle my servers irregularities easily.

Thanks! If you create a plugin that might be useful to others, you can
post it at http://www.webmin.com/third.html

 - Jamie

Re: [webmin-devel] Virtualmin and mail server support...

[Hugo C. <hug...@ya...>]

Jamie Cameron <jca...@we...> wrote:
Yeah, I find STDERR debugging with Data::Dumper to the best method in
Webmin, as often you are dealing with CGIs that are hard to attach a
regular debugger to.

What I often do to debug perl CGI scripts, is run them over Devel::ptkdb, a debugger that allows to set breakpoints and has an easy to use interface.

To open the debugger window on the right X-server, you can set the DISPLAY variable in the first BEGIN block of the CGI script (e.g. to point to the same display as where you run the browser that makes the http request).

I also use a rotating one shot log to debug scripts.  The rotation is important to track down a sequence of redirections.

Hope this helps.


Hugo




       
---------------------------------
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us.