Linux Linux, actualizacion de RedHat 6.4 a 6.8

Zuljin · 6 Septiembre 2016

Hace unos días el messages alertó errores en la lectura de memoria en uno de los servidores de base de datos de producción.

Código:

Aug 31 00:54:47 oracleprod1 kernel: sbridge: HANDLING MCE MEMORY ERROR
Aug 31 00:54:47 oracleprod1 kernel: CPU 1: Machine Check Exception: 0 Bank 9: cc001b08000800c1
Aug 31 00:54:47 oracleprod1 kernel: TSC 0 ADDR 4cf61bf000 MISC 90840c00040108c PROCESSOR 0:206d7 TIME 1472615687 SOCKET 1 APIC 20
Aug 31 00:54:47 oracleprod1 kernel: sbridge: HANDLING MCE MEMORY ERROR
Aug 31 00:54:47 oracleprod1 kernel: CPU 1: Machine Check Exception: 0 Bank 9: cc001b08000800c1
Aug 31 00:54:47 oracleprod1 kernel: TSC 0 ADDR 4cf61bf000 MISC 90840c00040108c PROCESSOR 0:206d7 TIME 1472615687 SOCKET 1 APIC 20
Aug 31 00:54:48 oracleprod1 kernel: EDAC MC1: CE row 0, channel 0, label "CPU_SrcID#1_Channel#0_DIMM#0": 108 Unknown error(s): memory scrubbing on FATAL area OVERFLOW: cpu=1 Err=0008:00c1 (ch=1), addr = 0x4cf61bf000 => socket=1, Channel=0(mask=1), rank=1

La gente de redHat me dice que es error de hardware y la gente de dell me dice que anda todo la raja porque el chequeo de hardware dice que anda todo impeque. Le mandé un reinicio al server pero a los dos días volvió a saltar el mismo error.

Finalmente Dell me dice "actualiza firmware" y bueno, actualicé firmware y el chequeo de hardware sigue impeque- Y ahora viene lo peor: aplicar yum update para pasar de RedHat 6.4 a RedHat 6.8.

Que el pulento se apiade de mi alma para que los servicios de Oracle levanten después de este update.

K3rnelpanic · 7 Septiembre 2016

yakko dijo:
tropa de maricones

yakko · 7 Septiembre 2016

es raro que pase algo al actualizar en el mismo release, pero pasa, es por eso que se debe tener una máquina de desarrollo y una de producción cuando es un servicio crítico (ambas exactamente iguales, mismo hardware, mismo software, no sacas nada con probar en un fiat 600 los cambios para un fórmula uno), ahora, si es virtual, aplicar snapshot antes del update, si es físico y no hay lukas te chupas el loly, respaldas todo y te encomiendas al señorS

K3rnelpanic · 7 Septiembre 2016

En el mundo informático es típico que el "no debería pasar nada al aplicar este update" siempre pase algo. :risas

Murphy's Law :zippy

yakko · 7 Septiembre 2016

VittokoX dijo:
En el mundo informático es típico que el "no debería pasar nada al aplicar este update" siempre pase algo.

Murphy's Law

depende de que se esté hablando, un windows no le hago un update ni a palos, de partida la mierda se puede tomar todo un día en dejar esa mugre al día, instalas unas actualizaciones, reinicias y aparecen mil más, y es muy probable que algo deje de funcionar (me ha pasado mil veces, en especial problemas con equipos en dominios ADS). En linux es raro que pase algo, en especial si es un update chico, lo más crítico son los update de kernel, pero es por eso que el kernel anterior no se actualiza, se instala el nuevo separado y así tienes la posibilidad de volver a usar el otro. En algunos casos raros algunas actualizaciones de aplicación agregan nuevas funcionalidades o cambian el archivo de configuración, pero siempre dejan un respaldo del original.

Ojo que a veces algunas aplicaciones al actualizarse rompen la funcionalidad de algunas aplicaciones ajenas al sistema, un clásico es cambiar de versión de php y la página/software hecha por el maestro chasquilla y que fue diseñada con la corneta no funciona nunca más y hay que hacerla entera de nuevo.

K3rnelpanic · 7 Septiembre 2016

yakko dijo:
depende de que se esté hablando, un windows no le hago un update ni a palos, de partida la mierda se puede tomar todo un día en dejar esa mugre al día, instalas unas actualizaciones, reinicias y aparecen mil más, y es muy probable que algo deje de funcionar (me ha pasado mil veces, en especial problemas con equipos en dominios ADS). En linux es raro que pase algo, en especial si es un update chico, lo más crítico son los update de kernel, pero es por eso que el kernel anterior no se actualiza, se instala el nuevo separado y así tienes la posibilidad de volver a usar el otro. En algunos casos raros algunas actualizaciones de aplicación agregan nuevas funcionalidades o cambian el archivo de configuración, pero siempre dejan un respaldo del original.

Ojo que a veces algunas aplicaciones al actualizarse rompen la funcionalidad de algunas aplicaciones ajenas al sistema, un clásico es cambiar de versión de php y la página/software hecha por el maestro chasquilla y que fue diseñada con la corneta no funciona nunca más y hay que hacerla entera de nuevo.

Ah claro, updates específicos. Pero actualizar la versiónde php es igual de crítico que actualizar la versión de la BD po.
Y sobre windows. Ni a palos un update a esa weá. Fijo que se rompe algo ( El armisael sabe algo de romper windows :risas

).

K3rnelpanic · 7 Septiembre 2016

Por cierto, para estar al día en tema de vulnerabilidades, esta página es obligación en las que se abren al iniciar sesión :zippy

https://access.redhat.com/security/vulnerabilities

yakko · 7 Septiembre 2016

VittokoX dijo:
Ah claro, updates específicos. Pero actualizar la versiónde php es igual de crítico que actualizar la versión de la BD po.
Y sobre windows. Ni a palos un update a esa weá. Fijo que se rompe algo ( El armisael sabe algo de romper windows ).

en las db no es tan critico, los motores nuevos siempre tienen retrocompatibilidad con data de motores más antiguos, en especial es justo la versión anterior

Miguelwill · 7 Septiembre 2016

claro
en php siempre hay jugo con funciones que se desactivan para dar mas seguridad en las nuevas versiones , en las db la compatibilidad si no se esta usando algo muy marciano , no debería dar problemas

lo que e visto es justo que cuando se suben a una nueva versión , la conf se deba actualizar y el mismo archivo anterior ya no sirve, y el nuevo esta con datos por default, pero eso suele pasar en releases completas (de 6.x a 7.x, de 4.x a 5.x, etc ), pero en versiones cercanas, si se ajusto lo justo y necesario, lo demás no se debería sobrescribir las conf estándares, pero si lo hiciera, queda como dijo @yakko, una copia del archivo como respaldo con una extensión adicional

igual eso suele pasar en varias distros diferentes, pero en Centos/redhat se ve con mas frecuencia que un update grande viene con reset de configuraciones que se necesitaban o se ajustaron, pero dentro de la misma version mayor los updates son menos riesgosos, pero igual esta el tema latente , aunque si se tienen mirrors standares y no este lleno de servicios diferentes (web, correo, dns, filtros, dbs diferentes, etc ) no debería ser difícil de descartar algún problema después del update

Zuljin · 8 Septiembre 2016

Como dato...

Actualicé el firmware del servidor con problemas (al que llamaremos Servidor 1), le pegué sus reinicios y todo bien. Levaron los servicios, se sincronizó con el servidor 2, todo impeque.
Hoy actualicé el firmware del servidor 2, pero después del reinicio los servicios de Oracle no parten: por lo que veo, la interface de red interna (un bounding) no responde. Ahora estoy abriendo un caso con RedHat. Si tienen datos para revisar avísenme.
PD: No hice actualización de Sistema Operativo.

K3rnelpanic · 8 Septiembre 2016

Qué dicen los logs?

Cosme · 8 Septiembre 2016

Zuljin dijo:
Como dato...

Actualicé el firmware del servidor con problemas (al que llamaremos Servidor 1), le pegué sus reinicios y todo bien. Levaron los servicios, se sincronizó con el servidor 2, todo impeque.
Hoy actualicé el firmware del servidor 2, pero después del reinicio los servicios de Oracle no parten: por lo que veo, la interface de red interna (un bounding) no responde. Ahora estoy abriendo un caso con RedHat. Si tienen datos para revisar avísenme.
PD: No hice actualización de Sistema Operativo.

Y se actualizó el kernel del sistema? suele pasar que al actualizar el kernel, el modulo de bonding no se agrega solo a las reglas de los modulos al levantar el kernel.

Zuljin · 8 Septiembre 2016

Cosme dijo:
Y se actualizó el kernel del sistema? suele pasar que al actualizar el kernel, el modulo de bonding no se agrega solo a las reglas de los modulos al levantar el kernel.

No, nunca actualicé el Sistema Operativo. Sólo actualicé el firmware (bios).

Zuljin · 8 Septiembre 2016

Ya, ayúdenme a recopilar logs. Esto también es culpa de ustedes por meter susto.

El bonding con problema es el em2. Su archivo de configuración es este:

Código:

DEVICE=em2
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.1.12
NETMASK=255.255.0.0
USERCTL=no

Las interfaces asociadas son la eth3 y la eth4.

Código:

DEVICE=eth3
MASTER=em2
SLAVE=yes
BOOTPROTO=static
ONBOOT=yes
USERCTL=no

Código:

DEVICE=eth4
MASTER=em2
SLAVE=yes
BOOTPROTO=static
ONBOOT=yes
USERCTL=no

Consulta. ¿Cómo puedo probar si la huea está andando? Porque el problema es que no es capaz de ver a la interfaz equivalente del servidor 1.

K3rnelpanic · 8 Septiembre 2016

tira el
# dmesg
para saber del proceso de booteo y los logs.

También puedes complementar con el /var/log/messages

Zuljin · 8 Septiembre 2016

Como dato, cuando hago un ifconfig en el servidor 1 obtengo esto:

Código:

em1       Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.131  Bcast:172.20.255.255  Mask:255.255.0.0
          inet6 addr: fe80::e2db:55ff:fe7b:62e4/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:482355840 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1005669899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:39592697945 (36.8 GiB)  TX bytes:1499624505295 (1.3 TiB)

em1:1     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.141  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em1:2     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.172  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em1:3     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.142  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em1:4     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.171  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em1:5     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.173  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em1:10    Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          inet addr:172.20.30.2  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

em2       Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E8 
          inet addr:10.0.1.11  Bcast:10.0.255.255  Mask:255.255.0.0
          inet6 addr: fe80::e2db:55ff:fe7b:62e8/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:45210961 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40064334 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:27292586220 (25.4 GiB)  TX bytes:20665992713 (19.2 GiB)

em2:1     Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E8 
          inet addr:169.254.47.163  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

eth1      Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:239238015 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502985652 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:19146386045 (17.8 GiB)  TX bytes:750041720630 (698.5 GiB)
          Interrupt:34 Memory:d1000000-d17fffff

eth2      Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E4 
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:243117825 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502684247 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:20446311900 (19.0 GiB)  TX bytes:749582784665 (698.1 GiB)
          Interrupt:36 Memory:d2000000-d27fffff

eth3      Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E8 
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:22555003 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20031715 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13613867279 (12.6 GiB)  TX bytes:10332933826 (9.6 GiB)
          Interrupt:48 Memory:d3800000-d3ffffff

eth4      Link encap:Ethernet  HWaddr E0:DB:55:7B:62:E8 
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:22655958 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20032619 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13678718941 (12.7 GiB)  TX bytes:10333058887 (9.6 GiB)
          Interrupt:52 Memory:d4800000-d4ffffff

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:9351863 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9351863 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4874159281 (4.5 GiB)  TX bytes:4874159281 (4.5 GiB)

Y cuando hago un ifconfig en el servidor 2 (con problemas) obtengo sólo esto

Código:

em1       Link encap:Ethernet  HWaddr E0:DB:55:10:19:32 
          inet addr:172.20.30.132  Bcast:172.20.255.255  Mask:255.255.0.0
          inet6 addr: fe80::e2db:55ff:fe10:1932/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:264243 errors:0 dropped:0 overruns:0 frame:0
          TX packets:93797 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:285237524 (272.0 MiB)  TX bytes:7609908 (7.2 MiB)
          Interrupt:34 Memory:d1000000-d17fffff

em2       Link encap:Ethernet  HWaddr E0:DB:55:10:19:34 
          inet addr:10.0.1.12  Bcast:10.0.255.255  Mask:255.255.0.0
          inet6 addr: fe80::e2db:55ff:fe10:1934/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7700 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:635696 (620.7 KiB)  TX bytes:1512 (1.4 KiB)
          Interrupt:36 Memory:d2000000-d27fffff

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:799 errors:0 dropped:0 overruns:0 frame:0
          TX packets:799 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:197348 (192.7 KiB)  TX bytes:197348 (192.7 KiB)

Zuljin · 8 Septiembre 2016

Otro dato.

En el servidor 1 (el servidor "bueno") puedo ver el proceso bonding.

Código:

cat /proc/net/bonding/
bond0  em1    em2

En el servidor 2 (el servidor "malo") ni siquiera está el directorio bonding en /proc/net.

K3rnelpanic · 8 Septiembre 2016

ejecuta dmesg en el servidor malo y en el servidor bueno, para comparar donde está fallando.

Zuljin · 8 Septiembre 2016

Ya, para el servidor bueno el dmesg dice:

Código:

bonding: em2 is being created...
bonding: em2: Adding slave eth3.
bnx2x 0000:03:00.0: firmware: requesting bnx2x/bnx2x-e2-7.2.51.0.fw
bnx2x 0000:03:00.0: eth3: using MSI-X  IRQs: sp 144  fp[0] 146 ... fp[7] 153
bonding: em2: enslaving eth3 as an active interface with an up link.
bonding: em2: Adding slave eth4.
bnx2x 0000:03:00.1: firmware: requesting bnx2x/bnx2x-e2-7.2.51.0.fw
bnx2x 0000:03:00.1: eth4: using MSI-X  IRQs: sp 154  fp[0] 156 ... fp[7] 163
bonding: em2: enslaving eth4 as an active interface with an up link.

pero para el servidor malo no dice eso, dice otras cosas que no parecen error, pero no hace referencia a la relación entre bonding (em2) y las interfaces asociadas (eth3 y eth4). Estoy buscando un registro en el log error que me diga exactamente donde está la pana pero no lo veo.

Zuljin · 8 Septiembre 2016

# ip -a

Código:

2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e0:db:55:10:19:32 brd ff:ff:ff:ff:ff:ff
    inet 172.20.30.132/16 brd 172.20.255.255 scope global em1
    inet6 fe80::e2db:55ff:fe10:1932/64 scope link 
       valid_lft forever preferred_lft forever
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e0:db:55:10:19:34 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.12/16 brd 10.0.255.255 scope global em2
    inet6 fe80::e2db:55ff:fe10:1934/64 scope link 
       valid_lft forever preferred_lft forever
4: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e0:db:55:7b:6f:28 brd ff:ff:ff:ff:ff:ff
5: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e0:db:55:7b:6f:2b brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Hay alguna forma de "levantar" una interfaz de red en particular? No se, la eth3 por ejemplo?

Zuljin · 8 Septiembre 2016

Otra más.

En el servidor bueno busco el IRQ asociado a la eth3.

# dmesg | grep eth3 | grep IRQ

Código:

bnx2x 0000:03:00.0: eth3: using MSI-X  IRQs: sp 144  fp[0] 146 ... fp[7] 153

Si ejecuto lo mismo en el servidor "malo", no me devuelve nada

.

Linux Linux, actualizacion de RedHat 6.4 a 6.8

Fundador

non serviam

pingüino mal genio

non serviam

pingüino mal genio

non serviam

non serviam

pingüino mal genio

I am online

Fundador

non serviam

Gold Member

Fundador

Fundador

non serviam

Fundador

Fundador

non serviam

Fundador

Fundador

Fundador