7. Administration

There are various aspects of administration. This is mostly related to testing links.

7.1 Setting up LinkController		How to get the system installed
7.2 Default Installation		A simple multi-user installation
7.3 User Administration		Adding and removing users
7.4 Cron Scripts		Running programs automatically
7.5 Link Database Maintenance		Dealing with database problems
7.6 Link Ageing		Clearing outdated data from the databases.

7.1 Setting up LinkController

This chapter is aimed at administrators setting up LinkController or who want to have a better understanding of the way that their installation is set up.

The first stage is to actually build and install the programs. This is covered in the document `INSTALL' which is included with the distribution.

Once you have installed the software, the next step is to configure LinkController so that it knows where you have all of your data. The program default-install provides one model of this.

7.2 Default Installation

Running default-install -all should set everything up correctly. There are various variations on this command which do different things, but the summary is

• Create a linkcont user-id and group which will be used for running programs
• Create a working directory where LinkController will keep it's data
• Create configuration files, especially /etc/link-control.pl
• Create cron scripts which will run LinkController automatically.

Using this command it is also possible to activate users and groups e.g. default-install -user username or default-install -group groupname in which case the specified users will become a member of the linkcont group.

7.3 User Administration

User administration is really only needed if you are running link testing centrally for your users. This makes sense since it means that if several users have a link to the same place (likely in any given site) then you will only have to check that link once.

In this case, the important question is which links are copied into the checking database. This is controlled by the program copy-links-from-users and decides copies data from users which are in the lnctusr group.

The command default-install can be used to manipulate which users are in the group e.g. default-install --user username or default-install -group groupname in which case the specified users will become a member of the lcntusr group.

Another form of user administration is limitation on which users have access to the database. This can be done with normal file permissions. There isn't any specific control to stop users from seeing which links other users have put into the database.

7.4 Cron Scripts

In order to be effective, link testing should be done every day. Furthermore, it is a good idea to do the testing at low usage times, which normally means at night. For this reason normally a cron script will be used.

• copy the links from each user with copy-links-from-users
• add them to the database with extract-links --in-url-list
• build a schedule for testing the links with build-schedule
• test the links with test-link

The program default-install can create these scripts 7.2 Default Installation.

7.5 Link Database Maintenance

For the most part the link database shouldn't need much maintenance. There are a number of cases where it might, however. If it becomes corrupt, you may try the db_recover command. Probably, however, it's just better to recover the database and link checking schedule from a recent backup. Time is not really critical since the work is normally easy to regenerate. You should make sure that link checking doesn't run in at the time you do backups, however.

The other thing is that occasionally you may want to recover space in the link database by dumping and un-dumping it. See the Berkeley database documentation for more details.

7.6 Link Ageing

Sometimes we have a link which is no longer in use within our infostructure. However, it's not a good idea to throw away information about it immediately. It could be that certain files have been temporarily deleted and will come back. Alternatively, a link could have been found broken and been corrected, but someone has a copy of the old page. When they re-install the copy, we will have to deal with that link again.

If we had not kept that link around and they immediately do a link check on their document they may see nothing wrong, and, because of the nature of LinkController, we won't start reporting the link as a problem until some days later, when we have confirmed that it really is broken.

If, on the other hand, we keep checking all of the links which have ever been in our web pages, we will cause ourselves considerable extra work.

To handle this, links are aged. Once a link has reached greater than a certain age, test-link will not be checked it any more. Once the link has reached a much larger age, it will be completely deleted from the link database. The age is reset to nothing each time the link is extracted from the infostructure, so links which are still in use will continue to be checked.

In the meantime, the link will still be repeatedly scheduled based to it's normal checking time. This causes us to examine it quite regularly, but that is okay, since we won't actually check it.

By default links which have not been refreshed will be ignored after one week and will be deleted from the database after two months.