You will need to remove php_value and php_flag from ALL .htaccess files you may have

In .htaccess under public_html, add the following:

suPHP_ConfigPath /home/AccountUserName/public_html
<Files php.ini>
order allow,deny
deny from all
</Files>

In php.ini under public_html add the settings that you want to use:

register_globals = On
post_max_size 6M
upload_max_filesize 6M
max_execution_time 90
max_input_time 90
....

Bookmark It

it’s recommended to backup the database before performing the deletion SQL statements.

Bookmark It

Here is a small script that reads all *.txt  or all *.html, all *.php  files and delete all lines between word1 and word2:

#!/bin/bash
FILES="*.php"
for f in $FILES
do
INF="$f"
OUTF="$f.out.tmp"
# replace
sed '/word1/,/word2>/d' $INF > $OUTF
/bin/cp $OUTF $INF
/bin/rm -f $OUTF
done

Then save this file as “myscript.txt”

run this script with: # bash myscript.txt

Bookmark It

It’s always a must for /var/log/messages to fill screens with tons of error messages, no matter what happened. But, when it’s about a disk crash, huge lots of kernel errors are reported. Some nasty examples, for the masochists,

   kernel: scsi0 channel 0 : resetting for second half of retries.
   kernel: SCSI bus is being reset for host 0 channel 0.
   kernel: scsi0: Sending Bus Device Reset CCB #2666 to Target 0
   kernel: scsi0: Bus Device Reset CCB #2666 to Target 0 Completed
   kernel: scsi : aborting command due to timeout : pid 2649, scsi0, channel 0, id 0, lun 0 Write (6) 18 33 11 24 00
   kernel: scsi0: Aborting CCB #2669 to Target 0
   kernel: SCSI host 0 channel 0 reset (pid 2644) timed out - trying harder
   kernel: SCSI bus is being reset for host 0 channel 0.
   kernel: scsi0: CCB #2669 to Target 0 Aborted
   kernel: scsi0: Resetting BusLogic BT-958 due to Target 0
   kernel: scsi0: *** BusLogic BT-958 Initialized Successfully ***

Most often, disk failures look like these,

   kernel: sidisk I/O error: dev 08:01, sector 1590410
   kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 28000002

or these

   kernel: hde: read_intr: error=0x10 { SectorIdNotFound }, CHS=31563/14/35, sector=0
   kernel: hde: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

And, as expected, the classic /proc/mdstat look will also reveal problems,

   Personalities : [linear] [raid0] [raid1] [translucent]
   read_ahead not set
   md7 : active raid1 sdc9[0] sdd5[8] 32000 blocks [2/1] [U_]

Later on this section we will learn how to monitor RAID with mdadm so we can receive alert reports about disk failures. Now it’s time to learn more about /proc/mdstat interpretation.

Bookmark It

redirectMatch 301 ^(.*)$ http://www.site.net
redirectMatch permanent ^(.*)$ http://www.site.net

You can also use one of these in your .htaccess file:

redirect 301 /index.php http://www.site.net/index.php
redirect permanent /index.php http://www.site.net/index.php
redirectpermanent /index.php http://www.site.net/index.php

If you need to redirect http://site.net to http://www.site.net and you’ve got mod_rewrite enabled on
your server you can put this in your .htaccess file:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^site\.net
RewriteRule ^(.*)$ http://www.site.net/$1 [R=permanent,L]

Bookmark It

Is it possible to get Awstats to send a monthly report with some basic stats  to Email?

Script to send last months AwStats report to an email address: www.sitepoint.com/forums/showthread.php?t=275042

This scipt will run on a web server with CPanel.  It uses the CPanel  system to log in and get the report page from AwStats for the previous month.

To use this script:

• change the strings located in the first block of code to match  information for your domain and CPanel account.
• Install the two script files into a location on your web server outside of the public html area (you don’t want someone accidently seeing the account details).
• Then set up a cron job to run the php program sometime after the first of the month. The command for the cron job might look like:php -q /home/userid/scripts/stats.php

Based on a script from Ronan Magee (ronanmagee on the SitePoint.com forum)
Modified by David K. Goodwin (dkg2000 on the SitePoint.com forum)

Bookmark It

I was recently surprised to see that my wordpress install folders have swelled up in size like anything. I have 3 installs of WP and I noticed that in the root of each install there were dump files with a name pattern “core.*” and with sizes to the tune of 12MB each.

core files come from a core dump. A core dump can happen for lots of reasons, but in shared hosting it generally occurs if:

1. Your site software is not compatible with the latest server software versions.

2. The server software itself was/is having issues.

• Check the content of the core dump files for clues. It is probably because one of your binaries (i.e. unzip, imagemagick) is not working correctly. If the core files point back to php, then it could be a a memory limit problem, a g2 bug, or a php bug.
• Try a clean install of WordPress (delete all old files, re-upload, new, empty database). Make sure you backup your blog (export all posts and also back up the database).
• ( System Administrator ) -  You can stop core files from being produced as a result of suPHP and Rlimit stoppages. In /etc/init.d/httpd at the top of the file you’ll see the ulimit command line. Add a “-c 0″ (slash-c-zero) to the line:
  Code:

  ulimit -c 0 -n x

  where the x above is the number previously assigned by your Rlimit script. That should stop core dump files

Bookmark It

How disable yum updatesd?
At least one other has seen this and it is a known bug, see: http://bugs.centos.org/view.php?id=2039

• service yum-updatesd stop
• chkconfig –levels 2345 yum-updatesd off
• chkconfig –del yum-updatesd
• yum –enablerepo=updates-testing install yum-updatesd

Bookmark It

Don’t leave your personal information exposed any longer! Protect yourself with FREE Private Registration when you register or transfer five domain names. Hurry, act now!

Private Registration More  Info

Bookmark It