Tomcat SSL requirement from client

    <Connector port="443"
               keystoreFile="/root/certificates/keystore.store"
               keystorePass="<keystorePass>"
               SSLEnabled="true"
               maxThreads="150"
               scheme="https"
               secure="true"
               connectionTimeout="2000"
               clientAuth="true"
               sslProtocol="TLS"
               address="172.16.95.162"
               restrictedUserAgents="^.*MS Web Services Client Protocol.*$"/>

clientAuth - Set to true if you want the SSL stack to require a valid certificate chain from the client before accepting a connection. Set to want if you want the SSL stack to request a client Certificate, but not fail if one isn't presented. A false value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication.

Rebuild initrd in Redhat Linux

Reference (Rebuild initrd and boot sequence): http://advancelinux.blogspot.ca/2013/06/how-to-rebuild-initrd-or-initramfs-in.html
 

What is initrd?

 The initial RAM disk (initrd) is an initial root file system that is mounted prior to when the real root file system is available. The initrd is bound to the kernel and loaded as part of the kernel boot procedure.

When do we need to rebuild initrd?

• If adding new hardware to a system that may be used very early in the boot process.
• If changing configuration files that may be used very early in the boot process
• If changing the options on a kernel module.

How to rebuild initrd?

mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r)

mkinitrd -f -v /boot/initrd-2.6.18-164.el5.img 2.6.18-164.el5

Kernel and initrd path in grub.conf

[root@localhost grub]# pwd
/boot/grub
[root@localhost grub]# cat grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-348.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-348.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet crashkernel=128M@16M
        initrd /initrd-2.6.18-348.el5.img

Mysql admin

Running mysql commands stored in a file without headers (Batch mode):

mysql --skip-column-names -h10.10.1.50 -u<username> -p < batch_file.txt

Execute mysql in one line,
mysql -u<user> -p -e "show processlist"

"show proceslist" shows you which threads are running. This statement is very useful if you get the “too many connections” error message and want to find out what is going on.

mysql> show FULL processlist; 
+-------+----------+---------------------+--------+---------+------+-------+-----------------------+
| Id    | User     | Host                | db     | Command | Time | State | Info                  |
+-------+----------+---------------------+--------+---------+------+-------+-----------------------+
| 20484 | User1 | localhost           | NULL   | Sleep   | 1381 |       | NULL                  |
| 20485 | User1 | 172.16.95.15:49580 | portal | Sleep   | 3056 |       | NULL                  |


mysql> show FULL processlist\G
*************************** 1. row ***************************
     Id: 20484
   User: user1
   Host: localhost
     db: NULL
Command: Sleep
   Time: 1414
  State:
   Info: NULL
*************************** 2. row ***************************
     Id: 20485
   User: user1
   Host: 172.16.95.15:49580
     db: portal
Command: Sleep
   Time: 3089
  State:
   Info: NULL

File System Failures

http://www.cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html 

 

Surviving a Linux Filesystem Failures

by NIX Craft on November 8, 2005 · 26 comments· LAST UPDATED November 15, 2007

in Debian Linux, File system, Gentoo Linux

When you use term filesystem failure, you mean corrupted filesystem data structures (or objects such as inode, directories, superblock etc. This can be caused by any one of the following reason:
* Mistakes by Linux/UNIX Sys admin
* Buggy device driver or utilities (especially third party utilities)
* Power outage (very rarer on production system) due to UPS failure
* Kernel bugs (that is why you don't run latest kernel on production Linux/UNIX system, most of time you need to use stable kernel release)
Due to filesystem failure:

• File system will refuse to mount
• Entire system get hangs
• Even if filesystem mount operation result into success, users may notice strange behavior when mounted such as system reboot, gibberish characters in directory listings etc

So how the hell you are gonna Surviving a Filesystem Failures? Most of time fsck (front end to ext2/ext3 utility) can fix the problem, first simply run e2fsck - to check a Linux ext2/ext3 file system (assuming /home [/dev/sda3 partition] filesystem for demo purpose), first unmount /dev/sda3 then type following command :
# e2fsck -f /dev/sda3
Where,

• -f : Force checking even if the file system seems clean.

Please note that If the superblock is not found, e2fsck will terminate with a fatal error. However Linux maintains multiple redundant copies of the superblock in every file system, so you can use -b {alternative-superblock} option to get rid of this problem. The location of the backup superblock is dependent on the filesystem's blocksize:

• For filesystems with 1k blocksizes, a backup superblock can be found at block 8193
• For filesystems with 2k blocksizes, at block 16384
• For 4k blocksizes, at block 32768.

Tip you can also try any one of the following command(s) to determine alternative-superblock locations:
# mke2fs -n /dev/sda3
OR
# dumpe2fs /dev/sda3|grep -i superblock
To repair file system by alternative-superblock use command as follows:
# e2fsck -f -b 8193 /dev/sda3
However it is highly recommended that you make backup before you run fsck command on system, use dd command to create a backup (provided that you have spare space under /disk2)
# dd if=/dev/sda2 of=/disk2/backup-sda2.img
If you are using Sun Solaris UNIX, see howto: Restoring a Bad Superblock.
Please note that things started to get complicated if hard disk participates in software RAID array. Take a look at Software-RAID HOWTO - Error Recovery. This article/tip is part of Understanding UNIX/Linux file system series, Continue reading rest of the Understanding Linux file system series (this is part III):

• Part I - Understanding Linux superblock
• Part II - Understanding Linux superblock
• Part III - An example of Surviving a Linux Filesystem Failures
• Part IV - Understanding filesystem Inodes
• Part V - Understanding filesystem directories
• Part VI - Understanding UNIX/Linux symbolic (soft) and hard links
• Part VII - Why isn't it possible to create hard links across file system boundaries?

Create a 1GB random file

dd can be used to wipe out the file, whole drive or partition permanently.

dd if=/dev/urandom of=sample.txt bs=1G count=1

dd if=/dev/zero of=sample.txt bs=1G count=1 

SSH Login with password

Host A / User A ---login---> Host B / User B

Generating public / private rsa key pair

a@A:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa): 
Created directory '/home/a/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

Copy the public key from A:id_rsa.pub to B:authorized_keys 

a@A:~> cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'
b@B's password: 

SSH Login without password

a@A:~> ssh b@B hostname
B 

route and route table

[root@localhost ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.95.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         172.16.95.1     0.0.0.0         UG    0      0        0 eth0


The server is sitting on the subnet 172.16.95.0. Add a route to the route table. The route will be rolled back next reboot. 

The gw has to be the ip directly reachable from your subset.
[root@localhost ~]# route add -net 192.168.102.0 netmask 255.255.255.0 gw 172.16.95.2

[root@localhost ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.102.0   172.16.95.2     255.255.255.0   UG    0      0        0 eth0
172.16.95.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         172.16.95.1     0.0.0.0         UG    0      0        0 eth0

[root@localhost ~]# route del -net 192.168.102.0 netmask 255.255.255.0 eth0
[root@localhost ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.95.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         172.16.95.1     0.0.0.0         UG    0      0        0 eth0

Add the route permanently, network restart is needed.

[root@localhost ~]# echo "192.168.102.0/24 via 172.16.95.2" >> /etc/sysconfig/ne
twork-scripts/route-eth0

[root@localhost ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.102.0   172.16.95.2     255.255.255.0   UG    0      0        0 eth0
172.16.95.0     *               255.255.255.0   U     1      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         172.16.95.1     0.0.0.0         UG    0      0        0 eth0

SNMP and its linux command

SNMP basic components and its functions:

The SNMP architecture consists of

The SNMP Manager

A managed device

An SNMP Agent

Management Information Databases (otherwise known as Management Information Bases or MIBs)


The SNMP Manager - (Usually the Network Management System - NMS) communicates with the multiple SNMP Agents implemented in the network.

A managed device - or the network element is a part of the network that requires some form of monitoring and management e.g. routers, switches, servers, workstations, printers, UPSs, etc..

An SNMP Agent - is a program that is bundled within the managed device. Enabling this agent allows it to collect the Management Information Database from the device locally to make it available to the SNMP Manager on request. These Agents could be standard (e.g. Net-SNMP) or specific to a vendor. (e.g. HP Insight Agent). The agent listens at port 161. TODO: UDP or TCP?

Management Information Base / database - The commonly shared database between the Agent and the Manager is called Management Information Base (MIB). In short, MIB files are the set of questions that the SNMP Manager can ask the Agent. The Agent collects these data locally and stores it, as defined in the MIB.

The MIBs contain a standard set of statistical and control values defined for the managed devices on a network. The SNMP protocol also allows the extension of these standard values with values specific to a particular Agent through the use of private MIBs. So the SNMP Manager should be aware of these standard and private questions for every type of Agent.
     

Linux Command 

One can simply issue one snmpwalk request on the root node of the sub-tree and the command gets the value of every node in the sub-tree.

[root@localhost ~]# snmpwalk -v 2c 169.254.0.8 -c FortiManager | grep OID
...
SNMPv2-SMI::mib-2.47.1.2.1.1.3.1 = OID: SNMPv2-SMI::enterprises.12356
...
[root@localhost ~]# snmpwalk -v 2c 169.254.0.8 -c FortiManager SNMPv2-SMI::enterprises.12356
...
SNMPv2-SMI::enterprises.12356.101.4.1.6.0 = Gauge32: 0
SNMPv2-SMI::enterprises.12356.101.4.1.7.0 = Gauge32: 0
SNMPv2-SMI::enterprises.12356.101.4.1.8.0 = Gauge32: 9
SNMPv2-SMI::enterprises.12356.101.4.1.9.0 = Gauge32: 80
SNMPv2-SMI::enterprises.12356.101.4.1.10.0 = Gauge32: 254764
SNMPv2-SMI::enterprises.12356.101.4.1.11.0 = Gauge32: 0
SNMPv2-SMI::enterprises.12356.101.4.1.12.0 = Gauge32: 0
SNMPv2-SMI::enterprises.12356.101.4.1.13.0 = Gauge32: 0
SNMPv2-SMI::enterprises.12356.101.4.1.14.0 = Gauge32: 0
...

[root@localhost ~]# snmpget -v 2c 169.254.0.8 -c FortiManager SNMPv2-SMI::enterprises.12356.101.4.1.8.0
SNMPv2-SMI::enterprises.12356.101.4.1.8.0 = Gauge32: 11