This HOWTO was written to allow a Linux system administrator provide the Usenet news service to readers of those articles. The rest of this HOWTO focuses on the server-end software and systems, but one chapter dedicated to the clients does not seem disproportionate, considering that the raison d'etre of Usenet news servers is to serve these clients.
The overwhelming majority of clients are software programs which access the article database, either by reading /var/spool/news on a Unix system or over NNTP, and allow their human users to read and post articles. We can therefore probably term this class of programs UUA, for Usenet User Agents, along the lines of MUA for Mail User Agents.
There are other special-purpose clients, which either pull out articles to copy or transfer somewhere else, or for analysis, e.g. a search engine which allows you to search a Usenet article archive, like Google (www.google.com) does.
This chapter will discuss issues in UUA software design, and bring out essential features and efficiency and management issues. What this chapter will certainly never attempt to do is catalogue all the different UUA programs available in the world --- that is best left to specialised catalogues on the Internet.
This chapter will also briefly cover special-purpose clients which transfer articles or do other special-purpose things with them.
TO BE ADDED LATER
TO BE ADDED LATER
TO BE ADDED LATER
We will discuss Suck and nntpxfer from the NNTP server distribution here. Suck has already discussed earlier. We will be happy to take contributed additions that discuss other client software.
NNTPCache is an interesting transparent cacheing proxy for news articles. News articles are read-only by definition, i.e. they do not change once they are posted; they can only be deleted. NNTPCache uses this feature to build a local cache of news articles.
You set up NNTPCache to listen on the NNTP port of your local Unix server, and act like an NNTP daemon. You configure it to connect back-to-back to another NNTP daemon, further away, which has all the interesting stuff the users want to read. When a user connects to the local NNTPCache, it connects to the remote NNTP server and acts as a relay for the NNTP connection, ferrying commands and responses back and forth. What the user sees therefore comes from the remote server, the first time. However, all news articles fetched by NNTPCache are also stored in a local cache, thus allowing the next user to browse the same set of articles faster. Like all demand-driven caches, the advantage here is that the local NNTPCache does not need (much) administering, and will automatically delete all articles from its cache once they've been lying unread long enough.
We list it here as an NNTP client because every proxy server is a server on one side and a client on the other.