• Aucun résultat trouvé

Setting up a caching only name server

Dans le document The NetBSD Operating System (Page 130-134)

A caching only name server has no local zones; all the queries go to the root servers and the replies are accumulated in the local cache. The next time the query is performed the answer will be faster because the data is already in the server’s cache. Since this type of server doesn’t handle local zones, to resolve the names of the local hosts it will still be necessary to use the already known/etc/hostsfile.

Since NetBSD supplies defaults for all the files needed by a caching only server, the configuration of this type of DNS is very easy, and can be performed with a few commands, without writing a single line in the configuration files.

Note: the number of the configuration files and their contents varies between versions of NetBSD.

The program which supplies the DNS server is the named daemon, which uses thenamed.conf configuration file for its setup. The default file supplied by NetBSD is located in the/etc/namedb directory, but the daemon looks for it in the/etc/directory, so we start by creating a link:

# ln -s /etc/namedb/named.conf /etc/named.conf

The name server is ready for use! We can now tell to the system to use it adding the following line to the /etc/resolv.conffile:

nameserver 127.0.0.1 Now we can start named.

# named

Note: we have now started the name server manually. Once we have tested it and are confident that it works, we can launch it automatically at boot using the relevant option of the/etc/rc.conffile.

Chapter 12 The Domain Name System

12.5.1 Testing the server

Now that the server is running we can test it using the nslookup program.

# nslookup

Default server: localhost Address: 127.0.0.1

>

Let’s try to resolve an host name, for example www.mclink.it (try a site near you.)

> www.mclink.it Server: localhost Address: 127.0.0.1 Name: www.mclink.it Address: 195.110.128.8

If you repeat the query a second time, the result is slightly different:

> www.mclink.it Server: localhost Address: 127.0.0.1 Non-authoritative answer:

Name: www.mclink.it Address: 195.110.128.8

As you’ve probably noticed, the address is the same, but the message “Non-authoritative answer”, has appeared. This message indicates that the answer is not coming from an authoritative server for the domain mclink.it but from the cache of our own server.

The results of this first test confirm that the server is working correctly.

We can also try the host command, which gives the following result.

# host www.mclink.it

www.mclink.it has address 195.110.128.8

Chapter 13

Mail and news

This chapter explains how to set up NetBSD to use mail and news. Only a simple but very common setup is described: the configuration of a host connected to the Internet with a modem through a provider: think of this chapter as the continuation of Chapter 11, assuming a similar network configuration. Even this

"simple" setup proves to be difficult if you don’t know where to start or if you’ve only read introductory or technical documentation; in fact you will notice that some details are really challenging (for example, mapping your internal network names to “real” names requires a good knowledge of sendmail.) A general description of mail and news configuration is beyond the scope of this guide; please read a good Unix Administration book (some very good ones are listed on the NetBSD site.) The problem is in fact very complex because of the myriad of possible configurations and connections and because it’s not enough to configure a single program: you need to correctly match the configuration of several cooperating components.

This chapter also briefly describes the configuration (but not the usage) of two popular applications, mutt for mail and tin for news. The usage is not described because they are easy to use and well documented.

Obviously, both mutt and tin are not mandatory choices: many other similar applications exist but I think that they are a good starting point because they are widely used, simple, work well and don’t use too much disk space and memory. Both are console mode programs; if you prefer graphics applications there are also many choices for X.

In short, the programs required for the configuration described in this chapter are:

sendmail

fetchmail

m4

mutt

tin

Of these, only sendmail and m4 are installed with the base system; you can install the other programs from the package collection.

Before continuing, remember that none of the programs presented in this chapter is mandatory: there are other applications performing similar tasks and many users prefer them. You’ll find different opinions reading the mailing lists. You can also use different strategies for sending and receiving mail: the one explained here is only a starting point; once you understand how it works you’ll probably want to modify it to suit your needs or to adopt a different method altogether.

At the opposite extreme of the example presented here, there is the usage of an application like Netscape Communicator, which does everything and frees you from the need of configuring many components:

with Communicator you can browse the Internet, send and receive mail and read news. Besides, the setup is very simple. There is a price to pay, though: Communicator is a “closed” program that will not cooperate with other standard Unix utilities.

Chapter 13 Mail and news Another possibility is to use emacs to read mail and news. Emacs needs no introduction to Unix users but, in case you don’t know, it is an extensible editor (although calling emacs an editor is somewhat reductive) which becomes a complete work environment, and can be used to read mail, news and to perform many operations. For many people emacs is the only environment that they need and they use it for all their work. The configuration of emacs for mail and news is described in the emacs manual.

In the rest of this chapter we will deal with a host connected to the Internet through a PPP connection via serial modem to a provider.

the local host’s name is “ape” and the internal network is “insetti.net”, which means that the FQDN (Fully Qualified Domain Name) is “ape.insetti.net”.

the user’s login name on ape is “carlo”.

the provider’s name is BigNet.

the provider’s mail server is “mail.bignet.it”.

the provider’s news server is “news.bignet.it”.

the user’s (“carlo”) account at the provider is “alan” with the password “pZY9o”.

First some basic terminology:

MUA (mail user agent)

a program to read and write mail. For example: mutt, elm and pine but also the simple mail application installed with the base system.

MTA (mail transfer agent)

a program that transfers mail between two host but also locally (on the same host.) The MTA decides the path that the mail will follow to get to the destination. On BSD systems (but not only) the standard MTA is sendmail.

MDA (mail delivery agent)

a program, usually used by the MTA, that delivers the mail; for example, it physically puts the messages in the recipient’s mailbox. For example, sendmail uses one or more MDA to deliver mail.

Figure 13-1 depicts the mail system that we want to set up. Between the local network (or the single host) and the provider there is a modem PPP connection. The “bubbles” with the thick border are the programs launched manually by the user; the remaining bubbles are the programs that are launched automatically. The circled numbers refere to the logical steps of the mail cycle:

1. In step (1) mail is downloaded from the provider’s POP server using fetchmail, which uses sendmail to put the messages in the user’s mailbox.

2. In step (2) the user launches mutt (or another MUA) to read mail, reply and write new messages.

3. In step (3) the user “sends” the mail from within mutt. Messages are accumulated in the spool area.

4. In step (4) the user calls sendmail to transfer the messages to the provider’s SMTP server, that will deliver them to the final destination (possibly through other mail servers.) The provider’s SMTP server acts as a relay for our mail.

Chapter 13 Mail and news The connection with the provider must be up only during steps (1) and (4); for the remaining steps it is not needed.

Figure 13-1. Structure of the mail system

mutt

sendmail

spool: /var/spool/mqueue sendmail

mailbox: /var/mail sendmail fetchmail

POP server SMTP server

provider

home

1 4

2 3

PPP link

Dans le document The NetBSD Operating System (Page 130-134)