New Server Tasks

[Scott Kitterman]

On Thursday 20 September 2007 07:23, Soren Hansen wrote:
> On Thu, Sep 20, 2007 at 11:23:13AM +0200, Nicolas Barcet wrote:
> > Short term :
> > a/ is there a good reason why spamd and clamd (or other similar tools)
> > are not part of the mail server task at this point ?
>
> Neither are in main at this point, and anything in the tasks must be in
> main. For Hardy we need to discuss which of these solutions we are
> comfortable supporting for 5 years (which is the scaring bit).

Clamav is hard to support for 6 months let alone 5 years (we are currently 
working our 4th security update for clamav in Feisty).  Spamassassin doesn't 
have the same kind of security update issues, but if not current quickly 
loses it's effectiveness.  

It's hard for me to contemplate Canonical signing up for contractual support 
for these in a form that would actually be useful to end users.  Both of 
these packages need a steady stream of backports to remain useful.

> > I can barely imagine someone running a mail server nowdays without some
> > kind of anti spam/anti virus nowdays...
>
> Agreed.

I wonder if we can have a supplemental task that includes a good default set 
of anti-spam/anti-virus from Universe.  The idea would be a solid core that 
could be supported for 5 years and then a recommended set of add-ons that are 
community supported.

I'd be interested to work on this.

> > b/ what is the reasoning behind including mutt and no webmail ?
>
> There's no webmail client in main AFAICS, so we need to look at the
> available options and figure out which one we feel comfortable
> supporting for quite a few years to come.
>
> Also, mutt (along with mailx) servers as good tools for testing when
> you're setting up a mail server.

I don't think those are valid reasons for inclusion.  Personally, I've never 
needed either for testing.  I think keeping the installed set to a minimum is 
useful.  If the documentation is going to describe using these for testing, 
then I think it would be fine, but otherwise not.

> > Roundcube has been mentionned yesterday on IRC but I have been running
> > it for a little while and think it is a bit too young just yet.  Would
> > rather recommend squirelmail.
>
> I've never really liked squirrelmail, but then again, I've never really
> liked *any* webmail client. I can live with roundcubemail, but even that
> annoys me. Setting up an imap proxy helps a lot to take the strain off
> the mail server, but php is just doesn't provide very good platform for
> building webmail clients.

Personally, I think of webmail servers as being a separate class of server 
than a proper mail server.  My mail servers do not even have a web server 
installed and I'd like to keep it that way.  I'm certainly not going to 
install PHP to do mail (but I don't provide webmail either).  

> > c/ for all data including tasks, could we detail a bit more what we are
> > planing to include as base config ?  I beleive that base config should
> > allow a total newbie to run the server without further configuration
> > other than account creation.  For example :
> > - do we plan to add some rbl checking to postfix by default ?
>
> There are currently no plans to that effect that I know of. That is not
> to say that there shouldn't be. :)

I will say it then. There shouldn't be.  Mail server administration is not a 
newbie task.  I do not believe it's possible to automate the setup to where 
it will just work.

There was a recently thread on postfix-users about trying to provide a list of 
recommended RBLs.  All the reasons it's not a good idea for Postfix to do it 
apply equally to Ubuntu.

> > - do we configure ntp by default ?
>
> Yes.
>
> > - do we run some hot in place backup procedure by default ?
>
> Nope.
>
> > Mid term :
> > a/ what would it take to prepare these tasks so that they could be
> > configured against an LDAP directory for account maintenance and
> > authentication on a conditional basis ?
>
> I think it would be good to set up some use cases that we want to make
> really easy and figure out how to implement those for Hardy.
>
If we wanted to get ambitious for Hardy, I think that the task to take on 
(which would include LDAP) would be the, "Your bosses want MS Exchange, but 
you'd rather use Ubuntu, here's what you do ..." use case.

Scott K