🐧 Ubuntu Linux — Guide Complet (Desktop / Server / Cloud / AWS)

Why Ubuntu became a professional standard

Ubuntu became a common professional choice because it offers a practical balance: easier than many traditional server distributions for newcomers, stable enough for production when using LTS, and supported by a huge ecosystem of packages, tutorials, cloud images and vendor documentation.

Professional value map

Ubuntu knowledge helps in:

                            Backend engineering
                            ├── deploy APIs
                            ├── manage services
                            ├── inspect logs
                            └── debug network and permissions

                            DevOps
                            ├── automate installs
                            ├── configure systemd
                            ├── harden SSH
                            ├── manage packages
                            └── operate containers

                            SRE / Production
                            ├── monitor CPU/RAM/disk/network
                            ├── investigate incidents
                            ├── patch security updates
                            ├── tune services
                            └── write runbooks

                            Cloud engineering
                            ├── boot cloud images
                            ├── use cloud-init
                            ├── configure storage
                            ├── set firewall rules
                            └── deploy workloads

Recruiter-friendly summary

Applications / Services
                            ├── nginx
                            ├── postgres
                            ├── redis
                            ├── django
                            ├── docker
                            └── monitoring agents
                            │
                            ▼
                            User space
                            ├── bash / shell
                            ├── GNU tools
                            ├── systemd
                            ├── journald
                            ├── apt / dpkg
                            ├── ssh
                            └── libraries
                            │
                            ▼
                            Linux kernel
                            ├── process scheduler
                            ├── memory management
                            ├── filesystem layer
                            ├── network stack
                            ├── security modules
                            └── drivers
                            │
                            ▼
                            Hardware / Hypervisor
                            ├── CPU
                            ├── RAM
                            ├── disk
                            ├── network card
                            ├── KVM / VMware
                            └── cloud hypervisor

What each layer means in operations

Use-case examples

Desktop:
                            - Python development
                            - Docker-based local stack
                            - SSH into production servers
                            - Kubernetes and cloud CLI tools

                            Server:
                            - Nginx reverse proxy
                            - Django or Node.js API
                            - PostgreSQL or Redis host
                            - monitoring server
                            - VPN or bastion host

                            Cloud:
                            - EC2 instance
                            - Azure VM
                            - GCP Compute Engine
                            - OpenStack instance
                            - Kubernetes node

Edition decision tree

Need a local workstation?
                            └── Ubuntu Desktop

                            Need a production VM?
                            └── Ubuntu Server LTS

                            Need a cloud instance?
                            └── Ubuntu cloud image

                            Need a container base?
                            └── Ubuntu minimal/base image

                            Need IoT appliance-like OS?
                            └── Ubuntu Core

                            Need enterprise security extensions?
                            └── Ubuntu LTS + Ubuntu Pro

Practical distinction

Ubuntu is frequently chosen in production because of the LTS model. LTS means long-term support: a stable base release used for servers, cloud images and enterprise deployments. Non-LTS releases are useful for newer software, but less common as a conservative production baseline.

Upgrade strategy

Safe production upgrade path:

                            1. Inventory servers and services
                            2. Confirm current Ubuntu version
                            3. Check application compatibility
                            4. Snapshot or backup
                            5. Test upgrade on staging
                            6. Review package changes
                            7. Schedule maintenance window
                            8. Upgrade one node first
                            9. Validate services and logs
                            10. Roll out progressively
                            11. Keep rollback plan ready

Version management commands

# Show Ubuntu version
                            lsb_release -a

                            # Show OS release file
                            cat /etc/os-release

                            # Show kernel version
                            uname -a

                            # Update package lists
                            sudo apt update

                            # Upgrade installed packages
                            sudo apt upgrade

                            # Full upgrade with dependency changes
                            sudo apt full-upgrade

                            # Check reboot requirement
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

Release risk table

In enterprise environments, Ubuntu is used when teams need a stable Linux baseline with strong cloud support, broad package availability, automation compatibility and a known operational model. It is especially common for backend platforms, DevOps infrastructure, Kubernetes nodes, CI runners and cloud-hosted services.

Production server lifecycle

Provision
                            │
                            ├── select Ubuntu LTS image
                            ├── configure cloud-init
                            ├── attach disk
                            └── configure network
                            │
                            ▼
                            Harden
                            │
                            ├── SSH keys
                            ├── disable root login
                            ├── firewall
                            ├── unattended upgrades policy
                            └── least-privilege users
                            │
                            ▼
                            Deploy
                            │
                            ├── install packages
                            ├── configure services
                            ├── systemd unit files
                            └── application release
                            │
                            ▼
                            Operate
                            │
                            ├── logs
                            ├── metrics
                            ├── backups
                            ├── patching
                            └── incident response

Professional checklist

[ ] LTS release selected
                            [ ] SSH key access only
                            [ ] sudo policy controlled
                            [ ] firewall enabled
                            [ ] services managed by systemd
                            [ ] logs visible through journalctl
                            [ ] backups configured
                            [ ] monitoring installed
                            [ ] security updates planned
                            [ ] disk usage monitored
                            [ ] certificates tracked
                            [ ] rollback plan documented

First diagnostic commands

# System identity
                            hostnamectl
                            cat /etc/os-release
                            uptime

                            # CPU and memory
                            top
                            free -h

                            # Disk usage
                            df -h
                            du -sh /var/log/*

                            # Network
                            ip a
                            ip r
                            ss -lntp
                            resolvectl status

                            # Services
                            systemctl status nginx
                            journalctl -u nginx --since "30 min ago"

                            # Packages
                            apt policy nginx
                            dpkg -l | grep nginx

                            # Security
                            sudo ufw status verbose
                            sudo journalctl -u ssh --since today

Django deployment example

Internet
                            │
                            ▼
                            Nginx
                            │
                            ├── TLS termination
                            ├── static files
                            └── reverse proxy
                            │
                            ▼
                            Gunicorn systemd service
                            │
                            ▼
                            Django application
                            │
                            ├── PostgreSQL
                            ├── Redis
                            ├── Celery workers
                            └── media/static storage

Example service units

Common systemd units:
                            - nginx.service
                            - postgresql.service
                            - redis-server.service
                            - docker.service
                            - gunicorn.service
                            - celery.service
                            - celerybeat.service
                            - prometheus-node-exporter.service

                            Typical commands:
                            sudo systemctl enable nginx
                            sudo systemctl restart gunicorn
                            sudo systemctl status redis-server
                            journalctl -u celery -f

Minimal web server setup flow

1. Create server
                            2. Update packages
                            3. Create deploy user
                            4. Configure SSH
                            5. Install Nginx
                            6. Install app runtime
                            7. Configure database
                            8. Create systemd service
                            9. Configure TLS
                            10. Enable firewall
                            11. Add monitoring
                            12. Add backup
                            13. Document runbook

Incident diagnostic decision tree

Application is down
                            │
                            ├── Is server reachable?
                            │       ├── no  -> network, firewall, cloud, DNS
                            │       └── yes
                            │
                            ├── Is service running?
                            │       ├── no  -> systemctl status + journalctl
                            │       └── yes
                            │
                            ├── Is port listening?
                            │       ├── no  -> config or bind failure
                            │       └── yes
                            │
                            ├── Is reverse proxy healthy?
                            │       ├── no  -> nginx config/logs
                            │       └── yes
                            │
                            ├── Is database reachable?
                            │       ├── no  -> DB service/network/auth
                            │       └── yes
                            │
                            └── Is app throwing errors?
                            ├── yes -> application logs
                            └── no  -> upstream routing/cache/client issue

First-response commands

systemctl status nginx
                            journalctl -u nginx --since "15 min ago"
                            ss -lntp
                            df -h
                            free -h
                            top
                            sudo ufw status
                            curl -I http://localhost
                            curl -I https://example.com

Learning roadmap

Ubuntu learning path:

                            1. Shell basics
                            2. Filesystem and permissions
                            3. Users, groups and sudo
                            4. apt and packages
                            5. systemd services
                            6. journald and logs
                            7. networking and DNS
                            8. firewall and SSH hardening
                            9. storage and mounts
                            10. Nginx reverse proxy
                            11. database service operation
                            12. Docker host usage
                            13. backups and restore
                            14. monitoring and alerting
                            15. cloud-init and automation

One-line positioning

Ubuntu App Center is the graphical software interface on Ubuntu Desktop. It is designed for easy discovery, installation and removal of common applications. It is convenient for desktop workflows, but it is not the primary tool for server automation or strict production package governance.

Typical App Center flow

Ubuntu Desktop
                            │
                            ├── Open App Center
                            ├── Search application
                            ├── Review publisher and package type
                            ├── Click Install
                            ├── Authenticate if required
                            ├── Launch application
                            └── Update through system update flow

What to verify before installing

Before installing a desktop app:
                            [ ] Is the publisher trusted?
                            [ ] Is it a Snap, DEB or Flatpak package?
                            [ ] Is the app maintained?
                            [ ] Does it need sensitive permissions?
                            [ ] Is there an official vendor package?
                            [ ] Is it needed system-wide or only for one user?
                            [ ] Is it appropriate for a professional workstation?

Graphical vs CLI management

Useful desktop package checks

# Show installed Snap packages
                            snap list

                            # Show installed DEB packages
                            dpkg -l | less

                            # Search APT package
                            apt search package-name

                            # Show package origin
                            apt policy package-name

                            # Show Flatpak apps if installed
                            flatpak list

Ubuntu is based on Debian packaging. A .deb file is a Debian package. APT is the higher-level tool that downloads packages from repositories, resolves dependencies, installs upgrades and tracks package versions.

APT essentials

# Update package metadata
                            sudo apt update

                            # Install package from repository
                            sudo apt install nginx

                            # Install local DEB file with dependency resolution
                            sudo apt install ./package.deb

                            # Remove package but keep config
                            sudo apt remove package-name

                            # Remove package and config
                            sudo apt purge package-name

                            # Upgrade packages
                            sudo apt upgrade

                            # Show package details
                            apt show package-name

                            # Show installed and candidate versions
                            apt policy package-name

DEB installation flow

Local DEB file
                            │
                            ├── verify source
                            ├── check vendor signature or checksum if available
                            ├── install with apt
                            │       └── sudo apt install ./package.deb
                            ├── inspect installed package
                            │       └── dpkg -l | grep package
                            ├── verify service or binary
                            └── document install source

Package inspection commands

# List installed packages
                            dpkg -l

                            # Filter installed packages
                            dpkg -l | grep nginx

                            # Show package status
                            dpkg -s nginx

                            # Show files installed by package
                            dpkg -L nginx

                            # Find package owning a file
                            dpkg -S /usr/sbin/nginx

                            # Show APT history
                            less /var/log/apt/history.log

                            # Show available versions
                            apt-cache madison nginx

Production DEB rules

Do:
                            - prefer repository installation over random downloads
                            - use official vendor DEB if needed
                            - keep package source documented
                            - automate installation in scripts or Ansible
                            - review apt history after changes

                            Avoid:
                            - random DEB files from unknown sites
                            - manual installs without documentation
                            - local DEB files with no update path
                            - mixing multiple competing repositories
                            - installing critical server packages from untrusted sources

Snap packages bundle applications with their dependencies and run with a confinement model. They are distributed through the Snap ecosystem and can use channels such as stable, candidate, beta or edge. Snap refresh behavior is important because packages can update automatically.

Snap commands

# List installed snaps
                            snap list

                            # Search for app
                            snap find package-name

                            # Show package info
                            snap info package-name

                            # Install stable channel
                            sudo snap install package-name --channel=stable

                            # Refresh snaps
                            sudo snap refresh

                            # Show refresh schedule
                            snap refresh --time

                            # Remove snap
                            sudo snap remove package-name

Snap operations

# Show changes
                            snap changes

                            # Show connections
                            snap connections package-name

                            # Connect interface
                            sudo snap connect package-name:interface

                            # Revert to previous revision if available
                            sudo snap revert package-name

                            # Hold refresh temporarily
                            sudo snap refresh --hold=24h package-name

                            # Logs for snap service
                            snap logs package-name

Snap decision tree

Considering Snap?
                            │
                            ├── Desktop application?
                            │       └── often acceptable
                            │
                            ├── Server daemon?
                            │       ├── check refresh policy
                            │       ├── check confinement
                            │       ├── check logs
                            │       └── check rollback
                            │
                            ├── Need strict package timing?
                            │       └── prefer APT or control refresh window
                            │
                            └── Need sandboxed app delivery?
                            └── Snap can be a good fit

Snap strengths and cautions

Flatpak is a cross-distribution packaging system often used for desktop applications. Applications run with a sandbox model and rely on runtimes. Flatpak is especially common when users want recent desktop applications independently from the system package version.

Install Flatpak support

# Install Flatpak
                            sudo apt update
                            sudo apt install flatpak

                            # Add Flathub remote
                            flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

                            # Search app
                            flatpak search gimp

                            # Install app
                            flatpak install flathub org.gimp.GIMP

                            # Run app
                            flatpak run org.gimp.GIMP

Flatpak operations

# List installed apps
                            flatpak list

                            # List remotes
                            flatpak remotes

                            # Update apps
                            flatpak update

                            # Show app info
                            flatpak info org.gimp.GIMP

                            # Uninstall app
                            flatpak uninstall org.gimp.GIMP

                            # Remove unused runtimes
                            flatpak uninstall --unused

                            # Show app permissions
                            flatpak info --show-permissions org.gimp.GIMP

Flatpak fit

Flatpak vs Snap mental model

Snap:
                            - integrated by default on Ubuntu
                            - used for desktop apps and selected system tools
                            - has channels and refresh behavior

                            Flatpak:
                            - popular for cross-distro desktop apps
                            - commonly uses Flathub
                            - strong desktop application ecosystem
                            - often installed separately on Ubuntu

A PPA is a third-party APT repository hosted on Launchpad. PPAs are useful when the official Ubuntu repository does not provide the needed version, but they must be treated as trust decisions. Adding a PPA can change package candidates, dependencies and upgrade behavior.

PPA commands

# Install helper if needed
                            sudo apt install software-properties-common

                            # Add PPA
                            sudo add-apt-repository ppa:owner/name

                            # Update metadata
                            sudo apt update

                            # Install package
                            sudo apt install package-name

                            # Show package origin and candidate
                            apt policy package-name

                            # Remove PPA source
                            sudo add-apt-repository --remove ppa:owner/name

PPA governance flow

Need a PPA?
                            │
                            ├── Is package available in official Ubuntu repo?
                            │       ├── yes -> prefer official repo
                            │       └── no
                            │
                            ├── Is there an official vendor repository?
                            │       ├── yes -> prefer vendor repo
                            │       └── no
                            │
                            ├── Is PPA trusted and maintained?
                            │       ├── no -> reject
                            │       └── yes
                            │
                            ├── Is this production?
                            │       ├── yes -> document and test in staging
                            │       └── no -> acceptable for lab if understood
                            │
                            └── Add with owner, reason and review date

Inspect repository sources

# Source list files
                            ls -lah /etc/apt/sources.list.d/

                            # Search active deb lines
                            grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

                            # Show package candidate and priorities
                            apt policy package-name

                            # Show all versions
                            apt-cache madison package-name

                            # Recent repository changes
                            sudo find /etc/apt -type f -mtime -30 -ls

PPA risk matrix

Choice diagram

Choose package format
                            │
                            ├── Is this a production server dependency?
                            │       ├── yes -> APT / DEB / official vendor repo
                            │       └── no
                            │
                            ├── Is this a desktop GUI app?
                            │       ├── yes -> App Center, Snap or Flatpak
                            │       └── no
                            │
                            ├── Do you need newest upstream version?
                            │       ├── yes -> official vendor repo first
                            │       ├── then PPA if trusted
                            │       └── document exception
                            │
                            ├── Do you need sandboxed desktop app?
                            │       ├── yes -> Snap or Flatpak
                            │       └── no
                            │
                            └── Need reproducible fleet?
                            └── automate APT and pin sources

Use-case recommendations

Software installation is a supply-chain decision. Every package source can install code with user or system privileges. Good governance means knowing where software comes from, how it updates, who maintains it and how to roll back when it breaks.

Pre-install security checklist

[ ] Is the source official?
                            [ ] Is the publisher trusted?
                            [ ] Is the package maintained?
                            [ ] Is the update mechanism known?
                            [ ] Is the package type known?
                            [ ] Is the installation reversible?
                            [ ] Is the version documented?
                            [ ] Does it add a repository?
                            [ ] Does it add a signing key?
                            [ ] Does it run a script as root?
                            [ ] Does it request sensitive permissions?
                            [ ] Is it approved for production?

Install script warning pattern

Risky pattern:
                            curl https://example.com/install.sh | sudo bash

                            Safer pattern:
                            1. Download script
                            2. Inspect script
                            3. Verify source
                            4. Verify checksum or signature if available
                            5. Run intentionally
                            6. Record package source
                            7. Test in staging first

Repository audit commands

# Show APT sources
                            grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

                            # List source files
                            ls -lah /etc/apt/sources.list.d/

                            # Show package origin
                            apt policy package-name

                            # Show installed Snap packages
                            snap list

                            # Show Flatpak remotes and apps
                            flatpak remotes
                            flatpak list

                            # Show recent package operations
                            less /var/log/apt/history.log

Production software governance

Governance record:
                            - package name
                            - package type
                            - source repository
                            - publisher
                            - installed version
                            - update policy
                            - rollback method
                            - owner
                            - reason
                            - review date

APT repair commands

# Repair interrupted package configuration
                            sudo dpkg --configure -a

                            # Fix broken dependencies
                            sudo apt -f install

                            # Refresh metadata
                            sudo apt update

                            # Clean package cache
                            sudo apt clean

                            # Check holds
                            apt-mark showhold

                            # Review package history
                            less /var/log/apt/history.log
                            less /var/log/apt/term.log

Package troubleshooting decision tree

Software install failed
                            │
                            ├── Read exact error
                            │
                            ├── APT lock?
                            │       └── check apt/dpkg process
                            │
                            ├── DNS or network?
                            │       └── resolvectl, dig, curl
                            │
                            ├── Signature or key?
                            │       └── inspect source and keyring
                            │
                            ├── Dependency conflict?
                            │       └── apt policy, apt -f install, holds
                            │
                            ├── PPA conflict?
                            │       └── disable source, apt update
                            │
                            ├── Snap confinement?
                            │       └── snap connections
                            │
                            └── Flatpak permission?
                            └── flatpak info --show-permissions

Disable source temporarily

# Disable a repository source file
                            sudo mv /etc/apt/sources.list.d/vendor.list \
                            /etc/apt/sources.list.d/vendor.list.disabled

                            # Refresh metadata
                            sudo apt update

                            # Check package candidate again
                            apt policy package-name

Snap and Flatpak diagnostics

# Snap
                            snap list
                            snap info package-name
                            snap changes
                            snap connections package-name
                            snap logs package-name

                            # Flatpak
                            flatpak list
                            flatpak remotes
                            flatpak info app-id
                            flatpak info --show-permissions app-id
                            flatpak update

Software management checklist

[ ] Package type is understood
                            [ ] Source is trusted
                            [ ] Publisher is verified
                            [ ] Update mechanism is known
                            [ ] Rollback path exists
                            [ ] Repository additions are documented
                            [ ] PPAs are justified
                            [ ] Vendor repos are preferred over random PPAs
                            [ ] Local DEB files are avoided unless necessary
                            [ ] Snap refresh behavior is understood
                            [ ] Flatpak remotes are known
                            [ ] Production servers use governed sources
                            [ ] Package changes are traceable
                            [ ] Staging test exists for critical software
                            [ ] Security updates are planned

APT / DEB cheat sheet

sudo apt update
                            sudo apt install package-name
                            sudo apt install ./package.deb
                            sudo apt remove package-name
                            sudo apt purge package-name
                            sudo apt upgrade
                            apt search package-name
                            apt show package-name
                            apt policy package-name
                            dpkg -l | grep package-name
                            dpkg -L package-name
                            dpkg -S /path/to/file
                            less /var/log/apt/history.log

Snap / Flatpak / PPA cheat sheet

# Snap
                            snap list
                            snap find package-name
                            snap info package-name
                            sudo snap install package-name
                            sudo snap refresh
                            snap refresh --time
                            sudo snap remove package-name

                            # Flatpak
                            flatpak remotes
                            flatpak search package-name
                            flatpak install flathub app-id
                            flatpak run app-id
                            flatpak update
                            flatpak uninstall app-id

                            # PPA
                            sudo apt install software-properties-common
                            sudo add-apt-repository ppa:owner/name
                            sudo apt update
                            apt policy package-name
                            sudo add-apt-repository --remove ppa:owner/name

Final rule

Production default

Production software default:
                            - Ubuntu LTS
                            - official Ubuntu repositories
                            - official vendor repositories when needed
                            - no random PPAs
                            - no unknown DEB downloads
                            - package baseline automated
                            - update policy documented
                            - rollback path tested
                            - package history reviewed after changes

Decision shortcut

Choose LTS when:
                            - server is production
                            - database is production
                            - uptime matters
                            - patching must be predictable
                            - infrastructure must be standardized
                            - cloud images are reused
                            - upgrade windows are rare
                            - compliance matters

                            Choose interim when:
                            - testing newer kernel
                            - testing new desktop stack
                            - testing new hardware support
                            - environment is disposable
                            - upgrade cadence is accepted
                            - production risk is low

Common professional rule

Bad decision examples

Bad:
                            - installing an interim release on a long-lived database server
                            - using different Ubuntu versions randomly across servers
                            - upgrading production without staging validation
                            - ignoring end-of-support dates
                            - choosing a release because it is "newer" only

                            Better:
                            - define one production LTS baseline
                            - define patch cadence
                            - define upgrade window
                            - keep rollback images
                            - document exceptions

Ubuntu versions use a year.month format. For example, 24.04 means a release from April 2024. LTS releases are usually April releases in even-numbered years. Point releases such as 24.04.4 are refreshed installation images for the same LTS family.

Version naming pattern

Ubuntu version format:
                            YY.MM

                            Examples:
                            22.04 = April 2022
                            24.04 = April 2024
                            25.10 = October 2025

                            LTS examples:
                            20.04 LTS
                            22.04 LTS
                            24.04 LTS

                            Point release examples:
                            22.04.5 LTS
                            24.04.3 LTS
                            24.04.4 LTS

                            Meaning:
                            major LTS family + refreshed installer media

Release interpretation flow

See a version number
                            │
                            ▼
                            Is it marked LTS?
                            ├── yes
                            │   ├── good production candidate
                            │   ├── check standard support date
                            │   └── check Pro/ESM if long-lived
                            │
                            └── no
                            ├── interim release
                            ├── check short support date
                            └── use mainly for dev/test unless justified

Useful official sources

Ubuntu release cycle:
                            https://ubuntu.com/about/release-cycle

                            Ubuntu releases:
                            https://releases.ubuntu.com/

                            Ubuntu release list:
                            https://documentation.ubuntu.com/project/release-team/list-of-releases/

                            Ubuntu release notes:
                            https://documentation.ubuntu.com/release-notes/

Support lifecycle matters because an unsupported server becomes a security and compliance risk. Once a release is out of standard support, teams must either upgrade, use an extended maintenance option if available, or retire the system.

Support responsibility map

Operating system lifecycle
                            │
                            ├── security updates
                            ├── kernel updates
                            ├── package patches
                            ├── repository availability
                            ├── vendor support
                            └── compliance status

                            Operations team responsibility
                            │
                            ├── know release version
                            ├── know support end date
                            ├── patch regularly
                            ├── plan reboots
                            ├── test upgrades
                            └── avoid unsupported servers

Timeline diagram

LTS release
                            │
                            ├── Year 0
                            │       └── release becomes production candidate
                            │
                            ├── Years 0-5
                            │       ├── standard security maintenance
                            │       ├── point releases
                            │       ├── cloud images maintained
                            │       └── normal production usage
                            │
                            ├── After standard support
                            │       ├── upgrade recommended
                            │       └── ESM / Ubuntu Pro may be used
                            │
                            └── Long-lived legacy phase
                            ├── higher operational risk
                            ├── stronger justification required
                            └── migration plan should exist

Operational policy example

Company Ubuntu policy:
                            - production servers use LTS only
                            - new projects use current LTS point image
                            - old LTS versions are reviewed quarterly
                            - unsupported releases are forbidden
                            - interim releases require architecture approval
                            - upgrade tests must pass in staging
                            - rollback image must exist
                            - patching window is monthly
                            - emergency CVE patching is immediate

Production decision matrix

Production workload?
                            ├── yes -> LTS
                            └── no
                            │
                            ▼
                            Long-lived machine?
                            ├── yes -> LTS
                            └── no
                            │
                            ▼
                            Need newest kernel/userspace?
                            ├── yes -> interim or LTS HWE
                            └── no -> LTS

                            Compliance or security audit?
                            └── LTS + documented patch policy

Version choice scoring

Ubuntu upgrades should be treated as infrastructure changes, not casual package updates. A release upgrade may change kernel, libraries, system services, defaults, packages, Python versions, OpenSSL behavior, firewall tooling or network configuration.

Safe upgrade process

1. Inventory
                            - server role
                            - Ubuntu version
                            - kernel version
                            - installed packages
                            - services
                            - external repositories

                            2. Prepare
                            - backup data
                            - snapshot VM
                            - export configs
                            - check disk space
                            - review release notes

                            3. Test
                            - clone staging
                            - upgrade staging
                            - run application tests
                            - validate logs and services

                            4. Execute
                            - schedule maintenance
                            - stop risky jobs
                            - upgrade
                            - reboot
                            - validate services

                            5. Verify
                            - application health
                            - network ports
                            - logs
                            - performance
                            - monitoring

                            6. Rollback if needed
                            - restore snapshot
                            - restore old image
                            - revert DNS or load balancer

Upgrade architecture

Current production server
                            │
                            ├── snapshot / AMI / backup
                            ├── package inventory
                            ├── config export
                            └── staging clone
                            │
                            ▼
                            Staging upgrade
                            │
                            ├── do-release-upgrade
                            ├── reboot
                            ├── service validation
                            ├── application tests
                            └── performance checks
                            │
                            ▼
                            Production rollout
                            │
                            ├── one node first
                            ├── monitor
                            ├── continue rollout
                            └── keep rollback window

Blue/green alternative

Instead of in-place upgrade:

                            1. Build new Ubuntu LTS image
                            2. Install application stack
                            3. Restore or connect data
                            4. Run smoke tests
                            5. Attach to load balancer
                            6. Shift traffic gradually
                            7. Keep old server as rollback
                            8. Retire old server after validation

                            Often safer for:
                            - web apps
                            - stateless APIs
                            - container hosts
                            - cloud workloads

Version inspection

# Ubuntu version
                            lsb_release -a

                            # OS release metadata
                            cat /etc/os-release

                            # Kernel version
                            uname -a

                            # Host and OS summary
                            hostnamectl

                            # Architecture
                            dpkg --print-architecture

                            # Check codename only
                            lsb_release -cs

Package maintenance

# Refresh package indexes
                            sudo apt update

                            # Show upgradeable packages
                            apt list --upgradable

                            # Upgrade installed packages
                            sudo apt upgrade

                            # Full upgrade with dependency changes
                            sudo apt full-upgrade

                            # Remove unused packages
                            sudo apt autoremove

                            # Check held packages
                            apt-mark showhold

Reboot and upgrade readiness

# Check if reboot is required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # See packages requiring reboot if available
                            cat /var/run/reboot-required.pkgs 2>/dev/null

                            # Check disk space before upgrades
                            df -h

                            # Check package manager locks
                            ps aux | grep -E 'apt|dpkg'

                            # Repair interrupted package operation
                            sudo dpkg --configure -a
                            sudo apt -f install

Release upgrade

# Install release upgrade tool if missing
                            sudo apt install update-manager-core

                            # Check release upgrader configuration
                            cat /etc/update-manager/release-upgrades

                            # Start release upgrade
                            sudo do-release-upgrade

                            # Server session safety
                            sudo apt install screen
                            screen -S upgrade
                            sudo do-release-upgrade

In cloud environments, Ubuntu versioning becomes part of your infrastructure standard. Teams usually define a base image: Ubuntu LTS version, packages, users, SSH hardening, monitoring agent, logging agent, cloud-init behavior and security baseline.

Cloud image lifecycle

Official Ubuntu LTS cloud image
                            │
                            ▼
                            Golden image pipeline
                            │
                            ├── install baseline packages
                            ├── configure SSH
                            ├── add monitoring agent
                            ├── apply security hardening
                            ├── apply updates
                            └── run validation tests
                            │
                            ▼
                            Approved image
                            │
                            ├── used by Terraform
                            ├── used by autoscaling groups
                            ├── used by Kubernetes nodes
                            └── used by application servers
                            │
                            ▼
                            Periodic rebuild
                            ├── security patches
                            ├── config changes
                            └── new point release

Cloud version rules

Recommended:
                            - use LTS for production cloud VMs
                            - pin or control image selection
                            - rebuild images regularly
                            - test cloud-init on target release
                            - document image version
                            - keep rollback image available
                            - avoid unmanaged snowflake servers

                            Avoid:
                            - latest image without validation
                            - random Ubuntu versions across fleet
                            - old images with no patch process
                            - manual changes after boot with no automation

Version risk decision tree

Server has old Ubuntu version
                            │
                            ▼
                            Is it still in standard support?
                            ├── yes
                            │   ├── keep patched
                            │   └── plan future migration
                            │
                            └── no
                            │
                            ▼
                            Is ESM / Pro enabled and valid?
                            ├── yes
                            │   ├── use as temporary bridge
                            │   └── plan upgrade
                            │
                            └── no
                            │
                            ▼
                            Risk is high
                            ├── isolate if necessary
                            ├── snapshot
                            ├── test upgrade path
                            └── migrate or retire

Upgrade failure symptoms

After upgrade, check:
                            - service fails to start
                            - port no longer listens
                            - Python or PHP version changed
                            - OpenSSL behavior changed
                            - Nginx config warning becomes fatal
                            - database extension mismatch
                            - kernel module missing
                            - firewall rule behavior changed
                            - DNS resolution changed
                            - cloud-init or network config changed

Version governance checklist

[ ] Approved Ubuntu LTS baseline is defined
                            [ ] Interim releases require explicit exception
                            [ ] Fleet inventory contains Ubuntu version
                            [ ] Fleet inventory contains kernel version
                            [ ] Support end dates are tracked
                            [ ] Old LTS migration plan exists
                            [ ] ESM / Pro usage is documented if used
                            [ ] Golden images are versioned
                            [ ] Cloud image selection is controlled
                            [ ] Third-party apt repositories are inventoried
                            [ ] Release notes are reviewed before upgrade
                            [ ] Staging upgrade test is mandatory
                            [ ] Rollback method is documented
                            [ ] Reboot policy exists for kernel updates
                            [ ] Patch cadence is documented

Minimum production baseline

Production Ubuntu baseline:
                            - LTS release
                            - latest approved point image
                            - security updates enabled
                            - patch window defined
                            - reboot policy defined
                            - monitored support end date
                            - standard package repositories
                            - controlled third-party repositories
                            - backup/snapshot before major upgrade
                            - staging validation before production rollout

Final decision summary

Final rule

BASH is both an interactive shell and a scripting language. It receives commands, expands variables, resolves paths, runs programs, connects outputs to inputs and lets you automate tasks through scripts.

BASH essentials

# Show current directory
                            pwd

                            # Show current user
                            whoami

                            # Show command history
                            history

                            # Clear screen
                            clear

                            # Show current shell
                            echo $SHELL

                            # Show environment variables
                            env

                            # Show PATH
                            echo $PATH

                            # Show command location
                            which bash
                            which python3
                            which nginx

Pipes and redirects

# Pipe output to another command
                            ps aux | grep nginx

                            # Redirect output to a file
                            ls -lah /var/log > files.txt

                            # Append output to a file
                            date >> audit.log

                            # Redirect errors too
                            command > output.log 2> error.log

                            # Redirect output and errors together
                            command > all.log 2>&1

                            # View long output page by page
                            journalctl -u nginx | less

Useful keyboard shortcuts

Navigation is the first terminal skill. You need to know where you are, what files are present, how to move between directories and how to distinguish absolute and relative paths.

Navigation examples

# Where am I?
                            pwd

                            # List current directory
                            ls

                            # Detailed list with hidden files
                            ls -lah

                            # Go to logs
                            cd /var/log

                            # Go home
                            cd ~

                            # Go one level up
                            cd ..

                            # Go to previous directory
                            cd -

                            # List directory without entering it
                            ls -lah /etc/nginx

Ubuntu filesystem map

/
                            ├── etc      system configuration
                            ├── home     user home directories
                            ├── var      logs, cache, databases, runtime data
                            ├── srv      service/application data
                            ├── opt      optional third-party software
                            ├── usr      installed programs and libraries
                            ├── tmp      temporary files
                            ├── boot     bootloader and kernel files
                            ├── dev      device files
                            ├── proc     process and kernel virtual filesystem
                            └── root     root user's home directory

Path examples

Absolute paths:
                            - /etc/nginx/nginx.conf
                            - /var/log/syslog
                            - /srv/myapp
                            - /home/deploy/.ssh/authorized_keys

                            Relative paths:
                            - ./script.sh
                            - ../backup
                            - logs/app.log
                            - ../../etc/example.conf

                            Special paths:
                            - .  current directory
                            - .. parent directory
                            - ~  current user's home directory
                            - /  filesystem root

File operations are powerful and dangerous. Copying, moving and deleting files from the terminal is fast, but usually does not ask for confirmation unless you request it. In production, create backups before editing or deleting configuration files.

File operation examples

# Create a directory tree
                            mkdir -p /srv/myapp/releases

                            # Create an empty file
                            touch /tmp/test.txt

                            # Copy a file
                            cp config.ini config.ini.bak

                            # Copy a directory with attributes
                            cp -a /etc/nginx /etc/nginx.bak.$(date +%Y%m%d-%H%M%S)

                            # Rename a file
                            mv old.conf new.conf

                            # Move a file to backup directory
                            mv app.log /tmp/app.log.bak

                            # Remove a file
                            rm old-file.txt

Danger zone: rm

# Remove one file
                            rm file.txt

                            # Ask before deleting
                            rm -i file.txt

                            # Remove directory recursively
                            rm -r directory

                            # Force recursive delete - dangerous
                            rm -rf directory

                            # Extremely dangerous if path is wrong
                            sudo rm -rf /some/path

Safe deletion workflow

Before deleting:
                            1. Show current directory
                            pwd

                            2. List target
                            ls -lah target

                            3. Check size if directory
                            du -sh target

                            4. Move to quarantine first
                            mv target /tmp/target.to-delete

                            5. Verify service still works

                            6. Delete later if safe

Backup-before-edit pattern

# Backup config before edit
                            sudo cp -a /etc/nginx/nginx.conf \
                            /etc/nginx/nginx.conf.bak.$(date +%Y%m%d-%H%M%S)

                            # Edit file
                            sudo vim /etc/nginx/nginx.conf

                            # Validate before reload
                            sudo nginx -t

                            # Reload if valid
                            sudo systemctl reload nginx

Reading and searching files is a core Linux skill. Logs, configuration, service units, environment files and scripts are plain text. The right command depends on file size and whether you need the beginning, the end, live follow or keyword search.

Read commands

# Small file
                            cat /etc/os-release

                            # Large file, scroll
                            less /var/log/syslog

                            # First lines
                            head -50 /var/log/syslog

                            # Last lines
                            tail -100 /var/log/syslog

                            # Follow live
                            tail -f /var/log/syslog

                            # Number lines
                            nl config.ini | less

Search examples

# Case-insensitive search
                            grep -i "error" app.log

                            # Search recursively
                            grep -R "server_name" /etc/nginx

                            # Show line numbers
                            grep -n "listen" /etc/nginx/sites-enabled/*

                            # Exclude noisy files
                            grep -R "DEBUG" /srv/myapp --exclude="*.pyc"

                            # Search compressed logs
                            zgrep -i "error" /var/log/syslog.*.gz

                            # Find files by name
                            find /etc -name "*.conf"

                            # Find large files
                            find /var -type f -size +100M -exec ls -lh {} \;

                            # Find recently modified files
                            find /etc -type f -mtime -2 -ls

Log reading pattern

When debugging logs:
                            1. Identify time window
                            2. Read service-specific logs first
                            3. Search for first real error
                            4. Correlate with recent deploy/update
                            5. Avoid reading huge files without filters

                            Examples:
                            journalctl -u nginx --since "30 min ago"
                            grep -i "permission denied" app.log
                            grep -i "connection refused" app.log

sudo runs a command with elevated privileges, usually as root. On Ubuntu, normal users do not directly administer protected system areas. Instead, trusted users are added to the sudo group and elevate only when needed.

sudo examples

# Update packages
                            sudo apt update

                            # Edit protected config
                            sudo vim /etc/ssh/sshd_config

                            # Restart service
                            sudo systemctl restart nginx

                            # Read protected log
                            sudo tail -100 /var/log/auth.log

                            # Run command as postgres user
                            sudo -u postgres psql

                            # Check your sudo privileges
                            sudo -l

sudo mental model

Normal user
                            │
                            ├── can read/write own files
                            ├── cannot edit system files
                            ├── cannot restart system services
                            └── cannot install packages
                            │
                            ▼
                            sudo
                            │
                            ├── asks for authentication
                            ├── checks sudoers policy
                            ├── logs action
                            └── runs command with elevated privilege

User sudo setup

# Create user
                            sudo adduser deploy

                            # Add to sudo group
                            sudo usermod -aG sudo deploy

                            # Check group membership
                            groups deploy

                            # Show sudo group
                            getent group sudo

                            # Edit sudoers safely
                            sudo visudo

sudo safety rules

Do:
                            - use sudo for specific commands
                            - keep named admin users
                            - review sudo group members
                            - use visudo for sudoers edits
                            - log administrative changes

                            Avoid:
                            - logging in directly as root
                            - running long sessions as root
                            - using sudo with unknown scripts
                            - using sudo rm -rf without path verification
                            - granting sudo to every user

chmod changes file permissions. Linux permissions are split into three groups: owner, group and others. Each can have read, write and execute permissions. For directories, execute means “can enter/traverse”.

Permission notation

Example:
                            -rw-r--r-- 1 root root 1200 app.conf

                            Breakdown:
                            -       file type
                            rw-     owner permissions
                            r--     group permissions
                            r--     others permissions

                            r = read
                            w = write
                            x = execute / enter directory

chmod examples

# Normal file readable by everyone, writable by owner
                            chmod 644 config.ini

                            # Directory accessible by everyone, writable by owner
                            chmod 755 /srv/myapp

                            # Private SSH directory
                            chmod 700 ~/.ssh

                            # Private SSH key
                            chmod 600 ~/.ssh/id_ed25519

                            # Authorized keys
                            chmod 600 ~/.ssh/authorized_keys

                            # Make script executable
                            chmod +x deploy.sh

                            # Remove write access for group and others
                            chmod go-w file.txt

Numeric mode logic

Permission values:
                            r = 4
                            w = 2
                            x = 1

                            Examples:
                            7 = 4 + 2 + 1 = rwx
                            6 = 4 + 2     = rw-
                            5 = 4 + 1     = r-x
                            4 = 4         = r--

                            chmod 755:
                            owner = 7 = rwx
                            group = 5 = r-x
                            other = 5 = r-x

                            chmod 640:
                            owner = 6 = rw-
                            group = 4 = r--
                            other = 0 = ---

Permission troubleshooting

# Show permissions
                            ls -lah file

                            # Show full path permissions
                            namei -l /srv/myapp/current/.env

                            # Show current user groups
                            id

                            # Test as service user
                            sudo -u myapp cat /srv/myapp/.env

chown changes file owner and group. Many permission errors are not caused by missing chmod, but by wrong ownership. Services such as Nginx, Gunicorn, PostgreSQL or application workers must be able to read the files they need, but should not own everything as root.

chown examples

# Change one file owner
                            sudo chown deploy app.log

                            # Change owner and group
                            sudo chown deploy:www-data /srv/myapp

                            # Change group only
                            sudo chown :www-data /srv/myapp/static

                            # Recursive change, use carefully
                            sudo chown -R deploy:www-data /srv/myapp

                            # App env file owned by root, readable by app group
                            sudo chown root:myapp /srv/myapp/.env
                            sudo chmod 640 /srv/myapp/.env

Ownership model for web app

/srv/myapp
                            │
                            ├── code files
                            │       ├── owner: deploy
                            │       └── group: www-data
                            │
                            ├── static files
                            │       ├── readable by nginx
                            │       └── not writable by public users
                            │
                            ├── .env secrets
                            │       ├── owner: root
                            │       ├── group: myapp
                            │       └── mode: 640
                            │
                            └── runtime logs/uploads
                            ├── owner: myapp
                            └── controlled write access

Service user checks

# Show service user in unit file
                            systemctl cat myapp

                            # Show process user
                            ps aux | grep gunicorn

                            # Check user groups
                            id myapp

                            # Check path permissions
                            namei -l /srv/myapp/current/.env

                            # Test access as service user
                            sudo -u myapp test -r /srv/myapp/.env && echo readable

Common ownership mistakes

The terminal is powerful because it does exactly what you ask. That also makes it dangerous. Professional terminal usage means verifying targets, backing up before edits, validating configs before restart and avoiding irreversible commands when a reversible action is possible.

Safe config edit workflow

# 1. Backup
                            sudo cp -a /etc/ssh/sshd_config \
                            /etc/ssh/sshd_config.bak.$(date +%Y%m%d-%H%M%S)

                            # 2. Edit
                            sudo vim /etc/ssh/sshd_config

                            # 3. Validate
                            sudo sshd -t

                            # 4. Restart only if valid
                            sudo systemctl restart ssh

                            # 5. Check logs
                            journalctl -u ssh --since "10 min ago"

Dangerous command patterns

Dangerous:
                            sudo rm -rf /
                            sudo rm -rf *
                            sudo chown -R user:user /
                            sudo chmod -R 777 /
                            sudo chmod -R 777 /var/www
                            curl URL | sudo bash
                            sudo mv /etc /tmp
                            docker compose down -v

                            Safer:
                            - verify path first
                            - backup first
                            - move instead of delete
                            - inspect scripts
                            - target exact directory
                            - keep rollback possible

Pre-flight checklist

Before destructive command:
                            [ ] Am I on the right server?
                            [ ] Am I in the right directory?
                            [ ] Did I list the target?
                            [ ] Did I check the size?
                            [ ] Do I have a backup?
                            [ ] Can I rollback?
                            [ ] Is the command scoped enough?
                            [ ] Am I using sudo unnecessarily?
                            [ ] Did I understand wildcard expansion?
                            [ ] Did I test on staging if production?

Know your context

# Confirm server
                            hostnamectl

                            # Confirm user
                            whoami

                            # Confirm directory
                            pwd

                            # Confirm target
                            ls -lah target

                            # Confirm disk and space
                            df -h
                            du -sh target

                            # Confirm command before sudo
                            echo sudo rm -rf target

Fundamental commands

# Navigation
                            pwd
                            ls
                            ls -lah
                            cd /path
                            cd ..
                            cd ~
                            cd -

                            # Files
                            cp file file.bak
                            cp -a dir dir.bak
                            mv old new
                            rm file
                            rm -i file
                            mkdir -p path/to/dir
                            touch file

                            # Read and search
                            cat file
                            less file
                            head -50 file
                            tail -100 file
                            tail -f file
                            grep -i "error" file
                            find /path -name "*.log"

                            # Context
                            whoami
                            id
                            hostnamectl
                            history
                            which command

sudo, chmod, chown cheat sheet

# sudo
                            sudo apt update
                            sudo systemctl restart nginx
                            sudo -l
                            sudo -u postgres psql
                            sudo visudo

                            # chmod
                            chmod 644 file
                            chmod 640 secret.env
                            chmod 755 directory
                            chmod 700 ~/.ssh
                            chmod 600 ~/.ssh/id_ed25519
                            chmod +x script.sh

                            # chown
                            sudo chown user file
                            sudo chown user:group file
                            sudo chown :group file
                            sudo chown -R user:group directory

                            # Diagnose permissions
                            ls -lah file
                            namei -l /path/to/file
                            id user
                            groups user

Final rule

Minimal professional reflexes

[ ] I know where I am with pwd
                            [ ] I inspect before changing with ls -lah
                            [ ] I backup config files before editing
                            [ ] I validate configs before restart
                            [ ] I avoid chmod 777
                            [ ] I understand sudo impact
                            [ ] I test SSH access before hardening
                            [ ] I move risky files before deleting
                            [ ] I use logs before restarting blindly
                            [ ] I document production changes

System updates fix bugs, close security vulnerabilities, improve hardware support and keep installed packages consistent with the Ubuntu release. Updates should be frequent enough to reduce exposure, but controlled enough to avoid surprise downtime on important machines.

Standard update flow

# 1. Refresh package metadata
                            sudo apt update

                            # 2. Review available upgrades
                            apt list --upgradable

                            # 3. Apply regular upgrades
                            sudo apt upgrade

                            # 4. Remove unused packages
                            sudo apt autoremove

                            # 5. Check if reboot is required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # 6. Verify system state
                            systemctl --failed
                            journalctl -p warning --since "30 min ago"

Update decision diagram

Updates available
                            │
                            ├── Desktop workstation?
                            │       ├── create Timeshift snapshot if major change
                            │       ├── apply updates
                            │       └── reboot if required
                            │
                            ├── Production server?
                            │       ├── review packages
                            │       ├── confirm backup/snapshot
                            │       ├── test staging if critical
                            │       ├── schedule maintenance window
                            │       └── apply and verify
                            │
                            └── Cloud VM?
                            ├── snapshot or image
                            ├── patch
                            ├── reboot if required
                            └── validate health checks

Reboot-required checks

# Check if reboot is required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "no reboot flag"

                            # Show packages that requested reboot if available
                            cat /var/run/reboot-required.pkgs 2>/dev/null

                            # Current kernel
                            uname -a

                            # Boot time
                            uptime
                            last reboot | head

Graphical update path

Ubuntu Desktop
                            │
                            ├── Open Software Updater
                            ├── Review proposed updates
                            ├── Install updates
                            ├── Reboot if requested
                            └── Verify desktop and main apps

A good update strategy balances speed and safety. Security updates should not be postponed indefinitely, but critical systems need backups, staging tests and rollback paths. The more important the machine, the more controlled the update process must be.

Unattended upgrades

# Install unattended upgrades
                            sudo apt update
                            sudo apt install unattended-upgrades

                            # Enable basic automatic security updates
                            sudo dpkg-reconfigure unattended-upgrades

                            # Main configuration files
                            /etc/apt/apt.conf.d/20auto-upgrades
                            /etc/apt/apt.conf.d/50unattended-upgrades

                            # Logs
                            sudo less /var/log/unattended-upgrades/unattended-upgrades.log

Safe production patch workflow

Patch workflow
                            │
                            ├── Inventory
                            │       ├── OS version
                            │       ├── kernel version
                            │       ├── critical packages
                            │       └── running services
                            │
                            ├── Protect
                            │       ├── backup
                            │       ├── snapshot
                            │       ├── Timeshift on desktop
                            │       └── rollback plan
                            │
                            ├── Apply
                            │       ├── apt update
                            │       ├── review upgrades
                            │       ├── apt upgrade
                            │       └── reboot if required
                            │
                            └── Verify
                            ├── systemctl --failed
                            ├── logs
                            ├── ports
                            ├── app health
                            └── user validation

Post-update validation

# Failed services
                            systemctl --failed

                            # Recent warnings
                            journalctl -p warning --since "30 min ago"

                            # Listening ports
                            ss -lntp

                            # Disk and memory
                            df -h
                            free -h

                            # Web smoke test
                            curl -I http://localhost

                            # Package history
                            less /var/log/apt/history.log

Update risk matrix

UFW is Ubuntu’s simple firewall interface. It helps expose only the ports required by the machine. A safe default is to deny incoming traffic, allow outgoing traffic, then explicitly allow SSH, web traffic or other required services.

UFW baseline

# Check current firewall status
                            sudo ufw status verbose

                            # Default policies
                            sudo ufw default deny incoming
                            sudo ufw default allow outgoing

                            # Allow SSH before enabling firewall
                            sudo ufw allow OpenSSH

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

                            # Enable firewall
                            sudo ufw enable

                            # Verify rules
                            sudo ufw status verbose
                            sudo ufw status numbered

Firewall decision diagram

New service installed
                            │
                            ├── Does it need network access?
                            │       ├── no -> keep local only
                            │       └── yes
                            │
                            ├── Should it be public?
                            │       ├── yes -> open exact required port
                            │       └── no
                            │
                            ├── Should it be private?
                            │       ├── yes -> restrict by source IP or subnet
                            │       └── no
                            │
                            └── Is rule documented?
                            ├── yes -> apply rule
                            └── no -> do not expose yet

Restrict by source

# Allow SSH from one admin IP
                            sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

                            # Allow PostgreSQL from one app server
                            sudo ufw allow from 10.0.1.25 to any port 5432 proto tcp

                            # Delete a numbered rule
                            sudo ufw status numbered
                            sudo ufw delete 3

                            # Deny a specific IP
                            sudo ufw deny from 198.51.100.44

UFW troubleshooting

# Firewall status
                            sudo ufw status verbose

                            # Listening ports
                            ss -lntp

                            # Local service test
                            curl -I http://localhost

                            # Kernel firewall logs if enabled
                            sudo ufw logging on
                            sudo journalctl -k --since "30 min ago" | grep UFW

Timeshift creates system restore points. It is useful on Ubuntu Desktop and some workstation scenarios before major updates, driver changes, package experiments or risky configuration changes. It is not a full personal-data backup solution by itself: it mainly protects system state.

Install Timeshift

# Install Timeshift
                            sudo apt update
                            sudo apt install timeshift

                            # Launch graphical interface
                            sudo timeshift-gtk

                            # CLI help
                            timeshift --help

                            # List snapshots
                            sudo timeshift --list

Timeshift workflow

Before risky change
                            │
                            ├── Open Timeshift
                            ├── Create snapshot
                            ├── Name or comment the snapshot
                            ├── Apply update or configuration change
                            ├── Reboot if required
                            ├── Verify system works
                            └── Keep or delete snapshot later

When to create a snapshot

Create a Timeshift snapshot before:
                            - major system update
                            - release upgrade
                            - driver installation
                            - desktop environment change
                            - kernel experiment
                            - repository or PPA experiment
                            - risky configuration edit
                            - important package removal

Timeshift vs backup

A complete protection strategy separates system restore from data backup. Timeshift can help restore the OS state. Personal files, project folders, databases, uploads, secrets and configuration must also be backed up separately.

Simple rsync backup example

# Backup home directory to external disk
                            rsync -aHAX --info=progress2 \
                            /home/user/ \
                            /media/user/backup/home-user/

                            # Backup project directory
                            rsync -a --delete \
                            /srv/myapp/ \
                            /backup/myapp/

                            # Dry run first
                            rsync -a --dry-run /source/ /destination/

Backup strategy diagram

Protection strategy
                            │
                            ├── System restore
                            │       ├── Timeshift
                            │       ├── VM snapshot
                            │       └── cloud image
                            │
                            ├── Data backup
                            │       ├── documents
                            │       ├── projects
                            │       ├── uploads
                            │       └── databases
                            │
                            ├── Configuration backup
                            │       ├── /etc
                            │       ├── service units
                            │       ├── nginx configs
                            │       └── SSH configs
                            │
                            └── Restore test
                            ├── can files be restored?
                            ├── can database be restored?
                            ├── can server boot?
                            └── is procedure documented?

Database backup examples

# PostgreSQL dump
                            pg_dump -U app_user -h localhost app_db > app_db.sql

                            # PostgreSQL compressed dump
                            pg_dump -U app_user -h localhost app_db | gzip > app_db.sql.gz

                            # MySQL / MariaDB dump
                            mysqldump -u app_user -p app_db > app_db.sql

                            # MySQL / MariaDB compressed dump
                            mysqldump -u app_user -p app_db | gzip > app_db.sql.gz

Backup quality checklist

[ ] Backup is automatic
                            [ ] Backup includes data, not only system files
                            [ ] Backup destination is separate from source disk
                            [ ] Backup has retention policy
                            [ ] Backup is encrypted if sensitive
                            [ ] Restore has been tested
                            [ ] Database backups are consistent
                            [ ] Secrets are protected
                            [ ] Backup logs are reviewed
                            [ ] Owner and schedule are documented

Logs are the first source of truth when Ubuntu behaves unexpectedly. They show service failures, authentication attempts, package operations, kernel events, disk errors, network issues and application errors.

journalctl essentials

# Recent errors and context
                            journalctl -xe

                            # Current boot logs
                            journalctl -b

                            # Previous boot logs
                            journalctl -b -1

                            # Service logs
                            journalctl -u nginx

                            # Service logs with time window
                            journalctl -u nginx --since "1 hour ago"

                            # Follow service logs live
                            journalctl -u nginx -f

                            # Warnings and errors
                            journalctl -p warning --since today

                            # Kernel logs
                            journalctl -k --since today

Classic log commands

# System log
                            sudo tail -200 /var/log/syslog

                            # Authentication log
                            sudo tail -200 /var/log/auth.log

                            # APT history
                            less /var/log/apt/history.log

                            # Search errors
                            grep -i "error" /var/log/syslog

                            # Search failed SSH attempts
                            sudo grep -i "failed password" /var/log/auth.log | tail -100

                            # Search sudo usage
                            sudo grep -i "sudo" /var/log/auth.log | tail -100

                            # Search OOM events
                            journalctl -k --since today | grep -i -E "oom|killed process"

Log reading workflow

Problem detected
                            │
                            ├── Identify time window
                            ├── Check failed services
                            ├── Read service journal
                            ├── Read system warnings
                            ├── Read kernel logs
                            ├── Check auth logs if access issue
                            ├── Check apt history if after update
                            └── Find first meaningful error

Journal size control

# Show journal disk usage
                            journalctl --disk-usage

                            # Keep only last 14 days
                            sudo journalctl --vacuum-time=14d

                            # Keep journal under 1 GB
                            sudo journalctl --vacuum-size=1G

Maintenance can fail: updates may be interrupted, repositories may break, firewall rules may block access, Timeshift snapshots may fill disk space, logs may grow, or services may fail after a package upgrade. Diagnose from the exact symptom.

APT repair commands

# Finish interrupted package configuration
                            sudo dpkg --configure -a

                            # Fix broken dependencies
                            sudo apt -f install

                            # Refresh metadata
                            sudo apt update

                            # Clean package cache
                            sudo apt clean

                            # Remove unused dependencies
                            sudo apt autoremove

                            # Review update history
                            less /var/log/apt/history.log
                            less /var/log/apt/term.log

Maintenance failure decision tree

Maintenance issue
                            │
                            ├── Package manager error?
                            │       ├── lock -> check apt/dpkg process
                            │       ├── broken -> dpkg --configure -a
                            │       └── repo -> inspect apt sources
                            │
                            ├── Firewall issue?
                            │       ├── check UFW rules
                            │       ├── verify SSH rule
                            │       └── test required ports
                            │
                            ├── Disk issue?
                            │       ├── check df -h
                            │       ├── check logs
                            │       ├── check snapshots
                            │       └── clean safely
                            │
                            ├── Service issue?
                            │       ├── systemctl status
                            │       ├── journalctl -u service
                            │       └── validate config
                            │
                            └── Bad update?
                            ├── use Timeshift if desktop
                            ├── use snapshot if VM
                            └── rollback package or config

Disk cleanup for maintenance

# Disk usage
                            df -h

                            # Large top-level directories
                            sudo du -xhd1 / 2>/dev/null | sort -h

                            # Journal usage and cleanup
                            journalctl --disk-usage
                            sudo journalctl --vacuum-time=14d

                            # APT cleanup
                            sudo apt clean
                            sudo apt autoremove

                            # Timeshift snapshots
                            sudo timeshift --list

A simple routine prevents many incidents. The goal is not to spend hours every day, but to maintain visibility: update status, disk usage, failed services, logs, backup state and restore readiness.

Weekly maintenance command block

echo "== SYSTEM =="
                            hostnamectl
                            uptime

                            echo "== UPDATES =="
                            sudo apt update
                            apt list --upgradable

                            echo "== DISK =="
                            df -h

                            echo "== FAILED SERVICES =="
                            systemctl --failed

                            echo "== WARNINGS TODAY =="
                            journalctl -p warning --since today --no-pager | tail -100

                            echo "== REBOOT REQUIRED =="
                            test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "no reboot flag"

Maintenance calendar

Daily
                            ├── monitor alerts
                            ├── failed services
                            └── backup success

                            Weekly
                            ├── package update review
                            ├── disk space review
                            ├── log warnings review
                            └── firewall exposure review

                            Monthly
                            ├── apply updates
                            ├── reboot if required
                            ├── test restore sample
                            ├── cleanup old logs/snapshots
                            └── review users and sudo

                            Before major upgrade
                            ├── backup data
                            ├── Timeshift or VM snapshot
                            ├── record current version
                            ├── apply change
                            └── verify and document

Server maintenance record

Maintenance record:
                            - date
                            - hostname
                            - Ubuntu version
                            - packages updated
                            - reboot required
                            - reboot performed
                            - services checked
                            - disk usage
                            - backup status
                            - warnings found
                            - actions taken
                            - rollback point
                            - operator

Maintenance checklist

[ ] Ubuntu LTS version is known
                            [ ] Package updates are reviewed regularly
                            [ ] Security updates are applied
                            [ ] Reboot-required status is checked
                            [ ] Reboot window exists for servers
                            [ ] Failed services are checked
                            [ ] Disk usage is monitored
                            [ ] Journal size is controlled
                            [ ] APT history is reviewed after updates
                            [ ] Timeshift is configured on desktop/workstation
                            [ ] Restore point is created before major changes
                            [ ] Data backup exists
                            [ ] Restore has been tested
                            [ ] Logs are readable
                            [ ] Maintenance actions are documented

Security checklist

[ ] UFW is enabled when appropriate
                            [ ] Default incoming policy is deny
                            [ ] Only required ports are open
                            [ ] SSH is protected
                            [ ] SSH source is restricted if possible
                            [ ] Root SSH login is disabled
                            [ ] Password SSH is disabled after key test
                            [ ] Users and sudo group are reviewed
                            [ ] Secrets are not world-readable
                            [ ] Backups are protected
                            [ ] Firewall rules are documented
                            [ ] Logs are reviewed after suspicious activity

Command cheat sheet

# Updates
                            sudo apt update
                            apt list --upgradable
                            sudo apt upgrade
                            sudo apt autoremove
                            sudo apt clean
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # Firewall
                            sudo ufw status verbose
                            sudo ufw default deny incoming
                            sudo ufw default allow outgoing
                            sudo ufw allow OpenSSH
                            sudo ufw allow 80/tcp
                            sudo ufw allow 443/tcp
                            sudo ufw enable

                            # Timeshift
                            sudo apt install timeshift
                            sudo timeshift-gtk
                            sudo timeshift --list

                            # Logs
                            journalctl -xe
                            journalctl -p warning --since today
                            journalctl -u SERVICE --since "1 hour ago"
                            journalctl -k --since today
                            sudo tail -100 /var/log/auth.log
                            less /var/log/apt/history.log

                            # Health
                            systemctl --failed
                            df -h
                            free -h
                            ss -lntp

Final rule

Minimal safe maintenance profile

Minimum safe profile:
                            - updates applied regularly
                            - reboot-required checked
                            - UFW configured
                            - SSH protected
                            - Timeshift or snapshot before major changes
                            - real data backup
                            - restore tested
                            - logs reviewed
                            - failed services checked
                            - disk usage monitored
                            - maintenance documented

Ubuntu Desktop installation is designed for workstations: developers, engineers, analysts and general desktop users. The main choices are language, keyboard, network, installation type, disk encryption, user account and optional third-party drivers.

Desktop install path

1. Download Ubuntu Desktop ISO
                            2. Verify checksum if required
                            3. Create bootable USB key
                            4. Boot in UEFI mode
                            5. Select language and keyboard
                            6. Connect to network
                            7. Choose normal or minimal install
                            8. Enable third-party drivers if needed
                            9. Choose disk layout
                            10. Enable encryption if laptop or sensitive data
                            11. Create admin user
                            12. Install and reboot
                            13. Remove USB key
                            14. Run updates
                            15. Install development tools

Desktop post-install developer baseline

# Update system
                            sudo apt update
                            sudo apt upgrade

                            # Install useful tools
                            sudo apt install curl wget git vim htop tree unzip ca-certificates

                            # Install build basics
                            sudo apt install build-essential pkg-config

                            # Install Python essentials
                            sudo apt install python3 python3-venv python3-pip

                            # Check version
                            lsb_release -a
                            uname -a

Developer workstation map

Ubuntu Desktop
                            │
                            ├── Terminal
                            ├── Git
                            ├── Python / Node / Java / Go
                            ├── Docker Desktop or Docker Engine
                            ├── IDE
                            ├── SSH keys
                            ├── browser dev tools
                            ├── cloud CLIs
                            └── VPN / security tooling

Ubuntu Server installation is usually text-based and focused on production readiness: network, storage, user account, SSH, package selection and minimal attack surface. A server should normally be installed without a desktop environment.

Server install path

1. Download Ubuntu Server ISO
                            2. Boot in UEFI mode
                            3. Select language and keyboard
                            4. Configure network
                            - DHCP for simple cases
                            - static IP for fixed infrastructure
                            5. Configure proxy if needed
                            6. Configure apt mirror
                            7. Choose disk layout
                            - guided LVM for most servers
                            - manual for advanced storage
                            8. Create admin user
                            9. Install OpenSSH server
                            10. Import SSH key if available
                            11. Select minimal server packages
                            12. Install bootloader
                            13. Reboot
                            14. Connect by SSH
                            15. Run post-install baseline

Server install architecture

Bare metal or VM
                            │
                            ▼
                            Ubuntu Server installer
                            │
                            ├── network setup
                            ├── disk layout
                            ├── user creation
                            ├── SSH setup
                            ├── package baseline
                            └── bootloader
                            │
                            ▼
                            First boot
                            │
                            ├── SSH login
                            ├── update packages
                            ├── harden access
                            ├── configure firewall
                            ├── install services
                            └── enable monitoring

First server commands

# Update package index and upgrade
                            sudo apt update
                            sudo apt upgrade

                            # Install baseline tools
                            sudo apt install curl wget vim git htop tree unzip net-tools dnsutils

                            # Check services
                            systemctl --failed
                            systemctl status ssh

                            # Check network
                            ip a
                            ip r
                            ss -lntp

                            # Check storage
                            lsblk
                            df -h

Modern Ubuntu installations should normally boot in UEFI mode. UEFI affects the boot partition, bootloader installation and compatibility with Secure Boot. If the USB key is booted in legacy BIOS mode, the final installation may not match the target firmware configuration.

Boot media preparation

Recommended flow:
                            1. Download ISO from official source
                            2. Verify ISO checksum if required
                            3. Write USB with Rufus, Balena Etcher or dd
                            4. Boot USB in UEFI mode
                            5. Install Ubuntu
                            6. Reboot without USB key
                            7. Confirm system boots from target disk

UEFI disk layout sketch

Disk /dev/sda
                            │
                            ├── EFI System Partition
                            │       ├── size: 512 MB to 1 GB
                            │       ├── filesystem: FAT32
                            │       └── mount: /boot/efi
                            │
                            ├── /boot
                            │       ├── optional separate partition
                            │       └── kernel and initramfs
                            │
                            ├── LVM physical volume
                            │       ├── root volume /
                            │       ├── var volume /var
                            │       ├── home volume /home
                            │       └── swap volume or swapfile
                            │
                            └── free space or data volumes

Boot verification commands

# Check if system booted in UEFI mode
                            test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"

                            # Show block devices
                            lsblk -f

                            # Show EFI boot entries
                            sudo efibootmgr -v

                            # Show mounted filesystems
                            findmnt

                            # Show boot partition
                            findmnt /boot/efi

Disk layout should reflect the server role. A laptop usually benefits from full-disk encryption. A server often benefits from LVM. A database server needs careful storage planning. A Docker host needs enough space under /var/lib/docker.

Example server layout

Small web server:
                            - /boot/efi     512 MB to 1 GB
                            - /             30 GB to 50 GB
                            - /var          20 GB to 100 GB
                            - /home         optional
                            - swap          swapfile or LV
                            - /srv          application data if needed

                            Docker host:
                            - /             30 GB to 50 GB
                            - /var          large volume
                            - /var/lib/docker on dedicated volume if possible

                            Database host:
                            - /             30 GB to 50 GB
                            - /var/log      separate or monitored
                            - /data         dedicated fast volume
                            - /backup       separate volume or external storage

Disk decision tree

Is it a laptop?
                            ├── yes -> enable disk encryption
                            └── no
                            │
                            ▼
                            Is it a production server?
                            ├── yes -> prefer LVM or cloud volume strategy
                            └── no -> automatic layout is acceptable

                            Will logs, Docker or DB grow?
                            ├── yes -> separate /var or data volume
                            └── no -> simple root filesystem

                            Need easy snapshot/resize?
                            ├── yes -> LVM or cloud block volumes
                            └── no -> simple partitioning

Storage inspection commands

# Show disks and partitions
                            lsblk

                            # Show filesystems
                            lsblk -f

                            # Show disk usage
                            df -h

                            # Show directory usage
                            sudo du -sh /var/*

                            # Show mounts
                            findmnt

                            # Show LVM volumes
                            sudo pvs
                            sudo vgs
                            sudo lvs

                            # Show swap
                            swapon --show
                            free -h

Server installation must make remote access reliable and safe. The minimum baseline is: one named sudo user, SSH key access, password authentication disabled where possible, root login disabled, firewall enabled and only required ports opened.

SSH hardening example

# Backup SSH config
                            sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

                            # Edit SSH config
                            sudo vim /etc/ssh/sshd_config

                            # Recommended directives
                            PermitRootLogin no
                            PasswordAuthentication no
                            PubkeyAuthentication yes
                            AllowUsers deploy

                            # Validate and restart
                            sudo sshd -t
                            sudo systemctl restart ssh

Firewall baseline

# Enable UFW
                            sudo ufw default deny incoming
                            sudo ufw default allow outgoing

                            # Allow SSH
                            sudo ufw allow OpenSSH

                            # Web server example
                            sudo ufw allow 80/tcp
                            sudo ufw allow 443/tcp

                            # Enable firewall
                            sudo ufw enable

                            # Check status
                            sudo ufw status verbose

Network diagnostic commands

# IP addresses
                            ip a

                            # Routes
                            ip r

                            # DNS status
                            resolvectl status

                            # Listening ports
                            ss -lntp

                            # Test local service
                            curl -I http://localhost

                            # Test remote host
                            ping -c 3 8.8.8.8

                            # Trace path
                            tracepath ubuntu.com

cloud-init is the standard way to initialize Ubuntu cloud images. It can create users, install packages, add SSH keys, write files, run commands, configure timezone and prepare the machine during first boot.

Minimal cloud-init example

#cloud-config
                            package_update: true
                            package_upgrade: true

                            users:
                            - name: deploy
                            groups: sudo
                            shell: /bin/bash
                            sudo: ['ALL=(ALL) NOPASSWD:ALL']
                            ssh_authorized_keys:
                            - ssh-ed25519 AAAA_REPLACE_WITH_PUBLIC_KEY deploy-key

                            packages:
                            - curl
                            - wget
                            - git
                            - vim
                            - htop
                            - ufw

                            runcmd:
                            - ufw allow OpenSSH
                            - ufw --force enable
                            - timedatectl set-timezone UTC

cloud-init lifecycle

Cloud VM first boot
                            │
                            ▼
                            cloud-init starts
                            │
                            ├── reads metadata
                            ├── reads user-data
                            ├── configures hostname
                            ├── creates users
                            ├── installs SSH keys
                            ├── installs packages
                            ├── writes files
                            ├── runs commands
                            └── marks initialization done
                            │
                            ▼
                            Server ready for automation
                            ├── Ansible
                            ├── deploy pipeline
                            ├── monitoring
                            └── application install

cloud-init diagnostics

# Show cloud-init status
                            cloud-init status

                            # Wait until finished
                            cloud-init status --wait

                            # Inspect logs
                            sudo less /var/log/cloud-init.log
                            sudo less /var/log/cloud-init-output.log

                            # Validate config file if tool is available
                            cloud-init schema --config-file user-data.yaml

                            # Re-run is not trivial on production
                            # Prefer rebuilding disposable cloud instances

Post-install is where a raw Ubuntu machine becomes a clean operating platform. The goal is to make the system secure, updated, observable, recoverable and ready for application deployment.

Post-install baseline commands

# Update system
                            sudo apt update
                            sudo apt upgrade

                            # Install useful admin tools
                            sudo apt install curl wget vim git htop tree unzip ca-certificates dnsutils

                            # Set timezone
                            timedatectl
                            sudo timedatectl set-timezone UTC

                            # Check failed units
                            systemctl --failed

                            # Check logs
                            journalctl -p warning --since today

                            # Check reboot requirement
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

Clean server baseline

Fresh Ubuntu Server
                            │
                            ├── system update
                            ├── admin user
                            ├── SSH key access
                            ├── root login disabled
                            ├── password auth disabled
                            ├── firewall enabled
                            ├── timezone configured
                            ├── monitoring installed
                            ├── log policy checked
                            ├── backups configured
                            ├── service manager ready
                            └── runbook documented

Server documentation template

Server record:
                            - hostname
                            - Ubuntu version
                            - kernel version
                            - role
                            - owner
                            - public IP
                            - private IP
                            - SSH port
                            - open firewall ports
                            - installed services
                            - data volumes
                            - backup policy
                            - monitoring URL
                            - patching window
                            - rollback method
                            - emergency contact

Diagnostic decision tree

Fresh server problem
                            │
                            ├── Does it boot?
                            │       ├── no -> UEFI, bootloader, disk
                            │       └── yes
                            │
                            ├── Does it have network?
                            │       ├── no -> IP, route, DNS, driver
                            │       └── yes
                            │
                            ├── Can you SSH?
                            │       ├── no -> ssh service, firewall, key, IP
                            │       └── yes
                            │
                            ├── Are packages working?
                            │       ├── no -> DNS, apt mirror, dpkg lock
                            │       └── yes
                            │
                            └── Are baseline services healthy?
                            ├── no -> systemctl and journalctl
                            └── yes -> server ready

Emergency commands

# SSH service
                            sudo systemctl status ssh
                            sudo systemctl restart ssh

                            # Firewall
                            sudo ufw status verbose

                            # Network
                            ip a
                            ip r
                            resolvectl status

                            # Package repair
                            sudo dpkg --configure -a
                            sudo apt -f install
                            sudo apt update

                            # Logs
                            journalctl -p err --since today
                            dmesg -T | tail -100

Before install

[ ] Target role is defined
                            [ ] Ubuntu edition selected
                            [ ] LTS version selected
                            [ ] ISO downloaded from official source
                            [ ] Checksum verified if required
                            [ ] Boot media created
                            [ ] UEFI mode confirmed
                            [ ] Disk layout planned
                            [ ] Static IP or DHCP decision made
                            [ ] Hostname chosen
                            [ ] Admin user chosen
                            [ ] SSH key available
                            [ ] Backup of existing data done
                            [ ] Rollback plan exists if replacing server

During install

[ ] Correct disk selected
                            [ ] EFI partition created if UEFI
                            [ ] LVM selected if server needs flexibility
                            [ ] Encryption enabled if needed
                            [ ] OpenSSH server installed
                            [ ] Admin user created
                            [ ] Network works
                            [ ] Bootloader installed correctly
                            [ ] Machine reboots without USB

After install

[ ] System updated
                            [ ] Reboot performed if required
                            [ ] SSH key login tested
                            [ ] Root SSH login disabled
                            [ ] Password SSH disabled after key validation
                            [ ] Firewall enabled
                            [ ] Only required ports open
                            [ ] Timezone and time sync configured
                            [ ] Hostname correct
                            [ ] Disk usage checked
                            [ ] Failed systemd units checked
                            [ ] Monitoring installed
                            [ ] Backup configured
                            [ ] Server documented
                            [ ] Snapshot or image created if needed

Final rule

Minimal safe server baseline

Minimum safe server:
                            - Ubuntu Server LTS
                            - named sudo user
                            - SSH key access
                            - root login disabled
                            - firewall enabled
                            - system updated
                            - timezone configured
                            - disk monitored
                            - logs accessible
                            - backup and rollback plan
                            - server record documented

Most Ubuntu administration starts with files: configuration files, logs, service units, application folders, SSH keys, certificates, scripts, backups and data directories.

Essential file commands

# Where am I?
                            pwd

                            # List files with permissions, owner, size and hidden files
                            ls -lah

                            # Copy a directory safely, preserving metadata
                            cp -a /etc/nginx /etc/nginx.bak

                            # Move or rename
                            mv app.conf app.conf.disabled

                            # Remove carefully
                            rm file.txt

                            # Dangerous: recursive delete
                            rm -rf path

                            # Find recent logs
                            find /var/log -type f -name "*.log" -mtime -7

                            # Find large files
                            find /var -type f -size +100M -exec ls -lh {} \;

Linux filesystem map

/
                            ├── bin      essential binaries
                            ├── boot     kernel and boot files
                            ├── dev      devices
                            ├── etc      system configuration
                            ├── home     user home directories
                            ├── lib      system libraries
                            ├── media    removable media
                            ├── mnt      temporary mounts
                            ├── opt      optional software
                            ├── proc     kernel/process virtual filesystem
                            ├── root     root user home
                            ├── run      runtime state
                            ├── sbin     system binaries
                            ├── srv      service/application data
                            ├── sys      kernel/device virtual filesystem
                            ├── tmp      temporary files
                            ├── usr      user-space programs and libraries
                            └── var      logs, cache, spool, databases, runtime data

Useful inspection commands

# Show file type
                            file /path/to/file

                            # Show file metadata
                            stat /path/to/file

                            # Read first lines
                            head -50 /var/log/syslog

                            # Read last lines
                            tail -100 /var/log/syslog

                            # Follow a log live
                            tail -f /var/log/syslog

                            # Search inside files
                            grep -R "error" /etc/nginx

                            # Compare two files
                            diff -u old.conf new.conf

Linux permissions define who can read, write or execute a file. Most application failures on Ubuntu servers eventually involve one of these: wrong owner, wrong group, missing execute bit on directory, overly permissive file, SSH key permissions or service user unable to access application files.

Permission notation

Example:
                            -rw-r--r-- 1 root root 1200 app.conf

                            Breakdown:
                            -       file type
                            rw-     owner permissions
                            r--     group permissions
                            r--     others permissions

                            r = read
                            w = write
                            x = execute / enter directory

Permission commands

# Show permissions
                            ls -lah /srv/app

                            # Show user and group identity
                            id deploy

                            # Change owner
                            sudo chown deploy:www-data /srv/app

                            # Change owner recursively
                            sudo chown -R deploy:www-data /srv/app

                            # Change file permissions
                            chmod 644 config.ini

                            # Change directory permissions
                            chmod 755 /srv/app

                            # SSH key permissions
                            chmod 700 ~/.ssh
                            chmod 600 ~/.ssh/id_ed25519
                            chmod 644 ~/.ssh/authorized_keys

                            # Show default creation mask
                            umask

Permission troubleshooting flow

Permission denied
                            │
                            ├── Which user runs the process?
                            │       └── ps aux | grep service
                            │
                            ├── Who owns the file?
                            │       └── ls -lah file
                            │
                            ├── Can the user access parent directories?
                            │       └── namei -l /path/to/file
                            │
                            ├── Is the group correct?
                            │       └── id user
                            │
                            └── Are permissions too strict or too broad?
                            └── chmod / chown carefully

Ubuntu administration should use named users with sudo privileges, not direct root logins. This improves traceability, reduces operational risk and supports least-privilege access. For production, SSH keys should be preferred over passwords.

User management examples

# Create admin user
                            sudo adduser deploy
                            sudo usermod -aG sudo deploy

                            # Check user
                            id deploy
                            groups deploy

                            # Switch user
                            su - deploy

                            # Test sudo permissions
                            sudo -l

                            # Add user to web group
                            sudo usermod -aG www-data deploy

                            # Lock user password
                            sudo passwd -l deploy

SSH access model

Admin workstation
                            │
                            ├── private key
                            └── public key
                            │
                            ▼
                            Ubuntu server
                            │
                            ├── /home/deploy/.ssh/authorized_keys
                            ├── sshd service
                            ├── firewall allows SSH
                            └── sudo controls privilege escalation

SSH hardening baseline

# Backup SSH config
                            sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

                            # Recommended settings in /etc/ssh/sshd_config
                            PermitRootLogin no
                            PasswordAuthentication no
                            PubkeyAuthentication yes
                            AllowUsers deploy

                            # Validate syntax
                            sudo sshd -t

                            # Restart SSH
                            sudo systemctl restart ssh

                            # Check logs
                            journalctl -u ssh --since today

Access control checklist

[ ] One named admin user
                            [ ] SSH key installed
                            [ ] User belongs to sudo group only if required
                            [ ] Root SSH login disabled
                            [ ] Password authentication disabled after key test
                            [ ] Unused users disabled
                            [ ] sudoers changes made with visudo
                            [ ] SSH access logs reviewed

Ubuntu uses systemd to manage services. A service can be running now, enabled at boot, failed, disabled, masked or waiting on dependencies. Most production daemons such as SSH, Nginx, PostgreSQL, Redis, Docker, Gunicorn and Celery are managed by systemd.

Essential systemd commands

# Service status
                            systemctl status nginx

                            # Start / stop / restart
                            sudo systemctl start nginx
                            sudo systemctl stop nginx
                            sudo systemctl restart nginx

                            # Enable at boot
                            sudo systemctl enable nginx

                            # Disable at boot
                            sudo systemctl disable nginx

                            # Show failed services
                            systemctl list-units --type=service --state=failed

                            # Show enabled services
                            systemctl list-unit-files --type=service --state=enabled

Service troubleshooting flow

Service is down
                            │
                            ├── Check status
                            │       └── systemctl status service
                            │
                            ├── Read service logs
                            │       └── journalctl -u service
                            │
                            ├── Validate config
                            │       └── nginx -t / sshd -t / app-specific check
                            │
                            ├── Check port binding
                            │       └── ss -lntp
                            │
                            ├── Check permissions
                            │       └── ls -lah, id service-user
                            │
                            └── Restart only after understanding error
                            └── systemctl restart service

Custom service unit example

[Unit]
                            Description=Gunicorn Django application
                            After=network.target

                            [Service]
                            User=deploy
                            Group=www-data
                            WorkingDirectory=/srv/myapp
                            Environment="DJANGO_SETTINGS_MODULE=config.settings"
                            ExecStart=/srv/myapp/venv/bin/gunicorn config.wsgi:application \
                            --bind 127.0.0.1:8000 \
                            --workers 3
                            Restart=always
                            RestartSec=5

                            [Install]
                            WantedBy=multi-user.target

Install custom unit

sudo cp gunicorn.service /etc/systemd/system/gunicorn.service
                            sudo systemctl daemon-reload
                            sudo systemctl enable gunicorn
                            sudo systemctl start gunicorn
                            systemctl status gunicorn
                            journalctl -u gunicorn -f

Logs tell what the system and services reported at the time of the incident. On Ubuntu, systemd logs are read with journalctl. Traditional logs often live under /var/log. Applications may log to journald, files, Docker logs or external observability tools.

journalctl essentials

# Recent critical context
                            journalctl -xe

                            # Logs for one service
                            journalctl -u nginx

                            # Follow service logs live
                            journalctl -u nginx -f

                            # Logs since a time
                            journalctl -u nginx --since "1 hour ago"

                            # Logs since today
                            journalctl -u ssh --since today

                            # Warnings and errors
                            journalctl -p warning --since today

                            # Boot logs
                            journalctl -b

                            # Previous boot
                            journalctl -b -1

Classic log commands

# Last lines
                            tail -n 200 /var/log/syslog
                            tail -n 200 /var/log/auth.log

                            # Follow file live
                            tail -f /var/log/syslog

                            # Search errors
                            grep -i "error" /var/log/syslog

                            # Search SSH failures
                            grep -i "failed" /var/log/auth.log

                            # Compressed rotated logs
                            zgrep -i "error" /var/log/syslog.*.gz

                            # Kernel recent messages
                            dmesg -T | tail -100

Log diagnosis map

Incident type
                            │
                            ├── Service fails
                            │       └── journalctl -u service
                            │
                            ├── SSH login issue
                            │       └── journalctl -u ssh, /var/log/auth.log
                            │
                            ├── Kernel or hardware issue
                            │       └── dmesg -T
                            │
                            ├── Package install issue
                            │       └── /var/log/apt/history.log
                            │
                            ├── Web server issue
                            │       └── nginx/apache logs + journal
                            │
                            └── App issue
                            └── app logs + service journal

Apt history

# See package changes
                            less /var/log/apt/history.log

                            # See apt terminal output
                            less /var/log/apt/term.log

Network troubleshooting should follow a strict order: local IP, route, DNS, firewall, listening socket, service health, upstream application. This avoids confusing a DNS issue with a service issue, or a firewall issue with an application crash.

Network essentials

# IP addresses
                            ip a

                            # Routes
                            ip r

                            # Listening TCP ports with process
                            ss -lntp

                            # Established connections
                            ss -antp

                            # DNS status
                            resolvectl status

                            # DNS query
                            dig example.com

                            # HTTP check
                            curl -I https://example.com

                            # Basic reachability
                            ping -c 3 1.1.1.1

                            # Path test
                            tracepath example.com

Network troubleshooting flow

Network problem
                            │
                            ├── Local IP present?
                            │       └── ip a
                            │
                            ├── Default route present?
                            │       └── ip r
                            │
                            ├── DNS working?
                            │       └── dig domain
                            │
                            ├── Firewall allows traffic?
                            │       └── ufw status verbose
                            │
                            ├── Service listening?
                            │       └── ss -lntp
                            │
                            ├── Local curl works?
                            │       └── curl -I http://localhost
                            │
                            └── Remote curl works?
                            └── curl -I https://public-domain

Firewall commands

# Status
                            sudo ufw status verbose

                            # Default rules
                            sudo ufw default deny incoming
                            sudo ufw default allow outgoing

                            # Allow SSH
                            sudo ufw allow OpenSSH

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

                            # Enable
                            sudo ufw enable

                            # Delete a rule
                            sudo ufw delete allow 80/tcp

Storage problems are among the most common Linux incidents. A full root filesystem, a full /var, a missing mount, broken permissions on a data directory or uncontrolled Docker logs can stop services even when CPU and memory look fine.

Storage essentials

# Filesystem usage
                            df -h

                            # Directory usage
                            sudo du -sh /var/*
                            sudo du -sh /var/log/*
                            sudo du -sh /var/lib/docker/*

                            # Disks and filesystems
                            lsblk
                            lsblk -f

                            # Mounted filesystems
                            findmnt

                            # Swap
                            swapon --show
                            free -h

                            # LVM if used
                            sudo pvs
                            sudo vgs
                            sudo lvs

Full disk incident flow

Disk alert or service failure
                            │
                            ├── Check filesystems
                            │       └── df -h
                            │
                            ├── Identify large directories
                            │       └── du -sh /*
                            │
                            ├── Focus common growth areas
                            │       ├── /var/log
                            │       ├── /var/lib/docker
                            │       ├── /var/lib/postgresql
                            │       ├── /tmp
                            │       └── application uploads
                            │
                            ├── Clean safely
                            │       ├── rotate logs
                            │       ├── prune Docker carefully
                            │       └── archive/delete known files
                            │
                            └── Prevent recurrence
                            ├── monitoring
                            ├── logrotate
                            ├── retention policy
                            └── larger/separate volume

Safe cleanup examples

# Clean apt cache
                            sudo apt clean

                            # Remove unused packages
                            sudo apt autoremove

                            # Vacuum journal logs older than 14 days
                            sudo journalctl --vacuum-time=14d

                            # Show Docker usage
                            docker system df

                            # Docker cleanup - use carefully
                            docker system prune

Troubleshooting on Ubuntu should follow a repeatable sequence: observe, isolate, verify, change one thing, measure again, document. Most incidents can be reduced to service state, logs, ports, permissions, network, storage, memory or recent changes.

Universal incident decision tree

Application not working
                            │
                            ├── Is the server alive?
                            │       └── ping, SSH, cloud console
                            │
                            ├── Is disk full?
                            │       └── df -h
                            │
                            ├── Is memory exhausted?
                            │       └── free -h, top
                            │
                            ├── Is the service running?
                            │       └── systemctl status service
                            │
                            ├── What do logs say?
                            │       └── journalctl -u service
                            │
                            ├── Is the port listening?
                            │       └── ss -lntp
                            │
                            ├── Is firewall blocking?
                            │       └── ufw status verbose
                            │
                            ├── Is DNS/routing OK?
                            │       └── ip r, resolvectl, dig
                            │
                            └── Did a recent change happen?
                            └── apt history, deploy logs, config diff

Useful “one screen” diagnostic

echo "== HOST ==" && hostnamectl
                            echo "== UPTIME ==" && uptime
                            echo "== DISK ==" && df -h
                            echo "== MEMORY ==" && free -h
                            echo "== FAILED UNITS ==" && systemctl --failed
                            echo "== PORTS ==" && ss -lntp
                            echo "== WARNINGS ==" && journalctl -p warning --since "30 min ago" --no-pager

Core cheat sheet

# Files
                            ls -lah
                            cp -a src dst
                            mv old new
                            rm file
                            find /path -name "*.log"
                            du -sh *
                            df -h

                            # Permissions
                            ls -l
                            chmod 644 file
                            chmod 755 dir
                            chown user:group file
                            id user
                            namei -l /path/to/file

                            # Users
                            adduser user
                            usermod -aG sudo user
                            groups user
                            sudo -l

                            # Services
                            systemctl status service
                            systemctl restart service
                            systemctl enable service
                            systemctl --failed

                            # Logs
                            journalctl -u service -f
                            journalctl -p warning --since today
                            tail -f /var/log/syslog

                            # Network
                            ip a
                            ip r
                            ss -lntp
                            curl -I http://localhost
                            dig domain
                            resolvectl status

                            # Storage
                            lsblk -f
                            findmnt
                            swapon --show
                            free -h

Production sysadmin baseline

[ ] I know the server role
                            [ ] I know the Ubuntu version
                            [ ] I know which services must run
                            [ ] I know which ports must listen
                            [ ] I know where logs are
                            [ ] I know which user runs each app
                            [ ] I know where configs are
                            [ ] I know where data is stored
                            [ ] I know backup location
                            [ ] I know firewall rules
                            [ ] I know how to restart safely
                            [ ] I know how to rollback
                            [ ] I avoid chmod 777
                            [ ] I avoid root direct login
                            [ ] I document changes

Final rule

Troubleshooting order

1. Observe symptoms
                            2. Check server health
                            3. Check disk and memory
                            4. Check service state
                            5. Read logs
                            6. Check ports
                            7. Check network and DNS
                            8. Check permissions
                            9. Check recent changes
                            10. Apply one fix
                            11. Verify
                            12. Document

APT is the standard daily tool for Ubuntu package operations. It downloads package metadata, resolves dependencies, installs software, upgrades packages and removes software cleanly.

Essential APT commands

# Refresh package metadata
                            sudo apt update

                            # Show upgradeable packages
                            apt list --upgradable

                            # Upgrade packages
                            sudo apt upgrade

                            # Install package
                            sudo apt install nginx

                            # Show package information
                            apt show nginx

                            # Show package versions and source repository
                            apt policy nginx

                            # Search package
                            apt search postgresql

                            # Remove package but keep configuration
                            sudo apt remove nginx

                            # Remove package and configuration
                            sudo apt purge nginx

                            # Remove unused dependencies
                            sudo apt autoremove

APT vs dpkg

Package inspection

# List installed packages
                            dpkg -l

                            # Filter installed packages
                            dpkg -l | grep nginx

                            # Show files installed by package
                            dpkg -L nginx

                            # Find which package owns a file
                            dpkg -S /usr/sbin/nginx

                            # Show package version
                            dpkg -s nginx | grep Version

                            # Show apt history
                            less /var/log/apt/history.log

                            # Show apt terminal logs
                            less /var/log/apt/term.log

APT installs packages from repositories. Repository governance is critical: every repository added to a production server becomes part of the trust and upgrade surface. Too many uncontrolled PPAs or vendor repositories can make upgrades unpredictable.

Repository locations

# Main APT source files
                            /etc/apt/sources.list
                            /etc/apt/sources.list.d/

                            # Newer Ubuntu systems may use deb822 source files
                            /etc/apt/sources.list.d/*.sources

                            # Trusted keyring locations
                            /etc/apt/keyrings/
                            /usr/share/keyrings/

                            # Apt preferences and pinning
                            /etc/apt/preferences
                            /etc/apt/preferences.d/

Repository inspection commands

# Show active source files
                            ls -lah /etc/apt/sources.list.d/
                            cat /etc/apt/sources.list

                            # Search configured repositories
                            grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

                            # Refresh repository metadata
                            sudo apt update

                            # Show repository used for package candidate
                            apt policy nginx

                            # Show all versions available
                            apt-cache madison nginx

                            # Show package origin details
                            apt-cache policy nginx

Vendor repository pattern

Recommended vendor repo pattern:
                            1. Add vendor signing key into /etc/apt/keyrings/
                            2. Add repository source referencing signed-by key
                            3. Run apt update
                            4. Check apt policy package
                            5. Install exact package
                            6. Document repository owner and reason
                            7. Monitor vendor release notes
                            8. Pin if required

Repository risk diagram

New repository added
                            │
                            ├── Can replace existing packages?
                            ├── Can introduce newer dependencies?
                            ├── Can break upgrade path?
                            ├── Is signing key controlled?
                            ├── Is vendor trusted?
                            ├── Is lifecycle documented?
                            └── Is rollback possible?

Ubuntu updates must balance security and stability. Security patches should be applied quickly, but critical production systems often require staging validation, maintenance windows and rollback plans. Kernel and libc-related updates may require service restart or full reboot.

Update commands

# Refresh metadata
                            sudo apt update

                            # Show upgradeable packages
                            apt list --upgradable

                            # Upgrade packages
                            sudo apt upgrade

                            # More complete dependency-aware upgrade
                            sudo apt full-upgrade

                            # Remove unused dependencies
                            sudo apt autoremove

                            # Check if reboot is required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # Show packages requiring reboot
                            cat /var/run/reboot-required.pkgs 2>/dev/null

Patch workflow

Patch workflow
                            │
                            ├── Inventory
                            │       ├── OS version
                            │       ├── kernel version
                            │       ├── critical services
                            │       └── package list
                            │
                            ├── Prepare
                            │       ├── backup
                            │       ├── snapshot
                            │       ├── staging test
                            │       └── maintenance window
                            │
                            ├── Patch
                            │       ├── apt update
                            │       ├── apt upgrade
                            │       ├── service validation
                            │       └── reboot if required
                            │
                            └── Verify
                            ├── systemctl --failed
                            ├── journalctl warnings
                            ├── listening ports
                            ├── application smoke tests
                            └── monitoring green

Unattended upgrades

# Install unattended upgrades
                            sudo apt install unattended-upgrades

                            # Configure automatic updates
                            sudo dpkg-reconfigure unattended-upgrades

                            # Main config files
                            /etc/apt/apt.conf.d/20auto-upgrades
                            /etc/apt/apt.conf.d/50unattended-upgrades

                            # Check logs
                            less /var/log/unattended-upgrades/unattended-upgrades.log

Package security is about more than installing updates. It includes repository trust, signing keys, CVE awareness, dependency origin, package version visibility, automatic security updates, rollback and auditability.

Security inspection commands

# Show installed version and candidate
                            apt policy openssl
                            apt policy nginx

                            # Show package details
                            apt show openssl

                            # Show package changelog if available
                            apt changelog openssl

                            # Review apt history
                            less /var/log/apt/history.log

                            # Show recently modified source files
                            sudo find /etc/apt -type f -mtime -30 -ls

                            # Check Ubuntu Pro status if available
                            pro status

Package security flow

Security advisory or CVE
                            │
                            ├── Identify affected package
                            │       └── apt policy package
                            │
                            ├── Check installed version
                            │       └── dpkg -s package
                            │
                            ├── Check available update
                            │       └── apt list --upgradable
                            │
                            ├── Apply patch
                            │       └── apt upgrade package
                            │
                            ├── Restart service if needed
                            │       └── systemctl restart service
                            │
                            ├── Reboot if kernel/system library
                            │       └── reboot-required
                            │
                            └── Verify
                            ├── version updated
                            ├── service healthy
                            └── logs clean

Key management principles

Good:
                            - vendor keys stored in /etc/apt/keyrings/
                            - repository line uses signed-by=
                            - repository owner documented
                            - old repositories removed
                            - package origin checked with apt policy

                            Avoid:
                            - legacy apt-key usage
                            - unknown curl | sudo bash scripts
                            - unmanaged PPAs
                            - repositories kept after one-time install
                            - blind upgrades without package review

Pinning and holds control package versions. They are useful when a service depends on a specific version, when a repository offers unwanted newer packages, or when an upgrade must be temporarily blocked. They should be documented because forgotten pins can create security and maintenance risks.

Hold commands

# Hold a package
                            sudo apt-mark hold nginx

                            # Show held packages
                            apt-mark showhold

                            # Remove hold
                            sudo apt-mark unhold nginx

                            # Install exact version
                            sudo apt install nginx=1.24.0-2ubuntu7

                            # Show available versions
                            apt-cache madison nginx
                            apt policy nginx

APT preferences example

# Example file:
                            # /etc/apt/preferences.d/nginx-pin

                            Package: nginx*
                            Pin: release o=Ubuntu
                            Pin-Priority: 700

                            Package: nginx*
                            Pin: origin "ppa.launchpadcontent.net"
                            Pin-Priority: 400

Version governance flow

Need version control?
                            │
                            ├── Is this temporary?
                            │       ├── yes -> apt-mark hold + ticket + expiry date
                            │       └── no
                            │
                            ├── Is repo priority wrong?
                            │       ├── yes -> APT preferences pinning
                            │       └── no
                            │
                            ├── Need fleet reproducibility?
                            │       ├── yes -> golden image or IaC
                            │       └── no
                            │
                            └── Document package policy
                            ├── package
                            ├── desired version
                            ├── reason
                            ├── owner
                            └── review date

Pinning risks

Snap packages bundle applications with their dependencies and run with confinement rules. Snaps are useful for some desktop applications and selected server tools, but production teams must understand refresh behavior, confinement, channels and operational policy before relying on them.

Snap essentials

# List installed snaps
                            snap list

                            # Find package
                            snap find code

                            # Install snap
                            sudo snap install package-name

                            # Install from specific channel
                            sudo snap install package-name --channel=stable

                            # Refresh snaps
                            sudo snap refresh

                            # Show refresh schedule
                            snap refresh --time

                            # Show snap information
                            snap info package-name

                            # Remove snap
                            sudo snap remove package-name

Snap operational commands

# Show connections/interfaces
                            snap connections package-name

                            # Connect interface manually
                            sudo snap connect package-name:interface

                            # Revert to previous revision if available
                            sudo snap revert package-name

                            # Hold refresh temporarily
                            sudo snap refresh --hold=24h package-name

                            # Hold all refreshes temporarily
                            sudo snap refresh --hold=24h

                            # Show changes
                            snap changes

                            # Show logs for snap service if applicable
                            snap logs package-name

APT vs Snap decision table

Package problems often come from broken dependencies, interrupted installs, repository errors, DNS issues, expired keys, dpkg locks, held packages or third-party repository conflicts. Troubleshooting should start by reading the actual APT error.

Repair commands

# Repair interrupted dpkg configuration
                            sudo dpkg --configure -a

                            # Fix broken dependencies
                            sudo apt -f install

                            # Refresh metadata
                            sudo apt update

                            # Clean local package cache
                            sudo apt clean

                            # Check held packages
                            apt-mark showhold

                            # Check locks safely
                            ps aux | grep -E 'apt|dpkg'

                            # Review apt history
                            less /var/log/apt/history.log
                            less /var/log/apt/term.log

Troubleshooting decision tree

APT operation fails
                            │
                            ├── Read exact error
                            │
                            ├── Lock error?
                            │       └── wait or inspect apt/dpkg processes
                            │
                            ├── Network or DNS error?
                            │       └── check ip, route, DNS, proxy
                            │
                            ├── Repository signature error?
                            │       └── check source file and keyring
                            │
                            ├── Dependency conflict?
                            │       └── apt -f install, apt policy, holds
                            │
                            ├── Interrupted install?
                            │       └── dpkg --configure -a
                            │
                            └── Third-party repo conflict?
                            └── disable repo, update, retry in staging

Repository isolation technique

# Temporarily disable a source file
                            sudo mv /etc/apt/sources.list.d/vendor.list \
                            /etc/apt/sources.list.d/vendor.list.disabled

                            # Refresh metadata
                            sudo apt update

                            # Re-check package candidate
                            apt policy package-name

In production, package management must be reproducible. The same server role should use the same repositories, packages, versions, configuration and patching process. Manual package drift is a major source of incidents.

Production package lifecycle

Package change request
                            │
                            ├── Why is package needed?
                            ├── Which repository provides it?
                            ├── Is vendor trusted?
                            ├── Is version pinned or floating?
                            ├── Has staging been tested?
                            ├── Is rollback possible?
                            └── Is owner documented?
                            │
                            ▼
                            Approved installation
                            │
                            ├── update IaC
                            ├── apply in staging
                            ├── validate
                            ├── apply in production
                            └── document result

Production rules

Do:
                            - use Ubuntu LTS for production
                            - keep security repository enabled
                            - document every external repository
                            - prefer vendor official repositories over random PPAs
                            - test updates in staging
                            - track reboot-required state
                            - keep rollback snapshot or image
                            - automate package baseline
                            - review apt history after changes
                            - monitor security advisories

                            Avoid:
                            - unmanaged PPAs
                            - curl | sudo bash without review
                            - compiling manually into /usr/local without documentation
                            - mixing APT and Snap for the same service role
                            - holding packages forever
                            - patching critical systems without rollback

Infrastructure-as-code examples

Package baseline can be expressed in:
                            - Ansible apt module
                            - cloud-init packages section
                            - Packer image build
                            - Terraform user_data
                            - Dockerfile for containers
                            - shell bootstrap script under version control

                            Goal:
                            rebuild server from code, not memory.

APT cheat sheet

# Metadata and updates
                            sudo apt update
                            apt list --upgradable
                            sudo apt upgrade
                            sudo apt full-upgrade

                            # Install and remove
                            sudo apt install package-name
                            sudo apt remove package-name
                            sudo apt purge package-name
                            sudo apt autoremove

                            # Inspect
                            apt show package-name
                            apt policy package-name
                            apt-cache madison package-name
                            dpkg -l | grep package-name
                            dpkg -L package-name
                            dpkg -S /path/to/file

                            # Troubleshoot
                            sudo dpkg --configure -a
                            sudo apt -f install
                            apt-mark showhold
                            less /var/log/apt/history.log

                            # Hold
                            sudo apt-mark hold package-name
                            sudo apt-mark unhold package-name

Snap cheat sheet

# Inspect
                            snap list
                            snap find package-name
                            snap info package-name

                            # Install and remove
                            sudo snap install package-name
                            sudo snap install package-name --channel=stable
                            sudo snap remove package-name

                            # Refresh
                            sudo snap refresh
                            snap refresh --time
                            sudo snap refresh --hold=24h package-name

                            # Operations
                            snap changes
                            snap connections package-name
                            snap logs package-name
                            sudo snap revert package-name

Final production checklist

[ ] Ubuntu official repositories are enabled
                            [ ] Security repository is enabled
                            [ ] External repositories are documented
                            [ ] Repository keys are managed in keyrings
                            [ ] PPAs are justified or avoided
                            [ ] Package baseline is automated
                            [ ] Critical package versions are known
                            [ ] Holds and pins are documented
                            [ ] Update policy is defined
                            [ ] Reboot policy is defined
                            [ ] Staging update test exists
                            [ ] Rollback image or snapshot exists
                            [ ] Apt history is reviewed after changes
                            [ ] Snap policy is defined
                            [ ] Security advisories are monitored

Final rule

Ubuntu Desktop uses GNOME with Ubuntu-specific defaults. Before installing extensions or themes, start with built-in settings: dock placement, appearance, workspaces, display scaling, night light, keyboard layout, privacy, notifications and power profile.

GNOME Tweaks installation

# Install GNOME Tweaks
                            sudo apt update
                            sudo apt install gnome-tweaks

                            # Launch from terminal
                            gnome-tweaks

                            # Install extension app if available
                            sudo apt install gnome-shell-extension-manager

Interface customization flow

Customize desktop
                            │
                            ├── Built-in Settings
                            │       ├── appearance
                            │       ├── display
                            │       ├── keyboard
                            │       ├── power
                            │       └── privacy
                            │
                            ├── GNOME Tweaks
                            │       ├── fonts
                            │       ├── window behavior
                            │       ├── startup apps
                            │       └── themes if enabled
                            │
                            ├── Extensions
                            │       ├── install only useful ones
                            │       ├── verify compatibility
                            │       └── disable if shell breaks
                            │
                            └── Backup preferences
                            ├── document installed extensions
                            ├── export dotfiles if needed
                            └── keep restore point

Useful inspection commands

# GNOME Shell version
                            gnome-shell --version

                            # Current desktop session
                            echo $XDG_CURRENT_DESKTOP
                            echo $XDG_SESSION_TYPE

                            # Display environment
                            echo $WAYLAND_DISPLAY
                            echo $DISPLAY

                            # Installed GNOME packages
                            dpkg -l | grep -i gnome | head

                            # User configuration directories
                            ls -lah ~/.config
                            ls -lah ~/.local/share

GNOME extensions modify the behavior of GNOME Shell. They can add indicators, tiling, dock improvements, clipboard managers, system monitors or workflow enhancements. However, extensions run inside the desktop shell environment and can break after GNOME upgrades if not maintained.

Install and manage extensions

# Install Extension Manager if available
                            sudo apt update
                            sudo apt install gnome-shell-extension-manager

                            # List enabled extensions
                            gnome-extensions list --enabled

                            # List all extensions
                            gnome-extensions list

                            # Show extension info
                            gnome-extensions info extension-name

                            # Disable extension
                            gnome-extensions disable extension-name

                            # Enable extension
                            gnome-extensions enable extension-name

Extension safety flow

Before installing extension
                            │
                            ├── Is it really needed?
                            ├── Is it compatible with GNOME version?
                            ├── Is it maintained?
                            ├── Does it overlap with another extension?
                            ├── Can it be disabled easily?
                            └── Is there a restore point before major desktop changes?

Extension troubleshooting

# Disable all extensions for diagnostic
                            gnome-extensions disable extension-name

                            # Check GNOME Shell logs
                            journalctl /usr/bin/gnome-shell --since "1 hour ago"

                            # Check session errors
                            journalctl --user -p warning --since "1 hour ago"

                            # Restart GNOME Shell on Xorg
                            # Press Alt+F2, type r, press Enter

                            # On Wayland, log out and log back in

Recommended extension policy

Good:
                            - install only a few extensions
                            - prefer maintained extensions
                            - remove unused extensions
                            - document core workflow extensions
                            - test after Ubuntu upgrade

                            Avoid:
                            - stacking many visual extensions
                            - installing abandoned extensions
                            - relying on extensions for critical access
                            - changing many extensions at once
                            - ignoring shell errors after login

Ubuntu visual customization can use GTK themes, icon themes, cursor themes and fonts. Themes can improve comfort and readability, but deep theming may break after application or desktop updates, especially when applications use different toolkit versions.

Theme directories

# User theme directories
                            mkdir -p ~/.themes
                            mkdir -p ~/.icons
                            mkdir -p ~/.local/share/icons

                            # System theme directories
                            ls -lah /usr/share/themes
                            ls -lah /usr/share/icons

                            # User config
                            ls -lah ~/.config
                            ls -lah ~/.local/share

Theme installation flow

Install theme safely
                            │
                            ├── Download from trusted source
                            ├── Extract theme
                            ├── Place in user directory
                            │       ├── ~/.themes
                            │       └── ~/.icons
                            ├── Open GNOME Tweaks
                            ├── Select theme
                            ├── Verify apps look correct
                            └── Keep original theme as fallback

Visual customization checklist

[ ] Theme source is trusted
                            [ ] Theme supports current GNOME/GTK version
                            [ ] Original theme remains available
                            [ ] Icons are readable in light and dark mode
                            [ ] Terminal colors remain readable
                            [ ] File manager remains usable
                            [ ] Browser and developer tools remain clear
                            [ ] Screenshots and presentations look professional
                            [ ] Theme can be reverted quickly

Common theme problems

Keyboard shortcuts are one of the highest-return customizations. They reduce mouse use, speed up window management, launch tools quickly and make development workflows smoother. The best shortcuts are easy to remember and do not conflict with application shortcuts.

Custom shortcut flow

Create custom shortcut
                            │
                            ├── Open Settings
                            ├── Go to Keyboard
                            ├── Open Keyboard Shortcuts
                            ├── Add Custom Shortcut
                            ├── Enter name
                            ├── Enter command
                            ├── Assign key combination
                            └── Test immediately

Useful custom commands

# Open terminal
                            gnome-terminal

                            # Open file manager
                            nautilus

                            # Open browser
                            firefox

                            # Open specific project directory
                            gnome-terminal --working-directory=/home/user/projects

                            # Run a custom script
                            /home/user/bin/daily-check.sh

                            # Lock screen
                            gnome-screensaver-command -l

Shortcut design principles

Good shortcuts:
                            - easy to remember
                            - close to existing habits
                            - not conflicting with IDE/browser
                            - consistent by category
                            - documented if custom
                            - limited to high-frequency actions

                            Avoid:
                            - too many shortcuts
                            - hard-to-type combinations
                            - overriding critical app shortcuts
                            - shortcuts that run destructive scripts
                            - undocumented production scripts

Developer workflow example

Workflow:
                            Super + Enter       -> terminal
                            Super + E           -> file manager
                            Super + B           -> browser
                            Super + D           -> IDE
                            Super + Shift + L   -> lock screen
                            Super + Shift + M   -> monitoring dashboard
                            Super + Shift + T   -> project terminal

Battery optimization on Ubuntu starts with power profiles, screen brightness, sleep behavior, background applications and hardware drivers. More advanced users can use tools like TLP or powertop, but should avoid applying random power tweaks without verifying their effect.

Power commands

# Show power profiles if supported
                            powerprofilesctl

                            # Set power saver
                            powerprofilesctl set power-saver

                            # Set balanced
                            powerprofilesctl set balanced

                            # Set performance if available
                            powerprofilesctl set performance

                            # Battery status
                            upower -i $(upower -e | grep BAT) 2>/dev/null

                            # Show running processes
                            top

                            # Show startup applications through GUI
                            gnome-session-properties

TLP and powertop

# Install TLP
                            sudo apt update
                            sudo apt install tlp

                            # Enable TLP
                            sudo systemctl enable --now tlp

                            # Show TLP status
                            sudo tlp-stat -s

                            # Install powertop
                            sudo apt install powertop

                            # Run powertop
                            sudo powertop

Battery optimization flow

Battery drains quickly
                            │
                            ├── Check power profile
                            ├── Reduce screen brightness
                            ├── Close high CPU apps
                            ├── Disable unused Bluetooth
                            ├── Review startup apps
                            ├── Check browser tabs
                            ├── Check GPU mode
                            ├── Use TLP if needed
                            └── Measure again

Laptop routine

On battery:
                            [ ] power-saver profile
                            [ ] lower brightness
                            [ ] close heavy browser tabs
                            [ ] stop unused containers or VMs
                            [ ] disable Bluetooth if unused
                            [ ] avoid heavy indexing jobs
                            [ ] monitor CPU usage
                            [ ] suspend when idle

Swappiness controls how aggressively the Linux kernel tends to move memory pages to swap. Lower values generally reduce swap tendency; higher values allow more swapping. It is not a magic performance setting. The correct value depends on RAM size, workload, disk speed and latency tolerance.

Inspect memory and swappiness

# Current swappiness
                            cat /proc/sys/vm/swappiness
                            sysctl vm.swappiness

                            # Memory overview
                            free -h

                            # Swap devices/files
                            swapon --show

                            # Swap activity
                            vmstat 1

                            # Top memory processes
                            ps aux --sort=-%mem | head -30

Temporary and persistent swappiness

# Temporary change until reboot
                            sudo sysctl -w vm.swappiness=10

                            # Persistent configuration
                            sudo vim /etc/sysctl.d/99-custom-swappiness.conf

                            # Example content
                            vm.swappiness = 10

                            # Apply persistent sysctl files
                            sudo sysctl --system

                            # Verify
                            sysctl vm.swappiness

Swappiness decision tree

Considering swappiness change?
                            │
                            ├── Is there real swap activity?
                            │       ├── no -> do not tune yet
                            │       └── yes
                            │
                            ├── Is system slow because of swapping?
                            │       ├── no -> investigate app first
                            │       └── yes
                            │
                            ├── Is RAM insufficient?
                            │       ├── yes -> reduce workload or add RAM
                            │       └── no
                            │
                            └── Test lower value
                            ├── apply temporarily
                            ├── measure behavior
                            ├── document result
                            └── make persistent only if useful

Memory interpretation

Cleanup keeps Ubuntu healthy, but careless cleanup can delete useful data. Focus on safe areas first: APT cache, unused packages, journal size, trash, thumbnails, old downloads and application caches. Be very careful with database directories, Docker volumes and project folders.

Safe cleanup commands

# Check disk usage first
                            df -h

                            # Show top-level directory sizes
                            sudo du -xhd1 / 2>/dev/null | sort -h

                            # Clean APT cache
                            sudo apt clean

                            # Remove unused packages
                            sudo apt autoremove

                            # Show journal size
                            journalctl --disk-usage

                            # Vacuum journal by time
                            sudo journalctl --vacuum-time=14d

                            # Vacuum journal by size
                            sudo journalctl --vacuum-size=1G

User cache cleanup

# Check user cache size
                            du -sh ~/.cache 2>/dev/null

                            # Check thumbnails
                            du -sh ~/.cache/thumbnails 2>/dev/null

                            # Remove thumbnail cache
                            rm -rf ~/.cache/thumbnails/*

                            # Review downloads manually
                            du -sh ~/Downloads/*
                            ls -lah ~/Downloads

Docker cleanup caution

# Show Docker disk usage
                            docker system df

                            # Remove unused images only
                            docker image prune

                            # Remove stopped containers
                            docker container prune

                            # More aggressive cleanup, use carefully
                            docker system prune

                            # Dangerous for persistent data if volumes included
                            docker system prune --volumes

Cleanup decision tree

Need disk space?
                            │
                            ├── Check filesystem
                            │       └── df -h
                            │
                            ├── Find large directories
                            │       └── du -xhd1 /
                            │
                            ├── Safe cleanup first
                            │       ├── apt clean
                            │       ├── apt autoremove
                            │       ├── journal vacuum
                            │       └── trash/downloads review
                            │
                            ├── App-specific cleanup
                            │       ├── browser cache
                            │       ├── Docker images
                            │       └── old build artifacts
                            │
                            └── Dangerous data zones
                            ├── databases
                            ├── Docker volumes
                            ├── project data
                            └── backups

Customization problems usually appear after installing extensions, changing themes, modifying startup apps, changing power tools, altering sysctl settings or cleaning too aggressively. The fastest recovery is to isolate the last change and revert it.

Diagnostic commands

# GNOME version and session
                            gnome-shell --version
                            echo $XDG_SESSION_TYPE

                            # Enabled extensions
                            gnome-extensions list --enabled

                            # User session warnings
                            journalctl --user -p warning --since "1 hour ago"

                            # GNOME Shell logs
                            journalctl /usr/bin/gnome-shell --since "1 hour ago"

                            # Resource usage
                            top
                            free -h
                            df -h

                            # Swappiness
                            sysctl vm.swappiness

Rollback flow

Customization issue
                            │
                            ├── What changed last?
                            │       ├── extension
                            │       ├── theme
                            │       ├── shortcut
                            │       ├── startup app
                            │       ├── power tool
                            │       └── sysctl value
                            │
                            ├── Disable or revert one change
                            ├── Log out and log back in if needed
                            ├── Check user journal
                            ├── Verify desktop stability
                            └── Document stable configuration

Safe mode mindset

If desktop is unstable:
                            1. Switch to terminal if possible
                            2. Disable recent extensions
                            3. Return to default theme
                            4. Remove recent startup app
                            5. Reboot or log out
                            6. Restore Timeshift snapshot if needed

Useful reset targets

# Disable one extension
                            gnome-extensions disable extension-name

                            # List user autostart entries
                            ls -lah ~/.config/autostart

                            # Move suspicious autostart entry away
                            mkdir -p ~/.config/autostart.disabled
                            mv ~/.config/autostart/app.desktop ~/.config/autostart.disabled/

                            # Revert sysctl custom file
                            sudo mv /etc/sysctl.d/99-custom-swappiness.conf /tmp/
                            sudo sysctl --system

Customization checklist

[ ] Built-in Settings used before extensions
                            [ ] GNOME Tweaks installed if needed
                            [ ] Extension list is short and useful
                            [ ] Extensions are compatible with GNOME version
                            [ ] Unused extensions removed
                            [ ] Theme source is trusted
                            [ ] Default theme remains available
                            [ ] Icons remain readable
                            [ ] Terminal colors remain readable
                            [ ] Keyboard shortcuts are documented
                            [ ] No shortcut runs destructive command
                            [ ] Startup applications are reviewed
                            [ ] Restore point exists before major desktop changes

Optimization checklist

[ ] Power profile configured
                            [ ] Battery behavior reviewed
                            [ ] Heavy startup apps disabled
                            [ ] Disk usage checked
                            [ ] APT cache cleaned when needed
                            [ ] Journal size controlled
                            [ ] User caches reviewed
                            [ ] Docker usage reviewed if installed
                            [ ] Swappiness observed before tuning
                            [ ] sysctl changes documented
                            [ ] Performance measured before and after changes
                            [ ] Cleanup avoids databases and important volumes

Command cheat sheet

# GNOME and extensions
                            gnome-shell --version
                            gnome-extensions list
                            gnome-extensions list --enabled
                            gnome-extensions disable extension-name
                            sudo apt install gnome-tweaks
                            sudo apt install gnome-shell-extension-manager

                            # Power
                            powerprofilesctl
                            powerprofilesctl set power-saver
                            powerprofilesctl set balanced
                            sudo apt install tlp
                            sudo systemctl enable --now tlp
                            sudo tlp-stat -s

                            # Memory and swappiness
                            free -h
                            swapon --show
                            vmstat 1
                            sysctl vm.swappiness
                            sudo sysctl -w vm.swappiness=10

                            # Cleanup
                            df -h
                            sudo du -xhd1 / 2>/dev/null | sort -h
                            sudo apt clean
                            sudo apt autoremove
                            journalctl --disk-usage
                            sudo journalctl --vacuum-time=14d

Final rule

Minimal safe profile

Minimum safe customization profile:
                            - default theme fallback
                            - small extension set
                            - documented shortcuts
                            - reviewed startup apps
                            - power profile selected
                            - disk cleanup routine
                            - no blind sysctl tuning
                            - no dangerous cleanup
                            - restore point before major changes
                            - stable desktop after logout/reboot test

SSH is usually the main administration door. On a public server, weak SSH configuration is one of the first risks to address. The safe baseline is key-based login, no direct root login, no password authentication when keys are validated, and limited users.

Generate and install key

# On admin workstation
                            ssh-keygen -t ed25519 -C "admin-server-access"

                            # Copy public key to server
                            ssh-copy-id deploy@server.example.com

                            # Test key login before changing server policy
                            ssh deploy@server.example.com

Safe SSH hardening flow

Open current SSH session
                            │
                            ├── Create deploy user
                            ├── Add SSH key
                            ├── Test second SSH session
                            ├── Backup sshd_config
                            ├── Apply hardening
                            ├── Validate syntax
                            ├── Restart SSH
                            ├── Test third SSH session
                            └── Close old session only after success

Server-side SSH configuration

# Create backup
                            sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d-%H%M%S)

                            # Edit configuration
                            sudo vim /etc/ssh/sshd_config

                            # Recommended baseline
                            PermitRootLogin no
                            PasswordAuthentication no
                            PubkeyAuthentication yes
                            X11Forwarding no
                            MaxAuthTries 3
                            AllowUsers deploy

                            # Validate syntax before restart
                            sudo sshd -t

                            # Restart SSH
                            sudo systemctl restart ssh

                            # Check service and logs
                            systemctl status ssh
                            journalctl -u ssh --since "15 min ago"

SSH diagnostic commands

# Service status
                            systemctl status ssh

                            # Listening port
                            ss -lntp | grep ssh

                            # Authentication logs
                            journalctl -u ssh --since today
                            sudo tail -100 /var/log/auth.log

                            # Current sessions
                            who
                            w

                            # Show user key file permissions
                            ls -lah ~/.ssh
                            ls -lah ~/.ssh/authorized_keys

UFW is a simple firewall frontend commonly used on Ubuntu. The baseline is to deny incoming traffic by default, allow outgoing traffic, then open only the required service ports. On cloud servers, UFW complements cloud security groups; it does not replace them.

Safe UFW baseline

# Show current status
                            sudo ufw status verbose

                            # Default policy
                            sudo ufw default deny incoming
                            sudo ufw default allow outgoing

                            # Allow SSH before enabling firewall
                            sudo ufw allow OpenSSH

                            # Web server ports if needed
                            sudo ufw allow 80/tcp
                            sudo ufw allow 443/tcp

                            # Enable firewall
                            sudo ufw enable

                            # Verify
                            sudo ufw status verbose
                            sudo ufw status numbered

Firewall decision diagram

New service installed
                            │
                            ├── Does it need network access?
                            │       ├── no  -> keep local only
                            │       └── yes
                            │
                            ├── Is it public-facing?
                            │       ├── yes -> allow only required public port
                            │       └── no
                            │
                            ├── Is it internal only?
                            │       ├── yes -> restrict to private CIDR or source IP
                            │       └── no
                            │
                            └── Is exposure documented?
                            ├── yes -> add rule
                            └── no  -> do not expose

Restrict access by source

# Allow SSH only from one admin IP
                            sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

                            # Allow PostgreSQL only from app server
                            sudo ufw allow from 10.0.1.25 to any port 5432 proto tcp

                            # Delete rule by number
                            sudo ufw status numbered
                            sudo ufw delete 3

                            # Deny a specific IP
                            sudo ufw deny from 198.51.100.55

UFW diagnostics

# UFW status
                            sudo ufw status verbose

                            # Listening ports
                            ss -lntp

                            # Check service locally
                            curl -I http://localhost

                            # Check logs if logging enabled
                            sudo ufw logging on
                            sudo journalctl -k --since "30 min ago" | grep UFW

Least privilege means each human and service gets only the permissions needed to do its job. Avoid shared admin accounts, avoid running applications as root, and keep secrets readable only by the users that need them.

User and group commands

# Create admin user
                            sudo adduser deploy
                            sudo usermod -aG sudo deploy

                            # Create service user without login shell
                            sudo adduser --system --group --home /srv/myapp myapp

                            # Show user identity
                            id deploy
                            groups deploy

                            # Show sudo permissions
                            sudo -l

                            # Edit sudoers safely
                            sudo visudo

                            # Add sudoers file safely
                            sudo visudo -f /etc/sudoers.d/deploy

Least privilege model

Human admin
                            │
                            ├── SSH key login
                            ├── sudo for admin actions
                            └── no direct root login

                            Application service
                            │
                            ├── dedicated user
                            ├── limited filesystem access
                            ├── systemd service unit
                            └── no shell login if not needed

                            Secrets
                            │
                            ├── owned by service user or root
                            ├── mode 600 or 640
                            ├── not world-readable
                            └── not committed to git

Secret and file permissions

# Private key
                            chmod 600 /home/deploy/.ssh/id_ed25519

                            # SSH directory
                            chmod 700 /home/deploy/.ssh

                            # Application env file
                            sudo chown root:myapp /srv/myapp/.env
                            sudo chmod 640 /srv/myapp/.env

                            # Application directory
                            sudo chown -R myapp:www-data /srv/myapp
                            sudo chmod -R u=rwX,g=rX,o= /srv/myapp

Account review commands

# List users
                            cut -d: -f1 /etc/passwd

                            # Show users with shell access
                            grep -E "/bin/bash|/bin/sh|/usr/bin/zsh" /etc/passwd

                            # Show sudo group members
                            getent group sudo

                            # Show recent sudo usage
                            sudo grep sudo /var/log/auth.log | tail -100

Security updates close known vulnerabilities. On Ubuntu, patching must include package updates, service restarts, kernel reboots when required, and validation after patching. Production teams should define standard patch windows and emergency patch paths.

Patch commands

# Refresh metadata
                            sudo apt update

                            # Show upgradeable packages
                            apt list --upgradable

                            # Apply upgrades
                            sudo apt upgrade

                            # Full upgrade with dependency changes
                            sudo apt full-upgrade

                            # Remove obsolete packages
                            sudo apt autoremove

                            # Check reboot requirement
                            test -f /var/run/reboot-required && cat /var/run/reboot-required
                            cat /var/run/reboot-required.pkgs 2>/dev/null

Patch workflow diagram

Security update required
                            │
                            ├── Identify affected packages
                            ├── Check staging compatibility
                            ├── Snapshot or backup
                            ├── Apply apt updates
                            ├── Restart affected services
                            ├── Reboot if required
                            ├── Validate application
                            ├── Check logs
                            └── Document package changes

Unattended upgrades

# Install unattended upgrades
                            sudo apt install unattended-upgrades

                            # Enable basic automatic security updates
                            sudo dpkg-reconfigure unattended-upgrades

                            # Config files
                            /etc/apt/apt.conf.d/20auto-upgrades
                            /etc/apt/apt.conf.d/50unattended-upgrades

                            # Logs
                            sudo less /var/log/unattended-upgrades/unattended-upgrades.log

Post-patch validation

# Failed services
                            systemctl --failed

                            # Warnings since patch
                            journalctl -p warning --since "30 min ago"

                            # Listening ports
                            ss -lntp

                            # Application smoke test
                            curl -I https://example.com

                            # Confirm kernel after reboot
                            uname -a

fail2ban watches logs and temporarily bans IP addresses that match suspicious patterns, such as repeated SSH authentication failures. It is not a replacement for key-based SSH and firewall rules, but it is useful as an extra layer against brute-force noise.

Install and baseline

# Install
                            sudo apt update
                            sudo apt install fail2ban

                            # Create local jail config
                            sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

                            # Edit local config
                            sudo vim /etc/fail2ban/jail.local

                            # Restart and enable
                            sudo systemctl enable fail2ban
                            sudo systemctl restart fail2ban

                            # Check status
                            sudo systemctl status fail2ban

Example SSH jail

[sshd]
                            enabled = true
                            port = ssh
                            filter = sshd
                            logpath = %(sshd_log)s
                            maxretry = 5
                            findtime = 10m
                            bantime = 1h

fail2ban operations

# Overall status
                            sudo fail2ban-client status

                            # Jail status
                            sudo fail2ban-client status sshd

                            # Ban an IP manually
                            sudo fail2ban-client set sshd banip 198.51.100.10

                            # Unban an IP
                            sudo fail2ban-client set sshd unbanip 198.51.100.10

                            # Logs
                            sudo journalctl -u fail2ban --since today
                            sudo tail -100 /var/log/fail2ban.log

Layered protection

SSH security layers
                            │
                            ├── SSH keys
                            ├── no root login
                            ├── no password auth
                            ├── AllowUsers
                            ├── UFW source restriction
                            ├── fail2ban
                            └── bastion or VPN for stricter environments

Hardening without visibility is incomplete. You need to know who logged in, who used sudo, which services failed, what ports are listening, which packages changed, and whether suspicious authentication events occurred.

Security log commands

# SSH logs
                            journalctl -u ssh --since today

                            # Authentication logs
                            sudo tail -200 /var/log/auth.log

                            # Failed SSH attempts
                            sudo grep -i "failed password" /var/log/auth.log | tail -100

                            # Sudo usage
                            sudo grep -i "sudo" /var/log/auth.log | tail -100

                            # Recent logins
                            last -a | head -30

                            # Current sessions
                            who
                            w

Audit architecture

Ubuntu host
                            │
                            ├── journald
                            ├── auth.log
                            ├── apt history
                            ├── service logs
                            ├── firewall logs
                            ├── fail2ban logs
                            └── application logs
                            │
                            ▼
                            Central logging
                            │
                            ├── CloudWatch
                            ├── ELK / OpenSearch
                            ├── Loki
                            ├── SIEM
                            └── long-term archive

auditd baseline

# Install audit daemon
                            sudo apt install auditd audispd-plugins

                            # Enable service
                            sudo systemctl enable auditd
                            sudo systemctl start auditd

                            # Status
                            sudo systemctl status auditd

                            # Search audit logs
                            sudo ausearch -m USER_LOGIN
                            sudo ausearch -m USER_CMD
                            sudo aureport --summary

Security review snapshot

echo "== USERS WITH SHELL =="
                            grep -E "/bin/bash|/bin/sh|/usr/bin/zsh" /etc/passwd

                            echo "== SUDO GROUP =="
                            getent group sudo

                            echo "== OPEN PORTS =="
                            ss -lntp

                            echo "== FAILED UNITS =="
                            systemctl --failed

                            echo "== RECENT SSH LOGS =="
                            journalctl -u ssh --since "24 hours ago" --no-pager

On cloud servers, Ubuntu security is shared between the operating system and the cloud perimeter. A safe design uses security groups, private subnets, IAM roles, metadata protection, snapshots, central logs and restricted administration paths.

Cloud exposure model

Public Internet
                            │
                            ├── HTTPS only
                            ▼
                            Load balancer / WAF
                            │
                            ├── forwards to app subnet
                            ▼
                            Application server
                            │
                            ├── UFW allows LB source only
                            ├── SSH allowed from bastion only
                            └── app talks to DB privately
                            │
                            ▼
                            Database server
                            ├── no public IP
                            ├── private subnet
                            └── port allowed only from app server

Cloud hardening checklist

[ ] Only required public ports are open
                            [ ] SSH is restricted by source IP or bastion
                            [ ] Database has no public exposure
                            [ ] Redis has no public exposure
                            [ ] Security groups are documented
                            [ ] UFW rules match cloud security model
                            [ ] IAM role uses least privilege
                            [ ] No static cloud keys in home directories
                            [ ] Instance metadata policy is reviewed
                            [ ] Snapshots are scheduled
                            [ ] Restore has been tested
                            [ ] Logs are shipped centrally
                            [ ] Monitoring alerts are configured

Cloud diagnostic commands

# Local listening ports
                            ss -lntp

                            # Local firewall
                            sudo ufw status verbose

                            # Instance view of routes and IPs
                            ip a
                            ip r

                            # Check outbound cloud metadata access if policy allows it
                            curl -s --max-time 2 http://169.254.169.254/ || true

                            # Check public service from server
                            curl -I http://localhost

                            # Check logs
                            journalctl -p warning --since "30 min ago"

Security incidents must be handled carefully. The first objective is to preserve evidence and stop further damage. Avoid making random changes before collecting logs, current sessions, open ports and process state.

First response commands

# Current users and sessions
                            who
                            w
                            last -a | head -50

                            # Listening ports and processes
                            ss -lntp
                            ps aux --sort=-%cpu | head -30

                            # Failed services
                            systemctl --failed

                            # Recent auth activity
                            sudo tail -300 /var/log/auth.log

                            # SSH logs
                            journalctl -u ssh --since "24 hours ago"

                            # Recent package changes
                            less /var/log/apt/history.log

Incident response flow

Security alert
                            │
                            ├── Preserve evidence
                            │       ├── logs
                            │       ├── sessions
                            │       ├── ports
                            │       └── process list
                            │
                            ├── Determine scope
                            │       ├── one account
                            │       ├── one service
                            │       ├── one host
                            │       └── multiple systems
                            │
                            ├── Contain
                            │       ├── firewall rule
                            │       ├── disable account
                            │       ├── stop service
                            │       └── isolate instance
                            │
                            ├── Eradicate
                            │       ├── patch
                            │       ├── remove access
                            │       ├── rotate secrets
                            │       └── rebuild if needed
                            │
                            └── Recover
                            ├── restore service
                            ├── validate logs
                            ├── monitor closely
                            └── write postmortem

Credential rotation checklist

[ ] SSH keys reviewed
                            [ ] Unknown keys removed
                            [ ] Sudo users reviewed
                            [ ] Application secrets rotated
                            [ ] Database passwords rotated
                            [ ] Cloud API keys revoked or rotated
                            [ ] CI/CD tokens rotated
                            [ ] Webhook secrets rotated
                            [ ] TLS private key checked
                            [ ] Backup access reviewed

Ubuntu security baseline checklist

[ ] Ubuntu LTS is used
                            [ ] Packages are updated
                            [ ] Reboot-required state is checked
                            [ ] Named admin user exists
                            [ ] Root SSH login is disabled
                            [ ] SSH key login is validated
                            [ ] Password SSH login is disabled
                            [ ] UFW default deny incoming is enabled
                            [ ] Only required ports are open
                            [ ] Database ports are private only
                            [ ] Redis ports are private only
                            [ ] fail2ban is installed if public SSH exists
                            [ ] Sudo group is reviewed
                            [ ] Service users are non-root
                            [ ] Secrets are not world-readable
                            [ ] Logs are reviewed and centralized if possible
                            [ ] Backups or snapshots exist
                            [ ] Restore has been tested
                            [ ] Cloud security groups are minimal
                            [ ] Incident response procedure exists

Quick security snapshot

echo "== OS =="
                            lsb_release -a

                            echo "== REBOOT REQUIRED =="
                            test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "no reboot flag"

                            echo "== UFW =="
                            sudo ufw status verbose

                            echo "== OPEN PORTS =="
                            ss -lntp

                            echo "== SUDO USERS =="
                            getent group sudo

                            echo "== SSH LOGS =="
                            journalctl -u ssh --since "24 hours ago" --no-pager | tail -100

Command cheat sheet

# SSH
                            sudo sshd -t
                            sudo systemctl restart ssh
                            journalctl -u ssh --since today

                            # Firewall
                            sudo ufw status verbose
                            sudo ufw allow OpenSSH
                            sudo ufw allow 443/tcp
                            sudo ufw enable

                            # Users
                            id deploy
                            getent group sudo
                            sudo visudo
                            sudo passwd -l username

                            # Updates
                            sudo apt update
                            apt list --upgradable
                            sudo apt upgrade
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # fail2ban
                            sudo fail2ban-client status
                            sudo fail2ban-client status sshd

                            # Logs
                            sudo tail -100 /var/log/auth.log
                            journalctl -p warning --since today
                            systemctl --failed

Final rule

Minimal secure server profile

Minimum secure Ubuntu server:
                            - Ubuntu LTS
                            - SSH key access only
                            - no root SSH login
                            - UFW enabled
                            - only required ports open
                            - security updates applied
                            - non-root service users
                            - secrets protected
                            - logs available
                            - backups tested
                            - cloud perimeter restricted

CPU performance issues usually appear as high load average, high user CPU, high system CPU, excessive context switching or too many runnable processes. On web servers, wrong worker counts can create CPU contention or memory pressure.

CPU commands

# Load average and uptime
                            uptime

                            # Interactive CPU/process view
                            top
                            htop

                            # Per-CPU statistics
                            mpstat -P ALL 1

                            # Per-process CPU every second
                            pidstat -u 1

                            # Process tree
                            ps aux --sort=-%cpu | head -30

                            # Threads of a process
                            ps -L -p PID -o pid,tid,pcpu,pmem,comm

CPU diagnosis flow

High CPU or high load
                            │
                            ├── Is load higher than CPU core count?
                            │       └── uptime, nproc
                            │
                            ├── Is CPU user, system, iowait or steal?
                            │       └── top, mpstat
                            │
                            ├── Which process dominates?
                            │       └── ps aux --sort=-%cpu
                            │
                            ├── Is it app code, DB, web server, backup, cron?
                            │       └── systemctl, logs, cron
                            │
                            ├── Did traffic increase?
                            │       └── nginx logs, app metrics
                            │
                            └── Did a deployment or package update happen?
                            └── deploy logs, apt history

Worker sizing examples

Gunicorn starting point:
                            workers = (2 * CPU cores) + 1

                            Example:
                            2 vCPU -> 5 workers
                            4 vCPU -> 9 workers

                            But verify with:
                            - memory per worker
                            - request latency
                            - DB connection limit
                            - CPU saturation
                            - queue time
                            - error rate

                            Celery:
                            - CPU-bound tasks: concurrency near CPU cores
                            - IO-bound tasks: higher concurrency can help
                            - DB-heavy tasks: limit by database capacity

Linux uses free memory for cache, so “used memory” is not automatically a problem. The important indicators are available memory, swap activity, OOM kills, growing process RSS, and whether memory pressure correlates with latency or crashes.

Memory commands

# Memory overview
                            free -h

                            # Swap
                            swapon --show

                            # VM activity
                            vmstat 1

                            # Top memory processes
                            ps aux --sort=-%mem | head -30

                            # Kernel OOM events
                            journalctl -k --since today | grep -i -E "oom|killed process"

                            # Memory per service process
                            systemctl status myservice
                            ps -o pid,rss,vsz,cmd -C gunicorn

Memory diagnosis flow

Service slow or killed
                            │
                            ├── Is available memory low?
                            │       └── free -h
                            │
                            ├── Is swap active?
                            │       └── swapon --show, vmstat 1
                            │
                            ├── Any OOM kills?
                            │       └── journalctl -k | grep -i oom
                            │
                            ├── Which process uses memory?
                            │       └── ps aux --sort=-%mem
                            │
                            ├── Did memory grow after deploy?
                            │       └── compare metrics before/after
                            │
                            └── Can service be limited?
                            └── systemd MemoryMax, worker count, app config

systemd memory limit example

# /etc/systemd/system/myapp.service.d/limits.conf
                            [Service]
                            MemoryMax=1G
                            MemoryHigh=800M
                            Restart=on-failure
                            RestartSec=5

                            # Apply
                            sudo systemctl daemon-reload
                            sudo systemctl restart myapp
                            systemctl status myapp

Swap policy

Disk IO bottlenecks often look like application slowness. CPU may appear idle while requests are stuck waiting for disk. Common causes: database writes, slow cloud volume, Docker logs, journal growth, backups, missing indexes, swap activity or full filesystem.

Disk and IO commands

# Filesystem usage
                            df -h

                            # Largest top-level directories
                            sudo du -sh /* 2>/dev/null | sort -h

                            # Common growth areas
                            sudo du -sh /var/log/*
                            sudo du -sh /var/lib/docker/*
                            sudo du -sh /var/lib/postgresql/* 2>/dev/null

                            # Block devices
                            lsblk -f
                            findmnt

                            # IO statistics
                            iostat -xz 1

                            # IO by process
                            sudo iotop -o

                            # Journal usage
                            journalctl --disk-usage

IO bottleneck flow

Application latency spike
                            │
                            ├── Is CPU iowait high?
                            │       └── top, iostat
                            │
                            ├── Which disk is busy?
                            │       └── iostat -xz 1
                            │
                            ├── Which process writes?
                            │       └── iotop -o
                            │
                            ├── Is filesystem near full?
                            │       └── df -h
                            │
                            ├── Did logs or Docker grow?
                            │       └── du -sh /var/log /var/lib/docker
                            │
                            └── Is database the writer?
                            ├── check slow queries
                            ├── check checkpoints
                            └── check volume IOPS

Safe cleanup examples

# Clean apt cache
                            sudo apt clean

                            # Remove unused packages
                            sudo apt autoremove

                            # Vacuum systemd journal by time
                            sudo journalctl --vacuum-time=14d

                            # Vacuum systemd journal by size
                            sudo journalctl --vacuum-size=1G

                            # Docker usage
                            docker system df

                            # Docker cleanup - careful on production
                            docker image prune
                            docker container prune

Preventive controls

Prevent disk incidents:
                            - alert when filesystem > 80%
                            - separate /var for log-heavy servers
                            - configure logrotate
                            - configure Docker log rotation
                            - monitor journal size
                            - monitor database volume
                            - keep backup volume separate
                            - test volume resize procedure

Network issues may appear as API latency, timeouts, intermittent failures, failed database connections, slow downloads or connection storms. Diagnose from local socket state outward: listening ports, established connections, interface errors, DNS, routing, packet loss and remote latency.

Network commands

# Socket summary
                            ss -s

                            # Listening TCP ports
                            ss -lntp

                            # Established connections
                            ss -antp

                            # Network interfaces and counters
                            ip -s link

                            # Routes
                            ip r

                            # DNS
                            resolvectl status
                            dig example.com

                            # Latency and packet loss
                            ping -c 5 1.1.1.1
                            mtr -rw example.com

                            # Live bandwidth
                            nload
                            sudo iftop

Network diagnosis flow

Network latency or timeout
                            │
                            ├── Local service listening?
                            │       └── ss -lntp
                            │
                            ├── Firewall blocking?
                            │       └── ufw status, cloud security group
                            │
                            ├── DNS slow or wrong?
                            │       └── dig, resolvectl
                            │
                            ├── Route correct?
                            │       └── ip r
                            │
                            ├── Packet loss?
                            │       └── ping, mtr
                            │
                            ├── Interface drops?
                            │       └── ip -s link
                            │
                            └── Too many connections?
                            └── ss -s, logs, rate limits

Connection pressure examples

# Count connections by state
                            ss -ant | awk 'NR>1 {state[$1]++} END {for (s in state) print s, state[s]}'

                            # Top remote IPs connected to port 443
                            ss -ant '( sport = :443 )' | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

                            # Check Nginx access bursts
                            sudo tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Kernel tuning should be conservative. Ubuntu defaults are reasonable for general production. Change kernel parameters only when you understand the workload and can measure before and after. Keep changes versioned and reversible.

Inspect kernel and limits

# Kernel version
                            uname -a

                            # CPU cores
                            nproc

                            # Current sysctl values
                            sysctl vm.swappiness
                            sysctl net.core.somaxconn
                            sysctl net.ipv4.ip_local_port_range

                            # Current shell limits
                            ulimit -a

                            # systemd service limits
                            systemctl show nginx | grep -E "LimitNOFILE|LimitNPROC"

                            # Kernel messages
                            dmesg -T | tail -100
                            journalctl -k --since today

Safe sysctl pattern

# Temporary test until reboot
                            sudo sysctl -w net.core.somaxconn=4096

                            # Persistent setting
                            sudo vim /etc/sysctl.d/99-custom-performance.conf

                            # Example content
                            net.core.somaxconn = 4096
                            vm.swappiness = 10

                            # Apply
                            sudo sysctl --system

                            # Verify
                            sysctl net.core.somaxconn
                            sysctl vm.swappiness

systemd limit example

# Create override
                            sudo systemctl edit nginx

                            # Add:
                            [Service]
                            LimitNOFILE=65535

                            # Apply
                            sudo systemctl daemon-reload
                            sudo systemctl restart nginx

                            # Verify
                            systemctl show nginx | grep LimitNOFILE

Tuning decision tree

Want to tune kernel?
                            │
                            ├── Is bottleneck measured?
                            │       ├── no -> measure first
                            │       └── yes
                            │
                            ├── Is app configured consistently?
                            │       ├── no -> tune app first
                            │       └── yes
                            │
                            ├── Is change reversible?
                            │       ├── no -> do not apply
                            │       └── yes
                            │
                            └── Apply one change
                            ├── measure again
                            ├── document
                            └── keep rollback

Production robustness depends on what happens when a process fails. systemd can restart services, limit resources, order dependencies, isolate users, set environment files and expose logs. A fragile script becomes a production service when it has a proper unit.

Robust service unit

[Unit]
                            Description=My application service
                            After=network.target
                            StartLimitIntervalSec=60
                            StartLimitBurst=5

                            [Service]
                            User=myapp
                            Group=myapp
                            WorkingDirectory=/srv/myapp
                            EnvironmentFile=/srv/myapp/.env
                            ExecStart=/srv/myapp/venv/bin/gunicorn config.wsgi:application \
                            --bind 127.0.0.1:8000 \
                            --workers 3
                            Restart=on-failure
                            RestartSec=5
                            TimeoutStopSec=30
                            LimitNOFILE=65535
                            MemoryMax=1G

                            [Install]
                            WantedBy=multi-user.target

Service robustness flow

Service process
                            │
                            ├── runs as non-root user
                            ├── starts after dependencies
                            ├── has environment file
                            ├── logs to journald
                            ├── restarts on failure
                            ├── has restart backoff
                            ├── has resource limits
                            └── is enabled at boot
                            │
                            ▼
                            Operations
                            ├── systemctl status
                            ├── journalctl -u service
                            ├── systemctl restart service
                            ├── systemctl show service
                            └── alerts on restart count

Service diagnostics

# Status
                            systemctl status myapp

                            # Logs
                            journalctl -u myapp --since "1 hour ago"
                            journalctl -u myapp -f

                            # Check restart count and limits
                            systemctl show myapp | grep -E "NRestarts|Restart|Memory|LimitNOFILE"

                            # Failed units
                            systemctl --failed

                            # Reload unit changes
                            sudo systemctl daemon-reload

Monitoring makes performance visible before users complain. The minimum production stack should monitor CPU, memory, disk, IO, network, service state, open ports, logs, reboot-required state, certificate expiry, backups and application health.

Monitoring stack example

Ubuntu server
                            │
                            ├── node exporter
                            ├── journald logs
                            ├── application metrics
                            ├── nginx metrics/logs
                            ├── database exporter
                            └── backup status
                            │
                            ▼
                            Observability platform
                            ├── Prometheus
                            ├── Grafana
                            ├── Loki / ELK
                            ├── Alertmanager
                            └── incident channel

Local monitoring commands

# CPU and memory
                            top
                            free -h
                            vmstat 1

                            # Disk and IO
                            df -h
                            iostat -xz 1
                            iotop -o

                            # Network
                            ss -s
                            ip -s link
                            nload

                            # Services and logs
                            systemctl --failed
                            journalctl -p warning --since "30 min ago"

                            # Reboot required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

Alerting baseline

Recommended alerts:
                            [ ] Disk filesystem > 80%
                            [ ] Disk filesystem > 90%
                            [ ] Inode usage high
                            [ ] Service failed
                            [ ] Reboot required too long
                            [ ] OOM kill detected
                            [ ] Swap activity sustained
                            [ ] CPU saturation sustained
                            [ ] IO wait sustained
                            [ ] Backup failed
                            [ ] Certificate expires soon
                            [ ] SSH failure spike
                            [ ] HTTP 5xx spike
                            [ ] Database unavailable

Symptom matrix

One-shot diagnostic

echo "== HOST =="
                            hostnamectl

                            echo "== UPTIME =="
                            uptime

                            echo "== CPU/MEM =="
                            free -h
                            top -b -n1 | head -30

                            echo "== DISK =="
                            df -h

                            echo "== PORTS =="
                            ss -lntp

                            echo "== FAILED SERVICES =="
                            systemctl --failed

                            echo "== WARNINGS =="
                            journalctl -p warning --since "30 min ago" --no-pager | tail -100

Universal performance decision tree

Production issue
                            │
                            ├── Is it user-visible?
                            │       ├── yes -> check app SLO, HTTP 5xx, latency
                            │       └── no  -> check monitoring and trend
                            │
                            ├── Resource saturation?
                            │       ├── CPU -> top, pidstat
                            │       ├── RAM -> free, vmstat, OOM
                            │       ├── IO  -> iostat, iotop
                            │       └── NET -> ss, ip, mtr
                            │
                            ├── Service instability?
                            │       └── systemctl, journalctl
                            │
                            ├── Recent change?
                            │       ├── deployment
                            │       ├── apt upgrade
                            │       ├── config change
                            │       └── traffic spike
                            │
                            └── Fix strategy
                            ├── rollback
                            ├── reduce load
                            ├── scale resource
                            ├── tune one parameter
                            └── monitor result

Change discipline

During performance incident:
                            [ ] Do not change many things at once
                            [ ] Capture metrics before change
                            [ ] Identify the bottleneck
                            [ ] Apply one controlled change
                            [ ] Measure again
                            [ ] Keep rollback possible
                            [ ] Document root cause
                            [ ] Add alert if missing
                            [ ] Add runbook step if useful

Production performance baseline

[ ] Ubuntu LTS is used
                            [ ] Packages are updated
                            [ ] Reboot policy exists
                            [ ] CPU metrics are monitored
                            [ ] Memory and swap are monitored
                            [ ] Disk usage is monitored
                            [ ] IO latency is monitored
                            [ ] Network errors are monitored
                            [ ] systemd failed units are alerted
                            [ ] Service restart count is monitored
                            [ ] Logs are centralized if possible
                            [ ] Backups are monitored
                            [ ] Restore has been tested
                            [ ] Capacity baseline is documented
                            [ ] Load test exists for critical services
                            [ ] Runbooks exist for CPU/RAM/IO/disk incidents

Robust service checklist

[ ] Service runs under non-root user
                            [ ] systemd unit is versioned
                            [ ] Restart policy is configured
                            [ ] Resource limits are configured if needed
                            [ ] Logs are visible with journalctl
                            [ ] Health check exists
                            [ ] Environment file permissions are strict
                            [ ] Deployment rollback is possible
                            [ ] Service starts at boot
                            [ ] Dependencies are documented

Command cheat sheet

# CPU
                            uptime
                            top
                            htop
                            mpstat -P ALL 1
                            pidstat -u 1

                            # Memory
                            free -h
                            vmstat 1
                            swapon --show
                            journalctl -k | grep -i oom

                            # Disk / IO
                            df -h
                            du -sh /var/*
                            iostat -xz 1
                            iotop -o
                            journalctl --disk-usage

                            # Network
                            ss -s
                            ss -lntp
                            ip -s link
                            mtr -rw example.com
                            nload

                            # Services
                            systemctl --failed
                            systemctl status service
                            journalctl -u service -f

                            # Kernel / limits
                            uname -a
                            sysctl -a | grep vm.swappiness
                            ulimit -a

Final rule

Minimal robust server profile

Minimum robust Ubuntu server:
                            - Ubuntu LTS
                            - systemd-managed services
                            - restart policies
                            - monitoring for CPU/RAM/disk/IO/network
                            - alerting on failed services and disk growth
                            - log retention
                            - patch and reboot policy
                            - backup and restore test
                            - documented runbook

Public AMI catalogs contain many images. In production, you should avoid selecting a random public image called “Ubuntu”. Use official Canonical images and verify the owner. This reduces the risk of using an untrusted image with unknown modifications.

Console filtering pattern

EC2 Console
                            │
                            ├── Images
                            ├── AMIs
                            ├── Public images
                            ├── Owner = 099720109477
                            ├── Name contains ubuntu/images/hvm-ssd/ubuntu
                            ├── Select LTS release
                            └── Verify architecture and region

AWS CLI AMI search example

aws ec2 describe-images \
                            --owners 099720109477 \
                            --filters \
                            "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-*-24.04-amd64-server-*" \
                            "Name=state,Values=available" \
                            "Name=architecture,Values=x86_64" \
                            --query 'Images | sort_by(@, &CreationDate)[-5:].{Name:Name,ImageId:ImageId,CreationDate:CreationDate}' \
                            --output table

AMI selection decision tree

Need Ubuntu EC2 image?
                            │
                            ├── Is this production?
                            │       ├── yes -> choose LTS
                            │       └── no  -> LTS still preferred, interim only if justified
                            │
                            ├── Is owner Canonical?
                            │       ├── yes -> continue
                            │       └── no  -> reject for production
                            │
                            ├── Does architecture match instance?
                            │       ├── yes -> continue
                            │       └── no  -> select amd64 or arm64 correctly
                            │
                            ├── Is AMI approved or pinned?
                            │       ├── yes -> launch
                            │       └── no  -> review before production

Launching Ubuntu on EC2 is a sequence of infrastructure decisions. The AMI is only the OS. Production quality also depends on instance sizing, EBS volume type, network placement, security groups, IAM role, SSH access, user data and monitoring.

EC2 launch flow

Launch EC2
                            │
                            ├── Choose official Ubuntu LTS AMI
                            ├── Choose instance type
                            ├── Configure EBS root volume
                            ├── Select VPC and subnet
                            ├── Attach security group
                            ├── Attach IAM role
                            ├── Select SSH key pair
                            ├── Add user data
                            ├── Add tags
                            └── Launch instance

Reference AWS Ubuntu architecture

Internet
                            │
                            ▼
                            AWS Load Balancer
                            │
                            ├── HTTPS listener
                            ├── certificate
                            └── health checks
                            │
                            ▼
                            Public or private app subnet
                            │
                            ├── Ubuntu EC2 app server
                            │       ├── Nginx
                            │       ├── Gunicorn / app runtime
                            │       ├── CloudWatch agent
                            │       └── UFW local firewall
                            │
                            └── Security group
                            ├── inbound from load balancer only
                            └── SSH from bastion or admin IP only

                            Private data subnet
                            │
                            ├── RDS / database
                            ├── Redis / cache
                            └── no public exposure

Sizing examples

Ubuntu cloud images use SSH keys for initial access. On AWS, the selected EC2 key pair is injected into the default Ubuntu user account during first boot. For Ubuntu images, the common default username is ubuntu.

SSH examples

# Secure private key permissions
                            chmod 600 my-aws-key.pem

                            # Connect to Ubuntu EC2
                            ssh -i my-aws-key.pem ubuntu@EC2_PUBLIC_IP

                            # First checks
                            hostnamectl
                            whoami
                            sudo -l
                            ip a
                            systemctl status ssh

Safe access architecture

Admin workstation
                            │
                            ├── SSH private key
                            └── fixed public IP if possible
                            │
                            ▼
                            Security group
                            │
                            ├── allow SSH only from admin IP
                            └── or allow SSH only from bastion
                            │
                            ▼
                            Ubuntu EC2 instance
                            │
                            ├── default ubuntu user
                            ├── sudo for admin tasks
                            ├── no root SSH login
                            └── logs in auth/journal

Hardening after first login

# Update packages
                            sudo apt update
                            sudo apt upgrade

                            # Create named admin user if needed
                            sudo adduser deploy
                            sudo usermod -aG sudo deploy

                            # Add SSH key for deploy user
                            sudo mkdir -p /home/deploy/.ssh
                            sudo cp /home/ubuntu/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
                            sudo chown -R deploy:deploy /home/deploy/.ssh
                            sudo chmod 700 /home/deploy/.ssh
                            sudo chmod 600 /home/deploy/.ssh/authorized_keys

                            # Test deploy login before restricting access
                            ssh deploy@EC2_PUBLIC_IP

Access alternatives

cloud-init is the standard first-boot initialization system for Ubuntu cloud images. It reads cloud metadata and user data, then applies configuration such as users, SSH keys, packages, files, commands, hostname, timezone and service setup.

cloud-init lifecycle

EC2 instance first boot
                            │
                            ├── Query AWS metadata service
                            ├── Read user data
                            ├── Configure hostname
                            ├── Inject SSH key
                            ├── Create users
                            ├── Configure packages
                            ├── Write files
                            ├── Run commands
                            ├── Start services
                            └── Mark initialization complete

Minimal cloud-init baseline

#cloud-config
                            package_update: true
                            package_upgrade: true

                            timezone: UTC

                            packages:
                            - curl
                            - wget
                            - git
                            - vim
                            - htop
                            - ufw
                            - fail2ban
                            - nginx

                            runcmd:
                            - ufw allow OpenSSH
                            - ufw allow 80/tcp
                            - ufw allow 443/tcp
                            - ufw --force enable
                            - systemctl enable --now nginx
                            - systemctl enable --now fail2ban

cloud-init diagnostics

# Status
                            cloud-init status

                            # Wait for completion
                            cloud-init status --wait

                            # Main logs
                            sudo less /var/log/cloud-init.log
                            sudo less /var/log/cloud-init-output.log

                            # Show instance metadata if allowed
                            curl -s http://169.254.169.254/latest/meta-data/ || true

                            # Validate config if tool supports it
                            cloud-init schema --config-file user-data.yaml

User data should be small, readable and reliable. A good pattern is to install only base packages, harden basic access, install monitoring and call a versioned bootstrap script from a trusted source. Avoid stuffing an entire production deployment into a long untested user-data block.

Pattern 1: simple HTTP test server

#cloud-config
                            package_update: true

                            packages:
                            - nginx

                            write_files:
                            - path: /var/www/html/index.html
                            permissions: '0644'
                            content: |
                            Ubuntu EC2 is running.

                            runcmd:
                            - systemctl enable --now nginx

Pattern 2: baseline security bootstrap

#cloud-config
                            package_update: true
                            package_upgrade: true

                            packages:
                            - ufw
                            - fail2ban
                            - curl
                            - htop

                            runcmd:
                            - ufw default deny incoming
                            - ufw default allow outgoing
                            - ufw allow OpenSSH
                            - ufw --force enable
                            - systemctl enable --now fail2ban

Pattern 3: handoff to versioned script

#cloud-config
                            package_update: true

                            packages:
                            - curl
                            - ca-certificates

                            runcmd:
                            - curl -fsSL https://example.com/bootstrap/ubuntu-app.sh -o /root/bootstrap.sh
                            - chmod 700 /root/bootstrap.sh
                            - /root/bootstrap.sh --role app --env prod

Better handoff pattern

Preferred production pattern:
                            1. cloud-init creates minimal baseline
                            2. instance has IAM role
                            3. script is downloaded from trusted private source
                            4. script checksum or signature is verified
                            5. configuration is versioned
                            6. logs are written to /var/log/bootstrap.log
                            7. monitoring reports success or failure

Bootstrap logging example

#!/usr/bin/env bash
                            set -euo pipefail

                            exec > >(tee -a /var/log/bootstrap.log) 2>&1

                            echo "bootstrap started at $(date -Is)"

                            apt update
                            apt install -y nginx

                            systemctl enable --now nginx

                            echo "bootstrap finished at $(date -Is)"

A golden AMI is a prebuilt, approved image containing a hardened baseline: Ubuntu LTS, patches, standard packages, users, agents, logging, monitoring and security defaults. It reduces boot time, improves repeatability and makes replacement safer than manual repair.

Golden AMI build flow

Official Ubuntu AMI
                            │
                            ▼
                            Packer image build
                            │
                            ├── apply apt updates
                            ├── install baseline packages
                            ├── install monitoring agents
                            ├── apply hardening
                            ├── clean temporary files
                            ├── validate services
                            └── create AMI
                            │
                            ▼
                            Approved AMI
                            │
                            ├── tagged with version
                            ├── tested in staging
                            ├── used by launch templates
                            └── rolled out progressively

Replace, do not repair

Traditional server:
                            - SSH into machine
                            - manually patch
                            - manually edit config
                            - server becomes unique
                            - recovery depends on memory

                            Cloud-native server:
                            - build image
                            - deploy new instance
                            - attach to load balancer
                            - drain old instance
                            - terminate old instance
                            - rollback by previous image

Golden AMI governance

[ ] Base AMI owner verified
                            [ ] Ubuntu LTS version recorded
                            [ ] Build script versioned
                            [ ] Security updates applied
                            [ ] Image tests pass
                            [ ] AMI is tagged
                            [ ] AMI ID is published to parameter store or IaC
                            [ ] Rollback AMI is retained
                            [ ] Staging rollout completed
                            [ ] Production rollout is progressive
                            [ ] Old AMIs are retired safely

Launch template model

Launch Template
                            │
                            ├── approved AMI ID
                            ├── instance type
                            ├── IAM role
                            ├── security groups
                            ├── EBS configuration
                            ├── user data
                            └── tags
                            │
                            ▼
                            Auto Scaling Group
                            ├── desired capacity
                            ├── health checks
                            ├── rolling replacement
                            └── rollback to previous template version

Ubuntu hardening and AWS security must work together. Security groups restrict network access before traffic reaches the instance. UFW adds host-level defense. IAM roles avoid static cloud keys. Private subnets prevent unnecessary exposure.

Security group examples

Public web server:
                            - inbound 443/tcp from 0.0.0.0/0
                            - inbound 80/tcp from 0.0.0.0/0 only if redirect is needed
                            - inbound 22/tcp only from admin IP or bastion
                            - outbound restricted if strict policy is required

                            Private app server behind load balancer:
                            - inbound app port only from load balancer security group
                            - inbound SSH only from bastion security group
                            - no direct public access

                            Database server:
                            - inbound DB port only from app security group
                            - no public IP
                            - no public SSH

Layered AWS Ubuntu security diagram

Internet
                            │
                            ▼
                            AWS perimeter
                            ├── Route 53
                            ├── CloudFront / WAF
                            ├── Load Balancer
                            └── Security Groups
                            │
                            ▼
                            Ubuntu host
                            ├── UFW
                            ├── SSH hardening
                            ├── non-root services
                            ├── package updates
                            ├── logs
                            └── monitoring agent
                            │
                            ▼
                            Application
                            ├── TLS
                            ├── secrets management
                            ├── app logs
                            ├── DB access
                            └── health checks

Metadata and credentials

Recommended:
                            - use IAM roles instead of static AWS keys
                            - keep role permissions minimal
                            - avoid storing credentials in user data
                            - avoid secrets in AMI images
                            - use Parameter Store or Secrets Manager
                            - monitor CloudTrail for suspicious API calls
                            - review instance profile permissions

                            Avoid:
                            - AWS_ACCESS_KEY_ID in .bashrc
                            - secrets embedded in user data
                            - secrets baked into AMIs
                            - overly broad IAM roles
                            - public metadata exposure through SSRF-vulnerable apps

Ubuntu EC2 operations combine Linux administration and AWS lifecycle management. The system must be patched, monitored, backed up, logged, tagged, replaceable and tested. A server that cannot be rebuilt is a long-term operational risk.

Operational metrics

Host:
                            - CPU utilization
                            - memory usage
                            - disk usage
                            - disk IO latency
                            - network throughput
                            - systemd failed services
                            - reboot-required state

                            Application:
                            - HTTP latency
                            - HTTP 5xx
                            - worker queue depth
                            - database connections
                            - error logs
                            - health check status

                            AWS:
                            - instance status checks
                            - EBS burst balance
                            - EBS latency
                            - load balancer health
                            - security group changes
                            - CloudTrail events

Recovery patterns

Pattern 1: EBS snapshot restore
                            ├── create volume from snapshot
                            ├── attach to instance
                            ├── mount and recover data
                            └── validate application

                            Pattern 2: AMI rollback
                            ├── select previous AMI
                            ├── launch replacement instance
                            ├── attach to load balancer
                            ├── validate health
                            └── terminate bad instance

                            Pattern 3: Blue/green replacement
                            ├── build new Ubuntu image
                            ├── launch green environment
                            ├── smoke test
                            ├── shift traffic
                            └── keep blue as rollback

Ubuntu EC2 health commands

# OS and kernel
                            hostnamectl
                            uname -a
                            lsb_release -a

                            # Cloud-init status
                            cloud-init status
                            sudo tail -100 /var/log/cloud-init-output.log

                            # System health
                            uptime
                            df -h
                            free -h
                            systemctl --failed
                            journalctl -p warning --since "30 min ago"

                            # Network and ports
                            ip a
                            ip r
                            ss -lntp

                            # Reboot required
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

AMI and launch checklist

[ ] Official Ubuntu AMI selected
                            [ ] Canonical owner ID verified
                            [ ] LTS release selected for production
                            [ ] Architecture matches instance type
                            [ ] AMI ID is approved or pinned
                            [ ] Instance type matches workload
                            [ ] EBS volume size is sufficient
                            [ ] EBS performance is appropriate
                            [ ] VPC and subnet are correct
                            [ ] Security group is minimal
                            [ ] SSH access is restricted
                            [ ] IAM role uses least privilege
                            [ ] User data is tested
                            [ ] Tags are complete
                            [ ] Monitoring is enabled

Cloud-init checklist

[ ] User data starts with #cloud-config if YAML
                            [ ] package_update is intentional
                            [ ] package_upgrade is intentional
                            [ ] No long-lived secrets in user data
                            [ ] Bootstrap logs to file
                            [ ] cloud-init status is checked
                            [ ] /var/log/cloud-init-output.log is reviewed
                            [ ] Failed commands are visible
                            [ ] Complex setup is delegated to versioned script
                            [ ] Script source is trusted
                            [ ] Rebuild process is documented

Production operations checklist

[ ] UFW matches security group policy
                            [ ] Root SSH login is disabled
                            [ ] SSH keys are controlled
                            [ ] Patch policy exists
                            [ ] Reboot policy exists
                            [ ] CloudWatch or equivalent metrics enabled
                            [ ] Logs are shipped centrally
                            [ ] EBS snapshots are scheduled
                            [ ] Restore has been tested
                            [ ] Launch template is versioned
                            [ ] Golden AMI pipeline exists if fleet is large
                            [ ] Rollback AMI is retained
                            [ ] Instance is replaceable
                            [ ] Runbook exists
                            [ ] Owner and cost tags are present

Final rule

Minimal safe EC2 Ubuntu baseline

Minimum safe baseline:
                            - official Ubuntu LTS AMI
                            - Canonical owner verified
                            - SSH restricted
                            - security group minimal
                            - IAM role instead of static keys
                            - cloud-init bootstrap tested
                            - packages updated
                            - UFW enabled if needed
                            - monitoring installed
                            - snapshots configured
                            - restore tested
                            - instance documented and tagged

Docker packages an application and its runtime dependencies into an image. A container is a running instance of that image. On Ubuntu, Docker is commonly used for development, CI/CD, local demos, staging environments and production workloads behind a reverse proxy or orchestrator.

Install Docker baseline

# Install from Ubuntu repository for simple usage
                            sudo apt update
                            sudo apt install docker.io docker-compose-v2

                            # Enable Docker
                            sudo systemctl enable --now docker

                            # Check status
                            systemctl status docker

                            # Add current user to docker group
                            sudo usermod -aG docker $USER

                            # Re-login before using docker without sudo
                            docker version
                            docker info

Core Docker commands

# List running containers
                            docker ps

                            # List all containers
                            docker ps -a

                            # List images
                            docker images

                            # Run Nginx
                            docker run --name web -p 8080:80 nginx:latest

                            # Stop and remove
                            docker stop web
                            docker rm web

                            # Logs
                            docker logs web
                            docker logs -f web

                            # Shell inside container
                            docker exec -it web bash

                            # Inspect container
                            docker inspect web

                            # Disk usage
                            docker system df

Docker architecture

Developer or CI
                            │
                            ├── Dockerfile
                            ├── build image
                            ├── tag image
                            └── push image
                            │
                            ▼
                            Registry
                            │
                            ├── Docker Hub
                            ├── GitHub Container Registry
                            ├── AWS ECR
                            └── private registry
                            │
                            ▼
                            Ubuntu host
                            │
                            ├── pull image
                            ├── run container
                            ├── attach volume
                            ├── expose port
                            └── collect logs

Docker Compose defines several containers in one YAML file. It is excellent for local development, prototypes, demos, test stacks and small internal deployments. For large production environments, Compose is usually replaced by Kubernetes, ECS, Nomad or another orchestrator.

Example Compose stack

services:
                            web:
                            build: .
                            command: gunicorn config.wsgi:application --bind 0.0.0.0:8000
                            ports:
                            - "8000:8000"
                            environment:
                            DJANGO_SETTINGS_MODULE: config.settings
                            DATABASE_URL: postgres://app:app@db:5432/app
                            REDIS_URL: redis://redis:6379/0
                            depends_on:
                            - db
                            - redis

                            db:
                            image: postgres:16
                            environment:
                            POSTGRES_DB: app
                            POSTGRES_USER: app
                            POSTGRES_PASSWORD: app
                            volumes:
                            - pgdata:/var/lib/postgresql/data

                            redis:
                            image: redis:7

                            volumes:
                            pgdata:

Compose commands

# Start stack
                            docker compose up

                            # Start in background
                            docker compose up -d

                            # Show containers
                            docker compose ps

                            # Show logs
                            docker compose logs
                            docker compose logs -f web

                            # Execute command
                            docker compose exec web bash

                            # Stop stack
                            docker compose down

                            # Stop and remove volumes - destructive
                            docker compose down -v

                            # Rebuild
                            docker compose build
                            docker compose up -d --build

Compose lifecycle

docker-compose.yml
                            │
                            ├── services
                            ├── networks
                            ├── volumes
                            ├── environment
                            ├── ports
                            └── dependencies
                            │
                            ▼
                            docker compose up
                            │
                            ├── creates network
                            ├── creates volumes
                            ├── starts containers
                            ├── streams logs
                            └── exposes ports

Production cautions

If using Compose in production:
                            [ ] pin image versions
                            [ ] avoid latest tags
                            [ ] define restart policies
                            [ ] configure log rotation
                            [ ] persist data in named volumes
                            [ ] backup volumes
                            [ ] monitor containers
                            [ ] document upgrade process
                            [ ] keep secrets out of git
                            [ ] place behind Nginx or load balancer

LXD manages LXC system containers. Unlike Docker, which usually runs one application process per container, LXD containers can behave like lightweight Linux machines with init, SSH, packages, services and multiple processes. This makes LXD excellent for labs, training, test environments, network simulations and isolated system services.

LXD install and init

# Install LXD
                            sudo snap install lxd

                            # Add user to lxd group
                            sudo usermod -aG lxd $USER

                            # Re-login, then initialize
                            lxd init

                            # Launch Ubuntu container
                            lxc launch ubuntu:24.04 test1

                            # List containers
                            lxc list

                            # Shell inside container
                            lxc exec test1 -- bash

LXD command examples

# Start / stop
                            lxc start test1
                            lxc stop test1

                            # Execute command
                            lxc exec test1 -- apt update

                            # Copy file into container
                            lxc file push local.txt test1/root/local.txt

                            # Snapshot
                            lxc snapshot test1 before-change

                            # Restore snapshot
                            lxc restore test1 before-change

                            # Delete container
                            lxc delete test1 --force

                            # Show configuration
                            lxc config show test1

                            # Limit memory
                            lxc config set test1 limits.memory 1GiB

                            # Limit CPU
                            lxc config set test1 limits.cpu 2

LXD lab architecture

Ubuntu host
                            │
                            ├── lxdbr0 bridge
                            │
                            ├── container: web01
                            │       ├── nginx
                            │       └── app service
                            │
                            ├── container: db01
                            │       └── PostgreSQL
                            │
                            ├── container: monitor01
                            │       └── Prometheus / Grafana
                            │
                            └── snapshots
                            ├── before-upgrade
                            ├── before-network-test
                            └── clean-baseline

KVM is Linux kernel-based virtualization. With QEMU and libvirt, Ubuntu can host full virtual machines. Each VM has its own virtual CPU, memory, disk, network card and guest operating system. This is heavier than containers but gives stronger isolation and supports different kernels and operating systems.

Install KVM stack

# Check CPU virtualization support
                            egrep -c '(vmx|svm)' /proc/cpuinfo

                            # Install KVM/libvirt tools
                            sudo apt update
                            sudo apt install -y \
                            qemu-kvm \
                            libvirt-daemon-system \
                            libvirt-clients \
                            bridge-utils \
                            virtinst

                            # Add user to groups
                            sudo usermod -aG libvirt,kvm $USER

                            # Re-login, then check
                            virsh list --all
                            systemctl status libvirtd

KVM architecture

Ubuntu host
                            │
                            ├── Linux kernel with KVM
                            ├── QEMU processes
                            ├── libvirt daemon
                            ├── virtual networks
                            ├── storage pools
                            └── VM guests
                            │
                            ├── Ubuntu VM
                            ├── Debian VM
                            ├── Windows VM
                            └── lab appliance VM

virsh commands

# List VMs
                            virsh list --all

                            # Start VM
                            virsh start vm1

                            # Stop gracefully
                            virsh shutdown vm1

                            # Force stop
                            virsh destroy vm1

                            # VM info
                            virsh dominfo vm1

                            # Autostart VM
                            virsh autostart vm1

                            # Show networks
                            virsh net-list --all

                            # Show storage pools
                            virsh pool-list --all

When KVM is better than containers

Use KVM when:
                            - guest needs its own kernel
                            - running another OS
                            - stronger isolation is required
                            - testing kernel-level behavior
                            - simulating production VM topology
                            - running legacy software
                            - needing VM snapshots and full machine state

virt-manager is a desktop GUI for managing KVM/libvirt virtual machines. It is useful for labs, local testing, training, troubleshooting, VM console access and visual VM configuration. On servers, CLI tools such as virsh and automation are more common.

Install virt-manager

sudo apt update
                            sudo apt install virt-manager

                            # Start GUI from desktop
                            virt-manager

                            # Check libvirt service
                            systemctl status libvirtd

                            # List VMs from CLI
                            virsh list --all

VM creation flow with virt-manager

virt-manager
                            │
                            ├── New virtual machine
                            ├── Choose ISO or cloud image
                            ├── Select OS type
                            ├── Allocate CPU and RAM
                            ├── Create virtual disk
                            ├── Choose network
                            ├── Start installation
                            └── Install guest tools if needed

Lab topology example

Ubuntu desktop host
                            │
                            ├── virt-manager
                            │
                            ├── VM: router-lab
                            │       ├── NIC 1: NAT
                            │       └── NIC 2: isolated lab network
                            │
                            ├── VM: web-server
                            │       └── lab network
                            │
                            └── VM: db-server
                            └── lab network

Good usage boundaries

Use virt-manager for:
                            - desktop labs
                            - OS installation
                            - visual debugging
                            - VM console access
                            - local experiments

                            Prefer CLI/IaC for:
                            - production servers
                            - repeatable deployment
                            - remote headless hosts
                            - large VM fleets
                            - automated rebuilds

Ubuntu containers and virtualization are extremely useful for reproducible development, automated tests, CI runners, network labs, database experiments, security sandboxes and integration environments. The goal is to reduce “works on my machine” problems.

CI pipeline example

Git push
                            │
                            ▼
                            CI runner on Ubuntu
                            │
                            ├── checkout code
                            ├── build Docker image
                            ├── start Compose services
                            │       ├── app
                            │       ├── postgres
                            │       └── redis
                            ├── run tests
                            ├── scan image
                            ├── push image to registry
                            └── deploy to target environment

Demo architecture: one Ubuntu host

Ubuntu host
                            │
                            ├── Docker service
                            │       ├── nginx container
                            │       ├── app container
                            │       └── redis container
                            │
                            ├── LXD container
                            │       └── ubuntu:24.04 system lab
                            │
                            ├── KVM VM
                            │       └── isolated test machine
                            │
                            └── Monitoring
                            ├── node exporter
                            ├── docker stats
                            └── systemd status

Useful demo commands

# Docker demo
                            docker run -d --name demo-nginx -p 8080:80 nginx:latest
                            curl -I http://localhost:8080
                            docker logs demo-nginx

                            # LXD demo
                            lxc launch ubuntu:24.04 lab1
                            lxc exec lab1 -- bash -lc "hostnamectl && apt update"

                            # KVM visibility
                            virsh list --all

                            # Host monitoring
                            top
                            df -h
                            ss -lntp

Containers in production require more than docker run. You need image governance, non-root containers, pinned versions, health checks, persistent volumes, log rotation, backup, monitoring, network boundaries, secrets management and a clear update strategy.

Single-host container production pattern

Internet
                            │
                            ▼
                            Nginx on Ubuntu host
                            │
                            ├── TLS termination
                            ├── rate limiting
                            ├── static files
                            └── reverse proxy
                            │
                            ▼
                            Docker network
                            │
                            ├── app container
                            ├── worker container
                            ├── redis container
                            └── internal-only database or external DB

Docker daemon log rotation

# /etc/docker/daemon.json
                            {
                            "log-driver": "json-file",
                            "log-opts": {
                            "max-size": "50m",
                            "max-file": "5"
                            }
                            }

                            # Apply
                            sudo systemctl restart docker

Production Compose example

services:
                            app:
                            image: registry.example.com/myapp:1.4.2
                            restart: unless-stopped
                            env_file:
                            - /srv/myapp/app.env
                            networks:
                            - internal
                            healthcheck:
                            test: ["CMD", "curl", "-f", "http://localhost:8000/health/"]
                            interval: 30s
                            timeout: 5s
                            retries: 3

                            redis:
                            image: redis:7.2
                            restart: unless-stopped
                            networks:
                            - internal
                            volumes:
                            - redisdata:/data

                            networks:
                            internal:

                            volumes:
                            redisdata:

When to move beyond Compose

Move to orchestrator when:
                            - multiple hosts are needed
                            - rolling updates are required
                            - autoscaling is required
                            - service discovery is complex
                            - secrets and config need governance
                            - many teams deploy independently
                            - high availability is mandatory

Troubleshooting should start at the right layer: host health, Docker daemon, container logs, network binding, volume permissions, image version, LXD profile, libvirt daemon, VM console or storage pool. Avoid deleting containers or volumes before understanding where persistent data lives.

Docker troubleshooting commands

docker ps
                            docker ps -a
                            docker logs CONTAINER
                            docker inspect CONTAINER
                            docker exec -it CONTAINER bash
                            docker stats
                            docker system df
                            docker network ls
                            docker volume ls
                            systemctl status docker
                            journalctl -u docker --since "30 min ago"

LXD and KVM troubleshooting commands

# LXD
                            lxc list
                            lxc info CONTAINER
                            lxc config show CONTAINER
                            lxc network list
                            lxc storage list
                            lxc exec CONTAINER -- bash
                            journalctl -u snap.lxd.daemon --since "30 min ago"

                            # KVM / libvirt
                            virsh list --all
                            virsh dominfo VM
                            virsh net-list --all
                            virsh pool-list --all
                            systemctl status libvirtd
                            journalctl -u libvirtd --since "30 min ago"

Decision tree

Container or VM issue
                            │
                            ├── Is host healthy?
                            │       └── CPU, RAM, disk, network
                            │
                            ├── Is manager running?
                            │       ├── Docker daemon
                            │       ├── LXD daemon
                            │       └── libvirt daemon
                            │
                            ├── Is workload running?
                            │       ├── docker ps -a
                            │       ├── lxc list
                            │       └── virsh list --all
                            │
                            ├── What do logs say?
                            │       ├── docker logs
                            │       ├── lxc info --show-log
                            │       └── journalctl
                            │
                            └── Is it network, storage or permissions?
                            ├── ports
                            ├── volumes
                            ├── bridges
                            └── UID/GID

Technology choice checklist

[ ] Docker selected for application containers
                            [ ] Compose selected for local or small multi-service stacks
                            [ ] LXD selected for system-container labs
                            [ ] KVM selected for full VM isolation
                            [ ] virt-manager selected for GUI lab management
                            [ ] Production orchestrator considered if multi-node
                            [ ] Persistent data location is documented
                            [ ] Backup strategy exists for volumes and VM disks
                            [ ] Network exposure is documented
                            [ ] Host firewall rules are known
                            [ ] Logs are rotated
                            [ ] Images are pinned
                            [ ] Secrets are not stored in git
                            [ ] Monitoring covers host and workloads
                            [ ] Update and rollback process exists

Docker cheat sheet

docker ps
                            docker ps -a
                            docker images
                            docker run --name web -p 8080:80 nginx
                            docker logs -f web
                            docker exec -it web bash
                            docker stop web
                            docker rm web
                            docker system df
                            docker compose up -d
                            docker compose logs -f
                            docker compose down

LXD / KVM cheat sheet

# LXD
                            lxd init
                            lxc launch ubuntu:24.04 c1
                            lxc list
                            lxc exec c1 -- bash
                            lxc snapshot c1 before-change
                            lxc restore c1 before-change
                            lxc delete c1 --force

                            # KVM / libvirt
                            virsh list --all
                            virsh start vm1
                            virsh shutdown vm1
                            virsh dominfo vm1
                            virsh net-list --all
                            virsh pool-list --all

                            # Host checks
                            systemctl status docker
                            systemctl status libvirtd
                            df -h
                            free -h
                            ss -lntp

Final rule

Minimal robust host profile

Minimum robust Ubuntu container/VM host:
                            - Ubuntu LTS
                            - patched kernel and packages
                            - Docker/LXD/KVM installed intentionally
                            - non-root operational model
                            - storage sized and monitored
                            - log rotation enabled
                            - firewall rules documented
                            - images or VM templates versioned
                            - backups tested
                            - monitoring and alerts enabled
                            - runbook documented

The first minutes of an incident are for orientation. You need to know whether the machine is alive, whether the disk is full, whether memory is exhausted, whether services failed, which ports are listening, and whether logs show a clear error.

One-screen diagnostic

echo "== HOST =="
                            hostnamectl

                            echo "== UPTIME =="
                            uptime

                            echo "== WHO IS CONNECTED =="
                            who

                            echo "== DISK =="
                            df -h

                            echo "== MEMORY =="
                            free -h

                            echo "== FAILED UNITS =="
                            systemctl --failed

                            echo "== LISTENING PORTS =="
                            ss -lntp

                            echo "== RECENT WARNINGS =="
                            journalctl -p warning --since "30 min ago" --no-pager | tail -100

Minimum incident facts

Incident facts to capture:
                            - exact symptom
                            - first detection time
                            - impacted users or services
                            - hostname
                            - Ubuntu version
                            - kernel version
                            - uptime
                            - recent deployments
                            - recent package upgrades
                            - failed services
                            - resource saturation
                            - relevant logs
                            - immediate workaround
                            - rollback option

Recent change checks

# Apt package changes
                            less /var/log/apt/history.log
                            less /var/log/apt/term.log

                            # Recently modified config files under /etc
                            sudo find /etc -type f -mtime -2 -ls | sort -k 8,9

                            # Recent system boots
                            last reboot | head

                            # Current users
                            who
                            w

                            # Cron logs if syslog is available
                            grep CRON /var/log/syslog | tail -100

Immediate triage matrix

Most production daemons on Ubuntu are managed by systemd. When a service is down, start with systemctl status, then read the journal, validate the config, check ports, check permissions, and only then restart.

Service commands

# Status
                            systemctl status SERVICE

                            # Logs
                            journalctl -u SERVICE --since "1 hour ago"
                            journalctl -u SERVICE -f

                            # Restart
                            sudo systemctl restart SERVICE

                            # Reload config if supported
                            sudo systemctl reload SERVICE

                            # Enable at boot
                            sudo systemctl enable SERVICE

                            # Failed units
                            systemctl --failed

                            # Unit file
                            systemctl cat SERVICE

                            # Runtime properties
                            systemctl show SERVICE | less

Service failure decision tree

Service failed
                            │
                            ├── Read status
                            │       └── systemctl status SERVICE
                            │
                            ├── Read logs with time window
                            │       └── journalctl -u SERVICE --since "30 min ago"
                            │
                            ├── Config syntax valid?
                            │       ├── nginx -t
                            │       ├── sshd -t
                            │       └── app-specific check
                            │
                            ├── Dependency available?
                            │       ├── database
                            │       ├── redis
                            │       ├── network
                            │       └── filesystem mount
                            │
                            ├── Permissions correct?
                            │       ├── service user
                            │       ├── config files
                            │       └── runtime directories
                            │
                            ├── Port conflict?
                            │       └── ss -lntp
                            │
                            └── Restart with monitoring
                            └── systemctl restart SERVICE

Common service failures

Logs are the timeline of the incident. On Ubuntu, the main tools are journalctl, service-specific logs, /var/log/auth.log, /var/log/syslog, kernel logs and application logs. The most useful log queries are scoped by service and time.

journalctl commands

# Recent errors and context
                            journalctl -xe

                            # Service logs today
                            journalctl -u SERVICE --since today

                            # Service logs last 30 minutes
                            journalctl -u SERVICE --since "30 min ago"

                            # Follow service logs
                            journalctl -u SERVICE -f

                            # Warnings and errors today
                            journalctl -p warning --since today

                            # Current boot
                            journalctl -b

                            # Previous boot
                            journalctl -b -1

                            # Kernel logs
                            journalctl -k --since today

Classic log files

# System log
                            sudo tail -200 /var/log/syslog

                            # Authentication log
                            sudo tail -200 /var/log/auth.log

                            # Nginx logs
                            sudo tail -200 /var/log/nginx/error.log
                            sudo tail -200 /var/log/nginx/access.log

                            # Apt history
                            less /var/log/apt/history.log
                            less /var/log/apt/term.log

                            # Compressed rotated logs
                            zgrep -i "error" /var/log/syslog.*.gz

                            # Kernel ring buffer
                            dmesg -T | tail -100

Log investigation flow

Need root cause from logs
                            │
                            ├── Identify incident time window
                            │
                            ├── Read service journal
                            │       └── journalctl -u SERVICE --since TIME
                            │
                            ├── Read system warnings
                            │       └── journalctl -p warning --since TIME
                            │
                            ├── Read kernel logs
                            │       └── journalctl -k --since TIME
                            │
                            ├── Read application logs
                            │
                            ├── Correlate with deploy/update
                            │       └── apt history / deploy log
                            │
                            └── Extract first error, not last symptom

Useful grep patterns

grep -i "error" app.log
                            grep -i "permission denied" app.log
                            grep -i "connection refused" app.log
                            grep -i "no space left" /var/log/syslog
                            grep -i "killed process" /var/log/syslog
                            grep -i "failed password" /var/log/auth.log

Network debugging should be layered: IP address, route, DNS, firewall, listening port, local service response, remote response. Do not assume an application is broken until the network path is verified.

Network commands

# Interfaces
                            ip a

                            # Routes
                            ip r

                            # DNS status
                            resolvectl status

                            # DNS query
                            dig example.com
                            dig A example.com
                            dig AAAA example.com

                            # Listening ports
                            ss -lntp

                            # Connection summary
                            ss -s

                            # Firewall
                            sudo ufw status verbose

                            # Local HTTP check
                            curl -I http://localhost

                            # Public HTTP check
                            curl -I https://example.com

Network decision tree

Service unreachable
                            │
                            ├── Is service listening locally?
                            │       ├── no  -> service/config issue
                            │       └── yes
                            │
                            ├── Does local curl work?
                            │       ├── no  -> app/service issue
                            │       └── yes
                            │
                            ├── Is firewall open?
                            │       ├── no  -> UFW/cloud security group
                            │       └── yes
                            │
                            ├── Does DNS point to correct IP?
                            │       ├── no  -> DNS provider / record
                            │       └── yes
                            │
                            ├── Does remote curl reach?
                            │       ├── no  -> route/LB/firewall/provider
                            │       └── yes
                            │
                            └── Is response app error?
                            └── app logs / upstream logs

Common network symptoms

Disk problems can break everything: package installs, logs, databases, Docker, SSH, application uploads and systemd services. Always check disk early in an incident. A full / or /var often creates misleading application errors.

Disk commands

# Filesystem usage
                            df -h

                            # Inode usage
                            df -ih

                            # Top-level directory sizes
                            sudo du -xhd1 / 2>/dev/null | sort -h

                            # Common growth areas
                            sudo du -sh /var/log/*
                            sudo du -sh /var/lib/docker/* 2>/dev/null
                            sudo du -sh /var/lib/postgresql/* 2>/dev/null
                            sudo du -sh /tmp/* 2>/dev/null

                            # Mounts and disks
                            lsblk -f
                            findmnt
                            cat /etc/fstab

                            # IO statistics
                            iostat -xz 1
                            sudo iotop -o

Disk full decision tree

Disk full
                            │
                            ├── Which filesystem?
                            │       └── df -h
                            │
                            ├── Is it root or /var?
                            │       └── du -xhd1 /
                            │
                            ├── Is journal huge?
                            │       └── journalctl --disk-usage
                            │
                            ├── Are app logs huge?
                            │       └── du -sh /var/log/*
                            │
                            ├── Is Docker huge?
                            │       └── docker system df
                            │
                            ├── Is database huge?
                            │       └── do not delete manually
                            │
                            └── Prevent recurrence
                            ├── logrotate
                            ├── monitoring
                            ├── retention
                            └── resize or separate volume

Safe cleanup commands

# Clean apt cache
                            sudo apt clean

                            # Remove unused packages
                            sudo apt autoremove

                            # Show journal size
                            journalctl --disk-usage

                            # Vacuum journal by time
                            sudo journalctl --vacuum-time=7d

                            # Vacuum journal by size
                            sudo journalctl --vacuum-size=1G

                            # Docker usage
                            docker system df

                            # Docker image cleanup - use with care
                            docker image prune

Dangerous cleanup commands

Dangerous in production:
                            rm -rf /var/lib/postgresql/*
                            rm -rf /var/lib/mysql/*
                            rm -rf /var/lib/docker/volumes/*
                            docker compose down -v
                            truncate unknown database files
                            delete random files under /var/lib

                            Safer:
                            - understand owner service
                            - stop service if required
                            - backup first
                            - use native cleanup tools
                            - document action

Resource saturation explains many incidents: slow responses, timeouts, SSH lag, services killed by OOM, high load, worker backlog, database slowness and container instability. Identify whether the bottleneck is CPU, RAM, swap, IO wait or one process.

Resource commands

# CPU/load
                            uptime
                            top
                            htop
                            ps aux --sort=-%cpu | head -30

                            # Memory
                            free -h
                            ps aux --sort=-%mem | head -30
                            vmstat 1

                            # Swap
                            swapon --show

                            # OOM events
                            journalctl -k --since today | grep -i -E "oom|killed process"

                            # Per-process stats if sysstat installed
                            pidstat -u -r 1

Resource decision tree

Server slow
                            │
                            ├── Load high?
                            │       └── uptime
                            │
                            ├── CPU saturated?
                            │       ├── yes -> top, process, app profiler
                            │       └── no
                            │
                            ├── IO wait high?
                            │       ├── yes -> iostat, iotop, disk playbook
                            │       └── no
                            │
                            ├── Memory low?
                            │       ├── yes -> ps by memory, OOM logs
                            │       └── no
                            │
                            ├── Swap active?
                            │       ├── yes -> reduce workers or add RAM
                            │       └── no
                            │
                            └── App-level bottleneck
                            ├── DB query
                            ├── lock
                            ├── external API
                            ├── cache miss
                            └── queue backlog

Common resource fixes

Boot issues usually come from filesystem errors, broken /etc/fstab, failed mounts, bootloader problems, bad kernel update, disk issues or cloud volume attachment problems. Recovery may require console access, rescue mode, previous kernel or mounting the disk on another instance.

Boot diagnostics

# Current boot logs
                            journalctl -b

                            # Previous boot logs
                            journalctl -b -1

                            # Boot errors
                            journalctl -b -p err

                            # Kernel logs
                            journalctl -k -b

                            # Filesystems
                            lsblk -f
                            findmnt
                            cat /etc/fstab

                            # Failed units
                            systemctl --failed

                            # Kernel version
                            uname -a

Boot failure decision tree

Server did not come back after reboot
                            │
                            ├── Cloud or physical console available?
                            │       ├── yes -> read boot output
                            │       └── no  -> use provider recovery tools
                            │
                            ├── Reaches GRUB?
                            │       ├── yes -> try previous kernel
                            │       └── no  -> bootloader/disk issue
                            │
                            ├── Emergency mode?
                            │       ├── yes -> check fstab and mounts
                            │       └── no
                            │
                            ├── Network failed?
                            │       ├── yes -> check netplan/cloud-init
                            │       └── no
                            │
                            ├── SSH failed?
                            │       ├── yes -> ssh service/firewall/keys
                            │       └── no
                            │
                            └── Application failed after boot
                            └── systemd service playbook

fstab recovery checks

# Check fstab content
                            cat /etc/fstab

                            # Test mounts without reboot
                            sudo mount -a

                            # Show current mounts
                            findmnt

                            # Validate UUIDs
                            blkid
                            lsblk -f

Cloud recovery pattern

Broken cloud VM
                            │
                            ├── Stop instance
                            ├── Detach root volume
                            ├── Attach volume to rescue instance
                            ├── Mount filesystem
                            ├── Fix fstab/config/keys
                            ├── Unmount cleanly
                            ├── Reattach as root volume
                            └── Boot and verify

Playbook matrix

502 Nginx playbook

502 Bad Gateway
                            │
                            ├── Check Nginx config
                            │       └── sudo nginx -t
                            │
                            ├── Check Nginx logs
                            │       └── tail -100 /var/log/nginx/error.log
                            │
                            ├── Check upstream app service
                            │       └── systemctl status gunicorn
                            │
                            ├── Check upstream port/socket
                            │       └── ss -lntp
                            │
                            ├── Check app logs
                            │       └── journalctl -u gunicorn
                            │
                            └── Fix app or upstream config

SSH lockout playbook

SSH unavailable
                            │
                            ├── Is server reachable?
                            │       └── ping / cloud status checks
                            │
                            ├── Is port open externally?
                            │       └── security group / firewall
                            │
                            ├── Console access possible?
                            │       └── provider console / serial console
                            │
                            ├── Check ssh service
                            │       └── systemctl status ssh
                            │
                            ├── Check firewall
                            │       └── ufw status verbose
                            │
                            ├── Check SSH config syntax
                            │       └── sshd -t
                            │
                            ├── Check keys and user
                            │       └── authorized_keys, permissions
                            │
                            └── Restore safe access before hardening again

Disk full playbook

Disk full
                            │
                            ├── df -h
                            ├── du -xhd1 /
                            ├── du -sh /var/log/*
                            ├── journalctl --disk-usage
                            ├── docker system df
                            ├── apt clean
                            ├── journalctl --vacuum-time=7d
                            ├── prune Docker carefully if applicable
                            ├── resize volume if needed
                            └── add monitoring and retention

Post-incident actions

After restoration:
                            [ ] Confirm user-visible service is healthy
                            [ ] Confirm logs are clean
                            [ ] Confirm monitoring is green
                            [ ] Record exact root cause
                            [ ] Record commands executed
                            [ ] Record rollback option used or not used
                            [ ] Add missing alert
                            [ ] Add missing dashboard panel
                            [ ] Add missing runbook step
                            [ ] Schedule permanent fix

Command cheat sheet

# Host
                            hostnamectl
                            uptime
                            who
                            w
                            last reboot | head

                            # Services
                            systemctl status SERVICE
                            systemctl --failed
                            systemctl cat SERVICE
                            journalctl -u SERVICE --since "30 min ago"
                            journalctl -u SERVICE -f

                            # Logs
                            journalctl -xe
                            journalctl -p warning --since today
                            journalctl -k --since today
                            tail -100 /var/log/syslog
                            tail -100 /var/log/auth.log

                            # Network
                            ip a
                            ip r
                            ss -lntp
                            ss -s
                            resolvectl status
                            dig example.com
                            curl -I http://localhost
                            ufw status verbose

                            # Disk
                            df -h
                            df -ih
                            du -xhd1 /
                            lsblk -f
                            findmnt
                            journalctl --disk-usage

                            # Resources
                            free -h
                            top
                            ps aux --sort=-%cpu | head
                            ps aux --sort=-%mem | head
                            vmstat 1
                            iostat -xz 1

Final troubleshooting checklist

[ ] Symptom is precisely described
                            [ ] Incident start time is known
                            [ ] Scope is known
                            [ ] Host health is checked
                            [ ] Disk usage is checked
                            [ ] Memory and CPU are checked
                            [ ] Failed systemd units are checked
                            [ ] Relevant service logs are read
                            [ ] Kernel logs are checked if needed
                            [ ] Network path is verified
                            [ ] DNS is verified
                            [ ] Firewall is verified
                            [ ] Listening ports are verified
                            [ ] Recent deploys are checked
                            [ ] Recent apt updates are checked
                            [ ] Fix is minimal and reversible
                            [ ] Service health is verified after fix
                            [ ] Postmortem notes are written
                            [ ] Preventive action is created

Final rule

Minimal incident report template

Incident report:
                            - title
                            - start time
                            - detection method
                            - impacted service
                            - user impact
                            - root cause
                            - immediate fix
                            - commands executed
                            - rollback used
                            - prevention action
                            - owner
                            - deadline

Host and OS

# Host and OS summary
                            hostnamectl

                            # Ubuntu release metadata
                            cat /etc/os-release
                            lsb_release -a

                            # Kernel
                            uname -a

                            # Architecture
                            dpkg --print-architecture

                            # Boot and uptime
                            uptime
                            last reboot | head

                            # Current users
                            who
                            w

Processes

# Interactive process view
                            top
                            htop

                            # Top CPU processes
                            ps aux --sort=-%cpu | head -30

                            # Top memory processes
                            ps aux --sort=-%mem | head -30

                            # Process tree
                            pstree -ap

                            # Find process
                            pgrep -af nginx

                            # Open files by process
                            sudo lsof -p PID

Users and groups

# Current identity
                            whoami
                            id

                            # User identity
                            id deploy
                            groups deploy

                            # Create user
                            sudo adduser deploy

                            # Add sudo rights
                            sudo usermod -aG sudo deploy

                            # Show sudo group
                            getent group sudo

                            # Show shell users
                            grep -E "/bin/bash|/bin/sh|/usr/bin/zsh" /etc/passwd

                            # Lock user password
                            sudo passwd -l username

Permissions

# File permissions
                            ls -lah /srv/app

                            # Path permissions
                            namei -l /srv/app/current/.env

                            # Change owner
                            sudo chown deploy:www-data file

                            # Recursive owner change
                            sudo chown -R deploy:www-data /srv/app

                            # File mode
                            chmod 644 file

                            # Directory mode
                            chmod 755 directory

                            # Secret file mode
                            chmod 600 secret.key

APT essentials

# Refresh package metadata
                            sudo apt update

                            # Show upgradeable packages
                            apt list --upgradable

                            # Upgrade packages
                            sudo apt upgrade

                            # Full dependency-aware upgrade
                            sudo apt full-upgrade

                            # Install package
                            sudo apt install PACKAGE

                            # Remove package, keep config
                            sudo apt remove PACKAGE

                            # Remove package and config
                            sudo apt purge PACKAGE

                            # Remove unused dependencies
                            sudo apt autoremove

                            # Clean package cache
                            sudo apt clean

Package inspection

# Search package
                            apt search nginx

                            # Package details
                            apt show nginx

                            # Installed and candidate version
                            apt policy nginx

                            # Installed packages
                            dpkg -l | grep nginx

                            # Files installed by package
                            dpkg -L nginx

                            # Package owning a file
                            dpkg -S /usr/sbin/nginx

                            # Available versions
                            apt-cache madison nginx

Repositories and history

# Source files
                            cat /etc/apt/sources.list
                            ls -lah /etc/apt/sources.list.d/

                            # Search repo lines
                            grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

                            # APT history
                            less /var/log/apt/history.log

                            # APT terminal logs
                            less /var/log/apt/term.log

                            # Held packages
                            apt-mark showhold

                            # Hold package
                            sudo apt-mark hold PACKAGE

                            # Unhold package
                            sudo apt-mark unhold PACKAGE

Package repair

# Finish interrupted dpkg operation
                            sudo dpkg --configure -a

                            # Fix broken dependencies
                            sudo apt -f install

                            # Check locks safely
                            ps aux | grep -E 'apt|dpkg'

                            # Re-run metadata refresh
                            sudo apt update

Update safety

# Reboot required?
                            test -f /var/run/reboot-required && cat /var/run/reboot-required

                            # Packages requiring reboot if present
                            cat /var/run/reboot-required.pkgs 2>/dev/null

                            # Security automation
                            sudo apt install unattended-upgrades
                            sudo dpkg-reconfigure unattended-upgrades

Service commands

# Service status
                            systemctl status SERVICE

                            # Start / stop / restart
                            sudo systemctl start SERVICE
                            sudo systemctl stop SERVICE
                            sudo systemctl restart SERVICE

                            # Reload config if supported
                            sudo systemctl reload SERVICE

                            # Enable / disable at boot
                            sudo systemctl enable SERVICE
                            sudo systemctl disable SERVICE

                            # Is active / enabled?
                            systemctl is-active SERVICE
                            systemctl is-enabled SERVICE

                            # Failed units
                            systemctl --failed

                            # Reset failed state
                            sudo systemctl reset-failed SERVICE

Unit inspection

# Show unit file
                            systemctl cat SERVICE

                            # Show runtime properties
                            systemctl show SERVICE | less

                            # Show service logs
                            journalctl -u SERVICE --since "1 hour ago"

                            # Follow logs
                            journalctl -u SERVICE -f

                            # Reload unit files after edit
                            sudo systemctl daemon-reload

Service failure flow