Discuss

discuss@lists.centos.org

8 participants
34745 discussions

mariadb or mysql web gui
by Ranbir 21 Dec '20

21 Dec '20

Hello, Is there a web gui available in CentOS 8 for managing mariadb and/or mysql DB servers? I've used phpMyAdmin for many years, but I don't see an RPM for it in EPEL for CentOS 8. Is there a popular alternative to phpMyAdmin that's packaged for CentOS 8? -- Ranbir

3 2

Finding which repository files provide required libraries
by H 21 Dec '20

21 Dec '20

I came across the following Ubuntu script to identify which repository files provide libraries required by an app. Is there a rpm alternative to dpk-query that would allow this to run on CentOS/RH? ldd /bin/zoom | awk '/=>/{print $(NF-1)}' | while read n; do dpk-query -S $n; done | sed 's/^$[^:]\+$:.*$/\1/' | uniq

3 4

Centos Stream Docker image
by Steve Malenfant 19 Dec '20

19 Dec '20

I've been looking, but couldn't find it. Can somebody give me a pointer to where I can find a Centos Stream Docker image? Thanks, Steve

1 0

PXE configuration
by Erick Perez - Quadrian Enterprises 19 Dec '20

19 Dec '20

Hi guys, I have a Centos 7.9 TFTP/PXe server that I use to serve ISO installers. I can properly serve installers but not live CDs. But I want to add a live cd, I'm using this but is not working. Can someone suggest a fix? label 2 menu label ^2) Run Centos LiveCD 79 x64 kernel centos7_x64_livecd_genome/isolinux/vmlinuz0 append initrd=centos7_x64_livecd_genome/isolinux/initrd0.img rootfstype=auto ro rd.live.image method=http://192.168.1.83/centos7_live/LiveOS/squashfs.img devfs=nomount -- --------------------- Erick Perez Quadrian Enterprises S.A. - Panama, Republica de Panama Skype chat: eaperezh WhatsApp IM: +507-6675-5083 ---------------------

1 0

Questions about Stream
by Andrey 18 Dec '20

18 Dec '20

OK, we realized that the changes are final, and must somehow deal with it. Before making final decisions we need some answers. 1. What about bugs and security issues? The FAQ says: "Security issues will be updated in CentOS Stream after they are solved in the current RHEL release." Consider the scenario: a bug or security issue found in both Stream and current RHEL. It was fixed in RHEL in a few days. How fast it will be fixed in Stream? Obviously, it needs some time to port the fix to newer version of package. Days or months? Another scenario: a bug or security issue found in Stream but NOT in current RHEL. How fast it will be fixed in Stream? In a few days or in next RHEL release (up to 6 months)? 2. What to do in 2024, when Stream 8 is EOL. Perform full reinstall of all servers to Stream 9? Or there will be some kind of major version upgrade? A note about hardware: we don't know now what drivers will be dropped from RHEL and Stream 9. Bad news for server owners: in 2024 they may be forced to upgrade hardware or move to RHEL 8 because of its longer lifecycle.

5 8

YUM problem
by Gestió Servidors 18 Dec '20

18 Dec '20

Hi, I'm trying to find a YUM package. My system runs a CentOS-7.2.1511 (yes, it's a old version, but some software is "stable" with this CentOS version). Now, I'm looking for a package with YUM. When a run "yum provides */system-config-lvm", I get this error: [root@mysystem ~]# yum provides */system-config-lvm Complementos cargados:fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * epel: mirror.uv.es * extras: ftp.csuc.cat<ftp://ftp.csuc.cat> * updates: ftp.csuc.cat<ftp://ftp.csuc.cat> Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 375, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 184, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 584, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 1557, in doCommand return base.provides(extcmds) File "/usr/share/yum-cli/cli.py", line 1619, in provides callback_has_matchfor=True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3538, in searchPackageProvides tagdata = getattr(po, tag) File "/usr/lib/python2.7/site-packages/yum/packages.py", line 668, in <lambda> filelist = property(fget=lambda self: self.returnFileEntries(ftype='file')) File "/usr/lib/python2.7/site-packages/yum/packages.py", line 1504, in returnFileEntries self._loadFiles() File "/usr/lib/python2.7/site-packages/yum/packages.py", line 1478, in _loadFiles files = self.hdr['filenames'] _rpm.error: invalid header data I have run "yum clean metadata" and "yum clean all", but error message still appears. What can I do? Thanks.

2 1

CentOS 8.3 bugs
by d tbsky 17 Dec '20

17 Dec '20

Hi: just try to install CentOS 8.3. I use two sata disks and create mdadm raid1 with LVM. Normally when I want to reinstall this system, anaconda should recognize the raid1/lvm so I can reformat it. anaconda at CentOS 8.3 failed to do the job. I tried Scientific Linux 7.9 and RHEL 8.3, both can recognize installed CentOS 8.3 correctly and let me reformat it. and there is no net-snmp-perl package in CentOS 8.3 repository. although it is in RHEL 8.3. wait for next bug-to-bug distribution....

6 8

Re: [CentOS] I'm looking forward to the future of CentOS Stream
by Gordon Messmer 17 Dec '20

17 Dec '20

On 12/11/20 9:56 AM, Ljubomir Ljubojevic wrote: > And I will repeat that millions of CentOS users found free clone of RHEL > trustworthy enough to use it for production, even without "official > endorsement". Exactly. That's why it's so weird that those people, today, think that CentOS Stream won't be usable, based on their interpretation of the official statements from Red Hat. Red Hat's statements weren't taken into consideration before, but now they're a sign of doom? > If they ... even allowed ANYONE ELSE that was not employed by Red Hat in > 2014 to even come close to learning the secrets of rebuild, no backlash > would have happened I'm going to stop you there, because the CentOS maintainers kept that process out of public visibility long before Red Hat was ever involved. If you think users should know more about the process, then you are pointing fingers at the *wrong* people. I don't want this to become a flame war. So rather than pointing fingers, let's focus on the fact that CentOS Stream promises to be developed in the open, resolving the problem that you're describing. Red Hat is fixing the thing you're complaining about. Red Hat is giving us the thing that has been requested more often, by more people, than any other change in CentOS, and the result is that the press is full of stories about users being angry, because five people on the mailing lists sent a lot of messages. (About half of the traffic in the threads on centos and centos-devel comes from five people, and various people replying to them.) > But no, as soon as Oracle started rebuilding RHEL source code Red Hat > first made things difficult for everyone to create kernels (source code > was not srpms anymore but tar?) You're misinformed. Kernels are still built from SRPM, but the archive used is no longer an upstream release with a series of patches. The reason for the change is not insidious. It's unfortunate that the pristine source + patches can't be maintained, I agree, but speaking as a developer: maintaining hundreds of patches that touch intersecting files and rebasing them all when earlier patches are updated is an incredibly difficult and time consuming task. And, if I remember correctly, applying all of those patches took almost as long as building the kernel. If it takes that long to just prepare the source code, that's a major hit to productivity when a developer needs to work on the code or build the SRPM to validate changes. And, ultimately, there's very little value in shipping those patches when the vast majority of them are already in the current version of the upstream kernel, and they're merely backported to the older release that Red Hat supports. It's an entirely different story when distributions are shipping patches that they don't push upstream, but that's not generally what you see with the kernel package.

15 19

I'm looking forward to the future of CentOS Stream
by Gordon Messmer 17 Dec '20

17 Dec '20

Personally, I think that changing focus on CentOS Stream is going to make CentOS (and maybe even RHEL) better in the same way and for the same reasons that Fedora is a better distribution than Red Hat Linux was. CentOS Stream should fix the biggest problems that CentOS has had in the past, providing a reliable, free LTS distribution with community participation. Having read the announcement, along with hundreds of reactions in blogs, forums, and mailing lists, I am of the opinion that all (or a reasonable approximation thereof) of the vocal concern is the result of the overloaded term "stable" as it applies to software distributions. If we imagine a spectrum of individuals in which one end of the spectrum is individuals whose primary occupation is in release engineering for software distributions and the other end is individuals who primarily consume software distributions, I would expect that individuals on one end to mostly use the term "stable" in the sense of compatibility and semantic versioning, and the other end to use the same term in the sense of having fewer bugs. The use of that word causes people at one end of the spectrum to infer a completely different message than people at the other end intend to communicate. If we never use the ambiguous term "stable" and instead use the terms compatibility and reliability (the two common meanings of "stable" at different ends of the spectrum), I think that various aspects of CentOS Stream will be better than CentOS, or the same as CentOS. With respect to compatibility: I think most developers are familiar with semantic versioning. Semantic versioning is used by some applications and libraries to indicate the nature and extent of changes. The version is presented numerically as Major.Minor.Revision. When new interfaces are added, the minor number is increased. Those changes don’t affect backward compatibility. When individual interfaces are changed or removed, the major number is increased. Those changes aren’t backward compatible. That allows consumers to infer that if an application is compatible with 8.1, then it is also compatible with 8.2 and later, but might not be compatible with 9.0. Red Hat Enterprise Linux applies that concept to the entire software distribution, providing independent software vendors a convenient means of communicating their compatibility. If they’ve tested their application on RHEL 8.2, then any RHEL 8 host patched to at least that release is expected to run the application. Moreover, Red Hat will continue to publish security patches to each given minor release’s channel, allowing consumers to "pin" a host to a minor release. Those hosts will not receive feature updates, but will mitigate vulnerabilities. CentOS Stream isn’t going to feature minor releases, and isn’t going to provide semantic versioning of the distribution. The same application that the vendor has validated on RHEL 8.2 will run on a fully patched CentOS Stream 8 host, but might not run on a host that isn’t fully patched. On the surface, it appears that CentOS users will lose the convenience provided by semantic versioning. I would simply point out that the CentOS developers have never supported running CentOS in any state other than fully patched. They don’t publish security information in the package repositories, and they don’t support any means of pinning a host to a minor release. For practical purposes, CentOS Stream will need to be fully patched for compatibility purposes, just like CentOS is, and will be equally suited for production purposes. To put a really find point on that: Semantic versioning is only meaningful for hosts that are not fully patched. A fully patched host is expected to be compatible with any application validated for that major release. With respect to reliability: Many of the people concerned about the change in focus refer to CentOS Stream as a "beta" for RHEL. That is not how Red Hat or the CentOS maintainers describe CentOS Stream( anywhere that I've seen), and I think it ignores most of the development, testing, and distribution pipeline. At the risk of oversimplifying that pipeline a whole lot, in the future Free Software will pass through several stages on the way to RHEL: Stage 1: (Software Development) The majority of development and testing is done in individual upstream projects, outside of Red Hat. Stage 2: (Release Development, aka Rawhide) The initial work to build and integrate individual packages with the rest of the software distribution is done in what is essentially a development branch of the software distribution. Stage 3: (Stable[1], aka Fedora) Packages that have passed through review and QA are published for general use. There is no minor release, as major releases occur every 6 months and are supported for only 13 months, anyway. Compatibility is maintained by prohibiting significant version changes for applications and libraries "whenever possible." Users expect no new features during a release, but no breaking changes either. Stage 4: (Long Term Support, aka CentOS Stream) Packages that CentOS Stream includes from Fedora have proven reliable in a variety of workloads managed by many users of Fedora. These packages are expected to be very reliable as a result of testing by their developers, by package maintainers, and by real-world users. They are included in CentOS Stream when they are ready. Stage 5: (Long Term Support with Semantic Versioning of the OS, aka Red Hat Enterprise Linux) Packages that RHEL includes from CentOS Stream have a similar level of QA, but package updates that introduce new features and interfaces are accepted only once every six months when Red Hat publishes a minor release. There’s a lot of concern that CentOS Stream will offer less reliability than RHEL, but there’s currently no reason to believe that will be true. There is no evidence that the minor releases that are part of the RHEL lifecycle improve reliability, and as far as I know that's not the reason they're used. Their function is to offer semantic versioning of the OS. CentOS Stream will probably offer the same level of compatibility and reliability that CentOS does today, and should be equally appropriate or inappropriate for production use in the future as CentOS is now in that respect. And that brings me to the one aspect where I think CentOS Stream will resolve the one major, glaring problem that CentOS has today, that most users ignore: Security. With respect to security: Today, CentOS is a release stage after Stage 5 described above. The CentOS maintainers begin work on a minor release after that release is available to RHEL consumers, and the process of rebuilding those packages is often very time consuming. CentOS maintainers have to reverse-engineer the exact order in which packages are built, with the exact set of installed and available packages in the build environment in order to ensure that the resulting package actually uses the same interfaces that RHEL’s packages do. All packages require that ordering and build environment matching, but most packages are published in small sets and ordering is much easier to identify than it is when they are published in a large batch. As a result, security updates can’t be published for CentOS while the maintainers are rebuilding the minor release, because the build dependencies aren’t available yet. Those windows occur every six months, and are typically a month or more in length. [2] Today, CentOS users accept the risk that for roughly two months out of the year, their systems may have known vulnerabilities with no patch to remediate the problem. Personally, I think that’s a huge risk that needs to be weighed against the costs of RHEL licenses whenever CentOS is used in production. The good news is that CentOS Stream looks like it won't have that problem. CentOS Stream updates still won’t be prepared early, while vulnerability details are embargoed, but there aren’t any windows in which CentOS Stream can’t immediately begin work on preparing updates once the embargo ends. That means that CentOS Stream will be as secure as CentOS is today in between minor updates, and significantly more secure than CentOS is today while its maintainers prepare minor releases. The trade-off of significantly improving security in exchange for giving up semantic versioning of the OS is a huge improvement for production purposes. In addition, the announcement of the change in focus indicates that Fedora maintainers should have much better visibility into work going on within the RHEL release engineering process, and more opportunity to participate in that work, and I look forward to that. CentOS’s big security problem has always been compounded by the lack of any external visibility into the process. Based on the information available today, I expect CentOS to be a very reliable, reasonably secure distribution of GNU/Linux with Long Term Support. And judging by Red Hat’s mention that Facebook’s internal groups either are already using an internally curated OS built from CentOS Stream, or will be using it soon, I think I’m not alone in believing that. 1: I’m using the term "stable" here because I expect it to have both common meanings: compatibility isn’t broken within a release, and the software is expected to be reliable. 2: https://en.wikipedia.org/wiki/CentOS#CentOS_version_8

15 20

Re: [CentOS] MTU report question
by Strahil Nikolov 17 Dec '20

17 Dec '20

seems so

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss