Wednesday, June 09, 2010

On the error message soapbox again

Q. What's wrong with this message?

Database Configuration Assistant: Info - There is an error in creating the following process: /data/ora/oracle/product/11.2.0/dbhome_1/bin/sqlplus -s -N /NOLOG  The error is: /data/ora/oracle/product/11.2.0/dbhome_1/bin/sqlplus: error while loading shared libraries: /data/ora/oracle/product/11.2.0/dbhome_1/lib/ cannot restore segment prot after reloc: Permission denied
A. The window that it pops up in doesn't support copy-and-paste (on Fedora 13, at least). If you want to websearch for this message, you have to type it in by hand.

Hey, Oracle - fix it, please? It's the sort of usability problem that I wouldn't nag you about if you were a little FOSS project or a mom-and-pop software shop, but you're a big company with fifty bazillion programmers and entire committees on usability, so I know you can do it.

I'm sure that's the fault of whatever Java GUI library underlies your graphical tools like dbca... so go on and fix the library, and the whole world will benefit!

Also, in keeping with my fixation with good error messages, I implore you to think about error message usability ahead of time. I suspect that error messages get the short end of developer attention because they never appear in sales presentations. Well, actually, they do appear in sales presentations, they're just not supposed to... (although, frankly, watching somebody work through an error is a million times more interesting than watching a polished sales pitch)

Q. What else is wrong?

A. The workaround to this error is to disable SELinux. For the ultimate bestest securest database EVAR, doesn't that seem a little cheesy?

Q. Anything else?

A. Until you actually achieve SELinux compatibility, how about trapping the error with a message that describes the workaround? Failing that, mentioning in the Installation Guide that SELinux should be turned off is a next-best solution... no, come to think of it, forget I said that. "It's on page 732 of the docs" is actually a terrible excuse for leaving a bug unfixed. I don't know how "document it" became an acceptable alternative to "fix it".

Q. Are you finished yet?

A. Almost. After more than 10 years of DBA work, I actually don't know what the proper channel is for making suggestions to Oracle Corp. I end up ranting about it on my blog, approximately the equivalent of wandering into the street and yelling about it. Is that silly or what?

I'm Catherine Devlin, and I approved this message.


Noons said...

Awesome post! I particularly like the last bit: "After more than 10 years of DBA work, I actually don't know what the proper channel is for making suggestions to Oracle Corp."

Join the club: it's been 20 years here... And I'll hazard a guess: there will likely be in the near future an official statement from Oracle on how to do it and how others have been doing it "for years".

It'll likely also involve an additional cost, or some silly "Ace" idiocy...

Unknown said...

Actually, I would think the proper response (assuming that it is an SELinux policy violation causing this) would be to create the appropriate policy module. Yes, it's a little "fiddly" to get it all working right, but I think it's a _whole_ lot better than just disabling SELinux.

Unknown said...

Ken, thanks for the suggestion. Can you follow it up with a pointer to a good way to learn enough SELinux to write a policy? (Ideally, of course, Oracle would compose and publish such a policy.)

Unknown said...

I'm no expert with SELinux by any means. Having said that, the process I've used in the past takes advantage of the "audit2allow" utility.

(Also note that I'm a "RedHat/CentOS/Fedora" user. I have no idea if/how this would translate to any other distro.)

Disclaimers aside, briefly:

1) Change SELinux mode from Enforcing to Permissive. (This causes the tests to occur, but logs events rather than blocking them.)

2) Use audit2allow to scan the log file and create the policy.

3) Use semodule to install the new policy.

4) Change mode back to enforcing.

5) Watch it fail again, but with a different message.

6) Repeat steps 1-4 until you have a complete set of policies that allow it to work.

A good intro to this sequence can be found in section 7 at

Unknown said...

(Brief follow-up to previous comment.)

I've used that process twice now to get recalcitrant databases working under SELinux, so this isn't just an Oracle issue. (Both DB2 and MySQL have given me problems.)

Mark Roddy said...

I could not agree more. The Oracle install/configuration process is a nightmare. I've lost track of the number of times I've forgotten the selinux issue. I've sadly since added disabling it to my 'server setup' check list.