List the scripts on your server

ls /scripts | less

Use the WHM interface where possible

Most tasks in this guide, such as adding accounts, editing quotas and managing DNS, are also available in WHM. The WHM interface checks input and shows what will change.

Before you run any script

• Read its help output, or the cPanel documentation for it.
• Take a backup, and run it on a test server first if it changes files.
• Never run a script you downloaded from an unknown source as root.

Need help? Open a ticket through @CustomerPanel.

Why scripts need care

Many cPanel and WHM scripts change files, restart services or delete data. Running one without understanding it can break a server in seconds. Before you run any script, find out what it does and whether a supported option already exists.

A checklist before you run a script

1. Find the script’s source, and confirm it comes from a trusted vendor or from cPanel itself.
2. Read it. Look for commands that delete, overwrite, change permissions or send data to another server.
3. Check whether a checksum or signature is published, and verify it.
4. Test on a staging or spare server first.
5. Take a backup, and write down how to undo the change.

Prefer the supported interface

Most tasks that scripts used to do now have an option in WHM or cPanel. The interface logs the change, checks the input and is updated with the product. Use it where you can:

• Service restarts and configuration: WHM > Service Configuration and Restart Services.
• Account tasks: WHM account functions and cPanel tools.
• Software installs: EasyApache 4 and the Software section.

Do not run unknown scripts as root

A script from a forum or a copied command can contain anything. Never paste a command you do not understand into a root shell, and never run a script that downloads and executes code from a second address without reviewing both.

What to do if a script went wrong

1. Stop the script if it is still running.
2. Check the change log and the files it touched, using your backup for comparison.
3. Restore the affected files or service configuration, and test the site.

What to look for when you read a script

• Commands that delete or move files, especially with wildcards or variables that could be empty.
• Permission changes that use recursive flags on system folders such as /usr, /etc or /var.
• Downloads that run straight into a shell, which skip your chance to read the code first.
• Requests that send passwords, keys or configuration files to another address.
• Changes to services, firewall rules or cron jobs that you did not ask for.

If you find any of these, do not run the script until you understand why it is there and who wrote it.

Keep a record of what you change

Write down the command or script you ran, the date, the reason and the files it touched. A short note in a shared document saves time when someone asks why a setting changed weeks later.

When you write your own script

• Use the least privilege you need: a regular user with sudo for one command beats a root session.
• Check the input before you use it, and quote variables so spaces and special characters do not break the command.
• Print what the script will do before it does it, and ask for confirmation before any delete or restart.
• Test on a copy of the server, and keep the script under version control.