Murder

[Rob Siemborski]

On 1 Oct 2002, Willem van den Oord wrote:

> from the config file. (This isn't in the documentation). When i added
> the lmtpproxy_username entry, it worked fine. I don't have to specify
> the other entries. I don't even need to specify a valid username. I
> think lmtpproxyd authenticates itself using the kerberos tickets it
> holds (in my case the mupdate tickets), is that a correct assumption?

Yes.  It should.  Did you declare the mupdate ticket to be an lmtp_admin
on the backend?

> When i try to create a mailbox (using the cyradm on the frontend) it
> says:
>
> NO Permission denied
>
> Which is really strange, because i *am* able to create a mailbox as the
> mupdate user, and there seems to be no immediate mupdate transaction
> involved. I suppose this might be wrong.

It's not as strange as you might think, though some of the logic is a bit
wierd.  We want to keep the privlidge level of the frontends on the
backends as low as possible, so frontends can't authenticate to the
backends as admin (well, they can authenticate as admin user, but they
lose all admin privlidges), so the frontends can't create top level
mailboxes themselves, they'd need to issue a referral.

But which server should they issue the referral to?  If a higher-level
mailbox already exists, we just pick that one (e.g. creating test.x.y
when test.x exists).  But if you want to create test.x.y if nothing
above it exist, we need to pick a server, so instead the admin should
just connect directly to the backend that they want the new mailbox
on.

I'd have to see in the code why you're getting Permission Denied in
particluar though, that may just be an unfortuinate side effect.

This should probably be documented somewhere.

> As a ordinary user i am able to create a mailbox just fine, allthough it
> logs an error message in the mail.log:

This is because the upper-level mailbox already exists, and because the
command doesn't need a referral (since users can be users on the backends
via the proxys, since they don't lose any administrative rights).

> Oct  1 16:10:33 jef cyrus/proxyd[724]: kick_mupdate: can't connect to
> target: No such file or directory

A side effect of running the master on the frotnend, this is in bugzilla
and hasn't been fixed since an option of just "mupdate_master_on_frontend"
doen't satisfy me.  Most likely I'll just put in a dummy kick_mupdate
socket on the master mupdate.

> I haven't tested deletion of mailboxes as an ordinary user but i guess
> this depens on the support of referals in the imap client.

No, it should just be proxied.

> Is using referals for mailbox deletion the way it should work? I was
> thinking about hiding my backend behind a packetfilter and presenting
> only the frontends, but when it returns referals to do the actual
> transaction, this isn't possible. I was also thinking on using perdition
> as a proxy to the frontends, to map usernames into mailbox names (i need
> this because we have different users with the same loginname now). This
> isn't possible either because it would refer to a backend and the
> username isn't valid anymore on the backend.

Yes, because of the administrative rights issue.  (So administrative user
deletes need a referral, but regular user deletes do not).

> Not to worry though... i guess i could let perdition connect to the
> right backends directly (when i also specify what backend to use), and
> let only the cross realm kerberos users (from windows 2000 servers) log
> in on the frontend :) (using the krb.equiv file to map principals to
> mailbox names). I really like that kerberos stuff! This doesn't break
> the mupdate database right?

A perdition-to-murder setup sounds like a hell of a complicated one to me,
but I'll take your word on it here (because of the username issue).

> The backends push there modifications to the
> mupdate master and the mupdate master informs the mupdate slaves when
> they need to know (right?).

Yes.  Or atleast that's the theory.  Under heavy load an update may take a
few seconds, which has caused us some strangeness and we're trying to find
ways to make the database more consistant (or atleast make sure that the
slaves are waiting to be consistant when they should be).

> Then there was the pop3proxyd issue. When i added a servername entry in
> the config file it didn't produce the Gethostbyname error anymore. But
> now it seems to segfault. At lease the mail.log says:
>
> Oct  1 16:43:42 jef cyrus/master[623]: process 843 exited, signaled to
> death by 11
>
> And the pop3proxyd just closes the connection.

I'd need a backtrace of the coredump to be of any help here.

> All things considered i have enough stuff running to build me a good new
> mail configuration and using murder is a great add-on. Besides providing
> load-sharing, I can configure all my hosts with the same postfix
> configuration because all mailboxes can be reached from all hosts, and
> it also should work for windows 2000 users using cross-realm
> authentication (allthough i haven't tested that yet). It also holds
> great potential for distributed mailboxes etc. I'm really looking
> forward to see how it will evolve and i hope i can help you guys a bit.
>
> A tip: It would be nice to have a facility to map usernames to
> mailboxnames via plugins in the proxy daemons (like perdition does).
> Maybe even using the perdition modules api, so one could use their
> modules. That would maybe be a more generalised alternative for the
> krb.equiv file too.

I'm still not sure what you mean here.  You have two user "foobar"s but
they map to different user.x mailboxes?  I think that this would be useful
in general for backends and frontends alike.

I'm not sure how you tell the difference in the two user.foobar(s) though.
The realm?  Cyrus IMAP 2.2 will do virtual domains that makes this work
correctly.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper