Custom domains for websites
TIG provides the lab a webserver cluster (designed and implemented by Erin Roberts) which makes it easy for us to support custom domains for CSAIL websites. (You will need to manage the content yourself; we just arrange for the web cluster to serve the content on the correct domain from the correct place.)
Unlike our generic shared domains, custom domains can be configured for dynamic content (PHP, CGI scripts, and server-side includes).
If your custom domain is something.csail.mit.edu,
setting things up is pretty easy and TIG can handle creating the domain
you ask for.
If your custom domain is something.mit.edu, it’s
still not too hard and either TIG or you can coordinate with IS&T to
get the domain created as an alias for our web cluster’s front-end, and
TIG can arrange for the web cluster to serve your content.
If your custom domain is a non-MIT domain, you’ll need to handle getting
DNS set up yourself (and usually register the domain yourself), but
TIG can tell you what to make the DNS records for the domain look like.
In this case, you may need to be prepared to make DNS changes to your
domain from time to time when and if we make technical changes to our
web cluster. (This is more complicated if you want a second-level
domain like mycoolproject.developer or mycoolproject.com to point
at your content; it’s considerably easier if you want a subdomain of
your custom domain, like mycoolproject.myresearchwebsite.org, or even
www.mycoolproject.com as long as you don’t need the same content served
from the shorter mycoolproject.com. But any of these can be made
to work.)
If you are serving dynamic content from CSAIL, you are responsible for upgrading and maintaining your code and keeping it secure. Depending on what tools you’re using this might mean upgrading for compatibility, keeping up with security-related announcements for your tools, responding promptly and fixing problems if we (TIG) or IS&T notify you of potential vulnerabilities, and upgrading to maintain compatibility when TIG upgrades the web-cluster server OSes. If a dynamic website is not kept secure and up-to-date, TIG may disable it until its maintainer fixes it. If we need to contact you about a website, we’ll contact the person (or people) who originally requested the web domain, as recorded in our web-cluster configuration. If you leave CSAIL (or your responsibilities shift) and somebody else is taking over the website from you, it’s your responsibility to make sure we know about the change and we have the new website maintainer listed.
Requesting a custom domain for a website
To request a custom domain for a website, send mail to help@csail.mit.edu telling us:
- what domain you want the website on
- Usually this is
something.csail.mit.edu - As described above, if it’s a non-CSAIL, non-MIT domain, you’ll need to set up the DNS entries yourself, which usually means registering the domain yourself.
- Usually this is
- who at CSAIL will be responsible for the domain (this is who we’ll contact if there are any problems down the road)
- where in AFS the content for the website will be hosted
- We also have a mechanism for checking your content out of a Git repository, which can be somewhere at CSAIL or someplace else like GitHub. If that’s what you want to do, check with us for more information.
- (Theoretically, we can also serve static sites from NFS, but the normal reason to have a website serve content from NFS is because you want to serve a large dataset that’s already there, and our dedicated data.csail.mit.edu website is designed explicitly for that purpose. We cannot under any circumstances support dynamic content served from NFS, and all content served from NFS must be world-readable in the filesystem since the AFS permission model we use for serving sites from AFS is not available. AFS is much preferred if practical.)
- whether your website will be purely static (just HTML, CSS, images, PDFs,
and other files served as-is), or whether it needs dynamic functionality
like PHP, CGI scripts, or server-side includes.
- We strongly encourage static websites wherever possible! Besides being much safer and easier for us to support, static websites are much more future-proof and less vulnerable to failing due to cluster upgrades or changes in the software ecosystem.
- JavaScript executed purely client-side does not prevent your website from counting as “static” for our purposes.
Some other capabilities we may be able to offer
The questions above will suffice for most websites, but we have some additional functionality we can provide if you need it. Send us mail at help@csail.mit.edu if you think you need any of these features:
- Restricting access only to CSAIL users, or only to members of a particular CSAIL group, and requiring people to authenticate with OIDC (and indirectly with their CSAIL Kerberos usernames and passwords). (You can also do this yourself with an .htaccess file, as explained here](https://tig.csail.mit.edu/web-services/web-access-restriction/), but we’re happy to do it in the server configuration if you prefer.)
- Running
hugoto generate a static site from Hugo source. (This may be less widely useful than it sounds, since we only provide one version of Hugo at a time, which changes as we upgrade the cluster, and most Hugo themes and websites are very version-sensitive. If you use Hugo a better approach is probably to run whatever version of Hugo you need by hand to generate your website into a particular directory in AFS, and then we can serve the static website so generated from that directory. This approach works for any other static site generator like Jekyll.) - We can also pull your full static site from a Git repository (e.g. on GitHub or in AFS). This makes for an easy deployment workflow; you can just push your changes and within an hour or so they will be live.