Archive

I have begun the documentation on how to install Luminis IV within our environment. You can view the evolving document over at the wiki titled Installing Luminis IV. At this point everything documented in the wiki on an install has been done on our test system (brax.cc.umanitoba.ca).

This documentation shall help ensure that when we are ready to move to Luminis IV anyone invovled will have hopefully a clear set of steps.

In spring SUngard had announced that Luminis IV would be officially supported on Red Hat Enterprise Linux(RHEL) 4. This was good news as the support for RHEL 3 which was the officially support Linux platform previously was about to dry up. As such we had a goal for our eventual move from Luminis III to Luminis IV to install Luminis IV on RHEL 4 as this should prove easier then upgrading the OS after the fact.

However we have had trouble in achieving this goal up until now. Today I had Ed reimage our RHEL 4 virtual machine (brax.cc.umanitoba.ca) and attempted another round of installing Luminis IV on it. It kept failing when it attempted to install the Java Enterprise System stack (calendar, directory, webserver, mail) with a return code of 50.

In examining the source code of the JES main install class error code 50 seemed to revovle around file I/O issues.Now up until this point I had been attempting to install Luminis IV onto a NFS partition, so on a long shot I decided to try and install it on the root file system. This almost worked except that we did not have enough disk space to achieve this goal. As such another call into Ed and the root file system gained an additional 5G.

This has allowed Luminis IV to be installed on RHEL 4. However this is not how we will want to leave it as we want to minimise the amount of software left on the OS disk. As such the next step will be to move this data over to the NFS partition and setup the symlink. This of course will be a job for another day.

I also will be placing some documentation into the wiki on how to install Luminis IV, with this rather important point present.

Last week found out we were facing a new defect with the migration. In this case admin permissions for manipulating channels were missing after the migration. With suggestions from Sungard over the weekend I installed LP IV on romulus and performed another migration.

This time post migration we have access to these admin level functions. So prior to this post things were in good shape for Debbie and Brian to test, not so for Dave, Naramada, and Bill. But now everyone can take part on vulcan (lumnext.cc.umanitoba.ca) to fix up the custom channels. Perhaps on the weekend I will try and put in some of my new custom channels.

Alright no real dancing but still some excellent news. Sungard reviewed the log files from Friday and Saturday and they all look good. Today I transferred over all the group/course tools files from June of last year (when we did the snapshot) to vulcan.

I am currently working with Sungard to resolve the odd issue with decreased admin access once logged into the portal. I still need to bring over the mb_topics table but once that is done I think we can open it up for testing.

Keep in mind the testing to be done is to confirm that the data present in the groups and courses is accurate. The testing is not for commenting on broken channels as we know that all custom channels we have developed will most likely be broken. There is one exception in that if a channel is not a custom channel (i.e. targetted content, or old school RSS) and it does not appear to have been migrated properly we need to know about it.

All feed back needs to be done via bugzilla, there is a new component called migration to track these issues in.

The main issue affecting us currently is the small change to the baseDN suffix in Luminis IV. We have been told that if we make it the same the migration script should work. However the migration script is also meant to handle such a change.

Well today it looks like I may have tracked down the reason for the issue. In all the translations that the mgiration script does, it does not translate the property values from the old system before loading them into the new system. As such the old system does contain various properties that contain an LDAP baseDN. These are used by the system when it is running, but also later parts of the migration for fixing the data. I have adjusted their code that does perform some modifications to the source system property file to correct the values and in tests this afternoon it produces the correct file.

In a few moments I will start up the job that will perform the full migration tonight to see if this resolves things. Of course we will not know anything until tomorrow, I also hope the oracle team gets my e-mail in time to disable the lp4prod recycle.

In regards to the migration it would appear that the belief Sungard had in regards to changing LDAP suffix causing the problem was incorrect. The problem was directly tied to attempting to move over a layout owner that did not exist in the list of users being loaded into Luminis IV. Once I removed this layout section from the dlm.xml file we were able to get farther. However we then stumbled on an issue with updating the LDAP with the layout owner information in the dlm.xml file.

This was due to there already existing layout information in the LDAP. The suggestion from Sungard for this was to reset the Luminis IV data and manually delete the layout information present so that the migration tool could insert the data from Luminis III.

This was done on Friday last week and we postponed the Luminis IV database recycle so that it could run through Saturday. We have now got even further then before. There is still an error in the output that I am having Sungard evaluate to determine if it is of a critical nature.

So in short the things that we have done to make the migration work:

1. Increase the error threshold to 2 as there is a known problem with the migration of the mb_topic table and UTF8

2. Migrate the mb_topic table manually as there is no translation being done on this table other then the dropping of one column

3. Ensure that there are no fragment entries in ou=site,o=Luminis Configuration, the cn pattern will look like org.jasig.portal.layout.dlm.fragments.data.?? where ?? is a number

Today I continued my efforts at installing Luminis IV on brax. I had to ask Ed to reimage the box as the luminis isntalled may have messed things up quite bad. At this point I am back to the initial error that I had reported to Sungard. Hopefully tomorrow will bring better luck.

I also received permission to attempt a Luminis III to IV migration during day time hours. The migration did not complete successfully, however this time it appeared to be failing dealing with the layout fragments. This is different then the Apr 23rd attempt that caused Sungard to think it was a LDAP suffix issue. I have updated the Sungard ticket with this new information in case it adjsuts the troubleshooting.

Today I spent some time looking into our recent migration attempt of Luminis III to Luminis IV. This was manily an exercise to try and find where in the migration code base it was picking up the old LDAP server’s base DN. Sadly more time will be needed here to track down this issue.

I also deal with bugzilla tickets 3422 and 3429. For Ticket 3429 I created a new Bugzilla component for JUMP called ‘Course: Duplicate PIDM’ as a means to track course population issues that are caused by the duplicate PIDM problem.

A few weeks back we were successful in migrating a snapshot of the data stored in our Oracle database to the new schema design for Luminis IV. This was after many repeated failures over the past year. Unfortunately at the end of the process we discovered that the LDAP information (this is where a portion of the user’s data and course data is stored) was not successfully migrated. In talking with our vendor’s support line we were given a couple of choices.

At this point we are persuing one of the options but are too far out to be able to predict success.