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
restarted.
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.
Martin
--
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
