Synchronise your Gentoo Linux clock with an Internet time server

There are a number of ways to synchronise Gentoo Linux with a time server on the Internet. Here I look at a few alternatives.

ntp-client

ntp-client and the NTP daemon ntpd are installed when you install the package net-misc/ntp. Although I have read on some Web sites that /etc/init.d/ntp-client should be added to the default runlevel in order to read the time from an NTP server (once-only, during start-up), this in fact does not work because usually the network connection is not up by the time the ntp-client initscript runs. Bear in mind that ntp-client does not run continuously; it syncs once with an external time server if there is a network connection, and that’s it.

NetworkManager Dispatcher

If you are using NetworkManager, an elegant solution is to use NetworkManagerDispatcher to restart ntp-client in order to resync your system clock every time a network connection comes up. This is my favoured solution for laptops; see further on for how to configure your machine to do this.

cronjob

Another way would be to create a cronjob to run periodically the ‘/etc/init.d/ntp-client restart‘ command or the ‘ntpd -q‘ command (the -q option means “set the time and quit”).

Wait a while after start up

A ‘quick-and-dirty’ method, which I have used sometimes to synchronise a laptop’s system clock every time it boots, would be to delay running ntp-client until the network is up by putting e.g. the command below in a file 10_ntp-client.start in the directory /etc/local.d/ (10 seconds is usually enough time for a wired or wireless connection to my home network to be established):

#!/bin/bash
sleep 10s && /etc/init.d/ntp-client restart

Don’t forget to make it executable:

# chmod 744 /etc/local.d/10_ntp-client.start

NTP daemon

Regarding the NTP daemon, it is possible to configure this from the command line, rather than via a Desktop Environment GUI, to run at start-up and continue running to adjust your system clock. The command:

# rc-update add ntpd default

will add the daemon’s initscript to the default runlevel so that it is launched automatically at the next startup, and the command:

# /etc/init.d/ntpd start

will start the daemon running right now.

Note that, by default, the NTP daemon won’t correct, all in one go, a time difference between your system clock and the remote NTP server if that difference is above a certain size. However, if you want to override the default behaviour, i.e. allow the NTP daemon to make a large first adjustment to the system clock, you can set the environment variable NTPD_OPTS in the file /etc/conf.d/ntpd as follows:

NTPD_OPTS="-g"
# The -g option enables ntpd to make large adjustments.

This would mean that you would not need to run ntp-client before ntpd. However, if you run ntp-client automatically — either once after start-up or periodically — then that would be good enough for the typical Desktop user, and could be an alternative to having a continuously-running NTP daemon. Nothing stops you doing both if you want, of course.

Updating the hardware clock

If you make clock_systohc="YES" in the file /etc/conf.d/hwclock then the time in the system clock will be written to the BIOS (CMOS) clock (a.k.a. hardware clock) when you shut down your PC.

How to configure NetworkManager Dispatcher to synchronise the system clock only when a network connection is made

If you’re using a machine that is permanently connected to a network, running the NTP daemon makes sense. But what if you have a machine that is not always connected to a network when it is powered up? I have a laptop and I don’t want the NTP daemon running all the time. But I would like my laptop to synchronise with an external time server once after start up when I connect to the Internet. NetworkManager has a handy tool called NetworkManager Dispatcher for doing just this.

If you have installed NetworkManager, you’ll find there is an initscript /usr/portage/net-misc/networkmanager/files/NetworkManagerDispatcher. Copy it to the directory /etc/init.d/ and give it the necessary restrictive permissions:

# cp /usr/portage/net-misc/networkmanager/files/NetworkManagerDispatcher /etc/init.d/
# chmod 744 NetworkManagerDispatcher

Then create a shell script called e.g. 99_ntp-client in the directory /etc/NetworkManager/dispatcher.d/ to be run by NetworkManagerDispatcher when a network connection is established, containing the following code:

#!/bin/bash

INTERFACE=$1 # The interface which is brought up or down
STATUS=$2 # The new state of the interface

case "$STATUS" in
    'up') # $INTERFACE is up
        echo "System time before starting ntp-client:" > /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
        echo "Starting ntp-client:" >> /home/fitzcarraldo/ntp-client.txt
        rc-config restart ntp-client &>> /home/fitzcarraldo/ntp-client.txt
        echo "System time after starting ntp-client:" >> /home/fitzcarraldo/ntp-client.txt
        date >> /home/fitzcarraldo/ntp-client.txt
        ;;
    'down') # $INTERFACE is down
        # Check for active interface and down if no one active
        if [ ! `nm-tool|grep State|cut -f2 -d' '` = "connected" ]; then
                echo "Stopping ntp-client at:" > /home/fitzcarraldo/ntp-client.txt
                date >> /home/fitzcarraldo/ntp-client.txt
                rc-config stop ntp-client &>> /home/fitzcarraldo/ntp-client.txt
        fi
        ;;
esac

Make the root user the owner of the script, and only allow the root user to write to it and execute it:

# cd /etc/NetworkManager/dispatcher.d/
# chown root:root 99_ntp-client
# chmod 744 99_ntp-client

Then add NetworkManagerDispatcher to the default runlevel so that it will be launched every time you boot your machine:

# rc-update add NetworkManagerDispatcher default

As the package net-misc/ntp installs both /etc/init.d/ntpd and /etc/init.d/net-client, users could optionally add the NTP daemon ntpd to the default runlevel too if desired, which would provide continuous, incremental adjustments to the system clock once net-client has done its one-shot adjustment each time a network comes up:

# rc-update add ntpd default

But users who don’t leave their PCs on for days on end — or who use laptops — can ignore the above step and just stick with the NetworkManagerDispatcher and net-client solution, whereas users who leave their machines on for days or weeks on end can also use the NTP daemon to keep the system clock in sync in between the times when ntp-client has synchronised.

Don’t forget to delete ntp-client from the start-up level if you are using NetworkManagerDispatcher to run it:

# rc-update del ntp-client

Notice that the script /etc/NetworkManager/dispatcher.d/99_ntp-client logs some information in a text file ntp-client.txt in my home directory which I can check. Here is an example of what ntp-client.txt contains after I select a network (or it is selected automatically) following start up of my laptop:

System time before starting ntp-client:
Sun Jun 3 19:24:08 BST 2012
Starting ntp-client:
Restarting init script
* Setting clock via the NTP client 'ntpd' ...ntpd: time slew +0.067178s
[ ok ]
System time after starting ntp-client:
Sun Jun 3 19:24:17 BST 2012

As you can see above, the ntpd command was executed once by NetworkManagerDispatcher and made a small adjustment to the system time on my laptop.

Replacing ntpdate with ntpd in ntp-client

Just for the fun of it, I changed /etc/conf.d/ntp-client to use the command ntpd instead of ntpdate, even though the ntpdate command works fine. Anyway, here’s my /etc/conf.d/ntp-client file these days:

NTPCLIENT_CMD="ntpd"
NTPCLIENT_OPTS="-g -q"

I have added the -g option so that the ntpd command can make large adjustments to the system time if it is way off the actual time. This is useful at the beginning and end of Daylight Saving Time, or if you dual boot with Windows. Here is an example of the former when I powered up my laptop the morning after the clocks changed from BST to GMT at the end of Summer 2010:

$ cat /home/fitzcarraldo/ntp-client.txt
System time before starting ntp-client:
Sun Oct 31 09:37:23 GMT 2010
Starting ntp-client:
Starting init script
* Setting clock via the NTP client 'ntpd'...ntpd: time set -3600.122381s
[ ok ]
System time after starting ntp-client:
Sun Oct 31 08:37:30 GMT 2010

You can specify the NTP server or NTP server pool in the file /etc/ntp.conf, but the default server pool already specified in that file should work. Note again that, when ntpd is run with the -q option, it synchronises the system clock once and terminates, i.e. it is not running as a daemon.

How to install and use Tor for anonymous browsing or to access country-restricted content from another country

Some people want to browse the Web in complete anonymity. One tool for doing that is Tor. However, there are other reasons for using Tor. For example, when I am travelling in a country where the government blocks certain Web sites (or blocks accessing content on certain Web sites), or when I am travelling overseas and certain Web sites back home will not let me view content (e.g. TV shows), I use Tor. Note that some Web sites are now clever enough to detect that you are accessing them via a proxy and could be overseas, so even Tor will not gain you access to media on some Web sites back home. Anyway, it’s still worth trying Tor to see if it works in your case.

For an overview of the installation and configuration procedure, see Running the Tor client on Linux/BSD/Unix. Below I will explain how to install and use Tor in Gentoo Linux.

Before you use Tor, it is useful to check your current IP address. Several Web sites will tell you your current IP address; here is the site I usually use: http://whatismyipaddress.com/

1. Install Tor:

# USE="tordns" emerge -1v tor

(Actually, the more-recent versions of the tor package don’t require that USE flag but I’ve left it in as it does no harm.)

2. Install Vidalia:

# cd /usr/portage/distfiles/
# wget --no-check-certificate https://www.torproject.org/dist/vidalia/vidalia-x.y.z.tar.gz
# USE="tor" emerge -1v vidalia

Use the current version x.y.z of the vidalia package in the package manager and https://www.torproject.org/dist/vidalia/

3. Install Polipo:

# emerge -1v polipo

4. Download polipo.conf

# cd /etc/polipo
# wget --no-check-certificate https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:/build-scripts/config/polipo.conf

Edit April 21, 2013: The above URL is now:

https://gitweb.torproject.org/torbrowser.git/blob_plain/ae4aa49ad9100a50eec049d0a419fac63a84d874:/build-scripts/config/polipo.conf

5. Edit it and change proxyPort = 8118 to proxyPort = 8123

6. Copy it to /etc/polipo/:

# cd /etc/polipo
# cp /etc/polipo/config /etc/polipo/config.bak
# cp polipo.conf config

7. Configure Firefox:

Edit > Preferences > Network > Settings

Manual proxy configuration:

HTTP Proxy: 127.0.0.1 Port: 8123
SSL Proxy: 127.0.0.1 Port 8123

SOCKS Host: 127.0.0.1 Port 9051
SOCKS v5
No Proxy for: 127.0.0.1

8. Run Vidalia and then configure it:

$ vidalia &

a) Settings > Sharing

Select ‘Run as a client only’

b) Settings > Advanced

Select ‘Use TCP connection (ControlPort)’
Address: 127.0.0.1 9051

Tor Configuration File:
/home/fitzcarraldo/.vidalia/torrc

Data Directory:
/home/fitzcarraldo/.tor

c) Click on ‘Edit current torrc’ and make it:

# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it
ControlPort 9051
ExitNodes {gb}
Log notice stdout
SocksListenAddress 127.0.0.1
StrictNodes 1

Note that I have specified “{gb}” above so that I am perceived by Web sites to be browsing in the UK even if I am in another country. But you can use a different country code if you want Web sites to perceive you are in another country. For example, “{us}” would make it look as if you are browsing in the USA.

9. Run Polipo:

$ sudo polipo

10. Surf to http://torcheck.xenobite.eu/ to check that you are now using a Tor exit node.

11. Surf to http://whatismyipaddress.com/ to check that your IP address has changed.

Cannot browse some Web sites: yet another cause

Having spent hours yesterday trying to figure out why I could no longer browse a few specific Web sites from my old Gateway Solo 9300 laptop running Linux, whereas all the other Linux and Windows laptops that use my wireless network can browse any Web site, I thought I’d post the solution as Google did not turn up this particular cause.

There are several possible reasons why one may not be able to browse some Web sites: IPv6; the MTU; a black hole router en route; the settings in the various ip_* and tcp_* files in /proc/sys/net/ipv4/, and so on. So, unfortunately I had many avenues to pursue.

My old Gateway Solo 9300 laptop had enabled me to browse the Web reliably via my home wireless network until recently. Suddenly I could neither browse the Sabayon Linux Web site nor access the Entropy package manager’s repository. I could also no longer browse some other Web sites, although most Web sites were still accessible without trouble.

I tried many different things without success, and then finally remembered that I had reconfigured my router a couple of weeks ago because one of my family had reset it whilst I was away from home. Now, when this model of router (BT Home Hub, Version 1.0) is reset it defaults to WEP encryption for wireless networking. However, I normally have it set to use WPA-PSK encryption. So, when I got home I accessed the router’s Web interface via Ethernet from a Desktop PC and changed wireless networking encryption to “WPA-PSK Version: WPA+WPA2″. In the past I had set it to “WPA-PSK Version: WPA”, and thought that setting “WPA+WPA2″ instead of “WPA” this time would not cause any problems. Well, it didn’t on all the other laptops using my network, but my old Gateway Solo 9300 with Linksys CardBus card (‘Linksys WPC54G (EU) v7.1 wireless notebook adapter card’) was different.

As soon as I wondered if the encryption setting was the cause of my problem, I browsed to the BT Home Hub configuration page and changed wireless networking encryption from “WPA-PSK Version: WPA+WPA2″ to “WPA-PSK Version: WPA”. Bingo, my Gateway Solo 9300 running Sabayon Linux E17 Edition and Firefox 4 could browse all Web sites again. Mind you, I also need to have the ipv6 module disabled (I had previously uncommented the line alias net-pf-10 off in the file /etc/modprobe.d/aliases.conf and used the command update-modules) as well as the modifications mentioned in an earlier post (Why can’t I access a specific Web site?). But all those other measures do not solve the problem if the router is configured for “WPA-PSK Version: WPA+WPA2″.

The router’s wireless security option “WPA-PSK Version: WPA” is intended for a network that would only be used by clients configured to use WPA encryption; the router’s option “WPA-PSK Version: WPA2″ is intended for a network that would only be used by clients configured to use WPA2 encryption; the router’s option “WPA-PSK Version: WPA+WPA2″ is intended for a network that would be used by clients configured to use either WPA or WPA2 encryption. So I wonder why there was a problem, as the laptop and CardBus card are configured for “WPA & WPA2 Personal” in nm-applet, and the card supports WPA (TKIP) and WPA2 (CCMP a.k.a. AES).

Why can’t I access a specific Web site?

Is there one specific Web site that you can never access? That always causes your Web browser to stall when you click on a link to that site or enter the site’s URL in the browser’s address bar? Perhaps it’s an Internet banking site? You don’t have trouble with other sites, just this one particular site or perhaps just a couple of sites?

The chances are that this problem is caused by what is called a ‘black hole’ router somewhere between you and that site. For the technical explanation of a black hole router, see e.g. the article Black Hole (networking).

I experienced this precise problem a couple of days ago with the popular Web site IMDb. The old Gateway Solo 9300 laptop I was using has no built-in networking hardware so I use a couple of CardBus cards for wireless and wired network access. The Linksys WPC54G (EU) v7.1 wireless notebook adapter works fine but, irrespective of the Web browser, I could not access the IMDb Web site; the browser always stalled when trying to load the site. I discovered I also had the same problem with my bank’s Web site.

I could ping other sites by IP address and by domain name, but pinging the IMDb site never received a reply (and it still doesn’t, even after the fix explained below which allows browsing of the site).

I also experienced this problem several years ago under Windows XP when trying to access the Amazon UK Web site, using an MTU that I had incorrectly set to a value smaller than possible. The problem this time was due to a correctly-set MTU. In both cases, the two MTUs are smaller than a router somewhere en route to those sites wanted to handle.

BACKGROUND

Bear with me while I explain how the problem arose, as it’s relevant (and useful) information.

I had just installed Sabayon Linux on the laptop and got the wireless network connection up, and the first thing I then did was to launch Firefox. With an MTU of 1500 for wlan0, Firefox would only load Google (and that, only intermittently). All other sites would stall. So I used the following command iteratively in order to find the MTU for this hardware, which is 1464 (the maximum packet size in bytes that does not fragment + 28 bytes):

# ping -M do -s packet_size_in_bytes http://www.cisco.com

e.g.

# ping -M do -s 1472 http://www.cisco.com

I just varied the packet size in the ping command until “Frag needed and DF set” was not displayed.

I can reduce the MTU to 1464 as follows:

# ifconfig wlan0 mtu 1464

I could make this permanent by adding an entry (mtu_wlan0=”1464″) to the file /etc/conf.d/net, but I chose instead to make it permanent by adding the above ifconfig command to the file /etc/conf.d/local. This (correct) MTU works fine for all sites I have visited so far except for two, which just stall the browser: IMDb and my bank’s Web site.

I also have a Belkin F5D5010 CardBus Network Card (wired Ethernet) for the laptop. It works fine with an MTU of 1500, and there is no problem accessing the IMDb Web site in Firefox. So, apparently, the MTU is the problem when using the wireless network connection. Now let’s look at the solution…

THE SOLUTION

Well, in the case of Windows it is possible to edit the Registry to solve the problem of network ‘black holes’. But what do you do in the case of Linux? It turns out that the kernel /proc file system provides an easy way to enable and disable TCP MTU Probing by changing a value in the ‘file’ /proc/sys/net/ipv4/tcp_mtu_probing. A value of 0 = disabled; 1 = enabled when a black hole router is detected; 2 = always enabled.

This is what my laptop had in that ‘file’:

# cat /proc/sys/net/ipv4/tcp_mtu_probing
0

So all I needed to do was:

# echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

and, bingo, a browser can access IMDb and my bank’s Web site without a problem. To make it permanent, I just added the above command to the file /etc/conf.d/local so that it is executed every time I boot the laptop. Here is what my file /etc/conf.d/local looks like now:

# Here is where you can put anything you need to start
# that there is not an init script for.

local_start() {
# This is a good place to load any misc programs
# on startup (use &>/dev/null to hide output)

# START OF MY ADDITIONS
# The Linksys CardBus card does not work with a MTU greater than 1464:
ifconfig wlan0 mtu 1464
# Enable TCP MTU Probing in order to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
# END OF MY ADDITIONS

# We should always return 0
return 0
}

local_stop() {
# This is a good place to unload any misc.
# programs you started above.

# We should always return 0
return 0
}

UPDATE (May 13, 2011): OpenRC 0.8.0 and later in Gentoo and Sabayon Linux no longer use the file /etc/conf.d/local but instead require the commands to be in files in the directory /etc/local.d/. So I created a file /etc/local.d/01network.start containing the following lines:

# The Linksys CardBus card does not work with MTU greater than 1464:
ifconfig wlan0 mtu 1464
# Enable TCP MTU probing to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

and made it executable:

# chmod +x /etc/local.d/01network.start

UPDATE (April 11, 2012): If “echo 2″ does not solve the problem, try “echo 1″ instead. The possible values are:

0 Do not perform PLPMTUD (Packetization Layer Path MTU Discovery)
1 Perform PLPMTUD only after detecting a ‘blackhole’.
2 Always perform PLPMTUD.

Follow

Get every new post delivered to your Inbox.

Join 26 other followers