Re: Oracle Security Alert for CVE-2012-1675 - 10g extended support

  • From: Martin Bach <development@xxxxxxxxxxxxxxxxx>
  • To: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
  • Date: Fri, 04 May 2012 21:26:00 +0100

Hi Brandon,

thanks for sharing-and I agree! On the upside I'm able to generate a lot 
of the configuration changes by default-i.e. create a dbca template with 
the local listener set. I can also package a listener.ora file as part 
of the deployment process which has a key matching the local_listener 
init.ora parameter. Point taken about brief outage when listener is 

In your (and everyone else's experience), how long does a listener 
start/stop take? If it's in a shell script it might be very quick, and 
done over a quiet period shouldn't hurt too much.



On 04/05/2012 21:14, Allen, Brandon wrote:
> The main advantages I was thinking of with DYNAMIC_REGISTRATION_LISTENER=OFF 
> vs. SECURE_REGISTER_LISTENER=(IPC) is that setting DRL=OFF can be done 
> without any downtime at all, while setting SRL=IPC requires a brief outage 
> while the listener is restarted.  I also like the fact that all the config 
> changes are in one place (the listener.ora), vs. the having to update 
> LOCAL_LISTENER in all the database instances to use IPC.  I would document 
> the requirement for static registration in the database-specific 
> documentation so DBAs should be aware of it and if not, they should figure it 
> out pretty quickly during initial testing of a new database so I'm not too 
> concerned about that.  The same thing could be said for using SRL=IPC - if 
> the DBA doesn't remember to configure local_listener to use IPC on a new 
> database, then users won't be able to connect either.
> Regards,
> Brandon
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
> Behalf Of Martin Bach
> just wondering - is there a reason for those on the list to turn off dynamic 
> registration of listeners in single instance
> ________________________________
> Privileged/Confidential Information may be contained in this message or 
> attachments hereto. Please advise immediately if you or your employer do not 
> consent to Internet email for messages of this kind. Opinions, conclusions 
> and other information in this message that do not relate to the official 
> business of this company shall be understood as neither given nor endorsed by 
> it.


Other related posts: