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
]]>Keeping the scripts.mit.edu servers secure is one of the most important things that the team works on. This includes not only careful design and review of the custom software that we run, but keeping up to date with security patches for Fedora, which is the distribution of Linux that we run. Fedora’s security support for Fedora 20 has ended, so we will be upgrading to Fedora 30 to receive official security support for approximately another year.
The actual transition is scheduled for XXX TBD XXX.
Unlike previous scripts upgrades, we have added the capability for each virtual host to migrate on their own schedule. To migrate your virtual host to Fedora 30 (or back to Fedora 20) visit Pony.
We expect that for the vast majority of our users, the upgrade will be very smooth, your applications will work with no changes, and you won’t have to do anything. However, we strongly encourage you to test your website as soon as possible. Also, check the list of known issues to see if you are likely to experience any problems we’re already aware of. In particular, the system installations of Django, Trac, Rails and TurboGears have had upstream upgrades that are somewhat backwards incompatible. Also, if your application still uses Python 2, it will reach end-of-life status in 2020. We expect this is the last version of scripts.mit.edu that will support it, and we strongly encourage you to start migrating your sites to Python 3.
We do not expect there to be any service outage. Our plan is to allow users to upgrade preemptively to Fedora 30 servers, then at a scheduled time change the default servers, and finally discontinue support for the legacy Fedora 20 servers. If your website and scripts work with our Fedora 30 testing server, they should work and be available to your visitors continuously throughout this process. You can control when this migration happens for your site by visiting Pony in advance of the cutover.
There are several options available to you.
Note: If you are running an application that asks you to upgrade it when you use our testing server, do not perform the upgrade until you are ready to permanently migrate your virtual host. If you do, your site will most likely work on the testing server, but no longer work on the production Fedora 20 servers. If you do perform an upgrade, you will most likely have to restore a backup of your database and/or application. If you wish to test your application sooner, you may wish to make a new copy of it that uses a different database.
Visit Pony to switch your virtual host to Fedora 30. You can easily switch back to Fedora 20 if your site doesn’t work.
On any Athena workstation, you can log in and run these commands (make sure you do not have a web browser open first):
athena% add scripts athena% firefox-test
This will start Firefox for you with special configuration that ensures that any website you visit that’s hosted on scripts will be retrieved from our test server. You can then try using all the features of your website just as you ordinarily would. Note that this will be using your real website; it is not a separate copy of your site.
This configuration will only be used while you have that copy of Firefox open. If you close it and run Firefox normally, you will no longer be using our test server.
If you visit the SIPB office (W20-557), there are a few specially labelled workstations there which always use the scripts testing server. You do not need to do any special configuration to test your site on these machines. Feel free to come by SIPB any time we’re open (the office doesn’t have fixed hours, but is open most afternoons and evenings; feel free to call 617-253-7788 to check if we’re open before coming over) and test your site on these machines.
If you use Linux, or a similar operating system, and are comfortable with system administration tasks, you can temporarily configure your system to use our testing server by adding a line to your /etc/hosts file that maps the hostname your website uses to the IP address 18.4.86.229
. Note that your website might use any of these hostnames:
scripts.mit.edu, scripts-cert.mit.edu, yourLockerName.scripts.mit.edu
or something like customname.mit.edu. Be sure that the line you add to your /etc/hosts uses the correct name, and be sure that you remove that line when you are done testing. If you are on a Windows system, the analogous file is
C:\Windows\System32\drivers\etc\hosts
Yes, anyone with a scripts account may ssh to scripts-test.mit.edu
, just as you ordinarily would ssh to scripts.mit.edu, if you would like to use a shell.
Autoinstalled WordPress and MediaWiki apps may not work due to the new version of PHP. They will be upgraded before the transition.
Currently, Ruby (including Ruby on Rails) web applications do not work on the test server due to a missing Ruby FastCGI library. This will be fixed before the transition.
News about scripts.mit.edu is posted to our blog periodically. Important announcements are e-mailed to the scripts-announce mailing list. If you’re not already signed up for the list, please take a moment to do so by clicking the link above.
]]>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.
]]>