Tuning defaults for 2.5
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
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
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
> - 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:
> - 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
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Info-cyrus