Retired OERca Install for Developers

From openmichigan

Jump to: navigation, search
RETIRED: OERca Install for Developers

For the most recent version, see: OERca install.

Contents

[edit] How to get it working on your Macintosh

Requirements: PHP5, with several modules, a web server (we use Apache 2.x), MySQL
The Subversion client (svn) is required for installation but not operation. It is available by default on MacOS 10.5.x and for MacOS 10.4.x an installation package can be downloaded from http://downloads.open.collab.net/binaries.html.
Access to bezak.umms.med.umich.edu will help you grab resources you need to complete the setup. If you are one of the current developers, you already have access to bezak. If you don't have access to bezak. Contact Bob or Ali.
This document uses the MAMP package. But if you have handled the requirements in other ways, you are probably savvy enough to still make sense of what follows.

  1. Download MAMP from http://www.mamp.info/en/index.php.
    • Help is available at http://www.mamp.info/en/help.html
    • Once MAMP is installed. The servers are controlled using the MAMP application or the widget in the MAMP folder within the Applications directory.
    • If MAMP is running you can go to http://localhost:8888/MAMP/ for more info
    • Finally, if you MUST read documentation, the README.rtf file in /Applications/MAMP may be of use.
  2. Open a Terminal window and change to whatever directory you use for development:
    cd <your development directory> e.g. cd ~/Documents/development
    Do a checkout of the source from the Subversion repository at https://source.sakaiproject.org/contrib/ocw2:
    svn co https://source.sakaiproject.org/contrib/ocw2
    This will create a directory within your development directory called ocw2.
    You may optionally specify another directory name during checkout for svn to fetch the source to a different destination directory as shown below.
    svn co https://source.sakaiproject.org/contrib/ocw2 <your destination directory> e.g. svn co https://source.sakaiproject.org/contrib/ocw2 otherdirectory
    The above example command will download the source from the subversion repository to a directory called otherdirectory
  3. Create a symbolic link between the source directory and the MAMP Apache htdocs folder
    • Change directory to /Applications/MAMP/htdocs:
      cd /Application/MAMP/htdocs
    • Create a symbolic link from the tool folder within the folder to which you downloaded the source in the previous step to the current directory:
      ln -s <path to the folder containing the tool code>/trunk/tool .
      e.g. ln -s ~/Documents/development/ocw2/trunk/tool .
  4. Create a MySQL database for the tool.
    In the Terminal window:
    • make sure you START the MYSQL server before you do anything else!
    • /Applications/MAMP/Library/bin/mysql -u root -p
    • Enter the root password at the password prompt. The default MAMP password for the MySQL root user is root.
    • CREATE DATABASE <name of the database you want to create>; e.g. CREATE DATABASE oerdb;
    • \quit

Optionally, you can create a dedicated user and password for this newly created database:
In the Terminal window:

  • /Applications/MAMP/Library/bin/mysql -u root -p
  • Enter the root password at the password prompt. The default MAMP password for the MySQL root user is root.
  • GRANT ALL ON <name of the database you just created>.* TO '<username>'@'<localhost>' IDENTIFIED BY '<password>';
    e.g. GRANT ALL ON oerdb.* TO 'oeruser'@'localhost' IDENTIFIED BY 'oerpassword';
  • \quit
  1. The latestoerdb.sql file in the /oerstuff folder on bezak can be used to load a recent dump of the OER/OCW database into your newly created database:
    • mysql -u root -p <name of database> < <name of dump file>
      e.g. mysql -u root -p oerdb < oerdbdump.sql
    • Enter the root password at the password prompt. The default MAMP password for the MySQL root user is root.
  2. Put a recent version of the uploads folder in /Applications/MAMP/htdocs/tool/ . It is available in the uploads.tar file in the /oerstuff folder on bezak.
    It will need to be untarred/extracted within the /Applications/MAMP/htdocs/tool folder
    It is critical that you have a recent version of the uploads folder for things to work, particularly adding materials and content objects.
  3. Set the database name and username/password information in the /Applications/MAMP/htdocs/tool/system/application/config/database.php file:
    Change the following lines to the values of the user name, password and database name that you have defined in the previous steps.
    • $db['default']['username'] = "<name of the database user>";
      e.g. $db['default']['username'] = "oeruser";
    • $db['default']['password'] = "<password>";
      e.g. $db['default']['password'] = "oerpassword";
    • $db['default']['database'] = "<name of the database>";
      e.g. $db['default']['database'] = "oerdb";
    • $db['default']['dbprefix'] = "<prefix on db tables if any>";
      $db['default']['dbprefix'] = "ocw_";
  4. To set the user (and as a result, the role) that will be set when you connect to the tool, you need to edit the $config['remote_user'] = "<username>"; line in /Applications/MAMP/htdocs/tool/system/application/config/config.php
    e.g. $config['remote_user'] = "tpain";
    will result in your user being set to tpain who is a dscribe1. For more details you can look at the ocw_user and ocw_acl tables in the database. You may use phpMyAdmin which you can access from http://localhost:8888/MAMP
  5. Open a browser window and go to http://localhost:8888/tool and you should be directed to the starting page for the user.

The above instructions help to set up the cutting edge code in the svn trunk, but you can easily set up the tagged phase 1 version by following the same instructions and making simple changes. To figure out what this means, please look in the svn source folder and it will become obvious.
Please contact Ali with any feedback on this guide.

[edit] How to install OER on a "real" Linux Server

The OER/OCW code is written in PHP and uses the CodeIgniter framework. This code runs as an application on an Apache web server. This OER application currently uses its own mechanisms for authenticating a user and authorizing access to different application functions. I explored several methods of replacing the self-contained authentication with the UM institutional authentication: 

   * proxy authentication machine (similar to the integration used with the Adobe Connect Server)
  * Apache Cosign filter (recommended by my colleague, Ali & provided by UM ITCS)

After several experiments and exploring ways to intergrate the Java runtime with the PHP runtime environment, I choose to implement the Apache Cosign Filter. Here's things worth knowing if you want to do this: 

   * Reference Material
  * Apache Web Server configuration
  * Apache Cosign Configuration
  * OER/CodeIgniter changes

I've checked all these changes into the SVN code tree maintained by the OER team, using a tool called "Zigversion". If you want to know how to install a new "version" of the code found in the SVN tree: 

   * upgrade OER tool code on Apache Web Server

[edit] Troubleshooting for naive web admins

The following changes are needed in the web server's httpd.conf file (for Fedora installs, anyway) 

   * Make sure mod_rewrite is loaded so that redirects may be enabled: LoadModule rewrite_module modules/mod_rewrite.so
  * Enable rewrites by putting the following in the <Directory> section for your top-level directory: RewriteEngine on
  * Make sure Overrides are enabled in the <Directory> section for your top-level directory: AllowOverride All

[edit] Things I wished I hadn't learned

The machine we used for the OER development was originally a Fedora Linux machine. So much crud was left over from previous development efforts that the development process was slowed down, so I decided it was time to scrub the machine. Given the current popularity of the Ubuntu Linux distribution (and the fact it's Ali's favortie linux!) I had bezask.umms.med.umich.edu load with Ubuntu 7.10. When I was trying to get the Cosign Apache filter to work, this code could/would never make a network connection to the weblogin.umich.edu server.

Why?

No Apache threads! Thanks to help from Cosign gurus at ITCS (Andrew Mortensen, Mark Montague) I learned that we might be the first to run this on a Ubuntu platform. I learned that the Cosign Apache Filter (mod_cosign) was not thread-safe. I then looked at the Apache server installed on the Ubuntu 7.10 distribution. Turns out that Ubuntu apparently installs the Apache server using the Multi-processing Module (MPM) which implements "a hybrid multi-threaded multi-process web server". This is incompatible with Cosign filter. I then figured out how to remove all the MPM modules and then installed the PREFORK libraries which implements a "a non-threaded, pre-forking web server". I also needed to install the PREFORK development libraries because they include the utility "apxs2".

Firewalls?

mod_cosign still wasn't able to talk to the weblogin.umich.edu server. The server was able to talk to other external sites so I began to wonder more about what the following message found in the Apache error.log meant: [error] mod_cosign: connect_sn: connect

Andrew provided some advice as well as a patch to the mod_cosign code that provided more information on the connection failure: error] mod_cosign: connect_sn: connect [Sun Feb 17 20:09:58 2008] [error] mod_cosign: cosign_cookie_valid: Unable to connect to any Cosign server.

This indicated a connection "timeout", that bezak.umms.med.umich.edu never was able to connect to the weblogin server. I asked the MSIS helpdesk folks if 141.214.119.71 was being filtered by a firewall. MSIS provided an MCIT message indicating that there was an OPENSSL security exposure on this machine. So I assumed that traffic to weblogin.umich.edu:6663 was being filtered by a firewall. A MCIT firewall guy (Orest Mylenko) was gracious enough to work with me. A test was run, the firewall logs were checked and I was told that no traffic related to the 141.214.119.71 was being blocked. You can test the connections on bezak by issuing a "telnet weblogin.umich.edu 6663" command.

My head hurts

The server has two NICs. So I check /etc/network/interfaces to see which interfaces were automatically started on the machine.

The loopback network interface auto lo iface lo inet loopback

The primary network interface auto eth0 iface eth0 inet static 

   address 141.214.119.71
  netmask 255.255.255.128
  network 141.214.119.0
  broadcast 141.214.119.127
  gateway 141.214.119.1
  # dns-* options are implemented by the resolvconf package, if installed
  dns-nameservers 141.211.144.17 141.211.125.17
  dns-search umms.med.umich.edu

Imagine my surprise when I did a "ifconfig:" and it showed both eth0 and eth1 interfaces were active! I then issued a "route -n" command and discovered the default route was over eth1 which had acquired a DHCP 10.21.*.* address. I rebooted this machine, expecting it to come up with just a single interface, eth0 active. It did not! Samba?

So I begin munging through the /etc files and finally discovered that eth1 was defined in some Samba configuration file as an interface for a "windows server". I don't understand why/how this interface is made active at boot without an entry in the /etc/network/interfaces. I assumed there is something going on somewhere that I hadn't found, so I did the obvious thing. I went to the machine room and pulled the ethernet cable out of the eth1 NIC.

The Cosign Apache filter then was able to connect to the weblogin.umich.edu server.

I have no idea why this Samba stuff was setup on the scrubbed machine. I have no idea why an ethernet cable was plugged into the second NIC. My best guess is that this is residue left over from earlier work that was applied (along with other helpful things!) the scrubbed server to permit other development efforts to continue if needed.

Retrieved from "http://webservices.itcs.umich.edu/mediawiki/openmichigan/index.php/Retired_OERca_Install_for_Developers"
Personal tools