Linux & Server Administration – Complete Developer Learning Guide

Linux & Server Administration

A practical developer guide to Linux commands, files and permissions, users, processes, SSH, networking, systemd, Nginx, IIS, and deploying ASP.NET Core applications to real servers.

Ubuntu Server 26.04 LTS.NET 10 LTSC# 14Beginner to Advanced

Learning Roadmap

1. Introduction to Linux and Server Administration 01
2. What Is Linux? 02
3. Linux LTS and .NET LTS Baseline 03
4. Linux Server Architecture at a Glance 04
5. Connect to a Linux Server with SSH 05
6. SSH Keys and Safer Remote Access 06
7. The Linux Shell and Command Structure 07
8. Navigate the Linux Filesystem 08
9. Important Linux Directories 09
10. Read, Search and Inspect Files 10
11. Users, Groups and Account Management 11
12. Linux File Permissions: Read, Write and Execute 12
13. chmod: Change File Permissions 13
14. chown, umask and Safe Ownership 14
15. sudo and Privilege Management 15
16. Processes and Process IDs 16
17. Signals and Process Management 17
18. CPU, Memory, Disk and Resource Checks 18
19. systemd and Linux Services 19
20. Create a systemd Service for an ASP.NET Core API 20
21. Read Logs with journalctl 21
22. Linux Networking Fundamentals 22
23. Inspect IP Addresses, Routes and DNS 23
24. Ports, TCP, UDP and Firewalls 24
25. UFW: A Simple Ubuntu Firewall Interface 25
26. Install and Update Software with APT 26
27. Environment Variables and Application Configuration 27
28. Publish an ASP.NET Core Application for Linux 28
29. Deploy the Application to a Linux Server 29
30. Nginx: What It Does 30
31. Install and Validate Nginx 31
32. Configure Nginx as a Reverse Proxy for .NET 32
33. TLS, HTTPS and Certificates 33
34. ASP.NET Core Forwarded Headers Behind Nginx 34
35. IIS: Windows Web Server Fundamentals 35
36. IIS Hosting Models: In-Process and Out-of-Process 36
37. Nginx vs IIS: When to Use Each 37
38. Linux Deployment Architecture for a .NET Application 38
39. Backups, Updates and Server Maintenance 39
40. Server Troubleshooting: A Practical Sequence 40
41. Common Linux Administration Mistakes 41
42. Practical Mini Project: Deploy a .NET 10 API on Linux 42
43. Interview Questions and Answers 43
44. Linux Server Administration Checklist 44
45. Official Documentation and Further Learning 45
46. Final Thought 46

01. Introduction to Linux and Server Administration

Most applications do not run on a developer's laptop forever. They eventually run on a server: a machine or virtual machine that stays available, accepts requests, stores data, runs background work, and connects to other systems.

Linux is widely used for web hosting, cloud workloads, containers, databases, automation, and networking. Even when you primarily build applications with C# and ASP.NET Core, understanding Linux helps you deploy, troubleshoot, secure, and operate the software you create.

A developer delivers an application; the server provides the environment in which it runs.

02. What Is Linux?

Linux is an open-source kernel. A Linux distribution combines the kernel with system tools, package management, libraries, services, and installation choices to create a usable operating system.

Distribution	Common environment	Package manager
Ubuntu Server	Cloud servers, web hosting, development	APT / dpkg
Debian	Stable general-purpose servers	APT / dpkg
RHEL	Enterprise environments	DNF / RPM
Rocky Linux / AlmaLinux	Enterprise-compatible server workloads	DNF / RPM
Amazon Linux	AWS-oriented server workloads	DNF / RPM (version-dependent)

Commands and paths can differ between distributions. This guide uses Ubuntu Server-style commands for most examples and calls out differences where they matter.

03. Linux LTS and .NET LTS Baseline

For the operating-system examples, this guide uses Ubuntu Server 26.04 LTS as the current Ubuntu LTS baseline. For the application examples, it uses .NET 10 LTS with C# 14. Keep both the operating system and .NET runtime on supported servicing updates.

Technology	Baseline	Operational note
Ubuntu Server	26.04 LTS	Standard security maintenance through 2031; Ubuntu Pro can extend coverage
.NET	10 LTS	Supported through November 14, 2028; keep current on patches
Web server	Nginx stable branch	Use distribution security updates or a supported vendor repository
Windows hosting comparison	Windows Server 2025 + IIS	Apply Windows Server and IIS servicing updates

Versioning reminder: .NET 11 is newer but is an STS release. .NET 10 is the LTS choice for this guide. Linux distribution support lifecycles are separate from the .NET runtime lifecycle.

04. Linux Server Architecture at a Glance

The kernel manages core resources. User-space programs provide the shell, services, libraries, and applications. A system administrator works across these layers when diagnosing a server issue.

05. Connect to a Linux Server with SSH

SSH (Secure Shell) provides encrypted remote command-line access. Administrators commonly use it to manage virtual machines without a desktop environment.

# Connect using a username and server address
ssh deployer@203.0.113.20

# Connect using a specific private key
ssh -i ~/.ssh/deploy_key deployer@203.0.113.20

# Specify a non-default SSH port
ssh -p 2222 deployer@203.0.113.20

The IP address above is a documentation example, not a real server. Use the host name or address assigned by your infrastructure provider.

06. SSH Keys and Safer Remote Access

SSH key authentication uses a key pair. The private key stays with the client; the public key is installed in the server account's ~/.ssh/authorized_keys file.

# Generate an Ed25519 key pair
ssh-keygen -t ed25519 -C "developer-workstation"

# Copy the public key to a server (where supported)
ssh-copy-id deployer@server.example.com

# Inspect the remote host key fingerprint on first connection
ssh-keygen -lf ~/.ssh/known_hosts

Protect private keys with appropriate file permissions and a passphrase. Verify server host keys through a trusted channel. Do not disable host-key checking as a routine workaround.

Server hardening: Prefer key-based access, restrict who can log in, avoid direct root SSH login, and use firewall rules or a private management network. Change SSH settings carefully and keep an existing session open until the new configuration is verified.

07. The Linux Shell and Command Structure

A shell reads commands and starts programs. Bash is common on Linux, but other shells exist. A command usually has a program name followed by options and arguments.

command [options] [arguments]

# Examples
whoami
date
uname -a
hostnamectl
pwd

Use man command or command --help to inspect options. Be careful when copying commands from tutorials: understand the target path and the effect of each option before running them with elevated privileges.

08. Navigate the Linux Filesystem

Linux organizes files in a single directory tree beginning at /. Drives and volumes are mounted into this tree rather than assigned letters like Windows drives.

pwd                 # Show current directory
ls -lah             # List files, including hidden entries
cd /var/log         # Change directory
cd ~                # Go to home directory
mkdir -p app/releases
touch notes.txt
cp source.txt backup.txt
mv old-name.txt new-name.txt
rm temporary.txt

Use destructive commands carefully: rm -r, rm -rf, recursive permission changes, and wildcard paths can delete or alter large parts of a server. Confirm the current directory and target before execution.

09. Important Linux Directories

Path	Purpose
/	Filesystem root
/etc	System and service configuration
/var	Variable data such as logs, cache and spool files
/var/log	System and application logs (configuration-dependent)
/home	Regular users' home directories
/root	Root user's home directory
/usr	Most user-space programs, libraries and shared data
/opt	Optional third-party application software
/tmp	Temporary files
/mnt and /media	Common mount points
/srv	Site-specific service data (convention)

These are common conventions, not a guarantee that every server uses each directory in exactly the same way.

10. Read, Search and Inspect Files

cat appsettings.json
less /var/log/syslog
head -n 30 file.txt
tail -n 50 file.txt
tail -f /var/log/my-api/app.log

grep -n "error" application.log
grep -R "listen" /etc/nginx
find /var/www -type f -name "*.dll"

less is useful for large files; press q to exit. tail -f follows new log lines. Use grep and find with a clear search scope to avoid scanning unnecessary filesystem areas.

11. Users, Groups and Account Management

Linux uses user and group identities to decide who can access files and perform privileged actions. Services should normally run under a dedicated, unprivileged service account rather than a personal administrator account.

whoami
id
getent passwd deployer
getent group www-data

# Create a service account (administrative action)
sudo useradd --system --home /var/lib/my-api \
  --shell /usr/sbin/nologin my-api

# Add a user to an existing group (verify group first)
sudo usermod -aG www-data deployer

Group membership changes may require a new login session. Do not add users to broad privileged groups unless their duties require it.

12. Linux File Permissions: Read, Write and Execute

Each file has an owner, a group, and permission bits for owner, group, and others. The common symbols are r (read), w (write), and x (execute or directory traversal).

For directories, execute permission means the ability to traverse/search the directory. A user may need execute permission on every parent directory in the path to reach a file.

13. chmod: Change File Permissions

chmod changes permission bits. You can use symbolic permissions or octal numbers.

# Symbolic form
chmod u+x deploy.sh
chmod g-w appsettings.json
chmod o-r secret.txt

# Octal form: owner 7, group 5, others 0
chmod 750 deploy.sh

# Common private file permission
chmod 600 ~/.ssh/id_ed25519

Octal values combine read=4, write=2, execute=1. Therefore 7 means rwx, 5 means r-x, and 0 means no permissions. Choose permissions based on the actual service identity and access requirement.

14. chown, umask and Safe Ownership

# Change owner and group
sudo chown my-api:my-api /opt/my-api/MyApi.dll

# Apply ownership recursively only when intended
sudo chown -R my-api:my-api /var/lib/my-api

# Show the current file-creation mask
umask

umask removes permissions from the default mode used when new files and directories are created. A common value is 022, but service and security requirements vary. Avoid broad recursive chown or chmod commands on system directories.

15. sudo and Privilege Management

sudo allows an authorized user to run a command with elevated privileges. It is generally safer than logging in as root for routine administration.

sudo systemctl status nginx
sudo apt update
sudo journalctl -u my-api.service -n 100

Use visudo to edit sudoers configuration because it validates syntax. Grant the smallest command set that supports the operational role. A shell with unrestricted sudo is effectively full administrator access.

16. Processes and Process IDs

A process is a running program instance. Each process has a process ID (PID), an owner, resource usage, and a lifecycle. A service may spawn child processes.

ps aux
ps -ef
pgrep -a dotnet
pidof nginx
top
htop

Use process inspection to answer practical questions: Is the API running? Which account owns it? Is CPU usage unexpectedly high? Are multiple instances running? Process state alone does not prove that an HTTP endpoint is healthy.

17. Signals and Process Management

Linux processes receive signals for events such as termination, interruption, or reload. SIGTERM asks a process to stop gracefully; SIGKILL forces termination and cannot be caught by the process.

kill -TERM 1234
kill -KILL 1234   # Last resort only
pkill -TERM -f "MyApi.dll"

Prefer stopping a managed service through systemctl rather than killing its process manually. A service manager knows how the process should be stopped, restarted, and supervised.

18. CPU, Memory, Disk and Resource Checks

free -h
df -h
df -i
du -sh /var/log/*
lsblk
uptime
vmstat 1
iostat -xz 1

These commands help distinguish memory pressure, disk capacity, inode exhaustion, I/O wait, and CPU load. Some tools such as iostat and vmstat may require installing a package such as sysstat or procps, depending on the distribution.

When a server is slow, correlate resource metrics with application logs, database latency, network behavior, and recent deployments instead of assuming the CPU is the only cause.

19. systemd and Linux Services

systemd is a common init and service manager on modern Linux distributions. It starts services during boot, supervises processes, manages dependencies, and provides service logs through the journal.

sudo systemctl status nginx
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl enable nginx
sudo systemctl disable nginx

enable configures a service to start at boot; it does not necessarily start it immediately. start starts it now. reload asks a service to re-read configuration when that service supports reload.

20. Create a systemd Service for an ASP.NET Core API

A systemd unit describes how to run the application, which account to use, where it runs, and how it should restart. This example assumes the application has been published to /opt/my-api and the my-api service account exists.

# /etc/systemd/system/my-api.service
[Unit]
Description=My ASP.NET Core API
After=network.target

[Service]
WorkingDirectory=/opt/my-api
ExecStart=/usr/bin/dotnet /opt/my-api/MyApi.dll
Restart=always
RestartSec=5
User=my-api
Group=my-api
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=ASPNETCORE_URLS=http://127.0.0.1:5000

[Install]
WantedBy=multi-user.target

# Load the unit and start the service
sudo systemctl daemon-reload
sudo systemctl enable --now my-api
sudo systemctl status my-api

Confirm the installed .NET runtime path and service account permissions on your server. Store production secrets in a secure provider or protected environment mechanism, not directly in a world-readable unit file.

21. Read Logs with journalctl

# Recent logs for a service
sudo journalctl -u my-api.service -n 100

# Follow logs live
sudo journalctl -u my-api.service -f

# Logs since the current boot
sudo journalctl -b

# Logs for a time range
sudo journalctl -u my-api.service --since "1 hour ago"

Use structured application logging and include correlation identifiers where appropriate. Avoid logging passwords, bearer tokens, connection strings, or unnecessary personal data. Journal retention depends on system configuration.

22. Linux Networking Fundamentals

Networking connects processes on a machine to other machines. The most useful concepts for application developers are IP addresses, interfaces, routes, DNS, ports, TCP, UDP, and firewalls.

In this design, the public client reaches Nginx on HTTPS. Nginx forwards the request to the API over loopback. The API port does not need to be exposed to the public internet.

23. Inspect IP Addresses, Routes and DNS

ip address
ip route
ip link
ss -tulpn
hostname -I

# DNS lookups
getent hosts example.com
resolvectl status
dig example.com

ip inspects interfaces and routes; ss shows sockets and listening ports. dig may need the dnsutils package on Ubuntu. DNS tools and resolver configuration vary by distribution.

24. Ports, TCP, UDP and Firewalls

A port identifies a network endpoint on a host. TCP provides a reliable ordered byte stream; UDP provides datagrams without TCP's delivery guarantees. HTTP/1.1 and HTTP/2 commonly use TCP, while HTTP/3 uses QUIC over UDP.

Port	Common service	Typical exposure
22/TCP	SSH	Management network or restricted source IPs
80/TCP	HTTP	Public when redirecting to HTTPS or serving HTTP
443/TCP	HTTPS	Public web traffic
5000/TCP	Example local ASP.NET Core app port	Usually loopback/private behind proxy
1433/TCP	SQL Server default port	Private application/database network only

Configure both the cloud network firewall/security group and the host firewall where applicable. Allow only required traffic. A host firewall rule cannot compensate for an accidentally public database listener or weak authentication.

25. UFW: A Simple Ubuntu Firewall Interface

sudo ufw status verbose

# Allow SSH before enabling UFW on a remote server
sudo ufw allow OpenSSH

# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable firewall
sudo ufw enable

Remote access caution: If you enable a firewall before allowing your SSH path, you can lock yourself out. Confirm the management port and source restrictions with your infrastructure team before applying rules.

26. Install and Update Software with APT

APT manages software packages on Ubuntu and Debian-based distributions. Keep the package index current and apply security updates according to your maintenance process.

sudo apt update
apt list --upgradable
sudo apt upgrade

# Search and install a package
apt search nginx
sudo apt install nginx

# Inspect package details
apt show nginx

On RHEL-family systems, use dnf instead. Production servers should have a planned patch window, backup/rollback strategy, and a way to verify critical services after updates.

27. Environment Variables and Application Configuration

Linux processes inherit environment variables from their parent process or service manager. ASP.NET Core can read configuration from environment variables; double underscores represent nested configuration keys.

# Example for a process or shell session
export ASPNETCORE_ENVIRONMENT=Production
export ASPNETCORE_URLS=http://127.0.0.1:5000

# ASP.NET Core nested configuration example
export ConnectionStrings__AppDb="(supply securely at runtime)"

Do not put real passwords in shell history, process listings, screenshots, or publicly readable service definitions. Prefer a managed secret store or a tightly permissioned runtime secret delivery mechanism.

28. Publish an ASP.NET Core Application for Linux

Build and publish the application in Release configuration. Framework-dependent publishing requires a compatible .NET runtime on the server. Self-contained publishing includes the runtime for the selected target runtime identifier, but it still requires OS-native dependencies and patch management.

# Framework-dependent publish
dotnet publish -c Release -o ./publish

# Example self-contained publish for 64-bit Linux
dotnet publish -c Release -r linux-x64 \
  --self-contained true -o ./publish-linux

Choose the runtime identifier that matches the server architecture (for example, x64 or arm64). Verify the supported OS and native dependencies. A self-contained app does not remove the need to update and republish when runtime security fixes are released.

29. Deploy the Application to a Linux Server

A simple deployment flow is: publish, transfer the artifact, place it in a versioned release directory, set ownership, update the service, and verify health.

# Transfer published files from your workstation
scp -r ./publish/* deployer@server.example.com:/tmp/my-api/

# On the server, place files in the application directory
sudo mkdir -p /opt/my-api
sudo cp -a /tmp/my-api/. /opt/my-api/
sudo chown -R my-api:my-api /opt/my-api

# Restart and verify
sudo systemctl restart my-api
sudo systemctl status my-api
curl -i http://127.0.0.1:5000/health

This is a learning example, not a zero-downtime deployment strategy. For production, use immutable/versioned releases, health checks, rollback, controlled permissions, and an automated deployment pipeline.

30. Nginx: What It Does

Nginx is commonly used as a web server and reverse proxy. It can accept public HTTP/HTTPS connections, terminate TLS, serve static files, apply routing rules, and forward dynamic requests to an application server such as Kestrel.

31. Install and Validate Nginx

sudo apt update
sudo apt install nginx

sudo systemctl status nginx
sudo nginx -t
sudo systemctl reload nginx

nginx -t checks configuration syntax and referenced files. Test configuration before reloading so a typo does not take down a working site. Package versions and default paths depend on the distribution and repository.

32. Configure Nginx as a Reverse Proxy for .NET

A server block can forward requests to the local Kestrel endpoint. The example assumes the ASP.NET Core application listens on 127.0.0.1:5000.

# Example Nginx server block
server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

For production, configure HTTPS, certificate renewal, appropriate request-size and timeout limits, and trusted forwarded-header handling in ASP.NET Core. Do not trust forwarded headers from arbitrary clients; configure known proxies or networks.

33. TLS, HTTPS and Certificates

TLS protects data in transit and authenticates the server when clients validate its certificate. Production web traffic should use HTTPS with a valid certificate and automated renewal monitoring.

• Obtain certificates from a trusted certificate authority.
• Protect private key files with restrictive ownership and permissions.
• Automate renewal and verify that reloads occur after renewal.
• Redirect HTTP to HTTPS where appropriate.
• Use modern TLS configuration supported by your platform and security policy.
• Monitor expiry and test renewal before the certificate is close to expiring.

Do not disable certificate validation in production clients to work around trust errors.

34. ASP.NET Core Forwarded Headers Behind Nginx

When Nginx terminates TLS and forwards a request over HTTP to Kestrel, the application may need forwarded headers to understand the original scheme and client address. Configure trusted proxies explicitly.

// Configure trusted forwarded headers in ASP.NET Core.
// Add only the proxy addresses/networks you actually trust.
builder.Services.Configure(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor |
        ForwardedHeaders.XForwardedProto;
});

// Place early in the middleware pipeline.
app.UseForwardedHeaders();

Exact configuration depends on your network topology and ASP.NET Core version. Do not clear trusted-proxy restrictions and accept forwarded headers from the public internet without a carefully reviewed reason.

35. IIS: Windows Web Server Fundamentals

Internet Information Services (IIS) is Microsoft's web server for Windows. It can host ASP.NET Core applications using the ASP.NET Core Module (ANCM), which forwards requests to the application process or manages its startup depending on hosting model.

IIS and Nginx solve overlapping web-server and reverse-proxy problems but belong to different operating-system ecosystems and have different administration models.

36. IIS Hosting Models: In-Process and Out-of-Process

With in-process hosting, the ASP.NET Core application runs inside the IIS worker process. With out-of-process hosting, IIS forwards requests to a separate Kestrel process managed through the ASP.NET Core Module.

Model	Request flow	Consideration
In-process	IIS worker process hosts the app	Often the default choice for IIS hosting; app runs within the IIS worker process
Out-of-process	IIS → ANCM → Kestrel	Separate app process; useful where process isolation or hosting requirements call for it

For current deployment guidance, follow the ASP.NET Core hosting documentation and install the matching Hosting Bundle on the Windows server.

37. Nginx vs IIS: When to Use Each

Area	Nginx on Linux	IIS on Windows
Typical OS	Linux (also available on other platforms)	Windows Server
ASP.NET Core runtime	Kestrel behind Nginx is common	ASP.NET Core Module integrates with IIS
Configuration	Text-based server blocks and files	IIS Manager, PowerShell, configuration files
Operations	systemd, shell, package manager, Linux logs	Windows services, PowerShell, Event Viewer
Choose when	Linux/cloud/container environment fits the workload	Windows integration or existing IIS operations are important

Neither is universally better. Choose based on application requirements, team skills, hosting platform, operational support, licensing, and the wider architecture.

38. Linux Deployment Architecture for a .NET Application

Production infrastructure also needs backups, patch management, secret storage, restricted administration, health checks, and a documented recovery plan. The diagram shows the main request path, not every component a production system may require.

39. Backups, Updates and Server Maintenance

Server administration is ongoing work. A server that was secure and healthy at deployment can become vulnerable or unavailable when updates are missed, disks fill, certificates expire, or backups cannot be restored.

• Patch the operating system, .NET runtime, Nginx/IIS, and application dependencies.
• Back up application data and configuration with protected access.
• Test restores; a backup that has never been restored is unverified.
• Monitor disk capacity, memory, CPU, service health, and certificate expiry.
• Keep an inventory of hosts, owners, environments, and exposed ports.
• Document maintenance windows, rollback, and emergency access.

40. Server Troubleshooting: A Practical Sequence

When a deployed API is unavailable, work from the outside in and collect evidence before changing configuration.

1. Confirm the reported URL, time, environment, and scope of impact.
2. Check DNS resolution and whether the server is reachable.
3. Check firewall rules and whether expected ports are listening.
4. Check Nginx/IIS service status and configuration validation.
5. Check the ASP.NET Core process or systemd service status.
6. Read service and application logs for startup errors and exceptions.
7. Call the application locally to separate proxy problems from application problems.
8. Check database connectivity, disk space, memory, and recent changes.
9. Apply the smallest safe fix, verify, and record the cause.

sudo systemctl status nginx
sudo nginx -t
sudo systemctl status my-api
sudo journalctl -u my-api -n 100
ss -tulpn
df -h
free -h
curl -i http://127.0.0.1:5000/health

41. Common Linux Administration Mistakes

• Using chmod 777 to solve every permission problem.
• Running the web application as root unnecessarily.
• Exposing Kestrel or database ports directly to the internet.
• Editing Nginx configuration without running nginx -t.
• Restarting services without checking logs or the impact on users.
• Putting secrets into shell history, source control, or readable service files.
• Enabling a firewall before allowing the remote management path.
• Assuming a process is healthy just because it exists.
• Updating production without backups, rollback, or verification.

42. Practical Mini Project: Deploy a .NET 10 API on Linux

Use a disposable Ubuntu Server LTS virtual machine or cloud VM. Do not experiment with firewall, SSH, or destructive filesystem commands on a production server.

1. Create a small .NET 10 Web API with a health endpoint.
2. Connect to the VM using SSH keys and a non-root account.
3. Update the OS and install the required .NET runtime or SDK.
4. Publish the API for the target Linux architecture.
5. Create a dedicated service user and a protected application directory.
6. Configure a systemd unit and verify service startup and logs.
7. Install Nginx and configure it as a reverse proxy to loopback Kestrel.
8. Configure HTTPS and restrict inbound ports using cloud and host firewall rules.
9. Test the public endpoint, local health endpoint, restart behavior, and logs.
10. Document deployment, rollback, patching, and backup procedures.

Expected deliverables: a working API, systemd unit, Nginx server block, firewall rule list, and a short runbook describing how to troubleshoot the deployment.

43. Interview Questions and Answers

1. What is Linux?

Linux is an open-source kernel used by many operating-system distributions that combine it with user-space tools and packages.

2. What is a Linux distribution?

A distribution packages the Linux kernel, system tools, libraries, package manager, and software into an installable operating system.

3. What is SSH?

SSH is an encrypted protocol for remote login and command execution.

4. What is the difference between a user and a group?

A user represents an account identity; groups collect users and help manage shared permissions.

5. What does chmod 755 mean?

The owner has read, write and execute; group and others have read and execute.

6. What is the purpose of chown?

It changes the owner and/or group associated with a filesystem object.

7. What is a process ID?

A PID is the numeric identifier assigned to a running process.

8. What is systemd?

It is a common Linux init and service manager used to start and supervise services.

9. What is journalctl?

It is the command-line tool for querying logs stored by systemd-journald.

10. What is a reverse proxy?

A server that accepts client requests and forwards them to one or more backend services.

11. Why put Nginx in front of Kestrel?

Nginx can handle public connections, TLS and proxying while Kestrel runs the ASP.NET Core application behind it.

12. What is the difference between TCP and UDP?

TCP provides a reliable ordered byte stream; UDP sends datagrams without TCP's delivery and ordering guarantees.

13. What does ss -tulpn show?

It displays socket information, including listening TCP/UDP sockets and process details when permissions allow.

14. What is the difference between systemctl enable and start?

Enable configures a service to start at boot; start starts it immediately.

15. How does IIS host ASP.NET Core?

IIS uses the ASP.NET Core Module to host the application in-process or forward requests to a separate Kestrel process.

16. Why should an application run as a non-root user?

It limits the damage possible if the application process is compromised.

17. What is the purpose of UFW?

UFW is a simplified firewall management interface commonly used on Ubuntu.

18. How do you troubleshoot an API returning 502?

Check proxy configuration and logs, confirm the backend process is running and listening, call it locally, and inspect application startup logs and network connectivity.

44. Linux Server Administration Checklist

• Use supported OS and .NET LTS versions and apply security updates.
• Use SSH keys, verify host keys, and restrict administrative access.
• Run applications under dedicated non-root service accounts.
• Apply least-privilege file and directory permissions.
• Manage services with systemd and inspect journal logs.
• Expose only required ports and restrict management/database access.
• Use Nginx or IIS deliberately as the public web-server layer.
• Use HTTPS with protected keys and certificate renewal monitoring.
• Keep secrets outside source code and broadly readable files.
• Monitor resource usage, application health, and service availability.
• Back up data and test restore procedures.
• Document deployment, rollback, and incident response.

45. Official Documentation and Further Learning

• Ubuntu Server documentation
• Ubuntu 26.04 LTS release notes
• Install .NET on Linux
• Host ASP.NET Core on Linux with Nginx
• Host ASP.NET Core on Windows with IIS
• Host ASP.NET Core on Linux with systemd
• Nginx documentation
• systemd manual pages
• Linux man-pages project
• .NET support policy

Use distribution and vendor documentation for the exact server release you operate. Commands, package names, default paths, service units, and support windows can differ by release.

46. Final Thought

Server administration is the bridge between writing software and keeping it available in the real world. You do not need to become a full-time system administrator to deploy a .NET application responsibly, but you should understand the operating system, service lifecycle, permissions, network path, reverse proxy, logs, and recovery process.

Practice on a test virtual machine, learn to diagnose one layer at a time, and automate repeatable deployment steps. A reliable application depends on both good code and a well-managed environment.

Skills Tutorials – Learn • Build • Grow Together

Skills Tutorials

Learn • Build • Grow Together