Re: [CentOS] CentOS Security Advisories OVAL feed??
> Q3) Does this indicate that only the latest CentOS (minor) release can > be considered "secure" or "patched"? Yes. Security errata for previous Enterprise Linux minor releases are a Red Hat product called Extended Update Support (EUS) [0]. CentOS doesn't build EUS updates. CentOS point releases are a point in time reference and an implementation detail, not something you should try to lock your system to. When someone says they are using CentOS X.Y, that just means that they haven't updated their system since X.Y+1 was released. Effectively, you don't have CentOS 8.1, you have outdated CentOS 8. [0] https://access.redhat.com/articles/rhel-eus On Tue, Aug 4, 2020 at 11:34 AM wrote: > > Dear List, > > I have spent some time playing around with oscap and the RHEL OVAL feed > (https://www.redhat.com/security/data/oval/v2/RHEL8/, also check Chapter > 16 of the RHEL 8 Design Guide). Because I could not find an existing > OVAL file for CentOS, I downloaded one of the RHEL8 files and managed to > modify (eg. the rhel-8.1-e4s.oval.xml) it to make it work on a CentOS > machine. Basically I just had to change the package signing key check to > use the CentOS key and I had to replace the redhat-release RPM package > name with "centos-release". Obviously, this would violate all kinds of > rights if redistributed, due to the fact that the upstream vendor is > named all over the place, but technically it "worked". > > On an internal system running a freshly updated CentOS 8.1 system I > ended up with three errors, titled: > > * RHSA-2019:4269: container-tools:rhel8 security and bug fix update > (Important) > > * RHSA-2019:3403: container-tools:rhel8 security, bug fix, and > enhancement update (Important) > > * RHSA-2019:2799: nginx:1.14 security update (Important) > > This raises some questions (some of them connected), namely: > > Q1) There are no equivalent CESA advisories for those RHSA advisories: > why is that? Note that there are also no equivalent CentOS packages to > those mentioned in the RHSA advisories. (My guess: because, when the > advisories where issued, Centos already had moved on to 8.2) > > Q2) Does this indicate a problem in the release process / handling of > upstream updates on the side of the CentOS project? Were the advisories > missed at the time of issuance? > > Q3) Does this indicate that only the latest CentOS (minor) release can > be considered "secure" or "patched"? > > Q4) Is there a native OVAL file released from the CentOS project > covering these issues? It could be extremely similar to the RHEL one, > but it should take the answers to the above questions into account (eg. > it could require the latests minor-release and there would only be one > file for CentOS 8 if the answer to Q3 is "yes"). > > Q5) If the answer to the last question is "no": shouldn't there be such > a resource? > > Thanks for any answers. > > peter > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Carl George ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Security Advisories OVAL feed??
Am 05.08.20 um 17:55 schrieb Johnny Hughes: On 8/5/20 10:45 AM, cen...@niob.at wrote: On 05/08/2020 16:49, Johnny Hughes wrote: On 8/5/20 1:05 AM, cen...@niob.at wrote: On 04/08/2020 23:50, Jon Pruente wrote: On Tue, Aug 4, 2020 at 11:34 AM wrote: Q5) If the answer to the last question is "no": shouldn't there be such a resource? CentOS doesn't publish security errata. If you need it then you should either buy RHEL, or deal with putting together your own set up with something like http://cefs.steve-meier.de/ I expected just this answer, and we do have a RHEL subscription (and BTW: thanks for the link). But you missed the main point by omitting the other questions (especially Q1, Q2 and Q3): There are upstream package versions that were never rebuilt for CentOS. For instance: If, for whatever reason, I am required to stay with nginx 1.14.1 then the missing rebuild of the packages mentioned in RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would leave me with a vulnerable system. The question for an OVAL feed is actually an add-on question: In the same spirit that is the base for the CentOS project itself: wouldn't such a feed be a good thing to have? Otherwise your answer could be the catch-all answer to all questions CentOS: Go get a commercial subscription. Personally, I think such an answer is not very helpful. So what do you think about the underlying issue? Under what argumentation does it NOT constitute to be an issue? Modules suck .. :) But that is built and in the repo .. dnf list 'nginx*' nginx.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-all-modules.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-filesystem.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-image-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-perl.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-xslt-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-mail.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-stream.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream As I have said before .. mbbox (the item used to build modules) adds an index code (the 184) and a part of the git commit (e34fea82) .. so this will always be different between RHEL and CentOS .. because we use different builders and a different git repo. Red Hat's RHEL index code is 4108 and the git commit is af250afe Thanks a lot for pointing that out! That explains part of the problem. The corresponding source RPMs are indeed identical (I checked :-) ), so the packages were (indeed) rebuilt. That was not at all obvious to me. OTOH: I probably would have guessed if there had been a corresponding e-mail to Centos-Announce. At this point, I would like to add that I am extremely impressed by the CentOS project and that I do not want to blame anybody for forgetting such an e-mail (or maybe it was just lost somewhere in SMTP-land) - I just want to state that fact. Thanks for putting in all that hard work! With that new knowledge, I also checked my other issues wrt to the container-tools package: Same module issue. So there is a pattern. But there is also the pattern that I cannot find the corresponding CentOS-Announce e-mail. Strange, isn't it? This still leaves me wondering if there should be an attempt at providing a CentOS OVAL file similar to the one by RH that is not generated by taking the upstream file and running some uninspired sed-script on it, like (for reference): sed -e 's,/etc/redhat-release,/etc/centos-release,g' -e 's/199e2f91fd431d51/05b555b38483c65d/g' However, the question could be asked if such an OVAL file would be of any use, in the light of possibly missing CESA announce e-Mails, because that advisory information must some be translated into the OCAL XML. Having said all this: maybe there is some deeper problem here, because of that pattern of missing announce e-mails that correspond with packages that differ in the final version number with respect to the upstream package. Or is this just a coincidence? We understand that there are no announcements for CentOS 8 .. this (the modules differences) is precisely the reason why (the names do not match up and our scripts require that). We do not have the capability to announce these at the present time. This is something that needs an engineering solution. Submissions welcome. I the mean time : https://feeds.centos.org/ -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Security Advisories OVAL feed??
On 05/08/2020 17:55, Johnny Hughes wrote: Having said all this: maybe there is some deeper problem here, because of that pattern of missing announce e-mails that correspond with packages that differ in the final version number with respect to the upstream package. Or is this just a coincidence? We understand that there are no announcements for CentOS 8 .. this (the modules differences) is precisely the reason why (the names do not match up and our scripts require that). We do not have the capability to announce these at the present time. This is something that needs an engineering solution. Submissions welcome. Thanks for the clarification. This explains exactly what I have seen. Are those scripts available somewhere? A quick search didn't turn up anything obvious... peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Security Advisories OVAL feed??
On 8/5/20 10:45 AM, cen...@niob.at wrote: > On 05/08/2020 16:49, Johnny Hughes wrote: >> On 8/5/20 1:05 AM, cen...@niob.at wrote: >>> On 04/08/2020 23:50, Jon Pruente wrote: On Tue, Aug 4, 2020 at 11:34 AM wrote: > Q5) If the answer to the last question is "no": shouldn't there be > such > a resource? > CentOS doesn't publish security errata. If you need it then you should either buy RHEL, or deal with putting together your own set up with something like http://cefs.steve-meier.de/ >>> I expected just this answer, and we do have a RHEL subscription (and >>> BTW: thanks for the link). But you missed the main point by omitting the >>> other questions (especially Q1, Q2 and Q3): There are upstream package >>> versions that were never rebuilt for CentOS. >>> >>> For instance: If, for whatever reason, I am required to stay with nginx >>> 1.14.1 then the missing rebuild of the packages mentioned in >>> RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would >>> leave me with a vulnerable system. >>> >>> The question for an OVAL feed is actually an add-on question: In the >>> same spirit that is the base for the CentOS project itself: wouldn't >>> such a feed be a good thing to have? Otherwise your answer could be the >>> catch-all answer to all questions CentOS: Go get a commercial >>> subscription. Personally, I think such an answer is not very helpful. >>> >>> So what do you think about the underlying issue? Under what >>> argumentation does it NOT constitute to be an issue? >>> >> Modules suck .. :) >> >> But that is built and in the repo .. >> >> dnf list 'nginx*' >> >> nginx.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-all-modules.noarch >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-filesystem.noarch >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-mod-http-image-filter.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-mod-http-perl.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-mod-http-xslt-filter.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-mod-mail.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> nginx-mod-stream.x86_64 >> 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream >> >> As I have said before .. mbbox (the item used to build modules) adds an >> index code (the 184) and a part of the git commit (e34fea82) .. so this >> will always be different between RHEL and CentOS .. because we use >> different builders and a different git repo. Red Hat's RHEL index code >> is 4108 and the git commit is af250afe >> > Thanks a lot for pointing that out! That explains part of the problem. > The corresponding source RPMs are indeed identical (I checked :-) ), so > the packages were (indeed) rebuilt. That was not at all obvious to me. > > OTOH: I probably would have guessed if there had been a corresponding > e-mail to Centos-Announce. At this point, I would like to add that I am > extremely impressed by the CentOS project and that I do not want to > blame anybody for forgetting such an e-mail (or maybe it was just lost > somewhere in SMTP-land) - I just want to state that fact. Thanks for > putting in all that hard work! > > With that new knowledge, I also checked my other issues wrt to the > container-tools package: Same module issue. So there is a pattern. But > there is also the pattern that I cannot find the corresponding > CentOS-Announce e-mail. Strange, isn't it? > > This still leaves me wondering if there should be an attempt at > providing a CentOS OVAL file similar to the one by RH that is not > generated by taking the upstream file and running some uninspired > sed-script on it, like (for reference): > > sed -e 's,/etc/redhat-release,/etc/centos-release,g' -e > 's/199e2f91fd431d51/05b555b38483c65d/g' > > However, the question could be asked if such an OVAL file would be of > any use, in the light of possibly missing CESA announce e-Mails, because > that advisory information must some be translated into the OCAL XML. > > Having said all this: maybe there is some deeper problem here, because > of that pattern of missing announce e-mails that correspond with > packages that differ in the final version number with respect to the > upstream package. Or is this just a coincidence? > We understand that there are no announcements for CentOS 8 .. this (the modules differences) is precisely the reason why (the names do not match up and our scripts require that). We do not have the capability to announce these at the present time. This is something that needs an engineering solution. Submissions welcome. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org
Re: [CentOS] CentOS Security Advisories OVAL feed??
On 05/08/2020 16:49, Johnny Hughes wrote: On 8/5/20 1:05 AM, cen...@niob.at wrote: On 04/08/2020 23:50, Jon Pruente wrote: On Tue, Aug 4, 2020 at 11:34 AM wrote: Q5) If the answer to the last question is "no": shouldn't there be such a resource? CentOS doesn't publish security errata. If you need it then you should either buy RHEL, or deal with putting together your own set up with something like http://cefs.steve-meier.de/ I expected just this answer, and we do have a RHEL subscription (and BTW: thanks for the link). But you missed the main point by omitting the other questions (especially Q1, Q2 and Q3): There are upstream package versions that were never rebuilt for CentOS. For instance: If, for whatever reason, I am required to stay with nginx 1.14.1 then the missing rebuild of the packages mentioned in RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would leave me with a vulnerable system. The question for an OVAL feed is actually an add-on question: In the same spirit that is the base for the CentOS project itself: wouldn't such a feed be a good thing to have? Otherwise your answer could be the catch-all answer to all questions CentOS: Go get a commercial subscription. Personally, I think such an answer is not very helpful. So what do you think about the underlying issue? Under what argumentation does it NOT constitute to be an issue? Modules suck .. :) But that is built and in the repo .. dnf list 'nginx*' nginx.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-all-modules.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-filesystem.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-image-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-perl.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-xslt-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-mail.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-stream.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream As I have said before .. mbbox (the item used to build modules) adds an index code (the 184) and a part of the git commit (e34fea82) .. so this will always be different between RHEL and CentOS .. because we use different builders and a different git repo. Red Hat's RHEL index code is 4108 and the git commit is af250afe Thanks a lot for pointing that out! That explains part of the problem. The corresponding source RPMs are indeed identical (I checked :-) ), so the packages were (indeed) rebuilt. That was not at all obvious to me. OTOH: I probably would have guessed if there had been a corresponding e-mail to Centos-Announce. At this point, I would like to add that I am extremely impressed by the CentOS project and that I do not want to blame anybody for forgetting such an e-mail (or maybe it was just lost somewhere in SMTP-land) - I just want to state that fact. Thanks for putting in all that hard work! With that new knowledge, I also checked my other issues wrt to the container-tools package: Same module issue. So there is a pattern. But there is also the pattern that I cannot find the corresponding CentOS-Announce e-mail. Strange, isn't it? This still leaves me wondering if there should be an attempt at providing a CentOS OVAL file similar to the one by RH that is not generated by taking the upstream file and running some uninspired sed-script on it, like (for reference): sed -e 's,/etc/redhat-release,/etc/centos-release,g' -e 's/199e2f91fd431d51/05b555b38483c65d/g' However, the question could be asked if such an OVAL file would be of any use, in the light of possibly missing CESA announce e-Mails, because that advisory information must some be translated into the OCAL XML. Having said all this: maybe there is some deeper problem here, because of that pattern of missing announce e-mails that correspond with packages that differ in the final version number with respect to the upstream package. Or is this just a coincidence? peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Security Advisories OVAL feed??
On 8/5/20 1:05 AM, cen...@niob.at wrote: > On 04/08/2020 23:50, Jon Pruente wrote: >> On Tue, Aug 4, 2020 at 11:34 AM wrote: >> >>> Q5) If the answer to the last question is "no": shouldn't there be such >>> a resource? >>> >> CentOS doesn't publish security errata. If you need it then you should >> either buy RHEL, or deal with putting together your own set up with >> something like http://cefs.steve-meier.de/ > > I expected just this answer, and we do have a RHEL subscription (and > BTW: thanks for the link). But you missed the main point by omitting the > other questions (especially Q1, Q2 and Q3): There are upstream package > versions that were never rebuilt for CentOS. > > For instance: If, for whatever reason, I am required to stay with nginx > 1.14.1 then the missing rebuild of the packages mentioned in > RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would > leave me with a vulnerable system. > > The question for an OVAL feed is actually an add-on question: In the > same spirit that is the base for the CentOS project itself: wouldn't > such a feed be a good thing to have? Otherwise your answer could be the > catch-all answer to all questions CentOS: Go get a commercial > subscription. Personally, I think such an answer is not very helpful. > > So what do you think about the underlying issue? Under what > argumentation does it NOT constitute to be an issue? > Modules suck .. :) But that is built and in the repo .. dnf list 'nginx*' nginx.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-all-modules.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-filesystem.noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-image-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-perl.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-http-xslt-filter.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-mail.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream nginx-mod-stream.x86_64 1:1.14.1-9.module_el8.0.0+184+e34fea82 AppStream As I have said before .. mbbox (the item used to build modules) adds an index code (the 184) and a part of the git commit (e34fea82) .. so this will always be different between RHEL and CentOS .. because we use different builders and a different git repo. Red Hat's RHEL index code is 4108 and the git commit is af250afe 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
On 8/4/20 10:45 AM, ja wrote: > On Tue, 2020-08-04 at 10:36 -0500, Chris Adams wrote: >> Once upon a time, Johnny Hughes said: >>> The issues should now be resolved. >>> >>> If you just mount /mnt/sysimage, set an ip address and upgrade (to get >>> th new shim) .. then: >>> >>> yum reinstall >> >> I'm curious - why does the kernel need to be reinstalled? The shim-x64 >> package installs its files directly to the EFI partition where they are >> needed. >> > > +1 > That is the easiest way for the initrd to be rebuilt .. which is what created the unbootable issue in the first place. At least is some circumstances. You can also regenerate your initrd manually after installing the shim. This is IF you are already in a failed boot condition from the bad install on Friday. If you are doing the upgrade/install now from a bootable system, all you need to do is a normal update. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
Am 05.08.20 um 13:44 schrieb Leon Fauster via CentOS: > Take a look into "top", > if something like gz or xz is in place occupying your CPU then the > initrd gets build ... just wait :-) 'journalctl -f' shows the state of the build process. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
Am 05.08.20 um 02:13 schrieb david: At 05:01 PM 8/4/2020, you wrote: Am 05.08.20 um 01:27 schrieb david: At 04:18 PM 8/4/2020, you wrote: Am 05.08.20 um 01:09 schrieb david: At 01:54 PM 8/4/2020, you wrote: On Tue, 04 Aug 2020 13:44:05 -0700 david wrote: > After all the updates, the system was NOT bootable. How long did you wait for it to boot, and what did it do when it failed to boot? What text messages showed up on the console? Any reported errors when you ran the update or when you rebooted the computer? If so, what did the say? I personally haven't had any issues updating any of my computers (using a mix of Centos 6, 7 and 8) but maybe they're all too old to for the issue to show up. -- How long did I wait: 5 minutes What on the console: nothing, just a dull gray color Errors on update: none - But when I blocked the update, it booted within a minute, and ran. Can you boot the system with all updates and secureboot=off? (Just to be sure; I imply that you use UEFI, right?) -- Leon I'm not sure how to turn 'secure boot' off or if it exists. (MacMini5.2). I presume it uses UEFI, but not sure how to answer that. Oh, an apple device. AFAIK the openfirmware of such hardware have also a legacy mode. So first check if it uses the UEFI mode at all by checking if this directory exists (in the working/bootable system): # ls -la /sys/firmware/efi if so test the secure boot state with # mokutil --sb-state Boot failure only occurs when the grub2/shim/mokutil updates are applied. [root@xxx -]ls -la /sys/firmware/efi total 0 drwxr-xr-x 5 root root 0 Aug 4 17:12 . drwxr-xr-x 7 root root 0 Aug 4 14:30 .. -r--r--r-- 1 root root 4096 Aug 4 17:12 config_table drwxr-xr-x 2 root root 0 Aug 4 14:30 efivars -r--r--r-- 1 root root 4096 Aug 4 17:12 fw_platform_size -r--r--r-- 1 root root 4096 Aug 4 17:12 fw_vendor -r--r--r-- 1 root root 4096 Aug 4 17:12 runtime drwxr-xr-x 10 root root 0 Aug 4 17:12 runtime-map -r 1 root root 4096 Aug 4 14:31 systab drwxr-xr-x 23 root root 0 Aug 4 17:12 vars [root@xxx ~]# mokutil --sb-state This system doesn't support Secure Boot [root@xxx ~]# The boot hole security issue is related to secure boot. In your case I would assume a different problem (after seeing the above information). As others mentioned already apply some patience while updating. You said that you could change to a different terminal. Take a look into "top", if something like gz or xz is in place occupying your CPU then the initrd gets build ... just wait :-) -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Announcing the version 1.0 hexpeek release!
Am 05.08.20 um 06:22 schrieb hexp...@hexpeek.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Announcing the version 1.0 hexpeek release! I am pleased to announce the first stable release of hexpeek, which seeks to be an efficient, powerful, and portable hex editor for files of all kinds and sizes. This release improves on the beta release with a live undo, a greatly increased backup depth, better support for writing to non-seekable files, and some miscellaneous cleanup. Visit https://www.hexpeek.com for more information. Out of respect for the bandwidth on this mailing list, I do not plan to announce future hexpeek releases here. There is a mailing list on https://www.hexpeek.com where future announcements will be posted. If you are interested in hexpeek becoming a package/port for your distro, please let me know. Its for sure a great tool but is this the right list for such announcements [*]? [*] "This is a General discussion list for all CentOS issues." https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
On 05/08/2020 10:40, Kenneth Porter wrote: Is there some way we could get the initrd rebuild to be more verbose, so that it doesn't appear to hang? It would be nice to get feedback that something is happening, especially on an older, slower system that takes a long time for this step. Not without hacking the underlying scripts that call dracut to increase the verbosity. You can run yum at a more verbose debug level, but it's not going to give you information on the state of individual rpm scriptlets. You could monitor the process in top where you should be able to see that it's still working. You can also monitor /var/log/messages where dracut activity is logged. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
On 8/4/2020 11:20 AM, Jonathan Billings wrote: Running transaction Installing : kernel-3.10.0-1127.el7.x86_64 1/1 at which point the process appeared to hang. No further output happened for five minutes. I opened a different terminal and entered "shutdown -r now". The result is an unbootable system. What did I do wrong? I must admit that there are multiple copies of advice on the mailing list, so perhaps I followed the wrong one? Your system was most likely rebuilding the initrd, and you interrupted it leaving you with a broken initrd. Is there some way we could get the initrd rebuild to be more verbose, so that it doesn't appear to hang? It would be nice to get feedback that something is happening, especially on an older, slower system that takes a long time for this step. I run into the same problem with the kernel-devel package, just because of the sheer number of files involved. I've learned to be patient and expect a kernel upgrade on my oldest system to take a very long time. (I need the -devel package to rebuild an ancient 3rd party driver no longer provided by RHEL.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Security Advisories OVAL feed??
On 04/08/2020 23:50, Jon Pruente wrote: On Tue, Aug 4, 2020 at 11:34 AM wrote: Q5) If the answer to the last question is "no": shouldn't there be such a resource? CentOS doesn't publish security errata. If you need it then you should either buy RHEL, or deal with putting together your own set up with something like http://cefs.steve-meier.de/ I expected just this answer, and we do have a RHEL subscription (and BTW: thanks for the link). But you missed the main point by omitting the other questions (especially Q1, Q2 and Q3): There are upstream package versions that were never rebuilt for CentOS. For instance: If, for whatever reason, I am required to stay with nginx 1.14.1 then the missing rebuild of the packages mentioned in RHSA-2019:2799 (https://access.redhat.com/errata/RHSA-2019:2799) would leave me with a vulnerable system. The question for an OVAL feed is actually an add-on question: In the same spirit that is the base for the CentOS project itself: wouldn't such a feed be a good thing to have? Otherwise your answer could be the catch-all answer to all questions CentOS: Go get a commercial subscription. Personally, I think such an answer is not very helpful. So what do you think about the underlying issue? Under what argumentation does it NOT constitute to be an issue? peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
