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.
About bloody time! I have been able to migrate the Luminis III data to Luminis IV. There are some fine touches that need to yet be done. Specifically:
- migrate mb_topics by hand
- migrate calendar data
- migrate the group and course files and photos
- put back the custom CAR files
Those were given issues from the outset of this process, which I will work on, on Monday. Now the data present in this system goes back to June of last year.
Perhaps I should not shout from the rooftops just yet, but I was actually able to log in and see a fairly functional portal unlike previous attempts where the bulk of the channels were broken.
The url for those that monitor this blog is http://lumnext.cc.umanitoba.ca
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.
Well look at that they did get it and it has been disabled. Yeah!
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.
Continued my attempts at installing Luminis IV on a RHEL 4 system. Ran into some issues that were sovled easily. Namely clearing the DISPLAY environment variable. However this still did not work in the end. Still in touch with the vendor on how to proceed.
I am also attempting another migration of Luminis III to Luminis IV. I have not heard back from the vendor but am going to try and remove the mention of a nonexistent user from one of the xml documents as the last attempt did complain about that user. I raised this with the vendor but they felt it was not the issue so I do not have high hopes, but despite that I figure it is worth a try.
Dealt with some lingering JUMP Lite login issues for employees and parking. Began work on preparing brax to replace apollo as our Luminis IV test server. As part of the EBS system makes use of apollo spoke with Bill on what we will need to do in order to move that code from apollo to brax.
We now have the USask drag and drop working in Luminis III, including their ‘add stuff’ feature. There are some aspects of this we need to tweak prior to putting it into production. Also when time permits I will look at reworking the ‘add stuff’ feature to make use of AJAX/JSON as opposed to being a traditional channel embedded in the layout. I feel this will give a performance boast as we have noticed very little customisation to Luminis so no sense in pulling in a bunch of content that may never get used.
Responded to Sungard in regards to our recent LDAP migration issue and their desire for our export data. I have requested they get back to me with the break point sand variable monitoring the develoepr would like to do (assuming that was at the heart of the request for data) and said I can do this and share the results.
Had a brief discussion with Brian in regards to where we are potentially going with handling RSS content in the future. I also began work installing the USask Drag and Drop into development. At this point it is there, but some aspects are throwing errors (i.e. add stuff). I hope to iron those out next week.
We also talked about the idea of switching back to the out of the box webmail client solution for JUMP as opposed to the link to Horde/IMP. Further talk will be needed.
Today I continued work on building an application that will filter out old events from our calendar files. It appears to have been successful against my ical file. I am lacking the various proeprty settings at the top of an iCal file but that will be tomorrows task.
The plan is to use the same property data in the orignal file for the new one, minus any non America/Chicago timezone properties.