Just to inform that some *debuginfo* packages have landed on some mirrors. For example the latest kernel 2.6.18-128.1.6.el5 (and all his variants) has the corresponding debuginfo package. I just saw that when i updated my local tree at home and was wondering why it was so slow just to fetch the latest kernel rpms .. of course with ~150mb of debuginfo per kernel variant , that makes the difference .. :D
example : http://mirrors.ircam.fr/pub/CentOS/5.3/updates/i386/RPMS/
On Thursday 02 April 2009, Fabian Arrotin wrote:
Just to inform that some *debuginfo* packages have landed on some mirrors. For example the latest kernel 2.6.18-128.1.6.el5 (and all his variants) has the corresponding debuginfo package. I just saw that when i updated my local tree at home and was wondering why it was so slow just to fetch the latest kernel rpms .. of course with ~150mb of debuginfo per kernel variant , that makes the difference .. :D
example : http://mirrors.ircam.fr/pub/CentOS/5.3/updates/i386/RPMS/
I see it on our mirror too (mirror.nsc.liu.se). On top of that mishap none of the debuginfo is yet available where it should be (debuginfo.centos.org and mirrors for that).
/Peter
Peter Kjellstrom wrote:
example : http://mirrors.ircam.fr/pub/CentOS/5.3/updates/i386/RPMS/
I see it on our mirror too (mirror.nsc.liu.se). On top of that mishap none of the debuginfo is yet available where it should be (debuginfo.centos.org and mirrors for that).
the files were only there for a short while and removed a long time back, are your mirrors lagging so far out ?
- KB
Karanbir Singh wrote:
the files were only there for a short while and removed a long time back, are your mirrors lagging so far out ?
Nope, we (mirror.nsc.liu.se) get those packages from the CentOS msync-dvd mirrors. I just verified that the files are present on both centose and centosj3 which is the ones our rsync usually hit.
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
Regards,
Pär Andersson NSC
Pär Andersson wrote:
Nope, we (mirror.nsc.liu.se) get those packages from the CentOS msync-dvd mirrors. I just verified that the files are present on both centose and centosj3 which is the ones our rsync usually hit.
Let me investigate this issue - the packages are definitely gone from the repo-head.
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
Thats a diff issue all together :) It does mean adding to the overall weight of the main repo's quite a lot though.
- KB
On Fri, 2009-04-03 at 18:18 +0200, Pär Andersson wrote:
Karanbir Singh wrote:
the files were only there for a short while and removed a long time back, are your mirrors lagging so far out ?
Nope, we (mirror.nsc.liu.se) get those packages from the CentOS msync-dvd mirrors. I just verified that the files are present on both centose and centosj3 which is the ones our rsync usually hit.
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
If you start shipping base-debuginfo disable, then someone might want to add the plugin-auto-debug-info package to CentOS:
http://yum.baseurl.org/gitweb?p=yum-utils.git;a=tree;f=plugins/auto-update-d...
...to take care of updates.
On Fri, 2009-04-03 at 18:18 +0200, Pär Andersson wrote: ...
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
Added debuginfo info to a couple of Wiki pages as this has also come up on Forum posts recently:
http://wiki.centos.org/AdditionalResources/Repositories http://wiki.centos.org/FAQ/General#head-92ba307b036080a16dbffa44486cde25c081...
Phil
On 04/03/2009 05:18 PM, Pär Andersson wrote:
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
btw, does the kernel-debug not give you already everything that is needed for systemtap/oprofile ? thats already there in the main distro tree.
On Sat, 2009-04-04 at 00:24 +0100, Karanbir Singh wrote:
On 04/03/2009 05:18 PM, Pär Andersson wrote:
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
btw, does the kernel-debug not give you already everything that is needed for systemtap/oprofile ? thats already there in the main distro tree.
Not sufficient for crash which is where I last came up against it. It needs vmlinux.
Phil
On Saturday 04 April 2009, Karanbir Singh wrote:
On 04/03/2009 05:18 PM, Pär Andersson wrote:
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
btw, does the kernel-debug not give you already everything that is needed for systemtap/oprofile ? thats already there in the main distro tree.
kernel-debug is not at all what I typically want when I go looking for kernel-debuginfo. What I want is to run tools (like oprofile and systemtap) on that (running) system right there and then. Ideally that should go something like this:
1) uuh, I need to run this .stp-script 2) stap xxx.stp
But since the kernel-debuginfo, kernel-devel may typically be missing for the running kernel the following step would have to be done between 1 and 2:
1.5) yum install kernel-debuginfo kernel-devel
But since we today lack a yumified way of doing this the step above typically turns into:
* look for a mirror that has debuginfo (sometimes it stops here with debuginfo for the kernel missing) * download manually * install manually (including ignoring the fact that debuginfo packages are unsigned...)
So I guess the good news is that here we have a part of CentOS with great potential for improvements :-)
/Peter
Hello Peter,
On Mon, Apr 06, 2009 at 11:04:13AM +0200, Peter Kjellstrom wrote:
On Saturday 04 April 2009, Karanbir Singh wrote:
On 04/03/2009 05:18 PM, Pär Andersson wrote:
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
btw, does the kernel-debug not give you already everything that is needed for systemtap/oprofile ? thats already there in the main distro tree.
kernel-debug is not at all what I typically want when I go looking for kernel-debuginfo. What I want is to run tools (like oprofile and systemtap) on that (running) system right there and then. Ideally that should go something like this:
- uuh, I need to run this .stp-script
- stap xxx.stp
But since the kernel-debuginfo, kernel-devel may typically be missing for the running kernel the following step would have to be done between 1 and 2:
1.5) yum install kernel-debuginfo kernel-devel
But since we today lack a yumified way of doing this the step above typically turns into:
- look for a mirror that has debuginfo (sometimes it stops here with debuginfo
for the kernel missing)
I just add http://debuginfo.centos.org/$releasever/$basearch/ as a new repo into all CentOS installs. Disabled by default, but prepared to download rpms from if I need to.
- download manually
- install manually (including ignoring the fact that debuginfo packages are
unsigned...)
Hope this can be changed, but no idea where in the process this needs to be.
So I guess the good news is that here we have a part of CentOS with great potential for improvements :-)
I think it is very good to keep the debuginfo separate from the rest of the mirror system to not overload mirrors. Question will be on how that scales with more and more people accessing debuginfo.centos.org.
regards,
Florian La Roche
Florian La Roche wrote:
- look for a mirror that has debuginfo (sometimes it stops here with debuginfo
for the kernel missing)
I just add http://debuginfo.centos.org/$releasever/$basearch/ as a new repo into all CentOS installs. Disabled by default, but prepared to download rpms from if I need to.
With things setup the way they are - network distance from debuginfo to the head-node is ~ 400KiB/sec which means that sometimes it takes a very long time to sync the debuginfo's into the right place. eg. the sync for 5.3 started on Sat morning, its about 35% of the way through.
Something to definitely consider / reconsider.
- download manually
- install manually (including ignoring the fact that debuginfo packages are
unsigned...)
Hope this can be changed, but no idea where in the process this needs to be.
Change which part ? signing them or automating something ? The reason debuginfo's are not signed is that bringing them into a securebox for the signing process and pushing them out again easily triples the time factor.
I think it is very good to keep the debuginfo separate from the rest of the mirror system to not overload mirrors. Question will be on how that scales with more and more people accessing debuginfo.centos.org.
At the moment, there are 2 internal and 1 external mirror for debuginfo - that can be increased if required. I know that atleast mirrorservice and kernel.org have previously said that they will make more space available to centos.org if we need it on their mirrors - and they are happy to host vhost's for debuginfo / beta's.
- KB
Hello Karanbir Singh,
On Mon, Apr 06, 2009 at 10:53:27AM +0100, Karanbir Singh wrote:
Florian La Roche wrote:
- look for a mirror that has debuginfo (sometimes it stops here with debuginfo
for the kernel missing)
I just add http://debuginfo.centos.org/$releasever/$basearch/ as a new repo into all CentOS installs. Disabled by default, but prepared to download rpms from if I need to.
With things setup the way they are - network distance from debuginfo to the head-node is ~ 400KiB/sec which means that sometimes it takes a very long time to sync the debuginfo's into the right place. eg. the sync for 5.3 started on Sat morning, its about 35% of the way through.
Something to definitely consider / reconsider.
- download manually
- install manually (including ignoring the fact that debuginfo packages are
unsigned...)
Hope this can be changed, but no idea where in the process this needs to be.
Change which part ? signing them or automating something ? The reason debuginfo's are not signed is that bringing them into a securebox for the signing process and pushing them out again easily triples the time factor.
Ok, thanks for the info.
I think it is very good to keep the debuginfo separate from the rest of the mirror system to not overload mirrors. Question will be on how that scales with more and more people accessing debuginfo.centos.org.
At the moment, there are 2 internal and 1 external mirror for debuginfo
- that can be increased if required. I know that atleast mirrorservice
and kernel.org have previously said that they will make more space available to centos.org if we need it on their mirrors - and they are happy to host vhost's for debuginfo / beta's.
Then maybe with an official upstream there could be an official mirrorlist repo with something like "repo=debuginfo".
Maybe also older CentOS releases could be archived in a similar fashion and get some official location as well.
regards,
Florian La Roche
Florian La Roche wrote:
Then maybe with an official upstream there could be an official mirrorlist repo with something like "repo=debuginfo".
Something to consider for sure.
Maybe also older CentOS releases could be archived in a similar fashion and get some official location as well.
there is vault.centos.org
- KB
Karanbir Singh wrote:
Change which part ? signing them or automating something ? The reason debuginfo's are not signed is that bringing them into a securebox for the signing process and pushing them out again easily triples the time factor.
Personally I would rather wait even longer if that meant signed packages. Of course it would not be an ideal solution, but I think the security risk of installing unsigned packages is much worse than the inconvenience of waiting.
Also this would only be a big problem at release time, for ordinary updates the delay should not be that bad.
At the moment, there are 2 internal and 1 external mirror for debuginfo
- that can be increased if required. I know that atleast mirrorservice
and kernel.org have previously said that they will make more space available to centos.org if we need it on their mirrors - and they are happy to host vhost's for debuginfo / beta's.
If disk space on mirrors is a problem you could separate the debuginfo into one directory per release, and move older ones to vault.centos.org.
Regards,
Pär Andersson National Supercomputer Centre, Sweden
On Fri, 10 Apr 2009, Pär Andersson wrote:
Karanbir Singh wrote:
Change which part ? signing them or automating something ? The reason debuginfo's are not signed is that bringing them into a securebox for the signing process and pushing them out again easily triples the time factor.
Personally I would rather wait even longer if that meant signed packages. Of course it would not be an ideal solution, but I think the security risk of installing unsigned packages is much worse than the inconvenience of waiting.
It's not obvious to me what the attack vector would be with unsigned debuginfo packages...
Charlie Brady wrote:
It's not obvious to me what the attack vector would be with unsigned debuginfo packages...
1. Get people to download packages from you instead of the real debuginfo.centos.org by a MITM attack, DNS poisoning or whatever.
2. Send modified malicious packages instead of the real ones. Debuginfo packages are (AFAIK) ordinary RPM packages so they can contain evil binaries, install a rootkit in their post-install script or something like that.
/Pär
On Mon, 2009-04-06 at 10:53 +0100, Karanbir Singh wrote:
Florian La Roche wrote:
- look for a mirror that has debuginfo (sometimes it stops here with debuginfo
for the kernel missing)
I just add http://debuginfo.centos.org/$releasever/$basearch/ as a new repo into all CentOS installs. Disabled by default, but prepared to download rpms from if I need to.
With things setup the way they are - network distance from debuginfo to the head-node is ~ 400KiB/sec which means that sometimes it takes a very long time to sync the debuginfo's into the right place. eg. the sync for 5.3 started on Sat morning, its about 35% of the way through.
Getting requests for current debuginfo packages. I there an ETA?
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=19719&forum=3...
Phil
Phil Schaffner wrote:
Getting requests for current debuginfo packages. I there an ETA? http://www.centos.org/modules/newbb/viewtopic.php?topic_id=19719&forum=3...
Rather than URLs' to context, be nice if there was some in the email so the conversation is semi complete. I have no idea whats on the other end of the URL in this case, but the debuginfo's should be online later today, they are all on the main mirror machine, just need putting into the right place, which should be done today.
- KB
On 04/15/2009 12:46 PM, Karanbir Singh wrote:
they are all on the main mirror machine, just need putting into the right place, which should be done today.
is now done.
On Wed, 2009-04-15 at 12:46 +0100, Karanbir Singh wrote:
Phil Schaffner wrote:
Getting requests for current debuginfo packages. I there an ETA? http://www.centos.org/modules/newbb/viewtopic.php?topic_id=19719&forum=3...
Rather than URLs' to context, be nice if there was some in the email so the conversation is semi complete. I have no idea whats on the other end of the URL in this case, but the debuginfo's should be online later today, they are all on the main mirror machine, just need putting into the right place, which should be done today.
OK... ------------------------------------------------------------------ mickrussom wrote: I need the debuginfo packages for:
kernel 2.6.18-128.1.6.el5 32-bit kernel 2.6.18-128.1.6.el5 32-bit PAE kernel 2.6.18-128.1.6.el5 x86_64 kernel-common debuginfo 2.6.18-128.1.6.el5
The files for -92- are there, but 2.6.18-128.1.6.el5, 2.6.18-128.1.1.el5, 2.6.18-128.el5 are not present.
Would be nice to see 2.6.18-128.1.6.el5 , as the other kernels are now out-of-date anyway. ------------------------------------------------------------------
however, ... # yum --disablerepo * --enablerepo debuginfo list available | grep kernel kernel-PAE-debuginfo.i686 2.6.18-92.1.22.el5.centos.plus kernel-debug-debuginfo.i686 2.6.18-92.1.22.el5 debuginfo kernel-debug-debuginfo.x86_64 2.6.18-92.1.22.el5 debuginfo kernel-debuginfo.i686 2.6.18-92.1.22.el5.centos.plus kernel-debuginfo.x86_64 2.6.18-92.1.22.el5.centos.plus kernel-debuginfo-common.i686 2.6.18-92.1.22.el5.centos.plus kernel-debuginfo-common.x86_64 2.6.18-92.1.22.el5.centos.plus kernel-xen-debuginfo.i686 2.6.18-92.1.22.el5.centos.plus kernel-xen-debuginfo.x86_64 2.6.18-92.1.22.el5.centos.plus
Phil
On 04/15/2009 10:53 PM, Phil Schaffner wrote:
I need the debuginfo packages for:
kernel 2.6.18-128.1.6.el5
these are also syncing out ( well, all the updates packages's debuginfo's are ) and should be visible within the next few hours. Keep in mind the update packages are pushed into the live system one package at a time, so they will start showing up a lot sooner.
On Monday 06 April 2009, Florian La Roche wrote:
Hello Peter,
On Mon, Apr 06, 2009 at 11:04:13AM +0200, Peter Kjellstrom wrote:
On Saturday 04 April 2009, Karanbir Singh wrote:
On 04/03/2009 05:18 PM, Pär Andersson wrote:
However I think having debuginfo packages for the kernel in the main repository would really be a good thing as tools like oprofile and systemtap (both in base) need kernel-debuginfo to be usable.
btw, does the kernel-debug not give you already everything that is needed for systemtap/oprofile ? thats already there in the main distro tree.
kernel-debug is not at all what I typically want when I go looking for kernel-debuginfo. What I want is to run tools (like oprofile and systemtap) on that (running) system right there and then. Ideally that should go something like this:
- uuh, I need to run this .stp-script
- stap xxx.stp
But since the kernel-debuginfo, kernel-devel may typically be missing for the running kernel the following step would have to be done between 1 and 2:
1.5) yum install kernel-debuginfo kernel-devel
But since we today lack a yumified way of doing this the step above typically turns into:
- look for a mirror that has debuginfo (sometimes it stops here with
debuginfo for the kernel missing)
I just add http://debuginfo.centos.org/$releasever/$basearch/ as a new repo into all CentOS installs. Disabled by default, but prepared to download rpms from if I need to.
Of course this can be fixed manually like this. My post was intended to start a discussion on a global (official) "fix".
My suggestion would be a disabled-by-default "debuginfo" in the CentOS-Base.repo file or like c5-testing in a different file.
- download manually
- install manually (including ignoring the fact that debuginfo packages
are unsigned...)
Hope this can be changed, but no idea where in the process this needs to be.
I think I've heard that it has to do with moving the built packages around so that they can be signed. Either way it would be nice to have it fixed.
So I guess the good news is that here we have a part of CentOS with great potential for improvements :-)
I think it is very good to keep the debuginfo separate from the rest of the mirror system to not overload mirrors. Question will be on how that scales with more and more people accessing debuginfo.centos.org.
Maybe it could be resolved like DVD images? That is, a subset of mirrors opt in to carry debuginfo. I don't think there'd be any problems finding enough mirrors (the traffic is much less that the normal mirror traffic).
/Peter
-
Charlie Brady -
Fabian Arrotin -
Florian La Roche -
James Antill -
Karanbir Singh -
Peter Kjellstrom -
Phil Schaffner -
Pär Andersson