From: Mark Hobley on
Ian Rawlings <news06(a)tarcus.org.uk> wrote:

> Mind you gentoo doesn't really go through releases, so I personally
> have two filesystems representing a basic non-X and a basic gnome
> gentoo install, and just copy them across the network to a new machine
> and up it comes.

That is interesting. I am looking at a similar sort of setup here, again
with a non-X setup and a separate X setup for workstations.

I am very interested to hear how you maintain this. Gentoo is extremely
rapidly evolving.

How do you look after this?

Do you have a third filesystem which is syncronized with the Gentoo repository
and then transfer packages manually your two filesystems?

Are your servers also Gentoo?

How do you test?

What do you do if one of the updates screws up?

Do you just copy the other way? Do you roll out updates to machines at
different times?

How do you look after local modifications?

Do you install any packages that are not in Gentoo?

My servers are currently Debian based, but I have a Gentoo machine on
test.

I like the ability to build from source, and I will probably be customizing
some of the packages.

It is going to be a gradual switch over process here.

I will intially keep my servers on Debian, and slowly switch the
workstations over.

I need to keep the updates and repositories under tight control. Gentoo
is a frighteningly fast flowing river.

The other problem that I have is that many of my packages are built
outside of Gentoo.

I haven't got into editing Gentoo packages yet. It is a pity, you can't
just unpack the files, edit the source, and package the files back up
again.

At the moment, I find that if I want to edit a package, I uninstall it
from Gentoo, then flag it up as manually installed, and do a manual
installation using my modified source code.

I could do with some sort of priority system on the repositories:

Take from repository of modified packages if available
If not, take from locally maintained repository
As a last resort, take the packages from out of the fast flowing river.

It is very early days for this, but hopefully I will eventually be in a
position to make a full switchover.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Ian Rawlings on
On 2008-11-26, Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote:

> That is interesting. I am looking at a similar sort of setup here, again
> with a non-X setup and a separate X setup for workstations.
>
> I am very interested to hear how you maintain this. Gentoo is extremely
> rapidly evolving.

Well, sorry to disappoint, but I'm afraid I "fudge". I have a few
main machines, and these tend to get updated fully on an irregular
basis, and if I want to build a basic machine I tend to rsync the
basic build from the filestore across, get it working reasonably well,
update it, then rsync the changes back across to the filestore, so the
filestore copy just ends up being a backup of the last machine that I
built at the time I built it.

I'm moving towards making my backups network bootable, but I'm already
in the situation where it's pretty easy for me to get a machine going
from cold metal to a fully functioning desktop from backups, and that
was much of the aim, use backups to build machines and then when you
need a panic restore, it'll be easy. I just fire up a live distro,
usually gentoo's install CDs, and rsync across.

> Do you have a third filesystem which is syncronized with the Gentoo repository
> and then transfer packages manually your two filesystems?

No, but I do have a local gentoo rsync repository so I don't beat up
the gentoo servers with regular rsyncs from all my internal machines.
I used to have a central distfiles repository too but it fell into
disuse, must resurrect that.

As for packages, much of the point of using gentoo is that each
package is tailored for the machine that it's going into, and as I
have a small network of non-similar machines, I don't have binary
packages stored anywhere, each machine builds its own. I could start
up a distributed build system which gentoo supports but I'm never in
enough of a hurry to worry about build times.

> Are your servers also Gentoo?

All my machines are gentoo, even my vmware images, other than the
occasional windows one.

> What do you do if one of the updates screws up?

Fix it! You do get it happening from time to time, normally it's a
case of a dependency being missed out, or a machine needing an emerge
sync to be run, however it's quite impressive to see a large update of
200 packages sit there overnight compiling away and you come back the
next day and it's finished. Build errors are fairly rare, the most
common gotcha is package blocks, that can cause issues if you're not
careful, but normally it's just a case of unmerging the blocking
package.

> Do you install any packages that are not in Gentoo?

Almost never, installing packages outside of packaging systems can be
a right royal PITA unless you hide the package away in
/usr/local/<package> or similar, and I've rarely come across a
substantial programme that I've needed that isn't already in the
package system. There's a fair few small utilities, mostly hacking
tools, that I install locally in my user's home dir.

> I need to keep the updates and repositories under tight control. Gentoo
> is a frighteningly fast flowing river.

It's not too hard to keep up, on some of my machines I update only
when required, and only those packages that I really need to update.
Every now and again a profile will become deprecated, then when that
happens I usually do a full update on that machine. For example my
firewall box is a fairly weedy machine, so I only update the bits that
talk to the outside world (openvpn and ssh basically), everything else
just stays on old versions. Recently I wanted to install unison, and
that needed to be the latest version, so a quick emerge sync and
emerge -p unison showed me it would pull in 4 packages, this despite
the machine not having had a full update in about 2 years.

> The other problem that I have is that many of my packages are built
> outside of Gentoo.
>
> I haven't got into editing Gentoo packages yet. It is a pity, you can't
> just unpack the files, edit the source, and package the files back up
> again.

Have a look at the ebuild executable, this is used by emerge to build
and install the packages, so when I need to twiddle some source, I use
ebuild to unpack the source to where it wants it to go, then I leap
into the directory and fiddle about, use ebuild to configure the
package, then do some more fiddling if required, then use ebuild to
compile and install the package. Then I mask the package version in
/etc/portage/package.mask so it never updates it until I'm ready to do
it myself. No need to actually learn the package system that way,
I've never bothered. Do a man ebuild and you can see the stages that
it goes through and the points at which you're likely to want to do
the fiddling.

> Take from repository of modified packages if available
> If not, take from locally maintained repository
> As a last resort, take the packages from out of the fast flowing river.

I think this is available, and is known as the overlay system, I've
never looked into it myself though. I believe that you can use it to
create your own patches to packages and this prevents an emerge sync
from overwriting your changes.

Go to www.gentoo.org and ferret around in the documentation area, it's
very useful. The forums are good too although the search engine is a
bit pants.

--
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/
From: Mark Hobley on
Ian Rawlings <news06(a)tarcus.org.uk> wrote:

> As for packages, much of the point of using gentoo is that each
> package is tailored for the machine that it's going into, and as I
> have a small network of non-similar machines, I don't have binary
> packages stored anywhere, each machine builds its own.

Ahhh right. I share binaries across machines here, so I try to keep
machines compatible with each other.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/