Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    create_ora_user_b doesn't use get_ora_passwd

    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    I've recently been changing our Oracle logins for all the Aleph-related accounts, by request of our audit department. So far, I hadn't had any trouble using passwords other than the defaults, until I tried to use a process that makes use of $aleph_proc/create_ora_user_b

    I was updating the test server with new data from production, using $aleph_proc/imp_current_library. This process re-creates the library's Oracle user. Subsequently, in trying to use that user (when get_ora_passwd thinks the password is something else) it locked out that user account - I guess due to too many failed login attempts.

    The problem lies in create_ora_user_b and create_ora_user_1 setting up the new Oracle user with the default password = username. Adjusting 3 lines total in these 2 scripts to invoke get_ora_passwd and pass the current password to the SQL, easily corrects the problem.
    I've made local adjustments on our test server.

    As far as I've noticed, all other procs and utils are using get_ora_passwd.

    Resolution:
    From Christine Moulen, at MIT:

    The problem lies in create_ora_user_b and create_ora_user_1 setting up the new Oracle user with the default password = username. Adjusting 3 lines total in these 2 scripts to invoke get_ora_passwd and pass the current password to the SQL, easily corrects the problem. See below.


    File: $aleph_proc/create_ora_user_b

    Change:
    $aleph_proc/aleph_plus @$data_scratch/create_ora_user.sql $1

    To:
    set passwd = `get_ora_passwd $1`
    $aleph_proc/aleph_plus @$data_scratch/create_ora_user.sql $1 $passwd

    File: $aleph_proc/create_ora_user_1

    Change:
    CREATE USER &&1 IDENTIFIED BY &&1

    To:
    CREATE USER &&1 IDENTIFIED BY &&2


    **Note: This or an equivalent change has been included in version 20: v20 rep_ver #015721.**


    • Article last edited: 10/8/2013