Bug 111260 - Overflow in checkDatabaseVersion()
Summary: Overflow in checkDatabaseVersion()
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer
Version: unspecified
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Fanny Augustin
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 113026
TreeView+ depends on / blocked
 
Reported: 2003-12-01 15:09 UTC by Nick Strugnell
Modified: 2007-08-06 15:50 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-06-08 14:10:14 UTC


Attachments (Terms of Use)

Description Nick Strugnell 2003-12-01 15:09:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2)
Gecko/20031013

Description of problem:
The satellite installer contains a procedure, checkDatabaseVersion(),
which runs the following PL/SQL code:

begin dbms_utility.db_version(:v,:c); end;

The bind variables, v and c are declared as 10 char long strings,
however this is not long enough as the Database verison on Oracle 9iR2
on Solaris returns as 9.2.0.3.0.0 which is 11 chars.

This causes the installer to bail with an error.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install RHN satellite connected to an instance of 9iR2 running on a
Solaris box.
2. Proceed to db initialisation/schema creation.
3.
    

Actual Results:  Immediately after certificate checking, an error
window displays:

ORA-06502: PL/SQL: numeric or value error: character string buffer too
small
ORA-06512: at "SYS.DBMS_UTILITY". line 519
ORA-06512: at line 1
{'SQL':'begin dbms_utility.db_version( :v,:c
);end;','Params':[(':c',''),(':v','')]})

Expected Results:  Installer should have created schema.

Additional info:

Patch:
cd install
rm satDB.pyc

Apply following patch:
--- satDB.py~   Mon Dec  1 15:10:27 2003
+++ satDB.py    Mon Dec  1 12:34:14 2003
@@ -91,8 +91,8 @@
 def checkDatabaseVersion():
     "Current supported Oracle DB versions are 8.1.7 and 9.2.0"

-    db_ver      = ' ' * 10
-    db_compat   = ' ' * 10
+    db_ver      = ' ' * 20
+    db_compat   = ' ' * 20
     h = prepare("begin dbms_utility.db_version( :v, :c ); end;");
     h.execute(v = db_ver, c = db_compat)
     version = string.join(string.split(db_ver,'.')[:3],'')

Comment 1 Todd Warner 2003-12-01 20:04:42 UTC
Lovely!
Appling patch.
Thanks.

TEST PLAN:
----------
o hmm.... difficult to test. We'll have to set up an environment that
  reports this version.
o ensure embedded DB and our DB's still report versions correctly.

Comment 2 Josef Komenda 2003-12-12 16:47:03 UTC
Need a funky db - over to Misa, who will be back in a month. Will
verify it does not break existing code until then. 

Comment 3 Mihai Ibanescu 2004-01-15 14:28:14 UTC
I don't feel like re-installing a full instance just for this. We can
probably hack the query to return a very long string instead of the
real versions.

Comment 4 Mihai Ibanescu 2004-01-26 20:33:12 UTC
komejo/jamo : please proceed with setting up the environment for
testing this bug (i.e. have a satellite installed). Then poke me and
I'll slightly change the code to return a longer string than usual.

Comment 5 Nick Strugnell 2004-09-24 10:13:58 UTC
There doesn't seem to have been any activity on this for 8 months. Is
it fixed? Can I tell my client that he can remove the hack I did for him?

Comment 6 Todd Warner 2005-09-30 15:51:10 UTC
Moving to NEEDINFO_ENG - he'll never see it ever otherwise.

Comment 7 David Lawrence 2006-04-18 20:17:05 UTC
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.

Comment 8 Mihai Ibanescu 2006-06-08 14:10:14 UTC
This has been long fixed.

    db_ver      = ' ' * 50
    db_compat   = ' ' * 50



Note You need to log in before you can comment on or make changes to this bug.