From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HpqDr-0004GR-Mu for garchives@archives.gentoo.org; Sun, 20 May 2007 18:33:40 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l4KIWoCh031975; Sun, 20 May 2007 18:32:50 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l4KITXix027277 for ; Sun, 20 May 2007 18:29:34 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1FC7D64FA6 for ; Sun, 20 May 2007 18:29:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 2.083 X-Spam-Level: ** X-Spam-Status: No, score=2.083 required=5.5 tests=[AWL=0.087, DNS_FROM_RFC_ABUSE=0.479, DNS_FROM_RFC_POST=1.44, TW_SV=0.077] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86lZe7qqxVgl for ; Sun, 20 May 2007 18:29:31 +0000 (UTC) Received: from isgenesis.com (smtp1.isgenesis.com [168.215.170.6]) by smtp.gentoo.org (Postfix) with ESMTP id 72A4264E0B for ; Sun, 20 May 2007 18:29:31 +0000 (UTC) Received: from [168.215.170.1] (HELO [10.222.0.214]) by isgenesis.com (CommuniGate Pro SMTP 5.1.5) with ESMTPS id 2559515 for gentoo-server@gentoo.org; Sun, 20 May 2007 13:29:30 -0500 Message-ID: <4650937E.80301@spamcop.net> Date: Sun, 20 May 2007 13:29:18 -0500 From: Charles Duffy User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-server@gentoo.org Reply-to: gentoo-server@lists.gentoo.org MIME-Version: 1.0 To: gentoo-server@lists.gentoo.org Subject: [gentoo-server] Best practices in managing large server groups Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: f4295057-08ad-4d7a-80ac-f60133387734 X-Archives-Hash: 9d8ac060d0ac3bf6d5790b1d3492f364 [Apologies if this is a duplicate post; I tried posting this through GMANE yesterday without subscribing first, and it appears not to have gone through; likewise when I posted several hours ago today from a different address than the one I subscribed]. All, I'm looking at replacing SuSE SLES9 with Gentoo for an enterprise application (for reasons of flexibility and licensing) (no, we don't have an enterprise application budget -- just the reliability requirements; yaaay, startups!). We're looking to be able to deploy and manage hundreds of geographically distributed servers. We have a QA department available to vet each configuration before it is deployed to the field. We have infrastructure for tracking the progress of code in svn from creation though QA to deployment; I'm anticipating tracking a local overlay (containing all packages we use), make.conf, /etc/portage/*, etc. through this system, autobuilding system images (either to run virtualized or on real hardware) from the contents of svn, building binary packages and deploying them to real hardware. I'm interested in best practices, suggested tools, and/or 3rd party experiences in this regard. Some particular questions which come to mind: - Should I be using a custom profile or a standard profile with overrides through make.conf, /etc/portage/* and the like? - What's the Right Way to create new system images ready to be loaded onto a hard drive or run through a virtual machine? gentoo-buildhoster looks interesting. I've seen Catalyst mentioned as a way to create stage3 images, but what documentation I've been able to find doesn't seem very much targeted for my use cases. - Any experiences with puppet? With out ratio of servers to staff, automating configuration and administration is a priority. (We already have an internal tool written with automating the server configuration process in mind; it has some functionality puppet doesn't, and puppet has functionality it doesn't; in theory, I'd like to extend puppet until our internal tool becomes unnecessary, though I'll need to understand puppet much better before I can think too hard about that). - Have any of 'yall been in the 100s-of-servers situation with comparable requirements and come up with a different approach to managing it? How did things work out? Thank you! -- gentoo-server@gentoo.org mailing list