Quoting John Rudd ([EMAIL PROTECTED]):
> > From: Chuck Yerkes <[EMAIL PROTECTED]>
> >
> > Quoting Clifton Royston ([EMAIL PROTECTED]):
> > > On Wed, Nov 27, 2002 at 11:50:14AM +0100, Jurgen Philippaerts wrote:
> > > > We are planning to upgrade our pop3 server (currently running on a dual
> > > > cpu Sun E450) to a more redundant solution.
> > > > with at least two qpoppers running, and using somekind of centralized
> > > > storage.
> > Why?
> >
> > What perceived problem do you think you'd solve?
>
> There are lots of reasons for it. Load distribution so that you can use
> smaller machines to serve your huge base of users. Easing your maintenance
> schedule by having multiple clones of the same end server, allowing you to
> take individual machines off-line so you can do maintenance without
> interrupting your production services, etc. And, really, even if you feel
> qpopper is reliable enough to be part of a '5 nines' type service, that
> doesn't mean the machine under qpopper is. (I'm not saying qpopper isn't
> that good -- the one time I thought qpopper was our problem, it wasn't ...
> it turned out to in fact be the machine under qpopper, which was having
> problems with its cache batteries).
Okay, load distribution is not failover. Failover means a machine
waiting for a (the?) main server to fail and take over for it.
Load distribution has its own bag of worms:
- You still need an HA back end (NetApp does this nicely).
- Concurrent access to the data.
- That means a SAN ($$$$$)
- or a shared file system (NFS, typically).
- *That* means dealing with locking
- It also means slower access (5 pop servers sharing a 1Gb/s
network will get you, typically, far less than 40MB/s).
I initially referrence to Nick Christensen's work. I still will.
I've done it. I'd do it again. It's not cheap.
5 9's (99.999% uptime) we can go through with the math. It's a
great marketing term that's usually meaningless. 17 minutes per
month of downtime. It can be done. For lots of money. It's
unwarranted (99% of the time customers spit out the term "5 9s").
> > > Getting the user login data to be shared also has several solutions,
> > > and though I'm not that familiar with Solaris, I know your options
> > > there should include LDAP and NIS+ (as well as simply slaving the
> > > password file from the master server.)
> > And Radius.
>
> And Kerberos for the authentication side ... for the account side, you can
> use just about anything (once your passwords aren't in the account system,
> you can even almost trust something as bad as NIS with the accounts
> themselves). For example, all of our passwords are in kerberos, and we
> serve non-kerberized mail clients through popper using PAM. The accounts
> themselves are in hesiod (which is sort of like NIS, only the underlying
> engine is DNS, giving you all of the flexibility and scalability of DNS).
Kerberos, done meaningfully, requires kerberized clients. Rare
with Internet use. Kerberos is best used within a "zone of trust"
where a single entity controls or "knows" the machines accessing
its services. I cannot expect that "jane smith" accessing her mail
from her friend's machine at home would use it. I like Kerberos, I
use it. I've also seen "kerberos" support where people pass their
password in the clear and the pop server tries to get a ticket using
the user/pass pair. Wrong way to hook in, IMHO. Defeats the security
and purpose of Kerberos.
I also like/use Hesiod (which can use DNS, I've also used it with
Sybase behind it). I've stuck very large alias files into Hesiod for
use by some 400 group mail servers in corporate use.
LDAP is a quite viable replacement and far more robust.
As I said, Radius is commonly used for authentication at ISPs.
Cyrus based IMAP servers can use internal user databases (as well
as external methods). NIS+ is dead and was pretty useless and poorly
done from the start.
