Devraj,

I have been thinking a lot about Gentoo as enterprise distribution, wondering 
what would be missing to make it work in that role. here's what I think.

Actually Gentoo has got all the characteristics to make a solid, performant 
and scalable enterprise Linux distribution but it can't achieve that role as 
it is designed and optimised to serve the needs of workstation users. That 
means for example to maximise the number of packages delivered, to deliver 
new packages as quickly as possible and to make sure that each package is 
stable individually. also, packages are compiled and used on the same 
machine.

In contrast, an enterprise class package management system should not be so 
much concerned about the number of packages delivered and the speed at which 
new packages are made available but should focus on getting key 
functionalites delivered in a stable and reliable manner. How long a package 
remains available is more important than how quickly.
So I think an enterprise distribution should focus on providing and 
maintaining stacks. Stacks are meaningful combinations of packages that 
deliver specific functionalities (e.g. an email system).The objective is to 
optimise the stack and not the individual packages. Look at what 
spikesource.com are doing.

Anyway, my point is that meta-ebuilds is a concept that enables the delivery 
of such stacks and should be developed beyond the current basic functionality 
to serve an enterprise Gentoo.

Other missing features are client-side tools to manage the selection of 
packages and stacks, their distributed compilation and their roll-out on a 
number of machines.

I am ready to participate in an effort to create an Enterprise Gentoo 
distribution with other people that share similar views.

JC Francois
http://www.noirextreme.com

On Monday 20 June 2005 02:36, Devraj Mukherjee wrote:
> Hi Robert,
>
> I have an idea for a system administration tool as well. Actually I
> started developing a GLSA update manager which would have a web based
> front end and eventually came up with the idea of a Gentoo styled
> enterprise distribution which would have a web based administration tool.
>
> Since I don't want to reinvent the wheel, I would use Gentoo as the base
> system and this would allow the flexibility of Gentoo Linux and would
> then write an ebuild to distribute my web based management tool with the
> relevant packages.
>
> Let me know if you are interested in something like this so I can
> discuss the idea with you further.
>
> Devraj
>
> --
> Eternity Technologies Pty. Ltd. ACN 107 600 975
> P O Box 5949 Wagga Wagga NSW 2650 Australia
> Voice: +61-2-69255866 / Fax: +61-2-69251039
> http://www.eternitytechnologies.com/
>
> Robert Larson wrote:
> > On Monday 13 June 2005 09:18 pm, Devraj Mukherjee wrote:
> >>Is there an ebuild that builds like a LAMP architecture for most popular
> >>applications on a Gentoo system?
> >
> > I can see quite a bit of use for something like this, and I have been
> > wondering about something like this too.  I have also been thinking a lot
> > lately about the possibility of Gentoo portage managing packages across
> > multiple hosts.
> >
> > With this metapackage idea, it seems to me that it would be a pretty
> > incredible thing if I could emerge meta-packages where I might answer
> > some simple questions, such as this:
> > # emerge -meta lamp
> > Would you like:
> > A. MySQL
> > B. PostgreSQL
> >
> > Or, I don't know, even a set of configuration files set in place to anwer
> > these questions for us.  The USE variable seems to answer these
> > questions, but it may be a bit limited for the concept of metapackages.
> >
> > I mention all of this because I have been working for months on
> > implementing an infrastructure such as the kind described on
> > infrastructures.org.  It would be nice to be able to build a set of
> > packages, on only a few terms. Even further it would be even more
> > productive to be able to build across multiple hosts, multiple
> > architectures, etc.  We are moving into a day where embedded systems are
> > more available, imagine having 200 embedded controllers you have Gentoo
> > installed on, and you can execute one emerge command across all of them
> > (of course, tested in a non-production environment first...). Or,
> > likewise, modify the USE flags on all of them with a single push of
> > make.conf.
> >
> > A few example metapackages might be:
> > ids:        emerges snort, can run multiple sensors, can tie logging 
> > mechanisms
> > into external programs that may also be included (ie: prelude, and sguil
> > for both real-time and post analisys).
> > prelude:    Network wide logging(securely), hids, nids, and may pull logs
> > and alerts from nagios, samhain, snort, etc. and provide a web frontend
> > authserver: ldap, sasl, heimdal, pam, samba-tng, squid, etc....
> > avgateway:  clamav, pop3vscan, squid, frox, etc...
> > gentoo-postinstall-default: vixie-cron, metalog, sudo, vim, (if needed:
> > reiserfs, etc)...
> > windowing:  xorg, gnome, kde, ati, etc.
> > themes:             gentoo-artwork, kde-themes, icons, etc..
> > stage1:     downloads tar, unpacks it, bootstraps, emerges system, etc.  - I
> > like this one, imagine deploying 100 identical (but, multiplatform)
> > workstations, using one gentoo configuration.
> >
> > Assuming that portage could work across multiple machines, we can define
> > the set of packages, the ways that these sets of packages can
> > interconnect, define which hosts, and define the incompatiblities, then
> > it would not be too daunting a task to supply the admin with a set of
> > options that they can use to implement an entire strategy in a day.  As
> > well, there would be use to me, if I wanted to create my own metapackages
> > through something similar to that of the Gentoo portage.
> >
> > I like the idea of one host to manage them all, and I love the idea of
> > stateful configuration.  I also love what portage has done to computing
> > (not excluding "ports"), and I will obsess until I can see it all
> > together.
> >
> > Just a few thoughts; I wanted to hear others.  Sorry for the lengthy
> > post.
> >
> > Robert Larson
-- 
[email protected] mailing list

Reply via email to