Discuss April 2020

discuss@lists.centos.org

90 participants
69 discussions

Network Interfaces Issue
by Jared Jacob 28 Apr '20

28 Apr '20

I have two network interfaces configured on a server. I would like both of them to be configured to start on boot, but when I enable the second interface to start on boot I do not have access to the first network interface. The second interface is a private network and does not allow any communication our or in from any other interfaces. I can start the server with the first network interface being the only one enabled to start at boot and go in and activate the second interface which allows communication on both interfaces, but when they are both enabled to start on boot only the private interface can communicate. I am running Centos 7.7. Thanks in advance for any assistance you can provide. Jared Jacob

2 1

Understanding modularity
by Simon Matter 28 Apr '20

28 Apr '20

Hi, I've read the Fedora modularity docs but am still missing the big picture somehow. Hope someone can clarify things for me. What I'm most wondering: does modularity have any influence on the RPM packages at all. I mean, is there anything inside a RPM package which says it belongs to a module or it has a special function in a module? >From what I understand the RPMs are just completely normal packages and only YUM/DNF knows from some metadata that an RPM belongs to a module. Is that corrent? Thanks for any insights, Simon

3 5

CentOS-announce Digest, Vol 182, Issue 3
by centos-announce-request＠centos.org 28 Apr '20

28 Apr '20

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Release for CentOS Linux 7 (2003) on the x86_64 Architecture (Johnny Hughes) 2. Release for CentOS Linux 7 (2003) on armhfp aarch64 i386 ppc64 ppc64le and power9 (Pablo Sebasti?n Greco) 3. CESA-2020:1488 Important CentOS 6 thunderbird Security Update (Johnny Hughes) 4. CESA-2020:1429 Important CentOS 6 firefox Security Update (Johnny Hughes) 5. CESA-2020:1403 Important CentOS 6 qemu-kvm Security Update (Johnny Hughes) 6. CESA-2020:1508 Important CentOS 6 java-1.7.0-openjdk Security Update (Johnny Hughes) 7. CESA-2020:1506 Important CentOS 6 java-1.8.0-openjdk Security Update (Johnny Hughes) 8. CESA-2020:1524 Important CentOS 6 kernel Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 27 Apr 2020 05:04:53 -0500 From: Johnny Hughes <johnny(a)centos.org> To: CentOS-Announce <centos-announce(a)centos.org> Subject: [CentOS-announce] Release for CentOS Linux 7 (2003) on the x86_64 Architecture Message-ID: <e9ae4414-edb9-7ac0-06fa-9013e6777dfd(a)centos.org> Content-Type: text/plain; charset="utf-8" Release for CentOS Linux 7 (2003) on the x86_64 Architecture We are pleased to announce the general availability of CentOS Linux 7 (1908) for the x86_64 architecture. Effectively immediately, this is the current release for CentOS Linux 7 and is tagged as 1908, derived from Red Hat Enterprise Linux 7.8 Source Code. As always, read through the Release Notes at : http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7 - these notes contain important information about the release and details about some of the content inside the release from the CentOS QA team. These notes are updated constantly to include issues and incorporate feedback from the users. ---------- Updates, Sources, and DebugInfos Updates released since the upstream release are all posted, across all architectures. We strongly recommend every user apply all updates, including the content released today, on your existing CentOS Linux 7 machine by just running 'yum update'. As with all CentOS Linux 7 components, this release was built from sources hosted at git.centos.org. In addition, SRPMs that are a byproduct of the build (and also considered critical in the code and buildsys process) are being published to match every binary RPM we release. Sources will be available from vault.centos.org in their own dedicated directories to match the corresponding binary RPMs. Since there is far less traffic to the CentOS source RPMs compared with the binary RPMs, we are not putting this content on the main mirror network. If users wish to mirror this content they can do so using the reposync command available in the yum-utils package. All CentOS source RPMs are signed with the same key used to sign their binary counterparts. Developers and end users looking at inspecting and contributing patches to the CentOS Linux distro will find the code hosted at git.centos.org far simpler to work against. Details on how to best consume those are documented along with a quick start at : http://wiki.centos.org/Sources Debuginfo packages are also being signed and pushed. Yum configs shipped in the new release file will have all the context required for debuginfo to be available on every CentOS Linux install. This release supersedes all previously released content for CentOS Linux 7, and therefore we highly encourage all users to upgrade their machines. Information on different upgrade strategies and how to handle stale content is included in the Release Notes. Note that older content, obsoleted by newer versions of the same applications are trim'd off from repos like Extras/ and Plus/ However this time we have also extended this to the SIG content hosted at mirror.centos.org, and some older End of Life content has been dropped. Everything we ever release, is always available on the vault service for people still looking for and have a real need for it. ---------- Download In order to conserve donor bandwidth, and to make it possible to get the mirror content sync'd out as soon as possible, we recommend using torrents to get your initial installer images: Details on the images are available on the mirrors at http://mirror.centos.org/centos/7/isos/x86_64/0_README.txt - that file clearly highlights the difference in the images, and when one might be more suitable than the others. sha256sum x86_64: 087a5743dc6fd6706d9b961b8147423ddc029451b938364c760d75440eb7be14 CentOS-7-x86_64-DVD-2003.iso 4120aff542c2f9a30bcf90d4d79e39511e5d9eabdf202566a94ff24ea7f0974c CentOS-7-x86_64-Everything-2003.iso 659691c28a0e672558b003d223f83938f254b39875ee7559d1a4a14c79173193 CentOS-7-x86_64-Minimal-2003.iso 101bc813d2af9ccf534d112cbe8670e6d900425b297d1a4d2529c5ad5f226372 CentOS-7-x86_64-NetInstall-2003.iso 3febddab1498f940e3127f2f5e1056d6fef57fcd559d5b70ff1bfa55a444f176 CentOS-7-x86_64-LiveGNOME-2003.iso 92be566a5b1d2aa62acf2e4ab01ba91420e7170cdb21e2e190dd1dafcb6a8c94 CentOS-7-x86_64-LiveKDE-2003.iso Information for the torrent files and sums are available at http://mirror.centos.org/centos/7/isos/x86_64 -------- Additional Images The Cloud images are posted here: https://cloud.centos.org/centos/7/images/ The container, Vagrant, and Atomic Host images are being prepared and will be released in the next few days. Look for an announcement posted to the centos-announce list for more information on availability for these in the coming days. ---------- Getting Help The CentOS ecosystem is sustained by community driven help and guidance. The best place to start for new users is at http://wiki.centos.org/GettingHelp We are also on social media, you can find the project: on Twitter at? : http://twitter.com/CentOSProject on Facebook at : https://www.facebook.com/groups/centosproject/ on LinkedIn at : https://www.linkedin.com/groups/22405 And you will find the core team and a majority of the contributors on irc, on freenode.net in #centos ; talking about the finer points of distribution engineering and platform enablement. ---------- Contributors This release was made possible due to the hard work of many people, foremost on that list are the Red Hat Engineers for producing a great distribution and the CentOS QA team, without them CentOS Linux would look very different. Many of the team went further and beyond expectations to bring this release to you, and I would like to thank everyone for their help. We are also looking for people to get involved with the QA process in CentOS, if you would like to join this please introduce yourself on the centos-devel list ( http://lists.centos.org/mailman/listinfo/centos-devel ). Finally, please join me in thanking the donors who all make this possible for us. Enjoy the fresh new release! Thanks, Johnny Hughes _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce

1 0

RHEL 8.2
by Thomas Stephen Lee 28 Apr '20

28 Apr '20

Got RHEL 8.2 today. https://www.redhat.com/en/about/press-releases/red-hat-delivers-force-multi… . thanks -- Lee

1 0

Weird problem with my app and blocked ports
by david allan finch 27 Apr '20

27 Apr '20

Hi, Not sure where to look for my issue. I hope someone can point me in the correct place. I have been working on a bespoke server package for more than twenty years. It was originally developed on Solaris (Unix), was ported to windows and now ported to Linux for the last five years. This system is in live production under heavy usage everyday. The servers are all written in C++ and use a version of encoded ONC RPC (without bind) to communicate server to server and java for the client displays. Since about six months ago, I have been experiencing a weird issue with the sockets on my test system. My dev env is on CentsOS 7.7 running on Virtualbox 6 on a Windows 10 machine. The VM has bridge networks interface to my lan using a static IP. Our servers talk on the interface on Virtualbox to other servers possibly on other hosts via my real network. All works well until I do a massive relability and soak test of one of our servers. I send a series of large data message every 15 second or so to one of our servers (say Y), expecting that I might see a lockup and bugs to fix etc in that server Y. But instead of Y server failing what I see is the well know port that our system uses (ie 2323) for name lookup requests, block and I then see timouts of on that socket (this is a different server say Z). All the others servers (A..Y) get timeouts communicating to Z from then on. This effect I don't see on other OSs with similar tests. If I systemctl stop our service and then restart the servers A-Y start but continue to fail with timeouts to Z. Reboot does the same. I have change the well know port to 23232 and it still fails. I have run the servers in the systemctl as a new user and it still fails. As a mad idea I change the interface so the servers talk on the virtual box internal network and the system returns to operation. Also if I run the servers manually on the command line as my user account they work. It kind of looks like a firewall/anti-virus/tojan block rule on our well known port 2323 or Z server. As far as I can see the CentOS firewall is not running. The Norton firewall on my PC does not seam to have an rules or warning about my virtualbox ips or ports. Our servers don't cache any ip data. The first time this happened I was too busy to look at it and just restored the VM from a backup. It then happened a second time a month ago and spend a day looking at the issue found nothing and restored from backup again, putting it down to the centos security update I have just done earlier that day. It happen for a third time on Friday (24th). This time I have done no updates since the last restore so I can be sure its not a centos update. I checked again could find nothing wrong, did all the updates and still nothing worked. Investigated all the firewall and interfaces and it works. I need the system to work on the external bridge network interface and I can't think of anything else todo. The socket error messages are just Timeout, there is nothing in dmesg, or journal that suggests anything. I am now a complete lost to what is happening and why. Regards David Finch

1 0

libGLU.so.1
by Art Edwards 27 Apr '20

27 Apr '20

I'm trying to download the rpm that will install this library. I do not see it on the CentOS site. Any help would be appreciated. Art Edwards

2 1

Weird bug in 389 Directory Server : no spaces in admin console (CentOS 7)
by Nicolas Kovacs 27 Apr '20

27 Apr '20

Hi, I'm currently setting up 389 Directory Server on a server running CentOS 7, and I have a weird and somehow showstopping bug. All the spaces are suddenly missing in the admin console. Here's a screenshot so you can get the idea : https://www.microlinux.fr/download/389-admin-console-2020.png So instead of "Standard branch for configuration information", I get "Standardbranchforconfigurationinformation", "Secure connection" reads "Secureconnection", etc. I tried to add a user in my directory, with "Nicolas Kovacs" in the "Common Name" field, but instead of "Nicolas Kovacs" I get "NicolasKovacs" and there is no way to add space between the first and the last name. Last year I made the same setup and even wrote a series of blog articles about 389 DS on CentOS 7, and everything worked perfectly. Here's the screenshot from last year's setup: https://www.microlinux.fr/download/389-admin-console-2019.png Any idea what's going on here ? Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

4 8

Open-source software to file IRS form 941 electronically
by H 24 Apr '20

24 Apr '20

Is there any such software available? Does not need to include paying payroll taxes but only the filing of form 941.

1 0

Looking for C8 AMD help
by Pete Geenhuizen 24 Apr '20

24 Apr '20

I'm migrating from C7 to C8. I'm currently using autofs, but alas autofs has been dropped in C8 for the AMD automounter. I have some very ancient knowledge of AMD, I used it when it was first introduced many years ago on Solaris and moved to Sun's automounter when it was introduced. So now it's back to square one. I used automount2amd to convert one of my existing maps, included it in the amd.conf file and tried it out. I don't get any syntax errors so I guess that the map syntax is correct, but amd fails to mount the remote filesystem and generates these errors in messages. Apr 23 16:04:29 localhost.my.domain amd[19389]: matched default selectors "type:=nfs;opts:=rw,grpid,nosuid,utimeout=600" Apr 23 16:04:29 localhost.my.domain amd[19389]: key new: map selector host (=localhost) did not match remotehost Apr 23 16:04:29 localhost.my.domain amd[19389]: merge rem/opts "rw,grpid,nosuid,utimeout=600" add "fstype=nfs,vers=4,soft,intr" => "rw,grpid,nosuid,utimeout=600,fstype=nfs,vers=4,soft,intr" Apr 23 16:04:29 localhost.my.domain amd[19389]: Map entry host==remotehost;type:=link;fs:=/export/data/& for /repo/new did not match Apr 23 16:04:29 localhost.my.domain amd[19389]: merge rem/opts "rw,grpid,nosuid,utimeout=600" add "fstype=nfs,vers=4,soft,intr" => "rw,grpid,nosuid,utimeout=600,fstype=nfs,vers=4,soft,intr" Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: returning NFS(4,tcp) on host remotehost.my.domain Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(4,udp) failed for remotehost.my.domain: RPC: Unable to receive Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(3,udp) failed for remotehost.my.domain: RPC: Unable to receive Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(2,udp) failed for remotehost.my.domain: RPC: Unable to receive Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: returning NFS(0,udp) on host remotehost.my.domain Apr 23 16:04:29 localhost.my.domain amd[19389]: Using NFS version 4, protocol tcp on host remotehost.my.domain Apr 23 16:04:29 localhost.my.domain amd[19389]: changing remotehost.my.domain's ping value from 30 to 30 Apr 23 16:04:29 localhost.my.domain amd[19389]: Trying mount of remotehost:/export/data/& on /.automount/remotehost/export/data/& fstype nfs mount_type non-autofs Apr 23 16:04:31 localhost.my.domain amd[19389]: Trying mount of remotehost:/export/data/& on /.automount/remotehost/export/data/& fstype nfs mount_type non-autofs Apr 23 16:04:32 localhost.my.domain amd[19389]: file server remotehost.my.domain, type nfs, state starts down Apr 23 16:04:49 localhost.my.domain amd[19389]: "/repo/new" on //nil// timed out (flags 0x20) I'm using firewalld on both hosts and allow these services mountd nfs rpc-bind and protocols 111/tcp and 111/udp all of which allow autofs to work flawlessly, I've tried turning firewalld off which made no difference. Here's my /etc/amd.remote file looks like new \ -addopts:=fstype=nfs,vers=4,soft,intr \ host==remotehost;type:=link;fs:=/export/data/& \ rhost:=remotehost;rfs:=/export/data/& Any assistance in pointing me in the right direction would be greatly appreciated. Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 2

CentOS repo question
by Tony Molloy 23 Apr '20

23 Apr '20

Hi All, I've just installed a test laptop with CentOS Stream 8.1. I notice that the default install has both CentOS-Base and CentOS-Base-Appstream repos enabled. Is that necessary, or should I just have the Appstream repos enabled. The reason I'm asking is because I'm having trouble updating the installation. The problem seems to be some installed rpms seem to depend on updates from the CentOS-Base repos and others seem to depend on similar updates from the CentOS-Base-Appstream repos and you can't install both. A typical error looks like this. cannot install both qt5-qttools-common-5.12.5-1.el8.0.1.noarch and qt5-qttools-common-5.11.1-9.el8.noarch qt5-qttools-common-5.11.1-9.el8.noarch is from CentOS-Base qt5-qttools-common-5.12.5-1.el8.0.1.noarch is from CentOS-Base-Appstream So updating some installed rpm depends on updating to the Appstream version of qt5-qttools and some other installed rpm depends on the original CentOS-Base version of qt5-qttools. I've played around with --allowerasing --best and --nobest but still can't get a clean update. Thanks, Tony -- Tony Molloy <tony.molloy(a)ul.ie> Home

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2020