LDN - Luminis Developer Network

Our Luminis database has crashed because of memory issues. Initially we had 4 gigs of ram on the database server with 2.8 gigs allocated to Oracle. We then increased the database server to 5.5 with the database at 3.2. It crashed at this point so we increased the database server to 8 gigs and the database to 5.5 gigs.

We're trying to get from redhat 3 to redhat 4 for Luminis IV. The sys admin who set up our current systems is gone. Working with the new sys admin, I'm trying to replicate the functionality of our RH 3 system on RH 4.

The sticking point is that from the luminis admin OS account, I can't issue startcp or stopcp, it is demanding the root password.

The sudo-ers setup has been replicated. It looks good ... at least it's the same on the new RH 4 host as it is on the production RH 3 host. Far as I can tell, I have /etc/passwd and /etc/group right.

Discussion question: what are the major functional changes to Luminis that you have seen released in the 4.x.x releases of Luminis?

There are often technical reasons for upgrading Luminis due to bug fixes, technical capabilities, etc. But I am curious to hear what functional changes between the minor releases of Luminis 4 have stood out to the lumdev community as valuable or noticable?

Another way to ask the same question, if you were recently on a "recommended build" of Luminis 4.2.x.x, what reasons (other than bug fixes) have motivated you to upgrade to the next minor version?

Prioritizing or re-ordering the announcements in the Personal Announcements channel is a common Luminis request I hear. Our district was no different. With all of the messages sent from Course Studio, Group Studio, and Targeted Messages, other important messages (like Banner Smart Events) blend in with the rest or get pushed off the list.

Our solution was to implement 3 Changes:

Hello Everyone,

I'm doing a bit of analysis and was wondering if someone could further clarify my research concerning how Luminis is using the passwords for other systems.

It is my understanding that when Luminis is told the password, it then SHA encrypts the password with the key being Luminis's actual login password. That way nobody can just unencrypt the 1 password unless they know the other.

Is this the way it works?

I'm looking for information that supports some of the advantages or disadvantage with having a fluid vs a static layout for luminis. What is the normal practice, in regards to fixed/fluid width, for your institution? By default luminis provides a fluid layout that allow for the width of the portal and the channels to scaled. However, I've heard arguments that support having a fixed width will allow more control and confidence over the presentation layer and the user experience with the exception that width consideration over developing channels is a little more involved.

I've received a few requests for our jQuery customizations lately, so I've decided to split them up into chunks (modules) and post them on the lumdev svn repository. This page will serve as the home for these customizations, but I'll probably do a post for each individual module also (mostly because I already have one for the tabbed content).

In general, our philosophy with these UI mods is that they should be light-weight and easy to manage/reapply to luminis. Since they are almost completely client-side, they act as more of an overlay to the baseline luminis functionality.

Our Luminis implementation has been largely successful. We've got the data to show that people are using it. They routinely give us positive feedback for a few of our more popular channels that have made their lives easier (yay us!) and they will tell us pretty darn quickly if they find a typo (boo us!) However, the one piece of feedback we get most often is not positive.