how to disable ipv6 – centos/redhat

how to disable ipv6

/etc/sysconfig/network-scripts/ifcfg-eth0

Code:

DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.0.2
NETMASK=255.255.255.0
GATEWAY=10.64.64.64
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=yes
DNS1=203.2.193.67
DNS2=202.135.30.4
DOMAIN=vfinternet.au
RESOLV_MODS=no
LINK_DETECTION_DELAY=6
IPV6INIT=no
IPV6TO4INIT=no

Configuring Simple SNMP on a Linux Server

By default Fedora, installs the net-snmp package as its SNMP server product. This package uses a configuration file named /etc/snmp/snmpd.conf in which the community strings and other parameters may be set. The version of the configuration file that comes with net-snmp is quite complicated. I suggest archiving it and using a much simpler version with only a single line containing the keyword rocommunity followed by the community string. Here is an example.

1) Save the old configuration file and make sure the new configuration file has the correct permissions
[root@bigboy tmp]# cd /etc/snmp/
[root@bigboy snmp]# mv snmpd.conf snmpd.conf.old
[root@bigboy snmp]# touch snmpd.conf
[root@bigboy snmp]# chmod 600 snmpd.conf
[root@bigboy snmp]# vi snmpd.conf

2) Enter the following line in the new configuration file to set the Read Only community string to nomnom.
rocommunity nomnom

3) Configure Linux to start SNMP services on each reboot with the chkconfig or sysv-rc-conf command depending on your linux variation:

For Fedora / RedHat / CentOS it would be:
[root@bigboy root]# chkconfig snmpd on

For Ubuntu / Debian it would be:
user@ubuntu:~$ sudo sysv-rc-conf snmpd on

4) Start SNMP to load the current configuration file.
[root@bigboy root]# service snmpd start
Starting snmpd: [ OK ]
[root@bigboy root]#

5) Test whether SNMP can read the system and interface MIBs using the snmpwalk command.
[root@bigboy snmp]# snmpwalk -v 1 -c nomnom localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux bigboy 2.4.18-14 #1 Wed Sep 4 11:57:57 EDT 2002 i586
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (425) 0:00:04.25
SNMPv2-MIB::sysContact.0 = STRING: root@localhost
SNMPv2-MIB::sysName.0 = STRING: bigboy
…
…
…
[root@bigboy snmp]# snmpwalk -v 1 -c nomnom localhost interface
IF-MIB::ifNumber.0 = INTEGER: 3
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: wlan0
IF-MIB::ifDescr.3 = STRING: eth0
…
…
…
[root@bigboy snmp]#

Now that you know SNMP is working correctly on your Linux server, you can configure SNMP statistics gathering software, such as MRTG, to create online graphs of your traffic flows.

thanks to bigboy

SBE 2010 – Backup SQL Cluster – SQL 2005

The solution to backing up a SQL Cluster remotely requires the following:

Remote Agents for each server in the cluster
SQL Agent for each server in the cluster

Install the remote agent on to each cluster node, and restart each node.
Configure a job for each cluster group presented by the cluster.

To illustrate this, let’s say we have 2 physical servers: SERVER1 and SERVER2.
Both SERVER1 and SERVER2 has got just one local drive letter to be backed up of C:.
These servers present 3 virtual nodes, each node being represented as Cluster Group within Cluster Administrator. Let’s call these three virtual nodes VIRTUALQUORUM, VIRTUALSQL1 and VIRTUALSQL2.

VIRTUALQUORUM has an assigned drive letter of Q:
VIRTUALSQL1 has an assigned drive letter of S: and a SQL Instance VIRTUALSQL1/SQL1
VIRTUALSQL2 has an assigned drive letter of T: and a SQL Instance VIRTUALSQL2/SQL2

To fully backup the cluster from a seperate server using backup exec, the jobs that will be required are:

SERVER1 Job
\\SERVER1\C$

SERVER2 Job
\\SERVER2\C$

VIRTUALQUORUM Job
\\VIRTUALQUORUM\Q$

VIRTUALSQL1 Job
\\VIRTUALSQL1\S$
VIRTUALSQL1/SQL1

VIRTUALSQL2 Job
\\VIRTUALSQL2\T$
VIRTUALSQL2/SQL2

VIRTUAL SQL Job
\\Virtual SQL Network Name
mdf & ldf

So long as these jobs are configured, the credentials provided have the right to backup the resources in the jobs and the server names (including virtual nodes) are resolvable by the backup server (as well as all usual caveates, such as access through firewalls etc), this will work, no matter where the virtual nodes are presented from.

Note:

-Make sure backup IP resource(if it’s different with production ip) is located in same cluster group with data resource to back up.
-create a new host record entry in DNS if backup IP is not associate with sql network name.