OxCLIC MDID_server

FAQ on Server Set-up

What are the steps required to install MDID under Oxford authentication

1. Install base OS and ASP.NET 1.1

2. Install WebAuth on the server and test

3. Install MDID application using an Oxford-specific distribution of MDID (available from OxCLIC-r101.zip). It includes the customised images for the Oxford header, and a module that allows MDID to integrate with WebAuth.

4. Import user data into MDID's MySQL database MDID User Import Scripts

5. Set up IIS to allow access to MDID under a second port (e.g. 8080) and protect that port using IIS access rules. See Section 1.14 below for details.

6. Load initial collections - Read the manual

7. Setting access controls for collections and system - Read the manual

Does MDID run on ASP.NET 2.0?

No. MDID is an ASP.NET 1.1 application, trying to compile or run it on ASP.NET 2.0 will fail spectacularly. It is a common mistake, you must use ASP.NET 1.1!

What MDID Server set-up documentation is there on all of this

See the MDID wiki at http//MDID.org there is also documentation linked under OxCLIC_MDID

A list of all documents is here: http://www.mdid.org/mdidwiki/index.php?title=Special:Allpages

A simple overview of MDID server demands from the originator institution is here: http://www.mdid.org/mdidwiki/index.php?title=Requirements

How do I install WebAuth on my IIS server

To take advantage of WebAuth Authentication ( and later use this for authorisation activities within an OxCLIC MDID) you need to install and various kerberos related pieces of software on your IIS server. This set-up process needs to be followed carefully, it is documented on the IT Support Staff wiki:

https://wiki.oucs.ox.ac.uk/itss/WebAuth_IIS

you should now be able to point your browser at the website (using https) and then to the folder you’ve protected, and the magic of passing seamlessly to WebAuth should occur, with you eventually being returned to that folder and it’s contents. This will provide you with a very basic Webauth setup, protecting the web pages you have specified in the config. Every time a user authenticates, a Windows account will be created on the server in the form webauth.<username> (e.g webauth.adrianp or webauth.uzdn0017), and added to a group called WebAuth. You can use this for authorisation purposes, but if you don't want this, set the EnableUserMapping parameter to 0 in the config.

How do I customise MDID to use WebAuth for authentication

Simply put, install the Stanford Webauth for IIS filter, and then modify the MDID code to accept it's input. This guide also covers the full customisation to allow MDID's helper applications and remote searching to work around the WebAuth filter.

Full details of this customisation can be found at https://wiki.oucs.ox.ac.uk/oucs/ltg/OxCLIC_MDID_SSO

How do I set-up MDID user information and groups

The input scripts for the system admininstrator are briefly discussed here MDID_User_Import. Also worth looking at the OxCLIC_MDID_authorisation page.

See the project team for the MYSQL scripts that allow you to import user data and appropriate premade groups appropriate for Oxford. These scripts provide the following based upon a data feed from Beth:

• Updating of existing user records (changes to names and email addresses) based on their WebAuth username

• Importing of new user records (first and last names, email address and WebAuth username as their login)

• Generating Groups based on the current import data
  • Staff of Department X
  • Staff and Postgraduates of Department X
  • Members of Course Y
  • All Students
  • All Staff (merely the opposite of the above)

Full details of what the script does and how it operates can be found are in MDID_User_Import. Note that this script attempts to avoid directly affecting manually created accounts and groups, however the following are issues to avoid:

• User accounts are not deleted. Therefore staff and students who have left and are no longer in the data import are not automatically removed from the system.
• Any manually created group that ends in "_staff" or "_staff_postgrad" will be deleted upon the script running and not recreated unless it co-insides with the data.
• The same applies to any group that matches an existing course title.
• Courses that are no longer offered or that students/staff previously were associated with will be left as they are. The system can not presently detect previously created course groups, and therefore does not edit/delete them.

What are the recommended default permissons settings for collections and activities

MDID has a full series of permissons for access to collections and all activities, rather similar to WebLearn. See the http://www.mdid.org/ -> documentation http://www.mdid.org/mdidwiki/index.php?title=Permissions

Also ask project team for advice. We'd recommend the following

• MDID defaults to access denied for every activity, hence a base user will not see any collections etc.
• Limit admin priviliges and delete/change collections to a the system support staff
• Limit each collection to the appropriate staff@department group
• Limit slideshow creation to staff@deptartment only
• Create adhoc reseacher groups made from staff@dept with added members
• Limit access to slideshows to the student course group or use slideshow "passwords" to protect

How do I import my first collection

Get the curator's handbook PDF from the MDID site. Read the workflow documents on the OxCLIC site here see [OxCLIC_MDIDimporting]

How do I customise the branding of the MDID interface

from https://listserv.jmu.edu/cgi-bin/wa?A2=ind0504&L=mdidusers-l&P=2097

>I'm ready to customize the user interface for our campus. Is it OK to do that?

There shouldn't be any issues whatsoever, we do it ourselves.

>Can we call it something other that MDID...like maybe KatyDID? Can we have our logo in the banner? What files do I need to edit to make that happen?

Images, including the logo are located in the wwwroot\images folder, to simply replace an image replace it there. If you want to change the look of various areas, the Header, Footer, and stylesheet (CSS) are in the wwwroot\PageTemplate directory, in files called PageHeader.ascx, PageFooter.ascx, and stylesheet.aspx. To change the look of pages specific to an individual page (like the logon screen which is default.aspx), they are in the wwwroot directory.

Changes to the .aspx and .ascx pages will take effect immediately (unlike changing the underlying code of MDID2), and should let you do all of the user interface changes you want.

More details on customisation here OxCLIC_MDID_customising

Where are the graphics/stylesheets headers for OxCLIC MDID versions

MDID uses very little CSS and the system is built to heavily (ab)use tables and as such is problematic to customise. The stylesheet can be found in the wwwroot/PageTemplates/ folder and is an aspx file (stylesheet.aspx) inline with the other ASP.net files. The graphics are referenced from wwwroot/images/. Substitution of existing images is the simplest means of changing the graphics displayed.

The OxCLIC header graphics can be obtained from the OxCLIC project team.

How do I set-up remote collection searching

This page, [OxCLIC_remote_collections] cover the topics below:

• A) How do I search another instance ?

  How do I make my collection searchable by others ?? C) How do I test this ..

Also review the MDID main wiki site at http://www.mdid.org/mdidwiki/index.php?title=Special:Allpages

How do I check that I can download a packaged .zip of slideshow viewer and myslides

You need to check under packages in the slideshow menus that you have setup things to allow a zip file of slides and application to be created. You can download a "package' for Mac OX X or PC that contains a viewer application similar to the MDID viewer, a full screen viewer with a folder of images that are detected by these applications.

Will it run under LINUX as well as .asp under IIS?

Alas no, it doesn't seem to be stable. Some notes are here ... https://listserv.jmu.edu:443/cgi-bin/wa?A2=ind0511&L=mdidusers-l&T=0&F=&S=&P=4198

From our experience ... Prev Windows System

• OS: Windows 2000 (also works under Windows XP, 2000 server, 2003 server)
• Web Server: IIS (free with windows)
• CGI Language: ASP
• Database: MySQL (free) (also works under SQL in Windows)
• Extras Required: ASP.NET 1.1 (free)

• Time taken: 2 Hours

New LAMP system

• OS: Suse Linux 9.2 Professional
• CGI Language: ASP
• Database: MySQL
• Extras required: Mono, Mod_mono (and several other modules for compiling everything)

• Time taken: 2 days (with the problem of Apache crashing when trying to view slideshows not yet solved)

The consensus on the MDID list (8/06) is that it isn't stable enough on Mono/LINUX to be run as a production server.

See also notes on fun and games with the failure to run MDID under Mono/Linux on Mac OSX OxCLIC_MDID

How do I create a second access point for MDID applications?

We will now create a second IIS instance, that points at the same site root and MDID installation. In this example it will be set to port 8888 for regular http access.

1. Access the IIS Management Console and use the menus to create a "New Website".
2. Work through the wizard using the defaults to create a second site.
3. Select the new site and edit its properties to match those of the existing site, with the following exceptions:
   1. DO NOT add the SUWA filter.
   2. Set the TCP port to 8888 (or your preferred alternative port number)

   3. Set the description to "OxClic Backend" (or your preferred name)

   4. Leave the SSL Port field blank.

NB: As this presently stands, anyone who accesses the server on that port will be able to enter any username they wish and anystring they like for a password, and the system will log them on as that user. So you could enter the username of "admin" and a password of "look-broken!" and it would successfully log you in as the user "admin". To counter the range of this effect, it is highly advised that you use the tools available to limit access to this port as much as possible. In our setup we have determined only the localhost and one other server actually need access to this interface, so we will use the IIS security tools to limit by IP address. This is done by the following steps:

1. Select Properties on the OxClic Backend site

2. Select the tab "Directory Security"
3. Click on the button in the second section down "IP address and domain name restriction" [edit]
4. In the new window click [add]
5. In this second new window, select "single computer" and enter the IP address of the second machine to be allowed access (e.g. myotherserver.ox.ac.uk)
6. Click [ok] to return to the window entitled "IP address and domain name restriction"
7. Change the radio buttons at the top to default to "By default, all computers will be... denied access".
8. Click [OK], then Click [OK] again to complete.

This will limit access to only the local machine and the machine you've listed by ip address (or DNS entry), thus minimising the profile of this security hole.