Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 432
  • Last Modified:

apache-ssl can't start

Am running Redhat 6.1 and i have installed the following without any error messages:

apache_1.3.12+ssl_1.39.tar.gz
apache_1.3.12.tar.gz
openssl-0.9.5a.tar.gz

However, when i try starting the httpsdctl service is the following message

[root@Mygateway /]# /usr/local/apache-ssl/bin/httpsdctl start
/usr/local/apache-ssl/bin/httpsdctl start: httpd could not be started

I checked the logs and i got this error message:

[Tue Apr 11 00:50:12 2000] [crit] error setting verify locations
[Tue Apr 11 00:50:12 2000] [crit] error:02001002:system library:fopen:No such file or directory
[Tue Apr 11 00:50:12 2000] [crit] error:2006D002:BIO routines:BIO_new_file:system lib
[Tue Apr 11 00:50:12 2000] [crit] error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib

what can be wrong?

thanks.

0
noree97
Asked:
noree97
  • 3
  • 2
1 Solution
 
jlevieCommented:
I use mod_ssl with Apache (that I build from source) so I can't be sure, but it seems odd to me that the startup script is httpsdctl. Apache 1.3.9 used that, but my 1.3.12 versions reverted to apachectl. The lib error about fopen suggests that the copy you installed may not match up with the libc on RH 6.1. Are you sure that what you loaded is supposed to work on 6.1?
0
 
alien_life_formCommented:
Greetings.

Do you have a valid (even if self-generated) certificate? If you don't, that would explain some of the diagnostics.

If you do, try to ldd httpsd (gives you the libraries that httpsd expects) and strace httpsd (expect lots o'output: this shows the system calls it's doing).

Use the no-fork switch (I forgot what it's called) on both counts.

HTH & cheers,
   alf

0
 
noree97Author Commented:
tq... i reverted in using

apache_1.3.9+ssl_1.37.tar.gz
apache_1.3.9.tar.gz
openssl-0.9.4.tar.gz

and i could start the httpsdctl service.

but how would i know which source to use with the designated service?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
jlevieCommented:
I'm not entirely convinced that I understand the last commnet, but I'll wing it.

Personally I prefer mod_ssl over apachessl. I think it works a bit better with less overhead (especially with mm included). If you are considering rolling your own from sources, I can furnish a small readme that will allow you to build an Apache+mod_ssl from the latest (as of a couple of weeks ago). If desired you can include PHP and/or database and/or LDAP support.

Okay, it's soapbox time... Some things that have little in the way of configuration options are reasonable to install from pre-built binaries. Other things like Apache or a database (MySQL, Postgres, PhP, etc) have lots of build time configuration options. I think it's better to learn how to build that class of app from source. You can pick the config options that you need and not have to settle for what somebody else liked. And most of the time it's not that hard to do.
0
 
alien_life_formCommented:
Greetings.

jlevie, I would second your soapbox corner if it were not for package management. Tarballs make an exceedingly poor job of documenting what they install were and supply no mangement facility.

My experience with tarballs is that, unless I carefully track them (by hand), the target machines quickly degrade into an unmanageable mess of oddball files scattered everywhere.
(In truth, some packages provide an uninstall target, but most of times the doc does not mention it, and besides, it usually uninstalls with little regard to the configuration changes that have been made...)

When pressed for customized installations I have recently started to use the .src.rpm, and work onthe spec file, then rpm -ba and rpm -i. Which gets me what I want, except it takes about 10 times more time and effort than ./configure && make install (or about twice if I am working from straight Makefiles - because I have to make changes, generate patches, figure out what is the right order in the diffs, and divine the right way to change the spec file).

What we need is InstallShield for Linux (the better mousetrap?)

Cheers,
      alf
0
 
jlevieCommented:
Ahh, but I don't let them scatter things hither & yon. Those sorts of things go in basically one or two places on any of my systems. In /usr/local or in /opt. By and you pick the location to extract a tarball to and the "install" is self-contained ad is capable of running out of the installation directory.

With very few exceptions, everything that's on my systems, be they Solaris, Linux, FreeBSD or Irix, that winds up in /&/usr comes directly off the installation CD's. Everything else is in /usr/local & /opt. I always make a pretty good sized /opt and /usr/local is typically a link to /opt/local where the files are. Since I have a lot of machines to manage, I simply make a "master copy" of what /opt contains & can copy the base set of data to any machine as needed (or in the case of my Solaris boxes that have a dynamite cache filesystem, I simply access the data via nfs).

So I don't see where package management is a problem. It's a bit more work on my part to create & maintain the /opt data. But you can easily tell what's there by inspection.
0

Featured Post

[Webinar On Demand] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now