Hope you had a good long weekend ...
We're starting to look at back end web development today, which I'll be showing on our linode, sandyshell.
Please look over the "command line" section of the resources if you feel like need a refresher for that stuff ... or haven't played with it much yet.
Today I'll introduce some of the ideas, then turn over the second half of the class to our SEPC rep .
One week from today is a "plan day" - no classes. There won't be a weekly assignment for that week; instead, I will come up with a longer one for the following week, covering both CGI and some PHP stuff which I will explain, demo, and point you towards some readings.
I'm not sure how far I'll get today - I'll continue with this material on Monday.
The first order of business is setting up user accounts and convenient remote access to them, with ssh keys. This is also a chance to practice understanding how users, groups, and file settings work on servers : chmod, chown, ssh, scp, cp, ls, nano, and all that.
I'll work through some of these backend notes : google "adduser" and "ssh key" to find descriptions of what's to be done.
For these sorts of tasks, if you understand the underlying ideas and concepts, then you can find the details and specifics by searching the 'net when you need them.
Then our next task is to understand how CGI scripts work : enabling them (apache config), writing them, debugging them (ugly, I'm afraid), and what they can do.
While they don't scale well in terms of performance, these were among the first dynamic back-end software mechanisms, and the ideas behind them are worth understanding and illustrate the tech running behind the scenes.
I have some an example and backend cgi notes that we'll discuss.
Your mission next week (in part) :
The common "gotcha" when doing this is file permissions - the apache web server (running as user and group www-data) must be able to run your scripts and write to your files and/or database.
Debugging backend scripts and services can be difficult - if it doesn't work, the error may seem to just vanish into the cloud somewhere. For cgi scripts, the first check it to see if it runs from the command line. After that, your best bet is usually to look in the server logs, typically in /etc/log/apache2/ . After that, lots of googling, staring at the code, checking the apache configuration files, and pulling of hair ...
We'll do that same task with a PHP script, too.
Here's a starting point.
sqlite
And then we'll move on to using a database rather than a file for the persistent storage.
