Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
List Archive: gentoo-cluster
On 2/14/07, Ramon van Alteren <ramon@...> wrote:
> Daniel van Ham Colchete wrote:
> > Here on my company we are going to start deploying Gentoo Linux on our
> > customers. Every server will have the very same installed packages,
> > the very same use flags, very same cflags, only a few configurations
> > will differ.
> Good plan...
>
> > I would like the deployment and maintenance to be done as easily as
> > possible because this project needs to be scalable to more than 100
> > servers. Although we are going to install only 10 servers in the
> > beginning, my boss says that I should be prepared for this number to
> > grow.
> >
> >
> > Setting the project aside, I'm thinking about developing my own
> > installer to install a catalyst's stage4 and reboot a working Gentoo.
> > After that I'm thinking about using emerge with binary packages to
> > install updates automatically. What do you think? Will it work? Is it
> > possible to rollback an update if something goes wrong?
> >
> > To solve the problem with incompatible configuration files, everytime
> > I upgrade anything, a perl script will reconfigure the customers
> > server.
> We use quickstart + pxe + catalyst stage4 to do the installing.
> http://agaffney.org/quickstart/
> http://www.gentoo.org/proj/en/releng/catalyst/
I liked this quickstart thing. I'll have a look at it. In the end I
need to have a nicer installer because some customers I'll install the
server for themselves (like at a thousand miles away) and I just
manage it. So the installation shouldn't request any interaction with
the user. If quickstart do the job of course I'll use it, for now I'm
thinking about writing one in PyGTK (the same as Anaconda).
> But that's only half the problem...
> After the install you have a server which needs to be maintained,
> configurations need to change because the customer wants different
> things, etc. etc.
> For that we're working on deploying puppet in our serverpark:
> http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction
> This is a tool that will manage configurations, users, mounts and what not.
>
> That would be a lot better then writing a perl-script, and offers you a
> lot more flexibility.
> In fact one of the stated goals of puppet by it's creator L. Kanies is
> to make it possible for sysadmins to start sharing
> system recipes among each other which solve problems, instead of every
> one inventing their own wheel.
>
> There are ebuilds for puppet in bugzie here:
> http://bugs.gentoo.org/show_bug.cgi?id=146712
> And there's a fairly active and friendly community on #puppet as well.
Nice! I'll study it.
> WRT binary packages, check out the tinderbox target in catalyst.
> That way you can at least ensure that what you want will build against a
> certain target, and if you enable package-cache in catalyst you already
> have a buildserver :-)
That's my idea my catalyst. It seems that a lot of people is running
through same path, what is good coz it's nice to know it will work :)!
--
gentoo-cluster@g.o mailing list
|
|