Linux Server Fundamentals

We now go one layer below:

DNS
 ↓
TCP/IP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

The next question is:

What is the Ubuntu server underneath all these services?

1. A Server Is a Computer

Your VPS is fundamentally a computer.

At the deepest practical level:

Computer
├── CPU
├── RAM
├── Storage
├── Network
└── Operating System

Your hosting software runs on top of the operating system.

2. The Basic Linux Architecture

Think of Ubuntu like this:

Applications
    │
    ├── Nginx
    ├── PHP-FPM
    ├── MySQL
    ├── WordPress
    └── Certbot
          │
          ▼
      System Libraries
          │
          ▼
         Kernel
          │
    ┌─────┼─────┐
    ▼     ▼     ▼
   CPU   RAM   Storage
          │
          ▼
       Hardware

The Linux kernel is the central component connecting applications to the underlying resources.

3. What Is the Kernel?

The kernel is the core of the operating system.

It manages resources such as:

CPU
Memory
Processes
Filesystems
Networking
Devices
Security

Applications normally do not directly control hardware.

Instead:

Application
    ↓
System call
    ↓
Linux kernel
    ↓
Hardware/resource

4. Example: Reading a File

Suppose Nginx needs:

/storage/websites/templates.cresignsys.com/public/index.html

Conceptually:

Nginx
 ↓
Request file
 ↓
Linux kernel
 ↓
Filesystem
 ↓
Storage
 ↓
Data
 ↓
Kernel
 ↓
Nginx

Nginx doesn’t directly operate the physical SSD.

The kernel manages that interaction.

5. Example: Sending Network Data

When Nginx sends an HTTP response:

Nginx
 ↓
Socket
 ↓
Linux networking stack
 ↓
Network interface
 ↓
Cloud virtual network
 ↓
Internet

Again, the kernel manages the underlying networking.

6. CPU

The CPU executes instructions.

Programs such as:

nginx
php-fpm
mysqld
sshd

are executable programs loaded into memory and executed by the CPU.

Conceptually:

Program
 ↓
Instructions
 ↓
CPU
 ↓
Execution

7. CPU Cores

A VPS may be allocated one or more virtual CPU cores.

For example:

CPU
├── vCPU 1
├── vCPU 2
├── vCPU 3
└── vCPU 4

The exact virtualization model depends on the cloud provider.

Multiple processes can run concurrently across available CPU resources.

8. RAM

RAM is working memory.

When Nginx runs:

Nginx program

its active code/data resides in memory.

Similarly:

PHP-FPM
MySQL
WordPress PHP execution

use RAM.

Conceptually:

Storage
   ↓
Program files
   ↓
RAM
   ↓
CPU

9. Storage

Storage is persistent.

It contains:

Ubuntu files
Nginx configuration
WordPress
Plugins
Themes
MySQL data
Logs
SSL certificates
Backups

Unlike RAM, storage is intended to retain data across reboots.

10. RAM vs Storage

Memorize:

RAM
=
working memory

Storage
=
persistent data

For example:

WordPress PHP file
     ↓
stored on disk

PHP executes it
     ↓
code/data loaded into memory

11. Processes

Linux runs programs as:

Processes

Run:

ps aux

You may see processes such as:

root
www-data
mysql
nginx
systemd

and many others.

12. What Is a Process?

A process is a running instance of a program.

For example:

Program:
nginx

Running instance:
nginx process

Conceptually:

Executable file
      ↓
Process
      ↓
CPU + RAM + resources

13. Process ID

Every Linux process has a:

PID

Process ID.

For example:

PID 1
PID 500
PID 1200
PID 2500

You can inspect processes using:

ps aux

or:

ps -ef

14. PID 1

One of the most important Linux processes is:

PID 1

On modern Ubuntu systems, this is typically:

systemd

It is the first userspace process started by the kernel.

Conceptually:

Kernel
 ↓
systemd (PID 1)
 ↓
Services
 ↓
Nginx
PHP-FPM
MySQL
SSH
...

15. systemd

systemd manages many system services.

For example:

systemctl status nginx

asks systemd about Nginx.

Similarly:

systemctl status mysql

asks about MySQL.

16. Service

A service is a long-running/background system component.

Examples:

nginx
mysql
php-fpm
ssh
cron

Conceptually:

systemd
 ├── nginx.service
 ├── mysql.service
 ├── php-fpm.service
 └── ssh.service

17. Start a Service

For example:

sudo systemctl start nginx

This asks systemd to start Nginx.

18. Stop a Service

sudo systemctl stop nginx

This stops Nginx.

19. Restart a Service

sudo systemctl restart nginx

This stops and starts the service.

Use restarts carefully on production servers.

20. Reload vs Restart

This distinction is important.

Reload

sudo systemctl reload nginx

Typically asks Nginx to reload its configuration while preserving existing worker processes/connections as appropriate.

Restart

sudo systemctl restart nginx

Stops and starts the service.

For configuration changes, a reload is often preferable when supported.

21. Enable at Boot

sudo systemctl enable nginx

This configures Nginx to start automatically during boot according to its systemd unit configuration.

22. Check Status

sudo systemctl status nginx

You might see:

Active: active (running)

This means systemd considers the service running.

23. `systemctl` Mental Model

Think:

systemctl
   ↓
systemd
   ↓
service
   ↓
process

For example:

systemctl
   ↓
nginx.service
   ↓
nginx master/worker processes

24. Users

Linux is a multi-user operating system.

You can have:

root
ubuntu
www-data
mysql

and many others.

Different processes can run under different users.

25. Root

root is the superuser.

It has extensive privileges over the system.

Commands such as:

sudo systemctl restart nginx

temporarily request elevated privileges.

26. `sudo`

Suppose you’re logged in as:

ubuntu

but need to perform an administrative operation.

You can use:

sudo command

For example:

sudo nginx -t

Conceptually:

ubuntu user
   ↓
sudo
   ↓
privileged execution

27. Why Not Run Everything as Root?

Because a compromised application running with unrestricted privileges could potentially cause much greater damage.

This leads to:

Principle of Least Privilege

Give each process only the permissions it needs.

28. `www-data`

On Ubuntu/Debian systems, web services often use:

www-data

as a service account.

For example, PHP-FPM workers may run as:

www-data

depending on configuration.

This means WordPress operations can be restricted by Linux permissions.

29. MySQL User

MySQL commonly has its own system account:

mysql

The database process runs under that account rather than as an ordinary web user.

Conceptually:

Nginx
  ↓
www-data
  ↓
PHP-FPM
  ↓
MySQL
  ↓
mysql user

The exact permissions and process model depend on configuration.

30. Files and Directories

Linux organizes storage as a hierarchy.

At the top:

called:

Root filesystem

Under it:

/etc
/var
/home
/usr
/opt
/tmp
/run
/storage

and many others.

31. `/etc`

This generally contains system and application configuration.

For example:

/etc/nginx/
/etc/php/
/etc/mysql/
/etc/ssh/

Your Nginx configuration lives under:

/etc/nginx/

32. `/var`

Often contains changing application/system data.

Examples:

/var/log/
/var/lib/
/var/cache/

Logs commonly live under:

/var/log/

33. `/var/log`

Examples:

/var/log/nginx/
/var/log/mysql/
/var/log/syslog/

Logs are essential for troubleshooting.

34. `/run`

Contains runtime state.

For example, service sockets can exist under:

/run/php/

A PHP-FPM Unix socket might be:

/run/php/php8.3-fpm.sock

depending on your PHP version/configuration.

35. `/home`

Usually contains users’ home directories.

For example:

/home/ubuntu

36. Your `/storage`

You have been using paths such as:

/storage/websites/

This is not one of the standard top-level directories required by Linux.

It is a directory/mount chosen for your server architecture.

Conceptually:

/storage
   ↓
websites
   ↓
domain
   ↓
public

37. Your Hosting Structure

For example:

/storage/websites/
    │
    ├── templates.cresignsys.com/
    │      └── public/
    │
    ├── learn.cresignsys.com/
    │      └── public/
    │
    └── shop.cresignsys.com/
           └── public/

This is your hosting filesystem organization.

38. Linux Permissions

Every file/directory has permissions.

Run:

ls -l

You might see:

-rw-r--r-- 1 ubuntu ubuntu 1234 index.php

This contains several pieces of information.

39. Permission Structure

Consider:

-rw-r--r--

Break it down:

-
rw-
r--
r--

The first character indicates the object type.

Then three permission groups:

Owner
Group
Others

40. `r`

Means:

Read

For a file:

means the user can read the file.

41. `w`

Means:

Write

For a file:

means the user can modify its contents.

42. `x`

Means:

Execute

For a file:

means it can be executed as a program, subject to other conditions.

For directories, x has a different but very important meaning: it permits traversal/search through the directory.

43. Directory Permissions

This is subtle.

For a directory:

generally allows listing directory entries.

allows traversing/searching the directory.

allows modifying directory entries, subject to the combination of permissions.

This is why directory permissions need to be understood separately from file permissions.

44. WordPress Permissions

Your web server needs appropriate access to:

wp-content/
uploads/
plugins/
themes/

depending on what WordPress needs to do.

But giving everything:

is generally a bad security practice.

45. `777`

You may encounter:

chmod -R 777 website/

Do not use this as a generic fix.

It grants broad read/write/execute permissions and can create serious security problems.

Correct permissions depend on:

Owner
Group
Web server user
Deployment method
Application requirements

46. Ownership

Check ownership with:

ls -l

Example:

www-data www-data

means:

Owner = www-data
Group = www-data

Ownership is separate from the permission bits.

47. `chown`

Changes ownership.

Example:

sudo chown user:group file

This is a powerful command.

Do not recursively change ownership across your whole server without understanding the consequences.

48. `chmod`

Changes permission bits.

For example:

chmod 644 file

means a common file permission pattern:

Owner  → read/write
Group  → read
Others → read

For directories, commonly used permission patterns differ because directories need traversal.

49. Symbolic Representation

Common permissions:

means:

Owner: 6
Group: 4
Others: 4

The numbers are based on:

r = 4
w = 2
x = 1

So:

6 = 4 + 2 = rw-
4 = r--
4 = r--

50. 755

means:

Owner  → rwx
Group  → r-x
Others → r-x

This is commonly used for directories and executable scripts where appropriate.

But permissions should be chosen based on actual requirements rather than blindly applying 755 everywhere.

51. Processes and Permissions Connect

Suppose PHP-FPM runs as:

www-data

and a file belongs to:

ubuntu

with permissions:

-rw-------

Then www-data may not be able to read it.

Result:

PHP
 ↓
File access
 ↓
Permission denied

This can cause application failures.

52. Linux Networking

Now move from filesystem to networking.

Linux exposes network interfaces.

Run:

ip addr

You may see interfaces such as:

lo
eth0
ens3

The exact interface name depends on the environment.

53. Loopback

The interface:

lo

is:

Loopback

Typically:

127.0.0.1

for IPv4.

It represents the local machine.

54. Why Loopback Matters

Suppose Nginx communicates with PHP-FPM using:

127.0.0.1:9000

Then:

Nginx
 ↓
localhost
 ↓
PHP-FPM

The traffic doesn’t leave the machine through the public Internet.

55. Network Interface

A network interface connects the system to a network.

Conceptually:

Linux
 │
 ├── lo
 │
 └── eth0
       ↓
    Cloud network
       ↓
    Internet

The actual cloud networking architecture is more complex.

56. IP Addresses on Linux

Run:

ip addr

You may see:

127.0.0.1

and a private/internal address such as:

10.x.x.x

or another private range.

Your cloud provider may separately associate a public IP with the VM through its virtual networking system.

57. Routing Table

Linux needs to know:

Where should packets go?

Run:

ip route

You may see a default route.

Conceptually:

Destination
     ↓
Routing table
     ↓
Interface / gateway

58. Default Route

A default route means roughly:

If there isn’t a more specific route, send the packet this way.

Conceptually:

Unknown destination
       ↓
default route
       ↓
gateway

59. Sockets

Now we connect networking to applications.

A socket is an endpoint used by applications for network communication.

Conceptually:

Application
    ↓
Socket
    ↓
TCP/UDP
    ↓
IP

60. Nginx Listening

When Nginx listens on:

0.0.0.0:443

it is waiting for incoming TCP connections on port 443 on IPv4 interfaces.

You can inspect this using:

sudo ss -lntp

61. Understanding `ss`

Example:

LISTEN

means a socket is waiting for connections.

0.0.0.0:443

means IPv4 address wildcard + port 443.

[::]:443

represents an IPv6 wildcard listener.

62. Process → Socket

Now the relationship becomes:

Nginx process
      ↓
Socket
      ↓
TCP 443
      ↓
Network interface
      ↓
Internet

This is how a web server becomes reachable.

63. SSH

You also connect to the server through a network service.

Typically:

SSH client
 ↓
TCP 22
 ↓
sshd
 ↓
Linux

The SSH daemon is commonly:

sshd

64. SSH and Nginx Are Similar at One Level

Both are programs listening on network sockets.

For example:

sshd
 ↓
TCP 22

and:

nginx
 ↓
TCP 443

Different application protocols, same fundamental networking concept.

65. Server Services Map

Your server may look conceptually like:

Ubuntu
 │
 ├── sshd
 │     └── TCP 22
 │
 ├── nginx
 │     ├── TCP 80
 │     └── TCP 443
 │
 ├── php-fpm
 │     └── Unix socket / TCP
 │
 └── mysql
       └── database socket / TCP

Not every service must be publicly exposed.

That is a major security principle.

66. MySQL Should Usually Not Be Public

If WordPress and MySQL are on the same VPS:

WordPress
 ↓
localhost/socket
 ↓
MySQL

There is usually no need to expose MySQL publicly.

A safer conceptual architecture is:

Internet
   ↓
Nginx :443
   ↓
PHP-FPM
   ↓
MySQL

rather than:

Internet
   ↓
MySQL :3306

67. Service Exposure

Ask for every service:

Does this service actually need to be reachable from the Internet?

For example:

Nginx :443
YES

Nginx :80
Usually yes for HTTP/HTTPS redirects and ACME HTTP validation, depending on setup

MySQL :3306
Usually no

PHP-FPM
Usually no

Redis
Usually no

This is a fundamental server-security concept.

68. Linux Security Model

Now the architecture becomes:

Internet
   ↓
Cloud firewall
   ↓
Ubuntu firewall
   ↓
Network socket
   ↓
Process
   ↓
Linux user
   ↓
Filesystem permissions

Security exists at multiple layers.

69. Defense in Depth

You should not rely on only one security mechanism.

For example:

Cloud firewall
      +
Ubuntu firewall
      +
Nginx configuration
      +
Linux permissions
      +
Application authentication
      +
TLS

This is called:

Defense in depth

70. The Server Is Not One Thing

When you say:

“My server is running.”

that doesn’t necessarily mean the website is working.

The server contains many independent components:

Kernel
systemd
Network
Nginx
PHP-FPM
MySQL
WordPress
Storage
DNS
TLS

Any one of them can fail independently.

71. A Better Mental Model

Think of your VPS as a small city:

Kernel
=
city infrastructure

Processes
=
businesses

Users
=
people/accounts

Ports
=
doors

Sockets
=
doorways/endpoints

Filesystem
=
buildings/storage

Permissions
=
access control

systemd
=
service manager

Nginx
=
front desk

PHP-FPM
=
application workers

MySQL
=
records/archive

This analogy is useful for understanding the relationships, but the actual Linux mechanisms are more precise.

72. Essential Commands

Start memorizing these:

CPU/RAM

top

or:

htop

if installed.

Processes

ps aux

Services

systemctl status nginx

Network

ip addr

Routes

ip route

Ports

sudo ss -lntp

Files

ls -la

Disk

df -h

Memory

free -h

73. `df -h`

This shows filesystem capacity.

For example:

df -h

You might see:

Filesystem
Size
Used
Avail
Use%
Mounted on

This is essential for hosting servers.

If your storage reaches 100%:

MySQL
Nginx
PHP
WordPress

can all start behaving unexpectedly.

74. `free -h`

Shows memory usage.

free -h

Conceptually:

Total
Used
Free
Shared
Buffers/cache
Available
Swap

Memory pressure can affect PHP-FPM, MySQL and other services.

75. `uptime`

Try:

uptime

It gives information including:

System uptime
Logged-in users
Load averages

76. Load Average

You may see:

load average: 0.20, 0.15, 0.10

These correspond to different time windows.

Load average is not simply “CPU percentage.”

It represents runnable/uninterruptible work in the system’s scheduling/load model.

This is a deeper Linux performance topic we will study later.

77. Process Tree

Use:

pstree

if installed.

You may see relationships such as:

systemd
 ├── sshd
 ├── nginx
 │    ├── nginx worker
 │    └── nginx worker
 ├── php-fpm
 └── mysqld

This helps visualize process hierarchy.

78. Parent and Child Processes

A process can create another process.

Conceptually:

Parent
  ↓
Child

The operating system tracks these relationships.

This is another reason PID information matters.

79. File Descriptors

This is a deeper Linux concept.

Processes interact with files, sockets and other resources using:

File descriptors

Conceptually:

Process
 ├── FD 0 → stdin
 ├── FD 1 → stdout
 ├── FD 2 → stderr
 └── other FDs → files/sockets

A network socket can be represented by a file descriptor inside a process.

This is why Linux has such a unified model around files and I/O.

80. Why This Matters for Nginx

Nginx can have many open connections.

Conceptually:

Nginx worker
 ├── socket FD
 ├── socket FD
 ├── file FD
 ├── socket FD
 └── ...

Operating-system limits on file descriptors therefore matter for high-traffic servers.

We will study this later.

81. The Deep Architecture

You can now visualize your server as:

                     INTERNET
                         │
                         ▼
                       DNS
                         │
                         ▼
                     CLOUD NET
                         │
                         ▼
                    LINUX KERNEL
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
     NETWORK            FILES             CPU/RAM
       │                 │                 │
       ▼                 ▼                 ▼
     SOCKETS          FILESYSTEM         PROCESSES
       │                 │                 │
       └─────────────────┼─────────────────┘
                         ▼
                      systemd
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Nginx          PHP-FPM         MySQL
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                      WordPress

82. The Most Important New Concept

The key idea from this lesson is:

Applications don’t directly own the machine. They request resources from the operating system kernel.

For example:

Nginx
 ↓
kernel
 ↓
network

and:

PHP
 ↓
kernel
 ↓
filesystem

and:

MySQL
 ↓
kernel
 ↓
storage

83. From Your Hosting Platform Perspective

Your CresignSys hosting system is ultimately an automation layer above all of this:

CresignSys Hosting Platform
            │
            ▼
       Linux commands
            │
            ▼
          systemd
            │
     ┌──────┼──────┐
     ▼      ▼      ▼
   Nginx   PHP    MySQL
     │      │      │
     └──────┼──────┘
            ▼
         Website

A hosting panel is therefore not magic.

It is automation and management around these underlying technologies.

Lesson 031 Summary

You now understand the foundation underneath your hosting server:

Hardware
 ↓
CPU / RAM / Storage / Network
 ↓
Linux Kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Filesystems
 ↓
Sockets
 ↓
systemd
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL

And the critical commands:

ps aux
systemctl status nginx
ip addr
ip route
sudo ss -lntp
ls -la
df -h
free -h
uptime

Next Lesson — 032

Linux Processes — The Deep Basics

We will go deeper into:

Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Threads
 ↓
CPU scheduling
 ↓
Memory
 ↓
Virtual memory
 ↓
File descriptors
 ↓
Signals
 ↓
Process states
 ↓
Zombie processes
 ↓
systemd services

Then we will connect these concepts directly to:

Nginx workers
PHP-FPM workers
MySQL processes
WordPress requests

so you can understand what is actually happening inside the VPS when 1, 10, or 1,000 visitors access your websites.

CresignSys Learn — Lesson 031

Linux Server Fundamentals

1. A Server Is a Computer

2. The Basic Linux Architecture

3. What Is the Kernel?

4. Example: Reading a File

5. Example: Sending Network Data

6. CPU

7. CPU Cores

8. RAM

9. Storage

10. RAM vs Storage

11. Processes

Processes

12. What Is a Process?

13. Process ID

PID

14. PID 1

15. systemd

16. Service

17. Start a Service

18. Stop a Service

19. Restart a Service

20. Reload vs Restart

Reload

Restart

21. Enable at Boot

22. Check Status

23. systemctl Mental Model

24. Users

25. Root

26. sudo

27. Why Not Run Everything as Root?

Principle of Least Privilege

28. www-data

29. MySQL User

30. Files and Directories

Root filesystem

31. /etc

32. /var

33. /var/log

34. /run

35. /home

36. Your /storage

37. Your Hosting Structure

38. Linux Permissions

39. Permission Structure

40. r

Read

41. w

Write

42. x

Execute

43. Directory Permissions

44. WordPress Permissions

45. 777

46. Ownership

47. chown

48. chmod

49. Symbolic Representation

50. 755

51. Processes and Permissions Connect

52. Linux Networking

53. Loopback

Loopback

54. Why Loopback Matters

55. Network Interface

56. IP Addresses on Linux

57. Routing Table

58. Default Route

59. Sockets

60. Nginx Listening

61. Understanding ss

62. Process → Socket

63. SSH

64. SSH and Nginx Are Similar at One Level

65. Server Services Map

66. MySQL Should Usually Not Be Public

67. Service Exposure

68. Linux Security Model

23. `systemctl` Mental Model

26. `sudo`

28. `www-data`

31. `/etc`

32. `/var`

33. `/var/log`

34. `/run`

35. `/home`

36. Your `/storage`

40. `r`

41. `w`

42. `x`

45. `777`

47. `chown`

48. `chmod`

61. Understanding `ss`

73. `df -h`

74. `free -h`

75. `uptime`