FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 08-28-2008, 08:31 PM
Warren Togami
 
Default New Key Repo Locations

This is the latest draft of New Key repo locations. Jesse Keating
points out that the deep levels are necessary because mirrors exclude
releases by directory name like "9/". Please let me know if you see any
errors in the below.


Release Before (no yum repo file)
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os/
Release After (no yum repo file)
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os.newkey/

fedora
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
fedora-newkey
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os.newkey/

fedora-debuginfo
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/
fedora-debuginfo-newkey
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug.newkey/

fedora-source
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/
fedora-source-newkey
http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS.newkey/

updates
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/
updates-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/

updates-debuginfo
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/debug/
updates-debuginfo-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/debug/

updates-source
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS/
updates-source-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS.newkey/

updates-testing
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/
updates-testing-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/

updates-testing-debuginfo
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/debug/
updates-testing-debuginfo-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/debug/

updates-testing-source
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS/
updates-testing-source-newkey
http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS.newkey/

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-28-2008, 08:36 PM
Jesse Keating
 
Default New Key Repo Locations

> On Thu, 2008-08-28 at 16:31 -0400, Warren Togami wrote:
> This is the latest draft of New Key repo locations. Jesse Keating
> points out that the deep levels are necessary because mirrors exclude
> releases by directory name like "9/". Please let me know if you see any
> errors in the below.

Also, "newkey" is literal.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-28-2008, 11:51 PM
Jeroen van Meeuwen
 
Default New Key Repo Locations

Warren Togami wrote:
This is the latest draft of New Key repo locations. Jesse Keating
points out that the deep levels are necessary because mirrors exclude
releases by directory name like "9/". Please let me know if you see any
errors in the below.




If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also
excluded? If it's not, then I guess there's no point in the new
directory being created either.


Will the ISOs be respun to reflect the changes as well so that what is
in os/ or in os.newkey/ meets what each of the ISO expects? I guess this
is primarily relevant to respins, netinstalls and so forth, as the old
RPM-GPG-KEYs will be in the root of those ISOs and I can only presume
they are used, and people will want to use os.newkey/ as the tree to
install from.


Has creating/composing an entirely new 9.1/ release tree been
considered? I guess recreating the entire release tree is a PITA (jigdo,
iso, torrent, foo) even though updates would not be included other then
maybe the updated fedora-release package (with the new rpm-gpg-keys and
new repo configuration files)?


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-28-2008, 11:59 PM
Jesse Keating
 
Default New Key Repo Locations

On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:
> If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also
> excluded? If it's not, then I guess there's no point in the new
> directory being created either.

Yes, if 9 is excluded (or included) that means the admin either doesn't
care about 9 and doesn't want to mirror it, or explicitly cares about it
and only wants to mirror it. Either way I wish to honor those choices
by not changing the top level directory where "9" or "8" will be. This
also means we won't have to re-file our export approval.

>
> Will the ISOs be respun to reflect the changes as well so that what is
> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this
> is primarily relevant to respins, netinstalls and so forth, as the old
> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume
> they are used, and people will want to use os.newkey/ as the tree to
> install from.

At this time, the isos will not be respun. We will however re-sign the
SHA1SUM file with the new gpg key. We are certain that the content on
the ISOs (and the numerous hard copies floating about) are safe. The
only content to be left in the repos these isos will be able to access
out of the box will be the transition fedora-update release, and the
fixed packagekit for gpg importing. We'll also have mirrormanager
direct all requests for the old dir directly to mirrors which we have
ultimate control over.

>
> Has creating/composing an entirely new 9.1/ release tree been
> considered? I guess recreating the entire release tree is a PITA (jigdo,
> iso, torrent, foo) even though updates would not be included other then
> maybe the updated fedora-release package (with the new rpm-gpg-keys and
> new repo configuration files)?

It was considered briefly, but not very much. Calling something 9.1
would also have a bit of an assumption that we've fixed some bugs or
otherwise made it a better release, which we aren't doing. We're merely
re-signing content and placing it in a slightly different directory, but
it's still 9, not 9+something. (ditto 8)

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 12:12 AM
"Jon Stanley"
 
Default New Key Repo Locations

Sorry for the top post, I'm on my crackberry. We need to male sure to
CLEARLY communicate this to mirror admins. I'm sure that more than 1
excludes releases/9/ since it is considered to be static content after
release in order to reduce the number of files for rsync to consider.



On 8/28/08, Jesse Keating <jkeating@redhat.com> wrote:
> On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:
>> If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also
>> excluded? If it's not, then I guess there's no point in the new
>> directory being created either.
>
> Yes, if 9 is excluded (or included) that means the admin either doesn't
> care about 9 and doesn't want to mirror it, or explicitly cares about it
> and only wants to mirror it. Either way I wish to honor those choices
> by not changing the top level directory where "9" or "8" will be. This
> also means we won't have to re-file our export approval.
>
>>
>> Will the ISOs be respun to reflect the changes as well so that what is
>> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this
>> is primarily relevant to respins, netinstalls and so forth, as the old
>> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume
>> they are used, and people will want to use os.newkey/ as the tree to
>> install from.
>
> At this time, the isos will not be respun. We will however re-sign the
> SHA1SUM file with the new gpg key. We are certain that the content on
> the ISOs (and the numerous hard copies floating about) are safe. The
> only content to be left in the repos these isos will be able to access
> out of the box will be the transition fedora-update release, and the
> fixed packagekit for gpg importing. We'll also have mirrormanager
> direct all requests for the old dir directly to mirrors which we have
> ultimate control over.
>
>>
>> Has creating/composing an entirely new 9.1/ release tree been
>> considered? I guess recreating the entire release tree is a PITA (jigdo,
>> iso, torrent, foo) even though updates would not be included other then
>> maybe the updated fedora-release package (with the new rpm-gpg-keys and
>> new repo configuration files)?
>
> It was considered briefly, but not very much. Calling something 9.1
> would also have a bit of an assumption that we've fixed some bugs or
> otherwise made it a better release, which we aren't doing. We're merely
> re-signing content and placing it in a slightly different directory, but
> it's still 9, not 9+something. (ditto 8)
>
> --
> Jesse Keating
> Fedora -- Freedom˛ is a feature!
> identi.ca: http://identi.ca/jkeating
>

--
Sent from Gmail for mobile | mobile.google.com

Jon Stanley
Fedora Bug Wrangler
jstanley@fedoraproject.org

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 12:22 AM
Jesse Keating
 
Default New Key Repo Locations

On Thu, 2008-08-28 at 20:12 -0400, Jon Stanley wrote:
> Sorry for the top post, I'm on my crackberry. We need to male sure to
> CLEARLY communicate this to mirror admins. I'm sure that more than 1
> excludes releases/9/ since it is considered to be static content after
> release in order to reduce the number of files for rsync to consider.

Yes, of course, this wouldn't be a silent change.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 12:32 AM
Jeroen van Meeuwen
 
Default New Key Repo Locations

Jesse Keating wrote:

On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:
If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also
excluded? If it's not, then I guess there's no point in the new
directory being created either.


Yes, if 9 is excluded (or included) that means the admin either doesn't
care about 9 and doesn't want to mirror it, or explicitly cares about it
and only wants to mirror it. Either way I wish to honor those choices
by not changing the top level directory where "9" or "8" will be. This
also means we won't have to re-file our export approval.



So, if 9/ is excluded from, say, the hourly sync a mirror does (since it
only needs to be mirrored once), the os.newkey/ won't end up on the
mirror, which is my primary concern. (I guess this has been answered,
partly, in another reply in this thread already).


Will the ISOs be respun to reflect the changes as well so that what is
in os/ or in os.newkey/ meets what each of the ISO expects? I guess this
is primarily relevant to respins, netinstalls and so forth, as the old
RPM-GPG-KEYs will be in the root of those ISOs and I can only presume
they are used, and people will want to use os.newkey/ as the tree to
install from.


At this time, the isos will not be respun. We will however re-sign the
SHA1SUM file with the new gpg key. We are certain that the content on
the ISOs (and the numerous hard copies floating about) are safe. The
only content to be left in the repos these isos will be able to access
out of the box will be the transition fedora-update release, and the
fixed packagekit for gpg importing. We'll also have mirrormanager
direct all requests for the old dir directly to mirrors which we have
ultimate control over.



I'm not sure how that solves the net install use case, especially if
mirrormanager is going to redirect to os.newkey/, as signatures used on
os.newkey/ packages will not meet what the installer expects the
signature to be on these files.


For the other part, where mirrormanager directs requests to mirrors we
have ultimate control over... is this going to interfere with the local
mirrors someone like myself may have set up at home and at multiple
customer sites? E.g., will clients in these netblocks be redirected to
mirrors the Fedora Project has ultimate control over, or am I
misunderstanding what you are saying?


Has creating/composing an entirely new 9.1/ release tree been
considered? I guess recreating the entire release tree is a PITA (jigdo,
iso, torrent, foo) even though updates would not be included other then
maybe the updated fedora-release package (with the new rpm-gpg-keys and
new repo configuration files)?


It was considered briefly, but not very much. Calling something 9.1
would also have a bit of an assumption that we've fixed some bugs or
otherwise made it a better release, which we aren't doing. We're merely
re-signing content and placing it in a slightly different directory, but
it's still 9, not 9+something. (ditto 8)



This sounds to me like a not-really-technical argument. You're right in
that the naming in releases/X.Y does imply a new and improved install
tree. I think there's some other serious consequences to choosing to do
it in the original X/ release tree though. I'm thinking, who gives a c*
that there's not actually 'new and improved' content in the trees even
though the naming suggests that there is, while it does carry an
entirely new tree with ISOs and jigdo's and stuff that have the new
signed content and make a full match between what you download and what
you start using, like with a normal release.


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 03:53 AM
Jesse Keating
 
Default New Key Repo Locations

On Fri, 2008-08-29 at 02:32 +0200, Jeroen van Meeuwen wrote:
> I'm not sure how that solves the net install use case, especially if
> mirrormanager is going to redirect to os.newkey/, as signatures used on
> os.newkey/ packages will not meet what the installer expects the
> signature to be on these files.

See bug 998. Installer doesn't expect keys.

> For the other part, where mirrormanager directs requests to mirrors we
> have ultimate control over... is this going to interfere with the local
> mirrors someone like myself may have set up at home and at multiple
> customer sites? E.g., will clients in these netblocks be redirected to
> mirrors the Fedora Project has ultimate control over, or am I
> misunderstanding what you are saying?

It's only for the queries for the old location. This drives all queries
for the old locations to our server so that we can get them the
transition fedora-release, pk and nothing else. Once they get the new
fedora-release, they'll be hitting the new url, which mirror manager
will do the normal thing, drive them to site local, or drive them to geo
locations. As to what to do about site local mirrors for the old
location, I don't think that has been fully discussed, that's probably a
good item for nit-picking.

>
> >> Has creating/composing an entirely new 9.1/ release tree been
> >> considered? I guess recreating the entire release tree is a PITA (jigdo,
> >> iso, torrent, foo) even though updates would not be included other then
> >> maybe the updated fedora-release package (with the new rpm-gpg-keys and
> >> new repo configuration files)?
> >
> > It was considered briefly, but not very much. Calling something 9.1
> > would also have a bit of an assumption that we've fixed some bugs or
> > otherwise made it a better release, which we aren't doing. We're merely
> > re-signing content and placing it in a slightly different directory, but
> > it's still 9, not 9+something. (ditto 8)
> >
>
> This sounds to me like a not-really-technical argument. You're right in
> that the naming in releases/X.Y does imply a new and improved install
> tree. I think there's some other serious consequences to choosing to do
> it in the original X/ release tree though. I'm thinking, who gives a c*
> that there's not actually 'new and improved' content in the trees even
> though the naming suggests that there is, while it does carry an
> entirely new tree with ISOs and jigdo's and stuff that have the new
> signed content and make a full match between what you download and what
> you start using, like with a normal release.

It's a lot of work for little gain. What you're downloading, the isos,
and what you start using, the content from the isos, will be matching,
the same. It's the updates or extra packages you install after that
which will have a new key on them. Rpm doesn't currently possess a way
to verify the GPG keys on installed packages, so I'm told, so those
installed from isos having the old key doesn't much matter. It's the
new packages one would fetch over the internet that matter.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 04:15 AM
Warren Togami
 
Default New Key Repo Locations

Jeroen van Meeuwen wrote:
Will the ISOs be respun to reflect the changes as well so that what is
in os/ or in os.newkey/ meets what each of the ISO expects? I guess this
is primarily relevant to respins, netinstalls and so forth, as the old
RPM-GPG-KEYs will be in the root of those ISOs and I can only presume
they are used, and people will want to use os.newkey/ as the tree to
install from.

At this time, the isos will not be respun. We will however re-sign the
SHA1SUM file with the new gpg key. We are certain that the content on
the ISOs (and the numerous hard copies floating about) are safe. The
only content to be left in the repos these isos will be able to access
out of the box will be the transition fedora-update release, and the
fixed packagekit for gpg importing. We'll also have mirrormanager
direct all requests for the old dir directly to mirrors which we have
ultimate control over.



I'm not sure how that solves the net install use case, especially if
mirrormanager is going to redirect to os.newkey/, as signatures used on
os.newkey/ packages will not meet what the installer expects the
signature to be on these files.




You misunderstand the New Key plan. Mirrormanager for the existing
repos fedora, updates and updates-testing will not redirect to the new
location. Please read the plan again carefully.


Warren Togami
wtogami@redhat.com

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 08-29-2008, 08:14 AM
Axel Thimm
 
Default New Key Repo Locations

On Fri, Aug 29, 2008 at 12:15:23AM -0400, Warren Togami wrote:
> Jeroen van Meeuwen wrote:
>> I'm not sure how that solves the net install use case, especially if
>> mirrormanager is going to redirect to os.newkey/, as signatures used on
>> os.newkey/ packages will not meet what the installer expects the
>> signature to be on these files.
>>
>
> You misunderstand the New Key plan. Mirrormanager for the existing
> repos fedora, updates and updates-testing will not redirect to the new
> location. Please read the plan again carefully.

Hi,

where can this plan be read, I didn't see it in this list or any URL
pointing to it.

W/o knowing all details, why not move os to os.oldkey and use os as
the new key's content? If the key is considered compromised what
mirror admin would like to keep the old signed packages around anyhow?
--
Axel.Thimm at ATrpms.net
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 

Thread Tools




All times are GMT. The time now is 04:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org