Saturday, June 24, 2006

Burleson's DBA Forum Hacked

Surprise, surprise. I received an email claiming to be from Janet Burleson with regard to my account on their DBA Forums ( The title of the email was "HACKED (Oracle DBA Forums)" and here's the text of the email.

Received: from ([]) by ;
Sat, 24 Jun 2006 10:44:12 -0700
Received: from nobody by with local (Exim 4.52)
id 1FuCAt-0007Iq-1r
for ; Sat, 24 Jun 2006 12:44:03 -0500
Subject: HACKED ( Oracle DBA Forums )
MIME-Version: 1.0
Content-type: text/plain; charset="iso-8859-1"
From: "Oracle DBA Forums"
X-Priority: 3
X-Mailer: IPB PHP Mailer
Date: Sat, 24 Jun 2006 12:44:03 -0500
X-AntiAbuse: This header was added to track abuse, please include it with any abuse
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Country: US
X-UIDL: 449E1620.A.583


Better luck next time

Oracle DBA Forums Statistics:
Registered Users: 4410
Total Posts: 1
Busiest Time: 121 users were online on 2nd May 2006 - 06:43 AM

Handy Links
Board Address:
Log In:
Lost Password Recovery:

So, is it true that the DBA Forums got hacked or was it a phising attempt? I went to the site by typing in the URL (not clicking on the link specified in the email) and everything seems okay. I don't think it's a phising attempt as there is no value in stealing a forum account unlike PayPal where there is money involved.

Saturday, June 03, 2006

Our current E-Biz work

In one of my previous entry, I talked about the licencing pricing that we had to get in order to ensure that our Oracle Financials implementation is properly licenced and for the future, our Supply Chain components too.

So, as a result, we had to migrate our existing Oracle Financials environment from a two server box to new servers (properly sized to meet current and future needs). Well, you would think that it's a no-brainer after all there are a lot of documentation in Metalink that show how an E-biz suite install can be "rapidly cloned" to new infrastructure, right? Errr...not really as it depends on the hardware involved and the nature of the "move".

In our case, we are moving from HP-UX (PA-RISC) to HP-UX (Itanium) and with Itanium in the picture, things gets a little bit complicated. Let me paint you a picture of what we current have. We currently have a separate server for the application tier which is a PA-RISC HP-UX server and it has everything except the database, the Concurrent Manager and the Reports Server which are on another PA-RISC HP-UX server. We want to move towards a totally separate database server without the Concurrent Manger and Reports Server which should be moved back to the application tier.

Since HP do not plan to carry the PA-RISC processor line beyond this calendar year, it does not make sense for us to keep our database on the PA-RISC server. Instead, we intend to move it over to one of the new Itanium servers and we would have loved to also move the Application tier to another Itanium server but unfortunately that has not been certified by Oracle yet (64-bit code). In this situation, we will be running the E-biz suite in what Oracle term a "split configuration" with the application tier on a PA-RISC server and the database tier on an Itanium server. Metalink has lots of articles on the various configuration including an FAQ. To further complicate things, we also want to upgrade the database version from to (10gR1). You might well asked, why not 10gR2? It's just that eventhough 10gR2 has been certified on the Itanium HP-UX server, E-biz itself has not been certified on the 10gR2 HP-UX split configuration although it has been certified for Linux Itanium. Go figure. Oracle plans to have the complete E-biz suite certified for HP-UX Itanium before the end of the calendar year.

Back to the approach that we are taking. First we have to do a merge since we are going from two application tier servers to one (remember, the Concurrent Manager and Reports Server are on a different server than the rest of the application tier). Since we are also moving to new hardware too, it will also be a clone and a database migration (to the new Itanium server) and finally an upgrade from to Whew! That's it. As part of the database upgrade, we will also need to follow the steps listed in the 10g Interoperability article. The challenge is that although Oracle has posted metalink articles on how to do each of these scenarios, nothing has been posted on how to do them all in one go so we are working out the timing and we will have to compress the actual work that needed to be done for final cut over as we probably only have a 48 hour window (the weekend) to shut down the existing Oracle Financials production environment, cut over, verify and start up the new environment for use come Monday morning.

It's all pretty exciting and we have already ran into obstacles and challenges which is a very good thing as it provides a fuller learning experience than if everything goes smoothly.

Once we are done in mid-July, I will provide a more detailed post on the actual steps that we took and the miscellaneous problems that we ran into.

Update June 9/06: I should note that this entry is a result of the work done by my team and the Oracle consultant who was contracted to help us with the migration.

Thursday, June 01, 2006

Yellow whiteboard markers & Oracle CPU

What's with the yellow whiteboard markers? You can hardly see them on the whiteboard and who ever came up with that colour schema should be taken out back and shot!

Most of the time, all the darker colours (black, blue, red, green, orange, purple) are used first leaving Mr. Yellow all by himself and full.

On a different topic, I see that Pete Finnigan has spent about 6 blog entries talking about Oracle's Chief Security Officer, Mary-Ann Davidson, interview in the press about the "patch mentality" and the follow-up responses from various folks to her comments. I think she's right. Look at the current Oracle CPU process being released quarterly. It's almost unworkable as you would probably spend the first couple of weeks going through the CPU notes and then another two weeks to work out the patch process (i.e. ensuring that there were no errors in the documented steps), another two-three weeks testing out the patches and then another four-six weeks applying the patches to all of your databases and then the whole cycle starts all over again. I can't see an normal organization doing that where every three months, you go through and apply patches to your environments trying to keep ahead of the hackers who probably already have zero day exploits (considering that we also have security researchers selling zero day exploits information).

Right now, we are trying to streamline our patch process so that we minimize the work and effort required while at the same time, ensuring that we are on current with patching.