Hey.
I was quite annoyed by the fact that one of my fully updated CentOS 5.3 boxes said "Red Hat" instead of CentOS when listing an empty dir with apache like this: http://flashdance.cx/tmp/ (said CentOS before) and http://www.flashdance.cx/tmp/ that said Red Hat.
Talked with some guys in #centos irc and alot of stuff was tested to see why it differ.
Then I realized that the one that still said CentOS hasnt been restarted since the box was rebooted, Jun16:
root 4747 0.0 0.1 17468 4836 ? Ss Jun16 0:01 /usr/sbin/httpd
thats why it still said CentOS! After restart of apache, it says Red Hat.
Now I dont have the previous httpd rpm file but I guess it happend with httpd-2.2.3-22.el5.centos.2 that I have installed now, ServerTokens isnt changed to CentOS in it.
It needs to be fixed :)
On 09/03/2009 09:14 AM, Peter Magnusson wrote:
thats why it still said CentOS! After restart of apache, it says Red Hat.
always a good idea to first go look at bugs.centos.org to see if your issue has already been reported, and if so - track that issue
On Thu, 3 Sep 2009, Karanbir Singh wrote:
On 09/03/2009 09:14 AM, Peter Magnusson wrote:
thats why it still said CentOS! After restart of apache, it says Red Hat.
always a good idea to first go look at bugs.centos.org to see if your issue has already been reported, and if so - track that issue
Its really boring and takes time but I'll report this for now... http://bugs.centos.org/view.php?id=3818
Question: Is there any point of reporting bugs that Red Hat itself got into bugs.centos.org? They are STILL bugs. CentOS can be better than Red hat. If so, I have more bugs to report (that I REALLY REALLY want to have fixed...).
No, I dont have any RHEL subscription. The other option will be to NOT report it to anyone.
On 09/03/2009 09:51 AM, Peter Magnusson wrote:
Its really boring and takes time but I'll report this for now... http://bugs.centos.org/view.php?id=3818
I dont think you actually read my last email, searching for it is not the same as reporting it. Go look once again, then close your new report as a dupe of the existing one.
Question: Is there any point of reporting bugs that Red Hat itself got into bugs.centos.org? They are STILL bugs. CentOS can be better than Red hat.
yes there is, if its not a local centos issue, its still good for people to be able to track it here, and yet be able to link upstream - in many cases, helping the upstream developers with testing and potential fix's.
If so, I have more bugs to report (that I REALLY REALLY want to have fixed...).
if you really really want them fixed, go out and buy a subscription to rhel. or propose patches along with the reports.
On Thu, 3 Sep 2009, Karanbir Singh wrote:
I dont think you actually read my last email, searching for it is not the same as reporting it. Go look once again, then close your new report as a dupe of the existing one.
Then I suggest a big SEARCH: directly on the front page so its possible to find stuff. Thats why I added a new, no search. Im quite used that bug tracking systems sucks so Im not suprised when I dont find a search. So I dont look too long to find one. Now I see that I get a Search when I click on "Unassigned" for example.
It cant possible be worse with a SEARCH directly on http://bugs.centos.org. I promise.
yes there is, if its not a local centos issue, its still good for people to be able to track it here, and yet be able to link upstream - in many cases, helping the upstream developers with testing and potential fix's.
Ok, then I'll do that.
if you really really want them fixed, go out and buy a subscription to rhel. or propose patches along with the reports.
No. However, if I happend to work where the company got a subscription to RHEL I WILL file a bug report. And will NOT GIVE UP until Redhat has fixed it. The damn bug has existed for like 5-10 years.
On 09/03/2009 10:29 AM, Peter Magnusson wrote:
It cant possible be worse with a SEARCH directly on http://bugs.centos.org. I promise.
try clicking on 'view issues', see that big box on the top'ish left side :)
if you really really want them fixed, go out and buy a subscription to rhel. or propose patches along with the reports.
No.
ok, dont be surprised if your reports just sit there with zero interest till someone who is interested enough to spend their spare time on the issues comes along.
On Thu, 3 Sep 2009, Karanbir Singh wrote:
On 09/03/2009 10:29 AM, Peter Magnusson wrote:
It cant possible be worse with a SEARCH directly on http://bugs.centos.org. I promise.
try clicking on 'view issues', see that big box on the top'ish left side :)
Yes there it is also. But still think a SEARCH directly on http://bugs.centos.org will be good :)
ok, dont be surprised if your reports just sit there with zero interest till someone who is interested enough to spend their spare time on the issues comes along.
Yes, thats why I havent reported it before.
On Thu, 3 Sep 2009, Karanbir Singh wrote:
ok, dont be surprised if your reports just sit there with zero interest till someone who is interested enough to spend their spare time on the issues comes along.
Done;
http://bugs.centos.org/view.php?id=3821 - KDE font problem Xdefaults exists http://bugs.centos.org/view.php?id=3822 - Network card order naming
Peter Magnusson wrote:
On Thu, 3 Sep 2009, Karanbir Singh wrote:
ok, dont be surprised if your reports just sit there with zero interest till someone who is interested enough to spend their spare time on the issues comes along.
Done;
http://bugs.centos.org/view.php?id=3821 - KDE font problem Xdefaults exists http://bugs.centos.org/view.php?id=3822 - Network card order naming
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
In an earlier post you also mentioned: "CentOS can be better than Red hat." I don't think that is the goal of CentOS, it would conflict with the goal of being a 100% compatible reproduction of the upstream OS. Adding custom patches would make CentOS deviate from upstream.
Anyway, the original topic, servertokens saying Red Hat, I personally wouldn't bother with it. There are more important things.
Glenn
Hi,
On Fri, Sep 4, 2009 at 16:38, Peter Magnussoniocc@centos.lists.flashdance.cx wrote:
On Fri, 4 Sep 2009, RedShift wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
It probably did not work because... oh, wait, my crystal ball is not working right now, so unfortunately I won't be able to help unless you actually give some information about what you tried, how did it not work, what the config files are, and other evidence such as logs and output of dmesg. Please consider posting this problem with the requested details to the main CentOS list.
And please lose the attitude, your posts and bug reports sound like you're ranting.
Thanks, Filipe
On 04/09/09 21:38, Peter Magnusson wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
are you saying that specifying the hwaddr still got you wrong device name allocations ? I find that quite hard to believe, unless you are doing some wierd bridging stuff and the nic's are not really using physical devices.
a bit more info about your setup would be good. on a usual machine, with usual nic's - I've never heard of hwaddr allocations going walkabout. ever.
- KB
Karanbir Singh wrote:
On 04/09/09 21:38, Peter Magnusson wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
are you saying that specifying the hwaddr still got you wrong device name allocations ? I find that quite hard to believe, unless you are doing some wierd bridging stuff and the nic's are not really using physical devices.
a bit more info about your setup would be good. on a usual machine, with usual nic's - I've never heard of hwaddr allocations going walkabout. ever.
Don't know about his situation but one place the concept is a real killer is when you ship an installed disk to a remote location to be plugged into a new identical box. Even on the times when I knew the MAC addresses and tried to preconfigure them, something would generally rename my prepared ifcfg-* files and generate new ones with an unwanted DCHP setting on the first boot.
On Fri, 4 Sep 2009, Karanbir Singh wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
are you saying that specifying the hwaddr still got you wrong device name allocations ? I find that quite hard to believe, unless you are doing some wierd bridging stuff and the nic's are not really using physical devices.
It was 1 year since it was installed so I dont remember exactly. But I have done some investigation and I GUESS that I didnt had HWADDR in ifcfg-* because of the dates of them:
-rw-r--r-- 1 root 109 Aug 9 2008 ifcfg-eth1 -rw-r--r-- 1 root 109 Aug 9 2008 ifcfg-eth2
The box was installed Aug 9 2008. I can not be sure however, they might have been there first and then removed.
I didnt play with any udev rules during the troubleshooting. What I did was playing around with hal and the file /etc/sysconfig/hwconf. I changed so it would be correct in it (there I filled in the right HWADDR) and hal changed it back after reboot. The fucker. So now hald is totally disabled on this box.
I didnt know about ifrename to be honest (http://bugs.centos.org/view.php?id=3822).
However, I still think this is a BAD DESIGN CHOICE and Im not changing that option no matter how it can be "fixed" with udev, ifrename or HWADDR in ifcfg-*. That wouldnt be needed if you would wait until ALL cards are detected and THEN name them.
I just wanted to say this, as my current workaround about this problem works I will not change it or tweak it (it needs to be working, or else I dont have any internet... or exists on internet).
Thats about it.
a bit more info about your setup would be good. on a usual machine, with usual nic's - I've never heard of hwaddr allocations going walkabout. ever.
CentOS release 5.3 - 2.6.26 Shuttle XPC SB52G2 Intel Celeron 2.4 GHz, 400 MHz FSB 512 MB, DDR PC2700 Maxtor 80 GB HD Bultin Intel Gigabit Ethernet Controller = My LAN Bultin Intel EtherExpress 10/100 Ethernet Controller = Transit1 PCI card EtherExpress 10/100 Ethernet Controller = Transit2 (from http://www.flashdance.cx/computers.html)
On 05/09/2009, Peter Magnusson iocc@centos.lists.flashdance.cx wrote:
On Fri, 4 Sep 2009, Karanbir Singh wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
are you saying that specifying the hwaddr still got you wrong device name allocations ? I find that quite hard to believe, unless you are doing some wierd bridging stuff and the nic's are not really using physical devices.
It was 1 year since it was installed so I dont remember exactly. But I have done some investigation and I GUESS that I didnt had HWADDR in ifcfg-* because of the dates of them:
-rw-r--r-- 1 root 109 Aug 9 2008 ifcfg-eth1 -rw-r--r-- 1 root 109 Aug 9 2008 ifcfg-eth2
The box was installed Aug 9 2008. I can not be sure however, they might have been there first and then removed.
I didnt play with any udev rules during the troubleshooting. What I did was playing around with hal and the file /etc/sysconfig/hwconf. I changed so it would be correct in it (there I filled in the right HWADDR) and hal changed it back after reboot. The fucker. So now hald is totally disabled on this box.
I didnt know about ifrename to be honest (http://bugs.centos.org/view.php?id=3822).
However, I still think this is a BAD DESIGN CHOICE and Im not changing that option no matter how it can be "fixed" with udev, ifrename or HWADDR in ifcfg-*. That wouldnt be needed if you would wait until ALL cards are detected and THEN name them.
I just wanted to say this, as my current workaround about this problem works I will not change it or tweak it (it needs to be working, or else I dont have any internet... or exists on internet).
Thats about it.
a bit more info about your setup would be good. on a usual machine, with usual nic's - I've never heard of hwaddr allocations going walkabout. ever.
CentOS release 5.3 - 2.6.26 Shuttle XPC SB52G2 Intel Celeron 2.4 GHz, 400 MHz FSB 512 MB, DDR PC2700 Maxtor 80 GB HD Bultin Intel Gigabit Ethernet Controller = My LAN Bultin Intel EtherExpress 10/100 Ethernet Controller = Transit1 PCI card EtherExpress 10/100 Ethernet Controller = Transit2 (from http://www.flashdance.cx/computers.html)
Please take this thread to the General CentOS m/l and continue it there.
It is not relevant to the CentOS devel m/l.
Thank you.
Alan.
Peter Magnusson wrote:
On Fri, 4 Sep 2009, RedShift wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
IIRC, HWADDR just prevents the link from coming up if it's bound to the wrong physical device. The right way is a local udev rule to force the binding the way you want it. Google for
linux HWADDR udev
and you'll find lots of instructions and examples.
Am Samstag, den 05.09.2009, 00:21 +0200 schrieb Robert Nichols:
Peter Magnusson wrote:
On Fri, 4 Sep 2009, RedShift wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
IIRC, HWADDR just prevents the link from coming up if it's bound to the wrong physical device. The right way is a local udev rule to force the binding the way you want it.
Nope. The ifup script actually renames the device! All issuess brought up so far sound like wrong configurations to me.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
On Fri, 4 Sep 2009, Peter Magnusson wrote:
On Fri, 4 Sep 2009, RedShift wrote:
That problem has been long dealt with. Use HWADDR in ifcfg-* to statically bind physical interfaces.
Tried that. Didnt work.
I tried that. It worked for me.
Anyway, you are wasting everybody's time here. If you don't like the current software, take it up with bugzilla.redhat.com.
Peter Magnusson wrote:
On Thu, 3 Sep 2009, Karanbir Singh wrote:
ok, dont be surprised if your reports just sit there with zero interest till someone who is interested enough to spend their spare time on the issues comes along.
Done;
http://bugs.centos.org/view.php?id=3821 - KDE font problem Xdefaults exists
To me it sounds like X is calculating your DPI differently at times. Try forcing it to 96 DPI in xorg.conf or the KDE control center. I think it's unrelated to .Xdefaults, it may have just been a coincidence.
Glenn
On Fri, 4 Sep 2009, RedShift wrote:
http://bugs.centos.org/view.php?id=3821 - KDE font problem Xdefaults exists
To me it sounds like X is calculating your DPI differently at times. Try forcing it to 96 DPI in xorg.conf or the KDE control center. I think it's
Well, thats a idea.
unrelated to .Xdefaults, it may have just been a coincidence.
No, its not. I have tested it MANY times. Its really .Xdefaults. Im not at all suprised that strange bugs affects me however.
-
Alan Bartlett -
Charlie Brady -
Christoph Maser -
Filipe Brandenburger -
Karanbir Singh -
Les Mikesell -
Peter Magnusson -
Ralph Angenendt -
RedShift -
Robert Nichols