Re: [CentOS-es] Ayuda VPN Red Red

[César Martinez M .]

Gracias Jose María si tengo en mi firewall principal punto A esta regla

$IPT -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp0s31f6 -j MASQUERADE

Si la elimino esta regla todos los clientes que se conectan con el 
cliente openvpn de windows dejan de navegar, que se puede hacer?


--
|Saludos Cordiales
|César Martínez M. | Ingeniero de Sistemas
|Consultor & Proyectos Software Libre| SERVICOM
|Teléfono: (593-2)554-271 2221-386 | Ext 4501
|Celular:593 999374317 |Skype servicomecuador
|Web www.servicomecuador.com Síguenos en:
|Twitter: @servicomecuador |Facebook: servicomec
|Zona Clientes: www.servicomecuador.com/billing
|Blog: http://servicomecuador.com/blog
|Dir. Av. 10 de Agosto N29-140 Entre
|Acuña y  Cuero y Caicedo
|Quito - Ecuador - Sudamérica

El 18/01/18 a las 17:00, Jose Maria Terry Jimenez escribió:



El 18/1/18 a las 21:33, César Martinez M. escribió:
Saludos amigos listeros acudo a ustedes con una consulta de un 
problema que tengo ya desde hace unos días


Tengo dos servidores en dos ciudades diferentes

Punto A Linux Centos 7.4 ip publica 1.1.1.1 ip en la lan 192.168.5.1, 
aquí esta montado la vpn y hace de servidor con openvpn


Punto B Linux Centos 7.4 ip publica 2.2.2.2 ip en la lan 192.168.0.1, 
aquí esta montada la vpn como cliente


Entre las dos redes se ven y se puede hacer ping a ips detrás de cada 
firewall, logré hacer esto con la ayuda de este tuto 
http://www.ecualug.org/?q=2007/02/07/comos/3_configuracion_de_openvpn_red_red


Ahora el problema que tengo es que al estar activo el cliente vpn en 
el Punto B pierdo internet del isp local con la ip 2.2.2.2 y la ip 
publica se convierte en la ip del Punto A.


La pregunta seria que cambiar o que configurar para que el tunel 
funcione bien pero cada punto use su propio internet.


Gracias a todos



Hola

No estarás metiendo todo el tráfico por VPN? Mira esto: 
https://openvpn.net/index.php/open-source/documentation/howto.html#redirect



___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es



___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] Ayuda VPN Red Red

[Jose Maria Terry Jimenez]

El 18/1/18 a las 21:33, César Martinez M. escribió:
Saludos amigos listeros acudo a ustedes con una consulta de un 
problema que tengo ya desde hace unos días


Tengo dos servidores en dos ciudades diferentes

Punto A Linux Centos 7.4 ip publica 1.1.1.1 ip en la lan 192.168.5.1, 
aquí esta montado la vpn y hace de servidor con openvpn


Punto B Linux Centos 7.4 ip publica 2.2.2.2 ip en la lan 192.168.0.1, 
aquí esta montada la vpn como cliente


Entre las dos redes se ven y se puede hacer ping a ips detrás de cada 
firewall, logré hacer esto con la ayuda de este tuto 
http://www.ecualug.org/?q=2007/02/07/comos/3_configuracion_de_openvpn_red_red


Ahora el problema que tengo es que al estar activo el cliente vpn en 
el Punto B pierdo internet del isp local con la ip 2.2.2.2 y la ip 
publica se convierte en la ip del Punto A.


La pregunta seria que cambiar o que configurar para que el tunel 
funcione bien pero cada punto use su propio internet.


Gracias a todos



Hola

No estarás metiendo todo el tráfico por VPN? Mira esto: 
https://openvpn.net/index.php/open-source/documentation/howto.html#redirect



___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Valeri Galtsev]

On 01/18/18 12:55, Matthew Miller wrote:

On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote:

Do we update the microcode now or do we wait until the latest
microcode_ctl rpm is available and then tackle this issue?

Check with your hardware vendor for BIOS/EFI firmware updates. Apply
those.


Thanks for the reply, but you missed what I was asking.  I've
already downloaded the appropriate files from the links that Johnny
provided in a previous posting.
My question is, do we wait until the latest microcode_ctl rpm is
installed or do it now?  My concern is that if I do it now the new
rpm might undo what I've done.


It does not matter. The microcode_ctl package contains CPU firmware
that is loaded at by the kernel early in the boot process if it's newer
than the one provided by the system firmware/BIOS. It is never
permanently stored in NVRAM or anything — it's loaded at each boot.

You should get a BIOS/EFI firmware update from your hardware vendor
which includes updated microcode. Then, you'll get the IBRS-capable
microcode at boot, every boot. This makes microcode_ctl moot.

Read more about this here: https://access.redhat.com/solutions/3315431



 Thanks, Johnny, Matthew, Peter, ... everybody for your insights!

 Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-es] Ayuda VPN Red Red

[Ernesto Pérez Estévez]

On 01/18/2018 03:33 PM, César Martinez M. wrote:
> 
> La pregunta seria que cambiar o que configurar para que el tunel
> funcione bien pero cada punto use su propio internet.
> 
> Gracias a todos
quítale la opción de default gateway

-- 
CEDIA
La principal herramienta de Investigación en el Ecuador.

Calle La Condamine 12-109 "Casa Rivera".
Cuenca -  Ecuador
Telf: (593) 7405 1000 Ext. 4220/4223
i...@cedia.org.ec
www.cedia.org.ec



signature.asc
Description: OpenPGP digital signature
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] Ayuda VPN Red Red

[Roberto Bermúdez]

Hola César

De lo que puedo comprender, el error se está dando por problemas de rutas,
cuando se conecta la VPN el punto B cambia su ruta por defecto hacia la red
del punto A y posiblemente están saliendo al Internet por el punto A,
dentro del archivo de configuración solamente debes poner route 192.168.0.0
(si ese es el segmento del punto A), con eso debería solo pasar los datos
que se dirijan a la otra oficina por la VPN, y el resto salir por el
Internet local, espero te sirva de algo mi comentario

Saludos cordiales
Roberto

El ene. 18, 2018 15:33, "César Martinez M." 
escribió:

> Saludos amigos listeros acudo a ustedes con una consulta de un problema
> que tengo ya desde hace unos días
>
> Tengo dos servidores en dos ciudades diferentes
>
> Punto A Linux Centos 7.4 ip publica 1.1.1.1 ip en la lan 192.168.5.1, aquí
> esta montado la vpn y hace de servidor con openvpn
>
> Punto B Linux Centos 7.4 ip publica 2.2.2.2 ip en la lan 192.168.0.1, aquí
> esta montada la vpn como cliente
>
> Entre las dos redes se ven y se puede hacer ping a ips detrás de cada
> firewall, logré hacer esto con la ayuda de este tuto
> http://www.ecualug.org/?q=2007/02/07/comos/3_configuracion_
> de_openvpn_red_red
>
> Ahora el problema que tengo es que al estar activo el cliente vpn en el
> Punto B pierdo internet del isp local con la ip 2.2.2.2 y la ip publica se
> convierte en la ip del Punto A.
>
> La pregunta seria que cambiar o que configurar para que el tunel funcione
> bien pero cada punto use su propio internet.
>
> Gracias a todos
>
>
> --
> |Saludos Cordiales
> |César Martínez M. | Ingeniero de Sistemas
> |Consultor & Proyectos Software Libre| SERVICOM
> |Teléfono: (593-2)554-271 2221-386 | Ext 4501
> |Celular:593 999374317 |Skype servicomecuador
> |Web www.servicomecuador.com Síguenos en:
> |Twitter: @servicomecuador |Facebook: servicomec
> |Zona Clientes: www.servicomecuador.com/billing
> |Blog: http://servicomecuador.com/blog
> |Dir. Av. 10 de Agosto N29-140
> 
> Entre
> |Acuña y  Cuero y Caicedo
> |Quito - Ecuador - Sudamérica
>
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

[CentOS-es] Ayuda VPN Red Red

[César Martinez M .]

Saludos amigos listeros acudo a ustedes con una consulta de un problema 
que tengo ya desde hace unos días


Tengo dos servidores en dos ciudades diferentes

Punto A Linux Centos 7.4 ip publica 1.1.1.1 ip en la lan 192.168.5.1, 
aquí esta montado la vpn y hace de servidor con openvpn


Punto B Linux Centos 7.4 ip publica 2.2.2.2 ip en la lan 192.168.0.1, 
aquí esta montada la vpn como cliente


Entre las dos redes se ven y se puede hacer ping a ips detrás de cada 
firewall, logré hacer esto con la ayuda de este tuto 
http://www.ecualug.org/?q=2007/02/07/comos/3_configuracion_de_openvpn_red_red


Ahora el problema que tengo es que al estar activo el cliente vpn en el 
Punto B pierdo internet del isp local con la ip 2.2.2.2 y la ip publica 
se convierte en la ip del Punto A.


La pregunta seria que cambiar o que configurar para que el tunel 
funcione bien pero cada punto use su propio internet.


Gracias a todos


--
|Saludos Cordiales
|César Martínez M. | Ingeniero de Sistemas
|Consultor & Proyectos Software Libre| SERVICOM
|Teléfono: (593-2)554-271 2221-386 | Ext 4501
|Celular:593 999374317 |Skype servicomecuador
|Web www.servicomecuador.com Síguenos en:
|Twitter: @servicomecuador |Facebook: servicomec
|Zona Clientes: www.servicomecuador.com/billing
|Blog: http://servicomecuador.com/blog
|Dir. Av. 10 de Agosto N29-140 Entre
|Acuña y  Cuero y Caicedo
|Quito - Ecuador - Sudamérica

___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-virt] Xen 4.4 Immediate EOL

[Sarah Newman]

On 01/18/2018 09:56 AM, Kevin Stange wrote:
> Apparently I failed to do proper due diligence before making this
> recommendation.  The Xen 4.4 repo does not have vixen build because of a
> dependency upon grub2 which isn't available under CentOS 6.  Your best
> bet would be to use Vixen for PV domains, so if you think that's
> something you want to do, we need some volunteers to help with packaging
> and testing.  Otherwise, use HVM domains or upgrade to a newer version
> of Xen.  Sorry for this error on my part.
>

We have a SPEC file available for grub2: https://github.com/prgmrcom/grub2 you 
will need epel installed.

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Phil Perry]

On 18/01/18 18:55, Matthew Miller wrote:

On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote:

Do we update the microcode now or do we wait until the latest
microcode_ctl rpm is available and then tackle this issue?

Check with your hardware vendor for BIOS/EFI firmware updates. Apply
those.


Thanks for the reply, but you missed what I was asking.  I've
already downloaded the appropriate files from the links that Johnny
provided in a previous posting.
My question is, do we wait until the latest microcode_ctl rpm is
installed or do it now?  My concern is that if I do it now the new
rpm might undo what I've done.


It does not matter. The microcode_ctl package contains CPU firmware
that is loaded at by the kernel early in the boot process if it's newer
than the one provided by the system firmware/BIOS. It is never
permanently stored in NVRAM or anything — it's loaded at each boot.



Hence, by my understanding, there should not be any permanent damage 
should you get a 'bad' microcode update, either from Intel or Red Hat, 
that prevents the system from booting. Presumably one should still 
always be able to boot the machine from a rescue disk, mount the fs and 
either delete the offending microcode or uninstall the microcode_ctl 
package to allow the system to boot again. This should not result in a 
'bricked' permanently unrecoverable system.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation) packages making their way to centos-virt-xen-testing

[Peter Peltonen]

Hi Nathan,

On Thu, Jan 18, 2018 at 9:31 PM, Nathan March  wrote:
>> -Original Message-
>> As there are now quite many options to choose from, what would be the
>> best option performance wise for running 32bit domUs under xen-4.6?
>>
>> Best,
>> Peter
>>
>
> It's worth taking a look at the table in the latest XSA, it helps clarify a
> fair bit:
>
> https://xenbits.xen.org/xsa/advisory-254.html

thanks for pointing this out, but there is a disclaimer:

"Everything in this section applies to 64-bit PV x86 guests only."

It also reads in the advisory "32-bit PV guests cannot exploit SP3"

So I am wondering if I just "yum update" will I get some fixes I do
not need that will slow my guests down?

Best,
Peter
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation) packages making their way to centos-virt-xen-testing

[Nathan March]

> -Original Message-
> From: CentOS-virt [mailto:centos-virt-boun...@centos.org] On Behalf Of
> Peter Peltonen
> Sent: Thursday, January 18, 2018 11:19 AM
> To: Discussion about the virtualization on CentOS 
> Subject: Re: [CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation)
> packages making their way to centos-virt-xen-testing
> 
> Thanks George.
> 
> As there are now quite many options to choose from, what would be the
> best option performance wise for running 32bit domUs under xen-4.6?
> 
> Best,
> Peter
> 

It's worth taking a look at the table in the latest XSA, it helps clarify a
fair bit:

https://xenbits.xen.org/xsa/advisory-254.html

Cheers,
Nathan

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation) packages making their way to centos-virt-xen-testing

[Peter Peltonen]

Thanks George.

As there are now quite many options to choose from, what would be the
best option performance wise for running 32bit domUs under xen-4.6?

Best,
Peter


On Wed, Jan 17, 2018 at 7:14 PM, George Dunlap  wrote:
> I've built & tagged packages for CentOS 6 and 7 4.6.6-9, with XPTI
> "stage 1" Meltdown mitigation.
>
> This will allow 64-bit PV guests to run safely (with a few caveats),
> but incurs a fairly significant slowdown for 64-bit PV guests on Intel
> boxes (including domain 0).
>
> If you prefer using Vixen / Comet, you can turn it off by adding
> 'xpti=0' to your Xen command-line.
>
> Detailed information can be found in the XSA-254 advisory:
>
> https://xenbits.xen.org/xsa/advisory-254.html
>
> Please test and report any issues you have.  I'll probably tag then
> with -release tomorrow.
>
> 4.8 packages should be coming to buildlogs soon.
>
>  -George
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-announce] CESA-2018:0095 Important CentOS 7 java-1.8.0-openjdk Security Update

[Johnny Hughes]

CentOS Errata and Security Advisory 2018:0095 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0095

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
2766912d0c8583b9a30da8bd2b71466f56a7fc92ff190af4172de63a505a363e  
java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.i686.rpm
4e74ae36e07d3d70a7546b65999644fc30f9352e5fa88180cd42f8254c578222  
java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64.rpm
be70d0e5ea69695df751ab29bbbc4bea2d9fdaf7041626a14da2f858ef084820  
java-1.8.0-openjdk-accessibility-1.8.0.161-0.b14.el7_4.i686.rpm
2f0c71aeb31a527037ff66d0e42d10d3d23956ca78f156ce9a523d68ef5093de  
java-1.8.0-openjdk-accessibility-1.8.0.161-0.b14.el7_4.x86_64.rpm
5730beececbde72bf96919f270a93d6c855026016426c052857c6e3fbba3b290  
java-1.8.0-openjdk-accessibility-debug-1.8.0.161-0.b14.el7_4.i686.rpm
409e515d1c0aa28f2c59b4e38eed54e75a2b34ec2fb215f5d4c3048c9d73298a  
java-1.8.0-openjdk-accessibility-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm
b5deb2dd947e0861bdbe2ecd7f573649a0762957b705ca355ccf948780c94fdc  
java-1.8.0-openjdk-debug-1.8.0.161-0.b14.el7_4.i686.rpm
bc183b1b9c1c1a48ac5e2248c23580c469bed6aad8c1b00d12e45ed3674f834f  
java-1.8.0-openjdk-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm
ccfafae41cee085f0d25f6c45f8a3271684f7878547f1fd1d1fb432b0cc585f3  
java-1.8.0-openjdk-demo-1.8.0.161-0.b14.el7_4.i686.rpm
4869f03636a2e3db10c62912bda10198eedc5c87e2bd92925ad8ec8717e75bf0  
java-1.8.0-openjdk-demo-1.8.0.161-0.b14.el7_4.x86_64.rpm
e2e76d4f3787d6f0b8889a48edc71a3c8e4dbaa51e697c9179ba9d4da78199be  
java-1.8.0-openjdk-demo-debug-1.8.0.161-0.b14.el7_4.i686.rpm
eb0ab0a91a663ae9dda18a30b54c707ebad1838d1158f3e1985a20f5a23f333e  
java-1.8.0-openjdk-demo-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm
44d5f739b1756e8cc9db1ed060f1b466f2ed5e0e33b4050815756729dbdf3130  
java-1.8.0-openjdk-devel-1.8.0.161-0.b14.el7_4.i686.rpm
987f47d6fd54cbef7b7c3ad01fcda79e06975060019027806ba91cb3e2655855  
java-1.8.0-openjdk-devel-1.8.0.161-0.b14.el7_4.x86_64.rpm
12a6f4858eb57161f73a10f35b181a0bb50564a6ecadb99ba3149c7a464c99bf  
java-1.8.0-openjdk-devel-debug-1.8.0.161-0.b14.el7_4.i686.rpm
ad5e3d9dff544ae145e3ecec11b203b4e1ec68b6307d8cc0ca5fc51427a92c43  
java-1.8.0-openjdk-devel-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm
12660f8b112be41ddc736c7a5e7ae89631b8d1fd15491c313e86689ace19aa88  
java-1.8.0-openjdk-headless-1.8.0.161-0.b14.el7_4.i686.rpm
679daae12c2c46b9427e7e45811ade63aeaf99f408d82e3d15b7a58f958aceb3  
java-1.8.0-openjdk-headless-1.8.0.161-0.b14.el7_4.x86_64.rpm
f273343cc2cc69a003df11942b1c53b09e591b856da79e5e0ba85d9841bd614d  
java-1.8.0-openjdk-headless-debug-1.8.0.161-0.b14.el7_4.i686.rpm
f2928bba6eec9fa58031db25f7fabca724b8d71b53037dbb03c03e95e0520c46  
java-1.8.0-openjdk-headless-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm
a85073538a6e46dfdbcf7c4e133490cc036efa2589523e6fcf12d90fb0950489  
java-1.8.0-openjdk-javadoc-1.8.0.161-0.b14.el7_4.noarch.rpm
aa1a25bc2ea08576790f3f16dec6744b9a984317a60db7fbb0e362172e423976  
java-1.8.0-openjdk-javadoc-debug-1.8.0.161-0.b14.el7_4.noarch.rpm
2f9e4deba0573a34379b94e96202b98de9f24775c0e3236d6e4f46031bcbea68  
java-1.8.0-openjdk-javadoc-zip-1.8.0.161-0.b14.el7_4.noarch.rpm
c77f9996c365bfd0e908defa91c5cd5cc5935ab043f83ac25edce54b43c57551  
java-1.8.0-openjdk-javadoc-zip-debug-1.8.0.161-0.b14.el7_4.noarch.rpm
8dc501543d8e5c660b759b2523770a377936e4fe7394cb2f54a9abbf377dd0dd  
java-1.8.0-openjdk-src-1.8.0.161-0.b14.el7_4.i686.rpm
8d3f2e4b551112bdccb364f587d7e596fde31ce87346d91059f6a5dd5b1d0fd6  
java-1.8.0-openjdk-src-1.8.0.161-0.b14.el7_4.x86_64.rpm
ef65b9442ae5d29b5845e5c0715a2d74a5d1e05d7d849f0a8a03f43f3cef9f0e  
java-1.8.0-openjdk-src-debug-1.8.0.161-0.b14.el7_4.i686.rpm
58eec59c90cf6c55c9c79a391acb00de0f5b92db9aca7388ae1eebc3cdec0352  
java-1.8.0-openjdk-src-debug-1.8.0.161-0.b14.el7_4.x86_64.rpm

Source:
bdd53201389bbc3d4e6673551a8913964c750b7a5996704bd4a3808176b2ed9e  
java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2018:0095 Important CentOS 6 java-1.8.0-openjdk Security Update

[Johnny Hughes]

CentOS Errata and Security Advisory 2018:0095 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0095

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
aedfa61bf2daf443844cf6e97ac3b1aca5978a0152dada7bc608ebf3f95a9461  
java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.i686.rpm
0228e7975a903a24e95d33731b508abd7094dc1ee97893fff9d238b18067adf8  
java-1.8.0-openjdk-debug-1.8.0.161-3.b14.el6_9.i686.rpm
887147e2ef26d6ae70a7564e884c4d822261065fe90556172eda958fb47e8f8c  
java-1.8.0-openjdk-demo-1.8.0.161-3.b14.el6_9.i686.rpm
c6cccf1e268f7202e1a90effbdd8d371bbcdb1ce13453f068c410de496ec97b1  
java-1.8.0-openjdk-demo-debug-1.8.0.161-3.b14.el6_9.i686.rpm
c0d65912e964721b78ba31641c7174e7a9981af86445b49cd71c0754bbf3f6e2  
java-1.8.0-openjdk-devel-1.8.0.161-3.b14.el6_9.i686.rpm
5a8f1d45265453ba3d1b423342ac60784b5e6e1f83d7d23480490811962decac  
java-1.8.0-openjdk-devel-debug-1.8.0.161-3.b14.el6_9.i686.rpm
a2bf3ce22b0bab146f4b385f1db394151e73d9cc41b574010f48bb7ddeaba855  
java-1.8.0-openjdk-headless-1.8.0.161-3.b14.el6_9.i686.rpm
105e35a7517a69afce3b8e7a1a0e4eb102d4358fe9b4c625958c919b8bc56b64  
java-1.8.0-openjdk-headless-debug-1.8.0.161-3.b14.el6_9.i686.rpm
7de3406d823412dbd17aaa8069f09768a117879bc8506a424eb75018b0e0a938  
java-1.8.0-openjdk-javadoc-1.8.0.161-3.b14.el6_9.noarch.rpm
01b581a28636ac8b8439506e6e16bc8da16b135349bbabb77c6aff02e811c4a3  
java-1.8.0-openjdk-javadoc-debug-1.8.0.161-3.b14.el6_9.noarch.rpm
2a6860c1944506df1df76dbef39e21bdb965a88ddd660f3dc9f90b69f09e1fee  
java-1.8.0-openjdk-src-1.8.0.161-3.b14.el6_9.i686.rpm
075c7525fe677e946029ed4a982f727b7f154a4a03951664bbed8eec184ddef4  
java-1.8.0-openjdk-src-debug-1.8.0.161-3.b14.el6_9.i686.rpm

x86_64:
ba95497dc991932b615659b2eb78c3a98d79f5f32fb2cb5bdc7254de8539a353  
java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64.rpm
d2ce15aef82064f5badb4ca47721e8fb8743b53adfb20908b7919711065ecf77  
java-1.8.0-openjdk-debug-1.8.0.161-3.b14.el6_9.x86_64.rpm
f0fafa95776412d4a1e15ce3c2db724ec82c620c974f8ad9167ca7f4cb255474  
java-1.8.0-openjdk-demo-1.8.0.161-3.b14.el6_9.x86_64.rpm
a9284fd2781365df7ce6819ec503f555903146d4c17d4a6dcc2fcba51b3d902f  
java-1.8.0-openjdk-demo-debug-1.8.0.161-3.b14.el6_9.x86_64.rpm
99cd860e133743c47a85e1ca4abc907e71e989a5087b7478695f92ba35e5ff5c  
java-1.8.0-openjdk-devel-1.8.0.161-3.b14.el6_9.x86_64.rpm
cdaa7a1761d9e003d31067c08dae44571575f70ee97bdabd342328b446a3c2ad  
java-1.8.0-openjdk-devel-debug-1.8.0.161-3.b14.el6_9.x86_64.rpm
3fe343d680a27e78031184e0be0b6dcc905e0b98d8a6618f29652caf298a4af4  
java-1.8.0-openjdk-headless-1.8.0.161-3.b14.el6_9.x86_64.rpm
5276a0a5981112fa3b78d7c1ab770e52faa3a866fe99a67bb0f43a08c30403d6  
java-1.8.0-openjdk-headless-debug-1.8.0.161-3.b14.el6_9.x86_64.rpm
7de3406d823412dbd17aaa8069f09768a117879bc8506a424eb75018b0e0a938  
java-1.8.0-openjdk-javadoc-1.8.0.161-3.b14.el6_9.noarch.rpm
01b581a28636ac8b8439506e6e16bc8da16b135349bbabb77c6aff02e811c4a3  
java-1.8.0-openjdk-javadoc-debug-1.8.0.161-3.b14.el6_9.noarch.rpm
fe1204dffecc7fdea9a2144bd92befa22d204cfbbac47fdac6b10eab29ea8e6a  
java-1.8.0-openjdk-src-1.8.0.161-3.b14.el6_9.x86_64.rpm
f6976bc2fb8aa2ae4850966e64dda40ec98b1d7f0110c34b10efcb4926a62edc  
java-1.8.0-openjdk-src-debug-1.8.0.161-3.b14.el6_9.x86_64.rpm

Source:
d565f75f024098b6e2d6d3fb4f9b32b5e08c01b63484ee0bbae5891873b27bbe  
java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Matthew Miller]

On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote:
> >>Do we update the microcode now or do we wait until the latest
> >>microcode_ctl rpm is available and then tackle this issue?
> >Check with your hardware vendor for BIOS/EFI firmware updates. Apply
> >those.
> >
> Thanks for the reply, but you missed what I was asking.  I've
> already downloaded the appropriate files from the links that Johnny
> provided in a previous posting.
> My question is, do we wait until the latest microcode_ctl rpm is
> installed or do it now?  My concern is that if I do it now the new
> rpm might undo what I've done.

It does not matter. The microcode_ctl package contains CPU firmware
that is loaded at by the kernel early in the boot process if it's newer
than the one provided by the system firmware/BIOS. It is never
permanently stored in NVRAM or anything — it's loaded at each boot.

You should get a BIOS/EFI firmware update from your hardware vendor
which includes updated microcode. Then, you'll get the IBRS-capable
microcode at boot, every boot. This makes microcode_ctl moot.

Read more about this here: https://access.redhat.com/solutions/3315431


-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen 4.4 Immediate EOL

[Kevin Stange]

On 01/18/2018 11:48 AM, Kevin Stange wrote:
> Hi,
> 
> I am very sorry to do this on short notice, but obviously Meltdown and
> Spectre are a lot more than anyone was really expecting to come down the
> pipeline.  Xen 4.4 has been EOL upstream for about a year now and I have
> personally been reviewing and backporting patches based on the 4.5
> versions made available upstream.
> 
> Given that 4.5 is now also reaching EOL, backporting to 4.4 will become
> harder and I've already taken steps to vacate 4.4 in my own environment
> ASAP.  Spectre and Meltdown patches most likely will only officially
> reach 4.6 and are very complicated.  Ultimately, I don't think this is a
> constructive use of my time.  Therefore, I will NOT be continuing to
> provide updated Xen 4.4 builds any longer through CentOS Virt SIG.  If
> someone else would like to take on the job, you're welcome to try.  Pop
> by #centos-virt on Freenode to talk to us there if you're interested.
> 
> For short term mitigation of the Meltdown issue on 4.4 with PV domains,
> your best bet is probably to use the "Vixen" shim solution, which George
> has put into the xen-44 package repository per his email from two days
> ago. Vixen allows you to run PV domains inside HVM guest containers.  It
> does not protect the guest from itself, but protects the domains from
> each other.  Long term, your best bet is to try to get up to a new
> version of Xen that is under upstream security support, probably 4.8.

Apparently I failed to do proper due diligence before making this
recommendation.  The Xen 4.4 repo does not have vixen build because of a
dependency upon grub2 which isn't available under CentOS 6.  Your best
bet would be to use Vixen for PV domains, so if you think that's
something you want to do, we need some volunteers to help with packaging
and testing.  Otherwise, use HVM domains or upgrade to a newer version
of Xen.  Sorry for this error on my part.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen 4.4 Immediate EOL

[Kevin Stange]

Hi,

I am very sorry to do this on short notice, but obviously Meltdown and
Spectre are a lot more than anyone was really expecting to come down the
pipeline.  Xen 4.4 has been EOL upstream for about a year now and I have
personally been reviewing and backporting patches based on the 4.5
versions made available upstream.

Given that 4.5 is now also reaching EOL, backporting to 4.4 will become
harder and I've already taken steps to vacate 4.4 in my own environment
ASAP.  Spectre and Meltdown patches most likely will only officially
reach 4.6 and are very complicated.  Ultimately, I don't think this is a
constructive use of my time.  Therefore, I will NOT be continuing to
provide updated Xen 4.4 builds any longer through CentOS Virt SIG.  If
someone else would like to take on the job, you're welcome to try.  Pop
by #centos-virt on Freenode to talk to us there if you're interested.

For short term mitigation of the Meltdown issue on 4.4 with PV domains,
your best bet is probably to use the "Vixen" shim solution, which George
has put into the xen-44 package repository per his email from two days
ago. Vixen allows you to run PV domains inside HVM guest containers.  It
does not protect the guest from itself, but protects the domains from
each other.  Long term, your best bet is to try to get up to a new
version of Xen that is under upstream security support, probably 4.8.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Pete Geenhuizen]

On 01/18/18 11:31, Matthew Miller wrote:

On Thu, Jan 18, 2018 at 11:01:18AM -0500, Pete Geenhuizen wrote:

Do we update the microcode now or do we wait until the latest
microcode_ctl rpm is available and then tackle this issue?

Check with your hardware vendor for BIOS/EFI firmware updates. Apply
those.



Thanks for the reply, but you missed what I was asking.  I've already 
downloaded the appropriate files from the links that Johnny provided in 
a previous posting.
My question is, do we wait until the latest microcode_ctl rpm is 
installed or do it now?  My concern is that if I do it now the new rpm 
might undo what I've done.


Pete

--
Unencumbered by the thought process.
 -- Click and Clack the Tappet brothers


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Pete Geenhuizen]

On 01/18/18 11:31, Matthew Miller wrote:

On Thu, Jan 18, 2018 at 11:01:18AM -0500, Pete Geenhuizen wrote:

Do we update the microcode now or do we wait until the latest
microcode_ctl rpm is available and then tackle this issue?

Check with your hardware vendor for BIOS/EFI firmware updates. Apply
those.



Thanks for the reply, but you missed what I was asking.  I've already 
downloaded the appropriate files from the links that Johnny provided in 
a previous posting.
My question is, do we wait until the latest microcode_ctl rpm is 
installed or do it now?  My concern is that if I do it now the new rpm 
might undo what I've done.


--
Unencumbered by the thought process.
 -- Click and Clack the Tappet brothers


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[isdtor]

> OK, so color me confused about the timing in all this.
> 
> Do we update the microcode now or do we wait until the latest microcode_ctl
> rpm is available and then tackle this issue?
 
The message is: stay away from microcode updates because they're broken right 
now. Intel may or may not release fixes next week to be tested by OEMs.

Once working updates are available, OEMs will integrate them into their 
firmware/BIOS releases. That is one method to avail of microcode updates. The 
other method is loading during OS boot (via udev rule), with codes provided by 
the microcode_ctl rpm. It looks like Red Hat are now staying away from that; in 
any case, their previous rpm only included ucodes for three cpus. I did not 
check if the microcode.dat included more updates than that.

Method number 2b is to download the firmware from Intel directly and provide it 
in the locations defined by the microcode_ctl rpm. Then it's up to you to do 
the QA.

If your RHEL/CentOS is fully up to date, you're protected against variant 
1/Spectre and Meltdown. Red Hat have done a pretty good job to backport those 
patches from upstream. GKH's blog is worth a read.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Matthew Miller]

On Thu, Jan 18, 2018 at 11:01:18AM -0500, Pete Geenhuizen wrote:
> Do we update the microcode now or do we wait until the latest
> microcode_ctl rpm is available and then tackle this issue?

Check with your hardware vendor for BIOS/EFI firmware updates. Apply
those.



-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Peter Kjellström]

On Thu, 18 Jan 2018 04:03:48 -0600
Johnny Hughes  wrote:

> On 01/18/2018 03:41 AM, Pete Biggs wrote:
> >   
> >> Look at:
> >>
> >> https://t.co/6fT61xgtGH
> >>
> >> Get the latest microcode.dat file from here:
> >>
> >> https://t.co/zPwagbeJFY
> >>
> >> See how to update the microcode from the links at the bottom of
> >> this page:
> >>
> >> https://t.co/EOgclWdHCw
> >>
> >> An before anyone asks .. I have no idea why Red Hat chose this
> >> path, they did.  It doesn't matter if I (or anyone else) agrees
> >> with the decision.  It is what it is.
> >>  
> > **I'm not blaming you.**
> > 
> > But can I just clarify. We have to *manually* install the microcode
> > update an EL7 in order to be protected against Spectre? EL6 as well?
> > 
> > Presumably this is to remove RH from the loop and to stop people
> > blaming them - i.e. this is between Intel and the customer, it's
> > nothing to do with them.
> >   
> 
> No, this is because at least one major CPU (Intel type 79) is
> completely broken by the Intel Microcode Update.  Those machines
> can't boot after the microcode rpm is installed.  It impacts at least
> these processors:
> 
> Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
> Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz
> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.50GHz
> 
> There may be others.

As a data point, we have the updated microcode running on 600+ Haswell
servers and so far no indication of problems.

We'll keep the ibrs/spectre mitigation this gives us and not revert
(unless it turns out it does cause problems).

/Peter


pgpq2wfXVQcOy.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Pete Geenhuizen]

On 01/18/18 09:01, Johnny Hughes wrote:

On 01/18/2018 07:51 AM, Phelps, Matthew wrote:

On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes  wrote:

So, if we applied the previous microcode update, and all our machines
rebooted OK, then we don't need to fallback?

Also, do we know if the updated CentOS microcode RPM reverted the microcode
for *all* Intel CPUs, or just the ones that had issues? In other words, if
I apply the latest microcode update to our 100+ machines (which all have
the previous update, and are OK) will they revert to a vulnerable state?



It reverted for all .. but, your machines may or may not be protected as
only a subset of machines were updated with the original microcode from
Intel.

It is your call as to what you install .. but the correct method is to
install the current microcode_ctl .. and then research your specific
machine, its CPU, chipset, firmware .. go to the vendor and make sure
you get all the things necessary to mitigate the issues.  It will be
different for each CPU vendor (Intel or AMD), each CPU / Chipset combo,
and even each vendor (Dell may have new firmware for x and y but not z
models, etc.)

There is no one size fits all update for this issue.


OK, so color me confused about the timing in all this.

Do we update the microcode now or do we wait until the latest 
microcode_ctl rpm is available and then tackle this issue?


--
Unencumbered by the thought process.
 -- Click and Clack the Tappet brothers


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Valeri Galtsev]

On 01/18/18 03:41, Pete Biggs wrote:



Look at:

https://t.co/6fT61xgtGH

Get the latest microcode.dat file from here:

https://t.co/zPwagbeJFY

See how to update the microcode from the links at the bottom of this page:

https://t.co/EOgclWdHCw

An before anyone asks .. I have no idea why Red Hat chose this path,
they did.  It doesn't matter if I (or anyone else) agrees with the
decision.  It is what it is.


**I'm not blaming you.**

But can I just clarify. We have to *manually* install the microcode
update an EL7 in order to be protected against Spectre? EL6 as well?

Presumably this is to remove RH from the loop and to stop people
blaming them - i.e. this is between Intel and the customer, it's
nothing to do with them.


I bet you are right. I was going to rant about that... then it occurred 
to me that class action against Intel (didn't hear about AMD though) is 
quite likely, so, indeed, RedHat does not want to be even mentioned in 
it, which will be unfair, especially after RedHat putting effort into 
fixing somebody's else crap.


Valeri



What about future microcode updates? They come out reasonably regularly
  (2 or 3 times a year) - are RH going to absolve themselves from all
future updates because presumably the next update will also contain the
Spectre fixes?

So, before I re-invent the wheel, does anyone have automation scripts
to do the microcode update? I don't relish the prospect of doing this
manually on a couple of hundred machines. Is it reasonable to grab the
microcode_ctl SRPM and create my own updated RPM to do it?

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-docs] Update the "repository URL" links for centos.org website

[Charlie Drage]

I had a bit of trouble git cloning the website since the repository URL
portion isn't filled in, see:
https://git.centos.org/summary/?r=websites/centos.org.git

Only until I went onto
https://git.centos.org/summary/?r=websites/bugs.centos.org.git was I able
to infer on how to actually git clone it.

Could someone possibly update the URL for
https://git.centos.org/summary/?r=websites/centos.org.git ?
--
Charlie Drage
PGP - 4096R/C037D617
http://pgp.mit.edu/pks/lookup?op=get=0xDA227403C037D617
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Phelps, Matthew]

On Thu, Jan 18, 2018 at 9:01 AM, Johnny Hughes  wrote:

> On 01/18/2018 07:51 AM, Phelps, Matthew wrote:
> > On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes 
> wrote:
> >
> >> On 01/18/2018 03:41 AM, Pete Biggs wrote:
> >>>
>  Look at:
> 
>  https://t.co/6fT61xgtGH
> 
>  Get the latest microcode.dat file from here:
> 
>  https://t.co/zPwagbeJFY
> 
>  See how to update the microcode from the links at the bottom of this
> >> page:
> 
>  https://t.co/EOgclWdHCw
> 
>  An before anyone asks .. I have no idea why Red Hat chose this path,
>  they did.  It doesn't matter if I (or anyone else) agrees with the
>  decision.  It is what it is.
> 
> >>> **I'm not blaming you.**
> >>>
> >>> But can I just clarify. We have to *manually* install the microcode
> >>> update an EL7 in order to be protected against Spectre? EL6 as well?
> >>>
> >>> Presumably this is to remove RH from the loop and to stop people
> >>> blaming them - i.e. this is between Intel and the customer, it's
> >>> nothing to do with them.
> >>>
> >>
> >> No, this is because at least one major CPU (Intel type 79) is completely
> >> broken by the Intel Microcode Update.  Those machines can't boot after
> >> the microcode rpm is installed.  It impacts at least these processors:
> >>
> >> Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
> >> Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz
> >> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
> >> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.50GHz
> >>
> >> There may be others.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1532283
> >>
> >> That means, it is NOT full-proof install and likely leaves many
> >> servers/machines broken.  I suppose that the decision is, go pack to
> >> what works for all machines (the last known good install) and let admins
> >> work with their hardware vendor because the alternative is breaking
> things.
> >>
> >> This also needs to be fixed with a combination of firmware updates AND
> >> microcode updates.  All of that is outside the expertise of a Linux
> >> vendor and is unique for each processor, chipset and firmware
> combination.
> >>
> >>> What about future microcode updates? They come out reasonably regularly
> >>>  (2 or 3 times a year) - are RH going to absolve themselves from all
> >>> future updates because presumably the next update will also contain the
> >>> Spectre fixes?
> >>>
> >>
> >>
> >> How they handle it in the future I have no way of knowing, but if you
> >> had 20,000 servers with the impacted CPU and you updated and could not
> >> reboot, I would assume that you did not appreciate it.
> >>
> >>> So, before I re-invent the wheel, does anyone have automation scripts
> >>> to do the microcode update? I don't relish the prospect of doing this
> >>> manually on a couple of hundred machines. Is it reasonable to grab the
> >>> microcode_ctl SRPM and create my own updated RPM to do it?
> >>>
> >>
> >> That is what I have found so far with a bit of research.
> >>
> >> This is NOTHING about who to blame and everything about stable, working
> >> updates .. at least it seems so to me.
> >>
> >>
> > So, if we applied the previous microcode update, and all our machines
> > rebooted OK, then we don't need to fallback?
> >
> > Also, do we know if the updated CentOS microcode RPM reverted the
> microcode
> > for *all* Intel CPUs, or just the ones that had issues? In other words,
> if
> > I apply the latest microcode update to our 100+ machines (which all have
> > the previous update, and are OK) will they revert to a vulnerable state?
> >
> >
>
> It reverted for all .. but, your machines may or may not be protected as
> only a subset of machines were updated with the original microcode from
> Intel.
>
> It is your call as to what you install .. but the correct method is to
> install the current microcode_ctl .. and then research your specific
> machine, its CPU, chipset, firmware .. go to the vendor and make sure
> you get all the things necessary to mitigate the issues.  It will be
> different for each CPU vendor (Intel or AMD), each CPU / Chipset combo,
> and even each vendor (Dell may have new firmware for x and y but not z
> models, etc.)
>
> There is no one size fits all update for this issue.
>
>
Johnny,

Thank you. We all appreciate your efforts, and your guidance.


-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphe...@cfa.harvard.edu, http://www.cfa.harvard.edu
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Johnny Hughes]

On 01/18/2018 07:51 AM, Phelps, Matthew wrote:
> On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes  wrote:
> 
>> On 01/18/2018 03:41 AM, Pete Biggs wrote:
>>>
 Look at:

 https://t.co/6fT61xgtGH

 Get the latest microcode.dat file from here:

 https://t.co/zPwagbeJFY

 See how to update the microcode from the links at the bottom of this
>> page:

 https://t.co/EOgclWdHCw

 An before anyone asks .. I have no idea why Red Hat chose this path,
 they did.  It doesn't matter if I (or anyone else) agrees with the
 decision.  It is what it is.

>>> **I'm not blaming you.**
>>>
>>> But can I just clarify. We have to *manually* install the microcode
>>> update an EL7 in order to be protected against Spectre? EL6 as well?
>>>
>>> Presumably this is to remove RH from the loop and to stop people
>>> blaming them - i.e. this is between Intel and the customer, it's
>>> nothing to do with them.
>>>
>>
>> No, this is because at least one major CPU (Intel type 79) is completely
>> broken by the Intel Microcode Update.  Those machines can't boot after
>> the microcode rpm is installed.  It impacts at least these processors:
>>
>> Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
>> Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz
>> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
>> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.50GHz
>>
>> There may be others.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1532283
>>
>> That means, it is NOT full-proof install and likely leaves many
>> servers/machines broken.  I suppose that the decision is, go pack to
>> what works for all machines (the last known good install) and let admins
>> work with their hardware vendor because the alternative is breaking things.
>>
>> This also needs to be fixed with a combination of firmware updates AND
>> microcode updates.  All of that is outside the expertise of a Linux
>> vendor and is unique for each processor, chipset and firmware combination.
>>
>>> What about future microcode updates? They come out reasonably regularly
>>>  (2 or 3 times a year) - are RH going to absolve themselves from all
>>> future updates because presumably the next update will also contain the
>>> Spectre fixes?
>>>
>>
>>
>> How they handle it in the future I have no way of knowing, but if you
>> had 20,000 servers with the impacted CPU and you updated and could not
>> reboot, I would assume that you did not appreciate it.
>>
>>> So, before I re-invent the wheel, does anyone have automation scripts
>>> to do the microcode update? I don't relish the prospect of doing this
>>> manually on a couple of hundred machines. Is it reasonable to grab the
>>> microcode_ctl SRPM and create my own updated RPM to do it?
>>>
>>
>> That is what I have found so far with a bit of research.
>>
>> This is NOTHING about who to blame and everything about stable, working
>> updates .. at least it seems so to me.
>>
>>
> So, if we applied the previous microcode update, and all our machines
> rebooted OK, then we don't need to fallback?
> 
> Also, do we know if the updated CentOS microcode RPM reverted the microcode
> for *all* Intel CPUs, or just the ones that had issues? In other words, if
> I apply the latest microcode update to our 100+ machines (which all have
> the previous update, and are OK) will they revert to a vulnerable state?
> 
> 

It reverted for all .. but, your machines may or may not be protected as
only a subset of machines were updated with the original microcode from
Intel.

It is your call as to what you install .. but the correct method is to
install the current microcode_ctl .. and then research your specific
machine, its CPU, chipset, firmware .. go to the vendor and make sure
you get all the things necessary to mitigate the issues.  It will be
different for each CPU vendor (Intel or AMD), each CPU / Chipset combo,
and even each vendor (Dell may have new firmware for x and y but not z
models, etc.)

There is no one size fits all update for this issue.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Phelps, Matthew]

On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes  wrote:

> On 01/18/2018 03:41 AM, Pete Biggs wrote:
> >
> >> Look at:
> >>
> >> https://t.co/6fT61xgtGH
> >>
> >> Get the latest microcode.dat file from here:
> >>
> >> https://t.co/zPwagbeJFY
> >>
> >> See how to update the microcode from the links at the bottom of this
> page:
> >>
> >> https://t.co/EOgclWdHCw
> >>
> >> An before anyone asks .. I have no idea why Red Hat chose this path,
> >> they did.  It doesn't matter if I (or anyone else) agrees with the
> >> decision.  It is what it is.
> >>
> > **I'm not blaming you.**
> >
> > But can I just clarify. We have to *manually* install the microcode
> > update an EL7 in order to be protected against Spectre? EL6 as well?
> >
> > Presumably this is to remove RH from the loop and to stop people
> > blaming them - i.e. this is between Intel and the customer, it's
> > nothing to do with them.
> >
>
> No, this is because at least one major CPU (Intel type 79) is completely
> broken by the Intel Microcode Update.  Those machines can't boot after
> the microcode rpm is installed.  It impacts at least these processors:
>
> Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
> Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz
> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
> Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.50GHz
>
> There may be others.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1532283
>
> That means, it is NOT full-proof install and likely leaves many
> servers/machines broken.  I suppose that the decision is, go pack to
> what works for all machines (the last known good install) and let admins
> work with their hardware vendor because the alternative is breaking things.
>
> This also needs to be fixed with a combination of firmware updates AND
> microcode updates.  All of that is outside the expertise of a Linux
> vendor and is unique for each processor, chipset and firmware combination.
>
> > What about future microcode updates? They come out reasonably regularly
> >  (2 or 3 times a year) - are RH going to absolve themselves from all
> > future updates because presumably the next update will also contain the
> > Spectre fixes?
> >
>
>
> How they handle it in the future I have no way of knowing, but if you
> had 20,000 servers with the impacted CPU and you updated and could not
> reboot, I would assume that you did not appreciate it.
>
> > So, before I re-invent the wheel, does anyone have automation scripts
> > to do the microcode update? I don't relish the prospect of doing this
> > manually on a couple of hundred machines. Is it reasonable to grab the
> > microcode_ctl SRPM and create my own updated RPM to do it?
> >
>
> That is what I have found so far with a bit of research.
>
> This is NOTHING about who to blame and everything about stable, working
> updates .. at least it seems so to me.
>
>
So, if we applied the previous microcode update, and all our machines
rebooted OK, then we don't need to fallback?

Also, do we know if the updated CentOS microcode RPM reverted the microcode
for *all* Intel CPUs, or just the ones that had issues? In other words, if
I apply the latest microcode update to our 100+ machines (which all have
the previous update, and are OK) will they revert to a vulnerable state?


-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphe...@cfa.harvard.edu, http://www.cfa.harvard.edu
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Minor problem with yum-cron

[Bill Gee]

Hello everyone -

I have a minor problem with yum-cron.  It has been doing this for a long time, 
and finally today I got annoyed enough to want to fix it.

The problem:  When yum-cron sends an email notification, the message is sent 
without a date field.  Therefore it shows up in my inbox as "date: Unknown" 
and sorts to the opposite end of the list.

The system is CentOS 7.4.1708 with all patches.  Yum-cron is version 
3.4.3-154.

The email headers look like this:

Return-Path: 
X-Original-To: b...@campercaver.net
Delivered-To: b...@campercaver.net
Received: from boinc01.billgee.local (unknown [192.168.17.131]) by 
campercaver.net (Postfix) with ESMTP id 94EA62C0C70 for 
; Thu, 18 Jan 2018 03:44:26 -0600 (CST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Yum: Updates installed on boinc01.billgee.local
From: r...@campercaver.net
To: b...@campercaver.net
X-Spambayes-Classification: ham; 0.00

As you can see, there is no "Date:" field.

I don't see anything in /etc/yum/yum-cron.conf that might affect this.  I also 
see nothing in /etc/mail.rc,l though in this case it might not be using that 
file.

The system does not have an smtp server on it.  Yum-cron.conf specifies 
another server for smtp.  It obviously works since I receive emails from it.

Is this a bug in yum-cron?  Am I missing something obvious?

Thanks!

-- 
Bill Gee

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 155, Issue 3

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CESA-2018:0093 Important CentOS 6 microcode_ctl   Security
  Update (Johnny Hughes)
   2. CESA-2018:0093 Important CentOS 7 microcode_ctl   Security
  Update (Johnny Hughes)
   3. CESA-2018:0094 Important CentOS 7 linux-firmware  Security
  Update (Johnny Hughes)


--

Message: 1
Date: Wed, 17 Jan 2018 14:59:21 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0093 Important CentOS 6
microcode_ctl   Security Update
Message-ID: <20180117145921.ga5...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2018:0093 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0093

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
54438c9b051c533a3b7c0eb4df3ee0b73f4bafcec4ea48428b2681e9a3aa3696  
microcode_ctl-1.17-25.4.el6_9.i686.rpm

x86_64:
5c2cc1670861c74c8ec14589d8cc9cb2b402ecb24fdb57a5472f4d213d727b37  
microcode_ctl-1.17-25.4.el6_9.x86_64.rpm

Source:
16e00d0102839f413217fd0616a7e5d204d9a9442495dccbed8e94e517096c41  
microcode_ctl-1.17-25.4.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 2
Date: Wed, 17 Jan 2018 16:50:17 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0093 Important CentOS 7
microcode_ctl   Security Update
Message-ID: <20180117165017.ga16...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2018:0093 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0093

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
9ca51137ec96c3340b38bdbc8769d52b1640c38159b443e1228c681927ba1106  
microcode_ctl-2.1-22.5.el7_4.x86_64.rpm

Source:
b7cb4af1f3498e147533df2523ebd1fe497ca9088cc26a207ecaf1b9d05a0a1e  
microcode_ctl-2.1-22.5.el7_4.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 3
Date: Wed, 17 Jan 2018 16:51:32 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2018:0094 Important CentOS 7
linux-firmware  Security Update
Message-ID: <20180117165132.ga16...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2018:0094 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2018:0094

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
477326f42dacde9755f0d662d0441e0f279225fbdb52c4f1557355bfe4ca0943  
iwl1000-firmware-39.31.5.1-58.el7_4.noarch.rpm
f4dcb45012ca1aaa758e9a31672d780270146a0070e0df6e0ed84b30824353f6  
iwl100-firmware-39.31.5.1-58.el7_4.noarch.rpm
998665697fa54cbf485c3934e4bd17b69fbb7d62792480b9598a898407b8b6fd  
iwl105-firmware-18.168.6.1-58.el7_4.noarch.rpm
1cfe05c5f1fbd5d9d393a11b9c4fe90df4def61a240eaa38fc219a795b776b1d  
iwl135-firmware-18.168.6.1-58.el7_4.noarch.rpm
ee01d9332220a7b91499180a83aae43abdfa14908f6f6139688bf017c609e68e  
iwl2000-firmware-18.168.6.1-58.el7_4.noarch.rpm
8429f035e10f57f4432929df9b218f597a368c84302cb5880d5e04fbc60395a4  
iwl2030-firmware-18.168.6.1-58.el7_4.noarch.rpm
4c989c9c1f433055cfa94e4c0246209894d9c078ad0834455e110ed0e502b647  
iwl3160-firmware-22.0.7.0-58.el7_4.noarch.rpm
8bc0c9de2f1f16da7cf7b0773809396e0f06147a3c199657fae4549c042358ec  
iwl3945-firmware-15.32.2.9-58.el7_4.noarch.rpm
52f1797d67c172b3326d152c0f0a7397b041c055fbf2e1878d596f685d8c35ee  
iwl4965-firmware-228.61.2.24-58.el7_4.noarch.rpm
a314bbb5fb6d07d3a689dbb2896fc886847e0ad9527c7655da1718ac438b6656  
iwl5000-firmware-8.83.5.1_1-58.el7_4.noarch.rpm
eae7b5d69cecf1f6a047a41bbf1c56c0c41b3beedef594263e97734482f2dcb4  
iwl5150-firmware-8.24.2.2-58.el7_4.noarch.rpm
ba5a716bc1791e844990fc37f968fc040fd5456cdf95f7aff47cc7cf042dee00  
iwl6000-firmware-9.221.4.1-58.el7_4.noarch.rpm
0b93b37d785647ca355adf71437b4d938b89aa7361bb6261937e670430ac93fb  
iwl6000g2a-firmware-17.168.5.3-58.el7_4.noarch.rpm

Re: [CentOS-virt] "Vixen" HVM shim package available in virt-xen-testing

[George Dunlap]

On Tue, Jan 16, 2018 at 10:45 AM, George Dunlap  wrote:
> To install the package:
>
>  yum --enablerepo=virt-xen-VV-testing xen-vixen
>
> Where VV is '44', '46', or '48', depending on which version you're
> using.   (It's the same package for all versions.)
>
> This will install the xen-vixen "shim" binary, as well as the
> pvshim-converter script.
>
> See XSA-254 [1] for detailed information about who should use it, why,
> and when.  Please report both successes and failures here. :-)

The package is missing two dependencies, without which the script
won't run: mformat and xorriso.  xorriso is only available from EPEL.

So to use the script, enable EPEL (if you haven't already):

yum install -y epel-release

Then install the two prerequisites:

yum install -y mformat xorriso

I'll add the mformat dependency, and see what I can do about xorriso.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Johnny Hughes]

On 01/18/2018 03:41 AM, Pete Biggs wrote:
> 
>> Look at:
>>
>> https://t.co/6fT61xgtGH
>>
>> Get the latest microcode.dat file from here:
>>
>> https://t.co/zPwagbeJFY
>>
>> See how to update the microcode from the links at the bottom of this page:
>>
>> https://t.co/EOgclWdHCw
>>
>> An before anyone asks .. I have no idea why Red Hat chose this path,
>> they did.  It doesn't matter if I (or anyone else) agrees with the
>> decision.  It is what it is.
>>
> **I'm not blaming you.**
> 
> But can I just clarify. We have to *manually* install the microcode
> update an EL7 in order to be protected against Spectre? EL6 as well?
> 
> Presumably this is to remove RH from the loop and to stop people
> blaming them - i.e. this is between Intel and the customer, it's
> nothing to do with them.
> 

No, this is because at least one major CPU (Intel type 79) is completely
broken by the Intel Microcode Update.  Those machines can't boot after
the microcode rpm is installed.  It impacts at least these processors:

Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz
Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz
Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.50GHz

There may be others.

https://bugzilla.redhat.com/show_bug.cgi?id=1532283

That means, it is NOT full-proof install and likely leaves many
servers/machines broken.  I suppose that the decision is, go pack to
what works for all machines (the last known good install) and let admins
work with their hardware vendor because the alternative is breaking things.

This also needs to be fixed with a combination of firmware updates AND
microcode updates.  All of that is outside the expertise of a Linux
vendor and is unique for each processor, chipset and firmware combination.

> What about future microcode updates? They come out reasonably regularly
>  (2 or 3 times a year) - are RH going to absolve themselves from all
> future updates because presumably the next update will also contain the
> Spectre fixes?
> 


How they handle it in the future I have no way of knowing, but if you
had 20,000 servers with the impacted CPU and you updated and could not
reboot, I would assume that you did not appreciate it.

> So, before I re-invent the wheel, does anyone have automation scripts
> to do the microcode update? I don't relish the prospect of doing this
> manually on a couple of hundred machines. Is it reasonable to grab the
> microcode_ctl SRPM and create my own updated RPM to do it?
> 

That is what I have found so far with a bit of research.

This is NOTHING about who to blame and everything about stable, working
updates .. at least it seems so to me.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Pete Biggs]

> Look at:
> 
> https://t.co/6fT61xgtGH
> 
> Get the latest microcode.dat file from here:
> 
> https://t.co/zPwagbeJFY
> 
> See how to update the microcode from the links at the bottom of this page:
> 
> https://t.co/EOgclWdHCw
> 
> An before anyone asks .. I have no idea why Red Hat chose this path,
> they did.  It doesn't matter if I (or anyone else) agrees with the
> decision.  It is what it is.
> 
**I'm not blaming you.**

But can I just clarify. We have to *manually* install the microcode
update an EL7 in order to be protected against Spectre? EL6 as well?

Presumably this is to remove RH from the loop and to stop people
blaming them - i.e. this is between Intel and the customer, it's
nothing to do with them.

What about future microcode updates? They come out reasonably regularly
 (2 or 3 times a year) - are RH going to absolve themselves from all
future updates because presumably the next update will also contain the
Spectre fixes?

So, before I re-invent the wheel, does anyone have automation scripts
to do the microcode update? I don't relish the prospect of doing this
manually on a couple of hundred machines. Is it reasonable to grab the
microcode_ctl SRPM and create my own updated RPM to do it?

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos