 |
 |
Articles / TULARC / PC info / Amiga / AmigaUUCP / |  |
|
|
||||
|
|
|||
|
|
|||
|
||||
|
|
||||
|
   |
|
||
|
7.0) Common Problems |
|
||
|
||||
|
|
|
||
|
||||
|
|
|
|
||
|
||
|
|
|
|
||
|
|
||
|
||
|
|
|
|
||
|
||
This article is from the AmigaUUCP
FAQ, by Marc SCHAEFER,
Batch news, yes but how ? [Autobatch entry in UULIB:Config]
if you add the config line (UULIB:CONFIG) "autobatch autobatch", news article will be compressed separately at each posting. You will end up with a lot of files in UUSPOOL:, decreasing throughoutput. However if you don't post a lot of articles, this can be interesting (you don't need to deal with DCRON or nasty uucico options.)
If you only poll another site, it would perhaps be more efficient to use the pre-batching capability of uucico (uucico -b). This will batch all posted articles in one file (if possible) and then call the specified host.
If you have downsites (if you feed other sites that calls you), you could also set up a "BatchNews" entry in S:Crontab (if you use DCRON) to pre-batch news before calling hours. Don't specify -b in UULIB:Passwd, because then the other uucico would have to wait (and possibly time-out) while online paying taxes.
The only situation you want to add the "Autobatch autobatch" config line to UULIB:CONFIG is when you don't know a lot about DCRON, you don't post a lot of articles and you don't have sites that you feed.
More information, see UUMAN:Batchnews, UUMAN:UUCICO, UUMAN:CONFIG.
RNews uses hardlinks. How to prevent it ?
Under the 2.0 operating system, RNews uses hardlinks to prevent cross-posted article to use n times the space on the harddisk. However, some utilities do not like very well hardlinks. It is then possible to disable hardlinks with the following change to UULIB:Config:
RNEWS UUCP:C/RNEWS -h
WARNING! Hardlinks to directories are buggy with ALL releases of the Operating System (V37-V39). Harlinks to files are also buggy under OFS and DCFS. Hardlinks should be turned off if not under FFS as shown above.
The UULIB:SEQ field.
The UULIB:SEQ fields is used to assign unique id's to files in the spool directory and to messages/articles sent out. Note that some news and mail systems (not AmigaUUCP) uses the ID's to prevent newsloops/mailloops. If you clear (or restore from a backup) the UULIB:SEQ, you should set it to a high value (or more than the last number it was) so your message are not getting filtered.
UUencode problems.
If you edit a mail and insert an uuencoded file, you may have problems if the editor changes spaces to tabs. With DME, you simply set this option to off ("savetabs off"). If you don't the file won't uu-decodable. By the way the syntax for uuencode, if you want to uuencode file "test.lha" is something like
uuencode <test.lha >test.lha.uu test.lha
The "test.lha.uu" file is the one to insert in your mail/news. Some NEWS utilities allow automatic posting of binaries (GRN).
UUCICO G protocol.
UUCico 1.16a and 1.15c implement also a "G" protocol besides the normal "g" protocol: If you poll one of these UNIX sites which support the 'G' protocol you have to force your own uucico to first try to use 'G' instead of 'g' when asking for the supported protocolls at connection startup. To do this, poll with
$ uupoll ... "-u -pG" ... or $ uucico ... -pG ...
Note that I couldn't test this.
There are a LOT more infos in the UUCP.internal FAQ, especially about other UUCP protocols.
Trimnews
New trimnews have been implemented, last is version 04, which supports new OS2.04 ExAll() calls which diminush the risk of a partition being trashed when deleting articles. It also offers trimming by hours rather than day and ALL trimming. It can be found on FTP/BMS/UUCP/FSP sites.
Multiple UUCICOs versions.
A lot of changes have been made on native UUCICO, and most of them in an uncontrolled way. When you specify a UUCICO version, you should also give the size of the file. The latest UUCICO is known to be:
--p-rwxd 1 53372 02-Jun-94 11:43:32 uucico 53372 bytes (105 blocks, 1 items Ram Disk: > uident uucp:c/uucico uucp:c/uucico @($)sysdep.c V1.17-beta.03 Jun 02 1994 uucp:c/uucico @($)uucico.c V1.17-beta.30 Jun 02 1994
From AmigaUUCP version 1.17b4 or 1.17b5.
Problems with newsloops due to Path-naming.
Suppose your newssite is called "foo". However, for an unknown reason, for example adminstration, it puts on the "Path" something like "foo.bar" or "bar" or "bar.edu". You will then have looping problems. The solution is to add the following entry to your sys file, replacing foo:* by foo:foo.bar:bar:bar.edu:*
Augmenting throughoutput.
The UUCP protocol, because it is a "send-ack-send" protocol, which needs an acknowledge of each packets before resuming sending, may be very slow. The following are some ideas to augment throughoutput.
a) Try to augment the window size. The window size is the amount of packets that may have been sent without being ack'ed in return. The bigger the better. Usually, 7 is OK. You set it via the -n uucico parameter (e.g. -n7). However some implementations of your feed's UUCP software will not allow above 3 (e.g. SYSV Basic Networking Utilities). b) Try to augment the packet size. It is how much data are being sent in one packet. This is done via the -P uucico keyword. For example -P5 selects 512 bytes packets.
c) Try to batch news in bigger packets. Avoid the "autobatch autobatch" configuration line in UULIB:CONFIG. Only batch once just before the outgoing call (for example use the -b switch for uucico).
d) Try to batch mail. Ask your feed if he can use BSMTP on both sides. This will diminush the number of small files to transmit.
e) In some case SUPPRESSING any error correction *AND* data compression protocol may decrease response time and increase throughoutput. Measures have been done concluding that it should be tested if your feed cannot do more than 3 windows and 64-bytes packets. If you do not send a lot of small files and can use 7-window packets with big size, usually disabling data compression and error correction may not be needed nor useful.
In general, you should TRY and figure out if anything helps. There is no universal solution to such problems.
Don't use tabs inside configuration files
A lot of problems have been reported with using TABs in your configuration files. For example, the BSMTP package written in Arexx does not accept any TABs in UULIB:Config. Also it has been reported that Batchnews will not understand a TAB in UULIB:L.Sys between the name of the node and "Any". This will result in no batching for the specified site. Beware that some editors will compress spaces into tabs. To force saving TAB to spaces use "savetabs on" in DME. This, according to Michael B. SMITH <mbs@adastra.cvl.va.us>, is no longer true with 1.17b4.
Using the mail/newssystem with "detaching" editors.
Most of AmigaUUCP software when calling external editors relies on the fact that the editor will only return control when the user has either cancelled (ie not changed the original edit file), or created a message (ie changed the oroginal edit file). DNEWS, GRn, DMAIL, and other software detect the cancel/ok condition from the length/modification date of the file. If it was not modified, then nothing is to be sent. Of course if the editor detaches itself it will prevent this mechanism from correctly working. The only solution is to force the editor not to return immediately. For example, with CED (CygnusEditor, commercial), you have to add Editor "CED -keepio" to your config file.
All news are stored in the JUNK directory.
Edit the UULIB:Newsgroups file, there must be a line with the newsgroup name (in . notation), a space/tab and the expiration delay
My news partition is growing, nothing seems to be deleted.
You have to either use cron to automatically run trimnews at specified times, or run trimnnews by hand. trimnews -all will delete all news. You should redirect the output to NIL: if you use it interactively (it will execute faster). Don't forget to use ONLY the latest version of trimnews. Some of them did awful things. Remember that a newspartition must be on a FFS disk. Using DCFS or other filesystems may create problemes due to bugs in the OS. My machine name is 'testa', but the world knows me as 'test.com'.
Add the following to UULIB:Domain: 'test.com MD UU testa', and add Reply-To: to your messages (or use testa.test.com). I want to prevent the news to go to siteb if they come from sitea and vice-versa.
If your feeds are sitea and siteb, update your UULIB:Sys config to: sitea:siteb:comp.sys.amiga.* siteb:sitea:comp.sys.amiga.* I keep getting 'Received x expected y' messages while uucico'ing.
Use hardware flow control, minimize other tasks running, augment uucico priority or buy a faster Amiga. These messages mean the two uucico speaking to each other are out of sync. This is not fatal, and will be recovered automatically by the protocol.
Strange problems with the configuration file and uuxqt looping forever This can happen, if the last line in UULib:Config is not properly terminated with a linefeed; the code idling around is in lib/config.c:FindConfig(). It affects at least AUUCP-1.17b4 and all derived code (including UMS-UUCP). The workaround is easy (make UUlib:config LF-terminated).
Sending mail to amiga.truc.com goes to my local amiga, amiga.sth.org
This is a bug with all sendmails before 1.17.33. Get the latest version.
Continue to:
|
|
|
|
 |
|