http.createServer
function. Read below to find out how to write or adapt Node.js code to run on scripts.mit.edu.
Scripts can be used to run your own Node.js code! To begin, you probably want to ensure to have your site run on Fedora 30.
Using typical Node conventions, you can usually replace your use of the http
package with node-fastcgi and install the code as an executable file whose name ends with .fcgi
.
See below for an example index.fcgi
:
#!/usr/bin/node
var fcgi = require('node-fastcgi');
const express = require('express'),
app = express(),
http = fcgi.createServer(app);
app.get('/', function (req, res) {
res.send("Hello World");
});
http.listen();
Naturally to do this, you need to install the node-fastcgi
library. To do so, first you need to make sure you have a writable npm folder for your locker as follows:
% add consult
% mkdir -p /mit/lockername/.npm
% fsr sa /mit/lockername/.npm daemon.scripts write
From here, you can now ssh into scripts to install whatever packages you need (show for node-fastcgi):
% ssh -k lockername@scripts.mit.edu
% cd myapp
% npm i node-fastcgi
If you get an “Internal Server Error” despite having valid code, make sure that you have marked the script executable with chmod +x index.fcgi
. You can diagnose your error by attempting to run your script directly at the prompt:
% ssh -k lockername@scripts.mit.edu
% cd myapp
% ./index.fcgi
]]>If the URL you’re accessing starts with “http://” instead of “https://”, then you simply need to change the URL that you’re accessing. You might also want to adjust your website so that this redirection happens automatically.
If you are using “https://”, you should select the option to get “Advanced” details, and see which of the following possibilities matches:
If none of the above apply, or if you need any help, please send an email to scripts@mit.edu and include a screenshot of the error message that you’re seeing. As you can see, there are lots of different possible error messages, and we’ll have trouble diagnosing your problem unless you show us exactly what’s happening.
]]>Since a .fcgi script is run by actually launching the script directly on our server as a command, it needs to be marked as “executable” to function, and if it is not, you will get a “500 Internal Server Error” when you try to visit the page.
To check if this is the problem, run ‘ls -l’ on your script, like follows:
$ ls -l index.fcgi
-rw-r--r-- 1 sipb cela 100 Jul 26 19:45 index.fcgi
(where ‘index.fcgi’ is replaced with the name of your script.)
The symbols at the far left represent the permissions of the file. If it says “-rwxr-xr-x” (i.e. has three x’s), then it is executable, and this is not your problem. But if it doesn’t have three x’s, and is (for example) “-rw-r—r—”, then you will need to mark it as executable:
$ chmod +x index.fcgi
It should then work (or at least fail for a different reason), and should show up with the correct permissions when you run ‘ls -l’ on your script:
$ ls -l index.fcgi
-rwxr-xr-x 1 sipb cela 100 Jul 26 19:45 index.fcgi
If you or someone else has recently visited a FastCGI site, and then you made changes to it, the changes may not appear immediately, because a process running the old version of the script may still be running.
To fix this, SSH into the server that your browser is currently load-balanced to, and run the following command:
$ pkill -u $USER index.fcgi
(where ‘index.fcgi’ is replaced with the name of your script.)
To determine the server that your browser is currently load-balanced to, scroll to the bottom of scripts.mit.edu to where it says something like “You are currently connected to shining-armor.mit.edu.” The name ‘shining-armor.mit.edu’ would be the name of the server that you’re currently load-balanced to.
Some web frameworks may by default require a trailing slash to be appended to a FastCGI URL.
So, if you’re accessing “https://yourwebsite.scripts.mit.edu/index.fcgi”, and it doesn’t work, you might also try “https://yourwebsite.scripts.mit.edu/index.fcgi/” (with the added trailing slash).
]]>These can take time, so it may be worth trying to fix problems you’ve introduced into your website directly, instead of restoring from a backup. (This does not apply if you’ve deleted data that you can’t recreate.) If you’ve exhausted the available debugging help, you can try contacting us at scripts@mit.edu to see if we can help with debugging. Keep in mind that our ability to help users debug their websites is limited, and we may end up telling you that you should just restore from backup or recreate your website.
If you do need to restore your backup, you should reach out to helpdesk@mit.edu with your request to restore the website files in your Athena locker from backup. If you have a database that you also need restored, and IS&T doesn’t help you restore it, reach out to scripts@mit.edu to request help restoring your database.
You can also find relevant information on the How can I get a file restored from AFS backups? page on the IS&T Knowledge Base.
]]>