One of my favourite utilities ever is tmux, no doubts about it. It allows you to create a session when you are connected to a machine via SSH and restore that session later even if your SSH connection drops for any reason. Once you reattach the session, you will be brought back exactly to the point where you were before the disconnection.
This is extremely useful in cases where the command you launched would take a long time to complete (for example, if you are burning in your hard drives for FreeNAS or if you are generating DH parameters when configuring OpenVPN).
What better way to start 2017 with a post on my future projects? There are several things I would like to try in the next 12 months, some that I have been meaning to try for a long time, others that made the list only recently. Of course, like every year, this list will change a million times and I will add and remove several entries as I go along, but for now, these are some of the things I want to spend some time playing with in 2017.
I have stumbled upon a very interesting article by Alasdair Allan today on how to build a Raspberry Pi cluster. It looks like one of the most clear and thorough ones on the topic, but what I absolutely want to try is adding an LCD screen to the cluster. Look at the final result:
This looks amazing and will definitely be one of my next projects. Make sure to give the original article a read, I’ll be sure to post something about this once I am done with the project.
After enabling CRL checking on my OpenVPN server, I have encountered an annoying permission issue. When I tried connecting from the Android app, the connection would simply timeout. Before enabling CRLs this had never happened, so I realized there must be something wrong with them.
So I looked into the OpenVPN logs (/var/log/openvpn.log) and noticed the following entry:
The weird thing was that both the crl.pem file and the whole /etc/openvpn folder were owned by root and were perfectly readable with a nano crl.pem when run from the CLI. So from a filesystem point of view, everything looked ok.
You probably know the NTP Pool Project, or perhaps you have noticed that in several Linux distributions it’s servers from this pool that are configured as default time servers. They are run by volunteers offering their own bandwidth and time to manage these NTP servers. From the project’s home page:
The pool is being used by millions or tens of millions of systems around the world. It’s the default “time server” for most of the major Linux distributions and many networked appliances (see information for vendors).
Because of the large number of users we are in need of more servers. If you have a server with a static IP address always available on the internet, please consider adding it to the system.
Therefore, I decided to contribute and added my own NTP server to the pool. To do this, I have used a Raspberry Pi model B+ and the Raspbian distro. I hope that these instructions will help more volunteers contribute to the project.
Stratum 1, 2, 3… ?
I have decided to go for a Stratum 2 NTP server, just because I didn’t have a GPS addon for the Pi. There are several nice guides on the Web on how to configure a Pi as a Stratum 1 server, so this guide will focus exclusively on the ntp software.
Note that it is not required that your server is a stratum 1 or 2 server – as this project is about load distribution mostly, there is no reason why a stratum 3 or even stratum 4 server shouldn’t join.
Configure the Raspberry Pi
Put Raspbian on the SD card and boot the Pi for the first time
Login (the default credentials are pi as the username and raspberry as the password)
sudo apt-get update && sudo apt-get upgrade
to upgrade the firmware of the Pi. It’s important that you run this after the update commands so that the latest version of the firmware update utility is downloaded and used
A reboot is necessary after the firmware upgrade
I recommend adding a new user and password to harden the system a bit:
sudo adduser new_user
Require a password for this new user (notice that, by default, Raspbian doesn’t require a password when you acquire root privileges from the pi user):
Look for the line #includedir /etc/sudoers.d and add the following line in that section:
new_user ALL=(ALL) ALL
Reboot and try to login with new_user to check that the operation has completed successfully
Delete the old pi user:
sudo userdel -r pi
Check that the pi user has been deleted:
cut -d: -f1 /etc/passwd
Remove the pi user line from visudo
Assign a static IP address to the machine. For reference, this is my /etc/network/interfaces file:
iface lo inet loopback
iface eth0 inet static
dns-nameservers 192.168.0.254 220.127.116.11 18.104.22.168
Now the most important part, configuring the NTP settings. It’s important to pick at least 3 different NTP servers for accurate measurements, 5 would be better. It’s also important, paradoxically, not to choose them from existing NTP Pool servers. I personally chose 5 from this list. Again for reference, this is my /etc/ntp.conf file:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
# Enable this if you want statistics to be logged.
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
sudo /etc/init.d/ntp restart
Check that everything is working:
Your output should look similar to this:
which lists the IP addresses of the NTP servers you have configured in your ntp.conf file and where they are getting the time from. Since this is a Stratum 2 NTP server, all of these servers are Stratum 1 and are therefore getting the time measurements from GPS.
This completes the configuration section of the server, but if you are picky, there are still a couple of things you might want to check.
Point clients to your server
Pointing client to your new NTP server is another good way to check if things are working. In Windows you can do this from the Date and Time control panel entry > Internet Time tab > Change Settings…
Enter your Pi’s IP address here and click on Update. If everything goes well, you should see a confirmation message like this:
On Linux, you just need to configure ntp.conf so that it uses your NTP server. After doing so, if you run ntpq -pn on the client, you should see one single entry with your Pi’s IP address:
If you cross check with your server’s ntpq -pn output, you should see that the refid value in your client’s output (i.e. the actual server the NTP server is taking the time from) matches the IP address marked by a * in the remote column of the server’s output, i.e. the NTP server actually being used:
That’s it folks, now you only need to join this to the pool (and don’t forget to configure port forwarding before doing so). Please consider doing it, there is constant need for new NTP servers, and it won’t use much bandwidth anyway.