Configure Ubuntu Skill

Purpose

This skill provides guidance for configuring Ubuntu LTS servers via cloud-init automation for any cloud platform (AWS, Azure, GCP, DigitalOcean, etc.).

Note: All examples in this skill currently use Ubuntu 24.04 LTS. Update version-specific package names or paths as needed for other LTS releases.

When to Use This Skill

Use this skill when:

• Writing cloud-init YAML for VM provisioning
• Configuring systemd services
• Setting up nginx reverse proxies
• Troubleshooting cloud-init or systemd issues
• Setting file permissions for service users

Reference Selection Guide

Choose the appropriate reference based on your task:

references/examples/*.yaml

references/cloud-init-patterns.md

references/systemd-patterns.md

references/common-pitfalls.md

Ready-to-Use Examples

references/examples/bastion.yaml

references/examples/proxy-http.yaml

references/examples/proxy-https.yaml

references/examples/proxy-https-letsencrypt.yaml

references/examples/static-files.yaml

references/examples/flask.yaml

references/examples/nodejs.yaml

references/examples/java.yaml

references/examples/dotnet.yaml

HTTPS Options:

• Use

  proxy-http.yaml

  by default (no SSL)
• Use

  proxy-https.yaml

  for self-signed certificates (development/internal)
• Use

  proxy-https-letsencrypt.yaml

  for trusted certificates (requires domain name)

When to Read Multiple References

• New VM setup: Start with relevant example, then cloud-init-patterns.md for customization
• Service won't start: common-pitfalls.md + systemd-patterns.md
• SSH access broken: common-pitfalls.md (Issue #1)
• Permission denied errors: common-pitfalls.md (Issues #4, #5, #6)
• Scheduled tasks: systemd-patterns.md (Systemd Timers section)
• Production HTTPS: proxy-https-letsencrypt.yaml (requires domain name)
• Static website: static-files.yaml + proxy-http.yaml (if reverse proxy needed)

Critical Rules (Memorize These)

These rules prevent the most common failures:

1. NEVER use

   users:

   directive in cloud-init — Deletes default SSH user, breaks access
2. Systemd: NO inline comments —

   After=network.target # comment

   fails
3. Permissions as quoted strings — Use

   '0640'

   not

   0640

   in cloud-init
4. Wait for cloud-init — Takes 2-3 minutes; don't deploy until done
5. Absolute paths in systemd — Use

   /opt/app/venv/bin/python

   not

   python

6. Fix permissions after SCP — Files copied retain local permissions

Default Choices for Vague Requests

When the request is ambiguous, use these defaults:

proxy-http.yaml

/opt/<app-name>/

/etc/<app-name>/

<app-name>

deployuser:servicegroup

Example Defaults

"Set up a web application server" → Use:

• examples/flask.yaml

  for application VM

• examples/proxy-http.yaml

  for proxy VM
• Port 5001 for Flask, port 80 for nginx

"Configure nginx" → Use:

• examples/proxy-http.yaml

  (reverse proxy, not static files)
• Unless HTTPS explicitly requested, then

  proxy-https.yaml

"Set up a secure bastion" → Use:

• examples/bastion.yaml

  (includes UFW + fail2ban)

Environment Variables Pattern

This is the standard way to handle environment variables (database credentials, API keys, connection strings) on the server.

Directory Structure

/etc/<app-name>/
└── environment      # All environment variables for the application

Setup in Cloud-init

runcmd:
  # Create config directory owned by root, readable by app group
  - mkdir -p /etc/myapp
  - chown root:myapp /etc/myapp
  - chmod 750 /etc/myapp

  # Create environment file with restricted permissions
  - touch /etc/myapp/environment
  - chown root:myapp /etc/myapp/environment
  - chmod 640 /etc/myapp/environment

Reference from systemd

[Service]
EnvironmentFile=/etc/myapp/environment

Environment File Format

# /etc/myapp/environment
DATABASE_URL=postgresql://user:password@host:5432/dbname
SECRET_KEY=your-secret-key-here
API_KEY=external-service-api-key
DEBUG=false

Why This Pattern?

root

640

/etc/

/opt/

EnvironmentFile=

Quick Reference Tables

Default SSH Users by Cloud Provider

ec2-user

ubuntu

azureuser

root

root

File Permission Patterns

Common systemctl Commands

sudo systemctl daemon-reload    # After editing service files
sudo systemctl enable myapp     # Start on boot
sudo systemctl start myapp      # Start now
sudo systemctl status myapp     # Check status
sudo journalctl -u myapp -f     # Follow logs

Cloud-init Verification

cloud-init status               # Check status
cloud-init status --wait        # Block until complete
sudo cat /var/log/cloud-init-output.log  # View logs

Reference Summaries

examples/ directory

Ready-to-use cloud-init YAML files for common server types. Copy and customize for your use case.

cloud-init-patterns.md

Reference documentation for cloud-init syntax:

• Module execution order
• Package management (

  packages

  ,

  package_update

  )
• Writing configuration files (

  write_files

  )
• Running commands (

  runcmd

  )
• Debugging and lifecycle

systemd-patterns.md

Reference documentation for systemd services:

• Service unit file structure (

  [Unit]

  ,

  [Service]

  ,

  [Install]

  )
• Service types (

  simple

  ,

  forking

  ,

  oneshot

  )
• Environment configuration
• Restart policies and resource limits
• Systemd timers (scheduled tasks, replacement for cron)
• Managing and debugging services

common-pitfalls.md

Prevention checklist and solutions for:

• Cloud-init issues (user deletion, timing)
• systemd issues (inline comments, permissions)
• File permission problems
• SSH and networking issues