In this lesson, you will learn how to apply Filesystem Hierarchy Standard (FHS) conventions to your own development projects to make your software more predictable and easier to deploy.
When you build an application, you often have to decide where configuration files, logs, and binaries go. Instead of creating a custom structure, we can borrow the logic from the Linux FHS. By mimicking how the operating system organizes itself, you ensure that your deployment scripts behave intuitively for any Linux administrator.
Aligning Project Layouts with the FHS
A well-structured project should separate concerns by function, just like /usr, /etc, and /var. Consider this standard layout for a project named myapp:
/myapp
├── bin/ # Executables (like /usr/bin)
├── etc/ # Default configuration files (like /etc)
├── lib/ # Shared libraries or runtime dependencies (like /usr/lib)
├── var/ # Runtime data, logs, or state (like /var/log or /var/lib)
└── share/ # Arch-independent data (like /usr/share)
Why This Matters for Deployment
When you write a shell script to deploy your project, adhering to this structure allows you to use standard environment variables and predictable paths. For example, your install.sh script doesn't need to guess where things go; it simply maps these directories to the system defaults:
etc/->/etc/myapp/bin/->/usr/local/bin/var/log/->/var/log/myapp/
By standardizing your project layout, you avoid the "magic path" problem where scripts fail because they expect a file in a non-standard location. Furthermore, if your application eventually grows into a package (like a .deb or .rpm), these tools expect this exact directory hierarchy to map your application files to the host system during installation.
Even in complex environments, such as those using Containerization and Filesystem Namespaces (Lesson 17), following these standards allows your containers to mount volumes cleanly into the expected directories, keeping your runtime environment consistent with your development environment.
Key Takeaway: By organizing your project directories to mimic the FHS, you ensure your software is predictable, easier to package, and inherently compatible with standard Linux system administration practices.