RAC Listener Best Practices

The listener is a small part of an Oracle RAC configuration – and maybe that’s why it is so often overlooked and setup with only the defaults. More often than not, the listener gets setup automatically by DBCA during the ASM or database configuration. However this is not a good practice at all; at best it leaves security holes and at worst it configures your listener totally wrong.

Getting listener configuration right is actually very simple. Following these five best practices will ensure that you have a secure and optimal listener configuration on your RAC database.

1. Make sure that you’ve installed the latest required patches.

   This should be common sense by now: one of the most important security practices is to make sure that the latest patches are applied to your system. Especially if you’re doing a new installation, there’s no excuse for not making sure that the system is up-to-date. There are three steps to getting the right patches: (1) install the latest patchset available for your platform, for example at the moment on Linux this is 10.2.0.3; (2) install the latest CPU (Critical Patch Update) listed at http://www.oracle.com/technology/deploy/security/alerts.htm; and (3) install any additional required one-off patches; for 10.2 you can check metalink note 316900.1 for the latest information and they usually do a good job of keeping this list down to the bare essentials.

2. Configure the listener from the ASM home if and only if there is more than one DB home on the machine.

   If you are using ASM with Oracle 10g then it is a best practice to install two copies of the Oracle DB software; one for ASM and one for the database itself. Although it is not recommended, it’s possible to have multiple versions of Oracle running on the server. If there is more than one database home (not including ASM) then you should run the listener from ASM since the listener is treated as a node-level (not database-level) resource by the clusterware. For example, if you have a 10.1 database and a 10.2 database on the same server then your ASM home must be 10.1 and the listener should run from there. If there will only be one database home then it makes sense to go ahead and run the listener from there since you probably want listener-related patches to go into the database home rather than the ASM home.

3. Explicitly configure the listener before creating any ASM instances or databases.

   Whether you manually create the LISTENER.ORA file or use NETCA, you should explicitly configure the listener rather than relying on DBCA to do it for you. DBCA will choose default settings from whatever home it happens to run from. For example, one good security recommendation is to run the listener on a non-default port – and DBCA will not configure this.

4. Configure the listener to only listen on the VIP address.

   By default the listener will listen on all public IP addresses. However in a RAC system only VIP addresses should be used to access databases. The public non-VIP address can be used for system administration, but never by oracle clients. You should configure the listener to only attach to the VIP addresses since clients should only connect to that IP. If you used NETCA to configure the listener, then you will need to manually edit the LISTENER.ORA file to make this change. Comment out the line with the public IP address.

   [oracle@iss-365-rac01 ~]$ cd $ORACLE_HOME/network/admin
   [oracle@iss-365-rac01 admin]$ head listener.ora
   # listener.ora.iss-365-rac01 Network Configuration File: /u01/app/oracle/product/10.2.0/db/network/admin/listener.ora.iss-365-rac01
   # Generated by Oracle configuration tools.
   
   LISTENER_ISS-365-RAC01 =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
         (ADDRESS = (PROTOCOL = TCP)(HOST = iss-365-rac01-vip)(PORT = 1521)(IP = FIRST))
   #      (ADDRESS = (PROTOCOL = TCP)(HOST = iss-365-rac01)(PORT = 1521)(IP = FIRST))
       )

   By the way, the clusterware in 10.2 contains a default dependancy between the VIP and the listener; it will always make sure that the VIP is available before starting the listener.

   [root@iss-365-rac01 ~]# crs_stat -p ora.iss-365-rac01.LISTENER_ISS-365-RAC01.lsnr|grep REQ
   REQUIRED_RESOURCES=ora.iss-365-rac01.vip

5. Secure the listener.

   At a minimum you should (1) set a listener password, (2) set ADMIN_RESTRICTIONS, and (3) secure the TNS_ADMIN directory. Integrigy has released an excellent whitepaper on Listener security and all of their recommendations are still valid on version 10.2 of Oracle.

Following these basic guidelines can save you a headache or two down the road. They will keep the right people connecting properly and keep the wrong people from connecting at all.