May 142012
 

The telnet service is never used these days as a means of accessing a host shell – it’s too insecure – but the telnet client is, for many sysadmins, still the tool of choice for testing whether a host has connectivity with another host network service. It’s a good reliable and general tool, and the syntax is dead simple. So for example, if you wanted to just test whether you could hit the Tomcat port (8080) on host “davros”, you’d:

   # telnet davros 8080

But telnet isn’t really the “right” tool for this job. By default it opens a TCP connection to a nominated port, but this flexible port argument is more of a side effect of its function as an interactive console, and not its real function. So from now on, you should be using netcat – which is executed as nc.

Netcat

Netcat is a Swiss army knife for network connections, and as well as being able to initiate outgoing calls to TCP and UDP ports, it can be made to function as a listener to read incoming connections. It can be used to construct a basic proxy. Most importantly, because netcat is non-interactive (unlike telnet) it can be easily used in scripts. The connection will be terminated gracefully, rather than left rudely cut off from the prompt with telnet’s “^]”.

Netcat is installed by default on several Linux distributions and is easily obtainable from the standard repositories on others.

Working Example

Here’s a few basic examples which show how it’s used to test network connectivity. Note that extent of the tests is just to check whether the port is listening, and not the nature of the daemon or whether it’s working. In every case, I’ll assume once again that our listening host is called “davros”.

Test that the Tomcat port (tcp/8080) is listening and accessible

   # nc -v davros 8080
Connection to davros 8080 port [tcp/http-alt] succeeded!

The man page has a lot of other good examples which are worth trying out. Netcat is a very versatile, yet very basic command, admirabl suited to creating TCP and UDP sockets.


Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.

May 082012
 

The primary use of iptables is as a host-based software firewall. It intercepts network traffic and applies filters to it, deciding what to permit, and what to deny. Iptables is very flexbile, but in its most common configuration it is used to simply filter incoming connections based on source, destination, protocol and port. In other functions, it is used to log traffic, filter outgoing connections, masquerade IP addresses for NAT and limit traffic rates. It is indispensable for maintaining the security of a server, but there’s other things its functions can be used for – simulating application failures.

It’s a relatively common testing scenario – you want to find out what happens when a service or resource becomes unavailable, and want to see how other applications handle this. For example, if your MySQL database goes down, what will Tomcat do? You could simulate this by shutting down the database, but if there are other nodes in the cluster, or other users accessing the database, this may not be possible.

A nice simple solution is to make an ad ad hoc addition to the iptables on the server that is noticing the failure. In the Tomcat/MySQL example, this will be a change to the application host running Tomcat. Since it’s attempting a connection to the MySQL database on port 3306, all that you need to do is configure iptables to block outgoing traffic with a destination port of 3306. Like this:

   # iptables -A OUTPUT -p tcp --dport 3306 -j DROP

Check that the iptables ruleset has been updated with:

   # iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:3306    <<====== This line here has been added

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 255 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 /* SSH */ 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80 /* http */ 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:8080 /* tomcat */ 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

This will have the effect of intercepting all outbound traffic heading to port 3306 on any destination host, and dropping it outright. The application will be unable to reach the database, although all other hosts will have no interruption of service.

One your testing is complete, you can undo the previous command by simply replacing the "-A" option ("append") with "-D" ("delete"):

   # iptables -D OUTPUT -p tcp --dport 3306 -j DROP

There are many other ways of using this technique. You could block a hosts ability to use DNS (UDP, port 53):

   # iptables -A OUTPUT -p udp --dport 53 -j DROP

Prevent a host from accessing Internet websites (HTTP, port 80 and 443):

   # iptables -A OUTPUT -p tcp --dport 80 -j DROP
   # iptables -A OUTPUT -p tcp --dport 443 -j DROP

Or block a host from reaching anything that isn't a private local address, by using the negation operator ("!"):

   # iptables -A OUTPUT -d ! 10.0.0.0/8 -j DROP

Which will look like this:

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0           !10.0.0.0/8   

This method could be use for testing monitoring, to force an automated cluster failover, or to eliminate extra traffic when tracing a bug.

The iptables command can be used as a powerful tool for exercising very fine-grained control over your host networking. A site-wide network catastrophe can effectively be locally simulated with one simple trouble-free command. Write it down.


Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.

Apr 172012
 

If using DHCP on Ubuntu to populate your network configuration, there can be times when customising the DNS information can seem a little difficult.

In my case, the DHCP server was supplying my desktop /etc/resolv.conf with the DNS information:

nameserver a.b.c.d
nameserver a.b.c.e
domain example.com
search example.com

This file gets auto-generated every time the NetworkManager restarts the interface, so there’s no point editing it by hand.

The problem was, I was mostly using servers in the subdomain “dev.example.com”, and wanted this added to the search list, so I didn’t have to type the “.dev” in every time. I’m lazy like that.

The fix is to edit /etc/dhcp/dhclient.conf, or /etc/dhcp3/dhclient.conf:

sudo vi /etc/dhcp/dhclient.conf

and add the following line:

append domain-search "dev.example.com";

Then, restart the dhclient process to update:

# pkill -HUP dhclient

The network interface will bounce, and when it comes back up, the extra domain-search “dev.example.com” will have been added to /etc/resolv.conf

To add extra domains to the search path, just add extra “append” lines.


Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.

Sep 182011
 

I had a development desktop fail and had to extract the data from the LVM managed hard drive. Easy, right? Pull out the drive, hook it up to an enclosure, plug into a laptop USB port and suck all the data down. And typically, it wasn’t that simple. The following error message appeared:

   # mount /dev/sdb1 /mnt
unknown filesystem type lvm2_member

Blast. Turns out, this disk has been part of an LVM volume group and the laptop didn’t know anything about this configuration. The solution, fortunately, is simple.

Install LVM, if it isn’t already:

   # apt-get install lvm2

List physical volumes, and their labelled volume groups:

   # pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/sdb1  VolGroup01 lvm2 a-   27.95g 22.95g

There’s a volume group, VolGroup01, which I do vaguely remember configuring. So, scan for this, make active, scan for logical volumes and mount. That’s it, like so:

   # vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup01" using metadata type lvm2

   # vgchange -a y VolGroup01
  1 logical volume(s) in volume group "VolGroup01" now active

   # lvscan
  ACTIVE            '/dev/VolGroup01/dataVol00' [5.00 GiB] inherit

   # mount /dev/VolGroup01/dataVol00 /mnt

And now the data on the stray disk is available, mounted under /mnt. Do with it what you will.


Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.