Enlarge Linux Partition to sizes Larger Than 2TB

If you have partitioned a disk using ‘fdisk’, most probably the partition table is using ‘MBR‘. Nowadays, one important disadvantage of MBR is the lack of supporting larger than 2 TB partitions. So, if you want to extend a partition while disk is using MBR, first the disk partition table needs to be converted to ‘GPT‘. To find difference between MBR and GPT see here as well.

Generally, to resize a partition, it needs to be deleted and re-created using new size or end sector. A good general approach to enlarge a partition while not losing data is explained in this link. You can follow this how-to with a slight but important difference: instead of using ‘fdisk’, ‘gptdisk’ or ‘gdisk’ should be used. ‘gdisk’ supports GPT and if you use the existing specifications (first sector) for new partition, there would be no data loss. When doing conversion, a warning will be triggered:

THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format!

But it’s okay! Don’t worry and continue. Then, it will ask for partition type, because the current partition type is based on MBR partition table. You can choose ‘ef00’ which is ‘EFI System’. Go ahead and create the new partition with new size, save the partition table and you are done. Then ‘resize2fs’ can be used to enlarge volume.

p.s – instead of enlarging partition, another choice (rather than MBR to GPT) is using LVM to create large logical volumes containing multiple physical volumes.

Advertisements

IP LAYER MONITORING IN VMWARE VSPHERE – 2

2 posts earlier, I talked about NetFlow in VMware 5.x and how to enable it in vSphere dvSwitch. I have also shown how you can send IP traffic flow information to a NetFlow collector. Nowadays, there are lots of commercial NetFlow collectors available; however, in this post I will introduce a simple, open-source NetFlow collector which you can use in your VMware environment to analyze IP traffic. This pretty piece of software is: ‘nfdump

As it’s shown, Nfdump has 2 major elements: ‘nfcapd‘ which is a daemon to gather and store relevant packets and ‘nfdump‘ which collects packets from all the daemons and interprets them. Apparently, nfcapd and nfdump could run on different machines and there could be multiple daemons but in case of VMware vSphere, it depends solely on the number of dvSwitches. If there is only one distributed switch, all the IP traffic flow information from all portgroups in that dvSwitch will be forwarded to one nfcapd. For test purposes, I also deployed both nfdump and nfcapd on a single linux machine but in cases that traffic is high, it maybe a good idea to deploy them on two different machines. Of course nfdump should have access to the storage in that case.

After installation, first you need to run daemon and specify a port and directory to store ip traffic information. Apparently, nfcapd will store information in binary. The command is simple, something like this:

  • nfcapd -w -D -l /var/netflow/dvswitch -p 23456

Then, daemon will run and listen to the specified port: 23456. If you have configured dvSwitch correctly (by specifying ip address of linux machine and 23456 as port) and activated monitoring on some portgroups in vCenter, this daemon will generate a couple of files in that directory.
Now, whenever you want to view the captured ip traffic flows, you should run nfdump. Since there are lots of files in that directory, you can interpret the whole directory using -R option with this command:

  • nfdump -R /var/netflow/dvswitch/

Filtering in nfdump is also possible, pretty much the same as tcpdump and you can view traffics of interest. You can find more information on nfdump website.

To view NetFlow captured traffic visually, you can mix nfsen with nfdump. It uses information that is dumped by daemon and utilizing rrdtool, it visualizes traffic flow. Installation is not difficult and you can see more information on their website. I’m really satisfied by this beautiful combination of nfdump and nfsen and if you intend to use NetFlow for monitoring, I recommend trying them. Good Luck!

tcpkill to Kill a TCP connection!

I recently found a very useful command in Linux named ‘tcpkill’. Actually, the other day I was trying to find a way to kill a tcp connection between my server and a client. Not that it was an attack or needed firewall rule, but simply I wanted it to be killed in order to let the upper layer application to re-establish connection. There was no utility in the upper layer application to do this and it handed TCP connection management over to OS (TCP KEEPALIVE in linux kernel). So, I started looking for the solution to kill the connection.
So, the solution was easy, just issue ‘tcpkill’ command with appropriate parameters. Parameters are compliant with ‘tcpdump’ filter formats. So, if you are familiar with ‘tcpdump’ you will find it easy. For more explanation, examples see the amazing cyberciti website.

Simple SMTP Relay in Cloud

In a cloud environment, there are many cases that a send-only mail server (smtp relay) would be required. Apart from cloud, in other applications like monitoring systems (to send alerts, cron reports, …) having a mail relay is beneficial. Exim (exim4) in Linux systems is a simple, good and safe candidate.

Well, if you want to have exim4 in your cloud, first install a VM with light-weight linux system in your Infrastructure cluster. I’m writing this short guide considering Debian/Ubuntu as linux VM. And then most probably, you would like to connect this VM to management network. The rest is easy, here comes the required steps:

1) Install lightweight exim4. Exim4 by itself is simple but exim4-daemon-light is a very basic mail server with all our required features, lacking advanced, unnecessary (in this case) features like LDAP, MySQL authentication.

  • apt-get install exim4-daemon-light

2) Edit configuration file, by default is /etc/exim4/update-exim4.conf

  • 2-1) change dc_local_interfaces variable to add IP address of the NIC attached to your management network. By default, exim allows only local machine (loopback address, 127.0.0.1) to send email. You should add management IP address to be able to listen to other machines in management networks.  Example:
    dc_local_interfaces = ‘127.0.0.1 ; 192.168.50.150’

  • 2-2) change dc_relay_nets variable to restrict the machines which are capable of sending email through this mail relay server. Apparently, this should be the network address of your management network. By default, it is empty that increases the risk of being used by other unknown machines but you like to enable only machines in management network to use this mail relay server. Example:
    dc_relay_nets = ‘192.168.50.0/24’
  • 2-3) change dc_relay_domains parameter to increase security. Maybe you want to restrict the domains of recipients; because this mail relay server is being used for internal purposes (sending alerts, cron reports, …) your recipients are known and most probably they will use your organization email. It’s a good idea to restrict recipients to increase security. so, let’s do this:
    dc_relay_domains = ‘example.com’

3) restart exim service:

  • /etc/init.d/exim4 restart

That’s it. Enjoy your relay server.