Yesterday I was able to successfully install IBM HTTP Server, and everything was working great until I attempted to begin configuring the SSL settings.
When attempting to load the SSL module by adding the following to my httpd.conf file:
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
...the server will fail to start up, and I see the following in my error_log:
[Tue Feb 17 16:33:29 2015] [info] mod_unique_id: using ip addr <removed>
(20019)DSO load failed: SSL0166E: Failure attempting to load GSK library (libgsk8ssl_64.so), libgsk8ssl_64.so: cannot open sharedobject file: No such file or directory
Configuration Failed
I have confirmed that I have GSKit installed with the gskver command:
libgsk8ssl_64.so
============
#(#)CompanyName: IBM Corporation
#(#)LegalTrademarks: IBM
#(#)FileDescription: IBM Global Security Toolkit
#(#)FileVersion: 8.0.50.34
#(#)InternalName: gskssl
#(#)LegalCopyright: Licensed Materials - Property of IBM GSKit
(C) Copyright IBM Corp.1995, 2014
All Rights Reserved. US Government Users
Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
#(#)OriginalFilename: libgsk8ssl_64.so
#(#)ProductName: gsk8g (GoldCoast Build) 140910
#(#)ProductVersion: 8.0.50.34
#(#)ProductInfo: 14/08/13.01:22:06.14/09/10.13:23:58
#(#)CMVCInfo: gsk8g_140909/gsk8g_ssl gsk8g_140909/gsk8g_cms gsk8g_140909/gsk8g_support gsk8g_140731/gsk8g_pkg gsk8g_140909/gsk8g_acme gsk8g_140909/gsk8g_doc gsk8g_140909/gsk8g_ikm
No other modules seem to be causing any issues. I'm at a bit of a loss as to what is causing this. Any ideas?
Check out the apachectl and envars scripts. Especially envars. Sometimes these scripts are modified for running third party modules. The path for the GSKit libraries are typically set up in the envars script.
I found the shared library symbolic links were missing from /usr/lib and /usr/lib64. If you (re)create these links, it may clear your problem. I navigated to the library directory (/usr/lib64 in this case) and ran (as root):
for name in $(ls -1 /opt/IBM/WebSphere/HTTPServer85/gsk8/lib64);
do ln -s /opt/IBM/WebSphere/HTTPServer85/gsk8/lib64/$name ./$name;
done
Of course change the source directory to what ever your install standard is. It created all the links necessary in my case.
A.
Related
I'm getting a wired error when loading Apache (Win 2016 STD, Apache/2.4.29 x86, OpenSSL/1.0.2n SVN/1.9.2)
i.e.
"Syntax error on line ... of .../conf/httpd.conf:
Cannot load ...modules/mod_dav_svn.so into server: (...) The specified module could not be found:"
The file is in the conf file properly: "LoadModule dav_svn_module modules/mod_dav_svn.so"
The file exists in the "modules" folder.
Although Apache reports a syntax error, it is not because other modules are loaded just fine with the same syntax.
Other file also has this problem: "mod_authz_svn.so".
Prerequisites are loaded before this module successfully (mod_dav.so, mod_dav_fs.so).
The best part: in my lab it is working just fine but in the customer's machine (same OS mentioned), something is not working properly.
I really need any help you can give me here...
mod_dav_svn.so is from subversion server - so it does not come with apache and has to be added. If you have - then to problem might be that a visual c++ runtime of another version is required. To find out you could try a tool like dependecy walker.
When all missing dependencies are installed on the system your apache should start.
I am running an Windows Server 2008 R2 Enterprise with an Apache Server installed and mod_perl & mod_ssl
I just installed Apache2::ModSSL, but i was not able to use cpan for this and had to compile it using nmake. CPAN is not working correctly on this Server and i am not able to change this.
A perl script called via https should later be able to Access the certificate the Clients used to authenticate, thats why i want to use Apache2::ModSSL to Access the SSL variables.
When i try to acess my test script after implementing
use Apache2::ModSSL;
i get an HTTP500 error from the Server.
The Servers error log states
[Fri Jul 01 15:01:58 2016] [error] [client 10.217.139.184] failed to resolve handler `ssl::hello': Can't load 'C:/Apache/Perl/site/lib/auto/Apache2/ModSSL/ModSSL.dll' for module Apache2::ModSSL: load_file:The specified module could not be found at C:/Apache/Perl/lib/XSLoader.pm line 68.\n at C:/Apache/Perl/site/lib/Apache2/ModSSL.pm line 8\nCompilation failed in require at ssl/hello.pm line 7.\nBEGIN failed--compilation aborted at ssl/hello.pm line 7.\nCompilation failed in require at (eval 3) line 3.\n
When i check the file Location, ModSSL.dll is stored at exact this path. I also checked the file Access and granted Full acess to All Users, System, Administrators etc. Apache was restarted multiple times and it did not Change anything.
When i tried to execute it in a cmd, obviously there was no Connection to check but i could execute
use Apache2::ModSSL;
print Apache2::ModSSL->VERSION;
without Problems.
How to solve the issue with loading the module within Apache?
Server readme states
This is a binary distribution for Win32 of Perl 5.8.7 and Apache
2.0.54, together with mod_perl-2.0.1, mod_ssl / OpenSSL (0.9.7g), and php-4.3.11, all built with VC++ 6.0 (SP5).
cl -version states
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
nmake -version states
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Without investigating too deeply, the most likely reason for your problem is that perl, OpenSSL, mod_ssl etc where compiled with a different compiler than the one you used to build Apache::ModSSL.
It seems to me that the module only tries the XS version if it thinks it's running under mod_perl. You can see this in the module's Apache2/ModSSL.pm:
XSLoader::load __PACKAGE__, $VERSION
if( exists $ENV{MOD_PERL} and $ENV{MOD_PERL}=~/mod_perl/ );
It only tries to load the XS component if the MOD_PERL environment variable exists and it contains mod_perl. My guess is if you did:
C:\> set MOD_PERL=mod_perl
C:\> perl -MApache2::ModSSL -e "print $Apache2::ModSSL::VERSION"
you would encounter problems.
In addition, I feel I must emphasize the facts that your OpenSSL version in addition to perl and php seem too old to be used safely.
Problem: I am trying to compile the Apache web server using the latest sources of httpd, apr and apr-util, and enabling LDAP support. My current steps do not seem to be commpiling mod_ldap.so and mod_authnz_ldap.so.
Environment background: Build and target OS are RHEL5. A non-LDAP enabled instance of httpd is already on the server (2.4.1) and SVN 1.7.3 is already installed and works anonymously with httpd-2.4.1
Steps to reproduce:
Following the compilation instructions here I have downloaded:
httpd-2.4.4 in /path/apache/src/httpd-2.4.4
apr 1.4.6 in /path/apache/src/apr-1.4.6
apr-utils 1.5.2 /path/apache/src/apr-util-1.5.2
OpenLDAP and Berkley DB (for the LDAP libraries to build apr-util against) in /path/openldap-2.4.35_src and /path/db-5.3.21_src
With the sources in place, I:
compiled BDB and installed it to /path/db-5.3.21
compiled OpenLDAP using the installed BDB and installed it in /path/openldap-2.4.35
configured apr, compiled and installed it in /path/apache/apr
configured apr-util with:
./configure --with-ldap --prefix=/path/apache/apr-util-1.5.2 --with-apr=/path/apache/apr-1.4.6 --with-ldap-lib=/path/openldap-2.4.35/lib --with-ldap-include=/path/openldap-2.4.35/include
Afterwards, I built and installed with make and make install.
Finally, I configured httpd with the following:
./configure --prefix=/path/apache/httpd-2.4.4 --with-apr=/path/apache/apr-1.4.6 --with-apr-util=/path/apache/apr-util-1.5.2 --with-pcre=/path/apache/pcre-8.30 --with-ldap --enable-ldap
This was successful, and I was able to run make and make install
I now have a httpd instance in /path/apache/httpd-2.4.4/. Using /path/httpd-2.4.1/httpd.conf as a model, I matched the existing configuration and loaded modules, adding:
LoadModule mod_ldap modules/mod_ldap.so
LoadModule mod_authnz_ldap modules/mod_authnz_ldap.so
However, if I run apachectl start I get a syntax error:
/path/apache/httpd-2.4.4> ./bin/apachectl start
httpd: Syntax error on line 148 of /path/apache/httpd-2.4.4/conf/httpd.conf: Can't locate API module structure 'mod_ldap' in file /path/apache/httpd-2.4.4/modules/mod_ldap.so: /path/apache/httpd-2.4.4/modules/mod_ldap.so: undefined symbol: mod_ldap
Looking within the httpd-2.4.4/modules directory, the modules mod_ldap.so and mod_authnz.ldap.so are missing. I have tried the above steps without success. I have discovered that within the src/httpd-2.4.4 directory, the files ./modules/aaa/.libs/mod_authnz_ldap.so and ./modules/ldap/.libs/mod_ldap.so exist, but copying those over to httpd-2.4.4/modules does not alleviate the issue.
Can someone assist me in diagnosing the error in my steps? I know I'm missing something, but I have been unable to find it so far. I will also add any other required information if needed.
As configured above, LDAP is supported through a shared module. To enable the modules defined (including LDAP in my case) you need to configure apache with the --enable-so flag. This will generate the shared modules and place them within the modules directory when compiled/installed.
Additional reference can be found in this SO article: Compiling Apache Web Server with Dynamic Module Support
ERRORS:
When checking out a large project we receive error on a random file in the project:
Could not read response body: SSL error: decryption failed or bad record mac
Response was to disable SSL and restarted SVNServer.
Retested and got this error:
chunk delimiter was invalid
So examined the SVNserver log:
Error writing base64 data: APR does not understand this error code [500, #620018]
Provider encountered an error while streaming a REPORT response. [500, #0]
A failure occurred while driving the update report editor [500, #620018]
We can recreate the above 100% of the time.
TRIED:
From here we tried:
Upgraded OpenSSL to latest version. Resulted in same errors above.
Copied the REPO to a new REPO to ensure no file corruption. Resulted in same errors above.
Installed SVNserver locally and tested taking network our of the equation. Resulted in same error above.
We think this may be isolated to the version of OpenSSL we are using with some other component installed with VisualSVN.
Anyone aware of this issue and how to resolve it ?
COMPONENTS/SETTING:
Windows 2008 Server R2
Apache Subversion 1.7.6
Apache HTTP Server 2.2.22
OpenSSL 0.9.8x
Neon 0.29.6
Serf 1.0.0
SQLite 3070603
ZLib 1.2.3
VisualSVN 2.5.6
SSL enabled
Windows 7 x64 pro client nodes
Do you have Nod32 installed? If yes then disabling protocol filtering can help. Best solution is to add exception for SVN.
Nod32 -> Advanced setup -> Web and email -> Protocol filtering -> Excluded applications -> check you client, mine is TortoiseProc.exe
The real error is Too many open files [500, #24]. I assume you're using *nix based Subversion server. In this case increase number of open file descriptor with the ulimit command:
ulimit -n 99999
See also: https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
I tried everything I could think of, but I always get this error when I try to start the Apache FtpServer service.
Windows could not start the Apache FtpServer on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 0.
Has anyone got Apache FtpServer to function as a Windows service in Windows 7 or even Windows Vista?
Note:
My Java_HOME environment variable is set as c:\java and I have a symbolic link, linking this directory to the longer C:\Program Files\Java\jdk1.6.0_17.
I also have another symbolic link pointing c:\ftp to the longer C:\Program Files (x86)\Apache Software Foundation\apache-ftpserver-1.0.3.
The only reason I did any of this in the first place is because I was reading that some people were having problems with spaces or long path names, but I tried physically moving the directories as well, all with the same error.
I had the same issue today using apache ftpser 1.0.5., the error message was "Failed installing 'ftpd' service".
The solution was to start the DOS command shell as "Administrator".