Core office-network services must agree on names, addresses, shared storage, and permitted traffic. This challenge-based project has you configure those layers on one Linux host while validating each service with its native administration tools.
You will build a local BIND zone, author an ISC DHCP subnet, expose separate NFS and Samba shares, and organize Firewalld zones and service definitions. The focus is server-side configuration and verification in a prepared single-node environment, not a production network rollout.
What You Will Learn
- Install BIND9, declare a master zone, create an A record, and resolve it through the local DNS server
- Define an ISC DHCP scope for
192.168.10.0/24with a specific address pool and router option - Validate DHCP configuration syntax with
dhcpd -tbefore attempting service deployment - Export
/srv/nfs/devand verify the active NFS export for Linux clients - Configure a password-protected Samba
[finance]share and provision its dedicated user - Start Firewalld, assign
eth0totrusted, and permanently list DNS, DHCP, NFS, Samba, and SSH inpublic
Who This Course Is For
This project is for Linux and DevOps learners ready to apply DNS, DHCP, file-sharing, and firewall administration skills without step-by-step commands.
Prerequisites: Familiarity with Linux packages and services, network addressing and ports, BIND zone files, DHCP scopes, Unix permissions, NFS exports, Samba users and shares, and Firewalld zones; this is an assessment-style project.
Learning environment: A browser-accessible single-node Linux host with sudo, APT, BIND9, ISC DHCP, NFS, Samba, Firewalld, and local verification tools; no external clients or physical office network are required.
Frequently Asked Questions
Will the DHCP server assign addresses to real client machines?
No. You install the server and define the subnet 192.168.10.0/24, pool .100–.200, and router .1, then verify syntax with dhcpd -t. The single-node lab does not test lease delivery.
Are the NFS and Samba shares tested from separate clients?
No. Server-side exports, Samba configuration, user presence, and service state are checked locally. Remote mounts and Windows authentication sessions are outside the project.
Does the DNS challenge configure public or recursive DNS?
No. It creates an internal authoritative master zone, globaltech.int, and verifies that the local BIND server resolves portal.globaltech.int to 127.0.0.1.
Does the firewall phase prove a default-deny policy on eth0?
No. For lab-access safety, the task sets the default zone and eth0 to trusted, then adds required service names to the separate public zone. It teaches zone and permanent-rule operations, but does not validate restrictive filtering on the trusted interface.
