applied linux.

Chapter 5 of 9

System Services

On this page

init

The init process is the first process that runs when a Linux system boots up. It is responsible for bringing the system up to a usable state by starting various system services and configuring hardware. Historically, Linux used SysVinit (or simply init) as the default init system.

SysVinit and rc Files

SysVinit follows a traditional approach, where system services are started and stopped according to predefined runlevels (numbered from 0 to 6). Each runlevel corresponds to a different state of the system, such as single-user mode, multi-user mode, or reboot.

Runlevels:

  1. Halt the system.
  2. Single-user mode (maintenance).
  3. Multi-user mode without networking.
  4. Multi-user mode with networking (CLI).
  5. Unused/custom (optional configuration).
  6. Multi-user mode with networking and GUI.
  7. Reboot the system.

In traditional SysVinit-based Linux systems, runlevels are used to define different states of the system, specifying what services and processes should be running. Each runlevel is represented by a number from 0 to 6, and each corresponds to a specific mode of operation for the system.

Here’s a breakdown of all six runlevels:

Runlevel 0: System Halt

  • Purpose: Shuts down the system.
  • Details:
  • When the system enters runlevel 0, it terminates all running processes, unmounts filesystems, and powers off the machine. This runlevel is equivalent to the shutdown command.
  • It’s used when the system needs to be turned off safely.

Runlevel 1: Single-User Mode

  • Purpose: Maintenance mode.
  • Details:
  • This runlevel is also known as “single-user mode” or “rescue mode.” It’s typically used for system maintenance tasks that require exclusive access to the system without other users logged in.
  • Only the root user is allowed to log in, and networking services are usually disabled.
  • The system does not start any multi-user services, like network daemons or a graphical interface.
  • It is often used for repairing filesystems, resetting passwords, or troubleshooting system issues.

Runlevel 2: Multi-User Mode without Networking

  • Purpose: Multi-user mode with no networking.
  • Details:
  • Runlevel 2 brings the system into a multi-user environment but without network services (like NFS, SSH, or web servers).
  • Multiple users can log in, and the system runs most non-network-related services.
  • This runlevel is more relevant to older systems, as modern distributions often configure networking to be active at this level.

Runlevel 3: Multi-User Mode with Networking

  • Purpose: Full multi-user mode with networking.
  • Details:
  • This is the standard runlevel for most servers and non-graphical workstations.
  • It enables all multi-user services, including network services. Users can log in from the console or remotely via SSH.
  • It does not start a graphical user interface (GUI); the system remains in a command-line interface (CLI) environment.
  • Runlevel 3 is often used on servers or systems where a GUI is unnecessary.

Runlevel 4: Unused/Custom

  • Purpose: Undefined or custom.
  • Details:
  • Traditionally, runlevel 4 is left undefined or unused, offering a space for system administrators to configure a custom runlevel that suits their specific needs.
  • On some systems, it can be configured to launch a specific set of services or run a particular application without affecting other runlevels.
  • Due to its undefined nature, the behavior of runlevel 4 can vary depending on the system’s configuration.

Runlevel 5: Multi-User Mode with Networking and GUI

  • Purpose: Multi-user mode with networking and graphical interface.
  • Details:
  • Runlevel 5 is similar to runlevel 3 but includes the starting of a graphical display manager, such as GDM, LightDM, or KDM, which brings up the system’s graphical user interface (GUI).
  • This is the default runlevel for most desktop distributions where a graphical environment is needed.
  • Users can log in via the GUI, and all networking services are enabled.

Runlevel 6: Reboot

  • Purpose: Reboots the system.
  • Details:
  • When the system enters runlevel 6, it shuts down all processes, unmounts filesystems, and then reboots the system.
  • This is equivalent to the reboot command.
  • Administrators can use this runlevel to restart the system after applying updates, configuring new software, or making changes that require a reboot.

Managing Services with Init

Although init is less commonly used today, some systems or specific environments might still require you to manage services with it. Here’s how you can manage services using the init system:

  • Starting and Stopping Services:
  • To start a service: service [service_name] start

  • To stop a service: service [service_name] stop

  • Checking Service Status:

  • You can check the status of a service with: service [service_name] status

For example, to start the Apache web server service using init, you would use: service httpd start

rc Files

The services that start or stop in each runlevel are controlled by shell scripts located in directories named /etc/rc.d/ or /etc/rcX.d/, where X represents the runlevel. Each script in these directories is a symbolic link to the actual service scripts in /etc/init.d/. The naming convention of these scripts (e.g., S01service for start and K01service for kill/stop) determines the order in which services are started or stopped.

Systemd

Systemd is the modern system and service manager that has largely replaced the traditional init system in many Linux distributions. It is known for its advanced capabilities, efficiency, and the ability to handle complex dependencies between services. Systemd is now the default in most major Linux distributions, including Ubuntu, Fedora, and CentOS.

Key Features of Systemd

  • Parallel Service Startup:

  • One of the standout features of systemd is its ability to start services in parallel. This means that instead of starting services one by one (as was the case with init), systemd can launch multiple services simultaneously. This significantly reduces the time it takes for the system to boot up.

  • Dependency Management:

  • Systemd uses a sophisticated dependency-based model to manage the order in which services start and stop. Each service is defined by a unit file (typically found in /etc/systemd/system/), which includes information about the service’s dependencies. This ensures that services are started in the correct order, preventing issues where a service fails because another service it depends on has not yet started.

  • State Tracking:

  • Systemd continuously tracks the state of all services, providing detailed information about their status, health, and recent activity. This allows system administrators to quickly identify and troubleshoot issues. For instance, if a service fails to start, systemd will log the reason and make it easy to diagnose the problem.

Managing Services with Systemd

As a system administrator or developer, you’ll frequently interact with systemd to manage services. Here’s how you can perform some of the most common tasks:

  • Starting and Stopping Services:
  • To start a service: systemctl start [service_name]

  • To stop a service: systemctl stop [service_name]

  • Enabling and Disabling Services:

  • Enabling a service configures it to start automatically at boot:

    systemctl enable [service_name]

  • Disabling a service prevents it from starting at boot:

    systemctl disable [service_name]

  • Checking Service Status:

  • You can check whether a service is running, see its current status, and view recent logs by using:

    systemctl status [service_name]

For example, to check the status of the Apache web server service (httpd), you would use:

  • systemctl status httpd

What does HTTPd do anyways?

In general terms: - HTTP is the communication protocol between a client (browser) and a server. - HTTP defines how the communication happens.

  • HTTPd is the web server software (the program running on the server) that processes and responds to those HTTP requests.
  • HTTPd is the software that enables the server to handle the communication.

HTTP (Hypertext Transfer Protocol)

HTTP is the protocol used for transferring hypertext requests and information on the web. It defines how messages are formatted and transmitted, and how web servers and browsers should respond to various commands. In simpler terms, HTTP is the “language” that allows your web browser to communicate with a web server to fetch and display a webpage.

  • When to use HTTP: You use HTTP whenever you’re interacting with a webpage or web resource. For instance, when you type a URL into your browser, it uses HTTP (or HTTPS, the secure version of HTTP) to request the webpage content from a server.
  • Why it’s important: HTTP provides the structure for data exchange on the web, enabling the retrieval of websites, documents, and media files by specifying how data is requested and received between a client (browser) and a server.

HTTPd (HTTP Daemon)

HTTPd, short for HTTP daemon, is a software application that runs on a server to handle HTTP requests. A “daemon” in computing refers to a background process that listens for requests and responds to them—essentially a server application. The most common example is Apache HTTPd, which is a web server that handles incoming HTTP requests and serves web pages or other content.

  • When to use HTTPd: You need an HTTPd when you are setting up a web server to handle incoming requests for web content. If you want to host a website or provide a service over the web, you need an HTTP daemon to manage these requests.
  • Why it’s important: HTTPd is crucial for making content accessible over the web. Without an HTTP daemon, your server wouldn’t be able to listen for incoming requests or serve any content in response. HTTPd ensures that the communication between your server and the client (user’s browser) functions correctly.

HTTP Protocol

HTTP, which stands for “Hypertext Transfer Protocol,” is the foundation of communication on the web. It’s a protocol that defines how data is transmitted between a client (like a web browser) and a server (where websites are hosted). Here’s a breakdown of how the HTTP protocol works:

  1. Client-Server Model: HTTP follows a client-server model. The client (usually a web browser) initiates a request, and the server (where HTTPd is running) responds to that request.

  2. Requests and Responses: - Request: When you visit a website, your browser sends an HTTP request to the server. This request includes a method (like GET or POST), a URL, and possibly some additional data (like form submissions). - Response: The server processes this request and sends back an HTTP response. This response includes a status code (like 200 for success or 404 for not found), headers with metadata, and the content itself (like an HTML page, image, or video).

  3. Stateless: HTTP is a stateless protocol, meaning each request from a client to a server is independent. The server doesn’t remember previous requests, which is why things like sessions and cookies are used to keep track of users across different requests.

  4. Versions: HTTP has different versions, with HTTP/1.1 being widely used, and HTTP/2 and HTTP/3 offering more advanced features like improved speed and security.

HTTPd

HTTPd is the software that implements the HTTP protocol on a server. It handles incoming HTTP requests from clients and serves them the appropriate content. Here’s how HTTPd fits into the process:

  1. Listening for Requests: HTTPd constantly listens for incoming HTTP requests from clients. When you type a website’s address into your browser, it sends a request to the server where that site is hosted. HTTPd receives this request.

  2. Processing Requests: Once HTTPd receives a request, it interprets the HTTP method (like GET, POST, etc.), the requested URL, and any additional data sent by the client.

  3. Serving Content: HTTPd finds the content requested by the client. This might be a static file (like an HTML page or image) stored on the server, or it might involve running a script or program to generate content dynamically.

  4. Sending Responses: After locating or generating the requested content, HTTPd sends an HTTP response back to the client. This response includes the requested content and an HTTP status code that indicates whether the request was successful or if there were any issues.

  5. Logging: HTTPd also typically logs requests and responses, which helps in monitoring and troubleshooting server activity.

How HTTP(d) works.

In order to understad how HTTP works or troubleshoot, it is helpful to to manually request a web page using netcat (often abbreviated as nc), you can simulate what a web browser does when it requests a page from a web server. netcat is a versatile networking tool that can create TCP or UDP connections and send/receive data over those connections.

Here’s a step-by-step guide to manually requesting a web page using netcat:

Step 1: Open a Terminal

First, open a terminal on your Linux, macOS, or Windows system (if you have netcat installed).

Step 2: Use netcat to Connect to the Web Server

To connect to a web server, use the nc command followed by the server’s domain name or IP address and the port number. HTTP typically uses port 80.

For example, to connect to example.com:

nc example.com 80

This command tells netcat to open a TCP connection to example.com on port 80.

Step 3: Manually Type the HTTP Request

Once you’re connected, you need to type an HTTP request manually. A basic HTTP GET request looks like this:

GET / HTTP/1.1
Host: example.com

Explanation:

  • GET / HTTP/1.1: This line specifies the method (GET), the path (/ for the root of the site), and the HTTP version (HTTP/1.1).
  • Host: example.com: This header specifies the domain name of the server you’re connecting to. It’s required for HTTP/1.1 requests, especially when the server hosts multiple websites (virtual hosting).

After typing these lines, press Enter twice to send the request. The double Enter indicates the end of the HTTP headers and tells the server to process the request.

Step 4: View the Response

After you press Enter twice, the server will respond with an HTTP response, which will include:

  • Status Line: Information about the request status (e.g., HTTP/1.1 200 OK).
  • Headers: Metadata about the response, like content type, length, and server information.
  • Body: The actual content of the web page (HTML, text, etc.).

Here’s an example of what you might see:

HTTP/1.1 200 OK
Date: Mon, 01 Sep 2024 12:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Wed, 28 Aug 2024 12:00:00 GMT
Content-Type: text/html
Content-Length: 1256
<example output>

Step 5: Close the Connection

After receiving the response, netcat may keep the connection open, waiting for additional input. You can close the connection by pressing Ctrl+C.

How is email sent?

To send an email manually from the terminal using netcat or openssl s_client, you need to communicate directly with an SMTP server. Below are the steps using each tool. You will need a working SMTP server address, typically provided by an email service like Gmail or your ISP.

Using netcat (nc)

Steps

  1. Open a terminal.
  2. Connect to the SMTP server using port 25 (or 587/465 for SMTP over TLS/SSL, though for plaintext communication, stick to port 25):

bash nc smtp.example.com 25

  1. Once connected, manually issue SMTP commands:

```plaintext HELO localhost MAIL FROM:your_email@example.com RCPT TO:recipient@example.com DATA Subject: Test email This is a test email sent via netcat.

. QUIT ```

  1. The email will be sent when you finish the DATA section by entering a . on a new line followed by the QUIT command.

Using openssl s_client

For secure communication with an SMTP server over TLS, use openssl s_client. You typically use this method with port 465 (for SMTPS).

  1. Open a connection with the SMTP server:

bash openssl s_client -connect smtp.example.com:465 -crlf -ign_eof

  1. Once the connection is established, you can proceed with the SMTP commands. If the server requires authentication (which many do), authenticate using the AUTH LOGIN method (Base64 encoding is required for the username and password).

Here’s an example session:

```plaintext EHLO localhost AUTH LOGIN MAIL FROM:your_email@example.com RCPT TO:recipient@example.com DATA Subject: Test email via openssl

This is a test email sent via openssl s_client.

. QUIT ```

To generate the Base64 encoded strings, you can use:

bash echo -n "your_username" | base64 echo -n "your_password" | base64

How does DNS work?

DNS Overview

DNS (Domain Name System) is a hierarchical, decentralized system responsible for translating human-readable domain names (like example.com) into IP addresses (such as 93.184.216.34). This system acts as the “phonebook” of the internet, ensuring that users can access websites and services by typing in easy-to-remember domain names instead of hard-to-remember IP addresses.

How DNS Works

When you type a domain like example.com into your browser, your computer follows these steps:

  1. Query a local DNS resolver: Your computer contacts a DNS resolver (usually provided by your ISP or set by you, such as Google’s 8.8.8.8) to ask for the IP address of example.com.
  2. Check the cache: The resolver first checks if it already knows the answer from a recent lookup. If it doesn’t, it moves to the next step.
  3. Contact root servers: The resolver queries a root DNS server, which directs it to a server that knows about .com domains.
  4. Query TLD (Top-Level Domain) server: The .com TLD server gives the resolver the address of the DNS server responsible for example.com.
  5. Query the authoritative DNS server: The resolver then asks the authoritative server for example.com for its IP address. The authoritative server replies with the answer.
  6. Return the answer: The resolver sends the IP address back to your computer, allowing your browser to connect to the site.

Types of DNS Records

Common types of DNS records include:

  • A record: Maps a domain to an IPv4 address.
  • AAAA record: Maps a domain to an IPv6 address.
  • CNAME record: Aliases one domain name to another.
  • MX record: Specifies mail servers for email routing.
  • NS record: Lists the name servers responsible for the domain.

Example: DNS Query by Hand

You can manually query DNS using the dig, host, or nslookup tools. Here’s an example using dig:

dig example.com

This command will return details such as the queried domain, answer section with the IP address, and additional information like authoritative servers.

To query just for the A record (IPv4 address) of a domain:

dig example.com A

To query the mail servers for a domain (MX records):

dig example.com MX

Alternatively, with the host command:

host example.com

For a reverse DNS lookup (to find the domain name from an IP address):

dig -x 93.184.216.34

Linux Tools for DNS Queries

  1. dig: A flexible DNS lookup utility. It provides detailed information about DNS queries and responses.

Example: bash dig google.com

  1. host: A simpler utility to look up DNS details such as IP addresses, mail servers, etc.

Example: bash host google.com

  1. nslookup: An older tool for querying DNS servers. While less commonly used than dig these days, it still functions well.

Example: bash nslookup example.com

  1. resolvectl: This tool is part of systemd and allows users to query DNS information directly from the system’s resolver.

Example: bash resolvectl query example.com

The DNS Protocol

DNS runs on the UDP protocol, typically using port 53. Since UDP is connectionless and faster than TCP, it’s ideal for the quick query/response nature of DNS. However, if the response data size is too large or the query is critical, DNS can also run over TCP (still on port 53).

DNS messages consist of a query from the client and a response from the server, structured into sections such as:

  • Header: Contains fields such as the query ID, flags, and counts for the sections.
  • Question Section: Specifies the domain name and query type (e.g., A record, MX record).
  • Answer Section: Contains resource records answering the query (e.g., IP addresses).
  • Authority Section: Provides details about the DNS servers that are authoritative for the domain.
  • Additional Section: Offers extra information that may assist the resolver.
$ try it — a real Linux shell, running in your browser

Boots a Buildroot Linux kernel client-side with v86, a 32-bit x86 emulator compiled to WebAssembly. Nothing you type leaves this tab. First boot fetches a ~10 MB kernel; it then runs offline.