Building Mezzanine projects in a university class

[Ross Laird]

I teach two university courses in new media and web development. In these course students build websites, and in the past I have encouraged students to choose whatever platform they like (after various discussions about the considerations in choosing). So, we've had sites built with Drupal, Wordpress, Radiant, and so on. However, I've had some challenges with the "build whatever you like approach," and I'm thinking for next semester that I'll ask the students to all use the same platform: of course, that platform would be Mezzanine.

But there is a challenge to this approach. In the past, students have used their own domains and servers. What I'd like to do is collect their accounts together onto one server, and provide each student an account and space on the server. So, in this scenario they would be able to login, create a Mezzanine project, and build their site. But then I start thinking about deployment, and how to handle Apache and so on.

Apache could be setup to serve all the student sites, but students would not be able to restart Apache. That should be OK, as long as they can restart Mezzanine. So, overall, I suppose this should work. But still, I have two questions:

1. How should we handle the development server, which normally runs on a local machine? If the students are building on a remote server, what's the best approach to allow them to deploy and test using the development server? Is the development server sufficient (ie as an alternative to Apache)? The students just need to be able to run each site in a browser, so that the rest of the class can view the projects.

2. Is there a better way to do this? A different web server than Apache, perhaps, or some type of fancy setup within Mezzanine to facilitate multiple projects?

I'm open to any suggestions. I haven't yet thought this all the way through, so it's likely that I'm overlooking something important. But I think I've described the end goal well enough to give you a sense of what I'm trying to do. Any and all feedback most welcome.

Thanks in advance.

Ross

[Josh Cartmell]

My thoughts are that since the sites really aren't going to be used in production the development server should work fine.  Then you could set up apache or nginx or whatever webserver so that each students domain listens/proxies to a specific port on localhost.

With that set up student A for example could run the devserver like so (assuming their port is 12345 and their domain is studenta.domain.com):
python manage.py runserver 12345
and then the site would be accessible at studenta.domain.com

I don't know how optimal of a solution that is, but it seems like it should work.

[POKOLI I PUNTO]

Have you considered that the users could use their own local development server and use heroku (or anything like heroku) to deploy their own servers? You could run a simple web page on the heroku free plan and you avoid having to manage a web server to deploy the students website.

Doing this way you force the users to use a DVCS (git) to deploy they code and you can examine their progress by sharing the repo. I was thinking on using GitHub, but I'm sure you won't like that every student code is public available on the web. So I will encourage you to mount a private git server with ssh access foreach user ;)

This way the can learn about how to use a public web service and a DVCS, so they learn more :D

Hope it helps,

Al 13/09/12 20:24, En/na Josh Cartmell ha escrit:

[Brian Schott]

Running the dev server will be fine as long as they leave debug on.  The easiest approach would be to create an command alias for students to run the server:

alias run-mezzanine='python manage.py runserver 0.0.0.0:`expr 8000 + \`id -u $USER\``'

Then all you need to do is go to http://hostname:9001 (or whatever) and the students won't collide.

If you want them to reside on and forward custom domains, you could use something like nginx to do proxy forwarding.  Build one nginx site file per student like this:

root@ip-10-245-22-95:/etc/nginx/sites-available# more student.domain.com 
server {
   listen 80;
    # change student.domain.com here    
    server_name  student.domain.com
    access_log   /var/log/nginx/student_domain_com.access.log;
    error_log    /var/log/nginx/student_domain_com.error.log;

    # change username here
    location  /static/ {
        root  /home/username/mezzanine;
	autoindex on;
    }

    # change username here
    location  /media/ {
        root  /home/username/mezzanine;
    }

    location  / {
	auth_basic "Restricted";
	auth_basic_user_file /etc/nginx/htpasswd;

	# change proxy location to port user's uid + 8000
        proxy_pass            http://127.0.0.1:9001/;
        proxy_redirect        off;
        proxy_set_header      Host             $host;
        proxy_set_header      X-Real-IP        $remote_addr;
        proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
        client_max_body_size  10m;
    }

    error_page 500 502 503 504 /media/50x.html;
}

Then you can either just use the runserver alias above, or look into django-gunicorn.   The above nginx config probably isn't perfect.  I hacked out an http redirect to https, but hopefully you will get the idea.  This way the main web server stays alive even if the server behind it crashes.

-------------------------------------------------

Brian Schott, CTO

Nimbis Services, Inc.

brian....@nimbisservices.com

ph: 443-274-6064  fx: 443-274-6060

[Ken Bolton]

I love this!

I think I would approach this leaning heavily on Mezzanine's Fabric
script. Give each student a personalized settings.FABRIC dict. Use a
modified Mezzanine fabfile with deploy targets 'local' - to provision
a Vagrant - and 'prod' - to deploy her master branch to the central
server and restart appropriate services. The student maintains
individual configuration files in deploy/. If a student deploys a
broken nginx config, she will certainly hear about it from her peers,
but that won't happen because the deploy was tested on the Vagrant.

Maybe the pain of deployment is a teachable moment you want to emphasize.

However you decide to go, I definitely want to hear how it goes.

best,
ken

[Stephen McDonald]

Just wanted to second Ken's comments. This is really exciting and would love to track the progress. 

I think Ken's approach of leveraging the bundled fabfile would work really well - each student would simply need their own set of unique fabric settings (port, project name, etc). Only thing to keep in mind is that the bundled fabfile assumes a user account on the server with sudo access, so a level of trust is involved here. 

--
Stephen McDonald
http://jupo.org

[Ross Laird]

Thanks for all these great suggestions. And I'm glad to see the enthusiasm for this. I'll let you know how it goes.
I'll discuss these options with the tech folks at the university. I know from experience that they are never going to give any student sudo access on a server, and I know also that I won't be able to use Heroku (the university is in Canada, and we have some strict guidelines about not using services hosted in the US, as Homeland Security and the NSA violate our privacy laws...). I can configure git for the server, though, and I can do most of what is outlined above. So, it does seem that this is going to be eminently doable. And yes, I am definitely trying to create "teachable moments" with this. My experience with my students in these courses is that generally they have very little real experience in actually building something, even though they have a good deal of experience in using something. The more adept students are able to use the command line proficiently and to deploy sites; but for the vast majority, this kind of thing will be a major undertaking (which is what I want...).

Thanks again.

Cheers.

Ross

[POKOLI I PUNTO]

We are waiting your message with your final solution!

Thanks for sharing!

Ross Laird <ro...@rosslaird.com> escribió:

[Nicola Larosa]

[WARNING] Personal, controversial opinion follows. I'll be that guy, sorry.

There's a contradiction here between:

Ross Laird wrote:
> I can configure git for the server, though, and I can do most of what
> is outlined above.

and:

> And yes, I am definitely trying to create "teachable moments" with
> this.

git's usability is inadequate. It's bad enough having to use it on the
job: foisting it on unsuspecting students will unnecessarily worsen their
learning experience. They'll be better off with something saner like
Mercurial or Bazaar.

No, the popularity argument does not really matter, otherwise you would
be teaching Java or C++, rather than Python.

--
Nicola Larosa - http://www.tekNico.net/

I think our policy should be: make the simplest thing that can possibly
work for a narrowly-tailored use case, then make things more generic
*slowly* if there's a demand. No need to be an Architecture Astronaut.
- Adrian Holovaty, Django web framework author, March 2012

[Markus Törnqvist]

On Fri, Sep 14, 2012 at 07:37:38AM +0200, Nicola Larosa wrote:
>[WARNING] Personal, controversial opinion follows. I'll be that guy, sorry.

A wild counter-argument appearss!

>git's usability is inadequate. It's bad enough having to use it on the
>job: foisting it on unsuspecting students will unnecessarily worsen their
>learning experience. They'll be better off with something saner like
>Mercurial or Bazaar.

That depends on where you're coming from. I ran a social experiment
on our intern; she had no experience in version control whatsoever.

She got SmartGit real easy. The trick is to make it sound easy,
because that's what it is, if you don't have legacy debt from CVS days.

Just explain commits and pushes as they are and they'll probably be
fine.

Last I saw hg it looked like the poor man's git. No bzr experience
though. But if these kids are to be taught how to operate in the
real world, git and especially github are worthwhile.

Git, github, runserver and fabric is a workflow that evolved
and became popular for a good reason ;)

Maybe even Heroku.

But there's no value in dumbing down education.

--
mjt

[Ken Bolton]

Hi Ross,

A well-crafted /etc/sudoers might mitigate the concerns of the
technologists at your institution. It took a while, but I convinced
sysadmins at a US university where I was formerly employed that a
properly secured OS in use by students required student sudo access.

Ken

[Ross Laird]

I don't think there is an inherent contradiction between teachable moments in education (all moments in education should be "teachable" moments of learning) and using git. Yes, git can be quite complex, but it can also be quite simple if used only for commits and file tracking (no merges, no cherry-picking, etc). That's what I intend to have the students use it for: simple stuff. The balance between overwhelm and skill development is always tricky in an educational environment such as the one in which I teach. Typically, I use the metaphor of learning to surf: it's easy to miss the wave, to have it pass beneath; and it's easy to be swamped by the wave, to be tumbled into the shore. The sweet spot, the turbulent edge, is where the learning is. It has to be a bit tough to get onto that edge, a bit tough to remain there -- but once you get there, as all students should in an authentically well-tuned learning environment, that turbulent edge is immeasurably rewarding.

[Ross Laird]

That's good to hear. I will try that approach.

[Ken Bolton]

Let this stand in as a "like".

I'm off to surf the Jersey shore this weekend, about two miles south
of the spot made famous by TV. Hoping to find the "turbulent edge".