Deploying a web service on WSO
A lot of open-source web software is out there just waiting to be deployed here at Williams: media lending software, wiki software, calendar software, blog software, radio scheduling software, you name it. These can either be useful for a particular student group, all students, or throughout the Eph diaspora. WSO has web servers that can host this software, and this page will give you some tips for deploying a service at Williams.
If you have an idea for a new service and want to build it yourself, check out How to hack on the WSO site.
To do anything on WSO, as always, you will first need to get a WSO account.
If your software calls for a database, you'll need to email Evan. WSO offers MySQL (4.1) and PostgreSQL (8.0) database accounts. Mention in your request the database type and name you'd like.
Most packages should actually just work in your home directory. However, some software packages require special web server settings, for example to let certain scripts execute. Email Ben if you need, for example, CGI support. The software's README should tell you exactly what settings you need.
Odds are that by default, your program will either let anyone sign up for an account, or will make it the administrator's responsibility to create accounts. Both of those scenarios present problems:
- Letting anyone have an account opens your system to abuse;
- Making an administrator create accounts is a huge pain if you plan to have more than 5 users;
- Your users will not be particularly pleased to have Yet Another Password.
If your software is just meant for a small group of people, maybe the administrator model will work for you. However, if you want to make your service all-Williams and Williams-only, you'll want to authenticate against LDAP servers, the same thing Blackboard uses to check your password. See if your package either has LDAP support built in or if it's available as an extension or plugin. You might want to check the software maintainer's site for such an extension
Here are settings for authenticating different types of users. Ideally, you can authenticate more than one type, but that will depend what kind of support your software has. Of course, if you are a true badass, you shouldn't be afraid to write your own extension to handle multiple LDAP settings. In all cases, you need to somehow substitute $USER with the name of the user that's logging in.
Server: nds2.williams.edu (or nds1.williams.edu) Bind domain: cn=$USER,ou=student,o=williams SSL: no
These include some students and some alumni.
Server: ursula Bind domain: uid=$USER,cn=users,dc=williams,dc=edu SSL: yes
Server: nds2.williams.edu Bind domain: cn=$USER,ou=faculty,o=williams SSL: no
Server: nds2.williams.edu Bind domain: cn=$USER,ou=staff,o=williams SSL: no