Introduction To Linux

Introduction to Linux Daemons
If users were using Linux, they would refer to these services as daemons. Novell refers to these services as Netware Loadable Modules (NLMs). Services, daemons, and NLMs all perform essentially the same tasks. They enable the operating system to provide functions like the Internet, file sharing, mail exchange, directory services, remote management, and print services. However, they work a bit differently in Windows as opposed to Linux or Novell.
The functions that are called services in Windows and Netware Loadable Modules (NLMs) in Novell are referred to as daemons in Linux. Examples of Linux daemons are FTPD and HTTPD. Daemons are not integrated into the operating system as services are in Windows. Daemons run as a background process. They run continuously without producing any visible output. For example, the FTP daemon (FTPD) will run in the background. As it processes incoming requests, it will send out files as needed, but it will not display anything on the screen. The activities of daemons are recorded on a log file. Many daemons can run on a Linux system at any given time. There are several common Linux daemons:
• HTTPD – This daemon is responsible for web browser requests.
• Inetd – This daemon will wait for an incoming request to be made and then forwards that request to the appropriate daemon.
• Crond – This daemon will run scripts at a specified time.
• Syslogd – This daemon will record information about currently running programs to the system log file.
Daemons can be loaded or unloaded into memory at any time. They can also be restarted without having to restart the entire system. Figure shows an example of the xinetd.d daemon being started. With Microsoft, the system must be rebooted when an application or service is installed. Both Novell and Linux can load, unload, and restart a daemon or NLM without requiring an administrator to reboot the system.


Starting,Stopping,and Restarting Daemons
Using Sys V Scripts to Start and Stop Linux Services and Daemons
Sys V scripts can be used to start, stop, or restart Linux daemons. The scripts are located in particular directories, most commonly in the /etc/rc.d/init.d or /etc/init.d directory. To execute these scripts, they need to be followed by options such as start, stop, or restart. The status option can be used on some scripts as well to get feedback on what the current state the daemon is in. For example, the following command will restart the Apache Web server daemon on a Red Hat 7.2 system.
# /etc/rc.d/init.d/httpd restart

There are some things that are important to know when manually starting or stopping a daemon this way.
First, depending on which distribution of Linux is being used, the exact name of the script may be slightly different. For example, in some distributions the Samba server uses the smb script and in others, it uses the samba script to manually start, stop, or restart the Samba daemon. Another instance in which the name of the start up script might not be standardized is when there are scripts that perform complex operations which start several other programs along with the program or daemon that is intended to be started with the script. The Network or Networking script is an example that is included in some distributions that is used to initialize many network functions.
Second, the Sys V startup scripts are designed to run on particular distributions of Linux. A Red Hat Sys V startup script will not work on other Linux distributions.
Third, it was mentioned before what a Failed message indicates when the script is executed. However, sometimes a script will execute and appear to be working correctly even though it is not operating correctly. If the daemon is not functioning properly check the log file, usually located in the /var/log/messages file. This log file can provide some indication of what errors are being generated.
Forth, it is always a good idea to read the specific daemons documentation for the different options that the script recognizes. This is because some scripts support different options than others. For instance, some daemons need to be restarted when a configuration change has been made. To do this, simply run the script with the restart option. Some scripts do not need to be restarted but rather they need to be completely stopped and then started again. Some daemons have commands that just reread the configuration without having to restart it.
Permanently Starting or Stopping a Daemon or Service with Sys V scripts
To be able to effectively start or stop a service or daemon running on a Linux system, a good understanding is needed of what runlevels are. Understanding how runlevels can be used to control what services, programs, and daemons the system automatically loads when the system starts up is also needed..
It was also mentioned previously in this section that the Sys V startup scripts that are used to temporarily start, stop, and restart daemon are located in the /etc/rc.d/init.d or /etc/init.d directory. There are also several directories within the Linux directory structure that contain symbolic links to these scripts. These symbolic links are associated with the different runlevels. When a Linux system is booted up into a specific runlevel, these symbolic links that are associated with a specific runlevel, reference the Sys V scripts to load services, programs, and daemons permanently. These directories that contain the symbolic links are typically named /etc/rc.d/rcx.d or /etc/rcx.d. The x is the specified runlevel number, which was covered.. The symbolic links in these directories contain files that execute the Sys V scripts when the system boots up into the corresponding runlevel. These file names are in the form of Kxxdaemon or Sxxdaemon, where xx is a two digit number and daemon is the name of the daemon. When the system enters a specified runlevel the Kxxdaemon and Sxxdaemon scripts are executed and the daemons or services that begin with S get the start command passed to them. The scripts that begin with K get the stop command passed to them. Therefore, daemon and services can easily be started or stopped permanently and automatically when the system boots up by renaming these scripts in the symbolic link directories with either an S or K. The two digit number represents the order in which the daemons or services are started or stopped. The system will execute the scripts with the lower number first. This can be important because some services should be started or stopped before others. For example, the Apache web server daemon should be started after the basic networking services have been started.
The xinetd.conf and xinetd.d Files
Sys V scripts are ideal for running daemons and services that need to be constantly running all the time. However, running these daemons and services permanently, take up valuable system resources and memory even when they are not being used. The xinetd.d file is what is known as a super-server. The main concept behind super-servers is to listen for requests for any of the daemons and services on the server. Then, load the daemon or service into memory only when a request has been made and it is in use. Until the request is made, the daemon would not be running or consume any memory. One problem with the super-server arrangement is that it can take a little more time to access the server. This is because the daemon or service needs to be loaded into memory first. The two types of super-servers that are used in Linux are inetd.d and xinetd.d. This course covers only xinetd.d because this is the super-server that is used in Red Hat 7.2. Red Hat did use inetd.d before switching to xinetd.d. The xinetd.d super-sever provides additional security features that are similar to TCP wrappers. Recall that TCP wrappers were covered in previous chapters. The xinetd.conf file, which is shown in Figure , is the configuration file that controls xinetd.d. The xinetd.conf file contains configurations and directives to files that are stored in /etc/xinetd.d. Each daemon and service that has been configured to run will install a file in /etc/xinetd.d with its own configuration options. The following sections describe how to configure individual servers for run using xinetd.d.

Using Custom Startup Scripts
There is yet another way to automatically start a daemon or service when the system boots up. By placing the proper text in the /etc/rc.d/rc.local script, it is possible to start any daemon or process. This script runs after the Sys V startup scripts run and loads what is specified in this script. This method may be practical to use when performance is an issue or when the daemon or server cannot be run in a Sys V startup script. For example, to start the Apache web server in the /etc/rc.d/rc.local script, which is shown in Figure , place the following line in the file:
/etc/rc.d/init.d/httpd start
It is important to understand that starting and running a daemon or service this way does not provide any means for stopping the service as can be done by using the stop command. The only way to stop a daemon that has been started by placing an entry in the /etc/rc.d/rc.local script is to use the kill or killall command after locating process ID (PID) number using the ps command.
Sys V scripts can be used to start, stop, or restart Linux daemons. The scripts are located in particular directories, most commonly in the /etc/rc.d/init.d or /etc/init.d directory
For example, the following command will restart the Apache Web server daemon on a Red Hat 7.2 system.
# /etc/rc.d/init.d/httpd restart
However, sometimes a script will execute and appear to be working correctly even though it is not operating correctly. If the daemon is not functioning properly check the log file, usually located in the /var/log/messages file.

Sys V startup scripts that are used to temporarily start, stop, and restart daemon are located in the /etc/rc.d/init.d or /etc/init.d directory.
These directories that contain the symbolic links are typically named /etc/rc.d/rcx.d or /etc/rcx.d.
These file names are in the form of Kxxdaemon or Sxxdaemon,
When the system enters a specified runlevel the Kxxdaemon and Sxxdaemon scripts are executed and the daemons or services that begin with S get the start command passed to them.
The scripts that begin with K get the stop command passed to them.

HTTP Daemon

The Linux NOS is not capable of providing the HTTP daemon to users.
Apache provides the same HTTP daemons for Linux that the Internet Information Services (IIS) tool does for Windows 2000.
Apache, like Linux, is available for download at no cost to users. Apache is available at http://www.apache.org.
Users of an HTTP enabled Linux system are typically given a special directory within their home directory for placing public web files.
The Windows 2000 FTP service may or may not be available by default, the Linux FTP service (FTPD) needs no configuring.


If a system administrator wishes to disable the service, a pound sign (#) can be placed at the start of the line.
Telnet allows a remote user to log in to a system for the purposes of issuing commands and accessing files using a Command-Line Interface (CLI).
Telnet was developed so that end users could access powerful mainframes from dumb terminals.
administrators use Telnet to remotely manage network servers, printers, and other devices. Figure illustrates a remote user that is using Telnet to manage remote devices.
Setting a password is often not enough. When a daemon is configured, such as Telnet, the server is forced to listen for requests
. Upon discovering that a server is listening for Telnet requests, a hacker can try to use brute force to break into a system.A brute force attack may involve using a program that guesses the password, using a dictionary as the source of its guesses.
If a hacker cannot break into the system using brute force, a listening server may still be vulnerable to Denial of Service (DoS) attacks.
DoS attack typically involves flooding a server with fake requests, preventing the server from replying to legitimate sources.
The Telnet protocol itself is not especially secure.
Telnet sends usernames and passwords in clear text, which can be read by other hosts on the network.
A more secure alternative to Telnet is Secure Shell (SSH).
There is a standard CLI command to open a Telnet connection to a remote computer:
telnet hostname | IP_address
For example:
telnet computer.company.com
or
telnet 123.45.67.90

The Server Message Blocks (SMB) protocol

The Server Message Blocks (SMB) protocol is designed to be a file sharing protocol. It has since been renamed to Common Internet Filesystems (CIFS) but is still used for file and printer sharing.
This protocol is used to allow non-Linux or UNIX systems to mount Linux filesystems and printers over the network.
The SMB protocol allows a Windows client to do this the same way as if they were connecting to another Windows system.
Use commands to transfer files and obtain file and directory listings the same way as if connected using FTP with the dir, get, and put commands.
However, SMB/CIFS was intended for direct access for file sharing and using the smbmount utility.
The syntax is similar to the smbclient command. For this,the location of the Linux mount point needs to be added to the command.
Then, to add a password for the user, use the smbpasswd command. The syntax for this command is as follows:
# smbpasswd –a jsmith
In this command, replace server with the hostname of the server.Keep in mind that regular users will not be able to use the mount command by default.
Recall that by editing the /etc/fstab
Specifically, the following line would need to be added to this file:
server:/home/jsmith/mnt/xxx nfs user,noauto,exec 0 0