Archive for July, 2010

Changing the Server Name for Automation Server

Thursday, July 29th, 2010

It’s not without some controversy (OK, “spirited discussion”), but I’ve strongly recommended the use of host files to aid environment portability.  If you’re a believer in this “alias” approach, you’ll find that for some components, it isn’t very obvious how to set up those aliases.  This isn’t quite a host file hack, but serves the same purpose:  when you migrate the database from one environment to the other, you want to avoid having to change as many settings as possible.

One of these settings is the ALUI Automation Server: in “Select Utility: Automation Service”, you get a list of servers running the Automation Service, and can set which administrative folders are associated to which Job (aka Automation) Servers.  If you migrate the portal database between environments, you might have one entry show up for “PRODPORTAL3″ (in prod) and another for “PORTALDEV9″ (in dev).  But then in the dev environment you have to re-register every one of the folders that was associated with the prod folder. 

What if you could just create an alias that worked in both environments?  Fortunately, you can, and the tweak is easy:  Just edit %PT_HOME%\settings\configuration.xml in both environments, and change the value below to be the same thing.  Then, when the automation server in either environment starts up, it’ll look for jobs registered with that same name:

<component name="automation:server" type="http://www.plumtree.com/ config/component/types/automation">
<setting name="automation-server:server-name">
<value xsi:type="xsd:string">WCI-AUTOMATION</value>
</setting>

Oh, and if you’re a “UI” kind of person, you can achieve the same result by changing the name through the Configuration Manager:

What Pages are those Portlets on?

Sunday, July 25th, 2010

You can do a lot with a few simple SQL queries against the ALUI / WCI database.  Oracle (and I) strongly discourage any direct database updating without using the API, but there’s nothing out there that says you can’t QUERY the database – heck, for Analytics server, it’s actually encouraged (PDF Link).

So, today’s post is an easy one that answers the question: “which pages and communities are my portlets displayed on”?  The SQL is simple:


 select
                        ptcommunities.name community_name,
                        ptpages.name page_name,
                        ptgadgets.name portlet_name
from
                        ptcommunities,
                        ptpages,
                        ptpagegadgets,
                        ptgadgets
where
                        ptcommunities.folderid = ptpages.folderid
and                ptpagegadgets.gadgetid = ptgadgets.objectid
and                ptpages.objectid = ptpagegadgets.pageid

… and you’ll get a list of communities, pages and portlets that you can sort or filter any way you want:

Cool Tools 7: Benthic Software’s Golden

Wednesday, July 21st, 2010

For those of you that use the Oracle DB in your portal stack (or for pretty much anything), you know what an atrocity Oracle’s SQL*Plus is (it’s more dated than Plumtree / ALUI!).  I’ve looked on and off over the years for a simple Oracle client that works as well as Microsoft’s SQL Server Management Studio, and I want to thank Hani Atalla for turning me on to this one: Benthic Software’s Golden.  It’s hyper-simple to use, and even has all the “creature comforts” like being able to copy a result set into an Excel Spreadsheet (try doing THAT with SQL*Plus!).  It does require Oracle’s Instant Client to work, but even I (as a non-Oracle DBA) was able to install both in a matter of minutes.

If you’ve sweated through SQL*Plus sessions for way too long, definitely check this tool out – it’s cheap, at only $40.  If you’ve got a better tool for quick and easy Oracle DB queries, I’d love to hear about it in the comments!

Analytics – SAML2Keystore value

Saturday, July 17th, 2010

Look, I’ll make this quick and profess my ignorance:  I’m not really sure what the whole “Key Service” thing is in WebCenter Analytics; it’s obviously a security token that needs to be set in multiple places (the Configuration Manager and Java Keystore) to work properly.  A little while ago, I had a client accidentally change the value, and Analytics wouldn’t work.  The keystore passphrase no doubt exists somewhere in the Analytics JRE, but I couldn’t find out where to reset it.  So, I couldn’t find out where to change it in the JRE, and didn’t know what it was suppose to be, so Analytics was DOA.

I got lucky on this one, and hopefully if you found this post through a Google Search, you’ll have saved yourself the headache of trying to figure out what value should be in there.  The answer is in the Analytics Configuration Worksheet (PDF link):

That’s right: it’s “saml2keystore“.  Anyone know how to reset the actual value in Java’s Keystore for Analytics?

Security Reminder: Stay Vigalent!

Tuesday, July 13th, 2010

Government work can be a challenge with all the rules, regulations, and procedures that come with it.  But there’s one thing I have to continually remind myself when dealing with that “way too much paperwork” thing: whether I’m administering a government web site, ALUI portal, or any other web application is that security can and MUST be taken seriously at all times. 

So, consider this a friendly reminder – especially if you’re exposing your portal on the Internet: stay vigalent, and take all threats seriously.  About 18 months ago, I got an alert in the middle of the night that we were out of drive space on a portal server at one of my semi-government clients.  No big deal; it happens all the time.  Only this time it was different.  Overnight, our logs had exploded from roughly 20MB/day to 2GB/day:  something was seriously wrong.  The logs were so big they were hard to even open, but when i did finally crack them open, here’s a snippet of what I found:

Basically, there were GIGABYTES of these requests – someone was scanning our servers, alternating in different object IDs for different spaces, looking for incorrectly secured communities or other portal objects.  They were basically just scanning different activity spaces, making all kinds of semi-random requests with different IDs a couple times a second.

It turned out that these particular baddies weren’t that sophisticated: they were making no effort to conceal their source IPs through some sort of distributed attack, and their algorithm clearly didn’t demonstrate a deep knowledge of how portal URLs are constructed.  And honestly, we were lucky for even finding this attack in the first place because at the time we didn’t regularly audit the logs, and only caught it because of that benign disk space warning.

In the end, we blocked the entire subnet (from China, a notorious hacker hangout), and the attacks stopped.  We should have reported the attempted breach, and I certainly would if it happened again, but I’m sharing this story with a single moral: no matter how “little” you think your site may be or how you think “noone cares about my little corner of the internet”, the bad guys are out there, and they don’t discriminate when they’re looking for victims.

So, take a minute today to check your security settings one more time, and keep an eye on those log files for anything suspicious!

Increase WCI Collaboration Server Memory Settings

Friday, July 9th, 2010

The Plumtree Server stack has had a long history, forming a decent patchwork of usable applications, but never quite getting to the point where every part of the stack is consistently configured.  When it became ALUI (AquaLogic User Interaction), there was a movement towards putting configuration settings in one place – the Configuration Manager – but unfortunately now that Oracle is holding the reins and the future of the stack is in question, it looks like we’ll never have that utopian vision of single, centralized way of configuring all applications the same way.

Case in point:  configuring the memory parameters for Collaboration Server.  While Publisher utilizes a config file for memory settings, Collaboration Server passes memory parameters via the service startup path.  So, if you’ve got a decently large Collaboration install, you might find that you’re running relatively low on memory:

To up the amount of RAM available to Collaboration Server, you need to edit the registry (and yeah, back it up first!).  The key you need to change is in HKLM\ SYSTEM\ CurrentControlSet\ Services\ ptcollaborationserver, and it’s called “ImagePath”:

Change the “-Xmx” value to something larger, restart Collab, and you’ll have more RAM breathing room:

Deploying WCI API applications without the portal installed

Monday, July 5th, 2010

Many of you have developed WebCenter Interaction portlets (and ALUI before that, and Plumtree before that), and you likely know the difference between the WebCenter Interaction Development Kit (IDK) and the Portal Server API. The difference is pretty straightforward: the IDK provides a relatively simple way to get started and provides Portal Remote Calls (PRC) to manipulate various objects. But it’s not all that powerful, and there are a LOT of things you simply can’t do with the PRC. That’s where the Server API comes in: it can pretty much do anything the portal itself can, but it is significantly more involved to setup. This has to do with how they both work:

  • The IDK / PRC makes remote SOAP calls to the WS API server in the portal stack. The WS API server (and, in some cases, Collaboration Server or Publisher Server) are the services that actually do the heavy lifting, like manipulating the database.
  • The API, on the other hand, is essentially a fully working portal loaded using either .jars (Java) or .DLLs (.NET), so it has full access to do anything the portal can, but also needs all the portal configuration files and secondary libraries (such as for the search server) installed on the machine.

The easiest way to use the API on a remote server is to install a portal component such as the portal itself, or Automation Server. But in some cases, this isn’t desirable; you just want your application running on the remote tier without actually installing the portal. In this case, you will need to do a pseudo-install by copying all the correct files to your portlet server, updating the configuration properly, and setting various environment variables so the portal code can find the files it needs. I should also point out that there is no harm in using Java files on the remote tier even if you’re using a .NET portal; the code is the same, and fundamentally serves the same purpose – handling updates to the database.

So, here’s a quick guide on how to set up a portlet on a remote server that doesn’t have the portal installed:

  1. Make sure your application has the same .jar files (or .dlls, if it’s a .NET app) as the portal is using in your environment: you want to make sure that your remote libraries are exactly the same as the portal libraries so they do the same thing when run.
  2. Copy the ptportal, settings, and common directories from %PT_HOME% on one of your portal servers to a folder on your remote server – in my case, I’m using C:\integryst\, so you should have the following subfolders:
    1. c:\integryst\ptportal
    2. c:\integryst\settings
    3. c:\integryst\common
  3. Update c:\integryst\settings\configuration.xml: replace all instances of c:\bea\alui\ptportal\10.3.0\webapp with c:\integryst (or whatever source/destination folders you’re using). Also, replace the original machine name with the remote server’s machine name.
  4. Set the following environment variables:
    1. ICU_PATH=C:\integryst\common\icu\2.6\bin\native
    2. INXIGHT_PATH=C:\integryst\common\inxight\3.7.7\bin\native
    3. OUTSIDEIN_PATH=C:\integryst\common\outsidein\8.1.9\bin\native
    4. PORTALLIB_PATH=C:\integryst\ptportal\10.3.0\bin\native
    5. PORTAL_HOME=C:\integryst\ptportal\10.3.0
    6. PTHREADS_PATH=C:\integryst\common\pthreads\2002.11.04\bin\native
    7. PT_HOME=C:\integryst
    8. PATH= C:\integryst\ptportal\10.3.0\bin\native; C:\integryst\common\pthreads\2002.11.04\bin\native; C:\integryst\common\outsidein\8.1.9\bin\native; C:\integryst\common\inxight\3.7.7\bin\native; C:\integryst\common\icu\2.6\bin\native;

… and that should do it! Now, when you run your application, if you have PTSpy installed (or even if you don’t), you should see messages in there when the app starts up that look just like the portal startup messages, because that’s essentially what you’re doing in your code – loading the entire portal and leveraging any APIs that are available to the portal itself!