Universal tool - /usr/bin/cyrus

[Ondřej Surý]

Ok,

can I get the responses on the mailing list as "yes, we are interested
in such universal tool in case it keeps backward compatibility and
switches to cyrus user?".

What about the name? Is /usr/bin/cyrus good?

In case the answer to both question is "yes" then I'll improve the
tool to fix those issues mentioned in the mailing list (switching to
cyrus user, compile time path) and then rewrite the tool into the C
(so it can call mailbox_reconstruct() and others directly) with
keeping backwards compatibility (or the usual plan - keep both in one
major release (2.5.x), print deprecation warnings in next major
release (2.6.x) and remove them in next+1 major release (2.7.x)).

How does that sound?

Regards,
Ondrej

On Thu, Jan 6, 2011 at 19:02, Jeroen van Meeuwen (Kolab Systems)
<vanmeeuwen at kolabsys.com> wrote:
> Ondřej Surý wrote:
>
>> Hi,
>
>>
>
> Hi Ondrej,
>
> First of all, apologies for my belated response.
>
>> as a part of packaging cyrus-imapd for debian we have talked (and I
>
>> have coded it) about universal tool (like f.e. git has) which will
>
>> support all those commands in $libdir/bin/ directory.
>
>>
>
>> I have called it /usr/bin/cyrus, but it's not published yet, so if we
>
>> can agree on a need to have such command (and since there is several
>
>> name clash if the cyrus binaries are installed into /usr/bin I think
>
>> it's good idea to have such command).
>
>>
>
>> I would be happy to recode this into something more universal than
>
>> just a wrapper script to call /usr/lib/cyrus/bin/<command> so new
>
>> commands (like make_sha1) could be implemented directly as a
>
>> subcommand of this universal tool - with fallback to calling external
>
>> commands. (Look at git source it has a nice example how to implement
>
>> that.)
>
>>
>
> I suppose I have two remarks:
>
> - switching to the cyrus user (with complementary group mail) or any such
> configurable would prove usefull in terms of adoption into different
> distributions, and switching to the cyrus user would perhaps make the
> wrapper a /usr/sbin/ utility (/usr/bin/cyrus of course could be linked to
> consolehelper),
>
> - As the /usr/lib/cyrus/bin/ path is actually a compile time configurable, I
> suppose this wrapper can make use of that fact, and be included into
> upstream in full.
>
> The former notwithstanding, I like what I'm seeing.
>
> I suppose for the switching to the cyrus user, what I always do is, for
> example:
>
> # su - -s /bin/bash cyrus -c '/usr/lib/cyrus-imapd/ctl_mboxlist -d'
>
> Because the cyrus user does not have a valid shell in RPM based
> distributions. The '-' (for login) is there to make sure we not only *gain*
> cyrus user privileges but also drop the privileges we used to switch to the
> cyrus user (not sure this is damn accurate BTW).
>
> Thank you,
>
> 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



-- 
Ondřej Surý <ondrej at sury.org>