@lab Wiki

From Cheaha
Revision as of 18:47, 20 July 2007 by Jpr@uab.edu (talk | contribs) (→‎4.5.0 to 4.6.0: Highlight how to check for term_node updates)
Jump to navigation Jump to search


Attention: Research Computing Documentation has Moved
https://docs.rc.uab.edu/


Please use the new documentation url https://docs.rc.uab.edu/ for all Research Computing documentation needs.


As a result of this move, we have deprecated use of this wiki for documentation. We are providing read-only access to the content to facilitate migration of bookmarks and to serve as an historical record. All content updates should be made at the new documentation site. The original wiki will not receive further updates.

Thank you,

The Research Computing Team

Supporting Local VO Rosources

The @lab contributes many of it's own resources to the VO. These pages will help document the configuration and management of those resources.

Drupal CMS

The Drupal CMS is a flexible web development platform that enables construction of all manner of web sites, in addition to its support for website-in-a-box configurations.

Requirements

Drupal mainly requires PHP and a relational database. The specific requirements can be found on their site: [1]. Of interest is their transition from PHP4 to PHP5 as this impacts what version run on specific Linux releases using vendor-supplied packages.

Upgrading Drupal

The @lab drupal site has aged significantly. It's not been updated since 4.3.x. In order to upgrade to the latest release in the 4.x line (4.7.6 as of this writing) all intermediate version update.php scripts need to be applied to the database. This is pretty easy to do. It just requires that you install the intermediate releases, configure them to point at the database, and step through the update.php scripts.

Links to older versions of drupal are not too hard to find, at least back to 4.5. The basic URL structure for the release page is http://drupal.org/drupal-x.x.x and the download file is http://drupal.org/files/projects/drupal-x.x.x.tar.gz. Before the 4.5.0 release, the release pages don't have well-known page names, seems Google is the best option here, just look for drupal-x.x.x, where the x's are the vesion number. The file structure changes, but it's still guessable, just replace "tar.gz" with "tgz".

For our upgrade path, the relevant release pages and download links are:

Some additional important notes for upgrading can be found on the drupal site http://drupal.org/upgrade/

UPDATE - the @lab drupal install was already at 4.4.0 as evidenced by the CHANGES.txt file, so that instance isn't needed. Jpr@uab.edu 17:21, 19 July 2007 (CDT)

Configuring instances for upgrade

The 4.4 and 4.5 release still use the includes/conf.php file. After that it switches to the site/default/settings.php approach. They all use the $db_url and $base_url configuration values, though so it should be easy to just plug in the original site values. The $base_url is optional in 4.7.6.

Perl script to change config across many versions for upgrading: 


 #!/usr/bin/perl -w
 
 $sitedb = $ARGV[0];
 $siteurl = $ARGV[1];
 
 while (<STDIN>) {
  s/([\"\']).*([\'\"])/$1$sitedb$2/ if ( /^\$db_url =/ );
  s/([\"\']).*([\'\"])/$1$siteurl$2/ if ( /^\$base_url =/ );
  print;
 }

Name the above script "setsite.pl" and run it as follows: 

# cd to top-level of multi-drupal site dir
for file in `grep -rl '^\$db_url =' *`
do
   ./setsite.pl mysql://dbuser:dbpass@localhost/dbname \
       http://host/path < $file > $file.new
   mv $file.new $file
done

Performing the Upgrade

The upgrade is performed on a version-by-version basis. After running the above config scripts, go to the version-based URL and invoke the 'update.php' script. You'll need to turn of the auth access check at the start of this file (manually) in order to allow non-auth'd access to the script. This is OK only if you're doing this is an isolalated env protected from outsiders.

4.4.0 to 4.5.0

In order to prepare for later upgrades (specifically the 4.6.0 one which changes some core abstractions), you need to log into the existing 4.4.0 site and change to the default blue marine theme and disable non-core modules.

For the @lab site we don't have our bluemarine theme anymore. It's been replaced with a variant of Xtemplate. We can wait till after the 4.5.0 update to switch to bluemarine from the out-of-box 4.5.0 upgrade install.

The non-core themes need to be turned off now though because they won't be there in the out-of-box code used for the upgrades.

Make sure your $base_url is set correctly in the config file. This depends on how you're invoking the update.php script. Keep this in mind if you are ssh-tunneling to the dev server from a remote location.

The 4.4.0 update.php script runs smoothly without error.

4.5.0 to 4.6.0

This is a more involved update due to some changes in architecture. See the update instructions on the drupal site for details. We basically follow the steps except that the modules were turned off earlier and the bluemarine theme was enabled after the 4.5.0 upgrade.

Before running the update.php script there are a couple of data errors that need to be corrected. The sessions table will be updated to avoid duplicates. This will cause update to fail. The easiest thing is just to delete existing session.

The term_node 2 column table is also updated to use both columns in a key, also to avoid duplicates. There may be many duplicates and has to be fixed manually. You can check if you'll be affected by this by runnin this sql statement in a mysql client: 

 select nid, tid, count(1) as num
          from term_node
          group by nid,tid
          having num > 1
          order by num;

The following script should take care of it. Just call it something like fix_term_node.php and invoke it before update.php: 

<?php
// Connecting, selecting database
$link = mysql_connect('dbhost', 'dbname', 'dbpass')
   or die('Could not connect: ' . mysql_error());
echo 'Connected successfully
';
mysql_select_db('dbname') or die('Could not select database');

// Get the entries with duplacates, run this query manually to sanity check count below
$query = "select nid, tid, count(1) as num
          from term_node
          group by nid,tid
          having num > 1
          order by num";
$result = mysql_query($query) or die('Query failed: ' . mysql_error());

if (mysql_num_rows($result) == 0) {
     echo "No rows found, nothing to do so am exiting";
     exit;
}

// Putting results in array elliminates the duplicates
while ($row = mysql_fetch_assoc($result)) {
     $t[$row["nid"]] = $row["tid"];
     $count++;
}
print "Target replace: $count
";
// Comment this out when your ready
//exit();

// Step through the now unique entries and clean up the db
foreach ($t as $nid => $tid) {
     $delnode = "delete from term_node where tid = $tid and nid = $nid";
     $insnode = "insert into term_node (tid, nid) values ($tid, $nid)";
     #print "$delnode
";
     #print "$insnode
";
     $result = mysql_query($delnode) or die('Query failed ($delnode): ' . mysql_error());
     $result = mysql_query($insnode) or die('Query failed ($insnode): ' . mysql_error());
}

// Closing connection
mysql_close($link);
?>
Retrieved from "https://docs.uabgrid.uab.edu/w/index.php?title=@lab_Wiki&oldid=1455"