Hmm, I am pretty suspicious of the config file
/etc/apache2/vhosts.d/30_subversion_ssl_vhost.conf
When you remove the '-D SSL' you will cause all parts of the configuration files that are enclosed in ... to be skipped. The default SSL vhost file on my Gentoo box is wrapped in that tag so I wonder if, by removing the '-D SSL', you are preventing the config in 30_subversion_ssl_vhost.conf from being run at all and if that is what is allowing Apache to start.
If you temporarily remove the file 30_subversion_ssl_vhost.conf from /etc/apache2/vhosts.d does Apache run? Are there any other SSL related vhost.conf files in vhosts.d? My reasonably fresh/unused Apache install's vhosts.d directory looks like this:
# pwd && ls
/etc/apache2/vhosts.d
00_default_ssl_vhost.conf 00_default_vhost.conf default_vhost.include
edit 1:
So much for that theory :) I am now wondering if the problem is with the Apache SSL setup itself. I apologize if I am covering ground you have already checked but I am wondering if you could do the following to help verify your Apache install.
On my Apache install with working SSL the use flags are as follows:
# emerge -av apache
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] www-servers/apache-2.2.11-r2 [2.2.11] USE="ssl -debug -doc -ldap (-selinux) -sni -static -suexec -threads" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta -charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http -substitute -version" APACHE2_MPMS="-event -itk -peruser -prefork -worker" 64 kB
In particular do you have the 'ssl' USE flag set?
Also, could you use equery to verify the integrity of your apache2 install? If you do not have the equery command you can install it by running 'emerge -av gentoolkit'. The following command should verify the integrity of your apache install:
equery check apache
On my server the above command gives the following output:
[ Checking www-servers/apache-2.2.11 ]
!!! /etc/apache2/vhosts.d/00_default_ssl_vhost.conf has wrong mtime (is 1256620928, should be 1246793824)
!!! /etc/apache2/modules.d/00_default_settings.conf has wrong mtime (is 1246796304, should be 1246793824)
!!! /etc/conf.d/apache2 has incorrect md5sum
* 429 out of 432 files good
edit 2:
Well the install looks good to me, so much for theory 2. I am wondering if we can coax Apache into giving some more information on startup. In /etc/conf.d/apache2 if you change your APACHE2_OPTS line from:
APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE"
to
APACHE2_OPTS="-X -e debug -D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE"
and then start Apache (/etc/init.d/apache2 start) the daemon should stay in the foreground (the -X flag) and output debuging messages as it starts (the -e debug option). Maybe this will give a clue as to why it is dying on startup.
Best Answer
The first thing to be aware of is that you didn't just install two instances of apache, you actually used two different installation mechanisms - one by compiling, the other by using the resident dpkg (called via apt) mechanism.
Neither method is more (or less) valid than the other, and, one can't categorically state you have to use only one method; but you've already identified the first issue with using two different mechanisms - your package manager (dpkg) doesn't know anything about your hand-compiled installation.
The reason you ended up with a version of apache from the apt-get install php5, is that built into the php5 package is a number of dependencies. You can query the packaging database for the dependencies with dpkg-query:
You'll see a link to libapache2-mod-php5, which in turn references the apache that was installed.
As to removal - apt-get remove apache2 will remove the version of apache2 installed by the package manager, but it will not touch (nor would you want it to) files that have been manually added - those will require your careful inspection and analysis of the system.
If you are lucky, the make file that did the install when you typed make install
also has a make remove
In the case of apache2/httpd - you don't have that luxury, but that's a fairly clean install, as installs go, so you should be able to identify the directory that you installed in, and an
rm -rf /usr/local/apache2 (or wherever you installed apache)
should remove most files placed onto your system.
If you don't have a clean install - you'll need to search for the files that were installed on your system.
One typical way of determining what has been added to your system after an installation done manually (works for everything, not just autoconfig installs) is to run the command:
find / -cmin -2 2>/dev/null | egrep -v '^(/proc|/sys)'
You can then use the output of that command to provide you with a list of files that should be considered for removal.
I realize this isn't a soup-nuts guide to removing what has been placed on your system, but the challenges you are experiencing are precisely why people work so hard to use package managers to manage their system (which, in addition to clean adding/removing of files, also provides a number of other useful benefits, such as binary-verification to see if anything has been modified)