As long as it is a Linux system, no matter what the release, network configuration, and system global design have the following core system services: init, inetd, syslogd, and cron. These services are relatively simple, but they are also the foundation of other operations. If you don't have them, Linux will not have the power now. This article will be introduced one by one for each core system service, the corresponding profile, and recommended application methods (if any). We strongly recommend: Be sure to spend some time to familiarize with the implementation principle of these services. By using these services, people have designed a lot of creative problem solutions. The init service init process is the initiator and controller of all processes. Because in any UNIX-based system (such as Linux), it is the first process of running, so the number of the init process, PID is always 1. If INIT has problems, the rest of the system will fall. There are two roles in init processes. The first role is to play the role of the end of the parent process. Because the init process will never be terminated, the system can always be confident that it exists and it is referred to when necessary. If a process is terminated before it is ended, it will appear to be referred to in init. At this point, those who have lost their parent processes will be in init as their parent process. Quickly execute the ps -af command, you can list the process of many parent process ID, PPID to 1. The second role of init is to run the corresponding program when entering a particular run level, and manages various run levels. Its role is defined by the / etc / inittab file. 1. / etc / inittab file / etc / inittab file includes all INIT startup run levels necessary. The format of each row statement in this file is as follows: ID: Runlevels: Action: Process Note: The statement starting with # is a comment statement. Look at your own / etc / inittab file, you can find a lot of comment statements. If you really need to make any changes to the / etc / inittab file (generally do not have this situation), remember to add some comment statements, explain why you want to make those modifications. 2. Telinit command notifies init when switching the mysterious power of the system running level is actually a telinit command. This command has two command line parameters: a parameter is used to notify the init to prepare to switch the run level; the other is -tsec, where the sec is to wait for the time before notifying init. Note: Do INIT is really handover running level is determined by itself. Obviously, it is often switched, otherwise this command will not be useful. In most UNIX operating systems (including Linux), the Telinit command is actually just a symbolic link to the init program. Based on this, many people prefer to switch directly to the run level they want to go directly instead of using Telinit. In a person concern, I found that it is more convenient to understand and memorize using Telinit switching.
The inetd process inetd program is a daemon. You may already know that the daemon is some special programs: They voluntarily abandon the control of calling their own terminals after being started. The daemon is only the interprocess communication, IPC) channel, or the LOG file relying on the system's global log file can be sent to the system. Inetd's role is a "super server" as a process related to network servers as Telnet and FTP. This is a simple truth: not all server processes (including those who accept new Telnet and FTP connections) will be called so frequently, so that there must be a program to run in memory at any time. Therefore, in order to avoid that there may be dozens of services are used to run in memory, they are listed in the Inetd profile /etd.conf. Instead of their inetd monitors entering the connection. This only needs a process to be in memory. Another advantage of inetd is that the programmer does not want to write the process that needs to be connected to the system. The inetd program will handle network code and passes the entry network data stream as standard input (Standard-in, ie stdin). The output of these processes will be sent back to the host connected to the process. Note: Unless you are programming, you don't need to connect to the inetd's stdin / stdout function. On the other hand, if someone intends to prepare a simple command script and let it appear in the network, it is worthy of in-depth research. 1.etc / inetd.conf file ETC / inetd.conf file is an inetd configuration file. Its structure is simple: each line statement represents a service. The format of the service definition statement is as follows: SRVCE_NAME SOCK_TYPE PROTOCOL [NO] WAIT USER SRVR_PROG SRVR_PROG_ARGS 2. Security and inetd.conf file You will find that many services open in the default case in most Linux installations. of. If your system will open to the Internet (including the Point Protocol through the dial-up point), the first thing you want to do will close everything! Never assume that because your system does not promote publicity, others will not find it. From the opposite direction, it is easy to find and easily used by the tool software to find a security attack hidden system. The first step of the shutdown service is to change all the service notes in the etc / inetd.conf file to a comment statement. In general, you will find that the following methods are easier to use: First turn all things to comment statements (completely closing the network service), and then selectively open the required services. After completing the modification of the etc / inetd.conf file, you need to report its configuration file to the daemon to have been modified. This is achieved by sending a HUP signal to the daemon. First use the following command to identify the process ID corresponding to inetd.conf: [root @ ford / root] # ps auxw | grep inetd | grep -v grep inetd | The output of this command is similar to the following: Root 359 0.0 0.1 1232 168? The second column in the S JUN21 0: 00 inetd output tells us that the process ID (here is 359). In order to send HUP signals, we need to use the kill command (how much misleading this program is called KILL. In fact, it just sends a signal to the process. By default, it will issue a request for a request to terminate the running of a program.
Below is a method for sending a HUP signal using a kill command: $ kil -1 359 should change 359 in the above command to process numbers from your system. The syslogd daemon will have a lot of things at the same time, while the network service that is disconnected in the terminal window is even more so. Therefore, it is necessary to provide a standard mechanism for recording special events and messages. Linux uses the syslogd daemon to provide this service. The syslogd daemon provides a standard method for recording system activity and messages. Many other types of UNIX operating systems also use a compatible daemon. This provides a method of crossing the platform in the network. In a large network environment, this is more value. Because in such an environment, it is necessary to collect various recorded data to obtain the accuracy of system operation. You can compare this record function subsystem as the systemlogger for Windows NT. Syslogd Save Data Record files are concise text files, which are generally stored in the / var / log subdirectory. Each data item constitutes a row, including the date, time, hostname, process name, process PID, and messages from the process. A global function in the standard C-function library provides a simple mechanism for generating record messages. If you don't like writing program code, you want to generate data items in your log file, you can choose to use the logger command. It is conceivable that the tool like syslogd should be started as part of the boot boot command script program. You are ready to have a Linux release version that is used in a server environment. 1. Call syslogd If you need to manually start Syslogd, or start the command script when you need to modify the boot boot, you must pay attention to the command line parameters of syslogd, please refer to the book, here don't make a detailed introduction. The 2./etc/syslog.conf file /etc/syslog.conf file contains configuration information that syslog needs to be run. The format of this file is somewhat unusual, but the existing default profile will be sufficient to meet usage, unless you need to find specific information in a specific file, or you need to send this information to the remote recording computer. ● Record information classification Before we master the /etc/syslog.conf file format itself, you need to learn how to learn how to classify. Each message has a function value (facility) and a priority. Function value tells us which sub-system is generated by this message, and priority tells us how important this news is. These two values are separated by the junctions and have an equivalent string so that it is easy to remember. ● The format of the /etc/syslog.conf file is below the format of each statement in the configuration file: Facility / Priority Combinations Separated by Commas file / process / host to log to log to log to log to logs: kern.info / ver / log / kerned syslogd is OK Flexibly sends a record message to a variety of different save destinations. It can save the message as a file, send the message to the FIFO queue, send it to a group of users, or in the case where the log is recorded in a large site, it is sent to a central recording host. In order to distinguish these destinations, the following rules are used in the destination portal: ◆ If the start character of the save destination is the slash character (/), the message will be sent to a file. ◆ If the start character to save the destination is a vertical character (|), the message will be sent to a FIFO queue. ◆ If the start character of the save destination is "@" character, the message will be sent to a host.
The cron program allows any user in the system to arrange a program at any date, time on time, time can be accurate to minutes. Using cron is an extremely effective way to automate, periodically generate reports, and perform other periodic tasks. Like other services we have already discussed herein, cron is started by the boot boot command script, and should be configured. A quick check of the process list can see it silently running in the background. The working principle of CRON service is: Wake up every other minute and check each user's crontab file. The content of this file is the list of events that the user wants to execute at certain time. Any activity that matches the current date and time will be transferred. The cron command itself does not require any command line parameters, nor does it require something signal to indicate changes in its status. The setting item used to edit the execution by cron is crontab. Its principle is: Verify that you have permissions to modify the cron settings, then transfer to a text editor to make you modify. After the modification is complete, CRONTAB places the file in the correct location and brings you back to the prompt. Whether you have the right permissions is determined by crontab by checking /etc/cron.allow and /etc/cron.deny. Regardless of which of these two files, only when you are explicitly listed in it, you can take your operation. For example, if the /etc/cron.allow file exists, only when your username is listed in this file, you can allow you to edit the cron data item. On the other hand, if the /etc/cron.deny file does not exist, the /etc/cron.allow file does not exist, as long as your username does not appear in this file, it indicates that you can edit your CRON data item. The format of the cronjobs file (usually referring to the crontab file) is shown below: Minute Hour Day Month Dayofweek Command, all values must be an integer. If you plan to set multiple values on a column (such as: intended in the morning 4: 00, 0: 00 and 5: 00 in the morning, running the same program), you need to use the time data in the corresponding column Separate, but no spaces can be added in this column. For the case of running the same program three times in the morning 4: 00, noon 12: 00 and 5: 00, the HOUR column should be 4, 12, 17. In the DayOf Week data item, value 0 indicates Sunday, 1 means Monday, so that it is so much until 6 means Saturday. If an asterisk (*) wildcard appears in a data item, you represent any minutes, hours, dates, months or days of the corresponding column. When the date and time in the file meet the current date and time, the commands set in this line statement will run the identity of the data item user, and any output generated will return to the way e-mail. That user. Obviously, this may cause full mailbox full, so it is important to make a rapid response to mail reports. A good way to control the message quantity is: only output an error, and those who are inevitable are sent to the / dev / null device. Let's see some examples.
The following data item runs every four hours / usr / bin / ping zaphod command: 0 0, 4, 8, 12, 16, 20 * * * / usr / bin / ping zaphod below the data items every Friday 10: 00 running program / usr / local / scripts / backup-level-0: 0 22 * * 5 / usr / local / scripts / backup_level_0 Finally, the following data items are on April 1 (regardless of the week Morning 4: 01 points issued an e-mail: 1 4 1 4 * / bin / mail dad@domain.com
