Showing posts with label redhat. Show all posts
Showing posts with label redhat. Show all posts

Saturday, December 8, 2012

Finding superblocks and fsck in RHEL



"If it looks like there is an issue with the filesystem's superblock. By running the command below we can check for the location of where backup superblocks will be:

mkfs.ext3 -n /dev/mapper/vg01-lvol5

The mkfs command may cause you some worry, but I'd like to stress the importance of -n option. This causes it to not actually perform any changes. Here is an excerpt from the mkfs.ext3 man page:

 -n     Causes mke2fs to not actually create a filesystem,  but  display
              what it would do if it were to create a filesystem.  This can be
              used to determine the location of the backup superblocks  for  a
              particular  filesystem,  so  long  as the mke2fs parameters that
              were passed when the filesystem was originally created are  used
              again.  (With the -n option added, of course!)

After this we can look for the lines simlar to:

Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632


Take the first value, i.e. 32768 and try using the commands I previously pasted with the -b option.

Once again confirm that the operation to be performed looks sane, keeping in mind to replace 32768 with your actual value:

fsck -b 32768 -fN /dev/mapper/vg01-lvol5

Then if it looks good try with:

fsck -b 32768 -fy /dev/mapper/vg01-lvol5

If you find the first backup superblock does not work try again with the next available one, i.e. 98304.

Again please make sure to have the filesystem unmounted."

Thursday, October 4, 2012

How do I move a Volume Group from one system to another?

We recently moved a server from one location to other but SAN as replicated one, not the original LUNs which were in use. Below are the steps followed.



1. Make sure to stop all the access to device coming from the old storage. You may need to unmount the devices if in use. Verify with the lsof command that no device is being used.

2. Poweroff the server. (step 1 can be skipped)

3. Detach the old storage.

4. Reboot the server and verify that it is booting correctly and no traces of old storage are present.

5. Poweroff the server. Move to another location. I assume here that the same multipathing software is being used, in our case it is EMC powerpath.

6. connect the server to new storage [Replicated disks] and boot the server.

7. All the LUNs should come up with the multipathing software. Any VGs should get activated.


You may also be interested in reading the following article (Commands in detail)

 https://access.redhat.com/knowledge/solutions/4123   How do I move a Volume Group from one system to another?

Friday, December 9, 2011

configure netdump of client RHEL 4.8 on RHEL 5.5

Login to the server monroe with individual login Id and then switch to root account
Netdump server: [root@monroe ~]# uname -a Linux monroe.imation.com 2.6.18-194.26.1.el5 #1 SMP Fri Oct 29 14:21:16 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [root@monroe ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) [root@monroe ~]#

Netdump client: grant:/root>cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 8) grant:/root>uname -a Linux grant 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:46:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux grant:/root>

Pre Tasks:

#uname -a
#df -k
#vgdisplay –v vg00
#lvs vg00
#cp –p /etc/fstab /etc/fstab.9DEC2011


Current information:

[root@monroe ~]# vgs vg00
VG #PV #LV #SN Attr VSize VFree
vg00 1 8 0 wz--n- 119.59G 68.59G
[root@monroe ~]#
[root@monroe ~]# lvs vg00
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lvol0 vg00 -wi-ao 5.00G
lvol1 vg00 -wi-ao 16.00G
lvol2 vg00 -wi-ao 6.00G
lvol3 vg00 -wi-ao 5.00G
lvol4 vg00 -wi-ao 5.00G
lvol5 vg00 -wi-ao 5.00G
lvol6 vg00 -wi-ao 5.00G
lvol7 vg00 -wi-ao 4.00G
[root@monroe ~]#

Activity:Create the file system /var/crash with 40GB Size


->create a 40gb logical volume lvol8 in volume group vg00
monroe#lvcreate -L 40G -n lvol8 vg00

->create ext3 file system on newly created logical volume
monroe#mkfs -t ext3 /dev/vg00/lvol8

->Mount the volume /dev/vg00/lvol8 on mount point /var/crash
monroe#mount /dev/vg00/lvol8 /var/crash

Update the file /etc/fstab with following entries.
Take the backup of /etc/fstab

/dev/vg00/lvol8 /var/crash ext3 defaults 1 2

Verify the file sytem /var/crash has been created with 40gb size and accessible

monroe# df –h /var/crash
monroe#lvs vg00


Netdump configuration:

On Server - Monroe:

 Need to install package
Install the EPEL version of netdump-server on your RHEL 5.5, please download the package from the link below: http://download.fedora.redhat.com/pub/epel/5/x86_64/netdump-server-0.7.16-23.el5.x86_64.rpm
Downloaded already to the server.

monroe# rpm –ivh netdump-server-0.7.16-23.el5.x86_64.rpm

On the netdump server, as root, type:
monroe# passwd netdump
and supply a password for netdump just like what you do to an ordinary user. Then do the following:
monroe# chkconfig netdump-server on
monroe# service netdump-server start



Client - Grant:

 Package is already present.

grant:/root>rpm -q netdump
netdump-0.7.16-14
grant:/root>

Edit /etc/sysconfig/netdump then uncomment and set the NETDUMPADDR variable to the IP address of the netdump server. For example:
NETDUMPADDR= 172.16.109.178

Then execute:
grant# service netdump propagate
and supply the netdump password that was configured on the netdump server. Finally, execute:
grant# chkconfig netdump on
grant# service netdump start

Useful Docs:
https://access.redhat.com/kb/docs/DOC-6855
https://access.redhat.com/kb/docs/DOC-4104
If you would like to install the EPEL version of netdump-server on your RHEL 5.5, please download the package from the link below: http://download.fedora.redhat.com/pub/epel/5/x86_64/netdump-server-0.7.16-23.el5.x86_64.rpm

Monday, November 7, 2011

vsftpd How To

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch15_:_Linux_FTP_Server_Setup

Friday, November 4, 2011

HowTo: Configure Linux To Track and Log Failed Login Attempt Records

PAM Settings

I found that under RHEL / CentOS Linux 5.x, you need to modify /etc/pam.d/system-auth file. You need to configure a PAM module pam_tally.so. Otherwise faillog command will never display failed login attempts.

PAM Configuration To Recored Failed Login Attempts

pam_tally.so module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail. Edit /etc/pam.d/system-auth file, enter:
# vi /etc/pam.d/system-auth

Modify as follows:
auth required pam_tally.so no_magic_root
account required pam_tally.so deny=3 no_magic_root lock_time=180

Where,

deny=3 : Deny access if tally for this user exceeds 3 times.
lock_time=180 : Always deny for 180 seconds after failed attempt. There is also unlock_time=n option. It allow access after n seconds after failed attempt. If this option is used the user will be locked out for the specified amount of time after he exceeded his maximum allowed attempts. Otherwise the account is locked until the lock is removed by a manual intervention of the system administrator.
magic_root : If the module is invoked by a user with uid=0 the counter is not incremented. The sys-admin should use this for user launched services, like su, otherwise this argument should be omitted.
no_magic_root : Avoid root account locking, if the module is invoked by a user with uid=0
Save and close the file.

How Do I Display All Failed Login Attempts For a User Called vivek?

Type the command as follows:
# faillog -u vivek

Login Failures Maximum Latest On
vivek 3 0 12/19/07 14:12:53 -0600 64.11.xx.yy
Taks: Show Faillog Records For All Users

Type the following command with the -a option:
# faillog -a

Task: Lock Account

To lock user account to 180 seconds after failed login, enter:
# faillog -l 180 -u vivek
# faillog -l 180

Task: Set Maximum Number of Login Failures

The -m option is allows you to set maximum number of login failures after the account is disabled to specific number called MAX. Selecting MAX value of 0 has the effect of not placing a limit on the number of failed logins. The maximum failure count should always be 0 for root to prevent a denial of services attack against the system:
# faillog -M MAX -u username
# faillog -M 10 -u vivek

How do I Reset The Counters Of Login Failures?

The -r option can reset the counters of login failures or one record if used with the -u USERNAME option:
# faillog -r

To reset counter for user vivek, enter:
# faillog -r -u vivek

On large Linux login server, such as University or government research facility, one might find it useful to clear all counts every midnight or week from a cron job.
# crontab -e

Reset failed login recover every week:
@weekly /usr/bin/faillog -r

Save and close the file.

Recommended readings:

=> Read the pam_tally, faillog and pam man pages:
$ man pam_tally
$ man tally
$ man faillog


courtesy: http://www.cyberciti.biz/tips/rhel-centos-fedora-linux-log-failed-login.html