Installing VirtualBox Guest Additions on Oracle Enterprise Linux 6 Guest

Are you having trouble getting Guest Additions installed on your OEL 6 guest machine in VirtualBox? I had quite a time with it myself, and while I am not the first person to encounter the issue, I had to combine tips from a few places and gain some additional understanding about Oracle Enterprise Linux to get it to work.

Assuming you’ve already installed Linux, you can start installation of Guest Additions from the VirtualBox Devices menu:

On the desktop, you will now find a shortcut to the Guest Additions. You might be prompted to open the Autorun Prompt, do this andyou should see the Guest Additions Installation start… and fail:

You are advised to examine the log at /var/log/vboxadd-install.log to figure out the cause, which in my case the log included:

/tmp/vbox.0/Makefile.include.header:97: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=<directory> and run Make again. Stop.


To resolve this you must install the kernel source which is not there by default. The Guest Additions Installation output suggests you install it via yum and even provides you the command to do so, but not so fast… if you don’t have yum configured yet  that will fail too. And you will also need the gcc package for the installer to update the kernel, but don’t worry, it’s all covered below. If you are running a version of Oracle Linux other than 6, you might visit public-yum.oracle.com first to get the correct URL for the below setup, otherwise:
# cd /etc/yum.repos.d
Next, use yum to install everything you need to get that Guest Additions Installer to work!
# yum update

# yum install gcc
# yum install kernel-uek-devel
If the above installs succeeded, try the Guest Additions installer once again:

And now you’re good to go. Now might be a good time to configure a shared folder from your host machine, and reboot to see if it works. Shared folders will appear at /media:

If these instructions did not help you, consider the pages below that provided helpful tips as I was troubleshooting the problem:

https://blogs.oracle.com/fatbloke/entry/virtualbox_and_the_unbreakable_enterprise

http://www.oracle.com/technetwork/articles/servers-storage-admin/vmlove-1368887.html

https://blogs.oracle.com/wim/entry/setting_up_oracle_linux_6

http://public-yum.oracle.com/

BatchLoader Tuning

Recently I have been tuning BatchLoader. Using sample PDFs around 100K in size, throughput was initially pretty good at 16 files per second but got progressively worse with more batches loaded; at some point reaching a low of 2 files per second.  In looking at the database activity while running BatchLoader, it was apparent that the following query was consuming 90% of the overall processing time:

SELECT DocMeta.dID FROM Revisions, DocMeta
WHERE
upper(dDocName)=upper(:”SYS_B_0″) AND
NOT(DocMeta.xCollectionID=:”SYS_B_1″) AND
Revisions.dID=DocMeta.dID

There was already an index on dDocName for the Revisions table, but because this query asks for dDocName in uppercase, the existing index is not used! To attempt to solve this problem a new index was created on the Revisions table for upper(dDocName). The result was a clear performance enhancement, with throughput in excess of 27 files per second after the change.

Conditionally hide the Standard Search and Standard Check-in links in Oracle UCM 11g

Before I begin, let me point out – this tip is specific to 11g. For an explanation of how to do this sort of thing in 10g, click here.

If you’ve read Kyle’s post on modifying the navigation menus in UCM 11g, you have a pretty good understanding of how to add your own custom links to the menu interface in UCM 11g using the new Dynamic Data tables. But what if your goal is to conditionally hide the default Standard Search and Standard Check-in links? It could be because you have created your own profiles to handle the search and check-in experience, and while you don’t want the clutter and possible confusion the default links could introduce to your users, you’d like to keep them around for admins. I’ll explain how this can be done by creating a simple Custom Component that restricts the Standard Search and Standard Check-in menu links to admins. I’ve created an example custom component called ‘CustomMenuLinks’ that does this, available for download at the bottom of this post.

If you look at the std_nav.idoc file you’ll see your standard links in the CoreMenuItems data table. The Standard Search link can be found in the linkData of the SEARCH item, and for Standard Check-in, the NEW_CHECK_IN item.

Scrolling down further in std_nav.idoc, we can see that the flags controlling visibility of menu items are configured in the CoreMenuItemsFlags data table.  To restrict a menu item to admins only, it’s as easy as adding a row with an id and flags pair. In fact, there are other flag values you can apply to menu items depending on the specific behavior you want – check the documentation for all the possibilities. At first glance it seems that adding rows for SEARCH and NEW_CHECK_IN with the corresponding flags value ‘isAdmin’ will do the job, however it is a little bit trickier than that.

CoreMenuItems SEARCH and NEW_CHECK_IN are actually more than just links. Scroll back up to the CoreMenuItemRelationships data table and you will find them referenced as parent items of the MY_PERSONAL_SEARCHES_LIST and MY_PERSONAL_CHECKINS_LIST items, respectively. These “lists” are in fact placeholders for your profile-specific search and check-in links. Setting their parents only accessible to admins would also restrict all profile-specific search and check-in links to admins, which isn’t what we want.

What you can do is create a simple custom component that makes the following changes to CoreMenuItems, CoreMenuItemRelationships and CoreMenuItemsFlags data tables:

  • Add new items for standard search and check-in, having their own labels but linkType and linkData use the values specified for SEARCH and NEW_CHECK_IN.
  •  Update the SEARCH and NEW_CHECK_IN items to leave their linkType and linkData values blank as the actual links themselves will be served by the new items. (You’ll need to specify mergeBlanks to ensure your empty values will be merged into the table)
  • In the CoreMenuItemRelationships table, configure SEARCH and NEW_CHECK_IN as parents of your new standard search and check-in links.
  • Finally, you can now add flags for your standard search and check-in links to the CoreMenuItemsFlags data table to restrict them to admins only.

To download this example custom component, click here. It consists of the below (that’s it!):

<@dynamicdata CoreMenuItems@>
<?commatable mergeKey="id" mergeBlanks?>
id,                                label,                                              linkType,   linkData
SEARCH,                            wwSearch,                                           ,
STANDARD_SEARCH,                   Standard Search,                                          cgi,        IdcService=GET_DOC_PAGE&Action=GetTemplatePage&Page=STANDARD_QUERY_PAGE
NEW_CHECK_IN,                      wwNewCheckIn,                                       ,
STANDARD_CHECK_IN,	Standard Check-In,	cgi,	IdcService=CHECKIN_NEW_FORM
<@end@>
<@dynamicdata CoreMenuItemRelationships@>
<?commatable mergeKey="id"?>
parentId,                          id,                                loadOrder
SEARCH,                            STANDARD_SEARCH,                   1000
NEW_CHECK_IN,	STANDARD_CHECK_IN,	1000
<@end@>
<@dynamicdata CoreMenuItemsFlags@>
<?commatable mergeKey="id"?>
id,                                flags
STANDARD_SEARCH,	isAdmin
STANDARD_CHECK_IN,	isAdmin
<@end@>