Tuning defaults for 2.5

Fri Mar 4 08:36:53 EST 2011

Simon Matter wrote:
> I've checked the options you suggest and here is where I don't agree:
> 

Thanks Simon for your feedback!

> - altnamespace to 1
> I don't remember any problems with altnamespace = 0 so why change it? I
> prefer to have the "nontranslated" namespace everywhere by default, which
> is the one also seen with the admin tools.
> 

Please note that it is merely a change of the default value, and not an 
elimination of the option; one can still change this option to match the 
desired behaviour. We are certainly not seeking the one solution that fits 
all.

Adjusting the default may give new deployments the best starting position, or 
may not, and I think that's why we're reviewing these.

That said, one of the cases I'm offering for your consideration is user 
interaction (presumably much more prominent that admin interaction).

- An altnamespace: 0 environment would nest all folders inside the INBOX. It's 
like it's represented in admin tools, and it doesn't require translation of 
the namespace, I agree these are valid points. Users however would, in most if 
not all client applications, I presume - you tell me please, still be 
presented with 'New subfolder' options to be created 'next to' INBOX; 
effectively a dead corner since folders can only be created as subfolders of 
INBOX. Additionally, it seems unnatural to create 'Sent' as a subfolder for 
'INBOX' if you now what I mean.

- An altnamespace: 1 environment does not show this problem; the upper 
"account folder" can have new subfolders created (e.g. 'next to' the INBOX 
folder), but then again does not allow subfolders in INBOX -creating another 
problem for the user experience.

As you can see, each has their own little user interaction challenge, and 
perhaps the real, ultimate fix is to be sought in the client side rather then 
the server side.

Now, presumably, each and every one of us has already picked his/her favorite 
and would probably like the default changed or unchanged to reflect that. 
That's OK but while it also does provide only limited perspective on what the 
*default* should be for *new* environments, I would want to urge you all to 
consider 1) we can't find a set of defaults that Just Works(TM) for everyone, 
and 2) we might try to figure out what the best set of defaults is for any new 
Cyrus IMAP user (e.g. an administrator new to Cyrus), as opposed to the impact 
on run-time environments changing this option - concerns wrt. the latter are 
great if they give us extra checklist items and TODOs, but won't really stand 
in the way of *aiming* for the change of the default value, it'll merely 
change the timeline and effort required to do so.

I hope that better explains 'why' a change of the default value for these 
settings is under (my) consideration, and what I'm looking for. I apologize if 
the aforementioned is preaching to the chior and/or suggests you did not 
understand what I was looking for because obviously you do, or that your 
comments are somehow wrong because they are not; rest assured these additional 
considerations will make it into a pros/cons table for final evaluation and 
into documentation as well.

> - hashimapspool to 1
> I have also used hashed spool on large servers in the past but I really
> don't like it to be the default. Hashed spool is only needed on large
> systems which lack decent filesystems. More and more modern systems have
> no issues with the number of directories. Hashed spool is just a hack for
> those who need it.
> 

Understood; personally I change this default on deployments because I like the 
ability to navigate through the filesystem side, and environments are more 
likely to grow and have use for hashimapspool, then they are to shrink and 
have use for no hashing of the imap spool. I was throwing this default up for 
consideration 

> - improved_mboxlist_sort to 1
> I don't know about this one but it hurts reading we have to
> "dump/convert/undump their mailboxes.db" :(
> 

That is not what is required on an upgrade or update; What would be required 
if we were to change the default for this option, is to either;

1) set improved_mboxlist_sort back to 0 in /etc/imapd.conf,
2) convert mailboxes.db, for which I would need to provide a script, possibly 
packaging included, before I would be allowed to touch the default ;-)

> - normalizeuid to 1
> Is this in 2.5 now? Because it has been in out RPMS just as a patch.
> 

Sorry, if this is an RPM only thing, its my mistake to have included it here; 
I went through man imapd.conf on one of my systems, instead of using 
lib/imapoptions from the upstream GIT repository - I realize that only now. 
Perhaps inclusion of this patch upstream would be considered (we'll make that 
a different topic for now), in which case whether having the option and what 
the default should be would become relevant.

> - unixhierarchysep to 1
> It's a constant source of confusion and like for altnamespace, I prefer to
> have the "nontranslated" hierarchy separator everywhere by default, which
> is the one also seen with the admin tools.
> 

This does effectively prevent dot characters from being used in folder names, 
does it not? I think that's a pretty big hurdle to overcome for a new 
environment, which presumably discovers the inability only too late, and may 
have to go through a migration of mboxes and scripts.

> - virtdomains to userid
> I'm not sure but I prever the default being the one for the easiest case
> without any virtual domain and whatever. Using virtual domains is allready
> an advanced configuration, isn't it?
> 

Admittedly, I consider that it is indeed advanced configuration. When one 
touches this, one should either know what one is doing, or be playing with 
this in a pre-production environment ;-) Perhaps also exactly the reason to 
consider what the default value is, especially if we can find one that works 
for non-virtdomain depoyments as well as virtdomain deployments.

As virtdomains might change (low probability, but still), what does chaning 
this option do in relation with unixhierarchysep as well as hashimapspool?

> Let me add my wishlist here:
> 

Great, thanks!

> - delete_mode: delayed
> - expunge_mode: delayed
> Both options are very helpful for those who just install the server and
> work with it until they have to do restores. Doing restores from backups -
> if they exist :) - is quite an exercise for those not using it often.
> Recovering with the options above it just so cool :)
> 

True, and true.

> - sendmail: /usr/sbin/sendmail
> I remember /usr/lib/sendmail has been quite common in the last millennium,
> but today?
> 

I'm not aware of any systems that currently still have /usr/lib/sendmail 
indeed, other then perhaps those currently no longer supported by their 
respective upstreams.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20110304/062b16b6/attachment-0001.html 