January 2021 - devel - lists.centos.org

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

RFC: Stream Kernel SIG Proposal
by redbaronbrowser 19 May '21

19 May '21

There are four main goals of this SIG: First, break down changes in the Stream version 4.18.0 kernel into individual patches. When possible, document the source the patch is from and the purpose of the patch. Moving forward also document which Stream kernel package revision introduced the patch. Second, build CentOS Plus kernel for Stream. Third, package newer LTS kernels during the LTS lifespan. These would be available as alternative kernels for Stream similar to the CentOS Plus kernel. Fourth, work on tools for better delivery of live security patches to be applied via kpatch. The reasoning for this SIG is to improve the openness of kernels available through Stream. Normally a distribution upstream would have access to which patch or commit each addition to the kernel belongs to. The patch name or commit comment would also give information as to the purpose of the patch. Stream's kernel reports to be 4.18.0 but uses a tar that is 110% the size of a true 4.18.0 tar. A breakdown of the additional 10% is not provided. Hence Stream's kernel still functions similar to a downstream rather than providing what is expected for a successful upstream project. This SIG would help close the kernel openness gap by documenting the changes. Stream users would then be in a better position to track down individual patches that cause regressions or bugs. This SIG would also help smooth the adoption of Stream for users that depend on CentOS Plus kernel features. Next, this SIG should help improve feedback to the LTS kernel developers. Tracking LTS kernel changes may also help with documenting some changes in the primary Stream kernel. Lastly, this SIG should help improve kernel security by promoting methods to enable kernel security updates even when a reboot of the system is not possible.

12 42

centos-release-stream.x86_64 VS centos-stream-release.noarch
by lejeczek 13 Feb '21

13 Feb '21

Hi devel Is that not something that needs looking into? -> $ dnf search release | grep -i strea Last metadata expiration check: 0:07:24 ago on Thu 28 Jan 2021 09:46:52 GMT. centos-release-stream.x86_64 : CentOS-Stream release file centos-stream-release.noarch : CentOS Stream release files Installing one package and not the other messes things a bit. regards, L.

4 5

CBS default maven module for virt8-ovirt-44-el8
by Sandro Bonazzola 05 Feb '21

05 Feb '21

Hi, I'm seeing the following error: Executing: xmvn --batch-mode --offline -Dmaven.test.skip=true -Dworkspace.root.dir=/builddir/build/BUILD/apache-sshd-2.6.0 package org.fedoraproject.xmvn:xmvn-mojo:install org.fedoraproject.xmvn:xmvn-mojo:javadoc org.fedoraproject.xmvn:xmvn-mojo:builddep ['xmvn', '--batch-mode', '--offline', '-Dmaven.test.skip=true', '-Dworkspace.root.dir=/builddir/build/BUILD/apache-sshd-2.6.0', 'package', 'org.fedoraproject.xmvn:xmvn-mojo:install', 'org.fedoraproject.xmvn:xmvn-mojo:javadoc', 'org.fedoraproject.xmvn:xmvn-mojo:builddep'] /usr/share/maven/bin/mvn: line 36: /etc/java/maven.conf: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.QeIPBF (%build) Bad exit status from /var/tmp/rpm-tmp.QeIPBF (%build) RPM build errors: which is a known bug of maven 3.6 shipped in RHEL 8.3 ( https://bugzilla.redhat.com/show_bug.cgi?id=1897375) There's a build in koji ( https://koji.mbox.centos.org/koji/taskinfo?taskID=207396) which should have the fix for this issue. Can we get that build in CBS build root? If not, can we get maven:3.5 module enabled instead of maven:3.6? thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 3

First round of RHEL programs announced
by Mike McGrath 04 Feb '21

04 Feb '21

Hi all, I know this was a hot topic on the list so I thought I'd share today's blog post which covers no-cost RHEL for small production workloads and no-cost RHEL for customer development teams. Keep in mind there are other programs coming, these just got done first. https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-progra… Bullet Points: - Self-Support RHEL for no-cost in production use cases of up to 16 systems. - No-cost RHEL for customer development teams (larger number of systems for non-production cases). - Available no later than February 1 - Single Sign-on via a Red Hat account, or Github, Twitter, Facebook or other accounts (You'll soon not need to provide all kinds of personal information like you used to). -- Mike McGrath Linux Engineering - Chicago Red Hat mmcgrath(a)redhat.com T: (312)-660-3547

36 141

CentOS/Fedora authentication system merge (Please Read)
by Fabian Arrotin 03 Feb '21

03 Feb '21

# Introduction and background As it was preannounced some time ago , the CentOS Board agreed to merge the CentOS accounts (https://accounts.centos.org) with the Fedora FAS (https://admin.fedoraproject.org/accounts/) As both projects were running their own instance of FAS (running on el6/CentOS 6, so coming to EOL, so that needed to be migrated to new solution/platform), but that there are a lot of contributors common to both projects, it made sense to "migrate and merge" both into one, and so having only one account that can be used for both. The AAA/Noggin team worked in the last months on the new authentication system that will be used as foundation. The core block will be (Free)IPA (https://www.freeipa.org , already available in the distribution) and the community portal feature will be provided by noggin (https://github.com/fedora-infra/noggin) If you want to know more about noggin, consider watching the presentation given at last Fedora Nest event (https://www.youtube.com/watch?v=x1SevUmkE60) # What does it mean for you, contributors and SIG members ? Fedora already had an IPA infra, but "hidden" behind FAS, so accounts were already created in IPA backend. For CentOS, we were just using plain FAS, so users in our own backend (fas db). The "Merge" operation will go like this : - Fedora will kick fas2ipa script (https://github.com/fedora-infra/fas2ipa) synchronizing FAS attributes back into IPA, including group memberships coming from FAS/Fedora - Then the same process will be ran but importing from ACO (https://accounts.centos.org) into the same IPA backend. That's where the "fun" begins: * If the same nick/account exists at both side, the script is considering FAS as authoritative (remember, the FAS user *already* exists there, and is only modified for group[s] membership and attributes) * What is used to consider same nick/account being the same person ? the email (validated when registering account) will be used as primary key. So that means that you should *now* verify/update your email address in FAS and ACO so that they match * in case of a email address mismatch, the ACO account isn't migrated (group membership) but put in a queue to be verified * in case of matching email address, existing account is added to imported ACO groups The "open" question is about what to do for same account but in fact being different people (question is debated between Fedora and CentOS through the AAA initiative) # What has been already done ? You can follow publicly the status through dedicated tracker ( https://github.com/orgs/fedora-infra/projects/6 ), but let me focus on the CentOS Side (sending this to centos-devel so centos contributors) In the last months, Fedora already deployed a staging (.stg.) IPA instance, as well as a noggin community portal. For CentOS, we deployed (to be able to test integration) the following components in front of the Fedora IPA: * https://accounts.stg.centos.org (using noggin, with a centos visual theme applied) * https://id.stg.centos.org (ipsilon, used for openid/openidc IdP) We then reached out to some "key users" to validate that some applications migrated to new authentication system were working fine. We tested with : * pagure (https://git.stg.centos.org) * koji * openshift/OCP * some other apps using openid In December 2020, there was a first ran of the fas2ipa script, so (consider this a snapshot) existing accounts in both FAS and ACO were merged. >From that import, there were 123 accounts that were duplicates ones, but as said, it can be that they are the same account but using different email addresses. # What do you have to do ? You can try to login through https://accounts.stg.centos.org and see if you can login. Important remark: if you *didn't* have a FAS account , your account was imported/created for the first time in IPA, so that means that you'll have to use the "Forgot Password ?" feature on portal to reset your account (mail will be sent to email address tied to your account) # When will the real migration happen ? We'll wait on AAA/noggin team to give us estimated date, and when they'll migrate Fedora first. Once that will be done, we'll migrate ACO to the new setup (probably fas2ipa script ran during a week-end, but to be announced) # How will that impact my workflow for CentOS as SIG member ? Worth knowing that all deployed services using ACO will have to be reconfigured for AAA. That currently means : * https://git.centos.org (and also the MQTT bus for git push notifications) * https://cbs.centos.org (and also non public signing service) * other small services using OpenID/OpenIDC for authentication (https://blog.centos.org, some jenkins instances used by QA team, etc) As said, we have already staged all changes to support new auth in our ansible roles. When we'll have rolled out these changes, your existing TLS certificate that you use to authenticate with for cbs.centos.org *will not* work anymore (important) That means that you'll have to retrieve a new TLS cert, signed by the IPA CA cert. How to do that ? I'll see about how porting this to know repository, but for now, there is a copr repo that you can use : https://copr.fedorainfracloud.org/coprs/arrfab/fasjson-client/ IMPORTANT : do *not* use this pkg now, or do this from another workstation/vm/account/whatever : the new 'centos-cert' util would replace your currently working TLS cert (from ACO) . (Well, as fasjson for prod *isn't* deployed yet, that would not work at all, but it would when deployed If you have questions, feel free to ask in this thread, or join #fedora-aaa on Freenode. -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

3 3

CentOS Stream 8 kernel
by Gena Makhomed 01 Feb '21

01 Feb '21

Hello All, I found regression in the CentOS Stream 8 kernels, and create bug report https://bugzilla.redhat.com/show_bug.cgi?id=1913806 After reading https://wiki.centos.org/Contribute/CentOSStream I try to download kernel sources and look for root cause of bug, but dist-git and source-git repos does not contain kernel sources, even if I try to execute %prep phase. For this reason I can't even try to find root cause of this bug by myself. This bug is critical for me, because currently I try to use systemd-nspawn for containers virtualization in production. If future CentOS 8.4 will contain this bug - it will be disaster. What else I can do (as user or developer) for fixing this bug? P.S. https://centos.org/distro-faq/ Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now? A: No. CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking we expect CentOS Stream to have fewer bugs and more runtime features as it moves forward in time but always giving direct indication of what is going into a RHEL release ================================== But currently I hit the bug, which is absent in CentOS 8.3 but present in CentOS Stream 8. Looks like CentOS Stream 8 is really the beta version for future RHEL minor release, despite the CentOS FAQ. Sorry, but this is true. -- Best regards, Gena

9 13

SIGs need to designate a "sponsor" (Re: Upcoming authentication changes)
by Rich Bowen 29 Jan '21

29 Jan '21

Hopefully you have seen Fabian's email earlier today with details about the upcoming changes to the authentication system. If you participate in a SIG, we need for you to identify someone who is the SIG lead, who will manage (the term FreeIPA uses here is "sponsor") the authentication (ie, SIG membership) for your particular SIG. For SIGs that don't speak up, we'll be using the information that's on your SIG wiki page, but I'm pretty sure that a lot of those are incorrect, and I'll be reaching out to some of you individually. Meanwhile, if you can update that information, we'll save everyone some time. Thanks.

4 4

[Cloud SiG] CentOS Cloud SIG meeting (2021-01-28)
by Amy Marrich 28 Jan '21

28 Jan '21

====================================================== #centos-meeting: CentOS Cloud SIG meeting (2021-01-28) ====================================================== Meeting started by spotz at 15:01:58 UTC. The full logs are available athttps://www.centos.org/minutes/2021/January/centos-meeting.2021-01-28-15.… Meeting summary --------------- * LINK: https://etherpad.opendev.org/p/centos-cloud-sig (spotz, 15:02:09) * ROll Call (spotz, 15:02:15) * Mission (spotz, 15:06:35) * LINK: https://wiki.centos.org/SpecialInterestGroup/Cloud (amoralej, 15:11:48) * LINK: https://www.centos.org/community/calendar/ I found to be more helpful (spotz, 15:13:19) * Chair/CO-Chair (spotz, 15:17:22) * Board Attendee (spotz, 15:39:40) * Sponsor for authentication (spotz, 15:42:45) * LINK: https://accounts.centos.org/group/view/sig-cloud (amoralej, 15:50:54) * Meeting Frequency (spotz, 15:55:49) Meeting ended at 16:01:42 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * spotz (77) * amoralej (70) * ykarel (9) * jcapitao (6) * jpena (6) * centbot (4) Generated by `MeetBot`_ 0.1.4 *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/>

1 0

Virtualization SIG meeting minutes - 2021-Jan-27
by Sandro Bonazzola 27 Jan '21

27 Jan '21

#centos-meeting: Virtualization SIGMeeting started by sbonazzo at 16:05:16 UTC (full logs <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…> ). Meeting summary 1. 1. ACTION: look through CentOS Virt SIG wiki and update anything that needs updating (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:09:18) 2. *Advanced Virtualization* (etrunko <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:09:59) 1. Reports of libvirt crashing with latest build (etrunko <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:10:35) 2. https://bugzilla.redhat.com/show_bug.cgi?id=1915601 (etrunko <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:10:39) 3. https://cbs.centos.org/koji/buildinfo?buildID=31798 (etrunko <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:11:54) 4. Fix has been officially released last Monday. The libvirt package has just been built for the Virt SIG. (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:12:07) 3. *oVirt updates* (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:12:56) 1. having troubles building apache-sshd within CBS, opened a ticket on it: https://bugs.centos.org/view.php?id=18036 (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:13:31) 2. upstream working on getting CentOS Stream as default platform for oVirt, still having some troubles there (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:14:14) 3. looking into having better collaboration and adding some oVirt test within CentOS Stream CI (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:14:59) 4. *Xen updates* (anthonyper <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:17:32) 1. Xen 4.12 package only missing one XSA release recently (anthonyper <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:18:16) 2. Nearly done with 4.13 packaging, I just need to check if packages are missing. (anthonyper <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:19:31) 5. *AoB* (sbonazzo <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…>, 16:20:15) Meeting ended at 16:21:29 UTC (full logs <https://www.centos.org/minutes/2021/January/centos-meeting.2021-01-27-16.05…> ). Action items 1. look through CentOS Virt SIG wiki and update anything that needs updating -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

1 0

CentOS related article at The Register
by redbaronbrowser 27 Jan '21

27 Jan '21

The Register has an article about CentOS: https://www.theregister.com/2021/01/26/killing_centos/ My best guess is the title and how the quotes form the interview was framed in the article wasn't what Red Hat expected. Maybe the reader should be taken with a grain of salt. I am posting it here for a number of reasons: First, my guess is the majority of members of centos-devel mailing list have already seen the article or would have seen it regardless of if I posted the link to it here. Second, I think it would be good to give someone from Red Hat a chance to respond to if there is inaccuracies in how the article characterizes things. Third, is this how we expect governance of Stream to work moving forward?

2 1

CentOS Dojo @FOSDEM, Next Week
by Rich Bowen 26 Jan '21

26 Jan '21

Reminder: we will be holding our annual FOSDEM CentOS Dojo next week on Thursday and Friday. It will of course be online. Details, schedule, and registration, are available at https://wiki.centos.org/Events/Dojo/FOSDEM2021 Registration is free. Please come, and tel your colleagues!

2 1

Balancing the needs around the RHEL platform
by redbaronbrowser 25 Jan '21

25 Jan '21

Karsten Wade has indicated the centos-devel mailing list is the place to talk about why he thinks things are going to turn out okay. He implied on the CentOS blog there is balancing of the needs of CentOS. Mostly the article is about the “openness gap” (which is brought up seven times). He goes through a very selective stroll through history to present his point leaving out anything that doesn’t fit his agenda. So, let’s go back to 2002. The most polished version of pre-RHEL Red Hat Linux, code named Valhalla, was released in March 2002. It was the result of years of refining the Red Hat packages in a repository called Rawhide and then a branch was released only when it passed quality assurance. Around the same time, a branch of Valhalla was also released as Red Hat Enterprise Linux 2. Then in September 2002, code name Psyche replaced Valhalla. Security updates for Valhalla ended unless you became a RHEL 2 customer. Psyche was a problem for a couple reasons. While Red Hat pointed out that it had more features than RHEL, it wasn’t just the “good” features. Psyche contained several regressions and bugs that should have never passed quality assurance. Rather, it appeared whatever was the latest packages in Rawhide just got dumped as Psyche since it was just the free community version and RH QA was focused on just RHEL. If I recall correctly, at the time Red Hat apologized for Psyche and tried to reassure the community the problems were not intentional. Red Hat 9 (Shrike) was released in March 2003 and the first Fedora Core released in November 2003. The continued development under FC addressed several of the bugs. But two new issues came up. First new issue was Red Hat’s creation of the openness gap. There were now two Rawhide repositories. The public Rawhide moved to Fedora. But also a Rawhide branch that RHEL work from was kept private. Second new issue was a COMPATIBILITY gap. Fedora wasn’t designed to be 100% API or ABI compatible with RHEL. Several times a binary built on Fedora could not be run on RHEL 2. A statically linked binary might temporarily address the issue but then security updates to the RHEL 2 libraries would not fix issues with the statically linked binary. To build a dynamically linked binary for RHEL 2 without paying for RHEL 2 required using Valhalla which was no longer getting security updates. In May 2004, a solution to the COMPATIBILITY gap was released. The Community ENTerprise OS. As stated in it’s FAQ: > “Does CentOS change the upstream Source RPMs?” > “No. CentOS' key mandate for our base and updates repositories is NOT extending or enhancing packages or features beyond those supplied by the upstream Source RPM's. CentOS strives intentionally to provide binary functionality for our users.” Now the community had two options. Fedora for features or CentOS for compatibility. It is important to remember, CentOS strived for COMPATIBILITY by *avoiding* additional features as this fundamental concept will come up later. In October 2004, Ubuntu would be released. This would be a challenge for CentOS. While CentOS *strive* for being 100% compatible with the commercially supported RHEL, Ubuntu LTS community edition is able to prove it is 100% identical to Ubuntu LTS with commercial support. Over time another openness gap was created. The Linux kernel is under the General Public License v2 which requires openness including notices of what files are modified and when. The Linux kernel development team accomplishes this with a public git repository. The majority of distributions (including Fedora) do this by providing the vanilla kernel source code and then each of the patches separately. RHEL/CentOS instead violated the spirit of the GPL v2 and the spirit of openness. CentOS users are given a kernel tar-ball with all the patches already applied and a changelog. The changelog does not indicate which files are modified per item but I am willing to guess that Red Hat legal has written off that they can defend this as compliant with the legal language of the GPL v2. This violation of openness also has technical downsides. If a newer Fedora kernel breaks something, you can rebuild the kernel RPM with select patches unapplied until you locate which specific patch in the new kernel causes the bad behavior. But performing a roll-back of patches on CentOS was made difficult because by design RH provides no clear indication exactly what each patch changes. Instead, CentOS users can open a bugzilla issue to try to get a Red Hat employee to trace down which individual patch caused the issue. But from what I can tell that usually doesn’t work out well. Maybe someone will take notice and ask for more information. However, from what I can tell, several times a project manager just closes the ticket with a statement a new version of RHEL has been released and to start back at square one with a new ticket (to be ignored again). So, fast forward to 2013. Karsten Wade has stated at this point he led the Red Hat team to assimilate CentOS and took a seat at the CentOS Governing Board. In 2014 the joining was announced which included this statement of reassurance to the CentOS community: > “The Red Hat Enterprise Linux to CentOS firewall will also remain. Members and contributors to the CentOS efforts are still isolated from the RHEL Groups inside Red Hat, with the only interface being srpm / source path tracking, no sooner than is considered released. In summary: we retain an upstream.” Then fast forward to October 2018, the Linux kernel development team releases 4.19 as a long term support kernel. In May 2019, RHEL 8 was released with a 4.18 kernel. RHEL doesn’t get the benefit of the community effort to support the LTS kernel for 6 years and the LTS kernel community doesn’t get the benefit of RHEL supporting a kernel for 10 years. Instead, RHEL continues a policy of releasing a monolithic tar-ball that obscures what each patch changes in violation of the spirit of openness (again, by design). Then continuing on to 2020. CentOS 6 is reaching the end of life at the end of November with no plans to continue providing security updates. RHEL Extended Life Cycle subscribers will get some select security updates but under an openness gap by RH design none will be shared through CentOS. At the same time, it appears “state level actors” are leveraging security holes more than ever before. CentOS users are given two options. First is to upgrade to CentOS 7 but then reach the end of life again in June 2024. Or skip from CentOS 6 to CentOS 8 which is stated to be supported until 2029. Then Red Hat announces after CentOS 6 users have performed their upgrades that the real end of life that CentOS was committed to for CentOS 8 is December 2021. It is really CentOS 7 that has a longer commitment by 2.5 years. To reassure the community there is an FAQ with the following: > “CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking we expect CentOS Stream to have fewer bugs and more runtime features as it moves forward in time but always giving direct indication of what is going into a RHEL release” This is a complete reversal on a fundamental concept stated earlier by CentOS. Previously the mission was to close the COMPATIBILITY gap by *NOT* “extending or enhancing packages or features.” But Red Hat is clever enough to rename “Rawhide” to “Stream” to make it sound better. However, at the end of the day this is the same behavior and problems that gave us Red Hat Psyche, only now it is CentOS edition of Psyche that is coming. Karsten Wade’s main sales pitch for this is addressing the openness gap. I agree that RHEL Rawhide should never have been made private. But based on the “firewall” established between CentOS and RHEL, it should be up to the RHEL team to make their Rawhide public and not involve CentOS at all. RH self-imposed openness gaps shouldn’t be used as the basis to violate the previous assurances provided to the community. But it turns out Red Hat was not being honest about the “firewall” from the RHEL group. In fact, one of the members of the CentOS Governance Board includes a member of a RHEL group. Also, this is not any old RHEL group member, it is Brain “Bex” Exelbierd, the RHEL member that establishes the roadmap for RHEL. WIth CentOS going from downstream provider to upstream provider, the roadmap for CentOS stops being focused on the community and comes instead from Bex for the benefit of RHEL. Exactly what CentOS users feared would happen in 2014 is now taking place. And this is being done in the name of openness? Where is the improved openness for CentOS users? Where is an open transcript, chat log or voice recording of the CentOS Governance Board meeting that selected to kill CentOS 8 in favor of CentOS Rawhide? Where is the openness in the statement there will be a firewall between CentOS and the RHEL group? Was Bex only interfacing at governance meetings via SRPMs? Was the firewall always a lie? Where is the openness in CentOS’ commitment to support CentOS 8 to 2029? Where is the openness in the CentOS kernel patches? Where is the openness in having one CentOS FAQ indicating extending features beyond upstream is *NOT* part of CentOS and at the same time have another FAQ stating CentOS features will be coming ahead of RHEL? The nicest way I can think of to put it regarding the assertion that this closes the openness gap as a benefit to CentOS users is at this point that I believe that Karsten Wade must have an intestinal tract full of copious amounts of matter. The most insane part is this change should be bad for Red Hat itself in the long run. CentOS should be helping attract market share for RHEL by encouraging developers to build/test on a RHEL compatible system and giving potential RHEL customers a try before you buy method. But CentOS hasn’t been competing well as it is. Majority of AWS instances are running Ubuntu. Several Azure instances are running Ubuntu. There are several Docker Hub images that use Ubuntu as a base image and much fewer using CentOS/RHEL. CentOS/RHEL is no longer the preferred runtime environment to develop for and where the developers go the users will eventually follow. Bringing back the COMPATIBILITY gap is not the solution to that. It is how to make things worse. Several of the projects Karsten Wade selected to highlight seems to suggest that Red Hat sees itself as expanding into ESXi’s market share. That is a worthy goal but should not replace promoting RHEL as a preferred runtime environment. Having a RHCE should not be reduced to knowing the next generation hypervisor and modern day BIOS. The test requires knowing much more than that and RH should continue to provide maximum possible value to the people with a RH certification. With CentOS Rawhide (or CentOS Stream if you prefer calling it that) replacing CentOS 8, the try before you buy will go to companies like Oracle and CloudLinux. But once someone resolves the COMPATIBILITY gap by going to either of those solutions for the community edition, chances are better they will go back to the same source for commercial support later as well. This is a roadmap for RH giving up more market share. Why? For claims of openness that ring empty? It would be nice to hear from Paul Cormier why he would allow this type of behavior and insanity on the part of Red Hat but I doubt we will ever get that level of openness.

25 124

May we get all subpackages in C8S repos?
by Alfredo Moralejo Alonso 24 Jan '21

24 Jan '21

Hi, With the refocus of CentOS to Stream, i think it'd make sense to open the discussion about the missing subpackages (mainly devel ones) in the repos. While I understand that this was part of the idea of a "pure clone" of RHEL when working with CentOS Linux, now that stream is more intended to be used by devel community and not as a pure rebuild, I think there are reasons to change this policy. What'd be the best way to open this discussion?, is it being discussed already?, should this be a topic for the board? Best regards, Alfredo

9 16

RDO and CentOS AMA Recording
by Amy Marrich 22 Jan '21

22 Jan '21

If you were unable to attend yesterday's session the recording is now available on You Tube[0]. Related links and questions were captured on an Etherpad[1]. If you have any questions, please reach out on the mailing list or in the #RDO channel. Thanks, Amy (spotz) 0 - https://www.youtube.com/watch?v=MlhAhClVaEI&feature=youtu.be 1- https://etherpad.opendev.org/p/RDO-Stream-AMA *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/>

1 0

how do we create CentOS' comps.xml
by Ken Dreyer 22 Jan '21

22 Jan '21

Hi folks, When I look at a commit like this: https://git.centos.org/centos/comps/c/5251f94b374cd9cf527f85a0a82245c0a8381… it's adding over 10,000 lines of configuration. I'm wondering how that relates to RHEL's comps. Do the CentOS developers have a tool that generated that XML from a data source elsewhere? Did someone write that XML by hand? - Ken

5 8

Centos Stream 8 installation fail...
by André Verwijs 22 Jan '21

22 Jan '21

I've installed Centos Stream 8 with Network install and install dvd, but with both Centos Stream doesn't statrup correctly. "gnome-initial-setp" account (first time run) doesn't close properly, so i don't get login screen to first non-root user .... when i instal Centos 8(not stream) everything works great..!! i have to upgrade to stream after installation... André -- ______________________________________________________________________________________ My Twitter Page: twitter.com OpenSimFan <http://twitter.com/OpenSimFan> My Instagram page: instagram.com dutchglory <http://instagram.com/dutchglory> My Facebook page (be my friend, please) facebook.com André Verwijs <http://www.facebook.com/andre.verwijs> My Google+ page (follow me please ) André Verwijs - Google+ <https://plus.google.com/111310545842863442992>

2 1

RHEL IdM update in CentOS 8 Stream
by Alexander Bokovoy 21 Jan '21

21 Jan '21

Hi, thanks for Carl and Brian, yesterday's compose of CentOS 8 Stream now includes RHEL IdM bits slated for RHEL 8.4. Several components were rebased to their upstream versions and are worth noting to those who want to test them in advance of RHEL 8.4. Note that these are not final RHEL IdM updates for RHEL 8.4. While RHEL builds already passed through a comprehensive QA cycle, there are still few improvements that will come during next month or so. Bugs found by CentOS 8 Stream users would in general be seen in the same way as those found by RHEL QE teams during the RHEL minor release development, so it is your opportunity to help. Also improvements in form of upstream patches are welcome too. There are many small and large fixes and improvements in FreeIPA 4.9.0. For more detailed information I'd point to FreeIPA 4.9.0 release notes: https://www.freeipa.org/page/Releases/4.9.0#Highlights_in_4.9.0 Among those changes, we are looking for a feedback to following features of RHEL IdM in CentOS 8 Stream: == ACME CA integration With FreeIPA 4.9 and Dogtag 10.10 it is now possible to deploy ACME support in FreeIPA CA and issue certificates using ACME protocol. For more details please look at https://www.freeipa.org/page/V4/ACME for general design overview and Fraser's blogs around the feature: https://frasertweedale.github.io/blog-redhat/tags/acme.html CentOS 8 Stream includes mod_md Apache module as one of ACME clients. Fedora and EPEL do also have a certbot, so there are multiple clients to use. Interoperability testing with other clients would also be great to see reported. == Active Directory integration improvements There are enhancements for services for user (S4U) feature of Kerberos protocol extensions in Active Directory. In particular, it is now possible to run MS SQL server on a server enrolled into RHEL IdM domain and allow access to it to users of trusted Active Directory forests, along with IPA users. MS SQL does certain operations that required functionality not supported by RHEL IdM. This was fixed in RHEL 8.3. More improvements are available in CentOS 8 Stream, including performance improvements when creating Kerberos tickets for Active Directory users with a large AD group membership. == Non-FQDN host support FreeIPA requires uniform hostname support -- either all systems defined with fully-qualified hostnames or they all are using non-FQDN. In practice, there are checks in the installers to always force FQDN host names. There are many applications that insist on seeing hostnames as non-fully qualified. FreeIPA 4.9.0 adds ability to enroll non-FQDN hosts to otherwise FQDN-based IPA deployment. In addition, this allows to enroll clients with hostnames of total FQDN length longer than 64 characters on Linux. == FIPS support RHEL IdM in CentOS 8 Stream is now capable to be deployed and operated in FIPS mode. One notable omission is the support for trusted Active Directory domains. We are working on FIPS support for trust to AD upstream and already have a good progress. Hopefully, this work will be completed in upcoming weeks and will also land in CentOS 8 Stream. == DNS support improvements PTR records now supported in any zone type to facilitate DNS-SD [RFC6763] operations, for example, publishing printers. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

Cloud SiG Reviatlization
by Amy Marrich 20 Jan '21

20 Jan '21

The Cloud SiG will be meeting next week to revitalize the group. We will meet January 28 at 15:00 UTC in the #centos-meeting room as outlined in https://www.centos.org/community/calendar/. Goals for the meeting are as follows: Election of Chair and Co-Chair Meeting frequency SiG Mission If you have an interest in Cloud and CentOS please join us! Thanks, Amy (spotz) *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/>

1 0

Thunderbird 78.6 for CentOS 8.3
by Chris Schanzle 19 Jan '21

19 Jan '21

Hi, It appears Thunderbird 78.6.0 was never released for CentOS 8.3. Could someone please check on it? Perhaps the Files->c8 section warning is a clue: Warning: This package was configured for automatic debranding, but the changes failed to apply. As a related topic, I have experience building RPM's/mock, superficial git user, but I'm still kinda lost how I might be able to get a .src.rpm out of the current state of https://git.centos.org/rpms/thunderbird/tree/404b3fff4f6bcc2c23e085b4ad2c1e… Any brief / terse tips would be appreciated. I did see Johnny's msg https://lists.centos.org/pipermail/centos-devel/2020-December/075681.html but it doesn't seem to apply to this situation as there is no koji build info. Thanks! Chris

4 4

Centos Stream 8 installation..
by André Verwijs 18 Jan '21

18 Jan '21

I've installed Centos Stream 8 with Network install and install dvd, but with both Centos Stream doesn't statrup correctly. "gnome-initial-setp" account (first time run) doesn't close properly, so i don't get login screen to first non-root user .... when i instal Centos 8(not stream) everything works great..!! i have to upgrade to stream after installation... André -- ____________________________________________________________________ Dank U - Thank You *Twitter:* http://twitter.com/OpenSimFan <http://twitter.com/OpenSimFan> *Facebook* http://www.facebook.com/andre.verwijs <http://www.facebook.com/andre.verwijs> *Instagram:* André Verwijs - Instagram <https://instagram.com/dutchglory>

1 0

Introducing the ARC sub-team in CPE - and first research topic
by Pierre-Yves Chibon 18 Jan '21

18 Jan '21

Good Morning Everyone, While planning work, the CPE team has realized that a number of our initiatives actually start with a research phase to find the most appropriate technical solution. This leads to some issues with planning as without knowing the technical solution we want to take, it's hard to evaluate the amount of work needed and thus the time it'll take to do it. In order to help with this, we're creating a small sub-team in CPE, called the ARC team for Advance Reconaissance Crew*. The goal of this team will be to investigate what we believe to be the possible technical solutions for initiatives and advise the team on what they believe would be the appropriate solution. To this end, we will reach out when we start looking for ideas as you may have ideas that we did not think about. The first investigation, led by Will Woods, Mark O'Brien and I, will be around datanommer and datagrepper. datanommer is an application listening to fedmsg and filling a (postgresql) database with all the messages passing on the bus. datagrepper is a web application exposing these messages and offering a way to filter or search them. available at: https://apps.fedoraproject.org/datagrepper/ Currently our ideas are: - for datanommer: - port it to fedora-messaging - adjust it to whichever solution we chose to replace datagrepper - for datagrepper: - keep it as is - Replace by - postgres https://postgrest.org/ - prest https://github.com/prest/prest - kinto https://docs.kinto-storage.org/en/stable/ - Swagger/OpenAPI https://swagger.io/ - Add support for Graphql - for the postgresql server - Split messages per year in different table - Unite them using a postgresql view - Kick out the old messages per year - Keep the current year + n-1 in the current DB - Kick the other to another DB? - Kick the other to a tarball somewhere? - Output the database daily dump to file / year - TimescaleDB a postgresql plugin for time-series data - https://alibaba-cloud.medium.com/postgresql-time-series-database-plug-in-ti… - https://dev.t-matix.com/blog/postgresql-as-a-time-series-database/ - https://docs.timescale.com/latest/introduction - Make the msg field in the message table be a JSON field Would you have any other ideas of things we could look at? Looking forward for your input, Thanks, Pierre, Will and Mark * Our notes and documentation are hosted at: https://fedora-arc.readthedocs.io/en/latest/index.html

1 0

Status of CentOS SIGs
by Rich Bowen 18 Jan '21

18 Jan '21

Hi, folks, In yesterday's board meeting, the board asked me to report on the status of all of our SIGs. I have put together this report - https://docs.google.com/document/d/1e6Bw1x7ReDOuk4rrPz-Wl4EBaEicLG35rJb8P7_… - which covers all of the SIGs which are listed on https://wiki.centos.org/SpecialInterestGroup If you are involved in any SIG, please review what I have written there, and make any comments/corrections that you feel are warranted, so that I am passing the most accurate information possible to the board. Thanks!

6 10

Questions regarding CS8
by Alex Iribarren 18 Jan '21

18 Jan '21

Hi all, We're starting to look at CentOS Stream 8 and we have some questions that we haven't been able to find clear answers for. The closest we've come is "stay tuned", I'm hoping to get a clearer timeline. 1. When will Stream source RPMs appear in `vault.centos.org`? (Bugs [#17951](https://bugs.centos.org/view.php?id=17951) and [#16715](https://bugs.centos.org/view.php?id=16715)). 2. When will debuginfo RPMs appear in `debuginfo.centos.org`? 3. When will the CentOS Stream 8 docker image be built? When will it be available in [dockerhub](https://hub.docker.com/_/centos)? [Bug #17973](https://bugs.centos.org/view.php?id=17973) 4. How will updates to Stream be handled? For example, will there be multiple "major" (ie. 4.18.0-259) kernel families in Stream, and then one of those will be picked to be the RH 8.4 kernel? Or will there usually be only one, and Stream's current 4.18.0-259 kernel family become the kernel of RH 8.4? 5. What is going to be in the [cr](http://mirror.centos.org/centos/8-stream/cr/) repository of Stream? Will those be updates that have yet to make it into CentOS Stream? How often will that repository be updated? 6. When I asked some of these questions on IRC in #centos-devel, I was told that the "Stream team" is in #centos-stream. Is there actually a different team? Is #centos-stream, and not #centos-devel, the canonical chat channel? Apologies in advance if some of these questions have already been answered, it's hard to keep up with the hundreds of messages over Christmas. Cheers, Alex

2 2

Re: [CentOS-devel] Upgrade to Stream wants to downgrade e.g. httpd
by redbaronbrowser 16 Jan '21

16 Jan '21

On Thursday, January 14, 2021 7:23 AM, orkcu via CentOS-devel <centos-devel(a)centos.org> wrote: > Considering that CentOS 8.5 will never be, a year from now (6 month only?) you will not have this issue, as Baron said, with new packages coming to Stream the issue will go away naturally unless you want to move from RHEL to CentOS Yes, I want to move from RHEL to Stream. If someone reports a bug in RHEL 8.5 then I want to be able to advocate for them to test that Stream fixes the issue. It is more likely they will have a RHEL 8.5 template to create a test virtual machine than a Stream template. I don't think it is unfair to assume they may use RHEL 8.5 as the starting point for trying Stream. If we aren't building a community that can advocate for use cases of Stream, then I'm confused what the goal of Stream is. If the goal is that Stream is to be PUBLICLY available as-is for people to try similar to what OpenSolaris ended up being, then that is fine but that should be clearly stated. If the goal is that Stream is to be OPEN to encourage building a community for two-way dialogue, then I think we can do better than suggest no one should ever want to side-grade from RHEL to Stream. There is advantages and disadvantage to either goal. I just would like to establish which it is and then set bug/feature requests accordingly.

5 8

CPE Weekly: 2021-01-15
by Aoife Moloney 15 Jan '21

15 Jan '21

Hi Everyone, New Year, same CPE weekly(ish) :) If you would like to see this report and toggle to the section you are most interested in, I would suggest visiting this link https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view and use the header bar on your left to skip to where you want to go! ## General Project Updates We are kicking off Q1 this year with some familiar project faces, namely Noggin, the replacement of the current FAS system and continuing our development of CentOS Stream. Most of our initiatives live here https://pagure.io/cpe/initiatives-proposal and you can use the new issue button to submit your own proposal. Our updated initative timetable can be viewed here for 2021 https://docs.fedoraproject.org/en-US/cpe/time_tables/ so you know when I need it in by to review it. We also have updated our docs section on the initiative process we follow as we cannot accept everything so please do check it out if you want to understand our process more https://docs.fedoraproject.org/en-US/cpe/initiatives/ ### Misc #### GitLab Being very honest, I've found myself a little bit strapped for time to give this project its due diligence over the last few months, but please bear with us/me and expect a more concentrated effort on this coming into Q2 (April, May, June) of this year. I apologise for the time a resolution is taking and I really do appreciate all of your patience. ## Project Updates *The below updates are pulled directly from our CPE team call we have every week.* ## CentOS Updates ### CentOS * Community newsletter can be read here https://blog.centos.org/2021/01/centos-community-newsletter-january-2020-21… ### CentOS Stream * Continuing to work on Stream 8 pushes and builds * Investigating how to automate some module pushes * Reviewing documentation that is available on Stream currently to identify gaps and where needs improvement ### Fedora * OSBS is building for aarm64 & x86_64 in production since December! * All of the projects under the fedora-infra and releng namespaces on pagure have had their default branch migrated from “master” to “main”. * F34 mass rebuild due to start next week ### Noggin/AAA * New sprint started focusing on testing correct access has been given per user/account * Last remaining apps being configured & tested with fasjson API * Work will be tracked here https://github.com/fedora-infra/aaa-tracker/issues/4 * Our open issues board can be found here https://github.com/orgs/fedora-infra/projects/6 ### Fedora Messaging Schemas * We are working through supybot and greenwave applications currently * There is a list of applications that require messaging schemas can be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit * There is a readme which contains documentation on messaging schemas, a cookie-cutter template to create the schema and a definition of Done for writing a schemas https://github.com/fedora-infra/fedora-messaging-schemas-issues * The board they are working from can be viewed here https://github.com/orgs/fedora-infra/projects/7 ## Team Info ### Background: The Community Platform Engineering group, or CPE for short, is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. See our wiki page here for more information:https://docs.fedoraproject.org/en-US/cpe/ As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

[CloudSIG] RDO plans to move to CentOS Stream
by Alfredo Moralejo Alonso 14 Jan '21

14 Jan '21

Hi, As you know, CentOS announced recently that they will be focusing on CentOS Stream [1] and that CentOS Linux 8 will be EOL at the end of 2021 [2]. In order to align with this change, the RDO project is adapting the roadmap for the current and upcoming releases: - RDO Wallaby (ETA is end of April 2021 [3]) will be built, tested and released only for CentOS 8 Stream. - RDO CloudSIG repos for Victoria and Ussuri will be updated and tested for both CentOS Stream and CentOS Linux 8 until end of 2021 and then continue on CentOS Stream. - In the upcoming weeks, we will create new RDO CloudSIG repos for Victoria and Ussuri for CentOS Stream 8. - RDO Trunk repositories (aka DLRN repos) will be built and tested using CentOS 8 Stream for all releases currently using CentOS Linux 8 (starting with Train). If you are interested in the details about these plans and how we plan to implement it, we've created a blog post [4]. Don't hesitate to ask us in the ML or in the #rdo channel on freenode if you have questions or suggestions about this. We are also organizing a video AMA about RDO and CentOS Stream on Thursday Jan 21 1600 UTC in the RDO Meet room https://meet.google.com/uzo-tfkt-top On behalf of RDO, Alfredo [1] https://centos.org/distro-faq/ [2] https://blog.centos.org/2020/12/future-is-centos-stream/ [3] https://releases.openstack.org/ [4] https://blogs.rdoproject.org/2021/01/rdo-plans-to-move-to-centos-stream/

1 0

Re: [CentOS-devel] Upgrade to Stream wants to downgrade e.g. httpd
by Yedidyah Bar David 14 Jan '21

14 Jan '21

On Thu, Jan 14, 2021 at 3:23 PM orkcu via CentOS-devel <centos-devel(a)centos.org> wrote: > > Considering that CentOS 8.5 will never be, a year from now (6 month only?) you will not have this issue, as Baron said, with new packages coming to Stream the issue will go away naturally unless you want to move from RHEL to CentOS I can definitely see myself wanting to move from RHEL (or a rebuild) to Stream in the future, for specific uses/machines. And I do not think this is a unique/strange/corner case. I agree it's probably not the most common one. -- Didi

1 0

Upgrade to Stream wants to downgrade e.g. httpd
by Yedidyah Bar David 14 Jan '21

14 Jan '21

Hi all, I have a CentOS 8.3 machine I want to upgrade to Stream following [1]. After fighting with it a bit due to oVirt-specific issues [2], I reached the current point: doing 'dnf update' updated everything nicely, but now doing 'dnf distro-sync' wants to downgrade these packages: Downgrading: httpd x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 1.7 M httpd-filesystem noarch 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 37 k httpd-tools x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 104 k mod_ssl x86_64 1:2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 133 k python3-docutils noarch 0.14-12.module_el8.3.0+389+6a62c88d appstream 1.6 M python36 x86_64 3.6.8-2.module_el8.3.0+389+6a62c88d appstream 19 k I specifically mention httpd in Subject because that's the one I spent some time looking at, but the issue is general. I currently have httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64 . It seems to be the result of [3], which says it was built from: git+https://git.centos.org/rpms/httpd#2f74eecf85362e67c403b7b1386a729da3e5c… . distro-sync wants to downgrade to 2.4.37-30.module_el8.3.0+462+ba287492.0.1 , which seems to be the result of [4], which says it was built from: git+https://git.centos.org/rpms/httpd#fcb5444a5c0aefcd065e6c4a805a454e4988b… . cloning the git repo, and then checking the difference between them, I get: $ git diff 2f74eecf fcb5444a diff --git a/SPECS/httpd.spec b/SPECS/httpd.spec index 8322bd8..7d66f2e 100644 --- a/SPECS/httpd.spec +++ b/SPECS/httpd.spec @@ -13,7 +13,7 @@ Summary: Apache HTTP Server Name: httpd Version: 2.4.37 -Release: 30%{?dist} +Release: 30%{?dist}.0.1 URL: https://httpd.apache.org/ Source0: https://www.apache.org/dist/httpd/httpd-%{version}.tar.bz2 Source1: centos-noindex-8.0.tar.gz So: 1. The sources seem to be identical, right now, with the only difference being the 'Release:'. 2. I failed to find where '462+ba287492' and '561+97fdbbcc' are coming from. I assume they are automatically-generated during the build process, but not saved in the dist-git repo. These seem to be what's causing the "newer" version in Stream to be considered a "Downgrade" - 462 < 561. Perhaps they are some kind of timestamps, or increasing counters, etc., and '462' was built earlier than '561', even if in all other regards it should be considered "newer". 3. Perhaps the intention was to have the release in Stream: Release: 30.0.1%{?dist} ? I think this would have caused this to not be considered a downgrade. I might be missing something. 4. IMO this is a bit confusing/discouraging. Can/Do we do anything so that 8-Stream packages are always >= 8.3 ones? Perhaps a fix should be manually applied to each and every package (if at all), but just generating a report somewhere, perhaps with a place to a link to a bug per package as applicable, can be done in batch, more-or-less, if I got it right. Do we have something like this? Do we want something like this? 5. Perhaps (alternatively?), Stream's version should just be rebuilt, e.g. with 'Release: 30%{?dist}.0.2'. Thanks and best regards, [1] https://www.centos.org/centos-stream/ [2] https://github.com/oVirt/ovirt-cockpit-sso/pull/30 [3] https://koji.mbox.centos.org/koji/buildinfo?buildID=14516 [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=12971 -- Didi

6 8

[CloudSIG] Questions about adopting CentOS 8 Stream
by Alfredo Moralejo Alonso 14 Jan '21

14 Jan '21

Hi, In Cloud SIG, we are planning adoption to CentOS 8 Stream. I'd like to clarify what will be the workflow and get some info about open questions and issues before starting to request stuff. IIUC, the intended workflow to build, ship and consume packages for c8s should be pretty similar to the current one: Build: 1. Request new tags which will use C8S buildroot, something like cloud8s-openstack-victoria-*. 2. Build from srpm on those new tags. Ship: 3. Tagging into cloud8s-openstack-victoria-testing will trigger automatically shipping a package under https://buildlogs.centos.org/centos/8-stream/cloud/x86_64/openstack-victori… (note 8-stream in url). 4. Tagging into cloud8s-openstack-victoria-release will trigger automatically shipping a package under http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/ (note 8-stream in url) Consume: 5. Users in a C8S box, install the release rpm from extras centos-release-openstack-victoria and repos are configured to use from 8-stream URLs. Please confirm this is the intended workflow or if there is any change. I assume we can maintain separated repos for C8 and C8S with different or same (cross-tagged) packages in the SIG. Now, some questions: - The release RPMs will be the same for C8 and C8S (as it is currently) or can be different?, we may have a new release only for C8S and not for C8 so we may need different release rpms. - Do we need to adjust somehow the .repo to point to the right URLs in C8 or C8S (i thing $releasever points to 8 in centos-stream). - Is the infra already ready to build and push packages for C8S or are there open issues that we should be aware of?, is the automated push and ship based on tagging/untagging ready for C8S builds? - Is there any change in naming convention for tags, repos, etc... (i assumed <signame>8s- instead of <signame>8- ). - Should we use a different disttag for C8S buildroots?, (I'd prefer to stay with regular .el8). Best regards, Alfredo

2 2

NFV SIG meeting minutes - 2021-Jan-13
by Thomas F Herbert 13 Jan '21

13 Jan '21

1 0

CentOS Dojo @ FOSDEM
by Rich Bowen 11 Jan '21

11 Jan '21

We are pleased to announce a preliminary schedule for the online CentOS Dojo prior to FOSDEM. Details are available here: https://wiki.centos.org/Events/Dojo/FOSDEM2021 Registration will be free, and the link to registration is at the above page.

1 0

Queries on CentOS Stream
by Chan, Catherine [ITS] 09 Jan '21

09 Jan '21

Hi, I'm working in a University and we have a no. of servers running CentOS Linux. We chose CentOS Linux because it is free of charge. Recently we learned that CentOS is shifting focus from CentOS Linux to CentOS Stream. We are very concerned if CentOS Stream requires subscription and if updates/patches for CentOS Stream requires subscription. Can you help on my queries below: Question 1 Referring to 'FAQ - CentOS Project shifts focus to CentOS Stream' (https://centos.org/distro-faq/<https://secure-web.cisco.com/12vidbGo4KDeMy7BxwP79RXZ8adFilOrBfFEAuqwSj1E2G…>): Q2: What about the other releases of CentOS Linux? A: * Updates for the CentOS Linux 6 distribution ended November 30, 2020<https://secure-web.cisco.com/1AFEn0WSozOLnX5KWTyqLb81hqQsytVdWyuFXdazPwmDg4…>. * Updates for the CentOS Linux 7 distribution continue as before until the end of support for RHEL7<https://secure-web.cisco.com/1Vjg5-b7gAc7XPdTp009SgavZ85rt-79Y60WEjKdZHhQl-…>. * Updates for the CentOS Linux 8 distribution continue until the end of 2021; users can choose to switch over directly to CentOS Stream 8 * Updates for the CentOS Stream 8 distribution continue through the full RHEL support phase<https://secure-web.cisco.com/1Vjg5-b7gAc7XPdTp009SgavZ85rt-79Y60WEjKdZHhQl-…>. We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.) I don't quite understand the 4th point, 'Updates for the CentOS Stream 8 distribution continue through the full RHEL support phase<https://secure-web.cisco.com/1Vjg5-b7gAc7XPdTp009SgavZ85rt-79Y60WEjKdZHhQl-…>'. Can you further elaborate it? Does it mean that users will receive updates/patches for CentOS Stream 8 ONLY if they subscribe full RHEL support? Question 2 In the announcement, it states 'If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.' Can you highlight what are the drawbacks of CentOS Stream causing not encouraged to run on a production environment? Thanks very much in advance. Regards, Catherine Chan [https://www.polyu.edu.hk/emaildisclaimer/PolyU_Email_Signature.jpg] Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful. The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.

6 8

Re: [CentOS-devel] [Gluster-devel] Multiple Geo Rep issues due to SELINUX on CentOS 8.3
by Strahil Nikolov 08 Jan '21

08 Jan '21

Hi Srijan, I will redeploy the scenario and I will check if the steps include that package. Shouldn't glusterfs-selinux a dependency ? Best Regards, Strahil Nikolov В сряда, 6 януари 2021 г., 07:29:27 Гринуич+2, Srijan Sivakumar <ssivakum(a)redhat.com> написа: Hi Strahil, Selinux policies and rules have to be added for gluster processes to work as intended when selinux is in enforced mode. Could you confirm if you've installed the glusterfs-selinux package in the nodes ? If not then you can check out the repo at https://github.com/gluster/glusterfs-selinux. Regards, Srijan On Wed, Jan 6, 2021 at 2:15 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: > Did anyone receive that e-mail ? > Any hints ? > > Best Regards, > Strahil Nikolov > > В 19:05 +0000 на 30.12.2020 (ср), Strahil Nikolov написа: >> Hello All, >> >> I have been testing Geo Replication on Gluster v 8.3 ontop CentOS >> 8.3. >> It seems that everything works untill SELINUX is added to the >> equasion. >> >> So far I have identified several issues on the Master Volume's nodes: >> - /usr/lib/ld-linux-x86-64.so.2 has a different SELINUX Context than >> the target that it is pointing to. For details check >> https://bugzilla.redhat.com/show_bug.cgi?id=1911133 >> >> - SELINUX prevents /usr/bin/ssh from search access to >> /var/lib/glusterd/geo-replication/secret.pem >> >> - SELinux is preventing /usr/bin/ssh from search access to .ssh >> >> - SELinux is preventing /usr/bin/ssh from search access to >> /tmp/gsyncd-aux-ssh-tnwpw5tx/274d5d142b02f84644d658beaf86edae.sock >> >> Note: Using 'semanage fcontext' doesn't work due to the fact that >> files created are inheriting the SELINUX context of the parent dir >> and you need to restorecon after every file creation by the geo- >> replication process. >> >> - SELinux is preventing /usr/bin/rsync from search access on >> .gfid/00000000-0000-0000-0000-000000000001 >> >> Obviously, those needs fixing before anyone is able to use Geo- >> Replication with SELINUX enabled on the "master" volume nodes. >> >> Should I open a bugzilla at bugzilla.redhat.com for the selinux >> policy? >> >> Further details: >> [root@glustera ~]# cat /etc/centos-release >> CentOS Linux release 8.3.2011 >> >> [root@glustera ~]# rpm -qa | grep selinux | sort >> libselinux-2.9-4.el8_3.x86_64 >> libselinux-utils-2.9-4.el8_3.x86_64 >> python3-libselinux-2.9-4.el8_3.x86_64 >> rpm-plugin-selinux-4.14.3-4.el8.x86_64 >> selinux-policy-3.14.3-54.el8.noarch >> selinux-policy-devel-3.14.3-54.el8.noarch >> selinux-policy-doc-3.14.3-54.el8.noarch >> selinux-policy-targeted-3.14.3-54.el8.noarch >> >> [root@glustera ~]# rpm -qa | grep gluster | sort >> centos-release-gluster8-1.0-1.el8.noarch >> glusterfs-8.3-1.el8.x86_64 >> glusterfs-cli-8.3-1.el8.x86_64 >> glusterfs-client-xlators-8.3-1.el8.x86_64 >> glusterfs-fuse-8.3-1.el8.x86_64 >> glusterfs-geo-replication-8.3-1.el8.x86_64 >> glusterfs-server-8.3-1.el8.x86_64 >> libglusterd0-8.3-1.el8.x86_64 >> libglusterfs0-8.3-1.el8.x86_64 >> python3-gluster-8.3-1.el8.x86_64 >> >> >> [root@glustera ~]# gluster volume info primary >> >> Volume Name: primary >> Type: Distributed-Replicate >> Volume ID: 89903ca4-9817-4c6f-99de-5fb3e6fd10e7 >> Status: Started >> Snapshot Count: 0 >> Number of Bricks: 5 x 3 = 15 >> Transport-type: tcp >> Bricks: >> Brick1: glustera:/bricks/brick-a1/brick >> Brick2: glusterb:/bricks/brick-b1/brick >> Brick3: glusterc:/bricks/brick-c1/brick >> Brick4: glustera:/bricks/brick-a2/brick >> Brick5: glusterb:/bricks/brick-b2/brick >> Brick6: glusterc:/bricks/brick-c2/brick >> Brick7: glustera:/bricks/brick-a3/brick >> Brick8: glusterb:/bricks/brick-b3/brick >> Brick9: glusterc:/bricks/brick-c3/brick >> Brick10: glustera:/bricks/brick-a4/brick >> Brick11: glusterb:/bricks/brick-b4/brick >> Brick12: glusterc:/bricks/brick-c4/brick >> Brick13: glustera:/bricks/brick-a5/brick >> Brick14: glusterb:/bricks/brick-b5/brick >> Brick15: glusterc:/bricks/brick-c5/brick >> Options Reconfigured: >> changelog.changelog: on >> geo-replication.ignore-pid-check: on >> geo-replication.indexing: on >> storage.fips-mode-rchecksum: on >> transport.address-family: inet >> nfs.disable: on >> performance.client-io-threads: off >> cluster.enable-shared-storage: enable >> >> I'm attaching the audit log and sealert analysis from glustera (one >> of the 3 nodes consisting of the 'master' volume). >> >> >> Best Regards, >> Strahil Nikolov > >> > > ------- > > Community Meeting Calendar: > Schedule - > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC > Bridge: https://meet.google.com/cpu-eiue-hvk > > Gluster-devel mailing list > Gluster-devel(a)gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > > >

1 2

glibc-2.28-145.el8 with glibc-hwcaps support is coming to CentOS Stream 8
by Florian Weimer 08 Jan '21

08 Jan '21

We have rebased a large part of the glibc dynamic loader and the x86 CPU detection infrastructure to the current upstream version. These changes are going to land in CentOS Stream soon. These glibc changes mean that going forward, run-time selection of optimized shared object implementations is possible for all x86 processors (e.g., generic AVX2-optimized code that gets loaded on EPYC and Xeon Scalable processors). This is primarily being done to allow user application code to leverage this functionality. At this time, we are not adjusting or optimizing CentOS Stream packages themselves. Convenient developer support depends on GCC Toolset 11 and LLVM Toolset 12, which are yet to be released (even in their upstream versions). I’m working on some form of documentation on how to produce builds that are compatible with this feature for earlier toolchain versions. Other changes in the new glibc version include: * Backwards-compatible ld.so cache format changes to support glibc-hwcaps * --argv0 support in ld.so * DT_AUDIT support: The --audit option in binutils ld finally works as expected. * Enhanced --help output in ld.so: “/lib64/ld-linux-x86-64.so.2 --help” shows library search path information. * TLS allocation improvements: dlopen is able to load shared objects that use initial-exec TLS in more cases. There is a new glibc.rtld.optional_static_tls tunable to support exceptionally large initial-exec TLS usage after dlopen. * The CPU tunable namespace has been renamed from “glibc.tune” to “glibc.cpu”. If you have any questions, please feel free to ask on-list. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

3 5

TLS issues koji.mbox.centos.org
by Leon Fauster 07 Jan '21

07 Jan '21

On a C8 station: LANG=C curl -I https://koji.mbox.centos.org curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html this worked a couple of days ago. Any hints? -- Leon

3 5

Hyperscale SIG (Proposed)
by Rich Bowen 06 Jan '21

06 Jan '21

FYI: A Hyperscale SIG has been proposed, and will be considered in next week's board meeting. Details may be found here: https://wiki.centos.org/SpecialInterestGroup/Hyperscale --Rich

1 0

Why gnutls update was built for c8 but not c8s?
by Igor Raits 06 Jan '21

06 Jan '21

Hello, The https://git.centos.org/rpms/gnutls/c/3ec527a2c4ad3bad520b1004a50c075d94cc80… has been imported month ago, but there was just build for c8 from today and none for c8s. Is the process of building automated, or who is responsible for building the updates for c8s? Thanks in advance for your help!

1 0

should we expect to close CentOS Stream bugs as dups of RHEL?
by Ken Dreyer 06 Jan '21

06 Jan '21

Hi folks, This RHBZ tracks a problem in CentOS Stream: https://bugzilla.redhat.com/show_bug.cgi?id=1901449 Today someone closed it as a duplicate of RHEL 8.4: https://bugzilla.redhat.com/show_bug.cgi?id=1901449 When is it appropriate to track a bug against RHEL 8.4 vs CentOS Stream? What do we expect community members (inside and outside RH) to do in these cases? - Ken

11 14

Re: [CentOS-devel] Multiple Geo Rep issues due to SELINUX on CentOS 8.3
by Strahil Nikolov 05 Jan '21

05 Jan '21

Did anyone receive that e-mail ? Any hints ? Best Regards, Strahil Nikolov В 19:05 +0000 на 30.12.2020 (ср), Strahil Nikolov написа: > Hello All, > > I have been testing Geo Replication on Gluster v 8.3 ontop CentOS > 8.3. > It seems that everything works untill SELINUX is added to the > equasion. > > So far I have identified several issues on the Master Volume's nodes: > - /usr/lib/ld-linux-x86-64.so.2 has a different SELINUX Context than > the target that it is pointing to. For details check > https://bugzilla.redhat.com/show_bug.cgi?id=1911133 > > - SELINUX prevents /usr/bin/ssh from search access to > /var/lib/glusterd/geo-replication/secret.pem > > - SELinux is preventing /usr/bin/ssh from search access to .ssh > > - SELinux is preventing /usr/bin/ssh from search access to > /tmp/gsyncd-aux-ssh-tnwpw5tx/274d5d142b02f84644d658beaf86edae.sock > > Note: Using 'semanage fcontext' doesn't work due to the fact that > files created are inheriting the SELINUX context of the parent dir > and you need to restorecon after every file creation by the geo- > replication process. > > - SELinux is preventing /usr/bin/rsync from search access on > .gfid/00000000-0000-0000-0000-000000000001 > > Obviously, those needs fixing before anyone is able to use Geo- > Replication with SELINUX enabled on the "master" volume nodes. > > Should I open a bugzilla at bugzilla.redhat.com for the selinux > policy? > > Further details: > [root@glustera ~]# cat /etc/centos-release > CentOS Linux release 8.3.2011 > > [root@glustera ~]# rpm -qa | grep selinux | sort > libselinux-2.9-4.el8_3.x86_64 > libselinux-utils-2.9-4.el8_3.x86_64 > python3-libselinux-2.9-4.el8_3.x86_64 > rpm-plugin-selinux-4.14.3-4.el8.x86_64 > selinux-policy-3.14.3-54.el8.noarch > selinux-policy-devel-3.14.3-54.el8.noarch > selinux-policy-doc-3.14.3-54.el8.noarch > selinux-policy-targeted-3.14.3-54.el8.noarch > > [root@glustera ~]# rpm -qa | grep gluster | sort > centos-release-gluster8-1.0-1.el8.noarch > glusterfs-8.3-1.el8.x86_64 > glusterfs-cli-8.3-1.el8.x86_64 > glusterfs-client-xlators-8.3-1.el8.x86_64 > glusterfs-fuse-8.3-1.el8.x86_64 > glusterfs-geo-replication-8.3-1.el8.x86_64 > glusterfs-server-8.3-1.el8.x86_64 > libglusterd0-8.3-1.el8.x86_64 > libglusterfs0-8.3-1.el8.x86_64 > python3-gluster-8.3-1.el8.x86_64 > > > [root@glustera ~]# gluster volume info primary > > Volume Name: primary > Type: Distributed-Replicate > Volume ID: 89903ca4-9817-4c6f-99de-5fb3e6fd10e7 > Status: Started > Snapshot Count: 0 > Number of Bricks: 5 x 3 = 15 > Transport-type: tcp > Bricks: > Brick1: glustera:/bricks/brick-a1/brick > Brick2: glusterb:/bricks/brick-b1/brick > Brick3: glusterc:/bricks/brick-c1/brick > Brick4: glustera:/bricks/brick-a2/brick > Brick5: glusterb:/bricks/brick-b2/brick > Brick6: glusterc:/bricks/brick-c2/brick > Brick7: glustera:/bricks/brick-a3/brick > Brick8: glusterb:/bricks/brick-b3/brick > Brick9: glusterc:/bricks/brick-c3/brick > Brick10: glustera:/bricks/brick-a4/brick > Brick11: glusterb:/bricks/brick-b4/brick > Brick12: glusterc:/bricks/brick-c4/brick > Brick13: glustera:/bricks/brick-a5/brick > Brick14: glusterb:/bricks/brick-b5/brick > Brick15: glusterc:/bricks/brick-c5/brick > Options Reconfigured: > changelog.changelog: on > geo-replication.ignore-pid-check: on > geo-replication.indexing: on > storage.fips-mode-rchecksum: on > transport.address-family: inet > nfs.disable: on > performance.client-io-threads: off > cluster.enable-shared-storage: enable > > I'm attaching the audit log and sealert analysis from glustera (one > of the 3 nodes consisting of the 'master' volume). > > > Best Regards, > Strahil Nikolov >

1 0

RFC: CentOS 8 SIG
by redbaronbrowser 05 Jan '21

05 Jan '21

This is an introductory Request For Comment to purpose a community SIG to run CentOS 8 from Jan 1, 2022 to June 30, 2024. The responsiblity of the SIG members will be to maintain a repository of Stream 8 packages which have been accepted for publication into RHEL 8 The benefit to the CentOS community should be two fold: (1) Hopefully smooth the transistion from CentOS 8 to either Stream or Elephant (2) Provide a repository for Stream 8 members to perform a dnf downgrade as needed The purposed SIG is also seeking a CentOS Governing board member as a sponsor.

4 4

SIG representatives for January Board meeting
by Rich Bowen 05 Jan '21

05 Jan '21

In our attempt to increase the openness of the board meeting process, the board has asked for a phased approach, with SIG leaders attending the meetings, before we open them entirely to the project, so that we can assess whether we're still able to complete business in the allotted time with more attendees. We appreciate your patience. To that end, I ask that each SIG let me know who they would like to send as a representative to the January board meeting (Wednesday, January 13th, 21:00 UTC) so that they can be added to the invite list for the meeting. You may send this info to me, or to Thomas Oulevey, board secretary. Thanks.

1 0

what uses the messages on mqtt.git.centos.org?
by Ken Dreyer 05 Jan '21

05 Jan '21

Hi folks, I was reading about the MQTT broker at mqtt.git.centos.org? (https://wiki.centos.org/Sources) Does anything in CentOS infrastructure consume those messages (for example, to automatically build packages in Koji based on Pagure pushes)? I was also wondering about https://github.com/CentOS/ansible-role-kojihub/commits/master/files/plugins… , does any other tool consume those messages? - Ken

4 3

Re: [CentOS-devel] Vote of Confidence
by Mark Mielke 04 Jan '21

04 Jan '21

On Sat, Jan 2, 2021 at 8:50 AM orkcu via CentOS-devel <centos-devel(a)centos.org> wrote: > I don't think CentOS (or any other clone/rebuild) was ever a Bazaar, it can not be if the goal is to be a good clone/rebuild. > Since the very beginning the control was in a handful of people, very tight, and I remember one crisis when the founder didn't want (was unable/unavailable) to release control of dns domain, sign keys and few other main components that now you complain RedHat don't want to release I think you are right. The original intent, and the announcements and documentation for the project suggested something greater, but the reality turned out to be difficulty in delegation and scale. This is a common problem for volunteer or non-profit organizations. It doesn't matter if you have 3000 people willing to work on your project for free, if you can't effectively assign them work to do. It's worse if you can't even scale beyond a small number like "3", as these 3 eventually move on, and there is no succession plan, resulting in the project failing. For many of us - I think we had a naive trust that this would be figured out, and we would be invited when the time came to invite us. However, it didn't happen, and in 2014, Red Hat offered to take the reins. It's not that Red Hat set out to destroy the community - it is only that Red Hat has a conflict of interest, and it is really difficult for this conflict of interest to not eventually result in favouring certain self-interest outcomes over other non self-interest outcomes, and this is exactly what is happening in 2021. In effect, it was an inevitable conclusion. It was even predicted by several people in 2014. A similar thing is playing out in Rocky right now, however, there is a great deal of accumulated know-how, access to resources, and sober reflection on what went wrong leading up to 2014 and 2020. 3000+ people willing to work for free, but probably only 70 will be able to directly contribute, and initially the number will be a lot fewer as the initial setup takes place. This is why I say that Rocky is what CentOS should have been in 2014. We all know it wasn't. Now there is a chance to fix this. It could be a very good thing. > I don't like CentOS to evolve to Stream, I agree there is a need of a cheap RHEL's quality distribution, and I think all the arguments given so far at the end (in the very bottom) it is about cost (money), from the people complaining about the end because we are losing a very good distro that was free/gratis, from RedHat it is about moving the money to a direction that might provide better benefits for the company. > If RedHat would offer its RHEL with a minimum price (20? 50? 100?) for self support and then charge for a ticket a good amount of money ( like 200? 500?), that might work for a lot of people who are complaining now, I think we all understand that everyone need to have an income to feed its needs, even the small shops that are trying to save in (software) costs as much as possible. If Red Hat had agreed to this in 2016 and 2017 when I was asking for a reasonable solution to our problem, the company I work for would still be a Red Hat only shop. This was an opportunity missed then, and I believe it will be an opportunity missed when the new plans are announced. I don't believe the new subscription plans will be enough to make them an attractive option, and after the stumble with CentOS, even a good subscription plan that might meet some use cases will be frowned upon as a result of this debacle. > Bottom line, I don't think we ever had a community built OS in CentOS, we had people of the community assisting in testing and QA, but not even that was open to the public. I might be wrong but I think even before 2014 we had builders that were not (much) active in mailing list or IRC, and that is OK, each person have different strengths. I don't think you are wrong. Healthy communities need to prioritize delegation and scalability. It means investing specific effort in ensuring that people of different skills and capabilities can successfully contribute to the project. -- Mark Mielke <mark.mielke(a)gmail.com>

7 9

Package AppStreams variants in CentOS Stream?
by Leon Fauster 04 Jan '21

04 Jan '21

Hey, corresponding to CentOS 8 Stream: will ALL package/module versions for the different AppStreams be available? Some appstreams are only available as latest version (maven, nginx, perl, php). Wish you all some nice and healthy Christmas days, Leon

3 4

Vote of Confidence
by redbaronbrowser 03 Jan '21

03 Jan '21

This is an *UNOFFICIAL* non-binding vote to help provide an assessment of the state of the CentOS community and provoke further discussion. On November 11th (7 weeks ago), the CentOS governance board voted to reduce the life span of CentOS 8 from 10 years to 2 years. One board member, Karsten Wade, this is part of Red Hat effort to close the openness gap. He also explained that there is an elephant of which the community has only been shown parts with a flashlight. The CentOS governance page describe the governing board as being like a greenhouse. Why is the greenhouse so darken that it can hide an elephant such that over the last 7 weeks it has never been fully shown in the brightness of day? Part of the problem is the governance board is packed with people that are not active members of the CentOS community and have made no effort to explain the board's actions to the community. Please vote on each of the following items with +1 (in favor), 0 (sustain), -1 (reject). If you vote to reject an item, please explain why. Should Brian Exelbierd be asked to resign from the CentOS governance board? Should Mike McLean be asked to resign from the CentOS governance board? Should Carl Trieloff be asked to resign from the CentOS governance board? Should Rich Bowen be asked to resign from the CentOS governance board? Is obfuscating the CentOS kernel patches consistent with Red Hat attempting to close the openness gap? Are you likely to ever assist with Stream if the CentOS 8 End of Life is December 31, 2021? Would you be more likely to help with Stream if the CentOS 8 End of Life was set to June 30, 2024? Please keep in mind this vote is *UNOFFICIAL* and only for the purpose of promoting discussion. Template for responding: BE resign: [+1|0|-1] [-1 reason] MM resign: [+1|0|-1] [-1 reason] CT resign: [+1|0|-1] [-1 reason] RB resign: [+1|0|-1] [-1 reason] Obfuscation = Openness: [+1|0|-1] [-1 reason] EOL 2021: [+1|0|-1] [-1 reason] EOL 2024: [+1|0|-1] [-1 reason]

7 10

rare but repeating system crash in C7
by Fred 02 Jan '21

02 Jan '21

Hi all, I'm hoping someone can help me figure this out. every now and then (less than monthly, maybe every 2-4 months, or so, I'll walk up to my C7 box (my home PC) in the morning, wiggle the mouse to wake up the screen, and after a second or so, instead of a live screen, the keyboard shift-lock and scroll-lock keys light up. if I wait a few (tens of) second(s) I find it is rebooting, as the BIOS splash screen appears. it boots normally and comes up with everything apparently working fine. Note that I tend to leave myself logged in 24/7/365 since there's nobody here except my wife and myself, and she has her own Linux box. as it happened again this morning, I grabbed some lines from /var/log/messages that show the last few minutes before it rebooted and the first 3 or four statements as it began to reboot: Jan 2 08:50:12 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cb10 trb-start 00000000a9f2cb20 trb-end 00000000a9f2cb20 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 08:50:13 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:50:13 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164858d0 trb-start 00000000164858e0 trb-end 00000000164858e0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 08:51:12 fcshome dbus[1192]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Jan 2 08:51:13 fcshome dbus[1192]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Jan 2 08:51:14 fcshome setroubleshoot: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock. For complete SELinux messages run: sealert -l e4620dcc-6cdc-460d-a8a4-db9ce9624646 Jan 2 08:51:14 fcshome python: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that smbd should be allowed read access on the cups.sock sock_file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'lpqd' --raw | audit2allow -M my-lpqd#012# semodule -i my-lpqd.pp#012 Jan 2 08:55:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:55:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485d20 trb-start 0000000016485d30 trb-end 0000000016485d30 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 08:55:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:55:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cae0 trb-start 00000000a9f2caf0 trb-end 00000000a9f2caf0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 08:58:00 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:58:00 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c530 trb-start 00000000a9f2c540 trb-end 00000000a9f2c540 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 08:59:51 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:59:51 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c340 trb-start 00000000a9f2c350 trb-end 00000000a9f2c350 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 08:59:51 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 08:59:51 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cfb0 trb-start 00000000a9f2cfc0 trb-end 00000000a9f2cfc0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:00:02 fcshome systemd: Created slice User Slice of root. Jan 2 09:00:02 fcshome systemd: Started Session 7364 of user root. Jan 2 09:00:02 fcshome systemd: Removed slice User Slice of root. Jan 2 09:00:06 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:00:06 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cd20 trb-start 00000000a9f2cd30 trb-end 00000000a9f2cd30 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485400 trb-start 0000000016485410 trb-end 0000000016485410 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cbc0 trb-start 00000000a9f2cbd0 trb-end 00000000a9f2cbd0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:00:59 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485c00 trb-start 0000000016485c10 trb-end 0000000016485c10 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:01:01 fcshome systemd: Created slice User Slice of root. Jan 2 09:01:01 fcshome systemd: Started Session 7365 of user root. Jan 2 09:01:01 fcshome systemd: Removed slice User Slice of root. Jan 2 09:03:45 fcshome dbus[1192]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Jan 2 09:03:46 fcshome dbus[1192]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Jan 2 09:03:47 fcshome setroubleshoot: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock. For complete SELinux messages run: sealert -l e4620dcc-6cdc-460d-a8a4-db9ce9624646 Jan 2 09:03:47 fcshome python: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that smbd should be allowed read access on the cups.sock sock_file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'lpqd' --raw | audit2allow -M my-lpqd#012# semodule -i my-lpqd.pp#012 Jan 2 09:04:31 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:04:31 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2ca60 trb-start 00000000a9f2ca70 trb-end 00000000a9f2ca70 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:04:58 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:04:58 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cd70 trb-start 00000000a9f2cd80 trb-end 00000000a9f2cd80 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:04:59 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:04:59 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485b30 trb-start 0000000016485b40 trb-end 0000000016485b40 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:04:59 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:04:59 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164856c0 trb-start 00000000164856d0 trb-end 00000000164856d0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:05:03 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:05:03 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164851b0 trb-start 00000000164851c0 trb-end 00000000164851c0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:10:01 fcshome systemd: Created slice User Slice of root. Jan 2 09:10:01 fcshome systemd: Started Session 7366 of user root. Jan 2 09:10:01 fcshome systemd: Removed slice User Slice of root. Jan 2 09:10:30 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:10:30 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164854c0 trb-start 00000000164854d0 trb-end 00000000164854d0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:10:30 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:10:30 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485eb0 trb-start 0000000016485ec0 trb-end 0000000016485ec0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:11:55 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:11:55 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164852c0 trb-start 00000000164852d0 trb-end 00000000164852d0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:11:55 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:11:55 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485b70 trb-start 0000000016485b80 trb-end 0000000016485b80 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cbb0 trb-start 00000000a9f2cbc0 trb-end 00000000a9f2cbc0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164858d0 trb-start 00000000164858e0 trb-end 00000000164858e0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:11:56 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485a00 trb-start 0000000016485a10 trb-end 0000000016485a10 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:14:46 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:14:46 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485450 trb-start 0000000016485460 trb-end 0000000016485460 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:09 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:09 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c170 trb-start 00000000a9f2c180 trb-end 00000000a9f2c180 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:09 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:09 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c7a0 trb-start 00000000a9f2c7b0 trb-end 00000000a9f2c7b0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:10 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:10 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485560 trb-start 0000000016485570 trb-end 0000000016485570 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:21 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:21 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485b90 trb-start 0000000016485ba0 trb-end 0000000016485ba0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:21 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:21 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cf90 trb-start 00000000a9f2cfa0 trb-end 00000000a9f2cfa0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:22 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:22 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c9e0 trb-start 00000000a9f2c9f0 trb-end 00000000a9f2c9f0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:22 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:22 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485660 trb-start 0000000016485670 trb-end 0000000016485670 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:23 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:23 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485330 trb-start 0000000016485340 trb-end 0000000016485340 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:24 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:24 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485500 trb-start 0000000016485510 trb-end 0000000016485510 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:25 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:25 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c400 trb-start 00000000a9f2c410 trb-end 00000000a9f2c410 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:25 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:25 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000164851c0 trb-start 00000000164851d0 trb-end 00000000164851d0 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485e30 trb-start 0000000016485e40 trb-end 0000000016485e40 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cbf0 trb-start 00000000a9f2cc00 trb-end 00000000a9f2cc00 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:26 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c000 trb-start 00000000a9f2c010 trb-end 00000000a9f2c010 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:27 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:27 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2ce50 trb-start 00000000a9f2ce60 trb-end 00000000a9f2ce60 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:31 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:31 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c4e0 trb-start 00000000a9f2c4f0 trb-end 00000000a9f2c4f0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:15:47 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:15:47 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cbb0 trb-start 00000000a9f2cbc0 trb-end 00000000a9f2cbc0 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:16:15 fcshome dbus[1192]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Jan 2 09:16:16 fcshome dbus[1192]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Jan 2 09:16:17 fcshome setroubleshoot: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock. For complete SELinux messages run: sealert -l e4620dcc-6cdc-460d-a8a4-db9ce9624646 Jan 2 09:16:17 fcshome python: SELinux is preventing /usr/sbin/smbd from read access on the sock_file cups.sock.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that smbd should be allowed read access on the cups.sock sock_file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'lpqd' --raw | audit2allow -M my-lpqd#012# semodule -i my-lpqd.pp#012 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 0000000016485b50 trb-start 0000000016485b60 trb-end 0000000016485b60 seg-start 0000000016485000 seg-end 0000000016485ff0 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c050 trb-start 00000000a9f2c060 trb-end 00000000a9f2c060 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c680 trb-start 00000000a9f2c690 trb-end 00000000a9f2c690 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:11 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2cb70 trb-start 00000000a9f2cb80 trb-end 00000000a9f2cb80 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:17:21 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:21 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2c520 trb-start 00000000a9f2c530 trb-end 00000000a9f2c530 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:17:21 fcshome kernel: xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 13 Jan 2 09:17:21 fcshome kernel: xhci_hcd 0000:03:00.0: Looking for event-dma 00000000a9f2ca10 trb-start 00000000a9f2ca20 trb-end 00000000a9f2ca20 seg-start 00000000a9f2c000 seg-end 00000000a9f2cff0 Jan 2 09:20:11 fcshome kernel: Initializing cgroup subsys cpuset Jan 2 09:20:11 fcshome kernel: Initializing cgroup subsys cpu Jan 2 09:20:11 fcshome kernel: Initializing cgroup subsys cpuacct Jan 2 09:20:11 fcshome kernel: Linux version 3.10.0-1160.6.1.el7.x86_64 The last four events are the start of reboot and everything above is leading up to the crash. I note that there was a selinux event early in this list of events, but I see those frequently and they normally don't cause a crash. if I scroll upward from this list, I find more of the same above what is shown here. The selinux event seems to be related to a SMB mount. since I have a Synology box on the LAN, and it stays mounted nearly all the time, I suspect the selinux event has something to do with that, but I have no idea why it would cause a crash once every few months. Is that selinux event something I need to fix? I'm further guessing that "xhci_hcd" has something to do with USB, am I right? If so I don't know what it would be... Clues would be greatly appreciated! Thanks in advance! Fred

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel January 2021