CHAPTER 13
Note For
information on leveraging the Oracle 12c RDBMS Server PreInstall RPM
for automating Linux server configurations for Oracle databases, please
review Chapter 11.
Note In
Oracle Database 11g, the maximum size of an Oracle ASM disk can’t be
larger than 2TB. Starting with Oracle Database 12c, the maximum size of
an ASM disk can be up to 32 petabytes (PB) for allocation size (AU) of
8MB. For other AU sizes, the maximum ASM disk sizes are: 4PB for 1MB AU
size, 8PB for 2MB AU size, and 16PB for 4MB AU size.
Note Run the ssh -V command to check the type and version of SSH installed on your server.
Note You can also launch ntsysv through the text mode setup utility by running the OS setup command and selecting System Services from the menu.
Note The
default SSH port number that the Linux/Solaris server will listen on is
22. To change the default SSH port number, modify the value of the
parameter Port in the /etc/ssh/sshd_config file.
Note To disallow the root user to log on via SSH, set the parameter PermitRootLogin to no in the /etc/ssh/sshd_config file. Once the non-root users have successfully logged on to the Linux/Solaris server via SSH, they can then run the su - root command or run the sudo command instead.
Note For security reasons, we recommend that you supply a passphrase when creating the SSH host key. This prevents non-root users from peeking on the SSH host key by running ssh-keygen with the -y option (discussed in detail in the next section).
Note If your Linux/Solaris server supports only SSHv2, set the value of the parameter Protocol to 2 in /etc/ssh/sshd_config.
Note You can run the ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key and ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key commands to verify the SSH host key fingerprint and SSH host key of the server.
Note If you want to run an X Window application on the remote Linux/Solaris server, run the ssh command with the -X option. For additional information about running an X Window application via SSH, refer to recipe 15-5.
Note To troubleshoot SSH connections, run the ssh command with the -v option to display debugging messages. For more debugging messages, run with the -vvv option instead. We also recommend that you review the /var/log/secure and /var/log/messages files.
Note The sftp command is another protocol to securely transfer files between Linux/Solaris servers. However, we excluded examples of the sftp command because the sftp protocol is not yet an Internet standard.
Note The scp command replaces the rcp
command because the latter is not a secure way of copying files between
Linux/Solaris servers, particularly when the data is traversing the
Internet. We recommend that you use the scp command to safeguard your critical data.
Note PuTTY also provides a pscp.exe client to securely copy files from the Microsoft Windows environment to a UNIX/Linux environment. You can download pscp.exe from PuTTY’s download page.
Note If
you immediately press Enter or Return when asked to provide the
passphrase, or if you provide the passphrase incorrectly three times,
you will be prompted instead for the actual password of the OS username
that you want to use to log on to the remote Linux/Solaris server.
Note When running Xorg -configure,
you might see this error message: “Fatal server error: Server is
already active for display 0. If this server is no longer running,
remove /tmp/.X0-lock and start again.” To avoid this error, delete the file described in the error message.
Note When troubleshooting X server, always check the log file /var/log/Xorg.0.log, as well as /var/log/messages for Linux and /var/adm/messages for Solaris.
Note To show the details of the X server, run the OS command xdpyinfo.
Note Running
an X server on your Linux database server can pose security issues
because another client can access and observe your keystrokes. For
security measures, we recommend that you employ access control using xhost or tunnel X over SSH, as discussed in recipes 15-4 and 15-5.
Note The X command may be in a different directory from other Linux distributions, so run the command which X to determine the exact directory.
Note The default port for X server is 6000. If this port is blocked, a workaround is to run ssh with the -X option to display th.plication, such as xclock or Oracle’s dbca.
Note To learn how to configure SSH tunneling using PuTTY, refer to recipe 1-1.
Note To troubleshoot your SSH connection, run the ssh command with the -v option to display debugging messages. For more debugging messages, run with the -vvv option instead. We also recommend that you review the /var/log/secure and /var/log/messages files.
Note To have a similar look and feel of your desktop as when you log on to the console of the Linux server, uncomment or add unset SESSION_MANAGER and /etc/X11/xinit/xinitrc to the $HOME/.vnc/xstartup file.
Note You can purchase a VNC license at https://www.realvnc.com/purchase/.
Note For additional details about creating OS groups and users, refer to recipes 3-12 and 3-14.
Note After
the VNC Server is automatically started, you can still manually stop
and start the VNC Server, as discussed in recipe 16-3. You may, for
example, want to manually stop the VNC Server because you lack memory
resources on the machine on which it is running.
Note The VNC Viewer for Java is not available when connecting to the VNC server’s Free Edition.
Note To
secure the connection to the server when you use the VNC Server Free
Edition, forward the VNC connection through SSH (refer to recipe 14-7).
Note To display the VNC Server options and parameters, run the OS command vncserver -list.
Optimizing Linux for Oracle Databases
Companies are migrating away from large IBM,
HP, or Sun hardware to commodity hardware running Linux. With the
readily available 18-core Intel chips at affordable prices, companies
can run massive Linux compute nodes at a fraction of the cost of
enterprise UNIX servers on IBM, HP, and Sun. Linux is proven to have
rock-solid OSs that provide extreme reliability similar to its
counterpart UNIX OSs such as IBM AIX, HP/UX, and Sun Solaris. With
proper optimizations, Linux can scale like its counterparts and run
Oracle databases even faster. Think about a single compute node on an
Exadata X5-2 configuration. It comes with 36 CPU cores and up to 768GB
of physical memory. If you run a 2-node RAC for a Quarter Rack, you can
harness 72 cores of processing power and approximately 1.5TB of memory.
Optimizing the Linux OS is an integral part of the
Oracle database server. Having a well-tuned Linux engine is crucial to
database performance. Companies incorporate best practices and
optimizations into a reference architecture for Linux builds. You will
focus on creating a lean and secure Linux infrastructure for Oracle that
will perform consistently with each build.
Laying out a well-designed Linux architecture for an
Oracle database is a critical factor for success. This chapter will lay
out the optimal foundation for Linux reference architecture for an
Oracle database. You will learn how to optimize Linux from a memory
perspective, tweak kernel parameters for additional throughput, choose
the right I/O scheduler, and increase network bandwidth for Oracle.
13-1. Minimalizing the Linux Environment for Performance and Security
Problem
You want to install only the required packages that are needed to install and configure Oracle Database 12c.
Solution
During the installation of Oracle or Red Hat Linux,
you want to choose the minimal installation option. You can select the
Minimal Install option from the top-left corner of the Software
Selection screen (see Figure 13-1).
Figure 13-1. Software selection for Linux installation
With the Minimal Install method, you get only the
basic functionality of the Linux OS. You will follow up after the
minimal Linux installation and leverage the Oracle 12c RDBMS Server
PreInstall RPM to continue to the next level. The Oracle RDBMS
PreInstall RPM installs only the required set of RPMS needed to install
Oracle. A majority of the Linux database servers don’t need much more
RPMS beyond what is installed by the Oracle RDBMS PreInstall RPM.
Note For
information on leveraging the Oracle 12c RDBMS Server PreInstall RPM
for automating Linux server configurations for Oracle databases, please
review Chapter 11.
You can then build additional infrastructure—such as
hugepages, I/O optimizations, network optimizations, and kernel
optimizations—to take the Linux optimizations to another level.
How It Works
You want to install just the minimum packages to
effectively limit the amount of miscellaneous processes running on the
database server and to run only database-related processes on the
database server. Lots of customers make the mistake of installing the
full GUI desktop on the Linux server. Although this method is great for
educational purposes, you should never install the GUI desktop on a
production database server. From a performance perspective, minimal
installation helps by keeping the server “lean and mean.” In addition,
the less you have on the server, the less you have to secure. When it
comes to patching the Linux server, the less you have installed, the
fewer times you have to patch the server with updates.
A leaner server with less software usually runs faster
than a server with all the software installed on it. For example,
X-Server or VNC Server is not installed with the minimal installation,
and you don’t see X-Server processes running on a database server. At
the same time, if you execute the chkconfig --list
command to review all the services with run level settings, a majority
of the non-Oracle related services should be turned off. You should also
disable services such as http on the database server. A good rule to
follow for optimal database performance is to separate out
database-server processes from application-server processes.
On database servers, you should run in run level 3
(Multiuser mode with networking) and never run a database server in run
level 5, which is GUI Desktop mode (the same as run level 3 + display
manager). The default run level is controlled in the /etc/inittab
file. In general, the fewer processes you have running in the
background, the better off you will be. The parameter to control the run
level looks like this:
id:3:initdefault:
13-2. Configuring Hugepages
Problem
You want to configure hugepages to save memory and increase the performance of Oracle running on the Linux server.
Solution
Setting up hugePages requires one kernel parameter change and modifications to two entries to the /etc/securities/limits.conf file. The kernel parameter that has to be modified is vm.nr_hugepages in the /etc/sysctl.conf file.
The /etc/security/limits.conf file has to be adjusted to account for soft and hard limits for Oracle, respectively, to increase the max locked memory limit:
oracle soft memlock 50331648 oracle hard memlock 50331648
After the kernel parameters are set, it is highly recommended that you reboot the server.
How It Works
Leveraging hugepages provides great advantages on
the Linux server. You will recognize performance through increased
Translation Lookaside Buffer (TLB) hits. Hugepages
ensure that System Global Area (SGA) components are locked in memory and
are never swapped out. Hugepages also reduce the overhead associated
with bookkeeping work for the kernel to manage kernel pages.
Suppose that the default kernel page is 4KB. By
increasing the kernel page to 2M, you effectively reduce the number of
kernel pages that you have to manage by a factor of 500x. The kernel
parameters are typically set in granules of 2MB. For example, if you are
allocating 48GB as your hugepage size, you have to set your kernel
parameter to 24576 (48*1024/2) in the /etc/sysctl.conf file.
There is no such thing as a free meal: you can’t use
the automatic memory management (AMM) feature of Oracle when you
implement hugepages. More specifically, the MEMORY_TARGET
initialization parameter of the Oracle database can’t be used. The
Program Global Area (PGA), which is also part of AMM, can’t be
automatically changed, so when hugepages are used, the SGA_TARGET and SGA_MAX_SIZE parameters have to be used. The good news is that the PGA_AGGREGATE_TARGET
is a dynamic parameter and can be adjusted as needed. You can view the
dynamic view associated with the PGA and set this parameter
intelligently, as suggested by Oracle’s advisor view: V$PGA_TARGET_ADVICE.
Settings for hugepages should be set based on the
amount of physical memory and total amount of SGA of each database on
the Linux server. As a standard, you can determine default settings for
hugepages for servers, depending on the amount of physical memory on the
server. The default settings will just be a standard for new server
builds as a starting point. The amount of memory to allocate for
hugepages varies with different databases and applications. Some
applications may need more PGA memory allocation. For example, you can
specify the following set of guidelines for your company:
- =<20GB of physical memory and below; 1/2 of the physical memory will be configured for hugepages
- >20GB of physical memory, 3/4 of the physical memory will be configured for hugepages
Automating Hugepages Server Configuration
Here’s a handy script to add to your arsenal, which
will one day save you tons of valuable time. Whether you are setting
hugepages on a new server or an existing server with multiple databases,
you can set up hugepages for the server with a single shell script.
This script, set_hugepages.ksh, accepts a
single command-line option for the amount of memory in MB that you want
to allocate for hugepages. If you don’t specify the amount of memory to
allocate for hugepages, the script will determine the total physical
memory from the server and take a majority percentage of the memory
specified by the DEFAULT_HP_PERCENTAGE variable. The current script is set to 60% of the physical memory.
The goal of the following script is to determine the values for the vm.nr_hugepages kernel parameter and the soft and hard memlock parameters for the security limits configuration files:
# cat set_hugepages.ksh #!/bin/ksh export HP_SIZE_MB=$1 DEFAULT_HP_PERCENTAGE=60 if [ "$HP_SIZE_MB" = “” ]; then echo "HugePage Value not specified in the command-line options." echo "We will set the HugePages value based on $DEFAULT_HP_PERCENTAGE % of physical memory" SERVER_MEMORY_KB=$(grep ^MemTotal /proc/meminfo |sed -e ’s/[^0-9]*//g’ -e ’s/ //g’) let SERVER_MEMORY_MB=$SERVER_MEMORY_KB/1024 echo "Server Memory: $SERVER_MEMORY_MB" let DEFAULT_HP_SIZE=$SERVER_MEMORY_MB*$DEFAULT_HP_PERCENTAGE/100 echo "Default HugePage size based on $DEFAULT_HP_PERCENTAGE %: $DEFAULT_HP_SIZE" export HP_SIZE_MB=$DEFAULT_HP_SIZE fi LINUX_VER=$(cat /etc/redhat-release |sed -e ’s/[^0-9]*//g’ -e ’s/ //g’) echo "Linux Version is: $LINUX_VER" echo “” echo "Checking to see if HugePages is already set" grep -i vm.nr_hugepages /etc/sysctl.conf RC=$? echo “” function calc_hp { let HP_KB=$HP_SIZE_MB*1024 echo "HugePages KB = $HP_KB" let HP_PRESETTING=$HP_KB/2048 let HP_SETTING=$HP_PRESETTING+6 echo "HP Settings: $HP_PRESETTING $HP_SETTING" echo "New HugePage Setting for /etc/sysctl.conf" echo "vm.nr_hugepages=$HP_SETTING" } calc_hp export TMP_SYSCTL=/tmp/sysctl.conf.tmp if [ "$RC" -eq 1 ]; then echo "Return Code for HugePages: $RC" echo "HugePages is not set!" echo "# -- HugePage Setting for Oracle Databases -- #" >>/etc/sysctl.conf echo "vm.nr_hugepages=$HP_SETTING" >>/etc/sysctl.conf elif [ "$RC" -eq 0 ]; then echo "HugePages is set..." cp /etc/sysctl.conf /tmp/sysctl.conf.$$ cat /etc/sysctl.conf |grep -v "vm.nr_hugepages" >$TMP_SYSCTL echo "vm.nr_hugepages=$HP_SETTING" >>$TMP_SYSCTL cp $TMP_SYSCTL /etc/sysctl.conf fi let MEMLOCK_VALUE=$HP_SETTING*2048 cat /etc/security/limits.conf |grep -v ^# |grep -i memlock |grep -v grep 2>/dev/null export MEMLOCK_RC=$? if [ "$MEMLOCK_RC" -eq 0 ]; then export SECURITY_LIMITS_FILE=/etc/security/limits.conf else export SECURITY_LIMITS_FILE=$(grep -il memlock /etc/security/limits.d/*.conf) fi # -- MEMLOCK has never been set so we need to find the limits.conf file cat /etc/security/limits.conf |egrep -v "^#" |grep nproc export NPROC_RC=$? if [ "$SECURITY_LIMITS_FILE" = “” ]; then if [ "$NPROC_RC" -eq 0 ]; then export SECURITY_LIMITS_FILE=/etc/security/limits.conf else # -- We need to find the limits file for RHEL 6 directory structure export SECURITY_LIMITS_FILE=$(grep -i nproc /etc/security/limits.d/* |awk -F ":" {’print $1’} |tail -1) [ "$SECURITY_LIMITS_FILE" = “” ] && export SECURITY_LIMITS_FILE=/etc/security/limits.d/90-memlock.conf fi fi export TMP_LIMITS_FILE=/tmp/limits.conf.tmp #echo "Security Limits File: $SECURITY_LIMITS_FILE" cp $SECURITY_LIMITS_FILE /tmp/limits.conf.$$ cat $SECURITY_LIMITS_FILE |egrep -v "memlock" >$TMP_LIMITS_FILE echo “” echo "# -- HugePage Setting for Oracle Databases -- #" >>$TMP_LIMITS_FILE echo "# -- Here’s the changes that were made to the $SECURITY_LIMITS_FILE" echo "oracle soft memlock $MEMLOCK_VALUE" >>$TMP_LIMITS_FILE echo "oracle hard memlock $MEMLOCK_VALUE" >>$TMP_LIMITS_FILE cp $TMP_LIMITS_FILE $SECURITY_LIMITS_FILE grep -i memlock $SECURITY_LIMITS_FILE echo “” echo "# ------------------------------------------------------- #" echo "# Your system has been set for hugepages. " echo "# Please reboot your server to see the changes!" echo “”
Before you make changes to the current kernel parameters and configuration file, back up the files by copying them to the /tmp directory. Also create a temporary file in the /tmp directory with the .tmp extension to massage before overlaying the original files. You can download this script from the DBAExpert.com web site. This script is evolving and will be improved upon with each release of Oracle and Red Hat Linux.
Executing the previous set_hugepages.ksh script produces the following output:
# ./set_hugepages.ksh HugePage Value not specified in the command-line options. We will set the HugePages value based on 60 % of physical memory Server Memory: 3587 Default HugePage size based on 60 %: 2152 Linux Version is: 66 Checking to see if HugePages is already set vm.nr_hugepages=15006 HugePages KB = 2203648 HP Settings: 1076 1082 New HugePage Setting for /etc/sysctl.conf vm.nr_hugepages=1082 HugePages is set... # -- Here’s the changes that were made to the /etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf oracle soft memlock 2215936 oracle hard memlock 2215936 # ------------------------------------------------------- # # Your system has been set for hugepages. # Please reboot your server to see the changes!
To specify an exact value for hugepages, pass in a parameter into the script with a value in megabytes:
# ./set_hugepages.ksh 64000
You must reboot the server to recognize hugepage
changes. If you log in as the Oracle Linux account owner, you can
confirm the hugepage settings by typing the ulimit command with the –l option. The –l option reports the maximum size that can be locked into memory:
# su - oracle [oracle@dal66a ~]$ ulimit -l 30732288
Notice that the value of ulimit –l matches the soft and hard memlock values from the security limits configuration files.
Computing the Value of Huge Pages on an Existing Linux Server
Oracle Support provides a nifty shell script that
calculates the total hugepages for a server that has one or more Oracle
databases running. In a nutshell, the script will compute recommended
values for HugePages/HugeTLB configuration for the current database
server by rolling up all the shared memory segments. Please review the
shell script to calculate the recommended for Linux Huge Pages/HugeTLB
Configuration (Doc ID 401749.1).
You can copy and paste the script called hugepages_settings.sh
and execute on a server that has existing databases already running on
it. The script is dependent on the fact that the database is running,
and the database has allocated shared memory that is visible with the ipcs –m command. The script also assumes that the database is not running in AMM mode. Here’s a sample output of the hugepages_settings.sh script:
$ ./hugepages_setting.sh This script is provided by Doc ID 401749.1 from My Oracle Support (http://support.oracle.com) where it is intended to compute values for the recommended HugePages/HugeTLB configuration for the current shared memory segments. Before proceeding with the execution please note following: * For ASM instance, it needs to configure ASMM instead of AMM. * The ’pga_aggregate_target’ is outside the SGA and you should accommodate this while calculating SGA size. * In case you changes the DB SGA size, as the new SGA will not fit in the previous HugePages configuration, it had better disable the whole HugePages, start the DB with new SGA size and run the script again. And make sure that: * Oracle Database instance(s) are up and running * Oracle Database 11g Automatic Memory Management (AMM) is not setup (See Doc ID 749851.1) * The shared memory segments can be listed by command: # ipcs -m Press Enter to proceed... Recommended setting: vm.nr_hugepages = 603
Disabling Transparent Huge Pages
Red Hat and Oracle Linux 6 have a new feature called
Transparent Huge Pages (THP), which is enabled by default. THP was
intended to simplify configuration of hugepages for the SAs because
manual configuration of hugepages can be difficult for SAs new to
Oracle. Hugepages are assigned at boot time and are usually used for
highly static memory allocation of Oracle databases. THP can be
dynamically set at runtime by the khugepaged thread in the kernel.
For Oracle databases, Oracle recommends disabling THP on database servers by executing the following command:
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
Please refer to the Oracle document “ALERT: Disable
Transparent HugePages on SLES11, RHEL6, OL6 and UEK2 Kernels” (Doc ID
1557478.1). To permanently disable transparent huge pages, add transparent_hugepage=never to the kernel boot line in /etc/grub.conf and reboot the server:
# cat /etc/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/vg_rac01-lv_root # initrd /initrd-[generic-]version.img #boot=/dev/sda default=2 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Oracle Linux Server Red Hat Compatible Kernel (2.6.32-358.23.2.el6.x86_64.debug) root (hd0,0) kernel /vmlinuz-2.6.32-358.23.2.el6.x86_64.debug ro root=/dev/mapper/vg_rac01-lv_root rd_NO_LUKS rd_LVM_LV=vg_rac01/lv_root LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 rd_LVM_LV=vg_rac01/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet numa=off transparent_hugepage=never crashkernel=auto initrd /initramfs-2.6.32-358.23.2.el6.x86_64.debug.img title Oracle Linux Server Unbreakable Enterprise Kernel (3.8.13-16.2.1.el6uek.x86_64) root (hd0,0) kernel /vmlinuz-3.8.13-16.2.1.el6uek.x86_64 ro root=/dev/mapper/vg_rac01-lv_root rd_NO_LUKS rd_LVM_LV=vg_rac01/lv_root LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 rd_LVM_LV=vg_rac01/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet numa=off transparent_hugepage=never initrd /initramfs-3.8.13-16.2.1.el6uek.x86_64.img title Oracle Linux Server Red Hat Compatible Kernel (2.6.32-431.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-431.el6.x86_64 ro root=/dev/mapper/vg_rac01-lv_root rd_NO_LUKS rd_LVM_LV=vg_rac01/lv_root LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_rac01/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet numa=off transparent_hugepage=never initrd /initramfs-2.6.32-431.el6.x86_64.img
Optionally, you can add the following lines in the /etc/rc.local file to disable THP at boot time.
[ -f /sys/kernel/mm/transparent_hugepage/enabled ] && echo never > /sys/kernel/mm/transparent_hugepage/enabled [ -f /sys/kernel/mm/transparent_hugepage/defrag ] && echo never > /sys/kernel/mm/transparent_hugepage/defrag
13-3. Enabling Jumbo Frames
Problem
You want to increase the packet size on your private
network transmission unit to increase network performance. You also
want to enable jumbo frames on the dedicated network for NFS or iSCSI
storage performance optimizations.
Solution
To enable jumbo frames on the Linux server, as the root user, execute the ifconfig command to set new MTU to 9000:
# ifconfig eth0 mtu 9000
Modify the network interface configuration file
specific to the network interface to make the changes permanent. The
following example demonstrates that by adding the parameter line MTU=9000 at the end of the network interface file, you are permanently setting jumbo frames:
# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 IPADDR=10.0.0.100 NETMASK=255.255.255.0 ONBOOT=yes BOOTPROTO=none USERCTL=no VLAN=yes MTU=9000
After you make changes to the network interface configuration file, you have to restart the network interface, eth0 in the example, by executing the ifdown and ifup commands:
# ifdown eth0 # ifup eth0
Alternatively, you can restart all the network interfaces with the service network restart
command. Typically, you must coordinate the jumbo frame configuration
with your network engineers. Jumbo switch support must be enabled on the
switches, and all the switches must be enabled to support jumbo frames
if you have multiple switches between the source and target database
servers. The ping command will test end-to-end connectivity between the source and target hostnames or IPs.
Once jumbo frames are enabled for the OS and network switches, perform a simple ping test with the -M, do, and -s options to test jumbo frame connectivity from end to end:
$ ping -M do -s 8972 -c 2 dalrac01a-priv $ ping -M do -s 8972 -c 2 dalrac01b-priv $ ping -M do -s 8972 -c 2 dalrac02a-priv $ ping -M do -s 8972 -c 2 dalrac02b-priv PING dalrac01a (10.17.33.31) 8972(9000) bytes of data. 8980 bytes from dalrac01a-priv (10.17.33.31): icmp_seq=1 ttl=64 time=0.017 ms 8980 bytes from dalrac01a-priv (10.17.33.31): icmp_seq=2 ttl=64 time=0.018 ms
The -s option specifies
the packet size. You can specify a packet size of only 8,972 bytes to
the network. The remaining 28 bytes make up the header information: 20
bytes of IP header information and 8 bytes of ICMP header data. Sending a
packet size larger than 8,972 bytes results in an error for the ping command. If you don’t specify the packet size with the –s option, you will send the default packet size for the ping command, which happens to be 56 bytes without the ICMP header data or the IP header bytes. The example also specified the -c option to send just two iterations of the ping command.
The general recommendation is to enable jumbo frames
for the private network interfaces for RAC configurations. When you are
dealing with NFS or iSCSI disks, setting jumbo frames on the network
associated with the dedicated network for NFS or iSCSI traffic
significantly improves performance.
You can take advantage of the cluvfy command with the healthcheck
option to verify whether jumbo frames are configured on the RAC
database server. As you check for best practices, which includes the
setup of jumbo frames, you can also leverage the healthcheck option with the –bestpractice option.
Here’s a short snippet of the syntax and high-level output to the cluvfy command with the healthcheck and –bestpractice options:
$ cluvfy comp healthcheck -collect cluster -bestpractice -deviations Verifying OS Best Practice Verifying Hardware Clock synchronization at shutdown ...warning Verifying Clusterware Best Practice\ Verifying Ethernet Jumbo Frames ...warning Verifying disk free space for Oracle Clusterware home "/u01/app/12.1.0/grid"passed ... ... ...
How It Works
In a nutshell, jumbo frames are Ethernet frames with
more than 1,500 bytes of payload Maximum Transmission Unit (MTU). With
jumbo frames, you can effectively increase the size of the Ethernet
frame to be larger than the IEEE 802 specification for an MTU of 1,500
bytes to a value of up to 9,000 bytes. When an application such as
Cluster Interconnect or the Parallel Query Engine sends a message
greater than 1,500 bytes, the message is fragmented into 1,500-byte or
smaller frames from one end-point to another. By setting the MTU size to
9,000 bytes, you can improve network throughput performance; because
the packet size is larger, fewer packets are sent across the network for
the application data, resulting in faster transfers and less CPU
overhead on both the transmitting and receiving servers.
Jumbo frames should be enabled as part of your
standard for Oracle RAC Interconnect. As mentioned earlier, the
configuration of jumbo frames has to be enabled from end to end. Not
doing it correctly results in suboptimal performance. Jumbo frames are
not just used for RAC; other use cases include running Oracle Database
file on NFS or even iSCSI protocols. Increasing the jumbo frames for
databases running on NFS or iSCSI significantly improve performance. If
your RMAN backups go to a distributed NFS, you should definitely run
jumbo frames from the database server and the network attached storage
(NAS) server.
Make sure that you are running Oracle’s direct NFS to
maximize all the performance and configuration benefits. For RAC
Interconnect traffic, network interfaces correctly configured with jumbo
frames improves performance by reducing the TCP and UDP overhead that
occurs when large messages have to be broken up into the smaller frames
of standard Ethernet. Properly setting jumbo frames is especially
important if you are working with 10GB (gigE) or higher network
interfaces.
13-4. Determining and Implementing the Right I/O Scheduler
Problem
You want to maximize I/O potential for Oracle databases by choosing the right I/O scheduler.
Solution
Starting from Red Hat/Oracle Linux 5, you can
dynamically modify the I/O scheduler for block devices without a server
reboot. For best performance, Oracle recommends the deadline scheduler
for devices that are used by heavy I/O intensive requests. The deadline
scheduler is highly recommended for Oracle databases to achieve higher
throughput and lower latency. For flash disks or solid-state drives
(SSDs), set the I/O scheduler to noop. You can dynamically set the I/O scheduler to deadline by manipulating the contents of the /sys/block/BLOCKDEVICE_NAME/queue/scheduler directory. As the root or privileged user, execute the following command for each of the disks:
# echo deadline > /sys/block/BLOCKDEVICE1/queue/scheduler # echo deadline > /sys/block/BLOCKDEVICE2/queue/scheduler
Setting the I/O scheduler with the preceding syntax
for block devices will not persist after a server reboot. Changes can be
made permanent by setting the boot parameter elevator=deadline or elevator=noop for flash disks and SSDs to the active kernel in /etc/grub/grub.conf. Here’s a sample grub.conf file that demonstrates how the configuration can be set at server startup:
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.18-238.el5) root (hd0,0) kernel /vmlinuz-2.6.18-238.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet elevator=deadline initrd /initrd-2.6.18-238.el5.img
If you are running the Oracle Unbreakable Enterprise Kernel (UEK), the settings for /etc/grub.conf for the I/O deadline scheduler are automatically set as default settings.
The following one-liner script can be leveraged to
validate that disks are correctly configured with the right I/O
scheduler. Notice from the output that the block devices are set with
the deadline scheduler:
$ find /sys/block/*/queue -name scheduler -exec sh -c ’echo -n "$0 : "; cat $0’ {} \; |tail -10 /sys/block/sda/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdb/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdc/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdd/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sde/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdf/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdg/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdh/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sdi/queue/scheduler : noop anticipatory [deadline] cfq /sys/block/sr0/queue/scheduler : noop anticipatory deadline [cfq]
How It Works
With Red Hat and Oracle Linux, different I/O
schedulers are available with options suited to perform better under
heavy Oracle database workload conditions. The default I/O scheduler
shipped with Red Hat is the completely fair queuing (CFQ) scheduler,
which provides a good compromise between latency and throughput. The
default I/O scheduler that comes with the Oracle UEK is the deadline
scheduler. The noop I/O scheduler is ideal for SSDs or flash-based
systems in which the read/write head has been proven to not affect
application performance. The anticipatory I/O scheduler is similar to
the deadline scheduler. Although it is heuristic and can improve
performance, it can also decrease performance. With the deadline I/O
scheduler, hard limits are put on latency, and it guarantees a start
service time for a request.
For databases running on virtualized environments such
as VMware, the general recommendation is to set the I/O scheduler to
noop. In a virtualized infrastructure, the hypervisor also performs I/O
scheduling and optimizations. You don’t want both the hypervisor and the
guest OS (VM) to perform I/O scheduling; the guest OS should relinquish
I/O scheduling to the hypervisor.
13-5. Setting Pertinent Kernel Parameters for Oracle Databases
Problem
You want to optimize pertinent Linux kernel parameters to effectively run the Oracle database(s).
Solution
This recipe reviews pertinent kernel parameters relevant to Oracle databases in the /etc/sysctl.conf
file. In your environment, if the suggested kernel parameter value is
higher than the value listed below, you should not lower the value.
Range values (such as net.ipv4.ip_local_port_range or /proc/sys/net/ipv4/ip_local_port_range) should match.
The /proc/sys/net/ipv4/ip_local_port_range
value defines the local port range that is used by TCP and UDP traffic.
You have to set this parameter with two numbers: the first number
represents the first local port allowed for TCP and UDP traffic on the
server, and the second represents the last local port number. In
previous releases of Oracle, the recommended values for net.ipv4.ip_local_port_range were 1024 and 65500.
Parameters such as SHMMAX
should be adjusted according to the amount of physical memory on the
database server. For example, you should usually tell customers that a
good number to start is 1/2 or 2/3 or more of physical memory, depending
on how much physical memory they have, how much PGA they have, and the
number of dedicated server processes they expect. SHMALL is also derived based on physical RAM size/page size. The key thing to mention is that the value of SHMMAX is set in bytes, but the value of SHMMALL is set in pages. To determine the page size for a system, execute getconf, as shown here:
# getconf PAGE_SIZE 4096
In the following example, you opt to allocate approximately 66% of the physical memory (approximately 170GB) for SHMALL on a server with 256GB of RAM. You can use the following equation to derive the SHMALL value:
1024 * 1024 * 1024 * 170 /4096 kernel.shmall=44564480
Here’s a comprehensive list of the kernel parameters modified by the Oracle-rdbms-server-12cR1-preinstall RPM:
# Controls the maximum number of shared memory segments, in pages kernel.shmall = 4294967296 # oracle-rdbms-server-12cR1-preinstall setting for fs.file-max is 6815744 fs.file-max = 6815744 # oracle-rdbms-server-12cR1-preinstall setting for kernel.sem is ’250 32000 100 128’ kernel.sem = 250 32000 100 128 # oracle-rdbms-server-12cR1-preinstall setting for kernel.shmmni is 4096 kernel.shmmni = 4096 # oracle-rdbms-server-12cR1-preinstall setting for kernel.shmall is 1073741824 on x86_64 # oracle-rdbms-server-12cR1-preinstall setting for kernel.shmmax is 4398046511104 on x86_64 kernel.shmmax = 4398046511104 # oracle-rdbms-server-12cR1-preinstall setting for net.core.rmem_default is 262144 net.core.rmem_default = 262144 # oracle-rdbms-server-12cR1-preinstall setting for net.core.rmem_max is 4194304 net.core.rmem_max = 4194304 # oracle-rdbms-server-12cR1-preinstall setting for net.core.wmem_default is 262144 net.core.wmem_default = 262144 # oracle-rdbms-server-12cR1-preinstall setting for net.core.wmem_max is 1048576 net.core.wmem_max = 1048576 # oracle-rdbms-server-12cR1-preinstall setting for fs.aio-max-nr is 1048576 fs.aio-max-nr = 1048576 # oracle-rdbms-server-12cR1-preinstall setting for net.ipv4.ip_local_port_range is 9000 65500 net.ipv4.ip_local_port_range = 9000 65500
You have to adjust the settings for SHMALL and SHMMAX
according to SGA requirements. Other kernel settings set by the
Oracle-rdbms-server-12cR1-preinstall RPM should be adequate for a
majority of the database servers. If you have requirements for large
amounts of concurrent dedicated sessions, you may have to adjust the
settings for semmsl and semmns.
How It Works
You will focus on the list of parameters that is mentioned in the solution of this recipe. Table 13-1 provides all the relevant kernel parameters for Oracle databases:
Table 13-1. Pertinent Kernel Parameters for Oracle Databases
Kernel Parameter
|
Description
|
|---|---|
kernel.shmall
|
Represents the maximum total shared memory in 4Kb pages.
|
fs.file-max
|
Represents the maximum number of open files.
|
kernel.sem
|
Has four parameters (in order): SEMMSL, SEMMNS, SEMOPM, and SEMMNI:
• semmsl specifies the maximum number of semaphores per set.
• semmns specifies the maximum number of semaphores.
• semopm specifies the maximum operations per semop call.
• semmni specifies the maximum number of semaphore sets.
|
kernel.shmmni
|
Represents the maximum number of shared memory segments.
|
kernel.shmmax
|
Represents
the maximum size of a single shared memory segment. We recommend a
starting value of 1/2 or 2/3 of the size of physical memory (in bytes)
and to go as high as 90% on some of the larger enterprise servers.
|
net.core.rmem_default
|
Represents the default OS receive buffer size.
|
net.core.rmem_max
|
Represents the maximum OS receive buffer size.
|
net.core.wmem_default
|
Represents the default OS send buffer size.
|
net.core.wmem_max
|
Represents the maximum OS send buffer size.
|
fs.aio-max-nr
|
Represents the total number of concurrent outstanding I/O requests.
|
net.ip_local_port_range
|
Represents the range of ports to be used for client connections.
|
For Oracle databases 11g and above versions, set the following network–related kernel parameters in the /etc/sysctl.conf file:
- net.core.rmem_default to 262144
- net.core.wmem_default to 262144
- net.core.rmem_max to 4194304
- net.core.wmem_max to 1048576
In Linux, the kernel is designed to overcommit memory
beyond its physical memory to make memory usage more efficient. The
overcommit model sometimes becomes problematic when all available
memory, including disk swap space, is consumed. When this state is
reached, the kernel will start killing processes to stay operational. It
is the job of the Linux out-of-memory (OOM) killer to sacrifice one or
more processes to free up memory for the system.
For Red Hat/Oracle Linux 5 customers, it is important to set the vm.min_free_kbytes
kernel parameter to protect from the OOM killer condition. In this
example, you will set this to a value of 51200KB (50 MB), which will
tell the kernel to reserve 50MB of memory at all times. To activate
these new settings into the running kernel space, run the sysctl –p command as root.
For Red Hat/Oracle Linux 6 customers, set the panic_on_oops
kernel parameter. As the kernel panics (or oops) or when a fatal bug is
encountered, you will encounter potential problems with the server. If
this parameter is set to 0, the kernel will attempt to continue to run with consequences. If the parameter is set to 1, the kernel will enter panic state and shut down/reboot. As the root user, execute the following command:
# echo 1 > /proc/sys/kernel/panic_on_oops
To make this kernel parameter change permanent, modify the /etc/sysctl.conf file and add the following entry:
kernel.panic_on_oops = 1
Optimizing virtual memory requires the changes to a
set of kernel parameters, which impacts Oracle database performance by
affecting the rate at which virtual memory is consumed and released with
Oracle databases: vm.swappiness, vm.dirty_background_ratio, vm.dirty_ratio, vm.dirty_expire_centisecs, and vm.dirty_writeback_centisecs.
Some enterprise Linux SAs don’t like the idea of disabling swap. The vm.swappiness
parameter determines how aggressively memory pages are swapped to disk.
The value can range from 0 to 100, and the default value is 60.
The higher the value, the more aggressive is the rate of swapping out
the physical memory when it is not active. We recommend setting the vm.swappiness parameter to 0. The Oracle-recommended value is 0 for Red Hat 6. You can monitor swap usage using native commands such as top, mem, and vmstat.
The vm.dirty_background_ratio parameter dictates the number of pages, specified in percentage, at which the pdflush background write back daemon will start writing out dirty data. The default value is 10; the Oracle recommended the value is 3.
The vm.dirty_ratio
parameter dictates the number of pages, in percentage of total pages, at
which a process that is generating disk writes starts writing out dirty
data. This is the ratio at which dirty pages created by application
disk writes will be flushed out to disk. The default value is 20; the Oracle-recommended value is 80.
The vm.dirty_expire_centisecs
parameter dictates when dirty in-memory data is old enough to be
eligible for writeout by the kernel flusher threads. Dirty in-memory
data older than the value of this parameter will be written out the next
time a flusher thread wakes up. The default value is 3000, expressed in hundredths of a second.
The vm.dirty_writeback_centisecs parameter dictates the interval when writes of dirty in-memory data are written out to disk. The default value is 500, expressed in hundredths of a second. The Oracle recommended value is 100.
In the /etc/sysctl.conf file, the following Linux kernel parameters can be set for database servers:
vm.swappiness = 0 vm.dirty_background_ratio = 3 vm.dirty_ratio = 80 vm.dirty_expire_centisecs = 500 vm.dirty_writeback_centisecs = 100
With different database workloads, you can tweak these kernel parameters as needed.
13-6. Configuring NTP for Oracle
Problem
You want to configure network time protocol (NTP) to keep your server clock in sync with all the servers.
Solution
You should synchronize your system time between your
RAC nodes and even for your primary and standby database server by
enabling the ntp daemon, which should be configured with the –x option to accept gradual time changes, also referred to as slewing. The slewonly option is mandatory for RACs and is also recommended for data guard configurations. To set up ntp with the –x option, modify the /etc/sysconfig/ntpd file, add the desired flag to the OPTIONS variable, and then restart the service with the service ntpd restart command:
# Drop root to id ’ntp:ntp’ by default. #OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g" OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid" # SYNC_HWCLOCK=no
Some SAs choose to update the system clock by executing the nptdate
command via a scheduled job in cron, which does a brute force update of
the system clock. If the system clock is off by 40 minutes, the time is
immediately corrected. For RAC environments, setting the system clock
with ntpdate can cause problems. As time is instantly caught up or sudden variances in time are detected, NTP can cause node evictions.
After you modify the ntpd file with the slewonly option, you have to push the files across all the database servers:
# for i in rac02 rac03 rac04; do scp ntpd ${i}:$PWD; done ntpd 100% 255 0.3KB/s 00:00 ntpd 100% 255 0.3KB/s 00:00 ntpd 100% 255 0.3KB/s 00:00
You can check your current NTP configuration by checking the process status and filtering on the ntp daemon. In the following example, the ntpd service starts and checks to confirm that the settings are correct with the ps command:
[root@rac1 sysconfig]# service ntpd start Starting ntpd: [ OK ] [root@rac1 sysconfig]# ps -ef |grep -i ntp ntp 3496 1 0 10:38 ? 00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid root 3500 2420 0 10:39 pts/1 00:00:00 grep -i ntp
Set up the NTP process for time synchronization on the host to restart after a server reboot. After enabling the ntpd daemon, execute the chkconfig command to validate that it is set up to start at the appropriate run levels:
# chkconfig ntpd on # chkconfig --list|grep ntpd ntpd 0:off 1:off 2:on 3:on 4:on
How It Works
Time consistency across database servers is
essential for every aspect of managing, troubleshooting, running, and
debugging database events because everything is centered on time. You
have to make sure that you have a point of reference when you are
reviewing incidents and logfiles. You have to maintain an accurate
system clock with NTP so that the OS time between the application server
and the database server are the same. If you are also leveraging
database links, you have to make sure that the source server and the
remote server times are in sync.
Starting with Oracle Clusterware 11g Release 2 (11.2),
Oracle provides another option for time synchronization that is
intended for Oracle customers who can’t leverage NTP services: Oracle
Cluster Time Synchronization Service (ctssd). If you leverage NTP, Oracle ctssd starts up only in observer mode. If you don’t leverage NTP, ctssd starts up in active mode and synchronizes time across all the RAC nodes. If you plan to leverage ctssd, deactivate NTP with the following commands:
# service ntpd stop # chkconfig ntpd off
To confirm the mode in which the ctss daemon (ctssd) is working, use the following command:
$ crsctl check ctss
13-7. Bonding Network Interfaces
Problem
You want to pair two network interface cards (NICs) to increase bandwidth and provide high availability.
Solution
This recipe reviews the processes to combine
multiple network interfaces (known as channel bonding or Ethernet
bonding) to provide redundancy for your database server. Bonding a NIC
is synonymous with port trunking and is relatively straightforward.
First, you have to configure the Linux bond drivers. For example, in Red
Hat 5, you must modify the /etc/modprobe.conf file to enable the bonding driver. For Red Hat 6, you must modify the /etc/modprobe.d/bonding.conf file. You must add entries for each of the logical interfaces in the modprobe.conf file that resemble the following:
alias bond0 bonding alias bond1 bonding options bonding miimon=100 mode=1
A mode value of 0 indicates that you want a balanced round robin. A mode value of 1
indicates that you want an active backup for fault protection in which
only one of the slave interfaces is active at a given time. The
different slave interfaces become active only when the active slave
fails. A mode value of 5 specifies that
you want an adaptive transmit load balancing. Outgoing transmission will
be distributed to the load of each slave interface. If one of the
devices fails, the other device will assume responsibility and complete
the network request. This configuration is popular because network
switch support is not required. The miimon value of 100 specifies the amount of time in milliseconds when the link will be checked for failure.
In this particular solution, you are adding two bonded
interfaces: one for the private interconnect and the other for the
public network. You also have four network interfaces: eth0, eth1, eth2, and eth3.
If you have not bonded network interfaces before, most
likely the bonding module is not loaded into the kernel. As root,
execute the insmod bonding.ko command from the /lib/modules/ uname -r/kernel/drivers/net/bonding directory to insert the module into the kernel. To confirm that the bonding module is loaded, you can leverage the lsmod command piped to the grep command, as shown here, to provide the status of the modules in the kernel:
# lsmod |grep -i bonding bonding 65128 0
Once you confirm that the bonding module is loaded
into the kernel, you can proceed by configuring the logical interfaces
by creating or modifying two configuration files in the /etc/sysconfig/network-scripts directory: ifcfg-bond0 and ifcfg-bond1. The entries for ifcfg-bond0 look like this for the private network:
DEVICE=bond0 IPADDR=192.168.1.20 NETWORK=192.168.1.0 NETMASK=255.255.255.0 USERCTL=no BOOTPROTO=none ONBOOT=yes
You must modify the ifcfg-eth0 and ifcfg-eth1 files, which are the NICs for ifcfg-bond0. Start by modifying the ifcfg-eth0 file with these settings:
DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
Similarly, you can modify the ifcfg-eth1 file so it looks like what is shown here:
DEVICE=eth1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
Now you have to repeat the procedures described earlier to configure the ifcfg-bond1 interface for the public network interface. The ifcfg-bond1 interface file has to resemble this:
DEVICE=bond1 IPADDR=72.99.67.100 NETWORK=72.99.67.0 NETMASK=255.255.255.0 USERCTL=no BOOTPROTO=none ONBOOT=yes
The key differences between ifcfg-bond0 and ifcfg-bond1 are the IPADDR, NETWORK, and NETMASK lines. After the ifcfg-bond1 file is created, you can proceed to modify the ifcfg-eth3 and ifcfg-eth4 files. You can create these two files to look like ifcfg-eth0 and ifcfg-eth1 and modify the DEVICE and MASTER names accordingly.
To enable the newly configured bonded network, you
have to bounce the networking services. You can shut down all the
interfaces with the service network stop command. As the final step, you have to start the bonded network interfaces by executing the service network start command.
How It Works
The Linux kernel comes with a bonding module that
provides NIC teaming capabilities. The kernel bonding module teams
multiple physical interfaces to a single logical interface.
Bonding or pairing a network is an important concept
for RAC. Network interfaces that are not bonded are a single point of
failure. Just as every other component of the RAC is built for
redundancy, the network infrastructure must be, too.
In the /etc/modprobe.conf file, you specified options bonding miimon=100 mode=1. The miimon parameter, which stands for Media Independent Interface Monitor, represents the frequency for link monitoring. The value for miimon is specified in milliseconds (ms), is set to 0 by default, and is disabled.
The mode parameter specifies the type of configuration to be deployed. A value of 0,
which is the default, indicates that a round-robin policy will be
implemented, and each of the interfaces will take turns servicing
requests. You can use a round-robin policy for load balancing. A value
of 1 indicates that an active backup
policy will be deployed. In an active backup policy, only one slave in
the bond is active. One and only one device will transmit at any given
moment. A value of 6 indicates adaptive load balancing.
In the ifcfg-eth[x] files, the MASTER parameter indicates the logical interface to which the particular NIC belongs. The SLAVE parameter indicates that the participating NIC is a member of bond interface. A SLAVE can belong to only one master.
13-8. Enabling Network Services Cache Daemon (nscd)
Problem
You want to enable nscd to better tolerate network failures associated with NAS devices or NFS mount points.
Solution
To enable ncsd, start by modifying the /etc/nscd.conf configuration file. You have to disable nscd options for passwd, group, and netgroup by modifying the enable-cache lines to no, as shown here:
# cat /etc/nscd.conf |grep enable-cache |grep -v \^# |sort -k3 enable-cache netgroup no enable-cache group no enable-cache passwd no enable-cache services yes enable-cache hosts yes
As the root or privileged user, start the nscd services with the service start nscd command. You have to enable nscd to start when the system is rebooted by issuing the following chkconfig command:
# chkconfig –level 345 nscd on
To confirm that nscd is enabled, issue the nscd command with the –g parameter, which prints the current configuration statistics. To see all valid options for nscd, pass the -? parameter.
If you performed a minimal OS install, you have to manually install nscd with the following yum command:
# yum –y install nscd
How It Works
The nscd is a small footprint daemon that provides a caching facility for the most common name service requests. The nscd can help when you have network hiccups and minimum changes are needed to enable ncsd.
Oracle database servers can house heavy network-based workloads and
issue lots of name lookups NFS or in a clustered environment. The goal
is to reduce latency of service requests and reduce impact on a shared
infrastructure with nscd. You can also expect performance improvements when using naming services such as DNS, NIS, NIS+, LDAP.
13-9. Aligning Disk Partitions Correctly
Problem
Lots of DBAs are not aware that they have to create a
partition on the database disks. Correctly aligned partitions improve
the performance of database workloads.
Solution
There are several techniques to properly configure partition alignment: parted, fdisk, or sfdisk. In this example, you will focus on the parted partition editor to create a partition on a LUN that will be served to house database files for Oracle.
Note In
Oracle Database 11g, the maximum size of an Oracle ASM disk can’t be
larger than 2TB. Starting with Oracle Database 12c, the maximum size of
an ASM disk can be up to 32 petabytes (PB) for allocation size (AU) of
8MB. For other AU sizes, the maximum ASM disk sizes are: 4PB for 1MB AU
size, 8PB for 2MB AU size, and 16PB for 4MB AU size.
You will see the examples using the parted command because parted can handle disk sizes larger than 2TB. For examples of leveraging the sfdisk command, please visit http://www.dbaexpert.com/blog/partition-alignment-with-sfdisk/. You can add, remove, clone, or modify partitions on the disk with the parted command. This example creates a partition alignment of 1MB with the GNU parted executable:
# /sbin/parted -s /dev/sdb mklabel gpt mkpart /dev/sdb1 asm1 2048s 32.0GB
In the preceding example, quite a number of parameters are passed. You start with the –s
option, which specifies that you want to script out the command-line
options instead of it being an interactive prompt. You also pass the
device name that you are manipulating, followed by the gpt value for the label type, which is the GUID partition table. The mklabel option creates a new disk label for the partition table. The mkpart option tells the parted
command to create a partition on the specified device name with the
file system type, start points, and end points for the partition. The
start and end point can be either in sectors or megabytes. The parameter
2048s represents 2048s sectors, which equates to 1MB because each
sector represents 512 bytes. In the example, you chose to create a
partition of 32GB in size. In your environment, you will probably create
the partitions to the maximum size of the LUN.
After you create partitions for the ASM disks,
double-check the settings to ensure that the partition alignment is set
up correctly. To check for partition alignment on an existing device,
use the following:
# /sbin/parted -s /dev/sdb print Model: VMware, VMware Virtual S (scsi) Disk /dev/sdb: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1049kB 32.0GB 32.0GB /dev/sdb1
How It Works
Misaligned ASM disks can cause suboptimal
performance for Oracle database workloads. By default on Linux, the
first 63 blocks are reserved for the master boot record (MBR). The first
data partition starts with offset at 31.5KB, which is derived from 63
blocks multiplied by 512 bytes. The offset of 31.5KB can cause
misalignment situations on many storage arrays’ memory cache or RAID
configurations, causing suboptimal performance due to overlapping I/Os.
You want the partition offset to be 1MB or 4MB for Oracle databases.
Most importantly, use parted instead of fdisk or even sfdisk because you can create partitions for disks larger than 2TB with parted. Prior to Oracle Database 12c, you had the flexibility to use sfdisk
because an ASM LUN couldn’t be larger than 2TB in size. As of Oracle
Database 12c, the 2TB limitation for LUN size is lifted, and you have to
start migrating to commands such as parted.
CHAPTER 14
Working Securely Across a Network
Secure communication is a concern, particularly
when sharing confidential and vital information between people. For
example, English Prime Minister Winston Churchill and American President
Franklin D. Roosevelt shared critical military information, such as
troop movements, during World War II. To secure their voice
conversations through the telephone, the SIGSALY (aka Green Hornet) was
devised to encrypt and decrypt using cryptographic keys.
Today, we can’t imagine anyone not worrying
about network security. Even people who are not so technically savvy
should be concerned. For instance, what if your bank’s network is not
secured, and a hacker steals your bank account number and PIN? Likewise,
a DBA may want to connect to a Linux/Solaris server situated in a
remote geographical location or another room in the building while
working at the office or at home. What if a coworker is eavesdropping
while that DBA is accessing sensitive data?
To address these network security
concerns, version 1 of SSH was hatched in 1995, but it was replaced a
year later by version 2 for security enhancements. SSH is a network
protocol in which the encrypted data traverses through the network using
a secure channel between computers, as illustrated in Figure 14-1. The ssh protocol replaces the older network protocols (telnet, rlogin, and rsh), and the scp command replaces the rcp
command. The older protocols and commands were replaced because they
lack the security feature; it just was not considered when they were
initially designed.
Figure 14-1. SSH connection
This chapter focuses the discussion on how to log on
securely to a remote Linux/Solaris server through SSH. It also discusses
how to generate the server’s SSH host key, how to use the SSH public
key for authentication in lieu of the username’s password, and how to
securely copy files between Linux/Solaris servers.
14-1. Setting Up SSH
Problem
You want to configure SSH so you can have a secured and encrypted connection to your remote Linux/Solaris server.
Solution
Before you configure SSH, ensure that you have the required packages: openssh, openssh-server, openssh-clients, and openssh-askpass. You can verify the SSH packages installed on your server by running the rpm command as follows:
# rpm -qa | grep -i openssh openssh-5.3p1-94.el6.x86_64 openssh-clients-5.3p1-94.el6.x86_64 openssh-server-5.3p1-94.el6.x86_64 openssh-askpass-5.3p1-94.el6.x86_64
Note Run the ssh -V command to check the type and version of SSH installed on your server.
Before you can connect to your remote Linux/Solaris server, the SSH daemon server (sshd) must be running. You can run sshd as follows:
# service sshd start Starting sshd: [ OK ]
You can also run sshd by calling the following script, which is the same script called by the previous command:
# /etc/rc.d/init.d/sshd start Starting sshd: [ OK ]
However, if sshd is already started, you can restart it as shown here. Another way is to issue the command /etc/rc.d/init.d/sshd restart:
# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]
For Solaris, issue the following command to enable the ssh service, as shown here:
# svcadm enable network/ssh
To disable the ssh service, issue the following command:
# svcadm disable network/ssh
Afterward, run the following command to verify whether the ssh service is online or offline:
# svcs -v ssh
For sshd to start automatically when the Linux server is rebooted, you need to have sshd activated. You can activate sshd by using chkconfig, ntsysv, or system-config-services.
For the chkconfig command, use the --level option and provide the run level in which you want sshd to start. The following command indicates that sshd is configured to start in run levels 2, 3, 4, and 5:
# chkconfig --level 2345 sshd on
For the ntsysv command, also use the --level option and specify the run levels for sshd to start. If no run levels are specified, sshd will be activated only on the current run level. The following command runs ntsysv and affects only run levels 3 and 5:
# ntsysv --level 35
Note You can also launch ntsysv through the text mode setup utility by running the OS setup command and selecting System Services from the menu.
After you launch the ntsysv command, the screen of the text console service configuration tool will appear, as shown in Figure 14-2. Navigate by scrolling down using the arrow keys until the cursor is on sshd. The asterisk (*)
inside the square brackets indicates that the status of the service is
active; empty square brackets show that it is not active. (You can press
the spacebar to toggle the status to become active or not active.) To
save the changes, click the Tab key to highlight the Ok button and then
press Enter.
Figure 14-2. Launching the ntsysv command
Another way to activate sshd is to run the system-config-services command; you can launch this tool as follows:
# /usr/sbin/system-config-services
After you launch system-config-services, the GUI-based service configuration tool will appear, as shown in Figure 14-3. Navigate by scrolling down to the sshd
service and check the adjacent box to activate it. In this dialog box,
you also have the option to start, stop, and restart the sshd service. You can also check the status and PID.
Figure 14-3. Launching system-config-services
How It Works
By default, the required SSH packages are included
in major Linux/Solaris distributions. Otherwise, you can download them
from any Linux/Solaris package download site such as http://www.openssh.com.
Once the SSH packages are installed on your remote Linux/Solaris server, you can activate and run the sshd
daemon, and it should be ready to accept SSH connections. You can,
however, make some changes, such as modifying the default port number on
which sshd should be listening.
Note The
default SSH port number that the Linux/Solaris server will listen on is
22. To change the default SSH port number, modify the value of the
parameter Port in the /etc/ssh/sshd_config file.
The /etc/ssh/sshd_config
file is the SSH systemwide configuration file at the Linux/Solaris
server, which is the computer that you want to connect via SSH. The /etc/ssh/ssh_config
file is the configuration file for the SSH client, which is the
computer from which you are initiating SSH. If you make some changes to
the /etc/ssh/sshd_config file, you have to reload sshd by running service sshd reload as follows:
[root@BLLNX2 stage]# service sshd reload Reloading sshd: [ OK ]
You can also run the service sshd restart command; another method is to stop and start the sshd service, which will give the same results, as follows:
# service sshd stop Stopping sshd: [ OK ] # service sshd start Starting sshd: [ OK ]
For Solaris, run the following:
# svcadm disable network/ssh # svcadm enable network/ssh
To verify the run level that sshd is configured to start, run the chkconfig command with the --list option. As shown here, sshd is set to start on run levels 2, 3, 4, and 5:
# chkconfig --list sshd sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Once sshd is running, issue the following OS command to verify whether the corresponding sshd process is running. If there are no results, it means that sshd is not running yet. So you have to run the service sshd start command to manually start sshd:
# ps -ef | grep -v grep | grep ssh root 4025 1 0 16:32 ? 00:00:00 /usr/sbin/sshd
Note To disallow the root user to log on via SSH, set the parameter PermitRootLogin to no in the /etc/ssh/sshd_config file. Once the non-root users have successfully logged on to the Linux/Solaris server via SSH, they can then run the su - root command or run the sudo command instead.
14-2. Generating Host Keys
Problem
The SSH host key of your remote Linux/Solaris server
is lost, is corrupted, or was not generated when the SSH packages were
installed or during the first run. You want to generate a new SSH host
key.
Solution
To generate a new SSH host key of the Linux/Solaris server, log on as root and run the ssh-keygen command with the -t option, which indicates the type of key to be generated. You must provide the -f option, followed by the file name of the key file. If you omit the -f option, it will create the public key for the OS account root instead of the SSH host key on the Linux/Solaris server.
The following example generates the SSH host key for
the RSA type. If the files of the SSH host keys already exist, you are
asked whether you want to overwrite them.
Next, you are asked to provide the passphrase:
root@BLSOL02:~# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key Generating public/private rsa key pair. /etc/ssh/ssh_host_rsa_key already exists. Overwrite (yes/no)? yes Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: 03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66 root@BLSOL02
To generate the SSH host key for the DSA type, run the following command:
root@BLSOL02:~# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key Generating public/private dsa key pair. /etc/ssh/ssh_host_dsa_key already exists. Overwrite (yes/no)? yes Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: ee:0d:88:61:1a:27:20:2e:69:27:7b:bc:70:de:a2:5c root@BLSOL02
Note For security reasons, we recommend that you supply a passphrase when creating the SSH host key. This prevents non-root users from peeking on the SSH host key by running ssh-keygen with the -y option (discussed in detail in the next section).
How It Works
The SSH host key is like a master key that encrypts
and decrypts the data that traverses between the remote Linux/Solaris
server and the client computer from which you want to initiate the SSH
connection. This secures your connection to the remote Linux/Solaris
server and eliminates vulnerability to man-in-the-middle attacks.
When creating a new SSH host key, you have to provide
the type of key that corresponds to the version of SSH and the kind of
encryption algorithm, which is either RSA or DSA.
Both the RSA and DSA support some security method and different
encryption algorithm. In terms of security, both the DSA and RSA are
similar when comparing them with the same length keys. However, there is
no clear winner for being fastest in encryption and decryption.
The valid values for the SSH host key are rsa1, rsa, and dsa. rsa1 refers to RSA of SSH version 1 (SSHv1); rsa and dsa are for SSH version 2 (SSHv2).
Note If your Linux/Solaris server supports only SSHv2, set the value of the parameter Protocol to 2 in /etc/ssh/sshd_config.
To create the RSA host key, run ssh-keygen with the -t rsa option, which creates two files: /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_rsa_key.pub. For the DSA host key, run -keygen with the -t dsa option, which creates /etc/ssh/ssh_host_dsa_key and /etc/ ssh/ssh_host_dsa_key.pub. Both ssh_host_rsa_key and ssh_host_dsa_key contain the private and public key, whereas ssh_host_rsa_key.pub and ssh_host_dsa_key.pub contain only the public key. The public key is used to encrypt the data; the private key is used to decrypt the data.
The first time you log on to the remote Linux/Solaris
server, which is the computer you are connecting to via SSH, you are
prompted to confirm the server’s SSH host key fingerprint, as shown
here. If you accept it, the file $HOME/.ssh/known_hosts is created on the local Linux/Solaris server, which is the computer from which you initiated the SSH connection. $HOME/.ssh/known_hosts contains the server’s SSH host key.
oracle@BLSOL01:~$ ssh BLSOL02 The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established. RSA key fingerprint is 03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ’blsol02,192.168.2.42’ (RSA) to the list of known hosts. Password: Last login: Thu Aug 20 23:59:50 2015 from ol6-121-rac1 Oracle Corporation SunOS 5.11 11.2 June 2014 oracle@BLSOL02:~$
To determine the SSH key fingerprint on the remote Linux/Solaris server, run the ssh-keygen command with the -l
option, as shown here. It verifies whether you have the correct SSH
host key fingerprint of the remote Linux/Solaris server that you want to
connect via SSH.
root@BLSOL02:~# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub 1024 ee:0d:88:61:1a:27:20:2e:69:27:7b:bc:70:de:a2:5c /etc/ssh/ssh_host_dsa_key.pub root@BLSOL02:~# root@BLSOL02:~# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub 2048 03:bc:53:70:ff:d2:c8:f5:2d:2e:6d:07:3d:3d:1a:66 /etc/ssh/ssh_host_rsa_key.pub
Meanwhile, to determine the SSH host key on the remote Linux/Solaris server, run the ssh-keygen command with the -y
option, as shown here. For security reasons, you can be asked to
provide the passphrase that you supplied when creating the SSH host key.
root@BLSOL02:~# ssh-keygen -y -f /etc/ssh/ssh_host_dsa_key ssh-dss AAAAB3NzaC1kc3MAAACBAJ2G5jV/4MHg9dG4DNb13Wrh94kbN5yUDQeW5SOP0JCzCQVpS2BnsV53L6CUQUPiNilXCqiLVMGaJmm+GSNL4Z82zAvNekTihXa1XabdAN7hBWccaxzH7ppmNbexiZVE/63aKIN+QnsjZ+cFbrqgDN9/10O8DKVM7AJQbyaPDbOrAAAAFQCmFbD9ei01XVMKkOzvqOpp4SwqXQAAAIBNRewVPbCM/p2GZ4PlepXnY2EtbeUZ8WFe15gEfrTwk9lDVh1M2RBs5NRqzHe3JNNddln116fhr++tFK2/xOtG9bNbWfIUEO++gULfYDqn1Ir17L7MZ3gK1KeELyJqtbkZKs2Ne/SA0oaZeJC0CMbi8Vs6ESkdMoSq34xbceDeugAAAIBc4ZWy840UAb7EURncb9KJg9wLFXfYpy7XubGGXhgfsw/z4Uect++kP8QpSYY3QynCzJ4ix3FpOyMKx4VShXKxQcYEMCNx5mnNOiLk/YmEfyeZI/pNR7WIixvQQIj0JObjQRzdz2T+K3Y83S8f522N76dNVBgJmCbW0SalhwqoIw== root@BLSOL02:~# root@BLSOL02:~# ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs/WovKxUpZw8T03HoH4dOlYGLzQ9bbfqayRd8Me33odUzKc8loUhOAdck7ySzaU3fd0Y+OYt1V/CN7wKo2qKowknf2K9JDsPyztSlSZi5FcT2WU6uDlb0FnEg+VAad83ETfDQQ+Ei2s5tV24n+QKAJd7qiAImITTfC55D/ftxpdKZL+m4Meupva6rTiagsLc7fiR4w6FYtuNI3oqaxElDuhJ3675XoTTF3FzhUj0spj4ZLZ6nkN3mYTVyAfrrjzeHDG6N59B6O46C2zW9hCW3e0ZQ3g1sQlDaE/hScErd4JoLR8F2VnWlrj0MQx+4328/p5C668LdPzULEuNEzXNPQ==
On your local client computer, run the tail command, as shown here. Check the SSH host key, which comprises the characters after ssh-rsa or ssh-dsa, and compare them against the results of the ssh-keygen -y option.
oracle@BLSOL01:~$ tail -1 $HOME/.ssh/known_hosts blsol02,192.168.2.42 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs/WovKxUpZw8T03HoH4dOlYGLzQ9bbfqayRd8Me33odUzKc8loUhOAdck7ySzaU3fd0Y+OYt1V/CN7wKo2qKowknf2K9JDsPyztSlSZi5FcT2WU6uDlb0FnEg+VAad83ETfDQQ+Ei2s5tV24n+QKAJd7qiAImITTfC55D/ftxpdKZL+m4Meupva6rTiagsLc7fiR4w6FYtuNI3oqaxElDuhJ3675XoTTF3FzhUj0spj4ZLZ6nkN3mYTVyAfrrjzeHDG6N59B6O46C2zW9hCW3e0ZQ3g1sQlDaE/hScErd4JoLR8F2VnWlrj0MQx+4328/p5C668LdPzULEuNEzXNPQ==
However, when the remote Linux/Solaris server has a
duplicate hostname or IP address, you will see the following error
messages the next time you log on:
[root@ol6-121-rac1 ~]# ssh oracle@BLSOL01 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the DSA host key has just been changed. The fingerprint for the DSA key sent by the remote host is 8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:6 DSA host key for blsol01 has changed and you have requested strict checking. Host key verification failed.
To resolve this problem, you can rename $HOME/.ssh/known_hosts,
but this is not advisable because you will lose the reference of the
SSH host keys of the other servers. Another workaround is to edit $HOME/.ssh/known_hosts
and remove the entry that corresponds to the hostname or IP address and
type of SSH host key of the remote Linux/Solaris server that you want
to connect via SSH. Before you edit $HOME/.ssh/known_hosts, we recommend that you make another copy of the file.
14-3. Logging On Securely
Problem
You want to log on to a remote Linux/Solaris server through a secured and encrypted connection.
Solution
On the local server, run the ssh
command, followed by the hostname or IP address of the remote
Linux/Solaris server that you want to connect. Afterward, supply the
password of the corresponding OS user on the remote Linux/Solaris
server.
In the first line of the following example, the OS prompt oracle@BLSOL01:~$ indicates that the OS username is oracle, which is logged on to the local Linux/Solaris server BLSOL01. The following ssh command connects to the remote Linux/Solaris server BLSOL02 and logs on to the same OS username oracle. You are then prompted to provide the password of the OS user on the remote Linux/Solaris server BLSOL02:
oracle@BLSOL01:~$ ssh BLSOL02 Password: Last login: Wed Aug 19 18:13:50 2015 from blsol01 Oracle Corporation SunOS 5.11 11.2 June 2014 oracle@BLSOL02:~$
Once you have successfully logged on, you can verify
whether you are already in the remote Linux/Solaris server. In the
following example, the OS prompt shows that you are now logged on as oracle on server BLSOL02. However, you can run the OS commands echo $HOSTNAME and echo $USER, as shown here, to display the hostname of the Linux/Solaris server and OS username, respectively:
oracle@BLSOL02:~$ echo $HOSTNAME BLSOL02 oracle@BLSOL02:~$ echo $USER oracle oracle@BLSOL02:~$
How It Works
Before you can run ssh on your local server, ensure that the open-ssh and openssh-clients packages are already installed. Otherwise, you can download them from any Linux/Solaris package download site, such as http://www.openssh.com.
To connect to the remote Linux/Solaris server from another UNIX/Linux computer or Mac OS, run the ssh
command. If you are initiating the SSH connection from Windows, we
recommend that you use the PuTTY software, as illustrated in recipe 1-1.
Another option is to download and install OpenSSH for Windows.
The first time you log on to the remote Linux/Solaris
server via SSH, you will be prompted to confirm the SSH host key
fingerprint of the remote Linux/Solaris server, as shown here. Once you
accept the SSH host key fingerprint, a row will be added in $HOME/.ssh/known_hosts
of the local Linux/Solaris server, which contains the hostname, IP
address, and SSH host key of the remote Linux/Solaris server.
oracle@BLSOL01:~$ ssh BLSOL02 The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established. DSA key fingerprint is 8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ’blsol02,192.168.2.42’ (DSA) to the list of known hosts. Password: Last login: Wed Aug 19 18:18:37 2015 from blsol01 Oracle Corporation SunOS 5.11 11.2 June 2014 oracle@BLSOL02:~$
Note You can run the ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key and ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key commands to verify the SSH host key fingerprint and SSH host key of the server.
To log on to a different OS user when connecting to the remote Linux/Solaris server, you need to add the -l option followed by the username, as shown here. Notice that the prompt is oracle@BLSOL01:~$ in the first line, so the current OS username is oracle and the hostname is BLSOL01. In the last line, the prompt is [bslopuz@BLSOL02 ~]$, which shows that you are now logged in as the username bslopuz of the remote server BLSOL02:
oracle@BLSOL01:~$ ssh -l bslopuz BLSOL02 Password: Last login: Wed Aug 19 15:59:33 2015 from 192.168.2.101 Oracle Corporation SunOS 5.11 11.2 June 2014 bslopuz@BLSOL02:~$
Another way to connect using a different username than the one you are currently logged on with is to run the ssh bslopuz@BLSOL0 command, where the username and hostname are concatenated with the @ character, as follows:
oracle@BLSOL01:~$ ssh bslopuz@BLSOL02 Password: Last login: Wed Aug 19 18:24:15 2015 from blsol01 Oracle Corporation SunOS 5.11 11.2 June 2014 bslopuz@BLSOL02:~$
By default, the SSH daemon server (sshd) is listening on port number 22. If the parameter Port in /etc/ssh/sshd_config on the remote Linux/Solaris server is pointing to a number other than 22, you have to add the -p option when running the ssh command, followed by the correct SSH port number, as shown here:
oracle@BLSOL01:~$ ssh -p 51 ol6-121-rac1 oracle@ol6-121-rac1’s password: Last login: Wed Aug 19 18:30:37 2015 from blsol01 [oracle@ol6-121-rac1 ~]$
Note If you want to run an X Window application on the remote Linux/Solaris server, run the ssh command with the -X option. For additional information about running an X Window application via SSH, refer to recipe 15-5.
If you can’t connect to your remote Linux/Solaris server via SSH, run the ping command, as shown here. It verifies whether you have a direct connection to the Linux/Solaris server. The -c3 option of the ping command means it will send requests to the remote Linux server only three times.
[oracle@ol6-121-rac1 ~]$ ping -c3 BLSOL01 PING BLSOL01 (192.168.2.41) 56(84) bytes of data. 64 bytes from BLSOL01 (192.168.2.41): icmp_seq=1 ttl=255 time=0.452 ms 64 bytes from BLSOL01 (192.168.2.41): icmp_seq=2 ttl=255 time=0.245 ms 64 bytes from BLSOL01 (192.168.2.41): icmp_seq=3 ttl=255 time=0.209 ms --- BLSOL01 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.209/0.302/0.452/0.107 ms
For a Solaris server, we recommend the –s option of the ping command, which will continually send packets to the remote server, as shown here:
oracle@BLSOL01:~$ ping -s BLSOL02 PING BLSOL02: 56 data bytes 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=0. time=0.520 ms 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=1. time=0.379 ms 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=2. time=0.290 ms 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=3. time=0.228 ms 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=4. time=0.251 ms 64 bytes from BLSOL02 (192.168.2.42): icmp_seq=5. time=0.195 ms ^C ----BLSOL02 PING Statistics---- 6 packets transmitted, 6 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.195/0.310/0.520/0.121
However, if you are passing through a proxy server
before you can connect to the remote Linux/Solaris server, we recommend
that you use the PuTTY software because it is easy to configure the
proxy server settings (refer to recipe 1-1). If the remote Linux/Solaris
server is behind a firewall, check with your SA to see whether the
corresponding SSH port number is open.
To monitor the OS users connecting to the remote Linux server via SSH, check the /var/log/secure
file, as shown here. This log file provides important information, such
as the date and time that a particular OS user is logged on, the
hostname or IP address from where the SSH connection is initiated, and
the relevant messages showing why you are perhaps unable to log on.
[root@ol6-121-rac1 ~]# tail -f /var/log/secure Aug 19 19:17:01 ol6-121-rac1 su: pam_unix(su-l:session): session opened for user oracle by (uid=0) Aug 19 19:17:02 ol6-121-rac1 su: pam_unix(su-l:session): session closed for user oracle Aug 19 19:17:04 ol6-121-rac1 sshd[5330]: Accepted password for oracle from 192.168.2.42 port 38569 ssh2 Aug 19 19:17:04 ol6-121-rac1 sshd[5330]: pam_unix(sshd:session): session opened for user oracle by (uid=0) Aug 19 19:17:20 ol6-121-rac1 sshd[5330]: pam_unix(sshd:session): session closed for user oracle
Note To troubleshoot SSH connections, run the ssh command with the -v option to display debugging messages. For more debugging messages, run with the -vvv option instead. We also recommend that you review the /var/log/secure and /var/log/messages files.
14-4. Copying Files Securely
Problem
You want to copy the files between Linux/Solaris servers through a secured and encrypted connection.
Solution
Run the scp command to copy files between Linux/Solaris servers through SSH. To run the scp
command, provide the source files and target files. These files can be
in the local and/or remote Linux/Solaris servers. In the following
example, the /home/oracle/temp/ccf_output01.log file is copied from server BLSOL01 to the same directory on server BLSOL02. You will be prompted for a password of the username on the remote Linux/Solaris server:
oracle@BLSOL01:~$ scp /export/home/oracle/temp/ccf_output01.log BLSOL02:/export/home/oracle/temp Password: ccf_output01.log 100% |*****************************| 14956 00:00
Note The sftp command is another protocol to securely transfer files between Linux/Solaris servers. However, we excluded examples of the sftp command because the sftp protocol is not yet an Internet standard.
How It Works
Similar to using the ssh
command, you will be prompted to confirm the SSH host key fingerprint
of the remote Linux/Solaris server the first time you run the scp
command to securely copy files to the remote Linux/Solaris server via
SSH, as shown here. Once you accept the SSH host key fingerprint, a row
will be added in $HOME/.ssh/known_hosts
of the local Linux/Solaris server, which contains the hostname, IP
address, key type, and SSH host key of the remote Linux/Solaris server.
oracle@BLSOL01:~$ scp /export/home/oracle/temp/ccf_output01.log BLSOL02:/export/home/oracle/temp The authenticity of host ’blsol02 (192.168.2.42)’ can’t be established. DSA key fingerprint is 8d:fa:39:1e:36:a7:6a:b1:87:ea:63:1a:c0:84:4a:3d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ’blsol02,192.168.2.42’ (DSA) to the list of known hosts. Password: ccf_output01.log 100% |*****************************| 14956 00:00
Note The scp command replaces the rcp
command because the latter is not a secure way of copying files between
Linux/Solaris servers, particularly when the data is traversing the
Internet. We recommend that you use the scp command to safeguard your critical data.
The following is the syntax of the scp
command. The hostnames can be different Linux/Solaris servers. If no
hostnames are defined, the files will be copied to the same local
Linux/Solaris server. The usernames may be different between the local
and remote Linux/Solaris servers.
scp [<option>] [source_user@]source_host:]source_file [[target_user@]target_host:]target_file
Table 14-1 shows the common options of the scp command. You can run man scp to determine other options.
Table 14-1. Common Options of scp Command
Option
|
Meaning
|
|---|---|
P
|
Preserves the permission and date timestamp of the source file.
|
P
|
Gets the SSH port number of the remote Linux/Solaris server.
|
Q
|
Hides the progress meter.
|
R
|
Copies recursively all subdirectories and their files.
|
v
|
Displays debugging messages.
|
To copy recursively all the files and directories, use the -r option. The following command will copy all the files and subdirectories of $HOME/temp1 of the local server BLSOL01 to a remote Linux/Solaris server BLSOL02 under the directory $HOME:
oracle@BLSOL01:~$ scp -r $HOME/temp1 BLSOL02:$HOME Password: ol6-121-rac1.localdo 100% |*****************************| 54 00:00 test03.txt 100% |*****************************| 0 00:00 ccf_output01.log 100% |*****************************| 14956 00:00 test02.txt 100% |*****************************| 0 00:00 test01.txt 100% |*****************************| 29 00:00
Similar to using the cp command, you can use a wildcard such as the asterisk (*) to copy selected files. The following command will copy all the files with an extension of txt in the directory $HOME/temp1 on the remote Linux/Solaris server BLSOL02 to the directory $HOME/temp2 on the local Linux/Solaris server BLSOL01:
oracle@BLSOL01:~$ scp BLSOL02:$HOME/temp1/*.txt $HOME/temp2 Password: ol6-121-rac1.localdo 100% |*****************************| 54 00:00 test01.txt 100% |*****************************| 29 00:00 test02.txt 100% |*****************************| 0 00:00 test03.txt 100% |*****************************| 0 00:00
Note PuTTY also provides a pscp.exe client to securely copy files from the Microsoft Windows environment to a UNIX/Linux environment. You can download pscp.exe from PuTTY’s download page.
14-5. Authenticating Through Public Keys
Problem
You want to log on to a remote Linux/Solaris server
when connecting via SSH. You want to authenticate using a public key
instead of typing the OS password.
Solution
In the following example, the OS username oracle is currently logged on to the local Linux/Solaris server BLSOL01 and will log on to the remote Linux/Solaris server BLSOL02. Perform the following steps to use a public key for authentication in lieu of a password prompt:
- On the local Linux/Solaris server BLSOL01, run the ssh-keygen command with the -t rsa option to generate the RSA public key or with -t dsa
for the DSA public key. If the files of the RSA and DSA keys already
exist, you will be asked whether you want to overwrite them. If no, you
can skip this step, but ensure that you remember their passphrases
because you will need them later. If yes, you are prompted to provide
the passphrase, which is used to access the newly created private key.
Afterward, the names of the private and public key files and key
fingerprints are displayed.
oracle@BLSOL01:~$ /usr/bin/ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/export/home/oracle/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /export/home/oracle/.ssh/id_rsa. Your public key has been saved in /export/home/oracle/.ssh/id_rsa.pub. The key fingerprint is: 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 oracle@BLSOL01
- On the local Linux/Solaris server BLSOL01,
provide the read, write, and execute permission only to the owner for
security reasons so the private and public keys are not accessible to
others:
oracle@BLSOL01:~$ chmod 700 $HOME/.ssh oracle@BLSOL01:~$ chmod 600 $HOME/.ssh/*
- Copy the public key from the local Linux/Solaris server BLSOL01 to the remote Linux/Solaris server BLSOL02. You may need to supply the password of the OS user on the remote Linux/Solaris server BLSOL02. This public key must be from the OS username on the local Linux/Solaris server BLSOL01, which is the computer from which you want to initiate the logon to the remote Linux/Solaris server and connect via SSH.
oracle@BLSOL01:~$ scp $HOME/.ssh/id_rsa.pub BLSOL02:$HOME Password: id_rsa.pub 100% |*****************************| 396 00:00
Note We recommend that you make local copies of the key files, such as id_rsa and id_rsa.pub. In case someone mistakenly executes ssh-keygen -t rsa, at least you can always restore the original copies. - Create the directory $HOME/.ssh if not yet available on the remote Linux/Solaris server BLSOL02:
oracle@BLSOL02:~$ mkdir $HOME/.ssh - On the remote Linux/Solaris server BLSOL02, append the public key from the local Linux/Solaris server BLSOL01 to $HOME/.ssh/authorized_keys. Afterward, delete the key file $HOME/id_rsa.pub on the remote Linux/Solaris server BLSOL02, which you copied from the local Linux/Solaris server BLSOL01.
oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys /export/home/oracle/.ssh/authorized_keys: No such file or directory oracle@BLSOL02:~$ cat $HOME/id_rsa.pub >> $HOME/.ssh/authorized_keys oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys -rw-r--r-- 1 oracle staff 396 Aug 19 20:34 /export/home/oracle/.ssh/authorized_keys oracle@BLSOL02:~$ rm $HOME/id_rsa.pub
- On the remote Linux/Solaris server BLSOL02, provide the read, write, and execute permission only to the owner for security reasons. Other users can’t access and modify $HOME/.ssh/authorized_keys.
oracle@BLSOL02:~$ chmod 700 $HOME/.ssh oracle@BLSOL02:~$ chmod 600 $HOME/.ssh/authorized_keys oracle@BLSOL02:~$ ls -l $HOME/.ssh/authorized_keys -rw------- 1 oracle staff 396 Aug 19 20:34 /export/home/oracle/.ssh/authorized_keys
- After the public key is successfully appended to $HOME/.ssh/authorized_keys on the remote Linux/Solaris server BLSOL02, you can now log on without supplying the password of the OS user when connecting via SSH to the remote Linux/Solaris server BLSOL02,
as shown here. Instead, you will be prompted for the passphrase, which
is actually the passphrase you supplied when creating the public key on
the local Linux/Solaris server BLSOL01.
oracle@BLSOL01:~$ ssh BLSOL02 Enter passphrase for key ’/export/home/oracle/.ssh/id_rsa’: Last login: Wed Aug 19 20:31:17 2015 from blsol01 Oracle Corporation SunOS 5.11 11.2 June 2014
Note If
you immediately press Enter or Return when asked to provide the
passphrase, or if you provide the passphrase incorrectly three times,
you will be prompted instead for the actual password of the OS username
that you want to use to log on to the remote Linux/Solaris server.
How It Works
To authenticate using the public key, run the ssh-keygen
command to generate the public key at the local Linux/Solaris server,
which is the computer from which you are going to initiate the SSH
connection. Then copy the newly generated public key and append it to
the $HOME/.ssh/authorized_keys on the remote Linux/Solaris server, which is the computer from which you are going to connect via SSH.
The ssh-keygen will create the RSA and DSA key files, which are used to encrypt and decrypt the data. For RSA, use the -t rsa option command, which will create two files: $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub. For DSA, use the -t dsa option, which will create $HOME/.ssh/id_dsa and $HOME/.ssh/id_dsa.pub.
$HOME/.ssh/id_rsa and $HOME/.ssh/id_dsa contain both the private key and the public key, whereas $HOME/.ssh/id_rsa.pub and $HOME/.ssh/id_dsa.pub
contain just the public key. The public key is used to encrypt the
data; the private key is used to decrypt the data. For security reasons,
ensure that both the private key and the public key files are writable
and readable only by the owner.
When creating the public key, you are prompted to
provide the passphrase, which can be a string of arbitrary length. The
passphrase is your password to decrypt the data. Even if the private and
public keys are stolen, they are useless without the passphrase because
the data can’t be decrypted. So it is important that you keep the
passphrase to yourself; don’t share it with others.
To change the passphrase, run the ssh-keygen command with the -p
option, as shown here. However, you have to supply the old passphrase
before you can change it to prevent unauthorized users from changing
your passphrase:
oracle@BLSOL01:~$ ssh-keygen -p Enter file in which the key is (/export/home/oracle/.ssh/id_rsa): Enter old passphrase: Key has comment ’/export/home/oracle/.ssh/id_rsa’ Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.
Using the public key as a way to authenticate when
connecting to the remote Linux/Solaris server via SSH can be a security
risk. For example, if other OS users can modify your $HOME/.ssh/ authorized_keys,
they can append their own public key to the said file. As a result,
they can log on to your account on the remote Linux/Solaris server
without needing your password.
As a security measure, we recommend that you provide a
passphrase when creating the public key and not share the passphrase
with anyone. Also, run the chmod 700 $HOME command, which ensures that the directories and files underneath the $HOME
directory are writable, readable, and executable only by the owner.
Doing so prevents other OS users to peek at and alter any files starting
from your $HOME directory.
After you have successfully logged in, run the
following OS commands to verify the OS username and hostname of the
remote Linux/Solaris server BLSOL02, as shown here. Even though that information is sometimes obvious in the OS prompt, it’s a good exercise to verify it.
oracle@BLSOL02:~$ echo $HOSTNAME BLSOL02 oracle@BLSOL02:~$ echo $USER oracle
14-6. Configuring a Promptless Logon
Problem
You want to log on without providing the remote OS
user’s password and public key’s passphrase when connecting through SSH
to a remote Linux/Solaris server.
Solution
In the following example, the OS username oracle is currently logged on to the local Linux/Solaris server BLSOL01 and will log on to the remote Linux/Solaris server BLSOL02. Perform the following steps to set up a promptless logon when connecting to the remote Linux/Solaris server via SSH:
- Create the public key on the local Linux/Solaris server BLSOL01 and the OS username where you will initiate the SSH connection. For additional details, refer to recipe 14-5 because you need to perform the same steps as in that recipe.
- Run the SSH agent and capture the output to $HOME/ssh-agent.sh:
oracle@BLSOL01:~$ /usr/bin/ssh-agent > $HOME/ssh-agent.sh - Run $HOME/ssh-agent.sh to set the environment variables SSH_AUTH_SOCK and SSH_AGENT_PID:
oracle@BLSOL01:~$ source $HOME/ssh-agent.sh Agent pid 4566
- Run the ssh-add command and provide the passphrase you supplied when the public key was created on the local Linux/Solaris server:
oracle@BLSOL01:~$ /usr/bin/ssh-add Enter passphrase for /export/home/oracle/.ssh/id_rsa: Identity added: /export/home/oracle/.ssh/id_rsa (/export/home/oracle/.ssh/id_rsa)
- As shown here, the OS username oracle on the local Linux/Solaris server BLSOL01 can now log on to the remote Linux/Solaris server BLSOL02 without providing the OS user password and the public key passphrase:
oracle@BLSOL01:~$ ssh BLSOL02 Last login: Wed Aug 19 20:41:48 2015 from blsol01 Oracle Corporation SunOS 5.11 11.2 June 2014 oracle@BLSOL02:~$
How It Works
In recipe 14-5, you used a public key for
authentication in lieu of the OS username’s password on the remote
Linux/Solaris server. However, you are asked to provide the passphrase,
which is generated when the public key was created on the local
Linux/Solaris server. So you are still prompted to enter something.
For a complete promptless logon to the remote Linux/Solaris server when connecting via SSH, run the ssh-agent and ssh-add commands. The ssh-agent command will create a socket and cache the passphrase of the private key. It will also create a new directory under /tmp, as defined in the environment variable SSH_AUTH_SOCK. The ssh-add
command will add the RSA and DSA identities and present them to the SSH
agent. You can then log on to the remote Linux/Solaris server without
any prompt for a password or passphrase.
To verify the key fingerprints, run the ssh-add command with the -l option to check what’s presented to the SSH agent. Next, run the ssh-keygen command with the -l
option, followed by the path name of the private key file. As shown
here, notice that both outputs have a similar key fingerprint, which is 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60:
oracle@BLSOL01:~$ /usr/bin/ssh-add -l 2048 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 /export/home/oracle/.ssh/id_rsa (RSA) oracle@BLSOL01:~$ /usr/bin/ssh-keygen -l -f $HOME/.ssh/id_rsa 2048 8b:de:0e:b3:22:de:77:3b:fa:37:ff:90:96:22:8a:60 /export/home/oracle/.ssh/id_rsa.pub
To delete the identities presented to the SSH agent, run ssh-add with the -d option. To delete everything, use the -D option instead:
oracle@BLSOL01:~$ /usr/bin/ssh-add -d Identity removed: /export/home/oracle/.ssh/id_rsa (/export/home/oracle/.ssh/id_rsa.pub)
For a promptless logon, the critical key is to ensure that the environment variable SSH_ AUTH_SOCK
is pointing to the correct path name before connecting through SSH.
Otherwise, you will be prompted again for the passphrase once you exit
from your shell or log out of the system.
A workaround is to run the ssh-agent command and capture the output to $HOME/ssh-agent.sh. Before you connect to the remote Linux/Solaris server via SSH, you must run $HOME/ssh-agent.sh to set the same value to the SSH_AUTH_SOCK environment variable. This setting should be the same as when the ssh-agent command was first executed.
To schedule the ssh or scp command in the cron job, ensure that the environment variable SSH_AUTH_SOCK
is set correctly each time you log on to the OS username on the local
Linux/Solaris server. To do this, we recommend that you add the
following lines in $HOME/.bashrc. Notice that you send the output to /dev/null when you run $HOME/ssh-agent.sh to avoid displaying the SSH agent PID every time you log on to that OS username:
if [ -f $HOME/ssh-agent.sh ]; then source $HOME/ssh-agent.sh > /dev/null fi
If you think you have configured everything correctly,
but are still prompted for the passphrase, you have to troubleshoot.
Begin by verifying that the OS process of the SSH agent is still active
and the environment variables are set correctly. Issue the ps -ef | grep ssh-agent command to determine the PID of the SSH agent:
oracle@BLSOL01:~$ ps -ef | grep ssh-agent bslopuz 1639 1601 0 Aug 17 ? 0:01 /usr/bin/ssh-agent -- gnome-session oracle 4566 1 0 20:44:03 ? 0:00 /usr/bin/ssh-agent
Run the env | grep SSH command to display the environment variables, as shown here. The value of the SSH_AGENT_PID and the PID of the SSH agent should be the same. In the example, the PID is 4566:
oracle@BLSOL01:~$ env | grep SSH SSH_AGENT_PID=4566 SSH_AUTH_SOCK=/tmp/ssh-XXXXoGaO6i/agent.4565
Also, the value of the environment variable SSH_AUTH_SOCK should be pointing to an existing path name. To verify, run the ls command as follows:
oracle@BLSOL01:~$ ls -l /tmp/ssh-XXXXoGaO6i/agent.4565 srw------- 1 oracle staff 0 Aug 19 20:44 /tmp/ssh-XXXXoGaO6i/agent.4565
After you have successfully logged on, run the
following OS commands to verify the OS username and hostname of the
remote Linux/Solaris server BLLNX2, as shown here. Even if that information is sometimes obvious in the OS prompt, it is a good exercise to verify them.
oracle@BLSOL02:~$ echo $HOSTNAME BLSOL02 oracle@BLSOL02:~$ echo $USER oracle
CHAPTER 15
Managing X Window
Many DBAs argue that most Linux/Solaris servers
don’t need an X Window System, even when hosting an Oracle database. In
fact, previous chapters of this book show that you can manage your
Oracle database on a Linux/Solaris server using a text console; you
really don’t need a graphical console. In recipes 10-11 and 10-12, you
learned how to install the Oracle RDBMS software and how to create an
Oracle database without running the Oracle Universal Installer (OUI) that requires a graphical display.
However, for DBAs planning to migrate from a Windows
environment and wanting to explore Oracle Database on a Linux/Solaris
environment, typing (and remembering exactly) the OS, SQL, and RMAN
commands via a command line can be intimidating. If you prefer to run
GUI-based programs, such as using the DBCA to create an Oracle database,
this chapter is definitely for you.
To understand the concept of the X Window System in a
Linux/Solaris environment, review the analogy of a client and a server
in a networked environment. An X client and an X server can both be
hosted on a single computer (which is an uncommon feature in a typical
client/server environment) or two disparate computers on a network, as
illustrated in Figure 15-1.
But the terminology is backward from what many expect. An X server, for
example, is what you run on your client PC to interact with your
application. So the application you run on some remote machine is
actually the client. The application you run locally (X Window) is
actually the server.
Figure 15-1. X clients on local or remote Linux/Solaris servers
This chapter shows you how to configure, start, and
stop an X server; and how to redirect and secure an X display to a
remote computer. You also learn how to change the look and feel when
running an X terminal. If you use Windows as your client computer, you
can explore OpenSSH for Windows or perhaps use Virtual Network Computing
(VNC), which is discussed in detail in Chapter 16.
15-1. Configuring an X Server
Problem
You want to configure an X Window server on a
Linux/Solaris server to run GUI-based applications such as the DBCA to
create an Oracle database.
Solution
To set up an X Window server (often called just an X server) on a Linux/Solaris server, you have to edit the xorg.conf X Window configuration file, which is usually found in the /etc/X11 directory. There are two ways to edit the /etc/X11/xorg.conf file:
- Directly modify the /etc/X11/xorg.conf file
- Run the Xorg application
To configure the /etc/X11/xorg.conf file, run Xorg with the configure option, which creates a temporary configuration file called /root/xorg.conf.new. The following is the snippet of the results after running the Xorg -configure command:
# /usr/bin/Xorg -configure X.Org X Server 1.14.5 Release Date: 2013-12-12 X Protocol Version 11, Revision 0 Build Operating System: SunOS 5.11 i86pc Current Operating System: SunOS BLSOL01 5.11 11.2 i86pc Solaris ABI: 64-bit Current version of pixman: 0.29.2 Before reporting problems, check http://support.oracle.com/ to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov 13 00:38:29 2015 List of video drivers: intel openchrome r128 vmware mga vboxvideo radeon cirrus ast mach64 ati vesa (++) Using config file: "/root/xorg.conf.new" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Number of created screens does not match number of detected devices. Configuration failed. (EE) Server terminated with error (2). Closing log file.
Note When running Xorg -configure,
you might see this error message: “Fatal server error: Server is
already active for display 0. If this server is no longer running,
remove /tmp/.X0-lock and start again.” To avoid this error, delete the file described in the error message.
You can then test the /root/xorg.conf.new configuration by executing the command X -config /root/xorg.conf.new. If the X server runs fine using the newly created /root/xorg.conf.new configuration file, copy that file to /etc/X11/xorg.conf.
How It Works
When you start the X server, it reads the xorg.conf file that is located by default in the /etc/X11 directory. The /etc/X11/xorg.conf
file contains configurations of the system resources, video card,
keyboard, mouse, and monitor for a Linux/Solaris server running the X
Window System.
You have to put in the sections that have changed into the xorg.conf
file. Otherwise, the unspecified sections will use the default
settings. Additional contents are also read from the files that are in
the /etc/X11/xorg.conf.d directory.
In the “Solution” section, two methods were described to create and update the /etc/X11/xorg.conf
file. One of the methods is to manually modify the file, which we don’t
recommend except when you are sure of the changes. Regardless of the
method you want to pursue, make sure to back up or create another copy
of the /etc/X11/xorg.conf file before you
attempt to modify it. That way, you can always revert to the original
settings in case the new changes don’t work.
Note When troubleshooting X server, always check the log file /var/log/Xorg.0.log, as well as /var/log/messages for Linux and /var/adm/messages for Solaris.
15-2. Starting an X Server
Problem
You want to start an X server on the Linux/Solaris server to run GUI-based software applications.
Solution
For Solaris server, perform the following steps:
- Run the svcs command to verify the status of the GDM service.
# svcs gdm STATE STIME FMRI disabled 1:25:37 svc:/application/graphical-login/gdm:default
- If the state of GDM service is disabled, run the following command:
# svcadm enable gdm
For Linux server, there are three ways to start the X server:
- Manually run the X command.
- Run init 5 or telinit 5.
- Modify /etc/inittab and reboot the server.
The first method happens to be the most involved and
requires manually starting the X server on the console of your Linux
server. Follow these steps:
- If you are prompted to log on, do so as the OS user from which you want to run the X server.
- Run the X server by typing the X command followed by an ampersand (&), as shown in the following line of code. Make sure you add an &
at the end so the X server will run in the background. That way, you
can still type other OS commands in the same console session.
$ X & - Press Ctrl+Alt+F7 to change to the graphical console. An x will appear in the center of a blank screen, which represents the cursor of your mouse.
- Press Ctrl+Alt+F1 to return to the text console session.
The second method for starting an X server is to run the init 5 or telinit 5 command as root on the OS prompt. A GUI-based logon screen may appear.
The third method is to change the value of the initdefault variable to 5 in the /etc/inittab file, as shown here. But you must reboot the Linux server to effect the changes made in the /etc/inittab file.
id:5:initdefault:
Note To show the details of the X server, run the OS command xdpyinfo.
How It Works
For Solaris server, you can run the command svcadm enable gdm to start the GDM service. If you made changes to the X Window configuration file xorg.conf, you can run the command svcadm restart gdm. To verify the status of the GDM service, issue the command svcs gdm. The following results indicate that the GDM service is online (i.e., enabled):
# svcs gdm STATE STIME FMRI online 11:23:58 svc:/application/graphical-login/gdm:default
For Linux server, if the run level is set to 5, the X server is automatically started when the Linux server is rebooted. However, if the Linux server starts with a run level 3, in which the default screen display is a text console, and you want to run some GUI-based applications such as dbca to create an Oracle Database, you have to manually start the X server on the Linux server.
You can start the X server in three ways. First, you can manually start the X server by running the X command, as demonstrated in the “Solution” section. Another method is to run either the init or telinit command and pass 5 as a parameter, but you must be root or have sudo
access to run those commands. Finally, if you want X server to
automatically run every time a Linux server is rebooted, you have to
change the id directive in /etc/inittab to run level 5.
Because the majority of DBAs don’t work in front of a
server console, starting the X server is not necessary when the Linux
server is booted. But if you have enough physical memory on your Linux
server, we recommend that you use the third method. If the current level
is 3, use either the first or second method to start the X server. We
recommend the second method because it is easier and requires fewer
steps than the X command.
Note Running
an X server on your Linux database server can pose security issues
because another client can access and observe your keystrokes. For
security measures, we recommend that you employ access control using xhost or tunnel X over SSH, as discussed in recipes 15-4 and 15-5.
The X command actually calls Xorg, as shown here:
# which X /usr/bin/X # ls -l /usr/bin/X lrwxrwxrwx. 1 root root 4 Jan 13 2014 /usr/bin/X -> Xorg # which Xorg /usr/bin/Xorg # ls -l /usr/bin/Xorg -rwsr-xr-x. 1 root root 2274240 Nov 21 2013 /usr/bin/Xorg
Note The X command may be in a different directory from other Linux distributions, so run the command which X to determine the exact directory.
Instead of running the X command to start the X server, you can run the startx command, which then invokes the X
command on your behalf and also launches a graphical display manager.
The default display manager of most Linux distributions is GNOME. If you
prefer another graphical display manager, see recipe 15-6 on how to
switch from GNOME to KDE, and vice versa.
Once an X server is already running, you can press
Ctrl+Alt+F1 to change to a text console or press Alt+F7 to change to the
graphical console. You can repeat these steps to go back and forth
between the text and graphical consoles.
15-3. Stopping the X Server
Problem
You want to stop the X server running on your Linux
server. For example, you might want to save on resources such as the
memory consumed by GUI-based software applications.
Solution
For Solaris server, issue the following command:
# svcadm disable gdm
For Linux server, there are three ways to stop an X server:
- Run init 3 or telinit 3.
- Press Ctrl+Alt+Backspace.
- Modify /etc/inittab and reboot the server.
For the first method, perform the following steps to manually stop the X server on your Linux server:
- If the X Window system is already running, press Ctrl+Alt+F1 to change to a text console.
- If you are prompted to log on, do so as root.
- Issue either init 3 or telinit 3 to stop the X server:
# init 3
For the second method, perform the following steps:
- Press Alt+F7 to change to the graphical console. If you are already on the graphical console, you can skip this step.
- Press Ctrl+Alt+Backspace to stop the X server.
For the third method, change the value of the initdefault variable to 3 in the /etc/inittab file, as shown here:
id:3:initdefault:
You must then reboot the Linux server to effect the changes.
How It Works
To stop the X server in Solaris, you can issue the command svcadm disable gdm. Afterward, issue the command svcs gdm. The following results indicate that the GDM service is disabled:
# svcs gdm STATE STIME FMRI disabled 11:18:03 svc:/application/graphical-login/gdm:default
For Linux, you can stop the X server in three ways. You can manually stop the X server by running either init 3 or telinit 3 on the text console to change the current run level to 3. But you must be root or have sudo
access to run these commands. If the current run level is already 3,
you can press Ctrl+Alt+Backspace when you are on the graphical console.
If you don’t want the X server to automatically run every time the Linux
server is rebooted, change the id directive to run level 3 in /etc/inittab.
The first and second methods are dependent on the
current run level. If the current run level is 5 and you perform the
second method, it will always return to the graphical login screen. So
perform the first method if the current level is 5; otherwise, use the
second method.
Issue the runlevel command to display the previous and current run levels. In the following example, the first character is N, which means that the run level is not changed yet; the second character indicates that the current run level is 5:
# runlevel N 5
15-4. Displaying an X Client on a Remote Server
Problem
You want to run an X client or a GUI-based software
application on your local Linux server, but X server is not running.
Instead, you want to redirect the graphical display to a remote
Linux/Solaris server in which an X server is running.
Solution
In the following example, the OS user oracle is currently logged on to the local Linux server RAC1,
where you want to run an X client or a GUI-based software application,
but an X server is not running. Meanwhile, the Solaris server BLSOL01 is a remote Linux server where an X server is running.
Perform the following steps to redirect the graphical display to the Solaris server BLSOL01 when running an X client or a GUI-based software application such as dbca to create an Oracle database on Linux server RAC1:
- On the Linux server RAC1, set the OS environment variable DISPLAY to point to the Solaris server BLSOL01.
[oracle@RAC1 ~]$ export DISPLAY=BLSOL01:0.0 - Run dbca on the Linux server RAC1.
[oracle@RAC1 ~]$ dbca Note If the OS environment variable DISPLAY
is not set, you might see this error message: “DISPLAY not set. Set
DISPLAY environment variable, then re-run.” To resolve this error, make
sure you set the OS environment variable DISPLAY to point to a server in which the X server is running. - Next, the Database Configuration Assistant screen will appear, as shown in Figure 15-2. Behind the screen, notice that the output of the OS command uname -a, executed on the terminal window, confirms that the Solaris server is BLSOL01.
Figure 15-2. Database Configuration Assistant screen
How It Works
You usually run an X client or GUI-based software
application and have the graphical display on the local Linux/Solaris
server in which you are currently logged on. But what if the X server is
not running on the local Linux/Solaris server? Your option is to
redirect the graphical display to another remote Linux server in which
an X server is running.
However, you may experience the following error because the local Linux/Solaris server, which is the Linux server RAC1
in the example illustrated in the “Solution” section, is probably not
granted access control on the remote Solaris server, which is server BLSOL01:
[oracle@RAC1 ~]$ dbca No protocol specified Error: Can’t open display: BLSOL01:0.0
To confirm whether access has been granted, run the OS command xhost without any parameter on the Solaris server BLSOL01. If the message says "access control enabled", only authorized clients can connect. If Linux server RAC1 is not in the list, that explains why you are getting the earlier error message when running the dbca. Here’s an example:
bslopuz@BLSOL01:~$ xhost access control enabled, only authorized clients can connect INET: BLSOL02 INET: RAC1
You can resolve this problem in two ways: run the command xhost +RAC1 from the Solaris server BLSOL01 or run the command xhost + on the Solaris server BLSOL01. Using the first approach allows only clients from the host RAC1 to connect. Here’s an example:
bslopuz@BLSOL01:~$ xhost +RAC1 RAC1 being added to access control list bslopuz@BLSOL01:~$ xhost access control enabled, only authorized clients can connect INET: RAC1
On the other hand, the OS command xhost + will grant access control to all servers that have direct access to BLSOL01.
We don’t recommend that you grant that much access because you are
basically allowing access from any server. Here’s an example:
bslopuz@BLSOL01:~$ xhost + access control disabled, clients can connect from any host
To revoke access control, run the OS command xhost -RAC1 to revoke the privilege from the specific server RAC1, as shown in the following example. Notice that in the results of the first OS command, xhost without any parameters, server RAC1 is on the list. Meanwhile, after you run the OS command xhost -RAC1, server RAC1 is no longer on the list during the second time you run the OS command xhost without any parameters.
bslopuz@BLSOL01:~$ xhost access control enabled, only authorized clients can connect INET:BLSOL02 INET:RAC1 bslopuz@BLSOL01:~$ xhost -RAC1 RAC1 being removed from access control list bslopuz@BLSOL01:~$ xhost access control enabled, only authorized clients can connect INET:BLSOL02
However, if you earlier issued the OS command, and the message says "access control disabled", clients can connect from any host when you issue the OS command xhost without any parameter. Any server, such as the Linux server RAC1, can still access the Solaris server BLSOL01, even though you have already revoked the privilege from the specific Linux server RAC1. To revoke access control from all servers, you can issue xhost -, as shown here:
bslopuz@BLSOL01:~$ xhost - access control enabled, only authorized clients can connect bslopuz@BLSOL01:~$ xhost access control enabled, only authorized clients can connect
15-5. Tunneling X Over SSH
Problem
You want to run an X client or a GUI-based software
application on a remote Linux/Solaris server. However, you want to log
on to that remote Linux server through a secured connection and have the
data encrypted that is traversing between servers.
Solution
In the following example, the OS user oracle is currently logged on to the local Linux server BLSOL01; server BLSOL02 is the remote Solaris server. Perform the following steps to connect to server BLSOL02 from server BLSOL01 through SSH and execute an X software application on server BLLNX2:
- On the local Solaris server BLSOL01, run ssh with the -X (uppercase X) option, as shown here. You may be prompted to provide a password of the OS user on BLSOL02.
bslopuz@BLSOL01:~$ ssh -X BLSOL02 Password: Last login: Mon Nov 16 02:17:46 2015 Oracle Corporation SunOS 5.11 11.2 June 2014
- If X11Forwarding is properly set up, the DISPLAY variable is automatically set up once you are successfully connected to the remote Linux/Solaris server, as shown here:
bslopuz@BLSOL02:~$ echo $DISPLAY localhost:10.0
- Once you are successfully connected to server BLSOL02, you can now run an X client or GUI-based software application on server BLSOL02. To test this, we recommend that you run a simple X client, such as xeyes, as shown in Figure 15-3.
Figure 15-3. xeyes display
Note The default port for X server is 6000. If this port is blocked, a workaround is to run ssh with the -X option to display th.plication, such as xclock or Oracle’s dbca.
How It Works
Recipe 15-4 allows you to redirect a graphical
display to a remote Linux/Solaris server. However, the data traversing
between the servers is not secured because it is not encrypted. For
security reasons, we recommend that you forward or tunnel the graphical
display through SSH, as shown in this recipe.
Note To learn how to configure SSH tunneling using PuTTY, refer to recipe 1-1.
To forward the display of an X client or GUI-based software application on a remote Linux/Solaris server, run ssh with the -X (uppercase X) option. The -x (lowercase X) option disables X forwarding. However, before you can start to connect using ssh, make sure that the Secure Shell daemon, or sshd, is already running on the remote Linux/Solaris server. Otherwise, review Chapter 14, particularly recipe 14-1, which discusses in detail how to set up ssh.
When running an X client or GUI-based software application on a remote Linux/Solaris server, you may receive this message: “Warning: Remote host denied X11 forwarding.” Also, if you run an X client or GUI-based software, you will receive the message “Error: Can’t open display.” To resolve these errors, make sure X11Forwarding is set to yes in the /etc/ssh/sshd_config file on the remote Linux/Solaris server.
Note To troubleshoot your SSH connection, run the ssh command with the -v option to display debugging messages. For more debugging messages, run with the -vvv option instead. We also recommend that you review the /var/log/secure and /var/log/messages files.
15-6. Manipulating the Terminal Emulator for X Windows
Problem
You want to launch the default X terminal and change
the look and feel to support different database environments:
development, quality assurance, and production database environments.
Solution
To launch an X Window terminal, you can execute the xterm command. If your OS environment variable DISPLAY
is set up correctly to a Hummingbird X Server, Reflection X Server, or
Cygwin X Server (or if you are running X server locally), a small white
terminal will appear. This small window will probably not be adequate to
support the day-to-day activities of today’s DBA who supports many
database environments. More than likely, you will have a larger window, a
title to specify the name of the window, different colors to easily
identify the environment, and a larger scroll buffer area. Here are
several xterm examples you can execute in your environment to support multiple database environments:
xterm -sl 32000 -sb -title "Production" -geometry 128x40 -bg red -fg white & xterm -sl 32000 -sb -title "QA" -geometry 128x40 -bg yellow -fg black & xterm -sl 32000 -sb -title "Development" -geometry 128x40 -bg blue -fg white &
Each of the xterm windows is designed with different background colors with the -bg
parameter to differentiate database environments. In our example, the
blue window represents the development environment, the yellow window
represents the QA environment, and, of course, the red window represents
the production environment. DBAs should be aware of the color scheme
and exercise extra caution by remembering that while in the red
background, they are logged on to the production database server.
In addition to the background colors, we defined the
scroll length buffer as 32,000 lines. The default scroll buffer is 64
lines above the top of the window. The scroll buffer of 32,000 lines,
designated by the -sl parameter, will consume more memory on the server, but will prove to be well worth it, especially when diagnosing problems.
The title of the windows can also be defined with the -title parameter, which should be enclosed with double quotes so that you can customize titles to suit your requirements.
The dimensions of the xterm window can be managed with the -geometry
parameter, which defines the window size and position. You can define a
specific font, font size, and other attributes with the -font parameter. The easiest way to designate font and size attributes is to execute the xfontsel command. Executing the xfontsel command will open another X window similar to the one displayed in Figure 15-4.
Figure 15-4. xfontsel window
When you decide on the font type and size attributes, you can click the select button and paste in another terminal with the xterm command, which will look like the following command:
xterm -font -adobe-courier-bold-*-*-*-12-*-*-*-*-*-*-*
Once you are satisfied with the font look and feel, you can go back to the xfontsel window and click the quit button.
Another popular parameter for xterm is the -e parameter. With the -e option, you can specify the program and arguments to run in the xterm window. Here’s an example of how the -e option can be manipulated:
xterm -e "ssh rac3 -l root"
How It Works
xterm is the standard
terminal emulator that runs in X Windows. Other terminal emulators in
Linux include Konsole (the default KDE terminal), GNOME Terminal (the
default GNOME terminal), rxvt (a slimmed-down replacement for xterm), and Eterm. xterm
is the standard de facto for terminals in all UNIX OSs. No matter
whether you are running Linux, Sun Solaris, IBM AIX, or HP/UX, xterm will look and behave the same. One behavior includes the ability to copy and paste. Within an xterm
window, if you highlight a word or a sentence, the highlighted portion
will automatically be copied to the memory buffer. To copy the memory
buffer, you simply press the middle mouse button; for a two-button
mouse, the middle button is most often the trackball. You can press on
the track ball to paste the contents of the memory buffer. If you have
the old traditional two-button mouse, pressing both the left and right
buttons at the same time will paste the memory buffer.
Similarly, if you hold the Ctrl key and simultaneously
press the left, middle, or right button, you will see the following
menu options:
- Press Ctrl and the left mouse button for Main Options.
- Press Ctrl and the right mouse button for VT Fonts.
- Press Ctrl and the middle mouse button for VT Options.
For example, with the VT Fonts menu, you can change
the size of the font to unreadable, tiny, small, medium, large, and
huge. As you change the size of the font, the window diameter will
change accordingly. With the VT Options menu, you can modify simple
things such as enabling or disabling scrollbars or enabling reverse
video.
For assistance with the myriad of xterm arguments, you can execute the xterm -help command.
CHAPTER 16
Managing Remote Servers with VNC
Fewer and fewer DBAs are working in front of
the console of the servers hosting their Oracle databases. It is common
now to see database servers or data centers located in separate
geographical areas from DBAs. For example, a database server might be
hosted somewhere in New York City while the DBA is in Orlando enjoying
the sunny weather.
DBAs can now easily access database servers remotely by using their preferred protocols, such as telnet, rsh, rlogin, and ssh;
and by using the various tools on the market today. Some of those tools
are freely available for download, particularly PuTTY and Virtual
Network Computing (VNC).
Software such as PuTTY, described in Chapter 1, allows you to remotely access a server via telnet or ssh from a Windows client. PuTTY allows you to configure proxy settings and ssh
port tunneling, as well as to save configurations so that you don’t
have to type everything each time you have to connect to the same
database server.
In most cases, accessing a database server in a
command-line mode via PuTTY is all you need. However, you may sometimes
need to access a database server in a way that lets you run GUI-based
software. For example, you may need to run Oracle’s Database
Configuration Assistant (DBCA) to create an Oracle database or run some other X Window System–based software. In this situation, VNC comes in handy.
VNC is a thin-client product of RealVNC,
which is based in Cambridge, United Kingdom. VNC allows you to access
the database server in a graphical way. This feature is useful for DBAs
because Oracle requires an X server to display its Java-based screens
for Oracle database installation, creation, and configuration; and also
for Oracle listener setup. In other words, you can run the same
GUI-based applications on your local VNC-client computer that you can
actually run on the console of the database server.
To run VNC, you need two components: the server and viewer, as shown in Figure 16-1.
The VNC Server component runs on the computer you want to monitor, and
the VNC Viewer component runs on the computer from which you want to
monitor the remote server. Both components have to be installed before
you can initiate a VNC session. VNC runs on most OSs, including UNIX
(such as Solaris), Linux, Windows, and Mac OS.
Figure 16-1. VNC connection
Aside from routing the output to the VNC Server, you
can also route the display to other X servers that are available on the
market today, such as Cygwin/X, Reflections X, and Hummingbird. However,
we recommend VNC because it is freely available and is usually included
by default in most Linux distributions, such as Red Hat Enterprise
Linux, Novell SUSE Linux Enterprise, Oracle Enterprise Linux (OEL),
and Oracle Solaris. VNC also has rich features, such as 2048-bit RSA
server authentication, 128-bit or 256-bit AES session encryption, HTTP
proxy, file transfer, desktop scaling, and screen sharing.
In this chapter, you will learn where to download the
VNC software, how to install and configure the VNC Server on your remote
Linux/Solaris database server and the VNC Viewer on your client
computer, how to share and secure your VNC connection, how to configure
proxy server, and how to troubleshoot VNC issues.
As you put into practice what you have read in this
chapter, such as using the VNC software to access and manage your remote
Linux/Solaris database server from anywhere and at any time, you will
learn to appreciate the benefits provided to you as the DBA:
flexibility, convenience, better collaboration with your team members,
data security, and potential cost savings to your company.
16-1. Downloading the VNC Software
Problem
You want to download the VNC software to allow you
to manage and display the console of your remote Linux/Solaris database
server from your client computer. You want to work in an X Window System
environment instead of a command-line prompt.
Solution
You need two components to run VNC: the VNC Server
running on your remote Linux/Solaris database server and the VNC Viewer
on your client computer. Perform the following steps to download the VNC
software for the two computers:
- Go to https://www.realvnc.com/download/vnc/
and click the Download button that corresponds to the OS and processor
type of your system, as well as the type of compressed file you want to
download.
Note To determine the processor type of your Linux system to see whether you have x86, x64, or ia64, issue the Linux command uname -p or uname -a. For a Solaris system, run the OS command isainfo -vk.
- On the next screen, check the box that says “I have read and accept these terms and conditions” after you review the VNC end user license agreement.
- Click the Download button and save the file to a specific directory.
How It Works
For VNC to work, you have to download and install
the VNC Server on your remote Linux/Solaris database server and the VNC
Viewer on your client computer. You have three different VNC editions to
choose from: the Free Edition, Personal Edition, or Enterprise Edition.
The Free Edition is best for individual private use, the Personal
Edition is ideally suited for small-scale commercial use, and the
Enterprise Edition is recommended for medium or large-scale commercial
use.
By default, the Free Edition is included in most Linux
distributions, such as Red Hat, SUSE, Oracle Enterprise Linux and
Oracle Solaris. However, the Personal Edition and Enterprise Edition
have some advantages over the Free Edition, such as encryption,
authentication, and proxy server features. If you want to take advantage
of these features, download the Enterprise Edition and replace the Free
Edition, which is usually included as a package on your Linux
distribution. Note that the Enterprise Edition and Personal Edition
require a license key before you can start the VNC Server.
16-2. Installing the VNC Software
Problem
You want to install the VNC
Server on your remote Linux/Solaris database server and the VNC Viewer
on your Windows client computer, on which you want to manage and access
your remote Linux/Solaris database server.
Solution
For VNC to work, you have to install the VNC Server
on your remote Linux/Solaris database server and the VNC Viewer on your
client computer. You can choose to install the VNC Server Enterprise
Edition or Free Edition on your server.
First, extract the packages. Here the VNC-Server-5.2.3-Solaris-x64.pkg and VNC-Viewer-5.2.3-Solaris-x64.pkg are being extracted.
root@BLSOL1:~/Downloads# tar -xzvf VNC-5.2.3-Solaris-x64-PKG.tar.gz x VNC-Server-5.2.3-Solaris-x64.pkg, 39088640 bytes, 76345 tape blocks x VNC-Viewer-5.2.3-Solaris-x64.pkg, 8895488 bytes, 17374 tape blocks
To install, you must log on as root and then run the pkgadd command:
root@BLSOL1:~/Downloads# /usr/sbin/pkgadd -d VNC-Server-5.2.3-Solaris-x64.pkg The following packages are available: 1 RVNCsrv VNC Server for Solaris (i386) 5.2.3.8648 Select package(s) you wish to process (or ’all’ to process all packages). (default: all) [?,??,q]: all Processing package instance <RVNCsrv> from </root/Downloads/VNC-Server-5.2.3-Solaris-x64.pkg> VNC Server for Solaris(i386) 5.2.3.8648 Copyright (C) 2002-2015 RealVNC Ltd. All rights reserved. Using </> as the package base directory. ## Processing package information. ## Processing system information. 14 package pathnames are already properly installed. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. The following files are being installed with setuid and/or setgid permissions: /usr/local/bin/Xvnc <setuid root> /usr/local/bin/vncserver-x11 <setuid root> Do you want to install these as setuid/setgid files [y,n,?,q] y This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of <RVNCsrv> [y,n,?] y Installing VNC Server for Solaris as <RVNCsrv> ## Installing part 1 of 1. /usr/lib/cups/backend/vnc /usr/local/bin/Xvnc /usr/local/bin/Xvnc-core /usr/local/bin/vncinitconfig /usr/local/bin/vnclicense /usr/local/bin/vnclicensehelper /usr/local/bin/vnclicensewiz /usr/local/bin/vncpasswd /usr/local/bin/vncpipehelper /usr/local/bin/vncserver-virtual /usr/local/bin/vncserver-virtuald /usr/local/bin/vncserver-x11 /usr/local/bin/vncserver-x11-core /usr/local/bin/vncserver-x11-serviced /usr/local/bin/vncserverui /usr/local/lib/vnc/get_primary_ip4 /usr/local/lib/vnc/vncelevate /usr/local/man/man1/Xvnc.1 /usr/local/man/man1/vncinitconfig.1 /usr/local/man/man1/vnclicense.1 /usr/local/man/man1/vncpasswd.1 /usr/local/man/man1/vncserver-virtual.1 /usr/local/man/man1/vncserver-virtuald.1 /usr/local/man/man1/vncserver-x11-serviced.1 /usr/local/man/man1/vncserver-x11.1 /usr/share/vnc/fonts/6x13-ISO8859-1.pcf.gz /usr/share/vnc/fonts/cursor.pcf.gz /usr/share/vnc/fonts/fonts.alias /usr/share/vnc/fonts/fonts.dir /usr/share/vnc/rgb.txt [ verifying class <server> ] /etc/gconf/schemas/realvnc.schemas /usr/share/applications/realvnc-vnclicensehelper.desktop /usr/share/applications/realvnc-vnclicensewiz.desktop /usr/share/applications/realvnc-vncserver-x11.desktop /usr/share/icons/hicolor/48x48/apps/vnclicensewiz48x48.png /usr/share/icons/hicolor/48x48/apps/vncserver48x48.png /usr/share/icons/hicolor/48x48/mimetypes/application-vnclicense-key.png <symbolic link> /usr/share/mime/packages/realvnc-vnclicensehelper.xml [ verifying class <desktop> ] /usr/local/doc/RVNCsvr/LICENSE_en.txt /usr/local/doc/RVNCsvr/README [ verifying class <doc> ] ## Executing postinstall script. Checking for xauth... /usr/openwin/bin WARNING: /usr/openwin/bin/xauth is not on your path. CUPS installation not found at /opt/sfw/cups/lib/cups. Please install CUPS from the Solaris Companion CD, then run vncinitconfig -enable-print Updating /etc/pam.d/vncserver Updating /etc/pam.conf... done Looking for font path... /usr/X11/lib/X11/fonts/misc/:unscaled,/usr/X11/lib/X11/fonts/100dpi/:unscaled,/usr/X11/lib/X11/fonts/75dpi/:unscaled,/usr/X11/lib/X11/fonts/misc/,/usr/X11/lib/X11/fonts/Type1/,/usr/X11/lib/X11/fonts/100dpi/,/usr/X11/lib/X11/fonts/75dpi/,/usr/X11/lib/X11/fonts/TrueType/,/usr/X11/lib/X11/fonts/Type1/sun/,/usr/X11/lib/X11/fonts/F3bitmaps/ (from /etc/X11/xorg.conf). Generating private key...done Installed SMF manifest for VNC X11 Service-mode daemon Start or stop the service with: svcadm (enable|disable) application/vncserver-x11-serviced Installed SMF manifest for VNC Virtual-mode daemon Start or stop the service with: svcadm (enable|disable) application/vncserver-virtuald Installation of <RVNCsrv> was successful.
To install the VNC Viewer on your Windows client computer, you must log on as the administrator and double-click the file VNC-5.2.3-Windows.exe. Just accept the default installation directory, C:\Program Files\RealVNC\VNC Viewer, and ensure that you select at least the VNC Viewer as one of the components to install.
How It Works
To manage and access your remote Linux/Solaris
database server from your Windows client computer using the VNC
software, you must install the VNC Server on your remote Linux/Solaris
database server and the VNC Viewer on your Windows client computer.
However, you can install the VNC Server and VNC Viewer on both
computers, so you can also manage and access other servers from your
Linux/Solaris database server.
16-3. Manually Starting and Stopping the VNC Server
Problem
You want to manually start and stop the VNC Server on your remote Linux/Solaris database server.
Solution
To manually start the VNC Server on your Linux/Solaris database server, type vncserver and a port number where you want the VNC Server to be listening. The port number is optional, and the default value is 1. The following example shows the VNC Server being started in its default configuration:
# vncserver
This next example shows how to specify a port number. It starts the VNC Server to listen at port number 7:
# vncserver :7
Note To have a similar look and feel of your desktop as when you log on to the console of the Linux server, uncomment or add unset SESSION_MANAGER and /etc/X11/xinit/xinitrc to the $HOME/.vnc/xstartup file.
To manually stop the VNC Server on your Linux/Solaris database server, run the Linux command vncserver -kill and provide the same port number you used when starting the VNC Server. Here’s an example:
# vncserver -kill :7
How It Works
You start the VNC Server on your remote Linux/Solaris database server by running vncserver and a port number. Like the other Linux/Solaris daemons—such as httpd, which usually listens on port number 80, and sshd, which usually listens on 22—the VNC Server listens on port number 5901 by default. If you include a port number when running vncserver, the actual port number is plus 5900. For example, if you run vncserver :7, the VNC Server listens on port number 5907.
The first time you run VNC server Enterprise Edition on your Linux server, you must issue the command vnclicense -add <license key>
to install the license key. However, the license key is not required if
you are using the VNC Free Edition. For example, to add the license
key, use this:
# /usr/bin/vnclicense -add FR464-RHDJ6-6WNF4-A4NB2-HR2YA
Note You can purchase a VNC license at https://www.realvnc.com/purchase/.
For security reasons, you shouldn’t run the VNC Server under a privileged user, such as root or oracle (in other words, the Oracle RDBMS software owner). If you run the VNC Server as root, any remote VNC user will have root
privileges after they are connected to your Linux/Solaris server, and
that is a security risk. Instead, you should create a new Linux/Solaris
user and launch the VNC Server from that account. After remote users are
connected to the server, they can su to root or oracle to perform any necessary administrative tasks.
In the following example, the groupadd command creates a new group called vncuser; the useradd command creates a new user called vncuser, and the -g option associates this user to the group vncuser. The passwd command prompts you to assign a new password for OS user vncuser:
# groupadd vncuser # useradd vncuser -g vncuser # passwd vncuser
Note For additional details about creating OS groups and users, refer to recipes 3-12 and 3-14.
The first time you launch vncserver for a particular OS user, you will be prompted for a password; and the relevant VNC files, such as the security key or the private.key file, will be created in the .vnc directory under the home directory of that OS user. In the example shown here, the su command makes vncuser the current OS user, and the ls -al $HOME/.vnc command displays the files in the .vnc directory under the home directory of OS username vncuser:
# su - vncuser $ ls -al $HOME/.vnc total 28 drwxrwxr-x 2 vncuser vncuser 4096 Apr 27 01:58 . drwx------ 29 vncuser vncuser 4096 Apr 27 02:00 .. -rw-rw-r-- 1 vncuser vncuser 5258 Apr 27 01:59 ol6-121-rac1.localdomain:9.log -rw-rw-r-- 1 vncuser vncuser 6 Apr 27 01:58 ol6-121-rac1.localdomain:9.pid -rw------- 1 vncuser vncuser 8 Apr 27 01:56 passwd -rwxr-xr-x 1 vncuser vncuser 654 Apr 27 01:58 xstartup
Subsequent restarts of the VNC Server won’t ask you to
set the password and won’t regenerate the secure key. However, you can
run the Linux/Solaris command vncpasswd to change the VNC Server password for an OS user, as shown here:
$ /usr/bin/vncpasswd Password: Verify:
In case you forget the port number on which the VNC Server is listening, you can run the Linux command ps -ef. The following example illustrates this. In the results, Xvnc :9 indicates that the VNC Server is listening on port number 5909:
$ ps -ef | grep Xvnc vncuser 10065 1 0 01:58 ? 00:00:01 /usr/bin/Xvnc :9 -desktop ol6-121-rac1.localdomain:9 (vncuser) -auth /home/vncuser/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/vncuser/.vnc/passwd -rfbport 5909 -fp catalogue:/etc/X11/fontpath.d -pn vncuser 11062 10784 0 02:02 pts/0 00:00:00 grep Xvnc
16-4. Automatically Starting the VNC Server on Linux
Problem
You want the VNC Server to automatically start when your Linux database server is rebooted.
Solution
Perform the following steps to ensure that the VNC Server will automatically start when your Linux database server is rebooted:
- Modify the /etc/sysconfig/vncservers file and insert the line VNCSERVERS="<port#>:<OS_user>". In the example, the VNC Server is owned by vncuser to listen on port number 5909:
# cat /etc/sysconfig/vncservers VNCSERVERS="9:vncuser"
- Check the existence of the file /etc/init.d/vncserver. If it is not available, create the file and insert the following lines:
#!/bin/bash # # chkconfig: - 91 35 # description: Starts and stops vncserver. \ # used to provide remote X administration services. # Source function library. . /etc/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 unset VNCSERVERARGS VNCSERVERS=“” [ -f /etc/sysconfig/vncservers ] && . /etc/sysconfig/vncservers prog=$"VNC server" start() { echo -n $"Starting $prog: " ulimit -S -c 0 >/dev/null 2>&1 RETVAL=0 if [ ! -d /tmp/.X11-unix ] then mkdir -m 1777 /tmp/.X11-unix || : restorecon /tmp/.X11-unix 2>/dev/null || : fi NOSERV=1 for display in ${VNCSERVERS} do NOSERV= echo -n "${display} " unset BASH_ENV ENV DISP="${display%%:*}" export USER="${display##*:}" export VNCUSERARGS="${VNCSERVERARGS[${DISP}]}" runuser -l ${USER} -c "cd ~${USER} && [ -f .vnc/passwd ] && " || \ "vncserver :${DISP} ${VNCUSERARGS}" RETVAL=$? [ "$RETVAL" -ne 0 ] && break done if test -n "$NOSERV"; then echo -n "no displays configured "; fi [ "$RETVAL" -eq 0 ] && success $"vncserver startup" || \ failure $"vncserver start" echo [ "$RETVAL" -eq 0 ] && touch /var/lock/subsys/vncserver } stop() { echo -n $"Shutting down $prog: " for display in ${VNCSERVERS} do echo -n "${display} " unset BASH_ENV ENV export USER="${display##*:}" runuser ${USER} -c "vncserver -kill :${display%%:*}" >/dev/null 2>&1 done RETVAL=$? [ "$RETVAL" -eq 0 ] && success $"vncserver shutdown" || \ failure $"vncserver shutdown" echo [ "$RETVAL" -eq 0 ] && rm -f /var/lock/subsys/vncserver } # See how we were called. case "$1" in start) start ;; stop) stop ;; restart|reload) stop sleep 3 start ;; condrestart) if [ -f /var/lock/subsys/vncserver ]; then stop sleep 3 start fi ;; status) status Xvnc ;; *) echo $"Usage: $0 {start|stop|restart|condrestart|status}" exit 1 esac
- Ensure that /etc/init.d/vncserver has an execute permission:
# ls -l /etc/init.d/vncserver -rw-r--r--. 1 root root 3236 Apr 29 2013 /etc/init.d/vncserver # chmod a+x /etc/init.d/vncserver # ls -l /etc/init.d/vncserver -rwxr-xr-x. 1 root root 3236 Apr 29 2013 /etc/init.d/vncserver
- Create a softlink in /etc/rc.d/rc3.d and /etc/rc.d/rc5.d:
# ln -s /etc/init.d/vncserver /etc/rc.d/rc5.d/S91vncserver # ls -l /etc/rc.d/rc5.d/S91vncserver lrwxrwxrwx 1 root root 21 Apr 27 01:46 /etc/rc.d/rc5.d/S91vncserver -> /etc/init.d/vncserver # ln -s /etc/init.d/vncserver /etc/rc.d/rc3.d/S91vncserver # ls -l /etc/rc.d/rc3.d/S91vncserver lrwxrwxrwx 1 root root 21 Apr 27 01:49 /etc/rc.d/rc3.d/S91vncserver -> /etc/init.d/vncserver
- Enable the VNC service using the chkconfig command:
# chkconfig --level 35 vncserver on # chkconfig --list | grep vnc vncserver 0:off 1:off 2:off 3:on 4:off 5:on 6:off
- If possible, log on as root and issue the Linux command reboot to manually restart your Linux database server. Otherwise, you can manually restart the VNC service by executing the Linux command /sbin/service vncserver restart.
- Issue the Linux command ps -ef | grep Xvnc
to verify whether the VNC Server started automatically after the
reboot. The following is an example. In the results, the VNC Server is
listening on port number 9 running under Linux user vncuser:
$ ps -ef | grep Xvnc vncuser 10065 1 0 01:58 ? 00:00:01 /usr/bin/Xvnc :9 -desktop ol6-121-rac1.localdomain:9 (vncuser) -auth /home/vncuser/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/vncuser/.vnc/passwd -rfbport 5909 -fp catalogue:/etc/X11/fontpath.d -pn vncuser 11752 10784 0 02:10 pts/0 00:00:00 grep Xvnc
How It Works
In some environments in which VNC is heavily used,
you may want to automate the restart of the VNC Server. If the VNC
service is enabled at the OS level, one of the files that will be
executed during the system startup is /etc/init.d/vncserver. That script in turn reads the file /etc/ sysconfig/vncservers, which contains the OS user under which the VNC Server will run and the port number on which the VNC Server will listen.
Note After
the VNC Server is automatically started, you can still manually stop
and start the VNC Server, as discussed in recipe 16-3. You may, for
example, want to manually stop the VNC Server because you lack memory
resources on the machine on which it is running.
16-5. Automatically Starting the VNC Server on Solaris
Problem
You want the VNC Server to automatically start when the Solaris database server is rebooted.
Solution
Perform the following steps to ensure that the VNC Server will automatically start when your Solaris database server is rebooted:
- Log on as root user to the Solaris server on which you want the VNC Server to run.
- Make sure to enable the Xvnc inetd services.
# svcadm enable xvnc-inetd - Modify the /etc/services and add the
following line if it is not existing yet, as shown here. In this
example, the VNC Server will listen on port 5901:
vnc-server 5901/tcp - Run the inetadm command, as shown here:
inetadm -m svc:/application/x11/xvnc-inetd:default exec="/usr/bin/Xvnc \\ -geometry 1024x768 -inetd -query localhost -once securitytypes=none" user="vncuser"
- Finally, restart the xvnc-inetd:
svcadm restart xvnc-inetd
How It Works
When a user connects to the Solaris server via the VNC client, the inetadm command allows the inetd to spawn a new VNC instance as the OS user vncuser. The VNC client session should connect to the port defined in the /etc/services as vnc-server. In the previous example, the VNC Server is listening on port 5901.
16-6. Starting the VNC Viewer
Problem
You want to start the VNC Viewer on your client machine, which is either your Windows computer or another Linux server. From that client, you want to manage and access your remote Linux/Solaris database server.
Solution
To start the VNC Viewer on a Windows computer, run the program C:\Program Files\RealVNC\VNC Viewer\vncviewer.exe or navigate to that program by selecting Start 
All Programs RealVNC VNC Viewer Run VNC Viewer. A connection details dialog box will display, as shown in Figure 16-2.
All Programs RealVNC VNC Viewer Run VNC Viewer. A connection details dialog box will display, as shown in Figure 16-2.
Figure 16-2. VNC Viewer connection details
In the connection details dialog box, provide the
hostname or IP address of your remote Linux/Solaris database server, as
well as the port number on which the VNC Server is listening. Click the
OK button to confirm.
To start the VNC Viewer on your Linux/Solaris server, run the OS command /usr/bin/vncviewer as follows (assuming port number 1):
$ /usr/bin/vncviewer BLSOL:1
You will be prompted for a username and password, as shown in Figure 16-3. Depending on the security settings in the VNC Server, you may be prompted only for a password.
Figure 16-3. VNC Viewer password prompt
After your username and password are successfully
verified, the screen of your remote Linux/Solaris database server is
displayed, as shown in Figure 16-4. You can now start to access and manage your remote Linux/Solaris database server as if you were in front of the console.
Figure 16-4. VNC Viewer screen display
If you don’t have the VNC Viewer installed on your
client computer and you have a Java-enabled web browser, you can open
the URL http://<host>:<port>, where <host> is the hostname or IP address of the VNC Server, and <port>
is the port number on which the VNC Server is listening minus 100. For
instance, if the IP address of the VNC Server is 192.168.2.41, and the
Server is listening on port number 5901, the URL will be http://192.168.2.41:5801.
How It Works
Before you can run the VNC Viewer on your client
computer, you have to ensure that the VNC Server is running on your
remote Linux/Solaris database server and listening on a specific port
number. For details on how to install and start the VNC Server, review
the first five recipes in this chapter.
However, if the VNC Viewer is not installed on your
client computer, such as a computer in an Internet café or in an
airport, you can use the VNC Viewer for Java using a Java–enabled web
browser. It provides great flexibility because you are no longer
confined to working in your office to perform DBA tasks. (Work from your
local café instead!) But ensure that your VNC connection is secured,
which you will learn more about in recipe 16-7.
Note The VNC Viewer for Java is not available when connecting to the VNC server’s Free Edition.
If you have the VNC Server Enterprise Edition running
on your remote Linux/Solaris database server, you can’t use the VNC
Viewer Free Edition because of its security limitations. Instead, you
must use the VNC Viewer Personal Edition or Enterprise Edition.
16-7. Securing a VNC Connection
Problem
You want to secure your VNC connection and you want
to have a good authentication method when users access the remote
Linux/Solaris database server from your client computer using the VNC
Viewer.
Solution
To enhance a user’s authentication and the security
of your VNC connection, set the following parameters when launching the
VNC Server:
- SecurityTypes: Sets the security method to employ. Valid values are None, VncAuth, RA2, and RA2ne.
- UserPasswdVerifier: Sets the method to authenticate the users. Valid values are None, VncAuth, and UnixAuth.
You can pass these parameters when manually starting your VNC Server. Here’s an example:
$ /usr/local/bin/vncserver :9 -SecurityTypes=RA2 -UserPasswdVerifier=UnixAuth
You can also configure the parameters to take effect
when the VNC Server is automatically started during the reboot of your
remote Linux database server, as discussed in recipe 16-4. To that end,
add the following lines to your /etc/sysconfig/vncservers file:
VNCSERVERS="9:vncuser" VNCSERVERARGS[9]="-SecurityTypes=RA2 -UserPasswdVerifier=UnixAuth"
The first argument you are passing in VNCSERVERARGS corresponds to the port number on which the VNC Server is listening. In this example, the port number is 9.
How It Works
We recommend that you use the latest version of the
VNC Server Enterprise Edition because it employs 2048–bit RSA server
authentication and 128–bit AES session encryption. If you use the VNC
Server Free Edition, be aware that no security feature is available.
However, you have to purchase a license key for the VNC Server
Enterprise Edition.
Note To
secure the connection to the server when you use the VNC Server Free
Edition, forward the VNC connection through SSH (refer to recipe 14-7).
As a security measure, don’t run the VNC Server as root because you don’t want to allow users to have root
access privilege after they connect to the server. Create another OS
user with minimal privileges and run the VNC Server under that new Linux
user (see recipe 16-3 for details). After remote users are connected to
the server, they can su to oracle to perform any needed DBA tasks.
To encrypt a VNC connection in the VNC Server Enterprise Edition, set the SecurityTypes parameter to RA2 or RA2ne. RA2ne
means that the authentication credentials will be encrypted, but
subsequent connections are not. For the VNC Server Free Edition, set the
SecurityTypes parameter to VncAuth.
For VNC Server Enterprise Edition, set the UserPasswdVerifier to UnixAuth instead of VncAuth.
That way, the OS user’s password is managed at the OS level, which
requires less maintenance because you don’t have to maintain two
passwords: one in the VNC and the other at the OS level.
Don’t set SecurityTypes or UserPasswdVerifier to None
because you are then allowing any users to access the VNC Server
without providing a password. It is like having no locks on your front
door at home.
16-8. Accessing VNC via a Proxy Server
Problem
You want to use VNC to access a remote Linux/Solaris
database server that is outside your company’s network, and all your
Internet connections pass through a proxy server.
Solution
Perform the following steps to configure the proxy settings in your VNC Viewer:
- Start the VNC Viewer (for details on starting the VNC Viewer, see recipe 16-6).
- Provide the appropriate hostname or IP address of the remote
Linux/Solaris database server, as well as the corresponding port number
where the VNC Server is listening, as shown in Figure 16-5.
Figure 16-5. VNC Viewer connection details - Click the Options button and then the Connection tab. The VNC Viewer properties dialog box will appear, as shown in Figure 16-6.
Figure 16-6. VNC proxy server configuration - In the Proxies section, select the Use These Proxy Settings radio button, and provide the appropriate hostname or IP address of the corresponding proxy server, the port number where the proxy server is listening, and the proxy type. If you have already configured a proxy setting in Microsoft Internet Explorer, select Use Microsoft Internet Explorer Proxy Settings instead.
- Click the OK button.
- Click the Connect button.
How It Works
For security and performance reasons,
the Internet connections of most companies that go outside their
network pass through a proxy server. These servers are common for IT
shops in which the DBAs access the servers of their clients or at their
home while working from their office. For details about the hostname or
IP address of your proxy server, its port number, and the proxy type,
contact your company’s system or network administrators.
To configure the proxy server setting using the VNC
Viewer, you must download and use the Personal Edition or Enterprise
Edition because the proxy server feature is not available in the Free
Edition. The proxy server is a new feature included in VNC Viewer
version 4.4, which was released in May 2008. Prior to version 4.4, you
could configure SSH tunneling and the proxy server using PuTTY, as
explained in recipe 1-1.
16-9. Running X Applications with VNC
Problem
You want to run an X application at your remote Linux/Solaris database server, such as the Oracle DBCA, to create the Oracle database from your client computer.
Solution
First, you have to run the VNC Viewer at your client
computer. (For details on how to run the VNC Viewer, review recipe
16-6.) In the VNC Viewer, open a terminal window and log on to the OS
user who will be the owner of the Oracle database:
$ xhost localhost localhost being added to access control list $ su - oracle Password: $ dbca
You will see a screen similar to Figure 16-7.
Figure 16-7. Running DBCA with VNC
How It Works
Once the VNC Viewer display is available on your
client machine, and you have access to the mouse and keyboard, you can
then run any X application, such as Oracle’s DBCA. Any X application
that you run will look and feel just as if you were running it on the
console of your remote Linux/Solaris database server.
16-10. Troubleshooting VNC
Problem
You can’t access the remote Linux/Solaris database server. You are having problems running the VNC Server or the VNC Viewer.
Solution
When troubleshooting VNC, you may have to check the areas described in the following sections to narrow down the cause of the problem.
VNC Server
Check that the VNC Server is running on your remote
Linux/Solaris database server and is listening at the port number on
which you are trying to connect. If the VNC Server does not run at all,
check the parameters you are passing to the server. Check for errors
such as spelling mistakes or invalid parameter values. If possible, try
running the VNC Server without any parameters except for the port number
and then add your parameters one at a time until you determine the
culprit parameter.
Note To display the VNC Server options and parameters, run the OS command vncserver -list.
You can check the log file at $HOME/.vnc/<hostname>:<port#>.log, where $HOME is the home directory of the Linux user under which the VNC Server is running, <hostname> corresponds to the hostname of the VNC Server, and <port#> represents the port on which the VNC Server is listening.
By default, the log parameter of the VNC Server is set to *:stderr:30. To configure the VNC Server log file, specify the VNC parameter -log <logname>:<dest>:<level>, where <logname> is the name of the log writer, <dest> is either stderr or stdout, and <level> ranges from 0 to 100. To gather extra details in the VNC Server log file, set <level>
to 100. For example, the following command starts the VNC Server to
listen on port 9 and logs extra details in the standard error file:
vncserver :9 -log *:stderr:100
You should display the VNC Server log file while you monitor incoming VNC connections. Use the tail command with the -f option for that purpose, as shown in this example:
bslopuz@BLSOL1:~$ tail -f /export/home/bslopuz/.vnc/BLSOL1:9.log <14> 2015-04-27T12:18:44.206Z BLSOL1 Xvnc[22368]: SModulePrint: set printer DELL2155-BAA060-IPv4_via_VNC_from_BLOPUZ-CA as default 1 <15> 2015-04-27T12:18:44.206Z BLSOL1 Xvnc[22368]: SystemPrinterMgr: created socket:/tmp/.vnc-bslopuz/print.0x5760_0x2dcc53fe <15> 2015-04-27T12:18:44.206Z BLSOL1 Xvnc[22368]: PrintDownloader: removeFinishedPrintShare() - removing share 768365566 <15> 2015-04-27T12:18:44.206Z BLSOL1 Xvnc[22368]: FTMsgWriter: Local releasing 768365566 <15> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: PrintDownloader: startDownloading() <15> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: PrintDownloader: startDownloading() - nothing to download <15> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: PrintStream: destroy (1561cd0) <15> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: PrintDownloader: Deleted stream 1561cd0 <14> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: SConnectionST: Encodings TRLE(15) CopyRect(1) Hextile(5) JRLE(22) JPEG(21) ZRLE(16) Zlib(6) RRE(2) Raw(0) CursorWithAlpha(-311) Cursor(-239) DesktopSize(-223) <14> 2015-04-27T12:18:44.207Z BLSOL1 Xvnc[22368]: SConnectionST: Current encoding TRLE
VNC Viewer
To avoid any compatibility issues, ensure that the
version of the VNC Viewer you use on the client computer matches the
version of the VNC Server on the remote Linux/Solaris database server.
For example, if the VNC Server is Enterprise Edition version 5, use VNC
Viewer Enterprise Edition version 5 on the client computer.
If you still have issues with the VNC Viewer on the
client computer, connect to the VNC Server using your Internet browser.
Most of today’s Internet browsers support Java applets, enabling you to
connect. For additional information on how to start the VNC Viewer,
review recipe 16-5.
Connectivity
Verify that you can connect from your client computer to your remote Linux/Solaris database server, and vice versa. Run the ping
command from the OS command prompt of your client computer. In the
following example, the IP address of the remote Linux/Solaris database
server is 192.168.2.41, and the client computer’s IP address is
192.168.2.181:
C:\>ipconfig Windows IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : home IPv4 Address. . . . . . . . . . . : 192.168.2.181 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.2.1 Ethernet adapter VirtualBox Host-Only Network: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 192.168.56.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : C:\>ping BLSOL1 Pinging BLSOL1 [192.168.2.41] with 32 bytes of data: Reply from 192.168.2.41: bytes=32 time<1ms TTL=255 Reply from 192.168.2.41: bytes=32 time<1ms TTL=255 Reply from 192.168.2.41: bytes=32 time<1ms TTL=255 Reply from 192.168.2.41: bytes=32 time<1ms TTL=255 Ping statistics for 192.168.2.41: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Also, perform your tests the other way around. Try to ping the client computer from the remote Linux/Solaris database server. Here’s an example:
root@BLSOL1:~# uname -a SunOS BLSOL1 5.11 11.2 i86pc i386 i86pc root@BLSOL1:~# traceroute 192.168.2.181 traceroute: Warning: Multiple interfaces found; using 192.168.2.41 @ net1 traceroute to 192.168.2.181 (192.168.2.181), 30 hops max, 40 byte packets 1 192.168.2.181 (192.168.2.181) 0.196 ms * 0.224 ms root@BLSOL1:~# ping 192.168.2.181 192.168.2.181 is alive
If you fail to make a connection using the ping
command, verify that you are using the correct hostname or IP address
for the VNC Server and also verify the correct port number on which the
VNC Server is supposed to listen. Check for a firewall that may be
blocking your connections to the remote Linux/Solaris database server
from the client computer, and vice versa. If you have to connect to the
remote Linux/Solaris database server through a proxy server, you have to
set up your proxy server configuration. (Configuring for a proxy server is discussed in recipe 16-8.)
How It Works
For the VNC software to work, you need the three
components to function properly: the VNC Server listening at the remote
Linux/Solaris database server, the VNC Viewer running at the client
computer, and connectivity between the two computers. First, you have to
identify the problematic area and start troubleshooting from there.
For the VNC Server, review the first five recipes in
this chapter to ensure that it is installed correctly and is listening
on the designated port number on your remote Linux/Solaris database
server. You can also monitor the messages generated in the VNC Server
log file while connections are coming to the VNC Server.
On the client computer, you have to check that the VNC
Viewer is running. If the VNC Viewer is not available or not running
correctly, you should connect using your Java–capable Internet browser
to ensure that you are using the same versions between the VNC Server
and the VNC Viewer.
Last but not least, you can use the ping
command to verify connectivity between the remote Linux/Solaris
database server and the client computer. If you still can’t connect,
contact your system or network administrators to help you troubleshoot
the connectivity issue between the remote Linux/Solaris database server
and your client computer.
No comments:
Post a Comment