DEV Community: Raafe Asad

How to Automate Daily Email Reports on Ubuntu: A Beginner’s Guide

Raafe Asad — Thu, 12 Feb 2026 11:27:50 +0000

Do you find yourself manually emailing the same files every morning?
Maybe it’s a daily sales report, a server status sheet, or data from an automated process.
Doing this by hand is tedious, error‑prone, and, let’s be honest, a waste of our talent.

Fear not, as we will build self‑monitoring email robot on Ubuntu for this exact purpose.
By the end, we’ll have a script that:

Attaches 2–3 files of any desired extension.
Emails them at exactly 9:00 AM every day.
Checks that the files actually exist before sending.
Creates a safe snapshot so that files can be updated while the script runs.
Logs everything for easy debugging.
Notifies you immediately if something fails via email.

And the best part? You’ll understand why every line is written – no black boxes, no copy‑paste without comprehension.

What We’re Building – The Big Picture

Think of the system as four layers:

Scheduling – Cron wakes up the script at 9 AM (or any time of your choosing).
Preparation – The script verifies and copies the files to a temporary, isolated folder.
Sending – mutt attaches the copies and sends them via Gmail’s secure SMTP server, using Postfix as the local mail relay.
Safety net – If anything breaks, you get an alert email with clear diagnostic information.

Let’s build it step by step.

Prerequisites

An Ubuntu machine (20.04 or 22.04 or any modern version)
A Gmail account (free) with 2‑Step Verification enabled and an App Password generated.
Basic knowledge of bash terminal.

Step 1: Install and Configure Postfix to Relay Through Gmail

Postfix is the engine that actually delivers email from your server to the outside world. By default it only delivers mail to local users. FOr our use-case, we need to teach it to use Gmail as a smart relay for sending emails over the internet.

1.1 Install the packages

sudo apt update
sudo apt install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

During installation, select Internet Site and use your machine’s hostname (ubuntu-server, mylaptop, etc.) when asked.

1.2 Tell Postfix to use Gmail’s SMTP server

Edit the main configuration file:

sudo nano /etc/postfix/main.cf

Add these lines at the very end:

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_use_tls = yes
inet_protocols = ipv4

Why this matters:

relayhost tells Postfix: “Don’t try to deliver directly. Send everything through Gmail’s server on port 587.”

The SASL lines enable authentication – Gmail won’t accept mail from strangers.

inet_protocols = ipv4 avoids IPv6 connection problems (common on many servers).

1.3 Store your Gmail App Password securely

Create the file /etc/postfix/sasl_passwd:

sudo nano /etc/postfix/sasl_passwd

Add exactly one line:

[smtp.gmail.com]:587 your.email@gmail.com:your-16-digit-app-password

Now secure it and build the indexed database that Postfix reads:

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

Why chmod 600? This file contains a plain‑text password – we must ensure only root can read it.

1.4 Reload Postfix and test

sudo systemctl reload postfix

Test with a simple email:

echo "Postfix can talk to Gmail!" | mail -s "Test from Ubuntu" <your_email>@gmail.com

Check your inbox (and spam folder). If it arrives, you’ve successfully turned your Ubuntu machine into an email sender.

No email? Check /var/log/mail.log by typing sudo tail -f /var/log/mail.log. The error message is always there and usually very specific.

Step 2: Install `mutt` – Because `mail` Can’t Handle Attachments Well

The basic mail command we just used is great for text, but it struggles with attachments. mutt is a lightweight, reliable email client that handles attachments beautifully.

sudo apt install mutt

Step 3: Write the Email Script

Create a new file called send_daily_report.sh in your home directory:

nano ~/send_daily_report.sh

Now let’s build the script piece by piece. I’ll show you the final script first, then walk through each section.

#!/bin/bash

# Who gets the daily report?
RECIPIENT="manager@company.com"

# Email subject – includes today's date for clarity
SUBJECT="Daily Report - $(date '+%Y-%m-%d')"

# Plain text email body (mutt can do HTML, but plain text is simpler)
BODY="Hello,\n\nPlease find today's report files attached.\n\nBest regards,\nUbuntu Server"

# Full paths to the files you want to send – one per line
ORIGINAL_FILES=(
    "/home/<username>/<folder>/<filename1.extension>"
    "/home/<username>/<folder>/<filename2.extension>"
)

# Who should be notified if the email fails?
# Use a DIFFERENT email address than the recipient – you don't want failure alerts
# to go to the same place that might be broken!
NOTIFY_RECIPIENT="admin@example.com"
NOTIFY_SUBJECT="ALERT: Daily Report FAILED on $(hostname) - $(date '+%Y-%m-%d')"

# Where to store logs – must be writable by your user
LOG_FILE="$HOME/daily_report.log"

log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a "$LOG_FILE"
}

log_message "Starting Daily Report Job"

# --- 1. Create a unique temporary directory (staging area) ---
STAGING_DIR="/tmp/daily_report_$$_$(date +%s)"
mkdir -p "$STAGING_DIR"
if [ $? -ne 0 ]; then
    log_message "CRITICAL: Cannot create staging directory $STAGING_DIR"
    exit 1
fi
log_message "Created staging directory: $STAGING_DIR"

# --- 2. Copy files to staging, verifying each one ---
MISSING_FILES=()
COPIED_FILES=()

for file in "${ORIGINAL_FILES[@]}"; do
    if [ -f "$file" ]; then
        cp "$file" "$STAGING_DIR/"
        if [ $? -eq 0 ]; then
            COPIED_FILES+=("$STAGING_DIR/$(basename "$file")")
            log_message "Copied $(basename "$file") to staging."
        else
            log_message "ERROR: Failed to copy $(basename "$file")"
            MISSING_FILES+=("$file")
        fi
    else
        log_message "ERROR: File not found: $file"
        MISSING_FILES+=("$file")
    fi
done

# --- 3. If any file is missing, abort and send a notification ---
if [ ${#MISSING_FILES[@]} -ne 0 ]; then
    ERROR_MSG="Missing files: ${MISSING_FILES[*]}"
    log_message "ERROR: $ERROR_MSG"

    NOTIFY_BODY="The daily report email FAILED at $(date).\n"
    NOTIFY_BODY+="Reason: $ERROR_MSG\n"
    NOTIFY_BODY+="Host: $(hostname)\n"
    NOTIFY_BODY+="Log: $LOG_FILE"

    echo -e "$NOTIFY_BODY" | mail -s "$NOTIFY_SUBJECT" "$NOTIFY_RECIPIENT"
    log_message "Failure notification sent to $NOTIFY_RECIPIENT."

    rm -rf "$STAGING_DIR"
    exit 1
fi

# --- 4. Build the mutt command with all attachments ---
MUTT_ARGS=(-s "$SUBJECT")
for file in "${COPIED_FILES[@]}"; do
    MUTT_ARGS+=(-a "$file")
done
MUTT_ARGS+=(-- "$RECIPIENT")

# --- 5. Send the email! ---
log_message "Sending email to $RECIPIENT with ${#COPIED_FILES[@]} attachment(s)."
echo -e "$BODY" | mutt "${MUTT_ARGS[@]}"
MAIL_EXIT_CODE=$?

# --- 6. Check if sending succeeded ---
if [ $MAIL_EXIT_CODE -eq 0 ]; then
    log_message "SUCCESS: Email sent."
else
    log_message "ERROR: mutt failed with exit code $MAIL_EXIT_CODE"

    NOTIFY_BODY="The daily report email FAILED at $(date).\n"
    NOTIFY_BODY+="Reason: mutt exit code $MAIL_EXIT_CODE\n"
    NOTIFY_BODY+="Host: $(hostname)\n"
    NOTIFY_BODY+="Check log: $LOG_FILE\n"
    NOTIFY_BODY+="Postfix log: /var/log/mail.log"

    echo -e "$NOTIFY_BODY" | mail -s "$NOTIFY_SUBJECT" "$NOTIFY_RECIPIENT"
    log_message "Failure notification sent."
fi

# --- 7. Clean up temporary directory ---
rm -rf "$STAGING_DIR"
log_message "Removed staging directory."

# --- 8. Exit with appropriate status ---
if [ $MAIL_EXIT_CODE -eq 0 ]; then
    log_message "Job finished successfully\n"
    exit 0
else
    log_message "Job finished with errors\n"
    exit $MAIL_EXIT_CODE
fi

Why Each Part Is Written That Way – A Guided Tour

Configuration section

RECIPIENT="manager@company.com"
SUBJECT="Daily Report - $(date '+%Y-%m-%d')"

Using $(date '+%Y-%m-%d') in the subject makes every email uniquely identifiable by the date.

ORIGINAL_FILES=( ... )

Why an array? Because file names might contain spaces in the future. An array handles each element cleanly.

NOTIFY_RECIPIENT="admin@example.com"

Critical : The failure alert should never go to the same address as the report. If the report email fails because of a problem with that domain, your alert would also fail. Use a different email provider or at least a different address.

LOG_FILE="$HOME/daily_report.log"

Keeping logs in your home directory avoids permission headaches with system folders.

Logging function

log_message() {
    echo "$(date ...) - $1" | tee -a "$LOG_FILE"
}

tee -a writes the message both to the terminal (so you see it when testing) and appends it to the log file. Timestamps are non‑negotiable. This helps to narrow down the failure when something breaks weeks later.

Staging directory is the secret sauce

STAGING_DIR="/tmp/daily_report_$$_$(date +%s)"
mkdir -p "$STAGING_DIR"

$$ is the process ID of the script. No two runs will ever have the same PID, so this directory is unique.
$(date +%s) adds the Unix timestamp. This will be different even if two scripts run in the same second.

Why copy files at all?

Imagine the files are generated by another program. If that program overwrites a file while your email script is reading it, you might send a half‑written, corrupt file. By copying to a staging area at the very beginning, you capture a consistent snapshot. The original files can be modified, moved, or even deleted. Your email will still contain the version that existed at 9:00:00 AM.

File verification loop

if [ -f "$file" ]; then
    cp "$file" "$STAGING_DIR/"
    ...
else
    log_message "ERROR: File not found: $file"
    MISSING_FILES+=("$file")
fi

This does two checks: first that the file exists, then that the copy succeeded. Any failure is recorded.

After the loop, we check the length of the MISSING_FILES array:

if [ ${#MISSING_FILES[@]} -ne 0 ]; then

${#array[@]} gives the number of elements. If it’s not zero, something is wrong.

Why not just check exit codes inline? Because we want to report all missing files in one go, not stop at the first error.

Building the `mutt` command

MUTT_ARGS=(-s "$SUBJECT")
for file in "${COPIED_FILES[@]}"; do
    MUTT_ARGS+=(-a "$file")
done
MUTT_ARGS+=(-- "$RECIPIENT")

This creates an array of arguments.

-s sets the subject.

-a is repeated for each attachment.

-- signals the end of options. The recipient comes after the end of options.

Then we execute:

echo -e "$BODY" | mutt "${MUTT_ARGS[@]}"

The "${MUTT_ARGS[@]}" syntax expands each element as a properly quoted word. This is the safe way to handle multiple arguments in bash.

Exit codes and failure notification

MAIL_EXIT_CODE=$?
if [ $MAIL_EXIT_CODE -eq 0 ]; then
    ...
else
    ...
fi

Every command in Linux returns an exit code. 0 means success, anything else means failure. mutt returns 0 only if it successfully hands the message to Postfix.

If it fails, we build a detailed error body and send it via the simple mail command (which we already know works). This notification contains:

The exact error (mutt exit code).
Hostname – very useful if you run this on multiple servers.
Paths to the logs so you can investigate immediately.

Cleanup

rm -rf "$STAGING_DIR"

Never leave temporary files lying around. This line runs regardless of success or failure, thanks to its placement.

Step 4: Automate with Cron

Cron is the time‑based job scheduler in Linux. One line is all it takes. But before creating a new cron entry, make the script executable:

chmod +x /home/raafe/send_daily_report.sh

Then, open your personal crontab:

crontab -e

Add this line:

0 9 * * * /home/raafe/send_daily_report.sh

Breakdown:

0 – minute (0 = on the hour)

9 – hour (9 AM)

* * * – every day, every month, every weekday

Save and exit. Cron will now run your script every day at 9:00 AM.

Pro tip: To test quickly, use * * * * * to run every minute, then remove it once you’re confident.

Testing Your Robot

Run the script manually first:

bash ~/send_daily_report.sh

Watch the logs in real time:

tail -f ~/daily_report.log

Check the Postfix log if something goes wrong:

sudo tail -f /var/log/mail.log

You should see your test email arrive within seconds. If not, the log will tell you why; usually an authentication typo or a network issue.

What You’ve Learned

Postfix + Gmail turns your Ubuntu machine into a legitimate email sender.

mutt handles attachments reliably.

Staging directories eliminate race conditions with concurrent file writers.

Exit codes are your friends. They turn success/failure into a numeric value the script can act on.

Failure notifications make your automation self‑aware.

Cron runs it all on schedule, no human needed.

This system is now running on my own ubuntu instance, sending a daily ops report every morning at 9:00 AM sharp. It hasn’t missed a beat in months.

A Beginner's Guide to Downloading Large Files from Google Drive with Python.

Raafe Asad — Thu, 15 Jan 2026 09:45:35 +0000

Have you ever wanted to download large files from Google Drive but found the process frustrating? Browser downloads often fail for huge files (like models that are several GBs in size), and keeping track of multiple model files can be confusing. Additionally, inconsistent network bandwidth can result in cancellation of downloads altogether.

In this beginner-friendly guide, I'll walk you through a Python script that solves these problems elegantly. This tool automatically downloads large files, verifies they're complete, and helps you organize them, all with simple commands! For this guide, we'll be downloading some large AI models from Google Drive.

What You'll Need

Before we dive in, let's make sure you have the essentials:

Python installed (version 3.6 or newer)
Basic command line knowledge (don't worry, I'll guide you through it)
Google Drive links for the models you want to download

Installing Required Packages

First, you'll need to install the required packages with this simple command:

pip install gdown

The gdown library is specifically designed to download large files from Google Drive without the headaches of browser downloads.

Script Breakdown

Let's break down what this script does in simple terms:

It reads a configuration file that contains all your model details.
It checks if files already exist before downloading (saving your bandwidth).
It automatically retries failed downloads.
It verifies file integrity by checking sizes.
It gives you clean status reports.

Here's the full script:

import gdown
import os
import sys
import time
from pathlib import Path
import hashlib
import json
from typing import Dict, Optional

class GoogleDriveModelDownloader:
    def __init__(self, download_dir: str = "", config_file: str = "models_config.json"):
        self.download_dir = Path(download_dir)
        self.config_file = config_file
        self.download_dir.mkdir(exist_ok=True)

    def load_config(self) -> Dict:
        """Load models configuration from JSON file"""
        try:
            with open(self.config_file, 'r') as f:
                return json.load(f)
        except FileNotFoundError:
            print(f"Config file {self.config_file} not found!")
            return {"models": {}}
        except json.JSONDecodeError as e:
            print(f"Error parsing config file: {e}")
            return {"models": {}}

    def get_file_hash(self, filepath: Path) -> Optional[str]:
        """Calculate MD5 hash of a file"""
        if not filepath.exists():
            return None

        hash_md5 = hashlib.md5()
        with open(filepath, "rb") as f:
            for chunk in iter(lambda: f.read(4096), b""):
                hash_md5.update(chunk)
        return hash_md5.hexdigest()

    def file_exists_and_complete(self, filepath: Path, expected_size_mb: Optional[int] = None) -> bool:
        """Check if file exists and is complete"""
        if not filepath.exists():
            return False

        # Check file size if expected size is provided
        if expected_size_mb:
            file_size_mb = filepath.stat().st_size / (1024 * 1024)
            if file_size_mb < expected_size_mb * 0.95:  # Allow 5% tolerance
                print(f"File {filepath.name} exists but seems incomplete ({file_size_mb:.1f}MB vs expected {expected_size_mb}MB)")
                return False

        return True

    def download_with_retry(self, url: str, output_path: Path, max_retries: int = 3) -> bool:
        """Download file with retry logic"""
        for attempt in range(max_retries):
            try:
                print(f"Attempt {attempt + 1}/{max_retries}: Downloading to {output_path}")

                # Use gdown with fuzzy matching for large files
                gdown.download(url, str(output_path), quiet=False, fuzzy=True)

                if output_path.exists():
                    print(f"Successfully downloaded {output_path.name}")
                    return True
                else:
                    print(f"Download failed - file not found after download")

            except Exception as e:
                print(f"Download attempt {attempt + 1} failed: {str(e)}")

                if attempt < max_retries - 1:
                    wait_time = (attempt + 1) * 10  # Exponential backoff
                    print(f"Waiting {wait_time} seconds before retry...")
                    time.sleep(wait_time)
                else:
                    print(f"All {max_retries} attempts failed for {output_path.name}")

        return False

    def download_model(self, filename: str, file_id: str, description: str = "", expected_size_mb: Optional[int] = None) -> bool:
        """Download a single model file"""
        output_path = self.download_dir / filename

        # Check if file already exists and is complete
        if self.file_exists_and_complete(output_path, expected_size_mb):
            print(f"{filename} already exists and appears complete, skipping download")
            return True

        # Remove incomplete file if it exists
        if output_path.exists():
            print(f"Removing incomplete file: {filename}")
            output_path.unlink()

        print(f"\n{'='*60}")
        print(f"Downloading: {filename}")
        print(f"Description: {description}")
        if expected_size_mb:
            print(f"Expected size: {expected_size_mb} MB")
        print(f"{'='*60}")

        url = f"https://drive.google.com/uc?id={file_id}"

        start_time = time.time()
        success = self.download_with_retry(url, output_path)

        if success:
            end_time = time.time()
            duration = end_time - start_time
            file_size_mb = output_path.stat().st_size / (1024 * 1024)

            print(f"Download completed in {duration:.1f} seconds")
            print(f"File size: {file_size_mb:.1f} MB")

            # Verify file size if expected
            if expected_size_mb and abs(file_size_mb - expected_size_mb) > expected_size_mb * 0.05:
                print(f"Warning: File size differs significantly from expected size")

        return success

    def download_all_models(self, force_redownload: bool = False):
        """Download all models from configuration"""
        config = self.load_config()
        models = config.get("models", {})

        if not models:
            print("No models configured. Please edit the config file.")
            return

        print(f"Found {len(models)} models to download")
        print(f"Download directory: {self.download_dir.absolute()}")

        successful_downloads = 0
        failed_downloads = 0

        for filename, model_info in models.items():
            file_id = model_info.get("file_id", "")
            description = model_info.get("description", "")
            expected_size_mb = model_info.get("expected_size_mb")

            if not file_id or "replace_with_actual" in file_id:
                print(f"Skipping {filename} - no valid file ID configured")
                continue

            success = self.download_model(filename, file_id, description, expected_size_mb)

            if success:
                successful_downloads += 1
            else:
                failed_downloads += 1

            # Brief pause between downloads
            if successful_downloads + failed_downloads < len(models):
                time.sleep(2)

        print(f"Download Summary:")
        print(f"Successful: {successful_downloads}")
        print(f"Failed: {failed_downloads}")
        print(f"Total models: {len(models)}")


    def list_models(self):
        """List all configured models"""
        config = self.load_config()
        models = config.get("models", {})

        if not models:
            print("No models configured.")
            return

        print(f"Configured Models:")


        for filename, model_info in models.items():
            file_id = model_info.get("file_id", "")
            description = model_info.get("description", "")
            expected_size_mb = model_info.get("expected_size_mb")

            output_path = self.download_dir / filename
            status = "Downloaded" if output_path.exists() else "Not downloaded"

            print(f"File: {filename}")
            print(f"Description: {description}")
            if expected_size_mb:
                print(f"Expected size: {expected_size_mb} MB")
            print(f"Status: {status}")
            print("-" * 40)

def main():
    print("Google Drive Large Model Downloader")


    # Initialize downloader
    downloader = GoogleDriveModelDownloader()

    if len(sys.argv) > 1:
        command = sys.argv[1].lower()

        if command == "list":
            downloader.list_models()
        elif command == "download":
            downloader.download_all_models()
        elif command == "force":
            downloader.download_all_models(force_redownload=True)
        else:
            print("Unknown command. Use: list, download, or force")
    else:
        print("Usage:")
        print("  python script.py list     - List configured models")
        print("  python script.py download - Download all models")
        print("  python script.py force    - Force redownload all models")
        print("\nFirst run will create a sample config file.")

if __name__ == "__main__":
    main()

Setting Up Your Configuration

The magic of this script is in its configuration file. Create a new file called models_config.json in the same folder as your script with this structure:

{
  "models": {
    "my_model.safetensors": {
      "file_id": "1ABC123xyz...",
      "description": "My text generation model",
      "expected_size_mb": 4000
    },
    "another_model.bin": {
      "file_id": "1DEF456uvw...",
      "description": "Image processing model",
      "expected_size_mb": 2500
    }
  }
}

How to find the file_id:

Open your Google Drive share link (looks like: https://drive.google.com/file/d/FILE_ID/view?usp=sharing)
The FILE_ID part (between /d/ and /view) is what you need
Copy just that ID part into your config file

The Google Drive share link should look this:

How to Use the Script

Once you have your script and config file ready, you can use three simple commands:

1. List The Model Files

python <script_name>.py list

This will show all configured models and their download status without downloading anything.

2. Download The Model Files

python <script_name>.py download

This will download only models that aren't already present or appear incomplete.

3. Redownload Everything

python <script_name>.py force

This ignores existing files and downloads everything again (useful when files get corrupted).

How the Script Works

Let me explain some of the smart features that make this script reliable:

Smart Download Resumption

If your internet connection drops during a large download, the script automatically retries up to 3 times. It uses an "exponential backoff" strategy, waiting longer between each retry (10 seconds, then 20, then 30).

File Integrity Checking

After downloading, the script checks if the file size matches what was expected (within a 5% tolerance). This helps catch incomplete downloads that might otherwise seem successful.

Progress Feedback

Unlike many download scripts, this one gives you clear feedback:

Expected file sizes
Download duration
Success/failure status
File size verification

Troubleshooting Common Issues

Issue: "Config file not found"

Solution: The first time you run the script, create an empty models_config.json file, then run python <script_name>.py list to see instructions for setting it up.

Issue: Download fails repeatedly

Solution: Google Drive sometimes blocks too many downloads. Try:

Waiting a few hours before retrying.
Using a different network.
Breaking large downloads into smaller sessions.

Issue: Files appear incomplete despite successful download

Solution: Use the force command to redownload those specific files. Also check if your disk has enough free space.

Practical Use Case

Let's say you're working with Stable Diffusion models for AI image generation. You might have:

A base model (~4GB)
Several LoRA adapters (~150MB each)
An upscaler model (~1GB)

Instead of manually downloading each file (and risking failures on the large ones), you can configure them all in your JSON file and download them with one command!
Downloading large AI models doesn't have to be frustrating. With this script, you can reliably download, verify, and organize all your model files with minimal effort.
Remember that Google Drive has download quotas, so if you're downloading many large files, space out your downloads to avoid temporary blocks.

Happy model downloading!!!

Need help? If you run into issues or want to share how you're using this script, leave a comment below!

Cron vs. Python’s schedule: Which Should You Use for Task Automation?

Raafe Asad — Tue, 13 Jan 2026 11:18:05 +0000

We all have to deal with repetitive tasks everyday, and this can be draining on our minds. What if we could automate those boring tasks, so that we could focus on the tasks that matter? Well, there is a tool for that.

Task automation is the process of using software to perform repetitive or time-consuming tasks without manual intervention. Whether it’s backing up files, sending email reports, or capturing images from a camera, automation saves time, reduces errors, and lets you focus on more important work. With just a few lines of code and the right scheduling tool, you can set up systems that run reliably day after day, hour after hour, all on their own.

Imagine you have a security camera (or any IP camera) that streams video over your network for monitoring purposes. You want your computer to automatically take one snapshot from that camera every hour and save it as an image file.

There are two popular ways to do this in Python:

Option 1: Use a tool called cron (a built-in scheduler in Linux).
Option 2: Use a Python library called schedule to run your code inside a long-running script.

Both can work, but one is usually better for this kind of task. Let’s break it down in simple terms.

What Are We Trying to Do?

Connect to a camera using its RTSP address (like a web link for video streams).
Grab one single image.
Save it with a timestamp (e.g., image_20260112_140000.jpg).
Do this once every hour, automatically, without you having to press a button.

Shouldn't be that hard, but how you schedule it matters!

Option 1: Use Cron (The System Timer)

Cron is a built-in feature in Linux (and macOS) that can run any command or script at specific times, just like scheduling an alarm, but for your computer. Technically, a cron job is a scheduled task executed automatically by the cron daemon (crond) on Unix-like operating systems (such as Ubuntu/Linux). It allows users to automate the execution of scripts, commands, or programs at predefined times or intervals, based on a configuration known as a crontab (short for cron table).

How It Works

Let's look the syntax for creating a cronjob:

┌───────────── minute (0–59)
│ ┌──────────── hour (0–23)
│ │ ┌──────────── day of month (1–31)
│ │ │ ┌──────────── month (1–12)
│ │ │ │ ┌──────────── day of week (0–6, where 0 = Sunday)
│ │ │ │ │
* * * * * command_to_execute

To create a cronjob, this time specification is combined with a script (python, shell, etc.) for timely execution.

For our use-case, we will:

Write a short Python script that does one thing: connect to the camera, take a picture, and save it.
Tell cron: “Run this script every hour.”

The computer handles the rest, even if you’re not logged in.

import cv2
import os
from datetime import datetime

# Your camera's RTSP link
rtsp_url = "rtsp://username:password@192.168.1.65:554/stream"

# Folder to save images
folder = "hourly_photos"
os.makedirs(folder, exist_ok=True)

# Connect and grab one frame
cap = cv2.VideoCapture(rtsp_url)
success, frame = cap.read()
cap.release()  # Close the connection right away

if success:
    filename = f"{folder}/photo_{datetime.now().strftime('%Y%m%d_%H%M%S')}.jpg"
    cv2.imwrite(filename, frame)
    print("Photo saved:", filename)
else:
    print("Failed to get image from camera")

Setting Up Cron

Open the terminal and type:

crontab -e

Then add this line to automatically invoke the script at every hour:

0 * * * * /usr/bin/python3 /home/<username>/<script_name>.py >> /home/you/photo_log.txt 2>&1

That’s it! The computer will now take a photo every hour.

Why Should It Matter?

Simple: One script, one job.
Reliable: If the script crashes one time, cron will still try again next hour.
Lightweight: Uses no memory when it’s not running.
Easy to test: Just run python3 script_name.py in the terminal to see if it works.

Option 2: Use Python’s schedule Library

This method keeps a Python program running all the time. Inside that program, you tell it: “Every hour, run this function.”

import schedule
import time
import cv2
from datetime import datetime

def take_photo():
    cap = cv2.VideoCapture("rtsp://...")
    success, frame = cap.read()
    cap.release()
    if success:
        cv2.imwrite(f"photo_{datetime.now().strftime('%Y%m%d_%H%M%S')}.jpg", frame)

# Schedule the job
schedule.every().hour.do(take_photo)

# Keep the program running forever
while True:
    schedule.run_pending()
    time.sleep(60)

Why This Can Be Tricky

The script must stay running 24/7. If your computer restarts or the script crashes, it stops working, unless you add extra tools to restart it.
It uses a little bit of memory and CPU even when doing nothing.
Debugging is harder: if something goes wrong at 3 AM, you might not know unless you set up logging.
For a task that only runs once an hour, keeping a program alive the whole time is like leaving your car engine running all day just to drive one minute every hour!

So… Which Should You Choose?

Situation	Best Choice
You want to take one photo per hour (or per day)	Cron
You need to take many photos per minute	Consider schedule (to avoid opening/closing the camera too often)
Your task is simple and doesn’t depend on past runs	Cron
You’re new to automation and want something easy to set up and forget	Cron

In essence, a Rule of Thumb can be established:

If your task happens less than once per minute and doesn’t need to remember anything from last time, use cron.

Final Advice

For taking hourly snapshots from a camera, cron is simpler, more reliable, and easier to manage, especially if you’re just getting started.

Save the schedule library for more complex projects where your program needs to stay awake, react in real time, or remember things between actions.

Remember, Start simple, and Automate wisely.
Happy automating!!

From Python Script to Docker Container: A Beginner's Guide (Windows + WSL2)

Raafe Asad — Tue, 09 Dec 2025 07:10:00 +0000

No prior Docker experience needed, just a Windows PC, Python, and curiosity!

What We Will Achieve in this Blog

We have a simple Python script that:

Loads an image,
Boosts its contrast using the Pillow library,
Saves the enhanced version.

We want to dockerize it — that is, package it into a self-contained, portable “container” that runs anywhere (a laptop, a colleague’s machine, the cloud), without worrying about Python versions or missing libraries.

And we’re on Windows, using Docker Desktop and WSL 2 — the recommended setup for modern Docker development on Windows.

Let's deep dive into a step by step guide on dockerizing the python script.

Part 1: The Python Script

Here is a clean and straightforward script for image enhancement:

from PIL import Image, ImageEnhance
import sys
import os

def enhance_image(input_path: str, output_path: str):
    img = Image.open(input_path)
    enhancer = ImageEnhance.Contrast(img)
    img_enhanced = enhancer.enhance(1.5)  # 50% more contrast
    img_enhanced.save(output_path)
    print(f"Processed {input_path} → {output_path}")

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage: python image_enhance.py <input.jpg> <output.jpg>")
        sys.exit(1)
    enhance_image(sys.argv[1], sys.argv[2])

It uses command-line arguments for the sake of removing hard-coded filepaths for input and output folders. In addition, it only needs Pillow, and does not require any heavy dependencies. This setup is ideal for our use case.

Part 2: Dockerizing the Script in 3 Files

Create a new folder (eg., image_enhancement) and add these three files:

requirements.txt

Pillow==10.4.0

The requirements file tells Docker which python packages to install. It is better if we specify the version of the required libraries for coherence.

Dockerfile

This Dockerfile defines a secure, efficient, and well-structured environment for running the Python script. Let's look at a breakdown of what a typical Dockerfile structure for Python looks like:

# Stage 1: Define the base image
FROM python:3.11-slim

# Stage 2: Set the working directory
WORKDIR /app

# Stage 3: Copy dependency files (if any)
COPY requirements.txt .

# Stage 4: Install dependencies (if any)
RUN pip install --no-cache-dir -r requirements.txt

# Stage 5: Copy the application script
COPY your_script.py .

# Stage 6: Command to run the application
CMD ["python", "your_script.py"]

Here's what each instruction does:

FROM -> Specifies the base image for our container. It's the starting point that includes the necessary operating system and software.
WORKDIR -> Sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, or ADD instructions. All file paths will be relative to this directory.
COPY -> Copies files from our local build context, i.e., the directory where the Dockerfile is located, into the container's filesystem at the WORKDIR.
RUN -> Executes any commands in a new layer on top of the current image. This is typically used for installing packages or setting up the environment.
CMD -> Provides defaults for an executing container. This is the command that runs when the container starts. Only the last CMD instruction in a Dockerfile will take effect.

For our use case, this Dockerfile is created:

# Stage 1: Build Image
FROM python:3.12-slim AS base

# Non-root user for security compliance
RUN useradd --create-home appuser && chown -R appuser:appuser /home/appuser
WORKDIR /home/appuser
USER appuser

# Copy requirements for better layer caching
COPY requirements.txt .
RUN pip install --no-cache-dir --disable-pip-version-check -r requirements.txt

# Copy the script
COPY image_enhance.py .

# Set entrypoint as a list form + CMD to accept args
ENTRYPOINT ["python", "image_enhance.py"]
# CMD will be overridden by docker run args — so leave empty or set defaults
CMD ["--help"]

You may note that some addtional instructions have been passed in our use case. So, here is a breakdown of why they were included in the Dockerfile:

FROM python:3.12-slim AS base -> Uses a small, production-ready base image that includes Python 3.12, minimizing the final image size.
RUN useradd --create-home appuser && chown -R appuser:appuser /home/appuser -> Creates a dedicated, non-root user named appuser and sets up a home directory. This is a crucial security best practice to prevent potential compromises from running the application as the powerful root user.
WORKDIR /home/appuser -> Sets the working directory to the new user's home directory.
USER appuser -> Switches the context so all subsequent commands (COPY, RUN, ENTRYPOINT, CMD) are executed as the non-root appuser.
COPY requirements.txt . -> Copies the file listing external Python packages into the container.
RUN pip install --no-cache-dir --disable-pip-version-check -r requirements.txt -> Installs all dependencies listed in requirements.txt using pip. The --no-cache-dir option reduces the final image size by discarding cached installation files.
COPY image_enhance.py . -> Copies te main Python script into the working directory.
ENTRYPOINT ["python", "image_enhance.py"] -> This sets the main executable for the container. The list form ensures that the Python interpreter is executed directly. Crucially, it makes the container behave like an executable command.
CMD ["--help"] -> This sets the default arguments to be passed to the ENTRYPOINT.

Combined Execution Logic

On running the container without any arguments, the full command executed is:

python image_enhance.py --help

Part 3: Building the Container

To build the container image, Open PowerShell or Command Prompt, go the project folder, and run:

docker build -t image-enhancer .

This command instructs Docker to download Python, install Pillow, and package the script. When it finishes, a read-to-run container image called image-enhancer has been built.

If we are to type docker images in the terminal, it will list all the container images. You should see image-enhancer there.

Part 4: Running it with Real Files

The project directory (from which you built the docker image) should look like this:

image_enhancer/
├── input/
│   └── chicken.jpg     ← put any image here
├── output/             ← leave this empty
├── image_enhance.py
├── requirements.txt
└── Dockerfile

In this directory, open PowerShell or Command Prompt, and run the container by:

docker run --rm `
  -v "${PWD}/input:/input:ro" `
  -v "${PWD}/output:/output" `
  image-enhancer `
  /input/chicken.jpg /output/chicken_enhanced.jpg

On running this command, you will see:

Processed /input/chicken.jpg → /output/chicken_enhanced.jpg

These commands look complicated at the first attempt, so let's unravel what we just typed in the terminal:

docker run -> This is the core command for executing anything in a new container. A docker container cannot be executed without these commands.
--rm -> This is a flag to automatically remove the container filesystem when the container exists. Usually, a docker container acquires more volume than expected, so, adding this flag in the command keeps the system clean after execution.
\ -> This is added for line continuation. This is primarily used in shells to break a long command into multiple lines for readability.
-v "${PWD}/input:/input:ro" -> This command mounts the local machine's ${PWD}/input directory (where ${PWD} is the current working directory) to the container's /input directory. the :ro (read-only) flag ensures the container cannot accidentally modify the original input files.
-v "${PWD}/output:/output" -> This mounts the local machine's ${PWD}/outputdirectory to the container's /output directory. The container will write its results (the enhanced images) here.
image-enhancer -> This specifies the Docker image to use for running the container. This is the image we built from the Dockerfile.
/input/chicken.jpg -> This is the first container argument passed to the container's ENTRYPOINT (python image_enhance.py). It tells the script which file inside the mounted input directory to process.
/output/chicken_enhanced.jpg -> this is the second argument passed to the container's ENTRYPOINT. It tells the script where to save the resulting enhanced image file inside the mounted output directory.

How Are These Commands Related to the Dockerfile

This command perfectly uses the design you saw in the Dockerfile:

ENTRYPOINT ["python", "image_enhance.py"] -> The base command executed is python image_enhance.py.

Arguments: The container arguments (/input/chicken.jpg and /output/chicken_enhanced.jpg) replace the default CMD ["--help"] and are appended to the ENTRYPOINT.

The full command executed inside the container will be:

python image_enhance.py /input/chicken.jpg /output/chicken_enhanced.jpg

This makes your containerized application behave exactly like a command-line tool running directly on your host machine.

Part 5: Fixing Any Errors in WSL2

If you tried this in WSL2 and got:

The command 'docker' could not be found in this WSL 2 distro.

Don't panic, this is a common issue in WSL2. Let's see how we can fix it:

Open Docker Desktop (from Windows Start menu).
Go to Settings → Resources → WSL Integration.
Check the box next to your Linux distro.
Click Apply & Restart.

You can verify its working by:

Open your WSL terminal and run:

docker --version
# Should print: Docker version 28.x.x…

Now you can build and run containers inside WSL — often faster and more natural for Linux-based workflows!

Next Steps (When You’re Ready)

Automate it: Write a .bat or .ps1 script to run the command with one click.
Connect a camera: Pull an image via HTTP, enhance it, save it — all automated.
Batch process: Modify the script to enhance all images in a folder.
Tweak contrast: Add a --contrast 2.0 flag using argparse.

Key Takeaways

Portability -> Share your tool with teammates, no “but it works on my machine!”
Reproducibility -> Exact Python/Pillow versions — no surprises.
Isolation -> Your system stays clean; no global pip installs.
Scalability -> Later, deploy the same container to servers or cloud.

Containers might seem intimidating at first, but as you’ve seen, dockerizing a simple tool takes just 3 files and 2 commands. Once set up, you gain reliability, portability, and the ability to ship your code with confidence.

And with Docker Desktop + WSL 2 on Windows? You get the best of both worlds: Windows comfort and Linux power.

Happy coding, and happy enhancing!!

Free Up Your C: Drive: Move WSL2 and Docker Desktop to Another Drive

Raafe Asad — Fri, 28 Nov 2025 10:46:17 +0000

Have you ever found yourself staring at a nearly full C: drive while your spacious secondary drive sits idle, waiting for your precious data to be stored? If you are running WSL2 with Ubuntu and Docker Desktop for development, this is a very common pain point. Let me walk you through how I freed up 40 GB+ on my system drive by relocating these utilities to my secondary drive.

You may ask, Why Does Any of This Matter?

The answer lies in the fact that WSL2 stores virtual hard disk files with a .vhdx extension. This virtual disk grows significantly as Docker containers and Machine Learning workloads accumulate. Docker Desktop compounds this by creating its own hidden WSL distributions. Relocating these distributions to a larger drive not only frees up system space, but also improves overall system performance, as the Operating System has more room to breathe.

Let's look at how to relocate these files.

Step 1: Relocate Your Ubuntu WSL Distribution

First, let's move your primary Ubuntu Installation:

Open Powershell and type:

# Shutdown all WSL instances
wsl --shutdown

# Export your Ubuntu distribution to a backup file on your secondary drive
wsl --export Ubuntu <Secondary_Drive_Name>:\WSL\ubuntu.tar

# Unregister the current distribution. This frees up space on your C: drive
wsl --unregister Ubuntu

# Import it to the new location on secondary drive
wsl --import Ubuntu <Secondary_Drive_Name>:\WSL\Ubuntu <Secondary_Drive_Name>:\WSL\ubuntu.tar --version 2

# Set your default user (find your username with: wsl -d Ubuntu cat /etc/passwd)
ubuntu config --default-user <yourusername>

You may see these text prompts after typing the commands:

Step 2: Move Docker Desktop Data

Docker Desktop is a tricky case as it manages its internal WSL distributions. Instead of exploring those distributions and struggling with their relocation, a cleaner approach is recommended:

1. Stop Docker Desktop completely (right-click system tray icon -> Quit)

2. Shutdown WSL by typing this command in Powershell:

wsl --shutdown

3. Move the Docker data folder:

# Create new directory on E: drive
mkdir <Secondary_Drive_Name>:\WSL\Docker

# Move Docker's WSL data
Move-Item "C:\Users\<YourUsername>\AppData\Local\Docker\wsl" "<Secondary_Drive_Name>:\WSL\Docker\wsl"

4. Update Docker Desktop Settings

Open Docker Desktop
Go to Settings -> Resources -> Advanced
Change Disk Image Location to <Secondary_Drive_Name>:\WSL\Docker\wsl
Click Apply & Restart

Step 3: Clean Up Leftover Files

After moving everything, clean up the leftover files to recover the used space. This can be done by removing the temporary ubuntu.tar file created during the export process. This file should be located in:
<Secondary_Drive_Name>:\WSL\ubuntu.tar

Bonus Step: Verify GPU access in Ubuntu terminal

If your system has an Nvidia GPU, you can verify its access in the Ubuntu terminal.

nvidia-smi

If this appears as a result of this command, Congratulations!
You have successfully relocated WSL Ubuntu in your secondary drive without altering any configuration whatsoever. This is because GPU acceleration works perfectly after relocation because Nvidia drivers remain on your Windows system while only the data moves.

Final Thoughts

Moving WSL2 and Docker to another drive is a game-changer for developers with limited system drive space. The process takes about 15 minutes but can free up dozens of gigabytes. Best of all, your development environment remains completely intact—no need to reinstall packages or rebuild containers.

Remember: Always backup important data before moving system files, and test your critical workflows after migration.

Till then, Happy Coding!!

Digital Zoom vs. Cropping: Are They the Same Thing?

Raafe Asad — Mon, 17 Nov 2025 08:52:07 +0000

If you have ever zoomed in on a photo on your phone and noticed it gets blurry, or tried simulating "zoom" in code by slicing an image, you may have wondered: Is digital zoom just cropping? Let's unpack this.

So, What is Digital Zoom?

Zooming simply means enlarging a picture in a way such that the details in the image become clear and visible to see. In essence, zooming in lets you see the details more clearly. It does not involve any moving optics. Internally, it usually does two things:

Crops a region of interest (ROI) from the center (or target area) of the full resolution sensor image.
Upscales that cropped region to match the original resolution (eg., via interpolation: bilinear, bicubic, Lanczos, etc.)

What does this result in?

Same pixel count as the original image - but with less real information. Upscaling cannot reconstruct the lost details by cropping.

Check out this code snippet that demonstrates the zooming in concept.

from PIL import Image

def zoom_image(input_path, output_path, zoom_factor, center_x=0.5, center_y=0.5):
    img = Image.open(input_path)

    # Calculate the crop box (the area we want to zoom in)
    crop_width = img.width / zoom_factor
    crop_height = img.height / zoom_factor
    left = int(center_x * img.width - crop_width / 2)
    top = int(center_y * img.height - crop_height / 2)

    # Crop and resize back to original dimensions
    cropped = img.crop((left, top, left + crop_width, top + crop_height))
    zoomed_img = cropped.resize((img.width, img.height), Image.Resampling.LANCZOS)
    zoomed_img.save(output_path)

You may ask, What is Cropping then?

Cropping simply selects a region of the image without resizing. As a result, you get fewer pixels, but every pixel is real sensor data. In essence, cropping is cutting off the parts you don't want in the image. Cropping is lossless in terms of pixel fidelity, i.e., just fewer pixels.

Let's look at what cropping an image in concept with this code:

from PIL import Image

def crop_image(input_path, output_path, left, top, right, bottom):

    with Image.open(input_path) as img:
        # Define the crop box: (left, upper, right, lower)
        # Note: (0, 0) is the top-left corner
        cropped_img = img.crop((left, top, right, bottom))

        # Save or display the result
        cropped_img.save(output_path)

So, what are the key differences at a glance?

Feature	Digital Zoom	Cropping
Output size	Same as input (upscaled)	Smaller (native resolution)
Details	Reduced (because of interpolation)	Preserved (no interpolation)
Use case	Live preview, thumbnails	Post-processing, analysis
Reversible	No (pixel information lost in upscaling)	Yes (if we keep the original image)

Let's look at the differences visually.

Original Image

Zoomed Image

Cropped Image

Notice the difference in quality?
No amount of zooming can recover the detail your sensor didn't capture.
Garbage in -> Garbage out.

Hope this clears up the digital zoom vs. cropping concepts.
Remember:

Crop = keep it real (but smaller).
Digital Zoom = crop + guesswork (via upscaling).
Optical zoom = the OG.

Try the code, break it, improve it, and share what you learn.
Until next time - zoom/crop responsibly 😉!