comp075 os2 managing linux services. services? services are processes that start, usually when the...
Post on 21-Jan-2016
217 Views
Preview:
TRANSCRIPT
COMP075 OS2
Managing Linux Services
Services?
• Services are processes that start, usually when the system starts, and run, usually, until the system stops
• These processes often provide a service of some sort to other processes through a client-server relationship and some form of IPC (Inter Process Communication)
• Some, like the components of the network protocol stack, and the X windows system perform functions for the system as a whole.
Starting ServicesMany Different Approaches
• Unix System 5 (SysV), introduced in the mid 1980's, introduced a method of starting services called SysV init
• Until recently this was the dominant architecture used in most linux variants
• Others were used less widely
• Systemd is a new emerging standard method that is slowly being adopted by the major linux distributions
• We will look at both systems
Starting Services (SysV init)
• Services can be started manually by running their associated init script with an appropriate parameter
• But given the number of needed services, this needs to be automated
• The run levels concept makes automatic service initialization easier to configure, and a little bit flexible
• The init process starts first and then starts init scripts according to the default run level
Run Levels• A run level is basically a directory containing softlinks
into a collection of scripts
/etc/init.d/rc3.d or /etc/rc3.d for run level 3
• The linked scripts start or stop services for that run level
• The init process runs the scripts when that run level is 'entered' (or 'left')
• Names of scripts cause services to start or stop in a specified sequence
– K03dbus
– S09ntp
What Run Levels?
• Only really standard levels are 0, 1 and 6
– Halt, Single User and Restart
• Many systems also use
– 2 multi-user
– 3 multi-user with networking
– 5 full GUI system
• But it depends on the way the system is configured
– In Kali and Debian the default level, 2, is a full GUI system
Start/Stop (init) Scripts
• init scripts are bash scripts that use a case statement to start or stop a service depending on a parameter (verb) passed to the script
• Most can handle start, stop and status
• Usually contained in /etc/init.d
/etc/init.d/postgresql status
– Gets the status of the postgresql service
• Many scripts can also handle restart
• /etc/init.d/rc3.d or /etc/rc3.d will contain softlinks to scripts in /etc/init.d
Linux Standard Base init Scripts
• According to the LSB, init scripts should always handle start, stop, restart, force-reload, and status
– Restart starts if not running already
– Force reload restarts if service doesn't understand reload
• Optionally reload and try-restart
– Try-restart only restarts if service already running
• Scripts should behave reasonable in situations like starting a service that is already running
Configuring Run Levels
• Services can be added to a run level by creating softlinks to the service's init script in the /init.d/rcX.d/ directory for run level X
• This is not easy: must follow naming conventions
– K03dbus• Kills dbus
– S09ntp• Starts ntp
– Numbers (03 09) force scripts to run in a predetermined sequence
AutomaticallyConfiguring Run Levels
• When packages or entire linux systems are installed:
– init scripts are written to /etc/init.d and
– softlinks to them are placed in the /etc/init.d/rcX.d directory
• This configuration is based on standard init info comments placed in the init scripts by the service developers
init info Comments
• Near the start of the script
• Delimited by the lines:
### BEGIN INIT INFO
### END INIT INFO
• Formatted comment lines then provide the init information
– What run levels to start in
– What sequence to start in
Standard init info Dependency Comments
• Service start sequence is based on dependencies between services specified by:
Provides: service-name …
Required-Start: service-name …
– Must be available during start up
Required-Stop: service-name …
– Must be available during shut down
Should-Start: service-name …
Should-Stop: service-name …
Processing Dependency Comments
• Dependency information has no effect at run time
– Is not checked
• Information is used to sequence the execution of the scripts by devising appropriate names for the softlinks in the run level directories during installation
/etc/init.d/rc3.d/S02network
– Starts the network before starting
/etc/init.d/rc3.d/S03syslog
Run level init comments
• init info comments are used to specify the standard run levels to install the service in
Default-Start: run level 1 [run level 2...] Default-Stop: run level 1 [run level 2...]
• Indicate run levels to start or stop the service
• There are also
• Short-Description
– Limited to a single line of text.
• Description
– Multi-line description
Manually Configuring Run Levels• Creating the appropriate softlinks is not meant to
be done manually
• chkconfig command allows for manual installation of a service in a run level
chkconfig
– Lists services with off/on status
-l shows each run level
service 35 sets service to start in levels 3 and 5
service on starts service in default levels
• Most distributions also have a gui for this purpose
Configuring with update-rc.d
• On kali the command update-rc.d performs functions like chkconfig (or you can install chkconfig)
• Only works if the service has not already been installed
update-rc.d remove|defaults
update-rc.d enable|disable S|2|3|4|5
The init Program
• First program run at system start up is called init
• It is responsible for starting services based on run levels
• Runs the init scripts pointed to by softlinks in /etc/init.d/rcX.d (or /etc/rcX.d)
• Controlled by /etc/inittab
• Is the parent process of all other processes
inittab
• Contains the default run level
id:3:initdefault:
• Line format is
id:runlevel(s):action:process
• id is somewhat arbitrary but conventional
• Action is sometimes an action type, sometimes an event that will trigger an action
• Process is usually a script to run
inittab examples
• l3:3:wait:/etc/init.d/rc 3
– When runlevel 3 is reached runs rc script with parameter '3' and waits for completion
• ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
– Runs shutdown command when Ctrl-Alt-Del is pressed
• 5:2345:respawn:/sbin/mingetty tty5
– Starts terminal on console 5 (/dev/tty5) in runlevels 2345 and respawns if it stops
Problems with init and Run Levels• Serial execution
– Services don't start in parallel making for longer boot time
• Large complicated init scripts
• Run level idea has limited flexibility
• Doesn't respect dependencies at init time
– Only when services are installed are dependencies consulted and then only to determine startup sequence
• Only invoked at startup (or manually)
– Limited ability to respond to events
Replacements for init
• Lots of not very widely used replacements have been tried
• Some are working:
– Service Management Facility
• Solaris 10 and on
– Launchd
• Mac OS X v10.4
– Upstart
• Ubuntu
– Systemd
• Suse 12.1 kali 2.0 and others
systemd
• Well defined dependencies
• Dependencies allow for safe parallel starting of daemons
• Avoids overhead of bash scripts
– Init requirements specified in declarative config files
• Unix domain sockets and D-Bus for IPC
– Allows closer monitoring of processes
• Aims to replace a lot of linux components
– cron, syslog, atd, udev …
– Some say too many
d-bus
• An IPC mechanism
• Includes a system daemon and per user daemons
• User daemons enable desktop applications to communicate conveniently
• System daemon can be used to ease interaction with processes such as system services
• d-bus presents an object interface to senders and receivers using objects located in the daemons
What does systemd do?
• mounting your disks (checking for errors if needed),
• starting the firewall and other security tools,
• starting services
• connecting the network and networked filesystems
• starting the graphical system and the login manager which brings you to your desktop
Targets and Units
• Instead of run levels there are targets
– When a target is started systemd starts everything the target needs
– Old style run levels are represented as targets in systemd
• Instead of services there are units
– A more general concept
– Allows services to be dependent on hardware units for example
– Targets are a type of unit
Types of Units
• Config file names are name.type
– service
– socket
– target
– device
– mount
– automount
– timer
– others
Unit Files Locations
• /lib/systemd/system
– Installed packages
• /run/systemd/system
– Created from templates at runtime
• /etc/systemd/system
– Local configs, override the above
• These unit files are used in system mode
– Like at startup
• Other files are used in user mode
User Unit Paths
• /usr/lib/systemd/user
• $HOME/.local/share/systemd/user
• /run/systemd/user
• /etc/systemd/user
• $HOME/.config/systemd/user
• Some others
Unit File Contents
• Many options
• Description=
• Documentation=
• Requires=
• RequiresOverridable=
• Before=, After=
• OnFailure=
Using sytemd
• Changing runlevel
– systemctl isolate runlevel5.target
– isolate means stop everything else
• Current runlevel
– systemctl list-units –type=target
– Only if your system uses targets to emulate run levels
• systemctl start sshd
– Starts sshd service
Using sytemd
• systemctl status sshd.service
• service command will still work but transfers request to systemctl
– service sshd status
• systemctl disable mysql.service
• systemctl enable mysql.service
• chkconfig still works in Suse but transfers to systemctl
• systemctl reboot/halt/poweroff/...
Compatibility
• Your system may have removed the SysVinit files from /etc/init.d
– If so you can't run these scripts directly
– But you shouldn't anyway
– Use of service will invoke systemctl for you
• If you do have these scripts, the dependency comments matter and will be respected by systemd
• And the init scripts have to follow standards
Compatibility
• runlevel command may produce odd results
hermes:/home/cmb # runlevel
N 3
– Actually running in level 5
• chkconfig may not work accurately
– OK in Suse
• But default levels 2 3 and 4 are identical
Some Fun
hermes:/home/cmb # systemd-analyze time
Startup finished in 10114ms (kernel) + 52972ms (userspace) = 63087ms
hermes:/home/cmb # systemd-analyze blame
16171ms ntp.service
13286ms metasploit.service
6402ms systemd-modules-load.service
3386ms ossec.service
….
References
• Man pages for init, inittab, chkconfig, service
• Man pages for systemd system
– http://www.freedesktop.org/software/systemd/man/
• An intro
– http://www.freedesktop.org/wiki/Software/systemd/
• Init script
– http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html
• D-bus– http://www.freedesktop.org/wiki/Software/dbus/
top related