Apache does not work after server 5.0.3 upgrade

Just to add to this, it seems that my CardDav and CalDav services are stuck since I downgraded to 4.1.5. They're just giving me the spinning wheel. Also the server app is having issues with loading the certificates service screen.

Thanks, this helped fixing it!

Also to note, while the Websites are working, they still show as not accessible in the Server app. Also, my Profile Manager won't turn on now either. Not sure what to do about that. Obviously this has something to do with the certs but it shouldn't be this hard. Come on Apple...

I used to be able to restart apache from the command line, this seems not to work anymore since the update.

I saw this on another thread and it might fix the problems that we are all having too. After doing the initial fix in the first post (editing the .conf file and replacing the placeholders with the path to the certs), which did fix my Websites issue, I still couldn't launch Profile Manager. I noticed after upgrading, I don't remember seeing the "Upgrading your Services" dialog we usually get when the Server app is updated. The suggestion on a different thread said to drag the Server app to the trash and wait for the dialog box that says it detected the Server app being removed. After that dialog, drag the Server app back to the Applications folder and then launch it. It will re-run the setup it normally does and upgrade the services. I did this and lo and behold, my profile manager is working again! This might also fix the Website issue too. I couldn't test it as I already did the other fix. Someone else who is having this issue want to test it? Hope this helps this issue!

My understanding so far, based on the Readme.txt in the apache config folder is that from now on:

- Ports 80 and 443 are "reserved" in the configuration for Apple services (including DeviceManager, Wiki,...)

- Any Virtual host is served from 34580/34543, and there are automatic proxy directives for each host from 80->127.0.0.1:34580 / 443->34543

There is a potential impact on the configuration/code of the virtual hosts (use x-forwarded-for insted of REMOTE_ADDR to get client IP, + any custom port forwarding/proxy you may use).

I think Apple did that to ensure that access to the Apple provided services is working whatever the configuration of your additional custom sites / vhosts.

Thanks for this suggestion. It worked. I deleted Server [dragged to Trash] => Affirmed the Dialog "Server removed.." => Opened up the Trash folder => Dragged Sever back to Applications => Relaunch Server and Affirm subsequent Dialogs. Cheers

Thanks for the explanation of the other prots. I found that after installing Server 5.0.3, my websites were also not available upon relaunch of Server app. I puzzled through these comments and finally just rebooted the server. That was all it took; my sites are restored. No messing around in Terminal required. Hope that helps someone out there. Apple might have mentioned that. - Joe

After the Server 5.03 update I too couldn't serve websites, and after messing with all this for a full day I installed the El Captain beta

and everything works perfectly. I only hope that Apple will get the OS X back into the fine code it used to be!

Upgrading to 5.0.4 seems to fix the problem.

it doesn't over here. I think this is a crappy way to treat us to an update.

How do I get rid of the strange port issue and the fact that REMOTE_ADDR is crapped up?

Updating to 5.0.4 didn't do the trick, sudo serveradmin command web:command=restoreFactorySettings didn't either.

Anyone?

Do I understand correctly that there should be PLACEHOLDER_TEXT in those files to replace with thecert infoform/etc/certificates?

My files do not have "PLACEHOLDER_TEXT"; the path is complete, but apparently wrong.

Anyone else stuck?

Any luck, I am having the exact same issue.

Hi,

Your lsof output indicates that the apache processes using the httpd_server_app.conf config were running, but the apache processes associated with apache_serviceproxy.conf were not working (these configs are in /Library/Server/Web/Config/apache2 and /Library/Server/Web/Config/Proxy respectively). Fixing the SSL cert problem in the apache_serviceproxy.conf file is probably what allowed those apache daemons to start working again.

By looking in either of those config files (or by looking at a process listing, e.g. pgrep -fla httpd) you can find the path to the error log file used by that apache instance. The error log is the best place to look when apache isn't doing what you expect. In the case of the broken service proxy (due for example to SSL cert issues) you would probably see repeating startup failures in that error.log, as apache starts, encounters the fatal error, logs it, and then immediately exits.

It is normal to have a bunch of IPv6 listeners 🙂

Cheers,

-dre

Hi, I have fast the same issue. I cannot reach my sites, they are all redirected to SLL versions which I doesn't have and then the system choose any one site which use SSL. I have 3 sites which use SSL, but they are separate with they own web address.

Please can anybody help me how to repair it or go back to the old version?

Im not so familiar with commands, so please when is possible to tell me exactly what I should do.

Thanks.