Is there a process for finding status updates to open bugs within Centos? The particular bug I am talking about is 0002329 http://bugs.centos.org/view.php?id=2329. This was assigned on 01-20-2008 and, as far as I can tell, there's been no action other than it being acknowledged. I've also searched upstream with RHEL and FC and I cannot seem to find a bug report there though complaints of the problem can be found through searching the web.
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official". So I have two questions:
1) Is there an "official" or "accepted" way to inquire about the status of an open bug? 2) With regard to bug 0002329 is this something that has to be fixed upstream so it filters down to centos?
Thank you!
Eucke
on 1-8-2009 1:28 PM Warren, Eucke spake the following:
Is there a process for finding status updates to open bugs within Centos? The particular bug I am talking about is 0002329 http://bugs.centos.org/view.php?id=2329. This was assigned on 01-20-2008 and, as far as I can tell, there's been no action other than it being acknowledged. I've also searched upstream with RHEL and FC and I cannot seem to find a bug report there though complaints of the problem can be found through searching the web.
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official". So I have two questions:
- Is there an "official" or "accepted" way to inquire about the status
of an open bug? 2) With regard to bug 0002329 is this something that has to be fixed upstream so it filters down to centos?
Thank you!
Eucke
The bug page gives you the status. It was assigned (to Karanbir), and he ack'ed it. If it was fixed, it would be resolved. It shouldn't be that hard to apply the fix manually and your legal department is too rigid if they are that picky about a fix to "free" software. I can see if they were paying contract support on it.
If Karanbir thinks it merits an upstream bug report, I'm almost sure he might do that, if the original bug poster doesn't. It "might" be fixed by the time 5.3 comes out, but do you want to wait?
on 1-8-2009 2:33 PM Scott Silva spake the following:
on 1-8-2009 1:28 PM Warren, Eucke spake the following:
Is there a process for finding status updates to open bugs within Centos? The particular bug I am talking about is 0002329 http://bugs.centos.org/view.php?id=2329. This was assigned on 01-20-2008 and, as far as I can tell, there's been no action other than it being acknowledged. I've also searched upstream with RHEL and FC and I cannot seem to find a bug report there though complaints of the problem can be found through searching the web.
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official". So I have two questions:
- Is there an "official" or "accepted" way to inquire about the status
of an open bug? 2) With regard to bug 0002329 is this something that has to be fixed upstream so it filters down to centos?
Thank you!
Eucke
The bug page gives you the status. It was assigned (to Karanbir), and he ack'ed it. If it was fixed, it would be resolved. It shouldn't be that hard to apply the fix manually and your legal department is too rigid if they are that picky about a fix to "free" software. I can see if they were paying contract support on it.
If Karanbir thinks it merits an upstream bug report, I'm almost sure he might do that, if the original bug poster doesn't. It "might" be fixed by the time 5.3 comes out, but do you want to wait?
So it is a year old... people get busy... ;-P
It must be of a low enough priority to not get a lot of attention.
On Thu, 8 Jan 2009, Scott Silva wrote:
on 1-8-2009 1:28 PM Warren, Eucke spake the following:
Is there a process for finding status updates to open bugs within Centos?
-- view it in a web browser, and optionally 'monitor' it so emails of updated state are received
-- offer to buy support from the the project or person it is assigned to, if really important [not likely and really CentOS is not interested in competing with the upstream]
-- buy enough upstream subscriptions to get assigned a TAC [and watch the report get triaged down to irrelevance ;) ]
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official".
official from centos means:
http://mirror.centos.org/centos-5/5/os/i386/EULA
Have fun watching legal and finance fight.
It must be of a low enough priority to not get a lot of attention.
Also, anyone who is on the upstream anaconda and kickstart mailing lists has seen this issue reported and debated, and more importantly knows that anaconda is tailored to each major release upstream.
Frankly, it is generally not worth fixing nor materially addressing with upstream without lots of TAC interest and firepower, as the patches be ignored, and will rot like fruit in the hot Sun (or be refactored away as it is so closely tied to the then underlying Python's quirks) ;)
-- Russ herrold
Scott Silva wrote:
The bug page gives you the status. It was assigned (to Karanbir), and
he ack'ed it. If it was fixed, it would
be resolved. It shouldn't be that hard to apply the fix manually and
your legal department is too rigid if they
are that picky about a fix to "free" software. I can see if they were
paying contract support on it.
I appreciate the response. If you recall I did post the link so it's a safe assumption that I read the page and understood it's content. What I'm after is whether there's any other information channel that might not be so obvious for seeing if there might be action coming up for an particular issue. Being in a highly regulated industry the legal department has a tough job. I work within the guidelines they set.
If Karanbir thinks it merits an upstream bug report, I'm almost sure
he might do that, if the original bug
poster doesn't. It "might" be fixed by the time 5.3 comes out, but do you want to wait?
I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 isn't an option either. Once I can sort out whether something "official" will fix this I can then determine how to pursue this internally. A workaround fix does not address that the kickstart-built system will still contain this bug as it will be built from RPM's that are not fixed.
Eucke
On Thu, Jan 8, 2009 at 6:14 PM, Warren, Eucke EWarren@wms.com wrote: <snip>
I appreciate the response. If you recall I did post the link so it's a safe assumption that I read the page and understood it's content. What I'm after is whether there's any other information channel that might not be so obvious for seeing if there might be action coming up for an particular issue. Being in a highly regulated industry the legal department has a tough job. I work within the guidelines they set.
If Karanbir thinks it merits an upstream bug report, I'm almost sure
he might do that, if the original bug
poster doesn't. It "might" be fixed by the time 5.3 comes out, but do you want to wait?
I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 isn't an option either.
Does that mean that your Legal Department does not permit you to upgrade your box, to get the latest packages, issued for Security & Stability reasons? 5.1, as you are well aware, is not the latest and greatest.
Lanny Marcus Wrote:
Does that mean that your Legal Department does not permit you to
upgrade your box, to get the latest packages,
issued for Security & Stability reasons? 5.1, as you are well aware,
is not the latest and greatest.
That is correct. What they approve is based on the contents of the DVD or CD for a particular version at the time of initial release. The governmental regulatory framework in which we work is what drives the requirements. I am well aware that 5.1 is not the latest, greatest, current or anything else of that matter.
Eucke
Warren, Eucke wrote:
Lanny Marcus Wrote:
Does that mean that your Legal Department does not permit you to
upgrade your box, to get the latest packages,
issued for Security & Stability reasons? 5.1, as you are well aware,
is not the latest and greatest.
That is correct. What they approve is based on the contents of the DVD or CD for a particular version at the time of initial release. The governmental regulatory framework in which we work is what drives the requirements. I am well aware that 5.1 is not the latest, greatest, current or anything else of that matter.
so you're not allowed to apply security patches or updates? because, just as soon as you
# yum update
you're on whatever is latest for the major version you're running, regardless of what point release you initially installed.
On Jan 8, 2009, at 6:35 PM, "Warren, Eucke" EWarren@wms.com wrote:
Lanny Marcus Wrote:
Does that mean that your Legal Department does not permit you to
upgrade your box, to get the latest packages,
issued for Security & Stability reasons? 5.1, as you are well aware,
is not the latest and greatest.
That is correct. What they approve is based on the contents of the DVD or CD for a particular version at the time of initial release. The governmental regulatory framework in which we work is what drives the requirements. I am well aware that 5.1 is not the latest, greatest, current or anything else of that matter.
Is your legal group aware that your company/agency has opened itself up to the risks of litigation in the event any customer or emloyee information is stolen due to negligent security practices?
Failure to apply the provided security patches for an OS is considered negligent.
This applies to internal security breaches as well as external.
I seriously doubt your legal group understands the regulatory issues properly.
-Ross
I appreciate the input on this question from those who have made suggestions. As the unofficial "fix" for %post does not change the target build (as the anaconda rpms are untouched) I will move in that direction. Those of you speculating will have to accept that there is much I cannot share and much of which you do not know about the systems and target environment. To suggest a "shaming" only makes the Centos community look bad as it would be done so without understanding the entire environment and situation. Thank you.
Eucke
On Fri, 9 Jan 2009, Warren, Eucke wrote:
... To suggest a "shaming" only makes the Centos community look bad as it would be done so without understanding the entire environment and situation.
Thank you for the restrained reply, Eucke
Wearing my '@centos.org' hat, let me add that I strongly concur to the effect that 'shaming' on a mailing list is probably not something to encourage; advising as to better practice, or better, simply staying still if one has nothing new to add are often fine responses to some posts.
We have a place to use social pressure toward education and growth as a sysadmin, in the ground rules of avoiding 'spoonfeeding' in the #centos IRC channel, and that's about all; we have not had inquiries there yet about 'baby mulching machines or atomic bombs' [1], but I suppose we would answer the centos 'on topic' part. We would send the off topic away, either to #centos-social (if it looked like we conld amuse that channel), or to a more appropirate venue for remaining off topic matter.
-- Russ herrold
on 1-8-2009 3:14 PM Warren, Eucke spake the following:
Scott Silva wrote:
The bug page gives you the status. It was assigned (to Karanbir), and
he ack'ed it. If it was fixed, it would
be resolved. It shouldn't be that hard to apply the fix manually and
your legal department is too rigid if they
are that picky about a fix to "free" software. I can see if they were
paying contract support on it.
I appreciate the response. If you recall I did post the link so it's a safe assumption that I read the page and understood it's content. What I'm after is whether there's any other information channel that might not be so obvious for seeing if there might be action coming up for an particular issue. Being in a highly regulated industry the legal department has a tough job. I work within the guidelines they set.
If Karanbir thinks it merits an upstream bug report, I'm almost sure
he might do that, if the original bug
poster doesn't. It "might" be fixed by the time 5.3 comes out, but do you want to wait?
I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 isn't an option either. Once I can sort out whether something "official" will fix this I can then determine how to pursue this internally. A workaround fix does not address that the kickstart-built system will still contain this bug as it will be built from RPM's that are not fixed.
Eucke
You might want to hint to your legal department that unpatched servers sitting on the internet are just waiting to be hacked and exploited. The fact that they make you sit with an older version without any patches says that they have no idea how much damage can be done, or how much info can leak from unpatched systems.
Maybe if a million customer records leak out because they won't let you patch systems they might update their thinking.
On Thu, Jan 8, 2009 at 6:33 PM, Scott Silva ssilva@sgvwater.com wrote:
on 1-8-2009 3:14 PM Warren, Eucke spake the following:
<snip>
I appreciate the response. If you recall I did post the link so it's a safe assumption that I read the page and understood it's content. What I'm after is whether there's any other information channel that might not be so obvious for seeing if there might be action coming up for an particular issue. Being in a highly regulated industry the legal department has a tough job. I work within the guidelines they set.
<snip>
I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 isn't an option either. Once I can sort out whether something "official" will fix this I can then determine how to pursue this internally. A workaround fix does not address that the kickstart-built system will still contain this bug as it will be built from RPM's that are not fixed.
You might want to hint to your legal department that unpatched servers sitting on the internet are just waiting to be hacked and exploited. The fact that they make you sit with an older version without any patches says that they have no idea how much damage can be done, or how much info can leak from unpatched systems.
Maybe if a million customer records leak out because they won't let you patch systems they might update their thinking.
Well said Scott. They are in the gambling business and I fully support what the Nevada Gaming Commission (or those in other states) does. However, I cannot imagine they want Software that has been updated for Security or Stability reasons not to be updated. http://www.wms.com/aboutwms.php Lanny
on 1-8-2009 3:41 PM Lanny Marcus spake the following:
On Thu, Jan 8, 2009 at 6:33 PM, Scott Silva ssilva-m4n3GYAQT2lWk0Htik3J/w@public.gmane.org wrote:
on 1-8-2009 3:14 PM Warren, Eucke spake the following:
<snip> >> I appreciate the response. If you recall I did post the link so it's a >> safe assumption that I read the page and understood it's content. What >> I'm after is whether there's any other information channel that might >> not be so obvious for seeing if there might be action coming up for an >> particular issue. Being in a highly regulated industry the legal >> department has a tough job. I work within the guidelines they set. >> <snip> >> I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 >> isn't an option either. Once I can sort out whether something >> "official" will fix this I can then determine how to pursue this >> internally. A workaround fix does not address that the kickstart-built >> system will still contain this bug as it will be built from RPM's that >> are not fixed.
You might want to hint to your legal department that unpatched servers sitting on the internet are just waiting to be hacked and exploited. The fact that they make you sit with an older version without any patches says that they have no idea how much damage can be done, or how much info can leak from unpatched systems.
Maybe if a million customer records leak out because they won't let you patch systems they might update their thinking.
Well said Scott. They are in the gambling business and I fully support what the Nevada Gaming Commission (or those in other states) does. However, I cannot imagine they want Software that has been updated for Security or Stability reasons not to be updated. http://www.wms.com/aboutwms.php Lanny
I thought the gaming industry used the IBM midrange equipment almost exclusively, or maybe that is only on their backend systems that actually control the machines.
Maybe the legal department doesn't realize that once updated, it is a different version. Many other people on this list have had that impression through the years.
Scott Silva wrote:
I thought the gaming industry used the IBM midrange equipment almost exclusively, or maybe that is only on their backend systems that actually control the machines.
FWIW, after a brief power failure at a local casino, I saw a Linux boot sequence being displayed on the screens of a lot of slot machines.
Scott Silva wrote:
You might want to hint to your legal department that unpatched servers
sitting on the internet are just waiting > to be hacked and exploited. The fact that they make you sit with an older version without any patches says that
they have no idea how much damage can be done, or how much info can
leak from unpatched systems.
Maybe if a million customer records leak out because they won't let
you patch systems they might update their thinking.
Not relevant. These machines are not tied to any public network. As much as I appreciate the commentary and lessons you're not telling me anything I'm not already aware of. I'm simply seeking some insight on this particular bug and, more generally, if there's a better way to find status on something like this. So far RP Herrold has helped most as I was not aware that there's been much conversation within anaconda and kickstart mailing lists.
Eucke
On Thu, Jan 8, 2009 at 6:14 PM, Warren, Eucke EWarren@wms.com wrote:
I am restricted to 5.1 as approved by legal. 5.2 is not approved so 5.3 isn't an option either. Once I can sort out whether something "official" will fix this I can then determine how to pursue this internally. A workaround fix does not address that the kickstart-built system will still contain this bug as it will be built from RPM's that are not fixed.
Eucke
OK -- I might be missing something here ... <my apologies, if so!>
You're running your own kickstart file, yes/no? And, running into this issue. Since you can control the ks.cfg, why not put into the %pre section something that copies the section of the CD that you need in the %post section to the RAM disk?? E.g.:
mkdir /tmp/source CDR=/mnt/cdrom; [ ! -d "$CDR" ] && mkdir -p "$CDR" DEV="/dev/$(sed -ne 's/.*trying to mount CD device //p' /tmp/anaconda.log)"
if [ -b "$DEV" ] ; then : elif [ -b /dev/cdrom ] ; then DEV=/dev/cdrom elif [ -b /dev/scd0 ] ; then DEV=/dev/scd0 elif [ -b /dev/hdd ] ; then DEV=/dev/hdd elif [ -b /dev/hdc ] ; then DEV=/dev/hdc elif [ -b /dev/hdb ] ; then DEV=/dev/hdb elif [ -b /dev/hda ] ; then DEV=/dev/hda else DEV=/tmp/cdrom fi
mount -r -t iso9660 "$DEV" "$CDR" && \ cp -rp $CDR/... /tmp/source/....
might give you some ideas ...
Remember ... you may be in a chroor'd env in the %post section, so you may need to have a non-chroot'd %post that copies the /tmp/source above to your built filesystems (e.g., /mnt/sysimage/tmp).
I hope that helps ..
-rak-
Warren, Eucke wrote:
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official". So I have two questions:
- Is there an "official" or "accepted"
way to inquire about the status of an open bug? 2) With regard to bug 0002329 is this something that has to be fixed upstream so it filters down to centos?
What company is this that doesn't wan't to pay for a support contract for RHEL but insists on using CentOS but requires "official fixes" only?
1. Can you name and shame this comapany it will make good reading on teh web. 2. Consider paying for RHEL so that you can actually get "official support" and can raise support tickets. 3. You probably don't understand what CentOS is or who is supposed to use it.
Regards, Vandaman. ------------------------------------------------------- Report another spam? Your average reporting time is: 3 hours; Great! ---- ---- ---- ---- ---- noob detector -> 15 noobs top-posting.
If you want a official fix then get your self a redhat license, nothing wrong with the excellent help that one can get from this list but by supporting redhat you also in my eyes support centos.
The only thing that I have noticed with RH support is that they are actually slower to release a fix or to come up with a fix then Centos, we have quite a few centos servers where I work and this was the reason for why we lowered our licenses to redhat and migrated some servers to Centos.
Per
On 1/9/09 10:04 AM, "Vandaman" vandaman2002-sk@yahoo.co.uk wrote:
Warren, Eucke wrote:
I do see the manual fix for it and will be testing that shortly. I am, however, dealing with a fairly rigid internal legal department that may not welcome a "fix" that's not "official". So I have two questions:
- Is there an "official" or "accepted"
way to inquire about the status of an open bug? 2) With regard to bug 0002329 is this something that has to be fixed upstream so it filters down to centos?
What company is this that doesn't wan't to pay for a support contract for RHEL but insists on using CentOS but requires "official fixes" only?
- Can you name and shame this comapany it will make good reading
on teh web. 2. Consider paying for RHEL so that you can actually get "official support" and can raise support tickets. 3. You probably don't understand what CentOS is or who is supposed to use it.
Regards, Vandaman.
Report another spam? Your average reporting time is: 3 hours; Great!
noob detector -> 15 noobs top-posting.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Per Qvindesland wrote:
If you want a official fix then get your self a redhat license, nothing wrong with the excellent help that one can get from this list but by supporting redhat you also in my eyes support centos.
The only thing that I have noticed with RH support is that they are actually slower to release a fix or to come up with a fix then Centos, we have quite a few centos servers where I work and this was the reason for why we lowered our licenses to redhat and migrated some servers to Centos.
You might want to read up on why top-posting is disallowed on many mailing lists. Even after sending you a polite offlist reminder and a link to the guidelines you are still top-posting.
With regard to your wrong claim that "upstream support is slower to release a fix than CentOS" I would ask you the following simple question :-
1. What is CentOS and where does it come from? 2. Which fix is this that CentOS released before upstream?
Regards, Vandaman. ------------------------------------------------------- Report another spam? Your average reporting time is: 3 hours; Great! ---- ---- ---- ---- ---- noob detector -> 15 noobs top-posting.
Vandaman wrote:
What company is this that doesn't wan't to pay for a support contract for RHEL but insists on using CentOS but requires "official fixes" only?
- Can you name and shame this comapany it will make good reading
on teh web.
a casino gaming machine manufacturer. their website has the same domain as his email address. video slot machines. poker machines. etc.
-
John R Pierce -
Lanny Marcus -
Per Qvindesland -
R P Herrold -
Richard Karhuse -
Robert Nichols -
Ross Walker -
Scott Silva -
Vandaman -
Warren, Eucke