July 13, 2020

Adding a site to the SCUTTLE backup scope.

By bluesoul

Today I got word that another website wanted to be included in the SCUTTLE backup scope. I’ve mentioned before there are a couple of steps to make that actually happen, you can probably reason through most of them. DNS has to be set up, then the apache config, then the certificate, then database work to add a Wiki object and a corresponding Domain object.

DNS:

DNS can really be set up any way you want so long as it resolves to the right place, but using CNAMEs for everything but your install root means you only need to update a single record later to migrate the full environment.

Apache:

A typical config block for a SCUTTLE host looks like so:

<VirtualHost *:80>
  ServerName en.scuttle.bluesoul.net
  DocumentRoot "/var/www/scuttle/public"
  <Directory "/var/www/scuttle/public">
    AllowOverride all
  </Directory>
RewriteEngine on
RewriteCond %{SERVER_NAME} =en.scuttle.bluesoul.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

There’s probably a fancier way to do this but I just make a new block for each host. I can’t set up a wildcard record for this domain, if you can you might a much easier route. Anyway, obviously this will match the DNS you just set:

<VirtualHost *:80>
  ServerName brucebase.scuttle.bluesoul.net
  DocumentRoot "/var/www/scuttle/public"
  <Directory "/var/www/scuttle/public">
    AllowOverride all
  </Directory>
RewriteEngine on
RewriteCond %{SERVER_NAME} =brucebase.scuttle.bluesoul.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

The nice thing if you’re using Let’s Encrypt is that you only have to edit a single .conf file, and certbot will handle the SSL config. You may need to restart apache before certbot sees the new host.

SSL:

sudo certbot and following the prompts, expanding the existing certificate. At this point, the new domain should resolve and present a good SSL cert.

SCUTTLE:

On the laravel/DB side, there are two rows to add. You can use tinker, or just insert the data directly. I should get around to adding a route to add these through a web view but it’s low on my list of stuff to do. It’s best to start with the wikis table. Some of it is not actually implemented yet but I encourage you to add the info anyway:

  • subdomain – Will correspond to the subdomain of the root domain that this wiki will always be found at. The idea here is that it’s a backup lookup in case there’s no matching domain in the domains table. Not yet implemented.
  • metadata – Most of this is not yet implemented, but there are some very important items here that are. Metadata is encoded in JSON and looks like so:
{"title": "SCP Cafe Podcast", "locale": "en", "wd_url": "scpcafe.wikidot.com", "wd_site": "scpcafe"}

locale is for the benefit of i18n, wd_url is where the site can be found on the internet, and wd_site is the subdomain of the site at wikidot, which isn’t necessarily the same thing. For example, SCP-RU has a wd_url of scpfoundation.net and a wd_site of scp-ru. You can find these values in the page data on opening a wikidot wiki in your browser, in some javascript variable assignments towards the top of the page:

        WIKIREQUEST.info.domain = "scpfoundation.net";  # wd_url
        WIKIREQUEST.info.siteId = 169125;
        WIKIREQUEST.info.siteUnixName = "scp-ru";  # wd_site

You need both because the API uses wd_site, but 2stacks uses wd_url.

Lastly, a new row in the domains table with the domain you’ve set up, and the wiki_id of your new wiki row. You need at least one record for a wiki to have the JSON metadata {"callback": true} so 2stacks knows which domain to send data back to for this wiki.

Once that’s done, SCUTTLE will begin including that wiki in the backup scope within 60 seconds.