The ethernet shield adds IP communication, acting as a client or as a server. The most well-known protocols are supported right out of the box, including TCP, UDP and ICMP. Several enthousiasts have added support for even more protocols, such as DHCP and NTP.

Creating programs for the Arduino with the ethernet shield is simple:

#include 

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 10, 0, 0, 177 };
byte server[] = { 64, 233, 187, 99 }; // Google

Client client(server, 80);

void setup()
{
   Ethernet.begin(mac, ip);
   Serial.begin(9600);

   delay(1000);

   Serial.println("connecting...");

   if (client.connect()) {
      Serial.println("connected");
      client.println("GET /search?q=arduino HTTP/1.0");
      client.println();
   } else {
      Serial.println("connection failed");
   }
}

void loop()
{
   if (client.available()) {
      char c = client.read();
      Serial.print(c);
   }

   if (!client.connected()) {
      Serial.println();
      Serial.println("disconnecting.");
      client.stop();
      for(;;)
         ;
   }
}

Every Arduino program has at least two parts: a setup() function and a loop() function. The Arduino IDE creates an actual proper C program around these two functions before it uploads the complete program to the Arduino.

The Arduino IDE contains a serial monitor, which allows you to send strings to the Arduino program or receive strings from it. The example program above shows how the Serial class works. In the setup() function, the serial communication is started at 9600 baud. In the loop() function, data is sent over the serial line with the method Serial.print(). If the serial line is actually connected, the program on the Arduino will halt until the serial monitor is opened. If the serial line is not connected, e.g. when you are done debugging, the program will run normally.

The ethernet library contains the Ethernet class. In the setup() function, the ethernet stack is started with Ethernet.begin(mac, ip). The mac and ip parameters are both byte arrays. If only these two parameters are present and the IP address has the form a.b.c.d, the gateway is assumed to be a.b.c.1 and the subnetmask is assumed to be 255.255.255.0. There are other constructors that take one or two extra parameters for people with different network setups.

After ethernet initialization, the class Client is used to create a TCP connection to the supplied server IP address and port number. The Client.connect() method tries to connect to the server and a call to Client.println() sends data over the TCP connection to the server. The Client.available() method tells if the server has sent data over the TCP connection to our client. If it has, a call to Client.read() gives these bytes.

There is a problem with the public IP addresses Hetzner gives you. Within the Hetzner network, there is a hard connection between the MAC address of your machine and the IP addresses you have been given. This is a problem for virtual machines that are bridged onto the network by the host machine. These virtual machines have their own MAC address and the Hetzner network will drop packets from these unknown MAC addresses.

There is a solution to this problem: have the host machine route IP packets from the virtual machines to the network and vice versa. We will use the following addresses in the example below:

We start with the configuration of the host machine (running XenServer). The first file is the configuration file of eth0: /etc/sysconfig/network-scripts/ifcfg-eth0

XEMANAGED=yes
DEVICE=eth0
ONBOOT=no
TYPE=Ethernet
HWADDR=40:61:86:be:ce:88 (replace with MAC address of host)
BRIDGE=xenbr0

Notice that this file does not contain any IP configuration. The second file is the configuration file of xenbr0: /etc/sysconfig/network-scripts/ifcfg-xenbr0

XEMANAGED=yes
DEVICE=xenbr0
ONBOOT=no
TYPE=Bridge
DELAY=0
STP=off
PIFDEV=eth0
BOOTPROTO=none
IPADDR=188.40.109.204 (replace with IP address of host)
NETMASK=255.255.255.192
GATEWAY=188.40.109.193 (replace with gateway of host)
DNS1=213.133.100.100
DNS2=213.133.99.99
DNS3=213.133.98.98

Now we need to enable IP forwarding on the host machine. We start with the sysctl configuration file: /etc/sysctl.conf

net.ipv4.ip_forward=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.lo.send_redirects=0
net.ipv4.conf.xenbr0.send_redirects=0

The first line tells the machine to perform IP forwarding. The four lines after that tell the machine to disable sending ICMP redirects. The last file we need to edit is the firewall configuration file: /etc/sysconfig/iptables. Add this text below the line -A RH-Firewall-1-INPUT -i lo -j ACCEPT:

-A RH-Firewall-1-INPUT -i xenbr0 -o xenbr0 -j ACCEPT

Now reboot the machine and continue with the IP configuration of the virtual machine running on XenServer. There is only one file we need to edit here, which is the configuration file of eth0: /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
HWADDR=8e:35:1e:3b:12:aa (replace with MAC address of VM)
IPADDR=188.40.109.250 (replace with IP address of VM)
NETMASK=255.255.255.192
GATEWAY=188.40.109.204 (replace with IP address of host)

The gateway in this configuration is crucial: it needs to be the IP address of the host itself, not the gateway of the host.

To enable SSL in Apache, we need to perform some steps.

We start by generating a key for our server:

openssl genrsa -out server.key 4096

Then we generate a Certificate Signing Request (CSR) based on this key:

openssl req -new -key server.key -out server.csr

Make sure that you enter a valid value for Common Name (CN). It is vital that you enter the Fully Qualified Domain Name (FQDN) or IP address of your server here.

If we want a legitimate SSL certificate for Apache, we need to take this file to a Certificate Authority (CA) and have them generate a certificate. However, if you want a certificate to play around with, it is enough to sign it yourself:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

In either case, we can now continue to create an SSL directory for Apache:

mkdir /etc/apache2/ssl

Move the necessary files to this directory:

mv server.key /etc/apache2/ssl
mv server.crt /etc/apache2/ssl

Now tell Apache to use SSL and these brand new files by editing /etc/apache2/sites-enabled/000-default:

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

And now start Apache:

/etc/init.d/apache2 start

Check if it works by connecting to https://yourservername. If you use a self-signed certificate, your browser will warn you that, although the connection is encrypted, it is a self-signed certificate and you shouldn’t trust the website.

Some companies and ISP’s do not allow you to send mail from your machine directly, but force you to use their smarthost. In the Postfix SMTP server we can accomplish this by editing the file /etc/postfix/main.cf:

relayhost = smarthost.example.org

We also have to tell Postfix to which domains it may send mail. We do this by adding:

relay_domains = example.org

These two lines together allow your Postfix installation to send mail to everybody@example.org through the smarthost smarthost.example.org.

In this article we will install the Ganglia monitoring system on a set of machines running CentOS. There are two kinds of machines involved:

• The meta node: one machine that receives all measurements and presents it to a client through a website.
• The monitoring nodes: machines that run only the monitoring daemon and send the measurements to the meta node.

Meta node

For this example we assume the meta node has the IP address 192.168.1.253. We start by installing the necessary software:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
yum install rrdtool ganglia ganglia-gmetad ganglia-gmond ganglia-web httpd php apr apr-util

If you want to monitor the meta node as well as the monitoring nodes, edit the gmond configuration file /etc/gmond.conf:

cluster {
  name = "cluster1"
  owner = "owner1"
  latlong = "unspecified"
  url = "unspecified"
}

udp_send_channel {
  host = 192.168.1.253
  port = 8649
  ttl = 1
}

udp_recv_channel {
  port = 8649
}

Start the gmond service and make sure it starts at boot:

chkconfig gmond on
service gmond start

Edit the gmetad configuration file /etc/gmetad.conf:

data_source "my cluster" 192.168.1.253:8649

Start the gmetad service and make sure it starts at boot:

chkconfig gmetad on
service gmetad start

Enable the http daemon, to be able to see the pretty monitoring pictures:

chkconfig httpd on
service httpd start

Monitoring nodes

On all the monitoring nodes start by installing the necessary software:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
yum install ganglia-gmond

Edit the gmond configuration file /etc/gmond.conf. You can use an exact replica of the gmond configuration file shown for the meta node.
Start the gmond service and make sure it starts at boot:

chkconfig gmond on
service gmond start

If you would like to emit your own measurements (called metrics in Ganglia) and view them on the website, call the gmetric program:

gmetric --name mymetricname --value mymetricvalue --type string

To use the output of a program you wrote as a metric, simply call it like this, making sure to use backticks (`) instead of quotes (‘):

gmetric --name mymetricname --value `/home/user/mymetricprogram` --type string

Static IP address

Assigning a static IP address on OpenSolaris is accomplished by editing the hostname files in the directory /etc. For example, assign a static IP address to interface bge0 by editing /etc/hostname.bge0:

192.168.0.123

Set the netmask by editing the file /etc/inet/netmasks:

192.168.0.0 255.255.255.0

Set the default gateway by editing the file /etc/defaultrouter:

192.168.0.1

Network interface bonding

In this example, 10.0.0.1 is the interface of the bond, 10.0.0.2 and 10.0.0.3 are test addresses. Start by editing /etc/hostname.e1000g0:

10.0.0.2 netmask + broadcast + group production
deprecated addif 10.0.0.1 netmask + broadcast + failover up

Then edit /etc/hostname.e1000g1:

10.0.0.3 netmask + broadcast + group production
deprecated + failover standby up

Static IP address

Assigning a static IP address on CentOS is accomplished by editing the files in the directory /etc/sysconfig/network-scripts. For example, assign a static IP address to interface eth0 by editing /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=none
IPADDR=192.168.0.123
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
ONBOOT=yes

Network interface bonding

To achieve higher bandwidth and/or reliability, network interfaces can be bonded. First, edit the file /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
BOOTPROTO=none
IPADDR=10.0.0.1
NETMASK=255.255.255.0
ONBOOT=yes

After that, you need to edit the network interfaces that are part of this bond, e.g. eth1 and eth2. Let’s start with /etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE=eth1
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
ONBOOT=yes

Then edit /etc/sysconfig/network-scripts/ifcfg-eth2:

DEVICE=eth2
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
ONBOOT=yes

The last file to edit is /etc/modprobe.conf:

alias bond0 bonding
options bond0 mode=active-backup miimon=100

The mode value in this last file can be one of several:

• balance-rr
• active-backup
• balance-xor
• 802.3ad
• balance-tlb
• balance-alb

In the active-backup mode shown in the example, only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond’s MAC address is externally visible on only one port (network interface) to avoid confusing the switch.

The option miimon (media-independent interface monitoring) defines how often, in milliseconds, link monitoring occurs.

Here are the steps to take to enable the Network Time Protocol (NTP) daemon on CentOS. Change the timeserver value to one that is close to you.

yum install system-config-date
ntpdate nl.pool.ntp.org
service ntpd start
chkconfig ntpd on

Samba is a file and print server for Windows-based clients using TCP/IP as the underlying transport protocol. In fact, it can support any SMB/CIFS-enabled client. One of Samba’s big strengths is that you can use it to blend your mix of Windows and Unix machines together without requiring a separate Windows NT/2000/2003 Server.

On OpenBSD, the Samba configuration file is /etc/samba/smb.conf. There are some changes we want to make to the original file. Assume we want to run Samba for machines located on our LAN, 192.168.0.0./24 and this machine has the IP address 192.168.0.1.

hosts allow = 192.168.0.0./24 127.0.0.1
interfaces = 192.168.0.1

socket options = TCP_NODELAY
encrypt passwords = yes

Now we have to add a directory we want to share. Assume we have a directory /data that we want to make public and writeable to everyone who can login to Samba.

[data]
    comment = Data
    path = /data
    read only = no
    public = yes

Now we have to set the password for a user to be able to login to Samba.

/usr/local/bin/smbpasswd username

The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.

The NTP subnet in early 2003 includes well over a hundred public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are well over a hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total well over 100,000 clients and servers in the Internet.

There are two programs that are used here: ntpd and ntpdate. The ntpd program operates by exchanging messages with one or more configured servers at designated poll intervals. When started, whether for the first or subsequent times, the program requires several exahanges from the majority of these servers so the signal processing and mitigation algorithms can accumulate and groom the data and set the clock. The ntpdate program can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use.

On OpenBSD, the NTP software is not installed by default, so we will have to do this first.

cd /usr/ports/net/ntp
make install

Now we have to edit the configuration file /etc/ntp.conf. This file contains the names of servers we want to synchronize to and the networks of clients we allow access to this server.

server ntp.example.com prefer
server ntp.example.org
server ntp.example.net

restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer
restrict 10.0.0.0 mask 255.255.255.0 nomodify nopeer

OpenBSD starts ntpd automatically if it can find the daemon at /usr/local/sbin/ntpd. However, it does not call ntpdate at startup. So if you want that to happen, edit rc.conf.local.

ntpdate_flags="ntp.example.com"