|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Tuesday, 27 March 2001||Author: Jerry Kilpatrick|
|Published to: learn_articles_firststep/General||Page: 1/1 - [Std View]|
Getting Started with Network Services, Part 2
Now that you have Linux installed you may have the urge to configure some of your services. This article will be a basic guide to explain and help you understand what services are, how you should go about configuring the most important of them.
Now that you have Linux installed you may have the urge to configure some of your services. For instance, you may not need to have an FTP (File Transfer Protocol) server running if you don't plan on letting people download files from your computer over the Internet, or you may want to make sure your Web server is running. This article will be a basic guide to explain and help you understand what services are, how you should go about configuring the most important of them, and how your services are run. There are many different kinds of service that you can run on Linux. Here we shall look at the some of the most useful: daemons.
Not the spawn of Hell, a daemon is a type of service that once run, sits in the background and services requests (as in a request for a web page) from other machines across the network. An example of a daemon is Apache (a webserver). When you run Apache, or rather when Apache is run automatically at the time the computer boots up, it sits in the background and listens for requests for Web pages. When it gets one, it handles it and remains running, waiting for the next request. Other examples of this type of service are Sendmail, (Simple Mail Transfer Protocol server, commonly referred to as an SMTP server) and Bind (Domain Name System server, commonly referred to as a DNS server). Both of these examples, once they are run, sit unattended in the background and do their specific jobs. There is, however, a second way of running a network service.
Inetd itself is a daemon. However, its purpose is to wait for requests for various different services and then pass them on to the appropriate service program. An example of this is a connection to an FTP server. When a computer across the network tries to connect to the FTP server on your machine, inetd recognizes this connection as an FTP connection, and sends that request to the actual FTP server program you have designated. The benefit of running services in this way is that it takes up less system resources. The reason it takes less resources is; 1) because instead of having an FTP server, a POP3 (Post Office Protocol 3) server, and a UUCP (UNIX to UNIX Copy) service running all at the same time, each taking up its own share of memory, all you have is one server, inetd, running, only taking up memory for itself. When a request comes in, inetd spawns (another way of saying it runs another program) an FTP server and when it is done, all the memory and resources that the FTP server was using are availaible again.
Yes, in most cases using inetd is easier on the system, but programs like Apache are very robust and need to be run by themselves. For instance, Apache has the ability to remember who just connected to it and so serve web pages to each person faster. This would be impossible to implement with inetd sending requests to Apache, since Apache would run once and then die (another way of saying it does its job and then exits). Apache has to stay in memory as a daemon to be able to serve pages faster. Another reason why services like Apache need to be run independently is because Apache takes a while to load. When I say a while, I actually only mean just slightly more than a split second. It doesn't sound like much, but if you were running it each time you had a request through inetd, there would be enough of a delay to become annoying.
To fork or not to fork, that is the question. Forking is something a daemon does. Since I've been using Apache as an example the whole time, I might as well stick with it. I'll run through what Apache does when it receives a request for a Web page. Now, if Apache receives the request, and this instance, (meaning that specific process of Apache), handled the request by itself, it would not be able to take another request until it was done serving the first. This is when forking comes into play. When Aapache gets a request for a Web page, it forks itself, which means it creates another identical Apache process, a copy, if you will, of itself. This process - which is now called the 'child' - responds to the second the request. The 'parent', the original Apache process, is free to listen for more requests. That way, there is always an Apache waiting for requests, and it can respond to them immediately. When it comes time to respond to them, it creates a copy of itself and tells it to do the job. On a busy day a program like Apache will have quite a lot of child processes running at any given time.
So how do you go about configuring some of these services?
I can't exactly walk you through configuring all of your services in this article. However, I can show you how to find information about services and point yourself in the right direction to start learning how to configure many of them yourself. I shall start with inetd, since it is one of the most important daemons you will run.
I am only familiar with the original inetd, which I believe almost every Linux distribution uses. There have been a few inetd clones. (Clones being programs that do the same job but normally have different configuration files.) Here, I'm sticking to explaining the original and most widely used inetd's on all Linux distributions. Usually if you search through your startup scripts for 'netd' you will find which inetd you are running. The two configuration files you need to know about are /etc/inetd.conf, which is inetd's configuration file, and the other file is /etc/services. /etc/services is not part of the inetd program exactly, but it is used by inetd. Before I jump into configuring inetd, lets look at /etc/services.
Each line of /etc/service that doesn't start with a '#' (commonly referred to as a hash, a pound sign, or a comment) specifies the name of a port. In Linux or Unix if a line in a config file starts with a '#' it is ignored as if it didn't exist. Anyway, back to /etc/services! Each line without the '#' specifies the name of a port and the port's number. What's a port? A port is a numbered spot in a network connection that is used to differentiate a request for POP3, FTP, or whatever service you may be connecting to. TCP/IP (Transmission Control Protocoal/Internet Protocoal, the system the network uses for passing messages between computers) uses ports to distinguish what service the request is intended for. Examples? If I were to try to get my mail via POP3, I would connect to port 110 of the server that had my mail. And if you notice in /etc/services you should see something to the effect of:
pop3 110/tcp # POP version 3
Port numbers are assigned only by convention. This line tells your computer that POP3 is the name of the port, and the port number is 110. It also specifies that it is going to take either tcp or udp traffic. There are two different types of communicationing over TCP/IP: TCP and UDP. (Explaining TCP and UDP is a whole different article in itself, or even a rather fat book. For the time being, you don't really need to know the specifics of each of these anyway. They are simply different methods of passing packets of data between computers. I have been working in Linux for years, and I can't remember too many times where it actually mattered that I understood the difference between the two.) Regardless, in my example it shows that either TCP or UDP can use the name POP3 to get to port 110. All /etc/services is for is a way to associate a word to a number so you don't have to remember that POP3 is port 110 and that FTP is port 21. This information that is going to come in handy when you read inetd.conf.
When it comes to inetd.conf, all of the hard work is usually done for you. Most distributions normally have already put in all the services you would want to run, and then just used the '#' to comment them out. So if you want the service to run, just remove the '#' and restart inetd, or if you don't want the service to run, add a '#' to the beginning of the line and restart inetd. I'll use the POP3 service's line as an example:
pop3 stream tcp nowait root /usr/sbin/tcpd in.pop3d
Most of this information you don't need to know so I shall only touch on the very important things. The beginning of the line says POP3, this is in reference to the /etc/services. The POP3 could be replaced with 110 and it would run the same, but with /etc/services you can make it much more readable. Now, up until the /usr/sbin/tcpd there is some information that explains what type of protocol to use, what type of socket (a socket is the connection to a port), and what user ID the service is going to run as. In case you are worried that you might install a program that doesn't already have a line made for you in /etc/inetd.conf, don't worry. Any program you install that runs through inetd will have the specific configuration line you need to add to inetd in their documentation. Now the '/usr/sbin/tcpd in.pop3d' is what program inetd runs when it gets a the request for POP3. /usr/sbin/tcpd is often used. It is called a wrapper (a program that runs another program and makes sure it doesn't do anything it's not supposed to). In this case the program that the wrapper runs is in.pop3d: The the actual POP3 server.
You usually restart inetd with a HUP Signal. To 'HUP' a process means to send it a Signal that tells it to re-read is configuration file. This way you don't have to kill the process and start a new one. To find the process id, or pid, I suggest a command like 'ps ax | grep inetd'. I shall explain that command for you because you will find grep to be a very useful tool! The command starts with a 'ps ax', If you type this at your command prompt it will list all of your current running process and their process id's. By passing the result of that command through the program 'grep' with 'inetd' specified as the match string, your output will only display the lines of the ps command that have 'inetd' in them. Grep is like a search tool, or really a 'match' tool. Thus you should only see one line from this command and it should be inetd's information. (By the way, the | symbol is called a pipe, and it simply tells Linux to take the output of the first command and pour it into the input of the second command.) It may also return the process id of the 'grep inetd' (itself) since it too is a running process. Don't worry about that. Find the line that ends in something like /usr/sbin/inetd. At the beginning of that line is a number. That number is inetd's process id. In order to send a Signal to that process we have to use the program 'kill'. If you found that your inetd's process id is 122 then you would type 'kill -HUP 122' This would send the HUP Signal to process id 122, and inetd would re-read its configuration file and any changes you had made would take effect.
I would have to write an entire book, maybe two, to go through and explain how to configure every Linux service. I can, however, teach you how to find the information you need. This is where my favorite command 'man' comes in. If you have a service like POP3, as in the example above, the program that you need the information on is 'in.pop3d', as you saw in the inetd.conf file. So when you are logged into your machine just type 'man in.pop3d' and you will see an entire document with information about your POP3 server. Using the principles we've gone over here, and following the instructions in each man page, you should be able to get quite far in configuring services by yourself.
Any daemon that runs on its own normally has about 10 books written about it. Therefore, I can't really go into any deep explanations on these since they are much more complex. However, I can point you in the direction of the configuration files so you can look up the man page and play around with them on your own time. The most important daemons you'll want to run when you first create your Linux system are listed here. This list is not even a fraction of the total number of services a Linux/Unix machine will have. However, with this list, the man pages and a little help you should be well on your way to controlling your machine's services. Apache is the webserver, the normal configuration file is httpd.conf and the webserver itself is called httpd. These file (in Unix everything is a file, even an application) can be in different directories depending on your Linux distribution. I suggest a command such as 'locate httpd.conf' to find out where the files are located. Sendmail is another important standalone deamon. If you are not aware what SMTP is, it stands for "Simple Mait Transfer Protocol". That clears it up doesn't it? Just kidding. SMTP is used for sending outgoing mail messages to other computers and it's also how mail gets to your server. The 'sendmail' program itself could be installed in various places, and again I suggest, 'locate sendmail' to find it. However, the configuration files can usually be found in /etc/sendmail.cf and /etc/mail/. /etc/sendmail.cf is the main configuration file. The files in /etc/mail/ are usually for configuring smaller aspects of sendmail. The last major daemon that I should describe is Bind. Bind is a DNS (Domain Name System) server. DNS is the service that allows www.valinux.com to mean the same thing as 220.127.116.11. The numbers are called an 'IP address.' If we didn't have DNS all the commercials that have websites on them would read http://18.104.22.168/ instead of http://www.valinux.com/. The program for Bind is called 'named' and it's normally in /usr/sbin/. The main configuration file for named is /etc/named.conf. This named file calls a bunch of other files called zone files that are usually located in /etc/named or /var/named.
If you are going to be doing any major changes to the config files and want to really know what you are doing, I would suggest buying a book about that particular service/program. If you want a recommendation from me I would say an O'Reilly book is the way to go, but those are usually really techie books and some people don't like them. As long as the book is about the specific daemon you are running it should be sufficieant.
A small side note for those of you beginners. It's always good practice to make a backup copy of a working configuration file before you start messing with it. If you mess something up and it stops working, then all you have to do is replace the broken configuration file with your last working backup. Saves you some heart ache in the long run.
Stay tuned for the next article about terminology and key words so you can begin sounding like a true geek, and understand true geeks when they talk.