Development Stuff for hardware and software configurations
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

180 lines
7.1 KiB

  1. # dubsdot
  2. 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.
  3. # Sections
  4. * Putting your application in place
  5. * Configuring your service with Apache
  6. * Configuring Virtual Hosts
  7. * Connecting your application to Dubsdot
  8. * Static site with no backend
  9. * Dynamic site with backend
  10. * Alternative backend server or other complex configuration
  11. * Control Access
  12. ## Putting your application in place
  13. 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.
  14. For example, if your project is called "FancyApp", you can
  15. ```
  16. git clone<gh username>/FancyApp.git
  17. ```
  18. 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.
  19. ## Configuring your service with Apache
  20. 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.
  21. (fun fact: Apache performs way worse than nginx at the same tasks)
  22. ## Configuring Virtual Hosts
  23. 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:
  24. ```
  25. myservice IN CNAME dubsdot
  26. ```
  27. Basically, what this means is that if the DNS server receives queries for ``, your computer will be directed to connect to the server dubsdot, located at `` with an IP address of, and use a host value of ``. You should also, however, configure your virtual hosts to listen on ``, 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).
  28. ## Connecting your application to Dubsdot
  29. There are a few different ways that you can configure your service on Dubsdot
  30. * Set up a directory, and service html/css/js for a website with no backend
  31. * Set up a directory, and run PHP or other code and html/css/js for a website with a backend
  32. * 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.
  33. ### Static site with no backend
  34. **Use this configuration if you are only serving static files.**
  35. 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:
  36. ```bash
  37. git clone<username>/<myapp>.git
  38. ```
  39. and it will clone your app to `/var/www/myapp`.
  40. Once it does that, become root on the system, and run the following:
  41. ```
  42. cd /etc/apache2/sites-available
  43. ```
  44. Create a new file called `<myapp>.conf` in this folder.
  45. ```
  46. vim <myapp>.conf
  47. ```
  48. Inside that, add some content like this:
  49. ```
  50. # Service: myapp
  51. <VirtualHost *:80>
  52. DocumentRoot "/var/www/myapp"
  53. ServerName
  54. ServerAlias
  55. ServerAlias myapp
  56. </VirtualHost>
  57. ```
  58. Here's the explanation of the various parts of the above configuration:
  59. * `VirtualHost *:80`: Listen on port 80 on any IP(v4?) address
  60. * `DocumentRoot "/var/www/myapp"`: Set the document location root to `/vrestore the file from a`. 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 ``
  61. * `ServerName`: Sets the default server name to listen for when specified by your browser from DNS with the `Host:` HTTP field.
  62. * `ServerAlias`: 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.
  63. Of these, the first and last opening/closing `VirtualHost`, `DocumentRoot`, and `ServerName` are required entries.
  64. **ALLWAYS** have the configuration contained within the `VirtualHost` tags. **DO NOT** put options outside of these! It **WILL** negatively affect other services.
  65. 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):
  66. Enable the website:
  67. ```
  68. a2ensite myapp
  69. ```
  70. Test the configuration:
  71. ```
  72. apachectl configtest
  73. ```
  74. If it fails, run the following so that if the server is rebooted for other reasons, that it doesn't crash the server:
  75. ```
  76. a2dissite myapp
  77. ```
  78. Once you feel confident with the configuration file you have specified, feel free to run the following:
  79. ```
  80. systemctl restart apache2
  81. ```
  82. If your service brings down the apache server, please disable your site.
  83. ### Dynamic site with backend
  84. **Use this configuration if you are doing PHP or something like that.**
  85. **TODO**
  86. ### Alternative backend server or other complex configuration
  87. **Use this configuration if you are using Flask or a custom socket server.**
  88. **TODO**
  89. ## Control Access
  90. Say you want your application to be visible only within Clarkson University.
  91. Modify what you have in your `Location` directive to something like this:
  92. ```
  93. <Location />
  94. Order deny,allow
  95. Deny from all
  96. Allow from
  97. </Location>
  98. ```
  99. To further restrict to COSI, use `Allow from` 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`.
  100. Here's a more complicated example with multiple subfolders:
  101. ```
  102. # root of website
  103. <Location />
  104. Order deny, allow
  105. Deny from all
  106. # allow from Clarkson
  107. Allow from
  108. </Location>
  109. <Location /private>
  110. Order deny, allow
  111. Deny from all
  112. # allow from only within COSI
  113. Allow from
  114. </Location>
  115. <Location /veryprivate>
  116. Order deny, allow
  117. Deny from all
  118. # allow from one particular computer (ex, dubsdot)
  119. Allow from
  120. # add another
  121. Allow from
  122. Allow from
  123. </Location>
  124. ```