DirectAdmin CLI database automation: challenges and solutions

CLI-based database provisioning is faster and more reliable for repetitive DirectAdmin operations, but small shell details can break automation.

Typical scenario

You are inside a customer path:

/home/user_name/public_html

And you want DB/user names based on the account prefix.

1) Common limitation of da utility

Some da versions do not support direct database creation and return:

Unknown command 'database'. Please specify one command of: admin, build, config...

In that case, use direct SQL execution via MySQL/MariaDB with DirectAdmin credential file.

2) Bash ! pitfall

Passwords containing ! may trigger history expansion:

-bash: !kL4kie: event not found

Escape it (\!) or use safe quoting strategy.

3) Inline provisioning command

One-liner example:

USER_NAME=$(pwd | cut -d'/' -f3) && mysql --defaults-extra-file=/usr/local/directadmin/conf/my.cnf -e "CREATE DATABASE IF NOT EXISTS ${USER_NAME}_db; CREATE USER IF NOT EXISTS '${USER_NAME}_user'@'localhost' IDENTIFIED BY 'MinhaSenhaComplexa\!2026'; GRANT ALL PRIVILEGES ON ${USER_NAME}_db.* TO '${USER_NAME}_user'@'localhost'; FLUSH PRIVILEGES;"

What it does

1. Extracts account name from current path.
2. Creates ${USER_NAME}_db.
3. Creates ${USER_NAME}_user.
4. Grants DB privileges.
5. Flushes privilege cache.

4) Sync with DirectAdmin panel

When DB objects are created directly in MySQL, GUI may lag behind. Trigger task queue update:

/usr/local/directadmin/dataskq

Production best practices

1. Verify extracted username before running batch automation.
2. Avoid exposing root credentials in shell history.
3. Enforce naming conventions per environment.
4. Validate scripts in staging first.

Well-designed CLI automation reduces manual errors and deployment time. Mastering Bash escaping and DirectAdmin integration gives you safe and scalable provisioning workflows.

This post is licensed under CC BY-NC.