Setting up DRBD for "mirroring" of static files

For this week, we were entitled to explore once again by ourselves in setting up, installing and configuring DRBD. The first step was to create a new partition, to do this I have look up in the internet that Gparted can do this task in ubuntu and I proceeded with doing it, I created a new partition using Gparted with 2.00Gb in size. 
Here is the screenshot of the creation of the said partition: 

**Note: Some prerequisites before configuring DRBD is to create two nodes, for the simulation of DRBD. 

For this, exercise what I picked as the file system was ext2, as said in the gparted tutorials indicated here: 

ext2 and ext3 filesystems are used for installing GNU/Linux and also for data. Since we will use DRBD to just "mirror" static files, I formatted it to the ext2 filesystem. 

The second step was Installing and Configuring DRBD :

Now that DRBD is installed, it need to be configured. 

To configure DRBD, the first step is to configure /etc/drbd.d/global_common.conf

This is an example of what the configuration file looks like, for this exercise, there is nothing to be configured here. 
The next step is to configure, /etc/drbd.d/<resource>.res For this example, we will use resource 0, so /etc/drbd.d/r0.res will be configured. 

this is the sample configuration for /etc/drbd.d/r0.res: 

this example, use two nodes: ics-user and useruser, static IP addresses are initially created and are stated above. 

Website screenshots: 

Login page: 

home page:

In today's session, we learned about the concept of heartbeat and how it is used to network systems and services. We were assigned to setup a High Availability Heartbeat. (HA-HB).

The steps are the following: 

1.) Step 1: Installing Heartbeat 

I have installed heartbeat by typing in the following command in a terminal:

$ sudo apt-get install heartbeat

The result are as follows: 

 

After installing heartbeat the next step is: 

2.) Step 2:   Configuration of the 3 files:

 - ha.cf

 - haresources

 - authkeys 

The first file that I configured was the ha.cf file, the following shows the contents of the ha.cf file:

The following lines have meaning and you can configure it according to what you prescribe.

Note:  node server1 is the first node, whilst the second node is named node server2

bcast eth0

Specifies to use a broadcast heartbeat over the eth0 interface.

keepalive 2

Sets the time between heartbeats to 2 seconds.

warntime 10

Time in seconds before issuing a “late heartbeat” warning in the logs.

deadtime 30

Node is pronounced dead after 30 seconds.

initdead 120

With some configurations, the network takes some time to start working after a reboot.   This is a separate “deadtime” to handle that case.  It should be at least twice the normal deadtime.

udpport 694

Use port number 694 for bcast or ucast communication. This is the default, and the official IANA registered port number.

auto_failback on

The master listed in the haresources file holds all the resources until a failover, at which time the slave takes over.  When auto_failback is set to on once the master comes back online, it will take everything back from the slave.  When set to off this option will prevent the master node from re-acquiring cluster resources after a failover.

node ics user

Mandatory.  Hostname of Primary machine in cluster.

node ics user

Mandatory.  Hostname of Secondary machine in cluster.

debugfile /var/log/ha-debug

This is used to specify the path where Heartbeat’s debug logs will be stored.

logfile /var/log/ha-log

This is used to specify the path where Heartbeat’s general logs will be stored.

[Reference: http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/ ] 

Since, other matters like deadtime, initdead, keepalive and warntime are not specified for us, I just used the default values for them. 

Configuring haresources file: 

The syntax are as follows: 

[node-name] [ip address]/[subnet]/[interface]

The first node, ics-user's haresources file looks like this:  

 You can configure this file, according to the preferences enlisted above. 

Configuring authkeys: 

After the configuration of the two files, the last file to be configured is authkeys. 

To begin configuring authkeys, you must first be in the root for you to be permitted to edit the authkeys file. You could do this simply by typing in the command: 

sudo -s

cd etc/ha.d

vi authkeys

 These set of commands will let you edit the authkeys file, basically it just contains two lines which are as follows: 

 auth 1 --> 1 is the authentication method ID. 

1 sha1 <password> none --> sha1 is the authentication method used, other methods include mdb5, and crc.  none is the password that is set for authentication. 

 Note: If your heartbeat runs over a secure network, such as the crossover cable in our example, you’ll want to use crc.  This is the cheapest method from a resources perspective.  If the network is insecure, but you’re either not very paranoid or concerned about minimizing CPU resources, use md5.  Finally, if you want the best authentication without regard for CPU resources, use sha1.  It’s the hardest to crack.

Determining the hosts of server 1 and server2: 

4.) Step 4: Starting heartbeat services: 

You could do this by typing in the following command: 

$ /etc/init.d/heartbeat start

$ /etc/init.d/heartbeat stop

$ /etc/init.d/heartbeat restart  

 These other commands can also be used to stop or restart heartbeat services.

5.) Step 5: Testing Heartbeat

After Heartbeat services are running on both machines, both the machines will monitor to each other.

To test if the services are actually working, we did the following test runs:

Primary machine  and secondary machine are allowed to run their heartbeat services for a while.

A third machine (having an IP in the same range and same subnet mask) is made to ping the IP address of Primary machine. After a while, the Primary machine is physically isolated from the given network. (We did this by pulling off the Ethernet cord). As soon as the Primary machine is taken out, the ping windows displays ‘Request timed out..’ in reply to its requests.

After a given interval of time (defined by warntime, deadtime, initdead) the ping window starts getting replies from the Primary machine’s IP again. What actually happened was, in the time interval, the Secondary machine got to know that its Primary machine is not sending heartbeats and therefore concludes that Primary is down. So the secondary acquires the resources of the Primary and starts serving any requests to the Primary’s IP.

Note: If it weren’t for Heartbeat, the ping window would have shown ‘Destination Host Unreachable’ when the primary was taken off.

[Reference: http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/ ] 

Server 1 Accessing Server 2's webpage: 

Server 2 Accessing Server 1's webpage: 

Since this result, we confirmed that the heartbeat services made it possible for the both servers accessing one another. 

Additional Blog entries: 
1. What are the problems encountered?

Problems encountered: Installing and setting up heartbeat without any knowledge of it at all, The only resource was the Internet and inability to understand the steps provided and how they work became a problem too while configuring the files for heartbeat. For the first two weeks, we were unguided and we didn't know what to do. We didn't know if what we're doing is right or wrong therefore we haven't accomplished the exercise well. When we were given instructions to do what it is to do, things became quite clear for us and has manage to somehow make it work. 


2. What are your insights about HA-HB?
HA-HB is a practical tool for web services that needs to have a 24/7 service. With HA-HB, Even though the primary server is down and couldn't reply to the request of the client, a secondary server can easily reply to that request while listening to the primary server's "heartbeat" 


3. State your ideas about the (possible) real world application of HA-HB? (Specific)

For web servers that wants to continue services even though the primary server is down. A secondary server or back-up server is needed for seamlessly requesting web services. Example of the real-world application that can use this or is already using this would be: UPLB's SystemOne, UP Diliman's CRS and the likes. Since during registration time, the servers would be up and running, it is better to have a back up or secondary server and an HA-HB service. This will guarantee developers and users to a seamless connection between clients and servers. which is crucial especially in registration time. 

4. What can you say about the mode of "discussion", allowing yourself to discover firsthand the configuration for HA-HB? 

Although I do understand that this mode of discussion will let the instructors gauge as to how independent we are in terms of learning new things on our own, It is still quite an issue for us since we cannot fully grasp the meaning of the things we are doing. We may have successfully done what it is to be done in a certain exercise but most parts of it, we cannot understand how it happened. I still prefer an in-depth discussion on each exercise and how things should be done properly. The mode of discussion that is most preferable for me is that the instructor will give us steps on how to do it properly, and we will follow. As we follow, we will discover things we cannot understand. And then, the instructor will interrupt us and discuss the matter comprehensively. it would be much fun also if the activity would be done by partners, groups or as a class and all of us would give out our opinions on the subject matter. For me, It is difficult to understand the topic when we are left by ourselves. There are different interpretations and ways of installations and configurations in the Internet and it's quite hard for us to determine what was really the right configuration to be done. Nonetheless, I still learn by myself; but I do hope that this topic would further be explained by our Instructor or Lecturer. 

References: 

http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/

In today's exercise, we learned and reviewed about router configuration and DHCP. The main goal of the exercise is to share the internet connection from a PC that has established connection to the internet, (making it a router for another PC with no internet connection) with another PC that doesn't have an established connection to the internet.

In order to do this, we first prepared and configured Computer B (the computer connected to a wired connection) We first check the ifconfig settings, and assigned a static IP address to the interface connected to Computer A, which is wlan0. (Since, the connection of Computer A to Computer B is wireless) as you can see in this image below: 

We also checked if IP Forwarding is enabled by the use of the command: 

#cat /proc/sys/net/ipv4/ip_forward

and as you can see in the image, it returned "1" meaning, IP Forwarding is enabled. We then set the appropriate firewalls settings for computer B, as shown in this image: 

 

We then check if Computer B is still connected to the internet by doing a ping to www.google.com and then we checked the contents of the file /etc/resolv.conf and copied it to computer A's /etc/resolv.conf. 

 

 We then proceed with configuring Computer A 

 

We assigned a static IP address to the interface connected to Computer B and then we set the IP address of computer B as a default gateway by typing the commands: 

#route add default gw 192.168.18.254

#route -n

We then tried to ping computer B using computer A: 

 and also tried to ping a website, www.google.com to check if Computer A has an internet connection already and successfully this is the result: 

 

This is somewhat a confirmation that Computer A has accessed to the internet through Computer B. 

B. Using DHCP Servers: (Another way of doing the process of letting another computer connect to the internet by the means of wireless connection with another computer that has wired connection to the internet)

1. We first installed  the DHCP server and did the following steps: 

We then created the configuration file /etc/dhcp3/dhcpd.conf  

to automate  the configuration for Computer A.

 

The file looks like this.

we set the range to 192.168.18.166 until 192.168.18.170, these are the set of IP addresses that the DHCP server will lease to computers wanting to connect to it. We then set the option router by the IP address of 192.168.18.1. Specifically, we just configured the lines 38 -40. Then after that we run the server by typing in the command: 

#/etc/init.d/dhcp3-server/ restart

As shown in the image below:  

 

Then in Computer A, we run the dhclient command to request for a host configuration information on to the server.

#dhclient wlan0

wlan0 is the interface connected to computer b. 

In order for us to see if Computer A had a hold of the IP address from the DHCP server, we viewed the leases file in Computer B to see what IP address was lease upon to Computer A and it showed us this results:

 

As shown here, Computer A successfully grab a hold of an IP Address made to be lease from the DHCP server. 

After confirming that Computer A is connected to Computer B by the use of DHCP server we proceeded with the cleanup.

We stopped the DHCP server and remove the configuration file: /etc/dhcpd.conf

as shown in the image above. 

As a whole, the process was tedious and required a lot of amount of time, effort and patience. Some of the aspects of the exercise was also quite confusing but it gave us a learning towards making a certain computer to be a router to another computer. 

Questions: 

1. Using the man pages for iptables, briefly explain what was done in step 5 in configuring
Computer B. Describe the parameters used in the iptables command.

Answer: 

- iptables -F -- flushes the selected chain, (or all the tables in the chain if there is nothing selected). similarly, it also deletes the rule one by one. 

- iptables -P INPUT ACCEPT -- sets policy for the chain to the given target. 
- iptables -P OUTPUT ACCEPT -- sets policy for the chain to the given target. 

- iptables -P FORWARD ACCEPT --  sets policy for the chain to the given target.  

- iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE --  specifies the packet matching table in which the following commands should operate on, in this case it's nat. -A then appends a rule to the selected chain. In this case, the rule is POSTROUTING. -o followed by ethY (name of the interface) this part of the command sets the name of the interface (eth0) via which a packet is going to be sent. -j MASQUERADE specifies the target of the rule or what it does if the packet matches it. In this case, MASQUERADE is the target of the rule.

2. What are the options you used in /etc/dhcpd.conf?

Answer: the options that we used are the IP addresses of computer A and computer B.
3. How do you assign a fixed IP address to a computer?What information do you need?
Answer: We just need the subnet, gateway and subnet mask.

On today's exercise, we learned how to configure DNS(Domain Name System) servers. The Domain Name System acts like an internet directory service wherein the IP address is connected to its appropriate domain name. So whenever we look up a website, we access them by typing its domain names rather than their real IP addresses. 

In order for us to simulate how the domain name system works we followed some steps and along the way we learned the process and mechanism of the DNS. 

We start off with entering this commands to the terminal (linux box) : 

     $sudo -s
     #apt-get install bind9
     #cd /etc/bind
     #ls

BIND9 is a version of BIND which means the Berkeley Internet  Name Domain. BIND is an implementation of the protocols in DNS. It provides an open-source redistributable reference implementation of the major components of a DNS which includes a Domain Name System Server, Domain Name System Resolver library,
and tools for managing and verifying of the proper operation of the DNS server (Reference: www.bind9.net)

After that, we begin with configuring the active interface with a static IP address that is 192.168.3.X, where X is our seat number in the lab using the command ifconfig:

   ifconfig eth0 192.168.3.13 netmask 255.255.255.0 broadcast 192.168.3.255

After we have done that, we proceeded with configuring /etc/bind/named.conf.local with the appropriate domain name, filename of forward and reverse zone files. For the class, we used cmscwantriseben.com as our domain name. 

Using VI (a text editor inside the terminal commonly used for programmers), the  /etc/bind/named.conf.local was configured with its appropriate parameters. 

Afterwards, we proceed with getting the IP addresses, forward and reverse zone files of our other classmates. As you can see here in this image their domain names and IP addresses are like added to the "directory" of computer networks that you can connect and "ping" to afterwards. 

And then, we entered the reverse zone files of our classmates domain names.

After we have done this we proceed with checking the configuration files if there are errors or not. At first, I have gained too many errors but resolved it with the use of the following commands: named-checkconf, named-checkzone

named-checkconf is a named configuration file syntax checking tool or simply checking the syntax of the configuration files. 

**named, is used on the vast majority of name serving machines on the Internet, providing a robust and stable architecture on top of which an organization's naming architecture can be built.(Reference: www.bind9.net)

named-checkzone is a zone file validity checking tool or converting tool. 

At first the result after I entered named-checkconf there were errors but I resolved it and after that, it didn't produce any results meaning there were no more errors. like here:

After this, we proceed with starting the server using the command /etc/init.d/bind9 restart

I really don't know the details of this command but I think it starts the DNS server we had been configured earlier. You can see it here in this image:

And then we need to specify the DNS server that will be used by the resolver by editing the file, /etc/resolv.conf resolv.conf is as follows: 

The edited version of /etc/resolv.conf goes like this:

After that we proceed with dig. DIG  is a DNS lookup utility, it looks whether the domain name you entered exists and it is also used for querying DNS servers with different queries. 

This is how I DIG my classmates' DNS: 

After this process I began testing the domain names of myself and my classmates by the means of ping. 
ping is sending ICMP ECHO_REQUEST to network hosts (the local computers of my classmates are the other hosts in the network) 

This is when i "pinged" myself

and my other classmates as follows:

After this we proceed with the cleanup by entering the following commands:

removing entries in /etc/bind/named.conf.local using vi

rm /etc/bind/<forward zone file>

rm /etc/bind/<reverse zone file>

removing entries in /etc/resolv.conf using vi

#history -c

And after all of this, the exercise is already done. I have experienced and learned how the domain name system works and how to connect with other domain names. Because of this, I had understood better how we access websites in the internet. It gave me a better understanding on it. At first, I thought that I would fail doing the exercise and fail with the goals to meet at the end of the exercise but luckily, I have finished well and understood most of the aspects of a domain name system. 

Exercise 2

In this week's exercise we learn the basics of TCP/IP networking, IP Routing and forwarding IP Packets from one network to another. 

This is how we basically put up a network in a network simulator.

In our exercise we created 3 computers connected in different networks and must able to access or communicate with one another. Here is the diagram of the 3 locally connected computers accessing one another: 

After setting the networks, hosts, routers and the switch we proceed with configuring each host to each of its routers. And after that we proceed with the configuration of each router, using its console which looks like this: 

We configured the router and created an IP route for each router(of other host computers)  to be able to communicate with one another. 

The IP Route for Router 1 is: 

The IP Route for Router 2 is: 

The IP Route for Router 3 is:

After setting it up for each routers we proceed with communicating with each host to another by the means of ping. The ping for host 1 to host 2 and 3 looks like this: 

The ping of host 2 to host 1 and 3 looks like this: 

And lastly, the ping of host 3 to hosts 1 and 2 looks like this: 

After we tried to ping one host to the other hosts, it showed that there's 0% loss of packets sent, it only means that the connection is correct and we have sent IP Packets to one another which was the main goal of the discussion and exercise. Having fulfilled to that, I was amazed by how networks are created and how packets are sent to each of the hosts. As to how I configured the routers to communicate with another, I connected them to one switch and added in the routing table the IP address of the other hosts by putting in:

ip route 192.26.2.0 255.255.255.0 192.26.0.2

ip route 192.26.1.0 255.255.255.0 192.26.0.1

(this example is from host 3) 

It was a great experience, although I have tried a lot of times in configuring the router. At this point, I have gain some knowledge about networking and I firmly believe that we will learn more about networking on the other exercises. 

I still want to learn more about networking and data communications next time.