Re: [CentOS] [EXT] Re: Kmods SIG in RHEL

[Peter Georg]

On 21/09/2022 12.02, Fabian Arrotin wrote:

On 21/09/2022 11:51, Fabian Arrotin wrote:

On 21/09/2022 08:32, Thomas Stephen Lee wrote:

Hi,

Is
https://sigs.centos.org/kmods/
a part of RHEL 9?
If yes, what is the repository name?
If not, when can we expect it to be included?

Thanks

---
Lee


No, it's not part of RHEL9 , and it's built and maintained by the 
Kmods SIG (see https://sigs.centos.org/kmods/) as a community project.


They were building it first for Stream 9 and later asked to also build 
for/against RHEL9 kernel when it was available (see 
https://pagure.io/centos-infra/issue/786)


Kind Regards,



Oups, realizing that I replied with same URL you gave and (I'll blame 
lack of coffee effect :-) ) my brain translated initially to 
artifacts/rpms that can be found on 
http://mirror.stream.centos.org/SIGs/9/kmods/ ...
But answer is still correct but now more complete as you see where 
built/signed pkgs are landing too (even if that was in the infra tracker 
ticket)




In addition to what Fabian already mentioned:

The Kmods SIG does by now provide all packages it provides for Stream 9 
also for RHEL9. However, there is no easy way for you to enable the 
Kmods SIG's repositories on RHEL9 (yet) as SIGs can not (yet) provide 
centos-release-* packages for RHEL9 (and its clones) [1].


In case you want to use any package provided by the Kmods SIG for RHEL9 
you have to manually add its repositories for now, e.g. by copying [2] 
to /etc/yum.repos.d/centos-kmods.repo
Note that you also need to copy the Kmods SIG's GPG key [3] to 
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Kmods


We hope to be able to provide a centos-release-kmods package soon which 
should then allow you to consume the Kmods SIG's content after a simple
dnf install https://mirror.stream.centos.org/... command similar to how 
you can easily enable EPEL.



[1]: https://pagure.io/centos-infra/issue/643
[2]: 
https://gitlab.com/CentOS/kmods/rpms/centos-release-kmods/-/raw/c9/centos-kmods.repo

[3]: https://www.centos.org/keys/RPM-GPG-KEY-CentOS-SIG-Kmods
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Raspberry Pi 4 and C++ 17

[Peter]

On 26/04/22 6:41 am, Will wrote:

Hi,

I have a program I want to run on a Raspberry PI 4 that was written on 
an x86_64 architecture.  So I downloaded the Raspberry PI image of 
CentOS 7 and now I'm on armv7hl.  Unfortunately, there doesn't appear to 
be any devtools for arm at all.  Is there an easy(ish) way to get c++ 17 
this architecture?


Rocky Linux 8 has gcc-toolset-11 for aarch64 with an rpi-installible 
image.  That has support for C++ 17.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] TCP Sequence Number Approximation Based Denial of Service on CentOS Linux release 7.9.2009 (Core)

[Peter]

It's not a major issue.  Here's Red Hat's stance on it:
https://access.redhat.com/security/cve/cve-2004-0230

And this is a good read:
https://lwn.net/Articles/81560/


Peter



On 18/03/22 6:51 am, Kaushal Shriyan wrote:

Hi,

I have 3.10.0-1160.59.1.el7.x86_64 on CentOS Linux release 7.9.2009 (Core)
running Nagios Monitoring system. We have run an external vulnerability
scan today on this server. The vulnerability reports say the below details.
I am not sure if I completely understand the below issue.

CVSS base score:- 5.0
CVE-2004-0230
Severity : Medium

TCP Sequence Number Approximation Based Denial of Service

TCP provides stateful communications between hosts on a network. TCP
sessions are established by a three-way handshake and use random 32-bit
sequence and acknowledgement numbers to ensure the validity of traffic. A
vulnerability was reported that may permit TCP sequence numbers to be more
easily approximated by remote attackers. This issue affects products
released by multiple vendors.   The cause of the vulnerability is that
affected implementations will accept TCP sequence numbers within a certain
range, known as the acknowledgement range, of the expected sequence number
for a packet in the session. This is determined by the TCP window size,
which is negotiated during the three-way handshake for the session. Larger
TCP window sizes may be set to allow for more throughput, but the larger
the TCP window size, the more probable it is to guess a TCP sequence number
that falls within an acceptable range. It was initially thought that
guessing an acceptable sequence number was relatively difficult for most
implementations given random distribution, making this type of attack
impractical. However, some implementations may make it easier to
successfully approximate an acceptable TCP sequence number, making these
attacks possible with a number of protocols and implementations.   This is
further compounded by the fact that some implementations may support the
use of the TCP Window Scale Option, as described in RFC 1323, to extend the
TCP window size to a maximum value of 1 billion.   This vulnerability will
permit a remote attacker to inject a SYN or RST packet into the session,
causing it to be reset and effectively allowing for denial of service
attacks. An attacker would exploit this issue by sending a packet to a
receiving implementation with an approximated sequence number and a forged
source IP address and TCP port.   There are a few factors that may present
viable target implementations, such as those which depend on long-lived TCP
connections, those that have known or easily guessed IP address endpoints
and those implementations with easily guessed TCP source ports. It has been
noted that Border Gateway Protocol (BGP) is reported to be particularly
vulnerable to this type of attack, due to the use of long-lived TCP
sessions and the possibility that some implementations may use the TCP
Window Scale Option. As a result, this issue is likely to affect a number
of routing platforms.   Another factor to consider is the relative
difficulty of injecting packets into TCP sessions, as a number of receiving
implementations will reassemble packets in order, dropping any duplicates.
This may make some implementations more resistant to attacks than others.
It should be noted that while a number of vendors have confirmed this issue
in various products, investigations are ongoing and it is likely that many
other vendors and products will turn out to be vulnerable as the issue is
investigated further.


Solution
Please first check the results section below for the port number on which
this vulnerability was detected. If that port number is known to be used
for port-forwarding, then it is the backend host that is really vulnerable.
   Various implementations and products including Check Point, Cisco, Cray
Inc, Hitachi, Internet Initiative Japan, Inc (IIJ), Juniper Networks, NEC,
Polycom, and Yamaha are currently undergoing review. Contact the vendors to
obtain more information about affected products and fixes.  "
http://packetstormsecurity.org/0404-advisories/246929.html;   NISCC
Advisory 236929 - Vulnerability Issues in TCP  details the vendor patch
status as of the time of the advisory, and identifies resolutions and
workarounds.   Refer to  "http://www.kb.cert.org/vuls/id/415294;   US-CERT
Vulnerability Note VU#415294  and  "http://osvdb.org/4030;   OSVDB Article
4030  to obtain a list of vendors affected by this issue and a note on
resolutions (if any) provided by the vendor.   For Microsoft: Refer to  "
https://docs.microsoft.com/en-us/security-updates/securitybulletins/2005/ms05-019;
   MS05-019  and  "
https://docs.microsoft.com/en-us/security-updates/securitybulletins/2006/ms06-064;
   MS06-064  for further details.   For SGI IRIX: Refer to  "
ftp://patches.sgi.com/support/free/security/advisories/20040905-01-P.asc;
SGI Security Advisory 20040905-01-PFor SCO U

Re: [CentOS] vault.centos.org down

[Peter]

On 2/03/22 12:36 pm, Nels Lindquist wrote:

On 2022/03/01 10:35 a.m., Simon Matter wrote:

On 2/28/22 23:46, Simon Matter wrote:

Yes, also mostly down for me. Some requests were answered but unable to
really use the site.



Is it just overloaded?  I've seen a few examples recently of people
building CentOS 8 containers by building repo definitions that reference
vault.  Naturally, I asked them to stop doing that...

If overload is the problem, I'd suggest that making the site *less*
reliable might eventually fix the problem.  In particular, dropping
requests for repomd.xml would probably shed a lot of load while still
giving human users access to package files.


In my case I was just trying with firefox to get some files and browsing
wasn't possible at all. Suddenly some pages were shown and then 
connection

was stuck again. However, currently it works fine for me.


I've been unable to access it at all for the past couple of days, either 
through a browser or yum.


There are working mirrors you can use:

https://mirror.rackspace.com/centos-vault/


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [EXT] c9s: CPU ISA level lower than required

[Peter Georg]

On 07/02/2022 17.40, Alessio wrote:

On Mon, 2022-02-07 at 16:58 +0100, Peter Georg wrote:

On 07/02/2022 16.28, Alessio wrote:

On Mon, 2022-02-07 at 16:20 +0100, Peter Georg wrote:

glibc-2.34-20 includes a fix to more reliable detect CPU
compatibility.
See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657

Does your CPU support x86-64-v2?


The KVM version I'm using doesn't support that? Could it be?


Possible. What is your configured KVM CPU model?
A first step might be to check the output of /proc/cpuinfo in your
VM.

Just to be sure, the host CPU does support x86-64-v2?


If this method [0] is correct, the host CPU supports x86-64-v2, x86-64-
v3 and x86-64-v4
While inside the VM, the result is "CPU supports x86-64-v1"


In this case your VM is misconfigured. Please check your configured KVM 
CPU model. A list of all CPU models and support x86-64 levels can be 
found here:

https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html



[0]
https://itectec.com/unixlinux/how-to-check-if-the-cpu-supports-x86-64-v2/


Thanks,
A.

___
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] [EXT] c9s: CPU ISA level lower than required

[Peter Georg]

On 07/02/2022 16.28, Alessio wrote:

On Mon, 2022-02-07 at 16:20 +0100, Peter Georg wrote:

glibc-2.34-20 includes a fix to more reliable detect CPU
compatibility.
See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657

Does your CPU support x86-64-v2?


The KVM version I'm using doesn't support that? Could it be?


Possible. What is your configured KVM CPU model?
A first step might be to check the output of /proc/cpuinfo in your VM.

Just to be sure, the host CPU does support x86-64-v2?



However I was able to install CentOS Stream 9 from the ISO in this VM.
So it wasn't supposed to work?


I do not know when/how the checks for x86-64-v2 are done.



Thanks,
A.

___
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] [EXT] c9s: CPU ISA level lower than required

[Peter Georg]

On 07/02/2022 16.01, Alessio wrote:

Hello.
I had a CentOS Stream 9 installation in a KVM VM.
Today a "dnf upgrade" lead to an unusable system: dnf, rpm commands
complain that "glibc cpu does not support x86-64-v2" or "CPU ISA level
is lower than required".
The updates leading to this state seem to be: python3 3.9.10-1, glibc
2.34-21, rpm 4.16.1.3-10

What happened?


glibc-2.34-20 includes a fix to more reliable detect CPU compatibility. 
See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657


Does your CPU support x86-64-v2?

CentOS Stream for AMD and Intel 64-bit architectures requires at least 
x86-64-v2. See [1] for some background.


[1]: 
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level#architectural_considerations_for_rhel_9



Thanks,
A.

___
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] Postfix and virtual mail boxes.[SOLVED - kinda]

[Peter]

On 11/10/21 2:06 pm, Rob Kampen wrote:

OK - just to let you know the munge I used.

example.com is an alias domain for example.org which is the actual 
domain with Maildir space on the server.


rob@ is alias for rkampen@ thus the only real address is 
rkam...@example.org


That's not what I meant by munge, but it helps.  Anyhow, what you showed 
me is what I need to see.



now the results


This is all good, except...

[root@mx rkampen]# postmap -q @example.com 
mysql:/etc/postfix/mysql-virtual_forwardings.cf

@example.org


This is a bad idea.  It's not the cause of your problem (as you 
discovered below) but it will lead you to become a backscatter source. 
I'll explain.


Postfix checks virtual_alias_maps entries twice, once in smtpd and once 
in cleanup (actually trivial_rewrite, which is called from cleanup).  At 
the smtpd stage it simply checks to make sure that there is a 
virtual_alias_map entry for the recipient address, but it doesn't care 
where that entry points, then (after other checks) postfix accepts and 
queues the message.


The message is then passed to cleanup, which, as once of its functions, 
calls trivial_rewrite which, once again, checks virtual_alias_maps and 
in turn rewrites the recipient to the target email address.  (It then 
loops and does this until there are no more rewrites to be done).  Then 
delivery is attempted to the target address.


So in your case, what happens when the original recipient is 
"nonexist...@example.com"?  Well Postfix first checks virtual_alias_maps 
for entries of "nonexist...@example.com", "nonexistent" and 
"@example.com", it finds a match for the last of these and so the 
message passes the checks in smtpd and the message is accepted for 
delivery and queued.


Then the message is passed to cleanup which checks with trivial_rewrite 
and trivial_rewrite checks virtual_alias_maps (again) and after finding 
the "@example.com" entry it rewrites the recipient to 
"nonexist...@example.org".


Then Postfix attempts to deliver the message to nonexist...@example.org, 
but since there's no such recipient and since postfix has already 
accepted the message for delivery it generates a bounce message which it 
sends to the envelope sender.  Thus you have a situation where messages 
can be sent to invalid recipients and your system will bounce them, and 
as such you become a source of backscatter.


You can confirm this by attempting to send a message to 
nonexist...@example.com and another one to nonexist...@example.org.  The 
example.com one will generate a bounce from Postfix while the 
example.org one will reject the message instead (you'll be able to see 
the difference in your Postfix logs).


The solution here is to not use an @example.com entry in 
virtual_alias_maps, but instead to have a separate entry for each valid 
recipient in example.com.  Since you're using mysql it is possible to 
craft a mysql query that can check the valid example.org recipients and 
only return example.com matches for those recipients, I'll leave that as 
an exorsize for you, but if you have problems with it I'll be happy to help.



Well that may have done it!

Now I get a correctly sent email with the alias substitutions done. 
Funny how that line seems to cause no error on my two original MX - 
looks like I better check them out a little more too.


That's great.  So basically what you've done by removing that entry is 
to bypass the policyd-spf check from Postfix.  What that means is that 
the problem is in policyd-spf and this is further confirmed by the 
following log entry:


Oct 11 13:53:10 mx policyd-spf[10723]: ERROR: Unknown name "TestOnly" in 
file "/etc/python-policyd-spf/policyd-spf.conf"


Unfortunately I am not a policyd-spf expert by any stretch, so at this 
stage I'll direct you to their community support for further help 
(unless someone else here wants to chime in and help).  What I can say 
is that if you fix your policyd-spf issue then it is likely that you can 
add that entry back into the Postfix configuration and it will work.



Thanks Peter, your help has been invaluable and MUCH appreciated!


You're quite welcome.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix and virtual mail boxes.[SOLVED - kinda]

[Peter]

On 10/10/21 11:28 pm, Rob Kampen wrote:

smtp   inet  n   -   n   -   -   smtpd
     -o smtpd_recipient_restrictions= -o content_filter=spamassassin


I assume based on what you've said before that this is after you added 
the workaround you mentioned, but the logs below are without the 
smtpd_recipient_restrictions= part here?


Cannot see how this log listing can possibly help as it contains only 
three lines


Nonetheless I do appreciate seeing them, no offense but you can never 
tell if someone's interpretations of the logs are accurate and so it's 
best just to see the logs themselves.


Here is the log of the incorrectly rejected email coming into the new MX 
- very short as it immediately rejects the alias recipient address - 
which my other two MX do not do.


Right.

This led me to the conclusion that the alias substitution is not taking 
place on my new MX whereas it does on my two working MX - hence my 
addition to the smtp processing line at the top of the master.cf file.


I wouldn't jump to that conclusion just yet, though.

That said, based on your config and logs I think I may have been wrong 
in my previous guess and it may very well be related to your 
policyd-spf.  More on that in a bit.


Can you provide the output of the following commands (but substitute the 
actual recipient domain and address for the munged versions you supplied 
here):


postmap -q example.com mysql:/etc/postfix/mysql-virtual_alias_domains.cf

postmap -q r...@example.com mysql:/etc/postfix/mysql-virtual_forwardings.cf

postmap -q r...@example.com mysql:/etc/postfix/mysql-virtual_email2email.cf

postmap -q example.com mysql:/etc/postfix/mysql-virtual_domains.cf

postmap -q r...@example.com mysql:/etc/postfix/mysql-virtual_mailboxes.cf

The results of the above should give a much better picture of what's 
going on.


To check if it's the policyd that's causing the problem can you modify 
the smtpd_recipient_restrictions line in main.cf and remove just the 
"check_policy_service inet:localhost:12350," part?  So that it reads 
something like:


smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_unauth_destination,

check_policy_service unix:private/policyd-spf

Then check to see if it works after that (and provide logs again so I 
can check things over).  Note this also means reverting your workaround 
in master.cf for this test.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix and virtual mail boxes.[SOLVED - kinda]

[Peter]

On 9/10/21 12:26 pm, Rob Kampen wrote:
So, after many dozens of hours and sending test emails I have found a 
solution (work around) that appears to work okay. It is now different to 
the original two MX servers I cloned from, in that the maillog shows a 
different cycle of processing, and it now fails a truly unknown mailbox 
much later in the process - thus higher workload on my MX. But the key 
thing is that it does now do the virtual_alias checks on incoming emails 
on port 25 before rejecting.


if your MX is not rejecting messages to invalid recipients right away 
but instead bounces the messages later on you become a backscatter 
source (See https://www.backscatterer.org/?target=bounces).


your server needs a properly configured list of valid recipients so it 
knows right away what recipients to accept and which ones to reject.


No idea why this third MX is behaving differently. It has a dual stack 
IP, so I disabled IPv6 access and tried again, but that certainly wasn't 
the cause of the difference in processing.


If you can provide the output of the following two commands it would be 
very helpful in troubleshooting your problem:


postconf -nf
postconf -Mf

Also of great help would relevant logs for one message that is giving 
you issues.  These should be in /var/log/maillog and contain a 
connection line followed by a number of postfix/smtpd lines, please copy 
all the logs for *one* message.  Please do not attempt to enable verbose 
logging (it only adds in a lot of extra unneeded info that detracts from 
finding the real problem) and it is unnecessary to provide log lines 
from non-postfix processes.


It should be noted that the two initial MX machines have an extra line 
in the maillog that is the second logged step in the process, and goes 
something like:


Oct  8 19:00:58 mx policyd-spf[16055]: prepend Received-SPF: None 
(mailfrom) identity=mailfrom; client-ip=209.85.210.180; 
helo=mail-pf1-f180.google.com; envelope-from=r...@example.com; 
receiver=


This is likely unrelated to the issue but may point to another issue 
having to do with a possibly incorrect policyd setup.  We can cross that 
bridge after we've fixed the primary issue though (one issue at a time).



After that processing steps are identical.


It's likely that there may be something else subtle in the logs that we 
can spot that you are not noticing.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

[Peter]

On 16/07/21 10:39 pm, Simon Matter wrote:

And I ask again, how else would you expect the package to satisfy the
dependency in chrome for the newer libstdc++?


And yet you still have not answered this question.


And that's where it breaks the rules! It "provides" something that it
doesn't really provide. That's NOT allowed with RPM because it breaks
other applications. It breaks the whole meaning of dependency tracking of
the RPM system. That's why the mentioned chrome package has to be
considered broken.


It is not broken, it does exactly what it intends to do.  It needs to 
provide the dependency in order to allow chrome to be installed, and 
with the usage of the correct LD_LIBRARY_PATH it allows chrome to run on 
the system where otherwise it would not.


Yes, it violates the Fedora packaging guidelines, it's a good thing it's 
not a Fedora package, then.  Also please note the very first sentence on 
the main page of the guidelines:


https://docs.fedoraproject.org/en-US/packaging-guidelines/

"The Packaging Guidelines are a collection of common issues and the 
severity that should be placed on them. While these guidelines should 
not be ignored, they should also not be blindly followed."


Sometimes you have to break some rules to get things to work.  In this 
particular case the results are worth it for a great many people.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

[Peter]

On 16/07/21 10:19 pm, Simon Matter wrote:

I think you missed from a different post where the package was created
by a different 3rd-party, not google.  So how else would you expect the
3rd-party package to satisfy the dependency?


I didn't say the chrome packages came from google. But, the TO has some
chrome RPM installed which "provides" the libstdc++ version required by
teams, but doesn't really provide this libstdc++ version to the whole
system. That's why the RPM is broken, it claims to provide a libstdc++
version which it doesn't really provide.


And I ask again, how else would you expect the package to satisfy the 
dependency in chrome for the newer libstdc++?  The package was 
explicitly created to allow chrome to run on an older system that 
doesn't have the newer libstdc++, by rights it should work with other 
programs that need a newer libstdc++ as well provided that they set 
LD_LIBRARY_PATH appropriately.  So it does, in fact, provide the stated 
dependency for the entire system, you just have to tell programs that 
need it where to find it.



It may have worked before because older teams required a libstdc++ version
which is available on CentOS 7.


Correct.


The broken chrome packages are the reason why RPM allowed the new teams
version being installed.


Again, they are not broken, they are suitable for the systems they were 
built for, which would be current Fedora systems (which happen to have a 
newer libstdc++).



But because the chrome package doesn't really
provide to the systems what it claims,


You're confusing here.  I assume you mean the package that provides the 
libstdc++ dependency which happens to have chrome in it's name but is 
not actually chrome and does not come from google or chrome.



teams won't work an is in a broken state.


teams should work if LD_LIBRARY_PATH is set appropriately.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

[Peter]

On 16/07/21 8:41 pm, Simon Matter wrote:

No, it looks for several different "libstdc++.so.6" versions, and the
"chrome" package provides them all. I just listed one of them to
illustrate the point.


I'm not sure that's true. You said your chrome package provides it all but
from what I see, it installs its libs into /opt/google/chrome/lib. But,
your system doesn't know about private libs installed in /opt and I think
the chrome package should NOT "provide" its private libs in its RPM
packages.


I think you missed from a different post where the package was created 
by a different 3rd-party, not google.  So how else would you expect the 
3rd-party package to satisfy the dependency?



IMHO, if it's like that, then the chrome packages are crap :-)


The chrome packages are not built for CentOS or supported on such, it is 
coincidence that they happened to have worked in the past.  They will 
continue to work if the libstdc++ dependency is satisfied.



What happens if you try this:

$ export LD_LIBRARY_PATH=/opt/google/chrome/lib
$ teams


Better to just do:
LD_LIBRARY_PATH=/opt/google/chrome/lib teams

...or if you have a desktop launcher that you use, edit the command and 
add this to the beginning:


env LD_LIBRARY_PATH=/opt/google/chrome/lib


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [External] Re: Microsoft Teams on CentOS 7. Does the latest version work?

[Peter Ajamian]

On 15/07/21 4:14 pm, Peter wrote:
Try this installing gcc10-libstdc++ from GhettoForge 
(https://ghettoforge.org/) and then set LD_LIBRARY_PATH=/opt/gcc-10.2.1


Sorry that's http, not https:
http://ghettoforge.org/


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [External] Re: Microsoft Teams on CentOS 7. Does the latest version work?

[Peter]

On 15/07/21 8:13 am, Phil Perry wrote:

Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
    Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
    Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit)
Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
    Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
    Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit)
Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
    Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit)


Try this installing gcc10-libstdc++ from GhettoForge 
(https://ghettoforge.org/) and then set LD_LIBRARY_PATH=/opt/gcc-10.2.1


If you have a desktop launcher edit the launcher and prefix "env 
LD_LIBRARY_PATH=/opt/gcc-10.2.1 " to the command.


Then see if it works.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-docs] Request Wiki page for proposed kmods SIG description

[Peter Georg]

Dear all,

I'd like to request the creation of a Wiki page for the "kmods" SIG I 
proposed recently on the centos-devel mailing list.


Similar to pages for other SIGs, the proposed subject is "kmods SIG" and 
the proposed location is:

https://wiki.centos.org/SpecialInterestGroup/Kmods

My username is: PeterGeorg

Please let me know in case you need any further information.

Thanks!

Peter
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] will there be centos 8.4?

[Peter]

On 11/05/21 4:47 am, Fabian Arrotin wrote:

Talking about that : what's the official position on how CentOS 8 will
go EOL ?
I'd be myself in favor of transparently redirecting CentOS 8 linux
yum/dnf mirrorlists to 8-stream end of the year, so that people would
still get automatically updates and would be able to "dnf install "


Can we not do this?  It could make migrating away from CentOS more 
difficult for those who choose to switch to another EL8.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Resize a VM: any risk involved ?

[Peter Larsen]

On 4/8/21 11:43 AM, Nicolas Kovacs wrote:

# yum install cloud-utils-growpart
# lsblk
# growpart -v /dev/sda 3
# resize2fs /dev/sda3

Now here's my question (finally): is there any risk involved in this sort of
operation? Or can it be performed on a production system without having to
worry about data loss?


Risk from a Virtual Machine perspective or just generally?  One of the 
many operations I do often with VMs is "mess" with disks treating them 
as logical devices means I can add storage later, easy, when needed. In 
most cases I don't take the system down at all. "It just works".


But there are always risks. If you're doing this manually, typos can 
bring down your system. Another part of your risk is using partitions. 
Partions, particular the "system" drive where rootfs is, can act oddly 
on Linux when it's live. It's not rare that you find the kernel refusing 
to do a "partprobe" on /dev/sda - which means you need a reboot for the 
kernel to see the new size of a partition. Next, your partition stuff is 
very limited - compared to so many other things you have in CentOS you 
should really avoid using partitions for anything - well, perhaps but 
that's about it.


I use LVM on all my systems. To expand a system I simply add a new 
virtual disk, expand the VG, and then expand the filesystem using 
"lvexpand -r". It's painless and there are no risks of conflicts. LVM 
allows me to remove the disk later if need be - ie. the first disk size 
you added was 50GB but you realize a few months later that you 
calculated wrong as should have added 500GB. LVM allows you to add a new 
disk of 500GB, move everything from the old disk to the new, and then 
you can remove the new one - all without taking down the file system!


It also comes with snapshot features for persistent backups. So at a 
risk of sounding like a broken record, don't use partitions. If risk is 
what you're focused on, there's a lot more risk using plain partitions 
vs. volume management.


--
Regards
  Peter Larsen
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] almalinux?

[Peter Eckel via CentOS]

> Looking.  Rocky was supposed to release something at the beginning of the
> month, but I haven't seen anything.

The release was postponed by one month.

"Unfortunately we’ve had to revise our previous update for a release candidate 
from March 31 to April 30, due to complications in the build efforts. We 
continue to make steady progress, and are optimistic about our revised 
timeline."





signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] almalinux?

[Peter Eckel via CentOS]

Hi Simon,

+1

I expect that to happen sooner or later. Currently Alma has a head start with 
Rocky postponed until the end of April, but to me the race is still open.

As is the case with many other colleagues, I'm currently stuck with RHEL clones 
because RHEL/CentOS is what my customers are using and they are not going to 
switch to Debian/FreeBSD/Ubuntu/whatever any time soon for a plethora of 
reasons. So it would be nice to have a one-stop-solution instead of having to 
decide which of the clones will be the more future-proof option.

Regards,

  Peter.

> On 5. Apr 2021, at 20:31, Simon Matter  wrote:
> 
> 
>> 
>> Anyone looked into almalinux? I was sort of waiting for rocky, but I see
>> from over the weekend on slashdot that almalinux stable is released.
>> 
>>mark
> 
> I hoped they would join forces and produce only one RHEL clone but put
> some effort into bringing EPEL to a usable state for EL8 instead. IMHO
> that would help *MUCH* more than to have two almost identical rebuilds of
> RHEL.
> 
> Simon
> 
> ___
> 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] almalinux?

[Peter Eckel via CentOS]

Hi Mark, 

> Anyone looked into almalinux? I was sort of waiting for rocky, but I see from 
> over the weekend on slashdot that almalinux stable is released.

yup. 

So far I upgraded a couple of test machines using the conversion tool they 
provided on GitHub (works fine, although it seems each and every package will 
be re-downloaded during the migration process which makes it a bit tedious), 
and I used my own KVM/virt-install/Kickstart/Ansible-Workflow to bring up one 
new server from scractch with no further change than swapping the ISO image for 
CentOS against the one for Alma 8.3.

Both procedures worked absolutely flawless, and so far I still have to find the 
first issue with any of the machines converted to or initially set up with 
AlmaLinux.

Caveat:

1. All of the machines I tried are VMs, no bare metal servers or VM hosts.
2. All of the machines are headless with no GUI installed at all.
3. No UEFI or Secure Boot (the latter is an open issue with Alma AFAIK).

On the other hand I did not need to change a single bit of Ansible code or 
Kickstart template in order to make it work, so the compatibility to CentOS 
seems to be very good.

Regards, 

  Peter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

> All relevant logging is centralised to a server cluster running Graylog.

... and, because I forgot to mention it: Yes, that server cluster has a 
"persistent data" device.

Regards, 

  Peter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

Hi Simon, 

> Whenever I read such things I'm wondering, what about things like log
> files? Do you call them OS files or persistent data? How do you back'em up
> then?

I don't. 

All relevant logging is centralised to a server cluster running Graylog.

Regards, 

  Peter.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

Hi Niki,

I'm using a similar approach like Stephen's, but with a kink.

* Kickstart all machines from a couple of ISOs, depending on the requirements 
(the Kickstart process is controlled by Ansible)
* Machines that have persistent data (which make up about 50% in average) have 
at least two virtual disk devices: The one for the OS (which gets overwritten 
by Kickstart when a machine is re-created), and another one for persistent data 
(which Kickstart doesn't touch)
* Ansible sets up everything on the base server Kickstart provides, starting 
from basic OS hardening, authentication and ending with monitoring and backup 
of the data volume
* Backup is done via Bareos to a redundant storage server

That way I can reinitialise a VM at any time without having to care for the 
persistent data in most cases. If persistent data need to be restored as well, 
Bareos can handle that as soon as the machine has been set up via Ansible. OS 
files are never backed up at all.

An improvement I'm planning to look into is moving from Kickstart to Terraform 
for the provisioning of the base machines. Currently it takes me about 10 
minutes to recreate a broken VM provided the persistent data is left intact. 

Cheers, 

  Peter.

> On 31. Mar 2021, at 14:41, Nicolas Kovacs  wrote:
> 
> 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
> 
> -- 
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> 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] nmcli

[Peter Larsen]

>how do I just remove the single ADDRESS I added as an alias ? not the whole
thing ?

You first remove all ipv4.addresses and then add the one you want. Then you
save/activate.

On Tue, Mar 30, 2021 at 4:41 PM Jerry Geis  wrote:

> under CentOS 7 - I use "alias" like eth1:0 for an alias network. Remove the
> file restart network - and back to normal. Now I am trying to us
> NetworkManager.
>
> I can 'add' the network fine. however - when I remove the network
> nmcli connection delete "Wired connection 2" ipv4.addr  192.168.1.58/22
>
> it remove BOTH address and removes the "Wired connection 2" config file -
> and it reverts to DHCP not the other static address I had associated with
> "Wired connection 2".
>
> how do I just remove the single ADDRESS I added as an alias ? not the whole
> thing ?
>
> Thanks
>
> Jerry
> ___
> 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] How to install XFCE on CentOS 8?

[Peter]

On 11/02/21 11:54 pm, Simon Matter wrote:

# dnf group install "Xfce"
Last metadata expiration check: 0:05:02 ago on Thu 11 Feb 2021 11:45:57 CET.
No match for group package "NetworkManager-gnome"
No match for group package "thunar-archive-plugin"
Dependencies resolved.

  PackageArch  VersionRepository
Size

Installing group/module packages:

...

Installing Groups:
  Xfce

Transaction Summary

Install  21 Packages

Total size: 10 M
Installed size: 48 M
Is this ok [y/N]:


Indeed I actually get the same output.  Those are soft dependencies, you 
should be able to answer "Y" here and go ahead and install XFCE.  Feel 
free to file a bug with EPEL about the missing deps.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to install XFCE on CentOS 8?

[Peter]

On 11/02/21 10:24 pm, Simon Matter wrote:

Hi,

Is anyone here running XFCE desktop on CentOS 8? If so, how did you
install it?

I just tried to install it from EPEL and this is what I got:

# dnf group install Xfce
Last metadata expiration check: 0:14:01 ago on Thu 11 Feb 2021 10:05:47 CET.
No match for group package "NetworkManager-gnome"
No match for group package "thunar-archive-plugin"


I run the command and it resolves the dependencies just fine, but does 
not want to install any of the above two packages.



I'm unable to find packages for NetworkManager-gnome or
thunar-archive-plugin anywhere in CentOS 8 or EPEL 8.


Can you please show the full output of your command, please?  Also the 
output of:


dnf repolist -v epel


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Infiniband special ops?

[Peter Kjellström]

On Thu, 21 Jan 2021 23:33:56 +
lejeczek via CentOS  wrote:

> Hi guys.
> 
> Hoping some net experts my stumble upon this message, I have 
> an IPoIB direct host to host connection and:
...
>  > $ iperf3 -c 10.5.5.97  
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-10.00  sec  16.2 GBytes  13.9 Gbits/sec 
> 0 sender
> [  5]   0.00-10.00  sec  16.2 GBytes  13.9 
> Gbits/sec  receiver
> 
> It's rather an oldish platform which hosts the link, PCIe is 
> only 2.0 but with link of x8 that should be able to carry 
> more than ~13Gbits/sec.
> Infiniband is Mellanox's ConnectX-3.

If you want to test the infiniband performance you ib_write_bw for
example not iperf.

IPoIB will always be quite a bit slower than native IB.

That said, if you want to optimize IPoIB for performance make sure
you're running connected mode not datagram mode.

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] MTU report question

[Peter Kjellström]

On Mon, 14 Dec 2020 14:46:30 +0100
Patrick Bégou  wrote:

> Hi,
> 
> I'm deploying a CentOS8 (not stream ) cluster and I have a question
> about MTU on the interfaces. I have a connectX6 Mellanox interface
> where I need IBoIP setup.
> I've setup this interface via nmcli and set the MTU to 65520 with:
> 
> nmcli connection modify ib0 mtu 65520
> nmcli connection up ib0
> 
> Running "nmcli connection show ib0" report:
> 
> infiniband.mtu: 65520
> 
> But "ip addr show ib0" report a mtu of 2044:
> 
> 6: ib0:  *mtu 2044 *qdisc mq
> state UP group default qlen 256

2044 is what you get with DATAGRAM mode and the native IB running with
2K packages. You can get 4092 IPoIB MTU with 4K IB. And you do want to
run 4K native IB in general.

To run 64K MTU you need to switch from DATAGRAM mode to CONNECTED mode
for IPoIB. CONNECTED mode give the highest single stream bandwidth
typically but may not give best overall performance (vs 4092 DATAGRAM
mode).

Cheers,
 Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-es] CentOS Governing Board: Do not destroy CentOS by using it as a RHEL upstream

[Peter Q.]

Bonjour,
Je viens de signer la pétition "CentOS Governing Board: Do not destroy
CentOS by using it as a RHEL upstream" et je souhaitais savoir si vous
voudriez nous aider en ajoutant votre signature.

Notre objectif est d'atteindre 10 000 signatures et nous avons besoin de
plus de soutiens. Pour en savoir plus et pour signer, c'est ici:

http://chng.it/Pg5TsFb69N

Merci !
Qz
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] CentOS 8.3 bugs

[Peter Huebner]

Am Freitag, den 18.12.2020, 00:50 +0800 schrieb d tbsky:
> > On 12/17/20 3:47 AM, Simon Matter wrote:
> > > > Hi:
> > > >     just try to install CentOS 8.3. I use two sata disks and
> > > > create
> > > > mdadm raid1 with LVM. Normally when I want to reinstall this
> > > > system,
> > > > anaconda should recognize the raid1/lvm so I can reformat it.
> > > > anaconda at CentOS 8.3 failed to do the job. I tried Scientific
> > > > Linux
> > > > 7.9 and RHEL 8.3, both can recognize installed CentOS 8.3
> > > > correctly
> > > > and let me reformat it.
> > > 
> > > Sounds like a bug then, yes.
> > > 
> > > > 
> > > >     and there is no net-snmp-perl package in CentOS 8.3
> > > > repository.
> > > > although it is in RHEL 8.3.
> > > 
> > > It's in appstream, checked in CentOS 8.3, Oracle 8.3 and
> > > Springdale 8.3.
> > > 
> > 
> > It is indeed there.
> > ./AppStream/x86_64/os/Packages/net-snmp-perl-5.8-17.el8.x86_64.rpm

Crazy, in Oracle Linux, it cames today as new package together with
net-snmp-libs in repo AppStream also. Considering Oracle Linux has RHEL
as upstream (not CentOS), the missing problem must be originated at
RHEL.

> 
> 
>   I find that now in the current mirror. but I could not find it  a
> week ago.
>  the problem old appstream repo file name is like below(and other
> previous files are also broken):
>  Nov 21 01:51
> 94ed8a9817da5e607b7674beb0b22fb09073901b041c26746124a5fd9f40a4e4-
> filelists.xml.gz
> 
> the fixed new one now net-snmp-perl is included:
> Dec 15 23:05
> 923c0ccd2eb9ea937baecdc108b9284cf8ea56d0ae9d2465a3c9efa0d5c8d402-
> filelists.xml.gz
> 
>  the strange part is "net-snmp-perl" is already at Centos-Stream
> before 8.3 release since I used it from there weeks ago. but it is
> missing at the 8.3 snapshot files until Dec-15.
> 
>  anyway I think it is fixed now.
> ___
> 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

[Peter Eckel]

Hi Johnny, 

> $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.
> 
> .. THEN buy 30 machines minimum (servers, not workstations) for
> building and testing, buy a service contract for those 30 machines, host
> the bandwidth required to sync out to 600 worldwide servers.
> 
> We need all the CI machines .. that is a bunch of blade servers for
> that.  They need service contacts too.

I don't doubt your numbers, they sound perfectly reasonable to me. 

On the other hand: How many of the employees will be laid off or reallocated 
now that CentOS point releases are no longer published? How many of the servers 
will be shut down, how many service contracts will be cancelled? What's your 
estimate of the reduction in bandwidth that will be saved by replacing point 
releases by a stream of releases with more frequent updates?

> In any event it doesn't matter.  The decision is made. If people don't
> want to use CentOS Stream, then don't.  The decision is not changing.

Too bad.

I've just completed a migration of about 30 servers from CentOS 6 to CentOS 8, 
expecting to get another 9 years of lifetime out of that (substantial) work. 
Now I have one year left of that, in which I need to plan what to do. One 
option is to go with the flow and switch to Stream, but I must admit that it's 
not my favourite one. Rocky, Lenix or maybe Springsdale would be the next best 
guesses. But given the fact that I migrated the whole setup process to Ansible 
it might be a good idea to jump off the cliff and switch to Debian or FreeBSD. 
As I said, I have one year left  which I plan to use for evaluation of options.

Two of my big customers will definitely not have that range of options. One of 
them is a RHEL shop with a tendency to try Debian, and last week they strongly 
thought about leaving the RHEL space entirely. The FOSS team there had made 
substantial effort over the last year to get CentOS on the list of 
company-approved operating systems (currently that's only RHEL and Debian), and 
now that work has gone down the drain completely. You can imagine how they feel 
now.

The other one is stuck with RHEL-based distributions (Oracle, you know) - but 
they consider switching to OEL with support as well. At least they'll get rid 
of the hassle with the RHN that way, which can be a pain in the backside.

I doubt those two are the only ones. My guess is this decision will backfire 
big time. I would love to stand corrected in one year's time, because I really 
like the RHEL way of doing things. Or rather, I liked it. Until last week. 
Still a great set of products, but the trustworthiness of Red Hat has taken a 
big hit for me, and for my customers as well.

Anyway, thank you and the rest of the CentOS team for all the great work you've 
done and are doing. It is appreciated, and it will not be forgotten.

  Peter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 8 future

[Peter Huebner]

Am Dienstag, den 15.12.2020, 12:06 -0500 schrieb Matthew Miller:
> 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.
> 
But with the move of CentOS/RedHat to restrict the previously promised
support time for CentOS 8, they loose alot of trust in future
statements.
Trust must be earned and RedHat/CentOS/IBM has carelessly wasted that
trust.

> > 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
> 
> 
We will see, what happens in the future, but currently i cannot
recommend without serious doubt to trust RedHat in the long run.

--
Peter Huebner

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Oracle a real alternative to Centos?

[Peter Huebner]

Am Dienstag, den 15.12.2020, 10:14 +0100 schrieb Ruslanas Gžibovskis:
> GPL stuff applies only to GPL parts, but they can have Oracle blob in
> everything. The same time, TM's and so on...
According to the Oracle license terms and official statements, it is
"free to download, use and share. There is no license cost, no need for
a contract, and no usage audits."
Recommendation only: "For business-critical infrastructure, consider
Oracle Linux Support." Only optional, not a mandatory requirement.
see: https://www.oracle.com/linux


> Also For example, according to RH license. You can install evaluation
> Version every month on your development system, where sysadmin
> develops a
> platform for the developer, but as soon when this platform is ready,
> it is
> a production system, but no-one will come to you and check, is it
> really
> still under development or it is already prod platform, which is
> rebuilt
> every 3 weeks with jerkins job... (yes, Mr. Jerkins) :)
> 
No need for such a construct. Oracle Linux can be used on any
production system without the legal requirement to obtain a extra
commercial license. Same as in CentOS.

> Legal and "can do" are 2 different things. ;)
So Oracle Linux can be used free as in "free-beer" currently for any
system, even for commercial purposes. Nevertheless, Oracle can change
that license terms in the future, but this applies as well to all other
company-backed linux distributions.
--
Peter Huebner

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on nmcli CentOS 8

[Peter Larsen]

On 12/11/20 3:19 PM, Jerry Geis wrote:

So now I need to "remove" both or all and add the 1 I want as static ? how
do I do that?



You have to remove the addresses and then add a new one. The 
ipv4.addresses is plural and additional when you set it. So to override 
you need to first remove all addresses, and add those you want to keep. 
Once you change method to manual, dhcp should be disabled.


You do need to reactivate the connection once you've save the changes 
(same/typical nmcli procedure).



--
Regards
  Peter Larsen
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [EXT] Re: https://blog.centos.org/2020/12/future-is-centos-stream/

[Peter Georg]

On 09/12/2020 18.10, Brendan Conoboy wrote:

On Wed, Dec 9, 2020 at 7:21 AM Phil Perry  wrote:


On 09/12/2020 03:26, Brendan Conoboy wrote:

On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs  wrote:


On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote:

On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote:



"CentOS will become the developer playground"


This one is categorically not the case. Even Fedora isn't a developer
playground. Everything landing in CentOS Stream is actually *planned*

(with

emphasis intentional) to go in a future RHEL release.


It's all the talk of SIGs and developing and testing and that Stream
will be the centerpiece of that. That's what I meant.



I don't know if I'd call SIGs a playground, but they're certainly an
important venue for communities to explore variations.



Previously, all the development around RHEL releases was done in

secret,

in

the Red Hat black box. Now it's out of the box and can be watched.

There

may

be some launch pains, but I expect the average quality of an update

hitting

CentOS Stream to be very high.


I don't get that from the documents released today.  If Stream is *not*
a test-bed, then surely the code that appears in Stream must be fully
formed in secret behind the scenes first. Yes, it will appear piecemeal
rather than in one big chunk, but it has been categorically denied that
Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling
release.



I think maybe some of the nervousness about CentOS Stream comes from RHEL
seeming opacity on its development model.  As one of the architects of

our

development process I'd be happy to field questions.  I'll start by

making

a two points in case they're in any way unclear:

1. Everything that goes into RHEL lands upstream first, then the patches
are backported into the RHEL releases.
2. Most of the work we do or plan on doing is in bugzilla.redhat.com.

If

you go into the RHEL8 product queue today and file a bug you'll see

"CentOS

Stream" as a "Version" where an issue is encountered.

I think what a lot of people are concerned about is the rolling-release

aspect of this. There will be no definitive versioning of CentOS in the
future - all you will be able to say is "fully updated" and it won't be
possible to slot a CentOS system in to exactly match a RHEL version.
Will third party RPMs built against RHEL 8.x be installable on a CentOS
8 Stream system? The answer is surely "it depends", but there are a lot
of hardware vendors that target drivers to RHEL releases, which may
well make CentOS non-viable for hardware that doesn't have drivers
built in to the kernel.



Generally if they follow the ABI guidelines I would expect it to work.
Those are here:

https://access.redhat.com/articles/rhel8-abi-compatibility


For loadable kernel modules there's a kernel ABI.




Hi Brendan,

This point is *critical*, so I apologise in advance for the lengthy
post, *you* are breaking the kernel ABI between RHEL8 and Stream.

One of the main unique selling points of RHEL is the stability of it's
kernel ABI. No other distro provides this. The very nature of rolling
kernel updates in Stream breaks the kernel ABI and breaks compatibility
between RHEL8 and Stream. What works on RHEL8 may not work on Stream. At
the kernel level, the two products diverge in fundamental compatibility
and are not compatible, are no longer the same.

How bad is this divergence / breakage? Well, we know the kernel ABI will
change from time to time, almost exclusively at new point releases due
to the massive backporting work that goes into the RHEL kernel. And this
is fine, we know it's coming, we know when it's coming, and we can plan
for it's impact. It's a price well worth paying.

To put this in context, at elrepo I currently help maintain around 50
3rd party kernel driver packages for RHEL8. When RH released RHEL8.3,
every single package in our repository broke due to changes in the
kernel ABI in the 6 month period between RHEL8.2 and RHEL8.3. It's not
ideal, but we accept it as a price we pay for the otherwise excellent
stability of the kernel ABI during the proceeding 6 months. As I said
above, we know it's coming, we know when it's coming, and we can plan
for it.

Now contrast that with Stream. Every kernel update in Stream has the
potential to break the kernel ABI causing packages built for RHEL to
break. We don't know when that may happen (only that it will), we don't
know how often it will happen, we have no idea which packages it will
break. and we have no way to fix it. Consequently, elrepo has been
unable to support Stream kernels.

It is not just elrepo's users that the Stream kernels will affect. All
OEM hardware manufacturers releasing 3rd party driver rpms as part of
Red Hat's Driver Update Programme or otherwise will be similarly
affected, and their driver updates will not be applicable to or
compatible with CentOS Stream. In fact, RHEL's own driver update
packages will likely need rebuilding 

Re: [CentOS] Upgrade OpenSSH version to the latest stable version on CentOS Linux release 7.9.2009 (Core).

[Peter]

On 1/12/20 4:04 pm, Kaushal Shriyan wrote:

I am running CentOS Linux release 7.9.2009 (Core). Is there a way to
upgrade OpenSSH version openssh-7.4p1-21.el7.x86_64 to the latest stable
version openssh-server 8.4 using yum repositories or rpm binaries?


No, 7.4p1-21 is the most recent up to date version in CentOS 7.  See 
https://access.redhat.com/security/updates/backporting/ for more info.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Firefox 78 under CentOS 6 -- no sound?

[Peter]

On 22/10/20 10:25 am, Stephen John Smoogen wrote:

Basically that says that upstream no longer thinks that Firefox is runnable
on RHEL-6/CentOS-6 anymore. I think there was a similar problem at the end
of EL-5 when a 'YOU HAVE TO UPGRADE' fix from Mozilla was released and
while a lot of work was done by Red Hat to get it to work on RHEL-5, some
items (and I really think it was sound and plugins) did not work. At the
tail end of a release, most 'desktop' concerns are very hard to figure out
as 10 year old software API's are rarely kept working by the various
'upstreams'.

I want to be clear that I do understand this is causing major issues for
users. I think a lesson learned from EL-5 and EL-6 is that EL releases need
to be clearer on the difference between desktops and servers. There seems
to be a point where desktop utilities fixes are mainly going to be
'reasonable effort' versus 'guaranteed' to be 100%... usually in the last 6
months of a release. That way users can plan better that a certain amount
of work is going to be needed by them to continue it working.


What confuses me here is why would Red Hat rebase a package so close to 
EOL.  Now that they have they're stuck with either leaving a severly 
broken firefox or providing a fix less than 6 weeks before EOL.  I 
honestly don't know which way they'll go here but it just seems to me 
like it was a very poor decision to rebase firefox in RHEL6 so close to 
EOL to begin with.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Mock config error

[Peter]

On 25/08/20 11:27 am, Jonathan Billings wrote:

On Aug 24, 2020, at 16:48, m...@tdiehl.org wrote:


Also, I am trying to add a dist tag to rpms that I build in mock.
In the epel-7 configs I do something like the following:
config_opts['macros']['%dist'] = '.el7.tnt' to get a dist tag on the
rpms. In epel/centos 8 this does not work.

Does anyone know how to apply a dist tag in the epel-8 mock configs?


config_opts['macros']['%dist'] = '.gf.el8'

...works for me without any further changes:
http://mirror.ghettoforge.org/distributions/gf/el/8/gf/x86_64/


Is mock documented anywhere besides the src code? I cannot find any
documentation that explains what actually needs to be in a mock
configuration file or in this case how to specify my own dist tag.


/etc/mock/site-defaults.cfg documents all of the possible config 
settings, then there is:


https://github.com/rpm-software-management/mock/wiki


It seems that the OpenSUSE mock configs[1] use the same syntax.  I wonder if 
you need to invoke mock in a specific way to not override the macro?


Not that I have been able to tell.  Setting the dist macro has always 
just worked for me.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 8.2 (2004) Linux Server is Compatible with Dell PowerEdge R640 1U Server

[Peter Kjellström]

On Thu, 13 Aug 2020 21:59:42 +0800
Turritopsis Dohrnii Teo En Ming  wrote:

> There are no issues so far.

Hahaha, I read _in_Compatible :-D

...generally nobody reports a server compatible.

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [Sharing] CentOS 8.2 (2004) Linux Server is Compatible with Dell PowerEdge R640 1U Server

[Peter Kjellström]

On Wed, 12 Aug 2020 21:46:19 +0800
Turritopsis Dohrnii Teo En Ming  wrote:

> Subject: [Sharing] CentOS 8.2 (2004) Linux Server is Compatible with 
> Dell PowerEdge R640 1U Server

This server should be fully ok to run RHEL8 and CentOS8. What exactly
goes wrong?

 https://access.redhat.com/ecosystem/hardware/2941651

/Peter K

> Good day from Singapore,
> 
> I have just installed CentOS 8.2 (2004) Linux Server on Dell
> PowerEdge R640 1U Server for "Donald Trump and Xi Jinping Investment
> Company LLP" (fictitious/fictional company name used) in Singapore on
> 11 August 2020 Tuesday.
> 
> I can confirm that CentOS 8.2 (2004) is compatible with Dell
> PowerEdge R640.
> 
> The hardware specifications of Dell PowerEdge R640 are:
> 
> (1) Processor: Intel Xeon Silver 4210R CPU @ 2.40 GHz (10 cores, 20 
> threads)
> (2) 128 GB DDR4-2400 RAM (8 pieces of 16 GB RAM, all 8 slots filled
> up) (3) PERC H740P Mini RAID Controller
> (4) 2 units of 960 GB SATA 6 Gbps SSD in RAID 1 configuration
> (5) Network Ports:
>  4 x 1 GbE
>  2 x 10 GbE + 2 x 1 GbE
> 
> Just sharing only.
> 
> 
> 
> 

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Unable to find the used space

[Peter Kjellström]

On Mon, 29 Jun 2020 15:21:12 +0530
Sachchidanand Upadhyay via CentOS  wrote:

> Hi,
> 
>  While checking with df -h, it's showing the used space is 94% on
> root (/). If checked with du -sh, it's not showing the used space.
> 
>   # df -h
> Filesystem Size Used Avail Use% Mounted on
> devtmpfs 7.8G 0 7.8G 0% /dev
> tmpfs 7.8G 0 7.8G 0% /dev/shm
> tmpfs 7.8G 857M 7.0G 11% /run
> tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
> /dev/mapper/centos-root 50G 47G 3.4G 94% /
> /dev/mapper/centos-home 241G 47G 195G 20% /var/log
> /dev/sda1 1014M 189M 826M 19% /boot
> tmpfs 1.6G 0 1.6G 0% /run/user/0
> tmpfs 1.6G 0 1.6G 0% /run/user/1002

As an addition to what others have already said. You'll also miss
things "hidden under mounts". That is, if you had 5G in /var/log on the
root file system and then mounted a different device on /var/log, then
that 5G would still be there but invisible.

Also, /dev/mapper/centos-home, HOME?!, on /var/log?

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] HP vs. Brother Printers: Use with Centos/Fedora

[Peter]

On 28/06/20 9:33 am, Jay Hart wrote:

If you had to rate which printer brand works better with Linux (Fedora and 
Centos), what would it be?


I'm currently on a Brother MFC-J4620DW and I recommend it 
wholeheartedly.  Others here have recommended brother for laser printing 
but I also think they're great ink jet printers.  Because you're not 
replacing the print head every time you replace the ink cartridge it 
cuts back on ink cost considerably and I have had no problems using 
3rd-party ink cartridges with it which really bring the cost down big 
time.  You can order sets of 3rd-party cartidges online for next to 
nothing, and I can count on two fingers the number of times I've 
received a dud cartridge.


I wouldn't touch an HP with a ten foot pole, though.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 22/06/20 10:13 am, Stephen John Smoogen wrote:

There are 2 sets of work.
1. There is the work on the tools which were slapped together as an
emergency from parts before 8.0. Those mbboxx tools are getting a
rewrite and upgrade currently by the CPE team to make them more useful
in the future. Stream only helps in that it is the excuse for that
work to be done versus it molding and falling apart right after every
8.x release comes out.


I didn't know that a rewrite is still needed on the current tool set and 
granted Stream can help with this, but I hardly think that it's 
necessary and the tool set can always be tested against the current 
release (8.2) from git.



2. There is the work that happens because various things are rebased
and you need to figure out the HTF you get from build A to build A+1
by rebuilding N packages. That is work that Stream should help on
because this is then knowledge is being done in stream before hand. If
you know that package A went to A+1 then to A+2 and then back to A+1
but you learned how to do the second A+1 from a flag you used with
A+2, then the amount of time reinventing the wheel is shortened.


This I do realize and it's the one exception I considered where Stream 
might come in handy, but not handy enough to justify its existence, imo. 
 Usually in a new point release there might be a small handful of 
packages that need re-basing, out of those the number of packages that 
would need to have the spec file tweaked to build them would be minimal 
(at a complete guess three or less) and out of those the number that 
would require a change to the tool set would likely average out to be 
less than one per point release.  In a worst-case scenario it might save 
a day or two on a particularly nasty point release, and this would 
easily be recouped in the amount of time it would save if the CentOS 
team did not have to maintain Stream at all.


Now these are just semi-educated guesses and I don't have the experience 
to justify this so I'm happy to consider real numbers that prove me wrong.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 22/06/20 7:03 am, John Pierce wrote:

On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS 
wrote:


On 21/06/20 1:23 pm, John Pierce wrote:

but the build process should be the same, no?I can't believe RH
would
use a completely different build process for the release than for the
beta/development stuff.


The packages still have to be built as a whole, they need to go through
QA testing, isos need to be built and tested.  The only thing that I can
think of that Stream benefits this process is to help Red Hat find the
odd bug here and there before their final release (after which CentOS
still has to do everything listed above).


As I understand it the whole full build and QA and whatever may still be
done again. The big difference is that the whole work of how to build and
setting up the build infrastructure has already been done and is known and
tested. So the complete build is going quite fast and the big delays are a
thing of the past.

If it's going to be like that it sounds very good.


exactly, that was my point.I remember 8.0 was very delayed by how much
harder and different the build process was.


That work was completed in the build of 8.0 and to a smaller extent 8.1. 
 Stream doesn't really add anything here.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 21/06/20 1:23 pm, John Pierce wrote:

but the build process should be the same, no?I can't believe RH would
use a completely different build process for the release than for the
beta/development stuff.


The packages still have to be built as a whole, they need to go through 
QA testing, isos need to be built and tested.  The only thing that I can 
think of that Stream benefits this process is to help Red Hat find the 
odd bug here and there before their final release (after which CentOS 
still has to do everything listed above).



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 21/06/20 9:15 am, John Pierce wrote:

On Sat, Jun 20, 2020 at 4:08 AM Tom Bishop  wrote:


+1 Streams is not for a production workload, if I wanted that I can easily
deploy an Arch instance if I want or need a rolling distro (it's not Redhat
etc but still). If Redhat wanted CentOS to be released near the same time
line they could help make that happen, although that wouldn't be in there
best financial interest.



think of it this way ... when the rolling beta is done, the final release
will be done with no further delay.


No, Stream and the core OS are built form a completely separate set of 
sources.  I highly doubt that we could use binaries built from stream to 
populate the final release.  The whole thing has to be rebuilt for the 
final release regardless of the status of Stream.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter Ajamian]

On 20/06/20 10:50 pm, Peter wrote:

On 20/06/20 3:50 am, Johnny Hughes wrote:

8.0  140
8.1  71
8.2  48


So the delays for 8 are significantly longer than they ever were for 7.


I should also say that the time lag for each point release of 8 seems to 
be dropping exponentially.  Hopefully this means that 8.3 will have a 
significantly shorter delay and we will be in the range of less than 30 
days for that, if so I can accept the delays up to this point.



Peter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 20/06/20 3:50 am, Johnny Hughes wrote:

Your dates are significantly off
Wikipedia has a delay listed in a table:

It is, for CentOS-7, For example:

7.0  27
7.1  26
7.2  25
7.3  39
7.4  43
7.5  31
7.6  34
7.7  42
7.8  28


For 6 .. since 6.2, it has bee3n between 10 and 18 days.

For 8:

8.0  140
8.1  71
8.2  48


So the delays for 8 are significantly longer than they ever were for 7.


And EL8 is exponentially harder with an entirely new build system and
the requirement to build modules.


But it seems like every major release has had reasons to be 
exponentially harder than the last.  With 7 it was the shift to using 
the git sources instead of the SRPMS that were previously provided by 
Red Hat, thereby necessitating an entirely new build system, plus the 
change to systemd and the introduction of a new point release numbering 
scheme, not to mention the move to entirely new infrastructure because 
of the change to Red Hat sponsorship.  So given those I find it hard to 
believe that the changes in 8 are so much different as to have had such 
longer delays than 7.


I'd also like to point out something else, from:
https://wiki.centos.org/About/Building_8.x#Current_Timeline_8.2.2004

It would appear that the package build was completed on the 4th of May, 
why didn't we get a CR repo dump this time around so that CentOS users 
wouldn't have to wait another month before getting critical updates?



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article about the state of CentOS

[Peter]

On 20/06/20 3:29 am, Johnny Hughes wrote:

How is this going to be fixed .. Welcome to CentOS Stream

Stream will be , once it is fully implemented, the ACTUAL development of
RHEL the 'next point release' on git.centos.org in the open.


So basically stream is a testing ground for RHEL.  It's not actually a 
rebuild of RHEL since it's what comes *before* RHEL, not after.



It will be a rolling distro that is GOING to be the Source Code used for
next RHEL point release.

Therefore, we will have all package as they are being worked on by the
RHEL Engineers .. and you can see it happen in progress.  You can also
use it however you want.  There will be no delay i this at all.  It will
be constantly moving. There will be no 500 pacakges drop or delays.


This is all well and good, but I don't think that CentOS was ever meant 
to be a testing ground for RHEL.  As the name actually stands for it is 
a "Community Enterprise OS" and it has always been a rebuild of the RHEL 
sources.  Stream is basically RHEL Rolling Beta, and that can hardly be 
considered "Enterprise".


I and I think many others find this focus on Stream to be rather 
distressing, and it does have the appearance to be taking focus away 
from the core OS.  This is further evidenced by the long wait times for 
release.


The way I see it, Red Hat pays the bills now, Red Hat employs the core 
team, and Red Hat wants a RHEL Beta platform, so that is what they have 
decreed that CentOS will become.  Now I could be wrong here because I 
certainly don't have any inside information about this, but it seems 
from teh outside looking in that any progress on the core OS is 
incidental and time spent on it has to be time leftover after any work 
is done on Stream.


Now I don't have an issue with Stream, in fact I think taht Stream can 
be beneficial to CentOS, but it hsould not be at the expense of the core 
OS, imo.  The core OS should take priority over any other CentOS 
project, whether it be streams, or SIGs or anything else, because we 
can't really have a Community Enterprise OS without the core OS.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum/dnf diff

[Peter]

On 6/06/20 7:34 am, Kenneth Porter wrote:
That's quite handy! But not what I'm looking for. I'm trying to figure 
out what edits I made to my config files.


Just mv those files that you changed (as shown by rpm -V packagename) 
and yum reinstall the package, then you can diff the original files to 
the ones you moved.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix restrictions

[Peter]

On 9/06/20 2:56 pm, Jon LaBadie wrote:

I hit another limitation.  My backup MX handler is a 3rd party who
will not use greylisting.  Thus all the 1st timers I rejected just
delivered to my alternate MX address and were not blocked at all.


Don't use a backup MX, they are a relic of the 90s when mail servers 
were often times not always online.  a sending mail server will 
generally retry the message for up to five days if your MTA is down so 
backup MXes are really not necessary.


As you have discovered, if you do decide to use a backup MX it really 
needs to have exactly the same anti-spam protections as the primary MX, 
but most backup MXes don't and spammers know this.  In fact many 
spammers will ignore the primary MX all together and push out SPAM 
directly to the backup MX.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to rebuild the kernel

[Peter Kjellström]

On Wed, 3 Jun 2020 20:24:35 +0530
Harsh chopra  wrote:

> Hi everyone,
> I am using Centos 7.8.2003 kernel 3.10
> . I was trying to build and install the latest linux stable kernel
> i.e. 5.7, I successfully did the process but accidentally messed it
> up by copying the .config file again in 5.7 kernel src,I tried to
> rebuild the 5.7 kernel but got make error as I was still on 5.7
> kernel.

You may want to have a look at elrepo and the kernel-ml package. Doing
this yourself can be painful.

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] XFS problem

[Peter Kjellström]

On Mon, 11 May 2020 12:40:15 +
Gestió Servidors  wrote:

> Hello,
> 
> My server is running kernel 3.10.0-1062.12.1 in a CentOS Linux
> release 7.7.1908. Since some weeks ago, server is restarting after
> XFS errors. Logs in /var/crash reported this information: [...]
...
> [443804.295922] blk_update_request: I/O error, dev sda, sector
> 72607920 [443804.295969] sd 0:0:0:0: rejecting I/O to offline device
...
> 10332927480 [443804.321376] sd 0:0:0:0: rejecting I/O to offline
> device
> [443804.321384] XFS (dm-2): metadata I/O error: block 0xf1
... 
> It seems problem are hard disk or XFS module, but physical RAID
> controller reports all hard disks are OK, so I suppose problem is XFS
> module. Also, I have read in this forum
> (https://bugs.centos.org/view.php?id=16960) something similar.

Just like your logs the thread you're referring to had SCSI errors
before the XFS errors. The thread ended with the OP concluding that it
was a problem on the hypervisor side (nothing to do with kernel/xfs on
the guest).

If you have a hardware RAID serving that block device I'd look at that
(and possibly its driver).
 
> Could someone say me is lastest kernel version for CentOS-7
> (3.10.0-1127) solves this problem?

Since neither are clear or confirmed it is not likely that anyone can
say...

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rpm command option

[Peter Kjellström]

On Wed, 6 May 2020 00:00:48 + (UTC)
Chris Olson via CentOS  wrote:

> We located an application recommended by one of customers
> for sharing certain data.  It was available for installation
> using a few different methods.  Using yum was also recommended
> for the installation.  The install instructions began with
> what appeared to be a fairly typical command as indicated
> below (with the URL slightly altered).
> 
> sudo rpm --import https://rpm.x.com/rpmrepo.key
> 
> To our junior employee assigned to perform the install
> on a test system, it seemed like a good idea to do some
> checking on the rpm option --import indicated in those
> instructions.  They did not find the --import in any of
> the 14 pages of the CentOS 7 man page for rpm.

Well I wouldn't called obvious, but the rpm man page has a "see also"
for rpmkeys(8) and this man page documents the rpm key related options.

I don't know how it came to be that rpm --import just quietly
does rpmkeys --import without documenting it though...

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] slow performance on company production server I need help

[Peter Kjellström]

On Wed, 22 Apr 2020 10:53:08 -0500
Christopher Wensink  wrote:
>Unit UnitType  Status %RCmpl  %V/I/M  Port  Stripe
>Size(GB)
>
>u0   RAID-5    OK -   -   - 256K    11175.8
>u0-0 DISK  OK -   -   p0    -   1677.28
>u0-1 DISK  OK -   -   p1    -   1677.28
>u0-2 DISK  OK -   -   p2    -   1677.28
>u0-3 DISK  OK -   -   p3    -   1677.28
>u0/v0    Volume    -  -   -   - -   4096
>u0/v1    Volume    -  -   -   - -   4096
>u0/v2    Volume    -  -   -   - -   2983.84

This read: You have 4 physical drives configured as one raid5 array.
The array has three volumes (v0, v1, v2). These three volumes will be
visible as three scsi devices in Linux.

You can use for example lsblk or lsscsi to list them.

Also, you may want to look physically for a battery backup unit (bbu).
The software said there isn't one and that certainly could be a
performance problem (as I would assume the controller turns off write-back
caching).

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7: cups-pdf Postprocessing prevented by selinux :(

[Peter Kjellström]

On Wed, 15 Apr 2020 04:55:13 +0200
hw  wrote:

> Hi,
> 
> how can I make it so that printing to a cups PDF printer can
> successfully run the postprocessing script I specified
> in /etc/cups/cups-pdf.conf?

I haven't run into this one myself so I'm not sure this will work (but
simple enough to try).

There is one cups exec related boolean in the base policy:

 # semanage boolean --list | grep -i cup
 cups_execmem   
 
You can try to enable it and see if it helps:

 # semanage boolean --modify --on cups_execmem

The semanage tool is in the policycoreutils-python package if you don't
have it installed.

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Versions in RHEL and CentOS

[Peter Kjellström]

On Thu, 2 Apr 2020 14:40:31 +0530
Thomas Stephen Lee  wrote:
> > On Thu, Apr 2, 2020 at 2:07 PM Peter Kjellström 
> > wrote:  
> 
> > I had no idea people still used that package. Especially on a
> > server.  
> 
> Is it due to some security issue ?

Not security but safety (and also, it's not needed when there are
supported ways to get that data and better).

By safety I refer the half-blind scanning of smbus etc. that
sensors-detect does.

To me it feels like a relic from desktops 15 years ago :-)

/Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Versions in RHEL and CentOS

[Peter Kjellström]

On Thu, 2 Apr 2020 11:10:23 +0530
Thomas Stephen Lee  wrote:
...
> /usr/bin/sensors
> 
> from the lm_sensors package
> 
> I had run
> 
> sensors-detect --auto

I had no idea people still used that package. Especially on a server.

Per core temperatures in linux for Zen2 is done using (a very up to
date kernel with its k10temp module). Alternatively one can look at:

 https://github.com/ocerman/zenpower.git

I don't know if it works with the c8 kernel (but it does not work with
the c7 one).

But in the end. Why care about per core temperatures? Setup basic
monitoring of the server using ipmi or whatever the vendor supports.

/Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Versions in RHEL and CentOS

[Peter Kjellström]

On Wed, 1 Apr 2020 10:01:04 +0530
Thomas Stephen Lee  wrote:
...
> Thanks for the information .
> Rented a new EPYC Rome Server from Hetzner, but sensors does not show
> status of all cores in list, which is why I asked.

Curious what "sensors" you are referring to..

Like this:

$ cat /sys/devices/system/cpu/online
0-63

or this:

$ lscpu | grep CPU\(s\)
CPU(s):64
On-line CPU(s) list:   0-63
NUMA node0 CPU(s): 0-15,32-47
NUMA node1 CPU(s): 16-31,48-63

or what?

/Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Need help to fix bug in rsync

[Peter Kjellström]

On Wed, 25 Mar 2020 14:49:24 +0100
Simon Matter via CentOS  wrote:

> Hi,
> 
> I've discovered a bug in rsync which leads to increased CPU usage and
> slower transfers in many situations.
> 
> When syncing with compression (-z)

Tbh, using -z with rsync is almost always a bad idea (unless you're on
some pre-historic type of network link..).

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C8 and Plasma5 error

[Peter]

On 11/03/20 9:19 pm, Alessandro Baggi wrote:
Sorry, I'm here again. I have created a bugzilla account and done what 
you said. Reading select list of which component give the error, I tried 
to locate what packages has kde5init but nothing contains it.


I run also "find / | grep "kde5init" but I don't get any results.

Seems that kde5init is not present on the system and inside repositories.


kf5-kinit has kdeinit5, maybe that's what you're looking for?


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Running CentOS 6 in a Docker container on a non-CentOS host

[Peter Kjellström]

On Mon, 9 Mar 2020 16:16:01 -0400
Alfred von Campe  wrote:

> > On Mar 5, 2020, at 6:05, Peter Kjellström wrote:
> > 
> > You can use singularity. The following example makes an image by
> > pulling from centos on dockerhub:  
> 
> Interesting!  However, I would prefer to use more “native” Docker
> commands, as I would rather not have all developers install and
> configure Singularity when they already have Docker installed on
> their systems.

Docker could pull from the same dockerhub url as singularity. I just
used singularity in my example because thats what I use and know. Its
main advantage is the no-root-required part..

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Running CentOS 6 in a Docker container on a non-CentOS host

[Peter Kjellström]

On Wed, 4 Mar 2020 16:56:02 -0500
Alfred von Campe  wrote:

> I have to support a legacy build that runs on CentOS 6.  I’m new to
> Docker and would like to use the official CentOS 6.10 image
> (https://github.com/CentOS/sig-cloud-instance-images/blob/da050e2fc6c28d8d72d8bf78c49537247b5ddf76/docker/Dockerfile
> <https://github.com/CentOS/sig-cloud-instance-images/blob/da050e2fc6c28d8d72d8bf78c49537247b5ddf76/docker/Dockerfile>)
> as a Docker container on another host (probably some flavor of
> Ubuntu), but can’t figure out how to tell Docker to find that image.
> I also need to make some specific customizations that I would like to
> distribute locally but not share with upstream.  Can somebody point
> me to some HOWTOs or tutorials?  Most Google searches return how to
> run Docker on CentOS, which is not what I’m after.

You can use singularity. The following example makes an image by
pulling from centos on dockerhub:

 singularity build c6.10.scif docker://centos:6.10

If you have an old binary, foo.x outside the container you can then:

 singularity exec ./c6.10.scif ./foo.x

None of this requires root.

More on singularity: https://sylabs.io/docs/

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] (SOLVED) YUM (DNF) Possible Confusion Centos 8

[Peter]

On 24/01/20 4:47 pm, david wrote:
I have a free subscription, but still can't get to the solution page.  
Oh well.


I can confirm it works with a free sub.  It may be that yours is 
expired, you have to renew it every year.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 8 (1911)

[Peter]

On 17/01/20 8:06 am, Lamar Owen wrote:

On 1/16/20 6:49 AM, Peter wrote:

On 16/01/20 4:14 am, Brian Stinson wrote:

Release for CentOS Linux 8 (1911)

We are pleased to announce the general availability of CentOS Linux 8.


CentOS 8 was released in September 2019.  Don't you mean 8.1?
No, they mean CentOS 8 (1911).  This was hashed to death back in early 
CentOS 7 days, so shouldn't need rehashing again..


No, the hashing ove back then had nothing to do with dropping the minor 
release number.  Doing that now is just making things way too confusing.


Back then the vast majority of the community showed disapproval for even 
that new naming scheme, but the wishes of the community were ignored and 
the new naming scheme went ahead anyways.  I doubt anything different 
will happen now.



Yeah, I know most people are going to call it 8.1,


That's because it *is* 8.1 and calling it 8 (1911) is just confusing and 
ridiculous.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 8 (1911)

[Peter]

On 16/01/20 4:14 am, Brian Stinson wrote:

Release for CentOS Linux 8 (1911)

We are pleased to announce the general availability of CentOS Linux 8.


CentOS 8 was released in September 2019.  Don't you mean 8.1?


Peter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] The case of the missing /boot/grub2/grub.cfg in centos8

[Peter]

On 28/12/19 2:48 am, Mauricio Tavares wrote:

With that said, if that is the case, why would the alias
/etc/grub2.cfg  still be created if it points to a non-existing file?
Wouldn't it make sense for it to just either not to be there at all or
point to the efi one? I can make arguments for both sides, but not for
a homeless alias.



[root@linux etc]# rpm -qf /etc/grub2.cfg
grub2-pc-2.02-0.80.el7.centos.x86_64
[root@linux etc]# rpm -qf /etc/grub2-efi.cfg
grub2-efi-x64-2.02-0.80.el7.centos.x86_64

...in other words, the grub2.cfg link is installed with the grub2-pc 
package and the grub2-efi.cfg link is created with the grub2-efi 
package.  You can probably get away without the grub2-efi package on a 
legacy bios system, but not the other way around, so an efi system will 
have both links.


At the end of the day it's harmless, don't loose any sleep over it.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] The case of the missing /boot/grub2/grub.cfg in centos8

[Peter]

On 27/12/19 7:36 pm, Nicolas Kovacs wrote:

Le 27/12/2019 à 04:11, Mauricio Tavares a écrit :

Why is it not there?  FYI, I did try 'yum reinstall grub2' and no
/boot/grub2/grub.cfg for me.


You're probably on an EFI system, and your grub.cfg is in a different 
location. Can't remember it off the top of my head, but do


/etc/grub2-efi.cfg -> ../boot/efi/EFI/centos/grub.cfg


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] cli Checking disk i/o

[Peter]

On 11/11/19 1:37 PM, Robert Moskowitz wrote:

OK.  That is interesting.  I am assuming tps is transfers per sec?

I would have to get a stop watch, but it seems to go a bit of time, and 
then a write.


Is there something that would accumulate this and give me a summary over 
some period of time?  Of course it better NOT be doing its own IOs...


I like iostat -x 4 which will give a summary every four seconds of 
accumulated stats, but check the man page for all the options you can 
use.  iotop (yum install iotop) may also be helpful as it shows disk 
usage per process like top does for CPU and memory.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] ls permissions format changed in CentOS 8

[Peter Kjellström]

On Sun, 27 Oct 2019 08:25:28 -0700
Kenneth Porter  wrote:

> It's a missing ncurses feature in the older PuTTY that's trigged by
> an update to ncurses or terminfo in CentOS 8. PuTTY 0.72 added
> support for the REP (repeating character) command and the newer
> terminfo adds that as an xterm feature. The Epsilon author spotted it
> in the PuTTY changelog.
> 
> So any curses app that uses repeating characters will have this
> problem when used with an old PuTTY version.

Nice trouble shooting. It's always satisfying to get to the root of
things.

Cheers,
 Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] deprecations leading up to C8

[Peter]

On 21/09/19 10:15 PM, Peter wrote:

On 21/09/19 1:25 PM, Fred Smith wrote:

On Fri, Sep 20, 2019 at 12:45:03PM -0500, SternData wrote:

Does that mean it's gone from the CentOS repos or just that PostFix is
the default choice?


I believe it means that it won't be in Centos anymore.


Correct, but do note that epel has picked up where Red Hat has dropped 
the ball.  Sendmail is available for el8 from epel.


Sorry, I am mistaken.  I looked at the epel package list and saw 
"sendemail" and mistook it for "sendmail".


I imagine that someone will end up building sendmail for el8, though.


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] deprecations leading up to C8

[Peter]

On 21/09/19 1:25 PM, Fred Smith wrote:

On Fri, Sep 20, 2019 at 12:45:03PM -0500, SternData wrote:

Does that mean it's gone from the CentOS repos or just that PostFix is
the default choice?


I believe it means that it won't be in Centos anymore.


Correct, but do note that epel has picked up where Red Hat has dropped 
the ball.  Sendmail is available for el8 from epel.


That said, there is nothing wrong with switching to postfix if that's 
what you want, postfix is an excellent MTA.  It's just that if you want 
to continue with sendmail then epel provides a solution for you.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Replacing sendmail with postfix

[Peter]

On 21/09/19 9:07 AM, Chris Adams wrote:

Once upon a time, Kenneth Porter  said:

Perfect. I think the only other significant customizations I have
are lines to use the MIMEDefang and OpenDKIM milters. When last I
looked into migrating, I recall that Postfix handled milters just
fine.


Milters work a little different under postfix IIRC... I haven't tried
them (which is a little sad, since I think I may have been the first
person to write a sendmail milter :) ).


Postfix has excellent milter support, it may not work exactly the same 
as they do in sendmail but they are designed to be fully compatible with 
sendmail milters.  Also I believe that nowadays milters are written just 
as much to be support postfix as sendmail, if not moreso:


http://www.postfix.org/MILTER_README.html


Meanwhile, I'd considered replacing procmail with the Dovecot
delivery program to get access to Sieve filtering but didn't see how
to easily invoke SpamAssassin as I do now in /etc/procmailrc. Is
Procmail still the default delivery agent in RHEL8?


I would recommend dovecot lmtp over dovecot lda.


Postfix can use dovecot lmtp or procmail (I don't remember which is default).


Postfix can use just about any delivery agent.  The default in postfix 
is to use its own local(8) and virtual(8) delivery agents.  That said, 
these delivery agents are very limited in comparison to dovecot lmtp or 
procmail.



IIRC sieve may not provide external scripting for security reasons.


I'm pretty sure it does via managesieve.


I use spamassassin via amavisd-new, with messages going postfix ->
amavisd -> second postfix (all via SMTP).


This is a good setup, but you may find that you can eliminate the second 
postfix step there and go postfix -> amavisd-new -> dovecot lmtp. 
Unless you need additional processing specifically from postfix after 
amavisd-new, that is.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix vs. Thunderbird on Mac OS

[Peter]

On 19/09/19 8:43 PM, Nicolas Kovacs wrote:


smtpd_helo_restrictions = reject_unknown_helo_hostname

...

One single user has a MacBook Air with Thunderbird on Mac OS
Mojave, and her outgoing mails are rejected with the following error
message in /var/log/maillog on the server:

Sep 16 14:22:32 sd-48011 postfix/smtps/smtpd[14434]: NOQUEUE: reject:
RCPT from villa.figaret.pck.nerim.net[62.212.106.47]: 450 4.7.1
: Helo command rejected: Host not found;
from= to= proto=ESMTP
helo=


reject_unknown_helo_hostname is not intended to be used for submission 
connections.  The thing is that email clients will connect with all 
sorts of crazy hostnames, and they generally have no way of knowing if 
they hostname they are claiming has any conformity with the actual 
hostname presented publicly from the computer, or indeed if there even 
is one at all.  If someone is authenticating with SASL auth then they 
really shouldn't need to be subjected to these additional tests anyways.


You should separate your MX connections )port 25) from your submission 
connections (port 587 or submissions on port 465).  It becomes much 
easier to resolve issues like this if you don't have to worry about MXes 
and MUAs connecting on the same ports to the same services.  Then you 
can write separate smtpd_*_restrictions in master.cf for submission and 
submissions that don't include things such as reject_unknown_helo_hostname.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix vs. Thunderbird on Mac OS

[Peter Eckel]

Hi,

the main problem is that the MacBook obviously presents an illegal host name to 
the mail server, which in turn rejects accepting mail to be submitted from it 
because of 'reject_unknown_helo_hostname'.

With your 'smtpd_helo_restrictions', Postfix handles submissions from clients 
as it would handle mail from external mail servers, and so the wrong host name 
gets mail to be rejected. The mail submission doesn't even get to the point 
where 'smtpd_recipient_restrictions' are checked (which would allow senders 
from 'mynetworks') because 'smtpd_helo_restrictions' hits first. One way to fix 
that would be to put 'permit_mynetworks' into 'smtpd_helo_restrictions' (and of 
course provide proper settings for 'mynetworks') so the invalid host name is 
ignored for local networks.

If you want to fix the client instead (which I would recommend in any case), 
'scholae.lan' could be a domain the mail server cannot resolve (as seen from 
your log, your domain is 'scholae.fr'), and so the host name is rejected. Even 
if the domain were resolvable, there is in all likelihood no DNS entry for 
'Air-de-bea', so the name is technically invalid as far as Postfix is concerned.

The main question is where it got that host name from - most mis-configuration 
on the device itself, or on the DHCP server it uses to get its network 
configuration from.

If it's not the DHCP server, have a look at the 'Sharing' system configuration 
on the Mac. On top of that panel there is a field to configure the simple host 
name (in this case it'S probably "Air-de-bea"), and below that there's an 
'Edit' button that you can use to specify an alternate name and sn FQDN. If 
'Use dynamic global hostname' is checked, the Mac will use the hostname 
configured there - this might well be set to 'Air-de-bea.scholae.lan'.

If it's DHCP where the host name gets its name from, you'll need to have that 
fixed - either provide dynamic DNS updates, or assign a properly registered 
host name to the Mac.

Cheers,

  Pete.

> On 19. Sep 2019, at 10:43, Nicolas Kovacs  wrote:
> 
> Hi,
> 
> I'm running our local school's mail server on CentOS 7, Postfix and
> Dovecot. We get quite a lot of spam, so I have the following sender
> restrictions in my /etc/postfix/main.cf:
> 
> --8<--
> # Restrictions SMTP
> smtpd_helo_restrictions = reject_unknown_helo_hostname
> smtpd_sender_restrictions = reject_unknown_sender_domain,
>  check_sender_access hash:/etc/postfix/sender_access
> smtpd_recipient_restrictions = permit_mynetworks,
>  permit_sasl_authenticated,
>  reject_rbl_client zen.spamhaus.org,
>  reject_rhsbl_reverse_client dbl.spamhaus.org,
>  reject_rhsbl_helo dbl.spamhaus.org,
>  reject_rhsbl_sender dbl.spamhaus.org
> smtpd_relay_restrictions = permit_mynetworks,
>  permit_sasl_authenticated,
>  reject_unauth_destination
> smtpd_data_restrictions = reject_unauth_pipelining
> --8<--
> 
> Most folks are using Thunderbird on Linux, and everything works
> perfectly. One single user has a MacBook Air with Thunderbird on Mac OS
> Mojave, and her outgoing mails are rejected with the following error
> message in /var/log/maillog on the server:
> 
> --8<--
> Sep 16 14:22:32 sd-48011 postfix/smtps/smtpd[14434]: NOQUEUE: reject:
> RCPT from villa.figaret.pck.nerim.net[62.212.106.47]: 450 4.7.1
> : Helo command rejected: Host not found;
> from= to= proto=ESMTP
> helo=
> --8<--
> 
> As far as I understand, it has to do with this MacBook's host
> configuration.
> 
> Any suggestions?
> 
> Cheers from the sunny South of France,
> 
> Niki Kovacs
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Updates

[Peter]

On 19/09/19 7:01 AM, Phil Perry wrote:

On 18/09/2019 13:12, Jerry Geis wrote:

Transaction check error:
   file /usr/lib64/libSPIRV-Tools-opt.so from install of
vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package
spirv-tools-libs-2019.1-1.el7.x86_64
   file /usr/lib64/libSPIRV-Tools.so from install of
vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package
spirv-tools-libs-2019.1-1.el7.x86_64


spirv-tools-libs-2019.1-1.el7.x86_64 looks to be from EPEL? If so, file 
a bug with EPEL and ask them to fix it?


There already is a bug filed for this:
https://bugzilla.redhat.com/show_bug.cgi?id=1745104


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] I broke "yum update" - C7

[Peter]

On 30/08/19 9:02 PM, Gary Stainburn wrote:

[root@stan2 ~]# yum update

  2. Reconfigure the baseurl/etc. for the repository, to point to a working
 upstream. This is most often useful if you are using a newer
 distribution release than is supported by the repository (and the
 packages for the previous distribution release still work).

Cannot retrieve metalink for repository: epel/x86_64. Please verify its path 
and try again


At this point I would follow the above advice, basically comment out the 
metalink= lines in your epel.repo file and uncomment the baseurl lines, 
then try the update again.


Later on you should try changing them back, but it appears as if for now 
at least you're having issues downloading the metalink file.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] I broke "yum update" - C7

[Peter]

On 29/08/19 9:58 PM, Gary Stainburn wrote:

  One of the configured repositories failed (Unknown),
  and yum doesn't have enough cached data to continue. At this point the only
  safe thing yum can do is fail. There are a few ways to work "fix" this:

Cannot retrieve metalink for repository: epel/x86_64. Please verify its path 
and try again


I would try this:

yum clean all
yum --disablerepo=epel update
yum --disablerepo=epel --enablerepo=extras reinstall epel-release
yum update

If that doesn't work show the complete output from the above commands 
and we'll go from there.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 5 file system read only issue

[Peter]

On 22/08/19 2:20 AM, Warren Young wrote:

On Aug 21, 2019, at 7:35 AM, Xinhuan Zheng  wrote:


my $s = IO::Select->new( $fh );
if ( $io->can_write( 10 ) {


That’s not designed to do what you hope.  select(2) is a system call intended 
for use on network socket handles, not file handles.  Since socket handles and 
file handles are compatible on a Unix type system (including CentOS) the call 
doesn’t fail, but it *cannot* report the information you’re hoping to get.

I would first try calling the -w operator:

print_to_file() if -w $fh;


First off I would be remiss if I didn't point out that CentOS 5 has been 
EOL for years, that said...


You're dealing with perl here and so this might be better off asking in 
a perl list.  The -X system of tests as documented with "perldoc -f -X" 
do not by default test actual ability to read and write files, but 
instead just check the file mode bits as returned by stat(), thus the -w 
test will not reflect the filesystem being in read-only mode.


There are two ways to get around this.  One is to to use the filetest 
pragma which changes the behavior of the -X tests to use the access(2) 
system function:

{ use filetest 'access';
  print_to_file() if -w $fh;
}

The other way is to use POSIX::access() directly (this requires the file 
name or path):


use POSIX qw(access W_OK);

...

print_to_file() if access($filepath, W_OK);


Note that there are caveats to either of the above approaches as per 
documentation.  See the following for additional info:


perldoc -f -X
perldoc filetest
access(2)


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] failing to install LibreOffice 6.3.0.4

[Peter]

On 11/08/19 2:37 PM, Fred Smith wrote:

As in subject, am attempting to install latest LibreOffice on C7.


CentOS 7 comes with Libreoffice 5.3.6.1.  There is no support for 
installing newer versions from other sources.



unpack all the rpm files,


RPM files from where?  We don't supply Libreoffice RPMs for any version 
other than what is stated above.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on server speed

[Peter Larsen]

On 8/5/19 3:00 PM, Jerry Geis wrote:
> The keyboard is USB attached and the external SSD disk is USB attached.

WHY? Why would you do that? What's the point of SSD if you reduce the
speed to USB? Or just use an old mechanical drive instead.  Any issue
with that drive will show up as IO Wait - my presumption is that you
expect to see that so you're not mentioning it but it's going to be
extremely high.

Remember, USB does not behave like SATA. And you may also find that the
"max speed" in the specification is far from what you get out of your
hardware. Use eSATA if you need it externally - not USB(3 or otherwise).

-- 
Regards
  Peter Larsen
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] browsers slowing Centos 7 installation to a crawl

[Peter]

On 6/08/19 6:33 AM, Richard wrote:

Javascript - if you're using firefox, install NoScript last week.


NoScript selectively blocks javascript, it doesn't turn it off --
which for testing purposes, at least, is the goal.

In ff -- about:config - then enter "javascript" in the search line
and set "javascript.enabled" to false.

With chrome this can be done in the advanced settings section, under
"site settings".


This will cause almost complete breakage of an increasing number of 
modern websites.  The vast majority of sites nowadays absolutely rely on 
JS and will not run or display correctly without it.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] browsers slowing Centos 7 installation to a crawl

[Peter]

On 6/08/19 3:44 AM, Michael Hennebry wrote:

In any case, Centos 7 has not always been this slow.
Presumably something has changed.


Websites have gotten more resource-intensive.  You've run "yum updates" 
and now have a newer version of Firefox and/or Chrome.  Your browsing 
habits have changed and you browse with more tabs open now.


Firefox for me has always had some amount of RAM leakage and when I used 
to run with 4G of RAM I had to restart it frequently (but I browse with 
a lot of tabs open).  I currently have my system maxed at 8G and still 
have to restart FF every couple of days or so to stop the system from 
swapping.  2G wouldn't even give me enough RAM to not run a browser on 
my system, so I can only imagine that your usage to date has been 
extremely simple.


I have two suggestions for you:

1.  Run a lightweight desktop such as XFCE instead of Gnome or KDE.

2.  Run out and buy more RAM.  Max your system out at 4G or 8G or 
whatever it will take.  You will need it and appreciate it.



Good Luck,


Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] browsers slowing Centos 7 installation to a crawl

[Peter]

On 5/08/19 10:42 AM, Michael Hennebry wrote:
Mem:    2020144 1454904   76140  204764  489100  
135004

Swap:   4883724  978480 3905244


free -h is generally more readable, but...

It's RAM.  You basically have a total of 2G ram on the system, you have 
less than 500M available and are into swap by nearly 1G, so you're 
swapping heavily.  2G is enough for a minimal install but browsers such 
as firefox and chrome can easily use a lot of memory fast and trying to 
run one on a 2G system while doing an install at the same time will get 
you swapping and slow the system to a crawl.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Roughly how many more months before CentOS 8.0 release?

[Wood Peter]

Where can we learn more about the workflow and software used to build
CentOS RPMs and iso images?
This will be extremely helpful to everyone facing the same challenges of
building a custom distro.

Thank you all for the hard work on CentOS.

On Fri, Jul 12, 2019 at 7:44 AM Johnny Hughes  wrote:

> On 7/10/19 1:18 AM, Turritopsis Dohrnii Teo En Ming wrote:
> > Good afternoon from Singapore,
> >
> > May I know roughly how many more months before CentOS 8.0 will be
> released?
> >
> > https://wiki.centos.org/About/Building_8
>
> Well .. as explained before, it is a very irritative process .. (ie ..
> do this, test, do that, test .. rinse, repeat).
>
> But with where we are right now .. I don't think it will take more than
> one more month to finish and test.
>
> Obviously, we have people working on it every day and a QA team helping
> us test what we are doing every day and we are still maintaining
> CentOS-6 and CentOS-7 as well.
>
> But we are making progress and we are getting closer.
>
> There are many things that we need to work on .. including, but not
> limited to a whole new build system (Koji AND MBS together), a
> completely new way to maintain installer images and repos (via Koji
> because of the modules).
>
> A whole new repository paradigm (BaseOS, AppStream, Devel {things not
> released but needed to build BaseOS and AppStream} .. etc, etc.
>
> Anyway .. we are working on it very hard and we will have it released as
> soon as we can.
>
> We don't have date yet.
>
> ___
> 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] 32-bit CentOS

[Peter]

On 10/07/19 8:01 AM, MAILIST wrote:

I tried to resurrect a 32-bit desktop with a Pentium 4 processor by
installing CentOS 7 32-bit version.  Everything installed OK, but after
the first boot, the performance was unusable.  And, the X11 would
crash repeatedly.  CentOS 7-32 is completely useless.


You need a light weight desktop like XFCE which is available for CentOS 
from epel.  Epel 7 doesn't natively come in i386 but CentOS has provided 
a rebuild at https://buildlogs.centos.org/c7-epel.i386/



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] where to get kernel source

[Peter Kjellström]

On Thu, 13 Jun 2019 18:52:22 +0800 (CST)
qw   wrote:
> http://vault.centos.org/7.2.1511/updates/Source/SPackages/
> 
> But I can't find kernel-3.10.0-327.36.4.el7.src.rpm.

Since it's not in updates (non source) either I'd guess that it was
never built/released by CentOS.

Infact, I can't even find a matching RHSA for that kernel and
Z-stream/EUS seems to have gone 327.41.1 ...

Where did you get the idea that it exists in the first place?

If you have it running on a host, what does rpm -qi show for build date
and host? Could it be a badly named local rebuild?

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What happened if install a el7 package on a el6 system

[Peter]

On 8/05/19 12:22 AM, Robert Heller wrote:

Many CentOS-7 packages will not install because they will need dependencies
that the EL-6 does not have.


Correct, and different versions of dependencies, and files go in 
different locations, etc.



The kernel is different because it is mostly
self-contained and meant to be parallel installed.


Correct.


In most cases, it should

result in an unbootable system because the boot is going to be
dracut+systemd bits and the EL-6 has none of that.


Older versions of dracut will run on newer kernels just fine.  When you 
install the kernel on CentOS 6 it will run the CentOS 6 version of 
dracut at the time of the install and create a CentOS 6 compatible 
initramfs image.


Systemd is user-space and does not include components in the kernel (as 
far as I'm aware).  Even if it does, the kernel is still 
backwards-compatible and would boot just fine to upstart (which is the 
init system in CentOS 6), it simply would not use those modules and 
features that are used for systemd.



And I wonder if the EL7 kernel will even show up as an available kernel.  EL7
uses Grub 2 and EL6 uses Grub [1].


CentOS 7 does have grub legacy (1) as an option and does work fine with 
grub legacy.  I have set up CentOS 7 systems that use grub legacy in the 
past.  It stands to reason that a kernel that installs and configures 
just fine in grub legacy on CentOS 7 will do the same in grub on CentOS 6.



I know that when I installed Ubuntu 18.04 as a *second* OS, that even though
the /boot file system is shared between CentOS 6 and Ubuntu 18.04 the Ubuntu
18.04 installer did not touch /boot/grub/grub.conf and installed
/boot/grub/grub.cfg along side (I manually reinstalled grub 1 and manually
hacked /boot/grub/grub.conf to put the Ubuntu 18.04 boot option in).


This is not the case with CentOS.  You can run dual-boot CentOS 6 and 7 
on the same grub legacy boot loader and CentOS 7 will boot up and run 
just fine.


While I cannot make any guarantees that a CentOS 7 kernel will not cause 
issues running in CentOS 6, and indeed I would not support a system that 
used such, the Linux kernel, being self-contained and largely 
backwards-compatible should in theory, at least, not have issues running 
a CentOS 7 kernel on CentOS 6, and indeed there are newer kernels that 
are specifically built for CentOS 6 (elrepo kernel-ml) that run just 
fine as well.


The main thing that might stand in your way would be any changes to the 
rpm file format (which does happen from time to time) that prevent an 
rpm built for CentOS 7 from being recognized and installible by rpm or 
yum in older versions of CentOS 6.  I am aware of such changes from 
older versions of CentOS but none between CentOS 6 and 7.


So in summary, it would probably work just fine, but I wouldn't do it, 
recommend it or support it.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accessing Android phones on CentOS 7

[Peter]

On 27/04/19 3:48 AM, Nicolas Kovacs wrote:

Hi,

My standard Linux desktop is based on a personal blend of CentOS 7 with
KDE 4.14 and various add-ons from third-party repositories like EPEL and
Nux-Dextop. After a brief stint on OpenSUSE Leap 15.0, this is what I
use on my workstation and on my laptop. And this is also what I install
on my client's machines, just like I did in our local school's computer
room.


Thunar (in epel, package name with a capital "T") automatically detects 
and accesses MTP devices.  It's designed for the XFCE desktop but I 
don't see a reason why it shouldn't work in KDE as well, it will just 
pull a few of the XFCE libraries when you install it.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Intel Vroc experiences?

[Peter Kjellström]

On Tue, 23 Apr 2019 10:00:45 +0100 (BST)
Nux!  wrote:

> Hi,
> 
> Has anyone had any experience with Intel Vroc[1]? I'm possibly having
> to deal with a new server with such technology and can't find much
> (real world) information about it. Looking at the specs it's
> basically a glorified fake raid which usually turns on my alarm
> bells. Has anyone done any testing, how does it compare with "real"
> raid or software raid?

Intel FAQ had the following nugget of info but I've yet to try it
myself..

  What is the difference between Intel® VROC and Linux* MD RAID?
 Intel® VROC for Linux* is built upon MD RAID, and the Intel VROC team
 has an MD RAID maintainer on the team. However, Intel VROC has the
 following extra features:

 * Provides UEFI HII and UEFI Shell command line RAID management
 * Provides webpage-based, remote RAID management and RESTful APIs
 * Fully validated and supported with Purley platform and
   industry-select
 * SSDs Provides hotfix/patch to specific customer issue on supported OS

Seems a mess of licensing and enabling too :-(

Also seen this from HPE:
http://www8.hp.com/h20195/v2/GetPDF.aspx/c05821090.pdf

And this from Intel:
https://software.intel.com/en-us/articles/intel-xeon-processor-scalable-family-technical-overview

/Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] time to say good-bye to win 7 / printer is the last blocker

[Peter]

On 22/02/19 19:12, Ralf Prengel wrote:

Hallo,
the laptop of my wife is the last Win7 system in my network.
My question:
I need a well supported printer (MFC) with network interface, if possible with 
colour printing.


Brother printers.  You will likely need to install the drivers from the 
brother website, but my experience with them have been exemplary.  My 
current printer is an MFC-J4620DW and I wouldn't trade it for the world.



Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Gordon, 

> There's probably going to be a lot of misinformation where bareos is 
> concerned.  The developers forked that product claiming that when they signed 
> license assignments they didn't know that this could or would allow Bacula to 
> begin a dual-license release in which some features were added to a separate 
> proprietary release. Bacula's developers claim that the fork included code 
> that was not licensed to them.  Their lawsuit was settled with undisclosed 
> terms.  Given what information is available publicly, I am inclined to 
> believe that the fork was in the wrong, but users are often more concerned 
> with protecting people that they like than they are in license compliance.


thanks for this interesting background information!

On the other hand, I'm not trying to defend one company against the other - 
their lawsuit has been settled as you wrote, and so that's stuff that is in the 
past and doesn't have much relevance from a technical viewpoint. 

When I switched from Bacula to Bareos it was a purely technical decision, 
driven by the ease of maintaining an installation of Bareos vs. Bacula. In the 
meantime, the forks have diverged a bit, and there are some very interesting 
features (such as a flavour of opportunistic TLS encryption based on PSK) that 
make me stay with Bareos.

Leon's suggestion of creating a Backup SIG that could - among other things - 
maintain an RPM release of recent Bacula versions would IMHO really help Bacula 
a lot. At least it would eliminate my first reason for switching, and probably 
it would never have happened had current releases been available more easily.

Cheers, 

  Peter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Leon,

> IMHO - as Kern (Bacula lead developer) is pushing Bacula forward I dont 
> understand this too. It must be
> a misinformation about the current status of the project itself and 
> competitors interests (Bareos).

the fork of Bacula happened in 2013, IIRC. Things may have changed since then, 
but I did not bother to switch back. It's a good thing, however, that there was 
a change.

The fact that I can't find any recent RPMs anymore is definitely nothing that 
makes switching back an attractive option :-)

> IIRC Bacula is also open source software. Remember RHEL binaries are not free
> available ... if you are referring to precompiled MS Windows binaries of 
> Bacula).

In fact Bacula is open core, i.e. there is an enterprise version that has 
additional functionality not contained in the community edition. It's only 
fair, however, to note that there is also a downside to Bareos' concept - 
binary distributions are released less frequently to the community while 
enterprise service subscribers receive more frequent binary updates.

> BTW Bacula is included in CentOS/RHEL albeit in an older version. This 
> applies also
> for example to PHP and has the cause in the enterprise strategy of the 
> distribution.
> So don't blame the wrong one.

I'm not blaming anyone at all - as a user of CentOS/RHEL I know about the 
drawbacks of a stable enterprise vs. bleeding edge release strategy.

> Maybe a good reason to start a Backup SIG which provides a repository with 
> current bacula packages?

Hm ... there used to be a repository maintained by some company associated with 
Bacula, but I can't find it anymore - so it seems that starting a SIG taking 
care of that would be a good idea.

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro, 

> Why many users skip bacula? It is powerfull and very stable. It is very 
> difficult to setup but if you know how it works it is simple.

I used Bacula before I switched to Bareos. 

There was a point, however, when the open source release of Bacula became, to 
put it mildly, a bit too inactive for my taste. Obviously I wasn't alone with 
this, because roughly at that time Bareos was forked from Bacula. 

<http://www.admin-magazine.com/Archive/2013/17/New-features-in-the-Bareos-Bacula-fork>

Essentially, Bareos is an improved (at least IMHO) fork of Bacula, and unlike 
Bacuka it's fully open source.

Cheers, 

  Peter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Valeri,

> you mean, director and STORAGE daemon, right? File daemon _IS_ a client...

yep. I noticed when klicking on 'send', as usual :-)

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

I must correct myself:

> I always do it the other way around, i.e. upgrade the director/file daemon 
> and then the clients as time suits. No problems with that so far.

I meant storage daemon, not file daemon!

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro,

> What if I will use bareos I will never get problem between version like 
> happening today with bacula?

difficult to say - I never ran into any upgrade issues with Bareos, but neither 
with Bacula while I was still using it.

> I could use newer bareos client on older bareos director?

I always do it the other way around, i.e. upgrade the director/file daemon and 
then the clients as time suits. No problems with that so far.

Do you happen to be at FOSDEM? The Bareos team is going to be there, as usual: 
<http://www.bareos.org/en/news/bareos-fosdem-19.html>

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

> Amanda (from base CentOS) -> USB removable disk -> firesafe.
> 
> Backups on or by the computer might protect you from disk failures, but
> are useless in case of fire or theft.

Good point. The backup strategy is at least as important as the tool used.

Using Bacula, I'm doing daily backups of critical data (which is not 
everything, but i.e. my business data) to an encrypted disk on an offsite 
server 400km from here over the internet.

I'm also still doing backups to external physical media, but on a much looser 
schedule since it's always some effort to bring them to my offsite safe. The 
best backup of your work is pretty useless when it's two months old.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro,

> what type of backup solution do you use on C7?

the same as on most other operating systems: Bareos.

<http://www.bareos.org/en/>

Bareos has some learning curve, but it's free, it's extremely reliable and 
flexible. I've been using it for years, after switching from its parent Bacula, 
which I've been using for years before that, and it has not failed me once when 
I needed it.

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos