|
|
|
| Task: | User web space |
| Group: | Neil, Julieta |
| Stage: | 1 |
informatics
domain.
This task needs to decide how user web pages are presented to the outside world, and how the technology behind the scenes achieves the result. We have assumed that Apache will be used as the http server, as we have significant expertise amongst the computing staff regarding this application.
Note If we go this route, then we need to consider how the automounter maps are generated. If all user web pages are held on a single partition on the web server, then this is fairly straight forward, /webpages/<user>/ would found at userwebhost:/disk/home/webpages/<user>/. However, if we think that at some point we won't be able/want to hold all user web pages on a single partition, then something more elaborate needs to be considered. Probably stored in the Person LDAP entry like their home directory eg:
dn: uid=neilb, ou=People, dc=inf,dc=ed,dc=ac,dc=uk gecos: Neil Brown ... homePartition: cn=u8, ou=Partitions, dc=inf,dc=ed,dc=ac,dc=uk webPartition: cn=web1, ou=Partitions, dc=inf,dc=ed,dc=ac,dc=ukWhere web1 would be defined in the Partitions unit has being a particular exported filesystem from the web user pages host, ie the same from as u8.
Update 21/3/2002 Following the last COs meeting, it's been
decided that users will get to their web space via the
/public/<user>/web/ file system path, and their
CGI script via /public/<user>/cgi/. To keep
things simple it has also been decided to go with one large
(possibly logical) partition, so that the automounter map can be
generated simply. It also has performance benefits as the
automounter is not required to locate the users web space on the
actual web server. We will always know that the files are in a
single (logical) partition.
There are other options for accessing option 2 above, a CVS interface to their web pages, as there is for the Division web server www.informatics.ed.ac.uk. Perhaps even a web/ftp interface like Yahoo!, Freeserve etc. provide. However, users are likely to see this as a step backwards, and timescales probably mean that mounting /public/<user>/web/ will be easier and more popular
We could try to make it "readonly" so that the users can no longer maintain it, and force them to move to new service. But then how to the users update the legacy pages saying "go look here now". Would it even be technically feasible?
Teaching material in staff's legacy web space. Currently there is a substantial amount of teaching material held in staff personal pages. We don't want to perpetuate this, as all teaching material should be migrated to the official www.informatics web service.
Username mapping. If a legacy site decides to unify, or remove their legacy password file, then this will impact on www.legacy.ed.ac.uk/~<user>. Currently only Computer Science is considering unifying usernames within their legacy domain. For example, all students, other than this years intake, who's username is currently of the form 'nrb', has a personal web page available as www.dcs.ed.ac.uk/~nrb/, if their usernames are unified to the form 's0123456' in the DCS legacy world, then their web page will also change to www.dcs.ed.ac.uk/~s0123456/. This may not be an issue for undergrads, but may be for final year PhDs. Perhaps aliases or redirects could be put in so that both old and new usernames will work.
If a legacy site decides to remove all user accounts from the
legacy password file, then continuing to provide
www.legacy.ed.ac.uk/~user/ will depend on how a site implements the Apache
UserDir directive.
To encourage people to migrate their pages to the new service, perhaps when people browse to a legacy URL, some form of nuisance-ware could be employed to pop up a message saying that the page should be moved, and encourage the browser to mail the owner to move the page. How practical it would be to implement this and the political ramifications, problably means this is a non-starter.
/public/<user>/web/ would suffice.
We need to consider the implications of how the automounter map will work. At CS all user web pages are on a single partition on the web server, which maps map generation simple. If this were to change to multiple partitions, then some thing more flexible is needed. (See the note above).
Providing a CVS, FTP or Web interface to this area would be more effort to implement and maintain, and would probably be seen as a step backwards by the users. Though there is an extra management effort to maintain a users home directory, as well as this extra web space, it does allow us to see all the users that have web pages at once.
http://homepages.inf.ed.ac.uk/user/. However
various variations of this will also be accepted. Namely:
These will be implemented via redirects so that browser will display the official URL despite having perhaps been initial directed to one of the alternatives.
Again, similarily with what the EUCS provide. URLs of the form
www.informatics.ed.ac.uk/~user/ will be redirected to
offical homepages.inf.ed.ac.uk/user/. We wouldn't want
to encourage this form of URL, but staff may prefer to use this "more
professional" looking form.
Extra functionality like PHP, mod_perl, HTTPS are still up for discussion. The likelihood is that PHP (which version) and HTTPS will be provided.
| Groups of User | Number in that group | Possible Web Quota (MB) | Possible Web Quota (MB) | Possible Web Quota(MB) |
|---|---|---|---|---|
| UG1 | 300 | 2 | 1 | 5 |
| UG2 | 200 | 2 | 1 | 10 |
| UG3 | 170 | 10 | 5 | 20 |
| UG4 | 120 | 10 | 5 | 40 |
| MSc | 80 | 20 | 10 | 40 |
| PhD | 180 | 20 | 10 | 50 |
| Staff | 260 | 50 | 50 | 100 |
| Total (MB) | 22,100 | 17,550 | 49,900 |
Assuming that these figures are in the right ballpark, then a 50GB disk would be large enough, but something nearer 100GB would allow us to be more flexible.
A quick trawl of /home/<user>/public_html on AI and CogSci machines and a look at /public/ at finds the following space being used:
Giving a rough total of approximately 12GB of user web files currently in the Division.
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
