operations/dubsdot.md

dubsdot

Adding or modifying dubsdot services are relatively easy. Please make sure that you don't interrupt other services on this shared hosts. Also, DO NOT run services from an LDAP user; use a local account if the service can't be run as the nobody or www-data user. Please request help if you are having problems. Also, DO NOT EVER directly edit the /etc/apache2/apache2.conf file without prior permission! Use sites-available folders with separate files for each service instead PLEASE. Also, don't declare things in the global scope of your configuration files, only within your VirtualHost definitions.

Sections

• Putting your application in place
• Configuring your service with Apache
• Configuring Virtual Hosts
• Connecting your application to Dubsdot
  • Static site with no backend
  • Dynamic site with backend
  • Alternative backend server or other complex configuration
• Control Access

Putting your application in place

It is very discouraged to run applications out of your LDAP folder, and rather to create yourself a folder in /var/www where you can run your application from. If the application does not actually use a website directory served by Apache, you can alternatively create a folder in /opt to store your custom socket application.

For example, if your project is called "FancyApp", you can

git clone https://github.com/<gh username>/FancyApp.git

while in the /var/www folder, and it will create the /var/www/FancyApp folder in the correct directory with your code within that folder.

Configuring your service with Apache

Your web service probably should be integrating with the webserver in one of a few select ways. No matter what, you have to interface with the currently running webserver. Right now, that's Apache 2, although we plan to move to nginx in the near future to make it easier to handle configuring applications, as well as much increased performance.

(fun fact: Apache performs way worse than nginx at the same tasks)

Configuring Virtual Hosts

In all cases, you will be setting up a new CNAME record on the DNS server to point at Dubsdot. (feel free to ask for help with this) For example, you may add a line like this to the BIND server:

myservice   IN CNAME  dubsdot

Basically, what this means is that if the DNS server receives queries for myservice.cslabs.clarkson.edu, your computer will be directed to connect to the server dubsdot, located at dubsdot.cslabs.clarkson.edu with an IP address of 128.153.145.200, and use a host value of myservice.cslabs.clarkson.edu. You should also, however, configure your virtual hosts to listen on myservice.cosi.clarkson.edu, as well as myservice, since you also want it to work when we use domain name search on the local machines (you may have been told to go to fsu/ in the past, for example), as well as when you connect from our other domain name(s).

Connecting your application to Dubsdot

There are a few different ways that you can configure your service on Dubsdot

• Set up a directory, and service html/css/js for a website with no backend
• Set up a directory, and run PHP or other code and html/css/js for a website with a backend
• Configure a separate service to handle requests on a different port, and redirect these requests through Apache 2 using a reverse proxy. This works for more complicated applications, and can be connected in various different ways.

Static site with no backend

Use this configuration if you are only serving static files.

To configure your static website with no backend, clone your website to /var/www/<myapp, as seen above. For example, while in the /var/www folder, run:

git clone https://github.com/<username>/<myapp>.git

and it will clone your app to /var/www/myapp.

Once it does that, become root on the system, and run the following:

cd /etc/apache2/sites-available

Create a new file called <myapp>.conf in this folder.

vim <myapp>.conf

Inside that, add some content like this:

# Service: myapp
<VirtualHost *:80>
  DocumentRoot "/var/www/myapp"
  ServerName myapp.cslabs.clarkson.edu
	ServerAlias myapp.cosi.clarkson.edu
	ServerAlias myapp
</VirtualHost>

Here's the explanation of the various parts of the above configuration:

• VirtualHost *:80: Listen on port 80 on any IP(v4?) address
• DocumentRoot "/var/www/myapp": Set the document location root to /vrestore the file from a backup.ar/www/myapp. Say that you have a file called index.html at /var/www/myapp/index.html, with the value set here, you will find your index.html at http://myapp.cslabs.clarkson.edu/index.html
• ServerName myapp.cslabs.clarkson.edu: Sets the default server name to listen for when specified by your browser from DNS with the Host: HTTP field.
• ServerAlias myapp.cosi.clarkson.edu: Additional server names to listen for on the website, if they mach, you will get directed here the same way as with ServerName. This field is optional, ServerName is not.

Of these, the first and last opening/closing VirtualHost, DocumentRoot, and ServerName are required entries.

ALLWAYS have the configuration contained within the VirtualHost tags. DO NOT put options outside of these! It WILL negatively affect other services.

After you have created your file, feel free to run the following as root (they will fail to auto-complete if you are not a root shell because stupid):

Enable the website:

a2ensite myapp

Test the configuration:

apachectl configtest

If it fails, run the following so that if the server is rebooted for other reasons, that it doesn't crash the server:

a2dissite myapp

Once you feel confident with the configuration file you have specified, feel free to run the following:

systemctl restart apache2

If your service brings down the apache server, please disable your site.

Dynamic site with backend

Use this configuration if you are doing PHP or something like that.

TODO

Alternative backend server or other complex configuration

Use this configuration if you are using Flask or a custom socket server.

TODO

Control Access

Say you want your application to be visible only within Clarkson University.

Modify what you have in your Location directive to something like this:

<Location />
  Order deny,allow
  Deny from all
  Allow from 128.153.0.0/16
</Location>

To further restrict to COSI, use Allow from 128.153.144.0/23 in replacement for the other Allow statement. You can also add additional Allow (or Deny) entries as needed to the end, for example, for a single IPv4 address, do Allow from 128.153.145.200/32.

Here's a more complicated example with multiple subfolders:

# root of website
<Location />
  Order deny, allow
  Deny from all
  # allow from Clarkson
  Allow from 128.153.0.0/16
</Location>
<Location /private>
  Order deny, allow
  Deny from all
  # allow from only within COSI
  Allow from 128.153.144.0/23
</Location>
<Location /veryprivate>
  Order deny, allow
  Deny from all
  # allow from one particular computer (ex, dubsdot)
  Allow from 128.153.145.200/32
  # add another
  Allow from 128.153.145.201/32
  Allow from 128.153.145.202/32
</Location>