Mailing List Archive

On Mon, 2004-09-20 at 21:24 -0700, Grant wrote:
> I've been very concerned with the possibility of an 'emerge -uD world'
> breaking any of my systems, but especially my server.

If that is so, then simply do not ever use `emerge world`

After all, assuming the ebuild is well written (they usually are) and
the dependencies are correct (they usually are too), then `emerge foo`
will result in an upgrade to libfoo, bar, and whatever else **if and
only if an update to those libraries is required by explicitly specified
dependencies**

The hidden benefit here is that rather than upgrading everything, all
the time, you only upgrade that which you need, AND YOU DON'T EXPOSE
YOURSELF TO HUNDREDS OF OTHER UNRELATED CHANGES.

Which is neat. This way, you only take a risk on specific software
you're upgrading, not the entire operating system. So if something is
borked, say, in this week's glibc, well, guess what? If you didn't
upgrade it, who cares? By tomorrow, it'll probably be fixed, but either
way it has no impact on you, so you probably won't even notice.

emerge -uD world == Debian Unstable.

Not doing emerge on a daily basis, results, in my experience in an
incredibly stable and low maintenance overhead system.

> The server
> just can't break.

Actually, that's a slightly more demanding standard than this mailing
list generally talks about - that's more about effective large
installation deployment, configuration management, high availability,
and roll out testing techniques. There's no such thing as a server that
will never break, so you need to engineer the problem at different
levels.

If this sounds interesting but you have no idea what I'm talking about,
you might start by reading http://www.infrastructures.org/ and the
collected proceedings of past LISA conferences at
http://www.usenix.org/events/bytopic/lisa.html . There have also been a
number of GLEPs of late attempting to push the things necessary to
enable Gentoo to be feasibly used in high consequence environments, see
http://www.gentoo.org/proj/en/glep/glep-0019.html and the mad debates on
gentoo-dev and elsewhere, eg
http://thread.gmane.org/gmane.linux.gentoo.devel/20270 . And, popping up
the stack slightly, you might be interested in a paper I wrote about
operations professionalism in systems environments,
http://www.operationaldynamics.com/reference/talks/SurvivingChange/

AfC
Sydney


--
Andrew Frederick Cowie
Operational Dynamics Consulting Pty Ltd

Stand up and be counted!

Register your Linux computers at http://counter.li.org/

On Tue, 21 Sep 2004 15:01:11 +1000, Andrew Cowie
<andrew@operationaldynamics.com> wrote:
> On Mon, 2004-09-20 at 21:24 -0700, Grant wrote:
> > I've been very concerned with the possibility of an 'emerge -uD world'
> > breaking any of my systems, but especially my server.
>
> If that is so, then simply do not ever use `emerge world`

But don't I need to stay on top of updates to all packages I have
installed to eliminate bugs and security holes?

>
> After all, assuming the ebuild is well written (they usually are) and
> the dependencies are correct (they usually are too), then `emerge foo`
> will result in an upgrade to libfoo, bar, and whatever else **if and
> only if an update to those libraries is required by explicitly specified
> dependencies**
>
> The hidden benefit here is that rather than upgrading everything, all
> the time, you only upgrade that which you need, AND YOU DON'T EXPOSE
> YOURSELF TO HUNDREDS OF OTHER UNRELATED CHANGES.
>
> Which is neat. This way, you only take a risk on specific software
> you're upgrading, not the entire operating system. So if something is
> borked, say, in this week's glibc, well, guess what? If you didn't
> upgrade it, who cares? By tomorrow, it'll probably be fixed, but either
> way it has no impact on you, so you probably won't even notice.
>
> emerge -uD world == Debian Unstable.
>
> Not doing emerge on a daily basis, results, in my experience in an
> incredibly stable and low maintenance overhead system.
>
> > The server
> > just can't break.
>
> Actually, that's a slightly more demanding standard than this mailing
> list generally talks about - that's more about effective large
> installation deployment, configuration management, high availability,
> and roll out testing techniques. There's no such thing as a server that
> will never break, so you need to engineer the problem at different
> levels.
>
> If this sounds interesting but you have no idea what I'm talking about,
> you might start by reading http://www.infrastructures.org/ and the
> collected proceedings of past LISA conferences at
> http://www.usenix.org/events/bytopic/lisa.html . There have also been a
> number of GLEPs of late attempting to push the things necessary to
> enable Gentoo to be feasibly used in high consequence environments, see
> http://www.gentoo.org/proj/en/glep/glep-0019.html and the mad debates on
> gentoo-dev and elsewhere, eg
> http://thread.gmane.org/gmane.linux.gentoo.devel/20270 . And, popping up
> the stack slightly, you might be interested in a paper I wrote about
> operations professionalism in systems environments,
> http://www.operationaldynamics.com/reference/talks/SurvivingChange/
>
> AfC
> Sydney

I think running UML for testing would get the job done for me, and
that sounds easier than the stuff above.

- Grant

--
gentoo-user@gentoo.org mailing list

Hi,
On вт, 2004-09-21 at 08:19, Grant wrote:
> On Tue, 21 Sep 2004 15:01:11 +1000, Andrew Cowie
> <andrew@operationaldynamics.com> wrote:
> > On Mon, 2004-09-20 at 21:24 -0700, Grant wrote:
> > > I've been very concerned with the possibility of an 'emerge -uD world'
> > > breaking any of my systems, but especially my server.
> >
> > If that is so, then simply do not ever use `emerge world`
>
> But don't I need to stay on top of updates to all packages I have
> installed to eliminate bugs and security holes?
>
Use glsa-check for keeping updated with security issues. That's its
purpose i think.
Ex. #glsa-check -l | grep N] - to get packages which are vuln.
> >
> > After all, assuming the ebuild is well written (they usually are) and
> > the dependencies are correct (they usually are too), then `emerge foo`
> > will result in an upgrade to libfoo, bar, and whatever else **if and
> > only if an update to those libraries is required by explicitly specified
> > dependencies**
> >
SKIP
> > AfC
> > Sydney
>
> I think running UML for testing would get the job done for me, and
> that sounds easier than the stuff above.
>
> - Grant
>
Haven't tried it but it seems fit.
PS: wonder what the devs use to test things. UML, chroot, separate test
install, other?
> --
> gentoo-user@gentoo.org mailing list
>
HTH
Rumen

Grant wrote:

> But don't I need to stay on top of updates to all packages I have
> installed to eliminate bugs and security holes?

I have several servers running Gentoo, currently, and one of them should
*never* go down, and another can't go down "during the day". The one
that can't go down during the day, *needs* to be up to date with
security, but it has to be stable as there are 24 users on the system
during the day.

I will sometimes do an emerge world, note the packages that it wants to
update, and do them individually - checking that they succeeded after
each emerge (settings, behaviors).

My biggest headache right now is Thunderbird 0.8. Because of some
security issues, I upgraded, and now t-bird is a bit unstable. While
bugzilla and the forums offer some suggestions, it's still a bit wacky.
I hope 0.8.1 comes out to fix some of the issues :) If this just
affected me, I wouldn't worry too much about it. However, this affects
24 other people - so it's a headache.

> I think running UML for testing would get the job done for me, and
> that sounds easier than the stuff above.

UML would be the best, however sometimes errors creep up on production
systems that you won't see on test systems. I always keep the binary
(using quickpkg) packages before an update - in case I need to roll back
the changes.

--
gentoo-user@gentoo.org mailing list

> Use glsa-check for keeping updated with security issues. That's its
> purpose i think.
> Ex. #glsa-check -l | grep N] - to get packages which are vuln.
> > >

That sounds like it could really keep updates to a minimum. I've been
over this:

http://www.gentoo.org/proj/en/portage/glsa-integration.xml

but it's very brief. Issuing 'glsa-check -l' seems to show me all of
the current issues. Is there a way to only see the ones that affect
my system? Is that functionality not ready yet?

> > > After all, assuming the ebuild is well written (they usually are) and
> > > the dependencies are correct (they usually are too), then `emerge foo`
> > > will result in an upgrade to libfoo, bar, and whatever else **if and
> > > only if an update to those libraries is required by explicitly specified
> > > dependencies**
> > >
> SKIP
> > > AfC
> > > Sydney
> >
> > I think running UML for testing would get the job done for me, and
> > that sounds easier than the stuff above.
> >
> > - Grant
> >
> Haven't tried it but it seems fit.
> PS: wonder what the devs use to test things. UML, chroot, separate test
> install, other?

Are you suggesting there is a way to use chroot without UML for this
kind of testing?

- Grant

--
gentoo-user@gentoo.org mailing list

> UML would be the best, however sometimes errors creep up on production
> systems that you won't see on test systems. I always keep the binary
> (using quickpkg) packages before an update - in case I need to roll back
> the changes.

Hmmm, trying to decide on a good plan for all of this. I'm in charge
of my personal workstation, my parents' workstation, my business
workstation, my audio server, and my web server. My personal
workstation will always be local, my web server will always be remote,
and the rest could be either way at any given time. These are all
Gentoo machines except the audio server which will be a Gentoo machine
as soon as I set it up.

I suppose I could arm myself with glsa-check and UML on every system
and just decide on a case-by-case basis what needs to happen as far as
updates and testing.

Here's a problem though. It looks like the guest/virtual OS in a UML
setup needs to be on usermode-sources, but my host OS will always be
on hardened-sources. Will my guest OS benefit from the hardening of
the host OS's kernel? If not I guess I'll have to deal with a
relatively exposed guest OS on each of my systems? This wouldn't be
ideal for QA either.

- Grant

--
gentoo-user@gentoo.org mailing list

Hi,
On ср, 2004-09-22 at 08:32, Grant wrote:
> > Use glsa-check for keeping updated with security issues. That's its
> > purpose i think.
> > Ex. #glsa-check -l | grep N] - to get packages which are vuln.
> > > >
>
> That sounds like it could really keep updates to a minimum. I've been
> over this:
>
> http://www.gentoo.org/proj/en/portage/glsa-integration.xml
>
> but it's very brief. Issuing 'glsa-check -l' seems to show me all of
> the current issues. Is there a way to only see the ones that affect
> my system? Is that functionality not ready yet?
>
See above. '#glsa-check -l | grep N]' will show you only the vuln.
packages.
you could also run glsa-check -t GLSA-NUMBER ... to test for these
specific GLSAs.
To automate things try:'#glsa-check -f GLSA-NUMBER ...' (see glsa-check
--help)
IMO sometimes there are vuln. packages shown which i already have
installed, so i inject this GLSAs so they don't bother (mistake) me
again.
> > > > After all, assuming the ebuild is well written (they usually are) and
> > > > the dependencies are correct (they usually are too), then `emerge foo`
> > > > will result in an upgrade to libfoo, bar, and whatever else **if and
> > > > only if an update to those libraries is required by explicitly specified
> > > > dependencies**
> > > >
> > SKIP
> > > > AfC
> > > > Sydney
> > >
> > > I think running UML for testing would get the job done for me, and
> > > that sounds easier than the stuff above.
> > >
> > > - Grant
> > >
> > Haven't tried it but it seems fit.
> > PS: wonder what the devs use to test things. UML, chroot, separate test
> > install, other?
>
> Are you suggesting there is a way to use chroot without UML for this
> kind of testing?
>
> - Grant
>
> --
> gentoo-user@gentoo.org mailing list
>
Not sure but think about the Gentoo install process - you chroot and run
(make) new system inside the other one.
HTH
Rumen

On Thu, 2004-23-09 at 13:21 +0200, Heinrich Rebehn wrote:
> Andrew Cowie wrote:
> > emerge -uD world == Debian Unstable.
>

The Debian unstable experience is "installing the newest version of
every single package whenever you do an update". The trouble is that
you're exposed to bugs that appear (temporarily) on the leading edge.

So what I was getting at was more advising that you avoid replicating
this experience on your Gentoo system.

Instead of upgrading everything (and worse, upgrading everything on a
daily basis via a cron job)*, instead just upgrade things when you need
to, and thus reduce your exposure to bugs in packages which are
secondary to your current [upgrade] requirements.

> Hmm, i thought this would result in == Debian stable and
>
> ACCEPT_KEYWORDS=~x86 emerge -uD world
>
> would result in == Debian unstable ?

Ok, you're right. Certainly, choosing to track ~arch is bringing you
closer to those risks. Personally, I bring in ~arch packages all the
time, but only when I am confident that I have the bandwidth to watch
for problems, debug them if they occur, and report back to
Gentoo/Upstream if they do.

But its the emerge-world-in-a-cron-job thing, regardless of arch or
~arch, which I suggest is asking for trouble.

YMMV.

AfC
Sydney

--
Andrew Frederick Cowie

OPERATIONAL DYNAMICS
Operations Consultants and Infrastructure Engineers

http://www.operationaldynamics.com/

On Thu, 23 Sep 2004 19:59:23 +1000
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> The Debian unstable experience is "installing the newest version of
> every single package whenever you do an update". The trouble is that
> you're exposed to bugs that appear (temporarily) on the leading edge.
>

Or, not to troll, to watch your packages being deinstalled while they are pending to be included in the unstable...

> Ok, you're right. Certainly, choosing to track ~arch is bringing you
> closer to those risks. Personally, I bring in ~arch packages all the
> time, but only when I am confident that I have the bandwidth to watch
> for problems, debug them if they occur, and report back to
> Gentoo/Upstream if they do.

For my part, I work daily on a ~amd64 system which is quite stable, and I never had any kind of *real* problem on a ~arch install, but those of compilation/broken dependencies/ebuild problems.
And I won't complain if someday my up-to-date addiction leads me to something buggy : I did it by myself.

But I quite agree with you : work on a emerge-world-cron basis isn't really a good idea, particularly for a production server (but that's logical).

(First post to gentoo-user, hello everybody.)

--
Julien Cassignol

--
gentoo-user@gentoo.org mailing list

Andrew Cowie wrote:
> On Mon, 2004-09-20 at 21:24 -0700, Grant wrote:
>
>>I've been very concerned with the possibility of an 'emerge -uD world'
>>breaking any of my systems, but especially my server.
>
>
> If that is so, then simply do not ever use `emerge world`
>
> After all, assuming the ebuild is well written (they usually are) and
> the dependencies are correct (they usually are too), then `emerge foo`
> will result in an upgrade to libfoo, bar, and whatever else **if and
> only if an update to those libraries is required by explicitly specified
> dependencies**
>
> The hidden benefit here is that rather than upgrading everything, all
> the time, you only upgrade that which you need, AND YOU DON'T EXPOSE
> YOURSELF TO HUNDREDS OF OTHER UNRELATED CHANGES.
>
> Which is neat. This way, you only take a risk on specific software
> you're upgrading, not the entire operating system. So if something is
> borked, say, in this week's glibc, well, guess what? If you didn't
> upgrade it, who cares? By tomorrow, it'll probably be fixed, but either
> way it has no impact on you, so you probably won't even notice.
>
> emerge -uD world == Debian Unstable.

Hmm, i thought this would result in == Debian stable and

ACCEPT_KEYWORDS=~x86 emerge -uD world

would result in == Debian unstable ?

Anybody prove me wrong?

--Heinrich
>
> Not doing emerge on a daily basis, results, in my experience in an
> incredibly stable and low maintenance overhead system.
>
>
>>The server
>>just can't break.
>
>
> Actually, that's a slightly more demanding standard than this mailing
> list generally talks about - that's more about effective large
> installation deployment, configuration management, high availability,
> and roll out testing techniques. There's no such thing as a server that
> will never break, so you need to engineer the problem at different
> levels.
>
> If this sounds interesting but you have no idea what I'm talking about,
> you might start by reading http://www.infrastructures.org/ and the
> collected proceedings of past LISA conferences at
> http://www.usenix.org/events/bytopic/lisa.html . There have also been a
> number of GLEPs of late attempting to push the things necessary to
> enable Gentoo to be feasibly used in high consequence environments, see
> http://www.gentoo.org/proj/en/glep/glep-0019.html and the mad debates on
> gentoo-dev and elsewhere, eg
> http://thread.gmane.org/gmane.linux.gentoo.devel/20270 . And, popping up
> the stack slightly, you might be interested in a paper I wrote about
> operations professionalism in systems environments,
> http://www.operationaldynamics.com/reference/talks/SurvivingChange/
>
> AfC
> Sydney
>
>
> --
> Andrew Frederick Cowie
> Operational Dynamics Consulting Pty Ltd
>
> Stand up and be counted!
>
> Register your Linux computers at http://counter.li.org/
>


--
gentoo-user@gentoo.org mailing list

Heinrich Rebehn wrote:
> Andrew Cowie wrote:
>
>> On Mon, 2004-09-20 at 21:24 -0700, Grant wrote:
>>
>>> I've been very concerned with the possibility of an 'emerge -uD world'
>>> breaking any of my systems, but especially my server.
>>
>>
>>
>> If that is so, then simply do not ever use `emerge world`
>>
<snip>
>>
>> emerge -uD world == Debian Unstable.
>
>
> Hmm, i thought this would result in == Debian stable and
>
> ACCEPT_KEYWORDS=~x86 emerge -uD world
>
> would result in == Debian unstable ?
>
> Anybody prove me wrong?
>
> --Heinrich

Depends on your ACCEPT_KEYWORDS setting in /etc/make.conf.

/etc/make.profile normally contains the stable arch setting, so stable
packages are unmasked by default. If you additionally add ~arch in
/etc/make.conf to unmask the unstable packages, then yes, you probably
would wind up with essentially Debian unstable (since unstable packages
usually are newer than stable packages, and an update world will pick up
the most recent version of all packages that have a newer version
available).

However, if you don't put an unstable arch setting in /etc/make.conf,
only stable packages will be fetched under all circumstances (because
the only KEYWORDS set to be accepted is the stable one in
/etc/make.profile), and unstable packages will remain masked, so you
will only update if a newer stable version is available.

Naturally, you can also use /etc/portage/package.keywords to unmask the
unstable versions of individual packages, so that your system as a whole
only used stable packages, but mozilla-firefox (for example) could be
updated to the latest unstable version.

Holly

--
gentoo-user@gentoo.org mailing list