Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
-- Abba Communications Spokane, WA www.abbacomm.net
On 5/21/07, Abba Communications lists06@abbacomm.net wrote:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
I let several boxen update themselves via the yum cron-job, but they were nearly all systems with stock packages, or the occasional rpmforge package slipped in. I had no problems with any of them, though one reloaded the scsi (cdrom) driver thanks to the new libata stuff.
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Scott Silva wrote:
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Yup, ever since servers upgraded to 4.5.. something like:
Timeout: No Response from localhost:161 . . .
Works as expected from the command line though.
- dhawal
Works as expected from the command line though.
- dhawal
What do all the logs say?
Is dns ok?
Have you checked the /etc/hosts file?
Do you use a firewall or iptables?
Selinux issue?
If so, have you setup logging to see if a rule is knocking it down somehow?
Did user or privs of user change?
If it works from the command line, it almost sounds like the environment or path changed in your cron etc and you could possibly need to hard code pathing in scripts or what have you.
Just food for thought
- rh
-- Abba Communications Spokane, WA www.abbacomm.net
Dhawal Doshy wrote:
Scott Silva wrote:
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Yup, ever since servers upgraded to 4.5.. something like:
Timeout: No Response from localhost:161 .
Works as expected from the command line though.
Further troubleshooting: mailscanner-mrtg uses this to query the interfaces /usr/bin/snmpwalk -v 2c -c COMMUNITY localhost:161 .1.3.6.1.2.1.2.2.1.16
This was timing out but would strangely not show on it on the terminal when run manually. This surely wasn't the case before.. so a 'rpm -q --changelog net-snmp-utils | head -13' tells me that now 'communication can be limited by tcp_wrappers'. Adding the right entry to hosts.allow appears to have solved the problem.
Dhawal Doshy spake the following on 5/22/2007 9:50 AM:
Scott Silva wrote:
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Yup, ever since servers upgraded to 4.5.. something like:
Timeout: No Response from localhost:161 . . .
Works as expected from the command line though.
- dhawal
I just installed the unstable 0.11.0 and it seems to have cleared up. Since unstable is near to 2 years old, it can't be that unstable, but we'll see.
Scott Silva spake the following on 5/22/2007 11:44 AM:
Dhawal Doshy spake the following on 5/22/2007 9:50 AM:
Scott Silva wrote:
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Yup, ever since servers upgraded to 4.5.. something like:
Timeout: No Response from localhost:161 . . .
Works as expected from the command line though.
- dhawal
I just installed the unstable 0.11.0 and it seems to have cleared up. Since unstable is near to 2 years old, it can't be that unstable, but we'll see.
Nevermind. It just slowed it down to less than 1 per hour.
Scott Silva spake the following on 5/22/2007 2:23 PM:
Scott Silva spake the following on 5/22/2007 11:44 AM:
Dhawal Doshy spake the following on 5/22/2007 9:50 AM:
Scott Silva wrote:
Dhawal Doshy spake the following on 5/22/2007 9:25 AM:
Scott Silva wrote:
Abba Communications spake the following on 5/21/2007 4:25 PM: > Anyone besides me totally throw (most) caution into the wind and yum > update > any mission critical production 4.x boxen to 4.5 without any problems? > > 8-p > > - rh The only issues I am seeing are some snmp timeout errors in MailScanner-mrtg.
Scott,
Did you manage to figure out an answer for this?
Not yet. I can poll snmp without error from the commandline, but get timeouts almost every run of mailscanner-mrtg. I am about ready to disable the snmp tests in mrtg until I can figure it out. I am getting tired of having my servers nag me all day.
Since you asked, are you seeing the same thing?
Yup, ever since servers upgraded to 4.5.. something like:
Timeout: No Response from localhost:161 . . .
Works as expected from the command line though.
- dhawal
I just installed the unstable 0.11.0 and it seems to have cleared up. Since unstable is near to 2 years old, it can't be that unstable, but we'll see.
Nevermind. It just slowed it down to less than 1 per hour.
I got it to stop by creating \etc\sysconfig\snmpd.options with the following;
-------snip-------
OPTIONS="-LS 4 d -p /var/run/snmpd.pid -a"
-------snip-------
I guess the default startup options for snmp daemon cause excessive logging, and can add delays to the responses. You can read what I ran across here: http://article.gmane.org/gmane.linux.centos.general/39531
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable...
See: http://kbase.redhat.com/faq/FAQ_46_10460.shtm
-Greg
Abba Communications wrote:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
Greg Bailey wrote:
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable...
Thanks for pointing that out, it turned out to be the solution to problems we had with a Dell PowerEdge 1950.
On Tue, 22 May 2007, Haakon Nilsen wrote:
Greg Bailey wrote:
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable...
Thanks for pointing that out, it turned out to be the solution to problems we had with a Dell PowerEdge 1950.
We've had great success with http://linux.dell.com/files/name_eths/ on our various boxen (even non-Dell) to resolve this problem.
Steve Friedman
On Mon, 21 May 2007, Greg Bailey wrote:
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable... See: http://kbase.redhat.com/faq/FAQ_46_10460.shtm
I wonder whose brilliant idea it was to introduce such a major change in a _patch release_?
-steve
On Wed, May 23, 2007 at 04:54:12PM -0400, Steve Thompson enlightened us:
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable... See: http://kbase.redhat.com/faq/FAQ_46_10460.shtm
I wonder whose brilliant idea it was to introduce such a major change in a _patch release_?
This has already been hashed out on the nahant-list. Someone from Redhat gave an explanation. I will leave it up to you to decided if the explanation is satisfactory to you or not.
Matt
On Wed, 23 May 2007, Matt Hyclak wrote:
On Wed, May 23, 2007 at 04:54:12PM -0400, Steve Thompson enlightened us:
I upgraded to 4.5 without any problems, but I did have to account for the fact that the new kernel can potentially reorder NICs on certain HP and Dell servers, so all was well after I switched the network cable... See: http://kbase.redhat.com/faq/FAQ_46_10460.shtm
I wonder whose brilliant idea it was to introduce such a major change in a _patch release_?
This has already been hashed out on the nahant-list. Someone from Redhat gave an explanation. I will leave it up to you to decided if the explanation is satisfactory to you or not.
Heh. I wasn't subscribed to nahant-list, so I went over there and took a look. I am in agreement with those that thought that it was a stupid idea. A very stupid idea. An extremely dumb stupid idea. The 4.4 -> 4.5 upgrade broke my PE2900 systems, and I _do_ use HWADDR as well as bonding. The bonding broke in a very spectacular manner. If that change was necessary, it should have been introduced in RHEL5, and not in a patch release. Of course, it has happened before, when the DLM locking protocols changed between RHEL4 U2 and U3 (was it?), leaving non-functional clusters after an up2date.
Steve
Abba Communications wrote:
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
Against my better judgement, I did it on a server that was providing primary domain name service for a domain I care about. It seemed to go without a hitch. Then a few hours later I noticed that DNS lookups for that domain were failing, but other domains served by that same instance of bind were just fine. I'm not sure why, but a bogus CNAME entry (which was indeed an error) in the db.thatdomain file was causing bind to quietly refuse to load that zone file. Otherwise, I haven't noticed any issues, but I haven't tried it on any other servers yet as that made me a bit skittish.
Best,
Abba Communications napsal(a):
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
Well, kudzu finds a "new" HW on all machines I have updated already. So update via ssh looks like this:
[root@rakosnicek ~]#yum update [root@rakosnicek ~]#reboot [root@rakosnicek ~]#kudzu [root@rakosnicek ~]#reboot
:o) David
David Hrbác spake the following on 5/22/2007 12:49 AM:
Abba Communications napsal(a):
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
Well, kudzu finds a "new" HW on all machines I have updated already. So update via ssh looks like this:
[root@rakosnicek ~]#yum update [root@rakosnicek ~]#reboot [root@rakosnicek ~]#kudzu [root@rakosnicek ~]#reboot
:o) David
I had the same thing, but didn't need the second reboot. It was just the backported libata stuff, although it got the cdrom detected on one HP server that didn't work before. I installed from it fine, but couldn't use it when the server was running. I hadn't cared since I usually only use the cdrom for install or rescue anyway.
Scott Silva napsal(a):
I had the same thing, but didn't need the second reboot. It was just the backported libata stuff, although it got the cdrom detected on one HP server that didn't work before. I installed from it fine, but couldn't use it when the server was running. I hadn't cared since I usually only use the cdrom for install or rescue anyway.
As far I have seen kudzu detects "a new HW" on Intel chipset mb's only. David
Hello,
This update has been quite nice to me - I am running Request Tracker 3.6.1 on this server, for our support team, and it keeps running correctly.
The new ata driver repaired a bus error which used to reset the bus at each boot in CentOS 4.4 !
Regards
--- Robert GRASSO System Engineer
CEDRAT 15, Chemin de Malacher - Inovallee - 38246 MEYLAN Cedex - FRANCE Tel: +33 (0)4 76 90 50 45 Fax: +33 (0)4 76 90 16 09 mailto:Robert.Grasso@cedrat.com --- Support service : mailto:support@cedrat.com Commercial service : mailto:cedrat@cedrat.com Web site : http://www.cedrat.com
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of Abba Communications Sent: Tuesday, May 22, 2007 1:25 AM To: 'CentOS mailing list' Subject: [CentOS] 4.5 upgrades on production servers?
Anyone besides me totally throw (most) caution into the wind and yum update any mission critical production 4.x boxen to 4.5 without any problems?
8-p
- rh
-- Abba Communications Spokane, WA www.abbacomm.net
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Abba Communications -
chrism＠imntv.com -
David Hrbác( -
David Hrbáč
-
Dhawal Doshy -
Greg Bailey -
Haakon Nilsen -
Jim Perrin -
Matt Hyclak -
Robert Grasso -
Scott Silva -
Steve Friedman -
Steve Thompson