How to Make Your System Admin Mad by Creating Huge-Ass Files

Posted by Nessa | Posted in Uncategorized | Posted on 31-10-2007

0

So If you’ve ever woke up in the morning and asked yourself…”Hmm, how can I make my system admin’s job harder to the point where they get mad and shut down my server?” Well, lucky for you I can answer that question. All you have to do is use the ‘dd‘ command to write a 120gb file to an 80gb hard drive. That’s a winner.

By ‘dd’ I’m not talking about my bra size, people. It’s sad, but we recently had an over-curious customer try to see what would happen if the hard drive filled up on his dedicated server. You know what happens when you flush a clogged toilet? Yea….

So here’s the command:

dd if=/dev/zero of=test bs=1024 count=125829120

This command will write a 120gb file directly to the disk. ‘of’ specifies the name of the output file, while ‘bs’ represents the size of a block and ‘count’ is how many blocks to create. Really, it’s a dangerous thing to do if you don’t know what you’re doing. Generally the only time I do this is when I’m testing large file support for servers and PHP.  Nevertheless, the sheer curiosity of ignorant users is enough for me to pull the power plug on a server.

Mass-Moving cPanel Accounts

Posted by Nessa | Posted in Uncategorized | Posted on 22-10-2007

15

If you’ve ever needed to move a ton of cPanel accounts from one server to another, you probably know the following:

  1. The multiple account move feature in WHM fails miserably
  2. It takes forever to do them one by one, esp. when you have other things to do

I figure the best way to mass-move accounts is by listing all the accounts in a file, then using a simple bash script to repetitively package all the accounts to they can be moved to another server.

First, you need to create a file (like users.txt) to list all the users you wish to move. If you’re only doing a few you can just go ahead and list the users in there manually, but if you’re doing like a whole server, you can get all the users in one file like so:

ls /var/cpanel/users > users.txt

You’ll then need to manually edit the users file and remove the ‘.’ and ”..’ entries, and any others that should not be included. The users.txt file should also be in a format like this:

user1
user2
user3

Next, you may want to set up an SSH key between servers so all the cpmove files and be transferred automatically. If you don’t know how to do this, here is a simple and straight-through tutorial.

Create a bash script called ‘cpbackup.sh’ with the following lines:

#! /bin/bash
for i in `cat users.txt`; do /scripts/pkgacct $i; done
scp -r /home/cpmove* root@server:/home
echo "Account backups done" > email.txt
mail -vv -s "Account backups done" your@emailaddress.com < email.txt


This will run cPanel backups up all the accounts listed in users.txt, scp them over to the new server, then email you when it’s done. Note that if you do not have SSH keys installed, you will have to manually type in the new server’s password when the script is ready to transfer the accounts over.

The on the new server you can use the same script and users.txt file, just change it around:

#! /bin/bash
for i in `cat users.txt`; do /scripts/restorepkg $i; done

This will restore all the user accounts that you copied over. From there, you’re all done!
One simple note: I’m not a shell programmer so I’m sure there are a lot better ways to accomplish this..if so, you can post them in a comment. The downside of using this method to move accounts is that all of the accounts are backed up in order so if you have a hundred some users, the backup files might be sitting on the server for hours until they are moved and restored, so you’ll want to make sure that your users are not making changes to their sites during the move process. Also, since the backup files are stored on the server it’s a good idea to figure out how much disk space you are going to need to avoid going over. You may be able to modify the script to do groups of 10-20 then delete the cpmove files if disk space is a concern.

PCLinux OS is Kind of Sexy

Posted by Nessa | Posted in Uncategorized | Posted on 18-10-2007

1

I recently became pretty fond of Ubuntu when I installed it on my work computer after dealing with daily crashes of Windows XP Pro. I find it to be a lot easier to manage, though it sucks that some software is still not compatible with Unix and installing a wireless network card is about as hard as finding a 34D push-up bra at Victoria’s Secret. I mean, it’s a lingerie store…you’d think they’d have a bigger push-up bra. Maybe I want my boobs to peek out of my shirt every once in a while…or maybe I’ll decide to turn tricks someday and need a good “come get me” outfit. I also just realized that this is the third time today I went off on a tangent about boobs.

So anyways, out comes PCLinuxOS which is a new OS determined to be the bridge between Linux and Windows, targeted towards beginner Unix-ers who aren’t quite ready to kick Microsoft to the curb. It’s not quite the Gnome desktop, but rather a Windows Vista-inspired interface powered by a Linux core. I think it’s a good idea and will probably help the world see that Windows is officially the dead rat in the soup, by converting end users over to Linux. Best off, it’s completely free and can be downloaded here.
I don’t have any plans in the near future to use PCLinuxOS since I’ve become very content with Ubuntu, but If you’re a beginner to Unix you might want to give this one a look and let me know how it works.
Screenshots

Using PHP to Display Version Info – Part II

Posted by Nessa | Posted in Uncategorized | Posted on 17-10-2007

3

Earlier I showed some examples of commands you can use to pull software versions into a simple PHP script. In the next example I’ll show how to do the distro and kernel versions. I’m sure that there’s a much simpler way to do this (i.e. a simple cat command on the /proc/version file), but I figured I’d use a more advanced example in the form of a function. I did the distro as a variable to show how easy this is:


<?php
function kernelinfo () {
$buf = exec( 'cat /proc/version');
if ( $buf == "ERROR" ) {
$result = "N.A.";
} else {
if (preg_match('/version (.*?) /', $buf, $ar_buf)) {
$result = $ar_buf[1];


if (preg_match('/SMP/', $buf)) {
$result .= ' (SMP)';
}
}
}
return $result;
}


$distro = exec('cat /etc/redhat-release');


$kernel = kernelinfo();


echo $distro;


echo "<html><br></html>";


echo $kernel;

?>

This will show a result of the following, obviously various depending on your platform:

CentOS release 4.5 (Final)
2.6.9-023stab033.9-enterprise (SMP)

Keep in mind that this script (as the last) requires the ability to pass shell commands through PHP. So, you would need to be able to the exec function, or replace it with system, passthru, escapeshellcmd, or shell_exec if those are allowed in your php.ini configuration. Also, if you run PHP as an Apache module, this will not work if you have open_basedir protection enabled.

Using PHP to Display Version Info

Posted by Nessa | Posted in Uncategorized | Posted on 15-10-2007

3

I’ve been working on this application for work that does some simple server reporting, part of which involves displaying the versions of major software running on the machines. The importance of this to me personally is that since we have over 30 shared servers hosting multiple customers, we are continually moving websites between servers. Some of our older generation servers are still running MySQL 4.0 and PHP 4.3, so I need to be aware of this to make sure that customers are being moved to servers with compatible versions. It’s also good in tracking and planning upgrades.

I find it best to use the exec() function since it’s not blocked by most hosts. However, if you are on a shared host it’s very likely that certain PHP functions are disallowed in the php.ini. In that case you may be able to subsitute exec with system, passthru, escapeshellcmd, or shell_exec…unless those are blocked too. Then I guess you’re out of luck.

Start by creating some variables to store ordinary shell commands. If you wanted to find the php version from command line, you would usually type:

php -v

This will give a huge chunk of crap that you really don’t need if you’re making a simple version display script. In this case, you can use grep, awk, sed, and cut to trim down the output into a one-liner:

php -v |grep built |awk {‘print $2′}

The awk command prints out columns, so in the above example I’m printing out the second column of the line that contains the word ‘built’. Once the desired output is figured out, you simply assign it to a variable passed through exec() or a similar function:


$phpver = exec("php -v |grep built |awk {'print $2'}");

Then you can call the variable $phpver anywhere in your script:

echo "PHP Version: $phpver";

You can probably go through and figure out the commands to show other software versions on your server. In my script I’m showing the perl, php, mysql, apache, python, cpanel, and ruby versions. Here are the commands I used:

<?php

$perlver = exec("perl -v |grep linux |awk {'print $4'}|sed -e 's/v//'");
$phpver = exec("php -v |grep built |awk {'print $2'}");
$mysqlver = exec("mysql -V |awk {'print $5'} | sed -e 's/,//'");
$apachever = exec("apachectl -v |grep version |awk {'print $3 $4'}|sed -e 's/Apache\///'");
$pythonver = exec("python -V 2>&1 | sed -e 's/Python //'");
$cpanelver = exec("cat /usr/local/cpanel/version");
$rubyver = exec("ruby -v |awk {'print $2'}"); ?>

Then I just echoed out all the variables to display my version numbers:

See here .

Size Matters with PHP

Posted by Nessa | Posted in Uncategorized | Posted on 27-08-2007

0

I figured this might be helpful to post since it seems to be a fairly common issue poking up about PHP’s limits in regard to file size. It’s no secret to fellow programmers that PHP is incapable of readily handling files over 2gb on the typical 32-bit system, but others are easily aggravated with a greeting of errors that look like this:

PHP Warning: ……. failed to open stream: File too large in ……..

Generally I’d say that if you’re trying to get PHP to man-handle huge files you’d need to have one badass server that can take that kind of abuse. Before you go about trying to compile PHP with large file support, you may want to consider passing the ‘split’ command through the system or passthru functions to break your massive files into smaller bits so PHP can handle them. If you’re the type that has to go about everything the hard way, then I guess that’s why you visited my site.
To compile PHP with large file support, you need to add a simple compiler flag preceding your configure statement. This should look as so:

# CFLAGS=”-D_FILE_OFFSET_BITS=64″ ./configure –with-modules-that-i-use

Then your make && make install and (if all goes without error) you should now be able to work with large files with PHP.

Too bad nothing’s really straight forward, eh? Apache itself has a filesize limit too (even up to 2.2.4) so don’t waste your time trying to get your newly-compiled PHP installation to work with Apache. When I was first trying to work this out I figured that it’s best to have two PHP installations, one for Apache and the other just for the CLI.

To do this, create yourself a phpinfo file and copy the configure line, removing the single quotes from around each flag. Two things you’ll want to change though:

  • Remove the ”–with-apxs2=/usr/local/apache/bin/apxs‘ (or similar) flag to keep the installer from compiling against Apache
  • Change your –prefix to a different location. I used ”–prefix=/usr/php-lfs’ .

When the installation is done, make it easier on yourself by creating some symlinks to the new binary:

ln -s /usr/php-lfs/bin/php /usr/bin/php5

ln -s /usr/php-lfs/bin/php /usr/local/bin/php5

This way you have your LFS-compiled PHP version in /usr/bin/php5 to use for your scripts. To call them, you’d use:

php5 /path/to/script or /usr/bin/php5 /path/to/script

What if you actually want to call the script from a browser? Well, you still can’t load a large file in the browser itself, but you can process it through a script to have a process run on the server:

<?php passthru('/usr/bin/php5 myscript.php'); ?>



And that should pretty much do it.

Upgrading to MySQL 5.1.x on cPanel

Posted by Nessa | Posted in uncategorized | Posted on 20-07-2007

13

Update 2/18/14: Hi Guys.  This post is no longer relevant as of…a really long time ago.  I wrote it in 2007, and a lot has changed.  If you’re trying to upgrade to a version of MySQL that cPanel doesn’t yet support, check out my article here, which has updated instructions.  This post is being left intact for archiving purposes only.

If you have server that run on cPanel, you’ll probably know how big of a Nazi it is in regards to the MySQL versions it can run. We just got this new line of servers at work and one of them I was pretty heartset on installing MySQL 5.1, mainly because of its loadable plugin features where you can install a plugin or module without having to recompile the whole damn thing. Upgrading to 5.1 is easy, you just have to follow the right steps.

First, I would recommend upgrading to cPanel 11 or EDGE, which should have support for compiling Apache with non-supported versions of MySQL. On this server, I’m currently running 11 on the bleeding edge build. Also, it’s a splendid idea to dump all your databases before upgrading.
Note that these instructions mention MySQL 5.1.20-beta because that’s the latest release available at the time of my writing….but you can essentially follow this guide for any version of MySQL!

1. Copy the MySQL libraries from the server into a temporary location:

mkdir /root/sqllibs
cp /usr/lib/libmysqlclient.* /root/sqllibs

2. Find any installed MySQL packages:

rpm -qa | grep -i mysql-

This should present a list of installed rpm’s…remove them with rpm -e ,but note that some may need to be removed before others. Some people also would remove the /var/lib/mysql directory, but you can leave that there.

3. Download and install the MySQL 5.1.x packages:

Hop on over to http://dev.mysql.com/downloads/mysql/5.1.html#linux-x86-32bit-rpms and download the 5.1 RPM’s and install them:

rpm -i MySQL-client-5.1.20-0.glibc23.i386.rpm
rpm -i MySQL-devel-5.1.20-0.glibc23.i386.rpm
rpm -i MySQL-embedded-5.1.20-0.glibc23.i386.rpm
rpm -i MySQL-test-5.1.20-0.glibc23.i386.rpm
rpm -i MySQL-server-5.1.20-0.glibc23.i386.rpm

4. Prepare cPanel

You’ll want to make sure that cPanel’s updates don’t reset the MySQL version, so you need to run the following commands to force cPanel to skip MySQL updates:

touch /etc/mysqldisable
touch /etc/mysqlupdisable

Now edit /var/cpanel/cpanel.config and change the MySQL version to 5.1

Create the symlink:

ln -s /var/lib/mysql/mysql.sock /tmp

Also, verify that the MySQL version is correct by running mysql -V

root@vps [~]# mysql -V
mysql Ver 14.13 Distrib 5.1.20-beta, for pc-linux-gnu (i686) using readline 5.0

5. Set up MySQL

MySQL should have already been started at this point, so you can attempt to log in as root using mysql -u root . If you are able to log in on the first try, great. If not, you’ll need to reset the MySQL password:

pico /etc/my.cnf

Add this line, and restart MySQL

skip-grant-tables


service mysql restart

Now log into MySQL root and set the password:


mysql -u root
mysql> FLUSH PRIVILEGES;
mysql> GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY 'yourpassword' WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> exit;

service mysql restart

When you’re done, remove the skip-grant-tables line from /etc/my.cnf and restart MySQL. Then log into Webhost Manager and reset the password *again*… this is necessary to build a bridge between the linux root user and the MySQL root user, so you can log into MySQL both through WHM’s phpMyAdmin, and SSH without a password when logged into the server as root.

All you need to do now is recompile Apache, but move the MySQL libraries back so easyapache can find them:

mv /root/sqllibs/libmysqlclient.* /usr/lib/mysql/

I haven’t tested too many configurations yet, but what works for me is Apache 2.2.4 with php 5.2.3, compiled with MySQL and mysqli, but NOT system MySQL.

Working with Permissions in PHP

Posted by Nessa | Posted in uncategorized | Posted on 20-06-2007

7

.!.

PHP uses the same command as *nix systems when dealing with changing permissions for files:

chown – changes ownership, but can only be done by a root user
chgrp – changes group ownership, can be done by a user who is a member of the new group
chmod – changes permissions, can be done by the user (and sometimes the group) that owns the file

These commands are particularly useful in situations where PHP runs as a different user on the system, which is common when PHP is compiled as an Apache user. A lot of our customers get frustrated at the fact that once they use PHP to create a file, their user can’t touch it. That’s why whenever you have PHP create a file that needs to be neutral, its permissions have to be set accordingly.

The syntax of those commands are simple:

chown($file, $user)
chgrp($file, $group)
chmod($file, $permissions)

The simplest example of using these commands is a follows:

<?php
$file = "myfile.txt";
$handler = fopen($file, 'w') or die("can't create file");
chmod($file, '0777');
fclose($handler); ?>

In this example, I had the PHP script create a file called ‘myfile.txt’ in write mode, then change its permissions to 777.  This is of course the simplest example in the world, but you can make them much more complex.

For more information on using fopen to handle files, you can read this.  Also, when you set permissions you have to use the octal value (0777) instead of just 777.

Listing IP Addresses of a Server

Posted by Nessa | Posted in Uncategorized | Posted on 10-06-2007

3

I hate using the jarbled output of ifconfig to find out what ip addresses are active on a server, so using this complex command will list all the IP addresses of the server in a nice little list:

ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'

I specifically use this command for a VPS setup script that I was working on to automatically input the correct server IP into the httpd.conf and named entries on cloned systems, so I don’t have to do it manually. To do this you would just assign the command as a variable, then call that variable with the replace command:

IP=`ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'`
cat httpd.conf |replace 123.456.789.123 $IP --httpd.conf

If you want to incorporate this into a PHP script, you just need to use the system() function, assuming your host allows it:

<?php system("ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'"); ?>

Installing suPHP on cPanel

Posted by Nessa | Posted in uncategorized | Posted on 05-06-2007

12

.!.

I wrote this tutorial a while back and figured it would be good to post because suPHP is growing more popular as an alternative to phpSuExec. The instructions assume that you are on a Linux cPanel server and are familiar with how to install PHP, but do not want to use EasyApache’s suPHP installer in WHM (you stubborn bitches)

Note also that these instructions use suPHP 0.6.1 with a cPanel patch that makes it equivalent to 0.6.2. I personally have had issues with the actual 0.6.2 version installing, so I stuck with the patch.

Next, download suPHP and the apply the patch:

wget http://v-nessa.net/imh_files/suphp-0.6.1.tar.gz
tar -xvzf suphp-0.6.1.tar.gz
cd suphp-0.6.1

wget http://v-nessa.net/imh_files/suphp-0.6.1-cpanel.patch
patch -p1 < suphp-0.6.1-cpanel.patch

Then compile the binary:

./configure –prefix=/usr –sysconfdir=/etc –with-apxs=/usr/local/apache/bin/apxs –with-apache-user=nobody
make && make install

Now locate your PHP binaries for installation. If you previously used EasyApache, you should be able to find them somewhere in your home directory within a directory named ‘cpeasyapache’ or something similar depending on your cPanel version. Otherwise you will need to fetch the PHP sources from php.net if you do not have the original sources you used to compile.

Check the server’s phpinfo file and grab the configure path, then copy and paste it into notepad and remove all the single quotes. You’re basically compiling PHP exactly the same way as it was before, only not as an Apache module.

cd /home/cpapachebuild/buildapache/php-5.2.3
make clean

The only difference is that you need to remove the ‘–with-apxs=’ switch from the configure line. The prefix can stay the same, but it’s recommended to install this in a different directory, like /usr/cgiphp or something.

So technically your configure would look like this:

./configure –prefix=/usr/cgiphp –with-xml –with-mm ………
make
make install

Now check that the installation was successful (should say cli for this one, but cgi will work as well) :

/usr/cgiphp/bin/php -v

PHP 5.2.3 (cli) (built: Aug 3 2007 07:22:58)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Download the suphp.conf into /etc, which is the location you specified during the configuration of suphp:

cd /etc
wget http://v-nessa.net/imh_files/suphp.conf

Now you need to edit /etc/suphp.conf and change the handler paths to (lines 47/48):

x-httpd-php=php:/usr/cgiphp/bin/php-cgi
x-httpd-php5=php:/usr/cgiphp5/bin/php-cgi

Check httpd.conf to see if there is already an suphp module setup in the virtualhost entries. If not, set up the apache template to automatically add it for new accounts:

pico /usr/local/cpanel/etc/httptemplates/apache1/default

Under <IfModule mod_php4.c> (exactly as is) add these lines:

<IfModule mod_suphp.c>
suPHP_UserGroup %user% %user%
suPHP_ConfigPath /home/%user%/php
</IfModule>

suPHP_ConfigPath /home/%user%/php specifies the location of the user’s php.ini file, which will be created later. This is completely optional, as it is only necessary if you want to specify where the users’ php.ini files are going to be location (default location is public_html). Recent versions of cPanel already have an suPHP module loader, so you may only have to add the suPHP_ConfigPath line to the suPHP section.

You should do the same for SSL hosts in /usr/local/cpanel/etc/httptemplates/apache1/ssldefault.

Add the following lines to httpd.conf in their appropriate sections:

LoadModule suphp_module libexec/mod_suphp.so
AddModule mod_suphp.c

<IfModule mod_suphp.c>
suPHP_Engine On
suPHP_ConfigPath /usr/local/Zend/etc
suPHP_AddHandler x-httpd-php5
AddHandler x-httpd-php5 .php5
suPHP_AddHandler x-httpd-php
AddHandler x-httpd-php .php .php3 .php4 .phtml
suPHP_AddHandler x-httpd-php-source
AddHandler x-httpd-php-source .phps
<Files *.php5>
suPHP_ConfigPath /usr/cgiphp/lib
</Files>
</IfModule>

It’s also a good idea at this point to disable the loading of the Apache php module, so they can only run as CGI. Comment out these lines:

#LoadModule php5_module libexec/libphp5.so
#AddModule mod_php5.c

If you do the above, comment out the following lines:

#AddType application/x-httpd-php .php
#AddType application/x-httpd-php .php4
#AddType application/x-httpd-php .php3
#AddType application/x-httpd-php-source .phps
#AddType application/x-httpd-php .phtml

The users that already exist on the system should already have suphp directives in their virtualhost entries. If not, you will need to add them manually:

<IfModule mod_suphp.c>
suPHP_UserGroup user user
suPHP_ConfigPath /home/%user%/php
</IfModule>

In this one you actually need to replace ‘user’ with the username and group of the account.

Now you need to fix the first VirtualHost entry as well, which is the website that is displayed when you go to http://server.com on a shared hosting environment. This is the site that is pulled from /usr/local/apache/htdocs and PHP will not work in this directory, because your suphp.conf file defines the docroot to be /home, meaning that suPHP will not execute PHP that is outside of /home. When you find the VirtualHost container for the main IP add the following into that VirtualHost:

<IfModule mod_suphp.c>
suPHP_UserGroup <user> <user>
<Directory /usr/local/apache/htdocs>
suPHP_GlobalDocRoot /usr/local/apache/htdocs
suPHP_DontCheckVHostDocRoot Yes
</Directory>
</IfModule>

For the user, since PHP won’t execute as nobody or root, this needs to be a valid user on the system. Generally it’s best to create a neutral user on the system with no SSH access to be the owner of the htdocs folder. Whatever user you use, you will need to chown the entire htdocs directory to that user (or whatever directory you use as a default. The DontCheckVHostDocRoot part is necessary if you are running this outside of /home.

Last you should create a php folder in /root/cpanel3-skel with a copy of the server’s php.ini file, so new user accounts are created with a php.ini.

The path to the cgi php binary is /usr/local/bin/php, so you want to make sure that it is accessible when called from command line and that suPHP loads the new binary.

ln -s /usr/cgiphp/bin/php-cgi /usr/local/bin/php
ln -s /usr/cgiphp/bin/php-cgi /usr/local/bin/php5
ln -s /usr/cgiphp/bin/php /usr/bin/php
ln -s /usr/cgiphp/bin/php /usr/bin/php5

If you get an error about one already existing, simple delete it and try to link it again.

Now you have to copy the extentions:

cd /usr/cgiphp/lib/php/
mkdir -p extensions/no-debug-non-zts-20060613

pico /usr/local/lib/php.ini

Change the extension_dir value to that of the new folder you created, then copy all the files over:

cp /usr/local/lib/php/extensions/no-debug-non-zts-20060613/* extensions/no-debug-non-zts-2006061/

Depending on the server, the actual extension directory may be different!

Settings for suphp.conf

Suphp.conf lets you control the settings in place for suPHP. The following settings are the recommended in place for shared servers:

logfile=/var/log/suphp.log

The location of the logfile on the server, will be created automatically.

loglevel=warn

What information to describe in the logs. ‘info’ is very broad, but you can also use ‘warn’ to only show warnings.

webserver_user=nobody

What use Apache runs as — this basically indicates what user no php scripts can run as, even ones in htdocs.

docroot=/home

The base directory where php scripts have to be located in order to run, which prevents php scripts from executing from system folders. If a user for some reason needs to execute something from outside of home, you need to make a virtualhost directive containing:

<Directory /usr/local/apache/htdocs>
suPHP_GlobalDocRoot /<path to directory>
suPHP_DontCheckVHostDocRoot Yes
</Directory>

allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

This is the most important for security, specifying the allowable permissions of files and folders by other users than the one owning the script.

If your server currently has accounts on it, you’ll need to run these followup scripts:

/scripts/postsuexecinstall
/scripts/chownpublichtmls

From /home:

find -perm 777 -exec chmod 755 {} \; -print
find -perm 666 -exec chmod 644 {} \; -print
/scripts/fixsuexeccgiscripts

For the php.ini, you’ll also need to copy it from /usr/bin/php.ini into /home/user/php for all users existing on the machine before the installation of suPHP. New user accounts will automatically have this, as long as it you followed the step of copying it to /root/cpanel3-skel/php

If the server is running Fantastico, make sure you set the config to use phpsuexec.