Discuss December 2020

discuss@lists.centos.org

157 participants
95 discussions

Oracle Linux 8 - short experiment with install and basic setup of Mate Desktop
by Frank Cox 13 Dec '20

13 Dec '20

So after reading other folks' opinions of an Oracle Linux 8 (thanks again, Nicolas!) trial installation, I decided to crank up a Virtual Box session and try an install myself. As others have stated, what you get when you install OL8 is identical in every way to what you see when installing Centos 8; literally the only difference is the logo and the default desktop background. There are no demands for registration or anything else when you install OL8. It's exactly the same experience as installing Centos 8. Since I use Mate on my computers (installed from https://copr.fedorainfracloud.org/coprs/stenstorp/MATE/ ) I immediately decided to see if I can get that going. I ran into two small issues, both easily dealt with. First, the PowerTools repo doesn't seem to exist under that name on OL8. It's called ol8_codeready_builder, for some reason. "dnf-config-manager --set-enabled ol8_codeready_builder" works fine and gets us where we need to be. A slightly more serious issue is that the oracle-epel, found through the rpm named oracle-epel-release-el8, appears to be less complete that the original Fedora epel found at https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm. Mate requires ImageMagick as a dependency for caja-image-converter and if you have oracle-epel installed it can't find ImageMagick. The solution (at least the solution that I used, which worked) is just to delete the oracle-epel-release-el8 rpm and install epel-release-latest-8 rpm instead. Then the Mate desktop can be installed on OL8 from the copr rpms listed above. Ultimately, the take-away here seems to be that if you decide to use OL8 instead of Centos 8 you'll be better advised to stick with "real" epel and not the oracle epel since there appears to be at least some stuff missing on the oracle epel. After I jumped through those minor hoops, what I ended up with was an Oracle Linux 8 installation with a Mate desktop and literally everything looks and works identical to what I already have with Centos 8. (An issue that I haven't seen anyone address yet is this. It's my understanding that epel builds their stuff on the current RHEL. Therefore the upcoming Centos Stream might get out-of-sync with whatever epel is building on at any given point in time.) -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

4 3

Re: [CentOS] CentOS Digest, Vol 191, Issue 12
by DBC-MMILLER 12 Dec '20

12 Dec '20

Sent from my iPhone > On Dec 12, 2020, at 07:00, centos-request(a)centos.org wrote: > > Message: 51 > Date: Fri, 11 Dec 2020 13:15:43 -0800 > From: Lists <lists(a)benjamindsmith.com> > To: CentOS mailing list <centos(a)centos.org> > Subject: [CentOS] Baffled by firewall rules with a Qemu VM, CentOS 7 > Message-ID: <2155552.iZASKD2KPV(a)tesla.effortlessis.com> > Content-Type: text/plain; charset="us-ascii" > > I've understood iptables well enough for a long, long time, and although I > think firewall-cmd is a poor replacement for iptables, I've always been able to > "get it to work" by comparing output with iptables -L or iptables -S and using > a direct-rule or two. > > And this time, I'm just baffled. > > I have a qemu VM running on a host. Postgresql runs on the host, and I'm > trying to connect to the Postgresql server on the host from the VM. > > VM: loco > Host: tesla > > 1) If I turn OFF the firewall on tesla, I have no trouble connecting from loco. > tesla: systemctl stop firewalld > loco: psql -U postgres -h 192.168.122.1 # yay! connection! > > 2) If I turn ON the firewall on tesla, I can't connect NO MATTER WHAT I DO > tesla: systemctl start firewalld; > loco: psql -U postgres -h 192.168.122.1 # Connection refused > > > I have tried: > tesla# firewall-cmd --zone=public --add-port=5432/tcp > tesla# firewall-cmd --add-service=postgresql > tesla# firewall-cmd --set-default-zone=trusted; > tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWI 0 -j ACCEPT > tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWO 0 -j ACCEPT > tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWX 0 -j ACCEPT > > ... and many more things. Literally stumped for a few hours. The output of > iptables indicates that I've wildcarded everything: > > tesla# iptables -S > -P INPUT ACCEPT > -P FORWARD ACCEPT > -P OUTPUT ACCEPT > -N LIBVIRT_FWI > -N LIBVIRT_FWO > -N LIBVIRT_FWX > -N LIBVIRT_INP > -N LIBVIRT_OUT > -A INPUT -j LIBVIRT_INP > -A FORWARD -j LIBVIRT_FWX > -A FORWARD -j LIBVIRT_FWI > -A FORWARD -j LIBVIRT_FWO > -A OUTPUT -j LIBVIRT_OUT > -A LIBVIRT_FWI -d 192.168.122.0/24 -j ACCEPT > -A LIBVIRT_FWI -i virbr0 -j ACCEPT > -A LIBVIRT_FWI -j ACCEPT > -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate > RELATED,ESTABLISHED -j ACCEPT > -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable > -A LIBVIRT_FWO -i virbr0 -j ACCEPT > -A LIBVIRT_FWO -j ACCEPT > -A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT > -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable > -A LIBVIRT_FWX -j ACCEPT > -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT > -A LIBVIRT_INP -j ACCEPT > -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT > -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT > -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT > -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT > -A LIBVIRT_OUT -j ACCEPT > -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT > -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT > -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT > -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT > > There are no REJECT rules not preceded by a wildcard ACCEPT, but I can't > connect with this config. But simply stopping host (tesla) firewalld allows me > to connect just fine. > > Any ideas? >

1 0

Baffled by firewall rules with a Qemu VM, CentOS 7
by Lists 12 Dec '20

12 Dec '20

I've understood iptables well enough for a long, long time, and although I think firewall-cmd is a poor replacement for iptables, I've always been able to "get it to work" by comparing output with iptables -L or iptables -S and using a direct-rule or two. And this time, I'm just baffled. I have a qemu VM running on a host. Postgresql runs on the host, and I'm trying to connect to the Postgresql server on the host from the VM. VM: loco Host: tesla 1) If I turn OFF the firewall on tesla, I have no trouble connecting from loco. tesla: systemctl stop firewalld loco: psql -U postgres -h 192.168.122.1 # yay! connection! 2) If I turn ON the firewall on tesla, I can't connect NO MATTER WHAT I DO tesla: systemctl start firewalld; loco: psql -U postgres -h 192.168.122.1 # Connection refused I have tried: tesla# firewall-cmd --zone=public --add-port=5432/tcp tesla# firewall-cmd --add-service=postgresql tesla# firewall-cmd --set-default-zone=trusted; tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWI 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWO 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWX 0 -j ACCEPT ... and many more things. Literally stumped for a few hours. The output of iptables indicates that I've wildcarded everything: tesla# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N LIBVIRT_FWI -N LIBVIRT_FWO -N LIBVIRT_FWX -N LIBVIRT_INP -N LIBVIRT_OUT -A INPUT -j LIBVIRT_INP -A FORWARD -j LIBVIRT_FWX -A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.122.0/24 -j ACCEPT -A LIBVIRT_FWI -i virbr0 -j ACCEPT -A LIBVIRT_FWI -j ACCEPT -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -i virbr0 -j ACCEPT -A LIBVIRT_FWO -j ACCEPT -A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWX -j ACCEPT -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT -A LIBVIRT_INP -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_OUT -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT There are no REJECT rules not preceded by a wildcard ACCEPT, but I can't connect with this config. But simply stopping host (tesla) firewalld allows me to connect just fine. Any ideas?

3 3

Debug information packages for 8.3 missing?
by Oliver Freyermuth 12 Dec '20

12 Dec '20

Dear all, after the upgrade from 8.2 to 8.3 one of the applications we use has unclear Kerberos authentication issues. I was going to diagnose these and tried: yum debuginfo-install krb5-libs However, I get: Could not find debuginfo package for the following installed packages: krb5-libs-1.18.2-5.el8.x86_64 Could not find debugsource package for the following installed packages: krb5-libs-1.18.2-5.el8.x86_64 Checking on http://debuginfo.centos.org/8/x86_64/Packages/ , I do indeed not find these packages, also glibc and other debug info packages are missing. Are they still being uploaded, or am I using a wrong repository? Thanks and cheers, Oliver

2 4

Question on nmcli CentOS 8
by Jerry Geis 11 Dec '20

11 Dec '20

I am trying to modify the current eth0 with nmcli I ran this: nmcli con mod eth0 ipv4.addr 192.168.1.15/22 gw4 192.168.1.1 ipv4.dns 192.168.1.14 and now nmcli shows (two ipv4) addresses. inet4 192.168.1.15/22 inet4 192.168.2.212/22 I think the original connection was DHCP... the 2.212 item listed. So I want to change the original DHCP to a static network - how do I do that? I only want the one address not two. So now I need to "remove" both or all and add the 1 I want as static ? how do I do that? Thanks, Jerry

3 2

Re: [CentOS] Moving to CentOS 8 Stream
by Kienker, Fred 11 Dec '20

11 Dec '20

"It takes years to build a reputation and seconds to destroy it." -- Business 101 class Best regards, Fred

6 6

8-stream dnf overly verbose
by Pete Biggs 11 Dec '20

11 Dec '20

In moving a test machine from 8.3 to 8-stream the main thing I've noticed is that dnf has become very verbose. It's as if someone has turned on the -v permanently. I've tried using '-q' (it says nothing then) and I've tried adjusting the debuglevel, but nothing seems to affect it. I get things like this: Downloading: http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=BaseOS&infr… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/r… 0 B --:-- ETA Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/c… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/b… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/6… CentOS Stream 8 - BaseOS 13 MB/s | 2.3 M For every repo when there's nothing cached. It never used to do this. How can I turn off the "Downloading:" messages? P.

7 10

CentOS 8 Stream: The Good, The Bad, The Ugly
by Joshua Kramer 11 Dec '20

11 Dec '20

Hello All- After reading and digesting a ton of community chatter about the recent CentOS announcement I've come to the conclusion that there's a lot of good about this, but there are also a lot of concerns that are being ignored. And nobody so far has stared directly into the eyes of the elephant in the room. So here goes. The Good: From a technical perspective- both in the sense of "getting newer software" and "technical community being more involved in bugfixes, etc"- having *a version* of CentOS called "AppStream" is fantastic. The various RedHat and CentOS folks who have been extolling these virtues in blog posts and twitter feeds are right-on. But from responses I've seen, it appears to me that they think that these virtues are enough to completely gloss over the complete and utter clusterfrackas they've caused. The Bad: No point releases. There is POSITIVELY NO* REASON that they can't have AppSream and still do point releases. Brand new stuff would go into AppStream, at some point they do a point release of RHEL, then follow the normal CentOS procedure to spin a CentOS build of that point release. This is already a tried and true process. It will cost RedHat all of what, low five digits (if that) in developer salary to do this. Heck I'm sure some volunteers would step up to use the existing infrastructure if RedHat didn't want to spend any paid developer time on this. The Ugly: I denoted "NO* REASON" above because there actually *are* reasons that we are not privy to. https://twitter.com/JoshuaPKr/status/1336744681716244480 Since RedHat is not being transparent with this, we are forced to speculate and remain bewildered at why they would make a decision that is going to cost them so much in the long run. The most common (and most likely) theory is that some MBA somewhere in middle management saw all of this CentOS being used in production environments (and otherwise downloaded for free), and had the idea that if CentOS had its head cut off people would just buy RHEL subscriptions. That may happen in a few cases, but for the most part, that is NOT what is going to happen. By handling the CentOS situation in this way, RedHat has branded itself as a company that acts in bad faith. If a company acts in bad faith towards a community where non-monetary value is exchanged, WHY would you trust that company to hold up its obligations for contracts that are actually paid? People are going to do whatever they can to get away from RedHat. Debian, Ubuntu, SuSE will all benefit from this. Even in cases where non-profits and other similar clients "contact RedHat about options because Stream won't meet their needs"- why would such entities have ANY reason to trust anything that RedHat says to them? There have been hundreds of other messages that describe exactly what RedHat loses in this deal so I won't go into that here. But branding oneself as a "bad faith actor" is usually a terrible way to try to pick up a little bit of subscription revenue. In the end it's going to be a losing scenario. This is an absolutely UNMITIGATED DISASTER from a marketing and community goodwill standpoint. It can, however, be mitigated if RedHat backtracks, admits their mistake, and affirmatively commits to support future CentOS point releases. I'll be interested to see how this turns out. --JK

12 14

Have lost access to ZFS pools with latest CentOS 8 kernels
by Robert G. (Doc) Savage 11 Dec '20

11 Dec '20

With the release of the vmlinuz-4.18.0-240.x and vmlinuz- 4.18.0.193.19.x kernels, ZoL cannot connect with a ZFS pool. I'm not 100% sure, but I believe the last CentOS 8 kernel to work with ZFS 0.8.5 was 4.18.0.6.x. Obviously CentOS does not support ZFS, so this means the ZoL folks must find and fix the problem. Otherwise, I think Fedora 33 is the only choice we have for hosting ZFS. --Doc Savage Fairview Heights, IL

2 1

CentOS Stream from bottom works, what is this?
by Walter H. 10 Dec '20

10 Dec '20

Hello, I just tried installing a VM from the stream ISO and it worked; the only thing I would like to have changed as a default config is GRUB_CMDLINE_LINUX=".... net.ifnames=0 ..." the reason, I find eth0, eth1, eth2 easier to use than cryptic names like ens33 or ens0p3 or so; Walter p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?

16 35

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss December 2020