Archive

Archive for the ‘Linux’ Category

How To remove all messages from a sendmail mail queue

 
Problem description:

Somehow your sendmail outgoing message queue got flooded by e.g. a job and you want to remove all of the messages to be delivered.

 
Problem resolution:

Outgoing messages in the sendmail queue are stored in /var/spool/mqueue. In order to get an overview of the messages you could execute the following sendmail command:

sendmail -bp

 
As your sendmail queue got flooded with a lot of messages, this command might take forever. So instead of querying all of the stored messages you can also check the files directly:

[root@server01 mqueue]# pwd
/var/spool/mqueue
[root@server01 mqueue]# 

[root@server01 mqueue]# ls -al
...
-rw-------  1 root smmsp    1285 18. Mai 10:35 qfr4I8ZSBn009790
-rw-------  1 root smmsp    1242 18. Mai 10:35 qfr4I8ZSu1009786
-rw-------  1 root smmsp    1233 18. Mai 10:35 qfr4I8ZumY009830
-rw-------  1 root smmsp    1253 18. Mai 10:35 qfr4I8ZUOF009794
-rw-------  1 root smmsp    1257 18. Mai 10:35 qfr4I8ZXPu009798
-rw-------  1 root smmsp    1253 18. Mai 10:35 qfr4I8ZZhj009802
...
[root@server01 mqueue]# 

[root@server01 mqueue]# ls -al | wc -l
34439
[root@server01 mqueue]#

 
There is no explicit command for removing all messages. You can directly delete them with “rm”. In order to remove all messages, we just delete the queued files:

[root@server01 mqueue]# pwd
/var/spool/mqueue
[root@server01 mqueue]# 

[root@server01 mqueue]# rm -f *
[root@server01 mqueue]# 

[root@server01 mqueue]# ls -al
insgesamt 1128
drwx------  2 root mail 1138688 20. Mai 11:06 .
drwxr-xr-x 16 root root    4096 11. Mai 2011  ..
[root@server01 mqueue]#

 
“sendmail -bq” should now report an empty mail queue:

[root@server01 mqueue]# sendmail -bp
/var/spool/mqueue is empty
          Total requests: 0
[root@server01 mqueue]#

 

Categories: CentOS, Linux, Oracle Linux, Red Hat Tags:

CentOS: yum operations fail with errors like “HTTP Error 404: Not Found” or “550 os: No such file or directory”

Problem description:

You want to update / upgrade your CentOS / RHEL-based Linux installation, but you are receiving errors like “HTTP Error 404: Not Found” or “550 os: No such file or directory”:

[root@centos01 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.fraunhofer.de
 * extras: mirror.fraunhofer.de
 * updates: centos.bio.lmu.de
ftp://mirror.fraunhofer.de/centos.org/5.7/os/i386/repodata/repomd.xml: [Errno 4] IOError: [Errno ftp error] 550 os: No such file or directory
Trying other mirror.
http://centos.intergenia.de/5.7/os/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://centos.kiewel-online.ch/centos/5.7/os/i386/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (-2, 'Der Name oder der Dienst ist nicht bekannt')>
Trying other mirror.
http://centos.mirroraustria.at/5.7/os/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://centos.psw.net/centos/5.7/os/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://centos.vieth-server.de/5.7/os/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
...
...

 
Problem resolution:
The repomd.xml file listed as missing comes from the Continuous Refresh Repo (CR) for your CentOS version, but your release has been superseded by a new one. In order to get yum to refresh its metadata, just clean up the existing one:

[root@centos01 ~]# yum clean all
Loaded plugins: fastestmirror
Cleaning up Everything
Cleaning up list of fastest mirrors
[root@centos01 ~]#

 
Now yum should determine the new mirror information and allow you to continue your update, upgrade or install operation by using the correct mirror-URLs:

[root@centos01 ~]# yum update
Loaded plugins: fastestmirror
Determining fastest mirrors
 * base: tweedo.com
 * extras: centos.mirroraustria.at
 * updates: centos.mirroraustria.at
base                                                                                                                                                                      | 1.1 kB     00:00     
base/primary                                                                                                                                                              | 967 kB     00:00     
base                                                                                                                                                                                   2725/2725
extras                                                                                                                                                                    | 2.1 kB     00:00     
extras/primary_db                                                                                                                                                         | 171 kB     00:00     
updates                                                                                                                                                                   | 1.9 kB     00:00     
updates/primary_db                                                                                                                                                        | 564 kB     00:00     
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package acl.i386 0:2.2.39-8.el5 set to be updated
---> Package acpid.i386 0:1.0.4-12.el5 set to be updated
...
...

 

Categories: CentOS, Oracle Linux, Red Hat Tags:

pfSense: Why can’t I access the latest information of a log file with tail, grep, cat or vi?

November 24th, 2011 Matthias Pölzinger No comments

Problem description:

You want to debug the logfiles of a pfSense firewall, but tail, grep, cat or vi do not provide the latest information and always ends with a “CLOG@?|?”:

# cd /var/log/
# tail -10l system.log 
Nov 24 15:33:14 pfsense99 sshd[45576]: error: PAM: authentication error for root from 192.168.210.198
Nov 24 15:33:14 pfsense99 last message repeated 2 times
Nov 24 15:33:14 pfsense99 sshd[45576]: Failed keyboard-interactive/pam for root from 192.168.210.198 port 47927 ssh2
Nov 24 15:33:14 pfsense99 sshd[45576]: Failed password for root from 192.168.210.198 port 47927 ssh2
Nov 24 15:33:14 pfsense99 last message repeated 2 times
Nov 24 15:33:14 pfsense99 sshd[45576]: Failed password for root from 192.168.210.198 port 47927 ssh2
Nov 24 15:34:18 pfsense99 sshd[45741]: error: PAM: authentication error for root from 192.168.210.198
Nov 24 15:34:18 pfsense99 sshd[45741]: error: PAM: authentication error for root from 192.168.210.198
Nov 24 15:34:18 pfsense99 last message repeated 2 times
Nov 24 15:34:18 pfsense99 sshd[45741]: Failed keyboard-interactive/pam for root fromCLOG@?|?# 
# 
# date
Thu Nov 24 19:15:38 CET 2011
#

 
Problem resolution:
pfSense writes its log information in a circular log format in order to keep a constant size. This prevents filesystem fillup, but also restricts you from using your standard shell tools to access the data inside these logfiles. Instead of using tail, grep, cat or vi directly, you should first access the log file with a command called “clog”:

# clog system.log 
2
Nov 24 12:59:08 pfsense99 sshd[20315]: error: PAM: authentication error for root from 192.168.210.198
...
...
...
Nov 24 19:15:42 pfsense99 sshd[20501]: Accepted publickey for root from 192.168.210.198 port 38451 ssh2
Nov 24 19:15:42 pfsense99 sshd[20503]: Accepted publickey for root from 192.168.210.198 port 38452 ssh2
#

 
clog also provides a follow option like tail:

# clog -f system.log 
...
...
...
Nov 24 19:15:42 pfsense99 sshd[20501]: Accepted publickey for root from 192.168.210.198 port 38451 ssh2
Nov 24 19:15:42 pfsense99 sshd[20503]: Accepted publickey for root from 192.168.210.198 port 38452 ssh2

 
If you want to grep for specific messages, just add a pipe and a grep:

# clog system.log | grep "keyboard-interactive"
Nov 24 19:15:09 pfsense99 sshd[16616]: Accepted keyboard-interactive/pam for root from 192.168.210.198 port 45104 ssh2
#

 

Categories: Firewall, pfSense, Security Tags:

Red Hat: How to check and repair your root-filesystem in rescue mode

November 24th, 2011 Matthias Pölzinger No comments

Problem description:

Your Linux server had some troubles with it’s underlying storage devices and put all your filesystems into read only mode. You corrected the issue and are booting up your Linux server. The boot process determines some problems with your root filesystems and requires a manual intervention by logging in with the root password. Unfortunately your are unable to login because the root password is not accepted (although you are using the correct one for the 25th time ;-) ).

You are unable to boot because of filesystem issues. At the same time your are unable to fix the filesystem, because your root password is not accepted.

 
Problem resolution:

Take a Linux installation media of your distribution and boot into linux rescue mode by typing the following command when asked for boot options:

linux rescue



 
Select your language and keyboard layout:

 



 
Network configuration is not necessary and can be skipped:

 


 
A very important step is to SKIP the mount of your Linux installation. Do not use MOUNT or READ-ONLY. For a filesystem check it is required that the filesystem is unmounted. Once mounted it is nearly unpossible to unmount your root-filesystem in rescue mode.

 


 
If you are not using a Logical Volume Manager for your filesystems you can directly jump to execute the “fsck” command. Otherwise you will have to first scan for your Physical Volumes and review them:

lvm pvscan
lvm pvdisplay

 


 
If your Physical Volumes were listed correctly continue to review the detected Volume Groups:

lvm vgdisplay

 
Now continue to activate your Volume Groups in order to create your Logical Volume devices in the “/dev” filesystem. In this example a Volume Group with the name “VolGroup00″ has to be activated:

lvm vgchange -a y VolGroup00

 


 
After activating your Volume Group(s), you will be able to perform a filesystem check and correct problems:

fsck /dev/VolGroup00/LogVol00

 


 
Once the filesystem check finishes successfully, you should be able to reboot without any further complication.

 

Categories: CentOS, Linux, Oracle Linux, Red Hat Tags:

AOUG Experts Forum 13.10.2011: Storage Technologies for Oracle Database Systems and Best Practices

October 14th, 2011 Matthias Pölzinger No comments

InITSo was invited to hold a lecture on Oracle ACFS / Oracle Cloud File System at the Austrian Oracle User Group’s Experts Forum on Storage Technologies for Oracle Database Systems – Best Practices (“AOUG Expertentreff: Storage Technologien Oracle Datenbanksystem – Best Practices“).

If you are interested in this topic, you can download an English or German version of the presentation via the following links:

 

Linux: How to query the WWPN of Fibre Channel HBA ports

October 8th, 2011 Matthias Pölzinger No comments

Problem description:

The WWPNs (World Wide Port Numbers) of your HBAs are required e.g. in order to configure Fibre Channel LUN Access. You want to use Linux instruments to access this information in order to avoid rebooting the servers and access the information from BIOS or any other utility.

 
Problem resolution:

Current Linux kernel versions provide relevant information about FC HBAs through the sysfs Filesystem mounted at /sys. The location for detailed information depends on your Linux OS version. For CentOS / Red Hat Enterprise Linux / Oracle Linux 5 the path is /sys/class/scsi_host/host*/device/fc_host*/, but for Version 6 it changed to /sys/class/fc_host/host*/ which makes it easier to separate between SCSI controllers and FC HBAs.

Example for Centos / RHEL / Oracle Linux 5:

[root@initso01 ~]# ls -al /sys/class/scsi_host/host5/device/fc_host:host5/
total 0
drwxr-xr-x 4 root root    0 Oct  5 17:03 .
drwxr-xr-x 6 root root    0 Oct  5 17:03 ..
lrwxrwxrwx 1 root root    0 Oct  5 17:03 device -> ../../../devices/pci0000:00/0000:00:03.0/0000:15:00.0/host5
-r--r--r-- 1 root root 4096 Oct  7 10:07 fabric_name
--w------- 1 root root 4096 Oct  7 10:07 issue_lip
-r--r--r-- 1 root root 4096 Oct  7 10:07 max_npiv_vports
-r--r--r-- 1 root root 4096 Oct  7 10:07 node_name
-r--r--r-- 1 root root 4096 Oct  7 10:07 npiv_vports_inuse
-r--r--r-- 1 root root 4096 Oct  7 10:07 port_id
-r--r--r-- 1 root root 4096 Oct  7 10:07 port_name
-r--r--r-- 1 root root 4096 Oct  7 10:07 port_state
-r--r--r-- 1 root root 4096 Oct  7 10:07 port_type
drwxr-xr-x 2 root root    0 Oct  7 10:07 power
-r--r--r-- 1 root root 4096 Oct  7 10:07 speed
drwxr-xr-x 2 root root    0 Oct  7 10:07 statistics
lrwxrwxrwx 1 root root    0 Oct  5 17:04 subsystem -> ../../fc_host
-r--r--r-- 1 root root 4096 Oct  7 10:07 supported_classes
-r--r--r-- 1 root root 4096 Oct  7 10:07 supported_speeds
-r--r--r-- 1 root root 4096 Oct  7 10:07 symbolic_name
-rw-r--r-- 1 root root 4096 Oct  7 10:07 system_hostname
-rw-r--r-- 1 root root 4096 Oct  7 10:07 tgtid_bind_type
-rw-r--r-- 1 root root 4096 Oct  5 17:03 uevent
--w------- 1 root root 4096 Oct  7 10:07 vport_create
--w------- 1 root root 4096 Oct  7 10:07 vport_delete
[root@initso01 ~]#

 
These fc_host directories can be used to to determine the port speed:

[root@initso01 ~]# for i in `ls /sys/class/scsi_host/host*/device/fc_host*/speed`; do echo $i; echo "==============="; cat $i; done
/sys/class/scsi_host/host5/device/fc_host:host5/speed
===============
unknown
/sys/class/scsi_host/host6/device/fc_host:host6/speed
===============
4 Gbit
/sys/class/scsi_host/host7/device/fc_host:host7/speed
===============
unknown
/sys/class/scsi_host/host8/device/fc_host:host8/speed
===============
4 Gbit
[root@initso01 ~]#

 
or to query the WWPN of each port:

[root@initso01 ~]# for i in `ls /sys/class/scsi_host/host*/device/fc_host*/port_name`; do echo $i; echo "==============="; cat $i; done
/sys/class/scsi_host/host5/device/fc_host:host5/port_name
===============
0x21000024ff2e30ce
/sys/class/scsi_host/host6/device/fc_host:host6/port_name
===============
0x21000024ff2e30cf
/sys/class/scsi_host/host7/device/fc_host:host7/port_name
===============
0x21000024ff2e30cc
/sys/class/scsi_host/host8/device/fc_host:host8/port_name
===============
0x21000024ff2e30cd
[root@initso01 ~]#

 
Just omit the hexidecimal prefix “0x” and you have the WWPN for each Fibre Channel HBA port.

 
Example for Centos / RHEL / Oracle Linux 6:

[root@initso02 ~]# ls -al /sys/class/fc_host/host1/
total 0
drwxr-xr-x. 4 root root    0 Aug 11 07:11 .
drwxr-xr-x. 3 root root    0 Aug 11 07:11 ..
-rw-r--r--. 1 root root 4096 Aug 13 10:29 dev_loss_tmo
lrwxrwxrwx. 1 root root    0 Aug 13 10:29 device -> ../../../host1
-r--r--r--. 1 root root 4096 Aug 13 10:29 fabric_name
--w-------. 1 root root 4096 Aug 13 10:29 issue_lip
-r--r--r--. 1 root root 4096 Aug 13 10:29 max_npiv_vports
-r--r--r--. 1 root root 4096 Aug 13 10:29 node_name
-r--r--r--. 1 root root 4096 Aug 13 10:29 npiv_vports_inuse
-r--r--r--. 1 root root 4096 Aug 13 10:29 port_id
-r--r--r--. 1 root root 4096 Aug 13 10:14 port_name
-r--r--r--. 1 root root 4096 Aug 13 10:29 port_state
-r--r--r--. 1 root root 4096 Aug 13 10:29 port_type
drwxr-xr-x. 2 root root    0 Aug 13 10:29 power
-r--r--r--. 1 root root 4096 Aug 13 10:29 speed
drwxr-xr-x. 2 root root    0 Aug 13 10:29 statistics
lrwxrwxrwx. 1 root root    0 Aug 11 07:11 subsystem -> ../../../../../../../class/fc_host
-r--r--r--. 1 root root 4096 Aug 13 10:29 supported_classes
-r--r--r--. 1 root root 4096 Aug 13 10:29 supported_speeds
-r--r--r--. 1 root root 4096 Aug 13 10:29 symbolic_name
-rw-r--r--. 1 root root 4096 Aug 13 10:29 system_hostname
-rw-r--r--. 1 root root 4096 Aug 13 10:29 tgtid_bind_type
-rw-r--r--. 1 root root 4096 Aug 11 07:11 uevent
--w-------. 1 root root 4096 Aug 13 10:29 vport_create
--w-------. 1 root root 4096 Aug 13 10:29 vport_delete
[root@initso02 ~]#

 
As with Version 5 these fc_host directories can be used to to determine the port speed:

[root@initso02 ~]# for i in `ls /sys/class/fc_host/host*/speed`; do echo $i; echo "==============="; cat $i; done
/sys/class/fc_host/host1/speed
===============
4 Gbit
/sys/class/fc_host/host2/speed
===============
4 Gbit
[root@initso02 ~]#

 
or to query the WWPN of each port:

[root@initso02 ~]# for i in `ls /sys/class/fc_host/host*/port_name`; do echo $i; echo "==============="; cat $i; done
/sys/class/fc_host/host1/port_name
===============
0x24000024ee09a545
/sys/class/fc_host/host2/port_name
===============
0x24000024ee09a578
[root@initso02 ~]#

 
Just omit the hexidecimal prefix "0x" as with Version 5 and you have the WWPN for each Fibre Channel HBA port.

Oracle Grid Control: “error: invalid compressed data to inflate” when trying do unzip Grid Control installation zip-file

Problem description:

When trying to extract the downloaded file GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip for a Grid Control intallation on Linux x86_64, you are receiving an error:

gc01:/INSTALL # unzip GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
Archive:  GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup2.jar
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup5.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup9.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup3.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup11.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup12.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup7.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup8.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup4.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup10.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup6.jar
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/
   creating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup5.1.1.jar
  error:  invalid compressed data to inflate
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup4.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup1.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup6.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup3.1.1.jar
gc01:/INSTALL # echo $?
2
gc01:/INSTALL #

Cause:

The file seems to be broken on the Oracle server since multiple downloads of the file always lead to a the same wrong checksum “3966614633″.

  • Checksum for downloaded file:

    oracle@gc01:/INSTALL> cksum GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
    3966614633 1589671704 GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip
    oracle@gc01:/INSTALL>
  • Checksums listed by Oracle:

    GridControl_11.1.0.1.0_Linux_x86-64_1of3.zip (1,430,649,530 bytes) (cksum - 4223002664)
    GridControl_11.1.0.1.0_Linux_x86-64_2of3.zip (1,589,671,704 bytes) (cksum - 535544209)
    GridControl_11.1.0.1.0_Linux_x86-64_3of3.zip (1,408,054,645 bytes) (cksum - 2199662147)

Problem resolution:

Download the Enterprise Manager installation medias from edelivery.oracle.com. The zip-files from this installation source are not broken and will output the correct checksums:

oracle@gc01:/INSTALL> cksum V23674-01_2of3.zip
535544209 1589671704 V23674-01_2of3.zip
oracle@gc01:/INSTALL>

Extraction:

oracle@gc01:/INSTALL> unzip V23674-01_2of3.zip
Archive:  V23674-01_2of3.zip
replace oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.ocamm/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup5.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup9.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup3.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup11.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup12.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup7.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup8.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup4.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup10.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.paf/11.1.0.1.0/1/DataFiles/filegroup6.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup5.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup4.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup1.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup2.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup6.1.1.jar
  inflating: oms/Disk1/stage/Components/oracle.sysman.agent.download/11.1.0.1.0/1/DataFiles/filegroup3.1.1.jar
oracle@gc01:/INSTALL> echo $?
0
oracle@gc01:/INSTALL>
Categories: Enterprise Manager, Linux, Oracle Tags:

Oracle RAC on Linux: PRVF-5449 and PRVF-5431 when executing addNode.sh

Problem description:

Executing addNode.sh in 11.2 results in PRVF-5449 and PRVF-5431 if Voting Disks are located on Oracle ASM Disks:

Checking Oracle Cluster Voting Disk configuration...
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID01(ORCL:GRID01)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID02(ORCL:GRID02)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
ERROR:
PRVF-5449 : Check of Voting Disk location "ORCL:GRID03(ORCL:GRID03)" failed on the following nodes:
Check failed on nodes:
        racn02
 
        racn02:No such file or directory
 
PRVF-5431 : Oracle Cluster Voting Disk configuration check failed
Time zone consistency check passed
 
 
 
[grid@racn01 bin]$

Although the Oracle ASM Disks are available on the node to add:

[root@racn02 ~]# service oracleasm listdisks | grep GRID
GRID01
GRID02
GRID03
[root@racn02 ~]#

Cause:

addNode.sh is checking Oracle ASM disks incorrectly and will cancel the node addition for Voting Devices on ASM disks.

Problem resolution:

Check manually if the Oracle ASM Disks are available on the nodes to add:

[root@racn02 ~]# service oracleasm listdisks | grep GRID
GRID01
GRID02
GRID03
[root@racn02 ~]#

If the voting disk locations check was the only one that failed, use the environment variable IGNORE_PREADDNODE_CHECKS and rerun addNode.sh. Otherwise resolve the other errors first before continuing.

Example usage of IGNORE_PREADDNODE_CHECKS:

[grid@racn01 bin]$ export IGNORE_PREADDNODE_CHECKS=Y
[grid@racn01 bin]$ ./addNode.sh "CLUSTER_NEW_NODES={racn02}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={racn02-vip}"
...
...

SuSE/SLES: hostname does neither print domain name nor fully qualified hostname

Problem description:

The hostname command does not recognise the domainname and will not use it in its output formats:

sles01:~ # hostname
sles01
sles01:~ # hostname -f
sles01
sles01:~ # hostname -d
 
sles01:~ #

Although the configuration seems correct:

  • /etc/HOSTNAME:

    sles01:~ # cat /etc/HOSTNAME
    sles01.mydomain
    sles01:~ #
  • /etc/resolv.conf:

    sles01:~ # cat /etc/resolv.conf
    search mydomain
    nameserver 192.168.0.1
    sles01:~ #

Problem resolution:

Check your /etc/hosts file and the order of the entries for your host. The fully qualified domain name should be in first position. In my case, the hosts-file somehow contained an entry with a wrong order:

sles01:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
 
127.0.0.1       localhost
 
192.168.0.100   sles01 sles01.mydomain
sles01:~ #

Example for a correct order of the entries:

sles01:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
 
127.0.0.1       localhost
 
192.168.0.100   sles01.mydomain sles01
sles01:~ #
Categories: Linux, Oracle, SuSE Linux Tags:

Linux/Nagios: sudo: sorry, you must have a tty to run sudo

Problem description:

If you are using Nagios or other monitoring products to check your servers, you might come into the situation running commands which require special permissions (e.g. like running them as the root-user). You have configured sudo permissions and your check runs fine on the terminal, but if the monitoring process/service tries to execute it, you are receiving the following message:

sudo: sorry, you must have a tty to run sudo

Cause:

By default sudo only allows to be executed with a tty:

[root@linux01 ~]# cat /etc/sudoers | grep requiretty
Defaults    requiretty
[root@linux01 ~]#

Problem resolution:

You can either disable requiretty or just disable it for the user you require to use sudo without tty (PREFERRED):

[root@linux01 ~]# cat /etc/sudoers | grep requiretty
Defaults    requiretty
Defaults:myosuser !requiretty
[root@linux01 ~]#
Categories: CentOS, Monitoring, Nagios, Oracle Linux, Red Hat Tags: