Normalizing an Example

Normalizing an Example Table
These steps demonstrate the process of normalizing a fictitious student table.
Unnormalized table:

Student# Advisor Adv-Room Class1 Class2 Class3
1022 Jones 412 101-07 143-01 159-02
4123 Smith 216 201-01 211-02 214-01
First Normal Form: No Repeating Groups

Tables should have only two dimensions. Since one student has several classes, these classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above records are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at this problem is with a one-to-many relationship, do not put the one side and the many side in the same table. Instead, create another table in first normal form by eliminating the repeating group (Class#), as shown below:

Student# Advisor Adv-Room Class#
1022 Jones 412 101-07
1022 Jones 412 143-01
1022 Jones 412 159-02
4123 Smith 216 201-01
4123 Smith 216 211-02
4123 Smith 216 214-01
Second Normal Form: Eliminate Redundant Data

Note the multiple Class# values for each Student# value in the above table. Class# is not functionally dependent on Student# (primary key), so this relationship is not in second normal form.

The following two tables demonstrate second normal form:

Students:

Student# Advisor Adv-Room
1022 Jones 412
4123 Smith 216


Registration:

Student# Class#
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01
Third Normal Form: Eliminate Data Not Dependent On Key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on the Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table, as shown below:

Students:

Student# Advisor
1022 Jones
4123 Smith


Faculty:

Name Room Dept
Jones 412 42
Smith 216 42

Build a Samba file server

Samba is a Linux/UNIX software package that allows you to share files and directories with computers running other operating systems over the network. It also allows your Linux desktop or laptop to sign into a Windows network and be able to share files inside a workgroup. There are several advanced features that Samba comes with, such as domain controller. We will look at how to convert your Ubuntu box into a Samba file server and configure it to share directories with different combinations of permissions.

01 Prerequisites
When setting up a Linux file server, there are certain things that you will to have set up on your server before you start working on the Samba bit. The first thing you want to do is to set up the server with a static IP address, as opposed to one assigned dynamically by a DHCP server. Edit the file ‘/etc/network/interfaces’ with root user privileges and set the IP address manually. An example of the settings would be using something like the following:

auto eth1
iface eth1 inet static
address 192.168.1.3
gateway 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Using a static IP for any type of server makes good sense. Save the changes and restart the network with the command ‘# sudo /etc/init.d/networking restart’.

02 Installing Samba
Distributions such as Ubuntu have made the installation of just about anything so simple and straightforward with smart package management that you can have pretty much any software installed with a one-line command. To install Samba on your Ubuntu computer, execute the following:

# sudo apt-get update
# sudo apt-get install libcupsys2 samba samba-common

Here we are requesting Ubuntu to install three packages. The first one is to share your printer, the other two are Samba and its support packages.

03 Configuration file
The configuration files of Samba are stored in the ‘/etc/samba/’ directory. The first thing you should do before we dive into the configuration of Samba is to make a backup of the main configuration file.

# cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

Now open the file with your favourite text editor and let’s make some configuration changes:

# sudo vim /etc/samba/smb.conf

Can I register my nick on an IRC network?

Yes if the Network provides NickServ.

Basically, the way it works is, you register your nickname with a password and an email address. Now everytime you come back to the network, you will be asked to identify yourself using a simple command. This will make sure that you hold on to your nickname and nobody steals it on you.

The command to register usually is...

/msg nickserv register PASSWORD EMAIL

You must replace PASSWORD with a password of your choice and EMAIL with a VALID email address. It must be valid as some networks like you to verify it exists by sending you an email. Once you have registered your nick, when you come back to the network you must identify yourself, you can do this with these commands..

/msg nickserv identify PASSWORD

OR

/nickserv identify PASSWORD (should work, does on most networks)

Replace password with the password that you used to register your nick. Now all you have to do is NOT forget your password.

How to disable password prompts in Ubuntu

This tutorial will explain How to disable password prompts in Ubuntu

Note:- Disabling password prompts might be a security risk

Open the terminal window from Applications –> accessories –> terminal, run the command:

sudo visudo

Find the line that says

%admin ALL=(ALL) ALL

and change it to

%admin ALL=(ALL) NOPASSWD: ALL

Save and exit the file

Hide Menubar and StatusBar in Virtual Box

There is no option in VirtualBox to hide Menubar and Statusbar. Many people likes to hide them so that they can get maximum space in their guest OS. Virtual Box provides VBoxManage command. It can do all the things that VirtualBox GUI can do. Furthermore it can help us in getting rid of Menubar and Statusbar. Here is a nice example of other VBoxManage commands.

Now to disalbe/hide Menubar and Stautsbar open terminal and type:

VBoxManage setextradata global GUI/Customizations noMenuBar,noStatusBar


where guest_os_name is the name of the virtual machine. To see the name or UID you cau use:

VBoxManage list vms


After running the first command your VirtualBox guest window will have no Menubar or Statusbar.

Virtualbox Case Study: Making host only networking work between two Ubuntu Guest OS (virtual machine) on Windows Vista host

Preface

In the past articles, I have talked about how to make internal networking work between two virtual machines built using Virtualbox. In this article, we will see seeing a configuration of host only networking between two virtual machines built on virtualbox.

The advantages of configuring host only networking are :

1) Internet works (yes!)

2) You get an IP on the LAN for each virtual machine. Yes, this is really possible. So this means that you can have 2 more real LAN IPs coming out of a single windows desktop/laptop in the LAN. Isn’t that amazing?

3) Due to 2), your host machine can also ping or access your virtual machine

4) Each virtual machine can access the other virtual machine. E.g. ping/ssh/telnet into it.

For most purposes, this kind of setup should be optimal or sufficient. Hey, if you can access your machines in the LAN and internet works from them, that should be good enough. And, its for free.

Here is a bird’s eye overview of the end setup..

click here to enlarge this diagram

The Virtualbox Network Adapter configuration

We start with the Virtualbox Network Adapter configuration. We create a host only network interface on each virtual machine definition.

For Virtual machine1 – Gutsy:

For Virtual machine2 – gutsy2:

Please note here that while this article primarily deals with setting up host only networking, in the previous article, I had setup internal networking too, so these VMs also have a Virtual Host Interface 2 for internal networking within themselves.

Install the Guest Operating system on the virtual machines

Now, do the installation of the guest operating system in the virtual machine and setup the two network interfaces like this.

Note here that I chose static IP 192.168.0.5 because my windows machine (host OS) had the IP 192.168.0.3 and the IP had to be in the 192.168.0.x subnet. My windows host was behind a Netgear router.

We need to make sure we choose non-conflicting IPs for the host only interface otherwise you will get an IP conflict in your LAN domain. For the other machine, the eth0 static IP was 192.168.0.4.

An interesting fact here was that if I chose DHCP for eth0 in the VM, i was getting an IP of 192.168.0.3, the same as that of my windows host!! This is another reason why I had to choose static IP address.

For eth1, i chose a random IP in the subnet 192.168.2.x for no particular reason. The eth1 IP of the other virtual machine was 192.168.2.1

Make sure to restart the network after doing this network setup to bring it into effect.

Do not bother about the SIOCADDRT: No such process error:

gverma@gverma-laptop:~$ sudo /etc/init.d/networking restart
[sudo] password for gverma:
* Reconfiguring network interfaces...
SIOCADDRT: No such process
Failed to bring up eth1.
[ OK ]

For the benefit of the reader, the DNS and host information is also reproduced here, although the only thing of significance should be the DNS and default gateway, both of which were set to be the same as that on windows host:

This is how the network configuration on the other virtual machine looked like:

For those who are interested, here is the output of the route command:

gverma@gverma-laptop:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
default         192.168.0.1     0.0.0.0         UG    100    0        0 eth0

A quick side note for Windows Vista

Here is a quick side note for Vista or windows in general. It is preferable to disable the UAC (user access control) setting and also disable the firewall on the host windows machine.

Disable the User Access Control (UAC) feature on vista to make your life easier:

Network bridging: the key to make host only networking work

The KEY to make host only networking work on windows is to bridge the real working network interface (either wireless connection of a hard wired ethernet) with the virtual adapter network interface. You can do this by selecting two network interfaces, right click, choose bridge and voila, there you have it.

A network bridge is nothing but a simplified concept of joining two connections into one. Its like joining two rivers into a bigger river. When water will flow into the bigger river, it will flow into both the rivers. At least, this is how I understand it.

ALSO, we have to enable promiscuous packet routing mode in ALL the member network interfaces that are in the bridge. This is an important setup to make it work.

Initially, I had struggled a lot to make host only networking work by enabling promiscuous for only the Virtualbox Adapter in the bridge, but was not successful. That is when I read a cryptic posting on the Virtualbox forum saying that it has to be done for all the member bridge interfaces; and thats when it worked.

A note of caution

When we add an adapter to the bridge, the connection of the main wireless network is lost for a moment, but it is re-enabled back. This is also covered in the user manual in secion 6.3 (Virtualbox version 1.5.6)

Warning: Setting up Host Interface Networking requires changes to your
host’s network configuration, which will cause the host to lose its network
connection. Do not change network settings on remote or production systems
unless you know what you are doing.

Later on, I assigned Virtualbox Host Interface 2 (on windows) to NAT0 (eth0) of Virtual machine 2 and bridged it to the wireless network connection too:

After the bridging, this is how the ipconfig output looked like (the IP of the windows host is 192.168.0.3):

Now, we were one BIG, HAPPY Family. Make sure the connection status shows as connected.

Testing the connections – Internet works!

At this point, the internet was working from the virtual machines:

Another real quick check is to use the wget utility:

gverma@gverma-laptop:~$ wget yahoo.com
--18:32:56--  http://yahoo.com/
=> `index.html'
Resolving yahoo.com... 216.109.112.135, 66.94.234.13
Connecting to yahoo.com|216.109.112.135|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.yahoo.com/ [following]
--18:32:57--  http://www.yahoo.com/
=> `index.html'
Resolving www.yahoo.com... 69.147.114.210
Connecting to www.yahoo.com|69.147.114.210|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,490 (9.3K) [text/html]

100%[=====================================================>] 9,490         --.--K/s

18:32:57 (258.06 KB/s) - `index.html' saved [9490/9490]

Testing the connections – Host only networking

Now comes the acid test of whether the virtual machines and hosts can see each other.

Windows could see the individual virtual machines:

C:\Users\gaurav> ping 192.168.0.4
Pinging 192.168.0.4 with 32 bytes of data:

Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\gaurav> ping 192.168.0.5
Pinging 192.168.0.5 with 32 bytes of data:

Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging the windows host IP from inside the VMs worked beautifully:

And, pinging to the other virtual machine from each VM worked beautifully too:

Taking this a step further, since ssh was enabled on both the virtual machines, I was able to login to the individual virtual machines also:

gverma@gverma-laptop:~$ ps -ef | grep ssh
gverma    4684  4643  0 21:27 ?        00:00:00 /usr/bin/ssh-agent x-session-manager
root      5422     1  0 22:20 ?        00:00:00 /usr/sbin/sshd
gverma    5456  4864  0 22:23 pts/0    00:00:00 grep ssh
gverma@gverma-desktop:~$ ssh 192.168.0.5

gverma@192.168.0.5's password:
Linux gverma-desktop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Mon Apr 14 22:20:55 2008 from gverma-laptop.local
gverma@gverma-desktop:~$

gverma@gverma-desktop:~$ ssh 192.168.0.4
The authenticity of host '192.168.0.4 (192.168.0.4)' can't be established.
RSA key fingerprint is a8:29:91:97:7d:99:37:6e:31:f1:06:ec:04:39:78:d7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.4' (RSA) to the list of known hosts.

gverma@192.168.0.4's password:

Linux gverma-laptop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Private networks

To make things better, the private networks were working too (thanks to the good karma accumulated in the previous article – Case study: Configuring Internal networking work for talking two linux guest OS (Ubuntu) on windows vista host ) :

gverma@gverma-laptop:~$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.200 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.16 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.000 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.073 ms
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.000/0.358/1.160/0.468 ms

gverma@gverma-laptop:~$ ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=4.49 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=0.368 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=1.65 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=3.15 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=64 time=1.51 ms