TIG offers and maintains a variety of Web publishing options for our community. If you need to host content for your group on a web site, but you’re not exactly sure where to begin, you can always send us email at email@example.com. The following is a quick overview of available options.
In general, we suggest that you use static page based sites wherever possible, for several reasons: first, static sites are less susceptible to being defaced or compromised than sites that run server-based software (like a CMS or Wiki). Second, static sites usually load much more quickly than sites written in a server-based language. Finally, they are much easier to pick up and transport to a new hosting site, since there are no dependencies on particular software versions to maintain.
However, we recognize that there are times when a dynamic site is the right tool for the job. In cases where you need to do more than just host pages and other content—for example, to use web forms, collaborative editing (besides what is available in version control systems like Git), front ends for databases, and so forth—you’ll need to make a choice between using pre-made software, like a CMS (content management system, like Drupal or Wordpress), rolling your own (using a framework like Django or Rails, for example). We can help you arrive at an optimal solution.
Shared web hosting
- Web server architecture - server names, capabilities, and limits
- Web server logs - for troubleshooting and statistics
- Distributing data sets from NFS
- Creating Personal Web Pages
- Security recommendations for course directories
- Granting the web server write access to a directory
- Sending redirects
- Restricting web access with .htaccess and OIDC
Running your own server
- Automatic HTTPS configuration for Apache
- Requesting an SSL certificate for other servers
- Configuring your own Apache Server with OIDC Authentication
- Create your own MySQL database (CSAIL Login required) on mysql.csail.mit.edu
- postgres.csail.mit.edu serves PostgreSQL schemas to CSAIL users (via their CSAIL Kerberos principals) and automated processes/web applications (via standard passwords), upon request to firstname.lastname@example.org.
- Do NOT use SQLite to store data anywhere in AFS (including home directories and web docroots). It assumes file locking semantics that AFS does not provide, and corrupted databases will result.