From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QOhzf-0000c9-BR for garchives@archives.gentoo.org; Tue, 24 May 2011 03:09:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0F5361C337 for ; Tue, 24 May 2011 03:09:14 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id E6B881C1E4 for ; Tue, 24 May 2011 02:45:10 +0000 (UTC) Received: by pwj5 with SMTP id 5so4284052pwj.40 for ; Mon, 23 May 2011 19:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=N/Xiu2y+OhGx/4qDqUEbYeIfUZeDEmahBzzYzTNN1/g=; b=adJ7JCESzBvBhNrLwD+Go+oGD9sff5uicGQuZj2BIpVAEJjRoG04lbHhRjIRVOxwV6 mlbwterFOy4P//lazfPB92qFqSO8ypPKL86TdnB+39A9StEMmd9FfQlt8douDeE+uhPY IbJgLnG1SFkue25XDFqmaJVQNAD5q46zfN13A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=qB53TpMVI+DAVaIEYNVdkjhDRbeUswA6Ui9/3VQRty58b69wO0HWDWu/0z1T0ttNuv KOdV4nayX/FIt6/FS31gkB7VaTMexgtxmsJuQEtLbP3fZIOlyrlEdkQeqrybUS8TPhmK fohOWYmwcVXLPdbBB9hKCH9cJ/ci+1gxmBwuQ= Received: by 10.142.213.20 with SMTP id l20mr943990wfg.203.1306205110137; Mon, 23 May 2011 19:45:10 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-server@lists.gentoo.org Reply-to: gentoo-server@lists.gentoo.org MIME-Version: 1.0 Received: by 10.142.58.6 with HTTP; Mon, 23 May 2011 19:44:50 -0700 (PDT) In-Reply-To: <4DDAFE82.9070308@badapple.net> References: <4DDAFE82.9070308@badapple.net> From: Fabiano - deStilaDo Date: Mon, 23 May 2011 23:44:50 -0300 Message-ID: Subject: Re: [gentoo-server] Managing multiple servers. To: gentoo-server@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: bde03e4bf9051d5af655371bd1999b14 Some more ideas: - Local copy dist files, two very easy ways to do without mirroring a huge official gentoo server: - Networked DISTDIR - First server on GENTOO_MIRRORS, like "http://10.0.0.2/gentoo" - This is interesting if you have a "master" gentoo server and other misc gentoos, for example I do this on my laptop, if I am on my local net it tries my local server first, the distfiles I want are usually there, if not, portage gets s 404 a tries the next server. The same happens when I am away from my local net. - Use you own binary packages: This saves some nice compile time, but the binary optimization has to be a common denominator for all the architectures in use, or have different binary repositories for different arches if they are "really" different (i.e. incompatible). For example, if you have intel and amd server you can optimize to i686. I like better this approach on more homogeneous setups, like everything optimized for say core 2. - Other consideration here is that when you use binary packages you fix the use flags for that packages, but gentoo handles this very nicely: when your use flags match the binary packages it uses the binary, if you flags are different it use binary for the packages that has the same flags and compiles only the packages that differs. I find this very good, as in my server more the 95% of packages usually don't need to be recompiled. - If you a have "master" gentoo server for bin packages, you can use distcc on it to have the packages build very fast (distributed grid compilation) and only one time, as the other servers then just download a bin copy and unpack/install. This "master" server or compiling server does not necessary need to have all the bin packages installed, as you can use --buildpkgonly. - Reduce upgrade downtime building binary packages before install and have a revert point: some services are safe to upgrade and restart after emerge of new versions are complete, but what if the new version does not start for some reason? And for service that you cannot upgrade while running, it is like this: service stop, emerge take some compile time =3D downtime, service start. Everyone knows that on a perfect world you should not be upgrading production servers directly, but test the upgrades on testing servers/environments and only then put the well tested stuff in production. But lets face it: just a few of us are able to do that in real world, we are usually overloaded/underpaid sysadmins, have time constrains, lack of man power, etc. So what is feasible to do being short on time/resources? - Here goes my favourite approach: - First backup every affected package with:quickpkg --include-config=3Dy - This makes it very easy to revert a unsuccessfully upgrade and usually is sufficient to revert, but special attention must me given to programs/services that uses files not save as config files (like databases for examples). - emerge with --buildpkgonly, this way a bin package is built but not installed, while the services are running. - now, the upgrade is much faster: service stop, emerge bin package =3D very fast tar unpack, service start. If service does not start, emerge very fast unpack time of previous binary backup version, service start. - this can be easy automated with shell scripts (or say, semi-automated, as the should ask for confirmation on critical operations) - Mail GLSA affected: it was mentioned on this list before to cron emerge update (or eix-sync). After every update I'd add glsa-check to e-mail me affected packages (security is never too much =3D) - Gentoo server "template": many like to have a stage4 to backup or replicate servers and customize. This is good to have cd/dvd copy in case of catastrophic raid/backup servers failure, but I enjoy other approach as well: I have a "template" root of a generic gentoo in one of my file servers, I find this very handy and flexible. How I use it: - Need new server: boot with gentoo minimal (or better sysresccd) - Partition it the way is more appropriate to that server (which is usually very different among all my servers), usually this is done on top of some raid. - Mount partitions, rsync the "tamplate" server to mounted partitions - Change unique configs, like hostname and ip - chroot, check if kernel config is appropriate for that machine, if not ajust and recompile - grub install - reboot Enjoy a new server up and running with most of the things already configured to you linking. I like this approach because I can change things directly on the "template" server which I think should apply to all new servers, and also I very easy regularly update it, just chroot and emerge world. - You can also use this approach to clone a running server, but then you need a few more tricks, specially to rsync special dirs, like /dev, temporaries, exclude ssh keys, etc. I can provides my details on how I do this if someone is interested. - Versioned configs: you can put config dirs (like /etc) under version control, like subversion or git. This makes it easy to track changes and do reverts if needed. In case of polytheistic environments (you are not the only god, there are other sysadmins) this is also a good way to track who changed what, why and when. So, and you guys, what are you gentoo-server tricks? Regards, Fabiano. On Mon, May 23, 2011 at 9:40 PM, kashani wrote: > On 5/23/2011 3:12 PM, la Bigmac wrote: >> >> Hello list, >> >> Seems to be a few people recently wanting to discuss Gentoo as a server >> :-) so thought I would pose a question that has been bugging me. >> >> What would you guys recommend to manage multiple servers and the package >> versions? >> >> While I have a central emerge server (*rsync)* and sync all of my >> servers to it I still manually update the packages. >> >> Example, openssh how should I be updating openssh on all of my servers >> other than logging onto each one in turn and running emerge openssh. >> >> Should I cron schedule an /emerge/ --/update world /and control the >> repository of packages or is there a more elegant solution? > > =A0 =A0 =A0 =A0I've become a huge Puppet nerd over the last year. I'm not= managing > Gentoo on it, but it's supported and Puppet Labs does seem to fix Gentoo > bugs in a reasonable time. > > First you'll need Ruby 1.8.7 as 1.9.2 support in Ruby isn't quite there y= et. > I'd also run unstable for Puppet and Facter. You're better off jumping in= at > 2.6.x than 0.25.x. > > Puppet requires facter which is very cool in it's own right. It's local > discovery of the OS and those facts about your system can be used in > templates to make decisions. Here's an example for setting higher thresho= lds > on my large machines. > > <% if processorcount.to_i >=3D 12 then -%> > > and here's an example of a module to make sure sudo is the latest version > and add a config file for my local sudoers additions. > > class sudo { > =A0package { "sudo": ensure =3D> latest, } > > =A0file { "/etc/sudoers.d/my_additions": > =A0 =A0ensure =A0=3D> present, > =A0 =A0owner =A0 =3D> root, group =3D> root, mode =3D> 440, > =A0 =A0require =3D> Package["sudo"], > =A0 =A0source =A0=3D> "puppet:///modules/sudo/my_additions", > =A0} > } > > =A0 =A0 =A0 =A0In order to make this work you'd really need to have modul= es for each > package in your world file and set ensure =3D> latest rather than just > present. However it does make it easy to keep configs, users, settings, > which packages in sync across machines. > > =A0 =A0 =A0 =A0That's Puppet in a very very tiny nutshell. They are some = unique > challenges with using it well with Gentoo, but it would ultimately make y= our > system easier to reproduce. > > kashani > >