Developed by Gemini

Phase 1: Packing Up (Old Server)

1. Zip the Files Navigate to your WordPress root and compress all files:

Bash

tar -czvf site_backup.tar.gz .

2. Export the Database Create a snapshot of your current database:

Bash

mysqldump -u [old_db_user] -p [old_db_name] > database_backup.sql

Transfer both site_backup.tar.gz and database_backup.sql to your Raspberry Pi.

---

Phase 2: Preparing the New Home (Raspberry Pi)

3. Create the Database and User Log into MariaDB on your Pi:

Bash

sudo mariadb -u root -p

Run these commands (replace placeholders with your choices):

SQL

CREATE DATABASE dummy_db;
CREATE USER 'dummy_user'@'localhost' IDENTIFIED BY 'STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON dummy_db.* TO 'dummy_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

4. Deploy Files & Adjust Permissions Create the folder structure and extract your backup:

Bash

sudo mkdir -p /var/www/yourdomain.com/public_html
sudo tar -xzvf site_backup.tar.gz -C /var/www/yourdomain.com/public_html

Now, fix the ownership so the Apache web server (www-data) can manage the files:

Bash

sudo chown -R www-data:www-data /var/www/yourdomain.com
sudo find /var/www/yourdomain.com -type d -exec chmod 755 {} \;
sudo find /var/www/yourdomain.com -type f -exec chmod 644 {} \;

5. Update wp-config.php Edit the configuration to match your new database credentials:

Bash

sudo nano /var/www/yourdomain.com/public_html/wp-config.php

Update DB_NAME (dummy_db), DB_USER (dummy_user), and DB_PASSWORD.

---

Phase 3: Web Server & Security

6. Apache Configuration Create a new Virtual Host file:

Bash

sudo nano /etc/apache2/sites-available/yourdomain.conf

Paste this configuration:

Apache

<VirtualHost *:80>
    ServerName yourdomain.com
    DocumentRoot /var/www/yourdomain.com/public_html

    <Directory /var/www/yourdomain.com/public_html>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/mysite_error.log
    CustomLog ${APACHE_LOG_DIR}/mysite_access.log combined
</VirtualHost>

Enable the site and reload Apache:

Bash

sudo a2ensite yourdomain.conf
sudo systemctl reload apache2

7. Secure with Let’s Encrypt Request your SSL certificate:

Bash

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d yourdomain.com

---

Phase 4: Path & URL Synchronization

8. Import the Database Import your SQL file into the new database:

Bash

mysql -u dummy_user -p dummy_db < database_backup.sql

9. Update File Paths and URLs This step is critical. WordPress stores absolute file paths (e.g., /home/olduser/public_html) and URLs in the database. If these aren’t updated to your Pi’s path (/var/www/yourdomain.com/public_html), your site will crash.

Using WP-CLI (The most reliable way):

Bash

cd /var/www/yourdomain.com/public_html

# Update the Domain URL
wp search-replace 'https://old-domain.com' 'https://yourdomain.com' --allow-root

# Update the System File Path
# Replace '/old/path/to/site' with the path from your old server
wp search-replace '/old/path/to/site' '/var/www/yourdomain.com/public_html' --allow-root

---

Introduction

Task automation is a fundamental responsibility of any Linux system administrator. One of the most powerful and widely used tools for scheduling tasks is cron.

In this guide, you will learn:

• How to verify if cron is installed and running
• How to list existing cron jobs
• How to create a Bash script
• How to set proper permissions
• How to schedule it safely using cron

We’ll use a real-world example: deleting log files older than 120 days from /var/log.

---

1️⃣ Check if Cron is Installed

Most Linux distributions use:

• cron (Debian/Ubuntu)
• cronie (RHEL/CentOS/Alma)

Check if cron exists:

which cron

Or:

rpm -qa | grep cron

On Debian-based systems:

dpkg -l | grep cron

---

2️⃣ Check if Cron Service is Running

On modern systems using systemd:

systemctl status cron

Or on RHEL-based systems:

systemctl status crond

You should see:

Active: active (running)

If not running:

sudo systemctl start cron
sudo systemctl enable cron

Cron is now persistent across reboots.

---

3️⃣ List Existing Cron Jobs

List Current User Cron Jobs

crontab -l

List Another User’s Cron Jobs

sudo crontab -u username -l

System-wide Cron Locations

Check:

cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/

These directories are commonly used for system-level scheduled tasks.

---

4️⃣ Create a Bash Script to Delete Old Log Files

Now we create a practical script.

Create the file:

sudo nano /usr/local/bin/cleanup_logs.sh

Add the following content:

#!/bin/bashLOG_DIR="/var/log"
RETENTION_DAYS=120echo "Starting log cleanup: $(date)"find "$LOG_DIR" -type f -mtime +$RETENTION_DAYS -exec rm -f {} \;echo "Cleanup finished: $(date)"

Save and exit.

---

5️⃣ Set Proper Permissions (Critical Step)

This is where many people fail.

Check current permissions:

ls -l /usr/local/bin/cleanup_logs.sh

Make it executable:

sudo chmod 750 /usr/local/bin/cleanup_logs.sh

Set ownership to root:

sudo chown root:root /usr/local/bin/cleanup_logs.sh

Now verify:

ls -l /usr/local/bin/cleanup_logs.sh

You should see something like:

-rwxr-x--- 1 root root

Why this matters:

• Only root can modify it
• Only root and group can execute it
• Prevents privilege escalation risks

---

6️⃣ Test the Script Manually

Always test before scheduling:

sudo /usr/local/bin/cleanup_logs.sh

If no errors appear, proceed.

---

7️⃣ Add Script to Cron

Edit root crontab:

sudo crontab -e

Add this line to run daily at 02:30 AM:

30 2 * * * /usr/local/bin/cleanup_logs.sh >> /var/log/cleanup_logs.log 2>&1

Explanation:

┌──────── minute (30)
│ ┌────── hour (2)
│ │ ┌──── day of month (*)
│ │ │ ┌── month (*)
│ │ │ │ ┌ day of week (*)
│ │ │ │ │
30 2 * * * command

This will:

• Run daily at 02:30
• Redirect output to a log file
• Capture errors (2>&1)

---

8️⃣ Verify Cron is Executing

Check logs:

On Debian/Ubuntu:

grep CRON /var/log/syslog

On RHEL-based systems:

grep CROND /var/log/cron

---

⚠️ Important Production Advice

Blind deletion in /var/log can be dangerous.

Safer approach:

find "$LOG_DIR" -type f -name "*.log" -mtime +$RETENTION_DAYS -exec rm -f {} \;

Even better:

• Use logrotate for managed log rotation
• Never delete application logs without validation
• Monitor disk usage with alerts

Cron is powerful — and dangerous if misused.

---

What You Learned

• How to verify cron installation
• How to check service status
• How to list user and system cron jobs
• How to write and secure a Bash script
• How to schedule tasks safely
• How to log cron output

---

Why This Matters

Automating maintenance tasks:

• Prevents disk full scenarios
• Reduces manual operations
• Improves system reliability
• Demonstrates real sysadmin maturity

Automation is not optional in production environments.