Customizable IP address in vhost file

Hi ixlr8

I think you mean customisable port rather than IP?

There's actually quite a bit of work going on on this right now to get more versatility for vhosts into the 0.4 release.

There's going to be support for different ports - essentially to support SSL and port 443.

There's a workaround for using SSL with Aegir at http://groups.drupal.org/node/25038.
This workaround creates a separate vhost file that aegir won't overwrite, and you don't have to hack any of the template files.

I think this answers your question, so I'm closing the ticket - but do feel free to reopen if I haven't answered your question fully.

cheers
Steve

I needed the same thing, so I took a stab at it. ( Please note: I'm new to Drupal, new to contributing ; though I made an effort to follow the Drupal coding standards and patch submission suggestions, I might've done something very wrong! I'm totally open to constructive criticism. )

Attached are two patches... one for the hosting module, and one for the provision module.

The patch for the hosting module adds an ip_address field to the site nodetype. It's optional -- if left unspecified, displays as default "*".

The patch for the provision module simply makes use of the new per-site ip address field -- if present, uses it in the apache vhost templates.

Being a newcomer to Drupal and Aegir ( which I'm really excited about ), I fear I may have taken a very naive approach at how to implement this feature request. Is there another subsystem of Aegir I should've taken into consideration?

Thanks so much,
Brady

Thanks for this excellent work! This will indeed be a great addition and a requirement for full ssl support (which I actually forgot about in the design).

The first patch on provision misses a critical part. It needs to *record* the site_ip_address in the drushrc. For that you need a post_provision_verify() hook in your verify file. Take a look at the way SSL does it:

--------------------------- ssl/verify.provision.inc ---------------------------
new file mode 100644
index 0000000..626eb34
@@ -0,0 +1,9 @@
+<?php
+
+// $Id$
+
+function drush_provision_ssl_post_provision_verify($url = NULL) {
+  if (PROVISION_CONTEXT_SITE) {
+    drush_set_option('ssl', drush_get_option('ssl'), 'site');
+  }
+}

That make sure the 'ssl' flag is kept in the drushrc.php (believe it or not ;).

+  $ret[] = update_sql("ALTER TABLE {hosting_site} ADD COLUMN ip_address varchar(15)");

This should use the new Drupal 6 shema API.

+function _hosting_site_form_ip_address($node = NULL) {

I'm not sure i see the need for a specific function to generate a single form element, unless it's used more than twice.

This is otherwise great work and barring problems in further testing (and provided the above is fixed) I'm ready to sponsor this patch in. I would request, however, two more features before this is actually released:

1. there should be a "use specific IP addresses" permission that would block all this functionality in the frontend
2. there should be a check to see if the IP is already in use by another site (or is that necessary?)

I think we may have a problem when our configurations mix name and ip-based configurations... Any thoughts on that?

Otherwise, one thing that will be missing for SSL is "ip pool management" (be able to say, here, I have a 1.2.3.4/24 and they are allocatable addresses). We should also be able to assign IP quotas to clients and even sometimes complete IP pools to clients.

Thanks so much for reviewing the patches and offering your advice.

You're right about needing permissions/security on whether or not to allow using custom IP addresses. I totally forgot about the fact that clients will be using this -- not just sysadmins.

Regarding your #2... it's "always" OK if the IP/port combination is in use by another site (when using NameVirtualHost) UNLESS it's SSL! (Because the HTTP request is encrypted, Apache can't inspect the Hostname requested to figure out which VirtualHost should handle it... so it HAS to use the ip/port combination... and either picks the first or last one it comes across.)

So I'm thinking my approach was way too simple... I need to take a step back and consider how IP management fits into all the other aspects of Aegir... not just the one little tiny piece I was interested in.

Some questions to consider...
1. Would we ever want one site to have more than one IP address? (I know when I make a DNS change, which may take a couple of days to propagate, I duplicate the VirtualHost entry so Apache will serve the same website at both the old and new IP addresses. Otherwise, the website could appear down to some for a day or two.)

2. What should happen when you migrate a site to a different webserver? (If allowed, pick from allowed IP addresses for the new webserver?)

Seems like I had more questions... all I can think of for now. Any thoughts on these, anyone?

Right, you are correct about the SSL + multiple IPs (or almost: it's possible to have multiple hosts with wildcard certs, iirc).

I don't think you need to redo the whole patch: it's a very good start and we can build upon it. Just add permissions and dupe-checking stuff (plus cleanup) and it goes in.

Now for your questions:

1. Would we ever want one site to have more than one IP address? (I know when I make a DNS change, which may take a couple of days to propagate, I duplicate the VirtualHost entry so Apache will serve the same website at both the old and new IP addresses. Otherwise, the website could appear down to some for a day or two.)

I can't think of (another) proper use case for this right now. I've worked on arbitrary vhost management too, which could workaround that issue by creating a redirect on another IP... I would say: do not make it support multiple IPs per site now, but don't make it especially and unnecessarily hard to extend later either.

2. What should happen when you migrate a site to a different webserver? (If allowed, pick from allowed IP addresses for the new webserver?)

Well, that's a really more tricky issue. I guess it should reset to *.

Another thing i just thought of: we may want to manage the IPs allocated to the webserver, in the frontend. That could be a new field in the webserver node (allowed_ips). When verifying the server (a coming task to develop see #586000: make a "server verify" task ), we would check the output of ifconfig (or ip addr list or whatever) to see which IPs are available on this server and use that list. Conversely, we may want instead to directly allow the admin to decide of the server's IP configuration (in multi-server) setups and give Aegir complete control over IP allocation, for example.

I am very interested in this feature as well. Perhaps soon I will be familiar enough with the Aegir codebase to contribute some code to this patch.

subscribing

This isnt going to work this way anymore. It will assign an ip address to a certificate and use that IP for any site using that certificate.

this is also similar enough to #712958: Assign IP to virtual host based on SSL certificate chosen. to be considered a duplicate.