devel

devel@lists.centos.org

1 participants
4605 discussions

[TripleO] [CloudSIG] Errors on Recent TripleO Deployment - Ussuri and Victoria
by Nathan McGarvey 12 Feb '21

12 Feb '21

To anyone on the cloud SIG team, specifically dealing with a TripleO deployment: As of this week, a stock install of the "Ussuri" and "Victoria" releases of TripleO undercloud fail due to internal puppet module issues as follows: Note that at least Ussuri worked recently (in the last few weeks): Ussuri: "puppet-user: Error: no parameter named 'key_size' (file: /etc/puppet/modules/tripleo/manifests/certmonger/haproxy.pp, line: 102) on Certmonger_certificate[haproxy-external-cert] (file: /etc/puppet/modules/tripleo/manifests/certmonger/haproxy.pp, line: 102) on node centos8-testing.localdomain" It seams that this may have been fixed in https://github.com/openstack/puppet-tripleo/commit/963b47338008f16039a815b0… Victoria: ... "Could not find class ::neutron::plugins::ml2::ovs_driver" ... I'm not sure if this is related/fixed, but it may be: https://review.opendev.org/c/openstack/puppet-neutron/+/757803 Steps to reproduce: Base install of CentOS8.3 Minimal (VM and baremetal behave the same) install centos-release-openstack-<version> [Optional?] dnf module disable container-tools:rhel8 and dnf module enable container-tools:2.0 dnf install python3-tripleoclient ceph-ansible openstack-selinux dnf distro-sync add the "stack" user and such, add sudo rules, etc. [copy undercloud.conf.sample to undercloud.conf] NOTE: minor customization of IPs in my test environment. [Optional] generate the container parameters yaml openstack undercloud install --verbose Has anybody else experienced this? Any ideas on how to rectify the issue or prevent this from happening in the future. This seems like a pretty big breakage since it is effectively a no-go for any new install at least. (I'd assume the overcloud install will break in the same manner since it should be using the same repos and containers.) Please pardon my ignorance if I'm missing something obvious since I'm a new poster to this thread. Thanks, -Nathan

2 2

Path forward for EL8 build roots in OBS / Copr?
by Anthony Alba 11 Feb '21

11 Feb '21

With the retirement of CentOS Linux 8, what is the intended path forward for unofficial user repositories like Fedora Copr or OBS (OpenSuse Build service)? Are they supposed to move to RHEL 8 or CentOS Stream? For example, Copr has "Epel for CentOS 8" build root for unofficial RPMs for EL8 systems. OBS has CentOS 6-8, but only RHEL 5-7. Cheers Anthony

1 0

CentOS Stream Container images available on quay.io
by Brian Stinson 11 Feb '21

11 Feb '21

Hi folks, CentOS Stream container images are now readily available! podman pull quay.io/centos/centos:stream OR podman pull quay.io/centos/centos:stream8 ## Tags· We expect the 'stream' tag to automatically move forward to new Streams as they come on board. This means when CentOS Stream 9 becomes the Live Stream, quay.io/centos/centos:stream will have 9 based content. The 'stream8' tag can be used while Stream 8 is Live, and during the overlap period between Stream 8 and Stream 9. A 'stream9' tag will be created at the appropriate time to serve the same purpose. You can browse through all of the tags for the CentOS repository here: https://quay.io/repository/centos/centos?tab=tags ## Next Steps - We are still in discussions on how to push these properly to Dockerhub. Since CentOS is an Official Image, there are some extra requirements here that we're working through. If you have questions you can find us on the centos-devel mailing list (centos-devel(a)centos.org) or in #centos-stream on Freenode Cheers! -- Brian Stinson On behalf of the CentOS Stream Team

1 0

False statement about insecurity made on Wiki
by Chris Drake 11 Feb '21

11 Feb '21

Your Wkii page here: https://wiki.centos.org/FAQ/CentOSStream#Where_is_the_source_code.3F After discussion in which it was confirmed that TLS *could* be implemented "but traditionally we have not done so", was just updated by Manuel Wolfshant with the following lie:- *Note: downloads are hosted on a mirror network, where we cannot mandate that every mirror node runs SSL/TLS, hence using regular http and not enforcing https* False statements are disgusting to begin with, but ones that attempt to excuse the lazy decision to put all CentOS customers at risk are totally unacceptable. LE is free and easy to use and setup - it's a no-brainer to fix this problem, assuming someone isn't getting a kickback from some 3-letter-agency to leave this exploitable security hole open ?

9 14

Re: [CentOS-devel] 7.9.2009 vault population
by Neale Ferguson 11 Feb '21

11 Feb '21

Thanks for the clarification. That makes sense. -------- Original message -------- From: Fabian Arrotin <arrfab(a)centos.org> Date: 2/11/21 20:43 (GMT+10:00) To: centos-devel(a)centos.org Subject: Re: [CentOS-devel] 7.9.2009 vault population From a SIG "sign and push" perspective, there is no 7.8.2003 nor 7.9.2009 as it's always pushing only to Major (so 7 in this case) and it seems that source packages you mentioned are listed there ? => https://vault.centos.org/centos/7/sclo/Source/rh/ -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel

1 0

[NFVSIG] Updated openvswitch and ovn
by Alfredo Moralejo Alonso 11 Feb '21

11 Feb '21

Hi, Note that openvswitch and ovn 2.13, ovn-2.11 and openvswitch-selinux-extra-policy have been updated in the NFV SIG repositories with latest FDP 21.A content: https://access.redhat.com/errata/RHBA-2021:0402 https://access.redhat.com/errata/RHBA-2021:0403 https://access.redhat.com/errata/RHBA-2021:0404 https://access.redhat.com/errata/RHBA-2021:0405 Please, let us know if you find any issue with it. On behalf or NFV SIG

1 0

7.9.2009 vault population
by Neale Ferguson 11 Feb '21

11 Feb '21

Is there a schedule for when the remaining SIGs will populate vault.centos.org? SCLO is a notable missing piece Neale

2 4

NFV SIG meeting minutes 10 February 2021
by Thomas F Herbert 10 Feb '21

10 Feb '21

======================== #centos-meeting: NFV SIG ======================== Meeting started by tfherbert at 15:01:51 UTC. The full logs are available at https://www.centos.org/minutes/2021/February/centos-meeting.2021-02-10-15.0… . Meeting summary --------------- * LINK: https://hackmd.io/oRe_HVJiTteDI4H332ApMw (amoralej, 15:02:08) * FDP 21.A status (tfherbert, 15:03:01) * Meetings agenda: https://hackmd.io/oRe_HVJiTteDI4H332ApMw (tfherbert, 15:03:43) * ovs and ovn 2.13 have been rebuilt for CentOS 8 and are being tested (amoralej, 15:04:01) * dholler: ovn 2.11 is rebuilt and it is in testing. (tfherbert, 15:05:03) * 2.11 includes selinux package (tfherbert, 15:05:31) * selinux is in testing too (tfherbert, 15:05:57) * fdp 2.13 to be pushed to release in a few days. (tfherbert, 15:07:01) * FDP release 2.11 and 2.13 to be released near simultaneously in a few days. (tfherbert, 15:09:57) * FDP 21.A status (tfherbert, 15:10:51) * 21.A completed. (tfherbert, 15:11:12) * CentOS 8 STream status (tfherbert, 15:11:25) * tags are available for C8 Stream, https://pagure.io/centos-infra/issue/220 (tfherbert, 15:12:21) * C8 stream plan: 2.14 and 2.15 and updates to 2.11 and 2.13 will be coordinated with FDP. The exact plan and release dates are TBD for now. (tfherbert, 15:28:07) * Automation and CI proposal. (tfherbert, 15:30:15) * LINK: https://review.rdoproject.org/r/#/c/31871/ (amoralej, 15:33:17) * Proposal for CI testing of NFV packages, currently FDP packages: OVS and OVN (tfherbert, 15:38:23) * Proposal is to use RDO CI currently used in Cloud Sig and OpenStack. Please see https://review.rdoproject.org/r/#/c/31871/ for info on RDO CI for more info. (tfherbert, 15:40:04) * Meeting about CI proposal February 12 11:00 Eastern US time: Please contact Alfredo Moralejo Alonso for more info, amoralej(a)redhat.com (tfherbert, 15:44:42) * Anything other topics for NFV SIG? (tfherbert, 15:47:58) * question about NFV: NFV is Network Function Virtualization. (tfherbert, 15:50:16) * FDP is "Fast Data Path" (tfherbert, 15:50:39) * ovn is Open Virtual Network (amoralej, 15:51:26) Meeting ended at 15:52:00 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * amoralej (93) * tfherbert (55) * dholler (12) * smooge (3) * centbot (2) * ykarel (2) * Arrfab (1) -- *Thomas F Herbert* CTO Office Networking Group Networking Group *Red Hat* he/him/his

1 0

More dojos! (FOSDEM Dojo and future plans)
by Rich Bowen 10 Feb '21

10 Feb '21

For those of you who missed it, here's a recap of last week's CentOS Dojo at FOSDEM - https://blog.centos.org/2021/02/centos-dojo-fosdem-2021/ Given the adversarial and occasionally toxic discussions we've seen on this list over the past 2 months, I was concerned that we'd have more of the same at the Dojo, but it seems that seeing people's faces tempered the discussion. People continued to ask the hard questions, but without the hostility that we've seen recently. As a result, I'm considering running several more of these over the coming year, at least until we get back to doing some in-person events, and probably even after that. Last week's event was optimized for a European-centric time zone. The next one will probably be more centered around North American time zones, and will probably happen some time around May. If you are interested in helping put the event together, or have ideas about what content you'd like to see, or if you yourself want to present something, please let us know. Based on early feedback on the post-event survey, people want to hear more about: * CentOS Stream 9 * more non-red hat use cases * koji (and similar ways of managing smaller scale automated rpm builds) * creating your own module/stream in personal repo, freeipa, keycloak * NextGen: RHEL Sources Home / GitLab / Stream9 And I would echo the "non-Red Hat" item here. While it makes sense that our content has strong Red Hat participation, I'm always doubly-pleased when we get presentations from outside of Red Hat.

7 8

Source code missing, and insecure delivery pages linked
by Chris Drake 10 Feb '21

10 Feb '21

1. Your info page here: https://wiki.centos.org/FAQ/CentOSStream#Where_is_the_source_code.3F links to an insecure download resource: http://mirror.centos.org/centos/8-stream/ 2. You are not running a secure server: https://mirror.centos.org/centos/8-stream/ => connection times out *. Hopefully you understand the implications of the above - if not, run a build and take a look at the number of warnings related to unsigned code that your systems ignore. Better still - fix your systems so they always hard-fails on everything unsigned it encounters. It only takes one single unsigned mistake in any of your packages to expose all users to compromise when you're not using secure servers. Insecure servers in 2021 are completely unnecessary. 3. Source code is still missing. The folder structure exists, but none of the files are in there. Some new examples https://git.centos.org/rpms/sendmail/tree (no source) https://git.centos.org/rpms/sendmail/archive/imports/c8s/sendmail-8.15.2-34… (linked from git - 404) https://vault.centos.org/centos/8-stream/AppStream/Source/SPackages/ (empty) https://composes.centos.org/CentOS-Stream-8-20210108.n.2/compose/BaseOS/sou… (incomplete) # yumdownloader --source sendmail Last metadata expiration check: 2:09:27 ago on Mon 08 Feb 2021 09:45:31 PM GMT. No package sendmail-8.15.2-34.el8.src available. Exiting due to strict setting. Error: No package sendmail-8.15.2-34.el8.src available. Might I suggest you ask someone in the build team to fix or write whatever script is needed to make "yumdownloader" work? Obviously, since they're building stuff, *they* know where the source code **really** is - so it would only take 5 or 10 minutes to glue your existing tools (like yumdownloader) into whatever new location someone seems to have dreamed up for the actual source. Spending the few minutes to fix what every administrator already knows around source packaging/distro systems is a far better idea than making them all learn entirely new things (which will probably change a few more times before everyone's happy anyhow) All the above carry security implications - we really need to know what source was used to build our products, and we really need to be able to download binaries from properly secure locations (preferably all with working signatures, but that's a whole other problem, so TLS distro endpoints is at least an interim mitigation).

11 18

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel