[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enterprise and Debian Pure Blends



"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:

> I agree that, specially after the coming of virtualization in x86
> systems, people tend to use the "one system, one application" paradigm
> but I can't agree that's a "best practice": it just avoids a short term
> management problem (related to responsibility delegation and promotion
> management) but adding a long term management problem (lots of systems
> -if even virtualized, to manage which tends to end up with systems *not*
> managed).

That problem is way easier to solve than the problem of multiple
applications on the same system, since the latter poses more challenging
interaction problems and security issues.  If you're running at an
enterprise scale, you've probably already solved the problem of
maintaining lots of separate systems, and if not, you'll have to anyway,
no matter how much you try consolidate applications.

I've run systems both ways over time, and every time we've let too many
applications accrue on a single system, we've regretted it later.  I
strongly believe it's best practices to separate out applications as much
as possible, particularly these days with powerful virtualization
environments available.

> Another server can be your "identity management" one, which could
> service LDAP and Kerberos KDC for instance.

I think running LDAP and a KDC on the same system is a very bad idea from
a security perspective.  If there is any system in your infrastructure
that you should absolutely put on a dedicated system, it's your KDC.  It
should generally be locked down to a much smaller subset of your full
system administration team, and ideally should require hardware token
authentication and possibly even no remote network authentication.  If
your KDC is compromised, you're in for a world of hurt.

> Yes and that's a problem hardly managed (today) at the distribution
> level and one that, say, Microsoft has focused on from the begining.
> Debian, for instance, is a very good system for "at-the-box" level
> management and as such, very "system administrator friendly" but lacks
> almost completly at the "site" level (at install time: is this going to
> be a "stand alone" server, an identity management server, an integrated
> in a "domain" workstation...? and for day-to-day administration: group
> the boxes per service family, group-manage debconf params and packages
> installed, cross-system integration, cluster configuration...)

I think this is all true, but I also do want to note that all that
user-friendliness is much less helpful when you're talking about a large
enterprise scale.  I think it's an interesting problem to solve for
smaller sites, but for example Stanford wouldn't use any of that even if
it were at the level of quality that Microsoft provides.

> I know that going this path is not exactly a trivial task, to say the
> less, and that each "site level" decision comes at the price of reduced
> flexibility (I said it before, but Debian Edu offers quite a nice
> example) but that's why I defend that going the "Best Practices" howtos
> and documentation is the proper point to start with (offers guidance for
> those that care or need without reducing flexibility when you know you
> need to go out the paved road).

Right.  I think documentation is more useful than automation in this area,
since particularly at the larger size, enterprises won't all fit in the
same box, or even a reasonable number of boxes.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: