Jasvinder Singh Aulakh (Sr. Lead Devops)

Configure rsyslog in RHEL 6.x / CentOS 6.x Step 1 :  Enable the module.We will uncomment the below given line by removing  # Edit the file /etc/rsyslog.conf Uncomment by removing  #  in front of these module names module(load="imuxsock") # provides support for local system logging (e.g. via logger command) module(load="imklog")   # provides kernel logging support (previously done by rklogd Now, in same file , search for line *.emerg *. Modify the action (i.e *) with :omusrmsg:* . See below given reference *.emerg                        :omusrmsg:* Now, at the end of file  /etc/rsyslog.conf , paste the below given code(These are rsyslog templates) # $template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" $template TmplMsg, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" authpriv.*   ?TmplAuth *.info,mail.none,authpriv.none,cron.none   ?TmplMsg Now , save and exit ...

 I've never logged into before via ssh, but it also cats the trusted key into the ~/.ssh/authorized_ksys file. Essentially it would be like combining the two scripts below.  1.  Create a script 1 with following: #!/bin/bash set -x HOST_FILE=$1 for SERVER in `cat $HOST_FILE` do         if ping -c 1 ${SERVER} |grep "100% packet loss"         then                 :         else         sshpass -p 'password' scp /root/.ssh/id_rsa.pub root@${SERVER}:/tmp         sshpass -p 'password' scp script1  root@${SERVER}:/tmp         sshpass -p 'password' ssh root@${SERVER} "chmod 755 /tmp/script1;/tmp/script1"         fi done 2. Create 2nd script of name script1 with following: #!/bin/bash set -x if [ ! -d /root/.ssh ] then         mkdir /root/....

lslpp -L                             displays info about all installed filesets or fileset updates lslpp -L <fileset>                   displays info about that fileset lslpp -h <fileset>                   shows the history of the fileset lslpp -l | grep <fileset>           shows if it is installed or not lslpp -lc| grep <fileset>           shows the state (Aplp., Comm., Broken..) in /etc/objrepos and in /usr/lib/objrepos of a fileset lslpp -f <fileset>                   shows all files that are installed with  a particular fileset lslpp -w /usr/local/bin/lsof        shows the fileset which contains the giv...

Backup rootvg using mksysb mksysb Creates an installable image of the root volume group either in a file or on to a bootable tape Bootable tape is created in backup format Can be restored individual files/directories using restore command mksysb -e /excludes files in /etc/exclude.rootvg -i to create image.data file -v verbose mode -X extend /tmp filesystem if necessory for storing boot image   -i option calls  mkszfile  command which inturn creats /image.data file. The bootable mksysb volume contains four images Boot image bosinstall image (image.data, bosinst.data, tapeblksz, etc..) An empty table of contents System Backup Image in Back up format /bosinst.data  file contains answer for questions during installation time such as Console name, Installation methode, locale seetings, etc.. If there is no /bostinst.data file present, then a sample file /usr/lpp/bosinst/bosinst.template is copied...

This article is a comprehensive steps for installing Oracle Database 11 g Release 2 (11.2.0.1) on the Red Hat Enterprise Linux 6 (RHEL6)  operating environment. Both 32-bit (x86) and 64-bit (x86_64) architectures are covered in this guide. Unless otherwise noted, the installation steps are the same for either. Having said that, one of the first decisions to make before continuing with this guide is which architecture you will be using. Both Oracle and Linux must be installed on the same operating system architecture. For example, 32-bit Oracle is only supported to run on 32-bit Linux OS and 64-bit Oracle is only supported to run on 64-bit Linux OS. Install Required Linux Packages for Oracle: After installing the Linux OS, the next step is to verify and install all packages required for Oracle Database 11 g Release 2. The Oracle Universal Installer (OUI) performs checks on the machine during installation to verify that it meets the...

The Audit system operates on a set of rules that define what is to be captured in the log files. There are three types of Audit rules that can be specified: Control rules — allow the Audit system's behavior and some of its configuration to be modified. File system rules — also known as file watches, allow the auditing of access to a particular file or a directory. System call rules — allow logging of system calls that any specified program makes.  Audit rules can be specified on the command line with the auditctl utility (note that these rules are not persistent across reboots), or written in the /etc/audit/audit.rules file. The following two sections summarize both approaches to defining Audit rules.   Auditing goals By using a powerful audit framework, the system can track many event types to monitor and audit the system. Examples include: Audit file access and modification See who changed a particular file Detect unauthorized cha...