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.
- 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
- 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.