After installing mongodb on CentOS 7 I ran into an issue with openssl versions. Version installed on the system is 1.0.2k-fips whereas during mongod startup 1.0.1e-fips is printed. How exactly is this possible and is there any way to tell mongo server to use 1.0.2 version ?
https://i.stack.imgur.com/KMbwt.png
This seems to be a RHEL peculiarity.
MongoDB is linked dynamically against OpenSSL, and should use the system OpenSSL library. You can verify this by running
ldd `which openssl`
ldd `which mongod`
The two commands should show references to the system-wide libssl and libcrypto.
What I think happened is RedHat updated OpenSSL from 1.0.1e to 1.0.2k, but retained the "1.0.1e" label for compatibility purposes in parts of the code.
So indeed, MongoDB is using system OpenSSL library, which can be verified with ldd.
The issue with version misinformation is because since a while ago (RHEL 6.x releases), RedHat changed SSLeay() function to report build time version as opposed to the run-time:
Because certain applications perform incorrect version check of the OpenSSL version, the actual runtime version of OpenSSL is masked and the build-time version is reported instead. Consequently, it is impossible to detect the currently running OpenSSL version using the SSLeay() function.
MongoDB uses this exact function to report OpenSSL version, here.
So when you use MongoDB packages and see 1.0.1e-fips while the system OpenSSL version is 1.0.2k-fips, this only means that the system where the package was built on had the older OpenSSL version, but the actual runtime version is your system one, 1.0.2k-fips.
Related
In Live server we have perl version 5.6.1,recently we have enabled TLS 1.2 which resulted in a error "500 SSL Negotiation failed". Earlier we have TLS 1.0 we don't have any issues. Enabling TLS 1.2 is unavoidable which is mandatory. How to resolve this issue?
I have searched & found that SOAP-LITE module has to be installed in order to resolve the above issue but the version 5.6.1 does not support SOAP-LITE module. It is available in active perl 5.8 and above version. Is it adviseable to upgrade to 5.8 version inorder to install soap::Lite?
I have used the modules MSSQL::DBLIB and MSSQL::SQLLIB in this project, Will upgrade supports this module?
Given how old your version of Perl is it is very likely that your version of OpenSSL (which is used at the end for SSL connectivity in Perl) is as old too. Support for TLS 1.2 was added with OpenSSL 1.0.1 which was released 2012. Perl 5.6.1 was released in 2000 while in 2012 we already had Perl 5.14.
And it is not unlikely that the rest of your software is similar outdated and unsupported and likely insecure too.
How to resolve this issue?
Finally upgrade your long unsupported software stack. You can try to only update openssl and rebuild Crypt::SSLeay (likely no Net::SSLeay is used yet) to keep changes minimal but I'm not sure that this will work or even compile.
Running a Laravel installation on a RedHat Enterprise Linux 7 server using PHP 7.1. I can see php-pgsql.x86_64 listed in the available yum packages, but it doesn't appear to be compatible with PHP 7.1 (and indeed is listed as version 5.4.16-43.el7_4.1).
On a lark, I tried installing it anyway and physically moved the pgsql.ini and pdo_pgsql.ini files from /etc/php.d into the relevant PHP 7.1 folder /etc/opt/rh/rh-php71/php.d/ (and did the same with the .so files they reference), but that returns an error indicating that the package couldn't be read (undefined symbol: file_globals_id in Unknown on line 0).
Has anyone managed to get PHP 7.1 talking to PostgreSQL on RHEL 7?
The sysadmin who originally created the server for me set me straight. The problem was I was looking in the wrong repository for the packages I needed for my particular PHP installation. Running the following two commands did the trick:
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-odbc
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-pgsql
We then added those two packages to the Ansible playbook so future generations would not suffer needlessly.
We've been using a shipping API via our Unix server, specifically SCO Openserver 5.0.7, for a little over a year.
Our system generates XML files, sends them to the server using the lwp-request command, receives the response, interprets it, and processes it as needed by our system.
The exact command we use is:
lwp-request -m POST https://url.com < REQUESTFILE.XML > RESPONSEFILE.XML
The shipping company is upgrading all servers to require TLS 1.2, and now I get
500 SSL negotiation failed:
as a response when using this command.
I'm not sure how to go about making our system compatible.
Do I need to update Perl? (Current version is v5.8.8 built for i586-pc-sco3.2v5.0). If so, what is the minimum version to use TLS 1.2?
Do I need to update LWP? I believe my LWP version is 5.805 (got this using perl -MLWP -le "print(LWP->VERSION)")
Do I need to go into the lwp-request script and manually modify it?
Or is there perhaps another command that does an equivalent job using TLS 1.2?
Given your very old version of Perl (5.8.8, where 5.8.9 was release 2008) and LWP (5.805, 5.806 was released 2007) on a very old OS (SCO OpenServer 5.0.7, last update around 2009) it is likely that you are also running a very old version of OpenSSL. TLS 1.2 was only specified in 2008 and got available in OpenSSL only with 1.0.1 which was released 03/2012, i.e. several years after any software updates to your system.
You can check it it with openssl version and my guess is that it says something about version 0.9.8, i.e. way too old.
To make TLS 1.2 work on this old system you would need to compile a newer version of OpenSSL (at least the latest 1.0.1) and rebuild the Perl modules interfacing with OpenSSL so that they use this new version. Depending on your setup this might be Crypt::SSLeay or Net::SSLeay. And given how old your system is it is not unlikely that you run in various problems with compiling simply because most don't expect that somebody tries to compile newer software on outdated systems. Thus it might just be easier to upgrade everything to a recent and supported OS instead of trying to fight with an old system.
I'm currently accessing an Oracle database version 9i (9.2.0.8.0) using perl modules DBI (1.613) and DBD::Oracle (1.26). The current scope of the project now requires that I access a version 8i (8.1.7.4.0 ) Oracle database and, according to the DBD::Oracle project, I can only access this second database with a DBD::Oracle version 1.20 or below.
I know I could possibly use the DBD version 1.20 to access both databases, but I was wondering if its possible to have installed the two versions of the DBD module and use the acceptable version for each database (less prone to errors).
I don't believe that the server version has any bearing on the DBD::Oracle version you can use, only the version of the client libraries that you install. The 9.2, 10.1, and 10.2 versions of the Oracle client libraries support connecting to Oracle server 8.1.7.4, and the latest version of DBD::Oracle remains compatible with all client libraries from 9.2 up, so I don't think that you will actually have any problem at all. However, if you install the version 11 client, you will lose the ability to connect to server versions below 9.2.0.
Install the different versions of DBI/DBD::Oracle into two different places, see INSTALL_BASE/--install_base. Access them seperately by setting PERL5LIB appropriately.
local::lib helps you automate this whole affair.
If you want to access the two database versions from the same program run you can do as follows:
install both versions in your system using local::lib
run a DBD::Proxy server with #LIB configured to load one version of DBD::Oracle
run your script with #LIB configured to load the other version of DBD::Oracle
in your script connect to one database using DBD::Oracle as usual and to the other one through the proxy.
I've got 64-bit Vista with ActiveState Perl "v5.10.0 built for MSWin32-x64-multi-thread" and I'm trying to get the Crypt::SSLeay package installed along with versions of libeay32.dll and ssleay32.dll.
I've done this before on a Win32 machine using the 'uwinnipeg' server, but I'm running into issues with my 64-bit system.
ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd
ppm install failed: The PPD does not provide code to install for this platform
I've tried a straight ppm install which seemed to work, but verification fails and I don't see any sign of the dll files?
C:\Perl64\bin>ppm install Crypt::SSLeay
Downloading ActiveState Package Repository packlist...done
Updating ActiveState Package Repository database...done
Syncing site PPM database with .packlists...done
No missing packages to install
C:\Perl64\bin>ppm verify Crypt::SSLeay
ppm verify failed: Package 'Crypt::SSLeay' is not installed
Does anyone know where/how I could get versions that are compatible with my PC?
There are a few issues here: First, AFAIK, you need OpenSSL v1.0.0 or greater for Windows 64. Second, until recently, Makefile.PL in Crypt-SSLeay did not detect correctly OpenSSL versions greater than 0.9.x.
I think you want to upgrade at the very least to Perl 5.10.1 as it fixed a number of crucial performance related bugs.
If you install mingw via ActiveState's ppm (I am assuming ppm install mingw would work even though I haven't tried it on a 64-bit system), you can use it to build OpenSSL 1.0.0a and Crypt-SSLeay.
Update: You probably don't need Crypt::SSLeay. See:
DO YOU NEED Crypt::SSLeay?
Does your code really depend on Crypt::SSLeay?
Don't declare a dependency on Crypt::SSLeay (or IO::Socket::SSL either).
Also useful:
Building OpenSSL 1.0.1g on 64-bit Windows Pro 8.1 with Windows SDK 7.1
Compile Vim and OpenSSL with Visual Studio 2013 Community Edition.
Sinan has very recently released a new version of Crypt::SSLeay which might clear up some Windows installation issues. I doubt it's made its way into a PPM yet.