Re: [CentOS] Question about virt-manager Version 9.1
This may provide the answer you are looking for: it's being deprecated in favor of Cockpit. https://bugzilla.redhat.com/show_bug.cgi?id=2030592 On Fri, Feb 10, 2023 at 6:58 AM Günther J. Niederwimmer wrote: > hello list, > > I switched to version 9 (not redhat) on my "new" server, and that worked. > But > after updating to 9.1, the virt-manger doesn't work anymore? There are > only > more error messages when opening the 2nd window for the settings. > > I hope someone on this list can help? It's a beloved tool which for me is > the > easiest way to create a KVM machine. > > thanks for any help, > -- > mit freundlichen Grüßen / best Regards, > > Günther J. Niederwimmer > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Looking for a RAID1 box
Look at HP Microserver line... it's as close as you're going to get. On Tue, Jan 3, 2023, 5:22 PM Robert Moskowitz wrote: > And I am just coming up empty on my searches. > > My search foo has been really off, it seems. > > On 1/3/23 17:13, Robert Heller wrote: > > At Tue, 3 Jan 2023 16:55:40 -0500 Robert Moskowitz wrote: > > > >> Help? > >> > >> I am looking for a box I can drop Centos or one of the spinoffs that: > >> > >> Has RAID1 internal (not an external USB RAID thing) > >>    Can be software or hardware > > All modern Linux kernels include software RAID out-of-the-box. This > means any > > system that supports more than one disk that you can install Linux on > > (including CentOS) can be set up with Linux software RAID. If you want > > hot-swap, there are various SATA hot-swap units than can be mounted in a > ATX > > case with front 5" or 3" spaces. A modern ATX motherboard with a AHA > SATA > > controller will support Linux, including hot-swap SATA disks, including > SATA > > connected SSDs. > > > >> small (4TB/drive fine) and low power > >> > >> I plan to use it ONLY for email server. perhaps iRedMail > >> > >> I have spent a lot of time looking and not finding any such piece of > metal. > >> > >> All I find are NAS boxes with their own OS. > >> > >> thanks > >> > >> Bob (frustrated) > >> ___ > >> CentOS mailing list > >> CentOS@centos.org > >> https://lists.centos.org/mailman/listinfo/centos > >> > >> > > > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS7 latest kernel still does not run KVM guests
"In fact, the system runs great on the newest kernel, right up to the point where a VM is started. It will run for days as long as I never start a VM. Start a VM and BAM! It is hung hard." Are you required to use "official supported kernels" or do you have some flexibility? My main KVM host is a Centos 7 box and I'm using kernel-ml from elrepo-kernel. The kernel version usually tracks with recent kernel releases- on my el9 boxes it's currently at 6.1- but I'm running 5.19 on my Centos 7 KVM host with no issue. On Tue, Dec 20, 2022 at 10:24 AM Bill Gee wrote: > Hmmm I have dealt with bad power supplies. I doubt it is the > problem in this case. If it were a power supply, then why does the > system work perfectly on the older kernel? > > In fact, the system runs great on the newest kernel, right up to the > point where a VM is started. It will run for days as long as I never > start a VM. Start a VM and BAM! It is hung hard. > > === > Bill Gee > > On 12/20/22 08:30, Christopher Wensink wrote: > > I have had two different Router machines do something similar on the > > IPFire OS, and the core cause ended up being power related. One power > > supply was intermittently dying with the whole system hanging, and the > > only option was a hard reset. The second system also had issues with > > the hard drive and also the power supply. These units were Mini ITX > > boards, Super micro Sys-E200-9B with the Pentium N3710 Quad Core, > > System-on-chip, 8GB Ram, 120 GB SSD, Quad NIC Cards, and they used > > external 60W DC power adapters similar to a higher end laptop style. > > > > I don't blame the manufacturer, I think it was an issue with the power > > supplies going bad. > > > > Chris > > > > On 12/20/2022 8:16 AM, Bill Gee wrote: > >> Hi Johnny - > >> > >> Yipes, I hate problems like this! > >> > >> The host computer is a SuperMicro C2SBC-Q mainboard. The processor is > >> an Intel Core2-Quad Q9400. Yes, it is x86_64 architecture. The > >> display adapter is an older nVidia GeForce 8400 GS, and I use the > >> nouveau driver for it. Selinux is disabled. > >> > >> The guest machines are Fedora 37 and CentOS7. > >> > >> So far I have found no log files with anything useful. The hang > >> happens so quick that nothing gets logged. Here is a section of > >> /var/log/messages. Notice the gap at 06:32 to 06:43. This is where I > >> started a virtual guest and the system hung. At reboot I chose a > >> different kernel. > >> > >> == > >> Dec 20 06:32:26 practice7 systemd: Starting Fingerprint Authentication > >> Daemon... > >> Dec 20 06:32:26 practice7 dbus[750]: [system] Successfully activated > >> service 'net.reactivated.Fprint' > >> Dec 20 06:32:26 practice7 systemd: Started Fingerprint Authentication > >> Daemon. > >> Dec 20 06:32:26 practice7 dbus[750]: [system] Activating via systemd: > >> service name='org.freedesktop.realmd' unit='realmd.service' > >> Dec 20 06:32:26 practice7 systemd: Starting Realm and Domain > >> Configuration... > >> Dec 20 06:32:26 practice7 dbus[750]: [system] Successfully activated > >> service 'org.freedesktop.realmd' > >> Dec 20 06:32:26 practice7 systemd: Started Realm and Domain > >> Configuration. > >> Dec 20 06:32:48 practice7 systemd: Starting Stop Read-Ahead Data > >> Collection... > >> Dec 20 06:32:48 practice7 systemd: Started Stop Read-Ahead Data > >> Collection. > >> Dec 20 06:43:08 practice7 journal: Runtime journal is using 8.0M (max > >> allowed 391.0M, trying to leave 586.5M free of 3.8G available → > >> current limit 391.0M). > >> Dec 20 06:43:08 practice7 kernel: microcode: microcode updated early > >> to revision 0xa0b, date = 2010-09-28 > >> Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpuset > >> Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpu > >> Dec 20 06:43:08 practice7 kernel: Initializing cgroup subsys cpuacct > >> Dec 20 06:43:08 practice7 kernel: Linux version > >> 3.10.0-1160.76.1.el7.x86_64 (mockbu...@kbuilder.bsys.centos.org) (gcc > >> version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed Aug 10 > >> 16:21:17 UTC 2022 > >> > >> == > >> > >> Is there anyplace else I should look for log files? Is there a way to > >> get verbose logging? > >> > >> How might I check for a kernel panic? The display never says anything > >> about a kernel panic - it just hangs. > >> > >> Thanks! > >> > >> === > >> Bill Gee > >> > >> On 12/20/22 07:25, Johnny Hughes wrote: > >>> On 12/20/22 06:50, Bill Gee wrote: > The two latest kernels for CentOS7 are complete fails for running > KVM and QEMU guest machines. > > Version 3.10.0-1160.76.1 works correctly. Both 3.10.0-1160.80.1 and > 3.10.0-1160.81.1 will hang within seconds of launching any virtual > machine. It is a HARD hang. I have to pull the power cord from the > computer in order to regain control. > > Since 81.1 came out within the last few
Re: [CentOS] Where can I find more information on the recent update to the 4.18.0-373 kernel
That's great Kay, thanks for the info! Question, if you don't mind my asking: how new is your hardware? The reason I ask is that certain newer Intel processors (11th generation mobile "Tiger Lake" i5 and i7) have a thermal issue where it's throttled down to 400MHz in certain heavy loads. There is a fix coming for this in 5.18 and I'm not sure if RedHat is going to backport it to earlier kernels. (There is a stopgap to this, if you replace the thermald package with a thermald version 2.4.9 or later the problem isn't as bad.) On Wed, Apr 20, 2022 at 5:17 PM Kay Schenk wrote: > Hi Joshua, and list... > > I got the non-workng sound driver for Intel HDA fixed with my kernel > 4.18.0-373. > > After removing the extra kernel flag i915_alpha from my command line > > (see instructions when this module really was alpha -- > > > https://access.redhat.com/discussions/3410491#understanding-kernel-command-line-parameters_configuring-kernel-command-line-parameters), > > > > I used the instructions given by > > Syaifur Rizal <https://ask.fedoraproject.org/u/oprizal> > > in this post... > > https://ask.fedoraproject.org/t/audio-devices-not-listed/19344 > > I had a feeling I needed a modprobe.d entry but I didn't know what the > syntax would be. > > In any case, posting more info in case anyone needs it. > > On 4/20/22 10:54, Kay Schenk wrote: > > > > Thank you Joshua. If I can't get this resolved by the end of this > > week, I'll use your suggestion. > > > > On 4/19/22 15:32, Joshua Kramer wrote: > >> I'm not sure how much freedom you have with your setup, but you could > >> always try to use the elrepo-ml or elrepo-lt kernels. The elrepo-ml > kernel > >> follows the published version pretty closely, so for example right now > I'm > >> running 5.17.3 on my el8 boxes. The newer kernels solve a lot of > hardware > >> issues. > >> > >> On Tue, Apr 19, 2022 at 5:54 PM Kay Schenk > wrote: > >> > >>> Hello folks -- > >>> > >>> Is there any write up for the most recent update to kernel 4.18.0-373 > >>> specifically with respect to sound setup or anything really? I had been > >>> using an "alpha" driver for my Intel sound that was appended to my boot > >>> line up until this latest. This not only did not work but caused > >>> continual hangs. Edited the 4.18.0-373 kernel line and things got > >>> somewhat better...butthis version is loading A LOT of modules and > do > >>> I really need them, etc. > >>> > >>> I am going through a lot of grief with this recent upgrade. > >>> > >>> Thanks for any help... > >>> > >>> -- Kay > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ___ > >>> CentOS mailing list > >>> CentOS@centos.org > >>> https://lists.centos.org/mailman/listinfo/centos > >>> > >> ___ > >> CentOS mailing list > >> CentOS@centos.org > >> https://lists.centos.org/mailman/listinfo/centos > > -- > > - > > -- > --- > "Do what you can, with what you've got, > where you are." >-- Theodore Roosevelt > MzK > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Where can I find more information on the recent update to the 4.18.0-373 kernel
I'm not sure how much freedom you have with your setup, but you could always try to use the elrepo-ml or elrepo-lt kernels. The elrepo-ml kernel follows the published version pretty closely, so for example right now I'm running 5.17.3 on my el8 boxes. The newer kernels solve a lot of hardware issues. On Tue, Apr 19, 2022 at 5:54 PM Kay Schenk wrote: > Hello folks -- > > Is there any write up for the most recent update to kernel 4.18.0-373 > specifically with respect to sound setup or anything really? I had been > using an "alpha" driver for my Intel sound that was appended to my boot > line up until this latest. This not only did not work but caused > continual hangs. Edited the 4.18.0-373 kernel line and things got > somewhat better...butthis version is loading A LOT of modules and do > I really need them, etc. > > I am going through a lot of grief with this recent upgrade. > > Thanks for any help... > > -- Kay > > > > > > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Compatible SATA controller needed
PCIe SATA controllers (and perhaps even PCI SATA controllers) are a dime a dozen on Amazon. I've purchased a few and they just worked with Linux. On Sun, Mar 27, 2022 at 4:34 PM Pete Geenhuizen wrote: > I've gone through the BIOS and tried all the combinations that were > available but still no joy. I used ELRepo's method of determining the > card type, and the result was none yielded a positive result. > > After trying all combinations my only course of action is to fins a > card that is compatible and ignore the controllers that I currently have. > > Thanks > > On 3/27/22 16:08, Robert Heller wrote: > > At Sun, 27 Mar 2022 12:23:21 -0700 CentOS mailing list > wrote: > > > >> On Sun, Mar 27, 2022 at 11:55 AM Pete Geenhuizen > >> wrote: > >> > >>> I'm trying to install Centos 8 on an older PC but it fails because the > >>> SATA controller isn't supported. > >>> Anyone have a source for a PCI/ePCI controller card that is compatible > >>> with Centos 8? > >>> Thanks > >>> Pete > >>> > >> Your controller might be supported by one of the ELRepo's kmod packages. > >> This can be checked if you provide the device ID pairing [:] as > >> reported by 'lspci -nn'. > > Also: what BIOS mode is the SATA controller operating in? The SATA > firmware in > > some PCs implement various "weird" modes, including "RAID" (no, not > really > > hardware RAID, just some kind of half BIOS half MS-Windows driver > software > > RAID hack), Make sure the SATA controller is in AHCI mode and not in some > > other mode. If it is in AHCI mode, it might just work out-of-the-box. > > > >> Akemi > >> ___ > >> CentOS mailing list > >> CentOS@centos.org > >> https://lists.centos.org/mailman/listinfo/centos > >> > >> > >> > > -- > Unencumbered by the thought process. > -- Click and Clack the Tappet brothers > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 9 and gtk-spice
Hello- Before I open a bug report on this, I wanted to ask if there is a specific reason that spice-gtk is not in the OS repositories of EL9? It looks like I have to install the ovirt repositories before I get access to spice-gtk and its dependencies. Thanks! -JK ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] stream 8 or stream 9 for new server
I wouldn't go with CentOS for something like that- all of my stuff is on Rocky 8. On Sun, Feb 13, 2022 at 2:07 AM Jon LaBadie wrote: > I'm replacing my ancient desktop home server > (CentOS 7, email, dns, backup) with a new mini-server. > > I've been running stream 9 on the new toy for a couple > of weeks and I find there are still a lot of incomplete > or missing things. Enough to delay full implementation. > Unless I do some workarounds or compile from source. > > On the other hand I've read there will be no migration > path from stream 8 to stream 9. It will require a > complete reinstall. > > Any guesses as to when the stream 9 repos (including > epel) will be fairly complete? Just trying to decide > whether to wait a bit or go with stream 8. > > Jon > > -- > Jon H. LaBadie j...@labadie.us > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Any downside to mount -o noatime?
You may get just as much SSD "savings" by putting /var/log and /tmp into a RAM disk. I do this with all of my Raspberry Pi's, since SD cards burn through pretty quickly, and I have several that haven't had their SD cards replaced in a couple years. On Wed, Feb 9, 2022 at 5:10 PM Kenneth Porter wrote: > I'd like to reduce the wear-and-tear on my SSDs and eliminate the > unnecessary metadata writes on my backup media that only slow down the > backup process. So I want to add noatime to all my mounts. Is there any > downside to this? > > At one time I remember atime being useful for tmpwatch, which removes > files > in /tmp that haven't been accessed in a week or two. But I can live > without > that feature. > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT Help: Zoneminder
I ran ZoneMinder for quite a while and then I ran into random problems similar to what you described (as well as others). After spending 6 hours trying to figure out what the issue was, I decided to see if there were any alternatives. 2 hours later I had MotionEye running on my video server with all of my cameras displaying great. MotionEye is a LOT more lightweight than ZoneMinder; it's Python based. On Fri, Oct 15, 2021 at 10:22 AM TE Dukes wrote: > Sorry for the off topic post but I have run out of options an hoping > someone > here can help. > > I have been running Zoneminder for a very long time. Its had its bumps in > the road as anything else but generally works well. > > Currently running Zoneminder 1.36.8 on CentOS 7 . > > The problem started back in June after an upgrade. When events are played > back, the first one plays fine, then it's a blur as in the faster than > light > drive kicks in. Supposedly, there is supposed to be some kind of pause > between event playback that keeps this from happening. > > I posted this issue on their forum, > https://forums.zoneminder.com/viewtopic.php?f=43&t=30955&p=122258#p122258 > and on their Github, https://github.com/ZoneMinder/zoneminder/issues/3359 > but have had no replies. There is a similar issue on github back in 2015, > but the file in question has been changed since that time. > > I have thought about uninstalling and re-installing the version that was > working prior to the upgrade but I don't think its Zoneminder. I think it > could be something else causing the problem. > > The problem occurs when playing back events using Firefox and Edge on a > Win10 PC and it does the same playing back events with Firefox on the > server > itself. > > TIA > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] video driver for NVIDIA Quadro
@Johnny Hughes- what version of the nVidia drivers did you have problems with, and what were the problems? I'm just curious. I have a Latitude E7450 with an M840 chipset and I've never had problems compiling or getting them to work under stock CentOS 8 kernels. On Fri, Apr 9, 2021 at 12:54 PM Johnny Hughes wrote: > On 4/9/21 11:43 AM, Phil Perry wrote: > > On 09/04/2021 16:40, R C wrote: > >> > >> On 4/9/21 9:24 AM, Johnny Hughes wrote: > >>> On 4/7/21 6:44 PM, R C wrote: > Hello, > > > I am running Centos/RHEL 8 on a Dell precision M6800/6700 with a: > NVIDIA > Corporation GK104GLM [Quadro K3100M] > > > Is there a driver for that one? or am I stuck with nouveaux ? > > >>> The kernel included in CentOS-8 (the last time I tested it), did not > >>> properly build and run the proprietary NVIDIA drivers .. neither did > the > >>> same kernel in RHEL. > >> > >> I found out, trying to install the driver, the NVIDIA installer was > >> complaining. (I was pointed to where the latest driver for it was, by > >> Nvidia (which surprised me a bit that they were still maintaining it > >> actually, at least it's the impression I have) > >> > > > > The GK104GLM [Quadro K3100M] _should_ be supported by the latest NVIDIA > > driver (currently v460.67) on el8. I say _should_ as I'm not 100% sure. > > I'm assuming your device is as below (check the device IDs with 'pci > -nn'): > > > > [10de:11b6] NVIDIA Corporation GK104GLM [Quadro K3100M] > > > > That device was previously listed as supported: > > > > > https://download.nvidia.com/XFree86/Linux-x86_64/410.66/README/supportedchips.html > > > > > > but I can't find it listed on the currently supported chipset's page, > > hence my doubt: > > > > > https://download.nvidia.com/XFree86/Linux-x86_64/460.67/README/supportedchips.html > > > > > > I'd be interested to know which driver version NVIDIA pointed you > towards? > > > >>> > >>> What I did was shift my workstation install to the elrepo kernel-ml > >>> kernels (you might want kernel-lt .. it is latest long term kernel). I > >>> can then build the latest NVIDIA drivers for my graphics card and use > >>> them. > >>> > >>> http://elrepo.org/tiki/kernel-ml > >>> http://elrepo.org/tiki/kernel-lt > >>> > >>> I have no issues using the elrepo kernels .. those guys and gals are > >>> outstanding. All the stuff they do is great. > >>> > >>> My card is a 1080ti .. so I have not tried building for Quadro 3100M .. > >>> but if NVIDIA has a linux driver for that, then it should build using > >>> the elrepo kernels. > >>> > >>> Phil Perry can tell us if the NVIDIA drivers they carry actually now > >>> work for EL8 .. i stopped trying it after I switched kernels as they > >>> don't carry drivers on elrepo for the kernel-ml or kernel-lt and I just > >>> rebuild the official NVIDIA drivers manually after every kernel update. > >> > >> That was sort of my plan, to see and wait if things would work with > >> later kernels. Fr now my desktop seems to be working ok-ish. When my > >> desktop is up for over 10-12 hrs, there seem to be some flickering, > >> windows that 'switch' focus etc, and at times the gnome desktop flat > >> out crashes (the machine keeps running, but no gnome. > >> > > > > Assuming it is supported by the latest v460.67 driver, and the above > > omission is a mistake, ELRepo have a driver (kmod-nvidia) which should > > work with the el8 distro kernel. > > > > As Johnny says above, if you use a different kernel, such as those from > > elrepo, you will need to install the driver directly from NVIDIA. > > > > Thanks Phil. > > I MIGHT try shifting back to the main CentOS kernel and see if they have > fixed the issue I was having loading NVIDIA drivers. If I ever have any > spare time on my hands :) > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ 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
Hi Konstantin, Debugging login issues between SSD, PAM, and AD is not for the faint of heart. In my case I set up Samba 4.3 as a primary AD DC. I could login with Windows 10 guests but not C8. I just did the following. 1. I spun up a fresh C8 VM, did not add any users, selected a graphical desktop. 2. I added a new user into my AD domain (the one being served by Samba4) 3. When my VM booted, the "first boot" screen appeared. As I went through the steps, when it prompted me to add a user, I clicked on "Configure Enterprise Login" 4. The system automatically found my domain name. I entered the username/password I created. 5. The system prompted for the Domain Admin password, which I entered it. 6. After a few seconds. everything was set up, and I could ssh in to the box in question using the following (keeping in mind that capitalization is important, especially when it comes to AD domain names!): ssh -l j...@my-domain.as authtest-el8 I was able to login using this procedure. You might try the same thing, and then compare your pam, sssd, and krb5 config files with the fresh VM and the VM you are trying to get working. -JK On Tue, Mar 30, 2021 at 7:01 AM Konstantin Boyandin via CentOS < centos@centos.org> wrote: > Do I understand correctly that this problem > - is too trivial > - isn't in fact CentOS-related > - never happened to anyone else ? > > There are no good explanations as far as I see, to such PAM behavior. I > would appreciate advice on where else to ask about this (the mentioned > quick fix doesn't look too good). > > Thanks. > > Sincerely, > Konstantin > > On 23.03.2021 13:09, Konstantin Boyandin via CentOS wrote: > > Hello, > > > > I joined a CentOS 8 box to an AD, using the below document as general > > guide: > > > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/connecting-rhel-systems-directly-to-ad-using-sssd_integrating-rhel-systems-directly-with-active-directory > > > (section 14.1) > > > > A problem: after I tried to log on via SSH (as an AD user) to the box, > > the journalctl gets the below records: > > > > March 23 12:41:01 sandbox.lan sshd[2262]: pam_sss(sshd:auth): > > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > > rhost=10.10.0.55 user=username > > March 23 12:41:01 sandbox.lan sshd[2262]: pam_sss(sshd:account): Access > > denied for user username: 4 (System error) > > March 23 12:41:01 sandbox.lan sshd[2262]: Failed password for username > > from 10.10.0.55 port 57610 ssh2 > > March 23 12:41:01 sandbox.lan sshd[2262]: fatal: Access denied for user > > username by PAM account configuration [preauth] > > > > Quick and dirty fix: > > > > When I comment a line in /etc/pam.d/password-auth (the one commented > > below), error goes away: > > === /etc/pam.d/password-auth below > > auth > required pam_env.so > > authrequired pam_faildelay.so delay=200 > > auth[default=1 ignore=ignore success=ok] > pam_usertype.so > > isregular > > auth[default=1 ignore=ignore success=ok] pam_localuser.so > > auth > sufficient pam_unix.so > > nullok try_first_pass > > auth[default=1 ignore=ignore success=ok] > pam_usertype.so > > isregular > > auth > sufficient pam_sss.so > > forward_pass > > auth > required pam_deny.so > > > > account > required pam_unix.so > > account sufficient pam_localuser.so > > account > sufficient pam_usertype.so > > issystem > > #account [default=bad success=ok user_unknown=ignore] pam_sss.so > > account > required pam_permit.so > > > > passwordrequisite pam_pwquality.so try_first_pass local_users_only > > password > sufficient pam_unix.so > > sha512 shadow nullok try_first_pass use_authtok > > password > sufficient pam_sss.so > > use_authtok > > password > required pam_deny.so > > > > session > optional pam_keyinit.so > > revoke > > session > required pam_limits.so > > -session > optional pam_systemd.so > > session optional pam_oddjob_mkhomedir.so umask=0077 > > session [success=1 default=ignore] pam_succeed_if.so service in > > crond quiet use_uid > > session > required pam_unix.so > > session > optional pam_sss.so > > === /etc/pam.d/password-auth above > > > > If I understand correctly, the commented line means "account is invalid > > by default; if found in SSSD, it's good; if not found - ignore and > > proceed". Commenting it is not a good idea, but I
Re: [CentOS] Disk read io very high, but no process perform io read
Install a program called iotop. iotop will show you, in real time, which processes are using the most i/o bandwidth. On Fri, Mar 5, 2021 at 2:54 AM yf chu wrote: > > We have experienced a very weird problem. The load of the server machine is > very high. We use "pidstat" and find that the disk read io is very high. > But the processes running on this server do not perform any disk read > operation. > We also noticed that when we execute "top" command, for most of processes, > the values in "SHR" column are zero. > Compared with other normal servers, we found that by executing "free -m", the > result shows that the buff/cache value in this server is lower than the value > of other normal servers. > We also found that there were lots of major page faults by executing "ps -o > majflt,minflt". > Swap is not enabled on this server. What could be the reason for this issue? > > > The centos version:CentOS Linux release 7.3.1611 > kernel version:3.10.0-693.21.1.std7a.el7.0.x86_64 > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recommendations for webmail client on EL8
> I've had good success with SOGo, and I publish scripts for building the free release as rpm packages: 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. On Mon, Mar 1, 2021 at 2:03 PM Gordon Messmer wrote: > > 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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On Fri, Dec 18, 2020 at 11:29 AM Johnny Hughes wrote: > People who certify things, who certified CentOS Linux for things, are > free to evaluate and do that with CentOS Stream as well. This is what makes me think this isn't as bad as people made it out to be. (And yeah, I take full responsibility for being one of those 'people' LOL). For the community, there are two challenges. One is very easy to overcome and the other is an unknown. (Or perhaps it is a known, once we can get everyone to see from the same perspective.) Suppose it is June of 2022 and I have been collecting and archiving all of the various versions of packages that are coming out for CentOS Stream. Then, maybe RHEL 8.7 is finalized and hits the mirrors. I can analyze the versions of packages that landed in RHEL 8.7. Then I can grab those versions from my archive and tag them "8.7". I could configure my repositories appropriately and build some ISO images. Of course, I couldn't call that "CentOS 8.7" because RedHat has prohibited that. But still I could release ISO's of "Enterprise Respin 8.7". That is the easy problem to overcome. But there's still the question of long term support. Suppose it is 2027 and some major bug is found in OpenSSL. For RedHat customers, RedHat will build a package of OpenSSL for RHEL 8.10 that fixes the bug. I would guess that such an OpenSSL package would NOT be the same one that lands in whatever version of RHEL 9 drops in 2027, since the OpenSSL in RHEL 9 will be based on a later version of OpenSSL and have more features. Presumably that RHEL 8 version of OpenSSL would go through the CentOS Streams process. Theoretically I could pick up that version of the package and provide it as an update to "Enterprise Respin 8.10". Except... how could that RHEL8 version of OpenSSL go through the CentOS Streams process? Based on what we've been told, at that time, "CentOS Streams" would really be "Whatever version of RHEL 9 drops in 2027 + 1". Or maybe it's even RHEL 10 by that point. So maybe long term updates won't go through the CentOS Streams process. So the question for the community is how to account for that second issue. --JK ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What about the AltArch repositories? (+ some experiments with aarch64 on Raspberry Pi)
This is aarch64: https://people.centos.org/pgreco/CentOS-Userland-8-stream-aarch64-RaspberryPI-Minimal-4/ On Wed, Dec 16, 2020 at 10:55 AM Mathieu Baudier wrote: > > > It's also worth noting that there is a CentOS 8 SD Card image for > > Raspberry Pi 4. That's what I used. It was dirt simple to "install"- > > simply dd the image file to an actual SD card, put it in the RasPi, > > and go! (Allthough in my case, I made some modifications to the > > > > Do you mean an image for armhfp (32 bits) or for aarch64 (64 bits) ? > Could you please send a link? Thank you! > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What about the AltArch repositories? (+ some experiments with aarch64 on Raspberry Pi)
It's also worth noting that there is a CentOS 8 SD Card image for Raspberry Pi 4. That's what I used. It was dirt simple to "install"- simply dd the image file to an actual SD card, put it in the RasPi, and go! (Allthough in my case, I made some modifications to the filesystems before actually booting. I made the filesystems bigger and I removed journaling from them.) On Wed, Dec 16, 2020 at 3:51 AM Mathieu Baudier wrote: > > Hello, > > given the recent change in direction of CentOS, what will become of the > AltArch repositories? (like CentOS 7 aarch64 and the related kernel > repositories) > > I have been experimenting (with some success) with running a regular CentOS > 8 aarch64 (ARM 64 bits) on a Raspberry PI 4 (with 4GB RAM), using the > aarch64 kernel-rpi2 provided by CentOS 7 AltArch [1]. (a few more technical > details below) > > This is a very different question than what is currently hotly discussed on > this list, with the end of the bug-for-bug clone of RHEL, as there were > never expectations that such settings would be supported. But on the other > hand, I liked to use CentOS for innovation in a given field (mostly Java > related) as its stability allowed one to go deep into one direction with > "other things being equal" (contrary to Fedora, which is always moving in > all directions). > > I guess that all these "side projects" (and SIGs, etc.) will disappear as > well, won't they? > > Cheers, > > Mathieu > > ## More details about running CentOS aarch64 on a Raspberry Pi 4 > > As for my experiments with running CentOS 8 on a Raspberry Pi 4, a bit more > details, so that these efforts are not completely lost. Two approaches were > working : > > - From a plain CentOS 7 AltArch aarch64 installation, perform a CentOS 8 > aarch64 install in a chroot (with the --installroot option) + a clean > kernel-pi2 install from the CentOS 7 kernel-pi2 repository. Then copy the > chroot to an .img file, and use this image to initialise an SD card. > > - From a plain CentOS 7 AltArch aarch64 installation, perform an in-place > upgrade to CentOS 8 (first install dnf from EPEL, then switch the repos, > and it works) > > The second approach had better device support on the Raspberry Pi 4 (most > importantly the wifi, which was not working with the first approach), but > this was probably a matter of subtle kernel / modprobe configs that were > beyond my skills. I thought that I would share all this at some point, and > ask for help from the CentOS AltArch developers; but I guess it is > irrelevant right now. > > Both approaches were working equally well on the Raspberry Pi 3 (but Fedora > support is good for this version, while Raspberry Pi 4 is not supported, so > I tend to use Fedora aarch64 on them). > > As for what is actually the point of doing all this, this is not for > weekend hobby tinkering, and it is relevant for server-side applications. > ARM 64 bits is becoming an important platform (hence the fact that RHEL is > now supporting it, MacOS will soon completely move to it, etc.) especially > if one is interested in climate-friendly low-power IT, also on the > server-side. But finding hardware is not easy and the (cheap) Raspberry Pi > have 64-bit capable processors, even though the default distrib (Raspbian, > based on Debian) does not yet support 64 bits (but they are working on it > [2]). After trying many distributions, a paradox was that CentOS was > actually the easiest to deploy and use in order to get some results (thanks > to the work of the AltArch team!) > > In my case, the main interest was to test on ARM 64 bits GraalVM, the next > generation Java platform, which can compile Java (and other programming > languages) to native code. These builds require a lot of memory, but with > an extremely slimmed down CentOS 8 and the 4 GB memory of the Raspberry Pi > 4, it worked! [3] > > On a different layer, I could also test Eclipse SWT (Java user interface > library) on this architecture (but on the plain CentOS 7 aarch64 with > GNOME), and provide some quick feedback to Eclipse developers on their > recent support for the whole Eclipse IDE on ARM 64 bits. [4] > > [1] http://mirror.centos.org/altarch/7/kernel/aarch64/kernel-rpi2 > [2] https://downloads.raspberrypi.org/raspios_arm64/images/ > [3] https://twitter.com/mbaudier/status/1274263320254722050 > [4] https://twitter.com/mbaudier/status/1291421892381937670 > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What about the AltArch repositories? (+ some experiments with aarch64 on Raspberry Pi)
I asked about this before. As far as CentOS itself is concerned this is an unknown. For me it's kind of annoying because I just set up a couple of Raspi 4's with CentOS 8 for a home automation system right before this announcement was made. Having said that- there is a little known distro called "RedSleeve Linux". It's just a couple of guys who do builds of RHEL 6, 7, 8 specifically for ARM systems. I contacted those guys because I did some work with them in the past, and I suggested they work with the folks at RockyLinux to combine efforts. On Wed, Dec 16, 2020 at 3:51 AM Mathieu Baudier wrote: > > Hello, > > given the recent change in direction of CentOS, what will become of the > AltArch repositories? (like CentOS 7 aarch64 and the related kernel > repositories) > > I have been experimenting (with some success) with running a regular CentOS > 8 aarch64 (ARM 64 bits) on a Raspberry PI 4 (with 4GB RAM), using the > aarch64 kernel-rpi2 provided by CentOS 7 AltArch [1]. (a few more technical > details below) > > This is a very different question than what is currently hotly discussed on > this list, with the end of the bug-for-bug clone of RHEL, as there were > never expectations that such settings would be supported. But on the other > hand, I liked to use CentOS for innovation in a given field (mostly Java > related) as its stability allowed one to go deep into one direction with > "other things being equal" (contrary to Fedora, which is always moving in > all directions). > > I guess that all these "side projects" (and SIGs, etc.) will disappear as > well, won't they? > > Cheers, > > Mathieu > > ## More details about running CentOS aarch64 on a Raspberry Pi 4 > > As for my experiments with running CentOS 8 on a Raspberry Pi 4, a bit more > details, so that these efforts are not completely lost. Two approaches were > working : > > - From a plain CentOS 7 AltArch aarch64 installation, perform a CentOS 8 > aarch64 install in a chroot (with the --installroot option) + a clean > kernel-pi2 install from the CentOS 7 kernel-pi2 repository. Then copy the > chroot to an .img file, and use this image to initialise an SD card. > > - From a plain CentOS 7 AltArch aarch64 installation, perform an in-place > upgrade to CentOS 8 (first install dnf from EPEL, then switch the repos, > and it works) > > The second approach had better device support on the Raspberry Pi 4 (most > importantly the wifi, which was not working with the first approach), but > this was probably a matter of subtle kernel / modprobe configs that were > beyond my skills. I thought that I would share all this at some point, and > ask for help from the CentOS AltArch developers; but I guess it is > irrelevant right now. > > Both approaches were working equally well on the Raspberry Pi 3 (but Fedora > support is good for this version, while Raspberry Pi 4 is not supported, so > I tend to use Fedora aarch64 on them). > > As for what is actually the point of doing all this, this is not for > weekend hobby tinkering, and it is relevant for server-side applications. > ARM 64 bits is becoming an important platform (hence the fact that RHEL is > now supporting it, MacOS will soon completely move to it, etc.) especially > if one is interested in climate-friendly low-power IT, also on the > server-side. But finding hardware is not easy and the (cheap) Raspberry Pi > have 64-bit capable processors, even though the default distrib (Raspbian, > based on Debian) does not yet support 64 bits (but they are working on it > [2]). After trying many distributions, a paradox was that CentOS was > actually the easiest to deploy and use in order to get some results (thanks > to the work of the AltArch team!) > > In my case, the main interest was to test on ARM 64 bits GraalVM, the next > generation Java platform, which can compile Java (and other programming > languages) to native code. These builds require a lot of memory, but with > an extremely slimmed down CentOS 8 and the 4 GB memory of the Raspberry Pi > 4, it worked! [3] > > On a different layer, I could also test Eclipse SWT (Java user interface > library) on this architecture (but on the plain CentOS 7 aarch64 with > GNOME), and provide some quick feedback to Eclipse developers on their > recent support for the whole Eclipse IDE on ARM 64 bits. [4] > > [1] http://mirror.centos.org/altarch/7/kernel/aarch64/kernel-rpi2 > [2] https://downloads.raspberrypi.org/raspios_arm64/images/ > [3] https://twitter.com/mbaudier/status/1274263320254722050 > [4] https://twitter.com/mbaudier/status/1291421892381937670 > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes wrote: > $250K is not even close. That is one employee, when you also take into > account unemployment insurance, HR, medical insurance etc. now multiply > that by 8. Now, outfit those 8 employees to work from home .. all over > the world, different countries, different laws. I'm genuinely curious about something, and this is mostly academic since it's probably the subject of proprietary discussions within RedHat. Presumably, RedHat had a build pipeline for RHEL that worked well for them, by supplying alpha/beta releases of point releases to their customers and giving them time to "cook" before releasing those point releases into production. Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On Tue, Dec 15, 2020 at 9:14 PM Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote: > Every package that ends up in a RHEL point release is in Stream at some > point, right? While I can certainly believe that the cost for the entire > CentOS effort is much more than $250K, dropping CentOS point releases just > means not gathering the particular versions that ended up in the > corresponding RHEL point release. This is exactly what I was talking about. I didn't ask, "how much does it cost to build CentOS". More specifically I was speculating on the amount of additional effort that was specifically required to do CentOS point release support, over and above the standard CentOS development (that RedHat would still be paying for). Having said that- it's possible that RedHat has heavily modified the build path for CentOS, since now it's upstream of RHEL instead of downstream; and if that's the case it could be that the new build path makes it impossible to build point releases. Having said THAT- it should be relatively simple to tag specific versions of packages in CentOS once those packages are released in a RHEL point release, then do an ISO build off of that. (I was guesstimating that it would take one FTE worth of time to do such tagging or other work needed to build the point releases based on the work that had already been done on the Stream updates, that's where I got the $250k from.) It seems as if it ought to actually be less expensive to do things this way than it has traditionally been to do CentOS... since traditionally, the CentOS team has had to pull the SRPMS for RHEL, duplicate a bunch of effort that RedHat had done to build them in the first place, and reconcile differences. Now since CentOS is actually part of the real RHEL build process, the work to create CentOS is paid for by RHEL. Officially. Maybe THAT is the problem. Since CentOS is now part of the official RHEL build pipeline, RedHat is unwilling to allow that work to be used to build the traditional CentOS point releases. They aren't going to directly contribute work that is paid for by RHEL to do the free CentOS releases. In order to do the 'clean room' implementation of point releases they would have to essentially re-duplicate ALL of the work that has traditionally been required to build CentOS... and THAT'S where the requirement of 8 FTE developers and dozens of servers comes from. They would build RHEL point releases and then they would put forth the 8 FTE worth of effort to do a clean-room rebuild of those releases in the form of CentOS, as they always have done. >From an internal view, if I were a RedHat business manager, I could totally see a legitimate desire to not fund a free product with the resources used to build my paid flagship product. Having realized all of the above- and I understand this is pure speculation on my part- from an external view, as a community member, it looks different. It seems like RedHat is saying, "WAAAH WAAAH YOU CAN'T HAVE MY TOYS GIVE THEM BACK OR ELSE" Even if the above is true regarding internal RHEL management not wanting RHEL funding a free product, *there is NO practical difference* on the effects towards the community. It is still the case that by taking this course of action RedHat has branded itself as being a bad faith actor. It is still the case that it would only cost RedHat a trivial amount- perhaps substantially less than the $250k I estimated- to continue to do CentOS point releases based off of RHEL. It is still the case that RedHat could earn back a huge chunk of the trust that it destroyed, by deciding to spend this trivial amount to continue the status quo of CentOS builds. RedHat needs to keep the following in mind: there is still value in RHEL. Patent indemnification, contractually guaranteed SLA's for defects for mission critical systems, and so forth. This is the whole idea of RedHat's existence, isn't it? To take all of these hundreds of free software packages and repackage them and sell the value that the legal and contractual guarantees offer. As a community we don't want that for CentOS. We know it's "not legally supported". We know that, if it breaks, we get to fix it ourselves or keep all the broken pieces. What we do want is a system that is repeatable, stable, and known. CentOS point releases provide that. CentOS Stream doesn't. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
> I don't think there will be a course change either, but for different > reasons. The motivation isn't "cashing/selling out". It's... actually the > stated motivation > https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2 First, I will note that I think the idea of creating *a version of* CentOS that is called "Stream", with the intent that it leads RHEL by a bit, is a GREAT idea, for exactly the stated reasons! There's one problem I have with this asserted motivation. Stream is not being done as *a version of* CentOS. It is being done as *THE* CentOS, which means you're discontinuing point releases. As far as "maintaining CentOS point releases to follow RHEL"- this is what is being discontinued. How much money, in developer time and other incidentals, does this cost RedHat per year? Of course this is a proprietary number. But let's imagine that this number is $250k per year. Out of what was it, about $433M of profit (2019)? So it would cost RedHat 0.06% of profit to hire more developers to keep issuing CentOS point releases. What does RedHat "buy" in return for spending 0.06% of its profit on maintaining point releases? -Community trust and goodwill. Those members of the community that cannot afford RedHat licenses for whatever reason still know that the #1 player in the Linux marketplace still has their back. Then when those folks move on to enterprises that can afford RH licensing (and in some cases demand it), will select RedHat because of this trust and goodwill. They will be highly likely to recommend other RedHat products- since it all "works together" and they'll know RHEL (i.e. CentOS) well. Also note that this trust and goodwill means "convenience", even within enterprises that have a large budget with RedHat. If I have a project and I want to spin up 100 OS instances just for the heck of it, I can. I don't need to ask anyone, I don't need to reserve or download any entitlement key files. I don't need to debug weird problems when entitlement key files don't work. -Control of part of the ecosystem. Those companies that build their products to run on RHEL (or in RHEL containers) are able to (and encouraged to) certify those products on RHEL because they are able to use CentOS. But more to the point, what does RedHat LOSE by saving 0.06% of its profit? The damage to community trust and goodwill far exceeds the gains that would be realized if the status quo were kept in place. Yes, it's true that many of the folks who used CentOS would never turn into paying customers. But due to this situation, you have thousands of system administrators who are actively looking to completely abandon the RedHat ecosystem altogether. When it comes time to recommend products... they aren't going to recommend RHEL. They aren't going to recommend JBoss, or Fuse, or 3Scale API management. It's clear that RedHat can't be trusted with some parts of its portfolio, so why should we trust ANY of its products? If it is 100% factually correct that the ONLY motivation for killing point releases is the stated motivation, then it's just a simple matter of finding a spare $250k (or whatever that cost is) from the almost-half-a-billion dollar corporate coin purse. The return on investment has been, and will continue to be, immeasurable... IF y'all do damage control ASAP. --JK On Tue, Dec 15, 2020 at 12:06 PM Matthew Miller wrote: > > On Tue, Dec 15, 2020 at 01:48:21AM -0700, R C wrote: > > I think that Centos, being that close to RHEL, should have had a > > licensing scheme for personal use, small business use, just to make > > things 'fair'. > > So, again, please stay tuned. Not for licensing schemes for CentOS, but for > programs for these use cases for RHEL. See > https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 > and please really do mail centos-questi...@redhat.com with your use cases. > This is answered by humans designing these programs, not by sales. > > > > I don't think their (IBM/RHEL) course is going to change though, > > redhat going "commercial" has been going on for a decade and a half > > or so, and it looks like initial investors have a desire > > cashing/selling out at this point. > > I don't think there will be a course change either, but for different > reasons. The motivation isn't "cashing/selling out". It's... actually the > stated motivation > https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2 > > > -- > Matthew Miller > > Fedora Project Leader > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 8 Stream: The Good, The Bad, The Ugly
Hello All- After reading and digesting a ton of community chatter about the recent CentOS announcement I've come to the conclusion that there's a lot of good about this, but there are also a lot of concerns that are being ignored. And nobody so far has stared directly into the eyes of the elephant in the room. So here goes. The Good: From a technical perspective- both in the sense of "getting newer software" and "technical community being more involved in bugfixes, etc"- having *a version* of CentOS called "AppStream" is fantastic. The various RedHat and CentOS folks who have been extolling these virtues in blog posts and twitter feeds are right-on. But from responses I've seen, it appears to me that they think that these virtues are enough to completely gloss over the complete and utter clusterfrackas they've caused. The Bad: No point releases. There is POSITIVELY NO* REASON that they can't have AppSream and still do point releases. Brand new stuff would go into AppStream, at some point they do a point release of RHEL, then follow the normal CentOS procedure to spin a CentOS build of that point release. This is already a tried and true process. It will cost RedHat all of what, low five digits (if that) in developer salary to do this. Heck I'm sure some volunteers would step up to use the existing infrastructure if RedHat didn't want to spend any paid developer time on this. The Ugly: I denoted "NO* REASON" above because there actually *are* reasons that we are not privy to. https://twitter.com/JoshuaPKr/status/1336744681716244480 Since RedHat is not being transparent with this, we are forced to speculate and remain bewildered at why they would make a decision that is going to cost them so much in the long run. The most common (and most likely) theory is that some MBA somewhere in middle management saw all of this CentOS being used in production environments (and otherwise downloaded for free), and had the idea that if CentOS had its head cut off people would just buy RHEL subscriptions. That may happen in a few cases, but for the most part, that is NOT what is going to happen. By handling the CentOS situation in this way, RedHat has branded itself as a company that acts in bad faith. If a company acts in bad faith towards a community where non-monetary value is exchanged, WHY would you trust that company to hold up its obligations for contracts that are actually paid? People are going to do whatever they can to get away from RedHat. Debian, Ubuntu, SuSE will all benefit from this. Even in cases where non-profits and other similar clients "contact RedHat about options because Stream won't meet their needs"- why would such entities have ANY reason to trust anything that RedHat says to them? There have been hundreds of other messages that describe exactly what RedHat loses in this deal so I won't go into that here. But branding oneself as a "bad faith actor" is usually a terrible way to try to pick up a little bit of subscription revenue. In the end it's going to be a losing scenario. This is an absolutely UNMITIGATED DISASTER from a marketing and community goodwill standpoint. It can, however, be mitigated if RedHat backtracks, admits their mistake, and affirmatively commits to support future CentOS point releases. I'll be interested to see how this turns out. --JK ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
