LPIC-2 202-450: Administering Network and Web Services

The LPIC-2 202-450 exam covers the services that make a Linux server useful to other machines: name resolution, web delivery, file sharing, mail and system security. Linux Professional Institute's current LPIC-2 examination version is 4.5, and 202 is paired with 201-450, which focuses on kernels, storage and broader system operation. Both exams are required for LPIC-2, alongside an active LPIC-1 certification. That structure mirrors real administration: a host may start and store data correctly yet still fail users because a DNS zone is wrong, a reverse proxy cannot reach its backend or a file share gives the wrong identity access.

It is tempting to approach this exam as a list of popular server packages. A more effective method follows a client request from name resolution through transport and service handling to the permissions on the requested data. Identify which program listens, where it reads configuration, what a client needs to reach it and what evidence distinguishes a successful connection from an application-level failure. LPI certifications expect candidates to handle heterogeneous Linux environments; no single distribution-specific wizard can replace that layered mental model.

Trace DNS and network services from the client's point of view

DNS maps names into records needed by applications, but the behavior depends on the role of the server. An authoritative DNS server answers for zones it serves; a recursive resolver seeks answers on behalf of clients, subject to its configuration and cache. Confusing the two can lead to serious security and troubleshooting errors. An authoritative service exposed to the internet should not casually provide unrestricted recursion for strangers. Conversely, a local resolver may need forwarding, caching and appropriate client access controls while not hosting any authoritative public zone.

BIND configuration requires understanding zones, resource records, access policies and validation before reloads. An A or AAAA record maps a name toward an address, MX records route mail by domain, and an SOA record carries zone-management information such as serial values. Incorrect serial handling can cause secondary servers to retain stale zone data even after a file is edited. The SOA record's role in stable DNS management is therefore directly relevant when diagnosing an apparently successful zone update that never propagated. Check syntax and service logs rather than assuming every edited text file is active immediately.

A forward lookup working does not imply that reverse lookup is configured or needed for every service, and a reverse PTR record does not create forward connectivity. Separating forward and reverse DNS zones helps explain why mail reputation and certain operational logs may use reverse mappings while routine HTTP traffic does not require them in the same way. `dig` and related diagnostic tools are valuable because they can query a specific server and reveal which answer path was used. An administrator should identify whether a failure arises from record content, caching, delegations, firewall access or the wrong resolver being queried.

DHCP adds another layer: it assigns network configuration to clients rather than resolving arbitrary names on request. A client with the wrong gateway can resolve an address correctly yet still fail to reach the service. Lease information, scope options, reservation behavior and conflicting servers should be investigated separately from DNS-zone syntax. In a mixed environment the relationship between DHCP-provided resolver addresses and authoritative DNS configuration matters, but changing one is not an automatic repair for the other. Good LPIC-2 answers preserve those responsibilities instead of compressing every network symptom into “DNS is broken.”

Administer web services with clear trust boundaries

Apache HTTP Server and Nginx can both serve HTTP traffic, but their configuration model, module ecosystem and deployment patterns differ. A virtual host or server block determines how incoming requests are associated with a site, while the document root and application backend determine what content can be returned. A 404 response may reflect routing to a wrong site or nonexistent path; a 502 response can indicate trouble between a reverse proxy and its upstream application. Neither status by itself proves that the physical network is unreachable. Begin with the service's listener, site selection and error logs.

TLS configuration introduces certificate identity, certificate-chain trust and protocol policy. A service can accept connections while presenting a certificate that does not match its hostname; an expired certificate does not become trustworthy because a browser provides a bypass option. Certificate storage and private-key access should be limited to principals that need them. A reverse proxy may terminate TLS and then communicate with an internal backend, but that arrangement requires an explicit trust decision about the internal hop. Candidates should be prepared to distinguish secure transport from the application's own authentication and authorization rules.

A web service commonly runs under a restricted system identity. The service account should read the required content and write only the directories necessary for logs, uploads or temporary files. Making the entire web root writable by the service to solve a deployment issue can allow one compromised request path to alter the site. Similarly, an executable upload directory creates different risk from a directory used for static images. The operational sequence is to identify which component needs a write, decide where it can be permitted, and then confirm that normal application operations still work after permissions are narrowed.

Caching, compression and load distribution may improve performance, yet each adds new behavior that can obscure faults. A stale cache can make a corrected web page appear unchanged; a proxy header may incorrectly convey a client's IP address unless the trusted proxy chain is configured; a backend health check can declare a process alive while it fails a real business request. Choose evidence that crosses the disputed boundary. Check what the client received, what the proxy forwarded and what the backend logged rather than treating a single green status light as proof that the entire request succeeded.

Manage file sharing and mail without confusing authentication with access

NFS and Samba expose shared data to remote clients with different ecosystem assumptions. NFS is commonly used for Unix-style sharing and may involve numeric identities, exports and mount semantics; Samba implements SMB services for mixed clients and integrates with various account and domain arrangements. The permission seen by a user is the outcome of server configuration, filesystem ownership, protocol-level rules and identity mapping. A share may be discoverable yet not writable, or a client may authenticate successfully and still be denied access to a particular directory.

Identity mismatches are especially troublesome across systems. If a remote user appears as a different UID on an NFS server, simply changing broad filesystem permissions may mask the mismatch while creating a security problem. If Samba has valid credentials but restrictive share or underlying filesystem rules, another login attempt will not resolve access. Investigate authentication, group membership, identity mapping and the actual read/write permission in a consistent order. Test with an ordinary user rather than a privileged account that bypasses the limits the share is supposed to enforce.

Mail services involve at least transport and delivery, often through separate components. SMTP accepts or relays messages under policy, while mailbox access and storage are different concerns. An open relay is a security and reputation risk, not a feature that increases delivery reliability. MX records identify where a domain expects incoming mail, but DNS configuration alone does not make delivery possible: the receiving service must listen, accept appropriate recipients, protect credentials and handle queues. The guide to MX record behavior in DNS is useful because it separates a routing record from the application that processes the resulting connection.

When email is delayed, distinguish message acceptance from final delivery. Queue inspection and mail logs may reveal DNS failures, authentication rejection, transient peer errors or local mailbox problems. A mail server could accept a message and queue it without placing it in the destination inbox. Likewise, a TLS requirement that is appropriate for submission may not map identically to all interserver transport scenarios. The exam rewards administrators who can trace the actual service flow and choose a fix for the failed stage rather than assuming that all mail problems are caused by spam filters.

Protect exposed services and verify incident recovery

Network daemons increase the attack surface because they accept input from clients. Controlling listen addresses, firewall rules, authentication methods, privilege separation and log retention reduces exposure, but a firewall is not a substitute for secure application configuration. A server bound only to loopback behaves differently from one listening on every interface. If a service is intended for a private management network, the access policy should express that decision in both network and service configuration where practical. Avoid broad exceptions introduced just to silence a connection error during installation.

SSH remote access, cryptographic keys and host identity are particularly important when systems are administered over insecure networks. Administrators should understand why key-file permissions matter, how authorized keys are controlled and why the client should validate a host key rather than silently trusting every prompt. Password policy, root login restrictions and audit records fit into a layered design. The discussion of SSH forwarding and its trust boundaries helps explain why a connection allowed through an SSH tunnel can expose a service beyond its original intended audience.

A useful learning environment contains two Linux virtual machines: one runs a local DNS zone and a simple web service, while the other acts as client. Introduce one failure at a time—a wrong resolver address, an invalid zone record, a listener restricted to loopback, a TLS hostname mismatch or a file-share permission conflict. Record what the client sees and where the server records the event. This builds a practical chain of evidence that can later extend to mail queues, Samba identity mapping and NFS exports without requiring a risky publicly exposed test environment.

Study the released version 4.5 objectives and keep the draft version 5.0 materials separate until LPI announces an official transition. The strongest 202-450 candidate understands not just how to start a service, but why its requests succeed or fail, where it stores data, which identity it uses and how its behavior can be audited. That capability completes the services half of LPIC-2 and complements the system-focused skills assessed by 201. Reliable network operations are the product of correctly joined layers, not a collection of independent configuration tricks.