Saturday, 13 April 2013

Significance of /etc

Last week one of my friend caught up in a difficult situation while testing some shell scripts in a development server. He changed some configuration files in some directories in dev server but unfortunately the changes got reflected in production server and screwed up some process. Ultimately it resulted in monetary loss and some embarassing situation with client.

How the change made in dev server able to hit the prod server? is it possible?

Yes, The reason is pretty much simple which we would have never thought off. Some of the directories in dev server is mounted with prod server or vice versa. So ultimately he has changed the files in prod server through dev box.This is one of the worst practice should not be followed at any case, what ever the justification or need is.

Let us dive in to the issue and see how to find such directories in advance especially  to avoid embarassing situations.

This can be acheived in two ways now let us see the first method.

Method 1:

As we all aware that in UNIX each and every OS action is file based so the mount information will definitely be maintained in some file or files.

Now the task for us is to find out the file. Here you go........

File /etc/mnttab is really a file system  that  provides read-only  access  to  the table of mounted file systems for the current host. Mounting a file system adds an entry to this file and Unmounting  removes  an  entry     from  this file

so spending a minute to fire "cat /etc/mnttab" in UNIX prompt will help us a lot.

Method 2:

Its pretty much simple than first method. Use the unix command mount. This command will list out the directories which are mounted. Ultimatley it will display the contents of /etc/mnttab.

So I advise the developers and testers to perform this simple check before doing any changes in configuration files or scripts or just a flat file....
Some of the other Important files to make our life easy.

cron.deny, cron.allow, vfstab, inittab, ssh* set of files

To make it simple /etc is the directory which holds many of the support and configuration files of the server. Its always better to understand the significance of the files listed especially in /etc .

Hope this information helps you.

Thank you. Happy Coding.........

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!!!