[CentOS] possible LVM corruption?
While updating a hypervisor, I'm getting the following errors printed to the terminal during rpm upgrade scripts. The first line is printed 15 times, and GRUB prints a similar error at boot. "vgck" doesn't seem to find any problems. Does anyone have suggestions for diagnosing the issue? error: ../grub-core/disk/diskfilter.c:524:unknown node 'vm_ipa-data_rimage_0'. grub2-probe: error: ../grub-core/kern/disk.c:236:disk `lvmid/uhx5FA-RmdV-cPYP-ELEA-pUrn-FfHl-M2RBEV/JQKCwn-RhKX-ek4u-VJxX-ja9j-rtAD-fVUBGc' not found. "vgdisplay --verbose" output includes: --- Volume group --- VG Name VolGroup System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 2053 VG Access read/write VG Status resizable MAX LV 0 Cur LV 82 Open LV 18 Max PV 0 Cur PV 2 Act PV 2 VG Size <7.28 TiB PE Size 32.00 MiB Total PE 238392 Alloc PE / Size 163262 / 4.98 TiB Free PE / Size 75130 / 2.29 TiB VG UUID uhx5FA-RmdV-cPYP-ELEA-pUrn-FfHl-M2RBEV --- Logical volume --- LV Path /dev/VolGroup/vm_ipa-data LV Name vm_ipa-data VG Name VolGroup LV UUID YSw2fz-e4cA-7i86-4ssj-5b49-7572-uNWm2p LV Write Access read/write LV Creation host, time ascension, 2023-10-26 21:31:26 -0700 LV Status available # open 1 LV Size 5.00 GiB Current LE 160 Mirrored volumes 2 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:197 # lvs -a | grep vm.ipa.data vm_ipa-data VolGroup rwi-aor--- 5.00g 100.00 [vm_ipa-data_rimage_0] VolGroup gwi-aor--- 5.00g [vm_ipa-data_rimage_0_iorig] 100.00 [vm_ipa-data_rimage_0_imeta] VolGroup ewi-ao 96.00m [vm_ipa-data_rimage_0_iorig] VolGroup -wi-ao 5.00g [vm_ipa-data_rimage_1] VolGroup gwi-aor--- 5.00g [vm_ipa-data_rimage_1_iorig] 100.00 [vm_ipa-data_rimage_1_imeta] VolGroup ewi-ao 96.00m [vm_ipa-data_rimage_1_iorig] VolGroup -wi-ao 5.00g [vm_ipa-data_rmeta_0] VolGroup ewi-aor--- 32.00m [vm_ipa-data_rmeta_1] VolGroup ewi-aor--- 32.00m ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] can I convert a linear thin pool to raid1?
In the past, I've used LVM on MD RAID, and I'd like to try using LVM RAID in order to also add dm-integrity data to some LVs. I've added new PVs to my VG, and I've converted some of my LVs to raid1 types, but I also have one thin pool that I use for VMs with multiple layers of snapshots. That pool can't be converted, directly: # lvconvert --type raid1 -m 1 VolGroup/vm_pool --yes Operation not permitted on LV VolGroup/vm_pool type thinpool. Is it sufficient to simply convert the tdata and tmeta LVs to raid1 type? Should I also convert lvol0_pmspare? Is there anything else I should consider? # lvs VolGroup/vm_pool VolGroup/vm_pool_tmeta VolGroup/vm_pool_tdata VolGroup/lvol0_pmspare LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert [lvol0_pmspare] VolGroup ewi-a- 128.00m vm_pool VolGroup twi-aotz-- 200.00g 12.83 15.93 [vm_pool_tdata] VolGroup Twi-ao 200.00g [vm_pool_tmeta] VolGroup ewi-ao 128.00m ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-25 16:24, Leon Fauster via CentOS wrote: Honestly, you are mixing unrelated, or not relevant topics and arguments, and even misconceptions and forget to understand the problem at all. I don't see how that's unrelated. As I said earlier, on this point we're discussing a matter of opinion on the "spirit" of the license, and mine is heavily influenced by the fact that RHEL is composed of publicly available software and patches. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-25 12:18, Chris Adams wrote: Once upon a time, Gordon Messmer said: If Red Hat were doing development in RHEL minor releases that wasn't published elsewhere, I would probably have a different view of thing, but they aren't. There's nothing there that isn't published elsewhere. This will not be the case for the second half of a RHEL major release life cycle, because the corresponding Stream will be EOL and no longer updated. As best I understand Red Hat's "upstream first" policy: every patch applied to RHEL X.10 will either be a patch that they import from an upstream project, or (for patches that Red Hat develops) will be offered to the upstream project. They're not held in reserve for RHEL customers exclusively. So, they may not appear in the Stream git repo, but the patches are still publicly available through other channels. If anyone has examples of this not happening, then we can talk about whether the process is working as intended, and what that means. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-25 09:19, Gordon Messmer wrote: 5. Red Hat's policy change contradicts the GPL's spirit. As you acknowledge, that's a subjective question. I would say "no." Seriously? You are the only person here who thinks that. After reading an unrelated thread, I want to make an additional comment: There are several reasons that I think that Red Hat's subscriber agreement is in the spirit of the GPL. One of them is that nothing is developed in RHEL minor releases that isn't available to the public. A RHEL minor release is just a snapshot of the major release branch (which is now used to build Stream), that Red Hat engineers continue to support. Updates to the RHEL minor release are either a direct merge of changes from Stream, or backporting a fix if Stream has rebased a package which needs that fix. If Red Hat were doing development in RHEL minor releases that wasn't published elsewhere, I would probably have a different view of thing, but they aren't. There's nothing there that isn't published elsewhere. The *software* is freely available to everyone, through Stream. RHEL is a *support* program that provides extended support to snapshots of the software (among other things), by applying patches that are generally available. Providing support is not a violation of the spirit of the GPL. Development all happens upstream, in publicly accessible repositories. That's a core part of my outlook on the subject. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-25 04:25, Phil Perry wrote: Nonsense. For years Red Hat freely published the complete RHEL SRPMs to their public ftp server. No, they didn't. Take a look at the planning guide diagrams, here: https://access.redhat.com/support/policy/updates/errata A RHEL major release isn't a single lifecycle. It's a sequence of minor releases, many of which have 4 year lifecycles of their own. Red Hat never published the updates for those lifecycles after the first 6 months, which is why CentOS had long gaps with no updates every 6 months, while they built a new release. If Red Hat had published *all* of their source, then CentOS could have continued publishing security errata right up until they were ready with a new minor release. But that's not the way that it worked. Few people, if any, were ever really concerned about the fact that Red Hat didn't publicly publish the source for their extended support life cycles. But, that's what minor releases fundamentally *are*, so it's weird to see users unhappy with arrangement today, in which the current sources for RHEL are published to the CentOS Stream git repositories, and the minor releases are treated the same way that extended support life cycles always have been. 3. Per Red Hat EULA, customers can not freely distribute the source code. (ref: Red Hat EULA) It's a little more complex than that, but probably close enough for now. It's not complex at all. The GPL absolutely allows recipients to freely redistribute the RHEL sources. That's not what I'm saying. The GPL does allow RHEL customers to redistribute source code for GPL-licensed software. The complexity is that the license doesn't require Red Hat to continue business relationships and support users who choose to do that. And that most of RHEL isn't GPL-licensed. This is the point at which I think we start to wade out into the territory of myth. It has never been possible to create a clone of RHEL from the code that Red Hat published. Of course it has. No, it wasn't. CentOS's maintainers were pretty clear about this when they were asked: https://www.spinics.net/lists/centos-devel/msg19564.html "CentOS was NEVER bug-for-bug compatible. ... Sometimes CentOS shipped packages which did not have a particular bug because we could not exactly duplicate the build environment and other times we added new bugs because our build environment is not exactly the same... At best, CentOS has been "good-enough" compatible for a set of years " And that's only for the packages that they actually shipped. CentOS never reproduced the extended life cycles that RHEL provided, which are what make minor releases actually valuable. Without the overlapping life cycles, there's just not a really good reason to have minor releases. The GPL *requires* Red Hat to publish the full sources including "the scripts used to control compilation and installation of the executable." To customers, yes. Red Hat goes above and beyond that requirement, by publishing the current state of the source code to the public, for both GPL and non-GPL software. First, because Red Hat doesn't publish the information that would be required to create reproducible builds. Yes they do - it's all in the SRPMs. See https://reproducible-builds.org/ for more information. It isn't all in the SRPMs. As above, CentOS's maintainers were always clear that it was never possible to reproducibly build RHEL. 5. Red Hat's policy change contradicts the GPL's spirit. As you acknowledge, that's a subjective question. I would say "no." Seriously? You are the only person here who thinks that. I don't think I am, but it doesn't really matter. Most of RHEL isn't GPL anyway. Even if the subscription agreement only covered content that wasn't GPL, you still can't build RHEL from the GPL sources alone. The GPL isn't anti-commerce. It doesn't prevent the sale of software. The spirit of the license is that users should be able to modify the code and build new systems, which they certainly can do with RHEL source code. There's no secret sauce in RHEL that isn't publicly available to users who want to build something new. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-24 13:47, frank saporito wrote: Let me know if you disagree with any of these statements: 1. Red Hat is no longer posting source code to git.centos.org. Correct. Red Hat used to publish a de-branded subset of RHEL source code there, and they've discontinued that process. The current code for RHEL is now published to the CentOS Stream repos. 2. Red Hat will release source code to partners and customers via the Red Hat Customer Portal. (ref: Red Hat announcement) Also correct. This is the only channel through which Red Hat ever posted complete code for RHEL. It hasn't been changed. 3. Per Red Hat EULA, customers can not freely distribute the source code. (ref: Red Hat EULA) It's a little more complex than that, but probably close enough for now. 4. Red Hat's policy decision has made it difficult (maybe impossible) for "clone" distributions to continue existing. (ref: Google "red hat source code") This is the point at which I think we start to wade out into the territory of myth. It has never been possible to create a clone of RHEL from the code that Red Hat published. First, because Red Hat doesn't publish the information that would be required to create reproducible builds. But more importantly, because RHEL has one life cycle per minor release, and distributions built from the old git.centos.org repositories had *at best* one life cycle per major release. CentOS Stream also has one life cycle per major release, and conforms to the interface compatibility guide for the matching RHEL major release. Distributions derived from CentOS Stream can have either lifecycles per minor release *or* one lifecycle per major release. Unlike the old source publication process, they can have continuous or overlapping life cycles. Yes, this involves more steps than the old process. The next natural question is whether the additional work is justified by the improvement in the outcome. And from my point of view, that is a very easy "yes". I understand that it's confusing, but CentOS was never a substitute for RHEL, and never provided the benefits of RHEL's model. It is not the "free RHEL" that many users tend to think it was: https://fosstodon.org/@gordonmessmer/110648143030974242 https://www.youtube.com/watch?v=tf_EkU3x2G0 ... and conversely, CentOS Stream is a much better stable LTS for self-supported systems than you might believe: https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8 5. Red Hat's policy change contradicts the GPL's spirit. As you acknowledge, that's a subjective question. I would say "no." I think the entire history of the free-as-in-speech vs free-as-in-beer clarification is proof that we wanted to ensure the right to improve software if you didn't like its limitations, not the right to give away software if you didn't like its price. But I also think it's important to acknowledge that the thing that rebuilders are asking for (the RPM source repositories) aren't GPL licensed, they're MIT licensed, which makes the question something of a non-sequitur. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-24 08:31, Tom Bishop wrote: Eh your keep dancing around and trying to spin what they did with the source and their intent. I'm not dancing around anything. I'm discussing the objective, verifiable facts of what they did, some of my opinions on that, and not Red Hat's intent, because that is a thing that we cannot know. Restraining commentary to the things that we can know might look like "dancing around" the subject to someone who's accustomed to discussing the intent of others, but as an engineer, I tend to think that there's nothing *wrong* with focusing on the facts and evidence. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-22 09:55, frank saporito wrote: On 7/22/23 02:29, Gordon Messmer wrote: From my point of view, Red Hat doesn't really sell software. They give away software. All of their software is available at no charge, typically in an unbranded release. What Red Hat sells is support. Does Red Hat give away software anymore? Yes? I'm not aware of any Red Hat software that isn't Free Software. I am confused. Last month Red Hat announced that the source code would not be published. That's not what they announced. The major-release branch of RHEL's source code is still published to the CentOS Stream git repos. I think it's important to point out that Red Hat never published *all* of RHEL's package source code. For the first six months of any release of RHEL, they would publish de-branded source by essentially taking one artifact from each build (the src.rpm), unpacking that in a git repository, removing the primary source code archive, debranding what was left, committing all of that, and then pushing the result. It was basically git as a fancy FTP. They've stopped doing that, in favor of publishing the major-release branch of the git repos for the entire primary support lifecycle of the major release. The spirit of GPL was meant to force sharing and prevent the commercialization of the volunteer work of many. It definitely wasn't. GPL software can't be made closed-source. Customers have to receive the source code (or an offer for it), and they have the rights that the license guarantees. But GPL software can definitely be commercialized. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-21 00:30, Lee Thomas Stephen wrote: But for my business, I do not want to pay Red Hat, Zimbra, or Google Workspace. Why ? Because the general rule seems to be Oh! You are an individual, we will offer you affordable/free service What! You are a business, we will offer you extremely 'unaffordable' service. Because being a 'business' by default means you have a 'lot' of money to waste. I'm not a Red Hat employee, so I'm not positive how they would respond to that. But, speaking as a customer who has worked with numerous enterprise support agreements over several decades, I want to suggest that the issue isn't that Red Hat assumes that businesses have a lot of money to spend, it's that they're targeting a set of the market that you might not be in right now. From my point of view, Red Hat doesn't really sell software. They give away software. All of their software is available at no charge, typically in an unbranded release. What Red Hat sells is support. I don't mean helpdesk style "support-me-when-something-breaks" support. Support isn't something that exists only during incidents, support is a relationship. It's periodic meetings with your account manager and engineers. It's discussing your roadmap and your pain points regularly, and getting direction from them. It's the opportunity to tell Red Hat what your needs and priorities are, and helping them make decisions about where to allocate their engineers time to address the real needs of their customers. It's setting the direction for the company that builds the system that sits underneath your technical operations. That kind of support is what makes RHEL a valuable offering. If you don't need the kind of support that comes with enterprise offerings, then by all means, use the Free Software that Red Hat provides to the community. But don't make the mistake of thinking that Red Hat is trying to mlik businesses simply because they're businesses. Red Hat's offerings are expensive because they're enterprise-focused support plans. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
On 2023-07-20 04:36, Itamar Reis Peixoto wrote: my predict is that they will continue as a #rebuilder / #freeloader, writing software is a hard work. #offensive terms to the community :-), hide hat wrote it. No, they didn't. That term was bandied about on social media by people who were speculating about the reasoning behind discontinuing the practice of debranding and publishing packages from RHEL minor releases. Mike McGrath responded to the use of that term by social media personalities to explain that the only group that Red Hat (for better or worse) considers freeloaders are large businesses who keep a small number of licensed RHEL systems so that when they have problems in their production network (which isn't running RHEL), they can reproduce the problem on RHEL and ask Red Hat for support. That practice is dishonest and abusive. If you're not doing that specific thing, then Red Hat is not calling you a freeloader. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How will fragmentation help Red Hat
On 2023-07-13 10:28, Tom Bishop wrote: Eh I beg to differ it's pretty clear that Magnus is calling folks freeloaders... https://www.linkedin.com/pulse/problem-rocky-linux-free-beer-magnus-glantz/ I've read that article several times, including just now with an eye out for such an accusation, and I just don't see it. (But, again, that is a blog from an individual employee, and not the position of the company.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How will fragmentation help Red Hat
On 2023-07-13 09:00, Tom Bishop wrote: as referenced by one of the many RH articles, we are all just freeloaders so we shouldn't be missed. I don't believe there are any Red Hat articles that call user freeloaders. I'm aware of one personal blog, not on the redhat.com site, in which the term "freeloader" is discussed as a term sometimes used informally by staff to describe large businesses that run production networks on a self-supported distribution, but issues that affect that production network are reported through a small number of support subscriptions. That's a very narrow use, and it's specifically organizations who abuse the support that Red Hat sells, by proxying production issues through RHEL systems. And it's the behavior of individuals, not the position of the company. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How will fragmentation help Red Hat
On 2023-07-13 05:11, mario juliano grande-balletta wrote: IBM wants to make money, PERIOD. They paid billions for RedHat and investors, executives, want ROI and profit, period. No excuses. So, they are locking down RedHat and closing channels to important software/materials. It is what companies do all the time. I see this hypothesis relatively often, but there's no evidence to support it, and it doesn't make much logical sense. If Red Hat (or IBM) wanted to "lock down" RHEL, they wouldn't be focusing on Stream, which opens it up (and makes it easier to fork.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How will fragmentation help Red Hat
On 2023-07-13 03:12, Simon Matter wrote: As I found out yesterday, the fragmentation of the "Enterprise Linux" ecosystem just started to come true. I've been trying to figure out what SUSE meant when they announced a "hard fork" of RHEL. If they mean to maintain a fork that remains interface-compatible with RHEL (and a fork that doesn't remain compatible doesn't make much sense, because the thing that everyone wants is the benefit of RHEL's integration with other vendors), then they'll probably periodically branch from Stream, the same way that RHEL does. If that happens, and if it's successful, the irony is that through poor communication, Red Hat might have actually made progress in creating a *less* fragmented ecosystem of distributions all conforming to a common ABI, descending from Stream. I expect this is only the beginning and Red Hat may also start to completely hold back sources of non GPL software which is part of the "Enterprise Linux" ecosystem. I think that's exactly the opposite of the direction that Red Hat is moving. CentOS Stream makes the RHEL product more open than it has ever been -- including making it easier to create real Enterprise-ready products that compete on level ground with RHEL, in ways that clones never could. I'm really wondering, how will this help anybody and how will this help Red Hat in the long run? https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wget http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/images/pxeboot/vmlinuz --max-redirect=0 --no-hsts
On 2023-03-29 11:52, Jelle de Jong wrote: I am using pxelinux to install centos stream 9 systems but this stopped working a while ago with mirror.stream.centos.org because it started forcing HTTPS and pxelinux is HTTP only. I believe the recommended configuration is to have vmlinuz and initrd.img on the same tftp server you use for the PXE boot loader. https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/advanced/Network_based_Installations/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream 8 sssd.service failing part of sssd-common-2.8.1-1.el8.x86_64 baseos package
On 2022-12-25 07:44, Jelle de Jong wrote: A recent update of the sssd-common-2.8.1-1.el8.x86_64 package is causing sssd.service systemctl failures all over my CentosOS machines. ... [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error! Were you previously using sssd? Or is the problem merely that it is now reporting an error starting a service that you don't use? Are there any files in /etc/sssd/conf.d, or does /etc/sssd/sssd.conf exist? If so, what are the contents of those files? What are the contents of /usr/lib/systemd/system/sssd.service? If you run "journalctl -u sssd.service", are there any log entries older than the package update? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND server getting DDOS
On 8/3/22 11:08, Mark Milhollan wrote: Usually that's someone hoping to use you in a reflection attack Doesn't a reflection attack require the reflecting server to answer queries? I'd think that the server logging that the query was denied would indicate that it is not vulnerable to that type of abuse. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND server getting DDOS
On 8/2/22 14:03, Robert Moskowitz wrote: I just, maybe, figured out why I have been having problems with my CentOS DNS server with BIND 9.11.4. Can you tell us more about what problem you've been having? Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.194.4#11205 (.): view external: query (cache) './A/IN' denied grep -c denied messages 46038 And that is since Jul 31 3am. If I'm not mistaken, your system is averaging one query denied every 4.6 seconds. That's not a large volume, as an average. Probably not a DDOS... A DNS server connected to the internet is very likely to get occasional q ueries. Anyone have recommendations on how to stop this? If this server is the authoritative server for domains: completely turn off recursive support. Authoritative servers should serve their authoritative domains, only. If this server offers recursive queries to your local network, use its firewall to allow traffic from the networks that are allowed to make queries, and drop all other traffic. Disable connection tracking for port 53 in your firewall. https://kb.isc.org/docs/bind-best-practices-recursive https://kb.isc.org/docs/aa-01183 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Special characters in bash strings
On 7/6/22 18:41, H wrote: To my consternation this worked fine in some places but not in others. It might be easier to explain if you had an example of where it worked. The bash man page has a section titled "EXPANSION" that details the order in which expansions happen. Since tilde expansion happens before variable expansion, the case you're discussing shouldn't work in any context (other than an eval or equivalent). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Need fstab-decode for CentOS 8
On 3/1/22 15:36, Robert Nichols wrote:
"${cmdline[@]}"
The problem there is that the last line is going to get interpreted by
a shell before anything is executed, so you now have to escape
characters that are special to the shell within a quoted string. This
is unlike the compiled fstab-decode program that invokes the execvp()
library call and avoids further shell parsing.
Does it, though?
$ bash fstab-decode.sh echo '$PATH'
$PATH
$ bash fstab-decode.sh ls '*'
ls: cannot access '*': No such file or directory
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Need fstab-decode for CentOS 8
On 3/1/22 10:29, Gordon Messmer wrote:
Chris Schanzle mentioned off-list that a tab character had been
replaced with spaces (I *knew* that should have been an attached file,
shame on me). He also suggested an improvement that removes the tab
character, so here's a second try.
Or not? Last try.
#!/bin/sh
declare -a cmdline
tab=$'\t'
eol=$'\n'
for arg in "$@"
do
arg="${arg//\\011/$tab}"
arg="${arg//\\012/$eol}"
arg="${arg//\\040/ }"
arg="${arg//\\134/\\}"
arg="${arg///\\}"
cmdline+=("$arg")
done
"${cmdline[@]}"
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Need fstab-decode for CentOS 8
On 3/1/22 08:52, Gordon Messmer wrote: If you prefer a version that you don't need a C compiler to use, here's a pure bash implementation: Chris Schanzle mentioned off-list that a tab character had been replaced with spaces (I *knew* that should have been an attached file, shame on me). He also suggested an improvement that removes the tab character, so here's a second try. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] vault.centos.org down
On 2/28/22 23:46, Simon Matter wrote: Yes, also mostly down for me. Some requests were answered but unable to really use the site. Is it just overloaded? I've seen a few examples recently of people building CentOS 8 containers by building repo definitions that reference vault. Naturally, I asked them to stop doing that... If overload is the problem, I'd suggest that making the site *less* reliable might eventually fix the problem. In particular, dropping requests for repomd.xml would probably shed a lot of load while still giving human users access to package files. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Need fstab-decode for CentOS 8
On 3/1/22 05:53, Robert Nichols wrote:
It turns out that particular wheel is best resurrected from the
fstab-decode.c file in an old initscripts source package. The encoding
is nonstandard, and the above perl code would not handle it correctly.
It's pretty close. It won't handle double backslash, and its use of
xargs is incorrect.
If you prefer a version that you don't need a C compiler to use, here's
a pure bash implementation:
#!/bin/sh
declare -a cmdline
eol=$'\n'
for arg in "$@"
do
arg="${arg//\011/ }"
arg="${arg//\012/$eol}"
arg="${arg//\040/ }"
arg="${arg//\134/\\}"
arg="${arg//\\/\\}"
cmdline+=("$arg")
done
"${cmdline[@]}"
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] stream 8 or stream 9 for new server
On 2/13/22 10:36, Joshua Kramer wrote: I wouldn't go with CentOS for something like that- all of my stuff is on Rocky 8. Using Rocky or Alma isn't going to result in a broader set of packages available on EPEL. Can I politely suggest that such suggestions don't actually address the question that was asked, and aren't helpful? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] stream 8 or stream 9 for new server
On 2/12/22 23:06, Jon LaBadie wrote: Any guesses as to when the stream 9 repos (including epel) will be fairly complete? As best I understand it: CentOS Stream's repos are complete, and significant new additions are not expected. There is no defined set of packages for EPEL, though. That package set consists merely of what Fedora maintainers have decided to build for EPEL, or have been requested. If there are packages that you need that aren't currently present, make a request: https://docs.fedoraproject.org/en-US/epel/epel-package-request/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KVM virsh console to physical console?
On 2/11/22 15:33, Lists wrote: Is there a way to "connect" the virsh console directly to a physical Linux terminal? EG: Ctl+Alt+F8 to access the Windows virsh console for Windows Server You could do something like "openvt virsh console mywindowsvm", which would run "virsh" on the first unused VT. (Assuming you've set up serial console support in the VM.) That seems like it's not a great solution in general, since it doesn't scale up to many VMs ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Any downside to mount -o noatime?
On 2/10/22 18:15, Chris Adams wrote: Unless you never write to the disk, that will still be lost in the noise of writes. But if it still bothers you, use rsync --open-noatime. I'd have suggested that, except that as far as I can tell, it doesn't apply to directories. Even with that option, the directory crawl results in lots of writes to both the source and destination volume (which stinks if the backup volume is slow, as they often are). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [EXT] c9s: CPU ISA level lower than required
On 2/7/22 09:10, Alessio wrote: Oh, well, it was plain "kvm64". Selecting "Nehalem", "SandyBridge" or "Westmere", it works. If you plan to live-migrate VMs from host to host, selecting a specific CPU which is the oldest generation CPU among the possible hosts which will run the VM is a good idea. Otherwise, you should probably select the option to copy the host CPU for best performance. If you don't do that, you're unnecessarily restricting guests from using features present in the host CPU. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ping as regular user not allowed (CentOS Stream 8)
On 1/20/22 03:13, Simon Matter wrote: But seriously, this should be a warning how dangerous even the smallest bug in systemd can be. In this case it's absolutely harmless but it shows once more how domineering systemd became to be in the Linux ecosystem. A bit frightening for me. I don't think that's particularly justified. A change was made to remove the capability from the file and instead set a kernel parameter that allows users to ping based on their GID, in order to allow ping to work from rootless containers. Systemd's only involvement here is that it loads sysctls when the system boots, and those sysctl files are bundled in its RPM. https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Echoing statements in bash script
On 1/14/22 17:18, H wrote:
Using a bash script I want to echo several strings to a file. The echo
statement, however, is in a function and thus indented but I do /not/ want the
strings echoed indented in the new file. Is this doable?
I don't think you can do that for strings passed as arguments, but you
can do that with strings that are here-documents:
https://www.oreilly.com/library/view/bash-cookbook/0596526784/ch03s04.html
So, maybe:
f () {
cat > file.txt <<-'EOF'
# this is a test
a=123
b=456
EOF
}
(Note that those lines need to be indented with tabs. None of my email
editors will compose in plain text at the moment, oddly, so those are
being converted to spaces)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
On 1/13/22 09:32, Valeri Galtsev wrote: In layman's language summary: RedHat Enterprise features (including "live" kernel patching) are to be expected _only_ in RedHat Enterprise "binary replica" distributions, which CentOS Stream is not. I don't think that's true, exactly. As far as I know, rebuild distributions never had the "Enterprise" features*. Critically, I think that a lot of people mistakenly believed that CentOS *did* have Enterprise features, because it was rebuilt from RHEL code, and that misunderstanding underlies a great deal of the negative response toward CentOS Stream. *: "Enterprise" features include but are not limited to: 1. Minor releases with independent life cycles / Extended Update Support 2. Classification for updates (security, bugfix, enhancement) 3. Live patching for kernel security vulnerabilities 4. Support ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rd.lvm.lv on CentOS Stream 9 (first-boot failure)
On 1/9/22 15:37, Gordon Messmer wrote: 1: The system also includes a volume group named "BackupGroup" and that group activates on boot (post-dracut). Why are those LVs activated when rd.lvm.lv is specified? As far as I can tell, this is because in the dracut boot process, the device backing VolGroup is activated, but the device backing BackupGroup is not. As a result, the latter device triggers a udev event after the normal root FS is mounted, and udev creates a transient systemd unit to start the BackupGroup VG. No udev event for VolGroup == no furter activation. 2: Why didn't Anaconda add the "var" LV to the kernel arguments? I still don't know the answer to this, but the current arrangement seems like a bug. As far as I know, the LVs inside VolGroup can't be activated unless that VG is complete, and if it's complete, then I can see no good reason why Anaconda should add individual LVs to the kernel command line rather than "rd.lvm.vg=VolGroup". Activating the group as a whole would fix both the boot failure resulting from lv_var not being activated, as well as the libvirt failure resulting from the guest LVs being absent. Once I replaced Anaconda's boot args with "rd.lvm.vg=VolGroup", the system works properly. 3: This seems like a change from earlier releases, but I can't find any documentation to that effect. Under CentOS 7, after dracut had finished, the remaining logical volumes in that group would be activated. Because they aren't, currently, libvirtd cannot start any of its guests until I manually activate the group. How can I restore the old behavior of activating all of the LVs on boot? I believe the regression is the result of deprecating lvmetad in favor of udev event-based activation. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] rd.lvm.lv on CentOS Stream 9 (first-boot failure)
I've install a CentOS Stream 9 system from a kickstart file that specified (among other things) several logical volumes: logvol / --fstype="ext4" --size=10240 --name=lv_root --vgname=VolGroup logvol /var --fstype="ext4" --size=4096 --name=lv_var --vgname=VolGroup logvol swap --fstype="swap" --size=2048 --name=lv_swap --vgname=VolGroup When that system rebooted, the kernel args did specify "rd.lvm.lv=VolGroup/lv_root rd.lvm.lv=VolGroup/lv_swap", but did not specify "rd.lvm.lv=VolGroup/lv_var", so boot failed because the filesystem required for /var couldn't be found. The dracut.cmdline documentation does record that it will only activate the LVs given as "rd.lvm.lv", but I'm confused about several things. 1: The system also includes a volume group named "BackupGroup" and that group activates on boot (post-dracut). Why are those LVs activated when rd.lvm.lv is specified? 2: Why didn't Anaconda add the "var" LV to the kernel arguments? 3: This seems like a change from earlier releases, but I can't find any documentation to that effect. Under CentOS 7, after dracut had finished, the remaining logical volumes in that group would be activated. Because they aren't, currently, libvirtd cannot start any of its guests until I manually activate the group. How can I restore the old behavior of activating all of the LVs on boot? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
On 1/7/22 10:36, Kenneth Porter wrote: If Stream is to be the next RHEL, wouldn't you want to test this kind of thing so the RHEL subscribers don't have to? Red Hat does not rely on end-users to test their software. (And that's definitely not what Stream is for.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
On 1/7/22 09:39, Gionatan Danti wrote: is kernel live patching working for CentOS Stream 9? https://access.redhat.com/solutions/2206511 My understanding of live kernel patching is that the feature allows systems to update specific individual kernel functions, and is primarily useful for addressing security vulnerabilities (and not, for example, for updating from one kernel version to another). I don't know for a fact, but my expectation is that CentOS Stream systems aren't going to get "live" patches because there's no ongoing support for individual kernels. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] issue with virt-install and CS9 boot iso
On 12/29/21 07:29, Leon Fauster via CentOS wrote: virt-install -l CentOS-Stream-9-20211222.0-x86_64-boot.iso I don't have CS8 host handy to check... The man page for "virt-install -l" notes that this should work if virt-install is run as root. Is it run as root? The man page also suggests that you should be able to mount the ISO to a local directory and then use that path as the argument to "-l". Have you tried that to verify that the structure of the ISO filesystem is as expected? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Qemu - enabling "bridge mode" for primary physical interface for VMs
The easiest way to set up bridged mode is to use virsh to convert the eth0 configuration to a new bridge, br0: virsh iface-bridge eth0 br0 --no-stp ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Delete local user/group but not LDAP one
On 11/25/21 21:24, Thomas Mueller wrote: at least it seems that save, that ansible * https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/user.py#L625 * https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/user.py#L640-L643 and puppet * https://github.com/puppetlabs/puppet/blob/main/lib/puppet/provider/user/useradd.rb#L12 are using it, when you specify "local=yes" or "forcelocal=true". I suppose someone should file bug reports. luserdel probably could be used to confine actions to the local host, as long as ansible/puppet provided their own libuser.conf and set the LIBUSER_CONF to the path of that file... ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Install OpenSSL 1.1.1 on CentOS Linux release 7.9.2009 (Core).
On 11/13/21 09:02, Jonathan Billings wrote: While you might be able to compile the software with those flags, you'll not be able to run anything with libraries out of the standard search path. And you don't want to add this openssl to the standard search path, because it will break packaged software. The openssl11 packages have to put the static libs and headers in an alternate location in order to be parallel-installable with the standard package, so you need to specify a header and library path when compiling. However, the *runtime* lib has a different soname, so that *is* in the standard search path: https://src.fedoraproject.org/rpms/openssl11/blob/epel7/f/openssl11.spec#_474 So, you will be able to run the resulting binary without any further changes, and there's no risk of breaking packaged software. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Install OpenSSL 1.1.1 on CentOS Linux release 7.9.2009 (Core).
On 11/9/21 09:30, Kaushal Shriyan wrote: #*./configure LDFLAGS="-L/usr/lib64/openssl11"* I believe that at a minimum, you would need: ./configure LDFLAGS="-L/usr/lib64/openssl11" CFLAGS="-I/usr/include/openssl11" ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] centos 7 mbr to gpt without loosing data
On 11/4/21 09:23, Ralf Prengel wrote: has anyone a working tutoring how to migrate a centos 7 system from mbr to gpt without loosing data. Do you mean the boot volume, or some other disk? I think your ability to do this, in any scenario, will depend heavily on your partition alignment. Where does your first partition begin? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Infiniband
On 10/8/21 10:51, Mark Woolfson wrote: I have a large server cluster running CentOS 6.4 and CentOS 6.6 using 10GbE. I want to upgrade to Infiniband. CentOS 6 hasn't received any feature updates since May 2017, so any compatible hardware would have had to be released and supported before that date (possibly substantially before then). CentOS 6 has been EOL for almost a year, and isn't receiving any security updates. You *really* should upgrade. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Find out which process consumed Network bandwidth
On 9/13/21 18:47, MRob wrote: While you probably can't recover such information for past events, going forward, iptables can help you figure this out. Putting an IPtables rule in the OUTPUT table prior to ACCEPTing the packets can help, e.g.: iptables -A OUTPUT -p tcp -m owner --uid-owner nginx -j ACCEPT OUTPUT and "-m owner" are only going to work for outgoing connections, initiated by nginx, which probably isn't much for most systems that aren't reverse proxies. Most of the time, if you want iptables to track the amount of traffic for a specific service, you'll need one or more rules inserted at the beginning of the INPUT chain, before the typical first rule that allows RELATED and ESTABLISHED packets. You could have one rule that allows all traffic to the service port (a stateless rule), or you could have one rule that allows ESTABLISHED traffic to the service port and one that allows NEW,UNTRACKED traffic to the port (stateful rules) That is nice solution! Why do you add a new output rule rather you can look at the existing port rule: # iptables -v -L | grep https xxx yyy ACCEPT tcp -- any any anywhere anywhere tcp dpt:https ctstate NEW,UNTRACKED xxx is number packets, yyy is number bytes. If adding OUTPUT rule, what is gained? Because the rule you're looking at only matches NEW and UNTRACKED packets, so it's usually only a record of the TCP SYN packets that initiated connections. If you want a byte count of the traffic for that service, this rule won't provide that. The nginx logs are the most detailed and usually the most useful record of traffic used, but accounting through iptables is also an option. Though, if you're interested in the sort of less detailed logs that you'll get from iptables, then I'd suggest what you want might be NetFlow data: https://www.linuxnetflow.com/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Troubles expanding file system.
On 9/1/21 9:42 AM, Jeff Boyce wrote: 6. I suspect that I need to rescan the devices on Sequoia so that it recognizes the increased space that has been allocated from the extended the logical volume. But when I did that (command below) it came back with a no such file or directory. echo 1 > /sys/class/block/vde1/device/rescan If you look at the content of /sys/class/block/vde and vde1, you'll see that vde has a device subdir, and vde1 does not. You can't rescan a partition. Rescan the *drive* echo 1 > /sys/class/block/vde/device/rescan ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 7/8/21 11:13 PM, Nicolas Kovacs wrote: This being said, things have changed, and Microsoft is now - amongst other things - the most important contributor to the Linux kernel in sheer terms of lines of code. I don't think that's true. Microsoft has, infrequently, appeared in the top 5 for specific releases. Mostly, as I understand it, those were due to large dumps of Hyper-V related code. Overall, Microsoft doesn't appear to be active in the Linux kernel, though they do have a large number of Open Source projects of their own. In general, Intel and Red Hat seem to be pretty consistently the top two corporate contributors to the Linux kernel. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Security Updates not properly flagged
On 6/21/21 4:53 AM, Gionatan Danti wrote: Historically the CentOS team refused to provide such metadata due to the added work required. Now with Stream, and the demise of classic CentOS, security updates are even less probable (ie: a rolling release is often wholly updated). CentOS Stream is not a rolling release. It gets "rolling updates," but that just means that there are no point releases within a major release, and that updates aren't delayed in order to group rebased packages together at 6 month intervals. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Multiple NICs, different IP Networks and routing centos 8
On 6/15/21 7:18 AM, Götz Reinicke wrote: Till now I was not able to figure that out, how do I configure such a setup in centos? You're looking for documentation on "multi-homed" networking or "policy based routing". This is the shortest document that looks like it will work from a quick search for "multihomed centos": https://dvsn.io/post/multihomed-network-config/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Prevent a particular kernel from being deleted
On 6/4/21 9:31 PM, Frank Cox wrote: So is there a way to tell dnf to update kernels in the usual manner but always keep a certain installed version until otherwise instructed? Not that I know of. You could increase "installonly_limit" in dnf.conf to a large number, and remove kernels manually rather than automatically. Or you could create a new empty dummy package that Requires: the kernel-version that you want to keep, and add that package to /etc/dnf/protected.d/. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Static configuration: prevent /etc/resolv.conf from being overwritten on first reboot
On 6/7/21 1:32 AM, Nicolas Kovacs wrote: # Generated by NetworkManager ... Q: how can I prevent /etc/resolv.conf from being overwritten on the initial reboot? Edit /etc/NetworkManager/NetworkManager.conf: [main] dns=none ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] where to get reliable/open source license manager
On 5/28/21 5:49 AM, qw wrote: I have developped one python application. I need open source license server to manage the app via local network. Where can I get this kind of open source project? It's not really clear (to me, anyway) what you're asking for. What would the application you're looking for *do*? Are you looking for something like flexlm? Are you licensing your python application on a per-seat basis? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OpenSSH 8.6/8.6p1 on CentOS Linux release 7.9.2009 (Core)
On 5/25/21 5:31 AM, Kaushal Shriyan wrote: Is there a way to validate if the above Key exchange, Cipher and MAC algorithms address the vulnerabilities? What vulnerabilities are you trying to address? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/30/21 11:36 AM, R C wrote: No, I think you've completely missed the point that I was making, which was simply that criticism of CentOS Stream often mistakenly argues that because of the change, users of CentOS lose things that they never had to begin with. I don't know for sure if that argument was ever made, but if it was, they are entirely correct. Again, it was for free, it is up to 'them' to do something else if they wish, what ever the circumstances of their decisions. It was your choice to use it, for free, and your choice doesn't mean an obligation on their part, they don't owe you anything ... so yes, you never had it to begin with. I think we're still talking past each other, but I'll try one last time: Critics of Stream often argue that CentOS users are losing support that CentOS never had to begin with. Their argument implies that CentOS has aspects of RHEL that it does not. They are not correct. Does that make sense? Please, go back and read my earlier message again. You seem to think I am complaining that CentOS is not supported, but I am not. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/30/21 11:03 AM, R C wrote: CentOS has *never* had support from Red Hat. So what is it you expect?, get an enterprise quality OS for free, and also expect highly paid, expensive, engineers to support your need for assistance on a whim for free too? No, I think you've completely missed the point that I was making, which was simply that criticism of CentOS Stream often mistakenly argues that because of the change, users of CentOS lose things that they never had to begin with. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/30/21 6:19 AM, Valeri Galtsev wrote: Why do, you, people use “creative editing”? Cite the whole piece I said, and place your question there, don’t tear single phrase out of context. It's not "creative editing", it's quote trimming in a forum which provides threaded discussions. It's the recommended etiquette for this forum, and has been for decades. Context can be readily provided from the parent message which is available to everyone who received my reply. But if it makes you happy, I'll expand the quote and ask the question again: On 4/29/21 8:51 AM, Valeri Galtsev wrote: A. "I am going to install CentOS which is binary replica of RedHat Enterprise", so whatever works on RedHat Enterprise will work on CentOS [implying my reputation behind merely an ability to install binary packages and common sense of what binary files are there on both systems in questions] B. There is CentOS which is promised (I am borrowing your phrasing here) "WILL BE extreamly similar to RHEL + a couple months" but in the second case I can not put my reputation at stake and finish my phrase with "whatever works on RedHat Enterprise will work on CentOS". Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release? (And if you don't trust point releases, why would you use the OS at all?) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/30/21 2:32 AM, Gionatan Danti wrote: Don't get me wrong: I understand that Stream is the way forward and that things are not going to change, and this is fine. But trying to ignore the key differences (shorter support, unknown upgrade from Stream-8 to Stream-9, broken kABI, etc) is not useful to anyone. 1: shorter support CentOS support was not nearly as good as some people make it out to be. (I don't mean to denigrate the work of the CentOS maintainers, at all. I don't think this is a fault of theirs, only a realistic assessment of the consequences of the downstream placement of CentOS relative to RHEL.) Each CentOS minor version was supported for (on average) five months. At the end of that five months, there was (on average) no support for one month until the next minor release was ready and updates resumed. Compare that to RHEL, in which every major release had continuous support without gaps for ~10 years and additionally, many minor releases had support for two years. I will happily take Stream's uninterrupted life cycle over CentOS's longer but discontinuous life cycle. Criticism of Stream on this point rests entirely on the idea that CentOS's life cycle was the same as RHEL's, but that has never been true. 2: Unknown upgrade path https://wiki.centos.org/FAQ/General#How_do_I_upgrade_from_one_major_release_to_another.3F "Upgrades in place are not supported nor recommended by CentOS" https://access.redhat.com/solutions/21964 Red Hat does have *limited* support for in-place upgrades, but that is fairly recent. Again, criticism of Stream on this point rests on the idea that CentOS's upgrade path was the same as RHEL's, but that is not the case. 3: kABI changes kABI changes in CentOS with every minor release, and the best solution here is probably to treat all kernel updates the same way you treat CentOS minor update today. Use DKMS. Build reproducible package sets with Katello, or Pulp, or reposync, or Spacewalk. Test them. Promote those to production when they're ready. That's the same thing that we do, today, in enterprise environments. Stream is a *different* product, because is avoid (for the good or the bad) basically *all* things that make RHEL so special. And lets face it: kABI and long/quality support from RedHat are the only two things which make RHEL special. Stripping them from CentOS CentOS has *never* had support from Red Hat. If you want to run a stable, supported production environment while you complete testing of a new minor release, you can get that from RHEL but not CentOS. If you want to apply only security updates to a production environment to reduce risk (in the sense of both security and stability risks), you can get that from RHEL but not CentOS. If you want to call an engineer for support when you have a problem in production, you can get that from RHEL, but not CentOS. So, I will agree with you on one point: Support is the thing that makes RHEL valuable. The product is excellent, but it's not the product that Red Hat's really selling, it's the support. It's the things that their engineers do so that you don't have to, as their customer. And CentOS has never offered that. Of course, you can fill some of those gaps with your own engineering, but if you're filling those gaps with local engineering today, you should be able to fill them using Stream, too. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/29/21 8:51 AM, Valeri Galtsev wrote: but in the second case I can not put my reputation at stake and finish my phrase with "whatever works on RedHat Enterprise will work on CentOS". Why do you think that? Are RHEL (and CentOS) point releases backward compatible or not? If you trust point releases to work, why would you hesitate to trust a distribution that resembles an upcoming point release? (And if you don't trust point releases, why would you use the OS at all?) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 4/27/21 6:36 AM, Carlos Oliva wrote: I have heard that Stream is beta releases of RH -- rather distressing. Is this a proper characterization? No, I don't think so. I think a better characterization would be: Rawhide is a development (beta?) release. Fedora is a stable release. CentOS Stream is a stable LTS release. RHEL is a stable LTS release with semantic versioning of the distribution as a whole (and point releases which are themselves branches of the main release). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] "System error" when trying to logon via SSH to CentOS 8 joined to AD
On Mon, Mar 22, 2021 at 11:10 PM Konstantin Boyandin via CentOS
wrote:
> I joined a CentOS 8 box to an AD, using the below document as general
> guide:
How general? Can you describe what you've done that differed from the guide?
> When I comment a line in /etc/pam.d/password-auth (the one commented
> below), error goes away:
> #account [default=bad success=ok user_unknown=ignore] pam_sss.so
Have you checked /var/log/audit/audit.log for AVCs during login? I
suspect an SELinux error.
> $ cat /etc/krb5.conf
> [libdefaults]
> default_ccache_name = KEYRING:persistent:%{uid}
Specifically, I thought that sssd defaults to KCM storage for kerberos
credentials, not the kernel keyring. You might be seeing an SELinux
deny due to non-default ccache storage.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KVM vs. incremental remote backups
On 3/31/21 12:50 PM, Nicolas Kovacs wrote: The problem with using Rsnapshot on the VM's filesystems rather than backing up the whole VM is the time it takes to restore all the mess. All the same, backing up the VM filesystem from within the VM is the best way to back them up using rsnapshot. rsnapshot's approach of hard links and rsync necessarily means that each time a file changes, the copy in the backup set consumes the entire file size if any byte in the origin file has changed. If you're backing up VM images, you're giving up all of the efficiency that rsnapshot was designed for. I'd note that your original message said that you were transferring the entire VM image. That *shouldn't* be the case. rsync should be transferring only the changed bits over the network, but on disk you'll have an entirely new file. There are a few ways you can work around that with rsnapshot, but I'm not aware of an easy solution. One option would be to use btrfs as your backup volume and write wrapper scripts for cmd_cp and cmd_rm. Rather than the default behavior, you'd want to create a snapshot (for cmd_cp) and remove snapshots (for cmd_rm). The other option that comes to mind would be to use either XFS or btrfs as your backup volume and write a wrapper script for cmd_cp. This would be simpler, the script would just be: #!/bin/sh exec cp --reflink=always "$@" If you pursued either option, you'd want to modify the rsnapshot rsync_long_args setting, and add --inplace. Those two approaches would take advantage of CoW filesystem capabilities to conserve disk space. If you decide to pursue them, bear in mind that "du" will report that each of the resulting VM images are full size, even though that's not really the case. The only way (that I know of) to accurately measure disk use will be to run "df" before a backup and after, and compare the disk use of the filesystem. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] remote disk decryption on centos?
On 3/12/21 1:51 PM, ept8e...@secmail.pro wrote:
Hi I was reading about how unlock encrypted root partition from remote
(unattended). I'd like asking what is compatible way for this in centos
and commonly used by administrators?
What's your threat model? Are you trying to protect the system from
physical theft, or are you trying to make sure the disks aren't readable
when they're retired or fail?
For most purposes, I recommend enrolling the disk with the TPM2 chip, so
that disks can be unlocked at boot without human intervention. If theft
is a concern, you'd need to ensure that the bootloader requires a
password, and that the firmware boots only from the internal disk
without a password:
clevis luks bind -d /dev/VOLUME tpm2 '{"pcr_ids":"7"}'
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dual WAN on EL8 desktop.
On Mon, Feb 15, 2021 at 10:30 PM Thomas Stephen Lee wrote: > What is ideal is the bandwidth of two connections and half bandwidth > when one link is down. That may not be *generally* possible. You can load-balance your network streams (connections), so that you'll utilize the bandwidth of two physical links in sum, but each individual network stream is going to traverse just one physical link, and will never be faster than whichever link is selected for that stream when it is initiated. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Expand XFS filesystem on CentOS Linux release 8.2.2004 (Core)
On 3/12/21 4:45 AM, Kaushal Shriyan wrote: Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB? Can you set up an identical EC2 instance to test the process? I definitely wouldn't do this on a system with data that you need, but you *might* be able to: * create a new 1M partition at the end of the drive (not BIOS boot type) * reboot * use 'dd' to copy the content of nvme0n1p3 to nvme0n1p4 * delete the third partition and change the fourth to BIOS boot type. * resize the second partition * grub-install /dev/nvme0n1 * reboot * xfs_growfs ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Tar of files
On 3/3/21 6:53 AM, Jerry Geis wrote: When I "tar" up an archive the files have an owner bob, when I extract that to another machine bob is there also but user number is different. So when I extract bob is no longer the owner of the files but someone else. Is there a good way to account for this ? In order to answer that question, we need to know what system is creating the tar file and what system is extracting the file. There are several formats for tar archives (see the --format option to GNU tar for a list), and tar will have different options on different platforms. This process works the way you expect, by default, on CentOS systems. I can demonstrate that by creating a CentOS container, adding a user and creating a tar archive with a file owned by that user. A new container, with users that have different numeric IDs will extract that archive and preserve the file's ownership by name and not numeric IDs: $ podman run -v $(pwd):$(pwd):z -w $(pwd) -it centos:8 [root@9d60934a7390 tartest]# useradd user1 [root@9d60934a7390 tartest]# touch user1file [root@9d60934a7390 tartest]# chown user1 user1file [root@9d60934a7390 tartest]# tar cf user1.tar user1file [root@9d60934a7390 tartest]# exit $ podman run -v $(pwd):$(pwd):z -w $(pwd) -it centos:8 [root@49a5818ef7a6 tartest]# useradd user2 [root@49a5818ef7a6 tartest]# useradd user1 [root@49a5818ef7a6 tartest]# rm user1file rm: remove regular empty file 'user1file'? y [root@49a5818ef7a6 tartest]# tar xf user1.tar [root@49a5818ef7a6 tartest]# ls -l total 12 -rw-r--r--. 1 root root 10240 Mar 3 19:21 user1.tar -rw-r--r--. 1 user1 root 0 Mar 3 19:21 user1file ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recommendations for webmail client on EL8
On 3/2/21 5:42 AM, Stephen John Smoogen wrote: You may need to rebuild gcc from different source rpms to get Objective-C in EL-8. The RHEL gcc source rpms did not produce Objective-C rpms or binaries when I looked at it in 2019. That would explain the gcc rpms in the upsteam nightly repo (https://packages.inverse.ca/SOGo/nightly/5/rhel/8/x86_64/RPMS/) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recommendations for webmail client on EL8
On 3/1/21 4:31 PM, Joshua Kramer wrote: Do those scripts also handle the building of Objective-C, which is needed to build SOGo? I have been toying with this off and on, there's an independent repo somewhere that has the EL8 builds of Obj-C and SOGo, but I haven't had time to get everything set up. I'm still running on 7, where gnustep is available from EPEL. I think you'd need to manually rebuild gnustep for CentOS 8. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recommendations for webmail client on EL8
On 3/1/21 5:57 AM, Simon Matter wrote: Is there anybody running webmail on EL8? Can you make a recommendation on a certain tool? I've had good success with SOGo, and I publish scripts for building the free release as rpm packages: https://github.com/gordonmessmer/build-sogo If you decide to pay for a license, the vendor publishes their own rpm (yum) repository. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bash: return status of an assignment
On 2/27/21 4:39 PM, Skylar Thompson wrote: You can fix it if you group the assignments together: [ -z "$INSMOD" ] && (INSMOD=$(which modprobe) || INSMOD="$(which insmod)") They do need to be grouped, but if you group them with parentheses, they execute in a subshell, and the assignment is lost. They should be grouped with braces instead. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bash: return status of an assignment
On 2/27/21 1:32 PM, Kenneth Porter wrote:
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
It seems to set INSMOD to /usr/sbin/insmod, even though
/usr/sbin/modprobe is available. (Both are symlinks to ../bin/kmod.)
[ -z "$INSMOD" ] && INSMOD=$(which modprobe) || INSMOD=$(which insmod)
This should be re-written as:
[ -z "$INSMOD" ] && { INSMOD=$(which modprobe) || INSMOD=$(which
insmod) ; }
As it is currently written, if INSMOD is set previously, it will be
replaced with the output of "which insmod". That is, the final
statement will be evaluated if either INSMOD was set previously, or if
"which modprobe" exits with a non-zero status.
It's unlikely that this is a PATH issue since both modprobe and insmod
are in the same directory. The most likely explanation is that $INSMOD
had a value before that line was evaluated.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Permission denied when updating CentOS 8 Streams
On 2/19/21 12:37 AM, Mathieu Baudier wrote: - Curl error (7): Couldn't connect to server for http://mirrorlist.centos.org/?release=8-stream=x86_64=AppStream=stock [Failed to connect to mirrorlist.centos.org port 80: Permission denied] It's unusual to see EPERM on a call to connect()... The man page suggests that this can be caused by a local firewall rule or an SELinux policy. https://man7.org/linux/man-pages/man2/connect.2.html "yum" and "wget" should be running in an unconfined domain, so SELinux is *probably* not the cause. I'd take a look at the output of "iptables -L OUTPUT" first. I've tried creating local firewall rules that I'd expect to result in EPERM, but they do not, so I'm not sure what such a rule looks like. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bnxt_en :: interface renamed with a suffix
On 1/15/21 3:26 AM, Adrian Sevcenco wrote: does anyone have any idea what is going on? I disabled anything i could (to have a proper normal nic that do not act and do things behind the OS) Can be more specific about either 1: what you have disabled or 2: what you expect the interface name to be? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LTS
On 1/11/21 10:30 PM, Thomas Stephen Lee wrote: CentOS Linux can continue as Fedora LTS or something similar with a five-year life cycle. Yeah, you're describing CentOS Stream. It's an LTS distribution with a five year support cycle, similar to other LTS distributions. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote: - No chance to "yum history undo last" as there are no older packages I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense. In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback". In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback". It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/6/21 9:20 AM, Nicolas Kovacs wrote: Broken packages explained away are still broken packages. I'm not sure how your system got in to a broken state, though. If you have a working system, and one repo updates a package to remove a dependency of a currently working package, those packages will normally continue working. rpm typically knows (as it did in the warning that you posted) when applying updates would break a system, and it won't apply them. Working systems will continue working, even in the rare case that one of the unsupported ABIs changes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] fail2ban problems - not banning
On 1/6/21 2:57 AM, Gary Stainburn wrote: 2020-12-22 19:38:27,619 fail2ban.utils [1836]: ERROR 7f119e95f7f0 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='113.110.47.81' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done 2020-12-22 19:38:27,619 fail2ban.utils [1836]: ERROR 7f119e95f7f0 -- stderr: 'Error: INVALID_PORT: 0:65535' See firewalld.richlanguage(5) The port port value can either be a single port number portid or a port range portid-portid. You'll need to also transform your ports with: tr : - ports="0:65535"; for p in $(echo $ports | tr : - | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='113.110.47.81' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 11:31 PM, Nicolas Kovacs wrote: No, this was an actual problem I had back in April 2020. Upgrading from CR broke imagemagick At the time, you described that problem as: I got an alert from Yum-Cron this morning: Failed to check for updates with the following error message: Failed to build transaction: sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickCore.so.5()(64bit) I don't have enough information to say why imagemagick or php would be broken, as you said it was. What I do see is that the sclo-php72-php-pecl-imagick has a dependency on libMagickCore.so.5()(64bit), which is recorded in the rpm package. If you have a package from a third party repository (either EPEL or SCLO, or others), and it depends on one of the few packages in CentOS Stream (or CentOS, or RHEL) that aren't guaranteed to be stable, and which Red Hat changes, then yum will warn you that the update would result in unresolvable dependencies, and it won't upgrade the package. Your system will keep the old imagemagick package and the old php-imagick package until the dependencies are resolved in the two repositories, and it'll update them after that. Stream doesn't change that. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 10:47 PM, Nicolas Kovacs wrote: And in the past, things have been known to break. Activate the CR repository, and suddenly libmagick is broken because it hasn't been rebuilt yet against the new version. Are you describing an actual problem, right now, or is that an invented example? Can you provide the specifics of what yum does, or what the application does after updates? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 6:30 PM, Valeri Galtsev wrote: I was not comparing CentOS Stream with CentOS (former 10 year life cycle system), I was comparing CentOS Stream with Debian (and clones) LTS. The original message came from a CentOS user who asked "is the change a non-issue for my use-case?" So, I'd have to ask you how Debian is relevant to that question. As I said, in terms of upgrade from one major version to another, CentOS Stream and CentOS are identical. If CentOS was suitable, then the change to CentOS Stream is a non-issue in the context of major version upgrades, because the change to CentOS Stream has no material impact on that concern. The question being asked is not "what operating system should I use", to which discussion of Debian or FreeBSD might be relevant, it's "will the change to CentOS Stream impact my current processes?" Comparisons to Debian or FreeBSD are non-sequiturs in the context of this conversation. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 3:39 PM, Valeri Galtsev wrote: And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind... In that respect, CentOS Stream is identical to CentOS. Not to mention other potentially problematic areas as no package version rollback, compatibility (potential) with EPEL CentOS Stream will be compatible with EPEL to the same extent that new point releases are compatible with EPEL. The vast majority of interfaces in RHEL (and Stream) are guaranteed stable within a major release, and only a small number of interfaces that aren't. It's possible that one of the latter interfaces might change, in which case you'd expect yum to not update the dependency until EPEL's packages have been rebuilt: https://access.redhat.com/articles/rhel-abi-compatibility#Appendix ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 3:02 PM, Jamie Burchell wrote: We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though? Yes. CentOS Stream has a lifecycle comparable with other LTS distributions. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 11:32 AM, Jamie Burchell wrote: is the change a non-issue for my use-case? Probably. For a lot of users, Stream is a drop-in replacement that's better than CentOS was, because it gets updates consistently and doesn't suffer from periods in which no updates are available, including security updates. If security was a priority for you, as it was for me, then CentOS wasn't really suitable for public-facing services, but CentOS Stream might be. If you're building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you. Compiling software in a Stream build root may result in a binary that has dependencies which aren't yet available in RHEL. And if you're building kernel modules (like Phil @elrepo), then there is the issue that the kernel isn't subject to RHEL's ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed. So that situation may improve... ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 1/5/21 2:27 PM, Jamie Burchell wrote: We already automatically update our systems with yum-cron / dnf automatic and I'm reading that if we're already doing that, Stream isn't going to be a departure I'd have said the same: If you trust CentOS enough to update automatically, then Stream will be an easy migration for you. You'll get a distribution that's just as trustworthy, with the added benefit that you'll get security fixes much sooner than CentOS did. but I'm still trying to make sense of the impact in real-terms i.e. what actually changes if we move to Stream. You'll get updated versions of software when they're ready, rather than once every 6-8 months. They'll be roughly the same versions that RHEL will get later. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/4/21 3:05 AM, Leon Fauster via CentOS wrote: I would expect broken update paths. Also after EOL of CentOS Linux but not sure if they plan a new "playground" repo: EPEL-NEXT ... see here: https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/WCFRJJ3JJFTGD6UMX7WOMCS4F2EVUM5X/ https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/LI5MCJEXHLNSZ5UQHFIHGZVPSKCMFWEU/ Those threads probably aren't relevant to *users* of EPEL, just to package managers. EPEL packages are intended for RHEL installation targets. CentOS Stream won't necessarily be an appropriate build root for an RHEL installation target, since it may provide ABIs before they're available in RHEL. CentOS Stream in this context is interchangeable with RHEL X.(Y+1). RHEL X.(Y+1) is backward compatible with previous releases, but previous releases aren't necessarily forward compatible with X.(Y+1). Therefore, using the currently available release of RHEL as a build root for the next release will generally yield usable packages, but using X.(Y+1) may yield packages that aren't usable on RHEL's currently available release. But X.(Y+1) should run packages from either build root, so CentOS Stream users shouldn't typically have any problems with EPEL, regardless. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 8:05 PM, Mark LaPierre wrote: So how would one use this shiny bit of information? Is there a way to discover if an EPEL application is going to clobber your system before you install it? As long as the upstream developers observe semantic versioning, dnf would tell whether or not a package is "broken" by an update (it would have unresolvable dependencies.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 5:34 PM, Stephen John Smoogen wrote: Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL QT and GTK+ are both stable within a major release, so there's no reason to worry about those: https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel-abi-compatibility#Appendix ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is EPEL compatible with Stream?
On 1/3/21 2:51 PM, Kay Schenk wrote: is it still OK to set up EPEL as a repo? Yes. CentOS Stream is expected to be backward-compatible with RHEL, for the same reason that each RHEL point release is backward-compatible with previous point releases. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk choice for workstation ?
On 12/26/20 12:20 PM, Nicolas Kovacs wrote: Any advice from the hardware gurus on this list? I think your request lacks at least one critical consideration: What is the cost of down time? You've got a RAID1 setup now, so I have to assume that you've decided at some point in the past that the down time you'd incur replacing a disk when one fails is great enough to buy a second disk. SSDs aren't immune to failure. Right now, I'm operating on a degraded RAID1 volume while I wait for an RMA for a SAMSUNG 860 QVO that I installed just over one year ago. For me, the cost of the outage justified the redundant storage device. It was expensive, but it's a cost that paid off this year. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/17/20 5:54 PM, Konstantin Boyandin via CentOS wrote: It's purely a developer's distro. Has Chris Wright ever recommended CentOS for any purpose other than development and testing? Shall I explain difference between a developer's distro and the one suitable for production servers (a rhetoric question)? How did you imagine you would look when you asked a CentOS maintainer if he understands the importance of the thing he's been doing for 17 years? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Status of DLM in CentOS?
On 12/9/20 2:16 AM, Michael Schwartzkopff wrote: I was searching for DLM for my Centos 8. But it seems there are no packages available. The "dlm" kernel module is included in the standard kernel. Locks are configured with the "pcs" package. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/15/20 7:59 PM, Joshua Kramer wrote: Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta? Indeed. Often, when you can't find a reasonable answer to a question, it is because the premise of the question itself is wrong. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/13/20 1:32 PM, Ljubomir Ljubojevic wrote: On 12/13/20 8:56 PM, Gordon Messmer wrote: On 12/13/20 2:45 AM, Ljubomir Ljubojevic wrote: When people are happy with something they do not voice their content on the mailing list, mailing list is only to voice your discontent. You heard about "silent majority", right? Ever though why it is called that? So, the majority of users are silent, because they're happy? Cool. HAHAHAHAHA, what a wonderful imaginary world you live in:-D I'm just trying to determine whether you were making the argument you intended to, because you are literally suggesting that the majority is silent, and the people who are silent are the ones that are happy with something. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/13/20 2:45 AM, Ljubomir Ljubojevic wrote: When people are happy with something they do not voice their content on the mailing list, mailing list is only to voice your discontent. You heard about "silent majority", right? Ever though why it is called that? So, the majority of users are silent, because they're happy? Cool. Point is that RH DID slow down build of clones due to this change Your memory is still rusty. Early accusations were that this would impact developers (such as Oracle) who were adding additional patches to the kernel, or other maintenance. It never impacted "clones" like CentOS at all. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] question centos stream 8 applying updates
On 12/11/20 10:19 AM, Gordon Messmer wrote: Just one ten-year long release. My mistake: Stream releases are five-year long releases (RHEL's "full" support period). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] question centos stream 8 applying updates
On 12/10/20 2:53 PM, edward via CentOS wrote: after reading some info on centos stream is a rolling release. i'm wondering applying It's not a "rolling release" in the most commonly used sense. There just isn't a minor number for releases. CentOS Stream 8 will always be CentOS Stream 8, and never 8.1 or 8.2, etc. Just one ten-year long release. At any given point in time, a fully updated system should be backward-compatible with any applications that have run earlier in the release cycle. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 8-stream dnf overly verbose
On 12/11/20 8:31 AM, Matthew Miller wrote: Also, WOAH. I just noticed that CentOS Stream bugs are to be filed as _actual versions of RHEL 8 and RHEL 9_. That's amazing. I don't usually like to reply when I have nothing to add, but that is *holy cow* level of amazing. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/11/20 8:00 AM, Sergio Belkin wrote: how could you ask trust and confidence with something like that: I'll repeat what I said earlier, CentOS has never offered the things people are complaining about losing. They've never asked for your trust and confidence. Both Red Hat and the CentOS maintainers have always referred users who needed "trust and confidence" to RHEL. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/10/20 6:28 PM, Konstantin Boyandin via CentOS wrote: Allow me to disagree. We both trust Chris Wright's words, don't we? CTO won't lie. Citing him: "To be exact, CentOS Stream is an upstream development platform for ecosystem developers. It will be updated several times a day. So, like Fedora? People run servers on Fedora now, and I think that's fine. This is not a production operating system." Does he say that CentOS is a production operating system? As far as I know, Red Hat has never endorsed running CentOS in production, so I don't understand why it's significant that they also don't endorse running CentOS Stream in production. And even if I reduce the number of CentOS Stream upgrades to minimal one, the base advantage of CentOS is lost: predictability. It's really difficult for me to look at a distribution that just stops getting updates for 4-6 weeks, twice a year, and use the word "predictable" to describe it. My first reaction to the announcement was pretty negative, too. But when I stepped back and looked at the current situation *real* honestly, I had to admit that CentOS just doesn't offer any of the things that people are complaining about losing. And I hope that the CentOS maintainers don't interpret that as criticism, because it isn't intended to be. They've always maintained that if you need updates/patches in a timely manner, then you should be paying Red Hat for RHEL. I agreed with them then, and I still do. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] I'm looking forward to the future of CentOS Stream
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
