Filed under: *Nix, Red Hat, Ubuntu | Tags: busy, device, rhel, Ubuntu, umount
So, one of these days, you will find yourself wanting to unmount a partition on your linux box. Problem is, most of the time, the partition is most likely still being used by some process, or by someone. So first, you need to find out which processes are keeping the drive busy, by:
root@Mach5-NX:~# fuser -m /media/prison /media/prison__: 3196c 3285c root@Mach5-NX:~# ps -ef | grep 3285 ikhsan 3285 3196 0 07:07 pts/1 00:00:00 vi lgf.conf
With that information in hand, you can start shutting down services, or killing the process that’s preventing you from unmounting the partititon:
root@Mach5-NX:~# kill 3285
Repeat the step above for each process listed on the previous command.
Or, if you’re feeling nasty, you can always kill all the process that’s using the partition, by issuing:
root@Mach5-NX:~# fuser -km /media/prison /media/prison__: 3350c 3437c
Unmount the drive normally
root@Mach5-NX:~# umount /media/prison
…And we’re done 
creating 1 or 2 new users on your system is a fairly simple task. But when you need to create 50 or 100 accounts on a system, creating it one by one by hand will surely annoy even the most patient sysadmin.
First, create a plain text file that contains all the informations required in a format of standard /etc/passwd file. For example, create a text file newuser.txt
[root@foxbat scripts] vi /root/newuser.txt
that contains:
ambon:afd43:673:673::/home/ambon:/bin/bash amurang:ixl89:674:674::/home/amurang:/bin/bash bandungcc:cfr45:675:675::/home/bandungcc:/bin/bash baubau:ndk73:676:676::/home/baubau:/bin/bash
“ambon” is the account name, “afd43″ is the new password for the account, “636″ refers to the account UID & GID. I skipped on the user info and leave it as blank. Next, the “/home/ambon” is the path to the home directory of that particular account, and “/bin/bash is the path to the account shell. Please note that since the password on this plain text is not encrypted, make sure that root and only root is the only user that has access to this file. You can chmod 600 this file to prevent access from another account.
Next, create the accounts by simply doing:
[root@foxbat scripts] newusers /root/newuser.txt
..And we’re done!
Filed under: *Nix, Red Hat, rhel, time out | Tags: export, import, redhat, rhel, volume group
This is a fairly straight-forward process.
- Exporting the volume group from its current host
- Unmount any LV residing on that particular VG. In my case, there’s only one LV on VG vg0
- list all lv in the vg
[root@hqhcmdev1 ~]# lvdisplay --- Logical volume --- LV Name /dev/vg0/lvol0 VG Name vg0 LV UUID 7HltCU-Elaq-x1pr-S7Wm-xvOt-NGk6-Fwufyd LV Write Access read/write LV Status NOT available LV Size 97.47 GB Current LE 6238 Segments 1 Allocation inherit Read ahead sectors 0 - unmount the lv
[root@hqhcmdev1 ~]# umount /u01 - if there’s any, remove the fstab entry for that particular partition, so that the booting process will not try to mount the partition
[root@hqhcmdev1 ~]# vi /etc/fstabThe /etc/fstab should look like this:
# This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 #LABEL=/u01 /u01 ext3 defaults 1 1
- list all lv in the vg
- Deactivate, and export the volume group
- Deactivating vg0
[root@hqhcmdev1 ~]# vgchange -an vg0 0 logical volume(s) in volume group "vg0" now active - exporting vg0
[root@hqhcmdev1 ~]# vgexport vg0 file system Volume group "vg0" successfully exported
- Deactivating vg0
- Unmount any LV residing on that particular VG. In my case, there’s only one LV on VG vg0
- Import the volume group to the new server
- Present the exported partition to the new server
- Search for the new partition This step depends on what hardware are you using for the storage. Some SANs provide it’s own tool, and others use linux generic command such as:
[root@hqhcmdev2 ~]# echo "- - -" > /sys/class/scsi_host/host0/scan - Check whether the partition has been detected by the target server using pvscan
[root@hqhcmdev2 ~]# pvscan PV /dev/sda2 VG VolGroup00 lvm2 [19.88 GB / 0 free] PV /dev/sdb1 is in exported VG vg0 [99.98 GB / 2.52 GB free] PV /dev/sdd1 VG VolGroup00 lvm2 [3.97 GB / 128.00 MB free] Total: 3 [123.83 GB] / in use: 3 [123.83 GB] / in no VG: 0 [0 ]
- Search for the new partition This step depends on what hardware are you using for the storage. Some SANs provide it’s own tool, and others use linux generic command such as:
- Activate and import the volumegroup
- Import the VG
[root@hqhcmdev2 ~]# vgimport vg0 Volume group "vg0" successfully imported - Activate the VG
[root@hqhcmdev2 ~]# vgchange -ay vg0
- Import the VG
- Mount the imported partition
- Create a mountpoint for the imported partition
[root@hqhcmdev2 ~]# mkdir /t01 - label the partition First, look for the logical volume residing on the newly imported partition
[root@hqhcmdev2 ~]# lvdisplay vg0 --- Logical volume --- LV Name /dev/vg0/lvol0 VG Name vg0 LV UUID 7HltCU-Elaq-x1pr-S7Wm-xvOt-NGk6-Fwufyd LV Write Access read/write LV Status available # open 1 LV Size 97.47 GB Current LE 6238 Segments 1 Allocation inherit Read ahead sectors 0 Block device 253:2Next, create a label for that LV
[root@hqhcmdev2 ~]# e2label /dev/vg0/lvol0 /t01 - optionally, create a fstab entry for the partition, if you want it to be automatically mounted on reboot
[root@hqhcmdev2 ~]# vi /etc/fstabThe /etc/fstab should look like this:
This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 LABEL=/t01 /t01 ext3 defaults 1 1 - Mount the partition
[root@hqhcmdev1 ~]# mount /t01
- Create a mountpoint for the imported partition
- Present the exported partition to the new server
If you’re into linux server administration, then sysstat is a very handy tool to have. It allows you to collect realtime and historical data about your server performance, and it’s readily available on all major linux distribution. What’s written in this blog is based on RHEL 4.7, but it should be applicable to other distros with some minor tweaks.
Packages to install on RHEL 4.7 :
- sysstat-5.0.5-19.el4.i386.rpm
to install:
[root@localhost RPMS]# rpm -ivh sysstat-5.0.5-19.el4.i386.rpm
warning: sysstat-5.0.5-19.el4.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:sysstat ########################################### [100%]
The first step that you’ll need to do is to make sure the sysstat is collecting data from your machine. Check the the content of /etc/crond.d/sysstat, it should be similar to this:
[root@localhost /]# more /etc/cron.d/sysstat
# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A
based on the above cron entry, the sa1 command is collecting data on your server in 10 minutes interval. You can change the interval by changing the */10 to whatever value you desire, ie: */5 for every 5 minutes. The data gathered by sa1 command is stored on saxx files, stored on /var/log/sa directory on your server, with xx refering to the date of the month (ie: sa01 for data gathered on the first day of the month)
The second cron line means that on 23:53 the sa2 command will generate a daily report, stored on a plain textfile named sarxx, with xx also refering to the date of the month.
The second step is to check whether the saxx files is created by sysstat
[root@localhost sa]# ls -la /var/log/sa
total 24
drwxr-xr-x 2 root root 4096 Apr 1 18:20 .
drwxr-xr-x 12 root root 4096 Apr 1 18:10 ..
-rw-r--r-- 1 root root 2064 Apr 1 18:20 sa01
Ok, so now sysstat is up and running on your server.
sysstat provides several tools to help you monitor your server, such as:
vmstat
used to monitor overall activity of the server
iostat
iostat can be used to monitor the disk activity of the server
mpstat
used to monitor processor(s) activities
Detailed functions of each tool can be found on their man pages.
I personally use sysstat for the sarxx files. It contains historical data of your server performance on a plain textfiles. You can load up the data to spreadsheet, and perform analysis to determine which part of your server is the performance bottleneck.
One tool that I often use to do this is kSar. kSar is a java application that can be used to translated your sysstat data to a graph. It’s very useful if you need to analyse the data at a glance.
kSar CPU overview
To run kSar, make sure you have java installed on your box. Then, download kSar from here, unzip, and run it by typing:
surfer@Mach5-M:~/apps/kSar-5.0.6$ java -jar kSar.jar
Then load one of a sarxx files created by sysstat (usually located on /var/log/sa for RHEL and its derivatives, /var/log/sysstat on ubuntu) by selecting Data > Load from textfile.
Memory usage on kSar
Filed under: *Nix, AIX, HP-UX, Red Hat, rhel | Tags: AIX, HP-UX, ibm, redhat, rhel, serial, tape, tivoli, tsm
One thing that you need to set up LanFree on TSM (or any kind of SAN Fiber channel backup) is the serial number of the tape drive registered on your server. I happen to be working on a somewhat heterogeneous environment that includes AIX, HP-UX, RHEL, and Windows. Below is my note on how to obtain the tape drive serial number those OSes. I’m using IBM TS3200 as our media library
RHEL
Pretty straight forward . All you have to do is type the following command:
[root@hqdwhbe1 ~]# cat /proc/scsi/IBMtape
lin_tape version: 1.10.0
lin_tape major number: 250
Attached Tape Devices:
Number model SN HBA FO Path
0 ULT3580-TD4 1310140159 qla2xxx NA
1 ULT3580-TD4 1310039844 qla2xxx NA
2 ULT3580-TD4 1310135990 qla2xxx NA
3 ULT3580-TD4 1310135028 qla2xxx NA
4 ULT3580-TD4 1310136043 qla2xxx NA
5 ULT3580-TD4 1310136063 qla2xxx NA
[root@hqdwhbe1 ~]#
The command above will show you the serial number of all tape drive installed on your RHEL box
AIX
Similar to RHEL, do this on the console:
# lscfg -vpl rmt0
rmt0 U789D.001.DQD74R5-P1-C2-T2-W2002000E11114398-L0
IBM 3580 Ultrium Tape Drive (FCP)
Manufacturer................IBM
Machine Type and Model......ULT3580-TD4
Serial Number...............1310140159
Device Specific.(FW)........89B2
PLATFORM SPECIFIC
Name: tape
Node: tape
Device Type: byte
HP-UX
IBM provide us with tapeutil, a nice tool operate the IBM tape from console. To start, just type:
# tapeutil
From the menu, press “1″ to open a device. Type down the path to your tape drive. Next press “1″ to choose to open the device for read/write access
..On the next screen, press “3″ to query for the tape drive serial number
There you go
That’s it
For those who are still using RHEL 4.x and in need of deploying PHP 5.3 & MySQL 5.1 , you can get the required rpm packages from here. You can add the repo and update php and MySQL packages via yum, or download and install manually. I think the bare minimum will require these packages :
PHP
- php-cli-5.3.1-1.el4.remi
- php-5.3.1-1.el4.remi
- php-common-5.3.1-1.el4.remi
- php-mysql-5.3.1-1.el4.remi
- php-pdo-5.3.1-1.el4.remi
MySQL
- mysqlclient15-5.0.67-1.el4.remi
- mysql-server-5.1.42-1.el4.remi
- mysqlclient14-4.1.22-1.el4.remi
- mysql-libs-5.1.42-1.el4.remi
- mysql-5.1.42-1.el4.remi
Also you might need the packages that I listed below for php 5.3 & MySQL 5.1 to install correctly. Some of them are not available at Remi’s repo, so I upload them to my dropbox account in case somebody need them :
- perl-DBD-MySQL-4.006-1.el4.centos
- libedit-2.11-1.20080712cvs.el4.remi
- sqlite2-2.8.17-2.el4.remi
- sqlite-3.3.6-2
Of course I think this will void your service warranty with Red Hat 
This is tested on RHEL 4.7
Filed under: *Nix, E51, IRL, life on the wired, oracle, Red Hat | Tags: EBS, linux, nfs, ORA-27054, oracle, redhat, rhel
I previously encountered this issue on my 10.2 RAC nodes running on top of HP-UX. I faced it the 2nd time when performing postclone operation on a Oracle EBS 12.0.0.5 on AIX. This time, the error popped up when I’m trying to perform postclone for Oracle EBS HCM module on a RHEL 4U6 x86-64. A reference in using nfs for Oracle can be found here. My NFS partition is mounted using :
mount 172.16.2.82:/hcmdev /u01 -o rw,bg,intr,hard, timeo=600,wsize=32768,rsize=32768,vers=3,tcp
I don’t have to put “noac” on the option since the RHEL node is not an RAC cluster
Some time ago, I was asked to setup a public key authentication for SCP session betwen 2 *nix servers. The process should be straight forward, as mentioned on my previous post regarding this subject.
But somehow the login process keep on asking me to enter the correct password, and ignoring the public key that I have copied to the remote server. I start the process in verbose mode, so that I can get meaningful output that can help me solve the issue:
[surfer@kazekiri ~]$ ssh -v mach5@avenger
and this is snipped from the output that I get:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/surfer/.ssh/identity
debug1: Trying private key: /home/surfer/.ssh/id_rsa
debug1: Offering public key: /home/surfer/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
This means the private key is recognized, and was offered as a mean for authentication by the local server, but somehow the login process still require me to type-in the password for the remote user.
After some reading, I found out the culprit was the access restriction to the key stored on each server. The login process requires that the private key (id_dsa) and the public key stored on the remote server (authorized_keys) are stored on a folder that can only be accessed by the corresponding users. So I need to do the following:
[surfer@kazekiri ~]$ chmod -R 700 .ssh
and, also on the remote server:
[mach5@avenger ~]$ chmod -R 700 .ssh
Aaand, voila! The public key authetication should works.
Filed under: *Nix, HP-UX, Red Hat, Ubuntu | Tags: *Nix, HP-UX, SCP, shell script, unix
So I need to automate a process where an oracle dump file is moved to a remote server, and the existing loacl file is then permanently removed. I have to make sure that:
- the status of copy process is reported, whether successful, or not
- The remove process will only start if the copy process is successful
- The copy process is unattended, so a public key authentication must be available between the local and remote server. I have guide regarding a public key authentication for ssh/scp somewhere around here
This is how the script looked like:
#!/sbin/sh
date >> /backup/movedump.log
tgl=$(date +”%y-%m-%d-%M”)
cd /backup
if [ -f /backup/dumpf* ];
then
scp dumpf* kirim@172.16.2.15:/opt/data/dump/backup/
STAT=$?
echo “$tgl-S1:dump file succesfuly moved” >> /backup/movedump.log
else
STAT=1
fi
if [ $STAT -eq 0 ];
then
rm dumpf*
echo “$tgl-S2:local dump file deleted” >> /backup/movedump.log
else
if [ $STAT -eq 1 ];
then
echo “$tgl-E1:no dump file on source directory, no action taken” >> /backup/movedump.log
else
echo “$tgl-E2:dump file move process exit with code $STAT, remove process not executed” >> /backup/movedump.log
fi
fi
The code above will check whether the dumpfile exists or not. If the file doesn’t exist, the variable STAT will be given a value of 1. If the file exist, it will begin scp process to the remote server. Scp process provide us with several report codes that is stored on “$?”. If the copy process is successful, the value of “$?” is 0, other if it’s not. That value is then stored on the variable STAT
The process then proceed based on the value inserted to the variable STAT
- If STAT=0, the copy process is successful, the script will proceed to remove the dump file on the local server
- if STAT=1, the script did not find a dump file to transfer to remote server
- if STAT value is other than 1 and 0, the transfer process has failed
All of the step taken by the script is logged on file movedump.log
The next step is to make sure the script is executed everyday, automatically. For me, it is scheduled to run 4 pm, everyday:.
$crontab -e
Then put this line:
00 16 * * * /backup/movedump.sh
With this, the script will be executed every day at 4 pm sharp.
Done!
Interface or NIC bonding or also called teaming, is to use two or more NIC in conjunction using round robin scheduler. The machine will only recognize one interface, while packet are sent from two slave interface. (more…)
