1) Create the DA tmp directory so you can log into DA again:

mkdir -p /home/tmp
chmod 1777 /home/tmp

2) Create the /home/username directories and subdirectories:

cd /home
vi make_dirs.sh

press ‘i’ to go into “insert mode” then paste the following script (right click)

#!/bin/sh
for i in `ls /usr/local/directadmin/data/users`; do
{
 for d in `cat /usr/local/directadmin/data/users/${i}/domains.list`; do
 {
  mkdir -p /home/${i}/domains/${d}/public_html/cgi-bin
  mkdir -p /home/${i}/domains/${d}/private_html
  mkdir -p /home/${i}/domains/${d}/public_ftp
  mkdir -p /home/${i}/domains/${d}/stats
  mkdir -p /home/${i}/domains/${d}/logs
 };
 done;
 mkdir -p /home/${i}/backups    

 chown -R $i:$i /home/${i}
 chmod -R 755 /home/${i}
};
done;
exit 0;

Press “ctrl-c” to exit “insert mode”, then press “shift-Z” twice to save and exit.  Once the file is saved, type:

chmod 755 make_dirs.sh
./make_dirs.sh

DirectAdmin relies on the system quotas to return a value for how much space is being used.  DirectAdmin will run

/usr/sbin/repquota /home

Where /homeis the quota_partition value set in the /usr/local/directadmin/conf/directadmin.conf file (eg, /home, / or /usr).  The command should output a large list of numbers, eg

[root@server]# /usr/sbin/repquota /home
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
———————————————————————-
root      –  417796       0       0           7446     0     0
nobody    –       4       0       0              1     0     0
bin       —   56880       0       0            510     0     0
majordomo —       8       0       0              2     0     0
diradmin  –       8       0       0              2     0     0
admin     —     200       0       0             44     0     0
user123   —     100       0       0             22     0     0
user456   —     100       0       0             22     0     0

If the “used” column is not showing anything, or users are not in the list, then you’ll need to run the quotacheck program:

Redhat:

/sbin/quotaoff -a; /sbin/quotacheck -avugm; /sbin/quotaon -a;

FreeBSD:

/usr/sbin/quotaoff -a; /sbin/quotacheck -avug; /usr/sbin/quotaon -a;

If are getting errors and no output is displayed for the repquota command, you’ll need to check your /etc/fstab file to make sure that it contains the rw,userquota,groupquota line beside the partition that is using the quotas.
*Important:  On Linux (Redhat/Debian), it’s usrquota,grpquota, and on FreeBSD it’s userquota,groupquota.

Sample /etc/fstab (do not make your’s look identical if it’s different, this is one example from a specific OS):

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ad0s1a                     /                       ufs     rw,userquota,groupquota 1       1
/dev/ad0s1e             /tmp            ufs     rw              2       2
proc                    /proc           procfs  rw              0       0

In this case, the quota_partition is /.  The quota partition should be the partition that holds your users.  Generally, this will be one of /home, / or /usr.

Once the repquota program is returning a normal value, then you can run the tally to get the correct usage to show up in DirectAdmin:

echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

This task.queue command will get picked up by the dataskq binary.   It calls the repquota command and dumps it into /home/tmp/quota-dump.
Check /var/log/directadmin/errortaskq.log for any errors with this.
Running the tally manually for a User can also help with debugging these issues.

If you wish to use per-user php.ini files in:
/usr/local/directadmin/data/users/username/php/php.ini
then you can use this guideto 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.
It’s loaded after the main php.ini, so if it’s not there, it’s not a big deal.  You can add just the php entries that you wish to override the global php.ini’s defaults.
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.

Sample /usr/local/directadmin/scripts/custom/user_create_post.sh

#!/bin/sh

HOME=/home/$username
OBD="${HOME}/:/tmp:/var/tmp:/usr/local/lib/php/"

P=/usr/local/directadmin/data/users/$username
if [ ! -e ${P}/php ]; then
            mkdir ${P}/php
fi

PI=${P}/php/php.ini
if [ ! -e ${PI} ]; then
            cp -f /usr/local/lib/php.ini.template ${PI}
            TMP="perl -pi -e 's#open_basedir = OBD#open_basedir = ${OBD}#' ${PI}"
            eval $TMP
fi
exit 0;

Where the /usr/local/lib/php.ini.template might look like this:

[PHP]
open_basedir = OBD

so that the regex in the user_create_post.sh will swap OBD will the user’s open_basedir path.

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.

Options ExecCGI
SetHandler cgi-script

At the end final entry looked like as follows:

<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>

Then I restarted apache and it worked like a charm. See Apache document Dynamic Content with CGI. Update: As pointed out by Randal you just need to add above four lines.

#Jailed shell (beta)
jail=yes

Then type

./build all_jail

The “./jail/jail_user.sh user” (from the custombuild dir) would be used for each user you want to jail.   The remaining httpd.conf and other options from this guide still apply.

1) First, install the scripts and binaries (note, currently for apache 1.3.x only):

cd /usr/local/directadmin/customapache
mkdir jail
cd jail
wget http://files.directadmin.com/services/customapache/jail/build
chmod 755 build
./build update
./build all

2) It’s recommended you make backups of /etc/passwd, /etc/shadow, /etc/group, and /etc/master.passwd (if you have it)

cp -f /etc/passwd /etc/passwd.backup
cp -f /etc/group /etc/group.backup
cp -f /etc/shadow /etc/shadow.backup
cp -f /etc/master.passwd /etc/master.passwd.backup

3) To jail a specific user, this command is used:

cd /usr/local/directadmin/customapache/jail
./jail_user.sh username

If they are to use jailed CGI, then

SetEnv JAIL_DIR |HOME|

would need to be added to their virtualhosts (where home is their home directory, eg: /home/username).

Note that php through apache is not jailed, so enableing safemode and open_basedir would be recommended.

To *automate* the jailing process, you can create /usr/local/directadmin/scripts/custom/user_create_post.sh and fill it with:

#!/bin/sh
if [ $ssh = "ON" ]; then
  cd /usr/local/directadmin/customapache/jail
  ./jail_user.sh $username
fi
exit 0;

Then chmod it to 755:

chmod 755 /usr/local/directadmin/scripts/custom/user_create_post.sh

To automate the cgi jailing, then the SetEnv option has to be added to any virtualhost that is to use the jailing.  Create /usr/local/directadmin/scripts/custom/domain_create_post.sh with the following:

#!/bin/sh
COUNT=`grep -e "^${username}:" /etc/passwd | grep -c /bin/jail`
if [ $COUNT -eq 1 ]; then
  echo "SetEnv JAIL_DIR |HOME|" > /usr/local/directadmin/data/users/${username}/domains/${domain}.cust_httpd
  echo "action=rewrite&value=httpd&user=${username}" >> /usr/local/directadmin/data/task.queue
fi
exit 0;

and chmod to 755, like the user_create_post.sh script.

4) Since a user can be created without ssh, and it gets added later, we’ll need to create a user_modify_post.sh script as well, but since it’s the same code, we’ll just create a symbolic link.

ln -s user_create_post.sh /usr/local/directadmin/scripts/custom/user_modify_post.sh

Note, that the jail_user.sh isn’t going to be very speedy as it has to transfer over all program binaries and libraries that would be needed inside the jail.  This takes time.  It also takes a huge amount of space that will not be counted in the users total disk usage.

Incoming search terms:

• enable jailed shell openvz (1)

1) At install time, the easiest thing to do is to mount your /tmp partition with the noexec,nosuid options, and mount the /home partition with the nosuidoption.  This is done in your /etc/fstab and requires those paths to exist as partitions, and not just as subdirectories of /.  If you’re unsure, type:

mount

to get a listing of your partitions and their current mounting options.  Use google for more information on these mounting options. Be very careful when editing your /etc/fstab, as any errors could prevent your system from starting up.  Note that you must not have “nosuid,noexec” for / or /usr, as those partitions have suid binaries normally (su, passwd, etc).

2) After the system is installed, a good idea is to add dangerous php functions to the disable_functionslist.  This prevents php scripts from running “raw” functions that could be used to execute programs on your system.  Note that some php scripts do legitimately require these functions to operate, so if your scripts don’t run after enabling this function, edit your php.ini to remove the required functions from the list, and restart apache.  To add the disable_functions with custombuild, type the following then restart apache:

cd /usr/local/directadmin/custombuild
./build update
./build secure_php

3)Do regular updates of system services, libraries and scripts.  It’s important to keep your system updated once installed.   This is the responsibility of the server administrator.  There are several tools and options avaiable to help the admin do this.  For system libraries like openssl and other low level system items, this is left to the admin to do how he wish, usually package systems like yum or apt-get can do this for you.  For services and scripts that DA installs, you can use the custombuild script.   A typical update command with custombuild is:

cd /usr/local/directadmin/custombuild
./build update
./build all d

Note that in the custombuild directory is a file called “options.conf”.  In this file is a list of all options you’ve got regarding what custombuild will do.   Regarding updates, ensure you have clean_old_webapps=yes present.  This removes all scripts from /var/www/html, after updating you do a new one.     The options.conf also has cron options to check for updates nightly, or even install these options nightly.  I recommend having the nightly cron check, and then a hand-on admin proceed with the update after he gets the notice.  To enable a nightly notice replace the following boldoptions with your relevant information:

#Cron settings
cron=yes
email=email@domain.com
notifications=yes
updates=no
webapps_updates=yes

Then type:

./build cron

These are the settings for getting nightly notices for updates, but it won’t do the updates for you.
After getting the notice in your inbox, you’d run the following from the custombuild directory:

./build update_versions

to update just those items that require updating.  Note that doing “./build all d” can be simpler, but takes longer to run.
If you wish to have “./build update_versions” be run automatically, change the updates=no to become updates=yes.  Just keep in mind that the server admin is still required to be fully aware of the system and it’s state if he choses yes for this option.  The webapps_updates option only applies when updates=no is used.  It’s there to still allow updates to the php scripts in /var/www/html, while not affecting compiled services.  Set webapps_updates=yes if updates=no and you wish to have automated updates of the webapps scripts with the cron option.  If updates=yes, then the webapps_updates value doesn’t matter.

4) If you’re running php in “CLI” mode, then enabling both php SafeMode and open_basedir is wise.  Safemode is an internal form of disable_functions which also does a bit more checking.  See the documentation on Safemode for more info on this.   Open_basedir, which is enabled by default, tells php to not allow scripts to access files outside of the set list of paths.
To control SafeMode and Open_Basedir on your php CLI system (default), go to:

Admin Level -> Php Safemode Config

5) suPhp is one option which some admin’s like, other’s do not.  What suPhp (php CGI) does is runs php scripts as the system user of the account, rather than the “apache” user.   This solves many issues like permission/ownership when a php script uploads files.  It also allows an admin to track down rogue scripts more easily as it’s not running as a generic user.  Another benefit of suPhp is that you can chmod your php scripts to 700 instead of 755.  This makes them more secure in the case you’re storing passwords in your scripts.   Drawbacks to suPhp include a slight slowdown in performance since there are a few more hoops to jump through to have php run as the user instead of “apache”.  Also, the items in point 4) above have no effect since suPhp does not monitor VirtualHost php flags.  All settings must be done in php.ini files.  Note that you can have per-user php.ini files to allow per-user settings, see this link.

To enable suPhp, see this guide.

6) If you don’t plan on doing any remote access to mysql, then setting up mysqld to only listen on 127.0.0.1 would be a good idea.  Note you’ll have to keep this in mind if your users start asking you why they can’t connect to mysql from a remote location.  To set mysql to only bind to 127.0.0.1, add the following to the [mysqld]section of your /etc/my.cnf, then restart mysqld:

bind-address = 127.0.0.1

7) One filtering option for apache is mod_security.  This is not part of our installation, but mod_security is an apache filter which checks all http requests sent by clients to ensure they’re valid.  Note that if not setup correctly, it can break frontpage, or other php scripts that often have long URL requests, so proper setup and testing would be important.  Check our forum for guides on this, it’s not covered by our support.

A firewall is always a good idea.  Many people use iptables or apf.  A new free plugin is also available here.

9) Set the User’s domains directory to block other Users on the system from seeing in:
http://help.directadmin.com/item.php?id=254

10) Setup your named.conf to not allow recursion.  This should be done by default now, but check anyway with this guide.

11) Prevent Users from using weak passwords by enabling difficult password enforcement.

12) Prevent Users from creating subdomains belonging to other Users with this option.

13) If you’re using DirectAdmin with SSL, it’s a good idea to force all SSL connections to use SSLv3 instead of other older protocols.

14) To add another layer of security with the permissions of the perl binary, using a trick similar to step 9, run the following:

chgrp apache /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl
chmod 705 /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/binl/curl

what this will do is tell the system that any user in group “apache” is not allowed to execute /usr/bin/perl.  If you did implement step 9 you could in theory use “access” instead of “apache” for the chgrp value, to also prevent other system account from running it, but apache is the main one.   This technique can be applies to other binaries as well, like wget, fetch, etc.. anything you don’t want the “apache” user from running.  Keep in mind that using suPhp (step 5) essentially negates this issue since php scripts run as the user instead.  Note that this is another layer of security, so using it anyway wouldn’t hurt anything, in the event that an apache exploit happens independant of php completely.

15) Brute Force Login Attempts are more common, so it’s best not to have direct ssh logins for common accounts like root or admin.  Generally, it’s safe to use a hidden “su” user first, then login to root or other accounts once connected.  Disable any accounts (root, admin, etc) that don’t need direct access by editing the /etc/ssh/sshd_config.   Always test changes before logging out else you may lock yourself out from the box.

ERROR: PleskFatalException StatInfo-> getProductVersion failed

OR

ERROR: PleskFatalException StatInfo-> getProductVersion failed:

file_get_contents () failed: mktime()

[<a href='function.mktime'>function.mktime</a>]

The “Plesk getProductVersion failed ” message states that either the Plesk version file /usr/local/psa/version is empty AND/OR the plesk version in the ‘psa.misc’ table is incorrect. This is mostly caused due to a failed Plesk upgrade OR by removing/installing some Plesk modules.

To fix the issue do the following:

1. First, check the Plesk version installed on the server

# rpm -qi psa

note down the ‘version’ and ‘release’ values (these values will be different on your server).

Version : 9.5.3 Release : cos5.build95301122.20

now, check the OS installed on the server (for example, on CentOS)

# cat /etc/redhat-release

CentOS release 5.5 (Final)

Using the above Plesk and OS info, insert a line as follows (your values will differ) in the /usr/local/psa/version file.

9.5.3 CentOS 5 95301122.20

Save the file and restart the psa serivce.

2. If the above fix doesn’t work, do the following

Check the current value of  Plesk in the psa.misc table.

mysql> select * from psa.misc where param='version';

If the value is not 0953 (example from my server), run the mysql update query to set the proper value. You should use the value that is returned by the ‘rpm -qi psa’  command on your server.

mysql> update psa.misc set val="0953" where param="version";

Exit and restart mysql. That is it.

Incoming search terms:

• pk unzip (1)

2. Prerequisites

3. Asterisk PBX configurations

4. Explanation

4. Uploaded files

2. Pre-setup:

3. Setup:

	Open your extensions.conf using a text redactor.
	At the bottom of the file (on new line) add new context by typing `[echotest]` (without the quotes).
	Add the following extension:
		exten => echo,1,Answer()
			; Answer the line
		exten => echo,n,Set(TIMEOUT(absolute)=120)
			; Sets maximum length of the call to two minutes (if someone forgets to hang up)
		exten => echo,n,Playback(file1)
			; Playbacks file named `f1`. The user will hear the contents of `f1`
			; In our tutorial `f1` is the first announcement that we have recorded.
		exten => echo,n,Echo()
			; starting Echo() application which will create the echo effect
		exten => echo,n,Playback(f2)
			; Playbacks file named `f2`. The user will hear the contents of `f2`
			; In our tutorial `f2` is the first announcement that we have recorded.
		exten => echo,n,System(/bin/notify_us ${CUR})
			; Notification script which will notify us that curtain user is experiencing problems.
		exten => echo,n,HangUp()
			; Hangs up the call.

		`cat /route/to/somewhere/file >> /etc/asterisk/extensions.conf`

	Context: echotest
		# Asterisk will execute extension in this string
	Extension: echo
		# Name of the extension
	Priority: 1
		# At which priority Asterisk will begin the execution
	Callerid: Automated Test System <>
		# Setting the CallerID to the specified string.

Enjoy your testing!

When you know which version you want to install download the according packages.

Note that we will install also libpri and zaptel packages. They are optional for Asterisk but if you want to use Asterisk with MeetMe (see MeetMe application and meetme.conf) or to use MusicOnHold you’ll have to install zaptel. The TDMoE cards will also need the zaptel module in order to work correctly. If you will use PRI cards you’ll have to install libpri module.

cd /path/to/source/libpri
make
make install

./configure
make
make install
make samples

Incoming search terms:

• how to install rpm packages in windows (1)