Closed (fixed)
Project:
Hosting
Version:
6.x-0.4-alpha3
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
23 Jun 2010 at 21:53 UTC
Updated:
12 Jun 2014 at 08:59 UTC
Jump to comment: Most recent
At present you configure a set of ports to run on, and when you create a site on a specific platform, it checks it's associated ports to allow you to select one. What happens now when you want to migrate the site to a platform on a server that isn't using those ports?
They were also used for evil in our nascent SSL support by trying to determine whether to use SSL based on port selection. This gets even crazier with web clusters, where they might not all be using the same ports (crazy, but true).
It's my feeling that when you create the service, you can choose one and only one port for the service to run on.
The way I see the SSL working, is that we will create a new service that inherits the Apache class, giving you an Apache +SSL service,
for which you get to choose one additional port to host SSL on.
When you create a site, you do not select a port for that site. That selection is entirely up to how the server was configured. SSL will not be enabled based on which port you select. Instead there will be a simple checkbox that says "Use SSL".
I think that simplification takes care of most of the use cases I've seen, and makes it much simpler for end users, and bypasses a lot of problems we have had to deal with regarding ports.
Additionally, I do not think ports should be a feature, as we can implement it in such a way that doesn't interfere with the end user too much.
We could implement this in such a way that we could resolve #743452: Support non-standard port specification for MySQL Server at the same time.
Comments
Comment #1
adrian commentedmaking very good progress on this in the dev-ports branch.
might even merge it in tonight.
Comment #2
adrian commentedThis is now in HEAD.
we lost entire tables and significantly cleaned up the API.
I have taken the (singular) port and restart command field and added them to the base services object, so any object can take advantage of those simply by specifying they 'has_port', or 'has_restart_cmd'.
This patch reduced a lot of complexity and removed way more code than it added.
I should also note that we are no longer generating the virtual host files in the format of $url_$port, because it added a lot of complexity to manage those changes. We no longer need to keep track of what ports it was using before and try and make sure we keep things in order.
When SSL is implemented the files will be stored in $url_ssl. Same reason.
As part of the upgrade to alpha 9 , we will be regenerating all of the virtual hosts in a new directory anyway, so the upgrade path is already handled for users up to alpha 8. People who were using HEAD should simply delete the vhosts and reverify.