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 1HqGtL-0007Sd-4i for garchives@archives.gentoo.org; Mon, 21 May 2007 23:02:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l4LN1av7005848; Mon, 21 May 2007 23:01:36 GMT Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l4LMxVIR002081 for ; Mon, 21 May 2007 22:59:32 GMT Received: (qmail 86501 invoked from network); 21 May 2007 22:59:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=GuAluGa1qGUcpuXMp/kmIhzSX8L1VO/i43sOY9bpUv4QFGMrmeWSY9bE3LRsqbxMzfKcOxFpVZnPbFYwB2Gj4iCx39gWlUTVPYoSmQKHS795/ybfbr49hlTBL3VPl03lH9drVT8oyFamXREPc5Daj2ObzZVejV5g8g8qee2RTI0= ; Received: from unknown (HELO ?192.168.1.50?) (karlg@rogers.com@74.99.106.43 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 21 May 2007 22:59:30 -0000 X-YMail-OSG: 3jlsFk0VM1k85sOqrY0eWOpe2RUifzgNRR3M2w1OKhK9YmZ94_TFOKeYNFkdkzMSXg-- 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 (Apple Message framework v752.3) In-Reply-To: <4651C876.2@routedtechnologies.com> References: <4650937E.80301@spamcop.net> <4650BCC7.60909@vanalteren.nl> <246510DE-93FF-46CD-AF10-70C53C8442A7@rogers.com> <4651C876.2@routedtechnologies.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--382345425 Message-Id: From: Karl Holz Subject: Re: [gentoo-server] Best practices in managing large server groups Date: Mon, 21 May 2007 18:58:37 -0400 To: gentoo-server@lists.gentoo.org X-Mailer: Apple Mail (2.752.3) X-Archives-Salt: 8af82833-ac46-4993-b71d-56682b5e367a X-Archives-Hash: f7ae56502b5adad83d2828107398df20 --Apple-Mail-2--382345425 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sure, you'll have a Portage tree, but it will be in you build root. here is the way I would set it up the build root would be under /build, you could also share this over nfs too # cd build # tar jxvf ~/stage3*.tar.bz2 # cd usr # tar jxvf ~/portage-latest.tar.bz2 # cd /build -mounting all the needed directories, binding the root to /build/ chroot is only if you want to build packages into it. # for x in "/sys:/sys" "/dev:/dev/" "/:/chroot" > do > mount -o bind $(echo $x|cut -d':' -f1) /build/$(echo $x|cut -d':' -f2) > done # mount -t proc none /build/proc # cat /etc/resolv.conf > /build/etc/resolv.conf # chroot /build /bin/bash now you can set your profile, edit your /etc/mack.conf (chroot) # env-update; source /etc/profile (chroot) # ROOT="/chroot" emerge for updating you system image use (chroot) # ROOT="/chroot" emerge -uD you could use world, but it will install the things you may not want. you can update the world of the build root /build (chroot) # emerge --sync ; emerge world -uD This can all be scripted too, you just neet to make 2 scripts; one to start the job and one to work inside the chroot, just change # chroot /build /bin/bash to # chroot /build /start.sh __________________ Karl Gustav B. Holz ---------- karl@new-aeon.com ---------- http://www.new-aeon.com On 21-May-07, at 12:27 PM, Ryan Gibbons wrote: > I believe you will still need a tree either way. > > I would just have the master server share it's portage tree over > nfs, and then when you update the nodes of the cluster, just mount > the nfs share, run your emerge system or world or whatever, and > then when you are finished umount the nfs share. > > I imagine this could be done easily via scripts, complete with > error checking for bad mounts bad emerges etc. > > Ronan Mullally wrote: >> Hi Karl, >> >> On Mon, 21 May 2007, Karl Holz wrote: >> >> >>>> Is there a way to run gentoo without a portage tree on each box? >>>> >>> yes, if you setup a build system, using a stage3 tarball, and >>> build your >>> system into a directory. Portage will only be under your /usr/ >>> portage and not >>> into the system image you're building. the good thing about using >>> a Stage3 >>> tarball is you can build you system on any linux system, build >>> your system >>> image, tarball the image, deploy and install grub on x86, yaboot >>> on Mac PPC, >>> silo on Sparc64. >>> >> How are updates handled? "emerge -uD " isn't going to >> work >> without a portage tree, so I presume I'd need to tell each server >> which >> packages need to be updated with "emerge ... " >> to have >> it download them from the binhost? >> >> >> -Ronan >> --Apple-Mail-2--382345425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Sure, you'll have a Portage = tree, but it will be in you build root. here is the way I would set it = up

the build root = would be under /build, you could also share this over nfs = too

# cd = build
# tar jxvf ~/stage3*.tar.bz2
# cd = usr
# tar jxvf ~/portage-latest.tar.bz2
# cd = /build

-mounting all the needed = directories, binding the root to /build/chroot is only if you want to = build packages into it.

# for x in "/sys:/sys" = "/dev:/dev/" "/:/chroot"
> do
>=A0 mount -o = bind $(echo $x|cut -d':' -f1) /build/$(echo $x|cut -d':' = -f2)
> done
# mount -t proc none = /build/proc
# cat /etc/resolv.conf > = /build/etc/resolv.conf
# chroot /build /bin/bash

now you can set your = profile, edit your /etc/mack.conf

(chroot) # env-update; = source /etc/profile
(chroot) # ROOT=3D"/chroot" emerge = <pkg>

for= updating you system image use

(chroot) # ROOT=3D"/chroot" = emerge <pkg> -uD=A0

you could use world, but it = will install the things you may not want. you can update the world of = the build root /build

(chroot) # emerge --sync ; = emerge world -uD

This can all be scripted = too, you just neet to make 2 scripts; one to start the job and one to = work inside the chroot, just change=A0

# chroot /build = /bin/bash
=A0
to=A0

# chroot /build = /start.sh

karl@new-aeon.com
--------= --

=

On 21-May-07, at 12:27 PM, Ryan Gibbons = wrote:

I believe you will still need a tree = either way.

I would just have the master server share it's = portage tree over nfs, and then when you update the nodes of the = cluster, just mount the nfs share, run your emerge system or world or = whatever, and then when you are finished umount the nfs share.

= I imagine this could be done easily via scripts, complete with error = checking for bad mounts bad emerges etc.

Ronan Mullally = wrote:
Hi Karl,

On Mon, 21 May 2007, Karl Holz wrote:

  
=
Is there a way to run gentoo without a portage tree on =
each box?
      
yes, if  you setup a =
build system, using a stage3 tarball, and build your
system into a directory. Portage will only be under your /usr/portage =
and not
into the system image you're building. the good thing about using a =
Stage3
tarball is you can build you system on any linux system, build your =
system
image, tarball the image, deploy and install grub on x86, yaboot on Mac =
PPC,
silo on Sparc64.
    
How are updates handled?  =
"emerge -uD " isn't going to work
without a portage tree, so I presume I'd need to tell each server which
packages need to be updated with "emerge   ... " to =
have
it download them from the binhost?


-Ronan
  

= --Apple-Mail-2--382345425-- -- gentoo-server@gentoo.org mailing list