In a server linux Centos 5 64bit, I have compile from the source code the webserver Apache version 2.4.6.
Below, the configure instruction that I have used.
./configure --enable-mods-shared=reallyall --with-suexec-caller=apache --enable-cache --enable-cache-disk --with-ldap --enable-ldap --enable-authnz-ldap
Now, I must recompile the webserver Apache to using the new installed version of openssl (1.0.1e-fips).
What is the correct syntax to reconfigure Apache to using the current version of openssl installed on the server?
Many thanks at all.
As you unfortunately didn't mention how you installed OpenSSL 1.0.1e-fips (and where), this can't be answered. Based on 1.0.1e-fips, I see some chances that you used my openssl101e RPM package from EPEL 5 (even more important: openssl101e-devel). If so, run
export CFLAGS="$CFLAGS -I/usr/include/openssl101e"
export CPPFLAGS="$CPPFLAGS -I/usr/include/openssl101e"
export LDFLAGS="$LDFLAGS -L/usr/include/openssl101e"
before ./configure. Otherwise you first need to reveal more details about your OpenSSL 1.0.1e-fips installation/update.
Related
At present we are on Apache/2.2.15 (UNIX) version. To fix the vulnerabilities we are suggested to upgrade to new version. I got new version from online using "wget" command and followed steps mentioned on this link http://httpd.apache.org/docs/2.2/install.html#download.
Once I am done, checked version using httpd -v. It gives me old version Apache/2.2.15 (UNIX). If I check using /usr/local/apache2/bin/httpd - v. It gives me new version. Did I successfully upgraded the version or not? If not what should I do?
I tried "yum install httpd" - It says "Nothing to do".
You now have two versions of Apache installed. You have the one installed with the system package manager (yum) in /usr/sbin/httpd. You have one installed manually in /usr/local/apache2/....
Which one you get will be determined entirely by which path you use.
In general, mixing system-managed packages with manually installed packages is a recipe for trouble. If you want to stick with the newer version in /usr/local, you should remove the system version, and realize that you will lose some manageability. For example, you will no longer be able to use yum install ... to install new Apache modules, and you will not be able to verify the installed files using tools like rpmverify.
If your distribution currently has Apache 2.2.x, that suggests your distribution is fairly old. For example, RHEL (and CentOS) 7 (and similar variants) have version 2.4.6 packaged, so you may want to update your host to something newer than whatever you're running now.
Yes, its successfully upgraded as per the screenshot.
httpd 2.2.15 is the version with RHEL 6 repository, here HTTPD_HOME is /etc/httpd (Highest version provided for HTTPD via RPM RHEL 6 is 2.2.15)
httpd 2.4.6 is the version with EPEL-HTTPD24 repository, here HTTPD_HOME is /usr/local/apache2/
I have CENTOS7 server, with:
Server version: Apache/2.4.6 (CentOS)
.
How can i enable/add HTTP/2 on these Apache ?
I'm trying to send http2 requests from the client via Nghttp, but i get an error in the response (recv RST_STREAM frame ) as a result of server which does not supports Http2.
I saw that i have to enable module_http2 in the apache, but i didn't
found hot can i do this.
Thanks in Advance.
HTTP/2 support was only added in Apache 2.4.18 which is not available in the standard CentOS/Red Hat repos. Though as mod_http2 was (and still is at time of writing) being actively worked on you should go with the latest version (2.4.33 at time of writing - though there are further mod_http2 patches available on top of that).
Additionally HTTP/2 requires OpenSSL 1.0.2 or above which means you need CentOS/RHEL 7.4 or above unless you want to install your own version of OpenSSL as well your own version of Apache. Note you need Apache 2.4.26 or above if you want to go further than that and go to OpenSSL 1.1.0.
So you need to download and compile a later Apache (and possibly OpenSSL) from source - or find another repo with these later versions. This does carry some risks - primarily that you lose the easy security patches that repo versions supply. CentOS Apache 2.4.6 actually includes all the latest security patches of later versions (assuming you regularly run "yum update" to update it) - but not the functionality changes like HTTP/2 (hence why they leave version number at 2.4.6).
If you're interested in installing from source then I've a step by step blog post on how to do that here: https://www.tunetheweb.com/performance/http2/
You can install a newer version of httpd than is included in the base repositories through the httpd24 Software Collection. Once you've enabled the SCL, you need the following packages:
httpd24
httpd24-nghttp2
httpd24-mod_ssl *
* It's best to configure SSL too, because for example Chrome will only do HTTP2 with TLS.
I have an rpm compiled in centos 5.x which requires libnetsnmp.so.10 and other shared objects. I want to create an rpm of it which is to be run on centos 6.x but it fails to install as on installation it says :
error: Failed dependencies:
libnetsnmp.so.10()(64bit) is needed and so on...
But Centos 6.x contains libnetsnmp.so.20
So I created symbolic links of libnetsnmp.so.10 of libnetsnmp.so.20.
But problem is still the same.
So can you please help me to resolve this problem?
If recompiling for Centos 6 isn't an option, you can try two things, first, install the correct libnetsnmp in the Centos 6 server. If that's not an option, you can add the following to your RPM spec file:
Autoreq: no
This will cause it not to scan your binary for dependencies (such as dynamically linked libraries), and automatically build that into the RPM.
Of course, if that version of libnetsnmp is ACTUALLY required, your just hosing yourself down the road, but likely newer versions will work just fine.
I installed GitLab 6.6.5 via the omnibus package on Ubuntu 12.04 LTE. My question is will the Ubuntu OpenSSL heartbleed update cover the GitLab's installation? The installation has an embedded nginx that is installed. I have enabled SSL via the GitLab Omnibus Merge Request #66.
Having an embedded NGinX doesn't mean it won't use the /usr/bin/openssl installed on your system. (for instance, the ngx_http_ssl_module does require openssl)
If that openssl is 1.0.1g or 1.0.2, you won't have any issue.
openssl version
If not, it is easy enough to recompile it and install it.
To be sure, you can type:
ldd /path/to/nginx
That will give you the path of the openssl used by the binary nginx.
To get the full path, you can then use
readlink -f /path/to/libssl.so.1.0.0
Bruno adds in the comments:
It's probably more about /lib/*/libssl.so.1.0.0 than /usr/bin/openssl (which ldd should indicate indeed).
In principle, upgrading to the package with the fix and restarting NGinX should fix the issue.
Also note that the version numbers in distribution packages (e.g. Ubuntu) don't necessarily match the official version numbers exactly, because they tend to keep the same version number (for the same features), but backport the security patches
The OP crushedGrass points out in the comments Jacob Vosmaer (jacobvosmaer)'s commit "Update omnibus-software (CVE-2014-0160)", in omnibus-gitlab
so all I had to do was run a reconfiguration.
I believe both your and Bruno's feedback is spot on, there are just more dependencies that have to match up.
GitLab uses Chef cookbooks to configure the setup and I definitely do not know enough about it to modify it downstream.
Just so it is clear:
-> # ldd /opt/gitlab/embedded/sbin/nginx
...
libssl.so.1.0.0 => /opt/gitlab/embedded/lib/libssl.so.1.0.0 (0x00007fe3cf8f9000)
libcrypto.so.1.0.0 => /opt/gitlab/embedded/lib/libcrypto.so.1.0.0 (0x00007fe3cf520000)
...
Gitlab omnibus uses its own bundled OpenSSL. apt-get update will not update and protect an install of gitlab omnibus.
How do I resolved this error on Solaris 11?
"Could not autodetect OpenSSL support. Make sure OpenSSL development packages are installed. Use configure --without-ssl to disable this message."
It is odd because I know that I have openssl 1.0.0e.
Also I know that Node is looking in /usr/include and that the files /usr/include/openssl/ssl.h and /usr/include/openssl/crypto.h exist.
Ubuntu Equivalent
The "OpenSSL development packages" are actually not the "openssl" package.
You need to apt-get (or similar for Solaris) install the package called "libssl-dev".
For me, this solved the problem while trying to configure the source for node.js.
If you have openssl already installed in /usr/local/ssl, use those configure options:
--openssl-includes=/usr/local/ssl/include --openssl-libpath=/usr/local/ssl/lib