Flexiant Cloud Orchestrator supports four mechanisms for using multiple billing entities:

  1. Each billing entity has its own fully qualified domain name (FQDN) for the control panel. This uses the same IP address as the other billing entities on the same platform. The end user or admin user accesses the control panel using a URL like http://cp.example.com/ (over http on port 80), which (by looking at the URL passed) redirects the user to an https URL. Each of the https URLs run on the same port. For instance, the following table might describe the redirections:

    HTTP URLIP:portHTTPS URLIP:port
    http://cp.example.com192.200.0.1:80https://cp.example.com192.200.0.1:443
    http://cp.example2.com192.200.0.1:80https://cp.example2.com192.200.0.1:443
    http://cp.example3.com192.200.0.1:80https://cp.example3.com192.200.0.1:443
  2. Each billing entity has its own fully qualified domain name (FQDN) for the control panel. This uses the same IP address as the other billing entities on the same platform. The end user or admin user accesses the control panel using a URL like http://cp.example.com/ (over http on port 80), which (by looking at the URL passed) redirects the user to an https URL. Each of the https URLs run on a different port. For instance, the following table might describe the redirections:

    HTTP URLIP:portHTTPS URLIP:port
    http://cp.example.com192.200.0.1:80https://cp.example.com192.200.0.1:443
    http://cp.example2.com192.200.0.1:80https://cp.example2.com:444192.200.0.1:444
    http://cp.example3.com192.200.0.1:80https://cp.example3.com:1444192.200.0.1:1444
  3. Each billing entity has its own fully qualified domain name (FQDN) for the control panel (e.g. cp.example.com). These have individual IP addresses, which are not shared by other billing entities on the same platform. The end user or admin user accesses the control panel using a URL like http://cp.example.com/ (over http on port 80), which (by looking at the URL passed) redirects the user to an https URL. Each of the https URLs run on a the same port. For instance, the following table might describe the redirections:

    HTTP URLIP:portHTTPS URLIP:port
    http://cp.example.com192.200.0.1:80https://cp.example.com192.200.0.1:443
    http://cp.example2.com192.200.0.2:80https://cp.example2.com192.200.0.2:443
    http://cp.example3.com192.200.0.2:80https://cp.example3.com192.200.0.3:443
  4. A combination of 1, 2 and/or 3. Each billing entity has its own fully qualified domain name (FQDN) for the control panel (e.g. cp.example.com). This might share the same IP address as used by other billing entities, or might not. The end user or admin user accesses the control panel using a URL like http://cp.example.com/ (over http on port 80), which (by looking at the URL passed) redirects the user to an https URL. Where an https IP address is shared, the URLs run on a different port. For instance, the following table might describe the redirections:

    HTTP URLIP:portHTTPS URLIP:portComment
    http://cp.example.com192.200.0.1:80https://cp.example.com192.200.0.1:443192.200.0.1 shared across first three BEs, first two share port 443 using SNI
    http://cp.example2.com192.200.0.1:80https://cp.example3.com192.200.0.1:443192.200.0.1 shared across first three BEs, first two share port 443 using SNI
    http://cp.example3.com192.200.0.1:80https://cp.example3.com:444192.200.0.1:444192.200.0.1 shared across first three BEs
    http://cp.example4.com192.200.0.2:80https://cp.example4.com192.200.0.2:443192.200.0.2 dedicated to example3 but shared between services

The advantage of mode 1 (and to an extent mode 2) is simplicity. It is only necessary to add your own DNS. Flexiant Cloud Orchestrator will do the rest for you. The advantage of mode 1 and mode 3 is that as all secure services run on port 443, you will have fewer problems with outbound firewall restrictions at customer sites. Route 4 gives a compromise, but allows for more possibilities for error.

Mode 1 is thus in all respects the best mode, save for one critical factor: in order to distinguish between the different SSL sites running on the same IP address and the same port, the client must support SNI (Server Name Indication). Old browsers (or in the case of Windows browsers, even new browsers on operating systems pre Vista) do not support SNI, and in this instance will not be able to access the control panel at all. Moreover, as the API is accessed using the same URL, the API will not be accessible to API initiators that do not support SNI. SNI is automatically enabled on any HTTPS endpoint where both the port and IP addresses are identical for two or more billing entities.

If two or more billing entities share names that resolve to the same IP and port for their HTTPS URL, the control panel may not be accessible to clients with old browsers / operating systems that do not support SNI, and the API may be not be accessible to programatic clients that do not support SNI.

 

Flexiant Cloud Orchestrator automatically supports all of these modes of operation. You do not need to tell it which mode you are using. During testing, you may choose to enter IP address addresses (rather than domain names). In this case, no two sites must share both the same numeric IP address. Note certificates will not validate using IP address.

If using numeric IP addresses, ensure no two sites share the same IP address.

The address to use when managing a billing entity is the full HTTPS URL including the port number (unless you are using port 443, i.e. the default port). In the examples above, this would be the data in the column headed 'HTTPS URL'. So, in the first example, the URL to use for the second BE would be https://cp.example.com:444 

Flexiant Cloud Orchestrator will automatically generate the redirects (i.e. the HTTP URLs above) to the correct HTTPS URL.

Managing your DNS

Whatever method you use, you need to ensure that appropriate DNS entries are generated for your billing entities. You will want a DNS entry for the control panel. This can point at either an existing interface (if you are using mode 1 above) or a new interface (if you are using mode 2 above), or either (if you are using mode 3).

Using NAT, firewalls and load balancers

Flexiant Cloud Orchestrator determines the IP addresses on which to listen using DNS. So, if you specify a URL of https://cp.example.com//, and cp.example.com looks up to 192.200.0.1, Flexiant Cloud Orchestrator will look up cp.example.com in DNS and conclude it should listen on IP address 192.200.0.1. This assumption is almost always correct. However, in some advanced configurations this assumption does not work. For instance, if the control panel concerned is behind a NATing firewall, the external IP address might be 192.200.0.1, but the internal IP address (on which the server should listen) is 10.100.100.1. In this case, Flexiant Cloud Orchestrator has no way of knowing that it should listen on 10.100.100.1 rather than 192.200.0.1. You can specify this manually by using the /etc/extility/hosts.override file, which overrides hosts lookup when building the apache configuration, and makes Flexiant Cloud Orchestrator listen on the specified IP address. The format is broadly the same as the /etc/hosts file. In this instance, the relevant entry would be:

 
10.100.100.1 cp.example.com
 

This file can also be used to standard host settings provided behind NAT devices, firewalls or load balancers. See Use of NAT, firewalls and load balancers for more details; this also contains a load balancing example.

Managing your network interface configuration

If you are using mode 3 above, or mode 4 with a new network interface, you will also need to add a new network interface to the machine. Use the standard Ubuntu techniques to do this. In brief:

  1. Find an unused IP in the range allocated for the management server.
     
  2. Still on the management server go to /etc/network.
     
  3. Edit the /etc/network/interfaces file on FCO management server.
     

  4. Add an entry similar to the following to the bottom of the file 

    auto eth0:1
    iface eth0:1 inet static
            address 192.200.0.2
            netmask 255.255.255.0

     

  5. Adjust the above such that:
    1. The characters before the colon interface name ('eth0:1' above) represent the correct outbound facing interface
    2. The number 1 (in 'eth0:1' ) is unique and in sequence
    3. The interface name is the same in both places
    4. The IP address is a unique IP address on the same IP range as the existing entry
    5. The netmask matches the netmask you are using.
       
  6. Save the changes
     
  7. Bring the interface up by typing the following (substituting the interface name used)

    ifup eth0:1

It is worthwhile testing the control panel URLs with the Fully Qualified Domain Name (FQDN) and the numeric IP URL to ensure that each billing entity is pointing at the correct control panel.

Important Considerations

The control panel URLs must begin with 'https://'.

If you add or change billing entity URLs, then you must rebuild the configuration - see Rebuilding Config.

Billing entity web sites will not be configured or function properly unless the DNS settings for the URL point to the control panel machine in question.

As the control panel sites are accessed over a secure connection using the https protocol, they need an SSL certificate to function correctly. Flexiant Cloud Orchestrator will generate a 'self-signed' certificate if no certificate exists. These self-signed certificates are not signed by a trusted certification authority, and thus will produce security warnings on browsers. The certificate public and private keys are held in /etc/extility/skyline/ssl/certs and /etc/extility/skyline/ssl/private (for the public and private components of the certificate respectively). They will be named with file names similar to extility-skyline-26562fbd-19ac-4644-a265-5e86269a5973.crt, the filename indicating the UUID of the billing entity. You can replace these with your own certificate. We strongly recommend you keep a master copy of the certificate somewhere other than on the machine in question. After changing SSL certificates, you will need to run the command build-config -a to apply the changes. In some cases it may also be necessary to use the service apache2 reload command.