Quota namespace questions
Nic Bernstein
nic at onlight.com
Wed Jan 18 18:06:33 EST 2017
Friends,
I'm working on documentation for various things Quota related, and find
that I'm a little confused about the "quota namespace." It appears
that, due to the second argument in
"mboxname_init_namespace("a_namespace, 1)" (quota.c:176) that quota
operations don't use 'altnamespace':
namespace->isadmin = isadmin;
namespace->hier_sep =
config_getswitch(IMAPOPT_UNIXHIERARCHYSEP) ? '/' : '.';
namespace->isalt = !isadmin && config_getswitch(IMAPOPT_ALTNAMESPACE);
namespace->accessible[NAMESPACE_INBOX] = 1;
namespace->accessible[NAMESPACE_USER] = !config_getswitch(IMAPOPT_DISABLE_USER_NAMESPACE);
namespace->accessible[NAMESPACE_SHARED] = !config_getswitch(IMAPOPT_DISABLE_SHARED_NAMESPACE);
if (namespace->isalt) {
...
}
else {
/* standard namespace */
sprintf(namespace->prefix[NAMESPACE_INBOX], "%s%c",
"INBOX", namespace->hier_sep);
sprintf(namespace->prefix[NAMESPACE_USER], "%s%c",
"user", namespace->hier_sep);
strcpy(namespace->prefix[NAMESPACE_SHARED], "");
}
return 0;
}
Am I reading that right (hint: not a C programmer)? But it also looks
to me like it should still use '/' as the hierarchy separator, right?
That's not what I'm seeing in my quota_db. I started with a system with
no quotas. The old configuration used quotalegacy, so when I added some
quotas, they ended up in /var/lib/imap/quota...:
# cyradm -U cyrus localhost
Password:
localhost> sq user/nic STORAGE 20000000
localhost> sq user/tim STORAGE 20000000
localhost> sq user/crystal STORAGE 20000000
localhost> sq user/nic X-NUM-FOLDERS 1000
localhost> quit
# head /var/lib/imap/quota/*/*
==> /var/lib/imap/quota/H/user.crystal <==
%(S (1190064060 20000000) M (13742) AS (3) NF (15))
==> /var/lib/imap/quota/K/user.tim <==
%(S (401903846 20000000) M (7308) AS (2) NF (8))
==> /var/lib/imap/quota/N/user.nic <==
%(S (1484883490) M (36930) AS (18) NF (42 1000))
I then used cvt_cyrusdb to convert from quotalegacy to twoskip, and I
still am seeing the netnews separator, rather than unix, both in the
quota_db and in the output from "quota -f":
# strings /tmp/quota.db
twoskip file
user.crystal%(S (1190064060 20000000) M (13742) AS (3) NF (15))
user.nic%(S (1484883490 20000000) M (36930) AS (18) NF (42))
user.tim%(S (401903846 20000000) M (7308) AS (2) NF (8))$
# su cyrus -c "cyrus quota -f"
Quota % Used Used Resource Root
20000000 5 1162171 STORAGE user.crystal
13742 MESSAGE user.crystal
0 X-ANNOTATION-STORAGE user.crystal
15 X-NUM-FOLDERS user.crystal
1450081 STORAGE user.nic
36930 MESSAGE user.nic
0 X-ANNOTATION-STORAGE user.nic
1000 4 42 X-NUM-FOLDERS user.nic
20000000 1 392484 STORAGE user.tim
7308 MESSAGE user.tim
0 X-ANNOTATION-STORAGE user.tim
8 X-NUM-FOLDERS user.tim
Now to be clear, I have no problem with this if it works, but I'm
concerned about confusing administrators.
We already have the task of teaching existing Cyrus admins about all of
the ramifications of converting to 'altnamespace: on' and
'unixhierarchysep: on' as the new defaults. This brings a new "but not
here" context on top of it.
Similarly, for new folks, who don't know or care about historical
legacies, we need to explain that while they're used to using slash "/"
they won't see that from "quota" runs, or when they go poking around to
repair quota problems.
I think I just need a good dose of cluefullness to proceed. :-)
Cheers,
-nic
PS - perl/imap/IMAP/Shell.pm POD info still says "The only I<resource>
understood by B<Cyrus> is C<STORAGE>." This needs updating (I'm happy
to do this.)
--
Nic Bernstein nic at onlight.com
Onlight, Inc. www.onlight.com
6525 W Bluemound Road, Suite 24 v. 414.272.4477
Milwaukee, Wisconsin 53213-4073
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20170118/f13ef7a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nic.vcf
Type: text/x-vcard
Size: 278 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20170118/f13ef7a0/attachment.vcf>
More information about the Cyrus-devel
mailing list