Exactly what are you trying to do? For having a daemon (or demon,
for that matter) lurking in the darnkness of the central server and
resetting expired passwords, the daemon needs to maintain a permanent
connection with sufficient privileges to change any user's password,
typically, a dba connection. If your DBA doesn't use profiles, with
the idle time limitation, you can have a permanently connected process
which would change password as soon as it was signalled to him. The
question is: what would the password be changed to? There are strings
which are extremely hard tu guess (username, "qwerty", "password", "tiger")
and which would make your username secure. At one of my places of
work, I've witnessed the following story: a tech support expert leaves
a unix worsktation logged in, as root, and goes home at 6 PM, when cleaning
ladies entered the office. One of the cleaning ladies had a 14 years old
son which wanted to check the old joke with "rm -rf /". He found out
that it really does destroy everything on a unix system. Now, you are absent,
your password expires at 7 P.M. and there is an eager help desk person who
wants to test "drop tablescpace FIN_DATA including contents and datafiles
cascade constraints" that he or she has seen written somewhere. I'll leave
the rest of the story to you.
On 02/23/2004 03:03:19 PM, "Vergara, Michael (TEM)" wrote:
> More cogitating now prompts me to ask this question. Jared
> (et al), could this be done in Perl?
>
> I'd really like this utility to not have to plant a client
> procedure or something at the remote DB. That's why I was
> trying to use Java from inside a central admin DB. However,
> since that central admin DB runs on a central server, is=20
> there a Perl ... um ... object that will connect and reset a
> password even if the user account has expired?
>
> If so, I'll dig into the Perl docs. This is an unexplored
> country to me. I can barely spell Perl!
>
> Cheers,
> Mike
>
>
> -----Original Message-----
> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> Sent: Monday, February 23, 2004 10:49 AM
> To: oracle-l_at_freelists.org
> Subject: Re: Slightly OT: Java in the DB
>
>
> Neither MetaLink nor Google have ever heard of ORa-21607, save
> the same stuff you saw from oerr.
> Time for an iTar
>
> Jared
>
>
>
>
>
>
> "Vergara, Michael (TEM)" <mvergara_at_guidant.com>
> Sent by: oracle-l-bounce_at_freelists.org
> 02/22/2004 01:13 PM
> Please respond to oracle-l
>
> =20
> To: "Oracle-L (E-mail)" <oracle-l_at_freelists.org>
> cc:=20
> Subject: Slightly OT: Java in the DB
>
>
> Hi All...sorry for the semi-OT post, but I'm trying to do a DBA
> function using Java and have run into another problem.
>
> I'm trying to reset user's passwords. That's the whole goal.
> I have a 'administrative' database that has connections (TNS,=3D20
> some DB links, etc) to other databases. I want to use the
> OCINewPassword function call in a stored Java procedure
> to execute the password changes on remote databases. I have=3D20
> this neat code that I cobbled together from hints on MetalLink
> and other places, and it works...but.
>
> The Java source compiles.
> It Loads into the DB with loadjava.
> I build a PL/SQL function wrapper.
> It executes. It changes the password and exits the remote DB
>
> Great. This is good.
>
> But...when I enter 'exit' at the SQL prompt, the process hangs,
> spins up to taking 100% of the CPU, and throws various errors in
> the trace file. I have to kill the client process with a 'kill -9'
> command to get the process back. There is one error I cannot=3D20
> figure out. It's an ORA-21607 error. It says "Initialize the=3D20
> memory service handle". Huh? What in the blinking blue blazes=3D20
> does that mean?
>
> Any suggestions? I'm gonna post a similar message on the Java
> list, but I thought that they'd not know about an ORA-21607.
>
> Help!
>
> Thanks,
> Mike
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Mon Feb 23 2004 - 14:17:53 CST
