|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|Recommended Books||Recommended Links||Runlevels||init.d scripts||Xinetd|
|service||YaST||Admin Horror Stories||Humor||Humor||Etc|
Most Linux distributions include the chkconfig command for managing runlevel services. The syntax for chkconfig is specified in the chkconfig man page.
For example, use chkconfig to configure the OpenSLP daemon, slpd, to start in runlevels three and five only. Do the following:
1. Check if slpd is on in the current runlevel
# chkconfig slpd
2. Check slpd's configuration for every runlevel.
# chkconfig -l slpd
slpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
3. Turn slpd on in runlevels three and five.
#chkconfig slpd 35chkconfig - updates and queries runlevel information for system services
chkconfig --list [name]
chkconfig --add name
chkconfig --del name
chkconfig [--level levels] name <on|off|reset>
chkconfig [--level levels] name
chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.
This implementation of chkconfig was inspired by the chkconfig command present in the IRIX operating system. Rather than maintaining configuration information outside of the /etc/rc[0-6].d hierarchy, however, this version directly manages the symlinks in /etc/rc[0-6].d. This leaves all of the configuration information regarding what services init starts in a single location.
chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, changing the startup information for services, and checking the startup state of a particular service.
When chkconfig is run without any options, it displays usage information. If only a service name is given, it checks to see if the service is configured to be started in the current runlevel. If it is, chkconfig returns true; otherwise it returns false. The --level option may be used to have chkconfig query an alternative runlevel rather than the current one.
If one of on, off, or reset is specified after the service name, chkconfig changes the startup information for the specified service. The on and off flags cause the service to be started or stopped, respectively, in the runlevels being changed. The reset flag resets the startup information for the service to whatever is specified in the init script in question.
By default, the on and off options affect only runlevels 2, 3, 4, and 5, while reset affects all of the runlevels. The --level option may be used to specify which runlevels are affected.
Note that for every service, each runlevel has either a start script or a stop script. When switching runlevels, init will not re-start an already-started service, and will not re-stop a service that is not running.
chkconfig also can manage xinetd scripts via the means of xinetd.d configuration files. Note that only the on, off, and --list commands are supported for xinetd.d services.
Each service which should be manageable by chkconfig needs two or more commented lines added to its init.d script. The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list. The second line contains a description for the service, and may be extended across multiple lines with backslash continuation.
For example, random.init has these three lines:
# chkconfig: 2345 20 80 # description: Saves and restores system entropy pool for \ # higher quality random number generation.This says that the random script should be started in levels 2, 3, 4, and 5, that its start priority should be 20, and that its stop priority should be 80. You should be able to figure out what the description says; the \ causes the line to be continued. The extra space in front of the line is ignored.
As stated earlier, the chkconfig command can be used to adjust which daemons start at each runlevel. You can use this command with the --list switch to get a full listing of daemons listed in /etc/init.d and the runlevels at which they will be on or off:
# chkconfig --list keytable 0:off 1:on 2:on 3:on 4:on 5:on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off wlan 0:off 1:off 2:on 3:on 4:on 5:on 6:off sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off random 0:off 1:off 2:on 3:on 4:on 5:on 6:off ... ...
You can use chkconfig to change runlevels for particular packages. Here we see sendmail will start with a regular startup at runlevel 3 or 5. Let's change it so that sendmail doesn't startup at boot.
The chkconfig command can be used with grep to determine the run levels in which sendmail will run. Here we see it will run at levels 3 and 5.
# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off #
The chkconfig command with the --level switch indicates that some action needs to be done at the runlevels entered as its values. The first argument in the command is the package you want to affect and the second defines whether you want it on or off. In this case we want sendmail not to be started when entering runlevels 3 and 5:
# chkconfig --level 35 sendmail off #
By not specifying the runlevels with the --level switch, chckconfig will make the changes for runlevels 3 and 5 automatically:
# chkconfig sendmail off
Because the intention is to permanently shutdown sendmail permanently, we might also have to stop it from running now.
# service sendmail stop Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ] #
We can then use chkconfig to double-check our work.
# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off #
To reactivate sendmail, we can use chkconfig once more, but with the on argument. Start sendmail again to get it running immediately, not just after the next reboot.
# chkconfig sendmail on # chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off # service sendmail start Starting sendmail: [ OK ] Starting sm-client: [ OK ] #
A default Fedora installation automatically starts a number of daemons that you may not necessarily need for a Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.
The screen output of the netstat -an command below shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?
# netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 :::22 :::* LISTEN udp 0 0 0.0.0.0:32768 0.0.0.0:* udp 0 0 0.0.0.0:930 0.0.0.0:* udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* ... ... #
For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command which lists all open, or actively used, files and can be given additional options to extend its scope to include the TCP/IP protocol stack.
In the next examples we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd and ntp daemons respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS", and 30, "Configuring NIS". portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. NTP, which is covered in Chapter 24, "The NTP Server", is required for synchronizing your time with a reliable time source, and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and xinetd", and it might be required for their operation:
# lsof -i tcp:111 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME portmap 1165 rpc 4u IPv4 2979 TCP *:sunrpc (LISTEN) [root@ bigboy tmp # # lsof -i tcp:32769 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME xinetd 1522 root 5u IPv4 2764 TCP probe-001:32769 (LISTEN) # # lsof -i udp:123 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ntpd 1321 ntp 4u IPv4 3390 UDP *:ntp ... ... #
In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently.
# lsof -i tcp:32768 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME rpc.statd 1178 rpcuser 6u IPv4 2400 TCP *:32768 (LISTEN) # ls /etc/init.d/rpc.statd ls: /etc/init.d/rpc.statd: No such file or directory # grep -i statd /etc/init.d/* /etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0 ... ... #
As a rule of thumb, applications listening only on the loopback interface (IP address 127.0.0.1) are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address 0.0.0.0, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shutdown nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers", for details). Your needs may be different.
Remember to thoroughly research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books and the Internet for information. Unpredictable results are always undesirable.
Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.
Remember the following:
Google matched content
init(8) ntsysv(8) system-config-services(8)
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019