This page describes some general maintenance operations you can perform on an installed node.

Gaining administrative access to a node

You will need to create a ssh authentication key and give your public key to a member of the operations team. This key will be placed on the nodes for which you need administrative access. Take a look at the command ssh-keygen to create your keys.

Once you do have the rights to get onto a node you can simply connect to it using secure shell. For example:

ssh nodexyz.personaltelco.net

This will allow you to connect to the host as a normal user. You will also be provided with sudo rights, which basically gives you the right to execute commands as root. A command is executed with root priviledges as follows:

sudo <command>

Some of the commands described on this page requires you to have root priviledges. These are not explicitly indicated but if you get "permission denied" errors, try running the command using sudo.

Verify correct services

The PTP boxes run several services. Once you are logged into a node you should check if the following important services are running:

• nocat: You will notice a perl process that is the actual NoCat service.

• apache: The local web server. There may be more than one running - depending on how many people are connected.

• dhcpd: The dhcp server.

• snmpd: The SNMP deamon that allows us to monitor the box with Nagios.

• named: This is the DNS server and there may be several named processes running.

The commands used for this is:

ps -ax

Verify services are running correctly

NoCat

A good check to verify that the machine is operating correctly is to see when the last user authenticated using NoCat. You can check this by looking at the entries in the file /var/log/nocat.log. In this file you will notice entries describing hosts entering and leaving the network. You can check the most recent timestamps of these entries to verify that the node is operating as expected.

A problem that occurs regularly is that the NoCat log file grows too big for the partition it is on. In this case you can do the following to free up some disk space:

 % cd /var/log
 % sudo gzip nocat.log
 % sudo touch nocat.log
 % sudo /etc/init.d/nocatauth-gateway restart

bind

Bone is the primary dns server for personaltelco.net. Bone's zone configuration files are located in /etc/bind/external . Note: these are in subversion so use the cof command to edit these files. (of course you want to make sure you know what you're doing editing those as well)

On the Node side of things. Each node runs is own instance of Bind9 it's local configuration is in /etc/bind. The configuration is set to allow locally connected clients (the wireless network) and the machine itself to use the NuCab as the primary nameserver for the network.

Each box is a secondary/slave for the ptp zone and the 10.11.in-addr.arpa zone. It also provides dns services to clients connected on the network using bone as it's primary source for un-cached dns queries.

You'll also want to pay attention to /etc/hosts -> /etc/net-node/hosts for node specific information.

Updating packages

It is a good idea to keep the nodes updates with recent packages. The commands used for this are:

 % sudo apt-get clean
 % sudo apt-get update
 % sudo apt-get dist-upgrade
 % sudo apt-get clean

Updating configuration files

You can also update a node with the latest configuration files as created by the PTP operations team. You update the configuration files as follows:

 % df -h (confirm there is adaquate disk space)
 % cd /home/web
 % sudo svn st (look at the changes to the repository, by the same token, know what your putting into subversion, space is very limited on most nodes)
 % sudo svn update

Change detection

A way to detect any configuration changes on a box is to use aide. Running aide will show you which files have been changed recently. This will give you a good idea about what is going on with the box. You can run aide as follows:

 % sudo aide --update | less

Notify the ops team if you notice a lot of files in the list or "odd" file changes. The database that changed files are compared against may need updating, but they should decide this. It should be noted that if you are the regular maintainer of the node in question it may not suprise you that say several files are changed concerning apache after a dist-upgrade where the apache-common pkg was upgraded. What your looking for and should be interested in is, after running "last" and seeing your the only one to have logged in since the last dist-upgrade, that an unrelated file in /etc was changed, say the shadow file or that /var/log/messages.3.gz was deleted. Use your heads. -Robert

CategoryNode