Re: [CentOS] MTU report question

[Patrick Bégou]

Hi Strahil

I get:

ping: local error: Message too long, mtu=2044
ping: local error: Message too long, mtu=2044

so ip report is correct and nmcli did not the job ?

Patrick

Le 14/12/2020 à 20:23, Strahil Nikolov via CentOS a écrit :
> what happens when you 'ping -M do -s 65000 -c 4  ?
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В понеделник, 14 декември 2020 г., 15:46:50 Гринуич+2, Patrick Bégou 
>  написа: 
>
>
>
>
>
> 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
>
> Why ? Who is wrong (possibly me)?
>
> Thanks
>
> Patrick
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos


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

Re: [CentOS] The conclusio: CentOS is dead

[R C]

It is not that we haven't been here before, this is just history 
repeating itself.


IBM, SCO, Sun, Novell, etc. majorly have screwed up because of some 
geniuses having a great business idea.


(that's how BSD disappeared, Solaris was a disaster, Xenix never made 
it..  and whatever happened to SCO etc?)


But here is the point, RHEL for example is used at scale a lot now, 
because there are people that know how to deal with it (far and few 
beyond)    and the ones I know use Centos for their own stuff (at 
home) because it is so similar. It is already a problem to find 
qualified people that can use/deal with RHEL in a production environment 
at scale (if you know what you're doing, you easily can get a cosy 6 
figure job, because it's next to impossible to find a decent sys person 
with experience, for sure not for at scale operations) , and those are 
not going to pay hundreds/thousands for a RHEL license at home, that is 
why they use Centos, while at work working with RHEL.


I am in that situation, I request 5-6 figures worth of RHEL licenses on 
a regular basis, and use several Centos machines at homes (yeah I am 
that guy that doesn't have a life and my 'hobby' is kinda like my work.) 
It will be a very freaking cold day in hell before I start paying 
thousands to have virtually 'the same thing' at home as at work.


If a few months down the road, if I decide to use Linus XYZ, or 
whatever, than that is what we'll be using where I get my pay check from 
...  and if not, well, good luck finding someone that can keep things 
running there. Because that is what it comes down to.  It is not the 
product that determines what the "industry standard" is..   it is the 
ones that have experience and can actually make stuff work.



I think Centos is dead because RHEL just committed suicide.


Ron



On 12/15/20 12:06 AM, Simon Avery wrote:

On Mon, 14 Dec 2020 at 22:48, Ruslanas Gžibovskis  wrote:


your suggestions?



Different:
Debian, OpenSuse, Ubuntu-server. All good choices.

Not quite so different:
Rocky, (Maybe one of the corporate sponsored centos-a-likes, (OEL,
Cloudlinux etc) but we've now learned it would be nicer to rely on a distro
that wasn't provided at the whim of someone who might need to cut costs at
any time)
___
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] The conclusio: CentOS is dead

[Nikolaos Milas]

On 15/12/2020 12:47 π.μ., Ruslanas Gžibovskis wrote:


your suggestions?


My course of action is to wait for Lenix (Ref.: 
https://blog.cloudlinux.com/announcing-open-sourced-community-driven-rhel-fork-by-cloudlinux) 
and Rocky Linux (https://rockylinux.org/) by CentOS original founder.


IMHO, both will end to what we really want/need, because they care.

As I have already mentioned, I would encourage projects to join forces 
to produce a single platform.


I won't go to Ubuntu, Debian, FreeBSD. You may call it a personal 
preference. I feel much more comfortable with EL.


I would try to avoid OL (as it is governed by a large corp which can 
drop it easily).


Cheers,
Nick

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

Re: [CentOS] The conclusio: CentOS is dead

[Simon Avery]

On Mon, 14 Dec 2020 at 22:48, Ruslanas Gžibovskis  wrote:

> your suggestions?
>
>
Different:
Debian, OpenSuse, Ubuntu-server. All good choices.

Not quite so different:
Rocky, (Maybe one of the corporate sponsored centos-a-likes, (OEL,
Cloudlinux etc) but we've now learned it would be nicer to rely on a distro
that wasn't provided at the whim of someone who might need to cut costs at
any time)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-es] cloudlinux hará un clon de CentOS

[Ing . Ernesto Pérez Estévez , Mg . via CentOS-es]

Les conozco, les uso. Que les vaya bien!

https://blog.cloudlinux.com/announcing-open-sourced-community-driven-rhel-fork-by-cloudlinux


-- 
CEDIA
La principal herramienta de Investigación en el Ecuador.

Gonzalo Cordero 2-122 y J. Fajardo
Cuenca -  Ecuador
Telf: +593 7 407 9300 Ext. 115
i...@cedia.org.ec
www.cedia.edu.ec
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] The conclusio: CentOS is dead

[Satish Patel]

I am centos guy last 20 years but not anymore. I have started looking into 
Ubuntu. 

Sent from my iPhone

> On Dec 14, 2020, at 5:48 PM, Ruslanas Gžibovskis  wrote:
> 
> if it is currently changed over the night...
> How can you be sure that the CentOS8 stream will not be dropped tomorrow?
> How about CentOS9, CentOS10, CentOS Core?!
> How can you be sure that what was "promised" will not be canceled in one
> second?
> I think most of the derivatives will be dead with one or two releases, like
> was with Debian, such as Devuan, never got a new version...
> 
> In general, I would blame "DevOps" mindset! That might have played the bad
> thing here and forced all to this decision.
> 
> Maybe RH wanted something like Debian GNU/Linux Testing/stable concept (in
> some cases TESTING more stable than prod, as it had the possibility to have
> a newer major version with rewritten codebase)?
> 
> In either way, RH showed, that after IBM have got them, IBM KPI's forced RH
> to do some moves which we never ever were expecting to happen before IBM RH.
> Maybe even a first thing that could be a sign, changing Logo into a
> "simple" one...
> 
> What is left now to treat as trust worthful OS? My decision would be to bet
> on:
> * Debian (biggest arch and package selection, which is quite up to date,
> and can easily upgrade from 2 to 10, yeah, of course, you will need to do
> some mambo jumbo), You can find some things like parrotOS, previous
> backtrack and much more in there, so just ADD repo, and download package
> what you miss in debian repos. And a shame thing, bubuntu is based on deb,
> so, same here, just add missing repos from bubuntu for particular package
> (but I have never ever seen such case, when bubuntu had smth needful, what
> debian didn't.
> * OpenBSD (very very very clear way forward, very openminded OS, but at
> the same time SEC on a first place!), already has vmd, written with a clean
> codebase, looks very promissing replacement for kvm in general usages.
> * FreeBSD, AnyOtherBSD BSD, you know... LOTS of appliances work on it! Has
> ZFS support... behyve...
> * Arch or Gentoo? Why not LFS then? But both have quite good support and
> showed themselfs.
> 
> your suggestions?
> 
> 
> 
>> On Fri, 11 Dec 2020 at 23:25, Matthew Miller  wrote:
>> 
>>> On Fri, Dec 11, 2020 at 07:50:00PM +0100, Walter H. wrote:
>>> it is called "rolling release" and no one gave officially a
>>> statement to the question I asked,
>> 
>> It should not have been called a rolling release. It is not a rolling
>> release in the sense that many Linux distributions use it.
>> 
>>> if it is meant like that of Win10 ...
>> 
>> I don't know what that means. No. It will not be like Win 10 in pretty much
>> every way.
>> 
>> 
>>> a beta release is not the same that many expect as a stable system,
>>> as they are used to have with CentOS;
>> 
>> It is not a beta release.
>> 
>> 
>>> you should think of renaming CentOS to something different, because
>>> with Enterprise this CentOS Stream has nothing in common;
>> 
>> Maybe. But I think it has more in common than you think
>> 
>>> and does Redhat really expect everone - even private people - afford
>>> a RHEL subscription¹ just to have a stable system?
>> 
>> No. In many cases, CentOS Stream will provide a stable system for the needs
>> of individuals. In many other cases, upcoming low- and no-cost RHEL
>> programs
>> will address many of these needs. As an individual, you can already get
>> RHEL
>> with no cost through the Developer Program, although it isn't as easy as it
>> could be and usage is limited. The upcoming plans are intended to address
>> those problems. It's unfortunate that the timing is such that those aren't
>> anything but future promises at this point, but they are coming. See
>> https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 and email
>> centos-questi...@redhat.com with your specific needs. That address goes to
>> real people who are working on these programs, not sales or anything like
>> that.
>> 
>> 
>> 
>> --
>> Matthew Miller
>> 
>> Fedora Project Leader
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>> 
> 
> 
> -- 
> Ruslanas Gžibovskis
> +370 6030 7030
> ___
> 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] Is Oracle a real alternative to Centos?

[Nicolas Kovacs]

Le 14/12/2020 à 23:18, Ruslanas Gžibovskis a écrit :
> Just in case, as the third author linked, read the Licence Agreement,
> everything will be there.

Since Red Hat source code is mostly GPL, the same thing applies to Oracle Linux.

> 
> And a small remark:
> Even if you can take a knife in a shopping mall and stab with it anyone
> within the same shopping mall, does not say that it is legal. But you can,
> Please do not try it in anywhere! well if you have no brain and interested
> in trying it...

We will keep your advice in mind.

:o)

-- 
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

Re: [CentOS] The conclusio: CentOS is dead

[Jon Pruente]

On Mon, Dec 14, 2020 at 4:48 PM Ruslanas Gžibovskis 
wrote:

> I think most of the derivatives will be dead with one or two releases, like
> was with Debian, such as Devuan, never got a new version...
>

Devuan 3.0 was released in June.
https://www.devuan.org/os/announce/beowulf-stable-announce-060120
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] The conclusio: CentOS is dead

[Ruslanas Gžibovskis]

if it is currently changed over the night...
How can you be sure that the CentOS8 stream will not be dropped tomorrow?
How about CentOS9, CentOS10, CentOS Core?!
How can you be sure that what was "promised" will not be canceled in one
second?
I think most of the derivatives will be dead with one or two releases, like
was with Debian, such as Devuan, never got a new version...

In general, I would blame "DevOps" mindset! That might have played the bad
thing here and forced all to this decision.

Maybe RH wanted something like Debian GNU/Linux Testing/stable concept (in
some cases TESTING more stable than prod, as it had the possibility to have
a newer major version with rewritten codebase)?

In either way, RH showed, that after IBM have got them, IBM KPI's forced RH
to do some moves which we never ever were expecting to happen before IBM RH.
Maybe even a first thing that could be a sign, changing Logo into a
"simple" one...

What is left now to treat as trust worthful OS? My decision would be to bet
on:
 * Debian (biggest arch and package selection, which is quite up to date,
and can easily upgrade from 2 to 10, yeah, of course, you will need to do
some mambo jumbo), You can find some things like parrotOS, previous
backtrack and much more in there, so just ADD repo, and download package
what you miss in debian repos. And a shame thing, bubuntu is based on deb,
so, same here, just add missing repos from bubuntu for particular package
(but I have never ever seen such case, when bubuntu had smth needful, what
debian didn't.
 * OpenBSD (very very very clear way forward, very openminded OS, but at
the same time SEC on a first place!), already has vmd, written with a clean
codebase, looks very promissing replacement for kvm in general usages.
 * FreeBSD, AnyOtherBSD BSD, you know... LOTS of appliances work on it! Has
ZFS support... behyve...
 * Arch or Gentoo? Why not LFS then? But both have quite good support and
showed themselfs.

your suggestions?



On Fri, 11 Dec 2020 at 23:25, Matthew Miller  wrote:

> On Fri, Dec 11, 2020 at 07:50:00PM +0100, Walter H. wrote:
> > it is called "rolling release" and no one gave officially a
> > statement to the question I asked,
>
> It should not have been called a rolling release. It is not a rolling
> release in the sense that many Linux distributions use it.
>
> > if it is meant like that of Win10 ...
>
> I don't know what that means. No. It will not be like Win 10 in pretty much
> every way.
>
>
> > a beta release is not the same that many expect as a stable system,
> > as they are used to have with CentOS;
>
> It is not a beta release.
>
>
> > you should think of renaming CentOS to something different, because
> > with Enterprise this CentOS Stream has nothing in common;
>
> Maybe. But I think it has more in common than you think
>
> > and does Redhat really expect everone - even private people - afford
> > a RHEL subscription¹ just to have a stable system?
>
> No. In many cases, CentOS Stream will provide a stable system for the needs
> of individuals. In many other cases, upcoming low- and no-cost RHEL
> programs
> will address many of these needs. As an individual, you can already get
> RHEL
> with no cost through the Developer Program, although it isn't as easy as it
> could be and usage is limited. The upcoming plans are intended to address
> those problems. It's unfortunate that the timing is such that those aren't
> anything but future promises at this point, but they are coming. See
> https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 and email
> centos-questi...@redhat.com with your specific needs. That address goes to
> real people who are working on these programs, not sales or anything like
> that.
>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Ruslanas Gžibovskis
+370 6030 7030
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

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

[Ruslanas Gžibovskis]

hi all.

Just in case, as the third author linked, read the Licence Agreement,
everything will be there.

And a small remark:
Even if you can take a knife in a shopping mall and stab with it anyone
within the same shopping mall, does not say that it is legal. But you can,
Please do not try it in anywhere! well if you have no brain and interested
in trying it...

The same way, just fetching ISO without account and install it and patch
it. It might be possible and no FBI agent will come to you, BUT if you want
to know is it Leagal?
RTFM! ;) by the way, this translates into F.ing  ;) Each dot represents
one char and '.' -ne ' ' ;)






On Sat, 12 Dec 2020 at 18:53, Frank Cox  wrote:

> On Sat, 12 Dec 2020 18:29:08 +0100
> Nicolas Kovacs wrote:
>
> > Here's my take on it:
> >
> > https://blog.microlinux.fr/migration-centos-oracle-linux/
>
> That's a really excellent article, Nicholas.
>
> Thanks ever so much for posting about your experience.
>
> --
> MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Ruslanas Gžibovskis
+370 6030 7030
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 8 future

[Chris Schanzle via CentOS]

On 12/14/20 3:47 PM, Leroy Tennison wrote:
> The whole issue of "support longevity" raises an issue I've been pondering, 
> is 10-year support a good thing from a security perspective?  At work we use 
> Ubuntu LTS which has only a five year support cycle (you can pay for an extra 
> five years) but, even with that, issues have arisen.  Although they do 
> security and bug fix updates, the package versions remain basically the same. 
>  So, if a package is on version 1.2.3, it remains 1.2.3 with bug fixes and 
> security patches for the life of the distribution. Does Red Hat/CentOS do the 
> same thing?

Yes.  Nearly always.  Exceptions are in release notes as "rebasing".


> The reason I ask is I ran into an issue where OpenVPN was updated in a later 
> release to support a more robust security architecture which wasn't available 
> until I upgraded.  A configuration change could have addressed a security 
> weakness in the older version so that the issue wasn't one of a security 
> patch.

This, in a nutshell, is why it is better for stability within a release, to 
back-port fixes.  Yes, it takes a lot more effort by Red Hat to maintain 
software this way.

When you decide a package needs a significantly newer version, that's when you 
start looking at new releases of the OS.





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

Re: [CentOS] CentOS 8 future

[Leroy Tennison]

The whole issue of "support longevity" raises an issue I've been pondering, is 
10-year support a good thing from a security perspective?  At work we use 
Ubuntu LTS which has only a five year support cycle (you can pay for an extra 
five years) but, even with that, issues have arisen.  Although they do security 
and bug fix updates, the package versions remain basically the same.  So, if a 
package is on version 1.2.3, it remains 1.2.3 with bug fixes and security 
patches for the life of the distribution. Does Red Hat/CentOS do the same thing?

The reason I ask is I ran into an issue where OpenVPN was updated in a later 
release to support a more robust security architecture which wasn't available 
until I upgraded.  A configuration change could have addressed a security 
weakness in the older version so that the issue wasn't one of a security patch. 
 However, the change required a lot of effort to implement.

Now I'm wondering about packages in general.


From: CentOS  on behalf of Lamar Owen 

Sent: Monday, December 14, 2020 10:57 AM
To: CentOS mailing list 
Subject: [EXTERNAL] Re: [CentOS] CentOS 8 future

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com
P:


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:
> My only concern ATM is whether RH can change its CentOS 7 maintenance
> plans as well, all of a sudden.
This is what bothers me, too, but in a slightly different way.  Even for
the GPL software, Red Hat actually doesn't have to provide public access
to the source code; the only thing required by GPL is that those who
receive binaries must be able to get sources.  So, even though it has
been said that the source will be available, well, it was also said that
C8 would be supported to 2029.  There are enough packages in RHEL with
non-GPL licenses where it would be very difficult to rebuild the whole
distribution without them, and RH is not required by those licenses
(MIT, BSD, and others) to redistribute those modified sources even to
people who have been distributed binaries.  So, while I want to believe
that the sources will remain available, that belief relies on trust,
which unfortunately is less abundant these days.

So while using another rebuild seems to be a good stopgap solution, I do
wonder if it will prove to be sustainable post-2021.  I'm personally
looking at which of the four (that we know about) to possibly go to; I
just really doubt I am going to use Oracle; Rocky isn't really there yet
and is very young; Springdale is available, mature, and academically
supported (nothing wrong with that, just a statement); CloudLinux OS
Project Lenix isn't yet released.  Out of the bunch, Springdale would be
my first choice right now because it's been around a very long time and
is available now.  C8 is supposed to be around until end of 2021, so
there is some time for the dust to settle and the way to become more
clear, though.  But CentOS 8 Stream is only an option for me if the
hardware driver KABI synchronization issue is solved and stays solved.
RHEL?  Under the current subscription models we just can't afford it.
(Cost also keeps SLES out of the running.)

But I'm now seriously considering just simply going to something that is
both older than Red Hat, fully and totally open, extremely
well-supported by a diverse developer community, and used by a whole lot
of people.  Yes, that's Debian; until I realized where the name came
from (Deb and Ian) it read to me like a play on 'deviant.'  The 'stable'
period is shorter, for sure.  The tradeoffs are pretty simple:
guaranteed openness versus less change for ten years.

So, let's look at that last piece.  CentOS 6's support just ended; what
have the last nine years and three months of actual C6 support looked
like?  I supported several C6 machines, and there were distinct
challenges early on, at least 

Re: [CentOS] Oracle Linux - oracle-epel vs epel - dnf priority

[Frank Cox]

On Mon, 14 Dec 2020 13:57:53 -0500
Stephen John Smoogen wrote:

> Having done this for years.. choose one or the other. Do NOT mix the two.
...
> In the case of nearly 1:1 repos, you
> will end up with it working 95%-99% of the time and then burning down the
> house.

That's pretty much what I was afraid of.

I guess the smart move would be to run OL along with the fedora-epel and not 
bother with the oracle-epel then.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Oracle Linux - oracle-epel vs epel - dnf priority

[Stephen John Smoogen]

On Mon, 14 Dec 2020 at 14:27, Nicolas Kovacs  wrote:

> Le 14/12/2020 à 19:41, Frank Cox a écrit :
> > For those of us who are considering moving to Oracle Linux (or at least
> > doing some experimenting with it), I just had an idea for dealing with
> the
> > fact that the oracle-el-epel apparently doesn't have all of the packages
> > that are in the fedora-el-epel that we all know and love.
>
> The Yum Priorities plugin (package yum-plugin-priorities) would be nice to
> have, but unfortunately it seems to have disappeared. I've used this quite
> extensively over the last decade. Whenever I have to use a third-party repo
> that's a potential threat to the official repos, I'm setting it up with
> priority=10 or something just to be on the safe side.
>
> This has always worked like a charm.
>
>
Like all system administration, there are a lot of corner cases which come
up when you have nearly the same repositories. It was nearly a daily
occurence in #epel and #centos-devel of someone, somewhere having a problem
with DAG and EPEL even with the appropriate priorities. The more overlap of
the package sets, the more likely something would break in a way you only
found 2 to 3 days after you updated.

There is also a level of system administration skill to make it work
seamlessly which we forget. Most of the people running into issues were
people who had followed someone else's advice in an irc or mailing list but
did not really understand what priorities or similar tools did. People who
do know tend to also have test systems and roll out methodologies which are
second nature versus 'yum -y update' cron jobs on a fleet of systems.






> Cheers,
>
> 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
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Oracle Linux - oracle-epel vs epel - dnf priority

[Nicolas Kovacs]

Le 14/12/2020 à 19:41, Frank Cox a écrit :
> For those of us who are considering moving to Oracle Linux (or at least
> doing some experimenting with it), I just had an idea for dealing with the
> fact that the oracle-el-epel apparently doesn't have all of the packages
> that are in the fedora-el-epel that we all know and love.

The Yum Priorities plugin (package yum-plugin-priorities) would be nice to
have, but unfortunately it seems to have disappeared. I've used this quite
extensively over the last decade. Whenever I have to use a third-party repo
that's a potential threat to the official repos, I'm setting it up with
priority=10 or something just to be on the safe side.

This has always worked like a charm.

Cheers,

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

Re: [CentOS] MTU report question

[Strahil Nikolov via CentOS]

what happens when you 'ping -M do -s 65000 -c 4  ?

Best Regards,
Strahil Nikolov






В понеделник, 14 декември 2020 г., 15:46:50 Гринуич+2, Patrick Bégou 
 написа: 





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

Why ? Who is wrong (possibly me)?

Thanks

Patrick

___
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] Oracle Linux - oracle-epel vs epel - dnf priority

[Stephen John Smoogen]

On Mon, 14 Dec 2020 at 13:41, Frank Cox  wrote:

> I'd like to run this by you guys and get your opinion.
>
> For those of us who are considering moving to Oracle Linux (or at least
> doing some experimenting with it), I just had an idea for dealing with the
> fact that the oracle-el-epel apparently doesn't have all of the packages
> that are in the fedora-el-epel that we all know and love.
>
> It makes sense to me to use the oracle epel with OL to the greatest extent
> possible simply because it's part of OL.
>
> To get around the missing package issue, what about setting up both
> oracle-epel and fedora-epel, and then using the dnf priorities to pick the
> stuff from oracle-epel first and if it's not there then grab it from
> fedora-epel.
>
>

Having done this for years.. choose one or the other. Do NOT mix the two.
You will end up with heartache and sleepless nights trying to figure out
why things are broken. If you are lucky it is something easy like an update
is broken because the missing EPEL package wants a library that the OEL has
an older version of. In other cases it is the same thing but the soname was
good enough to make rpm think it would work.

I say this as a former EPEL package leader.. either use Oracle EPEL and
figure out how to interact with them to get their rebuilds done faster or
do the same with Fedora EPEL. Priorities and similar filtering tools work
well enough if you have focused repositories where small sets may overlap
but you want X to take over from Y. In the case of nearly 1:1 repos, you
will end up with it working 95%-99% of the time and then burning down the
house.




-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Oracle Linux - oracle-epel vs epel - dnf priority

[Frank Cox]

I'd like to run this by you guys and get your opinion.

For those of us who are considering moving to Oracle Linux (or at least doing 
some experimenting with it), I just had an idea for dealing with the fact that 
the oracle-el-epel apparently doesn't have all of the packages that are in the 
fedora-el-epel that we all know and love.

It makes sense to me to use the oracle epel with OL to the greatest extent 
possible simply because it's part of OL.

To get around the missing package issue, what about setting up both oracle-epel 
and fedora-epel, and then using the dnf priorities to pick the stuff from 
oracle-epel first and if it's not there then grab it from fedora-epel.

One issue that I can see (though it may not be an actual issue) is the way the 
priorities setting works:

QUOTE:
priority
integer
The priority value of this repository, default is 99. If there is more than 
one candidate package for a particular operation, the one from a repo with the 
lowest priority value is picked, possibly despite being less convenient 
otherwise (e.g. by being a lower version).
END OF QUOTE

By setting fedora-epel to a lower priority, the if a package we want is only in 
fedora-epel, we'll grab it from there.  But if that package has a dependency on 
another package version X  that can be found in fedora-epel and for some reason 
oracle-epel supplies only package version X-1, what happens then?  Is dnf smart 
enough to pick the higher-versioned (and required) package from fedora-epel 
even though it has a lower priority.

I'll try to explain that again.

I want to install Foo, which is only in fedora-epel.

Foo requires Bar version 2.0.

Bar 2.0 exists in fedora-epel, but oracle-epel has only Bar version 1.0.

What happens then?  Does dnf see that Foo requires Bar-2.0 and get it from 
fedora-epel even though it has a lower priority?

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-es] CentOS rip?

[Rene L.A.]

Tal vez  debamos, nosotros, los usuarios, reflexionar sobre ciertos temas.
1) ¿Habrá algún proyecto que mantenga en el largo plazo sin la 
contribución de la mayoría de los usuarios?

Pienso que no.

2) Debemos contribuir mas.
Estoy de acuerdo que muchos lo usamos porque no hacemos gran negocio con 
él, pero  todos podemos en alguna medida contribuir.


Por mas filantrópico que sea el software libre, necesita recursos.
r.lara
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] CentOS 8 future

[Ian B]

> Lots of chat stuff...

Something interesting happens when there's change. People get involved in a
different way, and it can actually be positive.

Centos for me is an example of something that many people took for granted
(including myself). Now there's change and the start of things like Rocky,
I think a lot of people learn something new with a new distro, and feel
like they can get involved, people learn again what it takes, there's a new
energy. Personally I hope Centos, Rocky all thrive.

My main negative is the shortening of end of life, it's caught me out.
That's a big no-no in this world as far as I'm concerned. It's all been
said already though.

Ian


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

Re: [CentOS-es] CentOS rip?

[Ricardo J. Barberis]

El Sábado 12/12/2020 a las 19:40, Oscar Osta Pueyo escribió:
> El ds, 12 des 2020 a les 18:05 Sergio Belkin  va escriure:
> > El sáb, 12 dic 2020 a las 11:47, David González Romero (<
> > dgrved...@gmail.com>)
> >
> > escribió:
> > > > Genbeta: CentOS será historia tal y como lo conocemos: Red Hat dice
> > >
> > > adiós a
> > >
> > > > CentOS Linux para centrarse en CentOS
> >
> > https://www.genbeta.com/linux/centos-sera-historia-tal-como-conocemos-red
> >-hat-dice-adios-a-centos-linux-para-centrarse-centos-stream
> >
> > > Leyendo esta noticia, ahora recuerdo que mi punto de inflección con
> >
> > CentOS
> >
> > > fue cuando Red Hat Inc empezó a meter sus narices en CentOS y que
> >
> > miembros
> >
> > > del team CentOS pasaron a Red Hat y viceversa... para mi fue claro que
> > > CentOS correría la misma suerte más tarde o temprano.
> > >
> > > De cualquier forma yo les hago ver que Debian en su versión SID ya
> > > viene haciendo rolling release, SID no ha cambiado de ser SID y es
> > > claro que muchas cosas no funcionan ahí y otras pues costará más que se
> > > actualicen; sin embargo es el modelo.
> >
> > Pero la diferencia es que nadie en su sano juicio pone Debian SID en
> > servidores...
>
> Se está hablando mucho de que CentOS Stream 8 será una "rolling release" y
> según Red Hat la única diferencia es que tendrá disponible las
> actualizaciones de las versiones menores, nunca de las mayores. Así que
> poco tienen que ver con una "rolling release".
>
> En realidad es "continuos delivery"
> https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/

Exacto, no es una rolling release como Debian SID o Arch sino mas bien como 
tener el repositorio Continuous Release habilitado en CentOS 7.

> Saludos,
>
> > --
>
> Oscar Osta Pueyo
> oostap.lis...@gmail.com
> _kiakli_
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es



-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] CentOS 8 future

[Lamar Owen]

On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:
My only concern ATM is whether RH can change its CentOS 7 maintenance 
plans as well, all of a sudden. 
This is what bothers me, too, but in a slightly different way.  Even for 
the GPL software, Red Hat actually doesn't have to provide public access 
to the source code; the only thing required by GPL is that those who 
receive binaries must be able to get sources.  So, even though it has 
been said that the source will be available, well, it was also said that 
C8 would be supported to 2029.  There are enough packages in RHEL with 
non-GPL licenses where it would be very difficult to rebuild the whole 
distribution without them, and RH is not required by those licenses 
(MIT, BSD, and others) to redistribute those modified sources even to 
people who have been distributed binaries.  So, while I want to believe 
that the sources will remain available, that belief relies on trust, 
which unfortunately is less abundant these days.


So while using another rebuild seems to be a good stopgap solution, I do 
wonder if it will prove to be sustainable post-2021.  I'm personally 
looking at which of the four (that we know about) to possibly go to; I 
just really doubt I am going to use Oracle; Rocky isn't really there yet 
and is very young; Springdale is available, mature, and academically 
supported (nothing wrong with that, just a statement); CloudLinux OS 
Project Lenix isn't yet released.  Out of the bunch, Springdale would be 
my first choice right now because it's been around a very long time and 
is available now.  C8 is supposed to be around until end of 2021, so 
there is some time for the dust to settle and the way to become more 
clear, though.  But CentOS 8 Stream is only an option for me if the 
hardware driver KABI synchronization issue is solved and stays solved.  
RHEL?  Under the current subscription models we just can't afford it. 
(Cost also keeps SLES out of the running.)


But I'm now seriously considering just simply going to something that is 
both older than Red Hat, fully and totally open, extremely 
well-supported by a diverse developer community, and used by a whole lot 
of people.  Yes, that's Debian; until I realized where the name came 
from (Deb and Ian) it read to me like a play on 'deviant.'  The 'stable' 
period is shorter, for sure.  The tradeoffs are pretty simple: 
guaranteed openness versus less change for ten years.


So, let's look at that last piece.  CentOS 6's support just ended; what 
have the last nine years and three months of actual C6 support looked 
like?  I supported several C6 machines, and there were distinct 
challenges early on, at least for the first four years or so.  Since 
then, on the server, it's been very stable, but really old; key pieces 
of infrastructure software we use slowly became unusable on C6 due to 
the old versions of specific packages, and either a third-party repo 
with newer packages or a newer CentOS was needed.


Third-party repos have improved over the years, but some of the earlier 
C6 machines I installed had packages from Linuxtech, Dag, ATrpms, 
City-Fan (one particular DVD burner that just had to have the non-wodim 
cdrtools for some reason; yes, I know all the warnings about that repo), 
and others.  Having EPEL and Dag both package a few things that I 
needed, but package them differently, introduced me to package pinning 
and repo priorities I don't miss those days.  Seriously stable in 
the core repos means very little when you need much less stable 
third-party repos to get actual work done. That's also why Fedora isn't 
really an option, just too much package churn; been there, done that, a 
few years ago.


So I've started re-evaluating just why I use CentOS anyway; the answer 
really boils down to the fact that I started out with Red Hat Linux in 
1997 (I live in North Carolina, and I've always liked supporting local 
companies) and I just really don't want to change; it feels like I've 
wasted so much effort if I change now (that was the reason I stuck with 
it through the Fedora-RHEL split years ago, too, and went with a RHEL 
rebuild, first WBEL then CentOS).  But the reality is not nearly so 
stark; a vast majority of the information and skills I've picked up in 
these years are portable to other distributions; so it's not wasted 
effort.  Well, other than RPM packaging skills; those are a bit less 
portable.  Whenever I've built from source I've tried to either build my 
own RPM for it or rebuild the Fedora RPM for it, and so I have a local 
repo of those packages, making reinstall much easier.  So it becomes a 
tossup: small change to another rebuild now, possibility of major change 
later, or bite the bullet and go ahead and get the major change over 
with and only have small changes later.


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

Re: [CentOS] Blog article: CentOS is NOT dead

[Mauricio Tavares]

On Mon, Dec 14, 2020 at 9:41 AM Nicolas Kovacs  wrote:
>
> Le 14/12/2020 à 15:25, James Pearson a écrit :
> > As others have said, it misses the _really_ important bit about the
> > traditional CentOS model which is to follow the RHEL ~10 year life cycle
>
> I totally agree with you.
>
> But when you disagree with someone (e.g. the CentOS team), it's good at least
> to hear the person out.
>
  If you have followed the other threads in the subject, there is
one called "[CentOS]
https://blog.centos.org/2020/12/future-is-centos-stream/; where centos
and redhat are talking with the users, developers (like the bloke who
does epel), and supporters about the changes. I would say that means
people are discussing that in the list. If you missed that, please
look for it in the mail archive.

> Back at the university here in Montpellier, we had a funny exercise in one of
> the courses. Every one of us had to pick a subject where he or she had a 
> strong
> position. I remember I chose nuclear energy, which I think is a bad choice. 
> And
> in the exercise, I had to *defend* nuclear energy against its opponents.
>
> And I published the link to the article because it's a fine text and nicely
> argumented.
>
  I usually try to avoid reading anything on medium.com because of
its paywall and how it controls what users get to see; I can provide a
link to what a group who left it wrote if you want. But, for the sake
of hearing you out, I opened the doc in a browser in incognito mode.
In it the author states

'CentOS will no longer be old, crusty, and barely alive, trailing RHEL
by months at times.'

First, the word choice in that sentence, which prevails the article,
is anything but nicely argumented as you put it. Second, Centos stream
will have some patches before RHES but the security patches will be
done *after* RHES.  In my book that sounds like it checks the
"trailing RHEL by months at times" box where it counts. So, his pretty
drawing is very innaccurate.

Further down the author tells us that "IBM did not do this. The CentOS
governing board, some of which work for Red Hat, did this." Thanks to
the  "[CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/;
thread it became known that redhat told the centos steering committee
that centos was changing and they -- centos committee -- had the
option to vote to approve those changes -- unanimously -- while redhat
reserved the right to overrule the entire voting. To understand the
significance of this, we need to remember what the "C" in CentOS stand
for: community.

The author also states "This was not done intentionally. It is also
water under the bridge." I would like to focus on the last sentence.
That sounds very final and implies the "C" in Centos matters little
(refer to my previous comment on the decision process).

Then the author goes on and says 'If you are someone who is thinking,
“CentOS is now just the RHEL beta,” please ask yourself, did you use
to consider RHEL to be the CentOS beta? If not, you shouldn’t be
thinking that now about CentOS.' Like in other parts of this "nicely
argumented article" the author is very condescending, implying anyone
who does not agree with his point is a nitwit. In fact, his "The way
software makes it in is the same. It just hits CentOS first instead of
RHEL first" statement is misleading because of the security patches
case I pointed earlier.

Another of the author's points is that "[...] if RHEL is the gold
standard of stability (which many would suggest it is) then why would
CentOS Stream, a distro effectively taking its place in the line-up,
be less stable?" That clashes with what Chris Wright, the Red Hat CTO
stated

"To be exact, CentOS Stream is an upstream development platform for
ecosystem developers. It will be updated several times a day. This is
not a production operating system."
(source: 
https://web.archive.org/web/20201212012342/https://www.redhat.com/en/blog/transforming-development-experience-within-centos)

Further down the author argues 'It’s no secret that CentOS competes
with RHEL. I’ve personally heard CTOs tell Red Hat salespeople, “why
should I buy RHEL when I can use CentOS for free?” I die inside when I
hear that. It is a fair and good question, but asking it tends to fire
up a salesperson and gives them direct financial reasons to hate on
CentOS.' If that is the case, that shows Red Hat salespeople need some
training; there is a RH partner who commented out recently in the list
that his company has no issues helping groups with not enough budget
to use centos, understanding its limitations, and upselling those who
need the commercial version because of the support (last time I used
the RHES support it was quite good).



> Cheers,
>
> 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
> 

Re: [CentOS] Blog article: CentOS is NOT dead

[Jon Pruente]

On Mon, Dec 14, 2020 at 8:25 AM James Pearson 
wrote:

> I agree that Redhat really screwed up this announcement - they would have
> got a lot more kudos if they had announced CentOS Stream to exist along
> with keeping the current traditional CentOS ...
>

Oh, but they did do that. Last year, when CentOS 8 was announced Stream was
announced alongside it. The screw up here was in killing off CentOS Linux
by decree from Red Hat with a bunch of spin about how we're all better off
for it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article: CentOS is NOT dead

[Simon Matter]

Hi,

> "Nicolas Kovacs"  wrote:
>
>>  
>> https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877
>
> The article states that CentOS will now be "upstream" of RHEL instead
> of "downstream".
>
> This is strange to me. I never thought CentOS was upstream or
> downstream of RHEL; I always thought it *was* RHEL -- perhaps a little
> delayed, but that's not the same as being "downstream".

But that's also part of the problem for Red Hat, at least that's my
impression and I can understand why.

> It's also clear that Red Hat didn't understand the importance of the
> 10-year support period.

I _could_ probably live with CentOS Stream for the benefit of all even if
it's not 100% identical to RHEL but as stable as it, _but_, only if they
extend the maintenance period to the same 10 years analog to RHEL.

@Red Hat, do you hear our voices?

Regards,
Simon

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

Re: [CentOS] Blog article: CentOS is NOT dead

[Yves Bellefeuille]

"Nicolas Kovacs"  wrote:

>  
> https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877

The article states that CentOS will now be "upstream" of RHEL instead
of "downstream".

This is strange to me. I never thought CentOS was upstream or
downstream of RHEL; I always thought it *was* RHEL -- perhaps a little
delayed, but that's not the same as being "downstream".

It's also clear that Red Hat didn't understand the importance of the
10-year support period.

-- 
Yves Bellefeuille





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

Re: [CentOS] I'm looking forward to the future of CentOS Stream

[Phelps, Matthew]

On Mon, Dec 14, 2020 at 10:37 AM Scott Robbins  wrote:

> On Mon, Dec 14, 2020 at 08:00:24AM -0700, James Szinger wrote:
> > >
> > > Using Fedora on production servers is like climbing without a rope.
> > >
> > > It's possible. I've even seen some folks do it.
> >
> > Since the release of CentOS 8, I have been moving my stuff over to
> > Fedora.  The combination of modularity and missing -devel packages
> > make developing and building software on EL8 impractical.  As a
> > result, EL8 is poor choice for deploying custom software.
> >
> While I don't use Fedora as a production server, I will say that ever since
> Adam Williamson joined them, the QA has been quite good. I used to worry
> about an update breaking things. Now I use it as my go to Linux on laptops,
> and have successfully upgraded, using their instructions for CLI updates,
> with no problems.
>
> I do use openbox and dwm (which I install from source) rather than Gnome,
> which  might have something to do with my painless updates.
>
> Not to say it's a good server OS (though not saying it isn't, I don't have
> enough knowledge of it in that situation to say), but it's not the always
> on the edge of breaking that it used to be.
>
> --
> Scott Robbins
> PGP keyID EB3467D6
> ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
> gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
>
>
The main issue against using Fedora in production environments is the short
lifecycle. Forcing an upgrade, and all the associated testing, auditing,
etc. of the base version every year or so is not tenable for most
organizations.

-- 

*Matt Phelps*

*Information Technology Specialist, Systems Administrator*

(Computation Facility, Smithsonian Astrophysical Observatory)

Center for Astrophysics | Harvard & Smithsonian


60 Garden Street | MS 39 | Cambridge, MA 02138
email: mphe...@cfa.harvard.edu


cfa.harvard.edu | Facebook  | Twitter
 | YouTube 
| Newsletter 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article: CentOS is NOT dead

[Konstantin Boyandin via CentOS]

On 14.12.2020 22:39, Ljubomir Ljubojevic wrote:
> On 12/14/20 4:09 PM, Konstantin Boyandin via CentOS wrote:
>> On 14.12.2020 21:41, Nicolas Kovacs wrote:
>>> Le 14/12/2020 à 15:25, James Pearson a écrit :
 As others have said, it misses the _really_ important bit about the
 traditional CentOS model which is to follow the RHEL ~10 year life
 cycle
[...]
>>> And I published the link to the article because it's a fine text and
>>  nicely argumented.
>>
>> Well, it's mostly emotional (the leitmotif: "how can you say CentOS
>> Stream is bad if you didn't try it?"). And the author's bio spoils the
>> fun, as well:
>>
>> "Ben Porter is a Linux and open source advocate, currently working as an
>> OpenShift consultant for Red Hat."
>>
>> And the comments to the graphs, where RHEL, CentOS and Fedora are placed
>> on a line, are simply ridiculous (such as "did you use to consider RHEL
>> to be the CentOS beta?"). With all due respect to Ben Porter, it didn't
>> convince me.
> 
> I have posted a comment that explains why and on which topic he is
> wrong. You post them and I will debunk them :-)

Well, arguing with you in that Medium blog would be counter-productive:
- as far as I see, we share similar viewpoints on CentOS situation
- your response is very detailed, it would make little sense elaborating it

-- 
Sincerely,

Konstantin Boyandin
system administrator (ProWide Labs Ltd. - IPHost Network Monitor)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article: CentOS is NOT dead

[Ljubomir Ljubojevic]

On 12/14/20 4:09 PM, Konstantin Boyandin via CentOS wrote:
> On 14.12.2020 21:41, Nicolas Kovacs wrote:
>> Le 14/12/2020 à 15:25, James Pearson a écrit :
>>> As others have said, it misses the _really_ important bit about the
>>> traditional CentOS model which is to follow the RHEL ~10 year life cycle
>>
>> I totally agree with you.
>>
>> But when you disagree with someone (e.g. the CentOS team), it's good at
>  least
>> to hear the person out.
>>
>> Back at the university here in Montpellier, we had a funny exercise in one
>  of
>> the courses. Every one of us had to pick a subject where he or she had a
>  strong
>> position. I remember I chose nuclear energy, which I think is a bad
>  choice. And
>> in the exercise, I had to *defend* nuclear energy against its opponents.
>>
>> And I published the link to the article because it's a fine text and
>  nicely
>> argumented.
> 
> Well, it's mostly emotional (the leitmotif: "how can you say CentOS 
> Stream is bad if you didn't try it?"). And the author's bio spoils the 
> fun, as well:
> 
> "Ben Porter is a Linux and open source advocate, currently working as an 
> OpenShift consultant for Red Hat."
> 
> And the comments to the graphs, where RHEL, CentOS and Fedora are placed 
> on a line, are simply ridiculous (such as "did you use to consider RHEL 
> to be the CentOS beta?"). With all due respect to Ben Porter, it didn't 
> convince me.
> 

I have posted a comment that explains why and on which topic he is
wrong. You post them and I will debunk them :-)


-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] I'm looking forward to the future of CentOS Stream

[Scott Robbins]

On Mon, Dec 14, 2020 at 08:00:24AM -0700, James Szinger wrote:
> > 
> > Using Fedora on production servers is like climbing without a rope.
> > 
> > It's possible. I've even seen some folks do it.
> 
> Since the release of CentOS 8, I have been moving my stuff over to
> Fedora.  The combination of modularity and missing -devel packages
> make developing and building software on EL8 impractical.  As a
> result, EL8 is poor choice for deploying custom software.
> 
While I don't use Fedora as a production server, I will say that ever since
Adam Williamson joined them, the QA has been quite good. I used to worry
about an update breaking things. Now I use it as my go to Linux on laptops,
and have successfully upgraded, using their instructions for CLI updates,
with no problems. 

I do use openbox and dwm (which I install from source) rather than Gnome,
which  might have something to do with my painless updates.

Not to say it's a good server OS (though not saying it isn't, I don't have
enough knowledge of it in that situation to say), but it's not the always
on the edge of breaking that it used to be.

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

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

Re: [CentOS-es] CentOS rip?

[Ing . Ernesto Pérez Estévez , Mg . via CentOS-es]

El 13/12/20 a las 09:23, Henry Rosado escribió:
> Solo me pregunto uno de los creadores de éste sistema mail que fue EPE,
> como ve ésto, el era un fuerte en CentOS, aparte, que otra alternativa se
> podría tomar y de paso, los servidores que están en producción, tocará
> migrar a otros como Debian o ubuntu server?

por acá puse mi opinión https://youtu.be/X-4d8U4A41Y

Sí, soy moderador de la lista de CentOS en Español desde que salió, con
Orkcu.

En mi caso pienso que hay que esperar, hay más noticias que lo que
salió. No es el fin.

Y, atención, también hay más alternativas que las que se están
mencionando en este hilo, en el video las converso.

saludos
epe


-- 
CEDIA
La principal herramienta de Investigación en el Ecuador.

Gonzalo Cordero 2-122 y J. Fajardo
Cuenca -  Ecuador
Telf: +593 7 407 9300 Ext. 115
i...@cedia.org.ec
www.cedia.edu.ec
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] Blog article: CentOS is NOT dead

[Konstantin Boyandin via CentOS]

On 14.12.2020 21:41, Nicolas Kovacs wrote:
> Le 14/12/2020 à 15:25, James Pearson a écrit :
>> As others have said, it misses the _really_ important bit about the
>> traditional CentOS model which is to follow the RHEL ~10 year life cycle
> 
> I totally agree with you.
> 
> But when you disagree with someone (e.g. the CentOS team), it's good at
 least
> to hear the person out.
> 
> Back at the university here in Montpellier, we had a funny exercise in one
 of
> the courses. Every one of us had to pick a subject where he or she had a
 strong
> position. I remember I chose nuclear energy, which I think is a bad
 choice. And
> in the exercise, I had to *defend* nuclear energy against its opponents.
> 
> And I published the link to the article because it's a fine text and
 nicely
> argumented.

Well, it's mostly emotional (the leitmotif: "how can you say CentOS 
Stream is bad if you didn't try it?"). And the author's bio spoils the 
fun, as well:

"Ben Porter is a Linux and open source advocate, currently working as an 
OpenShift consultant for Red Hat."

And the comments to the graphs, where RHEL, CentOS and Fedora are placed 
on a line, are simply ridiculous (such as "did you use to consider RHEL 
to be the CentOS beta?"). With all due respect to Ben Porter, it didn't 
convince me.

-- 
Sincerely,

Konstantin Boyandin
system administrator (ProWide Labs Ltd. - IPHost Network Monitor)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] I'm looking forward to the future of CentOS Stream

[James Szinger]

On Sun, 13 Dec 2020 09:15:52 +0100
Nicolas Kovacs  wrote:

> Le 11/12/2020 à 02:25, Gordon Messmer a écrit :
> > Personally, I think that changing focus on CentOS Stream is going
> > to make CentOS (and maybe even RHEL) better in the same way and for
> > the same reasons that Fedora is a better distribution than Red Hat
> > Linux was.  
> 
> Using Fedora on production servers is like climbing without a rope.
> 
> It's possible. I've even seen some folks do it.

Since the release of CentOS 8, I have been moving my stuff over to
Fedora.  The combination of modularity and missing -devel packages
make developing and building software on EL8 impractical.  As a
result, EL8 is poor choice for deploying custom software.

Fedora has other advantages.

1. More changes.  Bugs are likely to be addressed sooner and I find
addressing small changes one at a time is more manageable than many
big changes all at once.  Having a good test suite helps.  Our
sysadmin at work spent most of 2020 doing the upgrade from CentOS 6 to
8.  I like to think there were better uses of his time.

2. More software.  Fedora packages much more software than CentOS.
Even adding in EPEL leaves a big gap and EPEL is Fedora, not RHEL.  I
spend less time building dependencies and more time adding value.

3. Easy licensing.  Fedora may be used anywhere for anything.  We have
a RHEL license at work, but I don’t use it because I do not want the
headache of tracking where and how it is deployed.  I’ve wasted too
many days fighting licensing and compliance issues to want to ever do
it again.  It is huge advantage for Free Software.

Your needs may differ, but it is not an insane choice, so please stop
insulting us.

Jim

P.S. It seems to me that compared to Fedora, Stream has the
disadvantages of RHEL but not the advantages.  It’s not clear to me
how Stream will be an improvement.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article: CentOS is NOT dead

[Nicolas Kovacs]

Le 14/12/2020 à 15:25, James Pearson a écrit :
> As others have said, it misses the _really_ important bit about the
> traditional CentOS model which is to follow the RHEL ~10 year life cycle

I totally agree with you.

But when you disagree with someone (e.g. the CentOS team), it's good at least
to hear the person out.

Back at the university here in Montpellier, we had a funny exercise in one of
the courses. Every one of us had to pick a subject where he or she had a strong
position. I remember I chose nuclear energy, which I think is a bad choice. And
in the exercise, I had to *defend* nuclear energy against its opponents.

And I published the link to the article because it's a fine text and nicely
argumented.

Cheers,

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

Re: [CentOS] Blog article: CentOS is NOT dead

[James Pearson]

Nicolas Kovacs 
> 
> Here's an interesting read which makes a point for CentOS Stream:
> 
> https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877
>
> tl;dr: Communication about Stream was BAD, but Stream itself might be a good
> thing. Here's why.

As others have said, it misses the _really_ important bit about the traditional 
CentOS model which is to follow the RHEL ~10 year life cycle

It doesn't matter how good/rock solid/whatever CentOS Stream turns out to be, 
but if it only has a 5 year life cycle for each major release, then it no good 
to me (and I suspect many others)

The article also mentions "CentOS will no longer be old, crusty, and barely 
alive, trailing RHEL by months at times" - then why didn't Redhat put resources 
into CentOS to improve that?

Redhat must have known, that if they killed off traditional CentOS, then users 
will simply go elsewhere for a RHEL rebuild ?

I agree that Redhat really screwed up this announcement - they would have got a 
lot more kudos if they had announced CentOS Stream to exist along with keeping 
the current traditional CentOS ...

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

[CentOS] MTU report question

[Patrick Bégou]

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

Why ? Who is wrong (possibly me)?

Thanks

Patrick

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

Re: [CentOS] Blog article: CentOS is NOT dead

[Gionatan Danti]

Il 2020-12-14 13:07 Nicolas Kovacs ha scritto:

Hi,

Here's an interesting read which makes a point for CentOS Stream:

https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877

tl;dr: Communication about Stream was BAD, but Stream itself might be a 
good

thing. Here's why.

Cheers,

Niki


While interesting, I think the blog post fails to identify the the main 
issue with Stream:
- Stream can be updated many times each days. You basically have a 
non-stop incoming flow of updates;
- as far I know, Stream does not have (and will not have) 
"synchronization points" with mail RHEL;

- the support window is much shorter (ie: 2024 vs 2029).

Anyone relying on RHEL/CentOS to be kABI compatible can be severely 
impacted by the first two points (it's difficult planning updates with 
rolling releases, when the kernel version can change from a day to 
another), while the third one (shorter support window) affect anyone.


Basically it seems to me that Stream will be to RHEL the same Rawhide is 
to normal Fedora releases. While this has the potential to be a good 
move, it should be offered *in addition* to normal CentOS releases - 
which effectively are a different product.


That said I am grateful to all the volunteers that made CentOS possible, 
and I don't want the above to be taken as a rant - they only are my 
(possibly wrong) opinions.


Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Blog article: CentOS is NOT dead

[Walter H.]

On 14.12.2020 13:07, Nicolas Kovacs wrote:

Hi,

Here's an interesting read which makes a point for CentOS Stream:

https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877

tl;dr: Communication about Stream was BAD, but Stream itself might be a good
thing. Here's why.


'might' doesn't mean 'is', there the "terminus techicus" 'dead' is korrekt


"CentOS Stream intends to be as stable as RHEL"

and where is the 10 year update support?

the last update of CentOS Stream will be in the year 2024

and do you really think it is worth the work to migrate to CentOS Stream,
when knowing to have this work again in less than 4 years?

Walter



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

[CentOS] Blog article: CentOS is NOT dead

[Nicolas Kovacs]

Hi,

Here's an interesting read which makes a point for CentOS Stream:

https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877

tl;dr: Communication about Stream was BAD, but Stream itself might be a good
thing. Here's why.

Cheers,

Niki
-- 
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