Installing and Configuring the DNS slave Server.

h3. Installing and Configuring the DNS slave Server.

We are using the chrooted environment for Bind. so that the base configuration path would be {code}/var/named/chroot/var/named{code}

For non glam dns we will build the caching name server.


h5. Install the required packages

{code}
# yum update -y
# yum install bind bind-utils -y
# yum install bind-chroot -y
#yum install caching-nameserver.x86_64


You should have following packages installed,

bind-chroot-9.3.6-20.P1.el5_8.5
bind-9.3.6-20.P1.el5_8.5
ypbind-1.19-12.el5_6.1
bind-utils-9.3.6-20.P1.el5_8.5
bind-libs-9.3.6-20.P1.el5_8.5
caching-nameserver-9.3.6-20.P1.el5_8.5


{code}

h5. Next step would be to create the named.conf file. Rather than  creating it from scratch, it would be much easier to copy it from any existing slave server.

So take backup of existing /etc/named.conf and scp the  named.conf file from existing slave server at location {code}/var/named/chroot/etc/named.conf{code}

And then create the softlink

{code}
# ls -l /etc/named.conf
lrwxrwxrwx 1 root root 32 Oct 17 00:50 /etc/named.conf -> /var/named/chroot/etc/named.conf

Verify the named configuration, using below command,

# named-checkconf ; echo $?
0

{code}


h5. Master server setup

On master you have to perform two major changes,

* Edit the named.conf and add the IP range of the new slave server in the acl "my_networks"


* Add the NS record of new slave server in every zone file, e.g.

{code}

;  This is a list of all of the named servers for this domain.   The first
;  is the primary (us) and the rest are our various secondaries
;
;  WARNING: cannot list as a nameserver any machine that forwards to mac

@                       IN      NS              tiber.tipsntraps.com
@                       IN      NS              slavetiber.tipsntraps.com


{code}

* Restart the named on both master and slave.

make sure you perform the configtest before restarting the named.


h5. how to perform the confitest

{code}


# named-checkconf ; echo $?
0

# /etc/init.d/named configtest
zone tipsntraps.com/IN: loaded serial 2013121908
{code}


h3. Make sure all the zone files are transferred in the newly configured slave properly, the zone defination files would be located at,

{code}/var/named/chroot/var/named/slaves/{code}

h3. Testing

Change the Serial of one of the zone file on master and do rndc reload , confirm that the change is propagated successfully on the new slave.



h3. Monitoring

We have DNS-Zone-CHECK monitoring in place on master server, which checks that all the zone files defined in master are also setup on the slave server. This monitoring also checks the Serial of every domain of slave server against the master server.

To enable this monitoring, add  the line in file {code}

/etc/check_mk/mrpe.cfg

Note- please pass the appropriate slave server name as second argument

### DNS zone check for rsukapp2
DNS-ZONE-CHECK-slavename /etc/nagios/scripts/check_dns_slave.sh  <master>  <slave>


{code}

once you have added this line in mrpe.cfg, take the re-inventory of the master dns server in check_mk and restart it.

DNS replication slow

Recently at work  I added two new DNS slave servers. We are using BIND 9 as a DNS server.

To my surprise I noticed that the the slave replication on these two boxes were extremely slow, infact after changing the SOA of the zone file it  was taking almost hours to replicate that to these slave boxes.

The other slave boxes were working perfectly fine.

I started digging into it.

/etc/named.conf on both the slaves was looking fine , in fact it was copied from the older running slave servers.

From master the telnet to port 53 was working.

There was no symptoms of any error in the log files.



The gotcha :

after much of debugging and goggling I found the gotcha, that none of the zone files on my master had declared these new slave servers as NS. so ... I added those entries chnaged the serial and restarted named on master. And issue resolved.

@                       IN      NS              tiber1.tipsntraps.com.
@                       IN      NS              tiber1.tipsntraps.com.


Conclusion :

After looking around I found that -

When the serial number is changed on the master, it will notify the slave immediately. In other words,notify is enabled by default. 

BUT, the way notify works is, the master looks at the NS records of that particular domain in the zone file, and notifies the servers listed in the NS record, excluding itself.

if your slave server's hostname is not  listed as an NS record in the zone file;  The slave will  contact the master, listed in the slave's config file - masters { X.X.X.X; }; at the defined Refresh interval.

 And that is why it is taking long time to update to the slave initially. 

YUM rollback in Centos 5 and 6

http://kernelmount.com/content/view/147/9/

Preserving the Environment variable for sudo

There is setting in the suodoers file , using which you can preserve the environment variable while using sudo.


Its called env_keep, see how  I have preserved the YUM0 variable for sudo access.

{code}

#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults    always_set_home

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults    env_keep += "YUM0"

{code}

how-to-install-oracle-java-7-update-45-on-ubuntu-12-10-linux

wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F" http://download.oracle.com/otn-pub/java/jdk/7u45-b18/jdk-7u45-linux-x64.tar.gz
tar -xvzf jdk-7u45-linux-x64.tar.gz  -C /usr/lib/jvm
cd /usr/lib/jvm
ls -ltr
update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.7.0_45/bin/javac" 1
update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.7.0_45/bin/java" 1
update-alternatives --set "javac" "/usr/lib/jvm/jdk1.7.0_45/bin/javac"
update-alternatives --set "java" "/usr/lib/jvm/jdk1.7.0_45/bin/java"
java -version
javac -version


Source :

http://hendrelouw73.wordpress.com/2013/10/16/how-to-install-oracle-java-7-update-45-on-ubuntu-12-10-linux/

Wget JDK

Download Oracle Java JRE & JDK using a script

Oracle has recently disallowed direct downloads of java from their servers (without going through the browser and agreeing to their terms, which you can look at here: http://www.oracle.com/technetwork/java/javase/terms/license/index.html). So, if you try:

wget "http://download.oracle.com/otn-pub/java/jdk/7u4-b20/jdk-7u4-linux-x64.tar.gz"

you will receive a page with "In order to download products from Oracle Technology Network you must agree to the OTN license terms" error message.

This can be rather troublesome for setting up servers with automated scripts.

Luckily, it seems that a single cookie is all that is needed to bypass this (you still have to agree to the terms to install):

Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F

So, if you want to download jdk7u4 for 64-bit Linux (e.g., Ubuntu) using wget, you can use:

wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F" "http://download.oracle.com/otn-pub/java/jdk/7u4-b20/jdk-7u4-linux-x64.tar.gz"

source : https://ivan-site.com/2012/05/download-oracle-java-jre-jdk-using-a-script/

Installing salt master and salt minion (agent) on CentOS 6

h3. Installing salt master and salt minion (agent) on CentOS 6

{color:#313131}Beginning with version 0.9.4, Salt has been available in{color}{color:#313131}&nbsp;{color}[EPEL|http://fedoraproject.org/wiki/EPEL]{color:#313131}. It is installable using yum. Salt should work properly with all mainstream derivatives of RHEL, including CentOS.{color}

Salt and all dependencies have been accepted into the yum repositories for EPEL5 and EPEL6. The latest salt version can be found in epel-testing, while an older but more tested version can be found in regular epel.

h5. Salt (master) dependencies:

* PyYAML
* libyaml
* m2crypto
* openpgm
* sshpass
* python-babel
* python-crypto
* python-jinja2
* python-msgpack
* python-zmq
* zeromq3


Now installing salt-master.

{code}
[root@tiber07vm2 ~]# yum install salt-master

[root@tiber07vm2 ~]# salt --version
salt 0.16.4
{code}

Install python pip to install python additional modules
{code}
[root@tiber07vm2 ~]# yum install python-setuptools

[root@tiber07vm2 ~]# easy_install pip
{code}

Upgrade salt which is supported version salt-ssh (first resolved the dependancies for it)
{code}
[root@tiber07vm2 ~]# pip install markupsafe

[root@tiber07vm2 ~]# pip install --upgrade salt

[root@tiber07vm2 ~]# salt --version
salt 0.17.1

[root@tiber07vm2 ~]# salt-ssh --version
salt-ssh 0.17.1
{code}


h5. Basically salt-stack comes with two environment

* Stack master (Server) \-> stack minion (Agent)

* Stack master (SSH) \-> Master connects to agent using ssh, so no additional salt agent is required.

h5. Managed Node Requirements


h5. 1) Salt (minion) dependencies:

On the managed nodes, you only need Python 2.4 or later,
* m2crypto
* openpgm
* python-babel
* python-crypto
* python-jinja2
* python-msgpack
* python-yaml&nbsp;&nbsp;
* python-zmq&nbsp;&nbsp;&nbsp;&nbsp;
* zeromq3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Now installing salt-minion.

{code}
[root@tiber07vm2 ~]# yum install salt-minion

[root@tiber07vm2 ~]# salt-minion --version
salt-minion 0.16.4
{code}

h5. Inventory of manged hosts:

Edit the /etc/salt/minion file on salt-minion server and add entry for salt-master server

{code}
[root@tiber07vm4 ~]# cat /etc/salt/minion
master: tiber07vm2.glam.colo
{code}

Start the master and minion services on salt master and client server
{code}
[root@tiber07vm2 ~]# /etc/init.d/salt-master start
Starting salt-master daemon:                               [  OK  ]

[root@tiber07vm2 ~]# /etc/init.d/salt-minion start
Starting salt-minion daemon:                               [  OK  ]

[root@tiber07vm4 ~]# /etc/init.d/salt-minion start
Starting salt-minion daemon:                               [  OK  ]
{code}

Check discovery for new minion and view the certificate requests on master:
{code}
[root@tiber07vm2 ~]# salt-key -L
Accepted Keys:
Unaccepted Keys:
tiber07vm2
tiber07vm4
Rejected Keys:
{code}

Looks perfect now\!\!

Accept the certificate requests on master:
{code}
[root@tiber07vm2 ~]# salt-key -A
The following keys are going to be accepted:
Unaccepted Keys:
tiber07vm2
tiber07vm4
Proceed? [n/Y] Y
Key for minion tiber07vm2 accepted.
Key for minion tiber07vm4 accepted.
{code}

Verify to see keys are accepted
{code}
[root@tiber07vm2 ~]# salt-key -L
Accepted Keys:
tiber07vm2
tiber07vm4
Unaccepted Keys:
Rejected Keys:
{code}


h5. Test the connection with the children:

Great you have done so far, now it is time to test


{code}
[root@tiber07vm2 ~]# salt 'tiber07vm4' test.ping
tiber07vm4:
    True

[root@tiber07vm2 ~]#  salt '*' test.ping
tiber07vm4:
    True
tiber07vm2:
    True
{code}


h5. 2) Salt (ssh) dependencies:

On the managed nodes, you only need Python 2.4 or later.



h5. SSH trust : since you want pass wordless authentication from your master machine ,its advisable to establish a trust

{code}
ssh-copy-id tiber07vm2

ssh-copy-id tiber07vm4
{code}

Inventory of manged hosts will be at /etc/salt/roster, this example configuration contains host without password (shared auth_key) and with password host entries.
{code}
[root@tiber07vm2 ~]# cat /etc/salt/roster
tiber07vm2:
  host: tiber07vm2
  user: root
tiber07vm4:
  host: tiber07vm4
  user: root
  passwd: myrootpassword
{code}

h5. Test the connection with the children:

Great you have done all, now it is time to test

{code}
[root@tiber07vm2 ~]# salt-ssh '*' test.ping
tiber07vm2:
    True
tiber07vm4:
    True
{code}

h5. Sample run :

{code}
[root@tiber07vm2 ~]# salt-ssh  'tiber07vm4'  -r  'uptime'
tiber07vm4:
     02:38:11 up 20 days, 14:16,  1 user,  load average: 0.09, 0.08, 0.02

[root@tiber07vm2 ~]# salt-ssh  '*'  -r  'uptime'
tiber07vm2:
     02:38:22 up 20 days, 14:16,  1 user,  load average: 0.08, 0.08, 0.02
tiber07vm4:
     02:38:23 up 20 days, 14:16,  1 user,  load average: 0.08, 0.08, 0.02
{code}


h5. Known Errors and fixes:

{code}[root@tiber07vm2 ~]# salt-ssh  'tiber07vm2'  -r  'uptime'
OSError: [Errno 38] Function not implemented
{code}

Ohh LXC\!\!, You will get python OSError because of not to write /dev/shm (tmpfs), so to enable it&nbsp; update your /dev/shm mount options (rw, noexec) and remount /dev/shm.


{code}
[root@tiber07vm2 ~]# cat /etc/fstab
/dev/root               /                       rootfs   defaults        0 0
none                    /dev/shm                tmpfs    rw,nosuid,nodev,noexec    0 0
#none                    /dev/shm                tmpfs    nosuid,nodev    0 0

[root@tiber07vm2 ~]# mount /dev/shm
{code}