how to deal with Redhat's bad port of libCurl ?
how to deal with Redhat's bad port of libCurl ?
What is the best way to deal with redhat's buggy backport of libCurl into CentOS 7 ?
https://bugs.centos.org/view.php?id=8076
https://bugzilla.redhat.com/show_bug.cgi?id=1130239
It is causing 150ms delay on my machines on every request
Since it is nearly September and they have not fixed it since January, I cannot wait any longer.
I want to be able to switch back to their rpm via yum when they finally get to it, should I just build my own copy and put it into /usr/local ?
https://bugs.centos.org/view.php?id=8076
https://bugzilla.redhat.com/show_bug.cgi?id=1130239
It is causing 150ms delay on my machines on every request
Since it is nearly September and they have not fixed it since January, I cannot wait any longer.
I want to be able to switch back to their rpm via yum when they finally get to it, should I just build my own copy and put it into /usr/local ?
Re: how to deal with Redhat's bad port of libCurl ?
Reading the posted bug reports, it seems the 150ms delay is due to DNS resolution - just don't do that - use the IP?
If I was to do what you are suggesting, then yes, I'm put it all (libraries and binaries) in /usr/local and ALWAYS call it by the full path (i.e.: /usr/local/bin/curl). Then when they fix it you can just remove the installation in /usr/local. Some people have suggested building a "local" RPM so it's easier to erase later, either way it's (almost) the same thing.
If you do this, I suspect it could no longer be supported by this CentOS.
If I was to do what you are suggesting, then yes, I'm put it all (libraries and binaries) in /usr/local and ALWAYS call it by the full path (i.e.: /usr/local/bin/curl). Then when they fix it you can just remove the installation in /usr/local. Some people have suggested building a "local" RPM so it's easier to erase later, either way it's (almost) the same thing.
If you do this, I suspect it could no longer be supported by this CentOS.
Re: how to deal with Redhat's bad port of libCurl ?
Apparently the city-fan repo built the newest curl 7.44 on CentOS7 (RHEL7) but it has several dependencies and installing those dependencies will definitely require PHP to be rebuilt and perhaps other things as well.
http://mirror.city-fan.org/ftp/contrib/ ... Mirroring/
curl libcurl libcurl-devel libssh2 libssh2-devel libcurl7155 libcurl7112 c-ares
really wish Redhat would just patch their source
I guess I could take the 7.29 source from redhat and just do the small patch on that, which in theory would not break anything else.
https://github.com/bagder/curl/commit/d529f388
Wow, it's not six months old, the bug is literally 13 months old. Nothing from redhat. Sheesh.
It's ONE LINE, just one damn line.
So, can anyone help with the steps here:
http://www.rpmfind.net//linux/RPM/cento ... 86_64.html
http://mirror.city-fan.org/ftp/contrib/ ... Mirroring/
curl libcurl libcurl-devel libssh2 libssh2-devel libcurl7155 libcurl7112 c-ares
really wish Redhat would just patch their source
I guess I could take the 7.29 source from redhat and just do the small patch on that, which in theory would not break anything else.
https://github.com/bagder/curl/commit/d529f388
Wow, it's not six months old, the bug is literally 13 months old. Nothing from redhat. Sheesh.
It's ONE LINE, just one damn line.
So, can anyone help with the steps here:
http://www.rpmfind.net//linux/RPM/cento ... 86_64.html
Re: how to deal with Redhat's bad port of libCurl ?
sheesh look at how much worse centos 7 is vs 6
https://bugzilla.redhat.com/show_bug.cgi?id=1218272
https://bugzilla.redhat.com/show_bug.cgi?id=1218272
Code: Select all
real usr sys
RHEL 7.1
curl FTP 0m11.610s 0m0.026s 0m0.041s
HTTP 0m1.551s 0m0.017s 0m0.039s
wget FTP 0m0.091s 0m0.011s 0m0.040s
HTTP 0m0.049s 0m0.014s 0m0.031s
RHEL6.4
curl FTP 0m0.099s 0m0.016s 0m0.031s
HTTP 0m0.096s 0m0.013s 0m0.042s
wget FTP 0m0.087s 0m0.007s 0m0.036s
HTTP 0m0.048s 0m0.008s 0m0.028s
Re: how to deal with Redhat's bad port of libCurl ?
Yeah, so RH (according to the bug listing posted) *thinks* it *may* have found another regression, that's probably the thing that's holding it up.
Testing is hard, so is patience.
Testing is hard, so is patience.
Give them shit loads of money and they'll fix your problem quickly.really wish Redhat would just patch their source
Yeah, PHP sucks spades and has a bad (IMO) of security problems for many years now.Apparently the city-fan repo built the newest curl 7.44 on CentOS7 (RHEL7) but it has several dependencies and installing those dependencies will definitely require PHP to be rebuilt and perhaps other things as well.
Re: how to deal with Redhat's bad port of libCurl ?
php is more frequently updated and fixed than perhaps any other languageaks wrote:Yeah, PHP sucks spades and has a bad (IMO) of security problems for many years now.
php7 next month will change everything, it will make php faster than many other languages
Re: how to deal with Redhat's bad port of libCurl ?
Yeah and it'll still have a shed load of bugs, probably due to it's popularity. I would say these words: "just stop, please!"php7 next month will change everything, it will make php faster than many other languages
Re: how to deal with Redhat's bad port of libCurl ?
Since it is fixed in curl-7.29.0-22.fc19 is there any chance that fedora rpms can be applied to a centos install?
Looks like they stopped at 27 and that patch actually was a security fix for ssl, etc.
https://lists.fedoraproject.org/piperma ... 47371.html
We are talking about the same base package with eight additional patches:
centos7: curl-7.29.0-19
fedora19: curl-7.29.0-27
curl-7.29.0-27.fc19.x86_64
libcurl-7.29.0-27.fc19.x86_64
libcurl-devel-7.29.0-27.fc19.x86_64
could those two technically be built into rpms and then dropped into centos7 and not need any dependency replacements since they are
Isn't fc19 the same base as centos7 ? (I think they are up to fc21 now)
rpm downloads:
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
now looking for the srpm
Looks like they stopped at 27 and that patch actually was a security fix for ssl, etc.
https://lists.fedoraproject.org/piperma ... 47371.html
We are talking about the same base package with eight additional patches:
centos7: curl-7.29.0-19
fedora19: curl-7.29.0-27
curl-7.29.0-27.fc19.x86_64
libcurl-7.29.0-27.fc19.x86_64
libcurl-devel-7.29.0-27.fc19.x86_64
could those two technically be built into rpms and then dropped into centos7 and not need any dependency replacements since they are
Isn't fc19 the same base as centos7 ? (I think they are up to fc21 now)
rpm downloads:
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
http://mirror.fdcservers.net/fedora/upd ... x86_64.rpm
now looking for the srpm
Re: how to deal with Redhat's bad port of libCurl ?
Not sure I am crazy enough to try this, but since the packages are isolated and no dependencies are changed, it can be undone
fedora.repo
yum --enablerepo=fedora update curl libcurl libcurl-devel
fedora.repo
Code: Select all
[fedora]
name=Fedora $releasever - $basearch
baseurl=http://dl.fedoraproject.org/pub/archive/fedora/linux/updates/19/$basesearch/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-19
Code: Select all
Resolving Dependencies
--> Running transaction check
---> Package curl.x86_64 0:7.29.0-19.el7 will be updated
---> Package curl.x86_64 0:7.29.0-27.fc19 will be an update
---> Package libcurl.x86_64 0:7.29.0-19.el7 will be updated
---> Package libcurl.x86_64 0:7.29.0-27.fc19 will be an update
---> Package libcurl-devel.x86_64 0:7.29.0-19.el7 will be updated
---> Package libcurl-devel.x86_64 0:7.29.0-27.fc19 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================================================
Package Arch Version Repository Size
================================================================================================================
Updating:
curl x86_64 7.29.0-27.fc19 fedora 262 k
libcurl x86_64 7.29.0-27.fc19 fedora 213 k
libcurl-devel x86_64 7.29.0-27.fc19 fedora 297 k
Transaction Summary
================================================================================================================
Upgrade 3 Packages
Total download size: 772 k
Re: how to deal with Redhat's bad port of libCurl ?
It worked! Looks stable so far, will run tests all week and watch for any errors in logs - since it the same version with just minor patches, I hope for the best...
Check out the before and after on the graphs, change is at 17:00 hours on the graph after the break, on the right
1. dns time drops to 4ms reading from the resolver cache instead of 150-350ms
2. connect time drops from 420ms to 74ms
3. time to first byte drops from 489ms to 143ms
4. download speed improves from 40KB/sec to 65KB/sec
Check out the before and after on the graphs, change is at 17:00 hours on the graph after the break, on the right
1. dns time drops to 4ms reading from the resolver cache instead of 150-350ms
2. connect time drops from 420ms to 74ms
3. time to first byte drops from 489ms to 143ms
4. download speed improves from 40KB/sec to 65KB/sec