Sky
Well-Known Member
V3 е най-силната версия досега и вече личи, че е минала през реални тестове, а не само през теоретичен review. Live-verified секцията е особено ценна: вече са документирани конкретни особености на CoolIceHost при subdomains, PHP selector, DNS/MX, force_ssl, WordPress quick installer, MariaDB dump и Softaculous.
Но открих два важни логически конфликта и няколко по-малки проблема.
Но runbook-ът сам извършва множество автоматични изтривания без такава confirmation:
rm -rf "$DA_SESSION"
rm -f "$tmp"
rm -f "$CNF"
rm -f "$PROBE"
и казва да се изтрие EICAR test файлът след тест. Session cleanup конкретно е автоматичен trap с rm -rf.
Това поставя AI агента в невъзможна ситуация: най-високоприоритетното правило му забранява да изпълни собствената bootstrap логика.
Трябва изрично изключение, примерно:
Но вече е live-verified, че Softaculous изисква:
DirectAdmin account password once — SOFT_PASS
и Login Key не е достатъчен.
Това също е пряк policy конфликт.
Трябва hard rule да стане нещо от рода на:
Softaculous | cli.php probe | --list / --install | --remove ...
А §29 категорично и live-verified казва:
Това е реално опасно за AI, защото Quick Reference обикновено ще се използва като най-краткия authoritative lookup.
Трябва да стане например:
Softaculous | plugin JSON API | cookie session + index.raw?api=json | remove via act=remove
Но основната секция вече правилно казва:
Таблицата трябва да отразява modern API.
Catch-all | CMD_API_EMAIL_CATCH_ALL | same | prefer :fail:
Но основният текст казва:
За CoolIceHost-specific runbook quick reference трябва да казва:
Catch-all | probe only | normally disabled on CoolIceHost | do not enable
--data "{\"username\":\"$DA_USER\",\"password\":\"$SOFT_PASS\"}"
ще се счупи, ако password съдържа например " или \.
При password не бива да се конструира JSON чрез shell interpolation.
По-безопасно:
python3 -c 'import json,os; print(json.dumps({
"username": os.environ["DA_USER"],
"password": os.environ["SOFT_PASS"]
}))'
и output-ът да отиде към curl --data-binary @-.
Допълнителен плюс: така password не стои като част от curl command argument.
Това е реален code fix, не само hardening.
curl --user "$DA_USER:$DA_PASS"
Например wrapper-ът го използва централизирано.
Това означава Login Key да се появи временно в process arguments. За shared CageFS рискът е ограничен, но документът е доста строг по отношение на secrets.
Има два варианта:
known = {"error", "text", "details", "success", ...}
и неизвестните responses fail-ват.
Това вече бих го считал за решено.
DA_SESSION=$(mktemp -d ...)
DA_HTTP_FILE="$DA_SESSION/http"
е правилното решение и премахва проблема с два едновременни SSH/agent sessions.
Освен гореспоменатия конфликт с delete policy, реализацията ми харесва.
DUMPBIN="$(command -v mariadb-dump || command -v mysqldump)"
"$DUMPBIN" --defaults-file="$CNF"
и изрично е документирано, че на конкретната CoolIceHost MariaDB 11.8 конфигурация --defaults-extra-fileне работи както се очаква.
Точно такъв тип live verification прави документа полезен.
Това вече е много добра реализация за agent runbook. Тук нямам съществена забележка.
Това адресира предишните ми основни забележки.
Така compiled документът може да остане един, без непременно всяка задача да носи целия context.
Бих оставил това така.
Това решава голям проблем от ранните версии: примерите вече не се представят безкритично като универсални.
Единствено бих добавил към заглавието/началото:
Policy/safety: 9/10, но става 9.7 след изчистването на двата големи противоречиви правила — delete на ephemeral файлове и main password/Softaculous.
Executable examples: 9.3/10. Основният конкретен бъг, който виждам сега, е ръчно конструираният Softaculous login JSON.
CoolIceHost-specific reliability: 9.5/10. Live testing е вдигнал документа много.
Структура: 9/10.
Общо: около 9.2/10 в сегашния вид.
Преди да го приема за финален, бих оправил точно пет неща: exception за agent-created temporary deletes; exception за panel password при verified unsupported-by-Login-Key subsystem; Softaculous login JSON; Quick Reference редовете за Softaculous/Vacation/Catch-all; и explicit правило, че live-verified §30 има предимство пред generic пример при конфликт.
След това вече не виждам причина да се правят още големи архитектурни промени — следващият етап е regression/integration testing, не ново пренаписване.
Но открих два важни логически конфликта и няколко по-малки проблема.
1. Delete policy вече противоречи на самия runbook — това е най-важният проблем
Глобалното правило е абсолютно:Но runbook-ът сам извършва множество автоматични изтривания без такава confirmation:
rm -rf "$DA_SESSION"
rm -f "$tmp"
rm -f "$CNF"
rm -f "$PROBE"
и казва да се изтрие EICAR test файлът след тест. Session cleanup конкретно е автоматичен trap с rm -rf.
Това поставя AI агента в невъзможна ситуация: най-високоприоритетното правило му забранява да изпълни собствената bootstrap логика.
Трябва изрично изключение, примерно:
Това според мен е P0 policy fix.
2. Hard rule за main password противоречи на Softaculous секцията
В началото:Но вече е live-verified, че Softaculous изисква:
DirectAdmin account password once — SOFT_PASS
и Login Key не е достатъчен.
Това също е пряк policy конфликт.
Трябва hard rule да стане нещо от рода на:
Иначе правилният агент трябва да откаже Softaculous workflow-а, въпреки че самият runbook го предписва.
3. Quick Reference за Softaculous вече е грешен
В Quick Reference още пише приблизително:Softaculous | cli.php probe | --list / --install | --remove ...
А §29 категорично и live-verified казва:
Това е реално опасно за AI, защото Quick Reference обикновено ще се използва като най-краткия authoritative lookup.
Трябва да стане например:
Softaculous | plugin JSON API | cookie session + index.raw?api=json | remove via act=remove
4. Quick Reference за Vacation също е остарял
Таблицата още сочи CMD_API_EMAIL_VACATION.Но основната секция вече правилно казва:
и използва /api/emailvacation/....
Таблицата трябва да отразява modern API.
5. Quick Reference за Catch-all е подвеждащ за CoolIceHost
Там още изглежда като поддържана операция:Catch-all | CMD_API_EMAIL_CATCH_ALL | same | prefer :fail:
Но основният текст казва:
За CoolIceHost-specific runbook quick reference трябва да казва:
Catch-all | probe only | normally disabled on CoolIceHost | do not enable
6. Softaculous login JSON има реален quoting bug
Това:--data "{\"username\":\"$DA_USER\",\"password\":\"$SOFT_PASS\"}"
ще се счупи, ако password съдържа например " или \.
При password не бива да се конструира JSON чрез shell interpolation.
По-безопасно:
python3 -c 'import json,os; print(json.dumps({
"username": os.environ["DA_USER"],
"password": os.environ["SOFT_PASS"]
}))'
и output-ът да отиде към curl --data-binary @-.
Допълнителен плюс: така password не стои като част от curl command argument.
Това е реален code fix, не само hardening.
7. DirectAdmin credentials също остават в process argv
Навсякъде има:curl --user "$DA_USER:$DA_PASS"
Например wrapper-ът го използва централизирано.
Това означава Login Key да се появи временно в process arguments. За shared CageFS рискът е ограничен, но документът е доста строг по отношение на secrets.
Има два варианта:
- да използвате curl --config/temporary 600 config;
- или да го документирате като accepted residual risk, както вече е направено с WP-CLI credentials.
8.
Тук корекцията е добра. Вече не приема произволно foo=bar; има known-key validation:known = {"error", "text", "details", "success", ...}
и неизвестните responses fail-ват.
Това вече бих го считал за решено.
9. Session race condition също е решен добре
Преминаването към:DA_SESSION=$(mktemp -d ...)
DA_HTTP_FILE="$DA_SESSION/http"
е правилното решение и премахва проблема с два едновременни SSH/agent sessions.
Освен гореспоменатия конфликт с delete policy, реализацията ми харесва.
10. MariaDB корекцията е важна и вече изглежда реално grounded
Тук V3 е значително по-силен:DUMPBIN="$(command -v mariadb-dump || command -v mysqldump)"
"$DUMPBIN" --defaults-file="$CNF"
и изрично е документирано, че на конкретната CoolIceHost MariaDB 11.8 конфигурация --defaults-extra-fileне работи както се очаква.
Точно такъв тип live verification прави документа полезен.
11. ZIP workflow вече е на добро ниво
Има:- path traversal validation;
- symlink rejection;
- collision listing;
- confirmation;
- SHA-256 check между list и extract.
Това вече е много добра реализация за agent runbook. Тук нямам съществена забележка.
12. Composer секцията вече е практически завършена
Поправени са:- timestamped backups;
- conditional composer.lock;
- --update-no-dev за Composer 2.10;
- разграничението между dependency rollback и Composer-script side effects.
Това адресира предишните ми основни забележки.
13. Структурата вече е подобрена логически
Промяната:е много по-добра от старото безусловно „paste all 1700 lines“.
Така compiled документът може да остане един, без непременно всяка задача да носи целия context.
Бих оставил това така.
14. Live-verified секцията е една от най-добрите части на V3
Тя отделя „как принципно работи DirectAdmin“ от „какво реално установихме на CoolIceHost на 21.08.2026“.Това решава голям проблем от ранните версии: примерите вече не се представят безкритично като универсални.
Единствено бих добавил към заглавието/началото:
Това формализира приоритета.
Финална оценка
V3 вече бих оценил така:Policy/safety: 9/10, но става 9.7 след изчистването на двата големи противоречиви правила — delete на ephemeral файлове и main password/Softaculous.
Executable examples: 9.3/10. Основният конкретен бъг, който виждам сега, е ръчно конструираният Softaculous login JSON.
CoolIceHost-specific reliability: 9.5/10. Live testing е вдигнал документа много.
Структура: 9/10.
Общо: около 9.2/10 в сегашния вид.
Преди да го приема за финален, бих оправил точно пет неща: exception за agent-created temporary deletes; exception за panel password при verified unsupported-by-Login-Key subsystem; Softaculous login JSON; Quick Reference редовете за Softaculous/Vacation/Catch-all; и explicit правило, че live-verified §30 има предимство пред generic пример при конфликт.
След това вече не виждам причина да се правят още големи архитектурни промени — следващият етап е regression/integration testing, не ново пренаписване.
