Hi,
I got an alert from Yum-Cron this morning:
Failed to check for updates with the following error message: Failed to build transaction: sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickCore.so.5()(64bit) sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickWand.so.5()(64bit)
The CR repository is activated on this server, so I guess that's why.
Which leads me to the more general question of: enable CR on a production server, yes or no?
Pros : get security updates sooner
Cons : expect breakage like the one above
Any suggestions?
Cheers,
Niki
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled means you're running without current security updates for quite some time. Seems a bad and risky idea to me.
Regards, Simon
On Thu, Apr 09, 2020 at 02:40:12PM +0200, Simon Matter via CentOS wrote:
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled means you're running without current security updates for quite some time. Seems a bad and risky idea to me.
I have private staged repos, so I pick and choose what goes onto production systems, after I've tested them on non-productions systems.
CR going to give you broken dependencies as this thread details. If I need to reinstall/build a new prod system, I don't want broken dependencies killing the install.
On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS centos@centos.org wrote:
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled means you're running without current security updates for quite some time. Seems a bad and risky idea to me.
Like most things in the world, there is no single answer which will satisfy all the different demands that all the environments have. You have to weigh what each environment needs in terms of confidentiality, availability, and integrity (or whatever 3 or 4 letter acronym your site uses) then answer if it is a good idea or not. If you need high availability, then you are going to set things up where testing is done first then roll out of updates is done. If you need high confidentiality, you may push out security updates more and if you need high integrity, well you probably make the waterfall model look simple in what you have to do to make sure anything changes anywhere.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS centos@centos.org wrote:
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled means you're running without current security updates for quite some time. Seems a bad and risky idea to me.
Like most things in the world, there is no single answer which will satisfy all the different demands that all the environments have. You have to weigh what each environment needs in terms of confidentiality, availability, and integrity (or whatever 3 or 4 letter acronym your site uses) then answer if it is a good idea or not. If you need high availability, then you are going to set things up where testing is done first then roll out of updates is done. If you need high confidentiality, you may push out security updates more and if you need high integrity, well you probably make the waterfall model look simple in what you have to do to make sure anything changes anywhere.
My reply was to the answer "Not on production. Only for testing.".
I didn't go into detail because I thought it's obvious that it's not so easy. I didn't mean to blindly feed all CR updates to production environments. In fact over here, we never ever feed any update directly from public servers to any production machine. It all comes from local repositories where we have control over what goes where and we can make sure not to blindly make updates.
What I meant is that just staying away from CR for production servers sounds dangerous. You just can't if security critical updates are only available in CR.
Regards, Simon
On Thu, 9 Apr 2020 at 09:34, Simon Matter simon.matter@invoca.ch wrote:
On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS centos@centos.org wrote:
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled means you're running without current security updates for quite some time. Seems a bad and risky idea to me.
Like most things in the world, there is no single answer which will satisfy all the different demands that all the environments have. You have to weigh what each environment needs in terms of confidentiality, availability,
and
integrity (or whatever 3 or 4 letter acronym your site uses) then answer if it is a good idea or not. If you need high availability, then you are going to set things up where testing is done first then roll out of updates is done. If you need high confidentiality, you may push out security updates more and if you need high integrity, well you probably make the waterfall model look simple in what you have to do to make sure anything changes anywhere.
My reply was to the answer "Not on production. Only for testing.".
I didn't go into detail because I thought it's obvious that it's not so easy. I didn't mean to blindly feed all CR updates to production
One thing I have learned in mailing lists is that it isn't always obvious and there is rarely anything which meets common sense. I have dealt with too many policies set at some site because the person read a comment on email/reddit/stack-overflow and didn't see the obvious nature of something. Instead they decided that the short nature was the MUST do and end up with replicating things which the original poster did not expect.
Or sometimes happens someone does believe that it is as simple as they stated and no matter what they turn on CR for every system (or turn off all updates or whatever simple solution they expound as being the one true solution.)
That said, I should have asked what you meant by that versus going for a high-horse response on my own. I apologize.
On Thu, 9 Apr 2020 at 09:34, Simon Matter simon.matter@invoca.ch wrote:
On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS
wrote:
On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
Which leads me to the more general question of: enable CR on a production server, yes or no?
Not on production. Only for testing.
I'm not sure. Running production environments without CR enabled
means
you're running without current security updates for quite some time. Seems a bad and risky idea to me.
Like most things in the world, there is no single answer which will satisfy all the different demands that all the environments have. You have to weigh what each environment needs in terms of confidentiality, availability,
and
integrity (or whatever 3 or 4 letter acronym your site uses) then
answer
if it is a good idea or not. If you need high availability, then you are going to set things up where testing is done first then roll out of updates
is
done. If you need high confidentiality, you may push out security
updates
more and if you need high integrity, well you probably make the
waterfall
model look simple in what you have to do to make sure anything changes anywhere.
My reply was to the answer "Not on production. Only for testing.".
I didn't go into detail because I thought it's obvious that it's not so easy. I didn't mean to blindly feed all CR updates to production
One thing I have learned in mailing lists is that it isn't always obvious and there is rarely anything which meets common sense. I have dealt with too many policies set at some site because the person read a comment on email/reddit/stack-overflow and didn't see the obvious nature of something. Instead they decided that the short nature was the MUST do and end up with replicating things which the original poster did not expect.
Or sometimes happens someone does believe that it is as simple as they stated and no matter what they turn on CR for every system (or turn off all updates or whatever simple solution they expound as being the one true solution.)
That said, I should have asked what you meant by that versus going for a high-horse response on my own. I apologize.
No problem, sorry for not being clear enough in my first answer. Anyway such a discussion is good as it shows different views and can help us to make smarter decisions.
In this particular case the question is not so much about CR but about SCLO being production ready or not.
How about upstream, do they already have updated SCLO packages?
Regards, Simon
Hi,
I got an alert from Yum-Cron this morning:
Failed to check for updates with the following error message: Failed to build transaction: sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickCore.so.5()(64bit) sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickWand.so.5()(64bit)
The CR repository is activated on this server, so I guess that's why.
Which leads me to the more general question of: enable CR on a production server, yes or no?
Pros : get security updates sooner
Cons : expect breakage like the one above
Any suggestions?
Hi,
The breakage you see is not directly within CentOS 7 and CR. The problem is that your SCLO package sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 is for 7.7.1908 and needs to be updated for CentOS 7.8.
All the same you'll not be able to update to CentOS 7.8 until a fixed sclo-php72-php-pecl-imagick package is available.
Applying CR updates to clean installations of a basic CentOS system usually works very fine.
Regards, Simon
-
Jonathan Billings -
Nicolas Kovacs -
Simon Matter -
Stephen John Smoogen