Saturday 10 December 2011

Unix History files.

Have you ever thought about where and how the history of commands used in the UNIX server is logged?
I thought of it today and that’s the reason why I share this article with you.
So by this time many people would have guessed that it should be in some file because in UNIX everything is based on file system. Now the next question is what file it is?
Here it is “.sh_history” and “.bash_history” – These are the hidden files which stores the commands what you use. Again the name and location of the files depends on how the configuration set up is. One more point to add is you need to use “ls –a” to list out these hidden files.
Let’s assume the file names are default file names (As mentioned above). The storage of commands and number of commands to be stored in these files are again configuration based. By default its 500 commands/lines.
In most of the cases the default location of these files would be your home directory and in some rare cases I have also seen these files in /etc directory (That again configuration based). So you need to take the pain of locating the directory.               
Don’t get panicked. It’s again very simple to locate the directory. Use the environment variable HISTFILE to find the file name of bash history file.
$ echo $HISTFILE
 As simple as that isn’t it? The below listed are some of the common bash history related variables. Please take the pain of googling to know more about these variables.
HISTFILESIZE, HISTSIZE, HISTTIMEFORMAT, HISTCONTROL, TMOUT and HISTIGNORE  
Hope the information is informative to my readers…

Auditing e-mail’s which flow out from UNIX server.

I believe most of us who work in UNIX know how to send an e-mail from UNIX servers

 Yes you are right, using the mailx command you can send e-mails to the people or team or to any interested parties.  But is there any way to audit those e-mails?
    Yes it’s pretty much easy and straight forward. Let us see how to do that.
    All the communication related details are stored in the files named syslog and authlog. These files holds the details of e-mail, ssh, rsh, ftp related communications from the server. This log files plays a major role in auditing especially when we share a common id in our projects (Of course that’s not advisable but it’s still happening in many organizations)
Ok let’s come to the point. Use the below simple command to find out the e-mails flown out from your server. This way you can capture the recipients of the e-mail with delivery time.
$grep sendmail /var/log/syslog
Similarly to find out the other inter- server communication details.
$grep ssh /var/log/syslog
$grep ssh /var/log/authlog
$grep ftp /var/log/authlog
This may sound simple for the people who already knew it, but I guess this will definitely be an useful information for many.  

Friday 9 December 2011

Database process triggered from Unix Shell script is moving or not?

Hi Friends
Many times we doubt whether the Shell script which is designed to do some database activities is actually doing its work or not. Of course, this situation would have been faced many times by people who work in support based projects.
Let me give you a simple suggestion to check the database movement of a process (Assuming the database you use is Sybase).
Here we go...
Step 1 – First and foremost, Get the process id of the Shell script which triggers the database activity. Do you know how?
ps –ef  |grep <Shell script name>
Example:
$ps –ef |grep run_shell1.ksh
primuni 28763  6490  0 23:12:35 pts/1    0:00 grep run_shell1.ksh
primuni 17555 17549  0 23:06:03 ?        0:01 /bin/ksh /homedirectory/scripts/run_shell1.ksh
Step 2 – Now the process id 17555 definitely would have triggered the child process to perform the database activity. So you need to find the process which actually communicates with the database. Either you need to do it manually or use ptree command to get those details.
Here I am going to use ptree command to get the details.
$ptree 17555
2330  /usr/sbin/inetd -s
  17549 auto_remote
    17555 /bin/ksh /homedirectory/scripts/run_shell1.ksh
      10275 /homedirectory/bin/dumpit -S MY_SERVER -D my-dbase -U primuni -P Hell0123 -T in
Wow! now you got the process id which actually does the database stuff for you….
Step 3 – Use the process id and check the physical IO Movement in database. Do you know how to do that? No worries even if you don’t.
Here it is…
select physical_io  from master..sysprocesses where hostprocess in ('10275')
physical_io

457123
Run the query at regular intervals and make sure that you see some change in value in output. If it’s not moving for quite some time then your process is in trouble. So In this case you have to check for database block or lock etc…
Will meet you all soon with a new post!!!