transport The (Web hosting ecommerce) last field, transport, describes the transport
transport The last field, transport, describes the transport to be used. A number of standard commands for different transports are available; their names begin with via. sendbatches passes them the destination sitename on the command line. If the batchparms entry is not /default/, sendbatches derives the sitename from the site field by stripping it of anything after and including the first dot or slash. If the batchparms entry is /default/, the directory names in out.going are used. To perform batching for a specific site, use the following command: # su news -c “/usr/lib/news/batch/sendbatches site” When invoked without arguments, sendbatches handles all batch queues. The interpretation of “all” depends on the presence of a default entry in batchparms. If one is found, all directories in /var/spool/news/out.going are checked; otherwise, sendbatches cycles through all entries in batchparms, processing just the sites found there. Note that sendbatches, when scanning the out.going directory, takes only those directories that contain no dots or at signs (@) as sitenames. There are two commands that use uux to execute rnews on the remote system: viauux and viauuxz. The latter sets the -z flag for uux to keep older versions from returning success messages for each article delivered. Another command, viamail, sends article batches to the user rnews on the remote system via mail. Of course, this requires that the remote system somehow feeds all mail for rnews to its local news system. For a complete list of these transports, refer to the newsbatch manual page. All commands from the last three fields must be located in either out.going/site or /usr/lib/news/batch. Most of them are scripts; you can easily tailor new tools for your personal needs. They are invoked through pipes. The list of articles is fed to the batcher on standard input, which produces the batch on standard output. This is piped into the muncher, and so on. Here is a sample file: # batchparms file for the brewery # site | size |max |batcher |muncher |transport #————-+——–+——-+———+———–+———– /default/ 100000 22 batcher compcun viauux swim 10000 10 batcher nocomp viauux Expiring News In B News, expiration needs to be performed by a program called expire, which took a list of newsgroups as arguments, along with a time specification after which articles had to be expired. To have different hierarchies expire at different times, you had to write a script that invoked expire for each of them separately. C News offers a more convenient solution. In a file called explist, you may specify newsgroups and expiration intervals. A command called doexpire is usually run once a day from cron and processes all groups according to this list. Occasionally, you may want to retain articles from certain groups even after they have been expired; for example, you might want to keep programs posted to comp.sources.unix. This is called archiving. explist permits you to mark groups for archiving. An entry in explist looks like this: grouplist perm times archive grouplist is a comma-separated list of newsgroups to which the entry applies. Hierarchies may be specified by giving the group name prefix, optionally appended with all. For example, for an entry applying to all groups below comp.os, enter either comp.osor comp.os.all. When expiring news from a group, the name is checked against all entries in explist in the order given. The first matching entry applies. For example, to throw away the majority of comp after four days, except for comp.os.linux.announce, which you want to keep for a week, you simply have an entry for the latter, which specifies a seven-day expiration period, followed by an expiration period for comp, which specifies four days.