Core Content Only

For those of you that have ever tried to setup an Oracle Database on Linux you know there are a variety of steps to take on your fresh box before you can actually begin the installation process.  You will need to install serveral binaries and those will perhaps have several depedencies.  After that you will need to create an “oracle” user.  And the list goes on.  If you have a support subscription with a valid Customer Support Identifeir (CSI) this whole process gets MUCH easier.

My Unbreakable Linux Network support subscription and accompanying CSI allow for the use of the “up2date” command.  This will update the binary I ask for as well as deduce, install and/or update any dependencies.  Technically, I can accomplish the same tasks without the subscrption.  This would require that I look up (and not miss) binary depedencies while also having the time to manually hunt down, download and install the binaries by hand.  Or I can just use the up2date command!

Having just installed OEL5.4 and registered the box with the Unbreakable Linux Network I can use the up2date command along with the parameter “oracle-validated”.  Running this command will update all the necessary binaries in prepartion for installing Oracle Database.  It will resolve and install or update all related dependencies of those binaries.  It will aso create the OS user oracle along with the oinstall and dba OS groups.  Let’s try it out here:

[bash]
[root@localhost ~] up2date -i oracle-validated

Fetching Obsoletes list for channel: el5_x86_64_latest…

Fetching rpm headers…
*******************************************************

Name Version Rel
———————————————————-
oracle-validated 1.0.0 22.el5

Testing package set / solving RPM inter-dependencies…
There was a package dependency problem. The message was:

Unresolvable chain of dependencies:
glibc-headers 2.5-42.el5_4.3 requires kernel-headers
glibc-headers-2.5-42.el5_4.3 requires kernel-headers >= 2.2.1
oracle-validated 1.0.0-22.el5 requires kernel-headers
[/bash]

Oops. Need to update the kernel headers. When you try to run up2date again telling it to update kernel-headers it will likely not do so. This is because of how up2date is currently configured. We can override the configuration by using the –force command:

[bash]
[root@localhost ~] up2date –force kernel-headers

Fetching Obsoletes list for channel: el5_x86_64_latest…

Name Version Rel
———————————————————-
kernel-headers 2.6.18 164.15.1.0.1.el5

Testing package set / solving RPM inter-dependencies…

kernel-headers-2.6.18-164.1 ***************** Done.
Preparing ***************** [100%]

Installing…
1:kernel-headers ****************** [100%]

[/bash]

Now when you run your up2date command with oracle-validated it should work a lot better.

The new (as of around March 15^th) Core Update Bundle (build 55) includes an updated Folders_g component.  If you have tried to install the Folders_g component that came with the update bundle released on or around December 30^th of last year you may have ran into issues with the install not working.

The issue revolved around new installations of the folders component not creating tables, etc. in the database.  If you had previously installed folders and you simply upgraded you may have been fine.  This only seemed to affect new installs.

Either way, grab the newest update bundle and hopefully we can put these issues behind us.  So far, from what I’ve tried, it has worked much better.

When you are developing and testing workflows in UCM the Update Event of a step in a workflow can be your worst enemy.  The update event is fired off roughly every sixty minutes in a standard configuration of UCM.  Any IdocScript you create in your Update event of your step then might have to wait as much as sixty minutes to execute.  This makes testing these scripts difficult.  Sure, in some cases you can use the built in test harness.  However, this little configuration will be a big boost:

DoDebugFastScheduledEvents=true

Adding this configuration variable to you <install>/config/config.cfg or through the Admin Server under General Configuration and restarting your content server will give you a big development/test boost.  This reduced the period from sixty minutes to five minutes.

Happy workflow debugging!

If you want to hide the alternate file on the check-in page you can add the following configuration to your <install>/config/config.cfg file.  You can also add this to the General Configuration Variables in the Admin Server.  Both of these methods will require a restart.  This will hide alternate file globally.  And what is the setting?  It looks like this:

suppressAlternateFile=1

What if you would like to do this for a certain profile, but not globally?  No problem.  Simply select one of your rules for your profile.  Enable the activation conditions and add this setting as a side effect:

<$suppressAlternateFile=1$>