Server 5.0.3 redirecting default websites to port 34543

Resetting everything with `serveradmin command web:command=restoreFactorySettings` and then manually reconfiguring the sites again fixed this issue for me.

Morphire wrote:

Now after the upgrade to 5.0.3 the urls direct to webmail.example.com:34543/webmail and leave off the https: which of course breaks everything. The /Library/Server/Web/Config/apache2/sites/ folder now contains .conf files for 0000_127.0.0.1_34543 and 0000_127.0.0.1_34580 as well as the old 0000_and_443 and 0000_any_80 .conf files used previously.

Here's a diagnosis but not a solution.

As mentioned above, Server.app now configures apache to redirect 443 to 34543 and 80 to 34580. You can see these open on the server:

$ nmap -p 34580,34543 localhost

34543/tcp open unknown

34580/tcp open unknown

You can even see your roundcube by visiting 127.0.0.1:34580/webmail/ on the server itself.

Comparing these to the previous virtual host files, ./apache2.previous/sites/0000_any_80_.conf and ../apache2.previous/sites/0000_any_443_.conf, the new files 0000_127.0.0.1_34580_.conf have the new rewrite rules that make it look like your still at your domain when your really at 127.0.0.1:34580:

RewriteEngine on

RewriteCond %{HTTP:X-FORWARDED-FOR} !^$

RewriteCond %{REQUEST_METHOD} !^(PROPFIND|OPTIONS)$

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^(.*)([^/])$ %{HTTP:X-FORWARDED-PROTO}://%{SERVER_NAME}/$1$2/ [R=301,L,NC]

These rewrite rules are the cause of the problem when you attach a "nonstandard" host like /webmail to your url.

The solution is to fix the rewrite rules in ./apache2/sites/0000_127.0.0.1_34580_.conf. We need someone with apache rewrite experience to post a solution, or one of us to go rtfm.

> jaydisc wrote:

> Resetting everything with `serveradmin command web:command=restoreFactorySettings` and then manually reconfiguring the sites again fixed this issue for me.

Sorry, this didn't work for me, though the behavior changed. Now I'm redirected to hostname.domain.tld:34580/webmail.

I also tried using Server.app to add an alias under the host, but this doesn't work either.

A translation of the rewrite:*

RewriteCond %{HTTP:X-FORWARDED-FOR} !^$

RewriteCond %{REQUEST_METHOD} !^(PROPFIND|OPTIONS)$

RewriteCond %{REQUEST_FILENAME} -d

If original_remote_client_address is not blank/empty, AND

If request_method is not PROPFIND and not OPTIONS, AND

If request_url is a path, exists, and is a directory THEN

RewriteRule ^(.*)([^/])$ %{HTTP:X-FORWARDED-PROTO}://%{SERVER_NAME}/$1$2/ [R=301,L,NC]

Match at start of the request_url any character, 0 or more times and put that into $1. Match at the last character of request_url any character that is not "/" and put that into $2.

If above condition is met, construct the rewrite like this (spaces added for clarity):

original_http_protocol (http or https) : // server_name / $1$2 /

send result code 301 (content permanently moved), last rule in chain - stop/end rewrite, non case sensitive

For example:

http://example.com/webmail and

http://example.com/webmail/

will be rewritten as:

http://example.com/webmail/

http://example.com/abc.html

will not be rewritten

*based on my basic regex understanding and server environment variables

If what you are trying to do is to take http://example.com/webmail and rewrite it to https://example.com/webmail

That is, force http to https. You can try adding a rewrite rule. To either the default site config file, 0000_127.0.0.1_34580_.conf, and/or the ones for example.com. Or better yet, in the Include file for example.com so it is safe from being rewritten by the server.

A line like this should work - in a site config file - place it after the last RewriteRule line:

RewriteRule ^(.*)$ HTTPS://%{SERVER_NAME}/$1 [R=301,L,NC]

You will need an additional line if you put it in the Include files:

RewriteEngine On

RewriteRule ^(.*)$ HTTPS://%{SERVER_NAME}/$1 [R=301,L,NC]

Disclaimer:

This should work in theory. I have not tested it (I don't have webapps set up this way). I am not responsible for any bad breath or hair lost as a result of this.

Remember that Safari can aggressively cache redirects. I recommend using curl -I to test instead.

Got this issue too after the "upgrade". Following helped me:

Got a domain, lets call it www.domain.com.

In /Library/Server/Web/Config/apache2/sites I have a file called 0000_127.0.0.1_34580_www.domain.com.conf.

This file starts with:

<VirtualHost 127.0.0.1:34580>

ServerName www.domain.com:34580

ServerAdmin admin@example.com

...

Remove the :34580 and save the file:

<VirtualHost 127.0.0.1:34580>

ServerName www.domain.com

ServerAdmin admin@example.com

...

Then restart you websites from the Server UI and you might have a fix. Works for me until I need to change anything in websites from the Server UI, when doing so the .conf is overwritten with the previous port number.

Hope it helps, if only as a quick fix.

Redirecting to 34580 and 34543 appear to be baked into the new web server design, so I'd be very circumspect about mucking with that without first understanding what's going on.

Here's a puzzle that will help: browsing to known services like /profilemanager works, but browsing to /webmail is broken. Can anyone explain how this is done?

essandess wrote:

Here's a puzzle that will help: browsing to known services like /profilemanager works, but browsing to /webmail is broken. Can anyone explain how this is done?

Can you be more specific about what you mean by broken? Are you getting an incorrect web page, are you getting a 404 page? AND is webmail configured to look for traffic on port 80/443? It is quite possible that webmail is looking at the wrong place now that ports 80 and 443 have been redirected by the time the request hit the custom sites.

As for how the web services works in Server 5.0.3, this is an exchange I had with someone from the Server Engineering Team:

"The custom sites are listening behind a proxy listening on ports 80/443. The custom sites themselves are in a separate Apache instance listening on 127.0.0.1 34580/34543. Some of this is documented in /Library/Server/Web/Config/apache2/ReadMe.txt"

You can also look at this thread for an explanation: https://discussions.apple.com/thread/7219529?start=15&tstart=0

TL;DR version, quoted from user Bi-noix:

"- 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'm having a similar problem after upgrading to Server 5.0.3.

When I visit www.myinsecurewebsite.com, I get the page I expect.

When I visit www.myinsecurewebsite.com/pma, I get the "Can't Connect to Server" error instead of my phpMyAdmin page because it is redirected to

www.myinsecurewebsite.com:34580/pma

It'd be nice if Apple fixed this quickly.

Francis Drouillard wrote:

When I visit www.myinsecurewebsite.com, I get the page I expect.

When I visit www.myinsecurewebsite.com/pma, I get the "Can't Connect to Server" error instead of my phpMyAdmin page because it is redirected to

www.myinsecurewebsite.com:34580/pma

A workaround is to be sure to add the "/" at the end. Like this:

www.myinsecurewebsite.com/pma/

That will work if I'm already logged into phpMyAdmin. If not, I get the login page, but I soon as I enter my credentials and hit return the port number 34580 is inserted into the url.

Seems like this is something that Apple should fix.

Francis Drouillard wrote:

That will work if I'm already logged into phpMyAdmin. If not, I get the login page, but I soon as I enter my credentials and hit return the port number 34580 is inserted into the url.

Yes. Apple should.

It appears that the rewrite rule in the custom site config files in /Library/Server/Web/Config/apache2/sites/ is the cause and only rewriting the urls pointing to directories below top level without the closing "/". Everything else appears to get passed along.

As nill-e posted above, taking out the :34580 in the ServerName line in the custom site config file will solve this problem. However, I have not done enough testing to know if this breaks anything else.

Fortunately, there's an "official" way to tickle this bug, so we can all file bug reports and have some hope that it will be addressed.

Please a file bug report with a title like "Server.app 5.0.3 Breaks Web Server Aliases".

"Official" bug behavior:

Server.app>Websites> Edit website> Aliases> Edit...> Add an alias like /webmail or /phppgadmin

This gives a "500 Internal Service Error" with the message:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at admin@example.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

"Unofficial" bug behavior:

$ sudo vi /Library/Server/Web/Config/apache2/httpd_server_app.conf

Import roundcubemail.conf

where roundcubemail.conf looks like

Alias /webmail "/usr/share/web/roundcubemail"

<Directory "/usr/share/web/roundcubemail">

DirectoryIndex index.php

...

</Directory>

This fails with the error the OP reported: Failed to open page https://host.domain.tld:34543/webmail/

Update: This is combined with a proxy problem.

The problem goes away for me if I reconfigure to go straight to the internet and not use my web proxy.

If you're running custom sites through a proxy service, do not use the proxy service if you want custom sites to work with Server.app 5.0.3. Unfortunately, that goes for all clients on the server and off, so this isn't much of a fix until Apple fixes the bug. Please file your bug reports.

The bug lives somewhere in the plist file /Applications/Server.app/Contents/ServerRoot/Library/Server/Web/Config/Proxy/se rvermgr_serviceproxy_customsites.plist, probably in one of these lines:

<dict>

<key>DEST_BASE</key>

<string>http://127.0.0.1</string>

<key>DEST_PORT</key>

<string>34543</string>

</dict>

<key>type</key>

<string>lines</string>

<key>strings</key>

<array>

<string></string>

<string>#default proxy command</string>

<string>ProxyPass / ${DEST_BASE}:${DEST_PORT}/</string>

<string>ProxyPassReverse / ${DEST_BASE}:${DEST_PORT}/</string>

</array>