Re: [CentOS] Running commands as apache user

2020-08-07 Thread H
On 08/07/2020 07:56 PM, H wrote:
> I have a dilemma: I have nextcloud running under user and group apache, as 
> recommended by the installation. I now have to run some nextcloud commands 
> but even as root I cannot su to user apache because "this account is 
> currently not available". Is there a way around this? The commands must be 
> run as user apache...
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

Fixed. I found "su -l apache -s /bin/bash" on the web which allows me to get 
around the nologin.

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


[CentOS] Running commands as apache user

2020-08-07 Thread H
I have a dilemma: I have nextcloud running under user and group apache, as 
recommended by the installation. I now have to run some nextcloud commands but 
even as root I cannot su to user apache because "this account is currently not 
available". Is there a way around this? The commands must be run as user 
apache...

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


[CentOS] CentOS advisories for 8 release

2020-08-07 Thread Olivier Bonhomme

Hello dear CentOS community,

I'm writing on this mailing list because I'm discovering CentOS 8 after 
several years of practice on CentOS 7.


One of my main concern about a distribution is Bug Fixes and Security 
Fixes. For CentOS 7, all fixes where identified on CentOS-Announces 
lists with CESA, CEBA and CEEA which is a good thing in order to 
identify how a distribution can be broken, vulnerable.


However, I didn't find any announcement for CentOS 8. I tried to 
investigate about any changes about announcement policies but I didn't 
find anything reliable.


So I'm asking here what is exactly the status about announcements for 
CentOS 8 ? Is it a thing who totally disappeared replaced by Red Hat 
advisories or is it something different ? Or maybe it is just not 
planned yet ?


Explanations would be very welcomed.

Thanks for your answer

Regards,
Olivier Bonhomme

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


[CentOS] Reset booleans to default value ?

2020-08-07 Thread Nicolas Kovacs
Hi,

Here's a list of all the booleans I tweaked on my server running CentOS 7:

$ sudo cat /etc/selinux/targeted/active/booleans.local
# This file is auto-generated by libsemanage
# Do not edit directly.

named_write_master_zones=0
httpd_can_sendmail=1
httpd_unified=1
ftpd_full_access=1
httpd_can_network_connect=1
spamd_enable_home_dirs=1

How can I "reset" (in a manner of speaking) these booleans to their default
value post-install?

Ideally, the booleans.local file should be empty, but since it's
auto-generated, there's not much sense in simply erasing it.

Curiously enough, I didn't find any information about this.

Cheers,

Niki
-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Strahil Nikolov via CentOS
Hi Alessandro,

Compared to Microsoft ,  both RH and SuSE are awesome.
You  always need a patch management  strategy  with locked  repos  
(spacewalk/pulp)  which can be tested on less important systems,  prior 
deployment on Prod.
Keep in mind that Secureboot is hard to  deploy in Virtual Environments and 
thus testing is not so easy.

Of course, contributing to the community was always welcomed.

Best  Regards,
Strahil Nikolov

На 7 август 2020 г. 10:40:01 GMT+03:00, Alessandro Baggi 
 написа:
>
>Il 07/08/20 08:22, Johnny Hughes ha scritto:
>>> "How on earth could this have passed Q & A ?"
>
>Hi Johnny,
>Niki's question is spread, legit, in the thoughts in many and many
>users 
>so don't see this as an attack. Many and many users,though really "if 
>this was tested before release" and I think that many of us are 
>incredulous at what happened on CentOS and in the upstream (specially
>in 
>the upstream) but as you said CentOS inherits RHEL bugs. I'm reading 
>about many users that lost their trust in RH with the last 2 problem 
>(microcode and shim). This is bad for CentOS.
>
>> Well, I mean that would be a valid point if it happened for every
>> install.  The issue did not happen on every install.  There is no way
>to
>> test every single hardware and firmware combination for every single
>> computer ever built :)
>>
>> It would be great if things like this did not happen, but with the
>> universe of possible combinations, i am surprised it does not happen
>> more often.
>
>Probably many users have not updated their machines between the bug 
>release and the resolution (thanks to your fast apply in the weekend, 
>thank you) and many update their centos machines on a 2 months base (if
>
>not worst). I think also that many users of CentOS user base have not 
>proclamed their disappointement/the issue on this list or in other 
>channels. For example I simply updated in the wrong time.
>
>> We do run boot tests of every single kernel for CentOS.  The RHEL
>team
>> runs many more tests for RHEL.  But every possible combination from
>> every vendor can't possibly be tested. Right?
>
>you are right but is not UEFI a standard and it shouldn't work the same
>
>on several vendors? I ask this because this patch broken all my uefi 
>workstations.
>
>While CentOS team could not have so much resources to run this type of 
>tests would be great to know what happened to RHEL QA (being RH giant) 
>for this release and given the partenership between CentOS and RH if
>you 
>know something more on this.
>
>Thank you.
>
>___
>CentOS mailing list
>CentOS@centos.org
>https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Alessandro Baggi



Il 07/08/20 15:46, Stephen John Smoogen ha scritto:

On Fri, 7 Aug 2020 at 09:15, Chris Adams  wrote:

Once upon a time, Alessandro Baggi  said:

you are right but is not UEFI a standard and it shouldn't work the
same on several vendors? I ask this because this patch broken all my
uefi workstations.

The great thing about standards is there's so many to choose from!  Also
relevant: https://xkcd.com/927/

UEFI has gone through a number of revisions over the years, and has
optional bits like Secure Boot (which itself has gone through
revisions).  Almost any set of standards has undefined corners where
vendors interpret things differently.  Vendors also have bugs in weird
places sometimes.


I go with the lines from Pirates of the Carribean movie.. it is less
of a rigid code and more a set of guidelines. Computer programmers are
a surly lot, and most take any MUST/SHALL in a standard a personal
challenge on how to make it pass a test but do so in an interesting
way.

+1 Jack :D
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Leon Fauster via CentOS

Am 07.08.20 um 17:17 schrieb Alessandro Baggi:


Hi Johnny,

what is the current status of the notification tool for security updates 
on C8? There are possibilities to get soon announces on ML for EL8?


Would be great have the tool working.





As I understand some kind of mapping must be implemented
for indexcode+gitcommitid beetween CentOS and RH ...

https://lists.centos.org/pipermail/centos/2020-August/351263.html



--
Leon


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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Alessandro Baggi


Il 07/08/20 14:53, Johnny Hughes ha scritto:

On 8/7/20 5:30 AM, Phil Perry wrote:

On 07/08/2020 10:01, Johnny Hughes wrote:

On 8/7/20 3:46 AM, Nicolas Kovacs wrote:

Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :

Probably many users have not updated their machines between the bug
release and
the resolution (thanks to your fast apply in the weekend, thank you)
and many
update their centos machines on a 2 months base (if not worst). I
think also
that many users of CentOS user base have not proclamed their
disappointement/the issue on this list or in other channels. For
example I
simply updated in the wrong time.

I'm using yum-cron to keep all my server updated on a daily basis.

And my question "How could this have passed Q & A" was obviously
directed at
Red Hat... and *not* at Johnny Hughes and the CentOS team who do
their best to
deliver the best possible downstream system. I raise my morning
coffee mug to
your health, guys.

Cheers,

Niki


I can assure you .. a BUNCH of testing was done.  Because of the scope
of this udpate, the CentOS team was looped in during the embargo stage
(we normally are not .. Red Hat Engineering got permission to make this
happen for this issue). Normally we see things that are open source only
.. not embargoed content.  Once the embargo gets lifted, the items
become open source.  Kudos to the RH team for making this happen.

The CentOS team worked with the RHEL team on this update for several
days (more than a week, for sure, maybe 2 weeks)

I gained MUCH respect for all those guys .. especially  Peter Jones.  He
is Mr.Secure Boot.

I personally tested both the c8 and c7 solutions on several machines
(All i have access to actually, including several personal machines that
have secureboot).  I saw some of the testing that happened on the RHEL
side.  It was extensive.


I'll just add to Johnny's already comprehensive reply. As a member of
the CentOS QA team, I personally tested the update on 3 physical
machines and all worked fine. Moreover, the QA team was not able to
replicate the issue on a single physical machine available to them - the
first indication of a problem came from public reports. We give up a
huge amount of our personal time and resources to ensure CentOS (and
RHEL) are the very best products they can be. I'm unsure what more could
have been done.

Thanks Phil,

I very much appreciate all you and the rest of the QA team do.

I know it is a knee jerk reaction to say .. how did that not get caught.
  I actually said it MYSELF for this very issue.  But looking back, I am
not sure how we could have caught it.

"Stuff Happens"  :)

There are just a huge number of possible combinations.


Hi Johnny,

what is the current status of the notification tool for security updates 
on C8? There are possibilities to get soon announces on ML for EL8?


Would be great have the tool working.

Thank you.

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Nicolas Kovacs
Le 07/08/2020 à 11:01, Johnny Hughes a écrit :

> 
> Microsoft, Debian, Ubuntu and others also had issues with this .. so if
> you are losing trust, you are losing it with all OS vendors WRT this issue.
> 
> All I can say is .. this issue was the hardest thing I have been
> involved with since starting with the CentOS Project 17 years ago.
> 
> Obviously, everyone involved in this build would have prevented this
> from happening if they could have.  Secureboot is complicated.

In my head I've filed this under the "sh*t happens" category. Bad luck this
happened on the first day of my holiday, so I had to cancel a hiking trip. :o)

This being said, rest assured my confidence in the CentOS project is still 100
% intact. On a side note, I've just published my third book about CentOS here
in France.

Keep up the good work,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Simon Matter via CentOS
> On 8/7/20 5:30 AM, Phil Perry wrote:
>> On 07/08/2020 10:01, Johnny Hughes wrote:
>>> On 8/7/20 3:46 AM, Nicolas Kovacs wrote:
 Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :
> Probably many users have not updated their machines between the bug
> release and
> the resolution (thanks to your fast apply in the weekend, thank you)
> and many
> update their centos machines on a 2 months base (if not worst). I
> think also
> that many users of CentOS user base have not proclamed their
> disappointement/the issue on this list or in other channels. For
> example I
> simply updated in the wrong time.

 I'm using yum-cron to keep all my server updated on a daily basis.

 And my question "How could this have passed Q & A" was obviously
 directed at
 Red Hat... and *not* at Johnny Hughes and the CentOS team who do
 their best to
 deliver the best possible downstream system. I raise my morning
 coffee mug to
 your health, guys.

 Cheers,

 Niki

>>> I can assure you .. a BUNCH of testing was done.  Because of the scope
>>> of this udpate, the CentOS team was looped in during the embargo stage
>>> (we normally are not .. Red Hat Engineering got permission to make this
>>> happen for this issue). Normally we see things that are open source
>>> only
>>> .. not embargoed content.  Once the embargo gets lifted, the items
>>> become open source.  Kudos to the RH team for making this happen.
>>>
>>> The CentOS team worked with the RHEL team on this update for several
>>> days (more than a week, for sure, maybe 2 weeks)
>>>
>>> I gained MUCH respect for all those guys .. especially  Peter Jones. 
>>> He
>>> is Mr.Secure Boot.
>>>
>>> I personally tested both the c8 and c7 solutions on several machines
>>> (All i have access to actually, including several personal machines
>>> that
>>> have secureboot).  I saw some of the testing that happened on the RHEL
>>> side.  It was extensive.
>>>
>>
>> I'll just add to Johnny's already comprehensive reply. As a member of
>> the CentOS QA team, I personally tested the update on 3 physical
>> machines and all worked fine. Moreover, the QA team was not able to
>> replicate the issue on a single physical machine available to them - the
>> first indication of a problem came from public reports. We give up a
>> huge amount of our personal time and resources to ensure CentOS (and
>> RHEL) are the very best products they can be. I'm unsure what more could
>> have been done.
>
> Thanks Phil,
>
> I very much appreciate all you and the rest of the QA team do.
>
> I know it is a knee jerk reaction to say .. how did that not get caught.
>  I actually said it MYSELF for this very issue.  But looking back, I am
> not sure how we could have caught it.
>
> "Stuff Happens"  :)
>

Crowd testing? Feed the green bananas to the crowd and let them ripe. It
works well for some of the biggest software companies :-)

At least it could make sense for directly hardware related stuff like
kernel, boot loader, firmware/microcode and similar.

Regards,
Simon

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Simon Matter via CentOS
> Once upon a time, Alessandro Baggi  said:
>> you are right but is not UEFI a standard and it shouldn't work the
>> same on several vendors? I ask this because this patch broken all my
>> uefi workstations.
>
> The great thing about standards is there's so many to choose from!  Also
> relevant: https://xkcd.com/927/
>
> UEFI has gone through a number of revisions over the years, and has
> optional bits like Secure Boot (which itself has gone through
> revisions).  Almost any set of standards has undefined corners where
> vendors interpret things differently.  Vendors also have bugs in weird
> places sometimes.
>
> The firmware and boot loaders arguably are the least "exercised" parts
> of a system - both change rarely and there are few implementations.
> There's not many combinations, and they don't change a lot.
>
> I'm interested to read about the cause of this issue - something like
> this can be a lesson on "hmm, hadn't thought of that before" type things
> to watch for in other areas.

If you ask me I think the real root of the problem is that the UEFI/Secure
Boot developers didn't know KISS - or they forgot about it. Once such a
beast is born you can not handle it correctly no matter how much you try.

Regards,
Simon

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Stephen John Smoogen
On Fri, 7 Aug 2020 at 09:15, Chris Adams  wrote:
>
> Once upon a time, Alessandro Baggi  said:
> > you are right but is not UEFI a standard and it shouldn't work the
> > same on several vendors? I ask this because this patch broken all my
> > uefi workstations.
>
> The great thing about standards is there's so many to choose from!  Also
> relevant: https://xkcd.com/927/
>
> UEFI has gone through a number of revisions over the years, and has
> optional bits like Secure Boot (which itself has gone through
> revisions).  Almost any set of standards has undefined corners where
> vendors interpret things differently.  Vendors also have bugs in weird
> places sometimes.
>

I go with the lines from Pirates of the Carribean movie.. it is less
of a rigid code and more a set of guidelines. Computer programmers are
a surly lot, and most take any MUST/SHALL in a standard a personal
challenge on how to make it pass a test but do so in an interesting
way.



> The firmware and boot loaders arguably are the least "exercised" parts
> of a system - both change rarely and there are few implementations.
> There's not many combinations, and they don't change a lot.
>
> I'm interested to read about the cause of this issue - something like
> this can be a lesson on "hmm, hadn't thought of that before" type things
> to watch for in other areas.
> --
> Chris Adams 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS-announce] CEBA-2020:3355 CentOS 7 subscription-manage BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3355 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3355

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

x86_64:
1c927db066d49d2572c84d77b53b0152ce2ba9a04520f93e897c15cdc8fd46a5  
python-syspurpose-1.24.26-4.el7.centos.x86_64.rpm
31468f95062ca8fa88067ef39ba88f6eecd517d7a203635e18d88225a8acb427  
rhsm-gtk-1.24.26-4.el7.centos.x86_64.rpm
9aa646de32ca88972bf93a978410a05d61c3d74879acf70f8887856b278d25c2  
subscription-manager-1.24.26-4.el7.centos.x86_64.rpm
6dac13f254edbe203f0d68e9d6b4bb5eb7a7f0c862351d15722295a78d9a257d  
subscription-manager-cockpit-1.24.26-4.el7.centos.noarch.rpm
251a068e56bb4816188fbce34d909886b0b02c3bad468d0e4e3825739aee9e14  
subscription-manager-gui-1.24.26-4.el7.centos.x86_64.rpm
0b8c765849f43d0d81d66dfeb49dafd2f2e14b0aa2e7dec718c78cce7d2efb1d  
subscription-manager-initial-setup-addon-1.24.26-4.el7.centos.x86_64.rpm
194e384492a53d4bff6c4b772d366eb2594020465973fd4442d483cde5117b04  
subscription-manager-plugin-container-1.24.26-4.el7.centos.x86_64.rpm
6454bc386904286cab7d050a3caec7ef1a83d84dd106a943e59fc5b5f232f014  
subscription-manager-plugin-ostree-1.24.26-4.el7.centos.x86_64.rpm
b02caf885b59066ab1966c0082bf91a5eeffb7606f3f9d26807f53cea39eab32  
subscription-manager-rhsm-1.24.26-4.el7.centos.x86_64.rpm
c0e63169421d350f84ad5b85faa7513a4404dedc34039fa7035730e980c699f1  
subscription-manager-rhsm-certificates-1.24.26-4.el7.centos.x86_64.rpm

Source:
ff8247b904efa20e0d45b9f8c21545793e20bebf55dfd9cd708b4d8d2695605a  
subscription-manager-1.24.26-4.el7.centos.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] CEBA-2020:3354 CentOS 7 libreswan BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3354 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3354

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

x86_64:
c205e6c8f267b531e6cb7cdabe53c2b3cda12f1afd4735ece2a55f5c116d0159  
libreswan-3.25-9.1.el7_8.x86_64.rpm

Source:
9fa72dc64fb2cbf7abd5961455b8d7de3e7bf228fb8380dc66ff74d573de1492  
libreswan-3.25-9.1.el7_8.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] CEBA-2020:3349 CentOS 7 sssd BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3349 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3349

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

x86_64:
951fc236cc64f56e35cbac9230458a0b7e9f02ce0ca94111f13b21728f3b01d6  
libipa_hbac-1.16.4-37.el7_8.4.i686.rpm
de6f5b0f12a323a952eac6fb26a71f83c4b31a17e73b674f17e0c25c3f0d5f28  
libipa_hbac-1.16.4-37.el7_8.4.x86_64.rpm
bdf75258c4c5982943a0164ed90fb4e38c59e624b2d32c77243a08c7572773a8  
libipa_hbac-devel-1.16.4-37.el7_8.4.i686.rpm
9e9e5f103edaffb9279059b2cf845ba927049d9afee19a71882882af28fbe12f  
libipa_hbac-devel-1.16.4-37.el7_8.4.x86_64.rpm
18feb09f3b6e5ac1a0aac276866af303cde065e854ab4351f0e9f6c43850f177  
libsss_autofs-1.16.4-37.el7_8.4.x86_64.rpm
4a257178b7d51080d29e42e53a5f92872cdf2243577473f2697565426c704a5f  
libsss_certmap-1.16.4-37.el7_8.4.i686.rpm
9f7df78e88a9ebcf9ac28fd22145329ef2187f908b3331e46c941ad35f27c590  
libsss_certmap-1.16.4-37.el7_8.4.x86_64.rpm
0aba5df1a174057050040f1cc7a8f0ae762fe8f0629dee49fe30b083ad25e9c3  
libsss_certmap-devel-1.16.4-37.el7_8.4.i686.rpm
7d4d2077888381b8547bde72a0147cd0a07b14c3665d3ed357d2f0cabf16565b  
libsss_certmap-devel-1.16.4-37.el7_8.4.x86_64.rpm
40af5b1a1322d4f5a1e460d7159c6b22e20cb5860c374a5fb0bcd8416f7f4cd6  
libsss_idmap-1.16.4-37.el7_8.4.i686.rpm
c3f3aec998aabd137978361995084df8c304b6cf6dcb6d52a370810143408dd7  
libsss_idmap-1.16.4-37.el7_8.4.x86_64.rpm
604c9865933f37465ce10184b730e8f3def1530a1b673c6716d30ba5894f  
libsss_idmap-devel-1.16.4-37.el7_8.4.i686.rpm
549bb38e7f9f2b41b58ed83df096931c805553c62cc77bef63a5132ca464d3ac  
libsss_idmap-devel-1.16.4-37.el7_8.4.x86_64.rpm
da0ff01442f292320033fcf40983e8cc391f3147cc4b9d82ec110e6b4a8612ee  
libsss_nss_idmap-1.16.4-37.el7_8.4.i686.rpm
776d9e1183b29511bb664261fcb50ff18cfcf03f09983ee0cda2262d1bf9214f  
libsss_nss_idmap-1.16.4-37.el7_8.4.x86_64.rpm
0bb688d4fdb510b6aa3305dd4f04eb123defdb4b1b4e7adf5ea05fd8c8035910  
libsss_nss_idmap-devel-1.16.4-37.el7_8.4.i686.rpm
83ef5b96c747c01f20f91131e073a42b034309463c767434107ac7622cb6588d  
libsss_nss_idmap-devel-1.16.4-37.el7_8.4.x86_64.rpm
f9a25ae69ede6a881d1ee057dfc324ba166a2437b2ee76675aae535e03a6d292  
libsss_simpleifp-1.16.4-37.el7_8.4.i686.rpm
8deb1cf27707b4157e2d35b534127a519e5c9ec2ed04a66fdc2ee7eac0e3a9b4  
libsss_simpleifp-1.16.4-37.el7_8.4.x86_64.rpm
ad330f1c4d29533cd112e262db9aac8d6cd05d8f7c95e92d6b403a45ac934423  
libsss_simpleifp-devel-1.16.4-37.el7_8.4.i686.rpm
975a0ec56c1e93233de9b5f1b88c36c089d0f97bdab02f1338de5a8e2def69f3  
libsss_simpleifp-devel-1.16.4-37.el7_8.4.x86_64.rpm
11648abbd4f5328bb3ec6ccc429907af6e57508806777147a4163dd47bbd657c  
libsss_sudo-1.16.4-37.el7_8.4.x86_64.rpm
08ae769c871b5a5ba80e3d03b3633ac25bd441ee207c5ece704b30d78ff0a73a  
python-libipa_hbac-1.16.4-37.el7_8.4.x86_64.rpm
a88b7709cda2745e911e7b17a20bd551c92d0a76fec7bd71df37075d69a90764  
python-libsss_nss_idmap-1.16.4-37.el7_8.4.x86_64.rpm
f7131988ed7fd2ef3bb0029ffc17668dbb3ba55046e443bac889a36fe10dc0c1  
python-sss-1.16.4-37.el7_8.4.x86_64.rpm
4033e9d709feccb8259d1502d2e4b628ad8784a4411ed8b5be28bda4da62414b  
python-sssdconfig-1.16.4-37.el7_8.4.noarch.rpm
2e7004d1968ff0e18ec095c8abc1a73489809b1396c392e4c4761c434f6084e7  
python-sss-murmur-1.16.4-37.el7_8.4.x86_64.rpm
f532fdec191ef4df783588315603da50f35c3575b082e22df9c5dc7b672c5002  
sssd-1.16.4-37.el7_8.4.x86_64.rpm
b05cf098b124b0e5c8ead1606bf991143528c832ed99eb96560a13bd0225ad48  
sssd-ad-1.16.4-37.el7_8.4.x86_64.rpm
4fb4b7a169cbdbcea5b5cde8e127c75879de15cec42e7b8a1b319c2d2453c213  
sssd-client-1.16.4-37.el7_8.4.i686.rpm
7a46b3da0245464a79e1281a79f0596c8dcc4a061e4810c2c636840e930b7472  
sssd-client-1.16.4-37.el7_8.4.x86_64.rpm
c6e4ed20c732c4eb29c6832618c6c9cb2228db0d78992e1ad01bba4d146cecf4  
sssd-common-1.16.4-37.el7_8.4.x86_64.rpm
2763fdaeb5f910cb6707a6f6aaa0a478911f0a3c9076496462911d923862b33d  
sssd-common-pac-1.16.4-37.el7_8.4.x86_64.rpm
a0117e31fc98d241300acd5f5c842689f64c41ae0dafd733ae76211a536b99a9  
sssd-dbus-1.16.4-37.el7_8.4.x86_64.rpm
3ed23e867739a86334b5c8e928dfd2c6111426cec4c14570b43fc89b25ed7fa3  
sssd-ipa-1.16.4-37.el7_8.4.x86_64.rpm
a1a3dbd2e49bffcd5290a411f675d0202a93bbe4567cc51c81a0771fb31715ec  
sssd-kcm-1.16.4-37.el7_8.4.x86_64.rpm
94a2e518b7228034d268b8a114a1b1f233f017cb28dffcf88e82c2207fd73d4a  
sssd-krb5-1.16.4-37.el7_8.4.x86_64.rpm
060c08fb78f3758c88f9a4a6ee5eeba408b602f1d3357b83180566a4d8d93916  
sssd-krb5-common-1.16.4-37.el7_8.4.x86_64.rpm
4ec48a061d2ab2c5e771589ff4dbe2d7e8334ea2e2d2e9c3834f8994379a6bdb  
sssd-ldap-1.16.4-37.el7_8.4.x86_64.rpm
ce1e7a403bb1a64cf8beb0d2fbf12fc85dab20960e978efe858386b687531668  
sssd-libwbclient-1.16.4-37.el7_8.4.x86_64.rpm
e1d4ed400e1a67410fc8debcd49ea116a9997543eb5bc7fd044ed76f9f4dfa3a  
sssd-libwbclient-devel-1.16.4-37.el7_8.4.i686.rpm
2980c43373fa3a063fb892d311e776a297ccc7582a9d188fc6e9129c2d38bd2f  
sssd-libwbclient-devel-1.16.4-37.el7_8.4.x86_64.rpm
3db373a29f4ebc71670875aa680289bcba5490a0b4798d116df09989f687d9d5  

[CentOS-announce] CEBA-2020:3348 CentOS 7 curl BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3348 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3348

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

x86_64:
ee225e394bfa89bf736af8ccbdc1de6dd411a05ede84e4493d27f935cee02a32  
curl-7.29.0-57.el7_8.1.x86_64.rpm
88ee4332615170eedaac483e9c5f7d0751be7ffcf7afd65cd6f2e8ce384e6e34  
libcurl-7.29.0-57.el7_8.1.i686.rpm
8efe21c365f79b4f7aa8f282faecff8f6d5acf301bd09c85d475eb736077c2db  
libcurl-7.29.0-57.el7_8.1.x86_64.rpm
ad59135146f02ca9ba3bb097f53883bd64e4a4b37df29f5f87c07e3728cd895d  
libcurl-devel-7.29.0-57.el7_8.1.i686.rpm
4e5cb836df4034cb950555892c1260a7903557e80f9c40ac80689627054674a5  
libcurl-devel-7.29.0-57.el7_8.1.x86_64.rpm

Source:
cb8a06720f8bf740f3f8023d4da375ede8dd4d5876f4c1a2969e20e5a4e269a5  
curl-7.29.0-57.el7_8.1.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-2020:3253 Important CentOS 7 firefox Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3253 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3253

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

x86_64:
c05f2405cfacec8c3474e4d03a33e999ca1ce8cd292603d6a09ae4709a2b3d37  
firefox-68.11.0-1.el7.centos.i686.rpm
d33e218058831eee24361057e3fc29e409d9ae6f2e73f76af0541a2311584a89  
firefox-68.11.0-1.el7.centos.x86_64.rpm

Source:
66241fa85b0f1176b74f76794478a4005fdf335985bf7f8c117d064b7b6e9636  
firefox-68.11.0-1.el7.centos.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-2020:3344 Important CentOS 7 thunderbird Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3344 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3344

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

x86_64:
1843f66766dd4e3ec0481895eb214582b167995238898e2666b1dcb523e0a7a1  
thunderbird-68.11.0-1.el7.centos.x86_64.rpm

Source:
ad6d42bca1ff78685b464bb05fab28a9ddedde5fc9c7a4a71de77fef45fedc6d  
thunderbird-68.11.0-1.el7.centos.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-2020:3233 Important CentOS 6 firefox Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3233 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3233

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

i386:
7044f145b77b097e9563a8f3db28972097d7f4690d7a80199e49b49d3d61cc5e  
firefox-68.11.0-1.el6.centos.i686.rpm

x86_64:
7044f145b77b097e9563a8f3db28972097d7f4690d7a80199e49b49d3d61cc5e  
firefox-68.11.0-1.el6.centos.i686.rpm
8ee0612e553f9f3f549f841001f353e36807f2e803fc80e4e053e445d9eb741c  
firefox-68.11.0-1.el6.centos.x86_64.rpm

Source:
ef35f3d262b5627d8b0868c42ab00cb41ffd5709a07db75b5a16ab638020a3e7  
firefox-68.11.0-1.el6.centos.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-2020:3345 Important CentOS 6 thunderbird Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3345 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3345

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

i386:
5ca8ca5aed2e182a74276462102ae266b546b12bc4823ebcd7cc07b4412f741a  
thunderbird-68.11.0-1.el6.centos.i686.rpm

x86_64:
d00deca958deb6d40c61b780599f9d56822cca073952ad0db29041d2249d7c5e  
thunderbird-68.11.0-1.el6.centos.x86_64.rpm

Source:
3c8d27d6bbb365d6be581f8bddf126d8d3f6df8bfc173377a4189e5cb93c372d  
thunderbird-68.11.0-1.el6.centos.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-2020:3284 Important CentOS 6 postgresql-jdbc Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3284 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3284

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

i386:
7da24f52d632e4a7bfe00e2133a719c22e6927e21c74a8c4a584b001aeb35df8  
postgresql-jdbc-8.4.704-4.el6_10.noarch.rpm

x86_64:
7da24f52d632e4a7bfe00e2133a719c22e6927e21c74a8c4a584b001aeb35df8  
postgresql-jdbc-8.4.704-4.el6_10.noarch.rpm

Source:
72decf7b6b1f789fbe15f76d71c768e6d5c95ea45c37ceea449a6b578ee61a8c  
postgresql-jdbc-8.4.704-4.el6_10.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-2020:2985 Important CentOS 6 java-1.8.0-openjdk Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:2985 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:2985

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

i386:
f75a638d28154c766756d9aeca9aaa885edbdd2783a700aae8503ede26f48498  
java-1.8.0-openjdk-1.8.0.262.b10-0.el6_10.i686.rpm
1876e63dc8c5bcc3c01732633a6d9396db5c7450ccc8e94975e56500ddfa080c  
java-1.8.0-openjdk-debug-1.8.0.262.b10-0.el6_10.i686.rpm
18c3d30bbbf499bd04d2efb8ec4898f27b9ab7465fb62d632dac9c276e384a44  
java-1.8.0-openjdk-demo-1.8.0.262.b10-0.el6_10.i686.rpm
8668ccefe8d0a342b85e05f973e91ce83fa123156909e77080fafd808d742eaf  
java-1.8.0-openjdk-demo-debug-1.8.0.262.b10-0.el6_10.i686.rpm
e3e9e43f455d3a1f0fb0fe0d76d173d6f03e679a41d0792ec423e1938307048c  
java-1.8.0-openjdk-devel-1.8.0.262.b10-0.el6_10.i686.rpm
12785de8d77d72818f91005350514866bb71773a32e9f9f8441921027d805d7e  
java-1.8.0-openjdk-devel-debug-1.8.0.262.b10-0.el6_10.i686.rpm
7e8bc1a88dd9e1ae7b2e1796047dbd23d0fecd3f8359123507f3e104c33c5f99  
java-1.8.0-openjdk-headless-1.8.0.262.b10-0.el6_10.i686.rpm
33d5602fa98dbacd65ced6a3c6bdc07e19b1d0a41b1aa1245f2589ee8ef8eb9c  
java-1.8.0-openjdk-headless-debug-1.8.0.262.b10-0.el6_10.i686.rpm
fa3012271b3417ee47ffbabbc4796c960a1ab4581b0050330f7be6fce79d9396  
java-1.8.0-openjdk-javadoc-1.8.0.262.b10-0.el6_10.noarch.rpm
5a526cf985821b87a11622b883216a0684c42a2bbcef5a8dffdcce9b0051d7db  
java-1.8.0-openjdk-javadoc-debug-1.8.0.262.b10-0.el6_10.noarch.rpm
ee7cdcaecfaa87fa778a608a8cd55dfe8ecc90f085078481af1e656f5d20e4fc  
java-1.8.0-openjdk-src-1.8.0.262.b10-0.el6_10.i686.rpm
742bc65e528fb22755fdbe43b620de70aa4c2bc3e0800382c38475ecbf93df88  
java-1.8.0-openjdk-src-debug-1.8.0.262.b10-0.el6_10.i686.rpm

x86_64:
1bef0dcee38ee08a34d74db4846192699e8b61586651aa083915bad611d04fb0  
java-1.8.0-openjdk-1.8.0.262.b10-0.el6_10.x86_64.rpm
951270257f960d024c4351519ca8837f5040f175f99d7eae4eb082067a6e50e1  
java-1.8.0-openjdk-debug-1.8.0.262.b10-0.el6_10.x86_64.rpm
604fde532fd66a74fe7ea1eb6fa8566023cba64b5ae61320b5ae6a93c3b6ce6f  
java-1.8.0-openjdk-demo-1.8.0.262.b10-0.el6_10.x86_64.rpm
400bccddfdafb028e6e685d8503e8c1ede80a54d78ba973004ab380f2c5b0d8c  
java-1.8.0-openjdk-demo-debug-1.8.0.262.b10-0.el6_10.x86_64.rpm
71c47203564d984c673d15146861601a77b0c01f28f43d1e74215ce072eeae94  
java-1.8.0-openjdk-devel-1.8.0.262.b10-0.el6_10.x86_64.rpm
e9082bae3be8fa82f4f6256640d796ff5617dc4b6ae4cc4c12ec00394a95859b  
java-1.8.0-openjdk-devel-debug-1.8.0.262.b10-0.el6_10.x86_64.rpm
847168d108cc411613839297d78f9943543391c0e85316cc7e49398b18235af9  
java-1.8.0-openjdk-headless-1.8.0.262.b10-0.el6_10.x86_64.rpm
cb47353d46c301885dedb4852c0b22e6c136148b52ff462bd4316811dfe2c97f  
java-1.8.0-openjdk-headless-debug-1.8.0.262.b10-0.el6_10.x86_64.rpm
fa3012271b3417ee47ffbabbc4796c960a1ab4581b0050330f7be6fce79d9396  
java-1.8.0-openjdk-javadoc-1.8.0.262.b10-0.el6_10.noarch.rpm
5a526cf985821b87a11622b883216a0684c42a2bbcef5a8dffdcce9b0051d7db  
java-1.8.0-openjdk-javadoc-debug-1.8.0.262.b10-0.el6_10.noarch.rpm
5425d0fefb4ae469e9126bf6583470093669126808106874b4418472a56d1708  
java-1.8.0-openjdk-src-1.8.0.262.b10-0.el6_10.x86_64.rpm
886dce58b333eb7b5dda2f290bf95c31707c3012b0dbd05254fe5ad01ef66401  
java-1.8.0-openjdk-src-debug-1.8.0.262.b10-0.el6_10.x86_64.rpm

Source:
efc8feb6d3b3479a7521be9a643f583f4f8cd77ef54699413a4e4b54caeb38c0  
java-1.8.0-openjdk-1.8.0.262.b10-0.el6_10.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-2020:2968 Important CentOS 7 java-1.8.0-openjdk Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:2968 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:2968

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

x86_64:
8f532a7f0a9990179096861d989457eea9f7c24edd5b3d341dc10c80f1df4c6d  
java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.i686.rpm
4157b121445b5c96d528d8bdce4d74a1db80e85b1aa5381c3c6f234e48252e12  
java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64.rpm
67bef95466a88959ff6f628ff841e0520c29c9a342d14db3c79fd2e0d28c24a7  
java-1.8.0-openjdk-accessibility-1.8.0.262.b10-0.el7_8.i686.rpm
b3c37393386892c3d785cd1e9c992f1a21cb1192bab0843fe54e5b4adae99a86  
java-1.8.0-openjdk-accessibility-1.8.0.262.b10-0.el7_8.x86_64.rpm
eb98030160767bedcae681955fbfe61ddaf3ce240b8235fd0b49038bb76f081a  
java-1.8.0-openjdk-demo-1.8.0.262.b10-0.el7_8.i686.rpm
cc621a3587b79b7bcb34c2d61ba251003fd1135ceb35954b8ad8cb4d28821eb9  
java-1.8.0-openjdk-demo-1.8.0.262.b10-0.el7_8.x86_64.rpm
9e5dc66739f0a75c5667ad152ed9c6c5b05e87c43a1aba2b696426132db70ced  
java-1.8.0-openjdk-devel-1.8.0.262.b10-0.el7_8.i686.rpm
a254d18accf85eabddb12b71d74683267d6b8c50c5b52b432489dc26da022f59  
java-1.8.0-openjdk-devel-1.8.0.262.b10-0.el7_8.x86_64.rpm
a61026d900ca0f74c38b7b37467fea46fa28f5b85e9a196b0bcd45e581d130e7  
java-1.8.0-openjdk-headless-1.8.0.262.b10-0.el7_8.i686.rpm
e2ab13df96583856fe6833bc907fa6cf19ceca648eb39e7ad3249970d41b1c2a  
java-1.8.0-openjdk-headless-1.8.0.262.b10-0.el7_8.x86_64.rpm
75ad65bcf12772af5222e052e70544be9a8af0fde301200a4a13ce9687c43720  
java-1.8.0-openjdk-javadoc-1.8.0.262.b10-0.el7_8.noarch.rpm
05457a56238a851fcd82d51c688a9802e3ad782dbc20ccce63d598870e75afb5  
java-1.8.0-openjdk-javadoc-zip-1.8.0.262.b10-0.el7_8.noarch.rpm
51e36310bdc0ddce15d267dc6944de19a91a9d19e9dd44f37ad4ddbdd0724d41  
java-1.8.0-openjdk-src-1.8.0.262.b10-0.el7_8.i686.rpm
540929693f191dacff0dac4cceb9ec615306ccfbce80d5a1d0429d29ad8ca70e  
java-1.8.0-openjdk-src-1.8.0.262.b10-0.el7_8.x86_64.rpm

Source:
f54585510704640991a5e66c7b0e2891db5792771110f207d661d630730898cd  
java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.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-2020:2969 Important CentOS 7 java-11-openjdk Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:2969 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:2969

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

x86_64:
f0baba96420d32cf4eebb994427ba2f86c7118788b4b3418c7b9402e2cd3c429  
java-11-openjdk-11.0.8.10-0.el7_8.i686.rpm
30b285edd46334713aa83e0b1b65a1b650ea385c267f67b0dd03546ac5d41329  
java-11-openjdk-11.0.8.10-0.el7_8.x86_64.rpm
9cec6ada57d884a042c6dac053f24360fa6d08e10d8cc3d5ae4425221285ae27  
java-11-openjdk-demo-11.0.8.10-0.el7_8.i686.rpm
04f656bf38e094ddfd1d3cdc3cdaab3c6143d0a01cf84af3b6adb01f43f3d3cd  
java-11-openjdk-demo-11.0.8.10-0.el7_8.x86_64.rpm
f5da7a184df2e97305571f4ef8d722f55bd7e2e511665a80b815081a382a6402  
java-11-openjdk-devel-11.0.8.10-0.el7_8.i686.rpm
e08bed834260820266f02776e247df0a271225ba91dbb647ac4a1199a40c8df6  
java-11-openjdk-devel-11.0.8.10-0.el7_8.x86_64.rpm
ed21b65052096b035615416b6caad336ad7ed21f7c00249fbed2114334613899  
java-11-openjdk-headless-11.0.8.10-0.el7_8.i686.rpm
4bb37201217d3967dd808c606e2278fb6bc38d94a6f7649ece2629ee1f7ec627  
java-11-openjdk-headless-11.0.8.10-0.el7_8.x86_64.rpm
a612490af174fb6404253014d82ac9126deab2e8cadbddf61de4b7b3cb8f7cb9  
java-11-openjdk-javadoc-11.0.8.10-0.el7_8.i686.rpm
ca4619eda8674e17681e66e31ee6c5a3c7c23a68863343ea2c07729675dd219c  
java-11-openjdk-javadoc-11.0.8.10-0.el7_8.x86_64.rpm
df07c8b3408ef966eb8912d441f8738a34f932886b59ca78f6b217f75ed20950  
java-11-openjdk-javadoc-zip-11.0.8.10-0.el7_8.i686.rpm
b255dc83851df1591ff837548b60443661f4c144c1ee08d0fb68f82fdaa0b8f2  
java-11-openjdk-javadoc-zip-11.0.8.10-0.el7_8.x86_64.rpm
5f2aee56a3aed990696e5c55ed2e32e96962b332fd99cf0b1744e731ac92a144  
java-11-openjdk-jmods-11.0.8.10-0.el7_8.i686.rpm
d0e09ef3079784e791ee53675f1e513bb98b53a8e7364089f993932eaf337663  
java-11-openjdk-jmods-11.0.8.10-0.el7_8.x86_64.rpm
8bdc41759d184666d96af0e64af8af5b7987e20b16b2ee54a797f3fe29bc73ba  
java-11-openjdk-src-11.0.8.10-0.el7_8.i686.rpm
61b97e281b86031b9203e5395b4738f04c73e4172ba7ea9ac0066a7ff6d8454d  
java-11-openjdk-src-11.0.8.10-0.el7_8.x86_64.rpm

Source:
e1c8da851ffc41a0622f258701ce0a3476dc6386660ed6e3a158b4956aa08d4b  
java-11-openjdk-11.0.8.10-0.el7_8.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-2020:3281 Important CentOS 7 libvncserver Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3281 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3281

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

x86_64:
6e3bb564a139de89aa75082746181d125ed4c599326591693741010469bbd88e  
libvncserver-0.9.9-14.el7_8.1.i686.rpm
cc9eef61c95aebbc7a432d58f5f85fbab25f19ee777834f671bc23fa94964d57  
libvncserver-0.9.9-14.el7_8.1.x86_64.rpm
27fd50136804eda5f0c7bfe32a61dcd680349725916fcebde89f0c8a2e549767  
libvncserver-devel-0.9.9-14.el7_8.1.i686.rpm
2b6dd64d39816de5f6fd5330c2e6b95ae66fa3c853d61272092b0a027fbd1da3  
libvncserver-devel-0.9.9-14.el7_8.1.x86_64.rpm

Source:
81f064d3624ca56c60a31e1328be3cc2ddf66aecceadabc2c7fa3195e20dfb40  
libvncserver-0.9.9-14.el7_8.1.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] CEBA-2020:3351 CentOS 7 nfs-utils BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3351 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3351

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

x86_64:
8094c76c7b75b5258a6632f6d5b20b2c596df2b9328f073c8424a3e11b02ce6c  
nfs-utils-1.3.0-0.66.el7_8.x86_64.rpm

Source:
1e243fc653f07565d48a007a8a2dcc8bf7537abf0f5d4dff7969ee3df4ba6096  
nfs-utils-1.3.0-0.66.el7_8.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-2020:3285 Important CentOS 7 postgresql-jdbc Security Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Security Advisory 2020:3285 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2020:3285

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

x86_64:
4085f09e7be4410758ded16aeb5fca59795cf4c2ad37a1afa78cddf45bef6806  
postgresql-jdbc-9.2.1002-8.el7_8.noarch.rpm
7ac006a9950b2c1cc710083732c5cc4a33e7c20c3699c50ad6f24318b5986edb  
postgresql-jdbc-javadoc-9.2.1002-8.el7_8.noarch.rpm

Source:
dec9a91e3d4f1c930e75b9ca02ce766fc30afc08ad522f6bb121cd0888e2e3fa  
postgresql-jdbc-9.2.1002-8.el7_8.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] CEBA-2020:3356 CentOS 7 sos BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3356 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3356

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

x86_64:
4009da92eddce4bed2fa62bb0fb255dbf2d4345f1ca2414db2c2e28b9766c14e  
sos-3.8-9.el7.centos.noarch.rpm

Source:
4f333939eb7228c4838905fe8491f0b95acb448a5e59b71863e41ef2ac8f9124  
sos-3.8-9.el7.centos.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] CEBA-2020:1212 CentOS 7 rdma-core BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:1212 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:1212

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

x86_64:
48b31125348c316305a75dfd8882d953f7108fd4a634c736fc55c3eac43a62ee  
ibacm-22.4-4.el7_8.x86_64.rpm
225973fb73009f0848d7cebd95ee7f9c1e5a859acfba4e51a3982538de576df1  
iwpmd-22.4-4.el7_8.x86_64.rpm
156b5bc36a7da8aee5f3055bf08ab9ac21ec19434b37062327863ddd9f4d56bf  
libibumad-22.4-4.el7_8.i686.rpm
404f2b30ca26abda9b338ccf044bdeca636c83c7845702d2b548b166beb4574c  
libibumad-22.4-4.el7_8.x86_64.rpm
1e070781f4f1e1b05b369d3995f059d0a06df2a0deb2d43d680a9327e087b06a  
libibverbs-22.4-4.el7_8.i686.rpm
7fd38827789deea174302f81113e9a6387dd19c3ff6cc9e97abda3e53d506ded  
libibverbs-22.4-4.el7_8.x86_64.rpm
95fece06596adfd7ad12b4fc5010a53a15cfbb8f035c8b7051797663b21e71ca  
libibverbs-utils-22.4-4.el7_8.x86_64.rpm
d406bde4cc99b6ec51e2f62a5ae891a0bb641fabeebd46fa97942b367ea69c83  
librdmacm-22.4-4.el7_8.i686.rpm
8ab3808a39cd1a3b77479a7f0ba0bcb2af4c34cf5bc50a55a14b81d29f785b2d  
librdmacm-22.4-4.el7_8.x86_64.rpm
5a169530aff0154784a5b5c6f29977d995af8bd257d8576bd550ec4b1dc25579  
librdmacm-utils-22.4-4.el7_8.x86_64.rpm
19e381909f3e9d23e2216a028d8a23f7e4067e7cbe6e07004d5170d26537bf43  
rdma-core-22.4-4.el7_8.i686.rpm
1d93bbb9fa2ae2cb4a02f22b8c0f44710cecd592f3ee85026e3b8b77257603e6  
rdma-core-22.4-4.el7_8.x86_64.rpm
26fc9f77718c9b3c14f849895ef5cd54ef24a1c13b7e23643bdf543e646b88a8  
rdma-core-devel-22.4-4.el7_8.i686.rpm
3a2811db0c5ff8c3d37365976127d0df91684438bb8e6e3a6d21ef39f34a370b  
rdma-core-devel-22.4-4.el7_8.x86_64.rpm
3109bc439b28e69faedc4218a741688aa6b42e5c22ed27c847ac18fb5e499af0  
srp_daemon-22.4-4.el7_8.x86_64.rpm

Source:
e06297368cc5dcfd52e7a5514f5d35d2d217de16ba76900610d67539a117230d  
rdma-core-22.4-4.el7_8.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] CEBA-2020:3350 CentOS 7 systemd BugFix Update

2020-08-07 Thread Johnny Hughes


CentOS Errata and Bugfix Advisory 2020:3350 

Upstream details at : https://access.redhat.com/errata/RHBA-2020:3350

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

x86_64:
c567d8148be4cbbafb0f443c59fb2faec08483cd81f6ca84f010769451162bf5  
libgudev1-219-73.el7_8.9.i686.rpm
33a6b4dedff36d3e14d23f9c5d527972b7707fe0dddad579d58663bd60d50005  
libgudev1-219-73.el7_8.9.x86_64.rpm
b0426ebf17b9b4f5889144f4d51f1a3fea6ec62d0facfb2630b6c07e1e7b8ac3  
libgudev1-devel-219-73.el7_8.9.i686.rpm
1f21f6edf5678e5cbcec7d36af46c56df5dc80378213a76f50009b6b07080936  
libgudev1-devel-219-73.el7_8.9.x86_64.rpm
e2400ded564b4fd9fba8a744b818b7a2152a78efd85aa025f543f0c5e0f03fcd  
systemd-219-73.el7_8.9.x86_64.rpm
de1dda0a139a4ae86e40604d17ecb33aef4a38156a3c3195942a8bbc13388666  
systemd-devel-219-73.el7_8.9.i686.rpm
2a1e7cd453de4133f5700b5d596fba9afce8541aa58c4734da107a1ddc6c4e5c  
systemd-devel-219-73.el7_8.9.x86_64.rpm
a42801b204c3b4178b62c54619c071aafa4532d836a93adf2c556daa932b51ae  
systemd-journal-gateway-219-73.el7_8.9.x86_64.rpm
27c0a7ced50251de61d4cbe4fb6b1942ae72e5ad332ece9a2a666c11fdc0093c  
systemd-libs-219-73.el7_8.9.i686.rpm
ede8f86313c99b59cd91ef1d7bad7890e8eeffe043f61abf47012c44dc5c99c3  
systemd-libs-219-73.el7_8.9.x86_64.rpm
07871f43c991e7eaca16f9eaf67151714434f77e0f892a1b424feee9442a94f2  
systemd-networkd-219-73.el7_8.9.x86_64.rpm
7d97385cd5463074fd2446fd28706d355c3d2e7866b33484d39c4a49ee775f4d  
systemd-python-219-73.el7_8.9.x86_64.rpm
56e2c1a59a1a0d1394c8a47fa1cc4e233c7d8317a4b397c5464a70483b58aa82  
systemd-resolved-219-73.el7_8.9.i686.rpm
9a180f5dc35c1b73775523bde31e65ba2263517d97afe6cd183f03bb96484dfe  
systemd-resolved-219-73.el7_8.9.x86_64.rpm
70bc0c186f63275107428c1b61f7d08f23d3d38c939b94c110c8186a503fd5a4  
systemd-sysv-219-73.el7_8.9.x86_64.rpm

Source:
0bb3b645abfb9222b27117583c76623f5ac783168a2b2eaf8e68b7b076ca61b5  
systemd-219-73.el7_8.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] Fixing grub/shim issue Centos 7

2020-08-07 Thread Chris Adams
Once upon a time, Alessandro Baggi  said:
> you are right but is not UEFI a standard and it shouldn't work the
> same on several vendors? I ask this because this patch broken all my
> uefi workstations.

The great thing about standards is there's so many to choose from!  Also
relevant: https://xkcd.com/927/

UEFI has gone through a number of revisions over the years, and has
optional bits like Secure Boot (which itself has gone through
revisions).  Almost any set of standards has undefined corners where
vendors interpret things differently.  Vendors also have bugs in weird
places sometimes.

The firmware and boot loaders arguably are the least "exercised" parts
of a system - both change rarely and there are few implementations.
There's not many combinations, and they don't change a lot.

I'm interested to read about the cause of this issue - something like
this can be a lesson on "hmm, hadn't thought of that before" type things
to watch for in other areas.
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Johnny Hughes
On 8/7/20 5:30 AM, Phil Perry wrote:
> On 07/08/2020 10:01, Johnny Hughes wrote:
>> On 8/7/20 3:46 AM, Nicolas Kovacs wrote:
>>> Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :
 Probably many users have not updated their machines between the bug
 release and
 the resolution (thanks to your fast apply in the weekend, thank you)
 and many
 update their centos machines on a 2 months base (if not worst). I
 think also
 that many users of CentOS user base have not proclamed their
 disappointement/the issue on this list or in other channels. For
 example I
 simply updated in the wrong time.
>>>
>>> I'm using yum-cron to keep all my server updated on a daily basis.
>>>
>>> And my question "How could this have passed Q & A" was obviously
>>> directed at
>>> Red Hat... and *not* at Johnny Hughes and the CentOS team who do
>>> their best to
>>> deliver the best possible downstream system. I raise my morning
>>> coffee mug to
>>> your health, guys.
>>>
>>> Cheers,
>>>
>>> Niki
>>>
>> I can assure you .. a BUNCH of testing was done.  Because of the scope
>> of this udpate, the CentOS team was looped in during the embargo stage
>> (we normally are not .. Red Hat Engineering got permission to make this
>> happen for this issue). Normally we see things that are open source only
>> .. not embargoed content.  Once the embargo gets lifted, the items
>> become open source.  Kudos to the RH team for making this happen.
>>
>> The CentOS team worked with the RHEL team on this update for several
>> days (more than a week, for sure, maybe 2 weeks)
>>
>> I gained MUCH respect for all those guys .. especially  Peter Jones.  He
>> is Mr.Secure Boot.
>>
>> I personally tested both the c8 and c7 solutions on several machines
>> (All i have access to actually, including several personal machines that
>> have secureboot).  I saw some of the testing that happened on the RHEL
>> side.  It was extensive.
>>
> 
> I'll just add to Johnny's already comprehensive reply. As a member of
> the CentOS QA team, I personally tested the update on 3 physical
> machines and all worked fine. Moreover, the QA team was not able to
> replicate the issue on a single physical machine available to them - the
> first indication of a problem came from public reports. We give up a
> huge amount of our personal time and resources to ensure CentOS (and
> RHEL) are the very best products they can be. I'm unsure what more could
> have been done.

Thanks Phil,

I very much appreciate all you and the rest of the QA team do.

I know it is a knee jerk reaction to say .. how did that not get caught.
 I actually said it MYSELF for this very issue.  But looking back, I am
not sure how we could have caught it.

"Stuff Happens"  :)

There are just a huge number of possible combinations.

> 
>> Microsoft, Debian, Ubuntu and others also had issues with this .. so if
>> you are losing trust, you are losing it with all OS vendors WRT this
>> issue.
>>
>> All I can say is .. this issue was the hardest thing I have been
>> involved with since starting with the CentOS Project 17 years ago.
>>
>> Obviously, everyone involved in this build would have prevented this
>> from happening if they could have.  Secureboot is complicated.




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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Phil Perry

On 07/08/2020 10:01, Johnny Hughes wrote:

On 8/7/20 3:46 AM, Nicolas Kovacs wrote:

Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :

Probably many users have not updated their machines between the bug release and
the resolution (thanks to your fast apply in the weekend, thank you) and many
update their centos machines on a 2 months base (if not worst). I think also
that many users of CentOS user base have not proclamed their
disappointement/the issue on this list or in other channels. For example I
simply updated in the wrong time.


I'm using yum-cron to keep all my server updated on a daily basis.

And my question "How could this have passed Q & A" was obviously directed at
Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to
deliver the best possible downstream system. I raise my morning coffee mug to
your health, guys.

Cheers,

Niki


I can assure you .. a BUNCH of testing was done.  Because of the scope
of this udpate, the CentOS team was looped in during the embargo stage
(we normally are not .. Red Hat Engineering got permission to make this
happen for this issue). Normally we see things that are open source only
.. not embargoed content.  Once the embargo gets lifted, the items
become open source.  Kudos to the RH team for making this happen.

The CentOS team worked with the RHEL team on this update for several
days (more than a week, for sure, maybe 2 weeks)

I gained MUCH respect for all those guys .. especially  Peter Jones.  He
is Mr.Secure Boot.

I personally tested both the c8 and c7 solutions on several machines
(All i have access to actually, including several personal machines that
have secureboot).  I saw some of the testing that happened on the RHEL
side.  It was extensive.



I'll just add to Johnny's already comprehensive reply. As a member of 
the CentOS QA team, I personally tested the update on 3 physical 
machines and all worked fine. Moreover, the QA team was not able to 
replicate the issue on a single physical machine available to them - the 
first indication of a problem came from public reports. We give up a 
huge amount of our personal time and resources to ensure CentOS (and 
RHEL) are the very best products they can be. I'm unsure what more could 
have been done.



Microsoft, Debian, Ubuntu and others also had issues with this .. so if
you are losing trust, you are losing it with all OS vendors WRT this issue.

All I can say is .. this issue was the hardest thing I have been
involved with since starting with the CentOS Project 17 years ago.

Obviously, everyone involved in this build would have prevented this
from happening if they could have.  Secureboot is complicated.



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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Alessandro Baggi


Il 07/08/20 10:47, Johnny Hughes ha scritto:

On 8/7/20 2:40 AM, Alessandro Baggi wrote:

Il 07/08/20 08:22, Johnny Hughes ha scritto:

"How on earth could this have passed Q & A ?"

Hi Johnny,
Niki's question is spread, legit, in the thoughts in many and many users
so don't see this as an attack. Many and many users,though really "if
this was tested before release" and I think that many of us are
incredulous at what happened on CentOS and in the upstream (specially in
the upstream) but as you said CentOS inherits RHEL bugs. I'm reading
about many users that lost their trust in RH with the last 2 problem
(microcode and shim). This is bad for CentOS.


Well, I mean that would be a valid point if it happened for every
install.  The issue did not happen on every install.  There is no way to
test every single hardware and firmware combination for every single
computer ever built :)

It would be great if things like this did not happen, but with the
universe of possible combinations, i am surprised it does not happen
more often.

Probably many users have not updated their machines between the bug
release and the resolution (thanks to your fast apply in the weekend,
thank you) and many update their centos machines on a 2 months base (if
not worst). I think also that many users of CentOS user base have not
proclamed their disappointement/the issue on this list or in other
channels. For example I simply updated in the wrong time.


We do run boot tests of every single kernel for CentOS.  The RHEL team
runs many more tests for RHEL.  But every possible combination from
every vendor can't possibly be tested. Right?

you are right but is not UEFI a standard and it shouldn't work the same
on several vendors? I ask this because this patch broken all my uefi
workstations.

It would be nice if it did .. however, this worked on many
UEFI/Secureboot machines.  It did not work on a small subset of machines.


While CentOS team could not have so much resources to run this type of
tests would be great to know what happened to RHEL QA (being RH giant)
for this release and given the partenership between CentOS and RH if you
know something more on this.


I have not seen the full post event account if what actually happened.
I do know that many Red Hatters worked many hours over the last weekend
to fix it.  I am sure a public post will be made (if not already there)
.. if someone knows where it is, post a link.

If I don't see it posted soon, I'll look for it and post here.

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Alessandro Baggi


Il 07/08/20 10:46, Nicolas Kovacs ha scritto:

Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :

Probably many users have not updated their machines between the bug release and
the resolution (thanks to your fast apply in the weekend, thank you) and many
update their centos machines on a 2 months base (if not worst). I think also
that many users of CentOS user base have not proclamed their
disappointement/the issue on this list or in other channels. For example I
simply updated in the wrong time.

I'm using yum-cron to keep all my server updated on a daily basis.

And my question "How could this have passed Q & A" was obviously directed at
Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to
deliver the best possible downstream system. I raise my morning coffee mug to
your health, guys.

Cheers,

Niki


Hi Niki,

I intended what you mean.

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Johnny Hughes
On 8/7/20 3:46 AM, Nicolas Kovacs wrote:
> Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :
>> Probably many users have not updated their machines between the bug release 
>> and
>> the resolution (thanks to your fast apply in the weekend, thank you) and many
>> update their centos machines on a 2 months base (if not worst). I think also
>> that many users of CentOS user base have not proclamed their
>> disappointement/the issue on this list or in other channels. For example I
>> simply updated in the wrong time.
> 
> I'm using yum-cron to keep all my server updated on a daily basis.
> 
> And my question "How could this have passed Q & A" was obviously directed at
> Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to
> deliver the best possible downstream system. I raise my morning coffee mug to
> your health, guys.
> 
> Cheers,
> 
> Niki
> 
I can assure you .. a BUNCH of testing was done.  Because of the scope
of this udpate, the CentOS team was looped in during the embargo stage
(we normally are not .. Red Hat Engineering got permission to make this
happen for this issue). Normally we see things that are open source only
.. not embargoed content.  Once the embargo gets lifted, the items
become open source.  Kudos to the RH team for making this happen.

The CentOS team worked with the RHEL team on this update for several
days (more than a week, for sure, maybe 2 weeks)

I gained MUCH respect for all those guys .. especially  Peter Jones.  He
is Mr.Secure Boot.

I personally tested both the c8 and c7 solutions on several machines
(All i have access to actually, including several personal machines that
have secureboot).  I saw some of the testing that happened on the RHEL
side.  It was extensive.

Microsoft, Debian, Ubuntu and others also had issues with this .. so if
you are losing trust, you are losing it with all OS vendors WRT this issue.

All I can say is .. this issue was the hardest thing I have been
involved with since starting with the CentOS Project 17 years ago.

Obviously, everyone involved in this build would have prevented this
from happening if they could have.  Secureboot is complicated.



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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Johnny Hughes
On 8/7/20 2:40 AM, Alessandro Baggi wrote:
> 
> Il 07/08/20 08:22, Johnny Hughes ha scritto:
>>> "How on earth could this have passed Q & A ?"
> 
> Hi Johnny,
> Niki's question is spread, legit, in the thoughts in many and many users
> so don't see this as an attack. Many and many users,though really "if
> this was tested before release" and I think that many of us are
> incredulous at what happened on CentOS and in the upstream (specially in
> the upstream) but as you said CentOS inherits RHEL bugs. I'm reading
> about many users that lost their trust in RH with the last 2 problem
> (microcode and shim). This is bad for CentOS.
> 
>> Well, I mean that would be a valid point if it happened for every
>> install.  The issue did not happen on every install.  There is no way to
>> test every single hardware and firmware combination for every single
>> computer ever built :)
>>
>> It would be great if things like this did not happen, but with the
>> universe of possible combinations, i am surprised it does not happen
>> more often.
> 
> Probably many users have not updated their machines between the bug
> release and the resolution (thanks to your fast apply in the weekend,
> thank you) and many update their centos machines on a 2 months base (if
> not worst). I think also that many users of CentOS user base have not
> proclamed their disappointement/the issue on this list or in other
> channels. For example I simply updated in the wrong time.
> 
>> We do run boot tests of every single kernel for CentOS.  The RHEL team
>> runs many more tests for RHEL.  But every possible combination from
>> every vendor can't possibly be tested. Right?
> 
> you are right but is not UEFI a standard and it shouldn't work the same
> on several vendors? I ask this because this patch broken all my uefi
> workstations.

It would be nice if it did .. however, this worked on many
UEFI/Secureboot machines.  It did not work on a small subset of machines.

> 
> While CentOS team could not have so much resources to run this type of
> tests would be great to know what happened to RHEL QA (being RH giant)
> for this release and given the partenership between CentOS and RH if you
> know something more on this.
> 

I have not seen the full post event account if what actually happened.
I do know that many Red Hatters worked many hours over the last weekend
to fix it.  I am sure a public post will be made (if not already there)
.. if someone knows where it is, post a link.

If I don't see it posted soon, I'll look for it and post here.




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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Nicolas Kovacs
Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :
> Probably many users have not updated their machines between the bug release 
> and
> the resolution (thanks to your fast apply in the weekend, thank you) and many
> update their centos machines on a 2 months base (if not worst). I think also
> that many users of CentOS user base have not proclamed their
> disappointement/the issue on this list or in other channels. For example I
> simply updated in the wrong time.

I'm using yum-cron to keep all my server updated on a daily basis.

And my question "How could this have passed Q & A" was obviously directed at
Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to
deliver the best possible downstream system. I raise my morning coffee mug to
your health, guys.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Alessandro Baggi



Il 07/08/20 08:22, Johnny Hughes ha scritto:

"How on earth could this have passed Q & A ?"


Hi Johnny,
Niki's question is spread, legit, in the thoughts in many and many users 
so don't see this as an attack. Many and many users,though really "if 
this was tested before release" and I think that many of us are 
incredulous at what happened on CentOS and in the upstream (specially in 
the upstream) but as you said CentOS inherits RHEL bugs. I'm reading 
about many users that lost their trust in RH with the last 2 problem 
(microcode and shim). This is bad for CentOS.



Well, I mean that would be a valid point if it happened for every
install.  The issue did not happen on every install.  There is no way to
test every single hardware and firmware combination for every single
computer ever built :)

It would be great if things like this did not happen, but with the
universe of possible combinations, i am surprised it does not happen
more often.


Probably many users have not updated their machines between the bug 
release and the resolution (thanks to your fast apply in the weekend, 
thank you) and many update their centos machines on a 2 months base (if 
not worst). I think also that many users of CentOS user base have not 
proclamed their disappointement/the issue on this list or in other 
channels. For example I simply updated in the wrong time.



We do run boot tests of every single kernel for CentOS.  The RHEL team
runs many more tests for RHEL.  But every possible combination from
every vendor can't possibly be tested. Right?


you are right but is not UEFI a standard and it shouldn't work the same 
on several vendors? I ask this because this patch broken all my uefi 
workstations.


While CentOS team could not have so much resources to run this type of 
tests would be great to know what happened to RHEL QA (being RH giant) 
for this release and given the partenership between CentOS and RH if you 
know something more on this.


Thank you.

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


Re: [CentOS] Fixing grub/shim issue Centos 7

2020-08-07 Thread Johnny Hughes
On 8/6/20 8:57 AM, Nicolas Kovacs wrote:
> Le 04/08/2020 à 08:31, lpeci a écrit :
>> I had the same problem with my UEFI bios machine and I fixed it so for 
>> Centos 7:
>>
>> 1) Boot from an rescue linux usb
>>
>> 2) When the rescue system is running:
>>
>>     2.1) #chroot /mnt/sysimage
>>
>> 3) Config network:
>>
>>     3.1) # ip addr add X.X.X.X/X dev X
>>
>>     3.2) # ip route add default via X.X.X.X    <--- default router
>>
>> 4) And finally:
>>
>>     #yum downgrade shim\* grub2\* mokutil
>>
>>     #exit
>>
>>     #reboot
>>
>> I hope you can fix it with these steps.
> 
> Thanks for the detailed suggestion.
> 
> Unfortunately I couldn't recover the installation, and I had to redo 
> everything
> from scratch, which cost me the first two days of my holidays.
> 
> One thought regularly kept crossing my mind:
> 
> "How on earth could this have passed Q & A ?"

Well, I mean that would be a valid point if it happened for every
install.  The issue did not happen on every install.  There is no way to
test every single hardware and firmware combination for every single
computer ever built :)

It would be great if things like this did not happen, but with the
universe of possible combinations, i am surprised it does not happen
more often.

We do run boot tests of every single kernel for CentOS.  The RHEL team
runs many more tests for RHEL.  But every possible combination from
every vendor can't possibly be tested. Right?



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


Re: [CentOS] rsync upgrade

2020-08-07 Thread Simon Matter via CentOS
> On 8/6/20 12:30 PM, Jack Bailey via CentOS wrote:
>> On 2020-08-06 08:45, J Martin Rushton via CentOS wrote:
>>> You'll need to upgrade to CentOS8.
>>>
>>> C7 is at rsync 3.1.2-10, and will not go above 3.1.2 ever.
>>>
>>> C8.2 is at 3.1.3-7, C8 will always be on 3.1.3
>>>
>>> Martin
>>
>> Another option is to build rsync from source, which is what I did to try
>> out the zstd compression.
>
>
> Just wanted to share Fedora 32's rsync-3.2.2-1.fc32.src.rpm rebuilds
> cleanly without any necessary tweaks on CentOS 7.  I used mock for a clean
> build environment.
>
> It is very empowering to learn how to build your own packages and not very
> hard to get started.  I encourage you to do the same!
>

If you're using 3.2.2, be sure to add this fix to make rsync behave as
expected:

https://github.com/WayneD/rsync/issues/81

Regards,
Simon

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