Customizable port field per site

Thank you for this work. This will be very useful when implementing #394452: Full SSL support, so try to keep that in mind.. I like the idea of having this a separate module: I think it should be simple enough to tear it out in a separate module with proper use of form_alter (?). In the backend, $site_port could just be defaulted to 80 in the templates when not defined.

One thing that is not taken into account in your backend code is that nothing special is done for port 443 (while https:// is specified in the frontend), so that's kind of broken.

anything else missing so this can be "needs review"?

I've been evaluating this for inclusion into a contrib module, and i'm having trouble seeing how to cleanly split it up.

Mostly because doing this the right way ( setting up available ports on the web server, and adding an optional port selection in the site creation form if there is more than one available port and the user has the right permissions), involves modifying the javascript we have.

Also, i'm working on adding a new directory in provision which allows you to override templates. You could add a conditional to the template to add the cert to the vhost if the port is 443. This is a bit of a ghetto way to do it, but it will work for our purposes.

If we don't do this in a module, I'd still like to see conditionals around the user interface parts of this, that are only activated when the experimental feature for non-standard ports is enabled.

I'm willing to make that concession if the easiest way to include this functionality is via a patch and not a module. The very fact that this is so tricky illustrates that we need to look at the API surrounding the site node page.

Also, we need to set up the NameVirtualHost entries somehow, so that probably means introducing a web server vhost file

will apache barf if we declare them multiple times?

As long as each NameVirtualHost is different apache will accept them.
NameVirtualHost 1.2.3.4:80
NameVirtualHost 1.2.3.4:443

NameVirtualHost 5.6.7.8:80
NameVirtualHost 5.6.7.8:443
and so on

Each virtual host container will need to reflect this:

<VirtualHost 1.2.3.4:80>
...
</VirtualHost>

and so on

port 443 must have a specified ip address as the ssl cert is for a specific domain or *.domain

BTW. provision already has a 'web_port' defaulted to 80, so we should change the parameter to that.

Okay, that's good. I still need to review the actual code but it makes sense in theory. Note that we will eventually migrate server-side settings to a server-wide config file (think /etc/aegir/config) so that you will not need to reverify all platforms.

Also, don't you need to make sure apache listens on the given port? In addition to NameVirtualHost, i feel you would need to add a Ports directive...

Maybe it could be possible to just keep config templates ready to use valid SSL cert (when uploaded), but if no cert is uploaded, default self-signed will be used (like in Webmin) to avoid duplicating templates for SSL/noSSL and to avoid building another modules just to have conditional including valid/selfsigned cert?

And one more thing: also SSL is much simpler in Pound: http://drupal.org/node/394452#comment-1807564

~Grace

@david - i don't see how you would need to create DNS records for separate ports. Changing firewall settings could be desirable, but that would be in a separate module. My point is that we shouldn't define policy: it could be nice to allow arbitrary port, and let the admin decide what those proper ports should be, out of the box, per server. In other words, once you let the policy in the hands of the Admin, which controls Aegir mostly through the frontend, you should make Aegir apply that policy, through Ports/Listen and NameVirtualHosts. That may be a bit too advanced to start with and could start with just detecting the setting (and sudo is fine here).

@omega8cc - please keep SSL stuff in the ssl issue. :) This issue is about ports, which are required for SSL, but have a life of their own.

Testing now, it's looking very promising.

only small issue i have so far is that the port field is at the top of the list.

While it makes some conceptual sense to have it right below the domain field, I feel it is less usable there, because the field is populated based on fields underneath it.

So when filling out the form, if you change the platform it changes something you already thought you had filled in.

@David Goode since you're obviously deep in code already...any idea how this will affect installing aegir on a non-standard port? See http://drupal.org/node/566410

I agree with 1) we shouldn't break the site link.

I also agree with point 2) although I don't think it's a blocker.

So I fixed the welcome link and committed that to CVS already. One thing I still not sure about is the "foo.server" file. Frankly, it doesn't seem like a good idea to me.

First, we already defined NameVirtualHost in the vhost file installed with Aegir

Second, it's not enough: I had to do a Listen directive to make sure apache would listen on that port.

Third, I think I would rather leave that to the admin than to let Aegir fiddle with those kind of configurations. It could easily lead to a serious denial of service attack (think Listen 22 or 25) if the Drupal is compromised. For me, the ports listened to (along with the NameVirtualHost directives) are part of the server configuration, and lay outside of Aegir.

Fourth, it's insecure: someone could create a "localhost.server" site and overwrite that file.

I would like to see the reverse: the "server verification" step (yet to be done) would check the apache configuration (apachectl -S) and would detect the ports it would be running as, and send that to the frontend.

I will still commit the code as is (with the fixes for the URL stuff), but I am considering reverting the server configuration part for now.