Re: [CentOS-virt] very low performance of Xen guests

2020-06-17 Thread Manuel Wolfshant

On 6/15/20 5:40 PM, Stephen John Smoogen wrote:



On Mon, 15 Jun 2020 at 09:42, Manuel Wolfshant 
mailto:wo...@nobugconsulting.ro>> wrote:


On 6/15/20 2:46 PM, Stephen John Smoogen wrote:

I got inspired by Adi's earlier suggestion and after reading
https://access.redhat.com/articles/3311301 I've tried today all
variants of disabling the spectre mitigations. Whatever I do,
immediately after a reboot, yum reinstall kernel does not take
less than 5 minutes :( It goes down to 2 min if I repeat the
operation afterwards so I guess some caching kicks in. I will try
later today the kernels from elrepo and maybe even xen.crc.id.au
 ( I kind of hate the "disable selinux"
recommendation from the install page so I postponed it in the hope
of other solution ).



If you can do a full reinstall, could you see if a KVM host/guest 
combo has the same problem? That would at least point the finger more 
firmly at VT, spectre or something else.





I finally managed to install a fresh KVM host / guest pair on an 
identical blade ( HS21XM, 64 GB ram, 2*E5450@ 3.00GHz ). Here are the 
results I see:



1. KVM host, stock instalation and fully updated, kernel 3.10.0-1127.10.1
#cd /sys/kernel/debug/x86/
#cat ibrs_enabled pti_enabled retp_enabled
0
1
1

#time yum -y reinstall kernel-3.10.0-1127.el7.x86_64
real    0m50.026s
user    0m32.872s
sys 0m23.312s


2. KVM guest on the same machine (virt-install --name guest1-rhel7 
--memory 2048 --vcpus 2  --disk size=20 --network=bridge:br0 --pxe 
--os-variant rhel7 <=== copy/paste from 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install 
), stock installation and fully updated with absolutely no change 
towards the defaults including same ibrs_enabled pti_enabled 
retp_enabled as the host, , kernel 3.10.0-1127.10.1



#time yum -y reinstall kernel-3.10.0-1127.el7.x86_64
real    2m39.644s
user    1m54.662s
sys 1m32.496s


3. Xen Domu,  3.10.0-1127.8.2.el7.x86_6 ( but results are consistent 
across all kernels )


# cat ibrs_enabled pti_enabled retp_enabled
0
0
0

# time yum -y reinstall kernel-3.10.0-1127.el7.x86_64
real    5m44.030s
user    2m9.931s
sys 4m7.771s


4. Dom0, 4.9.215-36.el7.x86_64, , xen 4.12 from centos' repo

# time  yum -y reinstall kernel-3.10.0-1127.el7.x86_64
real    1m52.417s
user    0m45.704s
sys 1m32.167s

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


Re: [CentOS] CentOS 8.2 corrupt pxeboot kernel

2020-06-17 Thread isdtor


> pxe is working for me in this test virtualbox build.
> 
> $ md5sum initrd.img vmlinuz
> 89251241a484010b98280ce00b3a3763  initrd.img
> 9261bb24add6bb4ff9ef6aaf348aaf35  vmlinuz
> 
> ( yum updated )
> 
> [centos@localhost ~]$ uname -a
> Linux localhost.localdomain 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 
> 10 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> [centos@localhost ~]$ cat /etc/redhat-release
> CentOS Linux release 8.2.2004 (Core)

And it is working here now, too. After replacing the trusty, 8-year old 
pxelinux.0 with a slightly newer version. Strange that it should break just 
after C8.1.

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


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

2020-06-17 Thread Noam Bernstein via CentOS
> On Jun 17, 2020, at 4:53 PM, Chris Adams  wrote:
> 
> Once upon a time, Noam Bernstein  said:
>> Of course.   My only question is whether the observation that the gap for 
>> CentOS 8 is indeed larger than we have come to be used to for CentOS 7.
> 
> So, I took a look... and the answer is "it's not" (with a small sample
> set).  I took dates from Wikipedia for RHEL and the archived release
> notes for CentOS.  I didn't bother with the .0 releases (since that's a
> lot of new work anyway).  Right now, CentOS 8 is far faster than CentOS
> 7 and 6 were at this stage.

Did you look at the German blog that started this discussion? I don't know what 
determines the archived release notes dates, but I just picked the longest 
delay, CentOS 7.4.   You list:
> 
> release RHEL date   CentOS date days
> 7.4 2017-08-01  2018-03-21  232
which is indeed the "last updated" dated on the archived notes. However, the 
German blog post that started this thread lists the much earlier 2017-09-13 for 
CentOS, 43 days.  On the mailing list this message
https://lists.centos.org/pipermail/centos-announce/2017-September/022532.html 
appears
 to confirm the earlier date.

I'm not sure the difference shown in that blog (assuming the other dates are 
also correct) is really quite so dramatic as to justify the conclusion that 
CentOS 8 is now too slow in getting updates for a substantial number of 
situations where the CentOS 7 lag was acceptable, but it's apparently not 
faster.

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


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

2020-06-17 Thread Akemi Yagi
On Wed, Jun 17, 2020 at 1:53 PM Chris Adams  wrote:

> Once upon a time, Noam Bernstein  said:
> > Of course.   My only question is whether the observation that the gap
> for CentOS 8 is indeed larger than we have come to be used to for CentOS 7.
>
> So, I took a look... and the answer is "it's not" (with a small sample
> set).  I took dates from Wikipedia for RHEL and the archived release
> notes for CentOS.  I didn't bother with the .0 releases (since that's a
> lot of new work anyway).  Right now, CentOS 8 is far faster than CentOS
> 7 and 6 were at this stage.
>
> release RHEL date   CentOS date days
> 6.1 2011-05-19  2011-12-12  207
> 6.2 2011-12-06  2012-07-24  231
> 6.3 2012-05-20  2012-09-30  133
> 6.4 2013-02-21  2013-05-21  89
> 6.5 2013-11-21  2014-02-26  97
> 6.6 2014-10-13  2014-11-15  33
> 6.7 2015-07-22  2015-09-05  45
> 6.8 2016-05-10  2016-07-28  79
> 6.9 2017-03-21  2017-04-05  15
> 6.102018-06-19  2018-07-03  14
>
> 7.1 2015-03-05  2015-10-11  220
> 7.2 2015-11-19  2016-02-19  92
> 7.3 2016-11-03  2016-12-21  48
> 7.4 2017-08-01  2018-03-21  232
> 7.5 2018-04-10  2018-10-30  203
> 7.6 2018-10-30  2019-01-28  90
> 7.7 2019-08-06  (didn't find release notes)
> 7.8 2020-03-31  2020-04-27  27
>
> 8.1 2019-11-05  2020-01-15  71
> 8.2 2020-04-28  2020-06-15  48
>

 7.7 2019-08-06  2019-09-17  42
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


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

2020-06-17 Thread Phil Perry

On 17/06/2020 21:05, Lamar Owen wrote:

On 6/17/20 3:32 PM, Phil Perry wrote:


On my home file server for example, which is not connected to the 
internet, what does it matter if the release is 1 month or 3 months 
out of date? I can install the server in the knowledge it's going to 
work, and be supported with updates for 10 years and I can largely 
forget about it. My el5 box ran for more than 10 years until the 
hardware eventually died. 
EL5... how modern...  from a production application server VM, not 
internet-connected:

[root@c6-2850 ~]# ssh root@10.1.x.y
root@10.1.x.y's password:
Last login: Tue Jan 28 19:53:32 2020
unknown terminal "xterm-256color"
unknown terminal "xterm-256color"
[root@localhost root]# cat /etc/centos-release
CentOS Linux Advanced Server release 2.1AS (Slurm)
[root@localhost root]#

This one has to be hard reset every day or two (virsh reset rhel2.1) 
since the bridge to the guest just dies randomly, and a reboot inside 
the guest hangs hard before finishing the reboot.  The hard reset has to 
manually load the ethernet kernel module after it's booted up so far; if 
the ethernet module loads too soon it will never connect haven't 
found the reason for that, either, just run a pinging script every 
fifteen minutes on the host to check for connectivity and 'virsh reset 
rhel2.1' when it fails.  The appserver is hard reboot resilient, and the 
software does a very specific task, and there's no budget for a 
rewrite.  At least I did upgrade it from Red Hat Linux 5.2 a couple of 
years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran 
almost continuously for 20 years).


Thanks, CentOS!



Indeed!

You have clearly had more success with the longevity of your hardware 
than me. I was plagued with expanding capacitors about 15 years ago 
which killed off most of my hardware at the time, and the replacements 
were taken out of service as they subsequently died meaning I'm 
exclusively running el7|8 now :-)


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


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

2020-06-17 Thread Chris Adams
Once upon a time, Noam Bernstein  said:
> Of course.   My only question is whether the observation that the gap for 
> CentOS 8 is indeed larger than we have come to be used to for CentOS 7.

So, I took a look... and the answer is "it's not" (with a small sample
set).  I took dates from Wikipedia for RHEL and the archived release
notes for CentOS.  I didn't bother with the .0 releases (since that's a
lot of new work anyway).  Right now, CentOS 8 is far faster than CentOS
7 and 6 were at this stage.

release RHEL date   CentOS date days
6.1 2011-05-19  2011-12-12  207
6.2 2011-12-06  2012-07-24  231
6.3 2012-05-20  2012-09-30  133
6.4 2013-02-21  2013-05-21  89
6.5 2013-11-21  2014-02-26  97
6.6 2014-10-13  2014-11-15  33
6.7 2015-07-22  2015-09-05  45
6.8 2016-05-10  2016-07-28  79
6.9 2017-03-21  2017-04-05  15
6.102018-06-19  2018-07-03  14

7.1 2015-03-05  2015-10-11  220
7.2 2015-11-19  2016-02-19  92
7.3 2016-11-03  2016-12-21  48
7.4 2017-08-01  2018-03-21  232
7.5 2018-04-10  2018-10-30  203
7.6 2018-10-30  2019-01-28  90
7.7 2019-08-06  (didn't find release notes)
7.8 2020-03-31  2020-04-27  27

8.1 2019-11-05  2020-01-15  71
8.2 2020-04-28  2020-06-15  48

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


Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Lamar Owen

On 6/17/20 1:51 PM, Ulf Volmer wrote:

...
Just to make it sure: Did you try to disable firewalld?
With my experience with libvirt and vlan bridges on Fedora, libvirt may
include unwanted firewall rules which drops the traffic over the bridges.

I haven't done that yet, so I'll try that next.  Thanks for the idea.

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


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

2020-06-17 Thread Lamar Owen

On 6/17/20 3:32 PM, Phil Perry wrote:


On my home file server for example, which is not connected to the 
internet, what does it matter if the release is 1 month or 3 months 
out of date? I can install the server in the knowledge it's going to 
work, and be supported with updates for 10 years and I can largely 
forget about it. My el5 box ran for more than 10 years until the 
hardware eventually died. 
EL5... how modern...  from a production application server VM, not 
internet-connected:

[root@c6-2850 ~]# ssh root@10.1.x.y
root@10.1.x.y's password:
Last login: Tue Jan 28 19:53:32 2020
unknown terminal "xterm-256color"
unknown terminal "xterm-256color"
[root@localhost root]# cat /etc/centos-release
CentOS Linux Advanced Server release 2.1AS (Slurm)
[root@localhost root]#

This one has to be hard reset every day or two (virsh reset rhel2.1) 
since the bridge to the guest just dies randomly, and a reboot inside 
the guest hangs hard before finishing the reboot.  The hard reset has to 
manually load the ethernet kernel module after it's booted up so far; if 
the ethernet module loads too soon it will never connect haven't 
found the reason for that, either, just run a pinging script every 
fifteen minutes on the host to check for connectivity and 'virsh reset 
rhel2.1' when it fails.  The appserver is hard reboot resilient, and the 
software does a very specific task, and there's no budget for a 
rewrite.  At least I did upgrade it from Red Hat Linux 5.2 a couple of 
years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran 
almost continuously for 20 years).


Thanks, CentOS!

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


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

2020-06-17 Thread Noam Bernstein via CentOS
> On Jun 17, 2020, at 3:46 PM, Leon Fauster via CentOS  
> wrote:
> 
> The answer is not inherently in the distribution itself. Make your
> analysis about your needs an requirements and the choice is then yours.
> 
> One could argue that the gap between disclosure of one security issues
> and the update via RHEL subscription is to big. Then a contract with
> the upstream developer of the corresponding software component is a
> better choice then relying in RHEL, right?

Of course.   My only question is whether the observation that the gap for 
CentOS 8 is indeed larger than we have come to be used to for CentOS 7.  I'm 
certainly not, and I don't think anyone is, claiming that the CentOS teams owes 
us any particular response time.  I just want to know if the claim that it's 
systematically significantly longer for 8 than 7 is in fact (empirically) true.

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


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

2020-06-17 Thread Leon Fauster via CentOS

Am 17.06.20 um 21:37 schrieb Noam Bernstein via CentOS:

On Jun 17, 2020, at 3:32 PM, Phil Perry  wrote:

I get what you are saying, but what difference does it make if it has? What 
does it matter if the lag is 1 week, or 1 month, or more? The only reason it 
will matter to you is if you are trying to do something with CentOS that is 
time critical - e.g, publicly facing server that needs security updates, using 
CentOS on test servers to validate production releases for RHEL, etc. At which 
point you probably should be using RHEL if it is important to you, not CentOS, 
and it was a mistake to deploy CentOS in those roles in the first place.


And yet in practice many of us have found CentOS to be perfectly adequate for 
such applications in the past, up to and including CentOS 7.  If this is no 
longer true for CentOS 8, for whatever reason, it's useful to know.  I'm not 
saying RHEL doesn't have its place - just that perhaps the boundary in the 
range of applicability between it and CentOS has therefore also changed.




The answer is not inherently in the distribution itself. Make your
analysis about your needs an requirements and the choice is then yours.

One could argue that the gap between disclosure of one security issues
and the update via RHEL subscription is to big. Then a contract with
the upstream developer of the corresponding software component is a
better choice then relying in RHEL, right?

--
Leon


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


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

2020-06-17 Thread Noam Bernstein via CentOS
> On Jun 17, 2020, at 3:32 PM, Phil Perry  wrote:
> 
> I get what you are saying, but what difference does it make if it has? What 
> does it matter if the lag is 1 week, or 1 month, or more? The only reason it 
> will matter to you is if you are trying to do something with CentOS that is 
> time critical - e.g, publicly facing server that needs security updates, 
> using CentOS on test servers to validate production releases for RHEL, etc. 
> At which point you probably should be using RHEL if it is important to you, 
> not CentOS, and it was a mistake to deploy CentOS in those roles in the first 
> place.

And yet in practice many of us have found CentOS to be perfectly adequate for 
such applications in the past, up to and including CentOS 7.  If this is no 
longer true for CentOS 8, for whatever reason, it's useful to know.  I'm not 
saying RHEL doesn't have its place - just that perhaps the boundary in the 
range of applicability between it and CentOS has therefore also changed.

Noam

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


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

2020-06-17 Thread Phil Perry

On 17/06/2020 20:06, Noam Bernstein via CentOS wrote:

On Jun 17, 2020, at 3:02 PM, Phil Perry  wrote:

Nothing has changed in this regard for as long as I've been a CentOS user or 
been involved in the CentOS community.


This is the essence of the question, to me.  I agree that _in_principle_ 
nothing has changed, and I don't even see any disagreement with that in the 
list.  However, there is a separate question, and that is whether _in_practice_ 
the lag between RHEL and CentOS updates has increased with CentOS 8.  I don't 
know what the answer is, because I'm not paying attention since I'm far from 
adopting CentOS 8, but it's a legitimate (and in fact empirical) question.



I get what you are saying, but what difference does it make if it has? 
What does it matter if the lag is 1 week, or 1 month, or more? The only 
reason it will matter to you is if you are trying to do something with 
CentOS that is time critical - e.g, publicly facing server that needs 
security updates, using CentOS on test servers to validate production 
releases for RHEL, etc. At which point you probably should be using RHEL 
if it is important to you, not CentOS, and it was a mistake to deploy 
CentOS in those roles in the first place.


People need to hold their hands up and say, I took a gamble that CentOS 
would get updates out quick and I wouldn't get hacked in a week, and now 
updates are taking a lot longer my gamble is no longer paying off and I 
need to get myself a RHEL subscription or switch to Ubuntu or whatever 
other flavor you like the taste of. Coming here and complaining when 
(you) made a bet and lost doesn't achieve anything.


On my home file server for example, which is not connected to the 
internet, what does it matter if the release is 1 month or 3 months out 
of date? I can install the server in the knowledge it's going to work, 
and be supported with updates for 10 years and I can largely forget 
about it. My el5 box ran for more than 10 years until the hardware 
eventually died.


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


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

2020-06-17 Thread Noam Bernstein via CentOS
> On Jun 17, 2020, at 3:02 PM, Phil Perry  wrote:
> 
> Nothing has changed in this regard for as long as I've been a CentOS user or 
> been involved in the CentOS community.

This is the essence of the question, to me.  I agree that _in_principle_ 
nothing has changed, and I don't even see any disagreement with that in the 
list.  However, there is a separate question, and that is whether _in_practice_ 
the lag between RHEL and CentOS updates has increased with CentOS 8.  I don't 
know what the answer is, because I'm not paying attention since I'm far from 
adopting CentOS 8, but it's a legitimate (and in fact empirical) question.

Noam

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


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

2020-06-17 Thread Phil Perry

On 17/06/2020 18:38, Michael Kofler wrote:

Hi,

I am the author of said blog article.

FIRST: It was never my intention to criticize the CentOS
team. I appreciate the hard work you are doing. If my blog
text (which is in German langugage) gave a wrong impression,
I apologize.

SECOND: I LOVE CentOS. Otherwise it would not matter to
me. I use CentOS to teach Linux administration at
university, I promote CentOS in my books and I use it
personally on some servers.

THIRD: It is a fact that the update gaps for CentOS 8 are
currently too long for productive use. Basically, that's why
I now warn against using CentOS 8 on live systems.

---

One might argue, CentOS was never intended for productive
use. Perhaps I misunderstood this. And with me all
administrators of some million web servers running on
CentOS. Hm. Time to rethink?



As far as I'm aware that has always been the case. Johnny has never been 
slow in coming forward and saying if you need updates, or a service 
level agreement, or support then you should buy RHEL. That is what it is 
for. If not, then use CentOS for free. But don't use CentOS for free on 
production servers and then shout or act surprised when you don't have 
updates on a timescale you consider appropriate.


Nothing has changed in this regard for as long as I've been a CentOS 
user or been involved in the CentOS community. If you are now having to 
rethink your approach then you probably either haven't given it 
sufficient thought in the first place or you originally came to the 
wrong conclusion.


This is a non-issue. Nothing has changed. Things were exactly the same 
with CentOS 4, CentOS 5, CentOS 6, CentOS 7, and by it's very nature it 
will be the same in CentOS 9... The simple matter is it takes time to 
rebuild a complete OS and there will always be a lag. Either that is 
acceptable to you and you use it, or you purchase a RHEL license for 
your publicly facing infrastructure. The only issue here is people's 
unrealistic expectations, and to be fair the CentOS Project can hardly 
be accused of falsely raising peoples expectations having consistently 
stated it will be ready when it's done for at least the last 15 years.


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


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

2020-06-17 Thread Greg Bailey

On 6/17/20 10:38 AM, Michael Kofler wrote:

Hi,

I am the author of said blog article.

FIRST: It was never my intention to criticize the CentOS
team. I appreciate the hard work you are doing. If my blog
text (which is in German langugage) gave a wrong impression,
I apologize.

SECOND: I LOVE CentOS. Otherwise it would not matter to
me. I use CentOS to teach Linux administration at
university, I promote CentOS in my books and I use it
personally on some servers.

[snip]

I truly believe, Red Hat has the means to make live for the
CentOS team easier. Either by simply increasing the team,
the infrastructure to build packages faster, whatever. Or by
making the clone process easier.


IMHO this is the crux of the problem.  I feel for the CentOS team every 
time they get beat up by users asking why things take so long, and 
they're forced to explain over and over again how they have to 
re-engineer processes that the RHEL team has already engineered.


In theory, both RHEL and CentOS start from the same sources -- 
git.centos.org -- which is a great thing.  But, RHEL obviously has 
package build infrastructure, release composition, release management, 
and QA (among other) systems that are requisite steps to building and 
releasing, say, RHEL 8.2.  It makes me sad that the CentOS devs (most of 
whom are Red Hat employees, as I understand it) are forced to 
re-implement what the RHEL team has already implemented, without any 
advice, guidance, or tooling from the RHEL engineering team.  (i.e. the 
CentOS team has to discover that "these packages have to be built in 
this order, or with this modified build environment", etc. on their own)


It's not clear why 2 different groups at the same company doing the same 
thing can't combine resources.  Why can't one group at Red Hat produce 
binary RPMs from git.centos.org that find their way into both a RHEL 
compose and a CentOS compose?  And would the composes then be so 
different if the only thing that varied was the package set and branding?


Perhaps the duplication of engineering effort stems from the history of 
CentOS being a separate organization that's still undergoing integration 
with other Red Hat teams.  And I'd love to be enlightened if any or all 
of my assumptions above are wrong; my perspective is just that of a 
long-time Red Hat Linux, RHEL, Fedora, and CentOS user (since 1998 or so).


-Greg

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


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

2020-06-17 Thread Stephen John Smoogen
On Wed, 17 Jun 2020 at 13:11, Alessandro Baggi
 wrote:
>
> Hi Johnny,
> thank you for your and all centos team works.
>
> Many of us know how much work is needed for building new releases and
> maintaining C6 and C7, plus CentOS Stream and modules (Appstream). This is
> a huge work for a small team. Again thank you.
>
> For me OL is not an alternative.
>
> As reported in my previous message I'm not worried about how much time is
> required to build the new (major/minor) release, it will be ready when it
> will be. My major concern is about the "security update blackout" that take
> long as the build process.
>
> I would ask to you:
>
> 1. Why all security fix are stopped when a new release building process is
> started? There is a way or possibility to run the two process in parallel?
>

Most of the security fixes after the minor release are based off being
built with the code from that minor release. Sometimes the code may
even not compile without the rest of the packages involved. Deciding
which packages can and can not be affected by the minor release can be
a full time job.


> 2. When a build process is started and a security fix released there is a
> way for your team to "suspend" the building process, release security
> updates (for 6/7.x or 8.1) and resume the builing process? I think that
> many users (included me) will have less disappointment having security
> updates instead of receiving a  "signal lost" when building process takes
> its way.
>

It would require a second build system which built against the older
set of packages, it would also require someone to edit those packages
so they can be replaced by later released ones after the main release
is done. It also requires work on making sure conflicts and broken
packages are dealt with.

A lot of this is sausage making.. We all want the end product of a
cooked sausage.. but there is a lot of messy work which adding more
people to doesn't help unless you can add a lot of other things which
are supposed to appear ex-nihilo and fully formed.  You can have a lot
of people volunteer to stand around but there are only so many places
to push meat on one side, turn cranks in the middle and one tube which
the mess gets stuffed into.  Every extra thing requires months and
months of work and preparation to set up while still trying to make
the other items. However the only time people seem to get bothered
enough to even try to set up their own build system and find out how
much mess it is.. is after the current release is delayed.


> Thank you for your time.
>
> Alessandro.
>
> Il Mer 17 Giu 2020, 16:15 Johnny Hughes  ha scritto:
>
> > On 6/17/20 8:06 AM, Simon Matter via CentOS wrote:
> > >> Hi,
> > >>
> > >> I just read this blog article from austrian Linux expert Michael Kofler.
> > >> For
> > >> those among you who don't know the guy, he's my home country's number
> > one
> > >> Linux
> > >> expert (known as "der Kofler") and most notably the author of a series
> > of
> > >> excellent books about Linux over the last 25 years.
> > >>
> > >> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
> > >>
> > >> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it
> > on
> > >> all
> > >> my servers, and yes, I know the difference between upstream RHEL and
> > >> CentOS.
> > >>
> > >> The article is in german, but the statistics graph is eloquent enough
> > for
> > >> the
> > >> non-german-speaking users. It focuses on updates for CentOS 8, and more
> > >> exactly
> > >> the extended periods of time where there have been no updates available.
> > >>
> > >> The author's theory ("unspoken truth"): while it's a positive thing that
> > >> Red
> > >> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
> > >> enough
> > >> so that the product is "starved to death" by Red Hat (e. g. IBM) to
> > >> encourage
> > >> users to move to RHEL.
> > >
> > > I think if Red Hat really wanted to improve the situation, they could
> > > integrate the building of CentOS into the EL build system to produce both
> > > versions, RHEL and CentOS, at the same time. In the end 99% of the bits
> > > are the same anyway. If the delay of CentOS builds is really wanted by
> > Red
> > > Hat, it would be nice of them to speak it out - and change the name to
> > > COS, because the ent is not true anymore :-)
> > >
> > > Up to now I thought the big delay with 8 is more an accident than wanted.
> > > Would be nice to hear what Red Hat says about it. Maybe the problem is
> > not
> > > known well enough in the Red Hat universe.
> > >
> >
> >
> > No one is trynig to make anything slower.
> >
> > And CentOS Stream 'is' going to be how RHEL is developed in the future.
> >  So, all this is happening.
> >
> > But modules introduced in RHEL 8 requires a who new build system (as
> > koji set up) and a whole new module build back end (MBS).
> >
> > If you would rather use Oracle for your open source needs .. well, that
> > is a decision you can make 

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

2020-06-17 Thread Valeri Galtsev



On 2020-06-17 12:38, Michael Kofler wrote:

Hi,

I am the author of said blog article.

FIRST: It was never my intention to criticize the CentOS
team. I appreciate the hard work you are doing. If my blog
text (which is in German langugage) gave a wrong impression,
I apologize.

SECOND: I LOVE CentOS. Otherwise it would not matter to
me. I use CentOS to teach Linux administration at
university, I promote CentOS in my books and I use it
personally on some servers.

THIRD: It is a fact that the update gaps for CentOS 8 are
currently too long for productive use. Basically, that's why
I now warn against using CentOS 8 on live systems.

---

One might argue, CentOS was never intended for productive
use. Perhaps I misunderstood this. And with me all
administrators of some million web servers running on
CentOS. Hm. Time to rethink?


Some of us fled servers from Linux (of whichever flavor) to one of BSD 
descendants. That has more to do with frequent reboots due to glibc or 
kernel security updates or other unpleasantnesses of Linux. Many of 
those who did this, still use/support Linux on workstations and laptops.




The way I see it, there is a need for free Linux systems. No
support, sure, but updates. In the past (and for CentOS 7,
still), I considered CentOS as 'good enough' for many
purposes. Not for the Bank of England, they can affort
whatever they like. But for a school. For a small company
needing a plain web and mail server. Etc.

The CentOS webpage says: 'CentOS Linux ... suits a wide
variety of deployments.'  Currently, I really fail to see a
wide range of possible deployments.

Sure, there are other options. Out of my point of view,
Ubuntu LTS is one. Debian is. Oracle Linux (free without
support) is, too. I am not entirely in love with this
company -- but if I had the need to deploy a RHEL 8
compatible system right now, and no budget to pay for RHEL,
I would prefer it to CentOS. Sorry about this.

---

I truly believe, Red Hat has the means to make live for the
CentOS team easier. Either by simply increasing the team,
the infrastructure to build packages faster, whatever. Or by
making the clone process easier.


RedHat has not and never had any obligation to financially or otherwise 
support its clones (released free for use). To think they do is 
delusional. And CentOS project I'm sure never expected that (I am not 
part of CentOS project, though I greatly appreciate what they do).


Valeri



My guess is, they don't want. And this is OK -- who am I be
to advice a multi billion dollar company? The question is,
what does this mean for the future of CentOS? Is CentOS to
become an open development platform for Red Hat, but no
more?

These are my thoughts.

Best wishes,

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


--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

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


Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Ulf Volmer
On 17.06.20 17:36, Lamar Owen wrote:
> On 6/17/20 11:04 AM, Lamar Owen wrote:
>> ...
>> It shows as being defined to 1.  I'm going to try adding to
>> sysctl.conf and see if that makes any difference, though.
> No difference.  What is aggravating, though, is virtually every howto on
> bridging out there refers to the deprecated brctl utility (from the
> bridge-utils package), and C8 no longer includes that package (even
> though it's in current Fedora 32!).  I know, I know, the new way is
> using the 'bridge' command or 'ip --br'  So I grabbed the F32 source
> RPM and rebuilt on my C8 laptop and uploaded to the host:
> [root@c8-kvm-pe1950-1 ~]# brctl show
> bridge name      bridge id            STP enabled    interfaces
> bridge101        8000.001ec9fcde9d    yes              team0.101
>                                                      vnet0
> bridge302        8000.001ec9fcde9d    yes              team0.302
> bridge68         8000.001ec9fcde9d    yes              team0.68
> 
> 
> Still no dice.  Next step is tcpdump.

Just to make it sure: Did you try to disable firewalld?
With my experience with libvirt and vlan bridges on Fedora, libvirt may
include unwanted firewall rules which drops the traffic over the bridges.

Best regards
Ulf

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


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

2020-06-17 Thread Michael Kofler

Hi,

I am the author of said blog article.

FIRST: It was never my intention to criticize the CentOS
team. I appreciate the hard work you are doing. If my blog
text (which is in German langugage) gave a wrong impression,
I apologize.

SECOND: I LOVE CentOS. Otherwise it would not matter to
me. I use CentOS to teach Linux administration at
university, I promote CentOS in my books and I use it
personally on some servers.

THIRD: It is a fact that the update gaps for CentOS 8 are
currently too long for productive use. Basically, that's why
I now warn against using CentOS 8 on live systems.

---

One might argue, CentOS was never intended for productive
use. Perhaps I misunderstood this. And with me all
administrators of some million web servers running on
CentOS. Hm. Time to rethink?

The way I see it, there is a need for free Linux systems. No
support, sure, but updates. In the past (and for CentOS 7,
still), I considered CentOS as 'good enough' for many
purposes. Not for the Bank of England, they can affort
whatever they like. But for a school. For a small company
needing a plain web and mail server. Etc.

The CentOS webpage says: 'CentOS Linux ... suits a wide
variety of deployments.'  Currently, I really fail to see a
wide range of possible deployments.

Sure, there are other options. Out of my point of view,
Ubuntu LTS is one. Debian is. Oracle Linux (free without
support) is, too. I am not entirely in love with this
company -- but if I had the need to deploy a RHEL 8
compatible system right now, and no budget to pay for RHEL,
I would prefer it to CentOS. Sorry about this.

---

I truly believe, Red Hat has the means to make live for the
CentOS team easier. Either by simply increasing the team,
the infrastructure to build packages faster, whatever. Or by
making the clone process easier.

My guess is, they don't want. And this is OK -- who am I be
to advice a multi billion dollar company? The question is,
what does this mean for the future of CentOS? Is CentOS to
become an open development platform for Red Hat, but no
more?

These are my thoughts.

Best wishes,

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


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

2020-06-17 Thread Chris Adams
Once upon a time, Alessandro Baggi  said:
> As reported in my previous message I'm not worried about how much time is
> required to build the new (major/minor) release, it will be ready when it
> will be. My major concern is about the "security update blackout" that take
> long as the build process.

I'm not involved in building CentOS, but the issue is that it is a
rebuild of upstream.  When RHEL 8.2 is released, there are no more
upstream updates released for RHEL 8.1; they are all on top of the RHEL
8.2 release.  So, until the time that CentOS can rebuild RHEL 8.2 and
make a new CentOS release, there can't be any updates for CentOS 8.1.

RHEL 8 introduced modules, which complicated the build system and
required new tooling, so CentOS has had a bunch of "under the hood" work
to catch up.  Hopefully, once that's ironed out, the gap between a RHEL
8.x release and the corresponding CentOS release will drop.

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


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

2020-06-17 Thread Alessandro Baggi
Hi Johnny,
thank you for your and all centos team works.

Many of us know how much work is needed for building new releases and
maintaining C6 and C7, plus CentOS Stream and modules (Appstream). This is
a huge work for a small team. Again thank you.

For me OL is not an alternative.

As reported in my previous message I'm not worried about how much time is
required to build the new (major/minor) release, it will be ready when it
will be. My major concern is about the "security update blackout" that take
long as the build process.

I would ask to you:

1. Why all security fix are stopped when a new release building process is
started? There is a way or possibility to run the two process in parallel?

2. When a build process is started and a security fix released there is a
way for your team to "suspend" the building process, release security
updates (for 6/7.x or 8.1) and resume the builing process? I think that
many users (included me) will have less disappointment having security
updates instead of receiving a  "signal lost" when building process takes
its way.

Thank you for your time.

Alessandro.

Il Mer 17 Giu 2020, 16:15 Johnny Hughes  ha scritto:

> On 6/17/20 8:06 AM, Simon Matter via CentOS wrote:
> >> Hi,
> >>
> >> I just read this blog article from austrian Linux expert Michael Kofler.
> >> For
> >> those among you who don't know the guy, he's my home country's number
> one
> >> Linux
> >> expert (known as "der Kofler") and most notably the author of a series
> of
> >> excellent books about Linux over the last 25 years.
> >>
> >> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
> >>
> >> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it
> on
> >> all
> >> my servers, and yes, I know the difference between upstream RHEL and
> >> CentOS.
> >>
> >> The article is in german, but the statistics graph is eloquent enough
> for
> >> the
> >> non-german-speaking users. It focuses on updates for CentOS 8, and more
> >> exactly
> >> the extended periods of time where there have been no updates available.
> >>
> >> The author's theory ("unspoken truth"): while it's a positive thing that
> >> Red
> >> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
> >> enough
> >> so that the product is "starved to death" by Red Hat (e. g. IBM) to
> >> encourage
> >> users to move to RHEL.
> >
> > I think if Red Hat really wanted to improve the situation, they could
> > integrate the building of CentOS into the EL build system to produce both
> > versions, RHEL and CentOS, at the same time. In the end 99% of the bits
> > are the same anyway. If the delay of CentOS builds is really wanted by
> Red
> > Hat, it would be nice of them to speak it out - and change the name to
> > COS, because the ent is not true anymore :-)
> >
> > Up to now I thought the big delay with 8 is more an accident than wanted.
> > Would be nice to hear what Red Hat says about it. Maybe the problem is
> not
> > known well enough in the Red Hat universe.
> >
>
>
> No one is trynig to make anything slower.
>
> And CentOS Stream 'is' going to be how RHEL is developed in the future.
>  So, all this is happening.
>
> But modules introduced in RHEL 8 requires a who new build system (as
> koji set up) and a whole new module build back end (MBS).
>
> If you would rather use Oracle for your open source needs .. well, that
> is a decision you can make and be responsible for.
>
> If you would instead have feedback directly into the RHEL development
> process as a community .. then CentOS is where you want to be.
>
> This stuff is open source, and you are all gown ups who can make your
> own decisions.
>
> I can assure you .. I am working my butt off everyday to make CentOS
> Linux the best it can be.  If you want to compare what the CentOS team
> (a small team) can do compared to Oracle (a tmulti billin dollar
> corporation who bought Sun Microsystems .. took over Java and Open
> Office, etc)  .. well, we can not provide the resources they can provide.
>
> But Red hat heard the community .. that the community and Red Hat
> customers want more direct input into RHEL development.  And Red Hat is
> taking action to open up RHEL development in CentOS Stream.
>
> You get to decide who you trust.
>
> Thanks,
> Johnny hUghes
>
>
>
> ___
> 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.2 corrupt pxeboot kernel

2020-06-17 Thread Jack Bailey via CentOS

On 2020-06-17 08:46, isdtor wrote:

Attempting to PXE boot from the BaseOS/x86_64/kickstart/images/pxeboot/ files 
results in repeating messages

Invalid or corrupt kernel image

eventually changing to

Could not find kernel image: centos8.2.x86_64/vmlinuz

I downloaded the files again, from a different mirror, and they are all the 
same. Wiped the files and recreated /tftpboot/linux-install/centos8.2.x86_64/. 
No dice.

First mirror

89251241a484010b98280ce00b3a3763  os/images/pxeboot/initrd.img
9261bb24add6bb4ff9ef6aaf348aaf35  os/images/pxeboot/vmlinuz

Second mirror

89251241a484010b98280ce00b3a3763  os/images/pxeboot/initrd.img
89251241a484010b98280ce00b3a3763  kickstart/images/pxeboot/initrd.img

9261bb24add6bb4ff9ef6aaf348aaf35  os/images/pxeboot/vmlinuz
9261bb24add6bb4ff9ef6aaf348aaf35  kickstart/images/pxeboot/vmlinuz



pxe is working for me in this test virtualbox build.

$ md5sum initrd.img vmlinuz
89251241a484010b98280ce00b3a3763  initrd.img
9261bb24add6bb4ff9ef6aaf348aaf35  vmlinuz

( yum updated )

[centos@localhost ~]$ uname -a
Linux localhost.localdomain 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 
10 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


[centos@localhost ~]$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

Best regards,
Jack

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


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

2020-06-17 Thread Fred Smith
On Wed, Jun 17, 2020 at 12:09:07PM -0400, Lamar Owen wrote:
> On 6/17/20 10:19 AM, Leon Fauster via CentOS wrote:
> >...
> >I wonder about the authors conclusion; the fact that RHEL is the choice
> >for critical applications (what ever critical is) is known since
> >the early days. This applies randomly to C5.11, C4.9 or C8.2.2004.
> >
> >So - cold soup get cooked again :-)
> 
> 
> Indeed.  The author's conclusion has been the case since White Box
> Enterprise Linux was a thing.  Anyone and everyone can get the
> sources from git.centos.org as soon as they are released and build
> the stuff themselves if they think it can be done faster; that's how
> WBEL got started, as a one-user project that just happened to be
> publicly released.  Building from source has never really been any
> easier; the lack of .src.rpms is not an impediment to just getting
> something built.  But the CentOS value-add is that those rebuilt
> sources have been tested for binary compatibility and are from a
> trusted source.  A one-person project like WBEL would have a much
> more difficult time today, with modularity especially. Build times
> for these packages is not zero.

And there was also Tao Linux, which I was using back in the day.
another one-person project, which that one person did a good job
with, but when time came to change jobs he had to let the project
go. He had the foresight and grace to work with Johnny Hughes to
define a way to transition to CentOS, which worked fine, so here
I am still in the CentOS camp.

And my thanks to that original developer (whose name I cannot
dredge out of my back-brain right now), to Johnny, and all the
other folks who make CentOS great!

Fred

-- 
---
Under no circumstances will I ever purchase anything offered to me as
the result of an unsolicited e-mail message. Nor will I forward chain
letters, petitions, mass mailings, or virus warnings to large numbers
of others. This is my contribution to the survival of the online
community.
 --Roger Ebert, December, 1996
- The Boulder Pledge -
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Amd es1000

2020-06-17 Thread Gianluca Cecchi
On Wed, Jun 17, 2020 at 6:13 PM paride desimone  wrote:

> Uhm, X dont't start :-(
>
>
I overlooked your post... my suggestions was for installation phase, but
you did install apparently.. did you install in graphic mode or by other
text based means (kickstart, pxe, ecc)? Or perhaps you installed xorg
related packages afterward?
Can you post your logs and the related errors?
Do you have gdm login at boot or not at all?

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


Re: [CentOS] Amd es1000

2020-06-17 Thread paride desimone
Uhm, X dont't start :-(

Il mer 17 giu 2020, 15:34 Gianluca Cecchi  ha
scritto:

> On Wed, Jun 17, 2020 at 1:56 PM paride desimone  wrote:
>
> > Hi, i have a proliant dl380 g5, with an amd as1000. I try to install
> > centos8 with gui, but when try to start the new installed system, the
> > xserver don't start. There is a throuble with the amd es1000 driver. This
> > grafic card, seems not supported more from amd.
> > I need a minimalistic gui for study for rhcsa certification.
> > The gui is mandatory for the exam.
> >
> > Any help?
> >
> > Paride
> >
> >
> for a different system, but with low end graphic card too, I had success
> going to graphical target during installation modifying the initial kernel
> line removing the "quiet" word and adding
>
> inst.xdriver=fbdev inst.resolution=1024x768
>
> PS: 1024x768 is the lowest resolution usable.
>
> HIH,
> Gianluca
> ___
> 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] Compile gnutls yo install samba-4.12.3

2020-06-17 Thread isdtor
Rommel Rodriguez Toirac writes:
> Hello all;
>  Has anyone installed samba4 from sources (samba-4.12.3.tar.gz) on CentOS 7?
>  I explain the problem: to install samba-4.12.3 you need to install a version 
> equal to or greater than 3.4.7 of gnutls; this (gnutls) depends on nettle and 
> gmp. 
>  I am trying to install gnutls-3.6.14; I already have gmp (gmp-6.2.0) and 
> nettle (nettle-3.6) installed (compiled from sources), but gnutls doesn't 
> want to install, it tells me "Libnettle 3.4.1 was not found" when I run the 
> ./configure
> 
>  Nettle is installed in /usr/local/include/nettle (all .h) and in 
> /usr/local/lib64/libnettle.s0.8.0
> 
>  I created a symbolic link for /usr/lib64 from 
> /usr/local/lib64/libnettle.s0.8.0 as libnettle.so and libnettle.so.8; I ran 
> the gnutls ./configure again, but it keeps saying it can't find libnettle 
> 3.4.1
>  
>  How can I do? 
>  Has anyone got CentOS 7 and samba-4.12.3 installed and fixed this situation?

I've just been through a very similar exercise on CentOS 6, not for samba, but 
involving gnutls. My respect for those who manage to build gnutls at all has 
grown considerably. The code below works for my purposes.

In the p11-kit section, consider that your system does have systemd. In the 
libtasn1 section, I'm applying a patch that changes the perlesque C99 for loops 
into something gcc 4.4.7 can digest. I don't know if gcc 4.8.5 knows C99 
(probably not). If you know a little C you can easily figure out what to do if 
needed. I didn't investigate building gnutls without external libtasn1 etc.

Now, linking your code against this version of gnutls is also a fun exercise. 
You need to configure against the same --prefix, for starters. You may also 
require the same PKG_CONFIG_PATH= stanza as below for gnutls. In your 
Makefiles, you may need to change anything "-lgnutls" to "-lgnutls -lgmp 
-ltasn1".


# keep it out of system directories!
prefix=/foo/bar

gmp_version=6.2.0
nettle_version=3.6
libtasn1_version=4.16.0
libffi_version=3.3
p11_kit_version=0.23.20
gnutls_version=3.6.14

tar xf gmp-${gmp_version}.tar.xz
pushd gmp-${gmp_version} >/dev/null
./configure --prefix=${prefix}
make install clean
popd >/dev/null
rm -rf gmp-${gmp_version}

tar xf nettle-${nettle_version}.tar.gz
pushd nettle-${nettle_version} >/dev/null
./configure --prefix=${prefix}   --with-include-path=${prefix}/include 
--with-lib-path=${prefix}/lib
make install clean
popd >/dev/null
rm -rf nettle-${nettle_version}

tar xf libtasn1-${libtasn1_version}.tar.gz
pushd libtasn1-${libtasn1_version} >/dev/null
#optional?# patch -p1 < ../libtasn1-4.16.0-c99-for-loop.patch
./configure --prefix=${prefix}
make install clean
popd >/dev/null
rm -rf libtasn1-${libtasn1_version}

tar xf libffi-${libffi_version}.tar.gz
pushd libffi-${libffi_version} >/dev/null
LIBFFI_CFLAGS="-I${prefix}/include" LIBFFI_LIBS="-L${prefix}/lib64" \
  ./configure --prefix=${prefix}
make install clean
popd >/dev/null
rm -rf libffi-${libffi_version}

tar xf p11-kit-${p11_kit_version}.tar.xz
pushd p11-kit-${p11_kit_version} >/dev/null
PKG_CONFIG_PATH=${prefix}/lib/pkgconfig \
  ./configure --prefix=${prefix} --without-systemd --disable-nls
make install clean
popd >/dev/null
rm -rf p11-kit-${p11_kit_version}

tar xf gnutls-${gnutls_version}.tar.xz
pushd gnutls-${gnutls_version} >/dev/null
PKG_CONFIG_PATH=${prefix}/lib64/pkgconfig:${prefix}/lib/pkgconfig: \
  GMP_CFLAGS="-I ${prefix}/include" \
  GMP_LIBS="-L${prefix}/lib -lm" \
  LIBTASN1_CFLAGS="-I${prefix}/include" LIBTASN1_LIBS="-L${prefix}/lib" \
  ./configure --prefix=${prefix} --with-included-unistring 
--disable-hardware-acceleration --disable-doc --disable-gtk-doc 
--disable-gtk-doc-html --disable-nls
sed -i 's%^#am__append_13.*%am__append_13 = -I${prefix}/include%' src/Makefile
for d in doc/examples src tests ; do
  sed -i 's%^LIBS = .*%LIBS = -L${prefix}/lib -lgmp -ltasn1%' ${d}/Makefile
done
make install clean
popd >/dev/null
rm -rf gnutls-${gnutls_version}

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


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

2020-06-17 Thread Lamar Owen

On 6/17/20 10:19 AM, Leon Fauster via CentOS wrote:

...
I wonder about the authors conclusion; the fact that RHEL is the choice
for critical applications (what ever critical is) is known since the 
early days. This applies randomly to C5.11, C4.9 or C8.2.2004.


So - cold soup get cooked again :-) 



Indeed.  The author's conclusion has been the case since White Box 
Enterprise Linux was a thing.  Anyone and everyone can get the sources 
from git.centos.org as soon as they are released and build the stuff 
themselves if they think it can be done faster; that's how WBEL got 
started, as a one-user project that just happened to be publicly 
released.  Building from source has never really been any easier; the 
lack of .src.rpms is not an impediment to just getting something built.  
But the CentOS value-add is that those rebuilt sources have been tested 
for binary compatibility and are from a trusted source.  A one-person 
project like WBEL would have a much more difficult time today, with 
modularity especially. Build times for these packages is not zero.




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


[CentOS] CentOS 8.2 corrupt pxeboot kernel

2020-06-17 Thread isdtor
Attempting to PXE boot from the BaseOS/x86_64/kickstart/images/pxeboot/ files 
results in repeating messages

Invalid or corrupt kernel image

eventually changing to

Could not find kernel image: centos8.2.x86_64/vmlinuz

I downloaded the files again, from a different mirror, and they are all the 
same. Wiped the files and recreated /tftpboot/linux-install/centos8.2.x86_64/. 
No dice.

First mirror

89251241a484010b98280ce00b3a3763  os/images/pxeboot/initrd.img
9261bb24add6bb4ff9ef6aaf348aaf35  os/images/pxeboot/vmlinuz

Second mirror

89251241a484010b98280ce00b3a3763  os/images/pxeboot/initrd.img
89251241a484010b98280ce00b3a3763  kickstart/images/pxeboot/initrd.img

9261bb24add6bb4ff9ef6aaf348aaf35  os/images/pxeboot/vmlinuz
9261bb24add6bb4ff9ef6aaf348aaf35  kickstart/images/pxeboot/vmlinuz

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


[CentOS] Compile gnutls yo install samba-4.12.3

2020-06-17 Thread Rommel Rodriguez Toirac
Hello all;
 Has anyone installed samba4 from sources (samba-4.12.3.tar.gz) on CentOS 7?
 I explain the problem: to install samba-4.12.3 you need to install a version 
equal to or greater than 3.4.7 of gnutls; this (gnutls) depends on nettle and 
gmp. 
 I am trying to install gnutls-3.6.14; I already have gmp (gmp-6.2.0) and 
nettle (nettle-3.6) installed (compiled from sources), but gnutls doesn't want 
to install, it tells me "Libnettle 3.4.1 was not found" when I run the 
./configure

 Nettle is installed in /usr/local/include/nettle (all .h) and in 
/usr/local/lib64/libnettle.s0.8.0

 I created a symbolic link for /usr/lib64 from 
/usr/local/lib64/libnettle.s0.8.0 as libnettle.so and libnettle.so.8; I ran the 
gnutls ./configure again, but it keeps saying it can't find libnettle 3.4.1
 
 How can I do? 
 Has anyone got CentOS 7 and samba-4.12.3 installed and fixed this situation?
-- 
Rommel Rodriguez Toirac
romme...@nauta.cu
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


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

2020-06-17 Thread Valeri Galtsev


> On Jun 17, 2020, at 9:10 AM, Alessandro Baggi  
> wrote:
> 
> 
> Il 17/06/20 15:42, Scott Robbins ha scritto:
>> On Wed, Jun 17, 2020 at 02:23:36PM +0100, Pete Biggs wrote:
>>> 
 About Oracle as alternative. Oracle Linux is not an alternative to
 CentOS but for RHEL and if I will force to pay for enteprise system
 currently I will pay RHEL, not OL. Over this, OL is not the only
 enterprise distro that a "user" could choose. If support is needed there
 are SUSE (SLES) and Ubuntu. For who that don't need support there are
 Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know
 that slackware,FreeBSD are in that list), so many alternatives are in 
 place.
>>> 
>>> I think it's particularly disappointing *if* this is a "policy" from RH
>>> since the other major RHEL clone, Scientific Linux, has not produced an
>>> EL8 offering in favour of using CentOS.
>> Keep in mind that as soon as Scientific Linux started taking off, IIRC,
>> because CentOS was late with a release, RH quickly hired its main
>> developer.  I don't think we can really expect RH to act differently than
>> most corporations.
> 
> Yes but today Scientific Linux is out of games and CERN made CentOS CERN 
> based on C8 so there is no more a valid competitor for this target (in the RH 
> family based distro)
> 

“Scientific” linux, with all due respect to one of US national laboratories 
situated nearby that fathered it, was never viable from the long term use 
standpoint system in my book.

I got experimental proof about 5 or 6 years ago when “Scientific” linux (no, 
I’m not misplacing the second quote mark ;-) didn’t release updates for some 6 
Months at least. I am more unimpressed by CERN’s nearsightness, than I am 
impressed by my own long term predictive power. The thruth is: “Scientific” 
linux is the creature of small team, situated in one place, and those who put 
it together have primamry dedication to their job place, NOT the the 
“scientific” linux project and its existense. And I am not mentioning what I 
was mentioning to my researchers when they asked to install “scientific” linux, 
and I was giving them a list of arguments why they will be better off with 
CentOS - in addition to the above, CentOS is much reacher without extra 
repositories (which when there is large enogh number tend to create mess for 
you).

Just my 2 cents.

Valeri

> 
> CentOS at the current status (third 8 release) is not suitable for production 
> with the current issues and we are forced to buy rhel license (and every 
> needed extension).
> 
> I would to know what think all ISPs that offer centos 8 on their VPS, 
> Dedicated Server, Shared Hosting and how they handle this problem (probably 
> they don't because the choice is on the customer but maybe...)
> 
> As you said, probably nothing will change for the corporation "limit" concept 
> but at this point, probably, many users will migrate to another platform with 
> less limitation.
> ___
> 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] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Lamar Owen

On 6/17/20 11:04 AM, Lamar Owen wrote:

...
It shows as being defined to 1.  I'm going to try adding to 
sysctl.conf and see if that makes any difference, though.
No difference.  What is aggravating, though, is virtually every howto on 
bridging out there refers to the deprecated brctl utility (from the 
bridge-utils package), and C8 no longer includes that package (even 
though it's in current Fedora 32!).  I know, I know, the new way is 
using the 'bridge' command or 'ip --br'  So I grabbed the F32 source 
RPM and rebuilt on my C8 laptop and uploaded to the host:

[root@c8-kvm-pe1950-1 ~]# brctl show
bridge name      bridge id            STP enabled    interfaces
bridge101        8000.001ec9fcde9d    yes              team0.101
                                                     vnet0
bridge302        8000.001ec9fcde9d    yes              team0.302
bridge68         8000.001ec9fcde9d    yes              team0.68


Still no dice.  Next step is tcpdump.

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


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

2020-06-17 Thread Valeri Galtsev


> On Jun 17, 2020, at 9:15 AM, Johnny Hughes  wrote:
> 
> On 6/17/20 8:06 AM, Simon Matter via CentOS wrote:
>>> Hi,
>>> 
>>> I just read this blog article from austrian Linux expert Michael Kofler.
>>> For
>>> those among you who don't know the guy, he's my home country's number one
>>> Linux
>>> expert (known as "der Kofler") and most notably the author of a series of
>>> excellent books about Linux over the last 25 years.
>>> 
>>> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
>>> 
>>> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on
>>> all
>>> my servers, and yes, I know the difference between upstream RHEL and
>>> CentOS.
>>> 
>>> The article is in german, but the statistics graph is eloquent enough for
>>> the
>>> non-german-speaking users. It focuses on updates for CentOS 8, and more
>>> exactly
>>> the extended periods of time where there have been no updates available.
>>> 
>>> The author's theory ("unspoken truth"): while it's a positive thing that
>>> Red
>>> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
>>> enough
>>> so that the product is "starved to death" by Red Hat (e. g. IBM) to
>>> encourage
>>> users to move to RHEL.
>> 
>> I think if Red Hat really wanted to improve the situation, they could
>> integrate the building of CentOS into the EL build system to produce both
>> versions, RHEL and CentOS, at the same time. In the end 99% of the bits
>> are the same anyway. If the delay of CentOS builds is really wanted by Red
>> Hat, it would be nice of them to speak it out - and change the name to
>> COS, because the ent is not true anymore :-)
>> 
>> Up to now I thought the big delay with 8 is more an accident than wanted.
>> Would be nice to hear what Red Hat says about it. Maybe the problem is not
>> known well enough in the Red Hat universe.
>> 
> 
> 
> No one is trynig to make anything slower.
> 
> And CentOS Stream 'is' going to be how RHEL is developed in the future.
> So, all this is happening.
> 
> But modules introduced in RHEL 8 requires a who new build system (as
> koji set up) and a whole new module build back end (MBS).
> 
> If you would rather use Oracle for your open source needs .. well, that
> is a decision you can make and be responsible for.
> 
> If you would instead have feedback directly into the RHEL development
> process as a community .. then CentOS is where you want to be.
> 
> This stuff is open source, and you are all gown ups who can make your
> own decisions.
> 
> I can assure you .. I am working my butt off everyday to make CentOS
> Linux the best it can be.  If you want to compare what the CentOS team
> (a small team) can do compared to Oracle (a tmulti billin dollar
> corporation who bought Sun Microsystems .. took over Java and Open
> Office, etc)  .. well, we can not provide the resources they can provide.
> 
> But Red hat heard the community .. that the community and Red Hat
> customers want more direct input into RHEL development.  And Red Hat is
> taking action to open up RHEL development in CentOS Stream.
> 
> You get to decide who you trust.
> 

Thank you, Johnny!

I was going to reply to original post that: Nobody ever promised to pay CentOS 
team to do what they do. That was my understanding always.

Changes in the OS, new components (do not mean systemd explicitly), and how new 
release is built may or may not be part of longer/bigger plan of RHEL owner.

Without regard to the above, RedHat always was following meticulously the 
letter of GNU license. And the reputation IBM has (in my book), does not raise 
red flag after they bought out RedHat. Time will show, but I’m sure with 
acquisition of RedHat by IBM “nothing changed” for open source community in 
general, and CentOS existence in particular. Not dramatically at least. And 
someone mentioned Oracle, and I agree, Oracle has quite opposite reputation in 
my boot to that of IBM.

Thanks, Johnny, very much again!!

Note: I’m just humble outsider, not CentOS project member.

Valeri

> Thanks,
> Johnny hUghes
> 
> 
> 
> ___
> 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] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Lamar Owen

On 6/17/20 9:59 AM, Deventer-2, M.S.J. van wrote:

Hi,

the first thing that comes to mind, did you set ip_forward to enable in
/etc/sysctl.conf ?
net.ipv4.ip_forward = 1

Should explain why you IP on the bridge works but not on the vms.

First, thanks for the reply and excellent suggestion.  Yeah, I thought 
about that, and while it's not specifically defined in /etc/sysctl.conf 
or /etc/sysctl.d/*, if I:


[root@c8-kvm-pe1950-1 ~]# cat /proc/sys/net/ipv4/ip_forward
1

It shows as being defined to 1.  I'm going to try adding to sysctl.conf 
and see if that makes any difference, though.


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


Re: [CentOS] EL8 / certwatch missing

2020-06-17 Thread Simon Matter via CentOS
> Am 17.06.20 um 12:28 schrieb John Horne:
>> On Sun, 2020-06-07 at 23:36 +0200, Leon Fauster via CentOS wrote:
>>> I have some scripts using certwatch from the crypto-utils package. This
>>> rpm seems to be unshipped with EL8. Any ideas whats the "new" tool to
>>> check pem cert files?
>>>
>> Hi,
>>
>> I have used the 'x509watch' package for several years now to see when
>> certificates are about to expire.
>
> Everyday learning new stuff. Thanks for the pointer. ;-)
>

Another option would be ssl-cert-check

https://github.com/Matty9191/ssl-cert-check

I'm using it with a patch for Zabbix.

Regards,
Simon

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


Re: [CentOS] EL8 / certwatch missing

2020-06-17 Thread Leon Fauster via CentOS

Am 17.06.20 um 12:28 schrieb John Horne:

On Sun, 2020-06-07 at 23:36 +0200, Leon Fauster via CentOS wrote:

I have some scripts using certwatch from the crypto-utils package. This
rpm seems to be unshipped with EL8. Any ideas whats the "new" tool to
check pem cert files?


Hi,

I have used the 'x509watch' package for several years now to see when
certificates are about to expire.


Everyday learning new stuff. Thanks for the pointer. ;-)

--
Leon







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


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

2020-06-17 Thread Leon Fauster via CentOS

Am 17.06.20 um 09:16 schrieb Nicolas Kovacs:

Hi,

I just read this blog article from austrian Linux expert Michael Kofler. For
those among you who don't know the guy, he's my home country's number one Linux
expert (known as "der Kofler") and most notably the author of a series of
excellent books about Linux over the last 25 years.

https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/

Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on all
my servers, and yes, I know the difference between upstream RHEL and CentOS.

The article is in german, but the statistics graph is eloquent enough for the
non-german-speaking users. It focuses on updates for CentOS 8, and more exactly
the extended periods of time where there have been no updates available.

The author's theory ("unspoken truth"): while it's a positive thing that Red
Hat is sponsoring CentOS, the amount of sponsoring is just insufficient enough
so that the product is "starved to death" by Red Hat (e. g. IBM) to encourage
users to move to RHEL.

The author's conclusion is quite severe: in the current state of things, CentOS
8 is not recommendable for production as updates are lagging too much behind.
While CentOS 7 may be usable, CentOS 8 has been "degraded to teaching and
testing purposes".

Still according to Mister Kofler, this "sorry state of things" will probably
encourage users to move to Oracle Linux, the other big RHEL clone.

After some hesitation, I decided to share this on the mailing list. Since this
raises some concerns, I'd be curious to have your take on this.




Site note: Despite the implications of update delays. The numbers 
provided by Michael are not comparable. The needed effort between every 
major release to build the OS is different. So, the numbers should be 
normalized.


Quote from https://wiki.centos.org/About/Building_8:

"The differences ... has changed drastically, the repository format has
added 'modules' and RPMS have grown many features that EL7 and before do
not have."

I wonder about the authors conclusion; the fact that RHEL is the choice
for critical applications (what ever critical is) is known since the 
early days. This applies randomly to C5.11, C4.9 or C8.2.2004.


So - cold soup get cooked again :-)

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


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

2020-06-17 Thread Johnny Hughes
On 6/17/20 8:06 AM, Simon Matter via CentOS wrote:
>> Hi,
>>
>> I just read this blog article from austrian Linux expert Michael Kofler.
>> For
>> those among you who don't know the guy, he's my home country's number one
>> Linux
>> expert (known as "der Kofler") and most notably the author of a series of
>> excellent books about Linux over the last 25 years.
>>
>> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
>>
>> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on
>> all
>> my servers, and yes, I know the difference between upstream RHEL and
>> CentOS.
>>
>> The article is in german, but the statistics graph is eloquent enough for
>> the
>> non-german-speaking users. It focuses on updates for CentOS 8, and more
>> exactly
>> the extended periods of time where there have been no updates available.
>>
>> The author's theory ("unspoken truth"): while it's a positive thing that
>> Red
>> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
>> enough
>> so that the product is "starved to death" by Red Hat (e. g. IBM) to
>> encourage
>> users to move to RHEL.
> 
> I think if Red Hat really wanted to improve the situation, they could
> integrate the building of CentOS into the EL build system to produce both
> versions, RHEL and CentOS, at the same time. In the end 99% of the bits
> are the same anyway. If the delay of CentOS builds is really wanted by Red
> Hat, it would be nice of them to speak it out - and change the name to
> COS, because the ent is not true anymore :-)
> 
> Up to now I thought the big delay with 8 is more an accident than wanted.
> Would be nice to hear what Red Hat says about it. Maybe the problem is not
> known well enough in the Red Hat universe.
>


No one is trynig to make anything slower.

And CentOS Stream 'is' going to be how RHEL is developed in the future.
 So, all this is happening.

But modules introduced in RHEL 8 requires a who new build system (as
koji set up) and a whole new module build back end (MBS).

If you would rather use Oracle for your open source needs .. well, that
is a decision you can make and be responsible for.

If you would instead have feedback directly into the RHEL development
process as a community .. then CentOS is where you want to be.

This stuff is open source, and you are all gown ups who can make your
own decisions.

I can assure you .. I am working my butt off everyday to make CentOS
Linux the best it can be.  If you want to compare what the CentOS team
(a small team) can do compared to Oracle (a tmulti billin dollar
corporation who bought Sun Microsystems .. took over Java and Open
Office, etc)  .. well, we can not provide the resources they can provide.

But Red hat heard the community .. that the community and Red Hat
customers want more direct input into RHEL development.  And Red Hat is
taking action to open up RHEL development in CentOS Stream.

You get to decide who you trust.

Thanks,
Johnny hUghes





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


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

2020-06-17 Thread Alessandro Baggi



Il 17/06/20 15:42, Scott Robbins ha scritto:

On Wed, Jun 17, 2020 at 02:23:36PM +0100, Pete Biggs wrote:



About Oracle as alternative. Oracle Linux is not an alternative to
CentOS but for RHEL and if I will force to pay for enteprise system
currently I will pay RHEL, not OL. Over this, OL is not the only
enterprise distro that a "user" could choose. If support is needed there
are SUSE (SLES) and Ubuntu. For who that don't need support there are
Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know
that slackware,FreeBSD are in that list), so many alternatives are in place.


I think it's particularly disappointing *if* this is a "policy" from RH
since the other major RHEL clone, Scientific Linux, has not produced an
EL8 offering in favour of using CentOS.


Keep in mind that as soon as Scientific Linux started taking off, IIRC,
because CentOS was late with a release, RH quickly hired its main
developer.  I don't think we can really expect RH to act differently than
most corporations.



Yes but today Scientific Linux is out of games and CERN made CentOS CERN 
based on C8 so there is no more a valid competitor for this target (in 
the RH family based distro)



CentOS at the current status (third 8 release) is not suitable for 
production with the current issues and we are forced to buy rhel license 
(and every needed extension).


I would to know what think all ISPs that offer centos 8 on their VPS, 
Dedicated Server, Shared Hosting and how they handle this problem 
(probably they don't because the choice is on the customer but maybe...)


As you said, probably nothing will change for the corporation "limit" 
concept but at this point, probably, many users will migrate to another 
platform with less limitation.

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


Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Deventer-2, M.S.J. van
Hi,

the first thing that comes to mind, did you set ip_forward to enable in
/etc/sysctl.conf ?
net.ipv4.ip_forward = 1

Should explain why you IP on the bridge works but not on the vms.

  Regards,

   Michel

On Wed, 2020-06-17 at 09:43 -0400, Lamar Owen wrote:
> As part of my initial KVM host on C8 deployment, I decided to set up 
> some HA features on the new host, specifically NIC teaming. Teaming 
> seems to be bond++ of a sort, so I thought I would at least try it. 
> So 
> here's the scenario:
> 
> 1.) Server with two gigabit ethernet ports, two Cisco switches.
> 
> 2.) During install, used the 'Server with GUI' group and added the 
> virtualization packages.
> 
> 3.) During install, set up team0 to include the two gig-e ports set
> up 
> active-backup (two switches).
> 
> 4.) During install, set up three bridges, with the slave devices
> being 
> VLANs pointed to the team0 subinterfaces (using VLANs 68, 101, and
> 302; 
> 101 is to be the management bridge for the host, with guests on all 
> three VLANs).  So, for instance, bridge101 has a slave that is
> VLAN101 
> that points to team0.101 with a VLAN ID of 101.  The bridge101
> interface 
> has a manual IP address, but bridge68 and bridge302 do not (IPv4 
> disabled; IPv6 Ignore)
> 
> 5.) After reboot, the bridge101 interface comes up, and I
> successfully 
> connect to the host, since the install is 8.1.1911, I ran a 'dnf
> update' 
> up to 8.2.2004, which went well, then I successfully set up and used 
> cockpit, cockpit-bridge, cockpit-machines, again over the IP address
> on 
> bridge101.
> 
> 
> Ok, now that the base connectivity is working:
> 
> 1.) Connect to the host (traffic on bridge101 over team0.101) using 
> virt-manager on my laptop and install a C8 guest, with the network 
> pointed to bridge302, and a manual IP address.
> 
> 2.) After reboot of guest, there is no IP connectivity to the
> guest's 
> gateway on VLAN302.
> 
> 3.) HOWEVER, the gateway's MAC address shows up in the host's bridge
> fdb 
> for VLAN302, AND in the arp output for the guest; ALSO, the MAC
> address 
> for the guest shows on the cisco switch 'show mac-address-table' 
> output.  The output of 'ip --br link' looks normal for this 
> configuration, but there's a disconnect somewhere.  So, since I see
> that 
> VLAN101 is passing traffic to the bridge correctly (since the
> management 
> IP is on that VLAN), I try to set up a guest on VLAN101; no dice, no 
> work, but the management IP still works fine.
> 
> 
> So, does anyone here have a working setup with KVM guests connecting
> to 
> bridges using 802.1q VLANs on top of a team?  Or even on top of a
> bond 
> (I can reinstall and set it up as a bond easily enough, using 
> active-backup, as far as I know; and, yes, I would reinstall the
> host 
> from scratch to do this).
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
-- 
Michel van Deventer

Integratie Specialist | Divisie Laboratoria, Apotheek en Biomedische
Genetica, Infra Services & Integration

Universitair Medisch Centrum Utrecht | Kamernummer 2.139
Tel. 06-25710398

--

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

--

This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a legal person by public law and is registered at
the Chamber of Commerce for Midden-Nederland under no. 30244197.

Please consider the environment before printing this e-mail.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


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

2020-06-17 Thread Stephen John Smoogen
On Wed, 17 Jun 2020 at 09:42, Scott Robbins  wrote:
>
> On Wed, Jun 17, 2020 at 02:23:36PM +0100, Pete Biggs wrote:
> >
> > > About Oracle as alternative. Oracle Linux is not an alternative to
> > > CentOS but for RHEL and if I will force to pay for enteprise system
> > > currently I will pay RHEL, not OL. Over this, OL is not the only
> > > enterprise distro that a "user" could choose. If support is needed there
> > > are SUSE (SLES) and Ubuntu. For who that don't need support there are
> > > Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know
> > > that slackware,FreeBSD are in that list), so many alternatives are in 
> > > place.
> >
> > I think it's particularly disappointing *if* this is a "policy" from RH
> > since the other major RHEL clone, Scientific Linux, has not produced an
> > EL8 offering in favour of using CentOS.
>
> Keep in mind that as soon as Scientific Linux started taking off, IIRC,
> because CentOS was late with a release, RH quickly hired its main
> developer.  I don't think we can really expect RH to act differently than
> most corporations.

A major reason various people were hired from Fermi labs was very much
that DOE(*) was cutting back funding on Fermilab and there were a lot
of layoffs for anything which could not be the 'core' mission of
Fermi. Making operating systems by any of the labs in the DOE complex
was considered to be not a core mission, and multiple groups were
either laid off or 'asked' to retire. The hiring of people was mainly
because people were soon to be out of a job.

DOE - US Department of Energy which funds Fermi and Argonne National
Labs in Illinois as physics science institutes.

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



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


Re: [CentOS] firewall help request

2020-06-17 Thread Tony Mountifield
In article ,
Paul Heinlein  wrote:
> On Tue, 16 Jun 2020, Leroy Tennison wrote:
> 
> > I have a gateway machine (currently Centos 7 with IPV4 only) with two
> > NICs.  One is connected to the internet, the other to an internal
> > network (10.0.0.0/24) of mixed hardware (windows7, android tablets,
> > android phones, linux boxes) using NAT.  I wish to block all outgoing
> > connects to any external IP address on port 22 (ssh) originating from
> > any internal machine except one (which has a known internal IP address).
> >
> > I've tried some commands using 'iptables' to accomplish this, but so
> > far have failed.  If anyone has a suggestion, I'd really appreciate
> > it.  In addition, a suitable version for 'firewalld' could be useful,
> > as an upgrade to Centos 8 is in plan.
> >
> > Examples of what I've tried, and then tested.  None of them stopped
> > an outgoing SSH from an internal system.
> >
> >   iptables -I INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j DROP
> >   iptables -I INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j DROP
> 
> I'm not sure it's your INPUT table that needs that rule. I don't have 
> any NAT machines for experimentation, but my initial hunch is that 
> you'd want OUTPUT rules, e.g.,
> 
> iptables -A OUTPUT -p tcp --dport 22 -s ${GOODIP}/32 -j ACCEPT
> iptables -A OUTPUT -p tcp --dport 22 -s 10.0.0.0/24  -j REJECT

No, the OUTPUT chains apply to traffic originating within the machine
itself (the gateway machine).

But for traffic being forwarded by the gateway, it will use the FORWARD
chains rather than the INPUT chains. So probably something like this:

iptables -A FORWARD -p tcp --dport 22 -s ${GOODIP}/32 -j ACCEPT
iptables -A FORWARD -p tcp --dport 22 -s 10.0.0.0/24  -j REJECT

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] C8 - KVM on bridge on VLAN on team issues.

2020-06-17 Thread Lamar Owen
As part of my initial KVM host on C8 deployment, I decided to set up 
some HA features on the new host, specifically NIC teaming. Teaming 
seems to be bond++ of a sort, so I thought I would at least try it.  So 
here's the scenario:


1.) Server with two gigabit ethernet ports, two Cisco switches.

2.) During install, used the 'Server with GUI' group and added the 
virtualization packages.


3.) During install, set up team0 to include the two gig-e ports set up 
active-backup (two switches).


4.) During install, set up three bridges, with the slave devices being 
VLANs pointed to the team0 subinterfaces (using VLANs 68, 101, and 302; 
101 is to be the management bridge for the host, with guests on all 
three VLANs).  So, for instance, bridge101 has a slave that is VLAN101 
that points to team0.101 with a VLAN ID of 101.  The bridge101 interface 
has a manual IP address, but bridge68 and bridge302 do not (IPv4 
disabled; IPv6 Ignore)


5.) After reboot, the bridge101 interface comes up, and I successfully 
connect to the host, since the install is 8.1.1911, I ran a 'dnf update' 
up to 8.2.2004, which went well, then I successfully set up and used 
cockpit, cockpit-bridge, cockpit-machines, again over the IP address on 
bridge101.



Ok, now that the base connectivity is working:

1.) Connect to the host (traffic on bridge101 over team0.101) using 
virt-manager on my laptop and install a C8 guest, with the network 
pointed to bridge302, and a manual IP address.


2.) After reboot of guest, there is no IP connectivity to the guest's 
gateway on VLAN302.


3.) HOWEVER, the gateway's MAC address shows up in the host's bridge fdb 
for VLAN302, AND in the arp output for the guest; ALSO, the MAC address 
for the guest shows on the cisco switch 'show mac-address-table' 
output.  The output of 'ip --br link' looks normal for this 
configuration, but there's a disconnect somewhere.  So, since I see that 
VLAN101 is passing traffic to the bridge correctly (since the management 
IP is on that VLAN), I try to set up a guest on VLAN101; no dice, no 
work, but the management IP still works fine.



So, does anyone here have a working setup with KVM guests connecting to 
bridges using 802.1q VLANs on top of a team?  Or even on top of a bond 
(I can reinstall and set it up as a bond easily enough, using 
active-backup, as far as I know; and, yes, I would reinstall the host 
from scratch to do this).


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


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

2020-06-17 Thread Scott Robbins
On Wed, Jun 17, 2020 at 02:23:36PM +0100, Pete Biggs wrote:
> 
> > About Oracle as alternative. Oracle Linux is not an alternative to 
> > CentOS but for RHEL and if I will force to pay for enteprise system 
> > currently I will pay RHEL, not OL. Over this, OL is not the only 
> > enterprise distro that a "user" could choose. If support is needed there 
> > are SUSE (SLES) and Ubuntu. For who that don't need support there are 
> > Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know 
> > that slackware,FreeBSD are in that list), so many alternatives are in place.
> 
> I think it's particularly disappointing *if* this is a "policy" from RH
> since the other major RHEL clone, Scientific Linux, has not produced an
> EL8 offering in favour of using CentOS.

Keep in mind that as soon as Scientific Linux started taking off, IIRC,
because CentOS was late with a release, RH quickly hired its main
developer.  I don't think we can really expect RH to act differently than
most corporations. 

-- 
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] Amd es1000

2020-06-17 Thread Gianluca Cecchi
On Wed, Jun 17, 2020 at 1:56 PM paride desimone  wrote:

> Hi, i have a proliant dl380 g5, with an amd as1000. I try to install
> centos8 with gui, but when try to start the new installed system, the
> xserver don't start. There is a throuble with the amd es1000 driver. This
> grafic card, seems not supported more from amd.
> I need a minimalistic gui for study for rhcsa certification.
> The gui is mandatory for the exam.
>
> Any help?
>
> Paride
>
>
for a different system, but with low end graphic card too, I had success
going to graphical target during installation modifying the initial kernel
line removing the "quiet" word and adding

inst.xdriver=fbdev inst.resolution=1024x768

PS: 1024x768 is the lowest resolution usable.

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


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

2020-06-17 Thread Pete Biggs


> About Oracle as alternative. Oracle Linux is not an alternative to 
> CentOS but for RHEL and if I will force to pay for enteprise system 
> currently I will pay RHEL, not OL. Over this, OL is not the only 
> enterprise distro that a "user" could choose. If support is needed there 
> are SUSE (SLES) and Ubuntu. For who that don't need support there are 
> Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know 
> that slackware,FreeBSD are in that list), so many alternatives are in place.

I think it's particularly disappointing *if* this is a "policy" from RH
since the other major RHEL clone, Scientific Linux, has not produced an
EL8 offering in favour of using CentOS.

I think all of us here understand the hugely complex process of
producing a quality OS, even when it's "just" a clone of another one.
The official sanctioning from RH was touted as a two-way process:
community input into RHEL and RH support and help of the cloning and
build process. It would be a bit underhand if it turned out that it was
RH's way of creating a two tier system: buy RHEL+support and get timely
updates; use CentOS for free, get security updates, but wait two months
for each upgrade.

P.


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


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

2020-06-17 Thread Simon Matter via CentOS
> Hi,
>
> I just read this blog article from austrian Linux expert Michael Kofler.
> For
> those among you who don't know the guy, he's my home country's number one
> Linux
> expert (known as "der Kofler") and most notably the author of a series of
> excellent books about Linux over the last 25 years.
>
> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
>
> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on
> all
> my servers, and yes, I know the difference between upstream RHEL and
> CentOS.
>
> The article is in german, but the statistics graph is eloquent enough for
> the
> non-german-speaking users. It focuses on updates for CentOS 8, and more
> exactly
> the extended periods of time where there have been no updates available.
>
> The author's theory ("unspoken truth"): while it's a positive thing that
> Red
> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
> enough
> so that the product is "starved to death" by Red Hat (e. g. IBM) to
> encourage
> users to move to RHEL.

I think if Red Hat really wanted to improve the situation, they could
integrate the building of CentOS into the EL build system to produce both
versions, RHEL and CentOS, at the same time. In the end 99% of the bits
are the same anyway. If the delay of CentOS builds is really wanted by Red
Hat, it would be nice of them to speak it out - and change the name to
COS, because the ent is not true anymore :-)

Up to now I thought the big delay with 8 is more an accident than wanted.
Would be nice to hear what Red Hat says about it. Maybe the problem is not
known well enough in the Red Hat universe.

Regards,
Simon

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


Re: [CentOS] Centos7 and Vlan

2020-06-17 Thread Alfredo De Luca
Thanks guys. I ll go through all your recò and links tomorrow and let
you know.
I might post my configuration so you can have a look at it.
Cheers

/Alfredo

On Wed., 17 Jun. 2020, 3:34 am Gordon Messmer, 
wrote:

> On 6/16/20 1:56 AM, Alfredo De Luca wrote:
> > I have centos7 with 1 network interface and on that IFwe have 2 vlan.
> >  From both vlan we'd like to reach the internet independently so
> basically
> > with 2 different gateways.
>
>
> Look for documentation on "multi-homing":
>
> https://blogs.oracle.com/networking/advance-routing-for-multi-homed-hosts
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] CentOS-announce Digest, Vol 184, Issue 7

2020-06-17 Thread centos-announce-request
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CESA-2020:2549 Moderate CentOS 7 libexif Security Update
  (Johnny Hughes)


--

Message: 1
Date: Tue, 16 Jun 2020 18:32:09 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2020:2549 Moderate CentOS 7 libexif
SecurityUpdate
Message-ID: <20200616183209.ga23...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2020:2549 Moderate

Upstream details at : https://access.redhat.com/errata/RHSA-2020:2549

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
ff151ff0d06a3a237f4112e81dd69cb30bdd207c1ce2eeb5c88d405e20445e69  
libexif-0.6.21-7.el7_8.i686.rpm
4ca77ed3d5488bddf31a813f9371f5487353f38a4d4fe7b38be4b46694f3e848  
libexif-0.6.21-7.el7_8.x86_64.rpm
73a55735154caaf123f7c2629028bca3814feea738608d640925ec8547daedd0  
libexif-devel-0.6.21-7.el7_8.i686.rpm
186ce67dec961f8d780c8d13e7155bc248bcc8287aa243db6203a96edec4350b  
libexif-devel-0.6.21-7.el7_8.x86_64.rpm
d3c72ed4324f614b0ed32dfcae0b76adb75317301ed01a759168c17e6c4f9427  
libexif-doc-0.6.21-7.el7_8.x86_64.rpm

Source:
9740fa364a4cb8a7ee5f1dedb9cc96917b316acbc157374e3f8c8bcab9ed354e  
libexif-0.6.21-7.el7_8.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Subject: Digest Footer

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


--

End of CentOS-announce Digest, Vol 184, Issue 7
***
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Amd es1000

2020-06-17 Thread paride desimone
Hi, i have a proliant dl380 g5, with an amd as1000. I try to install
centos8 with gui, but when try to start the new installed system, the
xserver don't start. There is a throuble with the amd es1000 driver. This
grafic card, seems not supported more from amd.
I need a minimalistic gui for study for rhcsa certification.
The gui is mandatory for the exam.

Any help?

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


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

2020-06-17 Thread Tom Bishop
*snip

>
>
> Thank you for sharing, I found it interesting.
>
> My 2 Cent
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos


+1

Longtime user but with the current sturcture they have turned it (centos8)
into really a non production release. I've always tried to use it on
internal servers but these are small businesses (non-profit) that will pay
for a windows server license vs a RHEL. Microsoft has actually expanded and
opened it up even more. I really thought it was a good thing for RHEL to
support Centos since they had made the builds more difficult but it doesn't
appear that they do not want to support it too much. As it currently stands
I could not or will not deploy Centos8 in a internet facing environment.

I continue to run 8 at home but do not see myself deploying it into
production anywhere. I deeply appreciate all the hard work that goes into
putting it out, Karanbir, Fabian, Johnny, Ralph and Tru and all the others
put in to produce and support it. :)

My hope is that RHEL changes the level of support they provide to centOS
but not confident it's going to happen here's hoping.

;)



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


Re: [CentOS] EL8 / certwatch missing

2020-06-17 Thread John Horne
On Sun, 2020-06-07 at 23:36 +0200, Leon Fauster via CentOS wrote:
> I have some scripts using certwatch from the crypto-utils package. This
> rpm seems to be unshipped with EL8. Any ideas whats the "new" tool to
> check pem cert files?
>
Hi,

I have used the 'x509watch' package for several years now to see when
certificates are about to expire.



John.

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK

[http://www.plymouth.ac.uk/images/email_footer.gif]

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, University of Plymouth accepts no responsibility for viruses and it is 
your responsibility to scan emails and their attachments. University of 
Plymouth does not accept responsibility for any changes made after it was sent. 
Nothing in this email or its attachments constitutes an order for goods or 
services unless accompanied by an official order form.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


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

2020-06-17 Thread Alessandro Baggi



Il 17/06/20 09:16, Nicolas Kovacs ha scritto:

Hi,

I just read this blog article from austrian Linux expert Michael Kofler. For
those among you who don't know the guy, he's my home country's number one Linux
expert (known as "der Kofler") and most notably the author of a series of
excellent books about Linux over the last 25 years.

https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/

Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on all
my servers, and yes, I know the difference between upstream RHEL and CentOS.

The article is in german, but the statistics graph is eloquent enough for the
non-german-speaking users. It focuses on updates for CentOS 8, and more exactly
the extended periods of time where there have been no updates available.

The author's theory ("unspoken truth"): while it's a positive thing that Red
Hat is sponsoring CentOS, the amount of sponsoring is just insufficient enough
so that the product is "starved to death" by Red Hat (e. g. IBM) to encourage
users to move to RHEL.

The author's conclusion is quite severe: in the current state of things, CentOS
8 is not recommendable for production as updates are lagging too much behind.
While CentOS 7 may be usable, CentOS 8 has been "degraded to teaching and
testing purposes".

Still according to Mister Kofler, this "sorry state of things" will probably
encourage users to move to Oracle Linux, the other big RHEL clone.

After some hesitation, I decided to share this on the mailing list. Since this
raises some concerns, I'd be curious to have your take on this.

Cheers from the sunny South of France,

Niki


Hi Niki,
this is a sad thing but I'm not surprised by this and this is what I'm 
thinking about CentOS since 8 was released. The CentOS team does a huge 
work to release CentOS8, CentOS Stream and maintaining 7 and 6. Thank 
you so much for this CentOS Team.
But since the core team is composed by 6(?) member is obvious that they 
can't maintain all this versions without being in late and because it is 
supported (but maybe supported is the wrong word in the current case) by 
RH, if RH really interest about CentOS release they should put more 
effort on CentOS Development. This is not what is happening and since 8 
is released, it seems a try and buy distro.
I walked through 6.5 to 7 and 8. In 6.5 I was new, in 7 I really 
appreciated CentOS but with 8 I noticed that it is not supported like 
CentOS 7.


I use (like you) centos on all my server, some are anchored to the old 
stable and other on 8 (but not production). I liked it very much that I 
use it also on my workstation.


About update blackout, this is a great problem for production system 
faced on Internet. SELinux can mitigate the risk (but also selinux got 
security fix) but this is always an issue. Many report that the gap 
between RHEL release and CentOS release is too much but I'm not 
interested in how much time centos releases get through the build 
process but I'm interested that, when a new centos release (major/minor) 
are on the way, all others releases (current stable inside) will get 
security updates during the build process and not left alone. Another 
minor issue about updates are relative announces on ml that works for C7 
but not for C8 (I read in a reddit AMA why this happens). This is 
annoying because I need to follow every RHBA to see what happened and 
why a package is updated or blindly install updates. This is another 
thing that is not so good for a server.


If the theory "unspoken truth" is real I don't like how RH is trying to 
encourage me to switch to RHEL and this is a bad way to do this.


About Oracle as alternative. Oracle Linux is not an alternative to 
CentOS but for RHEL and if I will force to pay for enteprise system 
currently I will pay RHEL, not OL. Over this, OL is not the only 
enterprise distro that a "user" could choose. If support is needed there 
are SUSE (SLES) and Ubuntu. For who that don't need support there are 
Debian, Ubuntu, OpenSUSE (I'm talking about the most used but you know 
that slackware,FreeBSD are in that list), so many alternatives are in place.


I hope that things will be better but in case of "failure" I will 
evaluate other alternatives to CentOS for this "sorry state of things".


Thank you for sharing, I found it interesting.

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


Re: [CentOS] Updating microcode_ctl froze Centos7

2020-06-17 Thread Robin Lee
On Mon, 2020-06-15 at 22:25 +0200, Robin Lee wrote:
> On Fri, 2020-06-12 at 09:20 +0200, Robin Lee wrote:
> > Today when I ran yum update two packages came up microcode_ctl
> > and unbound-libs. The updating process went fine until it
> > outputted 
> > 
> > Running transaction
> >   Updating   : 2:microcode_ctl-2.1-61.6.el7_8.x86_64
> > 
> > then it just froze. I could no longer ssh to the machine and the
> > console was just blank. I had to shut down it hard. It came back up
> > seemingly fine. But yum update doesn't work anymore. It says "Error
> > importing repomd.xml from base/7/x86_64: Damaged repomd.xml file"
> > I looked at the logs, but journalctl only shows the latest boot on
> > this
> > machine. 
> > 
> > So I guess I have three questions
> > - Any idea what happened with the update process?
> > - How can I repair repomd.xml?
> 
> Now that yum is up and running again it tells me the following 
> 
> "There are unfinished transactions remaining. You might consider
> running yum-complete-transaction, or "yum-complete-transaction --
> cleanup-only" and "yum history redo last", first to finish them. If
> those don't work you'll have to try removing/installing packages by
> hand (maybe package-cleanup can help)."
> 
> Doing "yum-complete-transaction --cleanup-only" should be safe,
> right?
> To clean up the botched microcode_ctl update and after that set it
> among excluded packages.


Is there some more information about this issue?

I've found this ticket https://bugs.centos.org/view.php?id=17452

I'm wondering how safe it is to update the microcode_ctl package on
other Centos machines I have? They don't have a Supermicro motherboard.

Cheers
Robin

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


[CentOS] Blog article about the state of CentOS

2020-06-17 Thread Nicolas Kovacs
Hi,

I just read this blog article from austrian Linux expert Michael Kofler. For
those among you who don't know the guy, he's my home country's number one Linux
expert (known as "der Kofler") and most notably the author of a series of
excellent books about Linux over the last 25 years.

https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/

Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on all
my servers, and yes, I know the difference between upstream RHEL and CentOS.

The article is in german, but the statistics graph is eloquent enough for the
non-german-speaking users. It focuses on updates for CentOS 8, and more exactly
the extended periods of time where there have been no updates available.

The author's theory ("unspoken truth"): while it's a positive thing that Red
Hat is sponsoring CentOS, the amount of sponsoring is just insufficient enough
so that the product is "starved to death" by Red Hat (e. g. IBM) to encourage
users to move to RHEL.

The author's conclusion is quite severe: in the current state of things, CentOS
8 is not recommendable for production as updates are lagging too much behind.
While CentOS 7 may be usable, CentOS 8 has been "degraded to teaching and
testing purposes".

Still according to Mister Kofler, this "sorry state of things" will probably
encourage users to move to Oracle Linux, the other big RHEL clone.

After some hesitation, I decided to share this on the mailing list. Since this
raises some concerns, I'd be curious to have your take on this.

Cheers from the sunny South of France,

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] After update to 8 (2004) ... system is unbootable - UEFI Secure boot

2020-06-17 Thread Fabian Arrotin
On 17/06/2020 04:03, Leon Fauster via CentOS wrote:
> Am 16.06.20 um 22:04 schrieb Fabian Arrotin:
>> On 16/06/2020 15:06, Leon Fauster via CentOS wrote:
>>> Hi all,
>>>
>>> I updated a Dell XPS laptop from CentOS 8.1 (1911) to 8.2 (2004).
>>>
>>> Installed kernels are
>>> kernel-4.18.0-147.5.1.el8_1.x86_64
>>> kernel-4.18.0-147.8.1.el8_1.x86_64
>>> kernel-4.18.0-193.6.3.el8_2.x86_64
>>>
>>> Unfortunately I can not boot into the latest
>>> kernel-4.18.0-193.6.3.el8_2.x86_64.
>>>
>>> After grub2 screen I only see following line:
>>>
>>> EFI stub: UEFI Secure Boot is enabled
>>>
>>> Booting into the older kernel is still possible. The
>>> above line appears and after that the normal kernel
>>> output scrolls over the screen (rhgb quiet disabled).
>>>
>>> Is the new kernel correctly signed?
>>>
>>> What can I do?
>>>
>>> -- 
>>> Thanks
>>> Leon
>>
>> Hi Leon,
>>
>> Don't think that it's due to secureboot, as on my work laptop (thinkpad
>> t490s), I have secureboot on, and kernel working fine.
>>
>> OTOH, on my family laptop (also in secureboot mode), when I updated from
>> 8.1.1011 to 8.2.2004, laptop became unresponsive during the
>> microcode_ctl update (in scriptlet) and after that it auto-reset itself
>> , so in the middle of the whole rpm transaction.
>> I tried to recover it but it was to a point where it was faster to just
>> reinstall from scratch with 8.2.2004, which I did ... and in gnome,
>> everything was fine, etc (adding repo, pkgs) but then on the *same*
>> kernel it was installed with, just tried a reboot, and nothing  : grub
>> shows menu, you select kernel and on upper left there is only cursor
>> (fixed) and nothing happens ..
>>
>> I'll try to diagnose what's the issue as actually that means troubles
>> with family using that laptop :)
> 
> 
> Hi Fabian,
> 
> an earlyprintk=efi kernel option shows a slowly executed kernel
> (at least the output). I disabled the early_microcode dracut option
> and rebuilded the initramfs image but no success in booting the kernel
> 4.18.0-193.6.3.el8_2.x86_64. Unfortunately no more time for more
> heuristics ...
> 
> -- 
> Leon
> 

I finally had reinstalled the laptop over pxe at home *but* pointing to
kickstart repo (so GA content without updates, and so local mirror of
http://mirror.centos.org/centos/8/BaseOS/x86_64/kickstart/), to ensure
that microcode_ctl wouldn't be installed, and in some minutes laptop was
back in action.
Excluding it from updates and updated the rest and all is ok.

I've seen some people mentioning strange problems like this due to
microcode, and it seems Ubuntu even had a second update a in row to fix
issues :
- https://usn.ubuntu.com/4385-1/ (introducing issue)
- https://usn.ubuntu.com/4385-2/ (fixing the introduced issue)

All that was reported for centos 7 as we had the same issue there too
(see https://bugs.centos.org//view.php?id=17452)

So for people impacted, I guess we have to wait for a new update to
land, and excluding it from updates for now

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab



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


Re: [CentOS] firewall help request (solved)

2020-06-17 Thread Simon Matter via CentOS
> At 03:47 PM 6/16/2020, Kenneth Porter wrote:
>>The rule is in the wrong chain. The INPUT chain affects packets that
>>terminate at the same machine. You want to block packets that will
>>be passed on to the Internet, so your rule needs to be in the
>>FORWARD chain. (The OUTPUT chain affects packets that originate at
>>your machine.)
>>
>>Here's a nice collection of diagrams showing how packets flow
>>through the system:
>>
>>
>
>
> Ah ... Caught it.  So here is the IPTABLES method to block output on
> port 22 from internal machines on a gateway:
>
>iptables -I FORWARD -p tcp --dport 22 -i
> {name-of-internal-interface} -j DROP
>
> So, for example, if your internal interface is, for example,
> /dev/enp2s0, you'd write
>
>iptables -I FORWARD -p tcp --dport 22 -i enp2s0 -j DROP
>
> If you want to log such attempts, preceed it with a log
> request.  Since I'm using the -I command (insert at top), it means
> the log request is entered second:
>
>iptables -I FORWARD -p tcp --dport 22 -i
> {name-of-internal-interface} -j LOG --log-prefix "LOOK HERE"
>
>
> If someone can suggest a firewall-cmd equivalent, it would be nice.

For that kind of firewalling, I suggest to use Shorewall instead:

https://shorewall.org/

IMHO it's the better tool for where you need more than a "personal" firewall.

Regards,
Simon

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