Re: [CentOS] Apache mpm itk
Il 2023-05-17 01:12 Chris Adams ha scritto: The package was orphaned in Fedora, so there's no maintainer to create and manage builds. Hi, I did not know that. Thanks for sharing. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Apache mpm itk
Il 2022-09-23 19:06 Gionatan Danti ha scritto: Hi all, the EPEL repository for CentOS7 contains httpd-itk, an apache module for running different vhosts under specific user/group ID. For RHEL8 I can find it only in 3rd party repos, while I misses it entirely for RHEL9. Is the module deprecated? Can it be re-included into EPEL? Regards. Hi all, anyone with some ideas? Any explanations on why httpd-itk is absent from both EPEL-8 an EPEL-9? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos Stream 9 module list
Il 2023-01-12 23:01 Josh Boyer ha scritto: There have been many discussions on modularity, both on this list and on lists like the epel and fedora devel lists, but I'll give a brief subset. Modularity provides parallel availability but not parallel installatability. Some software needs or perhaps wants to be parallel installable. Also, some upstream language stacks such as python have implemented parallel availability/installability inherently in their framework, which eliminates the need for modules. Ultimately, the Red Hat teams are using modularity where they believe it makes sense and using regular packaging to reduce complexity for customers where it doesn't provide much benefit. josh Make sense. Thank you for taking the time to explain. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos Stream 9 module list
Il 2023-01-12 16:10 Josh Boyer ha scritto: Modules are one of several packaging formats we have. With CentOS Stream 9/ RHEL 9, we took user and customer feedback on how the default versions of software are packaged and determined that the defaults should be normal RPMs. Newer and alternative versions of software will be delivered as modules in some cases, or as regular RPMs with applicable versioning in others. josh Hi Josh, can I ask the rationale behind this decision? It seems "strange" to have some different version in the main repos, with versioned RPMs, and other in specific modules (which needs to be manually enabled). Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrading system from non-RAID to RAID1
Il 2023-01-12 09:00 Simon Matter ha scritto: That's a huge improvement especially on very large disks. Hi, not-ancient versions of Linux MD RAID cope with these issues via two different means: - a write bitmap to track dirty disk regions; - an embedded bad list sector to remap such sectors when appropriate (and without failing the entire array, if possible). Still, splitting a disk into multiple slices has the specific advantage of using different RAID levels on different dataset (which can be very valuable in some cases). Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Apache mpm itk
Hi all, the EPEL repository for CentOS7 contains httpd-itk, an apache module for running different vhosts under specific user/group ID. For RHEL8 I can find it only in 3rd party repos, while I misses it entirely for RHEL9. Is the module deprecated? Can it be re-included into EPEL? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] chkrootkit---abandoned???
Il 2022-01-19 01:52 Fred ha scritto: Just tried to check for updated chkrootkit and it appears there haven't been any since 0.53, 3 1/2 years ago. Anybody know if it is now accessible somewhere other than www.chkrootkit.org ?? Thanks in advance! Wikipedia reports its latest version at 0.54, released Dec 24, 2020. But the site www.chkrootkit.org seems down right now. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is shellcheck safe?
Il 2022-01-17 06:30 Thomas Stephen Lee ha scritto: Hi, I downloaded, extracted, and ran 0.8.0 https://github.com/koalaman/shellcheck/releases After running, I submitted the file to virustotal with the below result. https://www.virustotal.com/gui/file/f4bce23c11c3919c1b20bcb0f206f6b44c44e26f2bc95f8aa708716095fa0651 Should I be concerned that I ran the program once? Thanks I don't see anything wrong with the shellcheck repository. Anyway the golden rules always apply: check you script on a test machine and, if needed, update your bash script on the production server. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
Il 2022-01-14 15:30 Johnny Hughes ha scritto: No .. none of the CentOS Kernels were EVER binary compatible with any RHEL kernel. CentOS Linux has always been (now also including CentOS Stream 8 and 9) a completely separate 'closed' build system. We use the SAME source code to build things, modified to remove branding. But CentOS has NEVER been (nor is any other rebuild distribution now) Binary Compatible. Want to see how .. just extract two rpms with the same name from two different distributions into separate directories and run a sha256sum on all the files in the different directories with find command. Some files may be identical (most text files that are copied), others will not be. It is virtually impossible for all produced packages to be 'binary compatible' UNLESS they are built with exact the same files (not files BUILT fromt he same sources .. the exact same files) in the build root AND with exactly the same software doing the building. Any group that claims 'binary compatibility' is either lying or they do not understand compiling and linking. CentOS never had that. Neither does any rebuild. This is why the CentOS Project 'CHANGED' our term from binary compatible to 'Functionally Compatible' a long time ago. (Using same source code, we produce DIFFERENT software .. that works the same way but has different SHASUM values. Don't be fooled by key words like 'binary compatible' .. check it out for yourself. If you build kpatches to kernels, to make them work you need to build the kpatch for the specific kernel (CentOS would need to build against CentOS kernels, etc). Also, there are the certificate signing issues and keys that you would need to take into account. You need to have the CA Trust to be able to create signatures that the system will allow. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Thank you so much for the detailed explanation, very appreciated. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
Il 2022-01-14 13:17 Josh Boyer ha scritto: RHEL's kernel live patching uses upstream open source kpatch. The sources to the kpatches are delivered in customer facing CDN repos at the same time as the kpatch itself. We do not use proprietary code to produce or apply the kpatches. I can only speculate on whether RHEL kpatches would work on a CentOS kernel, but my assumption is that they would not due to how they are signed. Is (well, was) the CentOS kernel identical at binary level to the RHEL one? If so, the same kpatch should be applicable to both RHEL and CentOS (the old one). But I seem to understand that the two kernels are *not* bytewise identical, so a binary kpatch can not be applied the CentOS. Is this true? Anyway, RH kpatches are surely not compatible with CentOS stream. So I asked if some project was started to provide live kernel patching to the new CentOS project. If I don't miss something, this is not the case. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel live patching on CentOS Stream 9
Il 2022-01-07 19:07 Brian Stinson ha scritto: There are 2 things to note here about kernel live patching: - We do not provide patch files in CentOS Stream (or previously in CentOS Linux, for that matter). We've always recommended RHEL as a better fit for folks that have hard requirements on this sort of workflow. - RHEL 9 is not yet released, my understanding is that patch files for RHEL proper will begin showing up after GA Yup, this matches my expectations. Thank you all for sharing. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Kernel live patching on CentOS Stream 9
Dear all, is kernel live patching working for CentOS Stream 9? I know that I can enable it via cockpit or the command line, but are kernel patch files really available or do they require an active RHEL subscription? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Roundcubemail
Il 2021-12-28 15:06 TE Dukes ha scritto: Hello, Just upgraded from CentOS 7 to CentOS 8 Stream and there is no rpm for roundcubemail. Could I get the SRPM for CentOS 7 and re-do it for CentOS 8? I really hate installing a non-RPM package. If not a good idea, what is available for webmail in CentOS 8 Stream? TIA Hi, you can use Remi's RPM repository to install roundcube. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Roundcube 1.4.12 on CentOS 8
Il 2021-12-10 22:20 Leon Fauster via CentOS ha scritto: Am 10.12.21 um 22:15 schrieb Gionatan Danti: Hi all, I recently updated a CentOS 8 machine to roundcubemail-1.4.12 (from 1.4.11) using remi's repo. I needed to explictly exclude the 1.5.0 packages because it was "shadowing" the latest 1.4.12 release. But now I can not see the 1.4.12 packages anymore - only 1.5.x are provided. Does anyone know why the previous stable package disappeared from remi's repo? Thanks. https://blog.remirepo.net/pages/English-FAQ#archive -> "Can I get an old version of a package ?" I always read this line as valid for very old packages only, which clearly is not the case! I'll use the forum to ask for the required package. Thank you for your fast (and helpful!) reply. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Roundcube 1.4.12 on CentOS 8
Hi all, I recently updated a CentOS 8 machine to roundcubemail-1.4.12 (from 1.4.11) using remi's repo. I needed to explictly exclude the 1.5.0 packages because it was "shadowing" the latest 1.4.12 release. But now I can not see the 1.4.12 packages anymore - only 1.5.x are provided. Does anyone know why the previous stable package disappeared from remi's repo? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Introducing CentOS Stream 9
Il 2021-12-03 16:22 Johnny Hughes ha scritto: Rich Bowen has posted a blog entry "Introducing CentOS Stream 9" https://blog.centos.org/2021/12/introducing-centos-stream-9/ More details here: https://centos.org/stream9/ Have we an official upgrade path from Stream-8 to Stream-9? From what I can understand the answer is "no", but maybe I am missing something. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS update
Il 2021-12-03 15:46 Johnny Hughes ha scritto: sssd-client-1.16.5-10.el7_9.11.i686.rpm exists and is here: http://mirror.centos.org/centos/7.9.2009/updates/x86_64/Packages/ Not sure why you are not seeing it in your update. It is an Azure CentOS instance, which is pre-configured for using ex-OpenLogic mirrors: # CentOS-Base.repo baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/os/$basearch/ I updated sssd-client and the libsssd dependencies by using an official CentOS mirrors. Thank you for pointing me to a mirror issue! Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS update
Dear list, I have an issue updating a CentOS 7.9 machine. A simple "yum update" exists with this error: # yum update --> Running transaction check ---> Package kernel.x86_64 0:3.10.0-1160.36.2.el7 will be erased --> Finished Dependency Resolution ERROR: update failed. Check the log file for details ... Protected multilib versions: libsss_idmap-1.16.5-10.el7_9.11.x86_64 != libsss_idmap-1.16.5-10.el7_9.10.i686 Error: Protected multilib versions: libsss_nss_idmap-1.16.5-10.el7_9.11.x86_64 != libsss_nss_idmap-1.16.5-10.el7_9.10.i686 Trying to update excluding all i686 packages reveal the true issue: an unmet dependency of # yum update --exclude="*.i686" libsss_idmap Resolving Dependencies --> Running transaction check ---> Package libsss_idmap.x86_64 0:1.16.5-10.el7_9.10 will be updated --> Processing Dependency: libsss_idmap = 1.16.5-10.el7_9.10 for package: sssd-client-1.16.5-10.el7_9.10.x86_64 ---> Package libsss_idmap.x86_64 0:1.16.5-10.el7_9.11 will be an update --> Finished Dependency Resolution Error: Package: sssd-client-1.16.5-10.el7_9.10.x86_64 (@updates) Requires: libsss_idmap = 1.16.5-10.el7_9.10 Basically, yum tries to update libsss_idmap to a too new version, not allowed in for sssd-client. I do not use sssd so I can simply uninstall the packages, but I am curious about the unmet dependency. Anyone has the same issue? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ruby on Cent OS 8
Il 2021-11-16 02:15 Markus Falb ha scritto: Rocky 8.5 has gained support for secure boot https://rockylinux.org/news/rocky-linux-8-5-ga-release/ Oh, good to know! Thank you. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ruby on Cent OS 8
Il 2021-11-15 16:03 Simon Matter ha scritto: These figures are interesting but they can not be compared directly. Oracle has its own EPEL repo and therefore I guess that the number here shows only those who are using the official EPEL instead of the one provided by Oracle. That said, I expect that the true number of Oracle Linux installations is quite a bit higher than what we see here. Personal note: I am currently using Rocky, but I am very tempted by Oracle Linux also. It has working secure boot and a proven update track record (with security metadata for yum, which Rocky only recently started providing). It also has an officially supported upgrade path between major releases. The only thing stopping my adoption is Oracle "the company". But, maybe, it is an irrational fear... That aside, can I ask how is the EPEL-8 situation now? I remember that one years ago many packages were missing compared to, say, EPEL-7. Is the current situation better? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix and virtual mail boxes.
Il 2021-10-07 23:24 Alexander Dalloz ha scritto:
Am 07.10.2021 um 15:06 schrieb Gionatan Danti:
Il 2021-10-07 12:40 Rob Kampen ha scritto:
mydestination = localhost localhost.localdomain
mydomain = example.org
myhostname = mx.example.org
mynetworks = 127.0.0.0/8, [::1]/128
Not that I expect it to be the cause, but you need a coma between
"localhost" and "localhost.localdomain" in mydestination.
That's simply wrong!
http://www.postfix.org/postconf.5.html#mydestination
"Specify a list of host or domain names, "/file/name" or "type:table"
patterns, separated by commas and/or whitespace."
Oh, I missed the last part ("or whitespace") and I always used comas.
Thanks for pointing it out.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix and virtual mail boxes.
Il 2021-10-07 12:40 Rob Kampen ha scritto: mydestination = localhost localhost.localdomain mydomain = example.org myhostname = mx.example.org mynetworks = 127.0.0.0/8, [::1]/128 Not that I expect it to be the cause, but you need a coma between "localhost" and "localhost.localdomain" in mydestination. I had originally only used "postconf -n" as it is MUCH smaller than postconf , however it still shows no material differences. Yeah, it seem the config are very similar (with the exception of virtual_alias_maps, which you explained). Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix and virtual mail boxes.
Il 2021-10-07 07:18 Rob Kampen ha scritto: Hi, not sure this is the best place to go for my problem, but hoping someone can point me to the correct or better place. I have two currently working CentOS 7 based email servers that host a number of virtual domains and users and delivers mail just fine - for correctly addressed vmail inboxes AND for alias addressed emails and domains. These all use postfix, dovecot, amavisd, clamAV, spamassassin, mysql (mariadb) and roundcubemail I use port 25 for the world email delivery - no auth needed as only accepts hosted virtual domain addressed email. and port 587 for user client MUA to send mail - smtp with STARTTLS auth needed port 993 for MUA IMAP access to account mail boxes A couple of weeks ago I rolled up a new minimal virtual server (also CentOS 7) and basically copied the same setup as the other two and have now spent far too long trying to get it going. My initial problem was that I set up mydestination to include $mydomain - this has the consequence of seeing any mail@$mydomain as local email and trying to deliver to the local machine rather than the vmail inboxes. So after setting up a new domain just for the MX we moved on. All three installations use mysql (mariadb) as the data store for domains, alias domains, user vmail accounts, and forwardings (virtual alias mapping) The mysql bits work just fine as I can send mail from an MUA client and they deliver correctly via an authenticated session on port 587 - i.e to any world email address AND to local vmail boxes, including those addressed via an alias and/or alias domain. What fails to work on the new installation, but works fine on my two legacy servers, is mail addressed via an alias. Specifically an alias domain. Even adding the complete alias email address to the forwardings table doesn't work. e.g. let's say we have an email domain '@example.com' and an alias domain '@example.org'. Needed so I can migrate my clients from one server to the other in a staged manner. Thus the new server is set up to operate as the MX for @example.org and @example.com but needs to alias redirect the incoming emails being sent to f...@example.org and deliver them to the vmail location for f...@example.com (i.e. we have no vmail locations for @example.org only for @example.com So if I send a test email via my MUA (using port 587 and hence authenticated) it does the alias lookups and translations needed and correctly delivers the mail. However if I send an email to f...@example.org from say a gmail account, it arrives at my new server and promptly gets bounced with a 550 5.7.1 error - no such email address. After doing diff on the main.cf and master.cf from all three servers the only differences are the myhostname, mynetworks (new one is dual stack IP4/IPv6 and thus includes [::1]/128), smtpd_tls certificate names, and the virtual_uid_maps - all expected and accounted for. master.cf are identical Many dozens of google searches and reading far too many pages, has left me with no idea why my new server doesn't accept alias directed emails via port 25. All the documentation indicates that alias lookups and translations are performed by postfix - all the time. receive_override_options is not set. Any suggestions of things to check or test would be welcome. TIA Rob Hi, can you show the difference on "postconf" output on your mailservers? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum quiet not really quiet anymore?
Il 2021-07-24 20:12 Simon Matter ha scritto: Maybe redirecting only stderr to /dev/null is enough? No, it really goes to stdout. Anyway, masking all error redirecting them to /dev/null would be too heavy-handed. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] yum quiet not really quiet anymore?
Hi all, I noticed that "yum -q" (or "dnf" -q) on CentOS 8 is not really quiet anymore. For example (notiche the "upgraded" line): [root@localhost cron.d]# yum upgrade -y -q Upgraded: python3-perf-4.18.0-305.10.2.el8_4.x86_64 While yum historically had issue with the quiet option [1], this specific issue seems new to me. Do you have any suggestion (short of redirecting stdout to /dev/null)? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Difference between CentOS Linux and CentOS Stream
Il 2021-07-19 21:38 Johnny Hughes ha scritto: Sure .. but just like you are using EL8 right now .. EL9 will be released before the 8-Stream EOL. Again .. Have no issues using whatever, but there will be plenty of time to get Stream 9 up and going for most loads before Stream 8 EOL. Any news about in-place migration from Stream-8 to Stream-9? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Server monitoring
Il 2021-07-10 20:10 H ha scritto: I want to install open-source software on my hosted CentOS 7 server to monitor the system in general, as well as logs, apache webserver, MySQL and PostgreSQL to begin with. I know there are a multitude of packages available and would be interested in hearing if others have a favorite package? My preference is for a graphical interface where it is easy to follow a variety of load measures but also provides alerts etc. You can try netdata [1] for monitoring single hosts or Zabbix [2] for network monitoring. [1] https://www.netdata.cloud/ [2] https://www.zabbix.com/ -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-07-09 13:57 Nikolaos Milas ha scritto: On 9/7/2021 1:14 μ.μ., Gionatan Danti wrote: While I fully understand & agree on the motivation for keeping Rocky (and other clones) 1:1 with Red Hat, it should be understood that current RHEL packages selection itself is drifting away from small/medium business needs. So the core issue is a more fundamental one: Red Hat, our upstream, is walking away from traditional server needs. IMHO, this is a more fundamental discussion, which is beyond future CentOS versions and alternative RHEL-compatible projects and it deserves a separate thread. Sure. In any case, I think that the existence and continuous availability / maintenance of external RHEL / CentOS-compatible repositories probably provides a solution for most use scenarios. Of course, I cannot possibly know all actual needs, so I may be wrong. I need to recognize the fact that it appears there is still a shortage of packages for CentOS 8, even though it is active for quite long already. Maybe this is mainly due to EPEL difficulties. This is my impression also. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-07-08 23:21 J. Adam Craig ha scritto: Well said. It is worth pointing out also that, while Kurtzer and other Rocky community leads are devoted to keeping Rocky 1:1 with upstream, they are also committed to engaging with the CentOS Stream community themselves (if they find a bug in upstream code and they can fix it, Kurtzer and others have stated multiple times that they will contribute the fix into Stream), and to encouraging such engagement among those who desire to see improvements with upstream. In other words, if we are uncomfortable with the direction Stream is going, the preferred approach is mobilisation within and engagement with the Stream community to have those changes realised there, so that they flow into Enterprise Linux and everyone benefits. While I fully understand & agree on the motivation for keeping Rocky (and other clones) 1:1 with Red Hat, it should be understood that current RHEL packages selection itself is drifting away from small/medium business needs. So the core issue is a more fundamental one: Red Hat, our upstream, is walking away from traditional server needs. So while I wish Rocky all the best (and I am actively using it!), I am looking toward Ubuntu and Debian for new deployments. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-07-08 16:46 Leon Fauster via CentOS ha scritto: Maybe "we" could fill this gap? Describe this state of EPEL? Did you requested such missing packages? From the early on (EL8.0) I requested such EPEL packages, some fedora maintainers branched there packages into EPEL8. Even a request for a devel package was honored and the rpm was included by RH later in 8.1. This is a community, so communicate! Everything else is a product in ready state that must be paid. For what it is worth, I opened various RH bugzilla enhancement request in the 10+ years of using CentOS. One of the last: https://bugzilla.redhat.com/show_bug.cgi?id=1902781 That said, lets face in: current CentOS is not really a community, at least in the sense that a community can steer the project direction. Nobody polled for Stream or asked about it. Stream simply happened due to an unilateral Red Hat decision. *Which is PERFECTLY fine*, unless trying to masking it behind the "community" word. My view is that RH/CentOS would be relatively inadequate for many roles without the outstanding work done by EPEL and the rest of the CentOS community, unless you are an hyperscaler who can do its own internal package additions. Red Hat failing to recognize the enormous value of EPEL and former CentOS model really baffles me. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-07-08 13:22 Nikolaos Milas ha scritto: If some people want to leave the RHEL ecosystem for Debian or FreeBSD, that's OK. But for those who want to stay in the RHEL world, Rocky Linux stands as a rock-solid solution. This opinion does not reject other CentOS clones, but emphasizes the fact that Rocky Linux appears to be a solid option for now and the years to come. While true, I also feel that RH is trying to actively shape its distribution away from small enterprise needs. For example, common packages are deprecated and/or removed (eg: virt-manager, screen, kernel-side DRBD, pam_mysql, etc) and EPEL 8 (which is fundamental to my CentOS/Rocky installations) is in a bad state. My impression is that RH is following cloud vendors & hyperscale needs - with Stream as a clear example. This is not an inherently bad thing, but it quite different from what the small and medium businesses I service need. So, while closely watching RH/CentOS/Rocky, I am going to steer new deployments on Ubuntu LTS or Debian. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-07-07 11:44 Nikolaos Milas ha scritto: I re-visit this thread, since it is crucial for CentOS 8 users. RESF / Rocky Linux is gaining worldwide recognition and sets itself as the primary organization / platform to become the CentOS 8 heir / successor in the future. Google and Microsoft become RESF sponsors/partners: https://rockylinux.org/news/community-update-june-2021/ And so IBM/RH lose the tremendous advantage they had by owning the CentOS project, which - it seems - never evaluated correctly. From now on, it is clear that hundreds of thousands of CentOS installations will be migrating to Rocky Linux. I also wish the best of success to CentOS Stream, but this is not what the CentOS community expected. Yeah, I share this view. As a side note, I evaluated Oracle Linux because it has working secure boot, but I am somewhat afraid of using it (due to corporate practices). This probably is an irrational feeling (after all, I do not exclusively use MariaDB, but MySQL also), but I prefer to stay on the safe side. Anyway, I strongly feel that IBM/RH miscalculated the move. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BTRFS to ext4
Il 2021-07-02 20:26 Christopher Wensink ha scritto: What steps would you go through to migrate the file systems over? Would you set up a duplicate VM and rsync data over? Expand the capacity of the existing VM, add a new partition then move data over from one partition to another from within the same VM? What are your thoughts? Both options seems reasonable to me. If choosing to use the same machine, I would not expand the existing disk; rather I suggest adding a *new* disk to VM (formatting it with EXT4). Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Security Updates not properly flagged
Il 2021-06-22 02:34 Gordon Messmer ha scritto: 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. Hi Gordon, yeah, I used the term "rolling release" in a too-broad sense - I was really referring to "rolling updates", sorry for the confusion. Still I think my point applies: if metadata for security updates were not provided before, it now seems even less probable than the CentOS team will provide such information, as the maintainers are facing a continuous stream of updates. But hey - happy to be proven wrong! Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Security Updates not properly flagged
Il 2021-06-21 13:34 Pete Biggs ha scritto: CentOS does not provide the metadata to allow the --security flag to work. Right. It doesn't provide it because that information from Redhat is proprietary and not open source. This is not my understanding. From what I can see, updates which patches CVEs are freely readable on Red Has site. For example: CVE: https://access.redhat.com/security/cve/cve-2021-3156 UPDATE: https://access.redhat.com/errata/RHSA-2021:0221 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). Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] pam_mysql
Il 2021-05-16 16:54 Alexander Dalloz ha scritto: cyrus-sasl provides the sql auxprop mechanism, which I would prefer over pam_mysql. https://blog.sys4.de/cyrus-sasl-sql-man-page-en.html I second this. However, if you really need a pam_mysql RPM, you can try using a third party repository [1] or a Fedora 29 package [2] (with the big warning that this is now totally unsupported). Regards. [1] https://pkgs.org/download/pam_mysql [2] https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/29/Everything/x86_64/Packages/p/pam_mysql-0.8.1-0.2.fc29.x86_64.rpm Regards, Alexander ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-04-30 21:16 Gordon Messmer ha scritto: 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. From here [1]: "Since March 2004, CentOS Linux has been a community-supported distribution derived from sources freely provided to the public by Red Hat. As such, CentOS Linux aims to be functionally compatible with RHEL. We mainly change packages to remove upstream vendor branding and artwork. CentOS Linux is no-cost and free to redistribute." Does it means that CentOS was appropriate on all scenario? No. Was CentOS making hard promises about their support or existence? No. So it is *fine* for classical CentOS to disappear if the developer / owner want that. Long live Stream! But stating that Stream is functionally equivalent to CentOS is not correct. Fact is that the CentOS team did a wonderful work at repackage RHEL, so 99.9% of times it just worked. And it worked for all the time the corresponding RHEL was supported (7 or 10 years). In return, RedHat (and so CentOS) got much testing and bug-report (I alone reported my fair share of bugs, some with hours/days spent try to reliably reproduce and tracking down them). Now, with a moving kernel, you simply can't provide this level of confidence. DKMS is not a silver bullet. See here [2] for an example. Rebooting your kernel and finding you can't access your storage is a quite a significant problem, no? And when I migrated a test machine to Stream some months ago, even something as basic as dnf had its issues. While I hope that now the situation is better, I hardly can see Stream equivalent to old CentOS. Regards. [1] https://web.archive.org/web/20200721184556/https://www.centos.org/about/ [2] https://listman.redhat.com/archives/vdo-devel/2021-January/msg5.html 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 -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-04-30 16:26 Johnny Hughes ha scritto: On 4/30/21 4:32 AM, Gionatan Danti wrote: Il 2021-04-30 06:55 Gordon Messmer ha scritto: 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? Because it very often break kABI compatibility, with 3rd party module heavily affected. 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. 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 will produce a very different product. And, as a side note, things break more often on Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a different product. My personal opinion is that RH created Stream to give cloud vendors a place to experiment/repackage *before* adding that to the main RHEL distro. Stream really does not seem targeted aSo, t small sites / "normal" sysadmins, rather at large cloud vendors. Which, again, is perfectly fine unless trying to disguise it as an "almost-RHEL" distro. Regards. Sure .. so block kernels and build your own in that situation. Or use something else. There are always edge cases. There are millions of CentOS users. What percentage use 3rd party modules (other than nvidia drivers). There are some, and this would be a problem for those people. So, IF another downstream distro works for you .. use it. Or use Debian or Ubuntu, or BSD. Use Alma or Rocky Linux. Buy RHEL. As stated above, if this is the vision of Stream, fine. I am not arguing about the vision: while I don't like it, my opinion is irrelevant. But disguising Stream as "almost-RH" (a mantra repeated many times both here and in various blog) is plain wrong, and I genuinely don't think it will be good for Stream. And you know better than me that what you wrote above regarding the kernel is a double-edge sword: as you cope with security patches if the kernel is blocked? How do you cope with HP/DELL/Lenovo kmod needed to configure the RAID subsystem if using a rolling kernel? Did you notice that even RH-sponsored modules as kvdo were broken multiple times on Stream? If you are using VDO to access your storage and it suddenly is not usable anymore, how would you feel? What about ZFS on Linux users? Do you realize this drastically reduces Stream fitness to bare-metal install (one of the main CentOS usage was as hypervisor)? The correct answer is to buy RH: fine. But do not let Stream touch anything which require a kABI compatible modules. As said above, the Stream move is squarely addresses *cloud* vendor requests and needs. Again, fine. But please leave apart the RH comparison, this is not going to help Stream. Again, don't let me wrong: I wishes the best to Stream, and I will use it where appropriate. But "where" is much smaller today than yesterday. But this aside, I really thank you all CentOS maintainer for your monumental work, and I really hope Stream will be a success. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-04-30 06:55 Gordon Messmer ha scritto: 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? Because it very often break kABI compatibility, with 3rd party module heavily affected. 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. 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 will produce a very different product. And, as a side note, things break more often on Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a different product. My personal opinion is that RH created Stream to give cloud vendors a place to experiment/repackage *before* adding that to the main RHEL distro. Stream really does not seem targeted at small sites / "normal" sysadmins, rather at large cloud vendors. Which, again, is perfectly fine unless trying to disguise it as an "almost-RHEL" distro. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
Il 2021-04-27 15:05 J Martin Rushton via CentOS ha scritto: The traditional rebuild of RHEL will continue under other guises. There has been a long standing release at Springdale. Since RH's announcement Cloud have produced the Alma release. There is also a new project called Rocky that hasn't yet released a full version but is working on it. Hi, I am not sure this is the place to ask, but lets try... If the Springdale release is a 100% RH clone, why do different teams (Alma and Rocky) are trying to re-package the same 100% binary-compatible RH clone? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Proxmox Backup Server equivalent for the RHEL/CentOS world ?
Il 2021-04-16 14:35 Nikolaos Milas ha scritto: On 16/4/2021 10:10 π.μ., Felix Kölzow wrote: you may take a look at _rear_ (it is that easy how it looks like) You may also want to check mondo: http://www.mondorescue.org/about.shtml (the website is not updated regularly!) I am using it for many years, since CentOS 5 (until now with CentOS 8). There may be a few glitches, but otherwise I am pretty satisfied. It supports bare metal recovery and can be used for cloning too. Cheers, Nick Hi, while relax-and-recover, mondorescue and similar tools have their place, I mostly find them outdated for VM backup. The main reason is that they have difficult providing low RTO and RPO. For my current low-cost linux hypervisors I use a ZFS filesystem, with backups done leaveraing a mix of both ZFS send/recv and rsnapshot. More specifically: - rolling hourly snapshots are taked via sanoid; - the primary datastore (with raw disk images) is replicated with 1min interval (thanks to send/recv) to a second, standby server. This guarantee a byte-for-byte copy of all the virtual machines backing files *and* the capability to quickly restart all VMs in case the first server dies; - a third machine does rsnapshot-based backup of the data inside the VMs themselves, for added convenience in recovering a single file and for longer historical retention. This backup scheme as served me very well. Just my 2c. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KVM vs. incremental remote backups
Il 2021-03-31 14:41 Nicolas Kovacs ha scritto: Hi, Up until recently I've hosted all my stuff (web & mail) on a handful of bare metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI, Roundcube) as well as mail and a few other things were hosted mostly on one big machine. Backups for this setup were done using Rsnapshot, a nifty utility that combines Rsync over SSH and hard links to make incremental backups. This approach has become problematic, for several reasons. First, web applications have increasingly specific and sometimes mutually exclusive requirements. And second, last month I had a server crash, and even though I had backups for everything, this meant quite some offline time. So I've opted to go for KVM-based solutions, with everything split up over a series of KVM guests. I wrapped my head around KVM, played around with it (a lot) and now I'm more or less ready to go. One detail is nagging me though: backups. Let's say I have one VM that handles only DNS (base installation + BIND) and one other VM that handles mail (base installation + Postfix + Dovecot). Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images. With the old "bare metal" approach I could perform remote backups using Rsync, so only the difference between two backups would get transferred over the network. Now with KVM images it looks like every day I have to transfer the whole image again. As soon as some images have lots of data on them (say, 100 GB for a small OwnCloud server), this quickly becomes unmanageable. I googled around quite some time for "KVM backup best practices" and was a bit puzzled to find many folks asking the same question and no real answer, at least not without having to jump through burning loops. Any suggestions ? Niki Hi Nicolas, the simpler approach would be to use a filesystem which natively supports send/recv on another host. You can be tempted to use btrfs, but having tested it I strongly advice against it: it will horribly fragments and performance will be bad even if disabling CoW (which, by the way, is automatically re-enabled by snapshots). I currently just use ZFS on Linux and it works very well. However, using it in CentOS is not trouble-free and it has its own CLI and specific issues to be aware; so, I understand if you don't want to go down this rabbit hole. The next best thing I can suggest is to use lvmthin and XFS, with efficient block-level copies done to another host via tools as bdsync [1] or blocksync [2] (of which I forked an advanced version). On the receiving host, you should (again) use lvmthin and XFS with periodic snapshots. Finally, I would leave the current rsnapshot backups in-place: you will simply copy from a virtual machine rather than from a bare metal host. I found rsnapshot really useful and reliable, so I suggest to continue using it even if efficient block-level backup are taken. Just my 2 cents. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
Il 2021-02-25 22:35 Stephen John Smoogen ha scritto: Mainly because customers don't want to pay for that work which is considerable. If Red Hat builds it, it is expected to have all kinds of 'promises' equivalent to its other products and that is expensive in terms of QA, engineering, documentation, various certifications, etc. Package growth goes up quickly so if people are complaining about the cost of a RHEL license for 4000 src rpms, then what would it be at 20,000 to 30,000. It is easier to allow the community to choose to do the work it wants and then 'consumers' of said repository get what they can. [Including Valeri] I doubt it. Price is mainly defined by offer and demand (which is, in turn, driven by how much value the customer put behind the product). While production/support cost can put a lower bound on it, I don't think this is the case for Red Hat. Anyway, Red Hat did not have to supporto EPEL packages the same as core one - even a best effort support would be enough in many cases. The point is that EPEL does not only contains nice-to-have packages, but sometimes provide really important packages. As an (outdated) example, a decade ago Cyrus with mysql backend was only provided by EPEL. For a more up-to-date example, consider how difficult is to run a "plain" CentOS 7 system - it misses monit, mbuffer, smem, x2go, various Perl modules, etc. You EPEL volunteers do an outstanding works - I would really than for all you did (free of charge) for the CentOS community. Red Hat should recognize and support your works. I think the industry is entering another crux point where 'classical' system administration will be in the same class as mainframe/miniframe system administration were in the late 1980's and early 1990's with Unix systems and then Linux. Our wor will remain incredibly important to various industries but it will increasingly be a smaller amount of 'total deployments'. Which is why so many of our conversations echo so much of the USEnet in the early-1990s, where mainframes/miniframes admins wondered why companies were not focusing on their industries anymore. Well, in a sense, the new cloud frenzy is something similar to a "remote mainframe" used with a new type of thin client (the browser). Yeah, I know this is a very stretched analogy... I should say that I saw so many services deployed "to the cloud" that are plain broken/misbehaving that it sometime worries me. My (naive?) impression is that we are switching from "few specific services which correctly work unless something bad happen" to a "mess-which-more-or-happens-to-works but nobody know what to do if it does not" model. I recently debugged an IPSec tunnel between an on-premise appliace and a Azure VPN services. The on premise appliance has extensive log and inspection tools, while on the Azure side we had litelly *nothing*. An Azure consultant was taken on board to help with specifig Powershell sniplet, to no avail. After 7+ days, a 3rd level Microsoft support engineer change a *private* setting on that VPN gateway service and the tunnel started working correctly. On another case, a Win2008R2 machine stopped working in a AWS instance. No console, no logs. After 2+ weeks of paid "gold/premium" support from an Amazon enginer, my customer simply decided to detach the virtual disk and to attach it to another machine, reinstallaing the server. Are we sure this is the way to go? Don't get me wrong - "the cloud" is the natural places for things as web and mail server. A virtualized domain controller? Mmm... not so much. But hey - I understand this is not going to change. The very same CentOS switch was done to please the cloud vendors, which will have a more "dynamic" base to rebuild. But I don't like how Red Hat does not simply produce a different product or profile for the cloud needs, rather than actively adding complexity at every layer. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
Il 2021-02-25 14:27 Simon Matter ha scritto: EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing. Yeah, same impressions here. EPEL really is a key package repository for RHEL - and I always wondered why they did not invest into maintaining (and extending) this excellent repo. I think RH now is extremely focused on cloud and SaaS platform, which leave us "normal" sysadmin in an uncomfortable situation... Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Filesystem choice for BackupPC extrenal drive
Il 2021-02-05 01:41 Kenneth Porter ha scritto: I'm setting up a CentOS 7 box as a BackupPC 4 server to back up Windows boxes on my LAN. I'm using an external 1.5 TB USB drive for the "pool". BackupPC deduplicates by saving all files in a pool, a directory hiearchy with each file named for the checksum of the file, and the directories acting as a hash tree to reach each pool file. A backup for a specific workstation is a directory tree of checksums and metadata that point into the pool for the actual file data. Incremental backups are reverse deltas from periodic "filled" backups of all files. I'm using rsyncd to pull changed files from the workstations. I'm deciding which filesystem to use for my external drive. I'm thinking the main candidates are ext4 and xfs. What's the best filesystem for this application? While being a fan of XFS, for an external drive I would use EXT4. My (anectodal) experience is that EXT3/4 is more resilient to flacky hardware/connection as the one provided my many USB adapters. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6 fix sudo CVE-2021-3156
Il 2021-01-28 19:17 James Pearson ha scritto: I don't know of another way of testing if this build fixes the issue ? According to Qualys blog, sudoedit -s '\' `perl -e 'print "A" x 65536'` should core-dump on vulnerable versions. I just tried on stock 6.10 and it core-dumps, indeed. Upgrading to the OL6 sudo package fixes the issue, indeed (no more core dump). So it seems to work fine to me. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6 fix sudo CVE-2021-3156
Il 2021-01-27 09:34 Walter H. ha scritto: is that what you expect to find? https://access.redhat.com/errata/RHSA-2021:0227 Yes, something similar... Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 6 fix sudo CVE-2021-3156
Hi all, do you know if a fix for sudo CVE-2021-3156 is available for CentOS 6? While CentOS 6 is now supported anymore, RedHat has it under its payedsupport agreement (see: https://access.redhat.com/security/vulnerabilities/RHSB-2021-002). So I wonder if some community-packaged patch exists... Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
Il 2021-01-22 13:43 Nikolaos Milas ha scritto: I think we can expect Rocky Linux to provide a real solution to CentOS future. We shall know very soon, so let's just wait for a short while. Hi, there are any specific reasons to not use Spingdale Linux? As far I know, it already ships a RHEL 8.3 clone. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
Il 2021-01-08 10:01 Fabian Arrotin ha scritto: With my SysAdmin hat on, I'd say that the only real impacting bit is the shorter lifetime (5y instead of 10), but with overlap between stream versions, so one would have time to have a look, reflect in automation, reinstall/migrate, enjoy One key question, which seems to be somewhat unresolved, is if a clear in-place upgrading path from Stream-8 to Stream-9 will exist. Any news about it? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article: CentOS is NOT dead
Il 2020-12-14 13:07 Nicolas Kovacs ha scritto: Hi, Here's an interesting read which makes a point for CentOS Stream: https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877 tl;dr: Communication about Stream was BAD, but Stream itself might be a good thing. Here's why. Cheers, Niki While interesting, I think the blog post fails to identify the the main issue with Stream: - Stream can be updated many times each days. You basically have a non-stop incoming flow of updates; - as far I know, Stream does not have (and will not have) "synchronization points" with mail RHEL; - the support window is much shorter (ie: 2024 vs 2029). Anyone relying on RHEL/CentOS to be kABI compatible can be severely impacted by the first two points (it's difficult planning updates with rolling releases, when the kernel version can change from a day to another), while the third one (shorter support window) affect anyone. Basically it seems to me that Stream will be to RHEL the same Rawhide is to normal Fedora releases. While this has the potential to be a good move, it should be offered *in addition* to normal CentOS releases - which effectively are a different product. That said I am grateful to all the volunteers that made CentOS possible, and I don't want the above to be taken as a rant - they only are my (possibly wrong) opinions. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] question centos stream 8 applying updates
Il 2020-12-12 15:54 Leon Fauster via CentOS ha scritto: EOL in 2024! https://lists.centos.org/pipermail/centos/2020-December/352340.html https://centos.org/distro-faq/#q13-can-i-start-up-a-sig-that-will-maintain-centos-stream-8-after-rhel8-reaches-the-end-of-full-support https://lists.centos.org/pipermail/centos-devel/2020-December/075532.html Thank you so much. This is quite unfortunate. Let's see if/how well the version upgrade system to upgrade from Stream-8 to Stream-9 works. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] question centos stream 8 applying updates
Il 2020-12-11 23:53 Pete Biggs ha scritto: Somewhere in amongst the vast number of posts, someone said that the release cadence for point releases was 6 months with the final release being 8.10 in 2024. After that RHEL 8 goes into maintenance mode and there will be no more content added to 8-stream (because it had reached the end of it's useful life as a pre point release distro). From what I can read here [1], the latest 8.10 release (due in 2024) will be supported for other 5 years, bringing RHEL 8 to the 10 years total support we know. So the question is: will Stream-8 follow the same support cycle? Or any Extended life cycle support patch to the RHEL 8.10 release will be considered private? This is a very important question and I sincerely hope someone can answer. Thanks. [1] https://access.redhat.com/support/policy/updates/errata -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] question centos stream 8 applying updates
Il 2020-12-11 19:26 Walter H. ha scritto: with CentOS Stream there are only updates till 2024(!) not 2029 as it be expected ... Is that officially confirmed? If RHEL 8 is expected to have an 8.10 release sometime in the 2028-2029 timeframe, and if any updates should really hit Stream-8 before, the latter should have the same EOL date. What I am missing? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
Il 2020-12-10 18:40 Brendan Conoboy ha scritto: Hey, you dropped Centos-devel from your reply. I'll assume that was intentional, but if it wasn't feel free to quote any of this back there. Hi Brendan, no, it was not intentional - I replied from the smartphone and I accidentally dropped the centos-devel list. I'll reply quoting the entire conversation to let others read your useful information. On Thu, Dec 10, 2020 at 9:26 AM Gionatan Danti wrote: Il 2020-12-10 14:35 Brendan Conoboy ha scritto: - are you going to keep stable ABI between Stream kernel releases, or should we expect each kernel to break 3rd party drivers/modules? All our kernel changes are implemented against the kernel ABI- there is no point in time during release development when we have interim changes in the kernel that ignore the symbols in the whitelist. So basically if your experience of going from one minor release to another has been smooth, the incremental kernels between those two releases would also tend to run smooth, assuming whatever motions happen with the 3rd party drivers/modules behind the scenes continue to happen (for example, rebuilding from source). Let's forget about minor release upgrades and focus on the incremental kernel updates between point releases for a moment. Can we expect a stable kernel ABI for these releases, or should we expect breaking changes? In other words, should 3rd party kmod be constantly updated for *any* kernel released on the Stream channel, or can we expect them to keep working until a "next-release" kernel appears? Regarding symbol whitelist, I understand it as related to a single minor releases - ie: all kernels of 8.3 branch will obey it, but this can be false for kernel on, say, 8.4 Am I missing something? I think it's a question of nuance. In broad strokes we don't break the kernel ABI as outlined by the whitelist starting with the first major release. In fact, taht whitelist grows throughout the life of the release, making the ABI more predictable. The problem you've likely experienced is that loadable kernel modules have access to symbols not included in the whitelist. Whether we're pushing new code upstream or backporting new code from upstream, we endeavor to keep symbols the same, even if they aren't on the whitelist. But if for strong technical reasons it's better to change a symbol, that will happen upstream, and if it wasn't part of our whitelist, it can happen in RHEL as well. Usually these changes only require minor updates in the loadable kernel modules, but for an end user this is the difference between a module loading or not loading, so the impact is glaring. I'm not sure how things will take shape with CentOS Stream and external drivers, whether some gating activity wil elrepo will hold back kernel updates until elrepo is updated, or if a SIG will form, or some other thing. All I can say for sure is that when you have a group of people with common problems, they will create solutions, and we want those solutions for CentOS Stream. So we'll work it out, I'm just not sure how yet (kABI isn't my focus, I'm simply familiar with the dynamics because I was the overall RHEL 8 development lead). - what/how many synchronization points are going to be with RHEL releases? I'm not sure I'm interpreting your question correctly, could you restate? I don't want to hit you with detailed process information only to find out I'm answering the wrong question! With Stream, all is going to change constantly. We will have any "sync point" where Stream is 100% identical to a specific RHEL point release? OK, I understand now, thanks! I don't think there will be a point where a RHEL minor release compose will be NVR identical to a CentOS Stream compose, though they will be pretty close. The reason for this is that there is a period of time where we're working on 2 RHEL releases at once: The one that is about to release, and the one that will follow. CentOS Stream, I believe, will follow the source tree of "the one that will follow." All the same fixes will be there, but CentOS Stream will also get additional fixes and features not included in the near term RHEL release. Thank you for taking the time to reply. Regards. I appreciate the questions! Regards, Thank you for the clear replies. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
Il 2020-12-10 04:55 Brendan Conoboy ha scritto: On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: On 12/9/20 12:10 PM, Brendan Conoboy wrote: > While I'm not sure how we'll get there, it seems like the > mutually satisfying end result would be one where third party binary > drivers work with CentOS Stream kernels. Let's see what we can do. > So, I want to address this part a bit. In MANY cases, it's not a third-party driver that ELrepo packages; it's an in-kernel driver that Red Hat has decided to disable. Such as the megaraid_sas driver I need for my servers. Ah yes, that's a great call-out. I'm not sure what the plan is there (or if there is one), but to me it seems like the sort of thing a SIG would build. Brendan, can you clarify the following points? - are you going to keep stable ABI between Stream kernel releases, or should we expect each kernel to break 3rd party drivers/modules? - what/how many synchronization points are going to be with RHEL releases? - what about security updates? Will they be released *before* the corresponding RHEL secure patch, or should we expect the (slow) current update cadency? - is an upgrade path from Stream-8 to Stream-9 planned, or the usual "total server rebuild" will be necessary? Full disclosure: the main CentOS point was to be 100% compatible, down to the specific kernel used, with RHEL. To get that, we lived with: a) comparatively few packages, b) not-working yum security-only updates and c) very restrictive selinux policies. I am heavily invested in CentOS/RHEL ecosystem and I opened many bug reports/enhancement requests in the past years, so I would really like to continue using CentOS. However, using Stream seems to removing the key selling point (ie: total RHEL compatibility) without clear benefit. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] State of CentOS 8
Il 24-12-2019 11:30 John Pierce ha scritto: on the other hand, 99% of those security updates are things that probably don't affect most centos deployments. It does not only affect security, but also *functional* updates. For an example of a quite important, but not fixed bug in current CentOS 8: https://bugzilla.redhat.com/show_bug.cgi?id=1680481 Long story short: currently, CentOS 8 is not usable as webmail server with classical httpd+prefork+mod_php (due to httpd crashing loop). Looking forward for CentOS 8.1! Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux repository
Il 03-07-2018 15:39 Nux! ha scritto: Watch out, ZFS on Linux is not as good as on FreeBSD/Solaris. Just recently there was an issue with data loss. https://github.com/zfsonlinux/zfs/issues/7401 I know; I was on the very same github issue you linked. While the bug was very unfortunate, ZFS remain an exceptionally strong and reliable filesystem. Let me ask again: anything is preventing to update the CentOS 3rd party repository page with ZoL repo? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux repository
Il 25-06-2018 23:59 Yves Bellefeuille ha scritto: I think the simplest solution would be to add this (which I haven't tried): http://zfsonlinux.org/ https://github.com/zfsonlinux/zfs/wiki/RHEL-and-CentOS to the Available Repositories for CentOS wiki page: https://wiki.centos.org/fr/AdditionalResources/Repositories/ unless someone with some authority says that you can't do this. Sure, this is the simplest path. Anyone has a good reason to be against it? That said, I keep the idea that SIG would be highly preferable. Anyone is using ZFS on this list? Any ideas? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] ZFS on Linux repository
Hi list, we all know why ZFS is not included in RHEL/CentOS distributions: its CDDL license is/seems not compatible with GPL license. I'm not a layer, and I do not have any strong opinion on the matter. However, as a sysadmin, I found ZFS to be extremely useful, especially considering BTRFS sad state. I would *really* love to have ZFS on Linux more intergrated with current CentOS. From what I know (and I can go wrong, obviously), while the incompatible licenses prevent CentOS from shipping it, nothing should prevent to have a package for enabling *its repository*, better yet the kmod-enabled one. I was thiking to something as a ZFS SIG, where we can simply issue "yum install zfs-sig" and have the correct kmod-enabled repository enabled. I searched the list but I did not found anything regarding native ZFS. Any feedback on the matter is welcomed. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
