Archive for October, 2010

cpanel 500 internal server error

I have seen many posts with people having trouble with internal server errors on cpanel while using suPHP as the php handler.

unfortunatley people seem to be going way above and beyond what is required to troubleshoot this issue.

A simple way to fix most issues is to simply login to your cpanel/WHM server via ssh and run /scripts/chownpublichtmls

In most cases it is simply a case that you have file permissions incorrect or you have root set as the owner on many of your files.

If that does not work then you likley have other permission based issues so I suggest you ensure all your directories are set to chmod 755 and make sure all your .php files are set to chmod 644 (suPHP will not work with permissions higher than 644)

you can check the permissions in command line by running e.g. ‘stat /home/john/public_html’

Hope it helps someone :)

 

Advertisements

Leave a comment

SSL + cpanel = 500 internal server error

Been working on this issue for some time and its been rather annoying, finaly got it solved with the help of a very helpfull member of the cpanel forum by the name of Miraenda.

Scenario:

You get a 500 server error after installing an ssl cert and using https and your error logs in apache contain somthing along the lines of:
SoftException in Application.cpp:422: Mismatch between target UID (99) and UID (503) of file “/home/someuser/public_html/anything.php”,

This is because the /var/cpanel/userdata/someuser/domain-name.com_SSL  does not contain the correct user info i.e. is installed as the wrong user (usualy nobody “UID (99) is nobody”)

FIX:

To fix this you first need to find your domain-name.com_SSL file in /var/cpanel/userdata/ look in this directory you will have a bunch of users in here one of which is likley to be “nobody” and is a good place to start.

Once you find the file move it to the correct user location.
e.g. if you are not sure which user it should be installed as go to the directory that is causing the issue and run “stat /home/someuser/publichtml/somefile.php” this will give you enough info to find out who it should be installed as.

Now you have the file in the right place you need to make a few changes to the domain-name_SSL file to make it work correctly.

You should see the following lines:

documentroot: /home/user/public_html
group: user
homedir: /home/user
user: user

Replace user with the username for each one. note, these are not the only lines in the file, they are just the lines you need to change in that file.

If the account is a reseller and not owned by root, you will also need to change owner: root to owner: user.

Please also check the ip: field has the right IP listed.

After making all the changes, then run these commands to rebuild Apache with the new entries and get it restarted:

/scripts/rebuildhttpdconf
/etc/init.d/httpd restart

Now test it again :)

hope this help someone.

 

4 Comments

How To rsync Server Setup for Centos

Little simple to follow guide I found on my travels, thought it might come in handy to some.

  • Make sure xinetd and rsync is available, if not type
    # yum -y install rsync xinetd
  • Add xinetd service to system
    # chkconfig –add xinetd
  • Make sure xinetd running on init 3 and 5
    # chkconfig –list xinetd
  • Enable rsync
    # vi /etc/xinetd.d/rsync
    Change disable = yes into disable = no
  • Create username and password for rsync client to use
    # vi /etc/rsyncd.secrets
    adminname:hispassword
  • Create configuration and shares for rsync daemon
    # vi /etc/rsyncd.conf
    max connections = 2
    log file = /var/log/rsync.log
    timeout = 300 

    [shares]
    comment = shared data stored here
    path = /home/adminname/shares
    read only = false # chg to true if you want read only
    list = yes
    uid = adminname
    gid = adminname
    auth users = adminname
    secrets file = /etc/rsyncd.secrets
    hosts allow = 10.10.105.0/24

  • Secure /etc/rsyncd.*
    # chown root.root /etc/rsyncd.*
    # chmod 600 /etc/rsyncd.*
  • Restart xinetd
    # service xinetd restart
  • Make sure rsync now running
    # chkconfig –list
  • Perhaps you also want to enable port 873 tcp and udp on your firewall so other can connect to your server
  • A good windows client if you intend using it from windown is DeltaCopy http://www.aboutmyip.com/AboutMyXApp/DeltaCopyDownloadInstaller.jsp

     

    Leave a comment

    Setting up A High Availability Cluster (Heartbeat) On CentOS

    This guide shows how you can set up a two node, high-availability HTTP cluster with heartbeat on CentOS. Both nodes use the Apache web server to serve the same content.

    Pre-Configuration Requirements

    1. Assign hostname node01 to primary node with IP address 172.16.4.80 to eth0.
    2. Assign hostname node02 to slave node with IP address 172.16.4.81.

    Note: on node01

    uname -n

    must return node01.

    On node02

    uname -n

    must return node02.

    172.16.4.82 is the virtual IP address that will be used for our Apache webserver (i.e., Apache will listen on that address).

    Configuration

    1. Download and install the heartbeat package. In our case we are using CentOS so we will install heartbeat with yum:

    yum install heartbeat

    or download these packages:

    heartbeat-2.08
    heartbeat-pils-2.08
    heartbeat-stonith-2.08

    2. Now we have to configure heartbeat on our two node cluster. We will deal with three files. These are:

    authkeys
    ha.cf
    haresources

    3. Now moving to our configuration. But there is one more thing to do, that is to copy these files to the /etc/ha.d directory. In our case we copy these files as given below:

    cp /usr/share/doc/heartbeat-2.1.2/authkeys /etc/ha.d/
    cp /usr/share/doc/heartbeat-2.1.2/ha.cf /etc/ha.d/
    cp /usr/share/doc/heartbeat-2.1.2/haresources /etc/ha.d/

    4. Now let’s start configuring heartbeat. First we will deal with the authkeys file, we will use authentication method 2 (sha1). For this we will make changes in the authkeys file as below.

    vi /etc/ha.d/authkeys

    Then add the following lines:

    auth 2
    2 sha1 test-ha

    Change the permission of the authkeys file:

    chmod 600 /etc/ha.d/authkeys

    5. Moving to our second file (ha.cf) which is the most important. So edit the ha.cf file with vi:

    vi /etc/ha.d/ha.cf

    Add the following lines in the ha.cf file:

    logfile /var/log/ha-log
    logfacility local0
    keepalive 2
    deadtime 30
    initdead 120
    bcast eth0
    udpport 694
    auto_failback on
    node node01
    node node02

    Note: node01 and node02 is the output generated by

    uname -n

    6. The final piece of work in our configuration is to edit the haresources file. This file contains the information about resources which we want to highly enable. In our case we want the webserver (httpd) highly available:

    vi /etc/ha.d/haresources

    Add the following line:

    node01 172.16.4.82 httpd

    7. Copy the /etc/ha.d/ directory from node01 to node02:

    scp -r /etc/ha.d/ root@node02:/etc/

    8. As we want httpd highly enabled let’s start configuring httpd:

    vi /etc/httpd/conf/httpd.conf

    Add this line in httpd.conf:

    Listen 172.16.4.82:80

    9. Copy the /etc/httpd/conf/httpd.conf file to node02:

    scp /etc/httpd/conf/httpd.conf root@node02:/etc/httpd/conf/

    10. Create the file index.html on both nodes (node01 & node02):

    On node01:

    echo “node01 apache test server” > /var/www/html/index.html

    On node02:

    echo “node02 apache test server” > /var/www/html/index.html

    11. Now start heartbeat on the primary node01 and slave node02:
    /etc/init.d/heartbeat start

    12. Open web-browser and type in the URL:

    http://172.16.4.82

    It will show node01 apache test server.

    13. Now stop the hearbeat daemon on node01:

    /etc/init.d/heartbeat stop

    In your browser type in the URL http://172.16.4.82 and press enter.

    It will show node02 apache test server.

    14. We don’t need to create a virtual network interface and assign an IP address (172.16.4.82) to it. Heartbeat will do this for you, and start the service (httpd) itself. So don’t worry about this.

    Don’t use the IP addresses 172.16.4.80 and 172.16.4.81 for services. These addresses are used by heartbeat for communication between node01 and node02. When any of them will be used for services/resources, it will disturb hearbeat and will not work. Be carefull!

     

    Leave a comment

    Setting up an SSL secured Webserver with CentOS

    This guide will explain how to set up a site over https. The tutorial uses a self signed key so will work well for a personal website or testing purposes. This is provided as is so proceed at your own risk and take backups!

    1. Getting the required software

    For an SSL encrypted web server you will need a few things. Depending on your install you may or may not have OpenSSL and mod_ssl, Apache’s interface to OpenSSL. Use yum to get them if you need them.

    yum install mod_ssl openssl

    Yum will either tell you they are installed or will install them for you.

    2. Generate a self-signed certificate

    Using OpenSSL we will generate a self-signed certificate. If you are using this on a production server you are probably likely to want a key from Trusted Certificate Authority, but if you are just using this on a personal site or for testing purposes a self-signed certificate is fine. To create the key you will need to be root so you can either su to root or use sudo in front of the commands

    # Generate private key
    openssl genrsa -out ca.key 1024 
    
    # Generate CSR
    openssl req -new -key ca.key -out ca.csr
    
    # Generate Self Signed Key
    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    
    # Move the files to the correct locations
    mv ca.crt /etc/pki/tls/certs
    mv ca.key /etc/pki/tls/private/ca.key
    mv ca.csr /etc/pki/tls/private/ca.csr

    Then we need to update the Apache SSL configuration file

    vi +/SSLCertificateFile /etc/httpd/conf.d/ssl.conf

    Change the paths to match where the Key file is stored. If you’ve used the method above it will be

    SSLCertificateFile /etc/pki/tls/certs/ca.crt

    Then set the correct path for the Certificate Key File a few lines below. If you’ve followed the instructions above it is:

    SSLCertificateKeyFile /etc/pki/tls/private/ca.key

    Quit and save the file and then restart Apache

    /etc/init.d/httpd restart

    All being well you should now be able to connect over https to your server and see a default Centos page. As the certificate is self signed browsers will generally ask you whether you want to accept the certificate. Firefox 3 won’t let you connect at all but you can override this.

    3. Setting up the virtual hosts

    Just as you set VirtualHosts for http on port 80 so you do for https on port 443. A typicalVirtualHost for a site on port 80 looks like this

    <VirtualHost *:80>
            <Directory /var/www/vhosts/yoursite.com/httpdocs>
            AllowOverride All
            </Directory>
            DocumentRoot /var/www/vhosts/yoursite.com/httpdocs
            ServerName yoursite.com
    </VirtualHost>

    To add a sister site on port 443 you need to add the following at the top of your file

    NameVirtualHost *:443

    and then a VirtualHost record something like this:

    <VirtualHost *:443>
            SSLEngine on
            SSLCertificateFile /etc/pki/tls/certs/ca.crt
            SSLCertificateKeyFile /etc/pki/tls/private/ca.key
            <Directory /var/www/vhosts/yoursite.com/httpsdocs>
            AllowOverride All
            </Directory>
            DocumentRoot /var/www/vhosts/yoursite.com/httpsdocs
            ServerName yoursite.com
    </VirtualHost>

    Restart Apache again using

    /etc/init.d/httpd restart

    4. Configuring the firewall

    You should now have a site working over https using a self-signed certificate. If you can’t connect you may need to open the port on your firewall. To do this amend your iptables rules:

    iptables -A INPUT -p tcp --dport 443 -j ACCEPT
    /sbin/service iptables save
    iptables -L -v

     

    Leave a comment

    How To Create Kickstart (Unattended)Centos Linux OS installation

    Kickstart means automated OS installation. Most Linux OS installation can be done via Kickstart and it can be performed using local boot media or over network(FTP, HTTP, NFS and etc).

    Here, we’re going to talk about using HTTP method to perform Kickstart.

    Prerequisite:

    1. Boot media (for creating a USB bootdisk, you can refer to my earlier article)
    2. You should have the Centos installation CD/image to crate the installation tree
    3. Running Webserver for Kick Start OS installation
    4. Running DHCP server (Optional)

    Setting Up Kickstart server:

    1. Create a directory name “Centos5.5″ in your webserver DocumentRoot.
      • eg: mount -o ro /dev/sdc /media/cdrom
    2. Insert the Centos CD-ROMs and copy all the binaries into that directory (copy the binaries from all the installation CD-ROMs)
      • eg: cp iVaf /media/cdrom/Centos /var/www/html/Centos5.5
    3. Create an answer file for automate the installation process.
      • You can use any kick start configurator tool or refer to the file /root/anaconda-ks.cfg in any of your Linux machine.
      • Or you may download my sample ks.cfg (18) as reference
    4. Copy the ks.cfg file to your Centos5.5 directory.
    5. You will have 1 new directory and 1 ks.cfg created like below:
      • For example /var/www/html is your DocumentRoot
      • You will have /var/www/html/Centos5.5 and /var/www/html/Centos5.5/ks.cfg
    6. Attached boot media and then boot up the machine that you want to perform Kickstart OS installation.
    7. Configure the BIOS setting to make your boot media as “First Boot Device”
      • For my case cause I’m using USB hard disk, so my “First Boot Device” should be Removable.
      • Save the BIOS setting then continue
    8. You will see OS installation menu screen, fro there type in below BOLDcommand
      • boot: linux ks=http://192.168.1.1/~chenhow/Centos5.5/ks.cfg
      • 192.168.1.1 is my Web server IP
      • ~/chenhow is my subdirectories (I’m using userdir module for lighttpd)
    9. Then, the installation process will start and everything should be automated.

     

    Leave a comment

    How to use Cron Jobs and Scripting

    Cron jobs

    Today I needed a quick solution to monitor the free space on my Ubuntu server.  I didn’t want to setup monitoring software just to find out a quick statistic about the server’s disk space so I figured I could write a script to check it for me.  This would also give me a chance to practice setting up tasks via the command line with cron.  My requirements for this were just to check the amount of free space on the single hard drive on the server.  The output would also contain the time & date so I could get an idea of when the drive was last checked. 

    First a script to get the information that I need from the server.  We can use the “df” command which will show information about the file system.  This along with some parsing commands will give us the results that we need.  The script goes something like this:

    #!/bin/bash
    date >> driveSpace.log
    fspace=`df -h | grep sda | awk ‘{ print $5 }’`
    echo “There is “$fspace” disk space left.” >> ~/driveSpace.log

    This little script creates a log file in my home directory (called driveSpace.log) which will get a “date” stamp and a single line telling me how much disk space is left on the drive.  I saved this as diskSpace.sh and also left it located in my home directory.  Next we will need to setup the cron command that will allow this script to run once a day to check the disk space.  In order to run the cron process as a non-root user you will need to have your account listed in the /etc/cron.allow file.  Now I’m working on an Ubuntu server and by default there is no cron.allow file you need to create it.  If you don’t the cron job will never execute.  My test user is called Jake so I will add him to the cron.allow file.  Use the sudo command to create the necessary file:

    sudo echo Jake >> /etc/cron.allow

    This will create the file and also put Jake in the file so that he now has rights to run his own cron jobs.  Next we can go ahead an create a crontab file for Jake.  Enter the following:

    crontab -e

    This will create a new crontab file (if one doesn’t exist already) and then bring you into that crontab file for the user.  You’ll see on the top commented out the syntax that we need to use in order to create cron jobs.  For our script we are going to use the following syntax:

    01 04 * * * /home/Jake/diskSpace.sh

    This syntax says that I want to run this script at 4:01AM every day of the week and output to the logfile specified in the script.  This way I can monitor the log file to check how full my system disk is.  You can get more fancy with a script like this as well making checks to see if the disk is at a certain threashold, or to email you when it breaks a certain threashold.  This is just a basic example of how powerful scripting can be along side creating tasks to automate the process.

    Leave a comment

    %d bloggers like this: