← Back to branch summary

~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to doc/upgrade.txt

  • Committer: matt.giuca
  • Date: 2009-01-14 10:10:12 UTC
  • mto: This revision was merged to the branch mainline in revision 1090.
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132
The new ivle.database.User class is now used in Request and usrmgt, which
    means it is now almost universally used in favour of ivle.user.User (now
    deprecated).

Noticeable change: The minor bug where the change to a user object in the
    database is not reflected in the user's session (eg. changing nick doesn't
    update title until log out).

ivle.dispatch:
    Session now contains 'login' (username string) rather than 'user' (full
        ivle.user.User object). This is a unicode string now.

    req.user is now a ivle.database.User object rather than an ivle.user.User
        object. This makes for a whole lot of really subtle differences, but
        largely conforms to the same interface. Note that strings must now all
        be unicode.

    login: Removed use of ivle.db. Now uses User object.

    html: Now handles unicode login and config options.

ivle.db: Removed update_user. Now replaced with Storm model.

ivle.database: Renamed has_cap back to hasCap (saved for later). Fixed small
    unicode bug.

ivle.makeuser.make_svn_auth now takes a store object.

usrmgt-server: Use new User class.

userservice: Now uses User class internally.
    get_user action now returns ISO 8601 date format, rather than a
        time tuple. (Wasn't being used).
    get_user action no longer transmits local_password (small security risk;
        note that it wasn't possible to see this for any user other than
        yourself unless admin).

ivle.util - added function object_to_dict.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/upgrade.txt
1
1
Upgrade Procedure for IVLE
2
2
==========================
3
3
 
4
 
Upgrading to a new version of IVLE is generally fairly painless, but
5
 
there are several steps involved.
 
4
Upgrading to a new revision of IVLE SVN is generally fairly painless,
 
5
but there are several steps involved.
6
6
 
7
7
Firstly, in the IVLE checkout, bring your codebase up to date:
8
8
 
9
 
  svn up
10
 
 
11
 
Then build IVLE:
12
 
 
13
 
  ./setup.py build
 
9
  svn update
 
10
 
 
11
Review the IVLE code changes. The current installed IVLE version can
 
12
be found in /opt/ivle/version/ivle-revision.txt. 
 
13
eg. run 'svn log -v --limit 20' to get the last 20 checking messages.
 
14
Look to see whether there have been any changes to the jails or
 
15
database tables.
 
16
 
 
17
Then configure and build IVLE. New configuration options may sometimes
 
18
be added, so the configuration questions should be watched closely.
 
19
 
 
20
  ./setup.py config
 
21
  sudo ./setup.py build
 
22
 
 
23
Note that this will not perform a full rebuild of the template jail -
 
24
only the IVLE files inside the jail will be updated. To force a full
 
25
jail rebuild, give the build command the -j option.
14
26
 
15
27
Now comes the time to block external access to IVLE. Stopping Apache
16
28
on each server in the cluster and killing any remaining python-console
20
32
latest applied migration should probably be kept somewhere to avoid
21
33
running the same one twice. This command must be run once for each.
22
34
 
23
 
  sudo -u postgres psql ivle < userdb/migrations/YYYYMMDD-NN.sql
 
35
  sudo -u postgres ivle < userdb/migrations/YYYYMMDD-NN.sql
24
36
 
25
 
Now we can install the new version, and update the jails:
 
37
Now we can install the new version:
26
38
 
27
39
  sudo ./setup.py install
28
 
  sudo ivle-buildjail
29
 
 
30
 
Note that this will not perform a full rebuild of the template jail -
31
 
only the IVLE files inside the jail will be updated. To force a full
32
 
jail rebuild, give ivle-buildjail the -r option.
33
40
 
34
41
... and remake the user jails, as this will occasionally be needed:
35
42