[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: My Take on Virtdomains so far
From:       Ken Murchison <ken () oceana ! com>
Date:       2002-08-24 1:54:30
[Download RAW message or body]



Phil Dibowitz wrote:
> 
> First let me say that the overall abilities added to cyrus in such a short
> amount of time are VERY impressive. Ken, I'm really impressed with all of your
> work.

Thanks!  A _lot_ of the work was already done with the abstractions that
I did for altnamespace and unixhiersep.  If these weren't already in
place, this would've been a non-starter for me (since I currently have
no use for virtdomains).


> OK, onto the real VirtualDomain stuff...
> 
> 1. One thing that should be added to the documentation is that if you are
> logged in with cyradm as a local domain admin (i.e. admin@bla.com) you can NOT
> use the fully qualified username. So, you can't say 'cm user.phil@bla.com).
> You must use a relative name such as user.phil. I don't think this is a
> problem, but it should be documented.

This a bug that I will fix.  There is code to prevent cross-domain
access, but I forgot (or was lazy) to check for the same domain.


> 2. It should also be documented that if a global user and a local user have
> the same username, the local user takes precedence.

I believe that this is only a problem when the domain is fetched from
the IP address (which happens to always be on).  This can be overcome by
specifying a 'defaultdomain' which is the same as the domain of the
primary hostname of the machine (ie, make a default domain with the only
user being the global admin).  I'll try to find a better workaround for
this if I can.  But I would suggest that the global admin have a
different username from the per-domain admins, ie admins: cyrus
admin@domain1 admin@domain2 ...


> 3. As Ken noted, the certificate stuff for the IP-hosting still does not work
> - this seems to be the last major thing needed for use in the real-world
> (after all most people doing by-IP hosting are doing so atleast partly so they
> can use seperate certs). Following that, per-domain configs would be nice, but
> aren't necessary.

Did you happen to see the following post?  Option #1, if supported by
clients, would work for both single-IP and multiple-IP configs.

http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&searchterm=SSL%2FTLS&msg=16940

Other than that, I can add support for a tls_cert_dir which would have
one cert per address each using the domain as the name, ie
oceana.com.crt


> So, now that I've said all that, I have another comment. These code changes
> seem 99% beneficial to those who want by-name hosting, and not by-IP hosting.
> I say this because if I compare this method to the previous by-IP method
> (namely the one I wrote a document about here
> http://home.earthlink.net/~jaymzh666/cyrus/), there's not much advantage. In
> fact, as I look, I see more disadvantages then advantages. This is NOT to put
> down Ken's work at all. This is simply to say that I think the people who need
> by-name virtualhosting will find this more useful then those who want by-name
> hosting.

You're right, the code was designed for user@dom.ain logins.  The only
reasons that I added multiple-IP support were because people asked for
it, and it was trivial (~15 lines of code).


> Since the method in my page uses only the built in ability to pass specific
> config files to each 'service' the master launches, as I see it, it's no
> stretch or far-fetched use. It is just using a built-in feature that was
> previously not used very often.

The addition of per-service config files, was my first "poor-man's"
virtdomains implementation.  You were the first one to take the ball and
run with it!  ;)


> Here's my comparison (NOTE this is ONLY for per-IP hosting)
> 
> **Advantages of the Old method (http://home.earthlink.net/~jaymzh666/cyrus/)
>   - Seperate SSL/TLS certs
>   - Per-domain configs
>   - Control the number of pre-launched deamons per-domain
>   - Don't have to rely on reverse DNS, you can hardcode ip-to-service, or hard
> code domain-to-service (uses forward DNS at launch).
>   - Can have seperate LMTP sockets for each domain so configuring your SMTP
> daemon is (potentially) less of a hastle.
> 
> **Advantages of the New method (builtin virthosting)
>   - Less config files (but no per-domain configs)
>   - Can set total number of daemons which can answer to any IP instead of
> having seperate daemons per IP. This may save CPU cycles, memory, etc.
>   - Can have a 'default domain' for easy migration
>   - Can have a 'global admin'


Additions OTH (I still think your solution is good and viable one):

    - Less administration (one config file, one set of databases)
    - Works with Murder

 
> **Misc Note about the two
>   - Creating mailboxes is the same - connect to the right IP and use cyradm as
> normal
> 
> Of course, I would recommend that anyone wanting to use the "old" method
> change to use the directory structure of the "new" method so that you can use
> the new tools like mkimap, etc.
> 
> For anyone wanting by-name virtual hosting, Ken's new modifications couldn't
> have been done better. I haven't tested it, but the implementation decisions,
> IMHO are great.

Thanks again!  If this ends up anywhere close to a one-size-fits-all
solution, its because of the great input that I received from the list.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
[prev in list] [next in list] [prev in thread] [next in thread]