[gentoo-server] Stable portage tree

[gentoo-server] Stable portage tree

[Jan Meier]

Hello,

how is the status of the stable portage tree? Is it already available? 

I am really interested in it because I am tired of frequently updates on my 
server just because there is a new version. Doing only security update would 
be nice.

Regards

Jan
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Marten Persson]

On Wednesday 16 August 2006 09.06, Jan Meier wrote:
> Hello,
>
> how is the status of the stable portage tree? Is it already available?
>
> I am really interested in it because I am tired of frequently updates on my
> server just because there is a new version. Doing only security update
> would be nice.
>
> Regards
>
> Jan
Whu do you need the latest versions? My servers run upates once or twice 
yearly and some security patching in between. 

Just a thought.

Marten
-- 
Höjebromölla
Mårten Persson

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 16 August 2006 11:01 schrieb Marten Persson:
> On Wednesday 16 August 2006 09.06, Jan Meier wrote:
> > Hello,
> >
> > how is the status of the stable portage tree? Is it already available?
> >
> > I am really interested in it because I am tired of frequently updates on
> > my server just because there is a new version. Doing only security update
> > would be nice.
> >
> > Regards
> >
> > Jan
>
> Whu do you need the latest versions? My servers run upates once or twice
> yearly and some security patching in between.

No, I do not need the latest version. But I do not want to do "some security 
patching", I want to have every security risk patched (updated), without 
updating all the dependencies. That's the point.

For example emerge -u imagemagick shows a really long list for updating, I do 
not think that all of them are really needed. 

Regards

Jan


> Just a thought.
>
> Marten
> --
> Höjebromölla
> Mårten Persson

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Craig Webster]

On 16 Aug 2006, at 10:19, Jan Meier wrote:
> No, I do not need the latest version. But I do not want to do "some  
> security
> patching", I want to have every security risk patched (updated),  
> without
> updating all the dependencies. That's the point.
>
> For example emerge -u imagemagick shows a really long list for  
> updating, I do
> not think that all of them are really needed.

Have you tried using glsa-check?

Cheers,
Craig
--
No long-term contracts, no complicated signup forms, no hidden costs.
Xeriom 2.0: Web hosting made easy. Coming soon! http://xeriom.net/


-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 16 August 2006 11:36 schrieb Craig Webster:
> On 16 Aug 2006, at 10:19, Jan Meier wrote:
> > No, I do not need the latest version. But I do not want to do "some
> > security
> > patching", I want to have every security risk patched (updated),
> > without
> > updating all the dependencies. That's the point.
> >
> > For example emerge -u imagemagick shows a really long list for
> > updating, I do
> > not think that all of them are really needed.
>
> Have you tried using glsa-check?

I am using glsa-check for reporting vulnerable software, currently not for 
updating. 
I will give "emerge imagemagick" a shot, maybe that has less dependencies :).  
With your answeres in mind I came to the opinion that there is not a real 
need for a "stable portage tree". 

Regards

Jan

> Cheers,
> Craig
> --
> No long-term contracts, no complicated signup forms, no hidden costs.
> Xeriom 2.0: Web hosting made easy. Coming soon! http://xeriom.net/

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Ian P. Christian]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

On 08/16/06 Jan Meier wrote:
> I am using glsa-check for reporting vulnerable software, currently 
> not for updating. I will give "emerge imagemagick" a shot, maybe that 
> has less dependencies :) . With your answeres in mind I came to the 
> opinion that there is not a real need for a "stable portage tree". 

I personally think there is a a large need for a stable tree.

I run 10s of servers, and I'm sure there's people on this list who run
many more.

Updating every 6/12 months is fine in principle, but it means going
though 10's of machines updating config files and resolving conflics.
This is a painful task, it's fine for 1 machine, it's fine for 5... but
you have any real number of servers to maintain and it ends up taking
hours or days to upgrade your servers.

A stable tree that has an update cycle of something like 6 months and
perhaps a security overlay (implement as an overlay perhaps to reduce
the sync time and therefore resources) would be idea - then upgrading
between 'releases' could be well documented and coordinated.
Unfortunatly, this is a huge project - and without a small/medium team
of dedicated gentoo devs, it's not going to happen.

-- 
Ian P. Christian ~ http://pookey.co.uk


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Paul Kölle]

Ian P. Christian wrote:
> On 08/16/06 Jan Meier wrote:
>> I am using glsa-check for reporting vulnerable software, currently 
>> not for updating. I will give "emerge imagemagick" a shot, maybe that 
>> has less dependencies :) . With your answeres in mind I came to the 
>> opinion that there is not a real need for a "stable portage tree". 
> 
> I personally think there is a a large need for a stable tree.
[ snipp ]
The basic problem here is: Upstream may not publish "security fixes" but
just a new (fixed) version. If you want a "stable" tree, you have to
watch upstream cvs/svn/mailing lists and backport fixes. That is a lot
of work.

cheers
 Paul
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Ian P. Christian]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On 08/16/06 Paul Kölle wrote:
> The basic problem here is: Upstream may not publish "security fixes" 
> but just a new (fixed) version. If you want a "stable" tree, you have 
> to watch upstream cvs/svn/mailing lists and backport fixes. That is a 
> lot of work.

that infrastructure is already in place in gentoo. Package maintainers
do it... they need to just make it clear when they update an ebuild
weather it's a general upgrade, or a security upgrade.


-- 
Ian P. Christian ~ http://pookey.co.uk


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Paul Kölle]

Ian P. Christian wrote:
> On 08/16/06 Paul Kölle wrote:
>> The basic problem here is: Upstream may not publish "security fixes" 
>> but just a new (fixed) version. If you want a "stable" tree, you have 
>> to watch upstream cvs/svn/mailing lists and backport fixes. That is a 
>> lot of work.
> 
> that infrastructure is already in place in gentoo. Package maintainers
> do it... they need to just make it clear when they update an ebuild
> weather it's a general upgrade, or a security upgrade.

glsa-check will tell you if it's a security upgrade, but it will do
version bumps including ${PV} nevertheless. That is, your dependency
tree will change and possibly lead to unwanted upgrades (read: upgrade
with possible config changes, new features, new bugs).
AFAIK gentoo devs don't do backports, i.e. if samba has a vulnerability
in say 3.0.23a which is fixed in 3.0.23b, you won't get a  "security
fixes only" 3.0.23a-r1 but just 3.0.23b with new features *and* fixed bugs.

cheers
 Paul
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 16 August 2006 12:18 schrieb Ian P. Christian:
> On 08/16/06 Paul Kölle wrote:
> > The basic problem here is: Upstream may not publish "security fixes"
> > but just a new (fixed) version. If you want a "stable" tree, you have
> > to watch upstream cvs/svn/mailing lists and backport fixes. That is a
> > lot of work.
>
> that infrastructure is already in place in gentoo. Package maintainers
> do it... they need to just make it clear when they update an ebuild
> weather it's a general upgrade, or a security upgrade.

I think every update because of security reasons has a security announcement.

I would be willing to start such a stable tree, I am thinking of taking a 
current portage tree, delete all ~arch ebuilds and create an overlay. Every 
time a security announcement is fired up I will add the newer ebuild to the 
overlay, checking for any really needed depencies.

The main portage tree will be updatedwith every new release, and the older 
trees will be supported until three new releases. Supported architecture 
would be currently only x86.

The overlay and the portage snapshot will I make public available.

What do you think about this?
The main problem is that it does not match the philosophy of gentoo. If other 
architectures should also be available it would be a lot of work.

Regards 

Jan

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Paul Kölle]

Jan Meier wrote:
> I would be willing to start such a stable tree, I am thinking of taking a 
> current portage tree, delete all ~arch ebuilds and create an overlay. Every 
> time a security announcement is fired up I will add the newer ebuild to the 
> overlay, checking for any really needed depencies.

~arch doesn't hurt, so the main difference to glsa-check+standard tree
would be old ebuilds not being deleted right? AFAIK that can be done by
removing the --delete and --delete-after flag from PORTAGE_RSYNC_OPTS in
/etc/make.conf (dunno if thats "supported" though).

cheers
 Paul
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 16 August 2006 15:12 schrieb Paul Kölle:
> Jan Meier wrote:
> > I would be willing to start such a stable tree, I am thinking of taking a
> > current portage tree, delete all ~arch ebuilds and create an overlay.
> > Every time a security announcement is fired up I will add the newer
> > ebuild to the overlay, checking for any really needed depencies.
>
> ~arch doesn't hurt, so the main difference to glsa-check+standard tree
> would be old ebuilds not being deleted right? 

No, the advantage would be that new ebuilds would not come into the portage 
tree. Only security relevant ebuilds, formerly which fix security holes, 
would come into the tree (kernel, php, mysql, apache, etc. should not be 
stopped from entering the portage tree).
This has the advantage that there would be less packages to update when the 
system has to be updated. And if there are security relevant updates there 
would not be as much dependency updates as with the normal tree.

Take a look here:
http://www.gentoo.org/proj/en/glep/glep-0019.html

Regards

Jan

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Paul Kölle]

Jan Meier wrote:
> Am Mittwoch 16 August 2006 15:12 schrieb Paul Kölle:
>> Jan Meier wrote:
>>> I would be willing to start such a stable tree, I am thinking of taking a
>>> current portage tree, delete all ~arch ebuilds and create an overlay.
>>> Every time a security announcement is fired up I will add the newer
>>> ebuild to the overlay, checking for any really needed depencies.
>> ~arch doesn't hurt, so the main difference to glsa-check+standard tree
>> would be old ebuilds not being deleted right? 
> 
> No, the advantage would be that new ebuilds would not come into the portage 
> tree. Only security relevant ebuilds, formerly which fix security holes, 
> would come into the tree (kernel, php, mysql, apache, etc. should not be 
> stopped from entering the portage tree).
Sorry, I don't get it. Why are you concerned about packages in the tree
you don't use? Is it about space savings?

> This has the advantage that there would be less packages to update when the 
> system has to be updated. And if there are security relevant updates there 
> would not be as much dependency updates as with the normal tree.
The depgraph of a bumped package does not depend on being bumped due to
a GLSA or not. If you only use glsa-check, you will get GLSA triggered
upgrades only and glsa-check will emerge the lowest safe version
possible. Keeping old versions around is sufficient to prevent unneeded
upgrades. If you want something like "emerge -u --stable world", well
then you would need a dedicated tree for --stable but thats way more
work than just deleting ~arch ebuilds you wouldn't use anyway.

> 
> Take a look here:
> http://www.gentoo.org/proj/en/glep/glep-0019.html
This glep talkes about a "stable tree" which conforms to some "higher"
QA standars than <arch> but I haven't seen much work here. Portage does
not support the "stable:<arch>" syntax and there is no sign gentoo devs
can handle those "higher QA" currently (see my comments on backporting
and missing seperate security patches upstream).

cheers
 Paul
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 16 August 2006 16:11 schrieb Paul Kölle:
> Jan Meier wrote:
> > Am Mittwoch 16 August 2006 15:12 schrieb Paul Kölle:
> >> Jan Meier wrote:
> >>> I would be willing to start such a stable tree, I am thinking of taking
> >>> a current portage tree, delete all ~arch ebuilds and create an overlay.
> >>> Every time a security announcement is fired up I will add the newer
> >>> ebuild to the overlay, checking for any really needed depencies.
> >>
> >> ~arch doesn't hurt, so the main difference to glsa-check+standard tree
> >> would be old ebuilds not being deleted right?
> >
> > No, the advantage would be that new ebuilds would not come into the
> > portage tree. Only security relevant ebuilds, formerly which fix security
> > holes, would come into the tree (kernel, php, mysql, apache, etc. should
> > not be stopped from entering the portage tree).
>
> Sorry, I don't get it. Why are you concerned about packages in the tree
> you don't use? Is it about space savings?

Eh, no. In my opinion it is clear what I want to say, so I have nothing to 
add.

> > This has the advantage that there would be less packages to update when
> > the system has to be updated. And if there are security relevant updates
> > there would not be as much dependency updates as with the normal tree.
>
> The depgraph of a bumped package does not depend on being bumped due to
> a GLSA or not. If you only use glsa-check, you will get GLSA triggered
> upgrades only and glsa-check will emerge the lowest safe version
> possible. Keeping old versions around is sufficient to prevent unneeded
> upgrades. If you want something like "emerge -u --stable world", well
> then you would need a dedicated tree for --stable but thats way more
> work than just deleting ~arch ebuilds you wouldn't use anyway.

The ~arch ebuilds are not the point, the stable ebuilds which potentially be 
upgraded are the point. If you say that glsa-check does only update the 
package which is security relevant and tries not to update the dependencies 
then this is what I want.

Regards

Jan


-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Wed, 16 Aug 2006 16:40:01 +0200
Jan Meier <jan.meier@zmnh.uni-hamburg.de> wrote:

> The ~arch ebuilds are not the point, the stable ebuilds which
> potentially be upgraded are the point. If you say that glsa-check
> does only update the package which is security relevant and tries not
> to update the dependencies then this is what I want.

It will only update dependencies when they are strictly required by the
new version, same like emerge if you don't use -u (which should
only be used for system and world updates anyway). Basically 
    glsa-check -f some-glsa
will call
    emerge --oneshot $EMERGE_OPTS =package-version
where 'version' is the lowest "safe" version that doesn't result in a
downgrade (of course if the system isn't affected it won't do anything).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Sune Kloppenborg Jeppesen]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On Wednesday 16 August 2006 13:26, Jan Meier wrote:
> I think every update because of security reasons has a security
> announcement.
Not every security issue results in a GLSA [1].

[1] http://www.gentoo.org/security/en/vulnerability-policy.xml

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Operational Manager
Gentoo Linux Security Team
http://security.gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Jan Meier]

Am Mittwoch 23 August 2006 07:30 schrieb Sune Kloppenborg Jeppesen:
> On Wednesday 16 August 2006 13:26, Jan Meier wrote:
> > I think every update because of security reasons has a security
> > announcement.
>
> Not every security issue results in a GLSA [1].
> [1] http://www.gentoo.org/security/en/vulnerability-policy.xml

Ahh, good to know. 

Regards

Jan
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Alex Efros]

Hi!

On Wed, Aug 16, 2006 at 11:00:21AM +0100, Ian P. Christian wrote:
> Updating every 6/12 months is fine in principle, but it means going
> though 10's of machines updating config files and resolving conflics.
> This is a painful task, it's fine for 1 machine, it's fine for 5... but
> you have any real number of servers to maintain and it ends up taking
> hours or days to upgrade your servers.

Yeah, your right. But there simple solution for this: update your servers
every 3-4 days, and you will be surprised how ease and quick this task become.
You'll need from a couple of seconds to 2-3 minutes in average for such update!
Usually a few not important for you applications will be updated, which
can't broke anything on your server, and which require few seconds to
update their config files. Sometimes one of applications critical for your
server become updated, and this require more attention, but it's much
better to update ONE such important application instead of updating ALL of
such important applications every 6-12 month. And this way you always can
ease fallback to previous version of this application if something goes
wrong on your server, add broken (for you) version to
/etc/portage/package.mask, report bug and wait for next update.

I've tried all these ways of updating my servers in last 2 years:
update every few days, update only security issues, update every 6-12 months
and found first way much more ease, effective and manageable than others.
With two other ways I also wanna 'stable portage tree', with first way I
don't need it - ARCH=x86 IS A 'stable portage tree' for me now. :)

-- 
			WBR, Alex.
-- 
gentoo-server@gentoo.org mailing list

RE: [gentoo-server] Stable portage tree

[Jesse, Rich]

Constant and needless updating servers is the exact opposite of
"stable".  Server stability equates to money in almost all business,
IMHO.  Why on earth would I risk my stability on a daily basis by
emerging world?  Remember that the ONLY reason to upgrade a server is if
there is discernable benefit.  The benefit may be a security fix, bug
fix, supportability, enhancement, or it just looks cooler -- that's for
the user/benefactor(s) to decide.

By default, Portage doesn't lend itself to this.  I don't need/want the
latest Postgres just because it's available, especially when the upgrade
would require data and/or app migration.  Upgrades warrant testing.  I
can't justify spend hundreds of man-hours testing all available apps on
a given system just because some program went from v4.3 to 4.3-1.

I also can't justify upgrading just because Gentoo no longer wants to
keep last year's ebuild around.  Thankfully, a sysadmin can make use of
OVERLAY and rsync (*without* "--delete"!) to create their own portage
tree, complete with all the old rebuilds.  Anyone that's tried to
upgrade an old OpenSSH knows what happens on the ensuing revdep-rebuild
-- ebuilds are gone, and you're stuck in the mud.

RedHat is stable.  It's also a PITA to maintain for some business apps.
Building Oracle on RedHat requires arcane incantations and animal
sacrifice.  But doing the same on Gentoo is the same as any flavor of
Unix.  So, I use RedHat in production, but Gentoo on my R&D desktop.
But that doesn't mean I don't need stability.  Any major libs get
changed and I need to relink Oracle.  Then I need to wonder what changed
and how to test it.  It's just not worth the hassle for almost all
updates for me.

I'm way short on time and way too terse here.  This is the kinda stuff
that needs to be debated over copius amounts of really freakin good
beer.

My $.02,
Rich


-----Original Message-----
From: Alex Efros [mailto:powerman@powerman.asdfGroup.com] 
Sent: Wednesday, August 16, 2006 6:30 AM
To: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Stable portage tree

Hi!

On Wed, Aug 16, 2006 at 11:00:21AM +0100, Ian P. Christian wrote:
> Updating every 6/12 months is fine in principle, but it means going
> though 10's of machines updating config files and resolving conflics.
> This is a painful task, it's fine for 1 machine, it's fine for 5...
but
> you have any real number of servers to maintain and it ends up taking
> hours or days to upgrade your servers.

Yeah, your right. But there simple solution for this: update your
servers
every 3-4 days, and you will be surprised how ease and quick this task
become.
You'll need from a couple of seconds to 2-3 minutes in average for such
update!
Usually a few not important for you applications will be updated, which
can't broke anything on your server, and which require few seconds to
update their config files. Sometimes one of applications critical for
your
server become updated, and this require more attention, but it's much
better to update ONE such important application instead of updating ALL
of
such important applications every 6-12 month. And this way you always
can
ease fallback to previous version of this application if something goes
wrong on your server, add broken (for you) version to
/etc/portage/package.mask, report bug and wait for next update.

I've tried all these ways of updating my servers in last 2 years:
update every few days, update only security issues, update every 6-12
months
and found first way much more ease, effective and manageable than
others.
With two other ways I also wanna 'stable portage tree', with first way I
don't need it - ARCH=x86 IS A 'stable portage tree' for me now. :)

-- 
			WBR, Alex.
-- 
gentoo-server@gentoo.org mailing list

-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Alex Efros]

Hi!

On Wed, Aug 16, 2006 at 09:16:55AM -0500, Jesse, Rich wrote:
> Constant and needless updating servers is the exact opposite of "stable".

Yeah.

But last years show ARCH=x86 is stable enough and such updates
very rare broke anything, so "constant" in this case doesn't result in
so many troubles as it sounds.

About "needless" - as I said before, in last years I've tried all ways
to update servers - exactly because I also wanna install only security
fixes for everything plus sometimes update some critical for my tasks
packages because of important bug fixes there... but this doesn't work 
in long term, :( while "constant updating" solve these issues without
introducing too many new problems.

> By default, Portage doesn't lend itself to this.  I don't need/want the
> latest Postgres just because it's available, especially when the upgrade
> would require data and/or app migration.  Upgrades warrant testing.  I
> can't justify spend hundreds of man-hours testing all available apps on
> a given system just because some program went from v4.3 to 4.3-1.

Hmm... Again, x86 is stable enough to avoid such retesting on each update.
I agree it's nice idea to retest everything, but it's just impossible -
you should define some intelligent amount of retesting which you able to
do quickly after update. Something like smoke testing in few clicks to be
sure your app is running and working with database is enough for most cases.
If some deeper problems arise in this app just because of database update
from 4.3 to 4.3.1 then it's probably because of bug in your app and it's
better to fix it NOW.

Probably this way isn't acceptable for you - I'm mostly administrate
servers dedicated for few complex apps, and it's ease to quickly check
them all after update.

Also, I don't think your example is good and realistic. So critical
components as database isn't update often, newer version of databases
isn't usually marked as dependency for some other app, so you usually
isn't forced to update it ASAP - you can delay database update until
you'll read changelog and become sure your apps are ready for it.

> I also can't justify upgrading just because Gentoo no longer wants to
> keep last year's ebuild around.  Thankfully, a sysadmin can make use of
> OVERLAY and rsync (*without* "--delete"!) to create their own portage
> tree, complete with all the old rebuilds.  Anyone that's tried to
> upgrade an old OpenSSH knows what happens on the ensuing revdep-rebuild
> -- ebuilds are gone, and you're stuck in the mud.

Yeah, I know. But removing --delete doesn't guaranty ability to install
old ebuild - just because ebuilds sometimes changed without versions
bumping, and reinstalling same version few months later can result in
compilation using different patches and/or configure options, etc.

Such "old" ebuild even can fail to unpack, see this example:
1) [January] foo-1.0.ebuild added, it use files/foo.patch
2) [Febrary] foo-1.0.ebuild deleted,
	     foo-2.0.ebuild added, it also use files/foo.patch, but this
	     is completely different patch while it has same name as
	     previous patch :(

And another problem: removing old ebuild from portage mean it isn't
supported anymore, so you doesn't get GLSA and bugfixes for it. This is
why naive initiative of Jan Meier (in second subthread of this thread)
will not work:

>> I think every update because of security reasons has a security announcement.
>> 
>> I would be willing to start such a stable tree, I am thinking of taking a
>> current portage tree, delete all ~arch ebuilds and create an overlay. Every
>> time a security announcement is fired up I will add the newer ebuild to the
>> overlay, checking for any really needed depencies.

> But that doesn't mean I don't need stability.  Any major libs get
> changed and I need to relink Oracle.  Then I need to wonder what changed

Yeah, but... there always some reason why things like glibc updates, and
you free to update it or delay update because you don't have time now
to relink Oracle.

There is a big difference between 'install only selected updates' and
'install all updates except selected'. I prefer second because first
don't work in long term (I got troubles installing security updates after
about 6-8 months going this way). To support first way and get 'stable
portage tree' we need big enough team of Gentoo devs dedicated for this
task. For now it doesn't looks like they willing to do this. 

Maybe 'Debian stable' is right choice for ppl who vote for 'stable
portage tree' - it has only very old, really stable packages and only
critical updates (I doesn't use Debian myself, so maybe I'm wrong about it).

> I'm way short on time and way too terse here.  This is the kinda stuff
> that needs to be debated over copius amounts of really freakin good
> beer.

Agreed! :)

-- 
			WBR, Alex.
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Ian P. Christian]

[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]

Perhaps this is simply just a case of accepting there's 2 schools of
though on how to keep a system upto date.  If this is the case, Gentoo
certainly doesn't' lend itself well to the school I attend, and clearly
I'm not the only person who's there.


Alex Efros wrote:
> very rare broke anything, so "constant" in this case doesn't result in
> so many troubles as it sounds.
> 
> in long term, :( while "constant updating" solve these issues without
> introducing too many new problems.

Twice you've suggested there are problems, and it's ok because there
haven't been many. This really isn't the case.  I can't afford to
upgrade 10's of machines every week and test them all (mostly they do
different things obviously).

> Hmm... Again, x86 is stable enough to avoid such retesting on each update.
> I agree it's nice idea to retest everything, but it's just impossible -

No, it's not. On a 6/12 month cycle (or like ubuntu for example, I
*think* it's 18) you get plenty of time to setup your stuff on some test
systems and test them out properly.  Perhaps giving them a week or two's
worth of stress testing.

> If some deeper problems arise in this app just because of database update
> from 4.3 to 4.3.1 then it's probably because of bug in your app and it's
> better to fix it NOW.

I'm sorry, but that is just crazy talk ;)
You clearly don't deal with PHP, where a point release can break a LOT
of things, some things you might not notice by loading 2 or 3 pages from
a website.

> Probably this way isn't acceptable for you - I'm mostly administrate
> servers dedicated for few complex apps, and it's ease to quickly check
> them all after update.

Can I ask how many? Perhaps this is just that you've not hit the point
where it's just a PITA yet.
I used to have no problem running 5 or 6 machines, but now it's just a
nightmare.

> Maybe 'Debian stable' is right choice for ppl who vote for 'stable
> portage tree' - it has only very old, really stable packages and only
> critical updates (I doesn't use Debian myself, so maybe I'm wrong about it).

Or, some might suggest the answer for those that want a 'stable portage
tree' is to provide... wait for it... it's a radical suggestion... a
stable portage tree? :)

Yours, occasionally sarcastically and no disrespect meant -

Ian

-- 
Ian P. Christian ~ http://pookey.co.uk


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Alex Efros]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

Hi!

On Wed, Aug 16, 2006 at 05:07:46PM +0100, Ian P. Christian wrote:
> Twice you've suggested there are problems, and it's ok because there
> haven't been many. This really isn't the case.  I can't afford to

In my exp and after reading ml I think constant updates in x86 result in 
1-2 issues per year. I think it's ok. I think it's better to get these
issues isolated, after updating 2-3 packages, and with ability to fallback
to previous package versions, than get these issues after massive update
of everything every 6-12 months and without ability to fallback.

Also I'm usually make `emerge --sync` and then wait 2-3 days reading ml
before running `emerge -uDNa world` - only in hope to avoid these
'1-2 issues per year', because if something so bad happens ppl in ml
usually notify about it very quickly.

> systems and test them out properly.  Perhaps giving them a week or two's
> worth of stress testing.

Yeah, I'm doing this 1-2 week stress testing by installing updates on
developers servers first, then on production servers. But this really
needed then some core package updated - linux kernel, perl, mysql, apache -
everybody has own list of critical packages and it isn't too big usually.

> I'm sorry, but that is just crazy talk ;)
> You clearly don't deal with PHP, where a point release can break a LOT
> of things, some things you might not notice by loading 2 or 3 pages from
> a website.

Yeah, you right about me. I don't deal with PHP and I never administrate
more than 5-6 servers. :) But I think it happens sometime, so this
discussion is very interesting for me - I wanna learn other's experience
and be ready for situations where my own experience will not work anymore.

It still isn't clear for me why update strategy for 100 servers differ
from 5-6 servers. I don't believe in 100 servers doing really DIFFERENT
tasks with really different configurations (at least - in all these
servers managed by single admin :)). If most of these server has similar
configurations then it's ease to setup few test servers updated
constantly and have production servers updated with some delay after test
servers.


P.S. About PHP. I don't deal with PHP because of only one reason:
I convince my boss what PHP is too unsecure (Ohh, I feel millions of PHP
fanatics will kill me now :)) and we moved all our PHP apps into
dedicated server, which we specially buy for this task, and I'm not really
think about security and updates of this server - I'm sure it can be hacked
just because of holes in PHP scripts which I can't audit and fix.
This may sounds terribly, but... overall security equal to security of
weakness place, and I don't think my attitude to updating this server
lowering it overall security. Myself, selecting between hacking one of
apache/ssh/qmail services on non-updated-in-12-months server with Hardened
Gentoo and hacking a lot of different (both custom and opensource) PHP apps
on this server will choose PHP without thinking too much. :)

-- 
			WBR, Alex.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Alex Efros]

Hi!

On Wed, Aug 16, 2006 at 05:46:18PM +0200, Karl Hiramoto wrote:
> You have to understand that people in production environments can not do 
> this.  You can not risk a server being off line every few days..  If you 
> have 10 severs, doing this you would 1-2 hours a week doing updates.  
> With 100 servers, you may need a full time employee just to do updates.

I'm understanding this, and I'm working in production environment. :)
If you've 10+, or even 100 servers, then most of them usually have same
configuration (3-4 different configurations), and you can dedicate 1-2
servers for testing updates before installing them of all servers.

> I think perhaps a good suggestion would be for example:
> Gentoo enterprise release 2006.0  with it's own rsync mirror, then only 
> security update ebuilds, or major bugs get added to this rsync mirror.  
> This release could be timed with a official gentoo live cd release.
> 
> When the admins want to do a major upgrade, they point their rsync 
> mirror to 2007.0   for example.

Yeah, but, as I said before, this require many Gentoo devs dedicated for
this task... and these devs must not be newbies, they must be security
experts and strong QA. For now I don't see enthusiasm from Gentoo devs to
work on this task.

All other solutions like 'update once in 6-12 months' for my experience is
much worse than 'update constantly everything except selected packages'.

-- 
			WBR, Alex.
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Sune Kloppenborg Jeppesen]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Wednesday 16 August 2006 18:04, Alex Efros wrote:
> Hi!
>
> On Wed, Aug 16, 2006 at 05:46:18PM +0200, Karl Hiramoto wrote:
> Yeah, but, as I said before, this require many Gentoo devs dedicated for
> this task... and these devs must not be newbies, they must be security
> experts and strong QA. For now I don't see enthusiasm from Gentoo devs to
> work on this task.
Currently we don't have the manpower needed for such a task. Some of us worked 
on GLEP 19 about a year ago but it has been dormant since then as we 
encountered quite a few problems.

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Operational Manager
Gentoo Linux Security Team
http://security.gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-server] Stable portage tree

[Sune Kloppenborg Jeppesen]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Wednesday 16 August 2006 17:46, Karl Hiramoto wrote:
> Alex Efros wrote:
> > Yeah, your right. But there simple solution for this: update your servers
> > every 3-4 days, and you will be surprised how ease and quick this task
> > become. You'll need from a couple of seconds to 2-3 minutes in average
> > for such update!
>
> You have to understand that people in production environments can not do
> this.  You can not risk a server being off line every few days..  If you
> have 10 severs, doing this you would 1-2 hours a week doing updates.
> With 100 servers, you may need a full time employee just to do updates.
With 100 servers some should be more or less identical giving you at least a 
few oppertunities to save time.

Previously I used to work for a hosting provider and in my memory we had less 
than one problem per server per year and we didn't even build packages 
centrally.

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Operational Manager
Gentoo Linux Security Team
http://security.gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

baselayout was Re: [gentoo-server] Stable portage tree

[Robert Welz]

Jan Meier wrote:
> Hello,
> 
> how is the status of the stable portage tree? Is it already available? 
> 
> I am really interested in it because I am tired of frequently updates on my 
> server just because there is a new version. Doing only security update would 
> be nice.
> 
> Regards
> 
> Jan

I have noticed three updates to baselayout in three days. Is there a 
real reason for that high frequency of updates? I have the problem of 
etc-update on 14 servers and really could spend my time on something 
more productive i.e. learning ldap, fixing sguile and debugging xen for 
nfs. Now I fix all those init.d files all the day.

Just my 2 cents,
Regards,
Robert
-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Mark Rudholm]

Robert Welz wrote:
> Jan Meier wrote:
>> Hello,
>>
>> how is the status of the stable portage tree? Is it already available?
>> I am really interested in it because I am tired of frequently updates
>> on my server just because there is a new version. Doing only security
>> update would be nice.
>>
>> Regards
>>
>> Jan
> 
> I have noticed three updates to baselayout in three days. Is there a
> real reason for that high frequency of updates? I have the problem of
> etc-update on 14 servers and really could spend my time on something
> more productive i.e. learning ldap, fixing sguile and debugging xen for
> nfs. Now I fix all those init.d files all the day.

The general complaint I'm hearing about Gentoo is the lack of
configuration stability.  Updates that aren't backward-compatible
are a pain.  I had to reboot a system that hadn't been booted in
about a year and the modules didn't load because of the changes to
modules.autoload.  I've had to clean up Apache conf files 'cause they
moved.  I've had to deal with moving to the new "modular" xorg (and
try to hunt down all the X tools I used to have).  Not to mention
the baselayout changes...

I used to laugh at http://www.funroll-loops.org/ but lately it
really does seem that the distro is being managed by those on
the young side.

Not that any other Linux distro is any better.  I'm contemplating
going back to BSD, which is my company's standard anyway.

-Mark
-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Jonas Fietz]

Hi

> are a pain.  I had to reboot a system that hadn't been booted in
> about a year and the modules didn't load because of the changes to
> modules.autoload.  I've had to clean up Apache conf files 'cause they
> moved.  I've had to deal with moving to the new "modular" xorg (and
> try to hunt down all the X tools I used to have).  Not to mention
> the baselayout changes...
Well, Xorg was an upstream decision, the config-files for apache where 
simply wrong before, so that had to be fixed, and about the changes in 
modules.autoload, i am not so sure.
But to the people needing a stable portage tree: It is really a totally 
different ideology which is somewhat diametral to what gentoo does. 
Gentoo does _not_ have real releases, which some people, me included, 
think is a good thing. Also, i think if the security-fixes are just 
backported, I personally believe that unless there are many people 
helping with the effort there will be more bugs introduced by this, as 
most of the time the codes might not know the code base as well.
Also, you are complaining about the long list of updates when doing a -u 
somewhat. Those are _real_ dependencies, even if they were just imagined 
by some hallucinating gentoo dev ;). So normally there would not be a 
way around installing them.
But on an infrastructure as big as some are talking about here, there 
usually are few types of servers, so that it can be tested anyway. And 
maybe, those types of companies should be more willing to spend a few 
bucks to the gentoo project, maybe about the new "adopt a gentoo-dev"-page.

Ok, ranted enough ;)

Jonas Fietz


DISCLAIMER: I AM NOT A GENTOO DEV
-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[kashani]

Robert Welz wrote:

> I have noticed three updates to baselayout in three days. Is there a 
> real reason for that high frequency of updates? I have the problem of 
> etc-update on 14 servers and really could spend my time on something 
> more productive i.e. learning ldap, fixing sguile and debugging xen for 
> nfs. Now I fix all those init.d files all the day.

I'd guess those would be "oops" bugs that they are fixing which is why I 
don't update a package unless it's a glsa or it's been in portage more 
than a week.

kashani
-- 
gentoo-server@gentoo.org mailing list

Re: [gentoo-server] Stable portage tree

[Christian Spoo]

[-- Attachment #1.1: Type: text/plain, Size: 172 bytes --]

Just had a look at the changes in baselayout. There were only some
grammatical fixes in some of the init-scripts. Something you even
needn't to reboot for.

Christian

[-- Attachment #1.2: mail.vcf --]
[-- Type: text/x-vcard, Size: 281 bytes --]

begin:vcard
fn:Christian Spoo
n:Spoo;Christian
adr;quoted-printable:;;Am Kaiser 26;W=C3=BCrselen;NRW;52146;Deutschland
email;internet:mail@christian-spoo.info
tel;fax:02405/475071
tel;home:02405/493466
tel;cell:0176/61055475
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 888 bytes --]

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Dice R. Random]

On 8/16/06, rdmurray@bitdance.com <rdmurray@bitdance.com> wrote:
> Just simplifying the etc-update process by having an option to silently
> install files that haven't been locally modified would help a _lot_.
> This was my big complaint about FreeBSD, too....
>
> Unfortunately I'm not doing enough server maintenance work myself these
> days to be able to justify taking the time to cook up some code for this.
>
> --David
> --
> gentoo-server@gentoo.org mailing list
>
>

You want dispatch-conf: http://gentoo-wiki.com/TIP_dispatch-conf
-- 
gentoo-server@gentoo.org mailing list

RE: baselayout was Re: [gentoo-server] Stable portage tree

[Jesse, Rich]

I'll have to check into that.  I still wish folks would adopt sdiff
(instead of diff) when dealing with output intended for human
consumption, which is why I wrote a quickie "ecfg" script to find the
etc-update-able config files show me changes via sdiff instead.

Thanks for the pointer!

Rich

-----Original Message-----
From: Dice R. Random [mailto:dicerandom@gmail.com] 
Sent: Wednesday, August 16, 2006 4:04 PM
To: gentoo-server@lists.gentoo.org
Subject: Re: baselayout was Re: [gentoo-server] Stable portage tree

[snip]
You want dispatch-conf: http://gentoo-wiki.com/TIP_dispatch-conf

-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Brian Kroth]

Jesse, Rich wrote:
> I'll have to check into that.  I still wish folks would adopt sdiff
> (instead of diff) when dealing with output intended for human
> consumption, which is why I wrote a quickie "ecfg" script to find the
> etc-update-able config files show me changes via sdiff instead.

You can do this in /etc/etc-update.conf or /etc/dispatch-conf.conf by 
changing the 'diff="..."' line.  I personally like colordiff.

Brian
-- 
gentoo-server@gentoo.org mailing list

RE: baselayout was Re: [gentoo-server] Stable portage tree

[Jesse, Rich]

Yet another excellent idea!  Thanks, Brian!

unalias ecfg

:)

Rich 

-----Original Message-----
From: Brian Kroth [mailto:bpkroth@wisc.edu] 
Sent: Thursday, August 17, 2006 7:45 AM
To: gentoo-server@lists.gentoo.org
Subject: Re: baselayout was Re: [gentoo-server] Stable portage tree

Jesse, Rich wrote:
> I'll have to check into that.  I still wish folks would adopt sdiff
> (instead of diff) when dealing with output intended for human
> consumption, which is why I wrote a quickie "ecfg" script to find the
> etc-update-able config files show me changes via sdiff instead.

You can do this in /etc/etc-update.conf or /etc/dispatch-conf.conf by 
changing the 'diff="..."' line.  I personally like colordiff.

Brian
-- 
gentoo-server@gentoo.org mailing list

-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Robert Welz]

Dice R. Random wrote:
> On 8/16/06, rdmurray@bitdance.com <rdmurray@bitdance.com> wrote:
>> Just simplifying the etc-update process by having an option to silently
>> install files that haven't been locally modified would help a _lot_.
>> This was my big complaint about FreeBSD, too....
>>
>> Unfortunately I'm not doing enough server maintenance work myself these
>> days to be able to justify taking the time to cook up some code for this.
>>
>> --David
>> -- 
>> gentoo-server@gentoo.org mailing list
>>
>>
> 
> You want dispatch-conf: http://gentoo-wiki.com/TIP_dispatch-conf

That looks great, thank you!

Greetings,
Robert
-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[rdmurray]

On Wed, 16 Aug 2006 at 14:03, Dice R. Random wrote:
> You want dispatch-conf: http://gentoo-wiki.com/TIP_dispatch-conf

Thanks!  I see disptach-conf is now mentioned in emerge --help config,
but of course I haven't read that text in a couple years :)

--David
-- 
gentoo-server@gentoo.org mailing list

Re: baselayout was Re: [gentoo-server] Stable portage tree

[Kerin Millar]

On 16/08/06, rdmurray@bitdance.com <rdmurray@bitdance.com> wrote:
> On Wed, 16 Aug 2006 at 21:21, Robert Welz wrote:
> > i.e. learning ldap, fixing sguile and debugging xen for nfs. Now I fix all
> > those init.d files all the day.
>
> Just simplifying the etc-update process by having an option to silently
> install files that haven't been locally modified would help a _lot_.
> This was my big complaint about FreeBSD, too....

I agree with this - it would make things easier. Note that you can
alleviate this problem to a certain extent by the use of
CONFIG_PROTECT_MASK. For example, if you never alter your stock init.d
scripts or, say, udev configuration files then you could put
CONFIG_PROTECT_MASK="/etc/init.d /etc/udev" in /etc/make.conf. Any
files beneath these directories will simply be clobbered by subsequent
installation of packages that place files there (remember,
CONFIG_PROTECT="/etc" is defined by default).

Cheers,

--Kerin
-- 
gentoo-server@gentoo.org mailing list