new way:
If you wish to use per-user php.ini files in:
/home/username/php.ini
then you can use this guide to add the code:

SetEnv PHP_INI_SCAN_DIR /usr/local/directadmin/data/users/|USER|/php/

to the VirtualHost entires for that domain and it’s subdomains. This will tell suPhp to look in that path for a php.ini (which you’ll need to ensure is there).
Note for complete usage of this setting, a how-to has been created here, which should be consulted with first: http://www.directadmin.com:80/forum/showpost.php?p=156958&postcount=25
If you only want to set a custom php.ini for individual users, and not all users, then you can use this guide to insert just the one line of code into the VirtualHost entires for that domain.
Related:
http://www.php.net/ini.sections
Improved php.ini handling in 5.3.0

---

old way:
In order to setup a php.ini for each user with suPhp (installed by custombuild), edit:
/etc/httpd/conf/extra/httpd-suphp.conf
Find this line:

suPHP_ConfigPath /usr/local/etc/php5/cgi/

and comment it out by changing it to

#suPHP_ConfigPath /usr/local/etc/php5/cgi/

(just add a # in front of it).
Doing this will let suPhp be more flexible in using a different php.ini file. By default, it will still fall back to the /usr/local/etc/php5/cgi/php.ini if nothing else is set, but by not setting it, it allows us to change it (suPhp only accepts the first call of that command).
The next step is to tell apache where to find the php.ini that you want.
Go to:
Admin Level -> Custom httpd configuration -> domain.com
Insert the following 1 line into the top textarea:

suPHP_ConfigPath |HOME|/

exactly as written, then hit save. You can do this for as many single domains as you wish.
Note that you can also make this a global change by adding that line to the virtualhost templates using this guide:
help.directadmin.com/item.php?id=2.
Restart apache when you’re done.
Don’t forget to actually add a php.ini file into /home/username/php.ini and save it with root as the owner if you don’t want the user changing it at all. In that php.ini file, you can specify a custom open_basedir path, thus preventing the user from wandering about the system. Automating a new php.ini can be done with the user_create_post.sh script.

By default, suPhp is compiled in "paranoid" mode. This means that the settings in the user httpd.conf files:

suPHP_UserGroup username username

will require all php files to be owned by username or suPhp will throw a "500 Internal Server Error".
This does not apply to domains, when used normally, because each domain has it’s own VirtualHost with the suPHP_UserGroup inside it using the correct settings.
The ~username (UserDir) method will fail in paranoid mode, because there is not a virtualhost for each ~username path, and no suPHP_UserGroup settings for each user, hence you get the 500 error.
The solution to this is to compile suPhp in "owner" mode instead of "paranoid" mode.
To do that, run these commands.

cd /usr/local/directadmin/custombuild
mkdir -p custom/suphp
cp -fp configure/suphp/configure.suphp custom/suphp/configure.suphp
perl -pi -e ’s/paranoid/owner/’ custom/suphp/configure.suphp
./build clean
./build suphp
cd /usr/local/directadmin/data/templates/custom
cp -f ../virtual_host* .
perl -pi -e ’s/suPHP_UserGroup/#suPHP_UserGroup/’ virtual_host*.conf
perl -pi -e ’s/suPHP_UserGroup/#suPHP_UserGroup/’ /etc/httpd/conf/httpd.conf
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Which will change all references of suPHP_UserGroup to #suPHP_UserGroup, basically, just commenting them out.

A few things that could cause that are:
Possible Causes:
1) MaxClients set to a value too low
2) If you have over about 800 VirtualHost entries (domains, subdomain, ssl, etc.. ), the ErrorLog files open too many file descriptors and apache won’t be able to log the errors and may stop responding. This number can vary per box depending on the limit, and setup of the system. (lower/higher)
Solutions:
1) edit /etc/httpd/conf/httpd.conf and increase the MaxClients setting to something like 200 or 300.
2)

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom

# remove all the ErrorLog lines (or comment them out) from the 4 virtual_host*.conf files that are in the custom directory.

perl -pi -e ’s/Error/#Error/’ virtual_host*.conf
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Apache should be restarted automatically after a few minutes later (rewrite might take a while with over 800 sites).
If that’s not enough to lower the limit and the problem persists, also try commenting out the CustomLog entries:

perl -pi -e ’s/CustomLog/#CustomLog/’ virtual_host*.conf

and repeat the above echo command to rewrite the httpd.conf files.
3) Other possible information:
Edit /usr/include/bits/typesizes.h and set
#define __FD_SETSIZE 32768
and then recompile with customapache or custombuild.
On FreeBSD, it’s /usr/include/sys/select.h or /usr/include/sys/types.h
Change:
#define FD_SETSIZE 1024U
to
#define FD_SETSIZE 32768U
then recompile apache/php
4) edit /etc/sysctl.conf and add:
fs.file-max = 32768
and run:

/sbin/sysctl -w fs.file-max=32768
/sbin/sysctl -w kern.maxfiles=32768
/sbin/sysctl -w kern.maxfilesperproc=32768

then recompile apache/php
Other possible entires for the sysctl.conf:
kern.maxfiles = 32768
kern.maxfilesperproc = 32768
5) Another way to free up FileDescriptors (FDs) is to disable ssl on any domain that does not require it.
A quck way to check is to type:

ls -la /home/*/domains/*/private_html/index.html

quickly scan the list for any index.html that isn’t betwen 200-300 bytes in size. Any that are not in that range will have been edited and the user is probably using ssl, so take note of those usernames and domains. Now, the quick way to do a mass SSL shutoff for domains is to type:

perl -pi -e ’s/ssl=ON/ssl=OFF/’ /usr/local/directadmin/data/users/*/domains/*.conf

Then turn ssl=ON back on for any users who need it. Note that this is an end user level setting, so they have the ability to turn it back on themselves via Domain Setup. Then type the action=rewrite&value=httpd command as mentioned in step 2 above.
What this does is reduced the number of FD’s by 50%. Since many people rarely use SSL, disabling it reduceds half of all virtualhosts, since all domains, subdomains, etc.. have 2 virtualhosts each with ssl, and only 1 each without ssl.
6) Openssl bug. Either update openssl and recompile apache, or patch apache 2:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43717

---

Related error messages:
[error] System: Too many open files in system (errno: 23)
host: isc_socket_create: not enough free resources socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.
host: isc_socket_create: not enough free resources

DirectAdmin Allows Admin to insert extra httpd.conf code that a User may require. To access the control page for this functionality, go to Admin Panel -> Admin Settings -> Customize Httpd Configurations.
Once you see the list of domain, click the domain you wish to insert the extra httpd.conf code to.
At the bottom of the page, you’ll see the current httpd.conf for that User. It will contain all VirtualHosts for all domain, subdomains and redirects. Any changes made by this page will only affect the VirtualHosts for the domain in question, not the other domains owned by that user. If all domains need the changes, then you would repeat this process for each domain.
The top textarea is where you will paste the custom httpd.conf code you wish to insert. The code you write will be inserted into the |CUSTOM| token for all VirtualHosts for this domain. You can edit the templates as needed if you require to move the |CUSTOM| token to a different position in the VirtualHost.
All tokens that are available for the VirtualHost will be available with this feature. You can also set any token you wish. For example, if you with to change the DocumentRoot for a domain, you can paste:

|?DOCROOT=/new/path/you/want|

Note that this new DocumentRoot will be used for all DocumentRoots for this domain, including https connections and subdomains, so it may not be a desired effect.
Another common use is to add another ServerAlias. This allows another domain to be used to access the exact same content. To accomplish this, you would write

ServerAlias newdomain.com www.newdomain.com

To get newdomain.com and www.newdomain.com to point to the original domain for the VirtualHost. You will also have to make sure that newdomain.com and www.newdomain.com both resolve to the same IP as stored in |IP|.

If you wish to change the setup of the VirtualHosts for all domains, you can do so by creating your own custom templates.

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom

Once you’ve copied the 4 VirtualHost files (or just the ones you want) to the custom directory, you can then edit the new files you’ve just copied. DirectAdmin will always check for the custom file before going to the default ones. Failure to copy the virtual_host*.conf files to the custom directory before modifying them will result in a loss of all changes when DirectAdmin updates itself (the files are overwritten). Note that there are actually 8 virtual_host files, but you only need to worry about the 4 that apply to you. The files with the 2 in them are for apache 2.x. The ones without the 2 in them are for apache 1.3.
Inside the virtual_host*.conf files, you’ll find code that is similar to httpd.conf code, but contains what are known as tokens. These tokens are what will be replaces with specific user data for each domain created.

Available tokens

DOMAIN
the name of the domain. eg: domain.com

IP
the IP address associated with that domain. eg: 192.168.3.4

HOME
The users home directory. eg: /home/gary

ADMIN
The email address of the server admin. webmaster@domain.com

HOSTNAME
The hostname of the server. eg: server.domain.com

SAFE_MODE
ON or OFF if php safe_mode is enabled or not

PHP
ON or OFF if php is enabled or not

CGI
The whole httpd.conf line used to add the Script-Alias

HANDLERS
httpd.conf code holding all apache handlers

MIMETYPE
httpd.conf code holding all apache mime types

USER
the username

GROUP
the users group name (99% of the time, it’s the same as the USER)

DOCROOT
The DocumentRoot of the VirtualHost. This is the path that apache will use to access the data when the ServerName (domain.com) is requested

SUB
for the virtual_host_*sub.conf file, the subdomain name. eg: sub

CUSTOM
custom httpd.conf code to be inserted if the domain.com.cust_httpd file exists. (See Adding custom httpd.conf code the VirtualHost of one domain)

CAROOT
The whole httpd.conf line used to load in the SSLCACertificateFile directive

CERT
The path of the certificate to be used for the domain

KEY
The path of the certificate to be used for the domain

The top of the templates should contain |?CGI=…| and |?DOCROOT=…|. These lines are where the data for the CGI and DOCROOT tokens are set. If cgi is not enabled, this line wil be ignored and the CGI token will be empty. If the domain is suspended, the DOCROOT will be filled the the path of the suspend page. The CAROOT token will be empty unless the User has added a valid CARootCertificate through DA.
You can use tokens when assigning a value to CGI or DOCROOT, just use `TOKEN` instead of |TOKEN|.
Once you are happy with your new virtual_host*.conf files they’ll need to be used in the real httpd.conf files. You can trigger DirectAdmin to rewrite all User httpd.conf files by running:

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

The command will be added the the task queue which is checked once per minute, so it may be a few minutes before all httpd.conf files have been rewritten. *Note: the main /etc/httpd/conf/httpd.conf is never overwritten (unless DirectAdmin is reinstalled) so any changes you make will be safe.
Note, that you can also use if-then-else statements if you don’t want all settings to be global. Example, say you want a custom item added, only for 1 domain:

|*if DOMAIN="domain.com"|
#custom item for just this domain
|*endif|

See the if-then-else link for more info on what else you can do with this basic scripting tool.
You can also run actual scripts with database queries, etc… if you wanted using the script portion of the templates.
More info on that here: http://www.directadmin.com/features.php?id=756