all_post.sh depending on other _post.sh scripts?

[michael]

Hi to you all,

I have started with DirectAdmin last week and excessively testing it and finding the best way to interact with it using the API and the custom scripts.

Is there some complete list of custom scripts with their environmental variables? The file scripts.custom is very good, but there are some scripts missing. Searching the version history shows various entries, but no complete list and mainly without environmental variables specifications.

My real issue is with the all_post.sh I'm playing with at this moment.
I noticed that, when creating a new reseller, the new username is not supplied in the variables.
Since there user_create_post.sh is also possible I added that one also and noticed that the all_post.sh is now called with a lot more variabled ... now including the new username! This also happens when the user_create_post.sh script has no commands (empty).
Is this correct?
-If no, what am I doing wrong.
-If yes, why is this and are there more scripts which changes the all_post.sh environmental variables?

Example:

Only all_post.sh:
    [TERM] => dumb
    [package] => Reseller_1
    [add] => Submit
    [caller_ip] => 1.2.3.4
    [username] => michael
    [passwd2] => pass4
    [email] => [email protected]
    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin
    [action] => create
    [_] => /usr/local/directadmin/scripts/custom/all_post.sh
    [PWD] => /usr/local/directadmin
    [domain] => testres4.xyz
    [LANG] => en_US.UTF-8
    [SHLVL] => 3
    [passwd] => pass4
    [command] => /CMD_ACCOUNT_RESELLER
    [ip] => shared

With the (empty) user_create_post.sh:
    [creator] => michael 
    [spam] => ON 
    [date_created] => Tue Mar  9 13:02:33 2010 
    [account] => ON 
    [TERM] => dumb 
    [nemailml] => unlimited 
    [package] => Reseller_1 
    [add] => Submit 
    [name] => testres5 
    [aftp] => OFF 
    [domainptr] => unlimited 
    [caller_ip] => 1.2.3.4 
    [skin] => enhanced 
    [cron] => ON 
    [nsubdomains] => 0 
    [username] => michael 
    [passwd2] => pass5 
    [email] => [email protected] 
    [quota] => 1000 
    [php] => ON
    [sysinfo] => ON
    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin
    [action] => create
    [_] => /usr/local/directadmin/scripts/custom/all_post.sh
    [dnscontrol] => ON
    [PWD] => /usr/local/directadmin
    [ssl] => ON
    [ftp] => unlimited
    [domain] => testres5.xyz
    [nemailr] => unlimited
    [LANG] => en_US.UTF-8
    [nemails] => unlimited
    [ssh] => ON
    [ns2] => ns2.hostingcollectief.nl
    [docsroot] => ./data/skins/enhanced
    [ns1] => ns1.hostingcollectief.nl
    [SHLVL] => 3
    [passwd] => pass5
    [language] => en
    [suspend_at_limit] => OFF
    [nemailf] => unlimited
    [mysql] => unlimited
    [command] => /CMD_ACCOUNT_RESELLER
    [cgi] => ON
    [vdomains] => 10
    [catchall] => ON
    [zoom] => 100
    [usertype] => reseller
    [ip] => shared
    [bandwidth] => 20000
    [suspended] => no

Thanks!
Michael

 

[michael]

Looking at it again, I see that the correct username is still not listed. But [name] should be equal to the username at time of creation and probably can be used.

Another strange thing is that all_post.sh is always called. Also when there was an error and the user/reseller has not been created (e.g. "That domain already exists
").
When using only the all_post.sh, it is not possible to distinguish between failure or success ??

 

[DirectAdmin Support]

Hello,

All of the *_post.sh scripts:
http://www.directadmin.com/search_versions.php?query=post.sh

All of the *_pre.sh scripts:
http://www.directadmin.com/search_versions.php?query=pre.sh

Always try and use the specific pre/post script. The all_pre/post scripts are usually reserved for when you don't have any other options.

For example, if you're doing some function specific to creating a domain, always use the domain_create_post.sh (or pre.sh if you need to abort the process).
The domain_create_post.sh won't be called if the domain creation failed.

The all_pre/post.sh scripts are not great for figuring out what was actually going on. All they know is what was requested, and what was passed. However, you (in the example of domain creation) they could just check the user's domain.list to see if it was added. If the domain is there, then the domain addition worked.

John