Please check the time on your PC.
+ +All spots are checked that they are no more +than 15 minutes in the future and 60 minutes in the past. If your clock on your client +prompt (or console.pl display) is not set to the correct time +in GMT (UTC) and is more than one hour out (say on your local (summer) time) then +the test will fail and no spots will come out. Neither will they be stored.
+ +If you are connected to the internet, most linux distributions have an implementation of +ntpd. The Microsoft Windows 2003, XP, +2000 and NT machine clock can also be set to be syncronised +to an NTP source. This can be done in the standard time configuration screen. There is also +the simple +nettime program for Windows 95/98/ME.
+ + +Assuming that the permissions are set correctly (perm level 5 required), it could be @@ -64,7 +83,7 @@ spoof gb7adx set/home gb7adx
Assuming that the node_call you are changing is gb7adx.
-There is a file in /spider/msg called forward.pl.issue. Rename this to @@ -72,7 +91,7 @@ forward.pl and edit it to meet your requirements. You will need to issue the command load/forward or restart Spider for the changes to take effect.
-Use the tmpwatch command. Create a file in /etc/cron.daily/ containing the line ...
@@ -84,9 +103,10 @@ take effect.Remember to make it executable!
-This will limit your debug data down to the last 10 days
+This will limit your debug data down to the last 10 days.
+However, modern versions of DXSpider will do this for you, so this is now probably unnecessary.
-Almost certainly this is a change in the db format of perl. Follow these @@ -95,13 +115,13 @@ few steps to correct the problem.
That should solve the problem.
-What has probably happened is that the dupefile has got corrupted in @@ -109,7 +129,7 @@ some way. Simply delete the /spider/data/dupefile and restart the cluster. It may take a little time to become fully functional but should solve your problem.
-This is now the way messages are handled for deletion in Spider. If you @@ -118,6 +138,100 @@ message is marked for deletion and will be deleted in 2 days if nothing further is done. Optionally you can use the command delete/expunge to delete it immediately.
+Whenever you update from CVS, a log is displayed. Next to each +file that is downloaded there is a letter, e.g.:
++
+
+? fred.pl
+? jim
+..
+.
+..
+cvs server: Updating perl
+P cluster.pl
+C Messages
+M Internet.pm
+U DXProt.pm
+..
+.
+..
+
+For normal CVS use you should only ever see the letters 'P', 'U' or '?'. The +letter 'P' means that the file has +changed in CVS and is more recent than the one that is currently on your system. You will also +see the letter '?', which means that +there is a file that you (or the system) has created that CVS doesn't know about and isn't +under its control. These are all normal and good.
+ +Sometimes you will see the letter 'U' next to a file. This means that it is a new file that you don't currently +have. This is also OK.
+ +However, if you see the letter 'C' or 'M', that means that CVS thinks that the file has +changed locally. For the letter 'C', it has changed sufficiently near to one or more +modifications which CVS wants to download to your system. For the 'M', CVS thinks that it +is OK to make the change (you may also see some messages about "merging revision 1.xx with 1.yy"). +Neither of these things are good. Files that are under the control of CVS +must not be changed by sysops. It is the files that have the 'C' next to them that will show +the errors that you are complaining about and they will be things like:-
++
+
+Syntax error near '<<<<' at line 23
+Syntax error near '===' at line 40
+Syntax error near '>>>' at line 51
+
+You will not necessarily see all of the errors shown but you will get one or more sets of some +of them. The cure is simple:
++
You will see that file come back (with a letter 'U' next to it). That will be the correct +file as CVS thinks it should be. If you still have a problem, then get onto the +dxspider-support mailing list.
+ +If all else fails (or you have several conflicts) you can safely remove the entire /spider/perl and
+/spider/cmd directories and then run the cvs update. They will all be recreated in their pristine
+condition.
The correct way to run cvs is:-
++
+
+cd /spider
+cvs -z3 update -d
+
+The '-d' is crucial. It makes sure that any new directories, that may contain new code, +are created and that new code downloaded. I have absolutely no idea why this is not the +default, seeing as CVS (in other circumstances) happily recurses its merry way down a +directory tree, but there you are.
+ +WinCVS and other graphical CVS frontends have a checkbox for the update screen called something +like "create sub-directories" (it may be hidden in some sub-screen - go look for it if it isn't +obvious). Make sure that this box is checked. If you can make this the +default setting in the program's setup screen then please do that. It will save you a lot +of pulled hair.
+