RE: [gentoo-dev] Re: where goes Gentoo?

RE: [gentoo-dev] Re: where goes Gentoo?

[Eric Brown]

>On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote:
>> 
>> Interesting thread.  I have used Gentoo in enterprise situations very
>> successfully, and I think the whole QA/live-tree argument is moot.  In
>> an enterprise environment, you might have a backup/testing machine to
>> run your updates on first before they went live.  You also wouldn't run
>> new packages unless they passed your own QA tests first.
>> 
>> Given the incredible flexibility of portage to support local mirrors,
>> binary package preparation, and localized versions of packages
>> (portdir_overlay), I would say that Gentoo is quite a contender in the
>> enterprise environment.
>> 
>> Perhaps we need some enterprise documentation to help people realize the
>> full potential of portage?
>
>I think you've missed some of the idea of "enterprise" support.  See,
>for starters, every person shouldn't have to create their own
>implementation of everything.  Perhaps a better solution would be a
>package that when installed, builds up a local mirror, a binary package
>repository (with revision control), an automated update system, a system
>for updating rolled out machines without forcing the use of etc-update
>on each machine, a slower moving stable tree capable of being certified
>with applications, and most likely a phone number of someone to call
>when the shit hits the fan.

Every business application of Gentoo I've done has been different.  I don't think I could generalize my needs into a single ebuild.  Although generally I have used rsyncd and apache, I never use them in the same way.  What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use).

About automating updates and etc-update:  you can rsync your config file sometimes and just bypass all of the portage stuff.  You could mount some config dirs over nfs even.  You could even remove config_protect on some dirs and roll your own custom packages.

About a slower moving portage tree for enterprise users:  Great idea, I think there's a GLEP about that.  I think it's best handled by third parties who can spend the money/man power on that kind of QA.

This brings me to your last point about calling someone when there are problems:  There are companies that provide Linux services, even Gentoo specific services.  Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there.

>
>While I will completely agree that Gentoo *can* be used in the
>enterprise successfully, that does not make it "enterprise-ready", in
>any sense.  Many people also seem to misunderstand the concept of
>"enterprise" when we are referring to it in this manner.  We don't mean
>"I'm running it on 10 servers in production" or anything like that.  We
>mean "I'm running this as our production platform for Linux services
>across our entire enterprise, that could be hundreds or even thousands
>of servers" instead.  While it might be possible to maintain a handful
>of Gentoo servers, it is next to impossible to maintain an army of them,
>without spending significant up-front manpower to design, test, and
>implement your own set of management tools.  Gentoo has no real
>management tools.  There are a few here and there that do specific
>tasks, but there isn't anything designed to really take control over
>your network of systems.  To be fair, Red Hat doesn't have anything like
>this, either.  Their "Satellite Server" product is good for initial
>builds and for updates, but falls short on the management aspects.
>Novell's offerings are probably the best examples of what we really
>need.  Of course, most people would be happy with even rudimentary
>management capabilities, as currently, we have none.  We don't have any
>form of update server.  You have to build one yourself.  We don't have
>any form of "jump-start" or "kickstart" for rapid automated deployments.
>You have to build one yourself.  Now, we do have the Gentoo Linux
>Installer project, which has this as one of its goals, so we will have
>this component at some point in the future.

I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought enterprise meant this (answers.com):

en·ter·prise (ĕn'tər-prīz') pronunciation
n.

   1. An undertaking, especially one of some scope, complication, and risk.
   2. A business organization.
   3. Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism.
   4. Willingness to undertake new ventures; initiative: “Through want of enterprise and faith men are where they are, buying and selling, and spending their lives like serfs” (Henry David Thoreau).

Doesn't this just go to show that in business, everyone wants something different from Gentoo?  What does Novell offer to manage large numbers of linux boxen?  Are you sure projects like OpenMosix don't have tools you could use to manage such a large number of machines?

Maybe we can't rely on portage so much in scenarios where replication is the goal...

>
>Last, there's the "Our servers just went belly up, and I want to call up
>someone on the phone and give them a piece of my mind" issue which gives
>managers a warm, fuzzy feeling, that we cannot provide.  If something
>goes wrong with RHEL or SLES, you call up Red Hat or Novell and get them
>to work on the problem.  If something goes wrong with Gentoo, you hop on
>IRC, or file a bug, and hope that somebody can help you in the time you
>need it done in, and not in 3 weeks when the maintaining developer gets
>back from his tour of the African Dung Beetle in it's own environment.
>Liability is a big selling point for the enterprise.

Of course, I'm sure you can't call Red Hat or Suse if you don't pay them some way or another.  If you don't pay, could you find such a supportive community on IRC or in forums? (I think not)

There are lots of Gentoo gurus who will gladly accept your money to help you fix your problems =)

>
>I work for a telecommunications company, and we run Linux and Solaris.
>For our Linux, we run Red Hat, even though they have, on staff, one of
>the people that understands Gentoo's deployment capabilities better than
>most, via catalyst and the GLI.  Why do we run Red Hat?  When something
>breaks with one of their packages, we call them, and expect them to fix
>it.  It is also a name that gives upper management the warm fuzzies.
>Gentoo has neither the brand recognition, nor the support capabilities
>to be a good sale to management.

Sounds like FUD to me.  Use what works for you though.  If you managers really need that big brand name with that 800 number, that's just how you'll have to do it.  Perhaps I've been lucky at the places I work where I am simply responsible myself for keeping certain systems up, and that's that.

>
>I'm not denying that Gentoo is very powerful, flexible, and gives the
>power back to the administrator, but that doesn't make it enterprise
>ready or friendly.  A few success stories from a few people isn't much
>to support the position, when we are lacking in so many simple and
>obvious ways.  Remember, if a manager can think of multiple ways to
>knock down the use of Gentoo, like the ones I've given above, what are
>you going to do to refute his claims?

I wouldn't refute my manager's claims if he controlled my paycheck :D
But in my professional opinion, as someone who has had to manage up to 10 Linux servers at a time, Gentoo was by far the best choice.  That's what I'd say to my manager if he ever asked me why I want to use Gentoo.

>
>I want to see Gentoo as an enterprise-capable distribution myself, but I
>also understand that it is a long, hard road ahead of us, and there will
>still be some things we simply cannot provide as a community
>distribution, which was my reasoning behind the "fork".  There would
>need to be an entity that is responsible, liable, if you will, when
>something goes wrong, and that has the manpower and resources to fix it.
>

Ever consider founding a company that specializes in Enterprise Gentoo deployment and support?  It sounds like there could be quite a demand for such services :)

>-- 
>Chris Gianelloni
>Release Engineering - Strategic Lead/QA Manager
>Games - Developer
>Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 11373 bytes --]

On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
> Every business application of Gentoo I've done has been different.  I don't think I could generalize my needs into a single ebuild.  Although generally I have used rsyncd and apache, I never use them in the same way.  What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use).

You completely missed the management aspect here.  I'm talking about
some form of actual enterprise-ready management framework for
controlling a set of Gentoo servers centrally from deployment to
maintenance and upgrades.

> About automating updates and etc-update:  you can rsync your config file sometimes and just bypass all of the portage stuff.  You could mount some config dirs over nfs even.  You could even remove config_protect on some dirs and roll your own custom packages.

You can... You can... You can...

All I heard here was a bunch of excuses about how a person can take the
time to implement something that's been implemented by countless other
people, because Gentoo does not provide a framework for doing this.  The
whole idea of being enterprise-ready is having a drop-in solution that
works right off the bat, with minimal to no configuration for basic
services.  All of your solutions requires manpower to accomplish that
not every enterprise can afford to spend.  Once again, this is why
Gentoo is currently not used in these situations.

> About a slower moving portage tree for enterprise users:  Great idea, I think there's a GLEP about that.  I think it's best handled by third parties who can spend the money/man power on that kind of QA.

Yes, there is a GLEP about this.  This is also the first step to being
able to provide any level of enterprise-readiness.  You simply cannot
tell someone to upgrade glibc to some new version if something is wrong
with the current one.  They want a patch for the current one.  Think
bug-fixes only with absolutely zero new features between whatever form
of releases are created.

> This brings me to your last point about calling someone when there are problems:  There are companies that provide Linux services, even Gentoo specific services.  Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there.

I don't think I would stake my company's infrastructure on the reliance
on Bob and Joe's Gentoo Support Hotline, sorry.  Not to mention you
haven't actually given a single example of someone who can provide this
level of enterprise support.  There's a reason why you haven't given an
example.  None exists.

> I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought enterprise meant this (answers.com):
> 
> en·ter·prise (ĕn'tər-prīz') pronunciation
> n.
> 
>    1. An undertaking, especially one of some scope, complication, and risk.
>    2. A business organization.
>    3. Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism.
>    4. Willingness to undertake new ventures; initiative: “Through want of enterprise and faith men are where they are, buying and selling, and spending their lives like serfs” (Henry David Thoreau).

Wow.  A dictionary definition that is completely out of context and
doesn't account for the word enterprise being used as a technical
representation.

I've got a few "enterprise" definitions for you, too.

The Enterprise type is a two-man hiking sailing dinghy with a
distinctive blue sail and no spinnaker. Despite being one of the older
classes of dinghies, it remains popular and well used for both cruising
and racing. It has a combination of stability, size and power which
contiues to appeal to all ages, and to sailing schools.

...or...

Star Trek: Enterprise is a science fiction television series set in the
Star Trek universe.(Until the third season its title was simply
Enterprise, and it is often abbreviated as ST:ENT or ENT).The series
follows the adventures of the crew of the Enterprise (NX-01), the first
human interstellar ship that can achieve Warp 5.Enterprise premiered in
the United States on September 26, 2001, and is presently in its fourth,
and final, season.

...though the one I am looking for, and the one that fits the scope of
this conversation is this one:

In the computer industry, an enterprise is an organization that uses
computers. In practice, the term is applied much more often to larger
organizations than smaller ones.

We are using this in practice.  Therefore, we are speaking of large
organizations, and not just *any* organization.

> Doesn't this just go to show that in business, everyone wants something different from Gentoo?  What does Novell offer to manage large numbers of linux boxen?  Are you sure projects like OpenMosix don't have tools you could use to manage such a large number of machines?

Not really.  It does go to show that you'll go to great lengths to try
to prove a point, even when you're grasping at straws.  Everybody
wanting something from Gentoo has zero to do with the single goal of
providing an enterprise-ready version of Gentoo, which is the topic that
we are discussing.

Novell has several tools, that when used in combination, form a cohesive
framework for deploying, managing, and upgrading systems.  What's even
better, is it isn't just limited to Linux, but I'll leave that as an
exercise for the readers... ;]  Novell uses a combination of these
components, such as eDirectory and ZENworks, to form this framework.

> Maybe we can't rely on portage so much in scenarios where replication is the goal...

Portage really has nothing to do with deployment or management.  In
fact, the only thing it really does is package management, which is
probably why it is called a package management tool, and not an
enterprise resource manager.

> Of course, I'm sure you can't call Red Hat or Suse if you don't pay them some way or another.  If you don't pay, could you find such a supportive community on IRC or in forums? (I think not)

Of course not, nobody ever claimed that you could, nor implied it.

Nobody has ever mentioned *anything* about our community, because it has
exactly zero value in the enterprise, especially as a support medium.
Try telling some upper manager that he needs to download an IRC client,
then connect to irc.freenode.net, then join #gentoo and ask his question
in the channel, along with all the other noise, then hope that someone
answers his question.  Try explaining to him that this is the standard
form of support for your deployment, and watch as you get laughed out of
the office and off to the unemployment line.

> There are lots of Gentoo gurus who will gladly accept your money to help you fix your problems =)

Sorry, but I'm not calling vapier and listening to him tell me about his
wang when I have an issue with LDAP replication that I need resolved
immediately as my customers are starting to call in quite irate.  I
would want a company with a dedicated staff on-hand to support my needs
that is available when I need them.

> >I work for a telecommunications company, and we run Linux and Solaris.
> >For our Linux, we run Red Hat, even though they have, on staff, one of
> >the people that understands Gentoo's deployment capabilities better than
> >most, via catalyst and the GLI.  Why do we run Red Hat?  When something
> >breaks with one of their packages, we call them, and expect them to fix
> >it.  It is also a name that gives upper management the warm fuzzies.
> >Gentoo has neither the brand recognition, nor the support capabilities
> >to be a good sale to management.
> 
> Sounds like FUD to me.  Use what works for you though.  If you managers really need that big brand name with that 800 number, that's just how you'll have to do it.  Perhaps I've been lucky at the places I work where I am simply responsible myself for keeping certain systems up, and that's that.

Ooohh... FUD.  Amazing how someone telling the truth is immediately
labeled as FUD, especially when it goes against the misconceptions and
bold-faced lies that someone that is a bit overzealous in his devotion
is trying to push.  My managers are normal managers, just like you would
find all over the enterprise.  They want to know about risks and costs,
and are damn well and ready to pay for support if it means that their
ass won't be on the line when something breaks.  It is starting to sound
to me that your idea of "enterprise" is "production" when the two are
far different.  Think of enterprise as an order of magnitude or more
greater than production.  If you're thinking 10 servers, think 100, or
1000.

> I wouldn't refute my manager's claims if he controlled my paycheck :D

Haven't you ever been in a meeting?  You know, where they ask your
opinion.  Are you a drone?  Do you just do everything that you're told
and question nothing?

If so, then you're *perfect* for a middle manager position in any large
enterprise corporation.  Start puckering your lips now, it's a position
you'll get used to quite quickly.  For the rest of us out here, we
actually give our managers our opinions, and when we're trying to use a
product, we fight for it.

> But in my professional opinion, as someone who has had to manage up to 10 Linux servers at a time, Gentoo was by far the best choice.  That's what I'd say to my manager if he ever asked me why I want to use Gentoo.

I don't mean to offend you, but 10 servers is nothing like an enterprise
deployment.  I have more than 10 servers at my house, and I surely don't
consider that any kind of enterprise.  Instead, think about managing
1000 geographically dispersed servers.  This is more the scale that
we're talking about, not the local Baptist church's IT needs.

Gentoo is currently unmaintainable at this scale without a significant
investment in infrastructure and development to make the system
manageable.  Think of it this way, if I can pay 4 developers to work on
this project for 6 months, and each developer makes $50,000 a year, or I
can pay Novell $100,000 and have the system in place in 2 weeks, which
do you think I would do?  This is the exact reason why Gentoo is not
used in the enterprise more.  There is simply too high a barrier of
entry into making a usable and manageable Gentoo deployment.

> Ever consider founding a company that specializes in Enterprise Gentoo deployment and support?  It sounds like there could be quite a demand for such services :)

Yeah, I considered it.  Then I came down from the acid trip and realized
how hateful it would be.  I'm sorry, but I definitely don't want to
spend my time being restricted to working only on the problems that some
large corporation deemed was important to them, being harassed and
stressed to meet their deadlines.  I work on Gentoo because I enjoy it,
not because I gain from it financially.  I have no problem adding
enterprise features or improving enterprise support, but I get enough
stress at my day job, why should I get even more from my hobby?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 8194 bytes --]

Long one kiddies... responses inlined, bit more interested in 
discussion of what's required/desired then "your definition of 
enterprise sucks"... (throws on the flamesuit)...


On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote:
> On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
> > Every business application of Gentoo I've done has been different.  I don't think I could generalize my needs into a single ebuild.  Although generally I have used rsyncd and apache, I never use them in the same way.  What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use).
> 
> You completely missed the management aspect here.  I'm talking about
> some form of actual enterprise-ready management framework for
> controlling a set of Gentoo servers centrally from deployment to
> maintenance and upgrades.

Elaborate on what you explicitly want out of portage please- the 
domain concept (aside from being useful design wise) *should* allow 
groupping of boxes (groupping of domains really) behind it, so you can 
effectively have a set of boxes, pushing changes to each.

Mind you no code written, but current design is intended to allow 
remote chunks to be swapped in/out of portagelib on the fly 
(including the actual portage configuration).

> > About automating updates and etc-update:  you can rsync your config file sometimes and just bypass all of the portage stuff.  You could mount some config dirs over nfs even.  You could even remove config_protect on some dirs and roll your own custom packages.
> 
> You can... You can... You can...
> 
> All I heard here was a bunch of excuses about how a person can take the
> time to implement something that's been implemented by countless other
> people, because Gentoo does not provide a framework for doing this.  The
> whole idea of being enterprise-ready is having a drop-in solution that
> works right off the bat, with minimal to no configuration for basic
> services.  All of your solutions requires manpower to accomplish that
> not every enterprise can afford to spend.  Once again, this is why
> Gentoo is currently not used in these situations.

Better angle of discussion rather then "we aren't there yet" is the 
specifics of what is needed to *get* there in peoples opinion.

It's not an overnight thing, glep19 (stable portage tree) addresses a 
chunk of concerns when/if it's implemented, but I'm a bit more 
interested in the the other tools people desire alongside.

Re: a drop-in solution, considering that gentoo is effectively all 
over the map (seriously, look at the tree), define the profile for the 
drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.

Specifics...

Hell, I have yet to see what I would define as a proper solution for 
config manamagent for N gentoo boxes.  NFS solution possibly, but that 
seems a bit hackish to me.

> > This brings me to your last point about calling someone when there are problems:  There are companies that provide Linux services, even Gentoo specific services.  Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there.
> 
> I don't think I would stake my company's infrastructure on the reliance
> on Bob and Joe's Gentoo Support Hotline, sorry.  Not to mention you
> haven't actually given a single example of someone who can provide this
> level of enterprise support.  There's a reason why you haven't given an
> example.  None exists.

Moot point frankly, considering we're all volunteers; someone 
*could* get off their butts and start up an attempt to provide hand 
holding (effectively what you're coloring the management arg as) 
services, but even if they did, the followup arg would be that you 
can't yet trust this new support company, because they're new.
Etc.

Basically, we don't have control over that portion, so... what 
can be mangled that we *do* have control over, and has an effect?


> 
> [snip]
> In the computer industry, an enterprise is an organization that uses
> computers. In practice, the term is applied much more often to larger
> organizations than smaller ones.
> 
> We are using this in practice.  Therefore, we are speaking of large
> organizations, and not just *any* organization.

That's a really crappy description, rather nebulous. :)
And... nobody probably cares about loose definitions, 'cause loose 
definitions are moving targets.  Again, specific suggestions/requests 
would rock.

Mentioned management tools, well, get into specifics; pxe network 
installs/imaging?  Single tree/cache for N servers?  Ability to push 
updates out to a specific box, or set of servers?  Integration of 
portage contents db with IDS tools?


> Novell has several tools, that when used in combination, form a cohesive
> framework for deploying, managing, and upgrading systems.  What's even
> better, is it isn't just limited to Linux, but I'll leave that as an
> exercise for the readers... ;]  Novell uses a combination of these
> components, such as eDirectory and ZENworks, to form this framework.
> 
> > Maybe we can't rely on portage so much in scenarios where replication is the goal...
> 
> Portage really has nothing to do with deployment or management.  In
> fact, the only thing it really does is package management, which is
> probably why it is called a package management tool, and not an
> enterprise resource manager.

Any enterprise resource manager is going to have to fool with pkgs at 
some point- that's my line of interest in this.


> Sorry, but I'm not calling vapier and listening to him tell me about his
> wang when I have an issue with LDAP replication that I need resolved
> immediately as my customers are starting to call in quite irate.  I
> would want a company with a dedicated staff on-hand to support my needs
> that is available when I need them.

See bit above about being (effectively) outside of our control (a 
niche someone with a brain could exploit also).

Besides, it would be pointless to call vapier to hear wang tales; just 
stick your head in #gentoo-dev, you get them for free there...

> > I wouldn't refute my manager's claims if he controlled my paycheck :D
> 
> Haven't you ever been in a meeting?  You know, where they ask your
> opinion.  Are you a drone?  Do you just do everything that you're told
> and question nothing?
[snip]

If it's going to descend into a bit of flaming (has it already?), I'll 
gladly go back to poking at portage- I'd rather see something constructive out of this, 
you obviously see areas where gentoo isn't up to snuff (as do I)... 
so... what would be useful to implement *now*, what would be required 
*down the line*, etc.

Mind you, our hands aren't bound, their are areas that work can be 
done in.


> Gentoo is currently unmaintainable at this scale without a significant
> investment in infrastructure and development to make the system
> manageable.  Think of it this way, if I can pay 4 developers to work on
> this project for 6 months, and each developer makes $50,000 a year, or I
> can pay Novell $100,000 and have the system in place in 2 weeks, which
> do you think I would do?  This is the exact reason why Gentoo is not
> used in the enterprise more.  There is simply too high a barrier of
> entry into making a usable and manageable Gentoo deployment.
Or, you find a collection of trained coder monkeys who are oddballs 
who might have an interest in implementing this stuff on their own 
time, and try to nudge them in the correct direction; no, this isn't a 
solution, but again, having an ent. solution (going by your statement) 
isn't going to be funded by anyone.

Ok, fine.  So it goes.

Meanwhile, reiterating my point, I'd rather see a discussion of what 
people *want* in the way of tools, then "we aren't there yet".  
Generally known that you have to roll your own somewhat for tools, 
well, would rather know what people want then see then another round 
of kicking the dead horse.


~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 9124 bytes --]

On Thu, 2005-08-04 at 14:37 -0500, Brian D. Harring wrote:
> Elaborate on what you explicitly want out of portage please- the 
> domain concept (aside from being useful design wise) *should* allow 
> groupping of boxes (groupping of domains really) behind it, so you can 
> effectively have a set of boxes, pushing changes to each.
> 
> Mind you no code written, but current design is intended to allow 
> remote chunks to be swapped in/out of portagelib on the fly 
> (including the actual portage configuration).

The only things I could see being needed out of portage itself is the
ability to control "emerge" commands remotely, such as forcing an update
of apache to $version to resolve a vulnerability.

Besides the back-end portage pieces, there would need to be a front-end
interface for performing these tasks.

> Better angle of discussion rather then "we aren't there yet" is the 
> specifics of what is needed to *get* there in peoples opinion.

Agreed completely.

Some things I could see as needed:

1. applying updates on any file that is under CONFIG_PROTECT where the
md5/file-size matches that in /var/db for the file without user
interaction
2. automatic removal of files under CONFIG_PROTECT where the
md5/file-size matches that in /var/db during unmerge

> It's not an overnight thing, glep19 (stable portage tree) addresses a 
> chunk of concerns when/if it's implemented, but I'm a bit more 
> interested in the the other tools people desire alongside.

As am I.  The Installer is one such project.  We do not have any project
that I am aware of that is designed to resolve the problem of remotely
managing a server.  There is nothing for pushing config changes/package
updates/new packages.  There would need to be some interface for doing
these things.  Stop by any trade show, such as LWE, and you'll see guys
pushing their wares on remotely managing Linux.  We should provide
something like this ourselves.

eg. If I want to change the subnet mask or default router on 50 machines
on my network, I should be able to do so via a simple interface and have
the work done automatically.

> Re: a drop-in solution, considering that gentoo is effectively all 
> over the map (seriously, look at the tree), define the profile for the 
> drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.

I meant a drop-in management solution, not a specific set of server
profiles, though those could be created with the Installer.  In fact, I
see the Installer as one of the first pieces of the framework necessary
for deployment and management of a large number of servers.  Once the
netfe interface is completed with the Installer, you will be able to PXE
boot your server and have it load a specific installer profile, and it
will install Gentoo to those specifications.  Beyond that, we lose
control of the server and must manually perform all other actions.

> Specifics...
> 
> Hell, I have yet to see what I would define as a proper solution for 
> config manamagent for N gentoo boxes.  NFS solution possibly, but that 
> seems a bit hackish to me.

There isn't a proper solution yet.  Honestly, something like a
repository holding configuration information with revision control would
probably be best, so you can revert changes.  There are quite a few
systems like this out for Red Hat and others, but nothing that is
Gentoo-specific, or even Gentoo-capable, as far as I know.  We should
beat people to the punch and design one ourselves.

The main things we need to provide are:

Provisioning - building a server from bare metal to some pre-determined
state
Management - being able to make changes to existing servers without
manually logging into each to make the changes
Updates - this somewhat goes with management, but a facility for
disseminating patches or updated packages to servers

> Moot point frankly, considering we're all volunteers; someone 
> *could* get off their butts and start up an attempt to provide hand 
> holding (effectively what you're coloring the management arg as) 
> services, but even if they did, the followup arg would be that you 
> can't yet trust this new support company, because they're new.
> Etc.

Not entirely moot, as a company could be formed in cooperation with the
Foundation, as I stated earlier in the thread.  This symbiotic
relationship would give the new company a bit more credit, as it will be
supported by the Foundation.  This could be a Foundation-owned company,
or a completely separate entity.  Anyway, this isn't so much my point,
as many people *are* willing to forgo having a human voice on the end of
a phone.

> Basically, we don't have control over that portion, so... what 
> can be mangled that we *do* have control over, and has an effect?

Our tools.  Currently, we have very few "Gentoo tools" used for managing
a system.  We would need to define the requirements for these tools, and
then work on ways of getting them built.  It's like I said, I think the
primary weakness in Gentoo's enterprise adoption is the need for each
company to reinvent the wheel on their own deployment.  If we had a set
of extensible tools for managing Gentoo machines, then companies would
have a framework for building upon to meet their own needs.  Why does
everyone, for example, need to invent their own way of adding users to
their network?  Why can't we provide some method and allow them to
customize it and extend it?

> Mentioned management tools, well, get into specifics; pxe network 
> installs/imaging?  Single tree/cache for N servers?  Ability to push 
> updates out to a specific box, or set of servers?  Integration of 
> portage contents db with IDS tools?

PXE installs is on its way.  Being able to share the tree/caches would
definitely be of benefit.  I already discussed updates.  I hadn't even
considered the IDS integration, but that is an awesome idea.  How about
configuration file management?  Asset management?  Inventory database?
How about a "remote assistance" feature?  Since Gentoo is not only used
on servers, but could also be deployed on the workstation, we should
also provide tools for managing and supporting them, too.  What about
some form of policy enforcement?  Things like turning on Remote Desktop
Sharing in KDE/Gnome, so IT staff can assist users with issues.

> > Portage really has nothing to do with deployment or management.  In
> > fact, the only thing it really does is package management, which is
> > probably why it is called a package management tool, and not an
> > enterprise resource manager.
> 
> Any enterprise resource manager is going to have to fool with pkgs at 
> some point- that's my line of interest in this.

Correct.  I think my meaning was that we need to look at things
*besides* package management.  You guys seem to already have a good idea
of the things we need and I've seen progress towards making portage more
enterprise-friendly with some of the features planned for the future.

The main thing we need is a powerful portage API that allows complete
control of portage without using "emerge" at the command line.

> > Gentoo is currently unmaintainable at this scale without a significant
> > investment in infrastructure and development to make the system
> > manageable.  Think of it this way, if I can pay 4 developers to work on
> > this project for 6 months, and each developer makes $50,000 a year, or I
> > can pay Novell $100,000 and have the system in place in 2 weeks, which
> > do you think I would do?  This is the exact reason why Gentoo is not
> > used in the enterprise more.  There is simply too high a barrier of
> > entry into making a usable and manageable Gentoo deployment.

> Or, you find a collection of trained coder monkeys who are oddballs 
> who might have an interest in implementing this stuff on their own 
> time, and try to nudge them in the correct direction; no, this isn't a 
> solution, but again, having an ent. solution (going by your statement) 
> isn't going to be funded by anyone.

I meant this to mean $company pays developers to implement this for
themselves, whereas Novell/Red Hat have already paid for most of this
work on their own distributions.  The idea being that we are much more
likely to get enterprise adoption if we have some tools in place, even
if rudimentary in comparison, where currently we have nothing.

> Ok, fine.  So it goes.
> 
> Meanwhile, reiterating my point, I'd rather see a discussion of what 
> people *want* in the way of tools, then "we aren't there yet".  
> Generally known that you have to roll your own somewhat for tools, 
> well, would rather know what people want then see then another round 
> of kicking the dead horse.

Quite simply:

Some form of GUI (and console) tools capable of controlling every aspect
of any given set of Gentoo servers within an enterprise, from birth
until death.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Brian D. Harring]

[-- Attachment #1: Type: text/plain, Size: 8110 bytes --]

On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
> The only things I could see being needed out of portage itself is the
> ability to control "emerge" commands remotely, such as forcing an update
> of apache to $version to resolve a vulnerability.

The requirements of portage, or whatever component supplies 
(essentially) pkg management of remote boxes is going to be a bit more 
complex then just pushing emerge commands out; aside from config data, 
it'll probably centralize the vdb type contents somewhere, let alone 
avoiding N copies of the ebuild tree on each server.

Basically, whatever daemon is running clientside for all of this will 
have to support a good bit of handing off commands to portage, hence 
the interest (since from my point of view, it's a starting point).


> Some things I could see as needed:
> 
> 1. applying updates on any file that is under CONFIG_PROTECT where the
> md5/file-size matches that in /var/db for the file without user
> interactio

That would have to be determined prior to starting the update push.
I'd think basically a CONFIG_PROTECT limited scan of boxes to be 
updated, verifying things are in order according to the vdb (whether 
remote or local to that box) probably would fly.


> 2. automatic removal of files under CONFIG_PROTECT where the
> md5/file-size matches that in /var/db during unmerge

current vdb implementation relies on md5/file-size, future should rely 
on refcount, and be a good bit more configurable.


> > It's not an overnight thing, glep19 (stable portage tree) addresses a 
> > chunk of concerns when/if it's implemented, but I'm a bit more 
> > interested in the the other tools people desire alongside.
Offhand, responding to my own snippet, I'd love to know what's going 
on with glep19...

> 
> As am I.  The Installer is one such project.  We do not have any project
> that I am aware of that is designed to resolve the problem of remotely
> managing a server.  There is nothing for pushing config changes/package
> updates/new packages.  There would need to be some interface for doing
> these things.  Stop by any trade show, such as LWE, and you'll see guys
> pushing their wares on remotely managing Linux.  We should provide
> something like this ourselves.
> 
> eg. If I want to change the subnet mask or default router on 50 machines
> on my network, I should be able to do so via a simple interface and have
> the work done automatically.

Approach I've been thinking about (that fits semi-neatly exempting 
collision-protect) is essentially config pkgs, binding them on the fly 
to pkgs being pushed out.  Essentially, base apache pkg (that out of 
an ebuild tree), with it's depend tweaked automatically to pull in a 
matching configuration pkg.

Pushing out config updates wouldn't be too hard if handled in this 
manner, although generation of the config pkgs themselves would be a 
bit tricky.


> > Re: a drop-in solution, considering that gentoo is effectively all 
> > over the map (seriously, look at the tree), define the profile for the 
> > drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.
> 
> I meant a drop-in management solution, not a specific set of server
> profiles, though those could be created with the Installer.  In fact, I
> see the Installer as one of the first pieces of the framework necessary
> for deployment and management of a large number of servers.  Once the
> netfe interface is completed with the Installer, you will be able to PXE
> boot your server and have it load a specific installer profile, and it
> will install Gentoo to those specifications.  Beyond that, we lose
> control of the server and must manually perform all other actions.
Niete.

> > Specifics...
> > 
> > Hell, I have yet to see what I would define as a proper solution for 
> > config manamagent for N gentoo boxes.  NFS solution possibly, but that 
> > seems a bit hackish to me.
> 
> There isn't a proper solution yet.  Honestly, something like a
> repository holding configuration information with revision control would
> probably be best, so you can revert changes.  There are quite a few
> systems like this out for Red Hat and others, but nothing that is
> Gentoo-specific, or even Gentoo-capable, as far as I know.  We should
> beat people to the punch and design one ourselves.
> 
> The main things we need to provide are:
> 
> Provisioning - building a server from bare metal to some pre-determined
> state
Installer...

> Management - being able to make changes to existing servers without
> manually logging into each to make the changes
Domain class should provide for it
> Updates - this somewhat goes with management, but a facility for
> disseminating patches or updated packages to servers
Same as above


> Our tools.  Currently, we have very few "Gentoo tools" used for managing
> a system.  We would need to define the requirements for these tools, and
> then work on ways of getting them built.  It's like I said, I think the
> primary weakness in Gentoo's enterprise adoption is the need for each
> company to reinvent the wheel on their own deployment.  If we had a set
> of extensible tools for managing Gentoo machines, then companies would
> have a framework for building upon to meet their own needs.  Why does
> everyone, for example, need to invent their own way of adding users to
> their network?  Why can't we provide some method and allow them to
> customize it and extend it?
glep27 comes to mind re: users, although that's not management of 
samba users (fex).


> > Mentioned management tools, well, get into specifics; pxe network 
> > installs/imaging?  Single tree/cache for N servers?  Ability to push 
> > updates out to a specific box, or set of servers?  Integration of 
> > portage contents db with IDS tools?
> 
> PXE installs is on its way.  Being able to share the tree/caches would
> definitely be of benefit.  I already discussed updates.  I hadn't even
> considered the IDS integration, but that is an awesome idea.  How about
> configuration file management?

Configuration file management, as long as it's centralized, can be 
slightly bastardized as pkgs for pushing/updating.  If that's the 
case, it should be possible to avoid reinventing the wheel for 
handling it- hence the IDS comment.  Verification of config's prior to 
stomping them on an upgrade.

>  Asset management? Inventory database?
No good answer on that one, since it's outside the ken of what my area 
of interest (portage) :)
Offhand, I'd expect whatever method is used to push commands down via 
the domain class, probably can be extended to add these additional 
knobs.  It really depends on what you're trying to query though, 
cpuinfo/df, or license management...


> > > Portage really has nothing to do with deployment or management.  In
> > > fact, the only thing it really does is package management, which is
> > > probably why it is called a package management tool, and not an
> > > enterprise resource manager.
> > 
> > Any enterprise resource manager is going to have to fool with pkgs at 
> > some point- that's my line of interest in this.
> 
> Correct.  I think my meaning was that we need to look at things
> *besides* package management.  You guys seem to already have a good idea
> of the things we need and I've seen progress towards making portage more
> enterprise-friendly with some of the features planned for the future.
> 
> The main thing we need is a powerful portage API that allows complete
> control of portage without using "emerge" at the command line.

Heh, what, current api isn't usable? :)
Yeah, api is an area needing improvement.


> Some form of GUI (and console) tools capable of controlling every aspect
> of any given set of Gentoo servers within an enterprise, from birth
> until death.
Oh... just that.  'k. :)

re: the remote assist/control of a box, I'd wonder what could be 
handled via ldap (auth) and use flag...
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Sune Kloppenborg Jeppesen]

On Friday 05 August 2005 03:40, Brian D. Harring wrote:
> On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
 > It's not an overnight thing, glep19 (stable portage tree) addresses a
> > > chunk of concerns when/if it's implemented, but I'm a bit more
> > > interested in the the other tools people desire alongside.
>
> Offhand, responding to my own snippet, I'd love to know what's going
> on with glep19...
Not much lately I'm afraid:-/ If anyone is willing to help out I guess a mail 
to glep19@gentoo.org might get it all (re)started.

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: where goes Gentoo?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Fri, Aug 05, 2005 at 10:59:23AM +0200, Sune Kloppenborg Jeppesen wrote:
> On Friday 05 August 2005 03:40, Brian D. Harring wrote:
> > On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote:
>  > It's not an overnight thing, glep19 (stable portage tree) addresses a
> > > > chunk of concerns when/if it's implemented, but I'm a bit more
> > > > interested in the the other tools people desire alongside.
> >
> > Offhand, responding to my own snippet, I'd love to know what's going
> > on with glep19...
> Not much lately I'm afraid:-/ If anyone is willing to help out I guess a mail 
> to glep19@gentoo.org might get it all (re)started.
Might be better stating what's needed...
A) people know what they're inadvertantly getting themselves into
B) something might be bloody simple to somebody, and they pick it off 
   when they may not have been willing to take the time and poke and 
   find out what's up
C) alternatives might be proposed...

So... spill the beans. :P
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Sune Kloppenborg Jeppesen]

On Friday 05 August 2005 11:07, Brian Harring wrote:
> Might be better stating what's needed...
> A) people know what they're inadvertantly getting themselves into
http://dev.gentoo.org/~jaervosz/glep19.html

> B) something might be bloody simple to somebody, and they pick it off
>    when they may not have been willing to take the time and poke and
>    find out what's up
> C) alternatives might be proposed...
Of course, but lets see if we can implement something first, otherwise we'll 
continue arguing alternatives every ~6 months and never really do anything. 

Last time around we at least got a bit going, though admittedly not much.

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: where goes Gentoo?

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Sune Kloppenborg Jeppesen wrote:
> On Friday 05 August 2005 11:07, Brian Harring wrote:
> 
>>Might be better stating what's needed...
>>A) people know what they're inadvertantly getting themselves into
> 
> http://dev.gentoo.org/~jaervosz/glep19.html
> 
> 
>>B) something might be bloody simple to somebody, and they pick it off
>>   when they may not have been willing to take the time and poke and
>>   find out what's up
>>C) alternatives might be proposed...
> 
> Of course, but lets see if we can implement something first, otherwise we'll 
> continue arguing alternatives every ~6 months and never really do anything. 
> 
> Last time around we at least got a bit going, though admittedly not much.

Yeah, we started to get somewhere with it, but then some of us got
caught up in being busier in real life or other things popped up. But I
agree here that we just have to start with something and see where it
goes. Too many times have things been debated and nothing ever
done/tried. I also tend to agree with Chris that to do it completely
right would require a small fork that would work together with Gentoo on
archiving its goals.

It would be nice to come up with a solution without forking, but I just
don't see how it'd be possible and keep things as they should in an
enterprise realm. Things are starting to settle down for me again and I
would like to jumpstart this project again.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| eg. If I want to change the subnet mask or default router on 50 machines
| on my network, I should be able to do so via a simple interface and have
| the work done automatically.

That's why we added c3 and clusterssh to the tree. =)

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC8yhRXVaO67S1rtsRAlW4AKCEGoFMs6HqJCTv/wqqcp/xmaEH2QCfUjMB
yqD8ydpUcTkSTJ89NdZ3Pxk=
=38rv
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Fri, 2005-08-05 at 01:50 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> | eg. If I want to change the subnet mask or default router on 50 machines
> | on my network, I should be able to do so via a simple interface and have
> | the work done automatically.
> 
> That's why we added c3 and clusterssh to the tree. =)

Doing this over ssh leaves a lot to be desired.  For one, it requires
ssh keys to be distributed over the entirety of the network.  Second it
requires ssh keys for root without a passphrase, or via an agent, to be
always active.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Devdas Bhagat]

On 04/08/05 14:37 -0500, Brian D. Harring wrote:
<snip>
> Hell, I have yet to see what I would define as a proper solution for 
> config manamagent for N gentoo boxes.  NFS solution possibly, but that 
> seems a bit hackish to me.
> 
http://www.infrastructures.org/ is a good place to start.

Devdas Bhagat
-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Re: where goes Gentoo?

[Eric Brown]

I think Brian is right, we should stick to being constructive.

Let's start an enterprise project on Gentoo.org
	Goals:
	1) provide documentation on existing tools and practices for
business/enterprise users.
	2) try to enhance the set of tools to build a comprehensive
framework that makes it easy to use and deploy Gentoo in a
business/enterprise environment.
	3) provide information so that concerned parties can find
companies that specialize in Gentoo deployment/management/support.


Any ideas?


--Eric

-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Re: where goes Gentoo?

[Eric Brown]

Interesting thread.  I have used Gentoo in enterprise situations very
successfully, and I think the whole QA/live-tree argument is moot.  In
an enterprise environment, you might have a backup/testing machine to
run your updates on first before they went live.  You also wouldn't run
new packages unless they passed your own QA tests first.

Given the incredible flexibility of portage to support local mirrors,
binary package preparation, and localized versions of packages
(portdir_overlay), I would say that Gentoo is quite a contender in the
enterprise environment.

Perhaps we need some enterprise documentation to help people realize the
full potential of portage?


-Eric

-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 5202 bytes --]

On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote:
> 
> Interesting thread.  I have used Gentoo in enterprise situations very
> successfully, and I think the whole QA/live-tree argument is moot.  In
> an enterprise environment, you might have a backup/testing machine to
> run your updates on first before they went live.  You also wouldn't run
> new packages unless they passed your own QA tests first.
> 
> Given the incredible flexibility of portage to support local mirrors,
> binary package preparation, and localized versions of packages
> (portdir_overlay), I would say that Gentoo is quite a contender in the
> enterprise environment.
> 
> Perhaps we need some enterprise documentation to help people realize the
> full potential of portage?

I think you've missed some of the idea of "enterprise" support.  See,
for starters, every person shouldn't have to create their own
implementation of everything.  Perhaps a better solution would be a
package that when installed, builds up a local mirror, a binary package
repository (with revision control), an automated update system, a system
for updating rolled out machines without forcing the use of etc-update
on each machine, a slower moving stable tree capable of being certified
with applications, and most likely a phone number of someone to call
when the shit hits the fan.

While I will completely agree that Gentoo *can* be used in the
enterprise successfully, that does not make it "enterprise-ready", in
any sense.  Many people also seem to misunderstand the concept of
"enterprise" when we are referring to it in this manner.  We don't mean
"I'm running it on 10 servers in production" or anything like that.  We
mean "I'm running this as our production platform for Linux services
across our entire enterprise, that could be hundreds or even thousands
of servers" instead.  While it might be possible to maintain a handful
of Gentoo servers, it is next to impossible to maintain an army of them,
without spending significant up-front manpower to design, test, and
implement your own set of management tools.  Gentoo has no real
management tools.  There are a few here and there that do specific
tasks, but there isn't anything designed to really take control over
your network of systems.  To be fair, Red Hat doesn't have anything like
this, either.  Their "Satellite Server" product is good for initial
builds and for updates, but falls short on the management aspects.
Novell's offerings are probably the best examples of what we really
need.  Of course, most people would be happy with even rudimentary
management capabilities, as currently, we have none.  We don't have any
form of update server.  You have to build one yourself.  We don't have
any form of "jump-start" or "kickstart" for rapid automated deployments.
You have to build one yourself.  Now, we do have the Gentoo Linux
Installer project, which has this as one of its goals, so we will have
this component at some point in the future.

Last, there's the "Our servers just went belly up, and I want to call up
someone on the phone and give them a piece of my mind" issue which gives
managers a warm, fuzzy feeling, that we cannot provide.  If something
goes wrong with RHEL or SLES, you call up Red Hat or Novell and get them
to work on the problem.  If something goes wrong with Gentoo, you hop on
IRC, or file a bug, and hope that somebody can help you in the time you
need it done in, and not in 3 weeks when the maintaining developer gets
back from his tour of the African Dung Beetle in it's own environment.
Liability is a big selling point for the enterprise.

I work for a telecommunications company, and we run Linux and Solaris.
For our Linux, we run Red Hat, even though they have, on staff, one of
the people that understands Gentoo's deployment capabilities better than
most, via catalyst and the GLI.  Why do we run Red Hat?  When something
breaks with one of their packages, we call them, and expect them to fix
it.  It is also a name that gives upper management the warm fuzzies.
Gentoo has neither the brand recognition, nor the support capabilities
to be a good sale to management.

I'm not denying that Gentoo is very powerful, flexible, and gives the
power back to the administrator, but that doesn't make it enterprise
ready or friendly.  A few success stories from a few people isn't much
to support the position, when we are lacking in so many simple and
obvious ways.  Remember, if a manager can think of multiple ways to
knock down the use of Gentoo, like the ones I've given above, what are
you going to do to refute his claims?

I want to see Gentoo as an enterprise-capable distribution myself, but I
also understand that it is a long, hard road ahead of us, and there will
still be some things we simply cannot provide as a community
distribution, which was my reasoning behind the "fork".  There would
need to be an entity that is responsible, liable, if you will, when
something goes wrong, and that has the manpower and resources to fix it.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Philip Webb]

050804 Chris Gianelloni wrote:
-- long interesting account of life in the enterprise snipped --
> I want to see Gentoo as an enterprise-capable distribution myself,
> but I also understand that it is a long, hard road ahead of us
> and there will still be things we cannot provide as a community distro.
> There would need to be an entity responsible when something goes wrong
> and that has the manpower and resources to fix it.

There's no way a volunteer organisation like Gentoo could undertake that.
What would be essential is a company with capital invested
& probably an insurance policy somewhere in the background,
which employs Gentoo-knowledgeable staff to build & fix systems.
It would probably have its own mirror with a selection of Gentoo packages,
which it is prepared to guarantee as reliable & safe to use,
& would develop all the enterprise-level management tools you describe.
Hopefully, it would give something back to the underlying volunteer Gentoo
by way of free staff time & some tools all of us might benefit from.

The first step is a visit to your friendly neighbourhood bank manager (smile).

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] where goes Gentoo?

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 3322 bytes --]

This is kinda bloggish, because it's basically a transcription of an
IRC monologue.  My apologies if it's hard to follow...  Nonetheless,
I'm interested in how other developers feel on the topics I bring up
below.

There have been some really interesting points brought up recently
about "where is Gentoo going?"  I have been wondering that myself.
Some people seem to think that Gentoo has the potential to be an
enterprise player.  I have not responded directly to those people, but
I wonder if they know what they mean.  I have worked in the enterprise
UNIX market for 6 years.  My code is running in places like NASA
mission control, 9-1-1 call centers, and most of the telephone
carriers.  I've produced patches on weekends to close $800m deals.
I now work in hp's Open Source and Linux Organization, mostly on RHEL
and SLES, so I have a good idea of what it takes to be an enterprise
player.

In my humble opinion, Gentoo is missing too many points to be an
enterprise Linux.  We commit to a live tree.  We don't have true QA,
testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
We don't really have product lifecycles, since we don't generally
backport fixes to older versions, requiring instead for people to
update to a more recent release.  We don't have, and probably will
never be able to offer, support contracts.  We support as wide a range
of hardware as the upstream kernel, plus hardware that requires
external drivers; we don't have access to a great deal of the hardware
for which we provide drivers.  We understand when real life gets in
the way of bug-fixing, because all our developers are volunteers.

I think that attempting to take Gentoo in the "enterprise" direction
is a mistake.  I think that we are a hobbyist distribution.  This
doesn't mean that we should not strive to meet some of the enterprise
goals.  Those things can be important to hobbyists too.  But I don't
think we should be aiming for corporate America.

I don't even understand why that goal appeals to people.  Let other
distros go there!  I want Gentoo to run in people's homes, in student
dorm rooms, etc.  Places where people want a fun distribution that
they can tailor and work on easily.

I like the idea of Gentoo on alternative arches and in embedded
environments.  Not because I want Sony to start using Gentoo on
walkmans, but purely because the idea of running Linux on a PDA is
cool.  I'd like Gentoo to be a place where neat things are developed.
If RH or SuSE (or another for-profit Linux vendor) wants to take some
of those developments and use them to make a profit, that's fine with
me.  We're over here having fun.

Also I find it amusing when people say that Gentoo exists for the
users.  I think that is wrong.  Gentoo exists for the *developers*.
It's our playground, and it's the reason we use a live tree rather
than switching to an actually sane approach.  The users are cool
because they point out bugs, help solve problems on bugzilla, suggest
enhancements, provide patches, and notify us of package updates.
Sometimes they become developers.  But the truth is that Gentoo sees
improvement and maintenance in the areas that appeal to the
developers.  And that is why Gentoo exists for the developers first,
the users second.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: where goes Gentoo?

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 5115 bytes --]

> This is kinda bloggish, because it's basically a transcription of an
> IRC monologue.  My apologies if it's hard to follow...  Nonetheless,
> I'm interested in how other developers feel on the topics I bring up
> below.

Though i'm a developer, i'm not a gentoo-developer.

> In my humble opinion, Gentoo is missing too many points to be an
> enterprise Linux.  We commit to a live tree.  We don't have true QA,
> testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
> We don't really have product lifecycles, since we don't generally
> backport fixes to older versions, requiring instead for people to
> update to a more recent release.  We don't have, and probably will
> never be able to offer, support contracts.  We support as wide a range
> of hardware as the upstream kernel, plus hardware that requires
> external drivers; we don't have access to a great deal of the hardware
> for which we provide drivers.  We understand when real life gets in
> the way of bug-fixing, because all our developers are volunteers.

QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
versions, not in the stable x86 series. For example baselayout: there
are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
it's sufficient to only fix the most recent version. How do they
legitimate that?

And yes, Gentoo does not backport patches to older version. But is it
Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and
the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat
will backport the patches propably. They is a big reason why all the
distrubutions with precompiled packages do that:
- the updates has to be binary compatible with the old one

Gentoo doesn't suffer from that limitation. Gentoo offers ways to
migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other
distributions doesn't offer that - although they could with better
package managers.

Also i've had too many SuSE- or Redhat-systems in the past that were
unsupported because RedHat and SuSE decide, to stop supplying updates
for older version of their distribution. So what am i supposed to do in
that case? Updating the whole distribution causing me troubles to
migrate everything to the new version (apache2 instead of apache 1.3, etc.)

With Gentoo, this is usually done as time goes by - though you have to
be very careful sometimes.

Administrating a Gentoo system takes time - much time, but ...

... writing my own packages for - let's say Redhat - takes more time
than writing an ebuild for Gentoo. If you have to maintain a system with
very special software, i would recomm Gentoo.

> I like the idea of Gentoo on alternative arches and in embedded
> environments.  Not because I want Sony to start using Gentoo on
> walkmans, but purely because the idea of running Linux on a PDA is
> cool.  I'd like Gentoo to be a place where neat things are developed.
> If RH or SuSE (or another for-profit Linux vendor) wants to take some
> of those developments and use them to make a profit, that's fine with
> me.  We're over here having fun.

I like Gentoo, since everything is compiled - which offers much
flexibility, that precompiled packages don't offer.

Just some days ago, someone reinstalled a Server where we had PostGreSQL
8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 -
so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to
use our existing database. This will become hell the more packages you
have to compile on you own. Any configure-make-install-like package,
Perl-Module, etc... can be easy installed by using an ebuild.

In addition Gentoo is the only distribution i know, that supports
installing multiple Java-version etc...
A must-have for every real java-developer.

> Also I find it amusing when people say that Gentoo exists for the
> users.  I think that is wrong.  Gentoo exists for the *developers*.
> It's our playground, and it's the reason we use a live tree rather
> than switching to an actually sane approach.  The users are cool
> because they point out bugs, help solve problems on bugzilla, suggest
> enhancements, provide patches, and notify us of package updates.
> Sometimes they become developers.  But the truth is that Gentoo sees
> improvement and maintenance in the areas that appeal to the
> developers.  And that is why Gentoo exists for the developers first,
> the users second.

by using Gentoo, you learn much about Linux (the Kernel) and all the
nice little software that makes it a usable OS. Somewhere on the net,
there was page about Gentoo and Debian. The conslusion was, that Gentoo
is a great distribution to learn, and Debian is a stable work-horse.
Well, Debian is stable workhorse - as long as you don't have a very
special configuration. AFAIK, Debian doesn't drop support for their
distributions that fast - and they doen't release a new distribution
every few months (like SuSE does).

So i'd say: use Debian, if you have a relativly normal system to
maintain, use Gentoo if you have the time - and never ever use Redhat or
SuSE.


Thx
  Sven

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 6409 bytes --]

On Wed, 2005-08-03 at 13:55 +0200, Sven Köhler wrote:
> > In my humble opinion, Gentoo is missing too many points to be an
> > enterprise Linux.  We commit to a live tree.  We don't have true QA,
> > testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
> > We don't really have product lifecycles, since we don't generally
> > backport fixes to older versions, requiring instead for people to
> > update to a more recent release.  We don't have, and probably will
> > never be able to offer, support contracts.  We support as wide a range
> > of hardware as the upstream kernel, plus hardware that requires
> > external drivers; we don't have access to a great deal of the hardware
> > for which we provide drivers.  We understand when real life gets in
> > the way of bug-fixing, because all our developers are volunteers.
> 
> QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
> versions, not in the stable x86 series. For example baselayout: there
> are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
> it's sufficient to only fix the most recent version. How do they
> legitimate that?

This one is easy.  A stable package's ebuild should not change.  Period.
To "fix" the stable version, means that a new revision of the latest
stable version would need to be made, and that revision would need to be
tested, before it would go to stable.  The only real exception to this
is security bugs.  Also, in many cases, the bug in question requires
changes that are simply not feasible easily in the current stable
version, but quite easy in the latest version.  It really boils down to
this:  If you're having an issue with a package in Gentoo and it is
fixed in the latest ~arch version, then you should *use* the ~arch
version (remember, it doesn't mean "unstable" it means "testing") and
you should report back to the maintainers that this is working for you
so that they can get it moved into stable quicker.  We don't have the
staff or the time to backport every fix to every stable version.
Remember that in many cases the "latest stable" version varies between
architectures.

> And yes, Gentoo does not backport patches to older version. But is it
> Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and
> the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat
> will backport the patches propably. They is a big reason why all the
> distrubutions with precompiled packages do that:
> - the updates has to be binary compatible with the old one

I don't feel that this is our responsibility.  While we sometimes do
backport patches, we just don't have the manpower to make it policy.

> Gentoo doesn't suffer from that limitation. Gentoo offers ways to
> migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other
> distributions doesn't offer that - although they could with better
> package managers.

Right.

> Administrating a Gentoo system takes time - much time, but ...

This is something that I think most people forget.  Running Gentoo makes
you a Linux Systems Administrator.  Sure, you're only being the
administrator for your machine, which might only have one user, but
you're the admin.  With some of the other distributions, *they* are the
admin, and you're just a user.  They make assumptions for you and limit
what you can and cannot do (without an enormous amount of work to bypass
their limits).  This is especially apparent in the many cases where
users expect Gentoo to do everything for them, when it doesn't.

> ... writing my own packages for - let's say Redhat - takes more time
> than writing an ebuild for Gentoo. If you have to maintain a system with
> very special software, i would recomm Gentoo.

I would agree with you.  Professionally, I work on Red Hat.  I have to
build custom RPMs on a daily basis, and I can say that the simple syntax
of ebuilds is a tremendous advantage.

> Just some days ago, someone reinstalled a Server where we had PostGreSQL
> 8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 -
> so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to
> use our existing database. This will become hell the more packages you
> have to compile on you own. Any configure-make-install-like package,
> Perl-Module, etc... can be easy installed by using an ebuild.

You aren't "supposed" to compile packages on your own on Debian.  You're
supposed to make your own DEB package and install that.  Otherwise, you
are working outside the package manager.  This is no different than on
Gentoo, just for many people, an ebuild is easier to write than creating
a DEB/RPM.

> In addition Gentoo is the only distribution i know, that supports
> installing multiple Java-version etc...
> A must-have for every real java-developer.

Agreed.  This is also very true for proprietary applications that rely
on java.

> So i'd say: use Debian, if you have a relativly normal system to
> maintain, use Gentoo if you have the time - and never ever use Redhat or
> SuSE.

Gentoo tends to be more flexible with a smaller amount of work.  This
makes it an excellent development platform, which is another reason why
many people say that Gentoo is "for the developers" first.  I also think
that it is a wonderful end-user platform.  My girlfriend runs Gentoo and
loves it.  I started her off on Red Hat, and she found lots of little
things that bugged her, so I showed her Gentoo, and she was hooked,
since it was so easy for her to change those little peculiarities, not
to mention she knows a lot more about what it going on behind the scenes
then with those little redhat-config-* apps.

I personally hope that Gentoo never changes.  I'd like to see quality
improve, but that doesn't require any major changes to Gentoo itself.
As far as enterprise support, I think a fork is honestly the best
answer.  Not a fork that becomes completely independent, but a fork
focused on providing the enterprise features, like a slower release
cycle and backporting fixes, and rolling what it can back into Gentoo.
I think this sort of symbiotic relationship is really the only way to
successfully move Gentoo into the enterprise.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: where goes Gentoo?

[Duncan]

Chris Gianelloni posted <1123076347.31550.17.camel@cgianelloni.nuvox.net>,
excerpted below,  on Wed, 03 Aug 2005 09:39:07 -0400:

>> Administrating a Gentoo system takes time - much time, but ...
> 
> This is something that I think most people forget.  Running Gentoo makes
> you a Linux Systems Administrator.  Sure, you're only being the
> administrator for your machine, which might only have one user, but you're
> the admin.  With some of the other distributions, *they* are the admin,
> and you're just a user.  They make assumptions for you and limit what you
> can and cannot do (without an enormous amount of work to bypass their
> limits).  This is especially apparent in the many cases where users expect
> Gentoo to do everything for them, when it doesn't.

I've found myself emphasizing this same point a number of times.  There
are general system users that don't care /what/ they are on.  Those are
/just/ users.  However, by definition, /Gentoo/ user == sysadmin,
full-stop (period, for those USians not familiar with international
English, "full-stop" seems to me to convey the idea better).  You mention
the lack of limits, and Sven mentioned the time it takes, but my emphasis
tends to be on the responsibilities of the job.  A good sysadmin invests
the time and energy necessary to keep a healthy system, known vuln and
exploit free, but more than that, "clean" and simple, because (s)he
realizes the consequences of a failure to do so.  A good sysadmin knows a
fair amount about how their system works, in ordered to do that.  A good
sysadmin enjoys the job, or finds other work.

Gentoo makes being a good sysadmin easy.  However, by the same token,
because it assumes that admin is in place, it tends to make being an
ordinary "user" on an admin-less Gentoo system very difficult.  Those that
don't like being sysadmins, really should be looking at a distribution
that, as you said, really takes on much of the sysadmin duties as part of
the services provided by the distribution.   The best Gentoo user, then,
because being a Gentoo user by definition means being a sysadmin, truly
enjoys both the responsibilities and privileges of system administration. 
Again, if that's /not/ the case, one really should be reexamining their
choice of Gentoo, as it's really not the best fit distribution available
for those who'd really rather be doing something other than system
administration.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: where goes Gentoo?

[River Yan]

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

I think it's value is that gentoo is for the developers.
: )

-- 
Riverfor [A chinese, a gentoo user, a programmer]

[-- Attachment #2: Type: text/html, Size: 149 bytes --]

[gentoo-dev] Re: where goes Gentoo?

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

>>>In my humble opinion, Gentoo is missing too many points to be an
>>>enterprise Linux.  We commit to a live tree.  We don't have true QA,
>>>testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
>>>We don't really have product lifecycles, since we don't generally
>>>backport fixes to older versions, requiring instead for people to
>>>update to a more recent release.  We don't have, and probably will
>>>never be able to offer, support contracts.  We support as wide a range
>>>of hardware as the upstream kernel, plus hardware that requires
>>>external drivers; we don't have access to a great deal of the hardware
>>>for which we provide drivers.  We understand when real life gets in
>>>the way of bug-fixing, because all our developers are volunteers.
>>
>>QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
>>versions, not in the stable x86 series. For example baselayout: there
>>are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
>>it's sufficient to only fix the most recent version. How do they
>>legitimate that?
> 
> This one is easy.  A stable package's ebuild should not change.  Period.

I agree with you there - though sometimes, stable ebuilds are changed -
even without changing the version-number.

> To "fix" the stable version, means that a new revision of the latest
> stable version would need to be made, and that revision would need to be
> tested, before it would go to stable.  The only real exception to this
> is security bugs.  Also, in many cases, the bug in question requires
> changes that are simply not feasible easily in the current stable
> version, but quite easy in the latest version.  It really boils down to
> this:  If you're having an issue with a package in Gentoo and it is
> fixed in the latest ~arch version, then you should *use* the ~arch
> version (remember, it doesn't mean "unstable" it means "testing") and
> you should report back to the maintainers that this is working for you
> so that they can get it moved into stable quicker.  We don't have the
> staff or the time to backport every fix to every stable version.
> Remember that in many cases the "latest stable" version varies between
> architectures.

I chose baselayout for a particular reason. There is baselayout 1.9,
1.11 and 1.12. (i think there was 1.10 too - some time ago - perhaps)

I i reported bugs - as usual - but the bug was fixed for 1.11 or 1.12 (i
can't remeber, it was about a year ago). The problem: the fix was not
backported to 1.9 (which was stable at that time). Since baselayout is a
very important part of Gentoo, i didn't think that it would be a good
idea, to upgrade my x86-version 1.9 to a ~x86-version 1.11. So i would
have expected that such changes would go into a new 1.9-version which
could have become stable after some testing - but they didn't. So
patches the scripts manually - well, and easy task, although i had to
pay attention so they my changes weren't overwritten.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]